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.

[KipK]

If you like the React way, Preact is a good candidate with a light footprint.
However, I kinda have some preference for Svelte.js with its compiled way of doing and top notch readability.
Booth are usable for embedded project without bloating the flash.

[KipK]

what about a new logo?

[jeremypoulter]

I like it, but that is a question for @chris1howell

[jeremypoulter]

On the framework front, I am not too fussed. I do want something that is mobile/adaptive focussed as that is the primary use case short of doing a native app (#237)

[KipK]

Seems Svelte should be the best fitted for booth world then, now Svelte-Native starts to be mature enough, should be easy to tweak a mobile app from it.
Also progressive Apps nowdays gives mostly same UX benefits as native.

For the layout, mostly all modern CSS framework now are mobile/responsive oriented, so it's a matter of taste, and depend of the requiered design. Best with minimal footprint.

[KipK]

I have started to play with Svelte.js, using Bulma as css framework.
It's a really convenient way to dev a UI for that project and gives incredible readable code . I like the light compiled vanilla JS from Svelte compiler instead of loading the full js framework at runtime ( react/vue way ) .
I'm in no way web designer so it's just a poc or starting basis.

It could be a good opportunity to start rethinking the UX. While copy/pasting old UI , I feel some actual choices could be improved:

• do we really need to use manual override to start/stop manually? We can just use claims for that now
• The Start / Stop button becoming an override Clear when activated ( perhaps we can just display start / stop and conditioning a new claim or a release depending of the context. )
• all the settings displayed on main + conf + services + car page should be organized in a Settings/Config tab with sub categories.
• Main charge page could splitted, one main for the charging status and actions and another one for logs / sensors data / other advanced stuff ? )
• I haven't got a look on how the logs are handled on openevse, do you think we have enough data internally to display some charts ?

[jeremypoulter]

That is excellent. Generally I would say let's get something basic done on a branch and we can try a few things to see how they work.

do we really need to use manual override to start/stop manually? We can just use claims for that now

Yes, this is a layer on top of the claims, is a higher priority, integrates with the front panel button, etc.

The Start / Stop button becoming an override Clear when activated ( perhaps we can just display start / stop and conditioning a new claim or a release depending of the context. )

With the way it works there are some edge cases where just start/stop become challenges. Mostly around the state changing while the override is active, eg you have a timer set and the EVSE is sleeping waiting for the start, you activate the override starting the charge and later while the override is still active the timer start time passes. Now if the override is cleared, the actual charge state will not change, so obviously if it was labelled stop that would be wrong.

This is not to say that I object to changing to a simple start/stop just that there are lots of edge cases that need considering, this is also another very good reason to keep the manual override module so this logic can be implemented on the ESP and shared with the front panel button, what probably needs doing is the state needs monitoring the the override gets automatically cleared if another module changes the state to match the manual override.

all the settings displayed on main + conf + services + car page should be organized in a Settings/Config tab with sub categories.

This sounds like a good idea

Main charge page could splitted, one main for the charging status and actions and another one for logs / sensors data / other advanced stuff ? )

Sounds good, generally the stuff that is shown by default, minus any settings as described above should give you a nice clean status page.

I haven't got a look on how the logs are handled on openevse, do you think we have enough data internally to display some charts ?

In principle the logs should be ok for charts. All the data is exposed as JSON objects so you shouldn't have to parse text or anything like that. We may want to add some APIs to better search/filter the logs.

[KipK]

@jeremypoulter I've pushed the templates here if you want to give a look to the svelte dev environment.

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

Don't bother on the logo, it's temporary, but old one will really needs some makeup. ^^

[KipK]

I have some wondering about the way the scheduler API is done.
How should it works with concurrent timers like here ?

By separating enable/disable state in 2 timers, wouldn't this bring some problems with overflown timers ?

[jeremypoulter]

It may very well do, the scheduler has not been well tested outside of the basic use case (one on, one off, repeated every day) but was designed to allow for many timers and they can repeat on different days. What you are not showing there is the days on which those timers repeat. That would for example be ok if the timer was active on Monday at 00:00 and disabled at 00:00 on Tuesday. That being said the API should probably reject any clashing times.

