Improve authorization after identification on wallbox

[ClemKC]

Hello,

I have a smartwallbox Schneider Electric. Everything looks to work well but I've noticed an issue. When I identify me on the wallbox with my card, it starts charging directly without any authorization from EVSE (Home assistant). Is it normal or an issue?

Expected behavior, I plug the car, I put the card on the RFID reader, the charging station push a request to HomeAssistant, home assisant can accept or refuse to start a charging session.

Thanks in advance for you support. By the way, I like your solution it's really helpfull :) I will pay you a coffee asap ;)

[drc38]

Currently any request from the charger to start a transaction is automatically authorised by the integration. You could write an automation or script to check the id.tag against a list of known tags and stop charging if it's not found or until you take some action in HA.

Also check your charger's ocpp configuration keys as they can be changed to alter authorisation behaviour eg local authorisation.

[lbbrhzn]

Indeed, the current version of the ocpp integration always accepts an authorization request. The proper way to deal with this is through an authorization list.

We could use an Options Flow, similar to https://aarongodfrey.dev/home%20automation/building_a_home_assistant_custom_component_part_4/ to define and edit the list. The example allows adding named items to a list, and removing items from a list. Preferably, we should support updating the authorization list without the need to restart the ocpp server or recreating the entities.

[ClemKC]

Hi, any update from the last request? I had to implement a function in node-red to block an unknown user but could you please implement this function into OCPP integration?

[lbbrhzn]

@ClemKC I've added support for an authorization list to configuration.yaml., see #437 Would you like to test it?

[ClemKC]

Hi, here are the tests, it seems not to work properly because it tag "BBD82A19" is allowed to start charging.

ocpp: default_authorization_status : 'Invalid' authorization_list:

• id_tag : '3N1633200001003' name: 'accepted tag' authorization_states: 'Accepted'
• id_tag : '1E08C064' name: 'accepted tag' authorization_states: 'Accepted'
• id_tag : 'BBD82A19'
  name: 'expired tag' authorization_status: 'Expired'
• id_tag : 'BBD82A19' name: 'blocked tag' authorization_status: 'Blocked'

Have I done something bad?

[lbbrhzn]

yes, a typo:

   authorization_states: 'Accepted'

should be

   authorization_status: 'Accepted'

also, make sure you use the proper indentation in your configuration.yaml.

[lbbrhzn]

BTW, which ocpp version did you use? The authorization list feature is not released yet, but you can access it by adding a custom repo with the full branch to HACS.

[ClemKC]

yes, a typo:

   authorization_states: 'Accepted'

should be

   authorization_status: 'Accepted'

also, make sure you use the proper indentation in your configuration.yaml.

It hasn't changed anyting to replace states by status

[ClemKC]

BTW, which ocpp version did you use? The authorization list feature is not released yet, but you can access it by adding a custom repo with the full branch to HACS.

I use the latest version of OCPP (0.4.24). How to get this custom repo?

[lbbrhzn]

That explains it 😝 I'll release a new version

[ClemKC]

That explains it 😝 I'll release a new version

Why have you closed the case? I have update with version 0.4.24 for the integration and the smart wallbox I has OCPP version 1.6. I have changed the configuration file and restarted Home Assistant but nope doesn't work. The blocked badge is still accepted ;)

[lbbrhzn]

Sorry, an issue is automatically closed by GitHub when an associated pull request is merged.

[lbbrhzn]

Try 0.4.25

[ClemKC]

Nope, still doesn't work properly, It hasn't changed anything to update from 0.4.24 to 0.4.25. Every badges work even those blocked in Configuration file.

ocpp: default_authorization_status : 'Invalid' authorization_list:

• id_tag : '3N1633200001003' name: 'test' authorization_status: 'Accepted'
• id_tag : '1E08C064' name: 'toto' authorization_status: 'Accepted'
• id_tag : 'BBD82A19'
  name: 'titi' authorization_status: 'Expired'
• id_tag : 'BBD82A19' name: 'tutu' authorization_status: 'Blocked'

[lbbrhzn]

ok, I'll have some more debugging to do! Thanks for testing!

[drc38]

@lbbrhzn my reading of the standard is that authorisation needs to be handled earlier in the process ie @on(Action.Authorize) rather than in the start transaction logic. That said it should still work returning the tag status in the start transaction payload however then there may be issues with how the charger's local authorisation cache works or is configured.

[lbbrhzn]

ok, i will revisit. Meanwhile, I got the authorizaiton list workign for my charger. @ClemKC please check v0.4.26!

[lbbrhzn]

@drc38 the way I interpret the standard is that the authorize request is optional, and can be skipped if the id_tag is found in the local authorization list/cache. The final authorization_status is passed in the startTransaction.conf:

Upon receipt of a StartTransaction.req PDU, the Central System SHOULD respond with a StartTransaction.conf PDU. This response PDU MUST include a transaction id and an authorization status value.

