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.

[KipK]

The gui can now be installed as Progressive Web App. There's nothing but a template waiting for proper dev, but it displays the app in fullscreen.

So i've changed the use of /override for /claims only. the demo in dev mode works quiet good for now with real API. Status top bar displays the correct data, Manual tab is almost ok but TimeLimit/ChargeLimit, Shaper and Divert switches are still not linked to api.

I'm also planning some conditional display in case there's external override/claims on the game. Still wonder of the best way to handle this in term oof UX.

@jeremypoulter As I don't poll /status anymore, I see a lack of data updated from the websocket. I'll submit a PR on OpenEVSE Wifi firmware to add some missing events to the create_rapi_json() and push Amp more frequently when charging . ( and perhaps some other values)

[jeremypoulter]

On the override, this is what the UI should be using for the On/Off and it should reflect the changes made by external entities, eg the button on the charger. For example you get home, press the button to start a charge, the later you go to the app to put it back to auto. It is entirely intended to be a global that all end user interactions with the device use. I think that is maybe part of the confusion when choosing between /override or /claim. If it is an end user choice use override, if it is an automated system use claim. By definition the UI is user operations so should use /override.

I thought the amps were already updated faster during charge, maybe that is just on the LCD... but may need to be a bit careful about the regularly updated vars, probably only want to event them via the websocket and/or give the new faster updating one(s) a different name so not to mess up anyone using them for data logging where they depend on a car being updated at regular intervals. Thinking about it, I prefer the latter...

[KipK]

@jeremypoulter event_send() only send over websocket & mqtt, we should be good. I've submitted the pr https://github.com/OpenEVSE/ESP32_WiFi_V4.x/pull/448

On the override, this is what the UI should be using for the On/Off and it should reflect the changes made by external entities, eg the button on the charger. For example you get home, press the button to start a charge, the later you go to the app to put it back to auto. It is entirely intended to be a global that all end user interactions with the device use. I think that is maybe part of the confusion when choosing between /override or /claim. If it is an end user choice use override, if it is an automated system use claim. By definition the UI is user operations so should use /override.

Yeah I got that. UI will check if there's other claims with higher priority and display the button according to it. It will then cancel this override/claim if asked ( as UI is manual too )

But to use auto_release correctly I need to use claim then.

use case:

Setting from Auto to ON to let it Activated whatever the timers for few days while renting my house.

I'll then needs an auto_release = false on this override or it will get back to Auto after the first session. So I use Claims for the UI as it's not an option with override. I can then set State & Max_current & charge_limit/Time_limit properties using the same claim.

Claim is automatically removed from the UI code if all properties are removed, dunno if it's already the case on evse side.

[jeremypoulter]

I think that is a very specific usecase. I don't think you can really do anything like that in the UI as it is not always loaded, all of that sort of logic needs to be in the backend really, I see why you wanted the auto release off. Maybe you can add a config option to control the override auto release (defaults to true)?

[fhteagle]

As an end user who is blissfully ignorant of the back end structures of OpenEVSE for now, I think simplicity and clarity on the UI is important. The UI present up to 4.1.4 was not very intuitive to understand for me. Having Mode: On really mean on, just on, and not, "on until...", etc is a very good way to achieve that simplicity.

I can think of a ton of use cases for "cancel the automation for awhile", including, but not limited to:

• First install testing
• Troubleshooting with a new / different car
• Guest staying at the house for a short time who needs to change regardless of time of use pricing, solar, etc
• Charging up before a potential disaster / evacuation
• Etc

In these cases, the possibility of accidentally leaving a claim, override, limit, whatever set is too high. Being able to force it on at the highest amount of amps the circuit can deliver / station is configured for is the only thing I care about.

It would be nice, in those cases, to not destroy, delete, remove a carefully built scheduler, divert, and / or time limit setup. So leaving those "saved" and shown in the Mode: Auto tab of the UI (but very clearly disabled or greyed out), and ready to be manually re-armed easily by re-selecting Mode: Auto makes the most sense to me.

Finally, having the ability to configure and see a different recurring time limit vs a one time limit that gets cancelled after it expires would be both useful and much more easy to understand. Use case for this would be a public place that wants to discourage people from monopolizing or abusing the chargers, so sets a recurring 2 hour time limit, but might need to one time allow a longer charge session by specific request of a paying guest.

I hope my explanation is clear, if not, please feel free to ask me to restate or any questions that might help to clarify.

Thanks

[KipK]

I think the feature of Time Limit / Charge Limit is handled by Openvse module not Wifi Firmware. On what I saw it auto delete at each charge session. There would need a change on the way they are handled ( better on Wifi module side ) , and change the behavior. I'm agree we should be able to keep those settings after charge session.