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
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.
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.
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.
@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?
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.
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.
@glyn.hudson Glyn …
My son checked the LCD this am - it was not illuminated.
He then checked the supply cabinet for the charger and noticed the RCD had tripped - having failed to notice that when powering off/on yesterday.
All is now working fine.
Apologies for the panic - an elementary mistake and a lesson learned.
Thx for the tip about the 10 sec button press.
Regards
PS - My son’s place is 40 miles away and I monitor the system remotely (using remote.it).
The EV started charging at approx. 8:20am. But it was not an ECO charge (as was intended) but a NORMAL charge – 3+ hours until the EV was fully charged – causing approx 30 kWh of Import.
It may be a coincidence but the charge started at the time the PowerWall battery became discharged (5% is the set minimum).
Can you explain this behaviour and how can we prevent it in future? The intent was for an ECO mode charge.
Firstly, there is an inconsistency between them. The green & purple lines (right axis) openevse ev_current & power do not agree with the downloaded csv. There is no current/power graphed between 8:13 & 8:16 but it is shown in the csv. And the csv shows blank values thereafter whereas the graph shows there to be values. Can you pls explain this inconsistency? (power is just current x 3 x 240).
Secondly, it is now clear that my Input Processing to derive grid_power to MQTT is in error – I’ve got the sign wrong. And this probably explains why charging continued in ECO mode once it had started.
But why did charging even start? A close look at the csv reveals …
Between 8:19:10 and 8:19:40, PowerWall batteries stopped discharging having reached their permitted min charge level. Thereafter the PowerWall on each phase did their import/export phase balancing act causing a few net watts charging.
Then at 8:19:50 GlowStick started to show Import of 1.9kW probably the house load. At that time my erroneous grid_power to MQTT was showing 2.1kW Export. Would that be enough to trigger an ECO mode charge? Or is it a 3 phase problem with the 2.1kW Export being interpreted as just one phase and so 6.3kW Export in total?
70 secs later at 8:21:00, Import had increased to 13.7kW and so clearly EV charging was then happening.
I really don’t understand how ECO mode works – the polling and trigger. And not liking mysteries, I’m almost hoping that the problem is just down to my erroneous grid_power to MQTT calculation.
