Simpson & Partners Charger

[edc1]

Anyone else here using this integration with a Simpson & Partners charger? I have one of their Home 7 Plus chargers and I thought I'd share my experience using it.

Setup

You configure the web socket URL that points the charger to Home Assistant in the S&P app under Settings -> OCPP. There's a bug in the iPhone app where you start typing the URL in the box and the characters disappear after a second or two. The only way I've found around this is to have the URL in your clipboard, paste it in the box, and quickly tap the save and restart button. That will configure the charger to use OCPP. I don't know if this bug is also present in the Android version of the app as I've only tried it on the iPhone one.

Measurands

The integration successfully detects the following measurands from the charger:

Current.Import
Current.Offered
Energy.Active.Import.Interval
Energy.Active.Import.Register
Power.Active.Import
Power.Offered
Temperature
Voltage

Unfortunately for the Temperature measurand, the charger reports its unit as '°C' instead of 'Celsius'. That causes schema validation to fail as '°C' isn't part of the OCPP 1.6-J schema specification. I disable automatic measurand detection and manually select all the ones above apart from Temperature. Possibly having both 'Automatic detection of OCPP Measurands' and 'Skip OCPP schema validation' enabled would work, but I think getting the integration to validate the messages from the charger is rather important.

Reliability

I've not found using OCPP with this charger to be very reliable. The charger often (multiple times per week) reports InternalError and enters a Faulted state:

[2,"xxxxxxxxxxxx-22c4f223-00000097","StatusNotification",{"connectorId":1,"status":"Faulted","errorCode":"InternalError"}]

This is particularly annoying when you need it to charge the car in the middle of the night and it doesn't. The only way to get it working again is to restart it from the S&P app. Sometimes twice. This seems to happen a lot more frequently since the 2.2.37 firmware was pushed to the charger. I've reported this to Simpson & Partners so we'll see if they take any notice. Disabling OCPP and just relying on a schedule set on the charger is reliable (but obviously no Home Assistant integration then). I suspect it's the OCPP code in the charger's firmware that's unreliable.

Does anyone have a reliable setup with this charger?

[m01]

Did you also report the temperature unit issue to S&P?

[edc1]

I've reported that to them too now. We'll see if they fix it.

[m01]

Looks like in the current firmware version the temperature units are fixed! 🎉

Nov 23 ... <hostname> hass[...]: 2024-11-23 ... INFO (MainThread) [ocpp] : receive message [2,"...","MeterValues",{"connectorId":1,"transactionId":...,"meterValue":[{"timestamp":"2024-11-23T...",...,{"measurand":"Temperature","value":"28.500","unit":"Celsius"},... ]}]}]

I'm no longer seeing the "fixing" warnings from my temporary workaround (and indeed, I don't see errors after removing my workaround).

[edc1]

Cool. Which version are you running? I must admit I didn't check if this was fixed in 2.2.39.

[m01]

2.2.40

[edc1]

Good stuff. I'm glad they've fixed that one!

[drc38]

You can use the OCPP integration's Get Diagnostics action to retrieve the charger log and this may shed some light on why the internal error is occurring. If you search the Discussions/Issues there is more info on how to do this.

[edc1]

Thanks very much for the suggestion. It doesn't look like I can get diagnostics data from the charger. Querying the configuration for SupportedFileTransferProtocols I get the following back:

2024-10-30 19:54:28.316 WARNING (MainThread) [custom_components.ocpp] Get Configuration returned unknown key for: SupportedFileTransferProtocols

When the charger starts, it tells me it supports the following feature profiles:

Core
RemoteTrigger
SmartCharging

The ocpp.get_diagnostics action is only registered in Home Assistant if the charger also supports:

FirmwareManagement

Just to see what would happen, I modified the relevant lines in api.py so the ocpp.get_diagnostics action was availalbe in Home Assistant. When I run it the charger reports NotImplemented:

2024-10-30 20:04:22.105 INFO (MainThread) [ocpp] : send [2,"bf357f5f-bac4-4aeb-a3bf-18bb1adc4c05","GetDiagnostics",{"location":"https://webhook.site/abc"}]
2024-10-30 20:04:22.306 INFO (MainThread) [ocpp] : receive message [4,"bf357f5f-bac4-4aeb-a3bf-18bb1adc4c05","NotImplemented","",""]

2024-10-30 20:05:34.824 INFO (MainThread) [ocpp] : send [2,"9761f9b3-1d0c-450a-828a-8ebb12826efd","GetDiagnostics",{"location":"ftp://webhook.site/abc"}]
2024-10-30 20:05:34.905 INFO (MainThread) [ocpp] : receive message [4,"9761f9b3-1d0c-450a-828a-8ebb12826efd","NotImplemented","",""]

