Grizzl-E Smart firmware v05.621

[hacsjalano]

Version of the custom_component

v0.4.23

Configuration

logger: default: info logs: custom_components.ocpp: critical websocket: debug

Add your logs here.

Describe the bug

Upon connecting the Grizzl-E Smart to the homeassistant instance, I see these every 2 seconds in the logs: 2022-03-15 15:45:26 INFO (MainThread) [websockets.server] connection open 2022-03-15 15:45:26 INFO (MainThread) [websockets.server] connection closed

Some background - Grizzl-E Smart recently updated their firmware, which has been buggy with OCPP before. It now connects to Chargelab by default but has an option to input a OCPP URL. I unfortunately had the version which did not allow a custom URL to be input until recently, so I'm a bit late to the party but I'd like to try to help figure out if this charger can work with the OCPP plugin.

Any suggestions for how I can increase the verbosity of the logs to help figure out what's going on? Obviously these disconnects are a problem and I realize it's not enough information to go on; I'm open to try some new things to figure out what's going wrong!

Debug log

2022-03-15 15:45:24 INFO (MainThread) [websockets.server] connection closed
2022-03-15 15:45:26 INFO (MainThread) [websockets.server] connection open
2022-03-15 15:45:26 INFO (MainThread) [websockets.server] connection closed
2022-03-15 15:45:28 INFO (MainThread) [websockets.server] connection open
2022-03-15 15:45:28 INFO (MainThread) [websockets.server] connection closed
2022-03-15 15:45:30 INFO (MainThread) [websockets.server] connection open
2022-03-15 15:45:30 INFO (MainThread) [websockets.server] connection closed

[hacsjalano]

I forgot to add - it appears the Grizzl-E isn't ever fully connecting to the OCPP component, because the OCPP component never shows the charger. So it sure seems like something is broken at the outset!

[lbbrhzn]

Please enable more detailed logging by updating your configuration.yaml.

See https://home-assistant-ocpp.readthedocs.io/en/latest/debugging.html

[hacsjalano]

I have this enabled; unfortunately that's all I see in my /root/config/home-assistant.log. Is there a more verbose setting?

[hacsjalano]

I changed the setting from: custom_components.ocpp: critical to custom_components.ocpp: debug

And now this is all I see:

2022-03-15 16:57:23 INFO (MainThread) [websockets.server] connection open 2022-03-15 16:57:23 ERROR (MainThread) [custom_components.ocpp] Client hasn't requested any Subprotocol. Closing connection 2022-03-15 16:57:23 INFO (MainThread) [websockets.server] connection closed 2022-03-15 16:57:25 INFO (MainThread) [websockets.server] connection open 2022-03-15 16:57:25 ERROR (MainThread) [custom_components.ocpp] Client hasn't requested any Subprotocol. Closing connection 2022-03-15 16:57:25 INFO (MainThread) [websockets.server] connection closed

[lbbrhzn]

Right, this shows the reason for the disconnects.

The OCPP standard uses websockets to transport messages between the charger and the central management system. When connecting to a websocket the client must specify the subprotocol, this should be ocpp1.6 to make it work. Your charger does not specify this subprotocol at all, so our central server drops the connection. Your charger then tries again after a few seconds.

Unfortunately, this means the charger / firmware version is not ocpp compliant. Please contact your manufacturer.

[lbbrhzn]

If you're feeling adventurous we could try skipping the check for the subprotocol. There is already a checkbox for skipping validation, I could add some code to make that also skip checking for the subprotocol. No guarantees that it will work though: if the grizzl-E is already non-compliant making the first connection there is a high chance the rest will not work either.

[hacsjalano]

