OCPP HASS integration

[KipK]

@matth-x , have you seen this ?

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

I have tried, not sure it is compatible with OpenEVSE yet. I see in the logs there's some missing entities we can still provide from openevse ( SOC, live power ) , and seems the actions are not working yet. But i'm not an HASS expert so it could be me.
However, that's a quick way to setup an OCCP server, probably easier than Steve. Worth to check.

[matth-x]

Hi @KipK,

Yes indeed, I was already contacted because of it last year, set up a Home Assistant and tested the connection. After a few changes the connection worked, but unfortunately I had no real test cases to check all features of HA. We could revive the discussion: lbbrhzn/ocpp#210

If you can provide me with the full logs, I can take a look (you can also send them via email if preferred). Perhaps the final steps are super simple and we can get OpenEVSE on the list of supported chargers really quickly.

[mathieucarbou]

FYI I have tried it some weeks ago before working on my HA integration for OpenEVSE and I was not able to make it work with OpenEVSE. I've installed it through HACS (Open Charge Point Protocol (OCPP)) and connected the OpenEVSE box but I don't get any metric.

[matth-x]

Hi @mathieucarbou, thanks for sharing your findings!

This doesn't look too bad imho, it could be really just a matter of the configuration. Unfortunately, I don't have a reasonable HA test setup at the moment, but I will definitely set it up again.

In case someone would like to give it another try in the meantime, I'm sharing my thoughts on the screenshots above: the OCPP connection seems to work, but the transactions are missing (most inconnu fields are about transaction-related data). By default, OpenEVSE waits for an authorization before starting a transaction. So it could be worth a try to enable the "Authorize automatically" option with any idTag.

[mathieucarbou]

I can try now! I still have the OCPP integration installed.

[mathieucarbou]

The intermediate screen where we have to select the measurements are really a pain: we should have a (un)check all and also maybe they should all be checked by default. Any sensors can be disabled by the user in HA afterward.

What should I put in the ID tag ?

[mathieucarbou]

I've put the SN.

So, it is the same. After waiting several minutes, all the sensors are unknown. I have activated all measurements this time.

Note: I am running with the latest evse release and latest commit of gateway (master branch).

[mathieucarbou]

I have some errors in HA logs:

Warning: charger reported Rejected while setting MeterValuesSampledData=Energy.Active.Import.Register,Energy.Reactive.Import.Register,Energy.Active.Import.Interval,Energy.Reactive.Import.Interval,Power.Active.Import,Power.Reactive.Import,Power.Offered,Power.Factor,Current.Import,Current.Offered,Voltage,Frequency,RPM,SoC,Temperature,Current.Export,Energy.Active.Export.Register,Energy.Reactive.Export.Register,Energy.Active.Export.Interval,Energy.Reactive.Export.Interval,Power.Active.Export,Power.Reactive.Export

debug logs:

