OpenEvse + Tesla EV + PowerWall

[johnbanks]

@TrystanLea

I’ve recently installed & got working the latest WiFi module in a kit built OpenEvse (single phase) charger.

(OpenEvse firmware 3.11.3 and WiFi firmware 3.3.1)

And I’ve now tried it out with Demand Shaper with the following results …

Late evening (Fri 23 Oct) the Tesla EV was a little over 60% charged and this was reflected in the solid green bar on the Demand Shaper page. I dragged the light green bar to 70% - the desired overnight charge. And Demand Shaper showed charging would happen between 3:40am and 4:00am.

This screenshot shows what actually happened overnight …

Until 3:40am PowerWall (orange line) is slowly discharging to satisfy the house load – situation normal

At 3:40am:

• OpenEvse (blue line) starts charging as the Demand Shaper page said it would
• PowerWall (orange line) discharge markedly accelerates as it is now charging the Tesla EV. This behaviour is a real disappointment – I will create a separate Forum topic to discuss this.

At 4:00am:

• OpenEvse (blue line) stops charging as the Demand Shaper page said it would
• The Tesla App sends a text message saying that Charging was Interrupted at 4:00am

BUT at 4:02am (2 mins later):

OpenEvse (blue line) restarts charging and the accelerated PowerWall discharging continues

At 4:44am:

Tesla EV charge (red line) reaches 70% which was the light green bar limit initially set on the Demand Shaper page – but OpenEvse ignores this and does not stop charging

At about 5:10am:

PowerWall (orange line) is fully discharged to 5% (limit for battery life reasons)

Just before 6:30am:

• Tesla EV (red line) reaches 87% (set as the max for battery life reasons)
• OpenEvse (blue line) finally stops charging

The Demand Shaper page then showed the solid green bar at 87%

So a bit of a dog’s breakfast and my settings maybe the problem …

My act in creating the OpenEvse Device and associated Demand Shaper caused many settings, inputs & feeds to be automatically created – very helpful – and I’ve gone with the flow – an act of faith with little understanding on my part.

This screenshot shows the detail behind Demand Shaper …

The settings are default for the most part. But I’ve used Battery Charge level (input) based on my understanding of earlier advice from Glyn.

I can find no explanation for all these settings – is this published somewhere?

But perhaps my OpenEvse settings are also screwed up? The following screenshot shows the Services page …

Both the emoncms server and the MQTT server are running at 192.168.1.15 on an RPi without any sensors attached running emon 10.2.6 plus a couple of scripts plus OpenEvse, of course. emonhub.conf only has the MQTTinterfacer and the emonhub log is blank.

However I’ve seen this in Resources which I don’t understand …

"MQTT can used to communicate with an emonPi for Solar PV Divert (EcoMode) feature.

Note: MQTT will also send the same status updates as Emoncms HTTP (see above). MQTT and Emoncms HTTP should not be both enabled to post to the same Emoncms server e.g emonPi since this will result in duplicate inputs."

Is it wrong to have the emoncms & MQTT servers running on the same RPi?

ECO-mode is turned on – which maybe relevant?

Any guidance would be most welcome – thx

(And if I can get these problems solved then it will be time to upgrade to a 3 phase EV charger)

[ian]

I had both mqtt and http enabled. Causes problems.

TrystanLea

18 Sep

@ian

One thing I have noticed now I can see all the inputs is that I have two sets of openevse inputs.

Do you have the OpenEvse configured to send data to emoncms using both the HTTP (Energy Monitoring: Enable Emoncms) and MQTT? I see that its a bit confusing, the MQTT actually replaces that other route

I was told only enable http if it is reporting to a different emoncms instance.

[johnbanks]

@glynhudson @trystanlea

Re my post below and in anticipation of yr comments, I’ve again tried Demand Shaper in Smart mode.

But this time I set a Reserve level on PowerWall using the Mobile App. This prevented PowerWall discharging to the Tesla EV as happened previously.

It made no difference – Demand Shaper still behaved bizarrely just as before:

• The Demand Shaper controlled charge happened exactly at the stated times. The Telsa App even sent a text saying that charging had been interrupted. So all according to plan/expectation to that point
• But then a couple of mins later, EV charging resumed
• And charging continued until the EV was fully charged. The light green bar setting to less than full charge was just ignored

The bright green bar correctly indicated the EV % charge at the outset which suggests that OpenEvse and the EV were ‘in communication’.

OpenEvse control is based on Battery Charge Level (input):

• The EV battery charge % (obtained from a running script and input to emoncms) is MQTT published to emon/openevse/soc
• MQTT is shown as connected with base topic emon/openevse

This begs the question – is it the charging end time or the light green bar setting (charge to %) that is/should be in control?

ECO-mode/Solar PV Divert is enabled and was set ON:

• It has a Grid (+I/-E) topic of emon/power/export
• Grid flow is monitored by a Hildebrand GlowStick with a running script inputting data to emoncms. Export is MQTT published to emon/power/export
• During the night period – there was no Export as shown by emoncms

How can I monitor MQTT ‘message traffic’ to verify the correct messages are being sent and received?

Any other suggestions?

Yr comments would be most welcome

Thx

[johnbanks]

@glyn.hudson @Trystan.lea

Third time lucky …
Last night things worked as they should. The EV just charged between the 2 times as selected by Demand Shaper.

And this AM when generation was good before noon, ECO-mode must have kicked in and the EV charged as it should.

The only change I’d made was to how the Grid (+I/-E) feed was calculated for Solar Divert. Why this affected night time charging is a bit of a mystery tho’.

On a point of detail …
It’s clear that the Demand Shaper charging duration is calculated from the Light Green Bar setting using an assumed charging rate. Assumption error must explain why last night charging only reached 78% whilst the Light Green Bar was set to 80%.

Per another post …

OpenEVSE Demand Shaper Settings

@glyn.hudson @Trystan.lea From Resources/Forum it’s clear that divert mode can be controlled by MQTT: Topic: /divertmode/set Value: 1 = Normal and 2 = ECO-mode I can find no similar MQTT facility for changing the Light Green Bar in Demand Shaper which sets the charge limit for cheap rate night charging. It seems this can only be changed by opening Demand Shaper and then mouse dragging the bar to the desired limit. Is it possible to use MQTT instead? Can this enhancement be added? T…

It would be great to be able to set the Light Green Bar via an MQTT input from a script.

Thx