Great to hear @stuart
Looks like mine is also updating every minute in interruptible mode as well, I missed that, it shouldnt do that ideally, the updates to the device should be minimized to reduce potential EEPROM wear (thinking specifically of the OpenEVSE) … I will look into it again
Thanks @TrystanLea, I’m trying to avoid waking the car up via the API so less chatter the better.
It still feels that the logic/code is a bit over the top, wouldn’t it be easier to have the main demand shaper controller just asking the end devices to switch on and off, rather than forcing them to use their own timers?
Just to add, if the schedule starts on the same day/evening for instance 10.30pm, you don’t get the update every minute, it only seems to be timers which start tomorrow morning which do this.
Hi @stuart I’ve got a date for my smart meter install - yay 
- but my car charger is decidedly not smart. I also had the idea of controlling the Tesla charging by setting the in-car schedule. Glad to see you have already been thinking about this. Is your code online anywhere, something we can hack on together / merge upstream in the demandshaper module? How has it been working for you?
Hello, the code was working fine.
I did find the demand shaper code a bit troublesome, and wouldn’t always trigger as expected.
The code I wrote is on GitHub, GitHub - stuartpittaway/demandshaper: Appliance, Smartplug, OpenEVSE demand scheduler: Find the best time to run household loads
Amazing, thanks! Past tense - you’re not using this any more?
I stopped using octopus Agile over winter as the prices went through the roof! Using Go tariff now, so not much need for a variable time
@stuart I wonder if you could just switch between Agile and Go based on the season…? 
@TrystanLea I can see Stuart based this bridge off the OpenEVSE module but more generally I’m wondering why there is a bridge process there (and hence here). Can you comment on the architecture a bit or is there a doc I’m missing?
I know EmonHub has code to eg monitor a Tesla Powerwall and report data over MQTT - would it be more / less appropriate to do some of this stuff here? Is that always read-only or can EmonCMS apps respond/interact via the hub? Is “local” vs “cloud” a consideration?
Eventually I want both the car’s charge timers, the Powerwall and various others tied up to the demand shaper and would appreciate a good “direction to hack in” and ideally get some bits submitted upstream.
With the new firmware update for the Powerwall, I’d expect that to stop working.
For me it would be better if the demand shaper module/service simply sent an off and off trigger at the correct time, without this you have to write your own schedule timer in each service.
Perhaps it could just send a trigger via Mqtt
I’ve got a fix for this in the works, will run a couple of schedules over the next few days and confirm that its working.
I think we need a mode within the demandshaper to make this possible.
Looking at your code @stuart Im trying to understand why you needed to create a new device type in the demandshaper, would it not have been possible to just have your service mimic an openevse and use the existing openevse device? It looks like you have mostly done that, but duplicated a lot of code that might not be needed?
Great, sounds good @ramcq.
I keep meaning to spend some time learning about how @borpin and others are doing a lot of this in nodered and openhab, I do wonder whether that would be more suitable for many here who might want something a bit more configurable…
I’ve not played with DemandShaper at all. From my perspective there are plenty of devices out there to provide the ability to switch things on or off with defined situations. Personally, I think this module is a distraction from core functionality.
I know you have said that plenty of times @borpin 
I was more looking for some pointers for interested people to look at nodered/openhab options
I found the original code a bit confusing to be honest. There are obviously differences in the API, but the biggest difference is that the Tesla API talks back to the car, if the car is sleeping, it will wake it up and that isn’t good for battery life if done regularly.
Therefore, I was attempting to cache the last known values in MQTT and use that for the “live” values. It sort of worked, but not perfect.
Why is this real-time control preferable? If scheduling is idempotent, the agile rates only “change” daily, and the only other relevant variables (eg total charge needed) are by definition unlikely to change if the car is plugged in to charge.
I guess I’m still unclear why this MQTT → API separate bridge process is necessary. Is this driven by the OpenEVSE architecture, the DemandShaper architecture, not wanting to call the Tesla APIs “in the middle of things”…?
It may just be my ignorance of Home Assistant but at least in the case of the car and the Powerwall, what I want to do is simply revise the schedules on a ~daily basis to reflect a policy decision about “150 miles of charge is my minimum, otherwise please charge up to 200 miles provided the price is below 8p, and never charge above 15p” or similar. I honestly have no idea how to express that in Home Assistant.
With the heat pumps and some other things, it’s more of a “price is low or high currently, switch it on or off” respectively, which is just event triggering, or “someone pushed the Remote Start button to schedule the tumble dryer for a cheap period”, which may well suit Home Assistant better. Guy (badguy99 of Octoblock fame) shared some more details about his setup at Octopus Smart Energy forum for Octopus folks.
It isn’t necessary, however having a “transport” in the middle of this is a good idea - it separates out the logic, decoupling programs from each other, and also makes it easier to move services around.
For instance, you could have the controlling schedule in the cloud/emoncms.org and the local service controlling stuff in the house, with communication over secure MQTT.
That is relatively simple to do in HA.
You could add in a weather forecast - “if sunny don’t charge as I will walk”
Or a diary link - “meeting x miles away so charge to max”
Not saying those examples are simple to integrate, but it is possible to incorporate any senor into the decision making process.
The support for HA is massive - look at the powerwall API change issues, solved in a few days by the community.
They are also quite powerful - look a TP-Link backing down on API changes that prevented integration with HA.
@borpin are there any new tutorials that you would recommend since the last time we discussed this?
The demandshaper uses MQTT to send commands to the OpenEVSE, and to read its status.
There is an internal HTTP API in the demandshaper module used by the front end when talking with the server side - and there is a bridge between HTTP and MQTT as part of that so that the front end can find the status of the device and confirm that the settings were transferred correctly (that’s probably a separate bridge to the one that you are talking about?)
I think @stuart is talking to the Tesla HTTP API and bridging that across to MQTT? perhaps that demandshaper device template could actually talk to the Tesla API directly, that’s would be fine I think.
It could, but that also then prevents me charging the vehicle via MQTT - for instance my solar panel inverter could fire an MQTT to the car.