# 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:** 3

<div class="post-metadata">

### Author: ![xAPPO](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/xappo/32/13726_2.png) [@xAPPO](https://community.homey.app/u/xAPPO)
#### Post date: [April 9, 2021, 3:19pm UTC](https://community.homey.app/t/strange-mqtt-client-behavior/45105/41 "2021-04-09T15:19:56Z")

</div>

Subscribe homie/+/# is effectively what’s happening though as it’s every device  
Possibly limited to the Homey homie tree

homie/homeyname/+/#

---

<div class="post-metadata">

### Author: ![HarriedeGroot](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/harriedegroot/32/56160_2.png) [@HarriedeGroot](https://community.homey.app/u/HarriedeGroot)
#### Post date: [April 9, 2021, 3:20pm UTC](https://community.homey.app/t/strange-mqtt-client-behavior/45105/42 "2021-04-09T15:20:46Z")

</div>

@robertklep Can you reproduce the actual problem?  
If you restart the hub, does it cause any flow to be disabled?

I’ve got 1 device in Homey (Homey itself), so it’s hard to test 😉

---

<div class="post-metadata">

### Author: ![xAPPO](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/xappo/32/13726_2.png) [@xAPPO](https://community.homey.app/u/xAPPO)
#### Post date: [April 9, 2021, 3:22pm UTC](https://community.homey.app/t/strange-mqtt-client-behavior/45105/43 "2021-04-09T15:22:39Z")

</div>

I’ll check too later when I get back home. I have a few devices …Got to go  
I have not seen this issue but don’t use incoming MQTT flow triggers really

Interesting though

---

<div class="post-metadata">

### Author: ![robertklep](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/robertklep/32/160628_2.png) [@robertklep](https://community.homey.app/u/robertklep)
#### Post date: [April 9, 2021, 3:23pm UTC](https://community.homey.app/t/strange-mqtt-client-behavior/45105/44 "2021-04-09T15:23:22Z")

</div>

I hardly have any devices in Homey, and not running the app, so not sure why I said that I could reproduce the actual problem… 🤔🥴

---

<div class="post-metadata">

### Author: ![HarriedeGroot](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/harriedegroot/32/56160_2.png) [@HarriedeGroot](https://community.homey.app/u/HarriedeGroot)
#### Post date: [April 9, 2021, 3:25pm UTC](https://community.homey.app/t/strange-mqtt-client-behavior/45105/45 "2021-04-09T15:25:40Z")

</div>

@Zimo Can you provide the full MQTT Client log after restarting the hub?

---

<div class="post-metadata">

### Author: ![Russell\_S](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/russell_s/32/45779_2.png) [@Russell\_S](https://community.homey.app/u/Russell_S)
#### Post date: [April 9, 2021, 4:09pm UTC](https://community.homey.app/t/strange-mqtt-client-behavior/45105/46 "2021-04-09T16:09:24Z")

</div>

Not sure if this helps but whenever I try to discover new devices in Tasmota MQTT I get the too many flows error occur , they then all get disabled and I then have to manually re-enable them again. All these flows use MQTT client …

I have tried hard to utilise the in-built 433MHZ feature in Homey (see my other posts) but I gave up in the end and now use a SonOff RF bridge thats been flashed with Tasmota and communicate to all my 433Hhz devices via MQTT…

When listening for MQTT events from my 433Mhz PIR sensors I use this method to capture all the incoming messages .

See flow (below)…

Basically I just get the system to scan and listen for a specific piece of text in all of the incoming MQTT data (identifying the unique device identity) and then make trigger depending on that devices identity…

This is the only on MQTT communication I use in my flows or system but I get the flow overload error when ever I get Tasmota MQTT to discover new devices . Not sure if this helps but just thought I’d share it …

