WARP in Home Assistant via MQTT und HTTP-API

[sahni]

Ich plane die Einbindung einer WARP Smart in Home Assistant via MQTT und HTTP-API zu realisieren um die Bedienung (Statusanzeige, Laden starten/stoppen etc.) unter einer Oberfläche (nämlich HA ;-) zu haben. Hat einer hier im Forum schon Erfahrungen im Umfeld von HA und der WARP gemacht? Über Tipps und ggf. Beispielcode (YAML) würde ich mich freuen.

[floho]

Noch nicht. Aber ich plane das gleiche sobald ich die WB habe. Also schon mal zwei :-)

[int5749]

Somit sind wir zu dritt, wobei ich dies in openHAB plane ;-)

[-Thomas-]

Ich habe die Box in meinen Home Assistant eingebunden, funktioniert soweit ganz gut. Hier meine Konfiguration:

config/configuration.yaml:

binary_sensor:
  - platform: mqtt
    name: "Wallbox Ladekabel verbunden"
    state_topic: "warp/SLq/evse/state"
    device_class: plug
    json_attributes_template: '{{ value_json }}'
    value_template: '{{ value_json.vehicle_state in [1, 2, 3] }}'
    payload_on: 'True'
    payload_off: 'False'

  - platform: mqtt
    name: "Wallbox Fehler"
    state_topic: "warp/SLq/evse/state"
    device_class: problem
    json_attributes_template: '{{ value_json }}'
    value_template: '{{ value_json.vehicle_state in [3] }}'
    payload_on: 'True'
    payload_off: 'False'

  - platform: mqtt
    name: "Wallbox verfügbar"
    state_topic: "warp/SLq/evse/state"
    device_class: connectivity
    json_attributes_template: '{{ value_json }}'
    value_template: '{{ value_json.uptime > 0 }}'
    expire_after: 30
    payload_on: 'True'
    payload_off: 'False'

  - platform: mqtt
    name: "Wallbox Ladevorgang"
    state_topic: "warp/SLq/evse/state"
    device_class: battery_charging
    json_attributes_template: '{{ value_json }}'
    value_template: '{{ value_json.vehicle_state in [2] }}'
    payload_on: 'True'
    payload_off: 'False'

sensor:
  - platform: mqtt
    name: "Wallbox Leistung"
    state_topic: "warp/SLq/meter/state"
    value_template: "{{ value_json.power }}"
    device_class: power
    unit_of_measurement: "W"
  - platform: mqtt
    name: "Wallbox Zählerstand"
    state_topic: "warp/SLq/meter/state"
    value_template: "{{ value_json.energy_abs }}"
    device_class: energy
    unit_of_measurement: "kWh"

switch:
  - platform: mqtt
    name: "Wallbox Maximaler Ladestrom"
    command_topic: "warp/SLq/evse/current_limit"
    payload_on: '{"current": 16000}'
    payload_off: '{"current": 6000}'
    state_topic: "warp/SLq/evse/max_charging_current"
    value_template: '{{ value_json.max_current_configured >= 16000 }}'
    state_on: "True"
    state_off: "False"
    json_attributes_template: "{{ value_json }}"

  - platform: mqtt
    name: "Wallbox Automatisches Laden"
    icon: mdi:ev-plug-type2
    command_topic: "warp/SLq/evse/auto_start_charging_update"
    payload_on: '{"auto_start_charging": true}'
    payload_off: '{"auto_start_charging": false}'
    state_topic: "warp/SLq/evse/auto_start_charging"
    value_template: '{{ value_json.auto_start_charging }}'
    state_on: "True"
    state_off: "False"

  - platform: mqtt
    name: "Wallbox Ladevorgang"
    icon: mdi:battery-charging
    command_topic: "warp/SLq/evse/charging_command"
    state_topic: "warp/SLq/evse/state"
    value_template: '{{ value_json.vehicle_state in [2] }}'
    state_on: "True"
    state_off: "False"

  - platform: template
    switches:
      wallbox_ladevorgang:
        friendly_name: "Wallbox Ladevorgang"
        icon_template: mdi:battery-charging
        value_template: '{{ is_state("binary_sensor.wallbox_ladevorgang", "on") }}'
        turn_on:
          service: mqtt.publish
          data:
            topic: warp/SLq/evse/start_charging
            payload: 'null'
        turn_off:
          service: mqtt.publish
          data:
            topic: warp/SLq/evse/stop_charging
            payload: 'null'

 

config/automations.yaml:

Die Automation ist leider notwendig, um das MQTT-Kommando der Wallbox richtig zu senden. Die Box hat zwei Topics zum Starten und Stoppen des Ladevorgangs, und Home Assistant unterstützt leider nur einen Topic für den Schalter. Funktioniert aber gut soweit.

