MQTT broker as event bus: 1.x vs. 2.x

Add-ons Bindings
,
1

From what I gather from other confused users in various threads, the 1.x MQTT binding out of the box could push all events to a MQTT broker, so that it could act as an event bus - and the 2.x MQTT can’t (at least the one from 2.4). Is that assessment correct ?

I have read advice that, if event bus functionality is desired, the best course of action for now to use the 1.x MQTT binding. Can anyone confirm that ?

Is there a good way to let a 2.4 Openhab push all events to a MQTT broker ? I found this mqqteventbus.rules but it looks like a lot of rules for something that I expected to be a couple of “catch-all”… Should I use it anyway ?

Is some “dump all events to MQTT” event bus feature roadmapped for the 2.x MQTT binding ?

2

There is an easy way with mqtt2 but its a bit hidden right now, you ll find how to do it here Roadmap: MQTT binding just click on the link and scroll to the part about synchronizing two instances

1 Like
3

Thank you - I had read that thread and the MQTT broker synchronization recipe you allude to, but I had failed to catch how relevant they are to my questions.

So, it looks like the below rule is pretty much what I need:

rule "Publish all"
when 
      Member of myGroupOfItems changed
then
   val actions = getActions("mqtt","mqtt:broker:myUnsecureBroker")
   actions.publishMQTT("allItems/"+triggeringItem.name,triggeringItem.state.toString)
end

Except of course that I’ll need to define a group - from what I understand from threads here, there is no built-in “all items” group… Wouldn’t such thing be useful ?

4

Sure. But the old rule syntax is not extended anymore. openHAB is a bit in flux at the moment.
It is probably possible with the new Java scripting support in openHAB (Jython, Javascript syntax)

1 Like
5

Hi,

you can give HABApp a try. It’s a rule engine for home automation in python I am using to easily create rules.
I have included an example rule which does exactly what you want without further configuration changes.
I would love to get some feedback :slight_smile:

6

I rewrote the mqtt2 eventbus rules to work with the awesome jython decorators from @5iver if you want to use those

from core.rules import rule
from core.triggers import when

@rule("Publish all")
@when("Member of OutItems changed")
def MQTTPublishOut(event):
    output1 = event.itemName
    output2 = str(event.itemState)
    actions.get("mqtt","mqtt:broker:f79d2a84").publishMQTT("allItemsout/"+output1,output2)

@rule("Receive all")
@when("Channel mqtt:broker:f79d2a84:TriggerIn triggered")
def MQTTPublishIn(event):
    input1 = event.event
    input2 = input1.split("/")
    input3 = input2[1].split("#")
    events.sendCommand(input3[0], input3[1])

Right now you need to comment out two lines in the triggers.py for it too work, see here [JSR223-Jython] Simplified rule definition (similar to Rules DSL) and universal decorator
As the publish channel of the MQTT2 Binding is declared as a State channel and not a trigger channel, see here [JSR223-Jython] Simplified rule definition (similar to Rules DSL) and universal decorator
Is this on purpose @David_Graeff?

7

There has already been a bug report opened by @5iver.
I’m currently clueless why that is, as the xml description file clearly marks trigger channels as type “trigger”. Will investigate when the integration tests work again on the addons repo.

1 Like
8

For reference…

9

What about using the persistence for the outgoing messages? That could be an “elegant” way of addressing the point, without having to define a group as it is possible to use the * wildcard.

Just my two cents.