Glyn …
This is the same charger (purchased a couple of months ago) referred to in this thread.
That screenshot showing v4.1 was from John Cabra – not me.
I’ll let you know what the LCD is showing and the result of a 10sec button press.
Many thx for the quick response.
@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).
@glyn.hudson
Glyn …
Would appreciate yr advice/comments on the following openEVSE (3 ph) behaviour …
Wireless firmware v4.0.1
Demand Shaper set OFF
No timers set
Divert mode was set to 2 (ECO) by a script that ran at 7:30am
EV was connected overnight
Per the screenshot …
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.
Thanks
@glyn.hudson
Glyn …
The Data viewer screenshot and 10 sec csv download are informative …
graph(45).csv (5.8 KB)
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.
Yr comments would be most welcome
Thx
I think on my solar setup (no battery) the trigger for eco mode charge is about 1600W spare power.
John
@glyn.hudson
I can now confirm that the sign error in my Input Processing for grid_power was the cause of the problem I reported earlier.
Yesterday ECO-mode charging was triggered twice: at -1714W and at -2147W. This confirms the observation by @JJC that the trigger point is about -1600W.
The experience raises questions about the timing of when ECO-mode can happen and the effect of having a battery. I’ll raise a separate forum topic on this.
Regards
Good to hear your up and running
The minimum charge current supported by all EV onboard chargers is 6A, this will be 1440W for single phase (6A240V) and 4320W for three-phase (6A3*240V). The minimum power level is a hardware limitation of EV onboard chargers, it’s not possible to charge any lower than 6A. EcoMode will activate when solar PV or grid export surplus is at least 6A .
I would recommend updating to V4.1.0
