Marketplace MQTT Event Bus

Tutorials & Examples Solutions
81

Doesn’t help, the same error :worried:

82

Make sure that “mqtt:broker:mosquitto” matches the Thing ID for your MQTT Broker Thing. If that doesn’t work please open a new thread.

83

Hm… two restarts and now it is working without errors again… :roll_eyes:
Strange. I don’t understand what was happening.

84

Hi!

I have one openhab installation running in my garage (which is located about 50m from my house) and one installation at home. I have connected the garage and house using a wireless link (Ubiquiti nanostations). This is perfect for me, I can now interconnect the two sites using mqtt. I did this previously as well but with the old mqtt-binding and without the eventbus. This is so much simpler and cleaner, great tutorial as well!

I got this up and running without any major problems, did have to restart a couple of time though.

Regards, S

85

@rlkoshak this tutorial is alot better now with the mqtt installation.
One question though - Whats required on the remote (or should I say clients) regarding mqtt. I dont assume there is a need of more than one broker. So is it just the binding on the remote?

86

My intent was to explain that with:

There only needs to be one MQTT broker installed. All openHAB instances must be able to see the machine and MQTT broker port over the network.

Under the MQTT Broker section.

And then in each later section at the end I say:

Repeat these steps on all openHAB instances that will participate with the Event Bus.

Or something like that.

I welcome any suggestions for how I can make that more clear or more apparent.

But the tl;dr is you only do the MQTT Broker installation once. All other steps are done on all instances of OH that participate in the event bus. That means installing and configuring the binding (i.e. how OH connects to the broker), creating the Groups and copying the Rules. The only difference is the client ID you use and the topics that are published to and subscribed from on each OH instance.

87

Hmm…Must have missed that part. Thats explains it very well indeed. Sorry if it was me who missed it.

88

Thank you @rlkoshak for another piece of art! The updated version makes it even better to understand.

Now I could finally migrate almost everything off my Rpi to a LXC container. A Rpi is just to slow when your setup grows. Only items which have a soft-, hardware or location restrictions (bluetooth, zwave smart meter) will be left running on my Rpi, everything else is moved (which is a very easy process when you have everything in text files). It just works so much smoother now.

1 Like
89

Eventbus is awesome! I really recommend using it and this excellent example if you want to tie together two or more openhab instances.

I’ve just updated my installation of 2.5.9. I ran into some problem I’ll list them here:
It’s just to make the tutorial even better, since there are lot of things to do, to get this working.

  • It was a bit confusing whether the python parts are need if using DSL, examples in the topic is DSL, but installation instructions show python as well. It’s easy to install both DSL and python getting multiple events as a result.
    For instance items are exemplified with python but not with DSL. Would be good to divide the tutorial with DSL and Python more clearly and will be simpler to follow.
  • The eventbus online DSL rule is not compiling,
 System started or
    Thing mqtt:broker:mosquitto changed to ONLINE

Should probably be

 System started or
    Thing "mqtt:broker:mosquitto" changed to ONLINE
  • The Python config is mentioning
mqtt_eb_in_chan = "mqtt:broker:broker:eventbus"

But that name is not used in any other examples, which is a bit confusing.

In my case I want to be able to both see status of a Switch Item and control it as well from both local and remote. In order to avoid a loop of mqtt messages I changed the DSL a bit:

On the remote instance I changed:

   if(type == "command") sendCommand(itemName, state)
    else postUpdate(itemName, state)
end

to:

   postUpdate(itemName, state)
   end

By doing so It will not trigger a new message on the eventbus if it recives a command on eventbus since it will post it as an update instead.

I recommend running:

mosquitto_sub -v -h your_mqtt_gw_host -t '#'

While setting this up, to double verify that you don’t send multiple messages and if you get a loop.

90

Given that the two implement the same thing I assumed that would be apparent. I guess not so I’ll add a note.

The quotes never used to be required for a Thing trigger, but the examples in the docs use the quotes so I guess so. Frankly, I don’t really use Rules DSL any more and definitely recommend that unless you have a bunch of legacy rules hanging around to Jython or JavaScript.

That’s a typo. I’ll fix it.

