PatrickM
-
Gesamte Inhalte
9 -
Benutzer seit
-
Letzter Besuch
Posts erstellt von 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.
-
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
-
vor 3 Stunden schrieb rtrbt:
Soweit du mit statischen IPs leben kannst, würde ich da erstmal nicht mehr Zeit investieren.
Ist für mich völlig OK, die WB bekäme über den DHCP auch immer die selbe IP, deswegen macht es für mich keinen Unterschied.
Vielen Dank für die schnelle Analyse
-
Nun klappt es auch über die reine LAN-Verbindung ohne parallele WLAN-Verbindung: Ich habe die IP-Konfiguration der LAN-Verbindung auf statische IP umgestellt. Damit scheint sich die Verbindung schneller aufzubauen.
Aus meiner Sicht bestätigt sich damit Deine o.g. Vermutung.
event-log-2021-10-06T14-01-25-768Z - Nur LAN Statische IP.txt
-
Du hast mich auf eine Idee gebracht: Ich habe die Box jetzt per WLAN ins Netz gehangen, und siehe da, die Verbindung zum MQTT Broker wird aufgebaut (event-log-2021-10-06T13-30-53-438 - Nur WLAN.txt)
Aus Interesse habe ich zusätzlich den LAN-Stecker wieder eingesteckt. Die Web-Gui Box war dann (wie zu erwarten) über beide IP-Adressen (LAN und WLAN) zu erreichen und die Verbindung wurde zum Broker wurde wieder aufgebaut. (event-log-2021-10-06T13-39-17-660Z - LAN und WLAN.txt)
Nun habe ich das WLAN wieder abgeschaltet und die Verbindung zum Broker schlägt wieder fehl (event-log-2021-10-06T13-44-40-366Z - Nur LAN.txt) - Aber nun wird ein Fehler des mDNS responder "Error setting up mDNS responder!" ins Log geschrieben, den habe ich vorher nicht gesehen.
Edit: Ich habe beim letzten Versuch zusätzlich den WLAN-Access-Point von "Nur Fallback" auf "Deaktiviert" gesetzt.
Vielleicht hilft Dir das bei der Suche.
event-log-2021-10-06T13-44-40-366Z - Nur LAN.txt event-log-2021-10-06T13-39-17-660Z - LAN und WLAN.txt event-log-2021-10-06T13-30-53-438 - Nur WLAN.txt
-
Nein, habe ich nicht :-) Habe Deinen Post gesehen und habe gleich auch an meine Box gedacht - Die liegt zwar geöffnet aber mit angeschlossenem Button auf der Werkbank :-)
-
Hallo Erik,
danke für die schnelle Rückmeldung.
Ich habe die neue Firmware installiert und der Wallbox etwas Zeit gegeben sich zu verbinden, aber leider kann ich keine zusätzlichen Informationen aus dem Ereignislog entnehmen. Trotzdem habe ich es nochmal angehängt.
Viele Grüße
Patrick
-
Hallo zusammen,
irgendwie schaffe ich es nicht, meine Warp2 Smart mit meinem Mosquitto MQTT Broker zu verbinden. Dieser läuft auf einem separaten RaspberryPi und kann von anderen Clients angesprochen werden.
In der Warp2 Web-GUI wird bei MQTT-Status "Getrennt" angezeigt und im Ereignis-Log erscheint regelmäßig "Connecting to MQTT broker".
Kann mir jemand einen Tipp geben? Anbei noch das Ereignis-Log und der Debug-Report.
PS: Ich weiß nicht, ob das relevant ist, aber aktuell betreibe ich die Warp2 noch testweise 1-phasig angeschlossen auf meiner Werkbank liegend ohne verbundenes Auto.
Vielen Dank schon mal, ich wäre über jeden Hinweis dankbar.
Patrick
event-log-2021-10-06T06-58-59-394Z.txt debug-report-2021-10-06T06-58-56-525Z.json
stop_charging / start_charging via MQTT in Node-Red
in WARP Charger
Geschrieben
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