The Central System MUST verify validity of the identifier in the StartTransaction.req PDU, because the identifier might have been authorized locally by the Charge Point using outdated information. The identifier, for instance, may have been blocked since it was added to the Charge Point’s Authorization Cache.

[lbbrhzn]

@drc38, I have some issues adding tests for the authorization list. How do I read the config from configuration.yaml in the test setup?

[drc38]

I don't know if you can, I think you replicate the config in the test eg DEFAULT_CONFIG = { sensor.DOMAIN: {"platform": "mqtt", "name": "test", "state_topic": "test-topic"} }

[drc38]

@drc38 the way I interpret the standard is that the authorize request is optional, and can be skipped if the id_tag is found in the local authorization list/cache. The final authorization_status is passed in the startTransaction.conf:

Upon receipt of a StartTransaction.req PDU, the Central System SHOULD respond with a StartTransaction.conf PDU. This response PDU MUST include a transaction id and an authorization status value. The Central System MUST verify validity of the identifier in the StartTransaction.req PDU, because the identifier might have been authorized locally by the Charge Point using outdated information. The identifier, for instance, may have been blocked since it was added to the Charge Point’s Authorization Cache.

Agree it is a bit vague why an authorise request is required separately to that in the start transaction. This excerpt from the start transaction The Charge Point SHALL send a StartTransaction.req PDU to the Central System to inform about a transaction that has been started. suggests that it is sent after starting, so my guess only rejecting in the start transaction could result in the EV getting a small amount of charge while the communication happens with the central system.

[RafSchandevyl]

It would be nice to be able to add tagID to accepted list without need to restart home assistant. Something like getting a notification if a new tagID is read with selection to accept the card.

[lbbrhzn]

@RafSchandevyl , I agree! I've been looking at Actionable Notifications for this. See https://companion.home-assistant.io/docs/notifications/actionable-notifications

[ClemKC]

Ok here is my feedback. Latest version installed on my HA. Here is my configuration file.

ocpp: default_authorization_states : 'Invalid' authorization_list:

• id.tag : '1E08C064' name: 'Kia EV6 Appart' authorization_states: 'Accepted'
• id.tag : '3N1906212005002' name: 'Supervision' authorization_states: 'Accepted'
• id_tag : '987654321' name: 'expired tag' authorization_status: 'Expired'
• id.tag : 'D6FC13F7' name: 'blocked tag' authorization_states: 'Blocked'

I tried with id.tag, id_tag (in HA my wallbox generates 3N1906212005002.Id.Tag). i tried with authorization_states and authorization_status and charging point still start charging my car even when a badge is blocked (D6FC13F7). Any ideas?

[lbbrhzn]

Everywhere you use _states it should be _status.

Can you enable logging at debug level and upload the log? See https://home-assistant-ocpp.readthedocs.io/en/latest/debugging.html

[lbbrhzn]

The config file should look like this:

ocpp:
  default_authorization_status: Invalid
  authorization_list:
    - id_tag: pulsar
      name: 'My tag'
      authorization_status : Accepted
    - id_tag: CAFEBABE
      name: 'Some other tag'
      authorization_status: Blocked
    - id_tag: DEADBEEF
      name: 'Old tag'
      authorization_status: Expired
    - id_tag: 12341234
      name: 'Invalid tag'
      authorization_status: Invalid

[lbbrhzn]

Here are some log messages to show that it works in my setup:

2022-03-24 22:21:18 INFO (MainThread) [ocpp] pulsar: receive message [2,"76a30e26-81bb-439c-9c2b-d5910745cb78","StartTransaction",{"connectorId": 1,"meterStart": 0,"idTag": "pulsar","timestamp": "2022-03-24T21:21:18Z"}]
2022-03-24 22:21:18 DEBUG (MainThread) [custom_components.ocpp] id_tag='pulsar' found in auth_list, authorization_status='Accepted'
2022-03-24 22:21:18 INFO (MainThread) [ocpp] pulsar: send [3,"76a30e26-81bb-439c-9c2b-d5910745cb78",{"transactionId":1648156878,"idTagInfo":{"status":"Accepted"}}]

@ClemKC can you confirm it works for you as well, so we can close the issue?

[ClemKC]

Hi! Nice, it works properly. I have the same logs procedure as you have. Thank you you can close the issue ;)

[lbbrhzn]

great, thanks for the feedback! We might add some more convenient way to update the authorization list in the future, but this should cover the immediate needs for now I think.

[ClemKC]

One more comment, is there a way not to restart HA after filling the file of autorization badges? I mean is there another way with for example an automation to add or delete badges?

[ClemKC]

ok sorry I didn't see your comment first ;) Yes it is not expected at this time but maybe in the future. Thanks

[lbbrhzn]

Please submit an enhancement request for this... Not sure what would be both simple to use and easy to implement. I have some ideas, let's discuss in the enhancement request.