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.

[KipK]

That said, I've just tried to use Time Limit and Charge Limit over claim but it doesn't work. Just saw in the API doc it's not implemented yet, @jeremypoulter is it true ? Any timeframe for this feature ?

[jeremypoulter]

Yeah, the limits are still on the EVSE module, it is the last 'smart' feature on there. I am intending to do them as part of #225 and hopefully soon to close off v4.1

[davethetallguy]

Suggestion / question related to solar divert and timer working together: Can "Eco Divert" simply be part of the max current selection? I.E. you can specify a value, or let Solar Divert specify for you, subject to (here's the important part) any other timer rules?

My situation is that I want to exclude all charging 4-9 PM, all the time. Most of the time when I reactivate I want eco-divert, but occasionally I want an overnight charge for a full battery before sunrise.

In the current firmware, if I set a "start" time of 9PM, EVSE starts charging at 9PM regardless of the eco-divert switch status. If I want to truly charge based on solar alone, I have to delete the timer.

However if I then need to charge the car after a long rainy weekend (like today) I have to remember to change to normal mode, AND put a timer back in, or I charge right on through prime time.

I'm imagining a selection button or slider for each activation timer that selects "system default / arbitrary limit / solar divert"

Many thanks for an awesome system, in any case. I like the new mock-ups.

[KipK]

@jeremypoulter Discovered that setup a claim using client ID EvseClient_OpenEVSE_Manual (65537) is considered as an override (can be cancelled by the Old UI) , and wait for it ... I can this way set the auto-release to false :) The only thing is manual_override parameter is not set to 1 then.

[fhteagle]

So I thought about this a bunch during a long drive yesterday. I came up with a few new ideas, a few modifications to previous ideas, etc. Again, my goal is make it very very obvious to the end user what the OpenEVSE is "thinking" about why it is or is not delivering, and what and when will it change to delivering next, etc. Allow simplicity for those who want it, complexity for those who want that, clarity for all, and flexibility to add more criteria/conditions to lists as the firmware gets new features (IEEE 2030.5?)

What about, instead of just ON, AUTO, and OFF, we had four modes instead: ON, TEMPORARY, AUTO, OFF ?

ON: means on, no smarts, no automation, no auto-release claims, no additional limits, etc. Just on at the configured hardware limit until the user pushes a different mode, that's it.

TEMP: means set a manual limit, until some event. Be able to add multiple "end temporary conditions", and whichever happens first wins, and disarms the remainder of the temporary until conditions. So, something like :

Charge at <16> amps until ... - ... Car is disconnected, or ... - ... Energy delivered is <4kWh>, or ...
- ... Session length is <3 hours elapsed> , or ... - ... Time is <4pm>, or ... - ... Car reaches <70% SOC / 80% SOC / done charging >, or ... - ... Grid price < more than / less than > < $0.12 / kWh >, or ... + (Add another end condition)

... then change mode to: <ON / AUTO / OFF>

dropdown would be below all the added + until .... lines, to tell the unit what to do after temporary is over. Rationale: this cleanly separates "one time" configuration from the AUTO (i.e. recurring) configuration below, easy to visualize we are doing something odd because of guests, or weird use pattern for us, or impending disaster, or whatever.

AUTO: Recurring limits configuration is set up in here all the time. Move schedule tab here. Show the schedule as a limit of 0 amps starting at a certain time period instead of "standby", "disabled", "sleeping" or "override". One limit controller per line instead of two columns. Show what the limit controller (Current Shaper, Eco, Divert, MQTT, OCPP, HTTP API, etc) would limit to if it were enabled right now on each line. Have recurring session length and energy delivered limits in this section.

OFF: as previously agreed ;^)

Change the word "Manual" to say "Mode"? A manual setting of auto seems like a contradiction to me

Also, what about moving "Logs" to be the last item in the Configuration menu instead of a tab?

[jeremypoulter]

@KipK I am not opposed to changing how the override module works if there is consensus that this is how the device should work, shouldn't be doing work arounds in the UI. We just need to come up with how we are going to present both override use cases to the user and make sure they interoperate with the button on the EVSE, including possible future expansions, eg setting a boost timer, charging at full rate for an hour to override the eco mode. The front panel operations very much apply to the session, eg you plug in the car, the override, and as not all units have a button the same logic should be available in the UI one way or another.

I am thinking what @KipK @fhteagle is similar to what you would have on a thermostat where you switch from off/schedule/on so I think the on/auto/off is the correct way to go. I am not sure about @fhteagle idea of adding the temp state as well, I am not sure it would work as well in practice.

My proposal would be to have the on/auto/off set a global mode config var (because this would also need to persist over a reboot) then the schedule/eco/Ohm modes would only be turned on when in auto and their respective enable options are enabled. Importantly, safety/security features, current shaper/RFID, should not be affected by this setting.

