OpenEnergyMonitor Community

Demandshaper v2 + Controlling Tesla vehicle charging

Tags: #<Tag:0x00007fc0aca6fe68>

Probably a question for @TrystanLea to help with!

I’m currently looking at how to integrate Demandshaper to control charging of my Tesla car.

I’ve delved into the code of OpenEVSE and it seems to make sense.

What I’ve done so far is…

  1. Write a standalone Python program to interface Tesla API to MQTT
  2. Added a new “Tesla Vehicle” device into the device API to create inputs and feeds
  3. Clone some of the OpenEVSE pages to communicate with the MQTT

Point 3 is where I’m a little confused, I can see the OpenEVSE stuff communicates with MQTT so you need to keep polling the backend for status updates.

Can the DemandShaper just using the emoncms input API as its source of data instead of relying on MQTT ?

I will still need to use MQTT to publish the requests to the Tesla API, but it would make more sense for the inputs to drive the web page/interface. I can also use the cached “last known” input values.


I could also do with some background information on how the automatic device configuration stuff works - any documentation/sample code for it?

Hello @stuart, sorry for the delay!

Are you referring to this script? and the status in terms of on/off timer settings etc?

or perhaps the get-state mechanism? that uses the MQTTRequest script

In Python you can use a callback on MQTT that gets triggered when a new message is published to the topic you are subscribed to - no need to poll the Broker - is that what you meant?


Apologies if I’ve misunderstood the situation. But I’m also trying to set up a Tesla EV to use OpenEvse with the objective – ECO mode charging during the day and Demand Shaper night time charging but only up to a set limit.
I’ve built a script (shareable if of any interest) which inputs the key Tesla EV data. And openevse is the only device that I’ve set up. Here’s a screen shot of my Inputs to emon …

I’m hoping that, from a charging aspect, OpenEvse can control the Tesla EV rather than the Tesla EV control OpenEvse. But I’m still trying to understand the detail and the many parameters involved with Demand Shaper.

Will it be necessary for me to also set up the Tesla EV as an additional Device?

Hi @johnbanks

I don’t have OPENEVSE, just a “dumb” charger. I’m attempting to use the Tesla API and demandshaper to switch charging on and off via the API during the night using Agile Octopus tariff. Unfortunately the API cannot control the charging current (although that is meant to be coming soon)

I can also get lots of useful info from the car to log into OpenEnergyMonitor (OEM).

At the moment I’ve built an interface between the Tesla API and MQTT. I can currently pull information into O.E.M using MQTT inputs and also start and stop the charging using the demandshaper on/off functions.


Ah! that explains things - two different situations.

Out of interest - when yr Tesla EV is fully charged, what % charge to you get via the API?
My experience is around 83% with a range of approx 240 miles.
I guess Tesla is protecting the the battery?

IIRC Tesla have some research that says only charging a Lithium battery to 80% is the best way to preserve it’s life. I do exactly that for my phone and after 2 years the capacity is pretty much the same as it was when new.

I’ve seen that number - plus discharge to not below 30% - too. Here, I think:

1 Like

@borpin @Robert.Wall

With less 20% at top end and less 30% at the bottom end that leaves 50%.

If the object is to ‘store AC’ until a later time then there’s also a 10% round trip efficiency loss.

So in summary - a 100kWh battery would provide just 40kWh of ‘delayed AC’.

Clearly people orders of magnitude smarter than me are pushing hard on those boundaries - investors in the battery farms we are beginning to hear about and battery maunufacturers have huge skin the game.
It all depends on how much capacity deterioration occurs and over what time, if the conservative 20%/30% rules are not applied.

As a data point - the Tesla PowerWall installation that I monitor discharges to 5%.

Batteries and their applications are really fascinating.

I first read that some years ago, and I think the bottom “limit” then was 20%. But like everything else in engineering, those numbers are a balancing act between usable capacity and overall life. I haven’t re-read the whole thing, but I seem to remember that it was at pains to recognise that there would be circumstances where operation between those values was infeasible. But the salient point is still valid: if it’s possible to operate between 20/30% and 80%, then the battery will remain healthier for longer.

In general terms, that website is a useful and largely independent source of unbiased information, because I understand it’s an arm of a company the makes battery test gear.

And the search is on to find a replacement for cobalt used in Lithium-ion batteries, because there’s concern that global supplies will run out too quickly at the present rate of consumption.