I am feeling adventurous! I do think it will work because I did get it working before, but in a totally hacky way that I didn't feel appropriate to bother anyone with. Back when I had firmware version 5.53, the infamous version that removed the ability to add a custom URL, I got it to work with Home Assistant by overriding the DNS in my router to point acharger.ca at my Home Assistant instance and changing the OCPP server to listen on port 8080. That faked out the Grizzl-E to think it was connecting the acharger.ca:8080 server and with OCPP plugin version 0.4.10, nearly everything worked. I got status, the amount of energy used when completing a charge, etc. I was not happy with this hack, but it at least convinced me that things could work, if and when they finally fixed their firmware to allow me to put a URL in again. Well, that time finally came last week, when the manufacturer gave me a copy of firmware 4.53 to downgrad by downloading directly to the Grizzl-E via a USB cable. So I tried that version out against 0.4.10 and the latest at the time, and unfortunately nothing worked. But since I knew this was just an interim release to get me back online because they told me that firmware 5.61 was coming once I connected to Chargelab, I again, decided to give them a chance and hope that with this version, things would finally work again. So I have bugged them again, but they are a bit slow moving.

Anyway, I'm willing to try all kinds of crazy stuff if you're willing! I've got nothing to lose! :)

[lbbrhzn]

ok, please try 0.4.24 with the configuration option 'Skip OCPP schema validation' selected

[hacsjalano]

2022-03-16 08:10:01 INFO (MainThread) [websockets.server] connection open 2022-03-16 08:10:01 WARNING (MainThread) [custom_components.ocpp] Skipping websocket subprotocol validation 2022-03-16 08:10:01 INFO (MainThread) [websockets.server] connection closed

Is there a way I can dump the interaction? Something I can copy to the manufacturer? I have tcpdump, but if there is some way to log websockets conversation that would be easier.

[lbbrhzn]

You could try setting websockets:debug or websockets.server:debug in configuration.yaml.

The websocket connection closes before any data is transmitted, so the home assistant log will not be much help. Better capture the IP packets using wireshark/tcpdump. You can filter for the packets between your home assistant server and your charge point using their IP addresses. I expect this to be only a few packets....

[lbbrhzn]

Here's what I get for a working connection with websockets.server:debug in configuration.yaml:

2022-03-16 16:33:08 INFO (MainThread) [websockets.server] server listening on 0.0.0.0:9000
2022-03-16 16:35:40 DEBUG (MainThread) [websockets.server] = connection is CONNECTING
2022-03-16 16:35:40 DEBUG (MainThread) [websockets.server] < GET /pulsar HTTP/1.1
2022-03-16 16:35:40 DEBUG (MainThread) [websockets.server] < Connection: Upgrade
2022-03-16 16:35:40 DEBUG (MainThread) [websockets.server] < Host: homeassistant.fritz.box:9000
2022-03-16 16:35:40 DEBUG (MainThread) [websockets.server] < Sec-WebSocket-Key: VLpFdctBQgYB6ZokyO2m3Q==
2022-03-16 16:35:40 DEBUG (MainThread) [websockets.server] < Sec-WebSocket-Protocol: ocpp1.6
2022-03-16 16:35:40 DEBUG (MainThread) [websockets.server] < Sec-WebSocket-Version: 13
2022-03-16 16:35:40 DEBUG (MainThread) [websockets.server] < Upgrade: websocket
2022-03-16 16:35:40 DEBUG (MainThread) [websockets.server] < User-Agent: WebSocket++/0.8.2
2022-03-16 16:35:40 DEBUG (MainThread) [websockets.server] > HTTP/1.1 101 Switching Protocols
2022-03-16 16:35:40 DEBUG (MainThread) [websockets.server] > Upgrade: websocket
2022-03-16 16:35:40 DEBUG (MainThread) [websockets.server] > Connection: Upgrade
2022-03-16 16:35:40 DEBUG (MainThread) [websockets.server] > Sec-WebSocket-Accept: hLE0rT2uOtRgVH4VLWoK8K7McNU=
2022-03-16 16:35:40 DEBUG (MainThread) [websockets.server] > Sec-WebSocket-Protocol: ocpp1.6
2022-03-16 16:35:40 DEBUG (MainThread) [websockets.server] > Date: Wed, 16 Mar 2022 15:35:40 GMT
2022-03-16 16:35:40 DEBUG (MainThread) [websockets.server] > Server: Python/3.9 websockets/10.2
2022-03-16 16:35:40 INFO (MainThread) [websockets.server] connection open
2022-03-16 16:35:40 DEBUG (MainThread) [websockets.server] = connection is OPEN
2022-03-16 16:35:40 DEBUG (MainThread) [websockets.server] < TEXT '[2,"4a7920fe-1ded-48ff-b9c8-ff8f33bc8118","Boot...: "5.5.10","imsi": ""}]' [318 bytes]
2022-03-16 16:35:40 DEBUG (MainThread) [websockets.server] > TEXT '[3,"4a7920fe-1ded-48ff-b9c8-ff8f33bc8118",{"cur...0,"status":"Accepted"}]' [129 bytes]
2022-03-16 16:35:40 DEBUG (MainThread) [websockets.server] < TEXT '[2,"336a0acf-3117-4e72-99c6-f4ae31acb131","Stat...2022-03-16T15:35:40Z"}]' [211 bytes]
2022-03-16 16:35:40 DEBUG (MainThread) [websockets.server] > TEXT '[3,"336a0acf-3117-4e72-99c6-f4ae31acb131",{}]' [45 bytes]
2022-03-16 16:35:40 DEBUG (MainThread) [websockets.server] < TEXT '[2,"654f6701-639c-4398-8608-a0c7d8287465","Stat...2022-03-16T15:35:40Z"}]' [211 bytes]
2022-03-16 16:35:40 DEBUG (MainThread) [websockets.server] > TEXT '[3,"654f6701-639c-4398-8608-a0c7d8287465",{}]' [45 bytes]

