Local RFID behaviour vs. OCPP is erratic

[mschmitt]

I'm working on a personal OCPP implementation (not pushed to Github yet) and have observed the following behaviour between Firmware 055.5 and 055.7 Beta when presenting an RFID tag that's locally known to the charger:

• 055.5: Sends locally known RFID tags to OCPP for authorization. Once authorized, consumption is reported to OCPP (StartTransaction/StopTransaction) and also added to the local RFID slot. The consumption after RemoteStartTransaction for the same RFID tag's ID is also added to the RFID slot.
• 055.7 BETA: Accepts locally known RFID tags without any OCPP interaction, but adds consumption to the next free (unassigned) RFID configuration slot. (Clarification: In my case, the consumption went towards slot 3, which has no RFID assigned, and the RFID in use was assigned to slot 2, might be an off-by-one situation.)

Is the Beta moving towards a new way of handling of locally known RFIDs where they are handled autonomously without OCPP interaction, or is this behaviour completely unintended?

[mschmitt]

• 055.7 released. Reproducible as described above. No OCPP interaction on locally known RFID, consumption counts towards wrong RFID.
• 055.8 BETA, reproducible as described above. No OCPP interaction on locally known RFID, consumption counts towards wrong RFID.
• Can now confirm that consumption counts towards RFID slot +1:
  • Present RFID 2, consumption counts towards RFID 3. (As observed earlier, 055.7 Beta, 055.7, 055.8 Beta)
  • Present RFID 1, consumption counts towards RFID 2. (Tried on 055.8 Beta only)
• Unknown RFID is passed to OCCP for authorization. (Tried on 055.8 Beta only)
• Back to 055.5 for me.

[0xFEEDC0DE64]

thanks for reporting, we will check this and maybe release another beta firmware with fixes applied

[mschmitt]

• 56.1 released.
• Present RFID associated with local slot 1
  • Activation goes through OCPP: no (expected: yes)
  • Consumption counts toward local slot 1: no, to slot 2 (expected: yes, to slot 1)
• Present RFID associated with local slot 2
  • Activation goes through OCPP: no (expected: yes)
  • Consumption counts toward local slot 2: no, to slot 3 (expected: yes, to slot 2)
• Present completely unknown RFID
  • Activation goes through OCPP and gets denied: yes (expected: yes)
• Back to 055.5 for me.

[0xFEEDC0DE64]

Please try to verify or change the configuration values of AllowOfflineTxForUnknownId, LocalAuthorizeOffline, LocalAuthListEnabled

Should we do a short meeting going through the stack? We would enable the go-e ocpp debug mode on your box so we see the incoming and outgoing traffic and all state transitions in between.
You can also always ask the go-e support if you include timestamps and serial numbers, maybe ask them for a direct google meets link together with me, Daniel :)

[mschmitt]

I'll be glad to help out. Feel free to get in touch with me directly (the "href" link on my github profile).

If you need some sort of paper trail with support, I can also take that path.

In the mean time, the OCPP values you asked about:

    {
      "key": "AllowOfflineTxForUnknownId",
      "readonly": false,
      "value": "0"
    },
    {
      "key": "LocalAuthorizeOffline",
      "readonly": false,
      "value": "0"
    },
    {
      "key": "LocalAuthListEnabled",
      "readonly": false,
      "value": "0"
    },

[mschmitt]

I'm closing this as I no longer feel the need to rely on RFID for backup accounting and am currently investigating pure OCPP issues in current versions.