Multiple state updates on the eventbus when using mqtt

Setup, Configuration and Use Runtime
, ,
1

Hi all,

I have configured OH2 with mqtt and mqtt-eventbus. Having one thing (a nexa switch) and a linked item allows me to control a lamp without any problem. When I subscribe to the eventbus topic for state updates (configured as statePublishTopic=/openHAB/in/${item}/state) using mosquitto_sub ( mosquitto_sub -t /openHAB/in/livingroom_bookshelf_lamp/state) I can se state updates.

Now to the troublesome parts - when I toggle the switch, either by clicking in the GUI or by sending an mqtt command, I get four (4) state updates.

Client cmdline received PUBLISH (d0, q0, r0, m0, '/openHAB/out/livingroom_bookshelf_lamp/command', ... (3 bytes))
OFF
Client cmdline received PUBLISH (d0, q0, r0, m0, '/openHAB/in/livingroom_bookshelf_lamp/state', ... (3 bytes))
OFF
Client cmdline received PUBLISH (d0, q0, r0, m0, '/openHAB/in/livingroom_bookshelf_lamp/state', ... (2 bytes))
ON
Client cmdline received PUBLISH (d0, q0, r0, m0, '/openHAB/in/livingroom_bookshelf_lamp/state', ... (3 bytes))
OFF
Client cmdline received PUBLISH (d0, q0, r0, m0, '/openHAB/in/livingroom_bookshelf_lamp/state', ... (3 bytes))
OFF

First line is the actual command sent (OFF) and then comes the four state updates.

Is this expected behavior? Why is it happening?

Best regards,
/David Boman

2

@DavidBoman Did you ever get this resolved? I’m seeing a similar where I see 2 state updates every time I send a command to an item.

mqtt.cfg

mqttloc.url=tcp://localhost:1883
mqttloc.clientId=openhab

mqtt-eventbus.cfg

broker=mqttloc
statePublishTopic=/openhab/out/${item}/state
commandPublishTopic=/openhab/out/${item}/command
stateSubscribeTopic=/openhab/in/${item}/state
commandSubscribeTopic=/openhab/in/${item}/command
3

@rgerrans : No, I have not yet resolved it but I did get some glues when I was looking att the actual radio communication with the Nexa switch. Turns out that it is actually sending multiple updates for some reason. I’m not sure how to handle it though - the Tellstick binding is talking directly with telldus-core and sees all traffic so naturally it will emit it on the event bus.

My current idea (but I have not yet had time to implement it) is to write a “unique-filter” that reads all the state updates from one topic and emits unique state updates to a new topic. So instead of:

A -> (publishes on) -> statePublishTopic <- (subscribes to) <- B

I will have:

A -> (publishes on) -> statePublishTopic <- (subscribes to) <- UniqueFilter -> (publishes on) -> statePublishTopicUnique <- (subscribes to) B

Hopefully that will stop the duplication but it’s an ugly and probably very error prone solution.

Cheers,
/David

4

Thanks for the follow-up. I ended up just putting in filters where I saw it happening as well.

5

Great! How did you implement the filtering?

6

I moved over to Node-red as my rules engine and am using built in rate limit and by exception nodes (depending on the type of device) to block the repeats from getting through.

Have you tested if going to a per item mqtt configuration has the same issue?

7

No, I did not do any extensive testing on a per item configured mqtt setup as that would be to cumbersome to maintain for a larger setup. Once I get the filtering to work as described above I will report my findings. I’m on parental leave with my one year old daughter so I don’t get that much time in front of the computer though :slight_smile:

8

Time much better spent, enjoy it goes fast.

Agree, though I’m about to migrate my Zwave over to a Zway board/software so will be going through the per item setup. I’ll test it once I I start the migration on a few devices prior to moving them over to see if it makes any difference.