search

OpenZWave / node-red-contrib-openzwave

OpenZWave nodes for node-red
Other
49 stars 27 forks source link

Configuration Question: Docker/K8S configuration for HA #82

Open fraser73 opened 3 years ago

fraser73 commented 3 years ago

I'm configuring my home Node-Red system to run on two Raspberry Pi4 machines, under K8s/Docker containerisation in a high availability mode. I can come up with a solution for most of the potential issues of preserving state of Node-Red, etc, however I can't come up with a solution for how to enable Z-wave, which relies on locally attached hardware.

I have two potential solutions:

1) Get some sort of Ethernet connected USB port. Pros: It's moved away from the local hardware, so bringing up a new instance of Node-Red should just reset the zwave and carry on. Cons: There's a reliance on a single piece of hardware, which sort of defeats the point of having containerised HA.

2) Use a zwave controller on each Pi Pros: No single point of failure Cons: It seems complicated and will probably rely on some sort of multi controller network, which I have no idea how it would work.

Any suggestions?

OnnoH commented 3 years ago

Not having the latest info on the Z-Wave standard, it's my understanding that you cannot include a device with multiple controllers/hubs. You probably can have multiple controllers in your network (interference?) but they each control a specific set of devices.

In the IoT or Smart Home world you're bound by hardware dependencies. I'm planning a Kubernetes cluster on Raspberry Pies as well using K3OS/K3S, with Z-Wave, Mi-Light, Bluetooth, WiFi, Multi Room Audio and some GPIO projects.

According to my calculations, a node gets a label and some containers running a specific service will only run on the node with that specific label (e.g. living-room-audio). Same applies to the Z-Wave service. It can only run on the Pi with the device attached.

That said, node-red probably won't cut it since this contrib won't allow it to start without a controller. I believe there's an issue for that. So I'm thinking to cut out the device specific flows and run them separately, either with node or python, and let them communicate over MQTT.

Accessing hardware from Docker on a Pi can be done in most cases. I've seen solutions for camera's, bluetooth and GPIO's. Not sure how this will workout in Kubernetes though. Any pointers are greatly appreciated.

fraser73 commented 3 years ago

@OnnoH - You can have multiple different controllers in a z-wave network - I've got a thermostat (Horstman/Secure, SC7 IIRC) which controls a heating z-wave switchy, even without the zwave/pi/node red being up. The controller is included - somehow - into the Pi's USB z-stick network. (I say somehow, because I remember it being a massive pain to setup, but it does work) This means that the PI/node red can control the thermostat and switch.

The big question is - if the second Pi in the cluster has a different USB z-stick, with the same name (/dev/zwave) will this allow a Docker based instance of node red to be brought up on either system, or will it not like the different hardware at the same location?

OnnoH commented 3 years ago

Perhaps I'm misreading your intensions @fraser73 , but I'm sure the Horstman doesn't qualify as a controller in the context I sketched. Hub is probably a better word :-) You can use the Horstman combination to control the thermostat in a standalone wireless fashion. The two devices are associated. Keyfobs may work in a similar way. You can use Fibaro dimmers as scene controllers to set off other devices. But in order to control every device properly you need a hub (z-stick, hc2, razberry etc.)

Without the z-stick the devices can't communicate with the Pi. So you need to include them with the stick. Press the button on the stick, put the device in include-mode (different procedures may apply), wait a few seconds for rapid flashing etc. etc. like you did, also for a couple of other devices I reckon.

And there's the catch: you only can include a device with ONE hub, so having a second one is useless in our scenario.

OnnoH commented 3 years ago

Follow Up with some links as food for thought: https://zwavezone.com/hook-up-multiple-z-wave-controllers/ https://www.vesternet.com/pages/understanding-z-wave-networks-nodes-devices https://zwavezone.com/hook-up-multiple-z-wave-controllers/

OnnoH commented 3 years ago

Slightly different approach: https://www.youtube.com/watch?v=NVhIAz2s--Q&frags=pl%2Cwn Distributed Node Red Still allowing Docker and K8s being part of the equation, but with configurable node restrictions built in.