New GUI

[jeremypoulter]

The existing GUI has served us well but it is becoming harder to maintain. We should start again from scratch, building with a modern framework.

[fhteagle]

@KipK -

I did clone your openevse-gui-v2 repo just to try some things out. It will load if I set VITE_OPENEVSEHOST to my actual OpenEVSE IP, but I am not willing to do dev against a hardware unit that is actually in use. If I set that env variable to any other value, it gets stuck on the "Loading Schedule" splash screen step. Is there already a good guide I can follow for setting up a dummy API server? I looked around for a bit for such a thing but did not stumble upon it (I blame lack of coffee yet this morning lol).

@jeremypoulter -

I looked at the docs and issues you linked. First Google doc is way above my pay grade, but I definitely liked the flow chart at the right. Second Google doc is much closer to what I am contemplating. Thinking about it a bit more, I think three separate Wiki pages at descending levels of abstraction would be useful:

• List of use cases, scenarios, stories that are supported and stable, are in work, are planned for future dev, and are out of scope for OpenEVSE project, with links to relevant issues
• Control task list, items that we should be able to accomplish via GUI, button, HTTP API, maybe a table showing what tasks can be accomplished by what kind of control, therefore can be a checklist for items to manually end-to-end test
• Automated tests info, guide, how to report failures, etc.

Thoughts?

I am not sure I can help you achieve your automated testing goal, beyond my skill set at the moment. But the first two lists I can help edit for awhile if that makes sense and would be useful to you all.

[KipK]

@fhteagle , I'm testing on my live unit too. Anyway that's just a gui there's no risk of messing up. It's compatible with concurrent commands coming from original gui. You can also replace the files in /stores/ bu the one in /stores-simu , but it will lack of features

[jeremypoulter]

It would also be good to implement the current API in the Node JS version, that should provid a bit better backend for development

@fhteagle Yeah that would work, lets create a new ticket for that as not specifically related to the new GUI

[KipK]

So I've finished the WiFi & time settings part.

I've encountered a bug with /settime as referenced here: https://github.com/OpenEVSE/ESP32_WiFi_V4.x/issues/467 But it's already the case with current UI too.

Tell me what you think on how it's presented.

I've also reworked a bit the whole responsivity.

[KipK]

Hi guys

For those who can't test live;, here is a video of the WIP UI working live on Desktop.

https://watch.screencastify.com/v/EP73NnuERNFHosoQAR92

[KipK]

Also mobile version here: https://photos.app.goo.gl/obkFe4wxKtFSMcNUA

[fhteagle]

Tracking some issues here with actual development, code, useability, clarity here as well:

https://github.com/KipK/openevse-gui-v2/issues

[KipK]

Hey

so I've made lot of improvment on UI2, but it needs my "testing" branch for wifi module until the pull requests are merged. Here is a testing build for openevsewifi_v1 if needed:

firmware.zip

Forget about the demo page, there's too many change to make it works on the github page. Just set .env file and 'npm install & npm run dev' to test the UI on http://localhost:5173

It uses a lot the /claims/target endpoint, and will display on the status bar the current controlling service

• if it's scheduler:

• if manual mode :

• if Divert is controlling state:

It doesn't show yet the Divert data, still wondering where & how to display this

Another thing, we're back to /override endpoint instead of /claim . I have started to work on a DataManager component, to centralise all the fetch request. I got some problem with concurrent requests crashing the wifi firmware so now every action is queued in the Datamanager queue and will be executed one at a time.

[jeremypoulter]

Great to see all the work and comms on your repo. Interesting that you see issues with multiple requests, not sure we have seen that before.

[KipK]

Great to see all the work and comms on your repo. Interesting that you see issues with multiple requests, not sure we have seen that before.

This is difficult to spot as it reboot fast most of the time and you don't notice it. Just spotted it with some HTTP time out , and saw the UI triggered 2 GET and 1 POST few ticks interval. Spacing them solved it, then I've decided to code this async queue engine ( works really good btw, I'll use it for other projects now :) )

[KipK]

btw, I've changed something that makes the whole Auto thing more clear for end user. Scheduler use same Robot icon than other services in the top tag, and Auto button just display this icon too., with tooltip displaying "Let OpenEVSE decide" ( or whatever )

Now, we know that Auto is not for scheduler only but any service that can control EVSE state Simple & quiet clear

[TommySharpNZ]

This all looks exciting and I'd be keen to be some kind of beta tester if that would help?

[KipK]

the new User Interface is mostly ready now and is ready for testing there: https://github.com/KipK/openevse-gui-v2/releases/tag/1.0.0-rc2

Before final integration in the firmware, there's some issues that needs to be solved first on the current firmware

1 - #414 : as scheduler crash the firmware if there's only one timer, UI can't be released before this is solved. 2 - #467 : /settime endpoint is wrong and can confuse users. 3 - #450 , #452 #481 #388 : Major security issue, OpenEVSE is always starting full amps when switching from disabled to active whatever the claim is. ( This is unrelated to new UI but it's a major issuse that need to be solved asaap ). Apparently this is a bug in OpenEVSE firmware not ESP32, but we could mitigate it on Wifi firmware side. 4 - #502 : OTA: modify Moongoose library to follow 302 HTTP redirects for OTA over github release

@jeremypoulter can we priorize those issues and timeframe them ?

[kallisti5]

@KipK any chance of dark modes via css? I was playing around with them for the current UI.

However, if there is a real / viable new UI in progress it feels like wasted effort.

Reading for anyone not familiar with dark mode sites: https://css-tricks.com/dark-modes-with-css/

[KipK]

It should be possible to use darkmode I use bulma css frameworj that should handle it. there's a bit of work on the css part