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.

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

Project #22 - Heartbeat / Shutdown Container to shutdown computer equipment in a graceful manner

I was also thinking of a third container that might be useful.  A container, that interfaces to MQTT, that issues heartbeats, and can issue a shutdown command on equipment.  The master controller would then have the ability to issue an mqtt shutdown command, listen for heartbeats, then when the heartbeat ceases, could issue a command to the IP Power Strip to turn off the power to that computer and report back status on the computer.  This has the added thought that it would be universal, working on different operating systems.  The code is pretty much the same, but the implementation is different.

IP Power Strip #01 - Some initial considerations

 I started thinking about an IP Power Strip almost 3 years ago in December 2017.  Since that time I have been inundated with work issues and never really came back to this project since I was always tired from work.  Now that I have been having more time at home due to the pandemic, and the fact that I had a power outage in my house that damaged a lot of equipment, I have returned to this project.  I have a definite need to turn a lot of my HomeLab equipment off when I am involved with other things.  I hope to travel and my interests have gone to other things like woodworking and wood carving.  I don't wish to give up the HomeLab completely, but at the same time I would not like to pay the whole bill if it just sits there idle.

First, I rearranged my network for power conservation and opened up a new project for an IP Power Strip.  I am hoping to be able to control the power strip from an MQTT based service.  I figure that if I setup Raspberry Pis with some relay hardware on a hat, then have the controller software running on the RPi interfacing to an MQTT server, I should be able to make this work.

I put in an order for three Keyestudio 5V DCAC 4-Channel Relay Shield Module Expansion Board for Raspberry Pi from Amazon.  I figure the easiest way to develop an IP Power Strip is to use a Raspberry Pi for the "brains" and a shield/hat that has relays on it.  Note that this one has a 10Amp limit on current through the relays.  But, and here is the good thing, individual items that will be controlled don't have anything near the 10A limit.

If I develop the software using a python controller, embedded in a docker container, then updates will become easier and my development environment can move around at will.  There will be two actual containers that do the work: (a) a master controller that does the real thinking concerning sequencing of on-off commands, looking for heartbeats from the slaves, etc. and (b) a slave controller that does the heavy lifting in that it actually turns the relays on and off as well as issues heartbeats, etc.  This should allow me to put as many IP Power Strips around the house that is necessary.  Also, I can issue commands via the home-assistant console.

I was also thinking of a third container that might be useful.  A container, that interfaces to MQTT, that issues heartbeats, and can issue a shutdown command on equipment.  The master controller would then have the ability to issue an mqtt shutdown command, listen for heartbeats, then when the heartbeat ceases, could issue a command to the IP Power Strip to turn off the power to that computer and report back status on the computer.  This has the added thought that it would be universal, working on different operating systems.  The code is pretty much the same, but the implementation is different.

Trying to Resurrect the WeatherPi

Now that I have most of the previous parts of the network seemingly working again (have found replacements for the two Netgear GS108Tv2s that crapped out), I can concentrate on some of the other items that seemed to have gone south.  The first up is the WeatherPi that is connected to my Personal Weather Station.  It doesn't seem to be pushing data out anymore.

I am also wondering if this would be a good time to replace the WeatherPi with a USB server and move the weewx program to the HA Server.  The HA Server is also giving me problems right now, but I can deal with that later.  First off, I am going to try to get the WeatherPi to at least push data to weather underground again.

I did manage to remove the WeatherPi from underneath the TV stand and discovered that the SD Card was pretty much done with (probably a result of the power outage).  I put a new SD Card into the RPi that used to be the WeatherPi and discovered that the RPi was okay.  The new designation was PiHoleLDAP; apparently this was the one that was going to be the one that I was going to use for the PiHole, Radius, and LDAP setup using Docker.  Which reminds me, there is no reason that I cannot run weewx under Docker, I just have to research it.

There seems to be a bit of a problem with weather underground.  Since IBM took over, the API has been removed; so things like predictions and the like are no longer available to gather for an html display.  Weewx has not been updated for Python 3, so should I go to a different outlet to publish the weather station data, or should I just abandon the weather station all together?  Part of me is saying the latter, because I still have to maintain the station, look at the stats, and generally update portions of this as my time allows.  Going into retirement, it would be a scheduled activity that I would do say once every two weeks.  Not sure if it is worth the trouble.