Edit: Ich habe doch eine Variante ohne Automation gefunden, mit Hilfe eines Template-Switches.

bearbeitet August 8, 2021 at 22:13 von -Thomas-
Automation entfernt

[sahni]

Danke @-Thomas- für den yaml Code. Ich muss meine Smart erst noch installieren lassen ;-)

[floho]

Super, funktioniert tadellos. Danke. 

Eine Anmerkung habe ich. Ich würde die Sensoren wie folgt abändern: 

sensor:
  - platform: mqtt
    name: "Wallbox Leistung"
    state_topic: "warp/XXX/meter/state"
    value_template: "{{ value_json.power }}"
    device_class: power
    state_class: measurement
    unit_of_measurement: "W"
  - platform: mqtt
    name: "Wallbox Zählerstand"
    state_topic: "warp/XXX/meter/state"
    value_template: "{{ value_json.energy_abs }}"
    device_class: energy
    state_class: total
    unit_of_measurement: "kWh"

Also die "state_class" Attribute einfügen. Dann wird das neue Energy Feature unterstützt und somit die Langzeitauswertung des Zählers. 

Gruß, Florian

[sahni]

@-Thomas-Vielen Dank für den Code. Hat bislang gut funktioniert mit der Einbindung meiner WARP2 in HA. Nun habe ich allerdings das Problem dass das Update für NFC Tag required true/false über MQTT nicht ausgeführt wird. Nach API Referenz sollte das mit derselben Methode gehen wie für auto_start_charging. 

Topic warp2/XYZ/nfc/config_update mit dem Payload { "require_tag_to_start": true } tut es leider nicht. Hast du vielleicht eine Idee, oder hast du das bei dir schon umgesetzt?

Grüße, Danny

[rtrbt]

Die NFC-Konfiguration wird auf dem Flash der Wallbox gespeichert. Änderungen werden deshalb erst übernommen, wenn du die Wallbox per warp2/XYZ/reboot neustartest.

[sahni]

