Do we know if they are working on it ?
1 - 17 of 84 Posts
Oh - how does that work? AFAIK the simple comms between car charger and AC chargepoint doesn't allow the car to send that kind of information. Obviously when Octopus is speaking to the car directly, it can get that, but when controlled through the Ohme integration, for example, it surely has to do without?Octopus want to do more than just turn the charging point on and off, they want to read the SoC (and possibly other stuff too).
Ah... it seems that Ohme can integrate with some car manufacturers to find the SOC from the car. So I guess it's Ohme doing that bit, rather than Octopus.
Charging with API Support
It seems to me that the best way to handle this is to separate out the code that speaks to the car, to present a standardised interface. It's the sort of thing the free software community is good at. Then Octopus can concentrate on the proprietary bit of code that does the scheduling (deciding when each car should charge), and hobbyists can concentrate on how to make their car and/or chargepoint start and stop charging. Octopus would obviously have to maintain a reference implementation, but they've already got those.Kind of sums up how it is all going. Lots of complexity, lots of cost, great while it works but hard to maintain in production with all of the combinations of car and charge point.
I mentioned in a Leaf-specific thread that OVMS seems to be one possible way to control charging in a homogenous way - they've already put effort in to how to speak to the various car models.
Not through the existing primitive protocol between car and (AC) chargepoint.You must be able to get state of charge / level communication between car and charger to some degree surely ?
I agree - while it would be nice to have, it turns out that the Ohme can get charge level from only some cars, so IO must be able to work without it. I'd be perfectly happy with being able to tell Octopus I want to charge for a total of 4 hours between now and noon on Saturday, for example. Though it's not much extra work for them if I ask for 40% to be added, once they know that my car is X kWh and my chargepoint is Y kW (taking charging losses into account). Except when I'm doing a 100% charge for balancing, which can be very slow. But that can just be done using the 6-hour timed slot.They may very well want it but I thought this was primarily about balancing load / demand for car charging. So can be turned off / on as required.
Hmm - one downside I can think of... if IO cannot monitor charge level on car, then it can only know that it turned the chargepoint on for a total of 4 hours. It wouldn't know whether the car was actually plugged in and taking charge. So if I happened to use the car just when IO decided to charge, I'd miss out.Must do as there are people on the forum with Ohme/original MG ZS. So on the back of that my Leaf is actually an MG ZS on the Ohme, lol. Carwings integration does my head in hence running it dumb.
But I believe smart chargepoints are required to monitor the energy supplied to the car. So in addition to being able to turn chargepoint on and off, I guess IO would ideally also want feedback on power delivered to the car from the chargepoint, even if they can't get it from the car.
But of course, after the unplanned journey I can just update my IO request if necessary, to ask for an additional 30 minutes, for example.
Yeah, that's one way they do it. But with an Ohme charger, it can operate without being able to speak to the car at all.IO monitors car charge level, not by the charger talking to their systems, but by the car data that is shared with the owners phone app, also being shared with octopus.
Ohme are able to speak to some cars via the manufactuer's back end. For others, it still works with IO, but you don't get the charge level feedback.Only because Ohme do the same trick of talking to the car’s manufacturer’s back-end API to get the data. The Ohme-to-car connection is still just a dumb type 2.
I assume there's some constraint to prevent abuse of the system? Eg can I tell it at 4pm that I want 28kWh by 8pm and get peak-time energy at cheap rate ?My understanding is for cars that cant get the SoC, the app offers a number of kWh you want to put in (bit like Zappi on boost). So it will assume you get say 7kW and work out how many half hour slots you will need and go from there. So you could well get extra slots anyway if it thinks you need a lot of charge.
Had hoped someone might have replied. Note that I have neither Ohme nor Intelligent Octopus - just doing some research and speculation, since there is now a price benefit in addition to the longer hours, so I have to decide whether to get myself a compatible chargepoint. (Direct integration from Octopus via car seems unlikely since Leaf API doesn't offer ability to turn off charging.)Building on what you are saying... Do you only get extra off-peak charge slots if Octopus can see your SOC? Cheers
Given that Octopus appear to delegate all the charge scheduling to Ohme, then in order to allow additional off-peak hours, Ohme would need to report back to Octopus which hours were used for charging, so that Octopus could bill correctly. This seems like quite a lot of effort, so I concluded that you probably wouldn't get that perk when using Ohme (whether or not Ohme integrated with your car).
However, if you then follow that through to the next logical step, there doesn't seem to be any particular reason why Ohme should be the only charger that is allowed to access IO - if there's no communication back from Ohme to Octopus, then they're just the same as any other chargepoint that has no communication back to Octopus. Yes, Ohme do have support for an Agile-level of smart charging, but since IO is a fixed price during the (default) off-peak hours, again, I can't see what special features Ohme would be offering.
(I did speculate that Octopus might supply fake prices during the off-peak hours, to persuade the Ohme algorithm to charge at the cheapest times, which benefits Octopus if not the end user, but that still ends up horrendously complicated, since any pricing Ohme shows to the end-user would be based on these fake prices, and therefore rubbish. Unless it was just fractions of a penny, I suppose...)
TL;DR : sorry, no idea ! But for me, cheaper rate and longer hours would already be enough of an incentive. Just a pity that Ohme charger is tethered and doesn't have solar integration. They they do have a new untethered model coming... And maybe there'll be some news on the Zappi front.
Okay, so I got that completely wrong. So there has to be some sort of mechanism where Ohme report back to Octopus when charging happened. But I assume Octopus would want some influence on which extra hours are used.My Ohme can’t read my EV’s SoC and I can (and do) get cheap slots outside of the default Intelligent off-peak hours.
I guess one possible mechanism would be that Octopus advertise some extra slots as 10p, and if the Ohme algorithm chooses them, Octopus bills the customer at that rate for that period. Otherwise, I'm not sure how they can choose good times to charge, rather than just let people get round-the-clock cheap-rate electricity. (There was someone on here that they reported that they charged their Tesla on a granny charger with IO - because it couldn't come even close to filling the car in 6 hours, they got lots of extra cheap slots.)
I've already proved that I don't know what I'm talking about, but I'd be surprised if it made much difference whether the Ohme could see the SOC or not. Even when it can't, it is responsible for getting N kWh into the car by a certain deadline.I've re-enabled the Ohme to see the cars SOC which works fine but when plugging the car after 5PM in it always starts charging immediately so... turned the car's charge timer back on until 10mins before it is supposed to start charging at 11:30. Seems to work well with no usage before 11:30. Not seen any 10p random slots yet. Perhaps using the granny is a good shout but I would have to make up a 32A commando > 13A Socket.
I think the granny trick only worked for the other chap because his Tesla charging was controlled by IO directly. When using IO via Ohme charger, I assume you only get extra cheap slots when Ohme reports to Octopus that it did some additional charging.
An interesting experiment might be to see if those correlate with cheap agile slots.Looking at a recent bill for Octopus Intelligent I can see the random 10p slots. The car was not plugged in. I guess if it was the car/Ohme would trigger and any other household load is just a welcome bonus.
It certainly makes it easier to understand if Octopus simply make cheap slots available unconditionally on whether the car is plugged in and charging (on the assumption that if the car is plugged in, the Ohme will take advantage of such cheap slots automatically).
On another recent thread about IO, it has been mentioned that it is normal behaviour to start charging immediately, but that only lasts a few minutes before it stops and waits for a cheap slot.I've re-enabled the Ohme to see the cars SOC which works fine but when plugging the car after 5PM in it always starts charging immediately so...
There's another thread talking about IO. As far as I can tell, when IO is using the car API directly, it has to allow the car to start charging so that it can get notified that the car is plugged in. They stop the charge as soon as they have noticed.Apperently the Ohme is correctly setup but charges immediately when plugged in which is not what I want being 40p peak!
===========================
Thank you for your email. Your vehicle is registered on the account which would imply the test charge was completed. Alongside this the charger will automatically charge the vehicle once plugged in but intelligent octopus should stop the charge within 30 minutes so that it can be set to the right times for the tariff.
For the Ohme charger, it ought to be possible in principle to discover from the chargepoint that the car is plugged in without actually starting to charge - the chargepoint can know from simple signalling between car and chargepoint. Whether it's actually implemented that way is another matter, of course.
But I assume that with Agile, Ohme operates independently, based on the published prices - you automatically get that price whether Octopus know you charged or not.Variable pricing worked with Agile without issue.
When using IO, there seems to be some additional requirement that Ohme tells Octopus about what's going on : if nothing else, so that Octopus costs charging slots at the cheap rate, but don't know whether it's Octopus that tells Ohme what slots it's allowed to use, or if Ohme decides for itself and simply tells Octopus.
Hmm... does mean that simply plugging in your car at the same time as you turn on your oven for your evening meal, you get all that energy at cheap rate ?Following your advice decided to pull up my big boy pants and it works! 👍
Yes, I got that. I thought you meant that when you first plugged in the car, it started charging, and that was cheap rate because it was part of the IO sequence.No, just talking about the ohme plug-in sequence, cheers
1 - 17 of 84 Posts
Speak EV - Electric Car Forums
A community for enthusiasts of all makes and models of EV from BMW to Tesla, Renault, Nissan, Mitsubishi and more. Join the electrifying discussion today!
Full Forum Listing
Recommended Communities
Join now to ask and comment!
