Support: MQTT

[Kitmgue]

Ich möchte hier mal einhaken, weil ich die aktuelle (2.1.8) Implementation nämlich etwas ungeschickt finde.
Und zwar wird der SoC nicht aktualisiert, sobald das Topic neu geschrieben wurde, sondern tatsächlich erst, wenn die definierte Zeit für "Während der Ladung" bzw. "Ohne laufende Ladung" abgelaufen ist. Alternativ kann man auch auf der UI das Neuladen-Symbol klicken.
Sinnvoller wäre es, meiner Ansicht nach, wenn openWB tatsächlich das entsprechende Topic subscribed und sich dann automatisch aktualisiert.
So verwirrt es nämlich ziemlich.

Und cool wäre es, wenn beim MQTT-SoC, analog zum Manuell-SoC, auch der SoC berechnet wird. Wenn nämlich mal das zuliefernde System ausfällt (aka Docker Container aus irgendwelchen Gründen keinen Datenabruf mehr hat), dann steht sonst für immer der einmal gelieferte SoC dort - obwohl vielleicht schon 20kW geladen wurden.

[rleidner]

Ich möchte hier mal einhaken, weil ich die aktuelle (2.1.8) Implementation nämlich etwas ungeschickt finde.
Und zwar wird der SoC nicht aktualisiert, sobald das Topic neu geschrieben wurde, sondern tatsächlich erst, wenn die definierte Zeit für "Während der Ladung" bzw. "Ohne laufende Ladung" abgelaufen ist. Alternativ kann man auch auf der UI das Neuladen-Symbol klicken.
Sinnvoller wäre es, meiner Ansicht nach, wenn openWB tatsächlich das entsprechende Topic subscribed und sich dann automatisch aktualisiert.
So verwirrt es nämlich ziemlich.

Du kannst das Neuladen via MQTT erzwingen indem Du Folgendes versuchst nach dem Senden des SoC/Range/Timestamp, z.B. für vehicle-id 4:

Code: Alles auswählen

mosquitto_pub -t openWB/set/vehicle/4/get/force_soc_update -m true

Natürlich mit Deinem MQTT-API.

[Kitmgue]

Du kannst das Neuladen via MQTT erzwingen indem Du Folgendes versuchst nach dem Senden des SoC/Range/Timestamp, z.B. für vehicle-id 4:

Code: Alles auswählen

mosquitto_pub -t openWB/set/vehicle/4/get/force_soc_update -m true

Natürlich mit Deinem MQTT-API.

Sinnvoller bzw. MQTT-like wäre aber, wenn neue Werte im Topic direkt verarbeitet werden.
Gibt ja keinen Grund, weshalb man die definierten Zeiten berücksichtigt. Die machen Sinn, wenn man meine API o.ä. abruft.

So fande ich es wahnsinnig irritierend.
Ich schreibe nach: openWB/set/mqtt/vehicle/1/get/soc
Von dort wird es umgeschrieben nach: openWB/vehicle/1/get/soc (mit Retained)
Und wird dann erst nach x Minuten abgerufen.
Weil das für mich nicht klar war, habe ich erstmal 10 Minuten (bei mir für "Ohne laufende Ladung" eingestellt) nach einem Fehler in der Konfiguration gesucht, obwohl alles richtig ausgesehen hat.
Wenn man sonst mit MQTT arbeitet, dann erwartet man das anders.
Zumindest sollte man in der Konfiguration einen Hinweis ergänzen, dass die Zeiten trotzdem gelten.

[caran17]

Danke Kitmgue, dass du das Thema ansprichst. Auch mich hat es verwirrt, dass ich "trotz" MQTT ein Intervall eingeben muss.

Mit der Erklärung kann ich damit aber umgehen. Ich habe einfach die kleinstmöglichen Werte eingetragen, um möglichst wenig Delay zu haben.

Aber die Implementierung scheint mir schon unglücklich zu sein, wobei ich einschränkend sagen muss, dass es natürlich möglich ist, dass es dafür Gründe gibt, die ich nicht kenne.

Aktuell ist es aber zum einen für den Anwender sehr verwirrend und es führt dazu, dass häufig gepulled wird, obwohl keine neuen Werte vorhanden sind und wenn neue Werte vorhanden sind, kommen sie verzögert an. mosquitto_pub bedeutet zusätzliche Komplexität für den Verwender, die ich an der Stelle vermeiden möchte.

[rleidner]

mosquitto_pub bedeutet zusätzliche Komplexität für den Verwender, die ich an der Stelle vermeiden möchte.

mosquitto_pub war hier nur als Beispiel gedacht. Ich verwende mosquitto_pub hier zum Testen von EV-SoC-Modulen und habe es der Einfachheit halber mal so geposted.
Und ja, es ist keine ideale Lösung sondern ein Workaround für die, die aktuell mit dem Warten unzufrieden sind und das selbst lösen möchten.
Es ersetzt das manuelle Betätigen des SoC-Refresh Button im UI.

Das geht auch ohne mosquitto_pub mit derselben Methode mit der SoC/Range/Timestamp zur openWB gepublished werden.