Wiki Everything you wanted to know about Intelligent Octopus But Were Afraid To Ask

Why write this post?
A lot of people are starting to get interested in IO. I don't think Octopus do a very good job of spelling out the benefits in their website. They have some FAQs, but the same questions keep coming up over and over on the forums.

What is it?
In a nutshell, IO is a split tariff that gives you a cheap off-peak rate for charging your EV and other electrical items in the household, including home batteries.

Isn’t that the same as Octopus Go or Go Faster?
The principle is the same, but in exchange for some benefits which we’ll explain, you allow Octopus to control the timing of your EV charge, so they can choose low carbon intensity and/or cheap wholesale priced time slots.

So I’m not in control of my charge? I don’t like the sound of that!
Well yes…and no. You’re in control of how much to charge and when you want the car to be ready, just like you would be normally. Within those parameters, you’re allowing Octopus to control which half-hour slots the car chooses to get to that target % charge. And you can always override IO if you want to “bump charge” through the day.

OK, but what are the benefits you mentioned for this trade off?
First of all, you get a larger guaranteed off-peak window for using household appliances and charging home batteries, etc. It’s six hours between 23:30-05:30. Go, for example, is a fixed 4 hour window.
In addition, when IO schedules your EV charging slots it sometimes creates schedules that fall outside of the fixed, six hour window. If that happens your EV charging and all your household use in these extra-slots is also charged at off-peak rates.
I have frequently had schedules give me seven or more hours of off-peak rates. On one occasion, I had a total of ten hours of off-peak rates.

Am I eligible?
You need a smart meter and a compatible car and/or charger. Since you’re reading this here, I assume you’ve got or are thinking of getting a Tesla. IO works with the Tesla API to create the charging schedules. The advantage of this is that IO will work with any* home charger. If you have a charger with smart features, you need to disable them so that the charger acts as a dumb switch. IO will control everything via Tesla’s API to start and stop your charging.
*Even your granny charger - but you need to tell IO what the max throughput is when you go through setup so that it can work out your schedules properly.

Some of this sounds too good to be true.
Phantom drain caused by having smart charging enabled in the Octopus app has been fixed as of 30th August 2022. One small side effect appears to be that schedules sometimes take longer to appear in the app after plugging in.

Further questions (to be updated in the main thread body once the edit timer on this post expires)

I have two EVs, can I charge the other while on IO?
Not with IO scheduling the charging, but you can charge any other car in the fixed 23:30-05:30 off peak window or at any other time at peak prices.

What are the rates etc?
Octopus do a decent job of explaining the peak and off-peak rates along with contracts etc. Head over to their pages to discover that.

I asked for a target % of x, but I got less than x.
There are two or three reasons for this.

The first, most common reason, is that Tesla reports battery % differently depending on where you look. The API (that IO uses) reports the gross battery %. This is generally fixed but can fluctuate very slightly. The Tesla app shows usable %. Apps like Teslamate and Teslafi can display both. Quite often, there is a delta of 2-3% which may be down to battery temp or other factors. This usable % will often be recovered as the battery warms up during a drive.

Some users have reported charging % being way off, perhaps 10% or more. This could be down to an error in the onboarding process. Some of the charger database entries incorrectly assume the charger you are onboarding is the 11kW version, without actually saying so in the charger description. The Andersen A2 was an early example of this. If you suspect this may be the case, the easiest thing to do is go through the on-boarding again and choose "Generic 7.4kW charger". It won't affect your functionality on IO in any way.

Lastly, it has to be mentioned that occasionally IO just craps out. It may be down to a comms error, a server error at Octopus' end, or just reasons. IO is a beta product and it's wise to expect one or two quirks from time to time

 

[Cardo]

Those are polling a single car, remember when musky blocked all services pilling multiple cars from a single IP

The streaming API doesn't reveal much, nothing about the state of the car (plugged, etc.)
There is a new last data endpoint but that's not populated yet

See, that doesn’t fit with what’s already been said. If IO isn’t polling frequently to ensure the car is allowed to fall asleep and doesn’t wake up the car when it does, and if the streaming API / last data endpoint doesn’t provide status such as whether the car is plugged in, how does IO work? If IO don’t poll the car before it falls asleep, how does IO know 1) where it is 2) if it’s plugged in in order to set a charge schedule?

 

[goRt]

See, that doesn’t fit with what’s already been said. If IO isn’t polling frequently to ensure the car is allowed to fall asleep and doesn’t wake up the car when it does, and if the streaming API / last data endpoint doesn’t provide status such as whether the car is plugged in, how does IO work? If IO don’t poll the car before it falls asleep, how does IO know 1) where it is 2) if it’s plugged in in order to set a charge schedule?

You can read up on the API end points if you like
The streaming endpoint provides location data
The car has to be polled to see if plugged, that endpoint keeps the car awake, so obviously some assumption is made after the car starts to sleep (streaming endpoint gear to null)

 

[Cardo]

You can read up on the API end points if you like
The streaming endpoint provides location data
The car has to be polled to see if plugged, that endpoint keeps the car awake, so obviously some assumption is made after the car starts to sleep (streaming endpoint gear to null)

