It doesn’t look like that’s the issue now though, at least I cannot reproduce it.
Even though Athom may think Homey has an open app platform, it’s basically still a black box with new undocumented surprises around every corner.
Hello, here is response from Athom support - as robert predicted…
Hi Zimo,
The rate limiter that stops your flow only looks at flows that have the WHEN card triggered. It does not matter what card, what app it belongs to, or even if it should be triggered or not, if a flow WHEN card is triggered, it is listed in the rate limiter, and if it exceeds one of the set limits, the flow will be paused. This is an integral part of Homey core to maintain system stability.
The issue is not the rate limiter itself, if that was the case I would have thousands of users contacting me with the exact same issue, and I would have it at my private setup as well. The problem in your case is that for some reason that is outside of our understanding, the flowcard is triggered, even though it should not. This is due to the behaviour of the card, which is determined by the (community) app, not by Homey. As I stated above, we only monitor if it is triggered, not if it should have been triggered or not.
This is the reason I am pointing at the community developer, as I am unable to help you with this issue. I totally agree with you that the flowcard should not trigger because the topic is fictional, and I agree that this is a bug, but it not a bug I or my developers will be able to solve for you, this is something in either the MQTT hub or MQTT Client app that for some reason (most likely an edge case) is triggering this flowcard in an unwanted situation, which then gets the flow paused, by a basic functionality inside Homey that has been in place (and working flawlessly) for years now.
I really am truly sorry but I cannot help you, the issue is not on our side.
Best Regards,
I have solved my issue by adding MQTT device (button) for each channel I need to monitor - then I created flow which is triggered when button is pressed… It’s not elegant, but it’s working…
Unfortunately this failsafe disabling of flows makes Homey quite unreliable - as far as I know there is no way to hook any action or better notification when flow is disabled by this mechanism…
1 Like
It’s strange though, because I haven’t been able to trigger the rate limiter when I do something similar to what the MQTT Client does: call the trigger handler but return “false” from it so the flow isn’t actually run.
Funny that they say the rate limiter is “flawless”. I guess @Rocodamelshekima’s issues with it are his own fault 
1 Like
I can repro it any time.
- create flow listening to any (even non existing) topic
- restart MQTT client (because it’s not listening until client is restarted)
…
now when I restart MQTT hub app it disables this flow.
strange thing is, that hitting “broadcast” button in app doesn’t disable flow…
Yeah I can reproduce it with the MQTT Client app as well, just not with a proof of concept I’m trying to make 
During app initialisation, the Hub starts listening to a lot of mqtt topics (the /set topic for each device + some more). It calls the MQTT Client ‘subscribeToTopic’ API for each topic.
During a broadcast only messages are sent (the current value of each device capability). The broadcast therefore uses the MQTT Client ‘sendMessage’ API.
Because a broadbast does not cause the flow to be disabled and app startup does, I gues we need to start looking into the topic subscription process of the MQTT Client app.
1 Like
Theses aren’t retained on the broker so shouldn’t generate incoming events. This sounds like a wildcard subscription that’ s being setup somewhere… although even then the rate limiting is weird in being applied.
Just subscribing to 1000 topics as fast as possible doesn’t seem to cause any issues.
And topics with wildcards: {topic}/#
For each device the hub subscribes to two topics:
Are the prefixes (t.mqttTopic and t.config.mqtt.base_topic) unique per device?
Yes, I think…
Should start a debug session to verify this.
What is t.mqtttopic`` typically? Every device ?
need som backtracking, it has been a while 
t.mqttTopic = t.config.mqtt.base_topic + t.config.device_id;
“base_topic”: “homie/”,
So it listens to all messages send to “homie/{homey}/{device_id}/*” for each device
And also homie/$broadcast/# for each device, correct?
That’s a very broad wildcard then … you are really only interested in …/set aren’t you and maybe the current state. But you additionally have to pickup any discoverable devices.(not originated by Homey) but they will be under a different device tree in homie
But I don’t understand why this ‘wildcard’ causes a flow to be disabled?
Agreed - that is a bug somewhere. Athom’ s implementation seems to believe the flow was triggered even though it wasn’t. Not a text false being returned when a Boolean was expected or something silly ?
Still can’t reproduce it:
…
subscribe to homie/device-248/# and homie/$broadcast/#
subscribe to homie/device-249/# and homie/$broadcast/#
So 250 “devices”, but all flows keep on working.
