Dueling Openhabs (feeding from a 2nd with zwave)

Setup, Configuration and Use Scripts & Rules
, ,
#1

I’ve just starting on this with zwave (reference: Multiple instances of Openhab) . I will have a main Openhab instance (its a vm, so I can’t physically connect a usb zwave stick to it), and I will have a openhabian based instance on a raspberry pi.

I know the mqtt transport (as used in the openhab.cfg). Where you define it as mqtt:mosquitto.url=tcp://localhost:1883

But how does this differ from mqtt-eventbus: and do I have to install something to get access to mqtt-eventbus?

So given at the moment my zwave network will consist of a controller and a multi sensor, I will be wanting to push temp readings from the multisensor to the main OH instance.

So my raspberry pi would have this config:

mqtt:mosquitto.url=tcp://master:1883
mqtt:mosquitto.clientId=slave1
mqtt:mosquitto.retain=true
mqtt-eventbus:broker=mosquitto
mqtt-eventbus:statePublishTopic=/slave1/out/${item}/state
mqtt-eventbus:commandSubscribeTopic=/slave1/in/${item}/command
And I assume on the raspberry Pi a temperature zwave item would look like:
Number zwave_temperature “Multisensor 1 Temperature [%.1f °C]” (g_temperature) {zwave binding temperature sensor}
But how do I get the zwave sensor on the slave (raspberry pi) to then push that temp value received from the zwave device to the mqtt bus that the master can read?

#2

The MQTT Binding bundle includes 3 main components:

  1. The MQTT Client, which allows you to configure items that subscribe or publish to MQTT some telegrams (OH2 associated file: mqtt.cfg)
  2. The MQTT Transport, which is essentially the fundamental support for the MQTT messaging protocol (no config file)
  3. The MQTT Event bus, which links the entire openHAB (2) Event Bus to the MQTT Broker (OH2 associated file: mqtt-eventbus.cfg)

There are also the MQTT Persistence & MQTT action Add-Ons but we don’t need them for your goal.

To get access to the mqtt-eventbus, you need to configure the OPENHAB_CONF/services/mqtt-eventbus.cfg file.
Check https://github.com/openhab/openhab1-addons/wiki/MQTT-Binding#event-bus-binding-configuration (watch out… this is from the openHAB 1 world)
and one example here:
[OH2] Control ESP8266 Relay using MQTT Eventbus

I see that you are using config references to openHAB 1 (openhab.cfg file). This will work but if you are using OH2, you need to use the files mentioned above.

One way would be to set up the MQTT <-> OH Event Bus connection on the slave rPi (with Z-Wave) and use a new item that is MQTT bound on the master rPi that subscribes to the status updates as they are published by the slave rPi via MQTT-Event Bus.

Or you could deploy in both rPis the MQTT-Event Bus and mirror the settings (out from slave = in to master, etc). I haven’t tried this setup yet, so I don’t know how it works in detail.

#3

Really? I think a number of people are using VMs and I thought it’s possible to map ports so that a VM can access them? I would try and solve the problem so that you only have a single system if possible.

#4

It’s hyper-v, not vmware/virtualbox.

I’ve have to get a network to usb program, and I haven;t found a good one yet.

#5

Thanks for that. So if I’ve got this right.

I’ll be doing the event bus to mqtt components (from your tutorial) - subsystems 1 and 2) on the raspberry pi oh2 instance with the zwave stick?

And on the main oh1 instance it’s just a regular mqtt driven item.

Is that correct?

#6

Would it make sense to have openhab slave binding?

I would like to have main openhab server in basement and then few raspberry pi’s acting as sensor (Bluetooh LE / Zwave / rfxcom) as well as wall mounted panels. I’d like to have openhab installed also to these raspberry pi’s and these “slave” openhab would be discovered by the main one and man openhab would receive events would able to send commands to slave ones.

Just an idea tough…

#7

How does that work, or are you proposing a new openhab architecture to the devs? Ie not something that is currently posssible?

#8

Yes actually proposing something new :slight_smile:

At least I don’t know that this exists.

#9

So I think I’ve got it.

The oh2 instance with the zwave controller seems to be pushing everything to mqtt.