Update: it is looking like weewx under Docker is going to be a pain to complete.  There are a number of builds on the Docker site, but all of them are rather complicated.  I am going to have to delay getting this accomplished.

The Network is Starting to Show Signs of Life

After much pushing and proding, I can now see the network coming back to life.  I was very quickly able to get the Media portion of the network back online.  But I was having trouble getting the other things like the printer and the WiFi working again.  The main culprit was the Netgear switch that controlled the printer, HA Server, and UniFi WAP.  When that went down I couldn’t control anything because of the multiple vlan nature of my network.  The switch had all the appearance of being fried, and since I had not succeeded in gettin extra port connections in one of the patch panels upstairs I was limited in what I could do.  Fortunately, I found out that the switch I used on the Ubuntu server was still operational.  Since the Ubuntu server is currently down I decided to use the switch as a replacement for the one upstairs.

So I obtained the text configuration of the switch that failed, changed the IP, and pushed it onto the replacement.  By replacing the previous switch, I now have a working system - at least in part.  This has also given me time to think about how to get my network back and running should I have such a disaster happen again. First, I need some things to make sure that a power outage doesn’t decimate things again.  I ordered some coax surge protectors to put on the TiVo Edge and Mini. Those are installed and I should not have a problem from the coax side of things.  I also purchased a couple of Ethernet surge protectors.  Lastly I have a whole house surge protector on order that should protect that part as well.

Ok People, Learn from my Mistakes

Updated: with new information on discovering electrical wiring mistakes.

This is a long post so bear with me.  I am putting this out there so that others can learn from my mistakes in networking.  If you read through to the end you will learn a lot of lessons including the ones that you will comment as “well everyone knows that.”

I have a distributed HomeLab that I have built up over the years that I had become quite proud of.  It allowed me to move equipment about the house and make changes as I needed as well as include new equipment that I purchase.  This included at least 8 different vlans for different purposes, including separating media and IOT equipment.  On the night of July 23rd we experienced a power outage.  It expressed itself as a loud bang, followed by the lights going out, and I witnessed a few sparks fly from the pole in front of my house (no transformer, just Verizon Fios gear).  The power came on about 30 seconds later but my internet, phone, and TV channels weren’t working (I have Verizon Fios).  SWMBO went to reading while I went off to explore what had happened.

I went downstairs to look at the ONT interface (I have the older version) and it was flashing as well as telling me that it was using battery power however, no problem lights.  Checked the electric panel and no breakers had been thrown.  Went back and reset the ONT interface, unplug and pull battery; reverse order to get it back.  Flashing stops for about 2 seconds, then goes back to the same flashing and battery lights.  So I get my meter and check the plug that the ONT interface was plugged into, power level is where it is expected.  I then went into my computer room and the first thing I notice is that my main router and accompanying managed switch have no lights on the front panel.  Sure enough, I try to access the router from my Mac Mini and no luck.  I pull the power from the router and the switch and I am getting power to both showing on the meter; also the UPS they are plugged into is showing no signs of problems.  The UPS has regulated power as well as surge protection so I was surprised.  I then pull out all of the patch cables from one of my extra Edgerouter-X, then I pull the ONT patch cord out from my main router and put it into the ER-X wan port, then I pull up a cable and connect the Mac Mini to the ER-X.  Looking into the configuration screen, I see that the ONT is alternating between connected and disconnected, and no IP.

Lesson 1: make sure you have a back up plan to troubleshoot in case you have a catastrophic network failure.

Lesson 2: a Patch Panel setup can save your bacon if you have to reconfigure your network in a hurry.

I tried a few different things, then concluded that the ONT wasn’t going to do its thing anytime soon.  I went off to bed knowing that SWMBO would not be happy in the morning.  The next morning I went searching for damage.  I found that I had lost the ONT (apparently), my main Cisco router (on UPS), my main 26 port Netgear managed switch (also on UPS), along with two 8 port managed switches (both on UPS) in my network.  I then set about reconnecting patches in a different way to connect my media equipment to the ER-X I had setup last night.  Fortunately, that was rather quick given that I had a diagram of the patch panel connections.  Once I did that, I called Verizon to get a tech out to fix the Fios connection issue, delay was a couple of days at least due to volume.  Having the media equipment on a flat network then allowed me to at least view the recordings SWMBO had made on our TiVo Bolt.  Unfortunately, it also showed me that I couldn’t see any of the TV channels on the Bolt, which was odd.

