Replies: 6 comments 19 replies
-
|
Did you also report the temperature unit issue to S&P? |
Beta Was this translation helpful? Give feedback.
-
|
I've reported that to them too now. We'll see if they fix it. |
Beta Was this translation helpful? Give feedback.
-
|
Looks like in the current firmware version the temperature units are fixed! 🎉 I'm no longer seeing the |
Beta Was this translation helpful? Give feedback.
-
|
Cool. Which version are you running? I must admit I didn't check if this was fixed in 2.2.39. |
Beta Was this translation helpful? Give feedback.
-
|
2.2.40 |
Beta Was this translation helpful? Give feedback.
-
|
Good stuff. I'm glad they've fixed that one! |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks very much for the suggestion. It doesn't look like I can get diagnostics data from the charger. Querying the configuration for
When the charger starts, it tells me it supports the following feature profiles: The ocpp.get_diagnostics action is only registered in Home Assistant if the charger also supports: 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 |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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:
|
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
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? |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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: The second is an issue with the charger not reconnecting to Home Assistant after it restarts. From the websocket server logs: |
Beta Was this translation helpful? Give feedback.
-
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:
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:
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?
Beta Was this translation helpful? Give feedback.
All reactions