Openhab commands to MQTT are slow

Hardware DIY
,
1

Hi,

I got 2 Sonoff basic up and running with MQTT, sending commands straight from the MQTT broker instantly triggers the sonoffs.
When I do it from openhab (no matter if it’s from the paper UI or through a rule), they are responding randomly. Sometimes they are responding instantly and sometimes it takes 6-8 sekunds for them to respond (receive the command in the MQTT broker). Also it can random, one maybe receives the command right away and the other one receives it 6-8 sekunds later.
The messages shows up instantly in the log in openhab, but is not always showing up in the MQTT broker at the same time.

I’ve tried to send commands from the MQTT broker and to the sonoffs, the log in openhab shows the update instantly.

So the problem is somewhere from the openhab to the MQTT and not the other way around.

I’ve created a bridge for my sonoffs:
Bridge mqtt:broker:HomeAutomation “MQTT” [ host=“127.0.0.1”, secure=false ]
{
Thing topic sonoff {
Channels:
Type switch : vask “vask” [ stateTopic=“stat/Vask/POWER”, commandTopic=“cmnd/Vask/POWER”]
Type switch : krydderi “krydderi” [ stateTopic=“stat/Krydderi/POWER”, commandTopic=“cmnd/Krydderi/POWER”]
}
}

I’ve created the two items:

Switch Vask "Køkken Vask" (Kitchen_lys, Lys, Stue) ["Lighting"] { channel="mqtt:topic:HomeAutomation:sonoff:vask"}

Switch Krydderi "Køkken Krydderi" (Kitchen_lys, Lys, Stue) ["Lighting"] { channel="mqtt:topic:HomeAutomation:sonoff:krydderi"}

Here is my log from Openhab

2019-11-27 18:07:02.222 [nt.ItemStatePredictedEvent] - Vask predicted to become ON

2019-11-27 18:07:02.232 [vent.ItemStateChangedEvent] - Vask changed from OFF to ON

2019-11-27 18:07:02.245 [nt.ItemStatePredictedEvent] - Krydderi predicted to become ON

2019-11-27 18:07:02.251 [vent.ItemStateChangedEvent] - Krydderi changed from OFF to ON

2019-11-27 18:07:05.660 [ome.event.ItemCommandEvent] - Item 'Kitchen_lys' received command OFF

2019-11-27 18:07:05.668 [ome.event.ItemCommandEvent] - Item 'Vask' received command OFF

2019-11-27 18:07:05.673 [ome.event.ItemCommandEvent] - Item 'Krydderi' received command OFF

2019-11-27 18:07:05.678 [nt.ItemStatePredictedEvent] - Vask predicted to become OFF

2019-11-27 18:07:05.685 [nt.ItemStatePredictedEvent] - Krydderi predicted to become OFF

2019-11-27 18:07:05.688 [vent.ItemStateChangedEvent] - Vask changed from ON to OFF

2019-11-27 18:07:05.691 [vent.ItemStateChangedEvent] - Krydderi changed from ON to OFF

2019-11-27 18:07:07.289 [ome.event.ItemCommandEvent] - Item 'Kitchen_lys' received command ON

2019-11-27 18:07:07.297 [ome.event.ItemCommandEvent] - Item 'Vask' received command ON

2019-11-27 18:07:07.303 [ome.event.ItemCommandEvent] - Item 'Krydderi' received command ON

2019-11-27 18:07:07.317 [nt.ItemStatePredictedEvent] - Vask predicted to become ON

2019-11-27 18:07:07.327 [nt.ItemStatePredictedEvent] - Krydderi predicted to become ON

2019-11-27 18:07:07.335 [vent.ItemStateChangedEvent] - Vask changed from OFF to ON

2019-11-27 18:07:07.338 [vent.ItemStateChangedEvent] - Krydderi changed from OFF to ON

2019-11-27 18:07:22.640 [ome.event.ItemCommandEvent] - Item 'Kitchen_lys' received command OFF

2019-11-27 18:07:22.650 [ome.event.ItemCommandEvent] - Item 'Vask' received command OFF

2019-11-27 18:07:22.656 [ome.event.ItemCommandEvent] - Item 'Krydderi' received command OFF

2019-11-27 18:07:22.667 [nt.ItemStatePredictedEvent] - Vask predicted to become OFF

2019-11-27 18:07:22.671 [nt.ItemStatePredictedEvent] - Krydderi predicted to become OFF

