Emoncms Demand Shaper module

TrystanLea · 18 October 2019 13:09

I’ve added a brief guide on setting up the demand shaper for EV charging to the OpenEnergyMonitor guide Emoncms Demand Shaper Module (beta) - Guide | OpenEnergyMonitor 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.

TrystanLea · 24 October 2019 17:45

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: GitHub - emoncms/demandshaper: Appliance, Smartplug, OpenEVSE demand scheduler: Find the best time to run household loads

gr0mit · 25 October 2019 09:20

Hi Trystan
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 GitHub - glynhudson/leaf-python-mqtt: Extract data from Nissan Leaf API and post to 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…

BR
Tim

TrystanLea · 25 October 2019 16:54

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:
https://github.com/emoncms/demandshaper/blob/master/demandshaper-module/general.js#L53

This is the line where the front-end interface pulls in the OVMS info
https://github.com/emoncms/demandshaper/blob/master/demandshaper-module/general.js#L131

This is the API end point on the server side for the OVMS info request:
demandshaper/demandshaper_controller.php at master · emoncms/demandshaper · GitHub

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?

gr0mit · 25 October 2019 17:13

Hi @TrystanLea

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.

myozone · 27 October 2019 17:15

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 !

Dave.

kylelamb · 28 October 2019 12:03

@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.

kylelamb · 28 October 2019 12:14

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?

github.com

openenergymonitor/guide/blob/master/source/integrations/mqtt-relay.markdown#

---
layout: page
title: WiFi MQTT Control Relay Thermostat
description: MQTT heating control relay
date: '2014-12-18 21:49'
sidebar: true
comments: false
sharing: true
footer: true
published: true
---

Multi-purpose Wifi connected relay control board. Applications include: remote heating an A/C systems control via nodeRED, openHAB and Android Tasker etc.


<a class="btn pull-right" href="https://shop.openenergymonitor.com/wifi-mqtt-relay-thermostat">View in Shop &rarr; </a>

## Overview

*   1 x High quality 16A Relay  (tested 100 switches @ 3x rated current)

This file has been truncated. show original

PaulS · 28 October 2019 19:23

@TrystanLea @gr0mit

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.

TrystanLea · 28 October 2019 20:00

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.

TrystanLea · 28 October 2019 20:04

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

TrystanLea · 28 October 2019 20:10

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…

ian · 29 October 2019 17:12

Hi @TrystanLea

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

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.

Ian

TrystanLea · 29 October 2019 21:33

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.

kylelamb · 30 October 2019 22:47

@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

TrystanLea · 1 November 2019 17:31

Great to hear @kylelamb

PaulS · 13 November 2019 00:25

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.

TrystanLea · 13 November 2019 11:02

Thanks @PaulS

Its using the timers, this line in demandshaper_run.php prepares the command to set the timer: demandshaper/demandshaper_run.php at master · emoncms/demandshaper · GitHub

The off state sends the $FS command, here’s the line in the demandshaper_run.php process: demandshaper/demandshaper_run.php at master · emoncms/demandshaper · GitHub

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.

PaulS · 13 November 2019 11:15

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.

TrystanLea · 13 November 2019 11:19

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.