I’ve fixed a couple of issues with support for Safari this morning while testing for a user, the timepicker style is now consistent and the OpenEVSE configuration boxes do not overflow the page resulting in clunky behaviour. Latest version is 1.2.1 and available in both stable and master branches.
Not that Im aware, I need to do more testing though.
It is on my list 
@TrystanLea Thanks for the reply.
There is a possible bug in the UI, am going to test more tonight but for info, the time required for charging doesn’t change until you click the battery icon even though the SOC is updated on display, the time part seems to not be called to refresh / recalculate.
Came across this thread which has got me thinking adding an openEVSE controller, contactor and a network work connection and using exsisting charger cable (from consumer unit) would allow me to utilize the Octopus agile tariff much more effectively that currently manuallysettign the car for the cheapest hours in the night.
It would seem I can manually enter the SOC % manually in demandshaper and it would do the rest. Alternatively it could get SOC from OVMS ?
I do have an Ohme cable currently but it doesn’t work woth Lineage OS, so exploring alterntives.
Possibly the openEVSE controller is overkill, just need a 240v relay/MCB that can be turned on and off with MQTT RAPI API ?
Hi @deano
I don’t think you can use the intelligent part of scheduling and SOC unless you use a OpenEVSE device.
The other thing to think about even if you can fudge something is that charging from a plug limits your charge rate to approx 2.4kW, ideally you want to charge as quickly as possible at the best time so you get the cheapest charge, with OpenEVSE you can charge at approx 7.4kW depending on your car.
The SOC can be set using MQTT and sending the value as a percentage but without the % sign to the topic emon/openevse/soc, i do this using NodeRed script that pulls the information from Renault services and then publishes it, but the SOC is only read by the OpenEVSE code and not other devices that can be controlled.
Do you really mean kWh? That’s a unit of energy, not power.
fixed
I’m thinking of using the inteligent part of the demad shaper to switch a solid state realy. This would controller an exsisting “dump” 32amp type2 charger.
I’d be quite happy to set the % of charge required. (dmeand shape would need to know the battery capacity) then just work hout hours required and use the cheapest ones.
Thanks
Just a little update in case anybody finds it useful info. I’ve now got Homeassistant updating the charge level from my BMW i3. It uses it’s module to enquire the status of the car, and then I’ve got an automation which updates DemandShaper when the SoC changes (only whilst parked).
@TrystanLea: This will update the SoC during the charge. Will that cause any issues?
So, this is in my homeassistant configuration.yaml
bmw_connected_drive:
i3Status:
username: !secret email
password: !secret bmw_password
region: "rest_of_world"
…and the automation…
- id: '1582088796177'
alias: Update demandshaper SoC
description: ''
trigger:
- entity_id: sensor.i3_94_charging_level_hv
platform: state
condition: []
action:
- alias: ''
data:
payload_template: '{{ states(''sensor.i3_94_charging_level_hv'') }}'
topic: emon/openevse/soc
service: mqtt.publishThanks @PaulS for sharing, that’s great!
No it only takes the SoC into account when you set the schedule at the moment.
So… question:
What will trigger the schedule to be re-calculated?
So if I park up at home in the evening, and the car sends it’s SoC to demand shaper, it won’t re-plan the schedule?
I’m living with my setup for a few days now, and I seem to be in a situation where the timer is only getting set on the EVSE if I visit the demand shaper page. My usage pattern is as follows:
@TrystanLea Is this expected behaviour?
One thing I’ve noticed is that when the car gets “over charged” (i.e. 82% instead of 80) the page border goes grey and says “Settings Mismatch”. Could this be part of the problem?
Yes correct. At the moment you need to reopen the scheduler page and adjust the schedule for it to take into account the SOC. I intend to get this fixed soon so that it automatically recalculates based on the updated SOC.
Yes that’s all what I would expect.
That shouldnt be the case, the timing is in 15min chunks so I would expect some error on the final SOC, when does the page border change to gray? right at the end? or as you create the schedule?
If I have the page open once charging has finished and it’s gone over. It goes from orange to grey.
What does the “Settings Mismatch” message mean? It’s a bit opaque as an error/warning message.
Ok. At least I understand that that’s what I need to do. Will be nice to get it do it automatically though 
I see this whenever the target SOC is less than the actual SOC. You should be able to see it if you click in a segment to the left of the reported SOC.
Thanks, i will look into it.
Documentation changes
I’ve moved the Sonoff S20 smartplug documentation out of the DemandShaper github readme and into the OpenEnergyMonitor Guide here: Sonoff WiFi Smart Plug scheduling - Guide | OpenEnergyMonitor
I’ve also updated the pictures and provided more detail on the behaviour of the smartplug.
The OpenEVSE & DemandShaper setup guide is separated out to its own page here: Smart Charge your Electric Vehicle - Guide | OpenEnergyMonitor there’s also a note covering the new method of fetching SOC using an emoncms input. I’m going to expand on this in more detail on that page soon.
The Intro page to the Emoncms DemandShaper module can be found here: Emoncms Demand Shaper Module (beta) - Guide | OpenEnergyMonitor
I have been doing some data analysis since I got demand shaper module to work properly with my setup. I found dozens of occasions when only 75% or 50% of the expected two hour charge was delivered during an evening. It got me thinking.
I turns out the the Sonos S20 smartplug is only set with two timers at the point when the webpage is opened. So if the demand shaper finds three or four separate half-hourly slots from Agile Octopus forecast, only the first two slots will run that evening.
Do I have something wrong with my setup? Or is this a known limitation with the demand shaper.
Hello @kylelamb the ‘ok to interrupt’ option appears to be buggy at the moment. I need to revisit the associated code to work out why this is the case. It is resulting somehow from the interaction with the 2 timers… i.e its not setting the timers in sequence as it should.
Id recommend using it without the ok to interrupt option for now until this is sorted.