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.
