openwb-2.0: implement RFID Reset

[kaindl]

RFID-Handling is fixed in current alpha/HEAD-Version of openwb/core and will be included in Release 2.3.0.

To utilize this, we have to reset the RFID-tag on unplug.,

[kaindl]

keeping this in draft-state until I tested the changes on my openWB,

@andig, @naltatis should we merge this before openWB releases 2.3.0 so advanced users can use it already with openWBs on alpha-channel or should we keep it back until their release?

[andig]

Lets wait until expectedly supported or it will create confusion.

[MartinRinas]

would it make sense to make this revert conditionally to the installed software of the openWB, or would we rather rely on a hint in the config dialog only?

[kaindl]

@MartinRinas there is no information about the openWB-Version in the modbus interface, so there is no way to do something automatically depending on the openWB version...

[andig]

We should not do this. Relying on status changes is brittle since evcc might miss them. The right thing here would be fixing this on the OpenWB side or switching to native on OpenWB.

To utilize this, we have to reset the RFID-tag on unplug.,

This is exactly what should be done by OpenWB and what every other wallbox is doing.

[kaindl]

@andig I strongly disagree here: There is no "standard" howto handle RFID-Identification AFAIK. We are trying to integrate different chargers into evcc and so we have to adapt to the interface of the charger, not the charger to our interface. At least as long, as we are not using standardized interfaces.

openWB won't change it's behavior for this, there was a statement for this from @kevinwieland in the corresponding issue for openWB: openWB/core#2832 (comment)
And I also received a statement about this from their support:

Wir sind vollkommen fein damit das jemand ein anderes EMS nutzt. Ein Problem dort kann aber in der Folge nicht das komplette Handling bei uns über den Haufen werfen.

Yes, we could miss status changes, but for the current logic only one change is important: the change from any other status to A/Disconnected. As the last status is kept in a variable, we must miss all communication in states B/plugged and C/charging before next unplug. This will happen either when there are communication problems or if plugging in and out is happening in a very short time < control cycle interval.
Both should be no big problem if we would add another logic I already had in my mind anyways: Reset also, if we see no status change in a defined time (I would suggest 5 mins) after a new RFID-Tag.
My thoughts about this where handling a RFID-Scan without plugging in the car, but it would also help for missed status changes.

[andig]

Yes, we could miss status changes, but for the current logic only one change is important: the change from any other status to A/Disconnected.

You can still miss these.

There is no "standard" howto handle RFID-Identification AFAIK.

The standard is to wipe RFIDs when vehicle disconnects.

Wir sind vollkommen fein damit das jemand ein anderes EMS nutzt. Ein Problem dort kann aber in der Folge nicht das komplette Handling bei uns über den Haufen werfen.

Das ist natürlich Quatsch. Das Problem ist nicht das EMS sondern die Tatsache, dass die OpenWB das als Secondary nicht selbst kann.

[kevinwieland]

Die openWB handhabt es seit 2018 so das die primary die Hoheit darüber hat, nicht die secondary.
Das dies über Modbus nicht verfügbar war, war ein Bug, der ist aber behoben (siehe Links).

[andig]

@kevinwieland das machts ja nicht besser bzw. ändert an der Diagnose nichts:

Das Problem ist nicht das EMS sondern die Tatsache, dass die OpenWB das als Secondary nicht selbst kann.

[kevinwieland]

Ja, die Diagnose bleibt. EVCC muss es schlicht zurücksetzen wenn es den RFID Tag ausgelesen hat. Die Möglichkeit besteht nun per MQTT und auch per Modbus.

[andig]

Then lets reopen when OpenWB has released.

[kaindl]

@andig what do you think about adding this additional logic?

Reset also, if we see no status change in a defined time (I would suggest 5 mins) after a new RFID-Tag.

[andig]

So car connects at night and RDIF gets resets since it doesn‘t charge? Sounds wrong.

[kaindl]

Ah, sorry, description was not precise enough.
This logic should of course only apply in status A, so scanning an RFID without plugging in a car afterwards should not "unlock" the charger or set the next connected vehicle forever.

[kaindl]

implemented extended logic:
Reset RFID if

• Status changes to A, no matter from where
• RFID was scanned in StatusA, but no car was connected in the next 2 Minutes

While testing I also found a bug in the current implementation: If reading of some values from modbus fails, random state-changes or identifier changes occur because of the way, errors are handled.
As I introduced cached values here for handling the RFID Reset, I changed this to using the cached value instead of random values in this case.

While testing I also found another bug in openWB and implemented a fix for that also: openWB/core#3797 -> hopefully this will be in the same release as the reset mechanism needed for this change :)

@andig could you please reopen as Draft, so my changes will be visible here?