Danke für den Hinweis. In der API Referenz (https://www.warp-charger.com/api.html#states_section_configs) steht das Aktualisierungen auf dem speziellen Suffix _update entgegengenommen werden. Das sie im Flash abgelegt werden und ein Neustart für eine Übernahme der Änderungen notwendig ist steht dort auch. Allerdings funktioniert eine Aktualisierung von evse/auto_start_charging via evse/auto_start_charging_update auch ohne einen Neustart. Das ein Neustart des Ladecontrollers diesen Wert zurück auf true setzt finde ich etwas unglücklich. Die Änderungen (auto_start_charging: false) wurden ja nicht ohne Grund durchgeführt.

Was spricht dagegen die Aktualisierung von nfc/config genauso zu handhaben wie für evse/auto_start_charging, d.h. ohne erforderlichen Neustart?

[sahni]

Am 5.11.2021 um 12:00 schrieb rtrbt:

Die NFC-Konfiguration wird auf dem Flash der Wallbox gespeichert. Änderungen werden deshalb erst übernommen, wenn du die Wallbox per warp2/XYZ/reboot neustartest.

Ich versuche über MQTT das Topic

warp2/WFZ/nfc/config_update

mit dem Payload 

{"require_tag_to_start": true}

zu schreiben.

Das funktioniert leider nicht mit dem gewünschten Ergebnis. Im Ereignis-Log der WARP2 steht der Eintrag MQTT: Failed to update nfc/config_update from MQTT payload: JSON object had 1 entries instead of the expected 3

Was fehlt denn da bei mir?

[rtrbt]

Du musst, wenn du Einträge nicht verändern willst, diese explizit auf null setzen. Also z.B.

{"require_tag_to_start": true, "require_tag_to_stop": null, "authorized_tags": null}

 

On 11/5/2021 at 1:16 PM, sahni said:

Allerdings funktioniert eine Aktualisierung von evse/auto_start_charging via evse/auto_start_charging_update auch ohne einen Neustart. Das ein Neustart des Ladecontrollers diesen Wert zurück auf true setzt finde ich etwas unglücklich. Die Änderungen (auto_start_charging: false) wurden ja nicht ohne Grund durchgeführt.

Dafür wird es voraussichtlich einen konfigurierbaren Default-Wert geben. Der Hintergedanke war an der Stelle mal, dass egal was man an Konfiguration kaputt gespielt hat, nach einem Neustart der Wallbox geladen werden kann. Das ist aber seit dem es das managed-Flag gibt sowieso nicht mehr gegeben.

[sahni]

Danke, nun funktioniert es!

[floho]

Ich hab nun in die WARP 1 das NFC Tool nachgerüstet. Dadurch werden per MQTT zyklisch diese Einträge versendet: 

 

Topic:

warp/XXX/nfc/seen_tags

Inhalt:

[
  {"tag_type":2,"tag_id":[1,2,3,4,5,6,7],"last_seen":1703665},
  {"tag_type":0,"tag_id":[],"last_seen":0},
  {"tag_type":0,"tag_id":[],"last_seen":0},
  {"tag_type":0,"tag_id":[],"last_seen":0},
  {"tag_type":0,"tag_id":[],"last_seen":0},
  {"tag_type":0,"tag_id":[],"last_seen":0},
  {"tag_type":0,"tag_id":[],"last_seen":0},
  {"tag_type":0,"tag_id":[],"last_seen":0}
]

Nun versuche ich das teil sinnvoll in HA zu integrieren. Ich dachte an ein Template mit dem Attributen "ID" und "last seen". Der Type ist eigentlich (für meinen Zweck) egal. Leider habe ich es bisher nicht hinbekommen. 

Vielleicht ist jemand hier firmer und hat eine Idee. 

Außerdem noch eine Frage an Tinkerforge: warum zyklisch? Und warum 8 Einträge? Kann es sein dass 8 Tags angelernt werden können und in einer fixen Liste gespeichert werden? Diese 8 Tags werden dann eben zyklisch gesendet? Aktuell habe ich nur einen Tag, daher kann ich es nicht empirisch ermitteln.

EDIT:

Nun habe ich einen zweiten NFC Tag gefunden. Offensichtlich werden in dem MQTT Topic einfach die letzen 8 gefundenen NFC - Tags gesendet. Da ich das ja direkt auswerte würde ich mir wünschen, dass man einstellen könnte dass einfach der letze erkannte Tag gesendet wird, nicht die letzen 8. Außerdem wäre es klasse wenn der Publisher nur nach dem Erkennen (gerne mehrmals) ein Nachricht sendet. So wird doch sehr viel Traffic erzeugt ....

Gruß und Danke, Florian

 

 

bearbeitet November 11, 2021 at 15:29 von floho

[rtrbt]

On 11/11/2021 at 2:19 PM, floho said:

Da ich das ja direkt auswerte würde ich mir wünschen, dass man einstellen könnte dass einfach der letze erkannte Tag gesendet wird, nicht die letzen 8.

seen_tags sollte immer nach last_seen sortiert sein. D.h. wenn du nur das zuletzt erkannte Tag willst, kannst du einfach immer den ersten Eintrag lesen.

On 11/11/2021 at 2:19 PM, floho said:

Außerdem wäre es klasse wenn der Publisher nur nach dem Erkennen (gerne mehrmals) ein Nachricht sendet.

Dann würde im Webinterface die Anzeige, wann Tags zu letzt gesehen wurden nicht mehr funktionieren. Kannst du in HA darauf reagieren, wenn last_seen kleiner als der Wert aus der letzten Nachricht wird? Falls nicht behalte ich das für die künftige Erweiterung der NFC-API mal im Hinterkopf.

[floho]

Stimmt. Dar letzte erkannte Tag ist immer seen_tags[0], danke.

Aus technischer Sicht habe ich keinerlei Probleme mit der aktuellen Implementierung, alles funktioniert bestens.

Allerdings "sorge" ich mich ein wenig wegen des Traffics. Die Wallbox sendet im 1s Takt und der Payload wird immer größer. Und sie ist ja nicht der einzige MQTT/HTTP Teilnehmer. Daher dachte ich, dass für meinen Anwendungsfall z.B. die Tag-History nicht wirklich relevant ist, und schon gar nicht sekündlich.

Die vergangenen Sekunden könnte man durch einen Timestamp ersetzen. Dann könnte man sich den Wert selbst errechnen. Andererseits kann so kein Ist-Zustand abgerufen wenden wenn man das einmalig gesendete Telegramm verpasst oder "vergessen" hat. Also auch keine so gute Lösung. 

Mein Vorschlag: Auch wenn das eher eine niedrige Priorität hat, vielleicht lässt sich in Zukunft auf der MQTT Seite eine erweiterte Konfig vornehmen:

• Sendeintervall
  • abhängig vom Zustand der Wallbox. Z.B. im Idle jede Minute, während des Ladevorgangs weiter sekündlich
  • abhängig von der Variable. Z.B. aktuelle Ladeleistung sekündlich, erkannte Tags eher langsamer.
  • ... 
• Zusammensetzung des Topic
  • An- und Abwählen der einzelnen Bestandteile
  • verschiedenen Formate
  • ...

Kann man beliebig aufblasen, klar. Wie gesagt, wenn Luft ist wäre das sicher eine nette Option, aber Dinge wie "Nutzer/Tagverwaltung" halte ich für wichtiger. 

Gruß und Danke, Florian

[rtrbt]

On 11/13/2021 at 8:02 AM, floho said:

Mein Vorschlag: Auch wenn das eher eine niedrige Priorität hat, vielleicht lässt sich in Zukunft auf der MQTT Seite eine erweiterte Konfig vornehmen:

• Sendeintervall
  • abhängig vom Zustand der Wallbox. Z.B. im Idle jede Minute, während des Ladevorgangs weiter sekündlich
  • abhängig von der Variable. Z.B. aktuelle Ladeleistung sekündlich, erkannte Tags eher langsamer.
  • ... 
• Zusammensetzung des Topic
  • An- und Abwählen der einzelnen Bestandteile
  • verschiedenen Formate
  • ...

So oder so ähnlich habe ich es auf die TODO-Liste gegossen ;) https://github.com/Tinkerforge/esp32-firmware/issues/36

