Grizzl-e Smart v2 support

[mkbrown]

Describe the bug

Grizzl-e Smart v2 does not work with the OCPP integration version 0.4.40

Firmware WiFi Module: GWM-07.013-03

Firmware Power Board: GCW-10.18-05.7

To Reproduce

Upon configuring the Grizzl-e, it connects and has the following errors in the HA logs:

This error originated from a custom integration.

Logger: custom_components.ocpp
Source: custom_components/ocpp/api.py:212 
Integration: Open Charge Point Protocol (OCPP) (documentation, issues)
First occurred: September 7, 2023 at 5:42:35 PM (9 occurrences) 
Last logged: 9:29:52 AM

Skipping websocket subprotocol validation

This error originated from a custom integration.

Logger: custom_components.ocpp
Source: custom_components/ocpp/api.py:865 
Integration: Open Charge Point Protocol (OCPP) (documentation, issues) 
First occurred: September 7, 2023 at 5:42:46 PM (8 occurrences) 
Last logged: 9:29:54 AM

Unexpected exception in connection to ‘GRS-170000xxxx’: ‘(“Error code ‘%s’ is not defined by the OCPP specification”, ‘FormationViolation’)’
Traceback (most recent call last):
  File “/config/custom_components/ocpp/api.py”, line 930, in run
    await asyncio.gather(*self.tasks)
  File “/config/custom_components/ocpp/api.py”, line 421, in post_connect
    await self.get_supported_features()
  File “/config/custom_components/ocpp/api.py”, line 495, in get_supported_features
    resp = await self.call(req)
           ^^^^^^^^^^^^^^^^^^^^
  File “/usr/local/lib/python3.11/site-packages/ocpp/charge_point.py”, line 281, in call
    response = await self._get_specific_response(
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File “/config/custom_components/ocpp/api.py”, line 865, in _get_specific_response
    raise resp.to_exception()
          ^^^^^^^^^^^^^^^^^^^
  File “/usr/local/lib/python3.11/site-packages/ocpp/messages.py”, line 439, in to_exception
    raise UnknownCallErrorCodeError(
ocpp.exceptions.UnknownCallErrorCodeError: (“Error code ‘%s’ is not defined by the OCPP specification”, ‘FormationViolation’)

This error originated from a custom integration.

Logger: homeassistant
Source: custom_components/ocpp/api.py:495 
Integration: Open Charge Point Protocol (OCPP) (documentation, issues) 
First occurred: September 7, 2023 at 5:43:16 PM (7 occurrences) 
Last logged: 9:30:24 AM

Error doing job: Task exception was never retrieved
Traceback (most recent call last):
  File “/usr/local/lib/python3.11/asyncio/tasks.py”, line 490, in wait_for
    return fut.result()
           ^^^^^^^^^^^^
  File “/usr/local/lib/python3.11/asyncio/queues.py”, line 158, in get
    await getter
asyncio.exceptions.CancelledError

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File “/usr/local/lib/python3.11/site-packages/ocpp/charge_point.py”, line 281, in call
    response = await self._get_specific_response(
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File “/config/custom_components/ocpp/api.py”, line 862, in _get_specific_response
    resp = await super()._get_specific_response(unique_id, timeout)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File “/usr/local/lib/python3.11/site-packages/ocpp/charge_point.py”, line 315, in _get_specific_response
    response = await asyncio.wait_for(self._response_queue.get(), timeout)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File “/usr/local/lib/python3.11/asyncio/tasks.py”, line 492, in wait_for
    raise exceptions.TimeoutError() from exc
TimeoutError

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File “/config/custom_components/ocpp/api.py”, line 421, in post_connect
    await self.get_supported_features()
  File “/config/custom_components/ocpp/api.py”, line 495, in get_supported_features
    resp = await self.call(req)
           ^^^^^^^^^^^^^^^^^^^^
  File “/usr/local/lib/python3.11/site-packages/ocpp/charge_point.py”, line 285, in call
    raise asyncio.TimeoutError(
TimeoutError: Waited 30s for response on [2,”ce60af0b-a978-47ef-a458-e01567d40ff6”,”GetConfiguration”,{“key”:[“SupportedFeatureProfiles”]}].

Additional context

With websockets debug added.

2023-09-08 15:34:07.476 INFO (MainThread) [ocpp] GRS-170000xxxxx: send [2,"13236754-38b2-424a-a4e3-0f54eeffaf3a","GetConfiguration",{"key":["SupportedFeatureProfiles"]}]
2023-09-08 15:34:07.477 DEBUG (MainThread) [websockets.server] > TEXT '[2,"13236754-38b2-424a-a4e3-0f54eeffaf3a","GetC...rtedFeatureProfiles"]}]' [98 bytes]
2023-09-08 15:34:07.662 DEBUG (MainThread) [websockets.server] < TEXT '[4, "13236754-38b2-424a-a4e3-0f54eeffaf3a", "FormationViolation", ""]' [69 bytes]
2023-09-08 15:34:07.663 INFO (MainThread) [ocpp] GRS-170000xxxxx: receive message [4, "13236754-38b2-424a-a4e3-0f54eeffaf3a", "FormationViolation", ""]
2023-09-08 15:34:07.663 INFO (MainThread) [ocpp] GRS-170000xxxxx: send [2,"aedabe09-d6ed-4f95-9dc2-e9186be0a005","GetConfiguration",{"key":["SupportedFeatureProfiles"]}]
2023-09-08 15:34:07.663 DEBUG (MainThread) [websockets.server] > TEXT '[2,"aedabe09-d6ed-4f95-9dc2-e9186be0a005","GetC...rtedFeatureProfiles"]}]' [98 bytes]
2023-09-08 15:34:07.664 ERROR (MainThread) [custom_components.ocpp] Unexpected exception in connection to 'GRS-170000xxxx': '("Error code '%s' is not defined by the OCPP specification", 'FormationViolation')'
Traceback (most recent call last):
File "/config/custom_components/ocpp/api.py", line 930, in run
await asyncio.gather(*self.tasks)
File "/config/custom_components/ocpp/api.py", line 421, in post_connect
await self.get_supported_features()
File "/config/custom_components/ocpp/api.py", line 495, in get_supported_features
resp = await self.call(req)
^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/ocpp/charge_point.py", line 281, in call
response = await self._get_specific_response(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/ocpp/api.py", line 865, in _get_specific_response
raise resp.to_exception()
^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/ocpp/messages.py", line 439, in to_exception
raise UnknownCallErrorCodeError(
ocpp.exceptions.UnknownCallErrorCodeError: ("Error code '%s' is not defined by the OCPP specification", 'FormationViolation')
2023-09-08 15:34:07.668 DEBUG (MainThread) [custom_components.ocpp] Closing websocket to 'GRS-170000xxxxx'
2023-09-08 15:34:07.668 DEBUG (MainThread) [websockets.server] = connection is CLOSING
2023-09-08 15:34:07.668 DEBUG (MainThread) [websockets.server] > CLOSE 1000 (OK) [2 bytes]
2023-09-08 15:34:07.813 DEBUG (MainThread) [websockets.server] < TEXT '[4, "aedabe09-d6ed-4f95-9dc2-e9186be0a005", "FormationViolation", ""]' [69 bytes]
2023-09-08 15:34:07.813 DEBUG (MainThread) [websockets.server] < CLOSE 1005 (no status code [internal]) [0 bytes]
2023-09-08 15:34:07.813 DEBUG (MainThread) [websockets.server] x half-closing TCP connection
2023-09-08 15:34:07.813 INFO (MainThread) [ocpp] GRS-170000xxxxx: receive message [4, "aedabe09-d6ed-4f95-9dc2-e9186be0a005", "FormationViolation", ""]
2023-09-08 15:34:07.814 ERROR (MainThread) [homeassistant] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
File "/config/custom_components/ocpp/api.py", line 421, in post_connect
await self.get_supported_features()
File "/config/custom_components/ocpp/api.py", line 495, in get_supported_features
resp = await self.call(req)

^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/ocpp/charge_point.py", line 281, in call
response = await self._get_specific_response(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/ocpp/api.py", line 865, in _get_specific_response
raise resp.to_exception()
^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/ocpp/messages.py", line 439, in to_exception
raise UnknownCallErrorCodeError(
ocpp.exceptions.UnknownCallErrorCodeError: ("Error code '%s' is not defined by the OCPP specification", 'FormationViolation')
2023-09-08 15:34:07.668 DEBUG (MainThread) [custom_components.ocpp] Closing websocket to 'GRS-170000xxxxx'
2023-09-08 15:34:07.668 DEBUG (MainThread) [websockets.server] = connection is CLOSING
2023-09-08 15:34:07.668 DEBUG (MainThread) [websockets.server] > CLOSE 1000 (OK) [2 bytes]
2023-09-08 15:34:07.813 DEBUG (MainThread) [websockets.server] < TEXT '[4, "aedabe09-d6ed-4f95-9dc2-e9186be0a005", "FormationViolation", ""]' [69 bytes]
2023-09-08 15:34:07.813 DEBUG (MainThread) [websockets.server] < CLOSE 1005 (no status code [internal]) [0 bytes]
2023-09-08 15:34:07.813 DEBUG (MainThread) [websockets.server] x half-closing TCP connection
2023-09-08 15:34:07.813 INFO (MainThread) [ocpp] GRS-170000xxxxx: receive message [4, "aedabe09-d6ed-4f95-9dc2-e9186be0a005", "FormationViolation", ""]
2023-09-08 15:34:07.814 ERROR (MainThread) [homeassistant] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
File "/config/custom_components/ocpp/api.py", line 421, in post_connect
await self.get_supported_features()
File "/config/custom_components/ocpp/api.py", line 495, in get_supported_features
resp = await self.call(req)
^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/ocpp/charge_point.py", line 281, in call
response = await self._get_specific_response(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/ocpp/api.py", line 865, in _get_specific_response
raise resp.to_exception()
^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/ocpp/messages.py", line 439, in to_exception
raise UnknownCallErrorCodeError(
ocpp.exceptions.UnknownCallErrorCodeError: ("Error code '%s' is not defined by the OCPP specification", 'FormationViolation')
2023-09-08 15:34:07.832 DEBUG (MainThread) [websockets.server] = connection is CLOSED
2023-09-08 15:34:07.833 INFO (MainThread) [custom_components.ocpp] Charger GRS-170000xxxxx disconnected from 172.20.21.150:9000.
2023-09-08 15:34:07.834 INFO (MainThread) [websockets.server] connection closed

[8jmm3]

After seeing the progress here I decided to go ahead and try one of the v2 units. I can get it to connect to the United Chargers OCPP server and I can get it to attempt a connection to my local OCPP server (which currently fails because I'm still using the stock integration).

My current issue is that my v2 unit broadcasts an essentially open wifi network (password = "password") with the SSID being the serial number of the device. Upon connecting to that network I can go to 192.168.4.1 to configure the device. With the v1 units this network would disappear after configuring the wifi settings but now it appears to be persistent. The problem is that ANYBODY can connect to this persistent wifi network allowing them to view your home wifi password and/or reconfigure the device. Am I the only one experiencing this?

Firmware WiFi Module: GWM-07.020-03 Firmware Power Board: GCW-10.18-05.7

[8jmm3]

As a proof of concept I modified the firmware (version GWM-07.020-03) and shortened the reported chargePointModel to be within the proper character limit. Upon flashing the modified firmware it appears to be happy.

Flash using: esptool.py --chip esp32 --baud 921600 write_flash 0x10000 GWM-07.020-03-mod.bin

Note that this is for a Grizzl-E Smart Connect (v2) and the charger must be power cycled after flashing the update. Use at your own risk. I've also included the unmodified firmware in case you need to revert to the original.

Firmware WiFi Module: GWM-07.020-03 Firmware Power Board: GCW-10.18-05.7

[Files removed as superseded by newer firmware release]

[djiesr]

8jmm

GWM-07.020-03-mod.zip

You have a uncompiled version of the bin?

[8jmm3]

8jmm

GWM-07.020-03-mod.zip

You have a uncompiled version of the bin?

If only I did. No, I just patched the binary that came on the device.

[djiesr]

Ok, I never try it to open a bin before. You don't have a error with "chargePointVendor"?

[windseye]

Sorry folks, a new problem to add. The unit was working fine and giving usable information. I am in the process of trying to set up a wireguard tunnel which resulted in the EVSE being out of communication with the central server for a few minutes. When i got things reconnected I am getting reconnects every 2 minutes or so. Apparently an unsupported feature request. Here is the log:

2023-10-30 13:11:25.206 DEBUG (MainThread) [websockets.server] ! failing connection with code 1006 2023-10-30 13:11:25.207 DEBUG (MainThread) [websockets.server] = connection is CLOSED 2023-10-30 13:11:25.209 DEBUG (MainThread) [websockets.server] x half-closing TCP connection 2023-10-30 13:11:25.209 INFO (MainThread) [custom_components.ocpp] Charger GRS-1700003fb5d disconnected from 0.0.0.0:9002. 2023-10-30 13:11:25.210 INFO (MainThread) [websockets.server] connection closed 2023-10-30 13:11:25.233 DEBUG (MainThread) [websockets.server] = connection is CONNECTING 2023-10-30 13:11:25.240 DEBUG (MainThread) [websockets.server] < GET /GRS-1700003fb5d HTTP/1.1 2023-10-30 13:11:25.240 DEBUG (MainThread) [websockets.server] < Connection: Upgrade 2023-10-30 13:11:25.241 DEBUG (MainThread) [websockets.server] < Host: 192.168.0.33:9002 2023-10-30 13:11:25.241 DEBUG (MainThread) [websockets.server] < User-Agent: ESP32 Websocket Client 2023-10-30 13:11:25.241 DEBUG (MainThread) [websockets.server] < Upgrade: websocket 2023-10-30 13:11:25.241 DEBUG (MainThread) [websockets.server] < Sec-WebSocket-Version: 13 2023-10-30 13:11:25.241 DEBUG (MainThread) [websockets.server] < Sec-WebSocket-Key: bLRMJrsukWeCPK05taX1cQ== 2023-10-30 13:11:25.241 DEBUG (MainThread) [websockets.server] < Sec-WebSocket-Protocol: ocpp1.6 2023-10-30 13:11:25.242 DEBUG (MainThread) [websockets.server] < Authorization: Basic R1JTLTE3MDAwMDNmYjVkOg== 2023-10-30 13:11:25.242 DEBUG (MainThread) [websockets.server] > HTTP/1.1 101 Switching Protocols 2023-10-30 13:11:25.242 DEBUG (MainThread) [websockets.server] > Upgrade: websocket 2023-10-30 13:11:25.243 DEBUG (MainThread) [websockets.server] > Connection: Upgrade 2023-10-30 13:11:25.243 DEBUG (MainThread) [websockets.server] > Sec-WebSocket-Accept: +ARFEFB/3aylKuGLRLQzsbjuIvU= 2023-10-30 13:11:25.243 DEBUG (MainThread) [websockets.server] > Sec-WebSocket-Protocol: ocpp1.6 2023-10-30 13:11:25.243 DEBUG (MainThread) [websockets.server] > Date: Mon, 30 Oct 2023 17:11:25 GMT 2023-10-30 13:11:25.243 DEBUG (MainThread) [websockets.server] > Server: Python/3.11 websockets/11.0.3 2023-10-30 13:11:25.244 INFO (MainThread) [websockets.server] connection open 2023-10-30 13:11:25.244 DEBUG (MainThread) [websockets.server] = connection is OPEN 2023-10-30 13:11:25.244 WARNING (MainThread) [custom_components.ocpp] Skipping websocket subprotocol validation 2023-10-30 13:11:25.244 INFO (MainThread) [custom_components.ocpp] Charger websocket path=/GRS-1700003fb5d 2023-10-30 13:11:25.244 INFO (MainThread) [custom_components.ocpp] Charger GRS-1700003fb5d reconnected to 0.0.0.0:9002. 2023-10-30 13:11:26.269 DEBUG (MainThread) [websockets.server] < TEXT '[2,"1481767829","BootNotification",{"chargePoin..."meterType":"timeout"}]' [233 bytes] 2023-10-30 13:11:26.270 INFO (MainThread) [ocpp] GRS-1700003fb5d: receive message [2,"1481767829","BootNotification",{"chargePointModel":"Grizzl-E Smart Connect","chargePointVendor":"UnitedChargers","chargePointSerialNumber":"GRS-1700003fb5d","firmwareVersion":"GWM-07.020-03_GCW-10.18-05.7","meterType":"timeout"}] 2023-10-30 13:11:26.272 INFO (MainThread) [ocpp] GRS-1700003fb5d: send [4,"1481767829","NotImplemented","Requested Action is not known by receiver",{"cause":"Failed to validate action: BootNotification"}] 2023-10-30 13:11:26.273 DEBUG (MainThread) [websockets.server] > TEXT '[4,"1481767829","NotImplemented","Requested Act...on: BootNotification"}]' [133 bytes] 2023-10-30 13:11:27.283 DEBUG (MainThread) [websockets.server] < TEXT '[2,"1481767830","BootNotification",{"chargePoin...-05.7","meterType":""}]' [226 bytes] 2023-10-30 13:11:27.283 INFO (MainThread) [ocpp] GRS-1700003fb5d: receive message [2,"1481767830","BootNotification",{"chargePointModel":"Grizzl-E Smart Connect","chargePointVendor":"UnitedChargers","chargePointSerialNumber":"GRS-1700003fb5d","firmwareVersion":"GWM-07.020-03_GCW-10.18-05.7","meterType":""}] 2023-10-30 13:11:27.286 INFO (MainThread) [ocpp] GRS-1700003fb5d: send [4,"1481767830","NotImplemented","Requested Action is not known by receiver",{"cause":"Failed to validate action: BootNotification"}] 2023-10-30 13:11:27.286 DEBUG (MainThread) [websockets.server] > TEXT '[4,"1481767830","NotImplemented","Requested Act...on: BootNotification"}]' [133 bytes] 2023-10-30 13:11:37.298 DEBUG (MainThread) [websockets.server] < PING '' [0 bytes] 2023-10-30 13:11:37.298 DEBUG (MainThread) [websockets.server] > PONG '' [0 bytes] 2023-10-30 13:11:45.247 DEBUG (MainThread) [websockets.server] > PING '\x1e\x138\x06' [text, 4 bytes] 2023-10-30 13:11:45.353 DEBUG (MainThread) [websockets.server] < PONG '\x1e\x138\x06' [text, 4 bytes] 2023-10-30 13:11:55.322 DEBUG (MainThread) [websockets.server] < PING '' [0 bytes] 2023-10-30 13:11:55.322 DEBUG (MainThread) [websockets.server] > PONG '' [0 bytes] 2023-10-30 13:11:55.606 DEBUG (MainThread) [websockets.server] < TEXT '[2,"1481767831","BootNotification",{"chargePoin...-05.7","meterType":""}]' [226 bytes] 2023-10-30 13:11:55.607 INFO (MainThread) [ocpp] GRS-1700003fb5d: receive message [2,"1481767831","BootNotification",{"chargePointModel":"Grizzl-E Smart Connect","chargePointVendor":"UnitedChargers","chargePointSerialNumber":"GRS-1700003fb5d","firmwareVersion":"GWM-07.020-03_GCW-10.18-05.7","meterType":""}] 2023-10-30 13:11:55.610 INFO (MainThread) [ocpp] GRS-1700003fb5d: send [4,"1481767831","NotImplemented","Requested Action is not known by receiver",{"cause":"Failed to validate action: BootNotification"}] 2023-10-30 13:11:55.610 DEBUG (MainThread) [websockets.server] > TEXT '[4,"1481767831","NotImplemented","Requested Act...on: BootNotification"}]' [133 bytes] 2023-10-30 13:12:05.355 DEBUG (MainThread) [websockets.server] > PING 3c f0 76 95 [binary, 4 bytes] 2023-10-30 13:12:05.426 DEBUG (MainThread) [websockets.server] < PONG 3c f0 76 95 [binary, 4 bytes] 2023-10-30 13:12:15.393 DEBUG (MainThread) [websockets.server] < PING '' [0 bytes] 2023-10-30 13:12:15.393 DEBUG (MainThread) [websockets.server] > PONG '' [0 bytes] 2023-10-30 13:12:25.422 DEBUG (MainThread) [websockets.server] ! failing connection with code 1006 2023-10-30 13:12:25.423 DEBUG (MainThread) [websockets.server] = connection is CLOSED 2023-10-30 13:12:25.424 DEBUG (MainThread) [websockets.server] x half-closing TCP connection 2023-10-30 13:12:25.425 INFO (MainThread) [custom_components.ocpp] Charger GRS-1700003fb5d disconnected from 0.0.0.0:9002. 2023-10-30 13:12:25.426 INFO (MainThread) [websockets.server] connection closed

[djiesr]

I understand it's the OCPP of mobilityhouse can't decode de message and it close the connection. I didn't know how you patch the number of the "maxLength 20", but it's possible you move or delete something?

[8jmm3]

Ok, I never try it to open a bin before. You don't have a error with "chargePointVendor"?

No error with "chargePointVendor" as it appears to fall without the allowable length stated in the OCPP specification, if I'm not mistaken. "chargePointModel" was the only problem I noticed in this regard. I implemented my firmware patch to avoid having to modify anything below the OCPP integration level so I can move my focus to the problems abated via api.py and such. This was easy because it just involved modifying a text string, not the binary code. Of note, I changed chargePointModel to "Grizzl-E Smart" rather than "Grizzl-E Smart Connect", which would be evident in the logs. Not sure whether that has any effect if trying to connect to the United Chargers OCPP server as I haven't tried yet. I'm still in the process of further analyzing the firmware binary. At least it doesn't appear to contain unreleased GPL code like the last iteration.

I'm currently back to playing with api.py since the above patch takes care of the BootNotification error. I'm still getting the FormatValidation error and a reconnect every minute or two, but it otherwise seems to be initializing the sensors. Perhaps I missed something in the prior discussion on this. Will keep investigating.

[djiesr]

I ask for the chargePointVendor beacause you had some space before like that ..., "chargePointVendor"... I just ask if you see a difference, but its good if not. It's strange you get FormatValidation after you change it. If you check "ignore the validation of the OCPP scheme" when you add the integration, this is ok?

[devzwf]

My current issue is that my v2 unit broadcasts an essentially open wifi network (password = "password") with the SSID being the serial number of the device. Upon connecting to that network I can go to 192.168.4.1 to configure the device. With the v1 units this network would disappear after configuring the wifi settings but now it appears to be persistent. The problem is that ANYBODY can connect to this persistent wifi network allowing them to view your home wifi password and/or reconfigure the device. Am I the only one experiencing this?

Hello, i am a bit concerned by that as well, even if you need to be close to the unit , still a red flag for me

BTW thanks @djiesr for all the efforts :)

[kenttse]

My current issue is that my v2 unit broadcasts an essentially open wifi network (password = "password") with the SSID being the serial number of the device. Upon connecting to that network I can go to 192.168.4.1 to configure the device. With the v1 units this network would disappear after configuring the wifi settings but now it appears to be persistent. The problem is that ANYBODY can connect to this persistent wifi network allowing them to view your home wifi password and/or reconfigure the device. Am I the only one experiencing this?

Hello, i am a bit concerned by that as well, even if you need to be close to the unit , still a red flag for me

BTW thanks @djiesr for all the efforts :)

I reported this as a security issue to United Chargers. Unfortunately, they did not give me an ETA on a fix or a patch to either allow for changing the password or turning the hotspot off when it is configured. I suggest everyone send in a bug report.

[djiesr]

I suggest everyone send in a bug report.

Good idea.

It's possible to reset the charger, so it's not a problem to change the password. If you forget it, just reset the charger.

Someone know if the charger have 2 antennas or it use the same for 2 WI-FI?

[devzwf]

do you have a link handy for the bug report ?

[kenttse]

do you have a link handy for the bug report ?

I logged it on this site: https://autochargers.zendesk.com/hc/en-ca

[8jmm3]

I also have an open ticket for this issue though the above link. I was initially brushed off and am awaiting further follow up, hopefully from a higher level support person. In the interim I might patch the firmware further to at least change the password to something other than "password". I don't think this would be too difficult. The way it is currently it would seem almost trivial to compromise the unit to gain access to your wifi network and/or push malware OTA to any charger within wifi range.

@djiesr I don't have the unit beside me now but I believe it uses an Espressif ESP32-D0WD. You can read the datasheet here if you want to know more: https://www.espressif.com/sites/default/files/documentation/esp32_datasheet_en.pdf

[devzwf]

and i think eveybody already know , but if you go to the IP of the unit you have the exact same page as 192.168.4.1

[devzwf]

answer from Unitedcharger : The software developers got back to me on this, and said there is absolutely no security concerns here. The webpage 192.168.4.1 provides ACCESS TO THE CHARGERS ONLY WHEN CHARGER IS IN INITIAL STAGE, i.e. not connected to Wi-Fi.

Not True

[8jmm3]

Still waiting for followup response to my ticket but I can clearly access the configuration web page from both GRS-XXXX Wifi/192.168.4.1 and Private Wifi/192.168.x.x simultaneously.

I wish they were a little less dismissive when people report things. If they refuse to act then perhaps someone can pursue getting a published CVE for this.

[djiesr]

Private Wifi/192.168.x.x

I always connect to it via 192.168.4.1, I never realize it's available on port 80 in my local network... to many "espressif" devices. Thanks for the tip :)

[devzwf]

Update: i was able to get UC attention , and make them understand the issue. i talk to a representative on the phone , and they told me a Fix is on the the way. let see

[8jmm3]

Misc updates:

1) Still no response from UC regarding wifi security issue. Hopefully @devzwf has gotten the ball rolling.

2) I set up a SteVe OCPP server (https://github.com/steve-community/steve) and the EVSE seems to connect just fine and provides useful data. I am using the above patched GWM-07.020-03 firmware to correct the chargePointModel issue but not sure whether it matters. I'll have to more closely compare the transactions with SteVE vs. the Home Assistant integration.

3) I can successfully connect the patched firmware to the United Chargers OCPP server, so it's clear the chargePointModel value is only being used for display purposes to the end user. Hopefully they will release a later firmware with a value that fits within the allowable character limit.

4) Methods to extract info from the device:

GET requests:

• http://192.168.4.1/info
• http://192.168.4.1/log
• http://192.168.4.1/scan

POST requests:

• curl -X POST http://192.168.4.1/getLogData | jq
• curl -X POST http://192.168.4.1/ocpp
• curl -X POST http://192.168.4.1/wifi

5) For those interested, I'm slowly investigating the ESP32 firmware. The flash storage consists of the following partitions:

  label      : nvs [contains wifi settings]
  offset     : 0x9000
  length     : 20480

  label      : otadata
  offset     : 0xe000
  length     : 8192

  label      : app0 [contains the core binary firmware]
  offset     : 0x10000
  length     : 1966080

  label      : app1
  offset     : 0x1f0000
  length     : 1966080

  label      : spiffs [contains log files]
  offset     : 0x3d0000
  length     : 192512

  label      : ident [contains the device serial number]
  offset     : 0x3ff000
  length     : 4096

The NVS partition contains the settings used for the wifi client and access point:

Namespace eeprom
  stationId       : STR   GRS-XXXX
  espMarker       : STR   
  stmMarker       : STR   
  providerUrl     : STR   wss://ocpp.unitedchargers.com/ocpp1.6?station=
  authKey         : STR
  energy          : U64
Namespace misc
Namespace nvs.net80211
  ap.sndchan      : U8
  opmode          : U8
  ap.authmode     : U8
  ap.chan         : U8
  ap.ssid         : BLOB
  ap.passwd       : BLOB
  ap.hidden       : U8
  ap.max.conn     : U8
  bcn.interval    : U16
  ap.p_cipher     : U8
  ap.ftm_r        : U8
  ap.pmk          : BLOB
  bssid.set       : U8
  sta.lis_intval  : U1
  sta.scan_method : U8
  sta.sort_method : U8
  sta.minrssi     : I8
  sta.minauth     : U8
  sta.pmf_e       : U8
  sta.pmf_r       : U8
  sta.rrm_e       : U8
  sta.btm_e       : U8
  sta.mbo_e       : U8
  sta.ssid        : BLOB
  sta.pswd        : BLOB
  sta.chan        : U8
  sta.apsw        : BLOB
  sta.apinfo      : BLOB
Namespace phy
  cal_data        : BLOB
  cal_mac         : BLOB
  cal_version     : U32

The gist being that you can modify the firmware by flashing the app0 partition and wifi settings by re-writing the nvs partition, though I haven't attempted the latter yet.

[devzwf]

Nice work. Regarding my discussion with UC, i feel they get the point.... here is an update from they : After further discussions earlier this afternoon, I am informed that we should be able to implement a custom password to protect from direct access to the configuration page 192.168.4.1.

that a step in the good direction. i will let you know when i get update.

[windseye]

8jmm3,

I appreciate your efforts to understand the firmware. I am totally uninformed about these matters but I have the following speculation:

It seems that there are two parts to the firmware package. In my case: Firmware WiFi Module: GWM-07.020-03 Firmware Power Board: GCW-10.18-05.7

It seems that the wifi module firmware might be the part of the package that gives us the connection problems that we are fighting while the power board firmware might be the same as in Grizzl-E dumb chargers? Perhaps someone with far greater knowledge than I could adapt the part of the OpenEVSE firmware package that controls the wifi module to run on our ESP32 based wifi board. I believe that the OpenEVSE firmware is available for ESP32 boards https://github.com/OpenEVSE/openevse_esp32_firmware

What do you think?

[8jmm3]

The "wifi module" firmware resides on the ESP32 board plugged into the main circuit board (power board). The "power board" firmware resides somewhere on the main board. It appears that the ESP32 communicates with the main board over a serial data channel calling various UART routines. The main board is proprietary to the Grizzl-E while the ESP32 is more off-the-shelf hardware with custom firmware. They are still shipping with main boards stamped version 5.4 / Jan 2022 so it seems that the high voltage components have not changed between v1 and v2 Grizzl-E Smart releases. Only the ESP32 module has changed in the interim.

I don't have a "dumb" version to see what's inside. They very well might be shipping the same main board without the ESP32 add-on but I can't confirm either way.

It is quite conceivable that someone could write custom firmware for the Grizzl-E. The Grizzl-E ESP32 firmware is based around FreeRTOS and other open source components. One would have to decipher the serial communication between the ESP32 and the main board in order to communicate with the charge control hardware. I don't know the OpenEVSE firmware well enough to comment except to say that it wouldn't be a drop in replacement given the custom hardware onboard.

[windseye]

Homeassistant has been reporting warnings on 3 variables:

WARNING (MainThread) [custom_components.ocpp] MeterValuesSampledData is a read only setting WARNING (MainThread) [custom_components.ocpp] ClockAlignedDataInterval is a read only setting WARNING (MainThread) [custom_components.ocpp] WebSocketPingInterval is a read only setting

By commenting out the corresponsing lines in api.py I have eliminated these warnings but one problem remains:

2023-11-13 07:10:55.981 INFO (MainThread) [ocpp] GRS-1700003xxxx: receive message [2,"1481769861","BootNotification",{"chargePointModel":"Grizzl-E Smart Connect","chargePointVendor":"UnitedChargers","chargePointSerialNumber":"GRS-1700003xxxx","firmwareVersion":"GWM-07.020-03_GCW-10.18-05.7","meterType":"timeout"}] 2023-11-13 07:10:55.983 INFO (MainThread) [ocpp] GRS-1700003xxxx: send [4,"1481769861","NotImplemented","Requested Action is not known by receiver",{"cause":"Failed to validate action: BootNotification"}]

It looks to me like the response to a meterType inquiry is being requested. The response should be either S0 or EVSE butthe request is being returned as null due to a timeout. Where do I find this variable in the .py files? I assume that meterType should be hard coded to EVSE. Am I on the right track?

[8jmm3]

Homeassistant has been reporting warnings on 3 variables:

WARNING (MainThread) [custom_components.ocpp] MeterValuesSampledData is a read only setting WARNING (MainThread) [custom_components.ocpp] ClockAlignedDataInterval is a read only setting WARNING (MainThread) [custom_components.ocpp] WebSocketPingInterval is a read only setting

By commenting out the corresponsing lines in api.py I have eliminated these warnings but one problem remains:

2023-11-13 07:10:55.981 INFO (MainThread) [ocpp] GRS-1700003xxxx: receive message [2,"1481769861","BootNotification",{"chargePointModel":"Grizzl-E Smart Connect","chargePointVendor":"UnitedChargers","chargePointSerialNumber":"GRS-1700003xxxx","firmwareVersion":"GWM-07.020-03_GCW-10.18-05.7","meterType":"timeout"}] 2023-11-13 07:10:55.983 INFO (MainThread) [ocpp] GRS-1700003xxxx: send [4,"1481769861","NotImplemented","Requested Action is not known by receiver",{"cause":"Failed to validate action: BootNotification"}]

It looks to me like the response to a meterType inquiry is being requested. The response should be either S0 or EVSE butthe request is being returned as null due to a timeout. Where do I find this variable in the .py files? I assume that meterType should be hard coded to EVSE. Am I on the right track?

I've spent further time analyzing the inner workings of the hardware/firmware. Here's a little insight:

From what I can tell the handling of meterType seems a bit strange/buggy. The actual value of meterType sent back in the BootNotification message is indeed populated from a string variable. It appears that this string is initially set to an empty string on powering of the EVSE. You might see HA log entries confirming this. Strangely, if a timeout is encountered while the Grizzl-E is waiting for an OCPP message it appears to then set this string variable to the value "timeout", which corresponds with what you are seeing. I have no idea why they would do this and not just have a hard coded value (or omit it entirely). According to the OCPP 1.6 spec meterType is an optional field so it could be omitted.

[djiesr]

When the chargeur start the connexion, the server try to send is setup to the charger, but these variable are in read only. For now, we can't change then on Grizzl-e. That not a real problem, but, if they change this "protection" later, we will be à le to set it.

[windseye]

Are any of you getting useful data from the v2 Grizzl-E Smart EVSE? Mine is caught in the following loop:

2023-11-18 08:06:24.624 INFO (MainThread) [ocpp] GRS-1700003fb5d: send [2,"e8202212-90a4-445f-b67b-e5c8625e3041","GetConfiguration",{}] 2023-11-18 08:06:24.715 INFO (MainThread) [ocpp] GRS-1700003fb5d: receive message [3, "e8202212-90a4-445f-b67b-e5c8625e3041", {"configurationKey":[{"key":"MaxCurrent","readonly":true,"value":"40000"},{"key":"MinCurrent","readonly":true,"value":"8000"},{"key":"SetCurrent","readonly":false,"value":"40000"},{"key":"StartChargingAfterConnect","readonly":false,"value":"true"},{"key":"AuthorizeRemoteTxRequests","readonly":true,"value":"true"},{"key":"ConnectorPhaseRotation","readonly":true,"value":"NotApplicable"},{"key":"HeartbeatInterval","readonly":false,"value":"0"},{"key":"LocalAuthorizeOffline","readonly":true,"value":"true"},{"key":"LocalPreAuthorize","readonly":true,"value":"true"},{"key":"MeterValueSampleInterval","readonly":false,"value":"20"},{"key":"NumberOfConnectors","readonly":true,"value":"1"},{"key":"ResetRetries","readonly":true,"value":"1"},{"key":"StopTransactionOnInvalid","readonly":true,"value":"false"},{"key":"SupportedFeatureProfiles","readonly":true,"value":"Core,FirmwareManagement"},{"key":"UnlockConnectorOnEVSideDisconnect","readonly":true,"value":"false"}]}] 2023-11-18 08:06:24.727 INFO (MainThread) [ocpp] GRS-1700003fb5d: send [2,"300ef5bd-5cf6-41f4-b38b-b8370f6e6cc8","GetConfiguration",{}] 2023-11-18 08:06:24.752 INFO (MainThread) [homeassistant.components.binary_sensor] Setting up binary_sensor.upnp 2023-11-18 08:06:24.760 INFO (MainThread) [homeassistant.components.sensor] Setting up sensor.upnp 2023-11-18 08:06:24.808 INFO (MainThread) [ocpp] GRS-1700003fb5d: receive message [3, "300ef5bd-5cf6-41f4-b38b-b8370f6e6cc8", {"configurationKey":[{"key":"MaxCurrent","readonly":true,"value":"40000"},{"key":"MinCurrent","readonly":true,"value":"8000"},{"key":"SetCurrent","readonly":false,"value":"40000"},{"key":"StartChargingAfterConnect","readonly":false,"value":"true"},{"key":"AuthorizeRemoteTxRequests","readonly":true,"value":"true"},{"key":"ConnectorPhaseRotation","readonly":true,"value":"NotApplicable"},{"key":"HeartbeatInterval","readonly":false,"value":"0"},{"key":"LocalAuthorizeOffline","readonly":true,"value":"true"},{"key":"LocalPreAuthorize","readonly":true,"value":"true"},{"key":"MeterValueSampleInterval","readonly":false,"value":"20"},{"key":"NumberOfConnectors","readonly":true,"value":"1"},{"key":"ResetRetries","readonly":true,"value":"1"},{"key":"StopTransactionOnInvalid","readonly":true,"value":"false"},{"key":"SupportedFeatureProfiles","readonly":true,"value":"Core,FirmwareManagement"},{"key":"UnlockConnectorOnEVSideDisconnect","readonly":true,"value":"false"}]}] 2023-11-18 08:06:24.818 INFO (MainThread) [ocpp] GRS-1700003fb5d: send [2,"2fdcc2ce-62b7-4581-9636-d607907510e5","GetConfiguration",{}] 2023-11-18 08:06:24.894 INFO (MainThread) [ocpp] GRS-1700003fb5d: receive message [3, "2fdcc2ce-62b7-4581-9636-d607907510e5", {"configurationKey":[{"key":"MaxCurrent","readonly":true,"value":"40000"},{"key":"MinCurrent","readonly":true,"value":"8000"},{"key":"SetCurrent","readonly":false,"value":"40000"},{"key":"StartChargingAfterConnect","readonly":false,"value":"true"},{"key":"AuthorizeRemoteTxRequests","readonly":true,"value":"true"},{"key":"ConnectorPhaseRotation","readonly":true,"value":"NotApplicable"},{"key":"HeartbeatInterval","readonly":false,"value":"0"},{"key":"LocalAuthorizeOffline","readonly":true,"value":"true"},{"key":"LocalPreAuthorize","readonly":true,"value":"true"},{"key":"MeterValueSampleInterval","readonly":false,"value":"20"},{"key":"NumberOfConnectors","readonly":true,"value":"1"},{"key":"ResetRetries","readonly":true,"value":"1"},{"key":"StopTransactionOnInvalid","readonly":true,"value":"false"},{"key":"SupportedFeatureProfiles","readonly":true,"value":"Core,FirmwareManagement"},{"key":"UnlockConnectorOnEVSideDisconnect","readonly":true,"value":"false"}]}] 2023-11-18 08:06:24.904 INFO (MainThread) [ocpp] GRS-1700003fb5d: send [2,"773d5188-3738-49f6-a8ad-15df20b76e6c","GetConfiguration",{}] 2023-11-18 08:06:25.026 INFO (MainThread) [ocpp] GRS-1700003fb5d: receive message [3, "773d5188-3738-49f6-a8ad-15df20b76e6c", {"configurationKey":[{"key":"MaxCurrent","readonly":true,"value":"40000"},{"key":"MinCurrent","readonly":true,"value":"8000"},{"key":"SetCurrent","readonly":false,"value":"40000"},{"key":"StartChargingAfterConnect","readonly":false,"value":"true"},{"key":"AuthorizeRemoteTxRequests","readonly":true,"value":"true"},{"key":"ConnectorPhaseRotation","readonly":true,"value":"NotApplicable"},{"key":"HeartbeatInterval","readonly":false,"value":"0"},{"key":"LocalAuthorizeOffline","readonly":true,"value":"true"},{"key":"LocalPreAuthorize","readonly":true,"value":"true"},{"key":"MeterValueSampleInterval","readonly":false,"value":"20"},{"key":"NumberOfConnectors","readonly":true,"value":"1"},{"key":"ResetRetries","readonly":true,"value":"1"},{"key":"StopTransactionOnInvalid","readonly":true,"value":"false"},{"key":"SupportedFeatureProfiles","readonly":true,"value":"Core,FirmwareManagement"},{"key":"UnlockConnectorOnEVSideDisconnect","readonly":true,"value":"false"}]}] 2023-11-18 08:06:25.055 WARNING (MainThread) [custom_components.ocpp] MeterValuesSampledData is a read only setting 2023-11-18 08:06:25.055 WARNING (MainThread) [custom_components.ocpp] MeterValuesSampledData is a read only setting 2023-11-18 08:06:25.055 WARNING (MainThread) [custom_components.ocpp] MeterValuesSampledData is a read only setting 2023-11-18 08:06:25.056 WARNING (MainThread) [custom_components.ocpp] MeterValuesSampledData is a read only setting 2023-11-18 08:06:25.056 WARNING (MainThread) [custom_components.ocpp] MeterValuesSampledData is a read only setting 2023-11-18 08:06:25.056 WARNING (MainThread) [custom_components.ocpp] MeterValuesSampledData is a read only setting 2023-11-18 08:06:25.056 WARNING (MainThread) [custom_components.ocpp] MeterValuesSampledData is a read only setting 2023-11-18 08:06:25.056 WARNING (MainThread) [custom_components.ocpp] MeterValuesSampledData is a read only setting 2023-11-18 08:06:25.057 WARNING (MainThread) [custom_components.ocpp] MeterValuesSampledData is a read only setting 2023-11-18 08:06:25.057 WARNING (MainThread) [custom_components.ocpp] MeterValuesSampledData is a read only setting 2023-11-18 08:06:25.057 WARNING (MainThread) [custom_components.ocpp] MeterValuesSampledData is a read only setting 2023-11-18 08:06:25.059 INFO (MainThread) [ocpp] GRS-1700003fb5d: send [2,"ec9b709e-4753-4e39-bb09-b2342c49a738","ChangeConfiguration",{"key":"MeterValuesSampledData","value":"Energy.Active.Import.Register,Energy.Active.Import.Interval,Power.Active.Import,Current.Import,Voltage"}] 2023-11-18 08:06:25.279 INFO (MainThread) [ocpp] GRS-1700003fb5d: receive message [3, "ec9b709e-4753-4e39-bb09-b2342c49a738", {"status":"NotSupported"}] 2023-11-18 08:06:25.281 WARNING (MainThread) [custom_components.ocpp] NotSupported while setting MeterValuesSampledData to Energy.Active.Import.Register,Energy.Active.Import.Interval,Power.Active.Import,Current.Import,Voltage 2023-11-18 08:06:25.282 INFO (MainThread) [ocpp] GRS-1700003fb5d: send [2,"c59c9a17-5c3b-46c3-b5e8-53369de4948a","GetConfiguration",{}] 2023-11-18 08:06:25.348 INFO (MainThread) [ocpp] GRS-1700003fb5d: receive message [3, "c59c9a17-5c3b-46c3-b5e8-53369de4948a", {"configurationKey":[{"key":"MaxCurrent","readonly":true,"value":"40000"},{"key":"MinCurrent","readonly":true,"value":"8000"},{"key":"SetCurrent","readonly":false,"value":"40000"},{"key":"StartChargingAfterConnect","readonly":false,"value":"true"},{"key":"AuthorizeRemoteTxRequests","readonly":true,"value":"true"},{"key":"ConnectorPhaseRotation","readonly":true,"value":"NotApplicable"},{"key":"HeartbeatInterval","readonly":false,"value":"0"},{"key":"LocalAuthorizeOffline","readonly":true,"value":"true"},{"key":"LocalPreAuthorize","readonly":true,"value":"true"},{"key":"MeterValueSampleInterval","readonly":false,"value":"20"},{"key":"NumberOfConnectors","readonly":true,"value":"1"},{"key":"ResetRetries","readonly":true,"value":"1"},{"key":"StopTransactionOnInvalid","readonly":true,"value":"false"},{"key":"SupportedFeatureProfiles","readonly":true,"value":"Core,FirmwareManagement"},{"key":"UnlockConnectorOnEVSideDisconnect","readonly":true,"value":"false"}]}] 2023-11-18 08:06:25.358 INFO (MainThread) [ocpp] GRS-1700003fb5d: send [2,"40d38a79-7fe6-41f4-accc-7d86b43d2029","GetConfiguration",{}] 2023-11-18 08:06:25.446 INFO (MainThread) [ocpp] GRS-1700003fb5d: receive message [3, "40d38a79-7fe6-41f4-accc-7d86b43d2029", {"configurationKey":[{"key":"MaxCurrent","readonly":true,"value":"40000"},{"key":"MinCurrent","readonly":true,"value":"8000"},{"key":"SetCurrent","readonly":false,"value":"40000"},{"key":"StartChargingAfterConnect","readonly":false,"value":"true"},{"key":"AuthorizeRemoteTxRequests","readonly":true,"value":"true"},{"key":"ConnectorPhaseRotation","readonly":true,"value":"NotApplicable"},{"key":"HeartbeatInterval","readonly":false,"value":"0"},{"key":"LocalAuthorizeOffline","readonly":true,"value":"true"},{"key":"LocalPreAuthorize","readonly":true,"value":"true"},{"key":"MeterValueSampleInterval","readonly":false,"value":"20"},{"key":"NumberOfConnectors","readonly":true,"value":"1"},{"key":"ResetRetries","readonly":true,"value":"1"},{"key":"StopTransactionOnInvalid","readonly":true,"value":"false"},{"key":"SupportedFeatureProfiles","readonly":true,"value":"Core,FirmwareManagement"},{"key":"UnlockConnectorOnEVSideDisconnect","readonly":true,"value":"false"}]}] 2023-11-18 08:06:25.455 WARNING (MainThread) [custom_components.ocpp] ClockAlignedDataInterval is a read only setting 2023-11-18 08:06:25.455 WARNING (MainThread) [custom_components.ocpp] ClockAlignedDataInterval is a read only setting 2023-11-18 08:06:25.456 WARNING (MainThread) [custom_components.ocpp] ClockAlignedDataInterval is a read only setting 2023-11-18 08:06:25.456 WARNING (MainThread) [custom_components.ocpp] ClockAlignedDataInterval is a read only setting 2023-11-18 08:06:25.456 WARNING (MainThread) [custom_components.ocpp] ClockAlignedDataInterval is a read only setting 2023-11-18 08:06:25.456 WARNING (MainThread) [custom_components.ocpp] ClockAlignedDataInterval is a read only setting 2023-11-18 08:06:25.456 WARNING (MainThread) [custom_components.ocpp] ClockAlignedDataInterval is a read only setting 2023-11-18 08:06:25.457 WARNING (MainThread) [custom_components.ocpp] ClockAlignedDataInterval is a read only setting 2023-11-18 08:06:25.457 WARNING (MainThread) [custom_components.ocpp] ClockAlignedDataInterval is a read only setting 2023-11-18 08:06:25.457 WARNING (MainThread) [custom_components.ocpp] ClockAlignedDataInterval is a read only setting 2023-11-18 08:06:25.457 WARNING (MainThread) [custom_components.ocpp] ClockAlignedDataInterval is a read only setting 2023-11-18 08:06:25.458 INFO (MainThread) [ocpp] GRS-1700003fb5d: send [2,"5d1591e9-25d4-4b4f-9d12-547c681b272b","ChangeConfiguration",{"key":"ClockAlignedDataInterval","value":"900"}] 2023-11-18 08:06:25.590 INFO (MainThread) [ocpp] GRS-1700003fb5d: receive message [3, "5d1591e9-25d4-4b4f-9d12-547c681b272b", {"status":"NotSupported"}] 2023-11-18 08:06:25.591 WARNING (MainThread) [custom_components.ocpp] NotSupported while setting ClockAlignedDataInterval to 900 2023-11-18 08:06:25.593 INFO (MainThread) [ocpp] GRS-1700003fb5d: send [2,"419ccfd6-b021-4de7-8788-5e605842bca3","GetConfiguration",{}] 2023-11-18 08:06:25.870 INFO (MainThread) [ocpp] GRS-1700003fb5d: receive message [3, "419ccfd6-b021-4de7-8788-5e605842bca3", {"configurationKey":[{"key":"MaxCurrent","readonly":true,"value":"40000"},{"key":"MinCurrent","readonly":true,"value":"8000"},{"key":"SetCurrent","readonly":false,"value":"40000"},{"key":"StartChargingAfterConnect","readonly":false,"value":"true"},{"key":"AuthorizeRemoteTxRequests","readonly":true,"value":"true"},{"key":"ConnectorPhaseRotation","readonly":true,"value":"NotApplicable"},{"key":"HeartbeatInterval","readonly":false,"value":"0"},{"key":"LocalAuthorizeOffline","readonly":true,"value":"true"},{"key":"LocalPreAuthorize","readonly":true,"value":"true"},{"key":"MeterValueSampleInterval","readonly":false,"value":"20"},{"key":"NumberOfConnectors","readonly":true,"value":"1"},{"key":"ResetRetries","readonly":true,"value":"1"},{"key":"StopTransactionOnInvalid","readonly":true,"value":"false"},{"key":"SupportedFeatureProfiles","readonly":true,"value":"Core,FirmwareManagement"},{"key":"UnlockConnectorOnEVSideDisconnect","readonly":true,"value":"false"}]}] 2023-11-18 08:06:25.879 WARNING (MainThread) [custom_components.ocpp] WebSocketPingInterval is a read only setting 2023-11-18 08:06:25.880 WARNING (MainThread) [custom_components.ocpp] WebSocketPingInterval is a read only setting 2023-11-18 08:06:25.880 WARNING (MainThread) [custom_components.ocpp] WebSocketPingInterval is a read only setting 2023-11-18 08:06:25.880 WARNING (MainThread) [custom_components.ocpp] WebSocketPingInterval is a read only setting 2023-11-18 08:06:25.880 WARNING (MainThread) [custom_components.ocpp] WebSocketPingInterval is a read only setting 2023-11-18 08:06:25.881 WARNING (MainThread) [custom_components.ocpp] WebSocketPingInterval is a read only setting 2023-11-18 08:06:25.881 WARNING (MainThread) [custom_components.ocpp] WebSocketPingInterval is a read only setting 2023-11-18 08:06:25.881 WARNING (MainThread) [custom_components.ocpp] WebSocketPingInterval is a read only setting 2023-11-18 08:06:25.881 WARNING (MainThread) [custom_components.ocpp] WebSocketPingInterval is a read only setting 2023-11-18 08:06:25.881 WARNING (MainThread) [custom_components.ocpp] WebSocketPingInterval is a read only setting 2023-11-18 08:06:25.882 WARNING (MainThread) [custom_components.ocpp] WebSocketPingInterval is a read only setting 2023-11-18 08:06:25.883 INFO (MainThread) [ocpp] GRS-1700003fb5d: send [2,"5f627388-5af5-462b-87de-11d299c05518","ChangeConfiguration",{"key":"WebSocketPingInterval","value":"60"}] 2023-11-18 08:06:25.964 INFO (MainThread) [ocpp] GRS-1700003fb5d: receive message [3, "5f627388-5af5-462b-87de-11d299c05518", {"status":"NotSupported"}] 2023-11-18 08:06:25.965 WARNING (MainThread) [custom_components.ocpp] NotSupported while setting WebSocketPingInterval to 60 2023-11-18 08:06:25.969 INFO (MainThread) [ocpp] GRS-1700003fb5d: send [2,"d651f3d0-7864-4c32-a3f8-1fe2ed316f6a","ChangeAvailability",{"connectorId":0,"type":"Operative"}] 2023-11-18 08:06:26.064 INFO (MainThread) [ocpp] GRS-1700003fb5d: receive message [3, "d651f3d0-7864-4c32-a3f8-1fe2ed316f6a", {"status":"Accepted"}] 2023-11-18 08:06:27.503 INFO (MainThread) [homeassistant.setup] Setup of domain flux_led took 8.2 seconds 2023-11-18 08:06:27.565 INFO (MainThread) [homeassistant.components.button] Setting up button.flux_led 2023-11-18 08:06:27.570 INFO (MainThread) [homeassistant.components.light] Setting up light.flux_led 2023-11-18 08:06:27.570 INFO (MainThread) [homeassistant.components.number] Setting up number.flux_led 2023-11-18 08:06:27.590 INFO (MainThread) [homeassistant.components.select] Setting up select.flux_led 2023-11-18 08:06:27.591 INFO (MainThread) [homeassistant.components.sensor] Setting up sensor.flux_led 2023-11-18 08:06:27.593 INFO (MainThread) [homeassistant.components.switch] Setting up switch.flux_led 2023-11-18 08:06:27.611 INFO (MainThread) [homeassistant.bootstrap] Home Assistant initialized in 19.79s 2023-11-18 08:06:27.613 INFO (MainThread) [homeassistant.core] Starting Home Assistant 2023-11-18 08:06:27.622 INFO (MainThread) [custom_components.hacs] Stage changed: startup 2023-11-18 08:06:27.661 INFO (MainThread) [custom_components.hacs] Loading removed repositories 2023-11-18 08:06:27.692 INFO (MainThread) [homeassistant.components.automation.basement_overhead_lights_motion_detection] Initialized trigger Basement overhead lights motion detection 2023-11-18 08:06:28.002 INFO (MainThread) [custom_components.hacs] Loading known repositories 2023-11-18 08:06:28.886 INFO (MainThread) [custom_components.hacs] Stage changed: running 2023-11-18 08:07:16.186 INFO (MainThread) [custom_components.ocpp] Charger GRS-1700003fb5d disconnected from 0.0.0.0:9002.

[windseye]

Have we reached a standstill on this thread? Has anyone reached a satisfactory resolution?

[kenttse]

Nice work. Regarding my discussion with UC, i feel they get the point.... here is an update from they : After further discussions earlier this afternoon, I am informed that we should be able to implement a custom password to protect from direct access to the configuration page 192.168.4.1.

that a step in the good direction. i will let you know when i get update.

Looks like it's been implemented in the latest firmware: GWM-07.021-03_GCW-10.19-05.7

And you can change it from the configuration page:

[devzwf]

Yup when i get back in town i will be able to look at this and get them some other feedback since now i have direct com with them. Keep the feedback coming

[8jmm3]

I've just installed the latest firmware and it definitely looks like progress, at least with respect to the wifi authentication issue. I haven't had a chance to test the other functionality yet.

I've spent a bit more time studying inner workings of the device. For anyone interested in mundane architectural details:

• The device consists of two main programmable elements:
  • The ESP32-based wifi board (firmware GWM...)
  • The STM-based power board (firmware GCW...)
• There are several revisions of each of the above in the wild
• The ESP32 board is attached to the main PSB using an 8-pin connector (power, ground, UART, ...)
• The ESP32 firmware is based around RTOS and various other ESP-IDF components
• The ESP32 and STM components communicate with each other over UART using a fairly simple protocol
• The v2 unit has a new daughterboard linked via I2C that contains a real-time clock
• The ESP32 firmware communicates with the STM microcontroller on the main PSB to exchange charging status
• The ESP32 firmware has the ability to process OCPP firmware update requests and download firmware images via FTP which are then written to the NVRAM
• The STM firmware is embedded in the ESP32 firmware, which is responsible for transmitting the firmware update to the STM microcontroller over UART
• The device has logging/log rotation functionality build in that writes to an NVRAM partition
• Curiously, the firmware exhibits special behaviour when connected to a special United Chargers developer Wifi SSID (UC-Dev_2.4) - for debugging or convenience?

[devzwf]

really interesting. when i get back i will have a test on the new firmware

[windseye]

I have installed the new firmware. I still have the BootNoitification error resulting from the inability to process meterType. My charge point connects but Homeassistant gets no usable data:

2023-11-22 08:59:35.359 INFO (MainThread) [ocpp] GRS-1700003fb5d: receive message [2,"1481767088","BootNotification",{"chargePointModel":"Grizzl-E Smart Connect","chargePointVendor":"UnitedChargers","chargePointSerialNumber":"GRS-1700003fb5d","firmwareVersion":"GWM-07.020-03_GCW-10.18-05.7","meterType":"timeout"}] 2023-11-22 08:59:35.361 INFO (MainThread) [ocpp] GRS-1700003fb5d: send [4,"1481767088","NotImplemented","Requested Action is not known by receiver",{"cause":"Failed to validate action: BootNotification"}]

[8jmm3]

If anyone is updating can you attempt to record the URL used to fetch the firmware update (via logs or packet capture)? That might be useful to have.

[windseye]

I flashed my unit with GWM-07.020-03.bin and I appear to have bricked the unit. the flash appears to have completed correctly:

root@mark:/home/mark/Downloads/grizzl-e# esptool.py --chip esp32 --baud 921600 write_flash 0x10000 GWM-07.020-03.bin esptool.py v4.6.2 Found 1 serial ports Serial port /dev/ttyUSB0 Connecting.... Chip is ESP32-D0WD (revision v1.0) Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None Crystal is 40MHz MAC: c4:de:e2:9b:94:bc Uploading stub... Running stub... Stub running... Changing baud rate to 921600 Changed. Configuring flash size... Flash will be erased from 0x00010000 to 0x00108fff... Compressed 1017072 bytes to 631863... Wrote 1017072 bytes (631863 compressed) at 0x00010000 in 11.1 seconds (effective 731.7 kbit/s)... Hash of data verified.

Leaving... Hard resetting via RTS pin...

I power cycle the unit and NOTHING! the led does not come on and the unit has no life. Please help.

[windseye]

If anyone has a copy of the complete GWM-07.021-03_GCW-10.19-0.57 bin file would you please share it? Perhaps I can unbrick my unit by flashing the complete current packsge.

Thanks

[8jmm3]

If anyone has a copy of the complete GWM-07.021-03_GCW-10.19-0.57 bin file would you please share it? Perhaps I can unbrick my unit by flashing the complete current packsge.

Thanks

Were you trying to revert to an earlier firmware version after receiving the latest update? That sounds risky. Among other things the power board firmware will have also been updated and is expecting to interact with a certain wifi firmware version.

If someone is able to determine the FTP download link for the latest firmware you could try to grab it and re-flash. Alternatively someone could dump the firmware off a working device. There only is one binary file for the firmware since the GCW part is rolled into the GWM part (what gets written at address 0x10000). The remainder of the NVRAM contains the bootloader and required file system partitions that would have been initialized prior to shipping the unit.

Does the device still respond when using esptool (e.g. running the chip_id command)? If it doesn't respond at all I'm not sure how to move forward.

[devzwf]

I did not update mine yet since i am out the country. but when i get back i will set up sniffing to get the url for the update.

[windseye]

Yes, I tried to go backwards. The system does respond to esptool. If I can get a good binary I think that I will be back in business.Thanks to anyone that can help.Sent from my T-Mobile 5G Device -------- Original message --------From: 8jmm3 @.> Date: 12/2/23 5:58 PM (GMT-05:00) To: lbbrhzn/ocpp @.> Cc: windseye @.>, Mention @.> Subject: Re: [lbbrhzn/ocpp] Grizzl-e Smart v2 support (Issue #899)

If anyone has a copy of the complete GWM-07.021-03_GCW-10.19-0.57 bin file would you please share it? Perhaps I can unbrick my unit by flashing the complete current packsge. Thanks

Were you trying to revert to an earlier firmware version after receiving the latest update? That sounds risky. Among other things the power board firmware will have also been updated and is expecting to interact with a certain wifi firmware version. If someone is able to determine the FTP download link for the latest firmware you could try to grab it and re-flash. Alternatively someone could dump the firmware off a working device. There only is one binary file for the firmware since the GCW part is rolled into the GWM part (what gets written at address 0x10000). The remainder of the NVRAM contains the bootloader and required file system partitions that would have been initialized prior to shipping the unit. Does the device still respond when using esptool (e.g. running the chip_id command)? If it doesn't respond at all I'm not sure how to move forward.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

[8jmm3]

Note that while the actual firmware data is ~1 MB in size, the firmware partition itself is ~2 MB. The latest firmware is slightly larger than the older firmware. Based on your esptool output the flash was only erased from 0x00010000 to 0x00108fff, which means that it did not clear the tail end of the GWM-07.021-03 image when you flashed GWM-07.020-03 over top of it. I'm not sure how the device is interpreting the garbage data now sitting at the end of your firmware image but clearly there's a problem.

Below is the latest firmware image if you're able to figure out a way to flash it.

GWM-07.021-03_GCW-10.19-05.7.zip

[windseye]

I have flashed GWM-07.021-03_GCW-10.19-05.7.zip but my EVSE is still unresponsive. The flash seems to complete:

root@mark:/home/mark/Downloads/grizzl-e# esptool.py --no-stub --chip esp32 --baud 921600 write_flash 0x10000 GWM-07.021-03_GCW-10.19-05.7.bin esptool.py v4.6.2 Found 1 serial ports Serial port /dev/ttyUSB0 Connecting.... Chip is ESP32-D0WD (revision v1.0) Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None Crystal is 40MHz MAC: c4:de:e2:9b:94:bc Changing baud rate to 921600 Changed. Enabling default SPI flash mode... Configuring flash size... Flash will be erased from 0x00010000 to 0x00109fff... Erasing flash... Took 4.01s to erase flash block Wrote 1024000 bytes at 0x00010000 in 21.5 seconds (381.2 kbit/s)... Hash of data verified.

Leaving... Hard resetting via RTS pin...

But the EVSE is unresponsive after cold reset. Is it possible that the ESP32 is nor resetting from bootloader mode? I see some posts in espressif that there are some reset timing issues in on linux machines. anyone have knowledge?

[windseye]

Well, I decided to throw in the towel. I ordered an openEVSE Advanced Series Kit ($299 US). I will cannibalize the Grizzle-E for its cords and build an open source system. I have now bricked my grizzle-E for the second time trying to get firmware that will speak passable OCPP 1.6. I know that tech support at United Chargers will be no help. I burned my goodwill with them the first time I bricked the unit. It is frustrating because the unit is not really bricked. Esptool.py communicates with the wifi module. It could be saved. The folks on this thread have been great -- many thanks -- but I need the support that I hope to find on openEVSE.

[devzwf]

@windseye good luck.... for sure OpenEVSE is a nice unit, i would get this one it was on the gov list.... oh well

[joeladria]

Just wanted to share my experience so far. I have what I assume is a v2 unit. Upgraded on installation to GWM-07.023-03-GCW-10.19-05.7 from the Grizz-E app. When I connect it to my OCPP instance, I do briefly get information about the status, but the unit seems to reboot every minute (and OCPP reports this in a notification). To me this shows there might be some hope here -- if the unit is rebooting because of something OCPP is returning (or not returning) maybe there's a way to make this work. Let me know what logs would be most useful!

[djiesr]

@joeladria Hi! Do you use my fork for Grizzl-E? https://github.com/djiesr/ocpp That can append whit the wrong integration. OR I have this problem to because my charger is outside and the antenna is in the metal box. I place a extender near it and now It's fine 99% of time.

[joeladria]

Oh that's great, I had not seen your fork, thanks! Works great so far!

[joeladria]

So after switching to your @djiesr 's build I'm still having reboots. WiFi should be stable, Access Point is right on the other side of the wall with -57dbm reporting by the AP. Reboots about every minute, will try and pull some logs.

[djiesr]

@joeladria I make a beta v0.1.7.320, it put the reboot message in debug mode only. I make some other little change, so I hope that can help you. the problem look like to be between OCPP and Websock, but the integration look to work. You will have a charger Reconnects value to see if it's really stable or not, but no reboot message.

[djiesr]

I just release a new version. If your version is stable, you don't need to update it. I just try to patch the "reconnection" problem.