[lbbrhzn]

I've added this info also to https://home-assistant-ocpp.readthedocs.io/en/latest/debugging.html

[hacsjalano]

Thanks for the additional debugging info! Here's what I'm seeing:

2022-03-16 08:56:38 DEBUG (MainThread) [websockets.server] = connection is CONNECTING 2022-03-16 08:56:38 DEBUG (MainThread) [websockets.server] < GET / HTTP/1.1 2022-03-16 08:56:38 DEBUG (MainThread) [websockets.server] < Host: homeassistant.local 2022-03-16 08:56:38 DEBUG (MainThread) [websockets.server] < Sec-WebSocket-Key: MDEyMzQ1Njc4OWFiY2RlZg== 2022-03-16 08:56:38 DEBUG (MainThread) [websockets.server] < Upgrade: websocket 2022-03-16 08:56:38 DEBUG (MainThread) [websockets.server] < Connection: Upgrade 2022-03-16 08:56:38 DEBUG (MainThread) [websockets.server] < Sec-WebSocket-Version: 13 2022-03-16 08:56:38 DEBUG (MainThread) [websockets.server] < User-Agent: TinyWebsockets Client 2022-03-16 08:56:38 DEBUG (MainThread) [websockets.server] < Origin: https://github.com/gilmaimon/TinyWebsockets 2022-03-16 08:56:38 DEBUG (MainThread) [websockets.server] > HTTP/1.1 101 Switching Protocols 2022-03-16 08:56:38 DEBUG (MainThread) [websockets.server] > Upgrade: websocket 2022-03-16 08:56:38 DEBUG (MainThread) [websockets.server] > Connection: Upgrade 2022-03-16 08:56:38 DEBUG (MainThread) [websockets.server] > Sec-WebSocket-Accept: BACScCJPNqyz+UBoqMH89VmURoA= 2022-03-16 08:56:38 DEBUG (MainThread) [websockets.server] > Date: Wed, 16 Mar 2022 15:56:38 GMT 2022-03-16 08:56:38 DEBUG (MainThread) [websockets.server] > Server: Python/3.9 websockets/10.2 2022-03-16 08:56:38 INFO (MainThread) [websockets.server] connection open 2022-03-16 08:56:38 DEBUG (MainThread) [websockets.server] = connection is OPEN 2022-03-16 08:56:38 WARNING (MainThread) [custom_components.ocpp] Skipping websocket subprotocol validation 2022-03-16 08:56:38 DEBUG (MainThread) [websockets.server] = connection is CLOSING 2022-03-16 08:56:38 DEBUG (MainThread) [websockets.server] > CLOSE 1000 (OK) [2 bytes] 2022-03-16 08:56:38 DEBUG (MainThread) [websockets.server] < CLOSE 1000 (OK) [2 bytes] 2022-03-16 08:56:38 DEBUG (MainThread) [websockets.server] x half-closing TCP connection 2022-03-16 08:56:38 DEBUG (MainThread) [websockets.server] = connection is CLOSED 2022-03-16 08:56:38 INFO (MainThread) [websockets.server] connection closed