[m01]

I can confirm the iOS app quirk with the edit field and the validation error with the temperature units. I worked around the latter by temporarily patching the Python ocpp library. I haven't yet seen the reliability issue - but I still need to finish one leg of the network cabling, so I've only had temporarily-installed network cables in place for a few days at a time.

I was wondering if the validation error would cause wide-spread issues, but another open-source OCPP "server" seems to just ignore anything other than (k)Wh, at least for display (steve-community/steve#1514). I'm not sure how strict they are with validation. That said, I'm happy this one logs the extra data.

[edc1]

S&P have identified the cause of the InternalError errors I was getting and pushed a version of the firmware to my charger with a fix. I've not seen the errors since. I expect that fix will be more widely deployed reasonably soon.

I've been told they will address the Temperature measurand reporting the wrong unit soon too. So hopefully that won't be a problem for much longer. That issue doesn't stop charging from working.

I've been impressed with the level of support I've received for these two issues.

[bleara]

I was reading this post & started to think I had written it because you are seeing exactly the behaviour that I get. I can confirm that the Android App has or at least had the same issue when trying to type in the URL, so having to do a quick copy and paste and save has been the only way to do it. I am told that this is fixed in the latest version of the App but I haven't tried it.
The reliability problems when using OCPP are just as I see too. I had observed this getting worse over the last few releases of the firmware but I had also been adding in code in HA to try and work around the occasional problems These changes I have made seem to make it worse, for instance checking 'charger_status' once a minute had my charger lock up twice in a day on one occasion this week.
S & P have put me on their beta test program so I am currently using 2.2.39 which has recovered from an 'unavailable' state but not always.
I have found that the more I read the 'charger_status' the worse it seems to get so if you can just do a start charge and stop charge without status checks then it works reliably so far (2 days at least). I am feeding back to S&P with my findings and they do sound keen to fix the issues.
How do you get the log data ? I've not gone to that level in HA so it's new to me and I can't see anything relevant in the system logs.

[bleara]

I just poll the status value "sensor.charger_status" which I expected would have no direct impact on the OCPP as I assumed it would be updated periodically from the OCPP interface by the driver. I was surprised that it did seem to have an effect, my knowledge of the internal workings is still sketchy though.
When it was failing it didn't seem to make any difference whether the car was connected or not, or charging or not.

[m01]

I see that 'm01' has 2.2.40 but mine still reports 2.2.39.

Note that I observed the version 2.2.40 on a Business 7 charger; maybe a difference between the home & business models' version numbers is normal.

[bleara]

I have had the charger go 'unavailable' twice yesterday. The first occasion was for over 2 hours in the middle of a charge so the charge stopped permanently as I hadn't got my error recovery code active. The charger did go into the 'preparing' state after the 2 hours but that would have been a large chunk of the charge time lost even if I had the code active. Charged last night though.
I'm not sure of the difference between 'preparing' and 'available', anyone know?
David Simpson did contact me last night to say they are working on the problem over the weekend.

[edc1]

The charger goes from Available to Preparing when you plug the car in. Essentially Preparing means connected to the car but not charging.

Here's what the status looks like in Home Assistant for a successful charge, from the perspective of the charger (Status Connector and Availability) and the car (Charging System Status):

The small brown-ish coloured block is SuspendedEV status where the car had reached it charge target.

Here are the definitions for the various different statuses as defined in the OCPP 1.6 spec:

STATUS	CONDITION
Available	When a Connector becomes available for a new user (Operative)
Preparing	When a Connector becomes no longer available for a new user but there is no ongoing Transaction (yet). Typically a Connector is in preparing state when a user presents a tag, inserts a cable or a vehicle occupies the parking bay (Operative)
Charging	When the contactor of a Connector closes, allowing the vehicle to charge (Operative)
SuspendedEVSE	When the EV is connected to the EVSE but the EVSE is not offering energy to the EV, e.g. due to a smart charging restriction, local supply power constraints, or as the result of StartTransaction.conf indicating that charging is not allowed etc. (Operative)
SuspendedEV	When the EV is connected to the EVSE and the EVSE is offering energy but the EV is not taking any energy. (Operative)
Finishing	When a Transaction has stopped at a Connector, but the Connector is not yet available for a new user, e.g. the cable has not been removed or the vehicle has not left the parking bay (Operative)
Reserved	When a Connector becomes reserved as a result of a Reserve Now command (Operative)
Unavailable	When a Connector becomes unavailable as the result of a Change Availability command or an event upon which the Charge Point transitions to unavailable at its discretion. Upon receipt of a Change Availability command, the status MAY change immediately or the change MAY be scheduled. When scheduled, the Status Notification shall be send when the availability change becomes effective (Inoperative)
Faulted	When a Charge Point or connector has reported an error and is not available for energy delivery . (Inoperative).

[bleara]

It's the 'charger status' rather than 'charger status connector' I have been looking at which doesn't matter if it's preparing or available just so long as it isn't unavailable. This is my successful 2 days of charging.

The 'charger status connector' is a more useful status.

[m01]

This is particularly annoying when you need it to charge the car in the middle of the night and it doesn't.

How did you setup the timed charging? Did you set the maximum current to 0A to pause charging until the right time? (like here: #1062 (comment)) If so, did that work?

[edc1]

No, I don't do that.

I'm an Octopus Energy customer in the UK on their Agile tariff. I use the Octopus integration in HA. That lets me configure target rate sensors. I have a target rate sensor that comes on when the electricity price meets the criteria I set. And goes off again when the criteria aren't met.

When the target rate sensor comes on, automation (in Node Red) turns the charge_control switch on. That sends a RemoteStartTransaction message over OCPP to the charger, and the car starts charging. Same thing when the target rate sensor goes off. Automation sets charge_control to off and a RemoteStopTransaction message is sent to the charger.

I also have a charge target set on the car. So if that car gets to 80% it tells the charger to stop.

Of course this doesn't work if the charger is in a Faulted state. Which is what's making this setup unreliable.

[edc1]

There are two seperate issues that S&P are looking at for me now. The first is the charger regulary reporting InternalError errors like this:

2024-11-25 05:14:30.165 INFO (MainThread) [ocpp] : receive message [2,"xxxxxxxxxxxx-4c598d93-00000029","StatusNotification",{"connectorId":1,"status":"Faulted","errorCode":"InternalError"}]
2024-11-25 05:14:30.168 INFO (MainThread) [ocpp] : send [3,"xxxxxxxxxxxx-4c598d93-00000029",{}]
2024-11-25 05:14:40.402 INFO (MainThread) [ocpp] : receive message [2,"xxxxxxxxxxxx-643bd725-0000002a","StatusNotification",{"connectorId":1,"status":"Available","errorCode":"NoError"}]
2024-11-25 05:14:40.406 INFO (MainThread) [ocpp] : send [3,"xxxxxxxxxxxx-643bd725-0000002a",{}]

The second is an issue with the charger not reconnecting to Home Assistant after it restarts. From the websocket server logs:

2024-11-03 17:49:56.078 DEBUG (MainThread) [websockets.server] < PING '' [0 bytes]
2024-11-03 17:49:56.079 DEBUG (MainThread) [websockets.server] > PONG '' [0 bytes]
2024-11-03 17:50:06.014 DEBUG (MainThread) [websockets.server] > PING 92 14 d2 a2 [binary, 4 bytes]
2024-11-03 17:50:14.609 DEBUG (MainThread) [websockets.server] = connection is CONNECTING
2024-11-03 17:50:14.611 DEBUG (MainThread) [websockets.server] < GET / HTTP/1.1
2024-11-03 17:50:14.611 DEBUG (MainThread) [websockets.server] < Connection: Upgrade
2024-11-03 17:50:14.611 DEBUG (MainThread) [websockets.server] < Host: xxx.xxx.xxx:9000
2024-11-03 17:50:14.611 DEBUG (MainThread) [websockets.server] < User-Agent: ESP32 Websocket Client
2024-11-03 17:50:14.611 DEBUG (MainThread) [websockets.server] < Upgrade: websocket
2024-11-03 17:50:14.611 DEBUG (MainThread) [websockets.server] < Sec-WebSocket-Version: 13
2024-11-03 17:50:14.611 DEBUG (MainThread) [websockets.server] < Sec-WebSocket-Key: /+zS60gG3tJObiTsdQ2lEQ==
2024-11-03 17:50:14.611 DEBUG (MainThread) [websockets.server] < Sec-WebSocket-Protocol: ocpp1.6
2024-11-03 17:50:14.611 DEBUG (MainThread) [websockets.server] < Authorization: Basic NDAyMmQ4ZjFiM2I0OjEyMzQ1Njc4
2024-11-03 17:50:14.612 DEBUG (MainThread) [websockets.server] > HTTP/1.1 101 Switching Protocols
2024-11-03 17:50:14.612 DEBUG (MainThread) [websockets.server] > Upgrade: websocket
2024-11-03 17:50:14.612 DEBUG (MainThread) [websockets.server] > Connection: Upgrade
2024-11-03 17:50:14.612 DEBUG (MainThread) [websockets.server] > Sec-WebSocket-Accept: SKa1YTL+n4b+fxuAp0xq2hDi9Js=
2024-11-03 17:50:14.612 DEBUG (MainThread) [websockets.server] > Sec-WebSocket-Protocol: ocpp1.6
2024-11-03 17:50:14.612 DEBUG (MainThread) [websockets.server] > Date: Sun, 03 Nov 2024 17:50:14 GMT
2024-11-03 17:50:14.612 DEBUG (MainThread) [websockets.server] > Server: Python/3.12 websockets/13.1
2024-11-03 17:50:14.612 INFO (MainThread) [websockets.server] connection open
2024-11-03 17:50:14.612 DEBUG (MainThread) [websockets.server] = connection is OPEN
2024-11-03 17:50:14.612 DEBUG (MainThread) [websockets.server] = connection is CLOSING
2024-11-03 17:50:14.612 DEBUG (MainThread) [websockets.server] > CLOSE 1000 (OK) [2 bytes]
2024-11-03 17:50:14.990 DEBUG (MainThread) [websockets.server] < TEXT '[2,"xxxxxxxxxxxx-5851f42d-00000001","BootNotifi...wareVersion":"2.2.38"}]' [198 bytes]
2024-11-03 17:50:20.915 DEBUG (MainThread) [websockets.server] = connection is CLOSED
2024-11-03 17:50:20.916 DEBUG (MainThread) [websockets.server] ! failing connection with code 1006
2024-11-03 17:50:20.917 DEBUG (MainThread) [websockets.server] x half-closing TCP connection
2024-11-03 17:50:20.920 DEBUG (MainThread) [websockets.server] > TEXT '[3,"xxxxxxxxxxxx-5851f42d-00000001",{"currentTi...0,"status":"Accepted"}]' [111 bytes]
2024-11-03 17:50:20.920 DEBUG (MainThread) [websockets.server] = connection is CLOSING
2024-11-03 17:50:20.920 DEBUG (MainThread) [websockets.server] > CLOSE 1000 (OK) [2 bytes]
2024-11-03 17:50:21.508 DEBUG (MainThread) [websockets.server] < CLOSE 1005 (no status received [internal]) [0 bytes]
2024-11-03 17:50:21.508 DEBUG (MainThread) [websockets.server] x half-closing TCP connection
2024-11-03 17:50:21.731 DEBUG (MainThread) [websockets.server] = connection is CLOSED
2024-11-03 17:50:21.731 INFO (MainThread) [websockets.server] connection closed
2024-11-03 17:50:21.731 INFO (MainThread) [websockets.server] connection closed

[blacknell]

Did these issues get sorted on 2.2.47?

[bleara]

Simpsons have been excellent on supporting our issues and Emlyn and I have been Beta testing for them over the last few months. They have been downloading code to our chargers and we have been reporting back with logs etc when we have seen issues. The version we are testing at the moment is 2.2.50 which seems solid. I am not sure when this will be on general release but I would imagine this shouldn't be long.

[blacknell]

Can you share what's new and what's been fixed please

[blacknell]

I've had a number of problems getting to grips with my new EV and charger which I discussed in #1551

[bleara]

As Emlyn commented in the other thread if you are using Intelligent Octopus Go because your car supports it then you shouldn't be trying to use HA to control it too.
I can't provide a definitive answer to what has been fixed, you would have to talk to Simpsons for that.
I don't have IOG support for my car so I purely use HA. I detect the car is connected using the cars status but you could use charger_status_connector == preparing, or charger_availability == Off. Then at 00:30 I then turn on charger_charge_control and turn it off at 05:30. I also check the SOC of the car so I can stop the charge early at a level set in HA rather than the cars set limit. I also have a charge restart routine to restart the charge if it is interrupted within the off peak period for whatever reason.

[8muirfield]

Hi All,

I've just got a S&P Home Series V3 Home Plus charger installed and trying now to link to home assistant. I've followed the instructions for OCPP, but unable to get any entities to show in home assistant and not sure I am putting the right URL into the charger app either. I think the Key points are what format to use in the app to link and also what settings to put into OCPP when configuring. Can anyone advise?

Thanks :-)