[https://homey.app/f/s6dnTy](https://homey.app/f/s6dnTy)

---

<div class="post-metadata">

### Author: ![HarriedeGroot](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/harriedegroot/32/56160_2.png) [@HarriedeGroot](https://community.homey.app/u/HarriedeGroot)
#### Post date: [April 9, 2021, 4:12pm UTC](https://community.homey.app/t/strange-mqtt-client-behavior/45105/47 "2021-04-09T16:12:59Z")

</div>

The cause of the problem is line 37-40 in [messagehandling.js](https://github.com/scanno/nl.scanno.mqtt/blob/master/messagehandling.js)  
It triggers a flow card for each incoming message.

 ![image](https://us1.discourse-cdn.com/flex025/uploads/athom/original/3X/a/2/a2c18fcf0f1763f0f22d308deba05589702ae040.png)

> <https://github.com/scanno/nl.scanno.mqtt/blob/master/messagehandling.js>

---

<div class="post-metadata">

### Author: ![HarriedeGroot](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/harriedegroot/32/56160_2.png) [@HarriedeGroot](https://community.homey.app/u/HarriedeGroot)
#### Post date: [April 9, 2021, 4:21pm UTC](https://community.homey.app/t/strange-mqtt-client-behavior/45105/48 "2021-04-09T16:21:00Z")

</div>

@scanno Can we match the incoming message topic against ‘ref.triggers.broker.getTopicArray().getTriggerTopics()’ before actually executing the trigger?

---

<div class="post-metadata">

### Author: ![robertklep](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/robertklep/32/160628_2.png) [@robertklep](https://community.homey.app/u/robertklep)
#### Post date: [April 9, 2021, 4:24pm UTC](https://community.homey.app/t/strange-mqtt-client-behavior/45105/49 "2021-04-09T16:24:15Z")

</div>

So the rate limiter is tied to `.trigger()` being called, and not the run listener for that trigger that may (subsequently) decide that the trigger isn’t meant for it? Not sure if that makes sense…

FWIW, I already tested this in my PoC and I wasn’t able to trigger the rate limiter:

```auto
    const trigger = this.homey.flow.getTriggerCard('test');

    trigger.registerRunListener((args, state) => {
      console.log('listener triggered', args, state);
      return Promise.resolve(false);
    });

    for (let i = 0; i < 500; i++) {
      trigger.trigger({ idx: i }, {});
    }

```

---

<div class="post-metadata">

### Author: ![HarriedeGroot](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/harriedegroot/32/56160_2.png) [@HarriedeGroot](https://community.homey.app/u/HarriedeGroot)
#### Post date: [April 9, 2021, 6:36pm UTC](https://community.homey.app/t/strange-mqtt-client-behavior/45105/50 "2021-04-09T18:36:30Z")

</div>

I can reproduce the problem by adding a flow card trigger on a broad wildcard topic like ‘#’ or ‘homie/#’. Such a flow will be disabled in no time due the many triggers, but that’s expected behaviour.

Found something else, I see these log messages **a lot** :  
20210409-18:18:25 MQTT Offline  
20210409-18:18:25 De MQTT broker is ONBESCHIKBAAR  
20210409-18:18:29 Broker State: DISCONNECTED  
20210409-18:18:35 MQTT Closed  
20210409-18:18:35 Broker State: DISCONNECTED  
20210409-18:18:37 MQTT Reconnect  
20210409-18:18:37 Broker State: RECONNECTING  
20210409-18:18:42 De MQTT broker is weer BESCHIKBAAR  
20210409-18:18:45 MQTT client connected  
20210409-18:18:46 Broker State: CONNECTED

Each time the broker is reconneced, all retained messages on the broker (thousands in my case) are send to the client. This causes an endless stream of the same messages.

---

<div class="post-metadata">

### Author: ![HarriedeGroot](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/harriedegroot/32/56160_2.png) [@HarriedeGroot](https://community.homey.app/u/HarriedeGroot)
#### Post date: [April 9, 2021, 6:51pm UTC](https://community.homey.app/t/strange-mqtt-client-behavior/45105/51 "2021-04-09T18:51:22Z")

</div>

@Zimo To answer your initial question about the log:

> [@Zimo](#):
>
> > **20210322-18:41:39 topic: homie/homey-5dd…1/town/conditioncode pattern: openHab/Okno3/BlindsControl**  
> > 20210322-18:41:39 We are not waiting for this topic  
> > 20210322-18:41:40 getLogLines called
> 
> I do not understand what has OpenWheatherMap to do with my blinds?

LOG explained:

- a message is received on topic: **homie/homey-5dd…1/town/conditioncode**
- a flow card trigger is registered to topic: **openHab/Okno3/BlindsControl**

The next line says: **We are not waiting for this topic**  
meaning: The flow card is **not** triggered by this message, because the pattern does not match.

It does not explain why the flow gets disabled though…

NOTE: Your log is from the MQTT client, not from the Hub.

---

<div class="post-metadata">

### Author: ![scanno](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/scanno/32/8358_2.png) [@scanno](https://community.homey.app/u/scanno)
#### Post date: [April 9, 2021, 7:20pm UTC](https://community.homey.app/t/strange-mqtt-client-behavior/45105/52 "2021-04-09T19:20:00Z")

</div>

That would not solve all problems… You need to iterate through the trigger cards anyway to see if a topic matches.

---

<div class="post-metadata">

### Author: ![HarriedeGroot](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/harriedegroot/32/56160_2.png) [@HarriedeGroot](https://community.homey.app/u/HarriedeGroot)
#### Post date: [April 9, 2021, 7:44pm UTC](https://community.homey.app/t/strange-mqtt-client-behavior/45105/53 "2021-04-09T19:44:43Z")

</div>

But a topic match can be checked before even calling the trigger? The flowcard trigger topics are known on beforehand. I know it shouldn’t matter because the trigger response will be false anyway, but who knows…

---

<div class="post-metadata">

### Author: ![scanno](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/scanno/32/8358_2.png) [@scanno](https://community.homey.app/u/scanno)
#### Post date: [April 9, 2021, 8:09pm UTC](https://community.homey.app/t/strange-mqtt-client-behavior/45105/54 "2021-04-09T20:09:29Z")

</div>

You only prevent iterating through the trigger cards when there is no registered topic. You still have to go through them all to do the matching when the topic is registered.

The best solution would be to have a list of topics and the corresponding trigger card id’s and then be able to trigger that specific card.

---

<div class="post-metadata">

### Author: ![Zimo](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/zimo/32/16621_2.png) [@Zimo](https://community.homey.app/u/Zimo)
#### Post date: [April 9, 2021, 8:36pm UTC](https://community.homey.app/t/strange-mqtt-client-behavior/45105/55 "2021-04-09T20:36:39Z")

</div>

Sorry Harrie for dumb question, is there a way to get better logs then copy-pasting log-lines from app interface? Because it trims logs and I can see only last 30 seconds after hub restart and there is much more log lines which I cannot capture…

---

<div class="post-metadata">

### Author: ![Russell\_S](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/russell_s/32/45779_2.png) [@Russell\_S](https://community.homey.app/u/Russell_S)
#### Post date: [April 16, 2021, 2:04pm UTC](https://community.homey.app/t/strange-mqtt-client-behavior/45105/56 "2021-04-16T14:04:58Z")

</div>

Was just curious as to how this went. Was the problem figured out ?

---

<div class="post-metadata">

### Author: ![HarriedeGroot](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/harriedegroot/32/56160_2.png) [@HarriedeGroot](https://community.homey.app/u/HarriedeGroot)
#### Post date: [April 16, 2021, 6:54pm UTC](https://community.homey.app/t/strange-mqtt-client-behavior/45105/57 "2021-04-16T18:54:44Z")

</div>

@Russell_S Well…  
I made a pull request with some improvements to the MQTT Client.

> <https://github.com/scanno/nl.scanno.mqtt/pull/28>
>
> 1. \*\*Made some improvements to the topic registrations (api vs trigger)\*\*
> 2. \*\*…Fixed handling of retained messages\*\*
> 3. \*\*Prevent losing api connections\*\*
> 4. \*\*Addressed the bug of randomly disabled flows\*\*
> 5. \*\*Added unsubscribe api\*\*
> 6. \*\*Introduced a TriggerQueue to handle the rate limiting of flow card triggers and prevent disabling of flows\*\*
> 7. \*\*Added broker online/offline flow card triggers\*\*
> 8. \*\*Added flow card action to send an empty message to be able to remove retained messages from the broker\*\*
> 9. \*\*Introduced TopicsRegistry to register topics by reference (e.g. app id), this reference can be used with the unsubscribe api\*\*
> 10. \*\*Performance improvements\*\*
> 11. \*\*General bug fixes\*\*
> 
> \*\*Commit 1\*\*
> Topic registration:
> \- always subscribe to the broker to return retained messages on subscription
> \- re-subscribe to all previously registered topics on connection of the broker/mqtt-client (keep topic registry alive)
> \- made some calls async and actually wait for the result before continuing + fixed some async handling of promises
> \- extended the TopicArray with seperate methods for api & trigger topics
> 
> \*\*Commit 2\*\*
> \- prevent topic unsubscription if its used by another registration (api vs trigger)
> 
> \*\*Commit 3\*\*
> Flow card triggers:
> \- prevent destruction of the full topics array, causing all api connections being lost
> \- subscribe to all flow card trigger topics on initialisation
> \- on trigger card change (flow card config): unsubscribe from removed topics & subscribe to newly added topics
> \- await the Homey trigger call
> \- check for api topic match before forwarding the message to the realtime api
> 
> \*\*Commit 4\*\*
> pre-check to prevent uneccesairy calls to the Homey trigger system
> prevents disabling of random flows not even listening to these topics (Homey BUG?)...
> this is also a performance boost, since the Homey trigger system won't be called for all api topics
> the small downside is the duplicate topic matching, if there is a match on a trigger topic
> 
> \*\*Commit 5\*\*
> (added missing file 'Trigger.js' for commit 3
> 
> \*\*Commit 6\*\*
> On change of app settings:
> \- prevent destruction of the full topicsArray resulting in lost api connections
> \- re-connect to the broker to trigger subscription al all registered topics (instead of the trigger topics only)
> \- await topic unsubscription before setting up the new client
> 
> \*\*Commit 7\*\*
> added unsubscribe api
> 
> \*\*Commit 8\*\*
> Introduced a TriggerQueue to handle the rate limiting of flow card triggers and prevent disabling of flows
> 
> \*\*Commit 9\*\*
> Added broker online/offline flow card triggers
> 
> \*\*Commit 10\*\*
> Added flow card action to send an empty message to be able to remove retained messages from the broker
> 
> \*\*Commit 11\*\*
> Introduced a TopicsRegistry to register topics by reference (e.g. app id). The unsubscribe api can only be called for topics with the reference provided during topic subscription. This prevents unsubscription of topics used by other apps/processes.
> Also optimized the topic matching by using a topic map (instead of array lookup).

@scanno Needs to look into it before it can be send to the store.  
But maybe someone is willing to test already by installing via CLI?  
branch: [GitHub - harriedegroot/nl.scanno.mqtt at feature/topic-subscription](https://github.com/harriedegroot/nl.scanno.mqtt/tree/feature/topic-subscription)

**DETAILS**

1. **Made some improvements to the topic registrations (api vs trigger)**
2. **Fixed handling of retained messages**
3. **Prevent losing api connections**
4. **Addressed the bug of randomly disabled flows**
5. **Added unsubscribe api**
6. **Introduced a TriggerQueue to handle the rate limiting of flow card triggers and prevent disabling of flows**
7. **Added broker online/offline flow card triggers**
8. **Added flow card action to send an empty message to be able to remove retained messages from the broker**
9. **Introduced TopicsRegistry to register topics by reference (e.g. app id), this reference can be used with the unsubscribe api**
10. **Performance improvements**
11. **General bug fixes**

**Commit 1**  
Topic registration:

- always subscribe to the broker to return retained messages on subscription
- re-subscribe to all previously registered topics on connection of the broker/mqtt-client (keep topic registry alive)
- made some calls async and actually wait for the result before continuing + fixed some async handling of promises
- extended the TopicArray with seperate methods for api & trigger topics

**Commit 2**

- prevent topic unsubscription if its used by another registration (api vs trigger)

**Commit 3**  
Flow card triggers:

- prevent destruction of the full topics array, causing all api connections being lost
- subscribe to all flow card trigger topics on initialisation
- on trigger card change (flow card config): unsubscribe from removed topics & subscribe to newly added topics
- await the Homey trigger call
- check for api topic match before forwarding the message to the realtime api

**Commit 4**  
pre-check to prevent uneccesairy calls to the Homey trigger system  
prevents disabling of random flows not even listening to these topics (Homey BUG?)…  
this is also a performance boost, since the Homey trigger system won’t be called for all api topics  
the small downside is the duplicate topic matching, if there is a match on a trigger topic

**Commit 5**  
(added missing file ‘Trigger.js’ for commit 3

**Commit 6**  
On change of app settings:

- prevent destruction of the full topicsArray resulting in lost api connections
- re-connect to the broker to trigger subscription al all registered topics (instead of the trigger topics only)
- await topic unsubscription before setting up the new client

**Commit 7**  
added unsubscribe api

**Commit 8**  
Introduced a TriggerQueue to handle the rate limiting of flow card triggers and prevent disabling of flows

**Commit 9**  
Added broker online/offline flow card triggers

**Commit 10**  
Added flow card action to send an empty message to be able to remove retained messages from the broker

**Commit 11**  
Introduced a TopicsRegistry to register topics by reference (e.g. app id). The unsubscribe api can only be called for topics with the reference provided during topic subscription. This prevents unsubscription of topics used by other apps/processes.  
Also optimized the topic matching by using a topic map (instead of array lookup).

---

<div class="post-metadata">

### Author: ![HarriedeGroot](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/harriedegroot/32/56160_2.png) [@HarriedeGroot](https://community.homey.app/u/HarriedeGroot)
#### Post date: [April 16, 2021, 7:06pm UTC](https://community.homey.app/t/strange-mqtt-client-behavior/45105/58 "2021-04-16T19:06:45Z")

</div>

I’ve got this running for a few days now with several thousands of (retained) messages. Also have a test flow with a trigger on topic ‘#’, which forwards the data to another mqtt topic. Non of the flows has been disabled yet…

---

<div class="post-metadata">

### Author: ![scanno](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/scanno/32/8358_2.png) [@scanno](https://community.homey.app/u/scanno)
#### Post date: [April 16, 2021, 8:06pm UTC](https://community.homey.app/t/strange-mqtt-client-behavior/45105/59 "2021-04-16T20:06:34Z")

</div>

As soon as I can find some spare time, I will have a look at the pull request. Work and thesis consume all my time right now.

Thanks for the effort.

---

<div class="post-metadata">

### Author: ![HarriedeGroot](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/harriedegroot/32/56160_2.png) [@HarriedeGroot](https://community.homey.app/u/HarriedeGroot)
#### Post date: [April 16, 2021, 8:10pm UTC](https://community.homey.app/t/strange-mqtt-client-behavior/45105/60 "2021-04-16T20:10:22Z")

</div>

@scanno Could it be an option to push this to the test channel?

[Previous page](https://community.homey.app/t/strange-mqtt-client-behavior/45105.md?page=2)

[Next page](https://community.homey.app/t/strange-mqtt-client-behavior/45105.md?page=4)
