LCD changes in latest build
jeremypoulter opened this issue · comments
For OpenEVSE/openevse_esp32_firmware#68 we are trying to allow the ESP32 to completely take over the LCD. Commit 899a958 will break this as the ESP is trying to display the error and may need to display different information, for example the device IP so the user can get to the UI and resolve the issue.
Also 98935cc seems unnesseserary, I have had no problems with displaying spaces from the ESP, and indeed 0x1 is needed to get access to the 'stop' char. Agreed the current behavior is arguably undefined but it does work and is a lot more conveniant than having to change spaces to 0x1. In addition how are you from a client POV supposed to test to see if you should send space or 0x1?
Here is a video demonstrating the issue: https://photos.app.goo.gl/p1x39c3yaUUCTKdG7, in addition to not allowing the ESP to update the LCD, the OpenEVSE does not update the display to show the an error message.
Hi, sorry to take so long to get back to you. I was busy w/ work, and was thinking of the best solution in the back of my head. There are 2 ways we can your wish to not allow the EVSE to override external messages when in a fault state:
- add a flag that RAPI can set to allow/disallow safety messages on the LCD to override. I must insist that at least the capability to behave the way I currently have it implemented be a default option, in case the WiFi module or whatever external controller isn't dies or isn't properly monitoring the EVSE state.
- you can add ifdefs to completely disable the LCD messages from the EVSE, and only allow RAPI to write to it. this would save a lot of code space, and eliminate a major redundancy for your purpose
as for using 0x1 to replace spaces.. .I did this because the existing method was flaky, it doesn't break your existing code, and splitting strings up into separate words to send down is inefficient. But I see how it would clash with displaying downloaded bitmaps. How about if we change the 0x1 to an agreed upon unprintable ASCII character, perhaps 0xFF or 0xEF?
@chris1howell what are your thoughts on if error messages should stay with the OpenEVSE?
I am ok with either method, although if we go for 2. I would recommed moving to Platform IO as the main build tool so we can easily have different configs with the different firmwares, or would you expect the OpenEVSE/OpenEnergyMonitor forks to change the defines?
Re spaces, the current WiFi module code just goes ahead and sends the spaces and it works just fine, can even use it to clear the whole line, see https://github.com/OpenEVSE/ESP32_WiFi_V3.x/blob/master/src/lcd.cpp#L107:L128
Very interesting topic... This may not fit in either option but here are my thoughts.
UL considers the color the primary safety indication and text is optional additional information. So maybe the OpenEVSE controller should always control backlight color by default even if an external device is writing text.
Option 1 sounds better to me so there will not be two different firmware versions for builds with/without WiFi. I am okay with stripping down the text displayed by the OpenEVSE controller to the absolute minimum to free up flash and RAM. Everything on the second line can go including all the energy counters and timer text, the button menu can be stripped to just Service Level, Current and GFCI Self Test. Error messages can be truncated as well.
lincomatic does have a good point about monitoring and failure. It may be a good idea to implement heartbeat monitoring in WiFi and have the OpenEVSE controller take back control of LCD text if the heartbeat dies.
I actually opened an issue already about the heartbeat and is really simple with the new architecture.
I have added support for the watchdog, but it is not enabled by default, maybe it could be?
Do we have a consensus on driving the LCD? If the OpenEVSE controller is going to remain in control of the LCD backlight, could we add a RAPI command and/or event to get the colour so the WebUI and any external pixels show a consistent colour?
I like the idea of the openevse controller retaining control of the LCD to be able to display error messages and basic info if the WiFi module fails.
@chris1howell / @lincomatic I think we may need to resolve this for the up-coming UL certification as the currently the LCD freezes under error conditions, although does show red. I think the heartbeat idea is a good one, can enable the heartbeat by default and only allow LCD override if receiving the heartbeat pulses.
Here is a video demonstrating the issue: https://photos.app.goo.gl/p1x39c3yaUUCTKdG7, in addition to not allowing the ESP to update the LCD, the OpenEVSE does not update the display to show the an error message.
I got rid of the code that converts 0x01/0xef to spaces in $FP. You can just send 0x11, which prints as space, anyway