Strange MQTT Client behavior

I’ve been testing it during weekend and so far this build looks really stable. So far no random disable of flows.

@HarriedeGroot, you did fantastic job.

Thanks!

1 Like

YW, got some good looking result here too:

works like a charm, updated without any problem and kept running since. No problems with broker and hub, all flows and nodered are still alive.

I am seeing promising results too… will post if I find anything ‘strange’

(Ignoring some v6 beta issues)

Great work Harrie… So far so good.

The disabling of flows error (flows which used MQTT client) doesn’t occur anymore. These flows use # wildcards to listen for certain text.

For me the disabling flows error would previously occur when ever I tried scanning for new Tasmota devices in the Tasmota App.

Doesn’t happen anymore :slightly_smiling_face: … Thanks mate …:smiley:

One week past. I’m curious if anyone had any issues with the beta/test version of the MQTT Client app?

@scanno did you get any reports? How many users installed the test version?

And the connection dropouts between apps? Are regular app restarts still needed?

And Homey responsiveness? Became worse due the retained messages coming in now or is improved by the additional checks for incoming messages?

CPU/Memory usage? Memory leaks introduced?

Perhaps I am not the most heavy user (though I am currently setting up a HA dashboard, so…), but have not had any issue at all.

Currently MQTT Client is using 17.8MB (and Hub 25.6MB) memory.
Homey seems very responsive too.
(Broker in Docker on local Synology DS218+)

@HarriedeGroot there are 52 users using the test version. I have not received any bug reports and the crash count is 0.

1 Like

For me all is fine with the test version.
Topic subscription is working. Also after Homey restart (subscription, automatic Hub-broadcast).
Homey systemload is stable and independent of number of topic subscriptions.
Memory: Hub=21,6MB, Client=14,5MB

Thanks for the info. Looking all good to me; actually much better then expected.

@scanno Are you comfortable pushing this to live?

I’ve got some updates for the Hub on test already. These need the new unsubscribe API of the client. So waiting for the client before it can be released.

Your build #6 for app nl.scanno.mqtt is now waiting for certification.

Version is live I see, thanks @scanno.

It’s still working well for me. My devices use it on a daily basis.

Just a quick update.

Unfortunately the “flow disabled because executed too many times” error is reoccurring again for me. :frowning:

Previously this would only happen for me whenever I was trying to discover new devices in the Tasmota APP… Now it just seems to happen at random every few days for no reason.

This only occurs with flows that have a MQTT wildcard in them.

The only thing that has changed with my setup just before these new bunch of errors started occurring is that I’ve recently added a few more flows that use MQTT wildcards…

The application I’m using these flows for is to monitor 6 x 433Mhz PIR motion sensors , 2 x FireAlarms , and a contact sensor on my fridge door. I have a SonOff RF-Bridge listening out for all of these. It’s been reflashed with Tasmota so it can communicate any events from these sensors to Homey via MQTT…

Each sensor pauses for a few seconds between every transmission that it does. The contact sensor on the fridge door can transmit more rapidly but the problem never happens with it. I’d also be very lucky to get two motion sensors trigger exactly at the same time so the amount of traffic and input coming from all of them is quite low.

I’m on Homey version 6.0 . The SonOff RF bridge is on the latest version of Tasmota… Can anyone think of an theories. ?

Here is a sample of one of the flows in case I’m doing something wrong … thanks

For me in the past helped to create MQTT device for each external sensor. Then flows do not monitor MQTT topic, but property of device which doesn’t lead to flow disable.

Only disadvantage is that only property (capability) which can store text messages is Album, Artist or Track, so messages from my UPS are displayed as Tracks :wink:

That sounds interesting.

Do I use the MQTT Hub App to create a MQTT device ?. I’ve never really used it before .

yes - add new device and choose MQTT hub device.

Thanks. I just downloaded it.

It looks like theres a bit to learn but I’d dare say it will sort out my problems for now. The disabling of flows issue is happening on a daily basis now and is majorly screwing up my house hold. Nearly tripped over last night as my lights wouldn’t turn on… :weary:

Would you mind telling me quickly how can I add or create a Virtual/MQTT device based on the input of a 433Mhz motion sensor… ?

Whenever it trIggers it sends a MQTT message containing the text “076F2C”.

How do I translate that into making a virtual/MQTT type device ?

Thanks again …

@Russell_S A general example can be found here:

Thanks mate.

Tonight I spent some more time making sure all my settings were correct as I didn’t know much about Tasmota, using MQTT or setting up Homey when I got my system originally going…

With the original “disabling of flows” errors that I was experiencing I think that may of been due to the original code of the MQTT client as that now doesn’t occur anymore when I try to discover new Tasmota devices.

After some thought I think I might have a theory as to why these new more recent errors are occurring .

Tonight I went to check the settings of my SonOff RF bridge (Tasmota) configuration. I noticed that I had previously set logging to “all”. I did this (at the time) as I was having issues getting it going . I never changed those settings back to default and just kept using them. Tonight I put those logging settings back to normal default…

After doing that change Ive noticed all my flows wont receive any inputs or triggers anymore… I went through some MQTT client logs and noticed it would occasionally reference “tele/rfbridge1” as the topic.

I’ve always use “stat/rfbridge1” in my flows…

Tonight I went and changed all my flows to listen to “tele/rfbridge1” instead . Now they work again …

Do you think all the recent disable flow errors I was experiencing over the last few days was due to the log settings I had previously setup on my SonOff-RF bridge combined with using “stat/rfbridge1” when listening for wildcards in my flows ?

It’s too early to tell but everything seems to be runnings fine since I made these new changes …