IP Power Strip #03 - the Python development environment setup for the IP Power Strip

I have been reviewing some blog material concerning Python docker development, here, here, and here.  In addition I have been reviewing some Python libraries developed to interface with MQTT.  I intend to use docker-compose to separate out the different elements so that I can individually change the code.  I also need to think closely about how I will be developing containers that might run on different platforms other than the Raspberry Pi, for instance on the Ubuntu server which is of a different architecture.  The environment should look like this:

• IP_Power_Strip_Project
• docker-compose.yaml
• Master
• Dockerfile
• requirements.txt
• Src
• globals.py
• Master.py
• Slave
• Dockerfile
• requirements.txt
• Src
• globals.py
• Slave.py
• InterfaceProxy
• Dockerfile
• requirements.txt
• Src
• globals.py
• InterfaceProxy.py
• Shutdown
• Dockerfile
• requirements.txt
• Src
• globals.py
• Shutdown.py

For right now that covers it.  I will update this post as I come into other aspects of the development.

UPDATE: rejuvinated

IP Power Strip #02 - How the IP Power Strip will work in the network

I am looking to make the IP Power Strip as useful in my network as is possible.  I should be able to use the IP Power Strip outside of the normal turn on/off my HomeLab and extend it to things like control lights during Christmas and Halloween.  What I am doing is turning power on and off.  Throughout the year it makes sense that I would use the units in the HomeLab, but these units would also have a use elsewhere.  I am rather interested in integrating it with my HA-IOT network and use the MQTT server that already resides there.

For the Master container, I visualize the following:

• it should be able to be "programmed" with control sequences to a certain point through MQTT messages
• I should be able to issue different sets of controller sequences "programs" so that the IP Power Strip can be controlled independently depending on the context
• I should be able to issue a list of IP Power Strip containers (IP addresses) to the Master container so that it knows the locations
• I should be able to effect a controlled sequence when tasked by an MQTT message
• I should be able to simply indicate a vacation mode and have the Master container do the rest
• I should be able to poll the Master container to reveal the current status of the IP Power Strips and what they are controlling
• The Master container should be able to respond to heartbeat messages in context

For the Slave container, I visualize the following:

• I should be able to have the Slave container come up issuing heartbeat messages to the Master container to indicate the status
• The slave container should be able to be controlled via MQTT messages for a single change or multiple changes
• The slave container should be able to be controlled via MQTT messages to stop/start issuing heartbeat messages

For the InterfaceProxy container, I visualize the following:

• This container is how we interface to the actual equipment, it is a proxy by reason that there may be other already built IP Power Strips, or power like systems that we want to integrate into the IP Power Strip system
• The InterfaceProxy container should be controlled by a RESTful interface, with json coding
• The only container that would interface would be the Slave container, on the other side is hardware
• The InterfaceProxy should receive unique IDs and be able to respond to a request for number of "ports" as well as initial setup and current setup for the "ports".  Initial setup defines how the "ports" come up from a hot start
• Notice that the InterfaceProxy can also serve as a test container which can be metered and check for correct sequences at the low end

For the Shutdown container, I visualize the following:

• I should be able to have the Shutdown container come up issuing heartbeat messages to the Master container to indicate the status
• The Shutdown container should be able to be controlled via MQTT messages to start a shutdown on the computer where it resides
• The Shutdown container should be able to be controlled via MQTT messages to stop/start issuing heartbeat messages

UPDATE: rejuvinated

HomeLink HA Interface #7 - altered way to put NodeRed and setup interface

I was having difficulties with getting the docker version of node-red to do what I wanted to do with the Raspberry Pi.  It seems like I wasn't able to update Node.js and the docker repository wasn't helping.  So I decided to abandon the docker version of node-red, but keep docker, run node-red natively, and set it up to command the interface to send MQTT topics to my Home-Assistant server.

-- remove the docker-compose elements
sudo docker-compose down -rmi all

