# Strange MQTT Client behavior
**URL:** https://community.homey.app/t/strange-mqtt-client-behavior/45105
**Category:** Apps
**Tags:** flow, mqtt
**Created:** [March 22, 2021, 7:03pm UTC](https://community.homey.app/t/strange-mqtt-client-behavior/45105 "2021-03-22T19:03:01Z")
**Posts on this page:** 20
**Page:** 2
### Author:  [@robertklep](https://community.homey.app/u/robertklep)
#### Post date: [March 26, 2021, 2:11pm UTC](https://community.homey.app/t/strange-mqtt-client-behavior/45105/21 "2021-03-26T14:11:16Z")
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](https://homey.app/en-gb/wiki/homey-vs-vera/), it’s basically still a black box with new undocumented surprises around every corner.
---
### Author:  [@Zimo](https://community.homey.app/u/Zimo)
#### Post date: [April 9, 2021, 11:52am UTC](https://community.homey.app/t/strange-mqtt-client-behavior/45105/22 "2021-04-09T11:52:32Z")
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…
---
### Author:  [@robertklep](https://community.homey.app/u/robertklep)
#### Post date: [April 9, 2021, 12:01pm UTC](https://community.homey.app/t/strange-mqtt-client-behavior/45105/23 "2021-04-09T12:01:01Z")
> [@Zimo](#):
>
> 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
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 😛
---
### Author:  [@Zimo](https://community.homey.app/u/Zimo)
#### Post date: [April 9, 2021, 12:33pm UTC](https://community.homey.app/t/strange-mqtt-client-behavior/45105/24 "2021-04-09T12:33:22Z")
I can repro it any time.
1. create flow listening to any (even non existing) topic
2. 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…
---
### Author:  [@robertklep](https://community.homey.app/u/robertklep)
#### Post date: [April 9, 2021, 12:34pm UTC](https://community.homey.app/t/strange-mqtt-client-behavior/45105/25 "2021-04-09T12:34:31Z")
Yeah I can reproduce it with the MQTT Client app as well, just not with a proof of concept I’m trying to make 🥴
---
### Author:  [@HarriedeGroot](https://community.homey.app/u/HarriedeGroot)
#### Post date: [April 9, 2021, 2:50pm UTC](https://community.homey.app/t/strange-mqtt-client-behavior/45105/26 "2021-04-09T14:50:31Z")
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.
---
### Author:  [@xAPPO](https://community.homey.app/u/xAPPO)
#### Post date: [April 9, 2021, 2:56pm UTC](https://community.homey.app/t/strange-mqtt-client-behavior/45105/27 "2021-04-09T14:56:17Z")
> [@HarriedeGroot](#):
>
> (the /set topic for each device + some more).
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.
---
### Author:  [@robertklep](https://community.homey.app/u/robertklep)
#### Post date: [April 9, 2021, 3:03pm UTC](https://community.homey.app/t/strange-mqtt-client-behavior/45105/28 "2021-04-09T15:03:03Z")
Just subscribing to 1000 topics as fast as possible doesn’t seem to cause any issues.
---
### Author:  [@HarriedeGroot](https://community.homey.app/u/HarriedeGroot)
#### Post date: [April 9, 2021, 3:03pm UTC](https://community.homey.app/t/strange-mqtt-client-behavior/45105/29 "2021-04-09T15:03:39Z")
And topics with wildcards: {topic}/#
For each device the hub subscribes to two topics:
---
### Author:  [@robertklep](https://community.homey.app/u/robertklep)
#### Post date: [April 9, 2021, 3:06pm UTC](https://community.homey.app/t/strange-mqtt-client-behavior/45105/30 "2021-04-09T15:06:52Z")
Are the prefixes (`t.mqttTopic` and `t.config.mqtt.base_topic`) unique per device?
---
### Author:  [@HarriedeGroot](https://community.homey.app/u/HarriedeGroot)
#### Post date: [April 9, 2021, 3:07pm UTC](https://community.homey.app/t/strange-mqtt-client-behavior/45105/31 "2021-04-09T15:07:53Z")
Yes, I think…
Should start a debug session to verify this.
---
### Author:  [@xAPPO](https://community.homey.app/u/xAPPO)
#### Post date: [April 9, 2021, 3:08pm UTC](https://community.homey.app/t/strange-mqtt-client-behavior/45105/32 "2021-04-09T15:08:13Z")
What is `t.`mqtttopic`` typically? Every device ?
---
### Author:  [@HarriedeGroot](https://community.homey.app/u/HarriedeGroot)
#### Post date: [April 9, 2021, 3:09pm UTC](https://community.homey.app/t/strange-mqtt-client-behavior/45105/33 "2021-04-09T15:09:28Z")
need som backtracking, it has been a while 🙂
t.mqttTopic = t.config.mqtt.base\_topic + t.config.device\_id;
“base\_topic”: “homie/”,
---
### Author:  [@HarriedeGroot](https://community.homey.app/u/HarriedeGroot)
#### Post date: [April 9, 2021, 3:12pm UTC](https://community.homey.app/t/strange-mqtt-client-behavior/45105/34 "2021-04-09T15:12:17Z")
So it listens to all messages send to “homie/{homey}/{device\_id}/\*” for each device
---
### Author:  [@robertklep](https://community.homey.app/u/robertklep)
#### Post date: [April 9, 2021, 3:13pm UTC](https://community.homey.app/t/strange-mqtt-client-behavior/45105/35 "2021-04-09T15:13:08Z")
And also `homie/$broadcast/#` for each device, correct?
---
### Author:  [@xAPPO](https://community.homey.app/u/xAPPO)
#### Post date: [April 9, 2021, 3:13pm UTC](https://community.homey.app/t/strange-mqtt-client-behavior/45105/36 "2021-04-09T15:13:12Z")
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
---
### Author:  [@HarriedeGroot](https://community.homey.app/u/HarriedeGroot)
#### Post date: [April 9, 2021, 3:13pm UTC](https://community.homey.app/t/strange-mqtt-client-behavior/45105/37 "2021-04-09T15:13:24Z")
@robertklep correct
---
### Author:  [@HarriedeGroot](https://community.homey.app/u/HarriedeGroot)
#### Post date: [April 9, 2021, 3:14pm UTC](https://community.homey.app/t/strange-mqtt-client-behavior/45105/38 "2021-04-09T15:14:53Z")
But I don’t understand why this ‘wildcard’ causes a flow to be disabled?
---
### Author:  [@xAPPO](https://community.homey.app/u/xAPPO)
#### Post date: [April 9, 2021, 3:16pm UTC](https://community.homey.app/t/strange-mqtt-client-behavior/45105/39 "2021-04-09T15:16:54Z")
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 ?
---
### Author:  [@robertklep](https://community.homey.app/u/robertklep)
#### Post date: [April 9, 2021, 3:17pm UTC](https://community.homey.app/t/strange-mqtt-client-behavior/45105/40 "2021-04-09T15:17:15Z")
Still can’t reproduce it:
```auto
…
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.
[Previous page](https://community.homey.app/t/strange-mqtt-client-behavior/45105.md?page=1)
[Next page](https://community.homey.app/t/strange-mqtt-client-behavior/45105.md?page=3)