2023-06-03 14:29:05.339 INFO (MainThread) [custom_components.ocpp] config = {}
2023-06-03 14:29:13.196 INFO (MainThread) [custom_components.ocpp] Websocket Subprotocol matched: ocpp1.6
2023-06-03 14:29:13.197 INFO (MainThread) [custom_components.ocpp] Charger websocket path=/OpenEVSE
2023-06-03 14:29:13.197 INFO (MainThread) [custom_components.ocpp] Charger OpenEVSE connected to 0.0.0.0:9000.
2023-06-03 14:29:15.243 DEBUG (MainThread) [custom_components.ocpp] Feature profiles returned: Profiles.REM|SMART|FW|CORE
2023-06-03 14:29:15.272 DEBUG (MainThread) [custom_components.ocpp] Get Configuration for NumberOfConnectors: 1
2023-06-03 14:29:15.293 DEBUG (MainThread) [custom_components.ocpp] Get Configuration for HeartbeatInterval: 3600
2023-06-03 14:29:15.384 WARNING (MainThread) [custom_components.ocpp] Rejected while setting MeterValuesSampledData to Energy.Active.Import.Register,Energy.Reactive.Import.Register,Energy.Active.Import.Interval,Energy.Reactive.Import.Interval,Power.Active.Import,Power.Reactive.Import,Power.Offered,Power.Factor,Current.Import,Current.Offered,Voltage,Frequency,RPM,SoC,Temperature,Current.Export,Energy.Active.Export.Register,Energy.Reactive.Export.Register,Energy.Active.Export.Interval,Energy.Reactive.Export.Interval,Power.Active.Export,Power.Reactive.Export
2023-06-03 14:29:15.435 DEBUG (MainThread) [custom_components.ocpp] 'OpenEVSE' post connection setup completed successfully
2023-06-03 14:29:15.524 DEBUG (MainThread) [custom_components.ocpp] trigger status notification for connector=0
2023-06-03 14:29:15.540 DEBUG (MainThread) [custom_components.ocpp] Received boot notification for OpenEVSE: {'charge_point_model': 'Advanced Series', 'charge_point_serial_number': 'B8D61A0D9F10', 'charge_point_vendor': 'OpenEVSE', 'firmware_version': 'local_custom_1e6b11b3', 'meter_serial_number': '8.2.3.EU'}
2023-06-03 14:29:15.546 DEBUG (MainThread) [custom_components.ocpp] Updating device info charger: {'charge_point_model': 'Advanced Series', 'charge_point_serial_number': 'B8D61A0D9F10', 'charge_point_vendor': 'OpenEVSE', 'firmware_version': 'local_custom_1e6b11b3', 'meter_serial_number': '8.2.3.EU'}
2023-06-03 14:29:15.621 DEBUG (MainThread) [custom_components.ocpp] trigger status notification for connector=1
2023-06-03 14:29:33.304 DEBUG (MainThread) [custom_components.ocpp] Connection latency from 'central' to 'OpenEVSE': ping=16.0 ms, pong=17.0 ms
2023-06-03 14:29:53.322 DEBUG (MainThread) [custom_components.ocpp] Connection latency from 'central' to 'OpenEVSE': ping=1.0 ms, pong=15.0 ms
2023-06-03 14:30:13.396 DEBUG (MainThread) [custom_components.ocpp] Connection latency from 'central' to 'OpenEVSE': ping=14.0 ms, pong=43.0 ms
2023-06-03 14:30:33.414 DEBUG (MainThread) [custom_components.ocpp] Connection latency from 'central' to 'OpenEVSE': ping=1.0 ms, pong=15.0 ms
2023-06-03 14:30:53.430 DEBUG (MainThread) [custom_components.ocpp] Connection latency from 'central' to 'OpenEVSE': ping=1.0 ms, pong=12.0 ms

[matth-x]

Apparently the transaction failed to start. Can you capture the logs at the moment where you plug the charge cable?

The ID tag in the screen shot is a good choice.

The error message means that for the moment, only the default measurands (energy and power) will be reported. The issue here is that HA queries sensor values which don't exist (e.g. the fan speed). Maybe it's possible to remove the unsupported fields from the query. But I can also add a workaround in the next OCPP upgrade and can also think of good reasons why HA queries everything by default.

[mathieucarbou]

@matth-x : I selected all the measurements when adding the integration. The problem I see with the measurements setup screen is that it's really hard for a normal user to know what's available. Instead a user knows what he wants ;-)
For example, OpenEVSE does not report any power factor or reactive power. But I would like to... So I basically selected them all, considering that it should be up to the OCPP protocol to do a sort of handshake about what's available and what's not.

[mathieucarbou]

The vehicle was already plugged and in charge when I activated OCPP. It is also possible that on OpenEVSE size, we cannot activate OCPP live and it requires a restart... I didn't test that.

[matth-x]

I agree that it would be easier if OCPP just ignored the superfluous items or specified a handshake mechanism. The workaround will be that by default, OpenEVSE will send all available readings. If HA doesn't need all of them, most likely it will just ignore them.

The Auto-Authorize reacts on the plug-in event, so yes, unplugging and plugging again is needed in this case to start the transaction.

[fhteagle]

I will be the first to admit that I am a bit ignorant of exactly what OCPP is capable of. However, is there any benefit to going HA -> OCPP -> OpenEVSE, vs HA -> HTTP API -> OpenEVSE as provided by https://github.com/firstof9/openevse already? Not a snarky question, I am genuinely trying to understand the difference.

Thanks.

[mathieucarbou]

Same case here: I did a more complete HA integration myself and see no value in OCPP because it currently offers very limited features. The standard still need to grow more I think.

[matth-x]

It would be absolutely no problem for me to officially recommend the HTTP interface over OCPP for the HA connection. However, it is problematic to have outstanding compatibility issues with the HA-OCPP package. There is a chance that the same issues could occur with other DLM systems as well where OCPP is the best option.

Can someone give it another try? I changed the factory defaults and added a possibly helpful config key here: https://github.com/matth-x/ESP32_WiFi_V4.x

Any insights would be highly appreciated!