Ok, so if you park your car at home and don’t plug in (or do plug in, it doesn’t matter) then the car goes to sleep before it is polled by IO, how does IO know whether the car is plugged in and its SoC without waking it up? Browellm asserts IO will _never_ wake up the car.

A number of people on here seem to be absolutely certain as to how this works, however I just can’t see how it works with the “accepted truth.”

 

[goRt]

Ok, so if you park your car at home and don’t plug in (or do plug in, it doesn’t matter) then the car goes to sleep before it is polled by IO, how does IO know whether the car is plugged in and its SoC without waking it up? Browellm asserts IO will _never_ wake up the car.

A number of people on here seem to be absolutely certain as to how this works, however I just can’t see how it works with the “accepted truth.”

You should address your question to the designers of kraken, I've pointed you to the API and how it functions

 

[Cardo]

You should address your question to the designers of kraken, I've pointed you to the API and how it functions

Indeed.

Are you in agreement with browellm in respect of IO never needing to wake up the car to function? (aside from starting a charge, of course)

 

[GeorgeSymonds]

You can poll the car for its status without waking the car, it just won’t return anything if the car is asleep.

Remember the last valid response you got. As the car takes 5 mins or so to sleep, poll more frequently than that and you’ll be up to date (barring battery drain)

If at 11pm you forgot to plug the car in, going out to plug in will wake the car enabling an update to be returned

The only time you’d need to wake the car is to force a live read, or to perform an action like start/stop charge.

That’s how I’d do it, or some combo of the logic. You’d never wake the car other than to send an command.

 

[Cardo]

You can poll the car for its status without waking the car, it just won’t return anything if the car is asleep.

Remember the last valid response you got. As the car takes 5 mins or so to sleep, poll more frequently than that and you’ll be up to date (barring battery drain)

If at 11pm you forgot to plug the car in, going out to plug in will wake the car enabling an update to be returned

The only time you’d need to wake the car is to force a live read, or to perform an action like start/stop charge.

That’s how I’d do it, or some combo of the logic. You’d never wake the car other than to send a command.

If IO were polling the car sufficiently regularly that it would be able to get an up-to-date status every time before the car falls asleep, this would make perfect sense. However, the suggestion is polling can occur rather sporadically (30-60 minutes?) judging by the fact when you plug the car in it can sit there charging for this amount of time before IO sends a stop command.

My current working theory is that the data polling and charge control are completely separate. Ie.
IO polls car state every ~5 minutes to ensure data is up-to-date.
A separate process that maybe runs every 30 mins polls the above gathered data, puts together a charge schedule and then sends a command to the car to stop charging, if necessary.

This would explain how IO can know the car state without waking it up, but accounts for the car not stopping charging for excessive amounts of time when initially plugged in.

 

[GeorgeSymonds]

If IO were polling the car sufficiently regularly that it would be able to get an up-to-date status every time before the car falls asleep, this would make perfect sense. However, the suggestion is polling can occur rather sporadically (30-60 minutes?) judging by the fact when you plug the car in it can sit there charging for this amount of time before IO sends a stop command.

My current working theory is that the data polling and charge control are completely separate. Ie.
IO polls car state every ~5 minutes to ensure data is up-to-date.
A separate process that maybe runs every 30 mins polls the above gathered data, puts together a charge schedule and then sends a command to the car to stop charging, if necessary.

This would explain how IO can know the car state without waking it up, but accounts for the car not stopping charging for excessive amounts of time when initially plugged in.

I guess there might be a couple of other things, the stop/start charge scheduler aligns with half hour (?) price blocks, and the test charge reuses the same control engine. It might also want a reasonable window to confirm the connection current/rate if energy being added. I don’t have it, but be interesting if the stops do align with a period end, or some logical time point (on the hour/ half hour/ quarter etc).

 

[Cardo]

I guess there might be a couple of other things, the stop/start charge scheduler aligns with half hour (?) price blocks, and the test charge reuses the same control engine. It might also want a reasonable window to confirm the connection current/rate if energy being added. I don’t have it, but be interesting if the stops do align with a period end, or some logical time point (on the hour/ half hour/ quarter etc).

Interesting.

I have noticed when I allow the car to start charging at 2330 it will not stop charging until it reaches a scheduled stop. So sometimes it can fully charge before it even reaches a charge block, if that isn’t until later in the night. This is why I also enabled a schedule in the car with a 0530 off-peak end time.

This would fit in with data polling and charge control being completely separate entities.

 

[goRt]

If IO were polling the car sufficiently regularly that it would be able to get an up-to-date status every time before the car falls asleep, this would make perfect sense. However, the suggestion is polling can occur rather sporadically (30-60 minutes?) judging by the fact when you plug the car in it can sit there charging for this amount of time before IO sends a stop command.

My current working theory is that the data polling and charge control are completely separate. Ie.
IO polls car state every ~5 minutes to ensure data is up-to-date.
A separate process that maybe runs every 30 mins polls the above gathered data, puts together a charge schedule and then sends a command to the car to stop charging, if necessary.

