# MQTT Client Topic-Trigger? **URL:** \ **Category:** Apps (DE)\ **Created:** [April 15, 2021, 4:19pm UTC](https://community.homey.app/t/mqtt-client-topic-trigger/46284 "2021-04-15T16:19:27Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![RonnyW](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/ronnyw/32/10879_2.png) [@RonnyW](https://community.homey.app/u/RonnyW)\ **Post date:** [April 15, 2021, 4:19pm UTC](https://community.homey.app/t/mqtt-client-topic-trigger/46284/1 "2021-04-15T16:19:27Z")
Ich versuche gerade, meine MiFlora-Topics vom MQTT-Broker als Flow-Event zu verwenden. Das funktioniert aber nicht so wie gewünscht. Im Broker wird diese Topic aktualisiert: ![grafik](https://us1.discourse-cdn.com/flex025/uploads/athom/original/3X/9/3/93547fa419516e43b6262852dd3c2f0a195f0915.png) Die Topic ist: miflora/C4:7C:8D:6B:F6:65/temperature In Homey habe ich diesen Flow angelegt: ![grafik](https://us1.discourse-cdn.com/flex025/uploads/athom/original/3X/5/c/5cefb2190faa7b5b8f55793251a2c6615053b9a4.png) Der Flow wird aber trotz Topic-Änderung nicht ausgelöst. Funktionieren solche Flows bei euch? Muss ich den Flow anders definieren? ---
**Author:** ![RonnyW](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/ronnyw/32/10879_2.png) [@RonnyW](https://community.homey.app/u/RonnyW)\ **Post date:** [April 15, 2021, 7:17pm UTC](https://community.homey.app/t/mqtt-client-topic-trigger/46284/2 "2021-04-15T19:17:23Z")
Ich habe die MQTT-Client-App neu gestartet und danach wurden die Werte der Topic übernommen. Wenn man das weiß ist das ja prinzipiell ok. Etwas irreführend ist das schon. Vielleicht ermittelt die App aber auch nur beim Start die registrierten Flows/Topics und registriert diese beim Broker… ---
**Author:** ![RonnyW](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/ronnyw/32/10879_2.png) [@RonnyW](https://community.homey.app/u/RonnyW)\ **Post date:** [April 16, 2021, 5:00am UTC](https://community.homey.app/t/mqtt-client-topic-trigger/46284/3 "2021-04-16T05:00:03Z")
Ich muss euch warnen, diese Topic-Trigger-Flows zu verwenden, falls ihr den MQTT-Hub verwendet und dadurch ziemlich viel MQTT-Traffic habt. Bei jedem MQTT-Update (d.h. für alle Topics!) scheinen alle Flows des MQTT-Client gestartet zu werden. Diese prüfen dann zwar die Auslösebedingung (Topic), das ändert aber nichts daran, dass die Systemlast damit ziemlich durch die Decke geht Mit 5 Trigger-Flows lief das noch ganz gut. Mit 15 war Homey nicht mehr bedienbar. Die Auslastung lag bei 1500% (falls ich mal in die Einstellungen kam). Ich muss also doch die MQTT-Elmente über den Umweg der HomeAssistant-App zum Homey bringen, oder vom ESP32 per Webhook ☹ ---
**Author:** ![Undertaker](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/undertaker/32/53278_2.png) [@Undertaker](https://community.homey.app/u/Undertaker)\ **Post date:** [April 16, 2021, 5:50am UTC](https://community.homey.app/t/mqtt-client-topic-trigger/46284/4 "2021-04-16T05:50:42Z")
Ich habe schon ähnliche Erfahrungen mit der Systemlast gemacht. Letztlich betreibe ich das Ganze genau so, wie von dir beschrieben. Home Assistant bekommt aktuell 412 Geräte von Homey per MQTT zum Fressen. ![Screenshot_20210416-074154_Chrome](https://us1.discourse-cdn.com/flex025/uploads/athom/original/3X/4/5/4590bc3d949977cd8b2fb3258437e6e0951ac24c.jpeg) Umgekehrt sind es etwa 80 Nodes, die Homey vom HA bekommt. Der MQTT Server läuft auf Homey Nr. 2, während Homey Nr. 1 für die Flows zuständig ist. Geteiltes Leid ist halbes Leid. Im Schnitt sind beide Homeys bei ca. 70-90% Systemlast. Wenn viele Flows zur gleichen Zeit auslösen, ist der App aber anzumerken, dass sie deutlich träger wird. ---
**Author:** ![RonnyW](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/ronnyw/32/10879_2.png) [@RonnyW](https://community.homey.app/u/RonnyW)\ **Post date:** [April 16, 2021, 7:17am UTC](https://community.homey.app/t/mqtt-client-topic-trigger/46284/5 "2021-04-16T07:17:52Z")
Ich habe nun versucht, die MiFlora Sensoren über die HA App nach Homey zu bringen. Erstmal muss man wie blöd die nicht gewünschten Sensoren abhaken. Danach kommt der Fehlet “could not find the pair session”. Geht das noch beib dir? ---
**Author:** ![Undertaker](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/undertaker/32/53278_2.png) [@Undertaker](https://community.homey.app/u/Undertaker)\ **Post date:** [April 16, 2021, 7:33am UTC](https://community.homey.app/t/mqtt-client-topic-trigger/46284/6 "2021-04-16T07:33:11Z")
Ich hab die Mi direkt an Homey. Die Reichweite ist gerade so ausreichend. Hast du die hauseigene App vorher geschlossen? Die Dinger können immer nur eine Bluetooth Verbindung aufbauen und blockieren, wenn die Flower Care App noch läuft. Ansonsten mal Neustart von HA und dann von Homey. Ja, das Abhaken der nicht gewünschten Geräte ist nervig. Anders herum wäre besser. ---
**Author:** ![RonnyW](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/ronnyw/32/10879_2.png) [@RonnyW](https://community.homey.app/u/RonnyW)\ **Post date:** [April 16, 2021, 8:04am UTC](https://community.homey.app/t/mqtt-client-topic-trigger/46284/7 "2021-04-16T08:04:35Z")
Die MIs hängen am ESP. Die Xiaomi-App ist deinstalliert. Das ging auch parallel, solange beide nicht im selben Moment abfragen. Homey ist neu gestartet, die HA App damit auch. Vielleicht probiere ich das mal mit Webhooks…Sehr lästig. Ich dachte, die Mqtt-Topics bekomme ich einfacher in den Homey… ---
**Author:** ![RonnyW](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/ronnyw/32/10879_2.png) [@RonnyW](https://community.homey.app/u/RonnyW)\ **Post date:** [April 16, 2021, 10:55am UTC](https://community.homey.app/t/mqtt-client-topic-trigger/46284/8 "2021-04-16T10:55:56Z")
Über die WebApp konnte ich die Sensoren nach Homey übernehmen. In der AndroidApp ist die Auswahl-Liste mittem im Wegklicken immer wieder verschwunden… Jetzt fehlt nur noch ein Flow-Event für die HA-Devices in Homey, um auf Wertänderungen reagieren zu können. Der Entwickler scheint nichts mehr daran zu machen. Die Anfrage nach deaktivierten Sensoren in der Auswahlliste ist damnals unbeantwortet geblieben… ---
**Author:** ![RonnyW](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/ronnyw/32/10879_2.png) [@RonnyW](https://community.homey.app/u/RonnyW)\ **Post date:** [April 18, 2021, 9:37am UTC](https://community.homey.app/t/mqtt-client-topic-trigger/46284/9 "2021-04-18T09:37:32Z")
Kurzes Update dazu… Webhooks habe ich mit dem ESP nur so halb hinbekommen. Die http-Requests liefern teilweise nur einen Verbindungsfehler von Homey. Das muss aber an der Implementierung der Bibliothen liegen (HTTPClient.h) - oder man muss selbst noch ein Retry bei Fehlern dazubauen. Im Browser laufen die Webhooks fehlerfrei. Ich habe das Experiment Webhooks mit ESP vorerst aufgegeben und bleibe bei MQTT. Die Daten werden dann aus HomeAssistant über die HomeAssistant-App nach Homey übernommen. Da die dafür angelegten Sensor-Devices leider kein Flow-Event bei Änderung besitzen, musste ich noch zeitgesteuert per Flow die Werte in einen virtuellen Sensor übernehmen. Über diesen virtuellen Sensor kann man dann auch per Flow auf Änderungen reagieren. Das ist zwar alles etwas umständlich, funktioniert aber. Schade, dass die MQTT-Client-App anscheinend auf alle MQTT-Nachrichten reagiert und Homey lahmlegt, statt nur die Topics zu abonieren, die auch in den Flows verwendet werden. Das würde die MQTT-Abindung eigener Topics deutlich verbessern. ---
**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 18, 2021, 9:58am UTC](https://community.homey.app/t/mqtt-client-topic-trigger/46284/10 "2021-04-18T09:58:14Z")
> [@RonnyW](#): > > Schade, dass die MQTT-Client-App anscheinend auf alle MQTT-Nachrichten reagiert und Homey lahmlegt, statt nur die Topics zu abonieren, die auch in den Flows verwendet werden. Das würde die MQTT-Abindung eigener Topics deutlich verbessern. [sorry English…] Exactly my thoughts. Yesterday the [test channel](https://homey.app/nl-nl/app/nl.scanno.mqtt/MQTT-Client/test/) is updated with a new version with some improvements: > **[MQTT Client](https://homey.app/nl-nl/app/nl.scanno.mqtt/MQTT-Client/)** > > Abonneer op MQTT topics I’m curious about your findings! The details about what has been changed / improvements can be found here: > > > 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 of 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). > > \*\*Commit 12\*\* > \- Remove messages from the trigger queue when a topic is unsubscribed > \- Added failsafe for the TriggerQueue size. Allow homey to disable the flow (by rate limiting) if the number of messages in the trigger queue exceeds the max allowed number of messages. > \- Correctly handle topic subscriptions after flow card triger changes. > \- updated the README with examples of usage of the reference and unsubscribing of topics > > \*\*Commit 13\*\* > \- merged api changes from commit: https://github.com/scanno/nl.scanno.mqtt/commit/02c3f0f816dd70475ebe2d848cd5012fb5034f2b > \- added response to unsubscribe api > \- version bump to 3.x ---
**Author:** ![RonnyW](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/ronnyw/32/10879_2.png) [@RonnyW](https://community.homey.app/u/RonnyW)\ **Post date:** [April 18, 2021, 10:10am UTC](https://community.homey.app/t/mqtt-client-topic-trigger/46284/11 "2021-04-18T10:10:23Z")
Hello, thanks for your fast answer. I’ll give it a try and report back 👍 So my experiance was right, that the client was acting on ALL topic changes of MQTT broker? And now only it’s only reacting on topics which are used as flow trigger? ---
**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 18, 2021, 10:15am UTC](https://community.homey.app/t/mqtt-client-topic-trigger/46284/12 "2021-04-18T10:15:45Z")
It’s a bit more complicated, but the latest version of the MQTT Client does some additional checks on how to handle the messages. Should the Homey flow trigger be called and/or forward the messages to external apps listening for them, or skip the message completely if there are no listeners at all. Instead of just forwarding all messages to both. ---
**Author:** ![RonnyW](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/ronnyw/32/10879_2.png) [@RonnyW](https://community.homey.app/u/RonnyW)\ **Post date:** [April 18, 2021, 1:31pm UTC](https://community.homey.app/t/mqtt-client-topic-trigger/46284/13 "2021-04-18T13:31:50Z")
I have some additional questions for a test… - If I create a flow for a topic event, ist it subscribed directly or only after app restart? Depending on my tests with timeline-output, new trigger flows are not active/started by default, onlky after app restart. Is it correct? - If I deactivate a flow, has it direct impact in performance? Is it unsubscribed and MQTT changes don’t trigger the app? Am I right, the the flow is not started, but the topic is still subscribed by MQTT broker? ---
**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 18, 2021, 1:59pm UTC](https://community.homey.app/t/mqtt-client-topic-trigger/46284/14 "2021-04-18T13:59:02Z")
1. Hopefully app restarts should be something of the past…topics are (un)subscribed immediately and retained messages should be send right away. 2. Started a discussion for this on the developers slack channel yesterday. Currently it’s not possible to detect the enabling/disabling of flows within apps. ---
**Author:** ![RonnyW](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/ronnyw/32/10879_2.png) [@RonnyW](https://community.homey.app/u/RonnyW)\ **Post date:** [April 18, 2021, 5:41pm UTC](https://community.homey.app/t/mqtt-client-topic-trigger/46284/15 "2021-04-18T17:41:02Z")
I have 15 topic trigger active now. System load seems to keep stable. In the past, the 15 trigger got the system load up to 1500%. So many thanks for this improvement. The FlowTrigger for Broker connect/disconnect is very useful, too - to start broadcast of MQTT-Hub after a reconnect. ---
**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 18, 2021, 5:53pm UTC](https://community.homey.app/t/mqtt-client-topic-trigger/46284/16 "2021-04-18T17:53:15Z")
Thanks for your feedback! ---
**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 18, 2021, 5:56pm UTC](https://community.homey.app/t/mqtt-client-topic-trigger/46284/17 "2021-04-18T17:56:07Z")
Ow and a broadcast for the Hub shouldn’t be necessary either. Messages are retained on the broker since the last versions of the MQTT Hub and when the mqtt client connects to the hub, all needed messages should be broadcasted automatically. ---
**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 18, 2021, 5:57pm UTC](https://community.homey.app/t/mqtt-client-topic-trigger/46284/18 "2021-04-18T17:57:58Z")
And…the MQTT Client keeps track off all registered topics now. So on a reconnect of the broker all previous subscriptions are restored. ---
**Author:** ![RonnyW](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/ronnyw/32/10879_2.png) [@RonnyW](https://community.homey.app/u/RonnyW)\ **Post date:** [April 18, 2021, 6:04pm UTC](https://community.homey.app/t/mqtt-client-topic-trigger/46284/19 "2021-04-18T18:04:32Z")
I have the situation that the connection between HomeAssistant and homey gets broken after a disconnect. In this case the values from Homey are still sent to HA, but changes in HA (changing a switch in HA dashboard) are not reported back to Homey. If this appears, only a new broadcast will reactivate the 2way communication. Sometimes the Hub must be restartet, too. I only found disconnects from Broker or a MQTT-Client restart as possible reasons. I didn’t found the real technical reasons, just arranged with the broadcast 🙂 ---
**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 18, 2021, 6:05pm UTC](https://community.homey.app/t/mqtt-client-topic-trigger/46284/20 "2021-04-18T18:05:57Z")
Please let me know if app restarts are still needed with this version of the client. [Next page](https://community.homey.app/t/mqtt-client-topic-trigger/46284.md?page=2)