Extending z-wave with secondary controller - Using Razberry with Aeotec z-stick

Hi @antares2001

I think I need to figure out how to MQTT between openHAB instances as I’m sure it will be really useful in future. I currently use the MQTT binding for connecting openHAB to SmartThings. So hopefully I’m already on my way to figuring it out.

I’ve seen the thread on this forum relating to how to do it so I’ll start there.

@Curtis

I suggest you to use the mqtt-eventbus.conf so that all changes of devices are propagated. That made it most effective and easy for me.

Good luck and have fun :slight_smile:

1 Like

@Curtis

My house is setup with both a Pi3 with Razberry board (running zway) and a Pi3 with z-stick (running OH2 with z-wave and z-way bindings). No need for MQTT command stuff. (I am using MQTT for other things but not this). As long as your large house has a common wi-fi network then you should be able to do what you are doing now. Just put the Razberry zway system near center of one house region and Z-stick system (running OH2 zwave and zway) near center of another house region, each acting as controller for their region (hence bound to those zwave devices in that region). Using OH2 you can bring all those devices into a single Habpanel (for instance). (I do all this. ) Since OH2-z-way binding talks to the IP address of the Razberry box, as long as you have common wi-fi, this should work fine. (I am having a difficult time imagining a house so large that you’d have end-devices more than 4 hops away from their respective controller when laid out by regions). That being said, if your house is truly that large, I don’t know if the z-way binding has been tested with multiple z-way servers all feeding one OH2. @pathec would most likely to know that.

3 Likes

Cheers, I’ll give your solution a whirl too. I’m a bit of a tinkerer so like to try out many possible solutions.

The house is 200 years old, has high ceilings, 20 rooms and an out-house that needs signal too. Not my house though unfortunately, its a friend of mines. We have 3 Netgear Orbi’s in there at the moment which struggle to get Wifi throughout. I think it has as much to do with the build of the property as much as the size.

? interior stone walls

Well yeah but some are COB and some are about 20cm thick. Could be interference with other stuff too. In any event z-wave and Wifi both struggle in that house.

Should go like you may need more than two controllers. If you have already fought and mostly won the wifi challenge in that house, have you considered using mainly wifi devices?

You will probably want to have at least as many controllers as you have wifi app/repeaters and you will want to have a pretty dense mesh network of devices so each individual device has at least two parties paths to it’s controller. This may mean installing repeaters or mains powered devices whose main purpose is to fill out the mesh rather than control something.

And in my experience, the network is more times for creating the mesh horizontally rather than vertically. If you have multiple floors you might need to add some repeaters to connect the floors. I for example, I have three floors , one of which is a basement. My controller is on the top floor and except for a battery powered smoke alarm was the only ZWave device on the floor. Well, the main floor and basement had a full mesh but only the power outlet in the room directly under the controller could see the controller. This other quickly became overwhelmed and the network was unreliable. I added a repeater to the top floor and now everything has two paths to the controller and it works great.

Good luck!

1 Like

Agree with @rlkoshak on this. Solid walls are going to be a problem. Was just having a thread with @trumee who is in India (partially) on this. (Wiring is another issue in India --sidebar - my wife is Indian – I’ve been there many times and know a fair amount about Indian construction and wiring practices. )

Your walls are stone/COB and thick–so you are going to have serious issues with transmission for z-devices.

I think a little systematic science is in order. I would get two or three plug-in z-wave range extenders and probe the environment for reachability. Basically stash a controller in what you think would be central to a zone, and systematically move a relatively portable z-device farther and farther away from it to see if you can maintain contact, inserting the range extenders either line-of-sight through non-stone, or possibly one stone wall from the either the controller or a prior range extender.

Make yourself a map of the real problem, in other words.

1 Like

Good suggestion in using z-way binding for second controller. I have my garage 80m away. Too far for zwave, but i can get wifi there. My original plan was to setup a new openhab instance a propagate stuff with mqtt to the main openhab instance, now if using your suggestion I can do with one openhab instance and 2 zwave controllers!
:+1:

1 Like

Thanks very much everyone I really appreciate your feedback. I certainly have enough food for though now. I’ll try a few options and see what works best.

Hello,

This sounds wonderful!

However, has anyone tried configuring the Z-Way binding in OH2 with two Z-Wave controllers (e.g. two Razberries), each with its own IP address (e.g. one installed in a garage, and another in the main house)?

It that really possible?

Cheers,

Gustavo

Hi Gustavo

Yes it is possible with the use of the MQTT binding which links two openHAB installations together. I was a bit confused at first but I have this working well now. Others on this forum pointed me in the right direction when I was stuck. See here: MQTT in layman’s terms, best practices, use cases?

