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:
Die Topic ist: miflora/C4:7C:8D:6B:F6:65/temperature
In Homey habe ich diesen Flow angelegt:
Der Flow wird aber trotz Topic-Änderung nicht ausgelöst.
Funktionieren solche Flows bei euch? Muss ich den Flow anders definieren?
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…
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 
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:
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?
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…
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.
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.
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 
Please let me know if app restarts are still needed with this version of the client.
