sahni Posted May 24, 2021 at 11:09 AM Posted May 24, 2021 at 11:09 AM 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. 1 Quote
floho Posted May 25, 2021 at 09:16 AM Posted May 25, 2021 at 09:16 AM Noch nicht. Aber ich plane das gleiche sobald ich die WB habe. Also schon mal zwei :-) Quote
int5749 Posted June 13, 2021 at 09:36 AM Posted June 13, 2021 at 09:36 AM Somit sind wir zu dritt, wobei ich dies in openHAB plane ;-) Quote
-Thomas- Posted August 8, 2021 at 02:47 PM Posted August 8, 2021 at 02:47 PM (edited) 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. Edited August 8, 2021 at 10:13 PM by -Thomas- Automation entfernt 3 Quote
sahni Posted August 19, 2021 at 05:58 PM Author Posted August 19, 2021 at 05:58 PM Danke @-Thomas- für den yaml Code. Ich muss meine Smart erst noch installieren lassen ;-) Quote
floho Posted October 19, 2021 at 03:44 PM Posted October 19, 2021 at 03:44 PM 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 Quote
sahni Posted November 4, 2021 at 03:18 PM Author Posted November 4, 2021 at 03:18 PM @-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 Quote
rtrbt Posted November 5, 2021 at 11:00 AM Posted November 5, 2021 at 11:00 AM Die NFC-Konfiguration wird auf dem Flash der Wallbox gespeichert. Änderungen werden deshalb erst übernommen, wenn du die Wallbox per warp2/XYZ/reboot neustartest. Quote
sahni Posted November 5, 2021 at 12:16 PM Author Posted November 5, 2021 at 12:16 PM 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? Quote
sahni Posted November 9, 2021 at 07:36 PM Author Posted November 9, 2021 at 07:36 PM 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? Quote
rtrbt Posted November 10, 2021 at 09:14 AM Posted November 10, 2021 at 09:14 AM 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. 1 Quote
sahni Posted November 10, 2021 at 07:55 PM Author Posted November 10, 2021 at 07:55 PM Danke, nun funktioniert es! Quote
floho Posted November 11, 2021 at 01:19 PM Posted November 11, 2021 at 01:19 PM (edited) 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 Edited November 11, 2021 at 03:29 PM by floho Quote
rtrbt Posted November 12, 2021 at 01:52 PM Posted November 12, 2021 at 01:52 PM 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. Quote
floho Posted November 13, 2021 at 07:02 AM Posted November 13, 2021 at 07:02 AM 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 Quote
rtrbt Posted November 16, 2021 at 08:03 AM Posted November 16, 2021 at 08:03 AM 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 Quote
philipps Posted April 25, 2022 at 09:25 AM Posted April 25, 2022 at 09:25 AM 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 1 Quote
rtrbt Posted April 27, 2022 at 11:32 AM Posted April 27, 2022 at 11:32 AM 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 1 Quote
masterdot Posted August 30, 2022 at 06:52 PM Posted August 30, 2022 at 06:52 PM 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 :) Quote
philipps Posted September 23, 2022 at 01:30 PM Posted September 23, 2022 at 01:30 PM 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. Quote
MarkG Posted January 7, 2023 at 08:07 PM Posted January 7, 2023 at 08:07 PM 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? Quote
rtrbt Posted January 9, 2023 at 10:57 AM Posted January 9, 2023 at 10:57 AM Prinzipiell implementiert haben wir die MQTT-Auto-Discovery, ist aber noch nicht veröffentlicht. Kommt in den nächsten Wochen. Quote
masterdot Posted February 27, 2023 at 07:52 PM Posted February 27, 2023 at 07:52 PM 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? Quote
MatzeTF Posted February 28, 2023 at 10:00 AM Posted February 28, 2023 at 10:00 AM Also wenn du noch bis morgen warten kannst… 😉 Quote
masterdot Posted February 28, 2023 at 10:16 AM Posted February 28, 2023 at 10:16 AM Na klar! (was passiert denn morgen? :)) Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.