-
Notifications
You must be signed in to change notification settings - Fork 107
Description
Angetrieben durch ein komisches Verhalten von evcc mit der openWB als secondary bei der Verwendung von RFID-Tokens hab ich mir das Handling der Tokens in der openWB als secondary genauer angeschaut.
Nach außen gibt es dafür mit MQTT und modbus zwei relevante Schnittstellen.
Laut Beschreibung der MQTT-API gibt es drei relevante Topics dafür:
openWB/internal_chargepoint/{duo_num}/get/rfid
openWB/internal_chargepoint/{duo_num}/get/rfid_timestamp
openWB/set/internal_chargepoint/last_tag
Der Timestamp wird aber nicht veröffentlicht, ich hab auch nichts im Code gefunden, wo der für den internal_chargepoint gesetzt wird.
Auf dem modbus gibt es nur ein relevantes Register mit dem RFID Tag.
Damit wird auf beiden Schnittstellen dauerhaft der zuletzt gescannte Token gesendet, ohne der Gegenstelle die Möglichkeit eines sinnvollen Handlings zu geben.
Anhand der Dokumentation war ich davon ausgegangen, das per MQTT ein sinnvolles Handling möglich wäre und wollte eigentlich einen PR einreichen, der nur den Timestamp und die Reset-Möglichkeit auch auf der modbus-Schnittstelle verfügbar macht.
Als ich festgestellt hatte, dass der Timestamp auch auf dem MQTT fehlt und mir das Ganze genauer angeschaut habe, bin ich zu dem Schluss gekommen: eigentlich sollte das Handling sowieso die openWB übernehmen.
Wie komme ich zu diesem Schluss?
Der RFID-Token wird bei beiden Protokollen für den Ladepunkt veröffentlicht. Für die Zuordnung zu einem Ladepunkt ist aber das Handling schon nötig (Abgleich mit gesteckt-Status usw.)
Für die Funktion als primary ist hier schon eine Logik implementiert, die meines Wissens sinnvoll funktionieren sollte. -> Mein Vorschlag wäre daher, diese Logik direkt auch für den Betrieb als secondary auf die auf den Ladepunkten veröffentlichten Tags (MQTT und modbus) anzuwenden.
Ich hatte das Thema bereits im Forum angesprochen, bevor ich alle diese Erkenntnisse hatte, da wurde vom offiziellen Nutzer "openWB" angemerkt, dass die Logik nicht im secondary sein sollte.
Deshalb denke ich, bevor irgendetwas implementiert werden kann/soll, sollte hier erst mal ein Konsens gefunden werden, was sinnvollerweise implementiert wird?