Then the manual override is implemented separately to this, so still have a button to start/stop the charge independent to the mode, same with the limits, so you can just do any adhoc charging independent of the mode, and that would be cleared when the session ends.

Also with the latest firmware the UI should be able to display what module has actually enabled/disabled the charge using the /claims/target endpoint. I do need to write that up in the docs as it is not the most obvious structure you get back... but displaying what has actively 'won' control of the EVSE may also help with user understanding.

How does that sound? I think that would cover most of the use cases.

Also this is a great discussion, thanks to everyone for our input so far, and especially @KipK for your work so far it is great to see.

[fhteagle]

@jeremypoulter , good that you brought up the buttons again from other issues here. I do not have the button installed on my unit, so I have not worked with it at all. Is the button capable of detecting and relaying separate short press, double press, long press events? If so, that is a way to at least be able to select ON / AUTO / OFF mapping to those three events, but I do not know or particularly care which event is mapped to which mode. Configuring all the items inside AUTO via button is a whole other animal, not sure what the expectation of capability is there. Perhaps two short presses separated by at least 2 seconds could arm TEMP ( i.e. ON until car disconnected).

I am not married to the TEMP section idea. I presented that concept primarily as a different way of organizing the GUI and keeping things clear to a basic user really. I am, however, very convinced that ON should be ON, not "on until". I was mostly reacting to @KipK 's mockup still showing ON + auto-release in the same area, so the TEMP was just a way to try to separate those visually and functionally for the user; i.e. compromise between my ON = on! concept and @KipK 's prototype UI.

Agreed with selected mode persisting over reboot, after loss of power, etc. Agreed also that AUTO should never show to the user as, nor actually ever be able to, violate configured safety limits, especially amperage. Very important point!

Your paragraph starting with "manual override" is not clear to me what you are suggesting. Please consider this as evidence that the verbiage of "override" should be banished from the UI, as it is not clear to users who are not involved in development and highly knowledgeable of the internal logic of the OpenEVSE board + Wifi modules. Your idea of adhoc charging sounds more like my TEMP concept, not the ON = on! concept.....?

"but displaying what has actively 'won' control of the EVSE may also help with user understanding." ... Agreed 100%!

And yes thanks to @jeremypoulter and @KipK and others who have contributed to this thread. It is hard to communicate these concepts clearly sometimes, but I think we have some good ideas and options and it is great to intelligently discuss the merits of the different ideas to make something very useful in the end.

[KipK]

My proposal would be to have the on/auto/off set a global mode config var (because this would also need to persist over a reboot) Then the manual override is implemented separately to this, so still have a button to start/stop the charge independent to the mode, same with the limits, so you can just do any adhoc charging independent of the mode, and that would be cleared when the session ends.

Agreed, but what would be Auto mode when there's no timers then ? Following your way, I see it like this then: add new settings in Configuration:

• mode_auto: true | false ( activate smart features ( allow whatever is not manual to control evse state: scheduler, rfid, ohm, divert )
• default_state : active | disabled ( default evse state when there's no claim/override , could be names UI side as Default Behavior: Start / Wait
• hwbutton_can_start: true | false ( either the hardware button can start a charge or not, stop is not affected )

On the main Charge page, then we only have one button with 3 states:

• No EV:
  • display: when no vehicle connected
  • click disabled
• Start:
  • display: when state is disabled ,
  • click => if override->remove override, if no override -> add override (state: active)
• Stop:
  • display: when charge is running
  • click => if override->remove override, if no override -> add override (state: disable)

Does it cover all the use case ?

The temporary max_current slider use also the same override or could be a separated claim, dunno if it brings any difference. The Limits needs to be developped on the API before integrating it on the UI.

Don't we also need to have permanent Limits on configuration side ? For Public charger that can be interesting. We could do that with claims but it doesn't survive reboots. manual_override limits should have bigger priorities

Also with the latest firmware the UI should be able to display what module has actually enabled/disabled the charge using the /claims/target endpoint. I do need to write that up in the docs as it is not the most obvious structure you get back... but displaying what has actively 'won' control of the EVSE may also help with user understanding.

Thanks for the /claims/target, I'm discovering this endpoint, quiet usefull ... somehow seems I've missed that in your code :) So we can display that easily somewhere in another tabs or tiles on desktop.

I'm trying to keep the interface responsive with mobile first, but I'd like to display things differently between mobile & desktop on a second step. Too much wasted space on desktop.

Thanks for your inputs guys

[fhteagle]

Further thought about "persistance after reboot": Is it possible to have a line item in station configuration to select which mode it defaults to after a power cycle, reboot, etc with four options:

• ON mode
• AUTO mode
• OFF mode
• Last mode in use at shutdown

If we choose to put implement the TEMP mode, I do not think it makes sense to have that as a default startup option, so I think that can be left off of the list either way.

[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