Just thinking about planning out my next environment. I was thinking about utilizing 4 raspberry pi’s. (2) openhab servers that are mirrored (utilizing some software to mirror the 2 live. maybe a riak cluster but that would mirror everything) and (2) redundant reverse proxys (utilizing keepalived for the virtual ip). The only thing that I can’t figure out is how to share the z-stick between the 2 openhab servers. Maybe I’m going about this wrong too.
Any ideas?
Or maybe I could just have 3 raspberry pi’s. (2) have openhab. Then I could just use keepalived on both to give me a virtual ip. rsync could mirror the files for me.
and then on the 3rd pi, use virtualhere to share the z-stick to the first 2 pi’s. This wouldn’t give me redundancy on the pi that has the z-stick however.
Search and browse around the forum. This topic comes up relatively frequently.
The tl;dr is there is no satisfactory way to have redundancy for your zwave network. So the zwave stick will always be a single point of failure.
That is an approach that I believe has been successfully done. I don’t think they used virtualshare but some Linux tool to convert a serial device into a sharable TCP socket so a machine can access the device over the network.
But, here is a bit of a philosophical question about all of this. What problem will running redundant OH instances actually solve? If one goes down (in my experience an extreme rarity), and it goes down for some reason that doesn’t have anything to do with the zwave network (since that is your single point of failure regardless, and this is an even rarer event), does redundancy actually buy you more reliability and if so, is it enough to make it worth the extra effort? Would it be cheaper in the long run to get more reliable hardware to run it on? Would it be less work to automate the rebuilding of the server than keep the data in sync?
To me it seems like automating the deployment of OH in such a way that you can just bounce the server and auto-rebuild it would provide the same level of ability to recover from a failure yet be much simpler to setup and configure. Particularly if you take advantage of tools like Ansible, Chef, Puppet, Docker, etc.
The only failure that I can envision where having a hot redundant instance of OH would actually help is in the case where the SD card on your RasPi became corrupted. And there are best practices for avoiding that are not too hard to set up.
Thanks for your reply.
To start, I’ll answer the philosophical question. The short answer? I just want to over-engineer it. The long answer? I’ve migrated over lately from VMWare/Windows to AWS/CentOS. I’m just coming to the realization that these little Raspberry pi’s can do a lot more than I thought. Just a few minutes ago, I walked over to MicroCenter (across the street) and bought (2) Raspberry pi 3’s for $29/each. I’m now itching to get these 2 up and play around with a few applications and start learning my way around the OS.
In regards to the path of automation, I’ve been using Ansible and Salt at work lately (more-so Salt). That is a possibility to just setup an admin-type system to quickly configure a new raspberry on the spot. But I really just enjoy automating things. The idea in my head is to have no outage in the event one of these fails (hardware or software). I thinking I could get a new one up in a matter of minutes by just setting up the OS and adding it to the cluster. I still plan on backups, but for the running system, I would like redundancy. TBH… What I’m describing are 2 esxi servers running vm’s ontop of HA and mirrored storage… lol. I’m still searching for an application that can perform live mirroring and manage a VIP at the same time.
I’ve been messing with OpenHAB 1.8 on my Synology NAS for a little while and I would rather not run it with all of the other services running.
The end result after testing will be mounted in a small server rack and put to work for home automation hopefully using OpenHAB!!
They are indeed quite powerful and capable. They are also relatively brittle in my experience so perhaps over engineering a setup like that could be handy. Like RAID for Pis instead of disks (RARP?).
However, consider that using the Pis as a remotely deployed little server/sensor platform is also a perfect use of these little guys. When you need something more powerful than an Arduino and/or easier to setup and program than an Arduino a Pi makes a great choice.
In regards to the over-engineering aspect, I tend to want to spend my time focused on the actual home automation part. Of course, I have precious little time to spend on it at all these days.
See this thread for more discussion on how people are making the Pis more reliable and the many recommendations to go with a little better hardware.
I like that… “RARP”.
That is what I have in mind though. I could easily do this with RIAK, but I’m not sure how i/o intensive the software is with a few (maybe 3-5) raspberry pi 3’s. With RIAK, the more “nodes” you add, the less intensive the i/o’s, but I’m not trying to create a huge cluster here. I might just play around with rsync and a cron job.
One question that I guess I need to answer first is where the device “states” are stored in OpenHAB. For example, do I need to have a live backup of whether a switch is on or not? If I don’t really need this information, I assume I only need to have a somewhat “live” copy of my configurations directory so that in an event of the current raspberry pi failing, the auxiliary would have enough information to keep everything up. I guess I need to figure out what directories I need to backup and how often before starting down a specific “redundant” path.
for getting all current states within a file, you would have to use mapdb with persistence for *, everyChange,restoreOnStartup.
So all states are stored and if openHAB or the underlying hardware fails, you only need to restart openHAB and it will get the last states automatically from mapdb.
The states for Items are stored in memory. If you configure persistence the states for the configured Items will also be saved to the configured database.
The problem is persistence is offline. OH will read in the most recent state when it starts or it reloads the Items files (assuming you have restoreOnStartup configured). But OH does not use persistence as its primary working memory for Item states. So if you have one OH instance up and running and it goes down the second OH will not have the current state of the Items in its memory without some trigger to cause it to load the current Item states into memory. There is a further complication in that if both OH instances are writing to the same persistence DBs they will be overwriting each other.
Now there is a way to keep the two OH instance’s Item states in sync with each other using MQTT in EventBus mode. This will cause one OH to subscribe to all the events that occur on the other. However, if you name your Items the same in both instances of OH you will end up in an infinite loop as an update in one gets published, transmitted to the second, updates an Item, gets transmitted back to the first, and so on.
Personally I think it would be much simpler to setup and configure and be just as reliable if you relax your “hot spare” requirement. Instead have only one OH instance running. Keep the configs and DBs in a location that all potential OH instances can get to (network share or what have you, see below for files to sync). To restore state use @Udo_Hartmann’s suggestion of MapDB which keeps only the most recent state. But if you use an embedded DB like rrd4j or an external db like MySQL that would work too.
Thus, if all potential machines that will run OH have its config and DBs kept in sync (i.e. they point at the same files) you can create a minder script that watches the running instance of OH and if it fails try to kill it (may not be possible), and start a new instance on a separate machine. Because the configs and DBs are in sync the new one will pick back up right where the old one left off with only a minor hick-up in your operations.
Folders you need to keep in sync (assumes an apt-get install and OH 1):
- /etc/openhab Configs, rules, items, scripts, sitemap, etc
- /usr/share/openhab/addons Installed bindings (optional)
- /usr/share/openhab/webapps Customized icons and webviews, habmin
- /var/lib/openhab/persistence DB files for embedded databases like rrd4j and MapDB
- /var/lib/zwave Node.xml files, (optional, will be automatically regenerated)