[wipeout666]

@hacsjalano, I am still on 5.43 and I am trying to update it to some newer version. I've reached out to united charger to get the .bin so that I can download myself using epstool. They said to contact chargelab instead and ask them to download it on my device. So far, chargelab did not respond (ignore) to my request after one week.

For which version do you have a .bin? Who gave it to you; united charger or chargelab ?

Thanks!

[hacsjalano]

@wipeout666 United Charger sent me the 5.43 firmware directly. Chargelab as far as I know, will only update the firmware once you connect to them; they will do it over the air after about a week, supposedly. Well, I waited a week then opened a ticket with support@chargelab.co and they told me it would happen automatically. Still didn't happen - 2 days later I asked when it was happening and a day later, someone said "it happened yesterday". So they aren't exactly the most responsive either. :(

I'm giving United Chargers a chance to respond to my questions about what the state of the firmware is - hopefully the new version that Chargelab created isn't so terribly borked it can't be made to work.

I figure if Chargelab doesn't fix their firmware I can always re-download the 5.43 firmware directly. Be aware - if you do this you'll need a right angle micro-usb cable; the clearance inside the case and the ESP32 is tight. I picked one up at Amazon for about $9 and used a Windows 10 virtual machine to do the downgrade. Keith Newman at United Chargers is the one who hooked me up with the older firmware and instructions on how to load it.

[hacsjalano]

Also, right now the state of the Chargelab app with the Grizzl-E is very basic. It only promises to do scheduling. I tried a few charges with it and the kWh reported looks to be exactly the same data I was getting using this OCPP integration and Home Assistant, so my main goals is to just fine a firmware that works, or works well enough that I can get Home Assistant integrated then I'm not touching the firmware again.

[hacsjalano]

@wipeout666 Does version 5.43 work with the OCPP integration for you now?

[wipeout666]

I'll try tonight.

Why do you need a right angle USB at all? Just keep the cover open when you plug it into 240v, and don't put your fingers in there 😜

[hacsjalano]

This is why :

[wipeout666]

Oh. My board is different. It's coming straight instead.

[wipeout666]

My board.

[lbbrhzn]

Thanks for the additional debugging info! Here's what I'm seeing:

...

Ok, your charger does not specify a subprotocol, so is not OCPP compliant. The connection is closed from the server side, even though the subprotocol validation is skipped. This needs to be investigated further...

[hacsjalano]

Thanks - I've got tickets opened at both Chargelab and United Chargers (the makers of Grizzl-E) to see who is going to take responsibility. I've posted the interaction to them. If you don't mind leaving this issue open for tracking that would be great - if not, maybe there is a better place to keep this going I'm open to moving there instead.

[wipeout666]

The charger is at version 5.43 and OCPP is at version 4.25. Disabling scheme validation, I get a bunch of connects/disconnects & all sensors show "unavailable":

2022-03-16 19:24:07 INFO (MainThread) [websockets.server] connection open 2022-03-16 19:24:07 INFO (MainThread) [websockets.server] connection closed 2022-03-16 19:24:09 INFO (MainThread) [websockets.server] connection open 2022-03-16 19:24:09 INFO (MainThread) [websockets.server] connection closed 2022-03-16 19:24:11 INFO (MainThread) [websockets.server] connection open 2022-03-16 19:24:11 INFO (MainThread) [websockets.server] connection closed 2022-03-16 19:24:13 INFO (MainThread) [websockets.server] connection open 2022-03-16 19:24:13 INFO (MainThread) [websockets.server] connection closed 2022-03-16 19:24:15 INFO (MainThread) [websockets.server] connection open 2022-03-16 19:24:15 INFO (MainThread) [websockets.server] connection closed 2022-03-16 19:24:17 INFO (MainThread) [websockets.server] connection open 2022-03-16 19:24:17 INFO (MainThread) [websockets.server] connection closed 2022-03-16 19:24:19 INFO (MainThread) [websockets.server] connection open 2022-03-16 19:24:19 INFO (MainThread) [websockets.server] connection closed

Keeping the scheme validation, I get the websocket error & a bit more sensors: 2022-03-16 19:29:41 ERROR (MainThread) [ocpp] Unable to parse message: '[3,"f8f25f09-47f4-48ec-82c2-239a0b6ed683",{"configurationKey":[]', it doesn't seem to be valid OCPP: FormatViolationError: Message is not valid JSON: Expecting ',' delimiter: line 1 column 65 (char 64), {}

[tube0013]

Are there any open source fw's that could be made to work with the grizzl-e? seems like being esp32 based it might be a more viable solution. https://github.com/matth-x/ArduinoOcpp possibly? would need to trace out the gpio pins I would think - but just browsing the code there not really saying any mention of gpio.

[wipeout666]

Are the safety features purely hardware or some security requirements are handled by the ESP32? I'd be hesitant to do this because of safety...

[jsb5151]

I'm on FW 5.43, should I stick to that one or upgrade to 5.621? Does anyone have the flash file and/or procedure?

I can get information using 5.43, but the Availability switch does nothing except "reboot" the Grizzl-E (at least according to the popups I get in HA).

[jsb5151]

Not sure if this is related, but I get "Charger Rebooted" pop-ups every few minutes now...

[drc38]

Are the safety features purely hardware or some security requirements are handled by the ESP32? I'd be hesitant to do this because of safety...

From your photo it looks like there'll be another controller (SAE J1772 driver) that handles the protection and signalling to the car. The ESP32 looks to be a daughter board for comms, worth checking in with @matth-x as he has been working on making the ArduinoOcpp library compatible with our integration. The pinouts are described here https://github.com/matth-x/ArduinoOcpp/tree/master/examples/SECC

[tube0013]

My board.

I have the same one. It's connected with an 8 pin header to the main board

to get a look at any of the controllers on the main board would need to remove the board from the case as they are likely on the back side.

[hacsjalano]

I'm on FW 5.43, should I stick to that one or upgrade to 5.621? Does anyone have the flash file and/or procedure?

I can get information using 5.43, but the Availability switch does nothing except "reboot" the Grizzl-E (at least according to the popups I get in HA).

I wouldn't upgrade yet. The only way to get to 5.621 is to sign up with an account at Chargelab, and wait for them to push the software to you. And so far my experience is it's not working with anything other than Chargelab. And both United Chargers and Chargelab support have been totally silent in my support tickets to them.

@jsb5151 What did you do to get FW 5.43 to work, and which version of the OCPP integration are you using? When I was briefly on 5.43, it did not work with whatever the most recent version of the OCPP integration was at the time; it constantly connected and re-connected in and endless loop, filling my notifications with "charger booted" messages every 30 seconds or so. Did you have that issue too?

[jsb5151]

@hacsjalano, yes, same symptoms - I just gave up and disconnected. I'm in the process of trying to get my hands on the latest firmware; it seems we can still enter a custom OCPP server at the latest version (they removed it and added it back). I hooked it up to ChargeLab, but I have to wait for them to "register" it which may take a few days... sigh.

[wipeout666]

@tube0013 In the other thread, you are showing screenshots of what seems to be a valid combination of FW / plugin. Can you reproduce this working condition?

[tube0013]

I'm not able to any longer, I get the reboot notifications now... noticed a few weeks ago and didn't look into it, then today after pulling the chargers plug to take a closer look at the board, after plugging it back in, by the time I looked at HA again I had 300+ notifications about the reboot.

I was hoping to find some fcc internal photos, but they fcc-id on the device is just to a SI_Labs wifi module - sigh.

[hacsjalano]

FYI I tested out this firmware with a different OCPP server, "SteVe": https://github.com/RWTH-i5-IDSG/steve

And on this version it also dies with the same issue - no OCPP version:

org.springframework.web.socket.server.HandshakeFailureException: No protocol (OCPP version) is specified.

I've sent this to both Chargelab and United Chargers support, but again, no response from either as of yet.

What's interesting is that on the SteVe compatible chargers page, the Grizzl-E is listed as working as of version firmware v5.41.

[wipeout666]

Back of the PCB there's another microcontroller, a STM32F730. There's a few rail to rail op amps and other ICs with unreadable markings due to the conformal coating. I feel that this ARM uC is dealing with everything but the WI-FI, while the ESP32 deals with OCPP.

There's a 6 pins IC that has 2 pins raised with rewires for a rework. The quality of the rework isn't the best I've seen, maybe due to my high reliabily standard for building spacecrafts?

Funny thing is that everything is conformal coated, but not the ESP32. Kinda pointless ...

https://www.dropbox.com/s/oqs1axrikbmcvu1/2022-03-17%2022.15.57.jpg?dl=0 https://www.dropbox.com/s/m08j4fcvnzp3dsn/2022-03-17%2022.16.09.jpg?dl=0

[tube0013]

Thanks for the snaps of the back.

I opened an issue here:

https://github.com/matth-x/ArduinoOcpp/issues/55

It's pretty easy to see the traces off the esp32 to see which gpio's are in use so maybe just some trial and error ⚡️😂

[matth-x]

Hi, thank you for involving me in the discussion. My OCPP client is able to connect to the HA OCPP integration now and it looks promising, however I wasn't able to test it with the normal HA routines yet so I haven't posted an update so far.

@drc38 has linked the right starting point for a port to to the Grizzl-E. The SECC sketch is the source for a communication controller just like you assume the ESP32 on the Grizzl-E to be. Probably, it will need some customization as the communication on the Grizzl-E board likely works differently. But the OCPP communication will be fine as HA will become a supported backend soon.

[hacsjalano]

https://grizzl-e.com/wp-content/uploads/2022/03/FW5.43-USB-Update.zip

United Charges has posted the Firmware 5.43 on their website, which includes instructions and the esptool.exe for flashing.

[wipeout666]

@hacsjalano Thanks. I suppose they posted that for users stuck with 5.53 unable to connect to chargelab.

[zer03Four]

Has anyone had the 5.43 firmware working with the HA integration?

[wipeout666]

None that I've heard of.

[hacsjalano]

For me, the integration did work, and quite well, with my Grizzl-E from Nov 2021 to Jan 2022. That's what's frustrating to me.

But I can't reproduce those conditions anymore, because I can't grab whatever firmware I was on back when I first bought the device (I didn't check what it was) nor can I grab version 5.53, which was the last version I was able to get working. I do know that 5.53 and this integration v4.10 did work.

Sadly I can't get back to that state now, which would probably be very useful for helping the developer with figuring out what's wrong now. :(

[hacsjalano]

@zer03Four @wipeout666

User malaiwah did get it working back on Dec 10th 2021 with firmware version 5.43, according to this:

https://github.com/lbbrhzn/ocpp/issues/224

Back then it would have been integration version v0.3.21

If anyone knows how to install an older version of the integration we can test it with the posted firmwmare from United Chargers.

EDIT: I tried the "re-download" option on the HACS control panel, and it only goes back as far as v0.4.22.

[drc38]

You can probably copy the url to older versions and add as per https://hacs.xyz/docs/faq/custom_repositories

[jsb5151]

Well, I'm now stuck in the same pattern. I got upgraded to latest FW by ChargeLab, and reconfigured the Grizzl-E to talk to my OCPP component:

2022-03-22 16:44:51 INFO (MainThread) [websockets.server] connection open 2022-03-22 16:44:51 WARNING (MainThread) [custom_components.ocpp] Skipping websocket subprotocol validation 2022-03-22 16:44:51 INFO (MainThread) [websockets.server] connection closed

...over and over again.

QQ - could it be expecting a secure websocket connection? Is there a way we could try this?

[jsb5151]

The plot thickens:

`2022-03-22 16:49:47 DEBUG (MainThread) [websockets.server] = connection is CONNECTING

2022-03-22 16:49:47 DEBUG (MainThread) [websockets.server] < GET / HTTP/1.1

2022-03-22 16:49:47 DEBUG (MainThread) [websockets.server] < Host: REDACTED

2022-03-22 16:49:47 DEBUG (MainThread) [websockets.server] < Sec-WebSocket-Key: ReDaCtEd!==

2022-03-22 16:49:47 DEBUG (MainThread) [websockets.server] < Upgrade: websocket

2022-03-22 16:49:47 DEBUG (MainThread) [websockets.server] < Connection: Upgrade

2022-03-22 16:49:47 DEBUG (MainThread) [websockets.server] < Sec-WebSocket-Version: 13

2022-03-22 16:49:47 DEBUG (MainThread) [websockets.server] < User-Agent: TinyWebsockets Client

2022-03-22 16:49:47 DEBUG (MainThread) [websockets.server] < Origin: https://github.com/gilmaimon/TinyWebsockets

2022-03-22 16:49:47 DEBUG (MainThread) [websockets.server] > HTTP/1.1 101 Switching Protocols

2022-03-22 16:49:47 DEBUG (MainThread) [websockets.server] > Upgrade: websocket

2022-03-22 16:49:47 DEBUG (MainThread) [websockets.server] > Connection: Upgrade

2022-03-22 16:49:47 DEBUG (MainThread) [websockets.server] > Sec-WebSocket-Accept: ReDaCtEd!=

2022-03-22 16:49:47 DEBUG (MainThread) [websockets.server] > Date: Tue, 22 Mar 2022 20:49:47 GMT

2022-03-22 16:49:47 DEBUG (MainThread) [websockets.server] > Server: Python/3.9 websockets/10.2

2022-03-22 16:49:47 INFO (MainThread) [websockets.server] connection open

2022-03-22 16:49:47 DEBUG (MainThread) [websockets.server] = connection is OPEN

2022-03-22 16:49:47 WARNING (MainThread) [custom_components.ocpp] Skipping websocket subprotocol validation

2022-03-22 16:49:47 DEBUG (MainThread) [websockets.server] = connection is CLOSING

2022-03-22 16:49:47 DEBUG (MainThread) [websockets.server] > CLOSE 1000 (OK) [2 bytes]

2022-03-22 16:49:47 DEBUG (MainThread) [websockets.server] < CLOSE 1000 (OK) [2 bytes]

2022-03-22 16:49:47 DEBUG (MainThread) [websockets.server] x half-closing TCP connection

2022-03-22 16:49:47 DEBUG (MainThread) [websockets.server] = connection is CLOSED

2022-03-22 16:49:47 INFO (MainThread) [websockets.server] connection closed`

So is it looking for wss:// instead of ws://?

[drc38]

You'd need to use wireshark or similar to see what is happening with the port number and packets to confirm if it is trying to use SSL. The first issue as @lbbrhzn mentioned earlier is it is not specifying the OCPP1.6 subprotocol when requesting a connection, no doubt there are probably other issues with their implementation.

[lbbrhzn]

Based on the log, it is not using a wss connnection.

The Sec-Websocket-xxx headers are part of the regular websocket protocol.

[wipeout666]

Their social media administrator is incredible:

URL of thread, in case you'd like to pitch in .... https://www.facebook.com/UnitedChargers/posts/589236412326095?comment_id=615914642991605&reply_comment_id=616470029602733&notif_id=1648067808863192&notif_t=feed_comment_reply&ref=notif