Emoncms Demand Shaper module

v1.2.3 of demandshaper master branch:

  • Fixed OVMS (v2 server) state of charge request
  • Multi user MQTT support (this is for hosting the demandshaper module on a remote server with multiple emoncms user accounts all controlling different devices - via MQTT access lists and authentication) … more details on this soon.

These are not yet merged to stable, to be done soon after further testing.

Hi @TrystanLea

Did you ever do anything about having the inverse option as we discussed some months ago? Turn off sonoff during high cost period. To be used with dehumidifiers and maybe refrigerator.

Ian

Not yet im afraid

@PaulS @sijones I have an initial implementation of the automatic recalculation of EVSE schedule based on updated SOC reading here https://github.com/emoncms/demandshaper/tree/recalc_soc. I will test it here over the next few days and merge in if its working ok.

1 Like

Hi Trystan

Trying to emulate switch off when Agile is high rate (16:00 - 19:00) I was setting long hours on demandshaper. I was using OK to interrupt (which I know I should not) As I was adding to run period this error popped up. I don’t know if this will help your debug of OK to interrupt

Thanks @ian I’ve fixed this one in the master branch (commit).

OVMS Bridge
For anyone interested in using the OVMS v3 server to bring the state of charge into the demandshaper via MQTT, I’ve created a small background script that subscribes to a remote MQTT broker to which the OVMS is connected, it specifically subscribes to the SOC metric and then forwards this on to the local emonPi/emonBase MQTT broker on topic openevse/soc.
See: demandshaper/ovms_bridge at master · emoncms/demandshaper · GitHub

I’ve pulled it and will test over next few days.

1 Like

Hi Trystan

I still see the same uncaught issue reported above, same line number. I think I pulled in master branch correctly but it may be something I am doing wrong.

1 Like

Hi @TrystanLea is the balancing time taken in to account in the service scheduler? haven’t looked at code yet but noticed car isn’t charged full today.

Good point, don’t think it is, I will add that in. Hope you were not inconvenienced!

I will take a look at that @ian, thanks!

No inconvenience at all, it hit 95%. Thanks for adding this,

Glad to hear, I’ve added in the balancing time factor now (commit). Still in the https://github.com/emoncms/demandshaper/tree/recalc_soc branch

Hi Trystan i have done a new virgin install on a pi4 the week end and i now note that in the demand shaper for the EV that i have lost the battery % Bar
could you tell me how i should be updating this software . to the pi 4 that is running emonpi .
is this a comand line thing i need to do ? or through the admin page . update All ?
i also noticed that to day i have demand shaper set to charge for 6 hours compleat by 7AM
that the demand shaper is starting chare times during the day when the car is not pluged in to the charger . sorry if i am jumping ahead in the devlopment of this . but i was wondering if the demand shaper takes note of when the car is conected to the evse charger and then shedules its charge time .from that point .
many thanks for the work you are doing with this . and if i can help in testing as i have two chargers using this at the moment and normaly do a full charge each night .
regards Bill

Hello @Bill_Burgess, if you downloaded the latest SD card image ( emonSD-17Oct19) you can update via the Admin UI > Updates > Full Update.

No it doesnt take this into account Im afraid. That’s a good idea. The approach is currently making the assumption that the car will be plugged in for the specified charge period.

Thankyou for testing, do you have two OpenEVSE units and corresponding entries in the demandshaper window?

While testing the automatic schedule recalculation last night, I came across an issue resulting from incorrectly reported SOC from the OVMS unit. The initial timer (set via smart feature) was set correctly and should have resulted in a 70% SOC this morning. The /var/log/emoncms/demandshaper.log entry stated:

2020-03-16 21:49:03.463 | openevse set timer 03 30 04 45

but when I checked the car this morning it was at 100%. Checking the log it seems that the charge period was extended at 2:13am:

2020-03-17 02:13:00.305 | openevse set timer 02 00 05 45

I noticed yesterday that the OVMS briefly reported a SOC of 0% so Im assuming that the same thing happened last night triggering the longer charge period.

I wonder if it would be safe to assume SOC needs to be at least 1% or above, to filter out this possibility? I will also look into why the OVMS might be reporting 0%

Here’s the graph of SOC from the OVMS, showing both 0% SOC datapoints

Hi Trystan
Yes I have two as picture

Also trying the sonoff. for me I would like to be able to set cost value which below it will turn on as I can use that to charge my battery storage system on octopus argil ie if it goes negative value or below say 1 pence kWh then switch on .

Regards. Bill

1 Like

Great, thanks @Bill_Burgess

I will consider that, thanks.

Hi Trystan,

Bizarre issue, the service scheduler is trying to set the charge during the day -

2020-03-21 08:01:00.027 | openevse schedule complete
2020-03-21 08:02:00.028 | openevse set timer 13 30 14 30
2020-03-22 08:01:00.965 | openevse schedule complete
2020-03-22 08:02:00.986 | openevse set timer 14 00 15 00
2020-03-23 08:01:00.132 | openevse schedule complete
2020-03-23 08:02:00.173 | openevse set timer 14 30 15 30

This is me going in to the openevse page to get it to reschedule. So looks like we’re missing something in the service.

2020-03-23 22:36:54.268 | openevse set timer 03 15 04 30
2020-03-23 22:37:22.081 | openevse set timer 03 00 04 30