openWB Forum

skyflying hat geschrieben: ↑Do Jul 22, 2021 7:50 am Ich kann das Verhalten von "Mading" bestätigen. Das direkte schreiben der Werte über den direkten Weg geht sowie auch der Weg über den Pfad "set/....", wobei es auch nicht immer greift. Den Hintergrund konnte ich noch nicht rausbekommen.

Weil mqtt nur ein Protokoll ist...eine Validierung der Daten findet auf der Ebene nicht statt.
Dieses Muster, mit ".../set/..." für das publish ist bei Steuerungen von Systemen über mqtt quasi Standard.
Die openWB abonniert (subscribe) auf dem Broker alles mit openWB/set/#.
Wenn also ein neuer Wert von Aussen kommt, wird dieser gelesen, analysiert und nur wenn kein Fehler vorliegt (zB PV-Erzeugung kleiner NULL wäre so ein Fall, der fachlich keinen Sinn ergibt), wird der Wert dann in der openWB selbst verarbeitet und allen anderen Abonnenten wieder publiziert auf dem "lese-Topic", ohne ".../set".

Wenn dieses Schema noch nicht für ein Topic funktioniert, dann weil die interne "Verdrahtung" in der openWb (noch) fehlt....mqtt ist nur die Schnittstelle für den Austausch der Informationen.

Dann stimmt etwas in der Implementierung nicht wenn der global/ChargeMode geschrieben werden kann?! Habe ich es richtig gelesen, dass das oWB Web UI auch auf mqtt setzt, um Kofigurationsänderungen zu setzten? Wenn ja, wie setzt das WebUI den ChargeMode oder SubchargeMode?

hominidae hat geschrieben: ↑Do Jul 22, 2021 10:33 am

skyflying hat geschrieben: ↑Do Jul 22, 2021 7:50 am Ich kann das Verhalten von "Mading" bestätigen. Das direkte schreiben der Werte über den direkten Weg geht sowie auch der Weg über den Pfad "set/....", wobei es auch nicht immer greift. Den Hintergrund konnte ich noch nicht rausbekommen.

Weil mqtt nur ein Protokoll ist...eine Validierung der Daten findet auf der Ebene nicht statt.
Dieses Muster, mit ".../set/..." für das publish ist bei Steuerungen von Systemen über mqtt quasi Standard.
Die openWB abonniert (subscribe) auf dem Broker alles mit openWB/set/#.
Wenn also ein neuer Wert von Aussen kommt, wird dieser gelesen, analysiert und nur wenn kein Fehler vorliegt (zB PV-Erzeugung kleiner NULL wäre so ein Fall, der fachlich keinen Sinn ergibt), wird der Wert dann in der openWB selbst verarbeitet und allen anderen Abonnenten wieder publiziert auf dem "lese-Topic", ohne ".../set".

Wenn dieses Schema noch nicht für ein Topic funktioniert, dann weil die interne "Verdrahtung" in der openWb (noch) fehlt....mqtt ist nur die Schnittstelle für den Austausch der Informationen.

Ja so verstehe ich auch MQTT und kann mich "mading" nur anschließen, dass hier in der Implementierung ein Fehler vorliegen muss ,wenn ich in der Lage bin in die openWB Datenbasis direkt schreiben zu können. Liegt damit nicht am MQTT.

gibt es einen Tipp, wie das Thema am besten an die Entwicklung gegeben werden kann? Reicht es hier mit unserem thread oder wäre ein Support Ticket der sinnvolle Weg, damit es ins Backlog kommt (bzw. erstmal transparent gemacht ist)?

Es liegt in dem Sinne kein Fehler vor. Einziger Punkt ist, dass der schreibende Zugriff nicht beschränkt ist.

LutzB hat geschrieben: ↑Do Jul 22, 2021 11:36 am Es liegt in dem Sinne kein Fehler vor. Einziger Punkt ist, dass der schreibende Zugriff nicht beschränkt ist.

M.E. stimmt das nicht ganz, da der ChargeMode und SubchargeMode in /set ja nicht bis zur owb durch schlägt

...aber das ist ja eben kein Fehler, sondern ein (noch) nicht implementiertes Feature.
Das Verfügbarkeit von Features in der (mqtt-)API und im UI nicht immer synchron sind, ist ja "normal".

Also fehlt ein Feature-Request, oder Warten auf 2.0 oder ein "Mitmach-Eingriff" per Pull-Request, für den der es selber macht/machen will/kann.

mading hat geschrieben: ↑Do Jul 22, 2021 12:01 pm

LutzB hat geschrieben: ↑Do Jul 22, 2021 11:36 am Es liegt in dem Sinne kein Fehler vor. Einziger Punkt ist, dass der schreibende Zugriff nicht beschränkt ist.

M.E. stimmt das nicht ganz, da der ChargeMode und SubchargeMode in /set ja nicht bis zur owb durch schlägt

Dann verrate mir mal, wie die Themes den setzen, wenn es nicht per MQTT gehen sollte.

Das ist ja meine Frage

hominidae hat geschrieben: ↑Do Jul 22, 2021 12:10 pm ...aber das ist ja eben kein Fehler, sondern ein (noch) nicht implementiertes Feature.
Das Verfügbarkeit von Features in der (mqtt-)API und im UI nicht immer synchron sind, ist ja "normal".

Also fehlt ein Feature-Request, oder Warten auf 2.0 oder ein "Mitmach-Eingriff" per Pull-Request, für den der es selber macht/machen will/kann.

ein Schritt weiter bin leider kein Entwickler. Lässt sich das als FR irgendwo einkippen? Die Doku zu mqtt unter Wissenssammlung vermittelt eben dass /set/ChargeMode und SubchargeMode implementiert ist. Nutzt das UI auch mqtt?

Da es evtl. etwas dauert bis SubChargeMode nutzbar ist hier mein aktueller Stand: mittlerweile habe ich ein Blockly was bzgl. OWB ein/ ausschalten sowie Lademodus setzen gut funktioniert. Das funktioniert auch bidirektional (entweder wird die Einstellung über vis gesetzt oder über das OWB UI).

Da ich eine PV auf dem Dach habe, werde ich (Auto noch nicht da) ohnehin Min+PV oder PV hauptsächlich nutzen, daher ist der Sofortlademodus für mich wohl eher uninteressant. Wäre toll gewesen, wenns mit dem SubChargeMode auch geklappt hätte aber man kann nicht alles haben . Reset Sofortladen funktioniert auch nicht.

Meine Vis Funktioniert soweit damit gut. Lademodus wird nur angezeigt, wenn der ChargePoint an ist, Sublademodus auch nur wenn Sofortladen an ist.
Im Anhang der view. Auf meinem Hauptview lasse ich mir dann noch wichtige Daten anzeigen wie SoC, ist das Auto eingesteckt?, lädt es? etc.

Für das Blockly welches die Werte für die OWB setzt bzw. ausliest, sind folgende Datenpunkte notwendig (ggf. bzgl. Pfad auch im Blockly anzupassen Die vis sieht dann so aus: Wer das bei sich umsetzen möchte und Fragen hat, kann sich gerne melden.