The Verizon tech appeared the next day and after some analysis replaced the ONT, and set me up.  Now, I was getting internet and my phone (on internet) was working.  Unfortunately, there were still no channels that I could receive on the Bolt, even after a cable card swap; I could however get to the internet.  So, I reasoned that the Bolt was bad so I contacted a family member that had recently converted their Bolt to a TiVo Edge.  I picked up the Bolt, got it back to the house, connected it and now I was receiving tv channels, verifying that I had lost my TiVo Bolt somewhere in the process.  I went downstairs and attempted to connect the TiVo Mini to the new Bolt, but was unsuccessful because these pieces of equipment were on two separate TiVo plans and the TiVo DRM kept me from connecting them together.  I then went out and purchased a couple of unmanaged switches that had decent throughput (2GB per port) to use with setting up the media on the network.

Lesson 3: Don’t forget that there may be DRM issues when you try to bring your equipment back up.

Lesson 4: Having equipment on UPS doesn’t guarantee that your equipment will be perfectly protected, there may be other issues.

I swapped some more patch cables so that I could get my UniFi AC-AP-Pro to at least give me wifi to the internet.  Now that I had at least a semblance of media working for SWMBO, it was time to determine what else had happened and how.  I went back and looked at my Cisco router and discovered that I could reset it and at least get the front lights working.  However, it was apparent that at least half of the 16 ports were fried, including the two WAN ports.  This led me to realize that there must have been a surge through the Ethernet lines; again odd.  In fact when I traced the path of the equipment that had failed, it was apparent that the surge came through the Ethernet cables connecting each device.  Since my TiVo Bolt was able to access internet but not the tv channels, it must have gotten the surge through the Coax cable.  Update: I later discovered that electricians that had wired my new kitchen appliances had used the main conduit that I had my longest Ethernet cabling and COAX cabling on.  Evidently I was the recipient of a power surge that had induced voltage in the Ethernet and COAX lines enough that it overcame the networking and media equipment.  I didn't first figure this out due to the odd failures I was seeing.

Lesson 5: it is important to invest in surge protectors on both Ethernet lines and Coax cables in your network because stuff happens.  Oh, and it wouldn't hurt to have a whole house surge protection system to limit collateral damage.

I have since purchased an Edgerouter 12 and the same Netgear M4100-26g switch that I had before (I actually like this switch).  I am still going through provisioning my network even two weeks after the initial power outage.  This morning I discovered another device that had bit the dust, my Ubuntu Desktop server.  It has all the appearance of a power supply problem; it boots, then powers off very quickly, even after getting to the screen where I enter credentials to login.  The server was also plugged into the UPS, go figure.  I am going to check out this one UPS to make sure that it is doing what it is supposed to do.  I also don’t have the UPS connected to a device to register error messages and do something with that information.  Update: I did indeed have to replace the power supply in the Ubuntu server.

Lesson 6: if you are using a UPS, make sure it is connected to a server to gather error messages, if nothing else but to determine if it is going bad.

Long story short, I am still finding things that have failed or partially failed due to this power outage.  I haven’t even looked at my home-assistant server and IOT equipment yet.  I am almost afraid to do so.

Lesson 7: have at least a minimal setup in mind to get your network back up after failures.  It may involve using older equipment or less capable equipment but those devices can come in handy.  Don’t just throw out old equipment, but be reasonable as well.  Don’t keep everything you have ever had in the network, just keep enough to get you back up and running.

Lesson 8: make a decision on what is important and what can wait should a catastrophe happen and you have to configure quickly.

Post log: I now have Ethernet surge protectors, Coax surge protectors, a whole house surge protector setup, have removed / rerouted the central Coax, and have two fiber optic setups running through the original central channel for network connection.

Hopefully, these thoughts will be important enough to you to think through your network and what may happen.  Good luck to everyone!!

LW