ESP miss boot from OpenEvse and dont get the state of the atmega boot notif
DylanVautrin opened this issue · comments
Hello,
I have an issue, i would like to catch the boot notification from the atmega ( the messages $AB XX Firmware) but i succed to catch it only when i reboot manually the atmega (alone).
Where can i get this state after the whole boot ? Thanks a lot for helping !
Best regards
My guess, ESP32 (which you probably use to takes longer time to boot than ATMEGA thus these messages are lost.
You can get firmware version from http://openevse-XXXX.local/#/configuration/firmware menu
Hello,
Yes, i think it is what happend,
But my question was to get this state with the ESP32, not on the GUI, maybe a RAPI command to get this boot notif ?
Best regards
You can get the version via $GV and the state via $GS see firmware/open_evse/rapi_proc.h for details
Okay thanks a lot !
I guess this can be now closed.
Okay so, i tried to use the $GS command, but it didn't succeed, are you sure you can get the post_code with this command ?
Thanks
The post code if just the status at boot, so it the status is not one of the error states it can be derived that the post code was 0
Okay, but i made some test, if i fake a stuck relay, i've got the post code 08 ( in the boot notif $AB at the boot), but when i send $GS i go state "fe" so sleeping. I try to send the command $F1, in a stuck relay behavior, then $GS, and i get state "00" so Unknown.
But, if i understand well what are you saying, i should get state 08 even in the $GS response ?
Have you checked the pilotstate(hex): EVSE_STATE_xxx ? I woud expect that to be 08 in this case
Yes, and i get 00 to most of the time, or 01 if nothing is connected:
I guess the check state is being cleared after the boot then, maybe a RAPI command is needed to get the POST code....
Ok, I see, I'm going to try to get it how I can for now, thanks for the help !
If you want to get the $AB result, you can send $FR and reset the ATmega when your ESP boots. OTOH, if you want what's returned by $AB, you can also just send $GS/$GV.
But I don't understand what's going on in your case:
- why is it booting up in state FE?
- you shouldn't be getting state 00 unless something is terribly wrong w/ the hardware. It means the firmware couldn't read the EVSE state
- if it boots in an error state, like stuck relay, it won't even go into state FE.. it just stays in the error state, and if you send $F1 in an error state, it just goes to the setup menu
I need to see what the EVSE is sending w/o the ESP32 running, to make sure it isn't interfering and sending commands to it.
What firmware are you using? If you're not running the latest from this repo, I can't comment on what's happening.
@lincomatic I couldn't find any error condition checks in or around J1772EVSEController::Sleep(). It looks like the RAPI commands coming from the WiFi controller always override the EVSE state, effectively resetting the error code.
The issue occurs if the WiFi controller is operated in "normally disabled" mode. The $FS command, used to put the Atmega into sleeping state after boot, overwrites the error state on the Atmega. Other functions like $F1 seem to reset the state variable too, but they leave it in undefined (00) state. And since the Atmega enters an infinite loop if the post checks fail, it doesn't recover the EVSE error state.
This will never mean that the Atmega does something harmful like re-entering the normal operational mode. However, the error disappears from the display and becomes invisible for the ESP, making it harder to track the hardware status in external charge management systems. Still, the post_code is not affected and works quite well.
@matth-x Thanks for the clarifications.
- What do you mean by "normally disabled mode?"
- Is WiFi firmware blindly sending $FS without reading the the state first? that is actually bad practice. the wifi firmware should check for an error state before sending its first command. Unfortunately, since the error conditions are encoded in the EVSE state, rather than separate bits, I can't separate them out w/o breaking existing firmware. I could change Sleep() to fail when the EVSE is in an error state, but I'm not sure if that's a preferable behavior, and it might cause side effects in existing firmware. $FS calls Sleep() if the EVSE is currently enabled, BTW.
Perhaps the easiest/best way to fix this is to disable $FS & $FE if POST fails. Would that be acceptable to all? Only configuration commands and reboot should really be sent during a POST error.
The "normally disabled mode" refers to the charging rules on the WiFi controller. If none of the rules explicitly allow charging, then the Atmega will be put into sleep. If no rule exists, it means the same.
To be honest, I just recently started diving into your code and the RAPI interface on the WiFi controller. I'm not sure if the WiFi controller actually uses the $FS command to forbid charging on the Atmega or if it is implemented using the Auth Lock which would not have that side effect of overriding the EVSE state. But in any case, there seems to be at least one message from the ESP to Atmega which leads to the reset of the post_code.
A first idea for a patch with less side effects could be to capture the EVSE state before processing the RAPI inputs and then to restore it afterwards. At this point:
open_evse/firmware/open_evse/J1772EvseController.cpp
Lines 1157 to 1159 in 4647293
Inside the while loop, capture and restore m_EvseState like this:
auto captureState = m_EvseState;
ProcessInputs();
m_EvseState = captureState;Unfortunately, I don't have the debugging tools set up to try this on my OpenEVSE, but maybe it's still useful to post it here.
FYI the latest ESP32 firmware should not put the ATMEGA to speed by default, but that is kind of mute as you can certainly set it up to go to sleep mode.
IMHO if the expected behavior is that you shouldn't call $FS/$FD after a post failure (or any error condition?) then that probably should be enforced (and documented). We will probably need to update the ESP code as well to handle this.
@jeremypoulter Have you ever tried the Auth lock feature? It seems like the less "intrusive" way of implementing the charge control.
@jeremypoulter Have you ever tried the Auth lock feature? It seems like the less "intrusive" way of implementing the charge control.
Yes, that's would be the preferred method, because it works independently of timers, user pressing the button, etc.