Hi Rich, The items worked on both instances perfectly using MQTT1x for about 2 years so it wont be the ZWave binding - it’s related to MQTT
07:02:22.759 [WARN ] [verter.ZWaveMultiLevelSwitchConverter] - No conversion in ZWaveMultiLevelSwitchConverter to StringType
07:02:26.127 [WARN ] [verter.ZWaveMultiLevelSwitchConverter] - No conversion in ZWaveMultiLevelSwitchConverter to StringType
Well, that part is pretty clear about being completely to do with zwave.
It’s not very helpful by not telling if it is complaining about inbound or outbound traffic, or what channel it relates to. But MultiLevelSwitch might well be something like a scene controller.
That’s even less direct help, but if we assume that the zwave device has not changed then it’s not likely to be about an inbound message suddenly changing from numeric to string.
It could be about a linked Item being of incorrect type.
Or it could be about trying to send an inappropriate command from your openHAB to a scene controller … which you might have accidentally set up by event bus.
What worked or didn’t work with the MQTT 1.x binding is completely irrelevant. We are not using the MQTT 1. binding here.
And I didn’t say that the problem is the Zwave binding, but that the warning is coming from the Zwave binding. And as rossko57 points out, it’s not a very informative warning so all we can say is what has already been said:
Beyond that 
Fair enough, ive no idea either. I guess ill keep looking when I get some time - thanks Rich/Rossko
You might use a bit of deduction. If you’ve got a timestamped complaint from zwave, suspected to be about some command issued via openHAB Item, all of those are shown in your events.log with timestamps too.
Hi,
I tried to use the Event Bus on openHAB 3.1. I used the openHAB Helper Libraries from CrazyIvan359 (GitHub - CrazyIvan359/openhab-helper-libraries: JSR223-Jython scripts and modules for use with ope) and installed Jython inside Settings → Automation.
The mqtt_pub.py will work without any problems. If I use MQTT.fx I can see that all topics are available. But the mqtt_sub.py will make some problems…
12:43:58.123 [DEBUG] [jsr223.jython.core.rules ] - Added rule 'Reload MQTT Event Bus Subscription'
12:43:58.148 [INFO ] [jsr223.jython.mqtt_eb ] - Successfully created rule Reload MQTT Event Bus Subscription
12:43:58.168 [INFO ] [jsr223.jython.mqtt_eb ] - Using event bus name of remote-openhab
12:43:58.237 [INFO ] [sr223.jython.MQTT Event Bus Publisher] - Using event bus name of remote-openhab
12:43:58.243 [INFO ] [jsr223.jython.mqtt_eb ] - Publishing OFF to <not_important> on mqtt:broker:mosquitto with retained 1
12:43:58.288 [INFO ] [sr223.jython.MQTT Event Bus Publisher] - Using event bus name of remote-openhab
12:43:58.293 [INFO ] [jsr223.jython.mqtt_eb ] - Publishing UNDEF to <not_important> on mqtt:broker:mosquitto with retained 1
12:43:58.390 [WARN ] [jsr223.jython.core.triggers ] - when: "Channel mqtt:broker:broker:eventbus triggered" could not be parsed because Channel 'mqtt:broker:broker:eventbus' does not exist
12:43:58.397 [WARN ] [jsr223.jython.core.rules ] - rule: not creating rule 'MQTT Event Bus Subscription' due to an invalid trigger definition
12:43:58.405 [ERROR] [on.Reload MQTT Event Bus Subscription] - Failed to create rule MQTT Event Bus Subscription
12:43:58.406 [ERROR] [on.Reload MQTT Event Bus Subscription] - Failed to create MQTT Event Bus Subscription!
12:43:58.411 [ERROR] [jsr223.jython.mqtt_eb ] - Failed to create MQTT Event Bus Subscription!
The MQTT Event Bus Subscription is also not listed as script.
While I don’t think that the Python implementation has anything that won’t work on OH 3, it’s completely untested. As it says at the openhab-rules-tools repo, one of the requirements for the Python implementations is OH 2.x, not 2.x+. None of them have been tested on OH 3 and the majority of them are known not to work on OH 3.
That being said, the error is pretty straight forward.
when: “Channel mqtt:broker:broker:eventbus triggered” could not be parsed because Channel ‘mqtt:broker:broker:eventbus’ does not exist
Did you create the subscription event Channel on the Broker Thing? Did you copy that Channel’s ID to mqtt_eb_in_chan in configuration.py?
I have created a MQTT Event Bus solution with HABApp. Possibly this is a solution that many are looking for.
You can find the post here or checkout my GitHub repository.
Two different master/slave solutions with two or more openHAB instances are given as example.
I tried it also by rewriting the above rules with the openHAB Helper Libraries and the Scripted Auotmation. You can find it also on GitHub.
Both approaches have the same problem. If you are using to much items at the same time it will not work. Maybe anyone can fix this.
Let me share the latest findings with you: The solution with the openHAB helper libraries seems to work partially. One problem you have here is the triggering channel of the Thing. With the instance that published, I have no problems. With the instance that subscribes, the triggering channel is spammed. When starting openHAB, first all models are loaded and then everything that belongs to Scripted Automation. The observed effect was that as soon as the MQTT Thing which points to the broker is loaded, the channel for the event bus is triggered. With about 3000 items openHAB is then so busy that my Jython script is no longer loaded and the whole thing does not work accordingly. If I disable this Thing, then restart openHAB and enable this Thing, the Jython script is loaded and ready to work.
But this makes a restart of openHAB more complicated, because you would have to check if the script is loaded and then you are only allowed to enable the Thing for the MQTT broker.
With less data load, I say, it loads the Jython script without problems, of course. Also the subscribing works then without problems. With a high data load it happens that not every time the trigger channel recognizes that a new message was received via the MQTT client, then the Jython script for subscribing is actually executed. This means that individual states or commands can be lost. I would also attribute this to an overload.
To reduce the data load, you could proceed as follows at the receiver:
- id: stateUpdates
channelTypeUID: mqtt:publishTrigger
label: State Updates Subscription
description: ""
configuration:
stateTopic: /messages/states/iBad_Hue_Lampe1_Schalter
separator: "#"
- id: stateUpdates2
channelTypeUID: mqtt:publishTrigger
label: State Updates Subscription
description: null
configuration:
stateTopic: /messages/states/iBad_Hue_Lampe2_Schalter
separator: "#"
You create a trigger channel for each item. Or optionally only for the items for which you also want to subscribe something. What is missing in this example, of course, is that the Jython script assumes only a single trigger channel. You would have to add several individual channels in the configuration and then iterate through them in a loop in the Jython script.
This would be a way to reduce what all may be received. It would be conceivable with several devices that they only have to subscribe to different topics.
What you could also do is work with a black list and a white list. Similar @rlkoshak has done with annotations and puball. I have left this out in my example.
To get more specific again on how subscribing works… The MQTT client receives a message, the trigger channel of the Thing recognizes this or triggers, then the subscribe rule is executed in the Jython script. However, if there is for example this item only on the master but not on the slave, the script can also not change the state of an item or execute a command to an item. This data load should be reduced. Processes would be started unnecessarily, which then hinder the reception of, let’s say, valid messages.
So if we could say that we don’t work with + or # as wildcards, but only with the items that are present on the instance the subscribed, we would have stopped this. The wildcards + and # ultimately also allow messages for which no item can be found.
I don’t know if it’s possible to create a Thing by Rule or the Channels to the Script by Rule, because then you could just do it in such a way that all Items (would be in use in the Jython Script in a different context) are passed through and accordingly a Trigger Channel is added one by one.
By the way, the event bus works fine when I openHAB controls with devices that access openHAB via MQTT. My Pepper robot runs music, lowers shutters or turns on lights. Means state and command work. Just the trigger channels are overloaded because of the wildcards.
You need to use QOS 1 or 2 on both the publishing and subscribing side. Under heavy load MQTT allows messages to simply be dropped on QOS 0. Based on what you’ve described I’m not certain the problem is necessarily OH specific, at least not in total.
It’s probably possible but by the time you go that far the Remote openHAB binding is probably a better choice anyway. There is a ThingRegistry and ThingManager which has similar capabilities as the RuleRegistry and RuleManager which is used to create Rules.
This behavior is also probably heavily dependent on the machine OH is running on and what rules you are using and how you are writing those rules. While I’ve not tested at 3000, I have at around 1000 using JS Scripting in UI rules and I’ve seen none of these problems. The reading and parsing of UI rules is much more light weight than doing so from files so perhaps there is less chance that the loading problem you describe can happen. I’m also running on a relatively hefty VM and not an RPi.
Another thing built into my implementations on purpose is that you have to choose which Items to publish. I filter the events that get published on the publisher side through Group membership. It does not and should not publish everything all the time by default. The user should make a deliberate choice on what Items get published.
First, this is far and away the best OpenHAB-related tutorial I’ve seen. It’s clear. It’s detailed. It shows lots of UI screenshots. Good job. We beginners need more like these.
It does seem to be self-contradictory however, probably as a result of changing circumstances over time. At the top it says:
However there may be use cases where MQTT is preferred, such as integration with a non-openHAB service.
That’s my situation, so I thought I was in the perfect place.
Later however, it says
[I’ve elipsed out some portions of that quote that were specific to that user’s needs.]
As I spent some time going down a blind alley and would like to prevent others from doing so in the future, I respectfully suggest that the first quote be deleted or altered to remove the reference to non-openHAB services.
Again, thank you for the great writing, and for all your work on openHAB.
I see this tutorial needs to be updated for OH 4 so thanks for reminding me that it’s here.
The two statements are not contradictory but perhaps need explanation.
What is missing from both statements is the direction of the integration.
OH → The World
If OH is simply exposing itself to some other service, MQTT and the MQTT Event Bus is a good choice. OH, as the source, gets to dictate what and how the messages get published.
So if you were wanting to use MQTT to integrate OH with Home Assistant, Node Red (if for some reason the plugin doesn’t work for you) or some custom GUI, MQTT and the MQTT Event Bus is a good choice.
Device → OH
However, if one is trying to expose something else to OH, a Generic MQTT Thing is the better choice. The reason is that MQTT Event Bus requires the MQTT topics to fit a very specific structure/hierarchy, a structure that is almost certainly not something that a third party service is going to know and follow. OH needs to adapt to the structure/hierarchy and messages published by the device, not the other way around.
That’s what those two statements are supposed to mean.
Thank you. I actually need bi-directional integration. A few current devices and all future devices will be managed by OH, but about 30 legacy devices are currently managed by another system, so I need these two to talk. Now I know that the Generic MQTT Thing is the right answer for me. Any text that will help guide folks to the right solution for them would be great.
Assuming your legacy system can not/should not adjust to the OH MQTT Event Bus.
The advice above is a rule of thumb, not a hard and fast rule. MQTT can be pretty flexible but some systems and devices sometimes are not flexible at all.
Updated from OH v3.3.0 to OH v4.0.4 and tried to get this new event bus implementation to work, but definitely would use some additional advice.
There used to be two rules (publisher, subscription), but now that I create a new rule that supposedly has both functions, what should be put to “Then” section?
Install the rule template. Make sure you get the 4.0+ template. MQTT Event Bus [4.0.0.0;4.9.9.9]
Configure your MQTT broker with an event channel and the Groups as described in that link.
Create a new rule and choose that as the template. Fill in the properties.
That’s it. The whole point of rule templates is they are installed and configured. You don’t need to edit the rule.
Hi there, I am trying to following your tutorial but I am still struggling :(. I am trying to publish a number to a another system (SAE) but keep on getting this error.
That’s not what this is for. Just use a Generic MQTT Thing configured to publish the number to the topic you want. Using the EB to publish one number is like using a blowtorch to light a candle.
Please don’t post screen shots of errors.
What version of OH? You installed the rule template (templates is on OH 3)? How did you configure them? What are the Groups and Item memberships?
Thanks Rich, that was indeed quite straightforward to use a Generic MQTT thing, defining a command topic and using the follow option. Thanks again for your quick response, Erik
Hello Rich,
I, too, don’t really need to link two openhab instances, but rather only want to do the same as Erik, publish state changes of OH items to MQTT. I could go the route of a Generic MQTT thing, but since I have quite a few items to publish, adding them to a group is a lot easier than creating MQTT channels and linking them. So basically using 1/4 of the function of the Event Bus.
I’m very sure that I have the configuration correct (I created the Publish-Channel on the MQTT bridge thing), even tried switching out the groups, but also run into the same error:
MQTT Event Bus rule triggered without an event we can process.
Any idea on this?
Put the rule into debug level logging by setting the logger level for org.openhab.automation.rules_tools.MQTTEventBus to DEBUG in any of the usual ways. There is also a line you can uncomment at the top of the Script Action to put the rule into debug logging.
It might be the template needs to be updated for a change in OH 4. A new Item event was added.
I’ve added some updates to the logging also so please remove the old template and add the new one and reinstantiate the rule.
That might be better handled using a rule with the publish Action. You’ll have a lot more control over how it works.
