Multiple z-wave bindings

Add-ons Bindings
15

Hi Chris

Not necessarily forwarding the actual stick - forwarding all the events would be enough. But I would like to avoid having to define all the devices and command classes as items etc.

Item-less devices would end up in the log as:

NODE 15: No item bound for event, endpoint = 0, command class = SWITCH_BINARY, value = 0

That is enough information to reflect what happened in the other OH - but it would raise a couple of obstacles:

  1. How to transfer the information to the other OH.
  2. How to receive the information in the other OH, to be able to map it to items and valid states.
  3. How to transfer commands in the other direction.

My guess is that I will have to at least create the items - but some kind of a single generic rule to forward every change for every device would be very nice. I want to avoid having to create hundreds of rules for each and every possible combination of device, command and value.

Ben: Sorry for hijacking your thread - let me know if I should create a new one.

16

This is the same thing - the binding can’t handle more than one stick. The only way to do this is to configure a separate instance of OH and then use something like MQTT to communicate between the two.

So this should be acheivable using the method above. Define all the items, configure all the command classes (which is part of the item definitions) and then use MQTT to forward every item update to the second instance of OH. I’m not an expert on MQTT, but there are many threads here on how to configure it, and people will help with this I’m sure…

17

Hi Chris

There would only be one ZWave binding in the first OH. All devices on the second OH (i.e those from the other region) would be MQTT items in the first OH.

I know what you describe in the second paragraph is perfectly achievable - but that is exactly the double work I’m trying to avoid.

MQTT event bus binding:

“In addition to configuring MQTT publish/subscribe options for specific openHAB items, you can also define a generic configuration in the openhab.cfg file which will act on ALL status updates or commands on the openHAB event bus.”

That looks promising, but:

“The variable ${item} will be replaced during publishing with the item name for which the state was received.”

That indicates that it only acts on items. I want it to act on everything, no matter if there’s an item or not (to avoid having to create all the items and command classes in the second OH too).

So I guess I’m narrowed down to a single question:

Can the MQTT event bus binding, or any other binding in one way or another, catch and forward the event below:

“NODE 15: No item bound for event, endpoint = 0, command class = SWITCH_BINARY, value = 0”

Regards
/P

PS. I found this thread about the same kind of solution that I am looking for: https://forum.z-wave.me/viewtopic.php?f=3419&t=22636&start=20

“I need this to be implemented in the most generic way (i.e. no need to re-configure anything when I add/remove z-wave devices). I don’t want to maintain any mapping-files.”

18

I don’t think there’s anything that will do what you want, but I might be wrong. Certainly, the ZWave binding won’t do this. I suspect that using MQTT is going to be your best bet, but as I don’t use it myself, I can’t comment - as I said earlier though, there are a lot of people using it so I’m sure if you post what you’re up to, someone should be able to point you in the right direction.

Good luck :slight_smile:

1 Like
19

Hi Chris (or anybody else that knows)

Can I run two instances of OH on the same machine? Then I could let them use one COM port each, for each ZWave dongle.

/P

20

I would guess this is possible with some messing around with folders etc to ensure there is no clash with config files, logfiles, IP ports etc. Another option which might make it easier is to run in a container.

1 Like
21

Hi Chris

Just FYI: Running multiple instances of OpenHAB using ZWave controllers on different COM ports was no problem at all. Everything is contained with in each OpenHAB directory - so there’s no need to mess around with any folders or files.

I haven’t been able to test the MQTT forwarding yet though - if there’s a way to event bus forward all ZWave events, or if I need to create duplicate item declarations - one in each OpenHAB. The reason is that I only have one single US ZWave device - and I can’t get that one included (it seems it is not in the ZWave database). Silly showstopper. :frowning:

I have a shopping cart resting on Amazon with a bunch of other US ZWave devices in it - but I won’t pull the trigger until I get this to work.

But I’m so very fortunate that you are already in the thread where I posted that problem, which makes me very confident that it will get solved sooner or later. :slight_smile: https://github.com/openhab/openhab/issues/4274

Regards
/P

22

Hi guys!

I know that is too hackish and that Chris is not going to like it, but I have recompiled the ZWave binding several times to use different ZWave networks in the same openHAB instance. I have also modified HABmin so that you are able to control the ZWave networks at the same time. Here you have the different .jars and a installation script:

Hope you find it useful and if you need any help, just ask! :wink:

Best regards,

Aitor

1 Like
23

Hey Aitor!

I’d be happy to try that out. Even if I get things to work the way I want with two OpenHAB instances, I would of course rather only have one.

However - I have a Fibaro FGMS-001 type 801 device - which would require a newer ZWave binding jar than the one you have patched. See https://github.com/openhab/openhab/issues/4274

Any chance you could download the latest 1.9.0 snapshot and update your GitHub site?

I’m running on Windows (only because it is a greater challenge), so I can’t use your install script - but I read it, and there’s nothing in it that I can’t reproduce on Windows.

Regards
/P

24

I don’t mind, but just to note that it’s not supported, so if there are any issues, I can’t support them - sorry. Also, you will need to support any updates to the database if needed…

25

you will need to support any updates to the database if needed…

I guess he just noted… :slight_smile:

26

Chris: Everything worked fine, but (as I thought) I had to add the items in both instances. The events have to end up on the event bus for the MQTT event bus binding to pick them up, and they won’t end up on the event bus unless there is an associated item.

The config, in case anyone is interested:

OH1 openhab.cfg:

mqtt:Mosquitto.url=tcp://localhost:1883
mqtt:Mosquitto.clientId=OpenHAB
mqtt:Mosquitto.user=User
mqtt:Mosquitto.pwd=Password
mqtt-eventbus:broker=Mosquitto
mqtt-eventbus:commandPublishTopic=OpenHAB/${item}/command
mqtt-eventbus:stateSubscribeTopic=OpenHAB2/${item}/state

