MQTT Client Topic-Trigger?

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 :frowning:

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.

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.

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?

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.

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


Ü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


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.

[sorry English
]
Exactly my thoughts. Yesterday the test channel is updated with a new version with some improvements:

I’m curious about your findings!

The details about what has been changed / improvements can be found here:

1 Like

Hello, thanks for your fast answer. I’ll give it a try and report back :+1:

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?

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.

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?
  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.

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.

1 Like

Thanks for your feedback!

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.

And
the MQTT Client keeps track off all registered topics now. So on a reconnect of the broker all previous subscriptions are restored.

1 Like

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 :slight_smile:

Please let me know if app restarts are still needed with this version of the client.

In the current stable version of the MQTT Client all topic subscriptions from the API (that’s external apps like the Hub) are lost if the broker connection is lost. On reconnect only flow trigger topics were re-subscribed. This is solved in the test version. Now all previous topic subscriptions are reconnected, including the subscriptions from the API.

Thanks! I will observe it the next days.