The preceding command not only stops all containers setup using docker-compose, but it removes the images after stopping the process.

Now that I have accomplished this, I move to install NodeRed on the Raspberry Pi natively.

-- install nodered, node.js
sudo apt update
sudo apt install build-essential git
bash <(curl -sL https://raw.githubusercontent.com/node-red/linux-installers/master/deb/update-nodejs-and-nodered)

This did manage to take a long time due to this being an RPi Zero.

HomeLink HA Interface #2 - Experiments with the LiftMaster 850LM

So I decided to go ahead and test out the LiftMaster 850LM to see what I was up against. This device will become central to how I am going to interface my home automation system to my car.  I have always been a little upset that there were no interface devices to link my car to other than a simple switch or a garage door.  That is shallow thinking on the part of the automotive industry and the people who make garage door devices.  Anyway I digress.

The 850LM is going to be used to detect button clicks from my car and convert those clicks to MQTT messages that will be sent to my home-assistant controller via an MQTT broker. I expect to interface this on a Raspberry Pi Zero W (RPi0W) using its gpio pins.  However, there are a couple of issues that need to be resolved. The gpio pins on the RPi take 3.3v and the lowest voltage DC that the 850LM can handle is 9v.  Fortunately, I noticed previously that the Adafruit bi-directional level shifter can take a high side voltage up to 10vDC.  That means that I can use the level shifter between the 850LM and the RPi0W. The main reason that I want to use the RPi0W for this interface is that I can run the software under a Docker container, and allow for another container to House a Bluetooth proximity sensor / MQTT setup. Note that the RPi0W needs a 5v DC power source, but generates its own 3.3v power for the gpio.

The 850LM has a power port as well as a screw connection marked plus and minus. It has a total of three relay connections; the first two having NO / GND screw terminals and the third having NO / GND / NC screw terminals.  So my first question was how do the power port and power screw terminals relate.  The second question was when the relays switch is it momentary (governed by how long you press the button on the car), is it momentary (fixed close then open time), or is it more of an on / off switch (changes as you click the car button). Fortunately, I should be able to use a remote control to do the testing.

Test 1: I powered up the 850LM using a 5v to 9v usb cable that I had lying around by plugging it into the power port.  I had to use an adapter because the center pin on the power port was thick (white size). Once powered up, I had no problem setting up the remote control by following the 850LM instructions (click yellow button on 850LM, led next to button flashes, click button on remote, led goes out).  Once I did this, a click on the remote caused the relay to close and then open on its own.  So I answered the second question.  It makes sense because most garage door controllers have wall switches that momentarily close a connection which starts the garage door motor running.

Test 2: I then checked the power terminal pins and discovered that there was on voltage in the millivolt range.  This means that I cannot power the 850LM and draw power from these terminals when the 9v supply is plugged into the power connection.

Test 3: while clicking on the remote, I checked the voltage levels appearing between the NO / GND terminals.  This did not measure any change from zero volts.  This means that I will need to use a pull-up resistor for transitioning on the level shifter.  It also means that I will need to deal with negative logic; high showing up on the gpio means False / 0 / not clicked, and low means True / 1 / clicked.  I might end up using interrupts instead of running everything through a loop in order to not interfere with other container programs.

Test 4: I connected my 9v power source to the power screw terminals. I checked the on / off with my remote and everything worked out just fine.  So I will be connecting the 9v source (via a barrel to screw terminal adapter) to these terminals, along with the input side of a Buck converter (to give 5v from the 9v source) and some connection wires to power up the high side of the level shifter.  What I may do instead is put everything on a breadboard connected to the RPi0W gpio and minimize the connections needed (use the breadboard as the connection points for all of it).

I wonder if I can mount the Buck converter on the breadboard as well, that would save some space for me.  I am also concerned that the Buck converter might interfere with the functioning of the RPi, but I will have to test that out as everything is built.