FYI the end goal is something like #6

[KipK]

Demo build is automatically deployed here if you want to try: https://kipk.github.io/openevse-gui-v2/

Days are displayed by rolling over the calendar icon.

[KipK]

It may very well do, the scheduler has not been well tested outside of the basic use case (one on, one off, repeated every day) but was designed to allow for many timers and they can repeat on different days. What you are not showing there is the days on which those timers repeat. That would for example be ok if the timer was active on Monday at 00:00 and disabled at 00:00 on Tuesday. That being said the API should probably reject any clashing times.

FYI the end goal is something like #6

Best way to simplify this would be to have start day/time - end day/time on the same timer instead of separate ones and prevent overflown ones either on gui or evse-wifi.

[glynhudson]

Demo build is automatically deployed here if you want to try: https://kipk.github.io/openevse-gui-v2/

Days are displayed by rolling over the calendar icon.

Looking good!

I've just tried to load the demo build, but I get an error:

[jeremypoulter]

The backend system was designed to handle more than just on/off so you could do things like set different pilot levels at different times of the day, eg so you can have a lower charge rate at peek times if you didn't want to completely disable the charge. So in that case there are not strict on/off pairs.

[glynhudson]

Wops, sorry didn't mean to close this

[KipK]

Demo build is automatically deployed here if you want to try: https://kipk.github.io/openevse-gui-v2/
Days are displayed by rolling over the calendar icon.

Looking good!

I've just tried to load the demo build, but I get an error:

Yes I was working on implementing a fake backend now it connects to evse api. Should be good now.

[jeremypoulter]

There is already a Node JS version of OpenEVSE, https://github.com/OpenEVSE/openevse_wifi_server, that can act as a simulator, although that has not need updated in a while so missing a lot of the v4 stuff. Also you should be able to generate a mock server from the API spec or use the one StopLight provide

[KipK]

Actually it's just some dummy promised functions loading local data.
This make it works for the github page demo as there's no backend possible there.

In dev env mode there's a proxy to the openevse server like for the current gui.

[jeremypoulter]

Sounds like great work and looking good too, really starting to take shape.

[fhteagle]

I just found this issue, have not been here in awhile.

https://kipk.github.io/openevse-gui-v2/ gets stuck on "Loading Status", so I cannot see your work so far.

If I were to redesign the GUI, I would like to see three options arranged as ON, AUTO, OFF, with the options under AUTO that are and are not "enabled", and what the amp limit that each auto feature would be trying to guide the output to right now (i.e. "why are the amps what they are"?). Enabled, active, etc could be communicated with icons and/or colors to help non-English speakers. Drag and drop to rearrange limiter items, remove and edit buttons or links per item. The terms "Sleeping", "override", etc are all done away with, as one would simply schedule 0 or temporary limit to 0 amps for sleeping, which would be shown in this display that way.

O OFF (no pilot / current offered to EVSE even if plugged in)
X AUTO: 9 of 12 amps in use < updates in realtime >
-- Enabled: Scheduled limit from 0800 to 1500: 16 amps ... configure link ... < enabled in faded green bg or border, updates as each schedule threshold time is reached >
-- Active: Solar divert limit: 12 amps ... configure link... < line value in dark green border or background, updates in real time >
-- Disabled: MQTT limit: 32 amps ...configure link... < disabled is no bg or border, updates in rt >
-- Enabled: OCPP limit: 48 amps ...configure link... < updates in rt >
-- Disabled: Temporary limit of 0 < dropdown > amps until < datetime picker widget >
-- Disabled: One time session limit to 2 hours < dropdown / text combo box >
-- Enabled: Recurring session limit to 10 hours < combo box >
-- Enabled: One time session limit to 20 kWh < combo box >
-- Disabled: Recurring session limit to 15 kWh < combo box >
-- Add a limiter link...
O ON (ignore the AUTO limiters, give full configuration max amps continuously)

