stop_charging / start_charging via MQTT in Node-Red

[PatrickM]

Hallo zusammen,

beim Anbinden der Warp2 an meine Hausautomation, die ich hauptsächlich in Node-Red realisiert habe, bin ich auf ein Problem gestoßen:

Laut der Warp2-API-Dokumentation muss beim Senden von stop_charging / start_charging via MQTT eine leere Payload (null) übergeben werden.

Über den in Node-Red standardmäßig integrierten "MQTT out node" habe ich keine Möglichkeit gefunden, dass der Start- oder Stopp-Befehl angenommen wird. Bei Übergabe von 

msg.payload=null;

wird im Ereignislog der Warp2 "MQTT: Failed to update evse/start_charging from MQTT payload: Failed to deserialize string: EmptyInput" angezeigt.

Bei Übergabe von

msg.payload={};

wird "MQTT: Failed to update evse/start_charging from MQTT payload: JSON null node was not null" angezeigt.

Ich habe noch diverse weitere Kombinationen ausprobiert, aber das Ergebnis war immer einer der o.g. Fehler. Nach etwas Suche habe ich vermutlich die Ursache gefunden, der Node-Red-MQTT-Node nutzt eine an ihn geschicke Payload=null zum Löschen gespeicherter Topics (Link).

Ich habe dieses Problem nun umgangen indem ich einen anderen MQTT-Node (node-red-contrib-mqtt-plus) nutze, wenn ich an diesen 

msg.payload=null;

sende, funktioniert die Steuerung der Box einwandfrei.

Vielleicht hilft dieser Beitrag dem ein oder anderen in der gleichen Situation etwas Zeit zu sparen.

Und außerdem wäre es ja vielleicht möglich das Interface auf Wallbox-Seite hinsichtlich der Akzeptanz von Start-/Stopp-Befehlen etwas toleranter zu gestalten. :-) Ich nutze bei Node-Red gerne erst die Bordmittel, bevor ich zusätzliche Nodes bemühe :-)

Viele Grüße

Patrick

[rtrbt]

Ich habe dafür ein Issue aufgemacht, das Problem kam ja schon ein paar Mal auf: https://github.com/Tinkerforge/esp32-firmware/issues/77

Frage dazu: Wäre dir geholfen, wenn zusätzlich ein leeres Objekt erlaubt ist? Oder ist das auch schwierig und man müsste eher z.B. false auf Top-Level erlauben?

[PatrickM]

vor 11 Stunden schrieb rtrbt:

Frage dazu: Wäre dir geholfen, wenn zusätzlich ein leeres Objekt erlaubt ist? Oder ist das auch schwierig und man müsste eher z.B. false auf Top-Level erlauben?

Ich bin mir nicht sicher, aber ich vermute, dass dies auch fehlschlagen wird. Was ich gefunden habe, wird eine leere Payload wie null behandelt, und auch zum Löschen der retained values genutzt. Ein true/false sollte auf jeden Fall funktionieren.

[Lenny]

Gibt es zu den Thema etwas neues? In der aktuellen Firmware aus Januar steht nichts.

Payload true/false oder on/Off wäre großartig. Sonst muss man zu sehr mit json pfuschen.

 

Das problem bei node ist, dass die leere payload ein Array ist und somit wiederum nicht null. 

 

bearbeitet January 26, 2022 at 19:00 von Lenny

[rtrbt]

Bisher gibt es noch nichts neues. Ich will nicht versprechen, dass das in die nächste Firmware-Version mit reinkommt, aber es sollte auch nicht mehr Monate entfernt sein, das zu implementieren. Ich gebe Bescheid ;)

[bs.]

Ich habe den node http request methode: PUT, url: http://warp2.fritz.box/evse/start_charging mit payload "null" genutzt und bin erst danach auf diesen Beitrag gestossen.

[dg3fbl]

Ich bin heute bei der Nutzung von IP SYMCON auf das gleiche Problem wie @PatrickMgestoßen. Es gelingt mir nicht NULL zu übergeben. Ich bekomme auch immer eine der beiden Fehlermeldungen:

MQTT: Failed to update evse/start_charging from MQTT payload: Failed to deserialize string: EmptyInput
MQTT: Failed to update evse/start_charging from MQTT payload: JSON null node was not null
 

Ich wäre auch dankbar wenn man hier einen leeren String, oder ein beliebiges boolean übergeben könnte.

Beste Grüße, Jochen

[markus.p]

Hallo,

ich habe MQTT-Node (node-red-contrib-mqtt-plus) benutzt und payload = null geschickt. Es funktioniert aber nicht stabil. Gestern hat sich die Ladesäule nach 2x AN/AUS verabschiedet. Das Starten des Ladevorgangs war auch über den Webserver nicht mehr möglich.  Ich musste das Ladekabel einmal ziehen. Danach ging es wieder über den webserver.

Ich würde auch eine schnelle Lösung begrüßen.

Grüsse,

Markus

[PatrickM]

Hallo @markus.p,

ich bin mir nicht sicher, ob Dein Problem etwas direkt mit MQTT zu tun hat. Ich kenne das von Dir beschriebene Problem auch, jedoch ist dann bei mir auch kein Einschalten über die WebUI möglich. Hast Du das auch bemerkt? Bisher habe ich es aufs Auto geschoben, tritt bei mir aber nur beim Ausprobieren auf, sonst kommt bei mir nicht vor, dass in kurzer Reihenfolge mehrere Ladrvorgänge gestartet und gestoppt werden.

Viele Grüße 

Patrick

[rtrbt]

Moin,

Je nachdem wie oft und vor allem wie schnell start/stop aufgerufen wird wird, kann das durchaus ein Selbstschutz des Autos vor defekten Wallboxen ausgelöst wird. Wenn das der Fall ist, dann ist auch erwartet, dass das Auto dann erst wieder erlaubt zu laden, wenn man es einmal abgezogen hat. Von welchen Zeitintervallen zwischen dem Umschalten reden wir hier?

Edit: Zeigt eins eurer Autos in dem Fall irgendetwas an? Rote LED am Ladeport oder irgendwelche Meldungen im Kombiinstrument?

[markus.p]

Hallo,

ich habe 2x in einer Minute Ein -und ausgeschaltet.

Ich werde diesen Hinweis mitnehmen und beobachten.

Gibt es eine Logausgabe wenn das Fahrzeug blockiert?

Markus

[Mr_O]

Hallo Zusammen, 

 

mein Name ist Olli und ich bin neu hier. Ich habe seit knapp einem Jahr eine Warp2 zusammen mit einem BMW i3 in Betrieb, und bin damit sehr happy.

 

Nun habe ich Home Assistant entdeckt und versuche die Warp2 über Home "Assistant / Node Red" zu Starten und zu Stoppen. Ich bekomme das aber nicht hin, mir fehlt

der richtige Hinweis, wie ich den Start/Stopp befehl in Node Red umzusetzen habe, das will mir irgendwie nicht klar werden... Ich habe leider keine Programmiererfahrung.

 

Evtl. ist ja einer so freundlich, und kann mir ein 1-2 (oder auch mehr) Screenshots hier einstellen, woraus die Konfig in Node Red ersichtlich wird, das wäre mir eine sehr große Hilfe.

 

Vielen dank und Gruß 

Olli