The oh1 instance (my full system) I now have a 2nd broker pointing at the oh2 machine. I’'ve got a window open with subscribe to everything and can see traffic.

And I’ve created an item for the zwave temperature sensor…just waiting for the temperture to change to see it the oh1 ui item updates.

Would be convenient to be able to force an update somehow

#10

Correct. Note: My tutorial is using MQTT Event Bus, but from only 1 openHAB installation simply to push telegrams to MQTT, so your configs may need some changes. For example: You would apply a similar setup like mine in your slave OH2 with your items, linked to your Z-wave thing(s) channel(s).

Then, the status updates from those slave items would be published to MQTT and in the master OH1 would need to configure items that subscribe to the relevant topics.

Note: I agree with Chris: Try to find a solution to use the USB Z-Wave stick in your VM… it’s easier (change of hypervisor is not an option?). On the other hand, if you make this master-slave setup working, you will learn a lot about openHAB :slight_smile: Also: Why not openHAB 2 for the master also? it’s the future! :sunglasses:

#11

In my opinion: No.
You can achieve this kind of results using MQTT since it gives you the flexibility to exchange information from multiple systems which use several setups (bindings, other technologies, etc).

Almost everything can publish and subscribe to a MQTT Broker, so that’s you “integration” solution for such use cases.

#12

That’s correct (you mean Broker config in mqtt.cfg).

It looks like you are running the Mosquitto MQTT Broker locally on the OH2 slave system with the Z-Wave setup. I would advise to use the VM for the Broker… it should be better than the rPi. The disadvantage would be that you would generate some extra network traffic from OH2 to the remote Mosquitto (but the telegrams are very light).

You could manually publish a telegram to the MQTT Mosquitto broker (from any client) to see if the master OH1 item picks up the update

mosquitto_pub -u openhab -P <some_passwd> -t <topic> -m <message>
#13

Ok, So I thought about it, and since you said the it was sending everything from the oh2 instance to mqtt that’s why I went for a local one.

I could change it to point to the master (I haven’t upgraded yet as it’s “production” and was seeing how things went, the oh2 instance was my first foray into oh2).

So on the oh1 instance (master) I’ve subscribed to everything and can see the events coming through.

In my oh1 instance config I have a mosquitto broker (for regular mqtt traffic) and a openhabian broker for incoming messages from the oh2 instance.

I can manually force a publish from oh2 on topic:
mosquitto_pub -t openhab/out/zwave_device_8862ff02_node6_alarm_general -m ON

And see it appear in the oh1 machine subscribed window:
openhab/out/zwave_device_8862ff02_node6_alarm_general ON

But for some reason I’m not getting anything into my items, and can’t see anything in the oh1 logs (neither the mqtt.log, events.log openhab.log)
Here’s the item:
Switch zwave_multisensor1_alarm "Zwave alarm" {mqtt="<[openhabian:openhab/out/zwave_device_8862ff02_node6_alarm_general:state:default]"}

…and I’ve just found it.
the item definition was a bit wrong, Should have been:
openhab/out/zwave_device_8862ff02_node6_sensor_temperature/state

I was missing the /state
And the openhab.cfg mqtt:openhabian broker defintion I had the .url keyword missing.

Wow, this is cool stuff now that it does seem to be doing its job…just waiting for the temp to update…and there it goes, that’s funky.

I kinda like this model.

No, changing the hypervisor isn’t an option now. I’m running 5 machines on hyper-v. 1 x windows 10, 3 x ubuntu, 1x windows 2008, Full time, with a few others that can be started as needed.

1 Like
Z wave - can openhab control a remote (Rasp Pi) z wave stick
#14

Yes, it is :slight_smile:

openHAB with MQTT is one of the coolest combos out there :sunglasses:

It’s great when it is configured correctly and it works!

1 Like
#15

Yes,

I was thinking not to have one more thing that I need to configure, install and learn.

But any way, it seems that mqtt is currently the only way to make this happen.

#16

Regarding usb to network programs, you might want to try https://www.virtualhere.com/

the basic version is completely free, and both the server and client support windows and linux, and you can mix and match.

I’m using it to pass my USB UPS from a xenserver (centOS) hypervisor to a windows VM, works great