Hope this is clear enough what my idea is suggesting. I can sketch it up more if need be.

Thanks, looking forward to seeing the next gen GUI.

[fhteagle]

https://kipk.github.io/openevse-gui-v2/ Loaded for me this morning.

First commentary is something on this demo site pushes both my laptop and phone to high CPU utilization. Using Vivaldi browser (Chrome derivative) on both. I can troubleshoot whenever we are far enough out of "demo" and into "development" on this to be worth it.

The demo has a pretty appealing look to my eye, all of the controls seem to work using a mouse, a keyboard only, and on phone touchscreen. The "current limiter" slider does not seem to highlight well / obviously when tabbing to focus it, but other than that accessibility looks reasonable to me.

Minor typo on the schedule settings modal, between "Wed" and "Fri" comes "Thu", not "Thi" .

Other than the CPU utilization, I would be perfectly happy for the UI to be built in the framework of the demo.

Let me know what you all think of my controls concept in my previous post. Thanks.

• DH

[KipK]

@fhteagle It's only a beginning of tryouts integration, depending of when you've tryied the "demo", there could have some wip changes messing it out.
I'd like to have the debug of your browser if cpu usage is still a case, I don't see anything yet that should bring this issue.
Nothing on Chrome or Edge here.

I was also thinking of 3 states button for manual, it's what I use already for my mqtt based widgets controlling the Evse and it's quiet clear.

Auto: no state override
On: manual override state to Active
Off: manual override state to Disable

I've added it to the demo.

[fhteagle]

@KipK -

Yeah no worries on the CPU usage, we can work on troubleshooting if high usage still exists after prototyping mockup phases are done.

I like the 3 buttons added to the demo.

Some ideas:

• Order the buttons ON, AUTO, OFF ? Vertically like accordion tab sections if possible...?
• If ON is pushed, grey out the items for "Time Limit" (min text box), "Energy Limit" (kWh text box), etc as those would no longer be applicable
• If OFF is pushed, grey out and disable all controls, including max amps
• Move the table from the Schedule tab to the Manual tab, but under the AUTO button accordion tab section?

[KipK]

Time Limit | Charge limit can be set when forced to ON , it will stop the charge when time limit | charge limit expire but keep the evse state Active for another session.
Time Limit | Charge limit parameters are by openevse deleted when first session expire.

[fhteagle]

Some answers to @KipK questions and ideas in his last comment:

" Agreed, but what would be Auto mode when there's no timers then ? "
I think the AUTO mode could / should always have the schedule line, even if no schedule events are configured. That way, the user always sees what is happening with the schedule, and knows to configure the schedule in the same place, every time.

From "Following your way..." to "Does it cover..." , are you describing a software web GUI emulation of the hardware button?

"Don't we also need to have permanent Limits on configuration side ?"
Yes, I think a separately configured max "safety limit" in a deeper configuration screen is a very good idea. This safety limit should NEVER be exceeded by ON, (TEMP), AUTO, OFF, claims, overrides, etc. The operation screen should not even offer, nor allow input from the user, that would even request a violation of the safety limits. Munro Live put out a video yesterday about the consequences of exceeding ratings and duty cycle on electrical equipment. I think the GUI needs to be designed so that a guest, employee, or other untrained user could not accidentally command too much current and destroy the property owner's equipment! Agreed that such safety limit configuration needs to survive reboots.

The mobile UI would have fewer columns and more vertical scrolling, but would still show all the same information and options as the desktop version of the page, right? A more compact arrangement makes sense to me, having information, options, features that are only available on desktop mode / over a certain pixel width of screen does NOT make sense to me. Plugshare's trip planner web page is set up this way, and it makes it unusable on both portrait orientation (due to script lockout) and landscape (UI elements too tall to be displayed correctly) on my mobile. Having to get a laptop to configure the OpenEVSE seems like hassle we would like to avoid to me.

[fhteagle]

