As I understand it with this new release, Demand Shaper will no longer work.
If so then that would be disappointing. In my view, Solar Divert (ECO-mode) and Demand Shaper are not alternatives but are complementary OpenEVSE features that are important at different times of the year.
Are there plans to incorporate Demand Shaper features into v4.1.0 and if so, when?
Regards
Correct, as mentioned in the release notes, all V4.x releases don’t support Demand Shaper. If you want to use Demand Shaper you will need to stick to V3.x.
There are plans to integrate Demand Shaper into the OpenEVSE interface directly. It was a poor user experience having the EVSE controlled from multiple locations, it caused a lot of conflicts. I’m sorry for this change, but hopefully it should be a far better experience once demand shaper has been implemented natively.
@glyn.hudson that sounds interesting, so would that be available as an update to the EmonEVSE as well? However, I’m finding it hard to understand what the Demand Shaper brings? Is it basically integration with Octopus Agile? If that’s it, then I see no real need at the moment, as the Agile tariff doesn’t seem any cheaper than just charging on Octopus Go at a rate of 5p. I can already charge in Eco mode from my solar panels, so what does it bring?
yes, correct
Glyn …
Urgently need yr help pls re the OpenEVSE 3 phase charger purchased just a few weeks ago.
For the past 2 two days, it will not charge but remains SLEEPING per the LCD display.
We have tried a Tesla EV and a Zoe.
We have tried 2 different charging cables.
I have tried the RAPI commands to enable, reset, etc.
Doing $FR causes the message STARTING for just a sec or two then reverting to : WAITING – EV Connected
I have tried restarting the hardware (7.1.3.3P) and wifi (4.0.1) firmwares.
The local network router has been rebooted.
Screenshots are attached
What to try next?
Thx & regards
John (Banks)
Hi John,
Very sorry to hear your having issues. I notice from the screenshot the unit has charged 730kWh in the past, as it been operating correctly until now?
V4.x OpenEVSE WiFi is not compatible with Demand Shaper, could you check the Demand Shaper is set in the off position on the emonPi?
I would also recommend updating to V4.1.0 WiFi firmware, there are a lot of minor fixes in this release including the conflict with Demand Shaper.
Here is the correct FW update for your WiFi module, you will need to unzip then upload the .bin via the web UI: https://github.com/OpenEVSE/ESP32_WiFi_V4.x/releases/download/4.1.0/openevse_wifi_v1.bin.zip
Here are the release notes: Release V4.1.0 · OpenEVSE/ESP32_WiFi_V4.x · GitHub
Glyn …
Thx for the speedy response.
The charger has been working fine for a few weeks but a couple of weeks ago I had to restart the firmware to start the charging.
This time that simple fix did not work.
But I’ve now switched off Demand Shaper, reset the firmware and IT’S CHARGING J - a great relief!
Re Demand Shaper …
Solar gen in Nov to Feb incl is 25% of the summer average so just enough to keep PowerWall charged and it to satisfy a lot of the house load.
There’s not enough to also charge the EV in ECO-mode – so it’s a case of EV charge overnight at the cheap rates.
But if you’ve been following Octopus Agile rates, it’s pretty clear that 5p to 7p rates are a thing of the past – so Demand Shaper sophistication has perhaps become less valuable.
Till now in winter, I’ve been running a Python script that in early evening sends my son a text suggesting he connects the EV before going to bed.
The script also disables OpenEVSE (to stop charging happening immediately on connection).
It then re-enabled the charger shortly after midnight when Demand Shaper took over.
I will now need to modify that script so that the charger is not re-enabled until say 1am which will then trigger the start of NORMAL charging – a crude approach.
Reading the notes on the new WiFi firmware suggests the RAPI command $ST to control timing has been disabled?
Thx & regards
John (Banks)
PS – Doing all this remotely (my son lives 40 miles away) is great ‘fun’ but as you know, I’m a great fan of remote.it
Glyn …
A less critical problem still persists …
OpenEVSE creates a lot of INPUTS one of which is called soc.
I log this to a feed and MQTT publish it to emon/openevse/soc
However the INPUT soc has stopped updating.
I have no idea how the charger gets this info – from the Tesla EV when it is connected? Or some other way?
Will an update to V4.1.0 fix this problem?
Thx
John (Banks)
John,
I notice you do not have any times populated on the EVSE, if you have set cheap times, as I do Octopus go faster then you can set the timers to only charge during these times.
John
@JJC
If I’ve understood correctly, the new V4.1.0 wireless firmware will disable Timers.
Hopefully Glyn will confirm or otherwise advise.
Regards
John,
it only disables the demand shaper which would be on your emoncms the timer I an talking about is on the EVSE. Screen shots of mine, which works great 
John
@JJC
Thanks
As I prefer to use a script to control things (rather than inputting to the webpage) that means using the openEVSE RAPI command $ST.
And I’ve noticed the following in the V4.1.0 Release Notes …
Block set-timer $ST RAPI commands that will interfere with WiFi module schedule manager.
Hopefully Glyn will clarify this.
Regards
The $ST command sets the timers on the OpenEVSE module, there is now a new API to set the timers on the WiFi module, this is what the UI uses. I haven’t written up the docs yet for the web API, but there are some examples in ESP32_WiFi_V4.x/schedule.http at master · OpenEVSE/ESP32_WiFi_V4.x · GitHub
The SoC in V4.1.0 is obtained via Tela API for via an MQTT feed. This is a work in progress, in a future FW update we will add SoC limit e.g stop charging at 80% SoC
Thanks to @jeremypoulter for answering the issue regarding RAPI timers and a link to the new API. The reason for deprecating RAPI for timers is the new API will in the future allow more advanced weekly schedules to be set.
@glyn.hudson
I am intrigued by yr reference to using a Tesla EV API as for some months I’ve been running a Python script to query the EV to get INPUTS to emon - soc, battery range miles, odometer miles and state (online or asleep).
In Feb, Tesla changed their security and my script stopped working but with info from a Tesla forum, I got it running again.
Well - Tesla have done it again - introducing captcha as an extra security measure.
My script stopped working a few days ago and the Tesla forum still seems to be struggling to find a solution.
Hence my great interest in the Tesla EV API you are using that does not even require knowing username & password.
Would you pls provide details.
Then if I get my script running again or find a different approach, I’ll post details on this fourum.
Thx in advance.
PS - And a solution that just provided soc would be better than nothing.
Is broken for OpenEVSE as well, kind of. The only part that is the issue is the login, so if you save the OAuth tokens and implement the refresh then you should be good.
There are a few apps, see Add advanced Tesla credential GUI · Issue #215 · OpenEVSE/ESP32_WiFi_V4.x · GitHub, which are less susceptible to Tesla blocking them that can give you these tokens.
@jeremypoulter
Many thx for that info and the link that in turn links to an Android App called Tesla Tokens …
This App works for me – providing an Access Token which I copy to the clipboard and email to myself. So, worst case, I must do this every 30 days or so until I find a way to automate it in a Python script that runs monthly by cron.
The App also provides an SSO Refresh Token (in JSON Web Token format) – quite different to the Refresh Token I was using prior to Tesla’s security change introducing Captcha.
This may be of interest – from an email I’ve received from the App author …
Since the changes in Tesla's authentication system in February now the process to refresh the token has changed.
Now there two kinds of sessions:
- SSO session
- Owner API session
For each kind of session we have an access token and a refresh token.
In the new authentication system we have to get an SSO session and use the SSO access token to get an Owner API session.
In the Owner API session, we use the Owner API access token to call Tesla's APIs to get vehicles informations.
Since these changes, the Owner API refresh token is now useless, and cannot be used anymore to get a new Owner API access token.
The refresh process is to get a new SSO access token from the SSO refresh token, and then get a new access.
All this is documented here:
https://tesla-api.timdorr.com/api-basics/authentication#refreshing-an-access-token
That's why in my app I chose to expose only the SSO refresh token and the Owner API access token, because only these two tokens can be used by users for respectively refresh the token and call Tesla's APIs.
I wonder whether this process can be automated in a Python script?
Also it would seem that, in future, openEVSE will need inputs – user credentials or the regular Access token or the SSO Refresh token?
Regards
Thx to the help of others incl yourself, I’ve now got a Python script running as a cronjob every 30 days which updates & saves a valid Tesla Access Token to a file.
This file can be read by other scripts that need the Token.
I’ll post the detail in a separate forum topic as it is not clear this topic relates to Tesla tokens.
Regards
Glyn …
A few hours ago our new OpenEVSE (3ph) charger disappeared from the local network and emon inputs stopped updating.
It is assigned a fixed IP address in the router and an nmap network scan does not show it.
We have tried rebooting the router and powering off/on the charger but to no effect.
The charger has a button but I can find no info on how to reset the charger using that button.
Yr advice would be most welcome – thanks
PS: the wireless firmware has not been updated to v4.1
Sorry to hear you’re having issues. Is this a different charging point to the one we have been discussing in this thread? If so, I will move this issue to a new thread to avoid confusion.
What can you see on the LCD, does it display OpenEVSE WiFi at startup? If your unit has an external button, holding this down for 10s should reset the WiFi. However, this should not be required.
What firmware version are you running? Earlier in this thread you posted a screenshot to show you were running V4.1.0 OpenEVSE New v4.1.0 and Demand Shaper - #11 by JJC