Personally I would use the Z-Wave binding though as in my experience it works much faster than the Z-Way binding. See my findings here Z-Wave – Can it be reliable? Too many variables? Try something else?

Hope this helps.

1 Like

Thank you Curtis for pointing me your your other posts and for the insights.

Let me just further share here my thoughts and questions - it’s a bit long, but please bear with me (and who knows, someone has a similar scenario, and can share their thoughts/questions).

I’m just now starting to experiment with a razberry and some battery powered z-wave sensors (a Zipato Smoke Detector and a Zipato 4-in-1 Multisonsor, for now - I also have some qubinos around, but I still need to wire them up and test them - I’m planning to do that later this week).

But before moving too deep into configuring devices and sensors, and installing servers and services, I’m first trying to figure out what would be the best Home Automation architecture for a country side property I own, where I have multiple separate units (main house, bungalows, garages, shacks, etc.), all already interconnected with Cat6 ethernet cabling to a central switch/internet router). So at each unit I already have IP/internet connectivity (both cabled and wifi - I’m also configuring separate VLANs for admin, home automation, guests, etc. - but I digress).

Inside each unit I want to have a dedicated sensor/actuator network. Of course IP sensors/actuators are an option (which I will also use wherever possible - mainly based around arduinos), but it would require power connections in a lot of points inside and around each building (e.g. door and windows sensors, etc.), which I want to avoid. So Z-Wave devices seemed like a good option (at least for now I’m not considering adding zigbee, or other solutions - but I like to keep those options open for a later phase).

So, for testing purposes, I have just installed OH2 on a server - this will be the “main” OH2 server, where I will configure the global sitemap where all the items from all the units in the property would be managed, and where all the rules would be configured and run (and where all the other general systems will be connected to, e.g. opensprinkler for the common property gardens, openenergymonitor, etc.). I plan this to be the main automation server for the entire property, where I can have an overall view of all the units (but where I can also have more specific views on each single house unit, if I want).

The question now resides on how should this main OH2 server interact with the devices inside each independent house unit, particularly the non-IP ones (e.g., Z-Wave sensors, actuators, etc. - IP devices are not a problem, since they are directly visible to this main OH2 server through IP - they will all be in a same VLAN/subnet).

Some options I’ve been considering:

  1. at each house unit have a RPi+Razberry, with only Z-Way installed, which will basically only manage the Z-Wave network for that single house unit. The main OH2 server will then use the Z-Way binding to connect to each and all the Z-Way servers in each house unit. No rules or advanced automation of Z-Wave elements will be configured in Z-Way, installed in these RPi+RazBerry servers (that will be done in the main OH2 server). However, this assumes the following:

1.1) OH2 Z-Way binding supports multiple connections to multiple Z-Way servers (each at its own IP address) - does it?

1.2) OH2 Z-Way binding is efficient and stable - from what I’ve been reading around here, that may not be the case (high CPU usage, latency problems, etc…)…

  1. at each house unit have a RPi+Razberry, with OH2 installed. And here I would have the following options:

2.1) also install Z-Way in each RPi+Razberry (this has proved to quite tricky, so far, if using the latest Raspbian Stretch-based openhabian - Z-Way 2.3.7 still has no official support for Raspbian Stretch, though I was able to make it run installing some older libs - but then I failed to make the Z-Wave devices to work… more tests needed…), and again use the OH2 Z-Way binding to locally interconnect Z-Way and OH2 (but then my questions in point 1, above, apply). Assuming Z-Way and OH2 work well together when installed in a same RPi+Razberry, I would then use MQTT to connect OH2 in this RPi-Razberry device to the main OH2 server, where all itens would be mapped.

2.2) instead of using the OH2 Z-Way binding to interconnect OH2 and Z-Way running inside that same RPi+Rzberry, I could try interconnecting them using MQTT (installing the MQTT binding in OH2 and the MQTT app in Z-Way). Once again, I would then use MQTT to connect OH2 in this RPi-Razberry device to the main OH2 server, where all itens would be mapped.

2.3) do not use Z-Way at all, and only install OH2 in each house unit’s RPi+Razberry, using the Z-Wave binding to manage the Z-Wave network. Once again, I would then use MQTT to connect OH2 in this RPi-Razberry device to the main OH2 server, where all itens would be mapped. Although this seems to probably be the simpler and most elegant solution, the problem I anticipate with this approach is that, as far as I could understand, the Z-Wave network configuration is not made persistent by OH2 (in case of server failure or other catastrophic situation), while if using Z-Way, that configuration is made persistent inside the Razberry controller itself - is this correct?

Maybe I should create a new thread on this topic… in addition to all this, I also need to understand which of these architectures (or any additional ones you may suggest) proves to be easier to backup and restore (and even include some redundancy abilities!), in case of fatal failures - as soon as I start building all the property automation on top of theses systems, I need to have robust and efficient backup/restore plans to quickly make the full system go back online.

