RGBW2 floods of MQTT messages problem

There is 1 reply in this Thread which was already clicked 311 times. The last Post () by holeymoley.

  • I have bought a few shelly devices to use with node red. The first one I am playing with is RGBW2. I have updated FW to the latest. It works with node red and my Iot handler perfectly but I noticed the NR log was growing very quickly and occasionally - things were not as snappy as before.


    The problem is that it starts to throw MQTT updates almost continuously - randomly bursting up to 10 or so messages per second. It will go quiet for a few seconds and then start again. It seems to depend on how many channels are on.


    I have tried changing various options from defaults - including changing mqtt_update_period. (currently set at 74). Non of the config changes seem to make a difference. It is NOT a loop in node red and MQTT. (Proved by disabling publishing any shellies/xxx from node red. Unless it has subscribed to something other than shellies/xxx)


    I have set back to factory settings and started afresh - no different.


    As it stands it appears the shelly system with current firmware is not usable - if this is typical - my rpi will grind to a halt when I add the other half dozen or so shellys.


    It seems quiet and in control when all channels are off - I get maybe 20 messages in a bunch every 75 ish seconds - more or less as configured.


    I don't really want to take the step of going to tasmota but wonder if that is the only way to get shellys working properly if you need MQTT


    Test setup:- It is running on 12v and has a test load on each output of a LED and 2K2 resistor

    (Revision is 20210415-131002/v1.10.3-g23074d0).


    Has anyone any suggestions for a fix or work around?


    Thanks

    Coppo

  • Hi, I use an RGB2 connected to a broker and have another seperate home automation system subscribed to its topics, and I have some scripting that keeps the two systems synchronised. I had a few issues that sound like yours when I started out. I wanted to use the Shelly native app, and my own Automation system app also, so I had some scripts syncing the two devices. For a while, I was causing loops, when one system updated the other, and then that one tried to update the first one again etc... I put small time delays in my scripts, and also some rules to only update the shared values if the change of value was greater than X percent etc.. So I basically applied a small deadband, or hysteresis effect. My scripts are all homemade and very tailored to my own needs so not much point in sharing the specifics, but that was the basic principle. I don't use Node-Red, so can't offer you any specific advice there...


    Some other things that helped were to set the MQTT QOS of the Shelly to 2, and also the QOS of my subscribing automation system to 2 aswell, so you can then be certain the messages are only sent once and received once. Also do not use 'clean-sessions' - untick it, and do use the Retain feature on both ends. Then you can be sure you have the most stable MQTT setup possible. If you do that, you might then find possible loops elsewhere. I know you mentioned you are pretty sure you don't have any, but I thought that too until I found them :). If you do find loops, you can relax the MQTT settings in the future...


    You can also set the MQTT update period to a much higher value, with the command http://192.168.xx.xxx/settings?mqtt_update_period=300 - so you only get broadcasts every 5 minutes. That should be fine, as real events and changes are still broadcast pretty much straight away. The update period broadcast things is only really for sorting out trivial drifts in state...