[philipps]

Hallo zusammen,

 

danke für die Homeassistant Konfiguration -Thomas-. Das ganze finktioner auch mit Firmware Version 2.0, ich musste allerdings eine kleine Änderung für einen Sensor vornehmen:

 - platform: mqtt
   name: "Wallbox verfügbar"
   state_topic: "warp/XXX/evse/low_level_state"
   device_class: connectivity
   json_attributes_template: '{{ value_json }}'
   value_template: '{{ value_json.uptime > 0 }}'
   expire_after: 30
   payload_on: 'True'
   payload_off: 'False'

 

Eine Frage in dem Zusammenhang an rtbt: Bei Home Assistant gibt es die Möglichkeit, solche Sensoren auch automatisch per MQTT Discovery zu definieren. Wäre es denkbar, das zu integrieren? Ich könnte hier gerne unterstützen bei der Erstellung der entsprechenden Definitionen. Es sieht für mich auf jeden Fall nach aus Nutzersicht sehr einfachen Möglichkeit zum Einbinden in Homeassistant aus, ohne dass eine eigene Integration geschrieben werden muss. Der Nutzer muss im Grunde nur die Verbindung zum MQTT-Broker herstellen.

 

Gruß,

Philipp

[rtrbt]

On 4/25/2022 at 11:25 AM, philipps said:

Bei Home Assistant gibt es die Möglichkeit, solche Sensoren auch automatisch per MQTT Discovery zu definieren. Wäre es denkbar, das zu integrieren?

Das klingt nach einer guten Idee. Wir müssen damit intern mal experimentieren, auch wie die Kompatibilität nicht nur zu Home Assistant, sondern auch zu z.B. openHAB ist. Ich habe mal ein Issue aufgemacht, damit der Gedanke nicht verloren geht: https://github.com/Tinkerforge/esp32-firmware/issues/135

[masterdot]

Irgendwas passt bei mir nicht. Es kommt in homeassistant etwas an, zumindest wenn ich den Broker auf # lauschen schicke. Aber in den Definitionen kommt irgendwie nichts an. 

Vielleicht hat jemand eine Idee, oder kann helfen :) 

[philipps]

Vielleicht blöde Antwort, aber manchmal übersieht man ja etwas: Hast Du evtl. das mqtt-Topic aus den Beispielen direkt so übernommen? Das muss auf jeden Fall angepasst werden genauer gesagt der Teil, der bei mir mit XXX im state_topic definiert ist. Wenn DU auf # lauscht am MQTT-Broker müsstest DU sehen, welche Tonics genau gesendet werden.

[MarkG]

Am 27.4.2022 um 13:32 schrieb rtrbt:

Das klingt nach einer guten Idee. Wir müssen damit intern mal experimentieren, auch wie die Kompatibilität nicht nur zu Home Assistant, sondern auch zu z.B. openHAB ist. Ich habe mal ein Issue aufgemacht, damit der Gedanke nicht verloren geht: https://github.com/Tinkerforge/esp32-firmware/issues/135

Hallo zusammen,

ist zu diesem Punkt bereits etwas implementiert worden? Das Issue wurde zwischenzeitlich gefixt / geschlossen, hier im Forum bzw. in der Dokumentation kann ich aber dazu nichts finden?

[rtrbt]

Prinzipiell implementiert haben wir die MQTT-Auto-Discovery, ist aber noch nicht veröffentlicht. Kommt in den nächsten Wochen.

[masterdot]

Hallo allesamt,

bis jetzt habe ich es nicht so recht zum laufen bekommen. 

Das modbus sieht interessant aus, aber an der Config scheitere ich ebenfalls :) die Autodiscovery ist anscheinend noch nicht veröffentlicht...

Hat vielleicht hier jemand das erfolgreich konfiguriert bekommen? 

[MatzeTF]

Also wenn du noch bis morgen warten kannst… 😉

[masterdot]

Na klar! 

 

(was passiert denn morgen? :))