By converting the command to an update, any device that is linked to that Item will not activate. For example, let’s say you want to turn on a light on the remote instance from the local instance. You send the command from the local instance but with your change the actual Item on the remote instance will only receive an update and the binding linked to the Item won’t act upon the command and the light will remain OFF. Furthermore, OH will indicate that the light is in fact ON resulting in a missmatch between what OH thinks and what is the actual case.

If all you need is to update sensor values, than yes, you can change the commands to updates. But if you actually want to control a device, you need to process a command as a command on the remote instance.

This is why the tutorial above recommends the device owner (i.e. the instance that is linked to the device itself) only publish updates, never commands. And the remote instance that wants to control the device only publishes command and never updates. Furthermore, the remote instance should use autoupdate=false so the Item doesn’t change state until the remote instance item changes state and reports it back.

When set up this way:

Local sends command to remote

  1. Local sends command
  2. EB publishes command
  3. Remote receives command
  4. Device linked to Item reacts to the command
  5. Remote Item Updates
  6. EB publishes the update
  7. Local receives the update and updates the local Item’s state

Item on Remote is commanded on the remote

  1. Command to Item is received on the remote instance
  2. Device linked to Item reacts to the command
  3. Item is updated either by autoupdate or by the binding to the new state
  4. EB publishes the Item update
  5. Local receives the update and updates the local Item’s state

As you can see, this allows local to command devices on remote, always reflect the state on remote, and never get into a loop.

I like MQTTExplorer which is UI based and lets you see and interact with the messages and topics in an more human friendly way. Other have recommended MQTT.fx.

Finally, I should add that in OH 3 there is an issue open to perhaps implement this as a binding. When/if that happens this whole tutorial will become deprecated.

2 Likes
91

Thanks Rich!
Your explanation and suggestions make sense, thanks for clarifying.

Regards s

92

First of all, thanks for publishing this and all the efforts you put into this solution. I installed and configured the python version of it and can export most openHAB2 item events to a mqtt broker.

But I see UnicodeEncodeError messages for String items with umlauts in the text, i.e. when the weather is mostly cloudy and the status reads “Überwiegend bewölkt!” the corresponding item can not be synced.

Instead I see

2020-11-05 11:34:39.366 [ERROR] [jsr223.jython] - Traceback (most recent call last):
  File "/etc/openhab2/automation/lib/python/core/log.py", line 51, in wrapper
    return fn(*args, **kwargs)
  File "<script>", line 60, in mqtt_eb_pub
UnicodeEncodeError: 'ascii' codec can't encode character u'\xdc' in position 0: ordinal not in range(128)

The line where the error occurrs reads:

msg = str(event.itemCommand if is_cmd else event.itemState)

which I replaced by

msg = "{}".format(event.itemCommand if is_cmd else event.itemState)

It looks somewhat hackish but the error messages stopped and it might work for umlauts now.

93

I’ll look into adding that or something like that to the library. However, there is now a binding that does this in OH 3 (and OH 2.5 I would imagine) which is probably a better way to go when/if you can use it. A binding will always be easier to use and it will be better maintained in the long run.

Edit: I’ve added your “hacnish” change to the code in the repo. It works. Thanks!

94

I’m a bit confused right now! :wink:
Do you mean a “Eventbus”-Binding or a “Umlauts”-Binding? I’d like to prepare for my main openHAB to migrate to OH3, so I’ll need to have some kind of eventbus-logic there to include my other instances (two of which must stay in OH2, because of legacy 1.x bindings)

95

EventBus binding, called Remote openHAB. It links OH instances without the need to use MQTT.

1 Like
96

So how is this implemented, does it use the REST API via HTTP/HTTPS?

97

It uses the REST API to send updates/command between instances and SSE to get the Item events.

98

oh! Thanks! Remote openHAB Binding ist also talking about it - but I seem to can’t find it in my OH3-MS3 test instance or in the official 2.x bindings? Do I miss something obvious? or do I have to download a jar for this?

99

It is a OH3 binding only, included in the official distribution since milestone 2.

1 Like
100

sorry - the update to MS2 was faulty, I was still on MS1. now I see it! thanks!