I’ve added a brief guide on setting up the demand shaper for EV charging to the OpenEnergyMonitor guide https://guide.openenergymonitor.org/integrations/demandshaper/ Im still working on the system diagram and will extend with a section discussing in more detail the ‘beta’ state of this development and intention for further development, e.g support for different vehicle API’s.
I’ve fixed a number of issues with the demandshaper module, now available on new image via standard update process, or via git if installed manually.
- Fixed missing carbon intensity forecast and associated undefined error.
- Fixed missing ‘Saved’ message on OpenEVSE schedule update
- Fixed OpenEVSE tariff info to now show p/mile
- Fixed an issue with timezone handling when schedules are near midnight, hour rollover/under issue.
- Fixed an issue relating to Setting mismatch error where start of schedule is in the past.
- Add device wizard hides automatically when first device appears
- UDP broadcast related setting was missing in emoncms core, now added in, results in much faster setup for smart plugs and wifi relay module.
Version is now v1.1.0: https://github.com/emoncms/demandshaper
I’ve been playing with Demandshaper - the problem I have is getting the present state of charge from the car and setting it in Demandshaper. is the ‘20%’ value hard coded? If so could you make it setable via the UI??
My Leaf (40kWh version) apparently doesn’t yet work with the OVMS so can’t get Demandshaper to talk to the car. However - there seems to be an app called ‘MyLeaf’ on Android that which someone has clearly reverse engineered to get the SoC and other things from the Nissan. wondering how easy it would be to grab the SoC from the Demandshaper script?! I searched github and came across https://github.com/glynhudson/leaf-python-mqtt ( hi @glyn.hudson !) so perhaps this could be added to Demandshaper to determine how long to charge for. I’m not really a coder but happy to play and test, given suitable instructions. I ran into issues installing it on my emon pi (IOError: [Errno 28] No space left on device) so haven’t played yet. Will try on a spare Linux box in a bit…
Hello @gr0mit great to hear your testing the module. Yes wider integration with different API’s would be great. I need to think through how to make this more modular and document a process for developing/attaching a suitable script here.
In the meantime here are a couple of pointers to where things are happening in the code:
The default 20% value is set here:
This is the line where the front-end interface pulls in the OVMS info
This is the API end point on the server side for the OVMS info request:
To add another service we would need to add an API end point in the demandshaper_controller and then make a way of selecting between services in the front end…
I think it might be possible to make the start SOC selectable in the short term and perhaps provide an enter kWh to charger option, or / and an option to specify say x number of miles to add in the charge?
I think it might be possible to make the start SOC selectable in the short term and perhaps provide an >enter kWh to charger option, or / and an option to specify say x number of miles to add in the charge?i
I think that would be a great plan in the short term. I’m not really a programmer (other than copy/paste of other folks code!) but to be able to set the SoC (which I can get from the Leaf app) and either kWh or miles/km to add to the car, it would be cool.
I suppose ideally this could be the first API endpoint from which the Demandshaper reads the values. Then other API endpoints can be added more easily. Just a thought.
I have couple of loosely related questions. I just download the new emoncms image to a 32GB card and it working great - thank you.
The Octopus Agile ‘Current Price’ seems to be reading the maximum price rather than the price at the current time ? (Sorry I didn’t realise the posts here Octopus Agile emoncms app)
Can the ‘Demand Shaper’ output to any MQTT device ?, if not is a .bin available of the emonESP - that makes life a lot easier to re-flash from Tasmota rather than remove it from where it is and take it apart to re-flash it !
@TrystanLea - Great work on the demand shaper. This is going to be what we need. I am keen to help and contribute.
I have started looking at the code because I am suffering from death by “settings mismatch” with a Sonos S20 Smart Plug. I think this problem started when you implemented the timer-based scheduling command rather than the simple on/off state (but I agree that this is definitely the way to go). I have been testing to try to identify the circumstances when “settings mismatch” is raised:
If the demand shaper is set with “ok to interrupt” and it then calculates that more than four periods are required, on the same calendar day, you always get a “settings mismatch” error with a Sonos S20 smartplug.
If the demand shaper calculates a period which has already started , you always get a “settings mismatch” error with a Sonos S20 smartplug.
If the demand shaper calculates a period which will start in less than 30 minutes time , you always get a “settings mismatch” error with a Sonos S20 smartplug.
I have had no issues flashing Sonos S20 smartplugs and connecting them to the Demand Shaper Module. Very easy to setup and connect. But… I am having no luck connecting a new, single relay MQTT to the demand shaper. The relay publishes to whatever topic I give it and you can see it in a feed… but I can’t get it to show in the demand shaper module.
I must be missing a step. I configured the MQTT settings (ref. screenshot), but do I need to configure anything on the demandshaper side so that there is something to subscribe to?
Those links to the code you provided looks like it’s reading the SoC from OVMSServers, putting that in emonCMS, and then the demand shaper reads that? Have I understood that correctly?
Would it be feasible to have an option to read the current SoC via an MQTT topic? That would allow it to be posted to a local server in a standard way.
Edit: Just read the rest of the thread and it looks like there’s a few of us asking similar things.
Thanks for testing @kylelamb
Have you tried the latest version of the module? I fixed quite a few of these in the last update. In particular the period that has already started one, and there where a couple resulting from timezone and midnight related issues.
Aha, sorry, you need to flash the EmonESP timer branch firmware to the relay module, same firmware as used for the smartplugs. Just change the node_type and node_description settings to be ‘wifirelay’ before compilation and upload, see this line: https://github.com/openenergymonitor/EmonESP/blob/timer/src/src.ino#L69
Yes, although ‘putting that in emonCMS’ is maybe more clearly understood as also happening within the demandshaper module. There’s a server and client component to the demandshaper module, the reading of the OVMS happens on the server component and then that’s read in to the client…
That’s not a bad idea, ideally we need to request the SoC when we need it rather than periodic polling that may be waking the car computer up each time, so we still need a way for the demandshaper module to trigger a request for the SoC…
I still have one issue with demandshaper. On my system it clearly uses previous days agile rates until sometime after 8pm in the evening. Not a big deal but I was using the demandshaper to provide times for our drier which I have to set manually.
I did notice this in the log. Is it relevant:-
LAST ENTRIES ON THE LOG FILE
2019-10-21 18:12:26.182|WARN|emoncms_mqtt.php|Not connected, retrying connection
2019-10-21 18:12:26.207|WARN|emoncms_mqtt.php|Connecting to MQTT server: Connection Accepted.: code: 0
2019-10-21 18:26:13.903|ERROR|index.php|Not Admin|admin/view
2019-10-21 18:28:03.765|ERROR|demandshaper_model.php|Saved to disk
2019-10-21 18:28:30.459|ERROR|demandshaper_model.php|Saved to disk
2019-10-21 18:28:47.642|ERROR|demandshaper_model.php|Saved to disk
2019-10-21 18:30:12.557|ERROR|demandshaper_model.php|Saved to disk
2019-10-22 06:32:28.450|ERROR|index.php|Not Authenticated|demandshaper
2019-10-23 18:25:10.683|ERROR|index.php|Not Authenticated|demandshaper
2019-10-24 06:12:26.539|ERROR|index.php|Not Authenticated|demandshaper
2019-10-24 06:15:02.319|ERROR|index.php|Not Authenticated|demandshaper
2019-10-24 20:34:35.578|ERROR|demandshaper_model.php|Saved to disk
2019-10-24 20:34:47.897|ERROR|demandshaper_model.php|Saved to disk
2019-10-24 20:34:52.043|ERROR|demandshaper_model.php|Saved to disk
2019-10-24 20:35:28.705|ERROR|demandshaper_model.php|Saved to disk
2019-10-25 06:13:20.495|ERROR|index.php|Not Authenticated|demandshaper
2019-10-25 10:58:46.886|ERROR|demandshaper_model.php|Saved to disk
2019-10-25 10:59:00.963|ERROR|demandshaper_model.php|Saved to disk
2019-10-25 11:36:27.053|ERROR|index.php|Not Authenticated|demandshaper
2019-10-29 16:49:48.699|ERROR|demandshaper_model.php|Saved to disk
2019-10-29 16:53:33.184|WARN|emoncms_mqtt.php|Not connected, retrying connection
2019-10-29 16:53:33.206|WARN|emoncms_mqtt.php|Connecting to MQTT server: Connection Accepted.: code: 0
Also you suggested demandshaper can be updated with the normal update command.
This is not true on my system. I use a git pull in the demandshaper directory to get updates AFTER an update from admin and frequently pull in an update.
Thanks @ian, yes it uses the previous day if the new agile rates are not available yet, i need to work on reducing the delay between the point at which the new rates are available and when they appear in the demandshaper.
Most of the ‘errors’ in the logs you show there should really be changed to be info or debug level messages. I wanted to see how many times the schedule was saving to disk from a write load perspective but I should change that back to a debug level log now. Nothing obvious to worry about there.
Thanks for the note regarding the update, I need to add a provision in the old image to automatically update the module.
@TrystanLea. Thanks, I took some time to regression test these three cases. Pleased to share that they are resolved. No more settings mismatch.
I also had to manual git pull the updates from the directory
Great to hear @kylelamb
Certainly in my case, requesting the SoC is just a case of a REST API call to the BMW servers which cache the latest reported value the car has sent. The car only updates the servers at the end of trips, or about every 5 minutes during charging. You get a charging curve like this. The steps down are at the end of journeys, and the staircase is the charging.
There’s no way of making the car do an update when it doesn’t want to.
I’ve got a some of questions/observations now that I’m up and running:
- If the EVSE is in the disabled state ($FD) then the demand shaper gives errors. A simple fix I suspect
- Is the demand shaper using the timers or the energy limiter on the EVSE, or is it just sending it sleep/enable commands? I’m trying to understand how it might interact with someone plugging in and pressing the button on the EVSE to start and things like that.
- What does “Off” mean in the UI? Similar hypotheticals to the last question.
Finally, have you thought at all about allowing power to be switched on for preconditioning on these cold mornings? I expect it’s more energy efficient to heat the car/battery from the mains rather than charge the battery and then precondition from the battery given charging losses. It could probably be on minimum current for preconditioning to limit charging at a non-minimum-price time.
Its using the timers, this line in demandshaper_run.php prepares the command to set the timer: https://github.com/emoncms/demandshaper/blob/master/demandshaper_run.php#L262
The off state sends the $FS command, here’s the line in the demandshaper_run.php process: https://github.com/emoncms/demandshaper/blob/master/demandshaper_run.php#L297
Yes this would be really good to add I agree, I haven’t managed to implement it yet, I would also like to add a feature that allows to increase preference for charging closer to end time, so that the battery does not sit at high SOC.
So, if we’re using timers then somebody switching the unit from sleeping to active with the push button will get power immediately? That’s probably a good thing. I just want to be able to explain it to the rest of the household.
The other minor thing was adding a price per kWh along side the price per mile. p/kWh is how public charging is priced, so it makes for a nice comparison. The rest of emoncms talks in p/kWh too.
Ideally yes pushing the button would override the timer, Im not 100% that depending on the timing of the button press and the next automated timer update, the timer might not then override the manual user press, it would be good to double check that, I’ve been using the timer exclusively and turning on/off via the demandshaper UI.
Good idea re showing p/kWh as well.