ECC will execute the when card when neccesary. That the whole point. ECC does not need to know what charger you have, it will start at 05 and stop at 06 in the case shown below
Now it makes total sense! Thanks! 
Way simpler than I thought. Then basically creating a flow so that the controller gets info on the cars battery charge level on a fixed interval, I think I saw a flow like that in the documentation right?
good.
You will connect this flow
to execute when the SoC is changed. But you don’t have to, if not you must change the SoC manually in the device using the slider.
So if you are able to get the current SoC from your car, then you will call the ‘Update current State of Charge SoC card, only when a new value is received. If the the new SoC is not changed from the ECC value, nothing will happen.
I have a simular problem. I get the charging plan populated but the when card “Start charging session” is never executed. I don’t understand why. When the planned start is reached a new plan is created and the charge session is nor started. I tried to work with different “Charger status” with no luck. Great if you have a tip! Let me know if you need any more information. I don’t have a charger I try to get this to work with just a wall plug. Thanks @bwa for a great app! I would love to get it to work, it is what I has been searching for.
send a diag, and I will check
Sent diag file as PM
I experience that the scheduled charging slot is sometimes recalculated when it changes from scheduled to active charging slot.
Say if the cheapest hours planned are from 12:00-14:00 but the car is connected at 12:10, then the charging is recalculated to 13:00-15:00, even though it would be cheaper to start the charging right away at 12:10.
Also it would be great if the ECC would be able have eg. 2 active charging slots, in order to charge at the absolute cheapest hours.
Example: Total needed charge duration of 3 hours before end time could result in charge for two hours, then pause for 5, then start again for 1 hour.
The starttime of next hour, is just a design desicion.
Also the continus charging periods, is also just a design choice.
Don’t expect it to change.
Hi Bjørn-Willy, and thanks for the app. Running it on a Homey Pro (Early 2023,
fw 13.5.0), ECC 2.3.0, price area SE3, driving an Easee charger with a Polestar
4 supplying SoC.
I have read the July exchange about slot recalculation and continuous charging
periods, and your answer that both are design decisions, so I am not asking for
either to change. Two things that I do not think are covered by that.
A bug: set-charging-endhour does not survive a restart
I set the end hour to 17 with the action card. ECC replanned immediately and
correctly to that day’s cheapest hours. After a Homey restart,
charge_end_time_capability was back to 8 and the plan I had asked for was
gone, with nothing to indicate it had changed.
If that action writes a device setting, it looks like the value is not being
persisted. I would expect something set from a flow to survive a restart the
same way a value set in the settings screen does.
This one matters more than it sounds, because the end hour is the only lever for
saying when I actually need the car. One morning the plan was 07:00-09:00, which
were the two most expensive hours of that day (167 and 191 öre, against 58 and
50 at midday). ECC was doing exactly what it had been told, planning backwards
from 08:00. I did not need the car until the evening, set the end hour to 17,
got a correct midday plan, and then lost it to a restart.
A question about 15 minute prices
Sweden has moved to 15 minute settlement and Tibber now shows and bills that
way. ECC is hourly: measure_price_hour.0..47, measure_charging_hour.0..47
and a measure_ladeplan of whole hours.
- Is 15 minute resolution something you are considering?
- In the meantime, is
measure_price_hour.Nan average of the four quarters,
the first quarter, or the old hourly product? It changes how much weight an
hour-level decision deserves, and I would rather know than guess.
Thanks either way, and no rush on any of it.
Will look into it
I did test it now using this
dropdown was updated
and after a restart of app, the dropdown was still 08.00
Did not test reboot, as if dont want it at present time
Is there any other usecase you are using ?
All values are capabilities so they should be persisted
I do set some initial values, but only onAdded
Thanks for testing that properly. I need to correct my report. My “restart” was a hard power cycle after a crash, not a clean reboot, and my Homey has been failing repeatedly and losing all local services. So the value very likely never got flushed to disk, which would be my hardware rather than your app. Sorry for the noise. I’ll retest properly once Athom have looked at the unit. The 15-minute price question still stands if you have thoughts.
regarding 15 minutes interval, I’m just requesting hourly values from nordpool, so I gues they are a average of the 15 minutes steps
It would need some ground rewriting as some of the maths are just +/- hours, and still thinks that your charging bill will stay pretty much the same
Thanks! that lines up with what I suspected. I ended up building a separate fetch straight against Tibber’s own API for true quarter-hourly prices, so your Nordpool feed is only used now as an hourly fallback if that cache goes stale. Wasn’t asking you to rebuild the granularity, just wanted to know where the numbers actually came from before deciding how far to trust them for cost tracking. Appreciate the quick answer!!
