Where to?

[hoggyhoggy]

Not a feature request more an enquiry - how far do you want to go with this? There are some things which CAN be done but the merits vs time spent are dubious (ultimately in the back of my mind I'm acutely aware that Ohme have a new app on the way and as such have a nice opportunity to do things that will stop this integration functioning. Equally this may have slipped under the radar for now over the holidays so they could rug pull sooner or later should they wish)

Basically, a few things I've done personally with it that may/may not be of interest are:

Switching vehicles - This gets messy as you then need to keep track of all the possible vehicles but is Doable

GET.../v1/carBrands
GET...v1/carModels?carBrand=SOLAR (Example Solar Charge Brand) POST.../v1/cars

Use case is probably only of use to those with multicar households & those with non solar matching chargers (i.e Ohme Go) to either toggle between 2 different cars being charged or to auto switch to pseudo solar matching charging 6A/10A/16A etc... Octopus Exports at 15p may negate the value of solar charging - it is often worth more to export & buy back overnight.

Changing charge current Now this is incredibly inelegant on the Ohme Go (newer Pro's may be different, especially if you can change max charge rate from say the installer menu via API - I do not have this to test) Currently you can switch vehicles to adjust charge rate (I used to have to rummage around looking for different vehicles such as an early Leaf - 3.3kW and so on) but now you can just use the solar group to ramp up and down BUT there is a catch:

Each vehicle change is not handled on the fly, it stops the charge and then restart. Once in a while this isn't so bad, but solar matching makes this really hard on the cars contactors as it stops & starts charging constantly. However, you can move gracefully from 32A to 6A by using "Trickle" cars (Sorry, again MG ZS quirks...) so you can drop down to 6A uninterrupted. You can't however go back up.
Ohme/IOG does however manipulate the charge rate overnight without halting current charge, however I am unsure how this is achieved but can be explored.

A 3rd option is the "create your own car" portion of the app, although I've not yet seen if they move gracefully through charge rates or not.

Preconditioning Probably of little merit but I guess some people might want the option to toggle Precondition on/off via HA over summer or something.

I'm sure there are features of later Ohme devices I'm unaware of (You/AndyV have a better handle on that) but as you've probably discovered they are relatively trivial to work back!

[hoggyhoggy]

one further thing (and food for thought more than anything) is taking a leaf from Octopus's book in regards to API usage. I know their Kraken team has asked for identifying headers in requests from some of the more popular HA integrations, so they know if specific userbases of integrations are impacting / causing issues. I know Ohme have neither blessed nor condemned this yet, but it may be an olive branch you can use along with pinky promise that should something start being a problem it would be acted upon ASAP. The other side of the see-saw being that they (Ohme) could then (temporarily) block access from requests with those headers until issue is fixed.

[dan-r]

So for my personal use, the goal was always to get data out of the charger rather than pushing anything to it. From requests on here and a surprising amount of engagement, I've ended up adding switches/inputs to replicate most things from the app. These have proved to be very useful for my automations (eg. auto approving charge if car says its plugged in and I'm home), and there's a lot more potential now I can control the charger through Home Assistant.

I'm definitely open to going further with it, so I'll give my current views on the suggestions you gave:

• Switching vehicles - I'm hesitant to do this for now as I believe the new app has support for vehicle switching, which could save a lot of work on my end
• Changing vehicle current - This would be nice to have, especially for those with solar panels/energy storage, but as you say all the current methods are pretty hacky - again potentially the new app has more control over charge limits that we could use
• Pre-conditioning - I don't have my car API connected (the Nissan integration is flaky at best) so its not as useful as it could be for me, but I can still see how it could be beneficial to turn on 'pre-conditioning' to let the car draw from the mains again. This is the most likely of the three to be done soon as it would be pretty easy to do, even if not awfully useful.

In terms of additional features, I don't think there really is all that much different. I expect the hardware is capable of more, but if so it hasn't been exposed to users... Maybe in the future.

In the spirit of open source, I'd also be very grateful for any contributions of features/fixes if any developers feel up to it, or even just to sanity check some of my logic from time to time.

[dan-r]

their Kraken team has asked for identifying headers in requests from some of the more popular HA integrations

I wasn't aware of this from Octopus but it makes perfect sense and I was considering adding a header to identify this integration, but just never got round to it.

If it means keeping this going, I'd of course be happy to comply with any restrictions on polling or headers for auditing if Ohme get in touch.

At the end of the day nothing I'm doing here is out of malice or trying to cause a problem for Ohme - I bought the charger, I like the charger, and I like it even more now I can get some data out of it :)

[andyvee69]

Personal views -

Taking this a lot further may result in significant rework with the new app on the horizon. I'll try and see if I can find anything out ref API changes. New app will support multiple vehicles, multiple chargers, and that awful graph will go. So maybe quite a few changes.

30 sec refresh rate isn't going to cause Ohme an issue I've been unofficially told ... Read in to that what you want, but that doesn't prevent someone higher up the food chain putting a stop to this. Request headers might well be a good idea ... I'll see if I can get any 'feedback' on that

For now, sticking to reading data for automating seems sensible. Otherwise this is likely to morph into a HA replica of the Ohme app

[dan-r]

Agreed - for now its at a stage where it has everything I can see the majority of users wanting, except for more solar/energy storage-related stuff, but I've no real drive to implement those at least for now (and nothing to test on!).

30s seems fair to me, and I probably will add headers to all requests in one of the upcoming updates. It seems as if the most popular Octopus integration sets the user-agent to integration repo name/integration version, so I'd just do the same.

Of course polling is not ideal and having some way to have events 'pushed' to us would be amazing, but unlikely to ever happen without a more open API (MQTT/Websockets endpoint?) or some cooperation. It'd also be nice to change the auth to use SSO, which would also require some cooperation, but make it even more trackable from Ohme's side. It would also mean we don't need to store the username and password in Home Assistant, just a token.

[hoggyhoggy]

The old Ohmes used to display the Websocket on the screen but that got blanked a while back...anyway, enough history I digress!
All just ideas/thoughts, it's your effort / baby so you are free to do as you see fit: You may even convince me to retire my Powershell version soon!

[dan-r]

I sat through a powershell course a few years back - I tend to spend more time trying to find function names than writing code!

If there's anything you need adding and I don't get round to it, feel free to tinker around and contribute (if you know python!). Or if you've any logic/powershell you wanted to share in private (email on my profile) it should be fairly simple to translate to Python.

Thanks again for your input on this, it's very useful especially as you've had a lot more time to play about with the API.

Dan

[hoggyhoggy]

I think we've pretty much covered most things between this and other threads. There is ultimately only so much relevant fields to pick from and lets be real, it is ultimately a fancy switch!

[dan-r]

Very true. Thanks for your insights. I'll close this issue for now but may revisit it after the new app release.

Dan