cannot connect to newly updated EVduty station firmware that should add OCPP

[zadigre]

Hello Everyone!

My EVduty station was just updated with what I believe OCPP support. the manufacturer told me a few weeks ago that they are working on adding OCPP support... and 2 weeks ago they said it should be released shortly. I just got an update today that added en OCPP URL entry.

so here I am with trying to add it to home assistant.

It looks like the station is trying to connect to the integration... but there's some kind of error. see below log... is there anything I can do to fix this problem? I already tried the skip validation option.

2022-06-27 20:42:12 INFO (MainThread) [websockets.server] connection open 2022-06-27 20:42:12 WARNING (MainThread) [custom_components.ocpp] Skipping websocket subprotocol validation 2022-06-27 20:42:12 INFO (MainThread) [custom_components.ocpp] Charger websocket path=/ocpp/EVC30-24541 2022-06-27 20:42:12 INFO (MainThread) [custom_components.ocpp] Charger EVC30-24541 reconnected to 0.0.0.0:8500. 2022-06-27 20:42:12 DEBUG (MainThread) [custom_components.ocpp] Reconnect websocket to EVC30-24541 2022-06-27 20:42:14 INFO (MainThread) [ocpp] EVC30-24541: send [2,"f6ee754e-9506-4d5c-a546-4e845c97c9e3","GetConfiguration",{"key":["SupportedFeatureProfiles"]}] 2022-06-27 20:42:14 INFO (MainThread) [ocpp] EVC30-24541: receive message [3,"f6ee754e-9506-4d5c-a546-4e845c97c9e3",{"configurationKey":[{"key":"WifiSSID","readonly":0,"value":"beaulac2"},{"key":"ChargeAccessType","readonly":0,"value":1},{"key":"MaxCurrent","readonly":0,"value":30},{"key":"InputVoltage","readonly":0,"value":240},{"key":"LocalIPAddress","readonly":1,"value":"192.168.25.217"},{"key":"MACAddress","readonly":1,"value":"A4:CF:12:E9:DF:FF"},{"key":"Firmware_A_Version","readonly":1,"value":"1.3.0.28"},{"key":"Firmware_B_Version","readonly":1,"value":"3.0.0.14"},{"key":"PSLVL1_BreakerValue","readonly":0,"value":40},{"key":"PSLVL1_LinkID","readonly":0,"value":1},{"key":"PSLVL1_ID","readonly":0,"value":1},{"key":"PSLVL1_TotalNumber","readonly":0,"value":1},{"key":"PSLVL2_BreakerValue","readonly":0,"value":40},{"key":"PSLVL2_LinkID","readonly":0,"value":2},{"key":"PSLVL2_ID","readonly":0,"value":1},{"key":"PSLVL2_TotalNumber","readonly":0,"value":1},{"key":"ChargeSessionEndingType","readonly":0,"value":0},{"key":"FallbackMode","readonly":0,"value":0},{"key":"WifiRSSI","readonly":0,"value":-49},{"key":"RampUpCurrentOutputAfterBoot","readonly":0,"value":0}]}] 2022-06-27 20:42:14 ERROR (MainThread) [custom_components.ocpp] Unexpected exception in connection to 'EVC30-24541': 'TypeConstraintViolationError: Payload for Action is syntactically correct but at least one of the fields violates data type constraints (e.g. “somestring”: 12), {'cause': "0 is not of type 'boolean'"}' Traceback (most recent call last): File "/usr/local/lib/python3.9/site-packages/ocpp/messages.py", line 200, in validate_payload validator.validate(message.payload) File "/usr/local/lib/python3.9/site-packages/jsonschema/validators.py", line 267, in validate raise error jsonschema.exceptions.ValidationError: 0 is not of type 'boolean' Failed validating 'type' in schema['properties']['configurationKey']['items']['properties']['readonly']: {'type': 'boolean'} On instance['configurationKey'][0]['readonly']: 0 During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/config/custom_components/ocpp/api.py", line 913, in run await asyncio.gather(*self.tasks) File "/config/custom_components/ocpp/api.py", line 409, in post_connect await self.get_supported_features() File "/config/custom_components/ocpp/api.py", line 483, in get_supported_features resp = await self.call(req) File "/usr/local/lib/python3.9/site-packages/ocpp/charge_point.py", line 289, in call validate_payload(response, self._ocpp_version) File "/usr/local/lib/python3.9/site-packages/ocpp/messages.py", line 203, in validate_payload raise TypeConstraintViolationError(details={"cause": e.message}) ocpp.exceptions.TypeConstraintViolationError: TypeConstraintViolationError: Payload for Action is syntactically correct but at least one of the fields violates data type constraints (e.g. “somestring”: 12), {'cause': "0 is not of type 'boolean'"} 2022-06-27 20:42:14 DEBUG (MainThread) [custom_components.ocpp] Closing websocket to 'EVC30-24541' 2022-06-27 20:42:15 INFO (MainThread) [custom_components.ocpp] Charger EVC30-24541 disconnected from 0.0.0.0:8500. 2022-06-27 20:42:15 INFO (MainThread) [websockets.server] connection closed

[drc38]

