search

shining-man / bsc_fw

Firmware battery safety controller (BSC)
MIT License
81 stars 15 forks source link

Erneutes Senden aller Datenpunkte bei MQTT reconnect #120

Open tueftler0 opened 1 month ago

tueftler0 commented 1 month ago

Normalerweise wurde bisher alle ca 30s alle Topics via MQTT übertragen, auch wenn sich keine Wertänderung ergab (glaube ich zumindest). Mir fehlen derzeit die zyklischen Trigger-Übertragungen seid dem neuen Release. In der RestAPI sind sie sichtbar.

shining-man commented 1 month ago

Die Trigger wurde auch vorher nicht zyklisch übertragen. Hier hat sich nichts geänert. Die Trigger werden nur bei einer Änderung gesendet.

tueftler0 commented 1 month ago

Danke fürs Feedback. Okay, dann wäre es toll, wenn man dies in Zukunft mal mit integrieren würde. ~HomeAssistant beispielsweise hätte gerne alle x Minuten eine Message, ansonsten gehen die States auf Unbekannt:~ Ohne jemals die Trigger einmal angesprochen zu haben, werden diese bis dahin als "unavailable" dargestellt: image

shining-man commented 1 month ago

Ansich finde ich es nicht schön etwas einzubauen nur um irgendwelche System mit etwas zu befriedigen, was sie morgen vielleicht schon wieder ändern. Macht es wirklich Sinn Nachrichten zyklisch zu versenden, auch wenn sie sich nicht geändert haben? Wäre es nicht Sinnvoller man würde den QoS erhöhen? Ansich kommt es auf die 10 Nachrichten nicht an, aber ich wollte genrell den Traffic senken und andere Werte auch nur bei Änderung senden, das würde dann vmtl. an mehr Stellen zu diesem Verhalten führen. Gut, dass wir auf das Thema zu sprechen kommen.

tueftler0 commented 1 month ago

Ich kann Dich da schon verstehen. Jedoch kann es ja auch gut sein, dass der MQTT-Broker einmal neu gestartet wird oder ein Repeater ausfällt (usw) und in dieser Zeit ein Trigger oder sonstiger Wert sich ändert. Das würde dann bis zur nächsten Änderung nie auffallen. Daher finde ich es schon sinnvoll, wenn man alle Werte alle 30 Sekunden oder so einmal rüber sendet. Auch könnte man in dieser Funktion das HA-Discovery integrieren, da hier ja scheinbar beim Anlegen immer alle via MQTT möglichen Daten vorliegen müssen. Das hatte glaub mal NSC heraus gefunden.

shining-man commented 1 month ago

HA-Discovery wird vmtl. nie den Weg in den BSC finden. Das ist einfach zu viel Overhead. Einen ausfallenden Repeater könnten man mit QoS 1 auch feststellen, denn dann muss die Nachricht mindestens einmal zugestellt werden. Zum Neustart: Es macht mehr Sinn alle Nachrichten erneut zusenden, wenn es zu einem reconnect kommt.

Ansich möchte ich die Flut der Nachrichten etwas ein dämmen. Ich möchte auf ein dynamisches Konzept umsteigen, bei dem es keine festen Sendezeiten mehr gibt, sondern nur bei Änderung und Gewichtung der Werte gesendet wird. Wenn das BPN einmal kommen sollte, dann gibt es pro BMS fast 40 Temperaturwerte mehr. Wenn ich die alle zyklisch sende, dann gibt es keinen 30s Intervall mehr, sondern ich muss langsamer werden. Daher nehme ich jetzt ungern Werte in das zyklische Senden auf.

tueftler0 commented 1 month ago

HA-Discovery könnte man ja auch einmalig über das Webfrontend, oder bei jedem Neustart triggern - Aber nun ja erst einmal egal ;)

QoS 1 wäre definitiv sinnvoll, wenn ein Senden aller Werte umgangen werden soll. Alle Werte nur bei einem Reconnect senden wäre schon eine Lösung. Was man genau gegen dieses "Unbekannt" machen kann werde ich mal nachforschen. Blöd ist eben, wenn man nach true/false triggert und dann ein unknown bekommt :)

tueftler0 commented 1 month ago

Korrektur der Aussage: HomeAssistant führt den Trigger (Sensor Component) als "unavailable" wenn bis zu dem Zeitpunkt über MQTT kein Wert übermittelt wurde. Grundsätzlich okay, wenn der State ja nicht sicher anzunehmen ist. Daher ist Deine Idee mit dem Senden aller Datenpunkte bei reconnect wahrscheinlich passend.

Ein Timeout für den Sensor ist zwar konfigurierbar, aber standardmäßig deaktiv.