Community
OpenEnergyMonitor

OpenEnergyMonitor Community

Demandshaper v2 + Controlling Tesla vehicle charging

Tags: #<Tag:0x00007fe7b44d58e8>

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.

image

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?
https://github.com/emoncms/demandshaper/blob/master/devices/openevse.php

or perhaps the get-state mechanism? https://github.com/emoncms/demandshaper/blob/master/demandshaper-module/js/get_device_state.js that uses the MQTTRequest script https://github.com/emoncms/demandshaper/blob/master/demandshaper-module/MQTTRequest.php?

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?

@TrystanLea

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.

@stuart

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.

1 Like

I’ve seen that number - plus discharge to not below 30% - too. Here, I think: https://batteryuniversity.com/learn/article/how_to_prolong_lithium_based_batteries

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. https://eandt.theiet.org/content/articles/2020/07/cobalt-free-battery-promises-higher-energy-density-cheaper-cost

Exactly. After 2 years of careful charging management, battery life on my phone is much the same as it was when new - not many folk will say that so I’m convinced that managing your charging is an excellent way to prolong the batteries life. Yes I occasionally charge to 100% or let it drop below 15% but for the majority of the time there is no need.

I think that Apple now charge fast to 80% and then trickle above that.

I’m not an Apple user, but they could easily implement a “max charge” level, say 80 or 90% and then stop charging at that. However, that would then prolong the life of the phones, which is the opposite of what most manufacturers want - especially as the batteries are generally not end user replaceable.

Very true! I’ve thought for a while that a USB charger that the phone could talk to through the data lines combined with an app that you could set to say, charge to 80% by x time in the morning, could be a winner. Yes I can do it with HA and a WiFi switch, but doing it on the charger would then be portable.

My phone does quick charge (MotoG6) and that does make a bit of a difference, but Working at Home means I usually charge it through the day. If it is not going to last the night, I charge it with a small portable charger so it doesn’t over charge.

I understand what you are trying to achieve now @stuart nice! In your custom device class you could write the get_state method differently… perhaps loading that information from an input? Id be happy to have a look at this if you can share something in a way I can replicate, could I simulate the tesla api somehow…

1 Like

Is there sample code for this, or is it just standard emoncms api stuff?

Charged overnight to 100% (using free electric from Octopus Agile) and the API reported 100% state of battery charge - range 220 miles (Model 3 SR+)

@TrystanLea when the GUI shows “Settings Mismatch” where is it reading these values from?

It’s reading the values via an MQTT request to the device, checking the demandshaper state vs the device state.

Last night was the first real test of my Tesla DemandShaper module - and it worked!

Car began charging at 2.30 to 3am, and again 3.30am to 4am, and gain 4am to 4.46am when it reached 90% state of charge and the vehicle stopped.

This is using the “control based on charge time” feature of DemandShaper rather than anything intelligent.

The yellow line is the charge rate, and the blue is the SOC of the battery.

@TrystanLea is it correct that the DemandShaper controller/service transmits an update every minute whilst the schedule is running, like below?

2020-11-18 02:32:00.548 | TESLA: emon/teslavehicle set timer 02 32 03 00
2020-11-18 02:33:00.051 | TESLA: emon/teslavehicle set timer 02 33 03 00
2020-11-18 02:34:00.210 | TESLA: emon/teslavehicle set timer 02 34 03 00
2020-11-18 02:35:00.135 | TESLA: emon/teslavehicle set timer 02 35 03 00
2020-11-18 02:36:00.030 | TESLA: emon/teslavehicle set timer 02 36 03 00
2020-11-18 02:37:00.108 | TESLA: emon/teslavehicle set timer 02 37 03 00
2020-11-18 02:38:00.396 | TESLA: emon/teslavehicle set timer 02 38 03 00
2020-11-18 02:39:00.115 | TESLA: emon/teslavehicle set timer 02 39 03 00
2020-11-18 02:40:00.187 | TESLA: emon/teslavehicle set timer 02 40 03 00

I also got a message to charge between 3.30 and 5am, but at 3.30 this was changed to 4am, and at 4 am I was sent another message to charge to 5am - this explains the blip in the graph when the charge stopped/started, but would have been smoother if the original charge time of 3.30 to 5am.

2020-11-18 03:00:00.895 | TESLA: emon/teslavehicle set timer 02 59 03 00
2020-11-18 03:01:00.044 | TESLA: emon/teslavehicle set timer 03 29 05 00
**2020-11-18 03:30:00.108 | TESLA: emon/teslavehicle set timer 03 30 05 00**
**2020-11-18 03:31:00.403 | TESLA: emon/teslavehicle set timer 03 30 04 00**
**2020-11-18 04:01:00.335 | TESLA: emon/teslavehicle set timer 04 00 05 00**
2020-11-18 04:02:00.418 | TESLA: emon/teslavehicle set timer 04 01 05 00
2020-11-18 04:03:00.505 | TESLA: emon/teslavehicle set timer 04 02 05 00
2020-11-18 04:04:00.068 | TESLA: emon/teslavehicle set timer 04 03 05 00