Anyway, any comments, suggestions, further questions are most welcome.

Cheers,

Gustavo

1 Like

Option 3. Install a RPo with Razberry and use Share Z-wave dongle over IP (USB over IP using ser2net / socat ) guide to make it look like the controller is available on your central OH server. The Zwave binding can connect to multiple controllers. Particularly if you have wired networking between all the units this should be pretty reliable.

The network is always stored on the controller dongle itself whether using Zwave or Z-Way bindings. The network is persisted. This won’t be a problem.

Redundancy is really tricky with Zwave. There can only be one master controller per network and only one service can access a controller at a given time. As a result the Razberry will become a single point of failure.

I strongly recommend looking into Ansible or related system management tools that will let you “program” your RPis and servers configurations so rebuilding, updating, or backing up one or more machines is a matter of running an Ansible playbook.

1.1) I don’t think you can
1.2) In my experience it is not. It is plagued with problems.

Yes I ran into the Stretch issue so use Jessy at the moment. It has been this way for some time and even the recent update has not addressed this. To me it seems they spend more time prettying the GUI rather than making it work better. I only use z-way software to backup z-wave network in case the Razberry fails.

I have gone this route and it works fantastically well. I just backup my Razberry in the z-way expert UI periodically. I disable OH, enable z-way, backup, disable z-way, enable openhab. I update z-wave parameters etc using HABmin as I find the Paper UI can be a bit flaky.

This is on my to-do list as it looks like it will be very useful.

Thank you @rlkoshak, for pointing me to this 3rd option, which seems really interesting and worth a try!

I’ll also have a look at Ansible to see how redundancy could be implemented in a simple/elegant way.

Cheers,

Gustavo

Thank you @Curtis! I’ll definitely do some experiments with options 2.3 and 3.

I’ll share back my results with you here, as soon as I find the time to complete this work.

Cheers,

Gustavo

1 Like

In my experience redundancy and simple/elegant are mutually exclusive. There are lots of threads on running redundant OH installations and I don’t think anyone has come up with a solution that I would find satisfying.

I and others recommend spending your time on a foolproof backup and restore procedure. Because you can’t have more than one OH instance connected to a hardware resource like the Razberry, and no Zwave device can belong to more than one primary controller, your redundancy can never provide automatic failover. You will always have some manual/semiautomated steps to move the controller from the old failed primary OH to the backup. And once you have that then you have to weigh whether that will take as much or more effort than restoring your primary from backup in the first place.

I just happened across this post while researching OpenHAB and thought to add some comments.

  1. I have used a z-way-server as a primary controller with a SmartThings controller for a couple of years with no issues ( I have S1 security working as well ).

  2. Some Z-wave devices do only allow for a single “Lifeline” controller, but most of those still allow you to specify another controller for notifications. There is one thermostat that I recall that only allows for a single Lifeline. There are a few ways to solve limited Lifeline devices.

2a) Point the lifeline at your secondary controller.

2b) Have primary controller provide the notifications to other devices via multi-instance (multi-associations1?) (I am writing this off the top of my head, there is a better/modern term for this). By default the z-way-server supports 16 devices via this manner; I have increased it to 32 with no ill effect.

2c) If you have a z-wave bridge controller ( which is rare ), you can create a virtual device for any device which has limited Lifeline support. That device will then appear as a seperate z-wave node, i.e. it will appear as two different devices.

  1. A secondary controller can be used to “recover” a network if a primary controller is damaged. This involves setting up the controller to become a SUC once the primary controller is gone ( you have to first shift the network from the primary controller which had been acting as a SIS to having a SUC on the network ). A SUC can rekey a network as well ( which I have never found to be of much use ). The Zensys tool makes most of this work doable. The z-way-server’s expert mode has the tools to do this as well.

  2. If you have the Zensys tool you can finish the adoption of the secondary controller into the z-way-server by just sending the correct version reports to the z-way-server (Zensys has a drop down which allows you to send correct z-way version reports). You should know though that there is no reason to do this, the only thing that matters is that you set the network-key on the secondary server. The z-way-server has minimal interactions with a secondary controller. The z-way-server never finishes interviews with the GE Z-wave plus motion switches either, but they still work.

I hope some of the above helps shed a little light on some of the questions asked in prior comments. A lot of the information on multiple controllers is fairly esoteric.

Hi!

I ended up using the mqtt plugin to z-way. It is really easy exposing the zway components to openhab via mqtt. It really fast and responsive. If.you dont have that many components I would recommend that route.

I have this to link my garage with my house. I prefer not to do usb exposed over ethernet, for stability reasons and latency.

Regards S