Labels

Friday, October 23, 2020

IP Power Strip #05 - Some Operational Considerations for the IP Power Strip Project

 I have discovered that most of what you want to do with a scene in IOT is actually a binary sequence, it either is or isn't performing it's function.  Lights on / off, doors locked / unlocked, security alarmed / not-alarmed, etc.  You have some secondary effects like dimming values or changing a lights color but that is after you turn the light on, likewise with setting the temperature on a furnace.  So in essence it is a two message sequence.  Likewise, if you are shutting down a plug and a computer is connected to it, you would want to send a message to start the shutdown, followed by a timer of so many seconds before you issue the turn off plug message.  

As I have been using Node Red, I realize that it doesn't necessarily scale well, and you are re-deploying the Node Red thread multiple times as you are making changes on different tabs (unless you purposefully select just the new flows before deploy). And if you need to run tests on a separate vlan as you are doing development it breaks the stuff that you already have working. Also, by partitioning the problem up into smaller bits, your Node Red applications can continue to run while you are developing something else. By having the applications in smaller chunks it supports the CI/CD development pipeline.

What do you do if you want to add additional plugs to power your HomeLab network? I need to bring stuff up and down all the time. How do you do this in such a way that it is a minor bump if you add additional power strip plugs to control and additional ways to control them with? What if you need to drop in a dimming controller to be controlled by a new set of Node Red controls without disrupting Node Red flows that already do something that works? What do I do if I need the host that my Node Red flows are running on for something else? Can I simply move it to a different host? What if the host is not an ARM but it's an i386 based processor?

This experiment has everything to do with getting very familiar with Node Red as a prototyping tool. But I also wanted to be able to take down portions of my network (servers, switches, etc.) when I would shift attention to some of my other hobbies like woodworking/woodcarving. I wanted to be able to take on multiple types of smart plugs, some based on RPi hats, some based on wifi power strips, some based on z-wave devices. I wanted to be able to add onto, or subtract from what I was doing without having to continuously update one server worth of Node Red. Doing it in Docker containers has allowed me to move things around easily. I can see this generic control set (Master and multiple Slaves controlling multiple Interfaces to the hardware) being used for all kinds of things IOT wise. I also wanted to have control over what is powered up (including lights) from both home-assistant, NanoMotes and WallMotes and garage controllers without changing either a scene def in home-assistant or changing up my single Node Red instance.

That being said, let me use my experience in other systems to explain why this setup might need multiple instances of Node Red and why that makes sense. Think of those automations that are temporary, with two examples: a test and a temporary power setup.

Say I have an already running automation with Node Red in a Docker container. It is using an MQTT broker as the go between for all the “production” automations. In this case I would like to add some functionality to my “production” automation. If I have my MQTT broker running in a container, I can just spin up another instance on a different host (note different IP). I pull my definition for the automation from a Configuration Management server, like Git, modify the MQTT IP to point to my test MQTT broker and spin up the container (this could be automated with a script). If I require other containers for development I can also pull those, change the MQTT IP, and spin them up before making changes (this could also be part of the same script), I might even need some test driver NR containers as well. I can now make changes as necessary for the new function and test it until I am satisfied it is what I want. I push the definition back to Git. The containers I needed for development and test can now be taken down. I can now deploy the change, that involves taking down the “production” automation container, pulling the updated automation container, setting the MQTT IP for production, and spinning up the new container which now should take the place of the old one. By doing it this way, I have minimized the down time for the “production” automation.

In the case of the temporary power setup, in my experiment, I might need a new automation for part of a Halloween or Christmas display where it changes from year to year as to what lights are lit; or alternatively I might have to set up the lights for a party which I just found out about the night before. In my power experiment I have at the bottom layer, an InterfaceProxy that controls individual power strips, switches, lights or what have you. Each plug is given a name representative of what it is powering (and can be changed on the fly). Each plug also has a semaphore count that dictates whether the plug is turned off or not. The next level up is a Slave Function, which controls a grouping of plugs. Each plug might have more than one grouping assigned to it. The Slave takes care of one grouping of plugs which might go across multiple devices. The Slave knows it’s list of plugs when it is given a list of names. The Slave issues the turn off, turn on when it is commanded. A Master Function controls the whole thing at the top. You only spin up a Slave container when you have a new list of plugs to control. You only spin up an InterfaceProxy container when you have a new set of hardware “plugs” to control.

So for my Christmas lights example, you would bring out the smart power strips (probably Tasmota), spin up one or more InterfaceProxy containers, set the plug names, spin up one or more Slave containers, give the list of plugs to control for each from the Master container after the Slave announces itself, and you can then control your Christmas lights through the Master container. After Christmas the new containers are spun down, smart power strips and lights are put back in storage until next year. For the party example, just feed a list of the plug names that need to be controlled, and the Master container spins up a Slave container and the cycle repeats. The new Slave container goes down after the party.

So development of the MQTT messages that control all this will be paramount.

Monday, October 12, 2020

IP Power Strip #04 - the Strikedown Container

I had suspected that the fastest way to build this was to use node red, at least I know that shutdown and reboot are easily implemented.  The issue is Mac and Ubuntu computers.  I don't think that  I will need to consider PCs (except for the Atom HA-IOT Server which runs Ubuntu).  I got the initial sequence done in node red, however I have not set it up yet to do an actual shutdown/restart - still figuring out the MQTT messages to use.  I decided on the following messages

  • relay/strikedown along with relay/strikedown_answer
    • reboot: 0/1, name: IP1, ping: 0/1
    • if reboot is 0 then does a shutdown
    • if reboot is 1 then does a restart
    • if ping is 1 then starts ping message sequence (5 times with 2 sec in between)
    • note when ping is 1, upon restart the ping sequence will start up
  • relay/myping
    • name: IP1, ping: 0/1
    • if ping is 1 then starts ping message sequence (5 times with 2 sec in between)
    • if ping is 0 then stops ping
    • note when ping is 1, upon restart the ping sequence will start up
  • relay/ping
    • name: IP1

