Continuing problems and frustration with the Simpsons charger

[blacknell]

I'm starting a new thread because I'm hoping it can bring some focus to getting to a solution. Some of this is mentioned in #1372 and #1787

The problem is that the charger disconnects randomly sometimes about an hour into a night charge. On Friday it started charging at 2330 and then shortly after 0030 stopped. I got a voice alert in the bedroom (only created because it keeps messing up our travel plans) and then tried to restart the charging session. No joy.

My charger just refuses to play ball. As I see there are 6 variables, any one of which could be causing the problem.

1. My HA automation
2. Octopus dispatching IOG events
3. The integration between Octopus and my Audi ( a 3rd party called enode)
4. My Audi's own software (very poor)
5. My Simpsons charger (a v2 running 2.3.28 firmware)
6. The HA OCPP integration

I've since removed the Octopus integration completely which deletes 2&3 from the list.

I have discovered from a bunch of tests and then using Claude to analyse the OCPP integration against the OCPP spec that it does a pretty good job.

I found the following problems though

ChargerAvailability staleness

post_connect_success never resets after the first connection, so the integration stops proactively re-checking charger status after that — it just caches whatever it last heard and waits. If the charger reconnects or reboots without volunteering a fresh StatusNotification, that cached status goes stale and stays stale indefinitely, so the switches and start/stop logic keep behaving as if the charger were genuinely Unavailable/Faulted long after it's actually recovered — until you manually force a resync (e.g. via trigger_custom_message).

Switching on/off ChargerAvailability fails

As a result of the above, trying to switch on/off the availability just fails. The switch always toggles back. Here are some logs

�[32m2026-08-17 16:21:25.726 INFO (MainThread) [ocpp] : send [2,"7877b84d-7b7b-4bdb-8a26-59868d2528b4","ChangeAvailability",{"connectorId":0,"type":"Operative"}]
�[32m2026-08-17 16:21:25.796 INFO (MainThread) [ocpp] : receive message [3,"7877b84d-7b7b-4bdb-8a26-59868d2528b4",{"status":"Rejected"}]
�[32m2026-08-17 16:21:25.797 INFO (MainThread) [ocpp] : send [2,"87d4dc81-e7af-4bc1-aab0-7eb329c4bb27","ChangeAvailability",{"connectorId":1,"type":"Operative"}]
�[32m2026-08-17 16:21:25.868 INFO (MainThread) [ocpp] : receive message [3,"87d4dc81-e7af-4bc1-aab0-7eb329c4bb27",{"status":"Rejected"}]
�[33m2026-08-17 16:21:25.869 WARNING (MainThread) [custom_components.ocpp] Failed with response: Rejected

If you then send a trigger_custom_message to get the status it clears the staleness and availability behaves itself for a while longer. My view is that the Simpson is not explicitly tell the OCPP is available again (its not mandated but it should). The integration assumes it will (it should not).

Note that if the charger is inoperative and you tell it to go operative (as I did above) it should do so and confirm (unless there is a hardware fault for example). In this case, it didn't - it must have decided I'm already operative I'm rejecting your request rather than silently ignoring or sending a status update. We know this because requesting the status immediately resulted in a confirmation it was operative.

After the charging stopped (randomly) it is impossible to restart the session.

It just keeps refusing to charge. Eventually I have to get up and go outside to unplug/plug in the cable and then it starts again. You can't believe how frustrating this is. Some nights that doesn't work and I have to go to the consumer unit outside and cold boot the charger).

I'd gladly help test firmware revisions, run local tests to help diagnose