2019-11-27 18:07:22.677 [vent.ItemStateChangedEvent] - Vask changed from ON to OFF

2019-11-27 18:07:22.681 [vent.ItemStateChangedEvent] - Krydderi changed from ON to OFF

And from the MQTT, the marked state is equal to 2. last message send in Openhab 18:07:07

image
image860×485 14.8 KB

1 Like
2

Hi Christian
I’m not sure what could be causing the delay but my first questions are what platform is OpenHAB running on and what version of OpenHAB. Is the system heavily loaded?

3

Hi Andrew,

I think you need to guide me a little to what I need to give you. I’m running openhab 2.4.0, CPU on the PI is not going above 30%, so I guess it’s not loaded?

4

OK, that is good. 30% doesn’t seem high enough to cause problems. What is the broker? is the broker running on the same Pi?

5

I use the standard ones from the bindings?

image

6

OK fair enough, you are using the embedded Moquette broker.
I guess you need to try to isolate the problem but it seems quite random. I am unfamiliar with Pi and sonoff, sorry. How does sonoff communicate? wifi?
I’m unsure how to proceed but look close at the logs and make sure there isn’t a spike in other things happening which is delaying the mqtt message, try to isolate the problem somehow

7

Every once in a while I notice mqtt will seem sluggish and what works for me is cleaning the cache.

sudo systemctl stop openhab2

sudo openhab-cli clean-cache

sudo systemctl start openhab2 or sudo reboot

I usually do the reboot.

8

Yes it’s through WIFI, I think it’s really random, I can’t figure out why it should be delayed, I’ve tried to isolate it knowing it’s only when I’m sending a message from the Pi to the MQTT and not the other way. But thx for trying

9

yes and that would point to OpenHAB itself not any other source. Look close at the logs, try to pinpoint when the delay happens if something else is going on. Maybe find a utility to log performance info like CPU and memory usage somehow

10

Unfortunately, the embedded broker Moquette, is essentially abandoned by it’s developer. There is not yet a consensus about what oh is to do about that so my recommendation for not is if you experience any problems with the embedded broker, abandon it and use Mosquitto instead.

1 Like
11

I’m running in to this same issue and have been for nearly a year, from 2.3? and still exists on 2.5.0 stable for me today (on a Pi3b which is confirmed to not be overloaded).
All tasmota flashed sonoffs seem equally affected in my ecosystem, at random. Direct switching from tasmota web interface is instant.

Is there a preferred/suggested method to running Mosquitto directly on openhabian alongside OpenHAB, or is it the same as any basic install on Debian?

Any guides/suggestions would be appreciated! Thanks

12

It’s the same basic install as on Debian, though it might set a username and password in the config. Beyond that it’s a basic install with pretty much all the settings at the defaults.

1 Like
13

I do appreciate the answer, thank you very much.
If I may ask one more, is it preferred to install the Eclipse MQTT Broker from the openhabian-config tool option?
I’m happy to do it manually, but would like to stick with whatever the consensus is for best practice (if there is currently such a thing).

14

If you are using openHABian it’ll be less work and you will end up with a “known” configuration if you isntall from openhabian-config.

1 Like
15

Just thought it worth posting, I made this change on my openHABian Pi 3b and WOW, the difference is day and night.
Instant switching from basicUI now with no random delay, instant switching without weird delays on my 2way (hallway type) switches…
Why the hell didn’t I do this ages ago?

All I had to do was uninstall moquette in addons/misc, reboot, use openhabian-config to install eclipse mosquitto (while ignoring that very confusing message saying "do you really want to install a separate MQTT broker…), add the same user/password in to the dialogue, reboot again and everything else was automagic.
I already used mqtt.things file so nothing else really needed to be changed:

Bridge mqtt:broker:embedded-mqtt-broker [ host="127.0.0.1", secure=false, username="openhabian", password="xxxxxxxxx" ]
{
    Thing mqtt:topic:mything {
    Channels:
        Type switch : Sonoff_T1_3G_Pass_Front_01 "Passage Front Light" [ stateTopic="stat/Sonoff_T1_3G_Pass_Front/POWER1", commandTopic="cmnd/Sonoff_T1_3G_Pass_Front/POWER1" ]
....

The only other thing I did (which didn’t affect function either way) was disable the paperui config/things (which I’ll delete later after some testing)

Thanks for the tips! MQTT response time is now back where it should be on my Pi using OpenHABian!!!

1 Like