This would explain how IO can know the car state without waking it up, but accounts for the car not stopping charging for excessive amounts of time when initially plugged in.

The streaming endpoint isn't polled, it sends out live data, however when the car's not in gear the frequency drops to approx every 5 mins - hence not catching the plug-in charge start events (actually simply the flow rate changing).
Simply avoided by setting a start time in the car to 23:30 - the car won't start charging but IO can simply override that

 

[Cardo]

Simply avoided by setting a start time in the car to 23:30 - the car won't start charging but IO can simply override that

If the car has a schedule start at 2330, you’re saying it won’t actually start charging at 2330? (Edit: Ignore this, I’ve reread your sentence again. Charging won’t start at plug-in, but will start at 2330. This then leads into my below paragraph)

Without using a car schedule but instead schedules on my EVSE, if I allow the car to charge from 2330 the car will start charging. If IO has set a schedule where the first charge block is at 0100-0130 then the charge won’t stop until 0130, having run from 2330. On the face of it, not a big issue, however if this means the car finishes charging early, IO will remap the charge schedule and remove further blocks, including any that may be after 0530, meaning I lose out on extra off-peak periods. This is why I’ve also set an end off-peak schedule for 0530 in the car, which works fine as long as the car isn’t on fumes.

 

[Yuff]

I've got two cars so I'll be constantly switching between scheduled and dumb depending on which car is plugged in.

I look forward to forgetting to switch the charger mode and charging at peak times

the octopus app and Tesla app work pretty well from what I have experienced.
we have 2 cars and the Tesla is much easier to connect with, than our E-tron.
the Tesla is a dream to talk to compared to Audi ( so much so i am changing it Mar 1st).
however I connect the Tesla to the 7kw charger and I have the E-tron on a timer with the granny charger and IO works perfectly.
if I had two 7kW chargers I would experience load issues especially during the 23:30-05:30 off peak hours, so IO gives us the perfect flexibility currently( pun in tended )

 

[Utumno]

Ok, so if you park your car at home and don’t plug in (or do plug in, it doesn’t matter) then the car goes to sleep before it is polled by IO, how does IO know whether the car is plugged in and its SoC without waking it up? Browellm asserts IO will _never_ wake up the car.

A number of people on here seem to be absolutely certain as to how this works, however I just can’t see how it works with the “accepted truth.”

Tessie manages happily without waking the car if you don’t want it to so it’s certainly possible to do this.

I expect Kraken will monitor a key timestamp somewhere that doesn’t trigger the car being woken. Here’s a screenshot of Tessie monitoring our MY, both plugged in and sleeping for nearly 8 hours as an example.

 

[goRt]

That will

Tessie manages happily without waking the car if you don’t want it to so it’s certainly possible to do this.

I expect Kraken will monitor a key timestamp somewhere that doesn’t trigger the car being woken. Here’s a screenshot of Tessie monitoring our MY, both plugged in and sleeping for nearly 8 hours as an example.

Simply monitor the car for longer after it signals null, keeping the car awake for longer initially to check for plug events

 

[Utumno]

That will

Simply monitor the car for longer after it signals null, keeping the car awake for longer initially to check for plug events

Except this isn’t what actually happens.

 

[WllXM]

Tessie manages happily without waking the car if you don’t want it to so it’s certainly possible to do this.

I expect Kraken will monitor a key timestamp somewhere that doesn’t trigger the car being woken. Here’s a screenshot of Tessie monitoring our MY, both plugged in and sleeping for nearly 8 hours as an example.

Absolutely, you can pull the last state API without waking the car. Then I guess Octopus can simply check if charging_state=Disconnected in the JSON. If it is, no further action needed. Otherwise, create schedule, and then wake up the car to start / stop the charge accordingly.

Look at the 'Firmware' tab on Tessie to see all the flags pulled.

 

[goRt]

Except this isn’t what actually happens.

All I state is how the API works
Go argue with us on GitHub if you disagree

 

[goRt]

Absolutely, you can pull the last state API without waking the car. Then I guess Octopus can simply check if charging_state=Disconnected in the JSON. If it is, no further action needed. Otherwise, create schedule, and then wake up the car to start / stop the charge accordingly.

Look at the 'Firmware' tab on Tessie to see all the flags pulled.

Latest_vehicle_data isn't widely deployed or populated at the moment

 

[WllXM]

Latest_vehicle_data isn't widely deployed or populated at the moment

True. I assume they are polling the API every few minutes so they can cache the result themselves before catching a 408. That is actually consistent with my experience as my car takes 20-30 mins to go to sleep whenever I arrive home.

 

[goRt]

True. I assume they are polling the API every few minutes so they can cache the result themselves before catching a 408. That is actually consistent with my experience as my car takes 20-30 mins to go to sleep whenever I arrive home.

So they're keeping the car awake for a period of time - either until the car is plugged or, say, 15 mins, then letting it enter its sleep cycle
Kraken could obviously do the same
For my automation I wait a minute from null and then read the vehicle state