Hello Openhab Users
I just wonder if it is possible to run openhabian on pi zero and Openhab on Windows 10 simultaneously, or only on one in case other is down for some reasons.
My thought is if I want to control heating and use mainly rp0 but if it shut down or broke. We never know…
It’s there a possibility to start emergency control of my heating from other device for example Openhab loaded with all settings on Windows 10? Thanks
I do recommend that you upgrade to something a bit bigger. The pizero will really struggle.
Yes you can
They can communicate to each other using the MQTT event bus (Search the forum)
You could but that’s no good approach and full of pitfalls.
For critical applications like HVAC is, get dedicated HW including a spare box and a recovery concept.
Some more info here.
1 Like
I’ll be somewhat contrarian here. Largely because I’m about to have a somewhat similar setup. I backed the HestiaPi project as a replacement for my Nest Thermostat. This is a custom PCB with an small LCD running on an RPi 0W and it’s running openHAB to control the HVAC. And I will be retaining my main openHAB instance as well and will integrate with it.
If this is all that your RPi 0 is doing with openHAB, about the only issue I see is relatively long startup times. But since it will have almost nothing else installed on it including addons and such it should run OK. A RPi 3 would be better but the 0 should do the job.
Despite what I said, instead of trying to create some sort of fail over situation where you somehow have your HVAC physically wired to your RPi0 and a Windows machine at the same time, which is what would be required here in order to have a fail over, you should focus on this instead of trying to set up a fail over situation.
There are tons of ways you can know. You can set up watchdogs on the RPi0 itself that will cause it to reboot if it detects a failure. You can set up your Windows OH instance to monitor the RPi0 using the Network binding or SNMP binding and generate an alert when it goes offline. If you use MQTT, you can use the LWT feature to detect when the RPi0 goes offline.
In my opinion, your best approach is to make whatever directly controls your HVAC as autonomously as possible. Your “main” OH only influences the main controller through settings (e.g. target temp, turn on the heat, etc.). But the RPi0, in this case, is perfectly happy being controlled locally (through some UI presumably) and it’s content to run along by itself, even if the network goes down, based on it’s given settings.
Then you can set up OH or something else to monitor the RPi0 for failures. Then you should have spare SD cards, backups, etc. to quickly get the RPi0 back up quickly.
Why don’t you run openhab in docker and use a docker swarm? That way it’ll automatically switch if there is a failure and you can use the swarm to run other software as well (e.g. HABApp, Graphana, etc.).
Also as the other prople suggested, get some simple hardware which provides a network interface for your wiring. Then control the simple hardware from openhab.
Most OH users are tied to specific hardware. The benefits of Swarm or Kubernetes or OpenShift are reduced when you either have to get another static machine to expose the physical devices over the network so your containers are not pinned to a specific piece of hardware (in which case what’s the point?).
And then you’ve just moved the single point of failure to the computer connected to the device, you’ve not eliminated it.
That’s correct but an USB/IP server on a Raspberry which creates no logging after startup is less likely to fail than PI running openhab.
Also if your wiring exension fails you only loose that part of your automation, the rest still works fine.
My view:
running two instances works well. I have two separate RPi where the same code runs on.
Basically concept of development & production instances. Whenever I need to try something, I do it on the non-prod, once fine, it will be moved to the production instance.
How did I achieve this:
I did not find any issues when OH is consuming MQTT, Homematic etc. So you can connect multiple instances.
What makes it a bit more difficult when you do somthing with rules (e.g. turn lights on, ask for a status and act on this etc.) This will completely drive you nuts because you never know which instance is doing what when they are both active.
Simple solution to that:
I have a “master switch” which can be turned on via the UI (always off after restart).
All rules check for master switch status, if off - nothing happens.
This is how I control which instance is active and which is only listening (status updates of switches, probes etc).
And then you’ve just moved the single point of failure to the computer connected to the device, you’ve not eliminated it.
That is actually a good point. I only have one Homematic controller, one MQTT-server, one mySensors-Gateway. If this goes down, major outage.
Here is my thoughts on how to take this a step further.
When using Scripted Automation you can enable and disable Rules from other Rules. With the MQTT 2 binding, you can have openHAB configured with a LWT message (maybe MQTT 1 too, I don’t remember).
So you could disable all the rules on your hot backup except for one that listens for the LWT message from your other OH instance. You could also do some other things like Network binding to monitor the broker and such as well. If the other instance is discovered to be offline, a Rule can re-enable all the disabled Rules. You could go a bit further and publish a retained message to a topic to indicate that the fail over instance has taken control. Then when the offline instance comes back online, it sees that it has been demoted to a hot backup and disables all it’s Rules except for the one that watches for the main one going offline.
Then you don’t need to add the same if condition to all of your Rules which will become more of a pain as we move towards most users installing and using prewritten Rules rather than needing to hand code everything.
1 Like
Thats actually a pretty smart idea and think quite easy to do. Thanks a lot for this!
I have a “global.rules” set which is only executed during startup, it is currently setting the “master switch” to off but based on your idea should check if the other system is up and then decide condition based.
Then I only need to add the monitoring rule to be executed on the inactive instance frequently and switch over once the other is down.
Major “problem”: I need a 3rd instance then, cause I still would need a development box to try new stuff
I don’t see that as a major problem. It’s just more of the same. The monitoring Rule just needs to check for two topics or two instances of OH instead of one.
I would add a little timer or something on start up so things have a chance to settle before performing any processing because the system is busy and sometimes acts a little funny and you would want this to work… every time
just to add to what I’m saying for instance, during start up rules, I’ve learned to set item values to simple stuff that doesn’t require any processing
NumberItem = 0 or 1
SwitchItem = ON or OFF
I have solved this problem in HABApp with read only configuration switches.
It’s then possible to run it in read only mode which means no changes will happen on the openhab/mqtt instance. Thus I just fire up any machine I want an test my created rules. 