strikedown, the Docker container in node red, will always use port 1885 on each host.  That way, I will be able to get to the node red invocation to make changes.  For strikedown on Raspberry Pi, theer is a node red contrib library that does both functions.  For the one on Ubuntu servers it will have to be made specific to the server.  I am thinking of using Python since there is a Python function node in the contrib library.

The strikedown node red sequence is in two parts, the startup and the strikedown sequence.  The startup sequence is:


The strikedown node red sequence is:


Update: I have since discovered that the Shutdown and Restart Nodes in this sequence do not work under a Docker Container running on RPi.  So I will have to figure out how to accomplish the task in another way.

Friday, October 2, 2020

Tips #7 - My Network Philosophy in So Many Words

When considering how to think about, design, and develop a home network you must consider your specific situation.  If I were to pick one topic I would have to stress the word CHANGE.  Change will happen to your network over time and you must be able to react and plan for it.  Networks are never static over time.  Here are some items to consider:

  1. Are you going to stay put for very long?
    • Renters know this, you don't just punch a hole in the wall to do something; you will end up having to repair it before you leave
    • The answer to this question might mean the difference between an all wifi or a partial wifi solution
  2. What are you planning on doing with your network?
    • You may have simple plans for what you are doing now, but what about the future uses?
    • It's not always about gaming
    • Consider things like setting up for IOT, cameras, and media in the future
    • Write up a list of the order of importance for things you will use the network for
  3. Cables will stay, devices will always be subject to moving
    • If you have spent the time putting a cable into a wall or overhead, you will really not want to move it again
    • I have moved my main router to 5 different locations in my house over the years - will you have to do the same
    • Consider the fact that equipment may fail and have to be replaced
    • You may, over time, have different ISPs that you deal with - I have dealt with 3 different ISPs over the years, each one had a different way of presenting their services to my house (dial up, cable, fiber optic)
  4. Do you really want to drill that hole?
    • Once you drill a hole, you are stuck with it
    • If you ever move you will have to repair it
    • Placement of a hole is important, can it be hidden - not everyone wants to see a cable sticking out of a wall, especially spouses
  5. Always start with the cabling
    • If your neighbors are "jaming" the wifi signal it will be nice to be able to fall back on cabling to supply your network needs
    • Don't forget you have options: Ethernet, Coax Cable, fiber optic in addition to wifi
  6. Patch panels, strategically placed, help in the movement of equipment
    • If you use keystone patch panels with straight through couplers you will always have the ability to use already made cables
    • Couplers allow you to move the positions of the Ethernet cable ends on a single patch panel
    • Patch panels allow you to use small patch cables to make one long connection between patch panels when a direct connection was not available
  7. Consider the judicious use of vlans in the Network to isolate equipment
    • Vlans give you the ability to minimize the number of cables run to different parts of the house; you use a "trunk" line from one managed switch/router to another and keep other ports on the router/managed switch to one specific vlan
    • Vlans give you the ability to isolate different segments of your network for different purposes
    • If the router from your ISP doesn't have vlan capability, you can always put a router behind it that does, or alternatively use your own router for the connection to the ISP
  8. Use the highest bandwidth switches and routers that your budget will allow
    • As bandwidth gets cheaper, and/or the signal from your ISP changes over time you may encounter a situation where it is advantageous to have already installed equipment that can meet the bandwidth increase
    • This means that you should always consider the cabling and what it's bandwidth capability provides; right now Cat5e should be sufficient, but you may want to consider Cat6 and above for growth
  9. Always consider the unthinkable, like failures and how it will affect the network
    • I have had older equipment fail on me when it was most inconvenient; being able to quickly replace the equipment because you thought out the problem beforehand will help
    • I have lost equipment to lightning strikes; never assume that it will not happen to you
    • Put lightning arrestors on Ethernet lines from the outside and on Coax cable connections to equipment
    • If at all possible get a whole house surge protector for those times when a higher than usual voltage spike happens that gets into your house
    • If it is within your budget consider the judicious use of UPS at different spots in your network; sometimes a hard fail of power will cause a failure in hard drives
    • If some piece of equipment fails in the network, how fast can you come back up to a semi normal state, or at least most of your list of network importance from #1 above
  10. Consider security when you are setting up the network
    • It goes without saying that IOT equipment needs to be isolated, due to it's very nature of contacting outside servers; if at all possible, keep the information in your house
    • Never assume that the router on the perimeter will always protect you from intruders; in fact, always assume that someone has already attacked and entered your network and design accordingly


Thursday, October 1, 2020

Unusual problem connecting Node Red to Home-Assistant

I decided to update my IOT network, by updating all of my Docker containers.  In doing so, I encountered an unusual problem with connecting Node Red to my Home-Assistant container.  This was from several containers.  Normally, I would be using the simple username password authentication, but now that authentication mechanism is not working at all.  Interestingly enough, part of the problem shows up with the Node Red extension that connects to HA via websockets.  I can no longer set the Home Assistant server or any of the authentication mechanisms associated with it.  In fact, it now shows up as a simple text box to enter the server's name.  But that does no good because I cannot specify what IP, port, or authentication mechanism that I want to use.  I am not sure of how to fix this issue.

Update (2020-10-08): I put the Node Red container on a Raspberry Pi, completely away from the Home -Assistant container and I was able to get Node Red to connect.  Now I have to figure out what has happened to my Node Red container on the HA-IOT Server.