Suggest sending the log to the manufacturer and raising a ticket. It is not responding to the Ocpp standard when sent [2,"f6ee754e-9506-4d5c-a546-4e845c97c9e3","GetConfiguration",{"key":["SupportedFeatureProfiles"]}]

[zadigre]

@drc38 thanks! I'll do this immediately and report back if they fix it.

[zadigre]

Hi!

I just got a reply from the manufacturer... it's in French. La clé « SupportedFeatureProfiles » n’est pas supportée dans notre configuration. Le profil supporté à date avec notre borne est le ‘core’. Je vous ai joint un pdf en pièce jointe de la norme OCPP 1.6 vous trouverai ce profil à la page 16, 17 et 18 (toutes les fonctions de ce profil sont inclus dans notre OCPP). La requête getConfiguration() supportée par notre borne ne contient aucune Key, c’est comme un getconfig généralisé. En réponse à cela on va envoyé toutes les informations nécessaire pour la gestion de l’APP (backend).

my own translation: the "SupportedFeatureProfiles" is not supported with our configuration. The supported profile on our station is "core". [... talking about the attached pdf with the OCPP 1.6 specification... page 16 to 18... all features for this profile are included in the OCPP implementation]. the supported getConfiguration() request on our station doesn't have any key... it's a generic getconfig.

my request has been sent to their senior backend dev to see if there's anything else that can be done.

in the meantime, is there anything we can do to get this working with my evduty station? ocpp-1.6.pdf

[drc38]

You can comment out await self.get_supported_features() in post_connect. You may have to comment out other get_configuration lines as well as their response to an unsupported key is not Ocpp compliant.

[drc38]

If the list of keys in the request PDU is empty or missing (it is optional), the Charge Point SHALL return a list of all configuration settings in GetConfiguration.conf. Otherwise Charge Point SHALL return a list of recognized keys and their corresponding values and read-only state. Unrecognized keys SHALL be placed in the response PDU as part of the optional unknown key list element of GetConfiguration.conf.

[zadigre]

@drc38 thanks again for your comments. I've shared this thread with the manufacturer... their dev is apparently looking at this right now.

[github-actions[bot]]

Stale issue message

[zadigre]

Manufacturer still hasn’t updated firmware yet.

[zadigre]

Hello Everyone,

I've got a beta firmware installed my my charging station... this should fix the "incompatibilities" but it's not.

here's the log done with the previous version of OCPP (before the update has been released this week):

2022-10-05 18:11:11.051 INFO (MainThread) [custom_components.ocpp] Charger websocket path=/ocpp/EVC30-24541
2022-10-05 18:11:11.051 INFO (MainThread) [custom_components.ocpp] Charger EVC30-24541 reconnected to 0.0.0.0:9000.
2022-10-05 18:11:11.052 DEBUG (MainThread) [custom_components.ocpp] Reconnect websocket to EVC30-24541
2022-10-05 18:11:13.054 INFO (MainThread) [ocpp] EVC30-24541: send [2,"a5317123-8ed6-41e5-933b-819a649109e3","GetConfiguration",{"key":["SupportedFeatureProfiles"]}]
2022-10-05 18:11:13.203 INFO (MainThread) [ocpp] EVC30-24541: receive message [3,"a5317123-8ed6-41e5-933b-819a649109e3",{"configurationKey":[{"key":"SupportedFeatureProfiles","readonly":true,"value":"Core"}]}]
2022-10-05 18:11:13.204 DEBUG (MainThread) [custom_components.ocpp] Feature profiles returned: Profiles.CORE
2022-10-05 18:11:13.205 INFO (MainThread) [ocpp] EVC30-24541: send [2,"92979304-e0c4-49fa-bef2-538c6b1a0e52","GetConfiguration",{"key":["NumberOfConnectors"]}]
2022-10-05 18:11:13.497 INFO (MainThread) [ocpp] EVC30-24541: receive message [3,"92979304-e0c4-49fa-bef2-538c6b1a0e52",{"configurationKey":[{"key":"NumberOfConnectors","readonly":true,"value":1}]}]
2022-10-05 18:11:13.499 ERROR (MainThread) [custom_components.ocpp] Unexpected exception in connection to 'EVC30-24541': 'TypeConstraintViolationError: Payload for Action is syntactically correct but at least one of the fields violates data type constraints (e.g. “somestring”: 12), {'cause': "1 is not of type 'string'"}'

it looks like it's expecting a string when reading Number of connectors... but this is not what is received. Apparently, it's an integer. And to my best of knowledge (and this is what the manufacturer told me), it should be an integer according to point 9.1.19 of the ocpp 1.6 document.

is this something that needs to be fixed in the ocpp implementation of this integration or my charging station manufacturer needs to adjust something from their side?

sadly I cannot try the new OCPP release of this week immediately... my charging stating has been reprogrammed with the stable firmware automatically (a newer stable release will be available later this month).

[drc38]

You'd need to do some research but I think the ocpp1.6 schema still requires it to be passed in json as a string. Validation of messages is not part of the HA integration and is handled upstream by this library https://github.com/mobilityhouse/ocpp

[drc38]

