$FE does not work when delay timer is active

[glynhudson]

Sorry to post another issue, I've just noticed that $FE cannot be used to start a charge (change state from sleeping > charging) when delay timer is active.

I have a very useful use case which requires $FE to work when the delay timer is active e.g.

• User has delay timer set to charge EV during an off peak tariff overnight
• User is using with Wifi gateway with 'EcoMode' SolarPV divert setup and enabled. If the EV is connected and it's a sunny day once the solar PV starts to generate more than 6A (1.4kW @ 240V) the EVSE will start charging at 6A, if the solar PV output increases the charging speed with be increased accordingly.
• In the UK (it's not that sunny here) with small domestic solar array it's unlikely (outside of mid-summer) that the solar PV will produce enough to fully charge EV.
• The delay timer should then kick in during the off-peak overnight tariff to fully charge to EV at full rate

This all works apart from $FE does not work when delay timer is active.

[lincomatic]

The timer behavior is an endless source of headaches. I've tried on several occasions to make it behave nicely with overrides without having to turn it on/off all the time. The way that it currently behaves via the front button is currently different, unfortunately, from what's currently achievable via RAPI, simply because I couldn't think of all of the various scenarios that a RAPI client would want.

1. can't you just turn off the delay timer temporarily?
2. let's say I allow $FE to override the timer. When is the timer expected to kick back in?

[glynhudson]

I know, sorry I'm being a pain!

1. can't you just turn off the delay timer temporarily?

Yes, that's an option. However it not only effects the Eco Mode function but also the main Pause button on the web interface: https://openevse.openenergymonitor.org/. In an ideal world the Pause button would always pause an active charge. My non-tethered unit doesn't have a physical button, therefore relies entirely on the web interface.

2. let's say I allow $FE to override the timer. When is the timer expected to kick back in?

I would expect the delay timer to stop any active charging session at the delay timer end time.

[lincomatic]

No, you're not being a pain at all! When I finally sat down and fixed the timer override via the pushbutton, I knew that I was not solving any of the issues via RAPI. I was just waiting for it to bite me in the ass and have someone complain to me about it ;)

This issue is closely related to your other issue,
#89

One thought I had was to give you a RAPI command to simulate the short button press, but the behavior won't be to your liking. When the short button press wakes up the EVSE, the timer is disabled until either the EV finishes charging, or is disconnected, upon which the timer re-enables itself. It's easy to see what's going on via the LCD, because the timer icon disappears while it's disabled. I feel this is the best behavior for the front button, since turning the timer on/off is such a big chore. A typical user wants to just leave the timer on all the time, and be able to override it when they need a charge. So time/charge limit also override the timer, and run their course before re-enabling it.

We need to come up with a way that both behaviors (current front panel behavior->charge past timer end and your intended behavior->stop at timer end) are supported, without causing strange behavior when say, a user does something via WiFi and then goes to the front panel and presses the button, or vice/versa.

[glynhudson]

One thought I had was to give you a RAPI command to simulate the short button press, but the behavior won't be to your liking. When the short button press wakes up the EVSE, the timer is disabled until either the EV finishes charging, or is disconnected, upon which the timer re-enables itself. It's easy to see what's going on via the LCD, because the timer icon disappears while it's disabled. I feel this is the best behavior for the front button, since turning the timer on/off is such a big chore. A typical user wants to just leave the timer on all the time, and be able to override it when they need a charge. So time/charge limit also override the timer, and run their course before re-enabling it.

I could live with with that. Even though I still think end time should always mean end time I can understand you thinking. In practice I doubt it would be an issue / many users would notice that the EV charged to full when overridden using the start / stop button on the interface. If this is the easiest solution then let's just go with this.

We need to come up with a way that both behaviour (current front panel behaviour->charge past timer end and your intended behaviour->stop at timer end) are supported, without causing strange behaviour when say, a user does something via WiFi and then goes to the front panel and presses the button, or vice/versa

Making the operation of the physical button and the web-interface button consistent is defiantly a good idea. Consistency is actually probably the most important thing

[lincomatic]

Sorry it's taken me so long to get back to this. I've been too busy with work and personal issues.

I've found some caveats to implementing a short press simulation button. It would work OK when the EVSE is in normal operation, there are cases when the behavior is not a simple toggle of sleep/wake:

1. when the EVSE is currently in a menu (due to the user entering menu state from the front panel) - rare, but could happen
2. EVSE is in a fault state

(1) I guess we could just ignore, since it's very unlikely
(2) we could make it a no-op. When the front button is short pressed during a fault state, the EVSE goes into the setup menu

Please have a look at BtnHandler::ChkBtn() to see the current code.

Proposed command/response:
$S0 - simulate front panel button short press
response:
$OK evsestate
evsestate(hex): EVSE_STATE_xxx

Would the response contain sufficient information, or do you need something else for the web UI?

[glynhudson]

Hi, no worries. Totally understand.

What would happen if the proposed $S0 was issued when the EVSE was in a menu or in a fault state? Would the EVSE just fail to start? Or would the simulated button press also advance the menu! I feel we can probably ignore these cases since they are unlikely as long as the effect will not pose a danger e.g. trying to start a charge while in fault state.

Would you recomend I change the web interface to use S0 to start a charge as opposed to $FE?

I think the proposed state response would be perfect. The web-interface just needs to know the current state.

[lincomatic]

Hi,
Sorry for the extended delay in implementing this.
I have implemented the simulated button press, but it's $F5, rather than $S0 (actually, $S0 already does something else).

Note that I found some unexpected behavior. Here is the RAPI command/response sequence when the EVSE is idle and ready:

$F5 <- send
$ST fe^00 -> async notification
$OK fe^03 -> RAPI response
$F5 <- send
$OK 00^00 -> RAPI response
$ST 01^02 -> async notification

Do think it's still useful to return the EVSE state, or should we save some code space and just return $OK?

The code is in the test branch. Once you've verified that it works as you need, I'll merge it to development

c7f65af

[glynhudson]

Do think it's still useful to return the EVSE state, or should we save some code space and just return $OK?

Thanks. The wifi gateway already check status using the standard status command, therefore I don't think it's needed to return status here and could confuse things. I vote saving code space and just returned ok

[lincomatic]

Argh, sorry, it's $F1, not $F5.
I changed the code so that it only returns $OK, rather than $OK evsestate

F1 - simulate front panel button short press
N.B.: it is possible that an asynchronous state change will be sent by the
EVSE prior to sending the response to $F1

latest code is in test branch

[glynhudson]

Nice, $F1 seems to work great for what I need to for e.g start charge button on the web UI will override timer and start the charge.

As you mentioned, an expected side effect of this is that when in a menu the $F1 command will literally simulate a button press! This is not a big issue since it's expected that the user will be remote from the unit and not be using the LCD menu while using the web UI. I will modify the wifi-gateway to try and use $F1 instead of $FE, falling back to $FE if NK is returned if user is running older open_evse FW.

I think you can close this issue once these new changes have been merged 👍

Thanks a lot.

[lincomatic]

pushed fix to dev branch in D5.0.0