Intelligent Octopus Go and Ohme integration modifications

[andyvee69]

Can you please consider the below as improvements for the IOG/Ohme integration:

If 'provider' is 'OHME' then the Ohme charger is integrated with IOG.

The following settings are not applicable as Ohme control the charge, not Octopus:
Bump Charge
Charge Limit
Ready Time
Smart Charge

Changing these settings can break the IOG/Ohme integration - there are examples in the FB group of users that have ended up with Smart Charging being disabled and billed at peak rate due to altering these settings. Could these please be disabled if provider is OHME.

Also, plannedDispatches are (at the moment) irrelevant for the IOG/Ohme integration. They are NOT when your car is scheduled to charge. They are a superset of times that Ohme use to influence the schedules they create, and in the vast majority of instances are removed from the API at 17:00. plannedDispatches are available via the API even if you are not plugged in.
The Ohme integration in effect works in reverse - billing is generated from the completedDispatches when the session id finalised after you unplug and Ohme send the session data to Octopus.
Could you consider disabling plannedDispatches triggering the IntelligentDispatches binary sensor as it is irrelevant for the Ohme integration and giving people the impression they are getting additional off-peak when they are not.

Example from the API showing provider as OHME
{'registeredKrakenflexDevice': {'krakenflexDeviceId': '00000000-0002-4000-8020-0000000xxxxx', 'provider': 'OHME', 'vehicleMake': 'MG', 'vehicleModel': 'MG4 EV Extended Range', 'vehicleBatterySizeInKwh': '74.40', 'chargePointMake': 'Ohme', 'chargePointModel': 'Ohme home pro charger', 'chargePointPowerInKw': '7.400', 'status': 'Live', 'suspended': False, 'hasToken': True, 'createdAt': '2023-10-12T11:29:58.927656+00:00'}}

[jerbzz]

This would be excellent for my use case as well.

[BottlecapDave]

Thanks for raising this. You'd have thought the APIs would have protected people from making invalid requests but 🤷‍♂️

My only issue is this would be a breaking change, so will need to be marked as such and planned accordingly.

The dispatch sensor always needs to be used with caution as there's outside forces (like not having the car plugged in as you mentioned) that the integration can't track (even for other chargers).

But to summarise, if the provider is OHME

• Only include the dispatch sensor. All other sensors will not be available
• Don't include planned dispatches attribute in dispatch sensor
• Dispatch sensor should only turn on when off peak

[andyvee69]

Correct, that would work perfectly for the Ohme integration.

Octopus have committed to showing planned charge times in the Octopus app in the future, which you can assume will therefore be available via the GraphQL API, but the timescale on that is not set in stone.

[brutus6]

Yes. This would be a good enhancement for owners of Ohme chargers. I'm not currently using the 'charger' device in the integration, just the meter devices with my mini, but I can see it and have set a notification to ping in case that either the bump charge is activated or smart charging is disabled accidentally.

However, that said, I saw an interview with Alex Schoch that Ohme could be integrated into the Octopus App by Christmas, so this would need revisiting, if that happens.

Quote: "I'd be very disappointed if by Christmas we don't have all our IOG customers with an Ohme not seeing a beta screen."

Link: https://twitter.com/sarah_go_green/status/1714206216761528721?t=iO0V203fAg5_NEBL851rmg&s=19

[andyvee69]

However, that said, I saw an interview with Alex Schoch that Ohme could be integrated into the Octopus App by Christmas, so this would need revisiting, if that happens.

I'm pretty sure that was just in relation to seeing charge slots, not control of charge settings. And there is no guarantee that it would be available as plannedDispatches via the Octopus GraphQL API either. Would be nice if it was but we will have to wait and see on that front. Octopus are also ridiculously optimistic on timescales in my experience

[Joshuaharry120]

Agreed, this should be integrated, lots of new HA users coming on and it's causing issues with there chargers.

One to add on the provider, as zappi is now comming to play, need to add zabbi to the provider list also.

[andyvee69]

Other EVSE are controlled by the Octopus app though so the API settings are still relevant.

It is only Ohme that is 'different'

[BottlecapDave]

It's easier to add support for providers than it is to take it away from users (which would be a breaking change in the integration as people would raise bugs if they had sensors, if incorrectly, which were then removed in a minor/bugfix update).

I guess the question is, which way is more common; Octopus in control or the manufacturer?

This would be a lot better/easier if Octopus Energy had an API endpoint that detemined the "features" that were available based on the provider, so the integration could adapt as new providers come on board without intervention.

[BottlecapDave]

Does Zabbi/Zappi control the intelligent charging (like OHME), or is Octopus in control?

[andyvee69]

For Wallbox and Zappi, Octopus are in control via their app so no different to a vehicle integration other than the Target % is instead a % to ADD (rather than charge TO).

It is only Ohme that is different and Octopus are not directly in control.