Its in test now @HarriedeGroot
I will leave the MQTT client in test for a while. Please let me know if all works out. If there are no (major) issues, I will submit it for certification.
Sorry for the lack of time, but I really have to focus on my research and thesis.
Thanks! Let’s monitor for a while indeed. No hurries. Study is much more important.
For completeness, the updated test version can be found here:
Please report your findings
Details of the changes:
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.
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 … Thanks mate …
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.
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.
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
That sounds interesting.
Do I use the MQTT Hub App to create a MQTT device ?. I’ve never really used it before .