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…
Write a standalone Python program to interface Tesla API to MQTT
Added a new “Tesla Vehicle” device into the device API to create inputs and feeds
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.
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?
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.
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.
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…
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.