They need to be using the official schemas eg for GetConfigurationResponse.json:

{
    "$schema": "http://json-schema.org/draft-04/schema#",
    "id": "urn:OCPP:1.6:2019:12:GetConfigurationResponse",
    "title": "GetConfigurationResponse",
    "type": "object",
    "properties": {
        "configurationKey": {
            "type": "array",
            "items": {
                "type": "object",
                "properties": {
                    "key": {
                        "type": "string",
                        "maxLength": 50
                    },
                    "readonly": {
                        "type": "boolean"
                    },
                    "value": {
                        "type": "string",
                        "maxLength": 500
                    }
                },
                "additionalProperties": false,
                "required": [
                    "key",
                    "readonly"
                ]
            }
        },
        "unknownKey": {
            "type": "array",
            "items": {
                "type": "string",
                "maxLength": 50
            }
        }
    },
    "additionalProperties": false
}

[zadigre]

thanks @drc38 for your help. they finally switched all integer to string in their code because apparently this is what ocpp standard is supposed to be.

now they need to fix the latency test issue... not sure here what could be the cause... seeing this every 2 minutes and reconnect after 2 seconds.

2022-10-17 20:30:45.586 DEBUG (MainThread) [custom_components.ocpp] Connection latency from 'central' to 'EVC30-24541': ping=1.0 ms, pong=20000 ms 2022-10-17 20:31:25.589 DEBUG (MainThread) [custom_components.ocpp] Connection latency from 'central' to 'EVC30-24541': ping=1.0 ms, pong=20000 ms 2022-10-17 20:32:05.591 DEBUG (MainThread) [custom_components.ocpp] Connection latency from 'central' to 'EVC30-24541': ping=1.0 ms, pong=20000 ms 2022-10-17 20:32:05.592 DEBUG (MainThread) [custom_components.ocpp] Connection to 'EVC30-24541' timed out after '2' ping tries 2022-10-17 20:32:05.592 DEBUG (MainThread) [custom_components.ocpp] Closing websocket to 'EVC30-24541' 2022-10-17 20:32:15.667 INFO (MainThread) [custom_components.ocpp] Charger EVC30-24541 disconnected from 0.0.0.0:9000.

the station did send this... 2022-10-17 19:51:35.560 INFO (MainThread) [ocpp] EVC30-24541: send [2,"402c3023-ffd6-40c1-9fe5-10beaea88f15","GetConfiguration",{"key":["WebSocketPingInterval"]}] 2022-10-17 19:51:35.849 INFO (MainThread) [ocpp] EVC30-24541: receive message [3,"402c3023-ffd6-40c1-9fe5-10beaea88f15",{"unknownKey":["WebSocketPingInterval"]}] 2022-10-17 19:51:35.851 WARNING (MainThread) [custom_components.ocpp] WebSocketPingInterval is unknown (not supported) which is the correct answer apparently if websocketpinginterval is not supported.

is this something missing from the charging station... like a standard ocpp that is not implemented?

[drc38]

It is a websocket standard to respond to a ping with a pong. The fact it does not support WebSocketPingInterval should not matter. Is your wifi connection rssi solid?

[zadigre]

yes very solid -48 dBm. router is less than 10 feet from charging station. if I put a high ping retry... it stays connected until it reaches the retry count. it will reconnect immediately after 3 seconds. besides this ping/pong disconnections, I've not see any other disconnection.

[zadigre]

I've sent a message to the manufacturer regarding the ping/pong reply that should be supported. everything else is working fine... I'm very near to get a working station with this ocpp integration.

[zadigre]

here's the last answer from the charging station manufacturer.

it's apparently unusual for the server to send a ping. Thus the charging station will not reply to with a pong. They are saying it's the "client" (here the charging station) that should do it... and they are doing it by default every 5 seconds I believe.

yes I read point 9.1.34... and it's taking about server sending ping and client replying with pong... but apparently manufacturer is not interested to add this feature.

is there a way to disable this ping/pong from the server? if not, I'll start looking for an other charging station that is really supported.

[drc38]

See https://www.rfc-editor.org/rfc/rfc6455#section-5.5.2 replying with a pong is not optional. If you want to disable you would need to create a patch for the function monitor_connection eg skip pinging if interval is 0, and submit a PR.

[zadigre]

Thanks a lot for your comment. I’ve submitted this link to the manufacturer… I don’t put any hope in this. Lets see what they are going to do.

I will not submit a patch for this as I don’t want to encourage a company that doesn’t follow the rfc. If they don’t do it, I’ll simply start looking for something else

[zadigre]

Hello all. Just got a final email from the manufacturer... they have no intention to push this further... they are saying no more work will be done on their OCPP implementation because it's compliant. These are essentially their words... not mine.

At this point, it's just the pong reply that needs to be adjusted/added in their firmware... I'm not sure why they do not want to do it.

Unless someone here wants to push this further in the OCPP code, we can close this bug report (and maybe tag it as a charger bug) as I have no intention to submit a PR

[olivierjag2]

CAN you contact me? I have issue with my evduty

[zadigre]

CAN you contact me? I have issue with my evduty

You should contact EVduty directly if you need support