Third thought: Should the max amperage safety limit configuration be locked by password, a pin, a warning, a EULA, something like that? There is an administrator username and password option in V4.1.4, which locks all GUI operations. But I am thinking of the use case of hotel employees, airbnb guests, etc, where an untrained and unprivileged user should be allowed to put the unit into ON mode at the very least, but should not be allowed to change "installation configuration", such as boot up defaults, max amperage safety limits, etc. I am not sure what the right balance of security vs hassle is for the two levels of privilege. I am just thinking out loud while the whole GUI is being re-thought out.

[KipK]

Yeah, I plan for later to let access to configuration with authentication only.

By limits I was talking about the time/charge limit as it was the context.

About the UI button I'm talking of the user experience to plan then. I kinda like it btw.
It needs a bit of mod on EVSE wifi firmware but could achieve a good user experience

The max current displayed on my demo is just a claim that don't override the overall limits of the config ( max_current_soft and shaper ) , it allows for the current charge to set a lower max_current, but not higher.

I repost the wip Demo link here:
https://kipk.github.io/openevse-gui-v2/#/

I 'd like to make configurable the data you want to display and position. Undone yet.
Better to try it with the dev environment using your real openevse API , it works pretty good for the part that has been done so far

You just have to get the repo,
Install dep using npm -IC
Set the openevse up in .env file at root
npm run dev
And connect to localhost:5173

[fhteagle]

@KipK , @jeremypoulter -

I am thinking of a list of tasks (aka unskilled user manually run unit tests), that the new GUI should be able to accomplish. Like use case scenarios that would require a realistic series of do something, until this, then that goals.

Example :

User arrives, wants 5kWh dispensed right now (to bring the battery off of dangerously low SOC), then resume previously configured solar divert.

Does such a list already exist? Would it be helpful to generate such a scenario list, task list, etc to test in progress and final GUI against? Thoughts?

[jeremypoulter]

I did start on a test list, not specifically targeted at the UI, I will see if I can dig it out.

[KipK]

@fhteagle yes having User Stories is a must

[fhteagle]

Great, happy to work on adding a few more use case, stories, and associated task tests to the list.

@jeremypoulter - did you happen to find your work in progress list?

What is the best way to collaboratively author, track, and publish the list? Issue in the queue here? Document in the source code? Wiki page?

[fhteagle]

TL;DR / crosspost from #452 , if claim priority is the basis for the programming logic as to what should be the controlling value for amperage offered on pilot signal, then the GUI should arrange the Mode: AUTO line items for each of enabled AUTO functions in descending priority order. Drag and drop might not be the best thing then, so ignore my request/idea for that above. Should claim priority be editable via GUI?

[fhteagle]

Further thought: If OpenEVSE keeps a priority value wins logic for claims, then should we use two different vocabulary terms in the GUI? Example:

• "Limit" for things that are actually a do not exceed value, like hardware safety limits
• "Target" for things that are soft adjustments, such as current shaper, eco PV divert, etc.

That makes it far more clear to me, but let me know what you all think as well.

[jeremypoulter]

Great, happy to work on adding a few more use case, stories, and associated task tests to the list.

@jeremypoulter - did you happen to find your work in progress list?

This doc is mostly focused on the EVSE module functionality, for a half finished project to build a test rig for automatically testing the EVSE module

https://docs.google.com/spreadsheets/d/1oeSjhI8OZH8ERV8obR7IN7Mzzzdc4y3Vi_dU9Ph0w5w/edit?usp=sharing

and this doc is from when I originally put together the 'design' for the EVSE manager

https://docs.google.com/document/d/1BbouYdWmD07ta1kKgMkW86JgcNjxoDtb_hFPSM180JU/edit?usp=sharing

What is the best way to collaboratively author, track, and publish the list? Issue in the queue here? Document in the source code? Wiki page?

I would like to start working towards something that can be automated, so using a tool like Cucumber would be good, but a document on the Wiki would also work

[jeremypoulter]

FYI there are also specific tickets about unit testing #287 and #360 but this is more end-to-end testing we are discussing here

[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: #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