OH1 items (no binding config needed - they will automatically pick up the bus events):

Number eye_lux "Lux: [%.2f Lux]"
Number eye_temp "Temp: [%.1f °C]"
Contact eye_motion "Motion: [%s]"
Number eye_batt "Battery: [%d %%]"
Switch eye_basic "Basic: [%s]"
Contact eye_alarm "Alarm: [%s]"

OH2 openhab.cfg:

mqtt:Mosquitto.url=tcp://localhost:1883
mqtt:Mosquitto.clientId=OpenHAB2
mqtt:Mosquitto.user=User
mqtt:Mosquitto.pwd=Password
mqtt-eventbus:broker=Mosquitto
mqtt-eventbus:commandSubscribeTopic=OpenHAB/${item}/command
mqtt-eventbus:statePublishTopic=OpenHAB2/${item}/state

OH2 items:

Number eye_lux "Lux: [%.2f Lux]" {zwave="6:command=sensor_multilevel,sensor_type=3"}
Number eye_temp "Temp: [%.1f °C]" {zwave="6:command=sensor_multilevel,sensor_type=1"}
Contact eye_motion "Motion: [%s]" {zwave="6:command=sensor_binary"}
Number eye_batt "Battery: [%d %%]" {zwave="6:command=battery"}
Switch eye_basic "Basic: [%s]" {zwave="6:command=basic"}
Contact eye_alarm "Alarm: [%s]" {zwave="6:command=alarm"}
27

Hmmm - not exactly ideal I guess…

Your other option as above is to look at OH2 which should (in theory) support multiple sticks out of the box - although as stated above, it probably needs a little bit of thought to avoid the xml files overwriting each other, but this is relatively manageable. I know at least one person has tried this, so it does broadly work.

28

It’s good enough. It’s a one time configuration (or… at least a one time per each device configuration…)

I guess at some point I will move over to OH2. But I’m not there quite yet.

29

Yeah, sure Chris, sorry for not making it more clear in my post:

WARNING: This jar files are not officially supported by Chris Jackson, so don’t open any issue ticket in the official ZWave repository if you are having problems with them!

1 Like
30

Hi @Pal !

It’s great to see that there is some interest in the project! Unfortunately, until the end of the next week I’m away from my development PC, so for now I can’t recompile the binding to add the new version of the Fibaro motion sensor. Anyway, how many ZWave networks are you planning to use? Is the new Fibaro device going to be present in all the ZWave networks or just in one of them? If it’s the second case, you can use the official ZWave binding as the, let’s call it, “ZWave1” binding, because my script doesn’t install the first ZWave binding.

Oh, don’t worry if you are using Windows, you will only need to follow this steps:

  • Stop openHAB
  • Download, from the zwave folder of the github repository, the zwave2, zwave3,… bindings that you are interested in. Remember that you need to install the zwave (zwave1) binding using the official version provided by Chris. Place all the jar files in the openhab addons folder. You don’t need to replace the official zwave binding.
  • If you are going to use 2 zwave networks, download, from the habmin folder of the github repository, the habmin_zwave2 .jar file. For 3 zwave networks, download habmin_zwave3 .jar file, and so on :wink: Remove the habmin jar file from the addons folder and place the habmin_zwaveX file that you have downloaded.
  • Download the habmin.zip file from the habmin folder of the github repository and unzip it in the webapps folder of your openhab installation directory.
  • Edit the openhab.cfg to add the zwave2:port, zwave3:port,… parameters.
  • Start openHAB
  • Enjoy! :wink:

Give it a try and don’t hesitate to ask any question if you need help!

Best regards,

Aitor

31

Ah, true. I only have two ZWave networks - one for EU devices and one for US devices. The Fibaro Eye is US, so I just need to run the official jar for the US network, and one of your jars for the EU network.

I’ll give it a try and let you know.

32

[quote=“chris, post:27, topic:10716, full:true”]
Your other option as above is to look at OH2 which should (in theory) support multiple sticks out of the box - although as stated above, it probably needs a little bit of thought to avoid the xml files overwriting each other, but this is relatively manageable. I know at least one person has tried this, so it does broadly work.[/quote]

Since my 2 buildings are to far from eachother, my zwave network isn’t that ideal. Some (far) devices sometimes work, sometimes they don’t. Not very reliable for security sensors. :blush:

So I guess I’ll order myself an second Z-wave Stick Gen5, and some USB over UTP extenders. And since I’m already running OH2, and noticed a second serial in items file for the zwave serial controller, it should be a good starting point, no?

Can you tell me if I need to pay attention to special things (hardware, configs…)?
Or should it be pretty straight forward?

Before I start buying things… :wink:

33

Okay, took the risk, and won!!!

I’ve got now following setup:

  • Openhab 2
  • 2x Aeon Labs USB Z-Stick GEN5

One Z-stick is connected directly to my server. And one Z-stick via an “Aten interfaceadapter: USB 2.0 Extender”. This way, my usb stick is now connected over an ethernet cable of about 40m.
(I took me some head worries to exclude/include all nodes from one stick to another. But finally, everything is in. And I’m very happy to say that at first sight, they all work…)

@chris
Another prove why to use OH2 … :wink:

34

Just a word of caution. At the moment, the binding doesn’t save the node files in a network specific way. So, if you have node 2 on both sticks, then there will be a problem. It’s probably ok in that the binding will check the home id is consistent when restarting, and it should sort itself out, but just letting you know in case you see anything strange happening! :slight_smile: .

I will change the way this works (it’s actually already done in one of my development branches) and there’s an open issue on it.

1 Like