Emoncms Demand Shaper module

Thanks @sijones I assume this is with ‘ok to interrupt’ turned off? did the SOC of the car report correctly through this period?

It feels like I really need to take this implementation apart again and see if there is a more robust way to approach it…

Keen to try the Demand Shaper module. I have it downloaded to my emonpi and when I navigate to it I can see the add devices page. I have a load of existing Sonoff plugs which already ‘know’ the wifi credentials - can I add them? (I control them at the moment with the eWeLink app)

Have a look here for instructions:-

1 Like

Many thanks Ian
These are certainly clearer instructions than what I was looking at. I’d missed the need to flash the S20

Hi Trystan this morning i have found that all my demand shaper units two sonoff plugs and both ev chargers are reporting settings miss match and have lost comunication from
the demand shaper module .
i have tried reinstalling them from the inputs menu and this has brought them back into the
demand shaper but still settings miss match . i have reinstaled the sonoff skt still the same
one thing i have noticed is that the time offset that was at 0 to get correct time i have had to change to 3600 due i take it to our time change . i checked my emonpi found that was set to utc so i have changed it to euroup / london +1 thinking it may be causing an issue
but still can not get any device to now work in the demand shaper … must say i am lost now
has anything been updated that may have broken this as it was all working ? it there anything that i can read that may give more in site on to how this is working as a system
as not sure what should happen if the switch is under demand shaper control and then it is switched on via the webpage for it ? thanks for your help bill . ps now running both ev chargers on the latest wifi software Version: 3.0.4.dev emonpi Modules: Administration | App v2.1.1 | Backup v2.2.2 | EmonHub Config v2.0.5 | Dashboard v2.0.7 | DemandShaper v1.2.4 | Device v2.0.5 | EventProcesses | Feed | Graph v2.0.8 | Input | Postprocess v2.1.2 | CoreProcess | Schedule | Network Setup v1.0.0 | sync | Time | User | Visualisation | WiFi v2.0.2

Hello @Bill_Burgess. We’ve spotted an issue here with an unset property that may have occured due to browser caching of the javascript. I’ve made a couple of changes that should hopefully fix this.
Could you try running the updater again and then rebooting the pi?

You should not need to apply the timezone offset on the sonoff, just keep that at 0. The timezone set in emoncms to Europe/London is all that is needed. Mine are working fine with the hour change here.

Well that fixed the demand shaper I now note that the description box at the bottom now has the name in it and. Is not blank Well done that man .

Regarding the so off time offset

I still find that I need the 3600 sec in it to get the time to match .

Now when I looked at the version

Of software I find that it tells me vBUILD_TAG. So I am thinking that when I compiled this in the aurduino

IDE that I have missed something

I did have to add a line of code to get it to compile as the sonoff switch from what I Rcall .

Is it possible to upload a binary precompiled firmware to this

As I see it does have an upload tab

But this does not seem to do anything
Regards. Bill

1 Like

There are precompiled binaries for the sonoff here: EmonESP/compiled/sonoff at master · openenergymonitor/EmonESP · GitHub

and wifirelay: EmonESP/compiled/wifirelay at master · openenergymonitor/EmonESP · GitHub

But these need to be uploaded via UART with esptool rather than the Upload tab which as far as Im aware does not currently work. Im only familiar with the steps for esptool on linux though Im afraid…

Hi Folks
I’m trying to get Demandshaper to look at the SoC of my Leaf when deciding how long to charge for.

I’ve got SoC into a feed

and I don’t know if I’m missing anything else. The green bar stays resolutely at ‘20%’ on demandshaper, and I’m not convinced it’s working. Is there any documentation that describes how to get Demandshaper to grab this info when deciding when to charge?


Hello @gr0mit

The soc needs to be an input rather than a feed under the openevse device on the inputs page.

In the “Control based on:” option on the DemandShaper you also need to select: “Battery charge level (input)”.

Hi Trystan
Thanks for your reply. Would it not be better to read the % charge from
a feed rather than the input? This makes it more ‘generic’ and can be
tweaked for different input methods?

Best Regards

Tim Robinson
TxRx Communications Ltd
+44 1256 810630

Finally got this working! with a bit of tweaking. Somewhat bodged as I’m not a programmer. But the current SoC is now picked up by DemandShaper and used to work out how long to charge for based on SoC. I’m still getting an error message at the top of demandshaper - see attached screenshot. Also, there is some overlapping text under the green charge bar. Wonder if this could be tweaked but I’m not confident in messing with the gui aspects - very scary!

The issue was that the filcole version of pycarwings2 was built for Python3 and Glyn’s leaf-python-mqtt.py script originally was built for P2. I’ve tweaked a few things on Glyn’s script to make soc available via MQTT. I can submit the changes on GitHub if you like once I’m happy with it.

1 Like

Thanks @gr0mit, a pull request would be great! Im currently working on a fairly substantial rewrite of the demand shaper module to make it more flexible and modular so that it can better support different forecasts and devices, it would be great to see what you have done and then I can try and work out how to fit it in to the new version.

This is great Jussi, you just saved me a ton of work. I have been running efergy and telldus with self developed demand shaper on rPI.

As nordpool is the major grid operator in northern europe covering prices for 14 countries including UK, maybe @jpalo:s forkcould be integrated to the emoncms package @trystanlea ?

1 Like

It is in the progress of being integrated, but afaik Trystan is refactoring the whole signal implementation of DemandShaper to streamline adding also other new signals.

Cool - btw, how did you implement the nigh/day tariff ? At least I am finding EV charging at night utilizing spot prices and night tariff being most economic solution.

If I understand you question correctly, I’d say that day/night tariff should already now be doable using Timer functionality, as start/end hours are always the same. If by day/night tariff you mean that between 22-06ish price is lower. At least here there is no option to combine hourly spot prices and day/night tariffs.

Exactly, the network transfer tariff i am after. Its something line 2c/kwh cheaper between 22-07 so when determining the cheapest hours that should be incorporated.

1 Like

This is going to be a silly question, but how do you get to demandshaper screens? I’ve a local installed emoncms running version “low-write 10.2.3” - I’ve updated using the GUI options but I still don’t see the module!

On what base?