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.
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.
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?
Hopefully app restarts should be something of the pastâŠtopics are (un)subscribed immediately and retained messages should be send right away.
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.
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.
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
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.
