openWB Forum

Hallo zusammen,
könnte mir hiermit jemand weiter helfen?
Das Problem besteht, wenn kein Fahrzeug angesteckt ist/wird und ein RFID Chip gelesen wurde. Dieser wird dann nicht nach 5 Minuten verworfen.

VG Christian

Hallo zusammen,
ich habe das gleiche Problem (OpenWB Software 2.0 als Secondary).
Ein einmal gescannter RFID Tag bleibt ohne zeitliche Begrenzung erhalten, bis ein anderer RFID Tag gescannt wird. Außerdem wird der RFID Timestamp kontinuierlich neu gesetzt - offensichtlich läuft eine Hintergrundaktivität, die einen gescannten RFID Code immer wieder neu setzt.
Dies stört die Identifikation von Fahrzeugen im Zusammenspiel mit evcc erheblich. Ein automatisches Rücksetzen des RFID Tags nach einer bestimmen Zeit wäre sehr hilfreich.
VG
Udo

Das RFID handling ist Sache des Masters. Der Secondary übermittelt nur und wartet auf Rückinfo.
Wenn du keine primary openWB hast muss EVCC das übernehmen für die Secondary.

Ich bin mit evcc auch über dieses Problem gestolpert, da auf einmal die bequeme, automatische Erkennung nicht mehr ging. Da habe ich festgestellt, es liegt am dauerhaft übermittelten RFID-Tag der openWB.

evcc nutzt aber modbus für die Steuerung der openWB, nicht MQTT.

@openWB du schreibst, evcc muss sich um das Handling kümmern, der Secondary wartet auf Rückinfo. In der MQTT-Doku sehe ich auch passende Topics dafür, mit Timestamp und dem Reset über last_tag kann der Primary hier auch ein Handling Implementieren.

In der modbus-Doku finde ich aber keine entsprechenden Register, nur den für den tag, und dieser wird nach einem Scan laufend geschickt.

Wie ist das Handling durch den Primary auf der modbus-Ebene denn gedacht?
Wie sollte ein modbus-Primary den Unterschied erkennen, ob der Tag gesendet wird, weil der Token vor 3 Tagen gescannt wurde oder weil er gerade eben gescannt wurde?
Und wie kann er den Reset triggern?

Wenn ich richtig sehe, dass es hier keine Möglichkeit gibt, sollte zumindest auf dem modbus doch auch das Verwefen des Tokens nach 5 Minuten Timeout greifen, oder?

Ohne das Coding nun genau zu kennen, würde ich hier erwarten, dass bei einer Steuerung der secondary per modbus einfach der Ladestrom gesetzt wird. Oder, falls es ein modbus-Register für gesperrt/entsperrt geben sollte, dass das dann entsprechend gesetzt wird. Dass eine Zeichenkette (also der gescannten RFID) per modbus zu übertragen wird um sie dann von der secondary auswerten zu lassen, halte ich für nicht sehr wahrscheinlich.

Magst du ja für unwahrscheinlich halten, ist aber so. Ist in der modbus-Doku beschrieben und ich sehe die Tags ja auch über modbus auf dem evcc.
Der Punkt ist nur, dass dieser Tag dauerhaft gesendet wird, nachdem er einmal gescannt wurde und weder ein Timestamp, noch ein Reset dazu angeboten werden...

Hmm. Ich finde das da nicht. https://openwb.de/main/wp-content/uploa ... -Pro-1.pdf

Schau mal auf Register 10160 in der von dir verlinkten Doku

Da steht „Read“. Ich verstehe das so, dass das der von der Secondary gelesene RFID-Tag ist.

Sorry, jetzt hab ich deinen Punkt verstanden.
Nein, der RFID-String wird natürlich nicht per modbus *an* die openWB im secondary Modus übertragen, macht ja auch wenig Sinn.
Der Kartenleser hängt natürlich an der openWB (secondary), dort will man ja den Tag auch hinhalten beim Anstecken, der Tag wird von der openWB (secondary) korrekt eingelesen und von zB evcc per modbus auf dem genannten Register ausgelesen.

Das Problem ist: die openWB (secondary) gibt diesen Tag ab jetzt dauerhaft auf diesem Register aus, der überlebt sogar ein Update+Reboot der openWB. Da aber per modbus nur der Tag, nicht aber der Timestamp zur Verfügung gestellt wird, kann die Steuerung (zB evcc) nicht wissen, ob der Tag gerade eben oder vor 3 Tagen gescannt wurde.
Auch gibt es kein schreibbares Register dazu, mit dem die Steuerung (zB evcc) der openWB (secondary) mitteilen kann "hab den aktuellen Tag verarbeitet, bitte zurücksetzen bis zum nächsten Scan".
Demnach kann die Steuerung (zB evcc) kein sinnvolles Handling der Gültigkeit des gelesenen Tags übernehmen und dieses Handling muss in der openWB (secondary) passieren.
Meines Wissens ist die dafür implementierte Logik wenn die openWB als primary konfiguriert ist, den Tag nach 5 Minuten zu verwerfen, wenn bis dahin kein Fahrzeug angesteckt wurde, ansonsten mit Abstecken des Fahrzeugs.
-> so eine, bzw idealerweise die identische Logik sollte deshalb für die modbus-Schnittstelle auch aktiv sein, wenn die openWB als secondary konfiguriert ist.