kipk/openevse-gui-v2

OpenEVSE WiFi Gateway User Interface (V2)

openevse-gui-v2's Issues

If host unreachable, UI hangs at loading

So my OpenEVSE is being really stubborn about connecting to my Wifi the past couple of days. Not reachable on the network.

I get console output in the terminal I launched nvm run dev from:

8:08:52 AM [vite] http proxy error at :
Error: connect EHOSTUNREACH LANIPHere:80
at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1187:16)

But the UI just looks like it is stuck at 1/3 loaded.

Could we add an error message about this if OpenEVSE cannot be contacted in ~30 seconds or so?

Correctly display UI version?

It's a minor issue, but I've noticed the UI version V1.0.0 is displayed. I think this should be V2.x.x when running the V2 UI to avoid any confusion with the V1 UI.

Item placement adjustment suggestions

What about moving the OpenEVSE logo into the shaded status block at the top, then moving the menu line to below the status block. This would do a few things:

1. Reduce redundant lines and space
2. Make it easier to reach the menu while operating a large phone screen with one hand, by placing the menu in the "middle" of the display, instead of the top right

Move the actual time clock to near or between the "Previous Event" and "Next Event" items?

Finally, pinning the entire status block to the top of the display (the way the OpenEVSE logo / menu icon bar is pinned now) makes sense to me. Thoughts?

Elapsed time continues to run with OpenEVSE disabled

I think I remember that the elapsed time counter would stop when the OpenEVSE was in Manual Override: On, status: disabled. But with 4.1.9 firmware, the counter seems to keep running anyway. Bug or by design?

Possibly related to OpenEVSE/openevse_esp32_firmware#594

Testing master_2e570854 to see if its still present...

Use of scheduling / timer seems to interact with charge modes

I've used the GUIv2 for a while now (4.1.8) and it works really well as long as you do not use scheduling.

Yesterday I used a combination of scheduling with an energy limit and FAST mode. The energy limit was the first hit. Later the one schedule entry to disable at a certain time kicked in.

The next morning, I was not able to use the OpenEVSE in ECO mode because it was disabled. That is fine. But...

I removed the "disable" schedule and added a "enable" schedule to (to enable 2 minutes later). The OpenEVSE enabled, but ECO mode no longer worked. Even with the GUI set on ECO mode. It just gave max current. Resetting the WiFi did not work. When I removed all the timers ECO mode worked again.

Set Amps slider would not move

At commit: 733fde8

Set Amps was at 6A since several days previous. I could not move the slider to change the amps delivered to the car. Tried in ON, AUTO, OFF modes, but in each case the slider would refuse to change.

Went back to 4.1.5 GUI and was able to change the Amps to 16 there. Reloaded new GUI and the 16 amps was then shown.

Minor wording changes request

I suggest some small changes to labels to make things more clear to inexperienced OpenEVSE users:

0. Change "Current Event" to say "Previous Event" or maybe "Activated/Disabled Since"? Similarly, "Next Event" could just say "Disables at 15:00" Done by changing to icon and "Timer!
1. "Manual" heading on home page, should be "Mode" (a manual selection of auto is nonsensical to me). Done, thank you!
2. "Auto-Release" label and its associated tooltip are not clear. What exactly does this do? Maybe "Return to Auto Mode after Unplug " or "Change Next Session to Auto Mode" ?
3. "Limit Current" to "Set Amps" or "Target Amps" ? Done, thanks
4. Consider changing "Charge Limit" to "Energy Limit"? Done, thanks
5. "Supervision" to "Safety" or "Sensors" ? (This has both "safety" information and "sensors" on this page, not sure of a word that means both of these. Maybe "Self-Checks"? "Monitoring"?)

Highlight disabled icon background on limit reached

If no schedule is set, only "charge" and "disabled" icons are shown on main charging tab, which is expected. If a limit is later set and reached, neither "charge" nor "disabled" buttons are shown as selected / active (white background for either button).

If limit is reached, "disabled" button should have filled in red background.

where is the Interface language selection menu?

I haven't been able to find in the new interface a menu where you can select the langage for the interface from en, es and fr?
This selection was possible in the previous interface.

Toggle instead of button for Fast/Eco?

What are your though on using a toggle switch to change between Fast and Eco? Currently, the user has to tap the button labelled "Fast" to enable "Eco", this seems a bit confusing to me and has caught me out a couple of times! I'm sure I'll get used to it overtime, but I think a toggle would be more intuitive? A toggle would also match the UI element above. What do you think?

12 vs 24 hour clock consistency

Much of the UI uses 24 hour clock (i.e. 7PM is 19:00), but some places use a 12 hour clock, such as the schedule input boxes.

Best of all possible worlds is to let the user pick 12 or 24 hour time format based on what they are comfortable with and use that everywhere in the UI (could this also trigger a change in format for the physical display?!?). Second best would be using consistently either the 12 or 24 hour clock everywhere in the GUI, and no option to change it. I personally prefer 24 hour clock, but I know many people, especially in North America, who are not comfortable with this.

If the answer is to allow or standardize on 12 hour clock, then the time input box on the schedule tab should be widened to show the AM/PM marker:

Thoughts?

Remove ID from schedule table

The left most column of the schedule table is schedule item ID. This does not have much meaning for the user. Important for the system, yes, but the ID is not something we can edit, or need to know, or affects function from our perspective. Table would be cleaner and clearer without this column.

Feature Request : Daily kWh counter

Any thoughts on getting a daily counter added similar to the session and total counters?

Manual line in status block showed disabled during ON

At commit c7b3078

Pressed ON mode, got red background disabled in status block line that says what is in control

Initial configuration wizard not working on Android Web UI

Just tried the initial configuration wizard (just happened to be install on a new device) and it did not move through the screen. This is with the PR to embed in the firmware.

Status block sometimes stops updating

I discovered a case where the status block stops updating. I do not have a way to solidly reproduce just yet, but I will keep trying. Might be just an in progress dev bug. Opening this just to remind myself to test more later.

Screenshot showing status bar has not updated in over 4 minutes:

No way in UI to prevent "Auto-Release"?

Is there any way with GUI v2 to turn off / prevent / ban Auto-Release? I crawled through the whole UI and could not find it anywhere. I would like to be able to permanently turn off auto-release, in a way that will survive power cuts, firmware updates, etc.

Settings submenu popup in icon bar

Testing the UI on mobile in Vivaldi and Firefox Focus at commit d1bc542 :

When I short tap the gear icon, it changes from half-strength to full white, but nothing happens. So the main charge bolt icon and the gear icon are both white, but I am still on the bolt icon tab. Longer press the gear does bring up the submenu, but that also brings up the "Open in new tab?" dialog in both browsers.

Options for improvement:

a. Integrate all the blocks that are in the various submenu items into one longer scrolling page for "Settings", thereby removing this submenu entirely (this is my preference)
b. Make the menu popup on first short tap of the gear icon, and do not make it highlight white until one of the submenu items are tapped
c. If option b. is going to make the page too long, then if schedule block goes onto the bolt tab, there is room for a separate icon for "basic settings" and one for "advanced settings" next to each other.

Thoughts?

Needs some feedback for first release candidate

EDIT: rc2 https://github.com/KipK/openevse-gui-v2/releases/tag/1.0.0-rc2

I know have a stable ( I hope ) polished version for latest UI as https://github.com/KipK/openevse-gui-v2/releases/tag/1.0-rc1

please [@fhteagle ] [@jeremypoulter] can you give a test and reports back ?

Hope you'll like it.

To do for rc2;

• 1- Wizard Setup done: 1371a23
• 2- RAPI developper page done: 2a0b501
• 3- check that passwords/keys are not sent on various forms when filled by "DUMMY_PASSWORD"
• 4- add more help pages whith doc when needed
• 5- add About section with OpenEVSE links + doc done: 5eef754
• 6- Add Max Current Soft setting ( forgot this one ^^ ) done: 01b03df
• 7- clean-up the mess
• 8 - rewrite Monitoring page with tabs done: b0773b8
• 9 - host Fonts & Icons locally 72fd120 & bf3acca

Time & Charge Limits are disabled for now until proper API integration on EVSE firmware

FR: Simultaneous Active Limits

Per RC3 issue thread, splitting this here:

It may be useful for some users to be able to set multiple limits, and pause on whichever is reached first.

Firmware update dialog release, pre-release, and dev build confusion

With 4.1.9 installed, the presence of the 4.1.7 in green and "Update" button make it look like the user should be "upgrading" to a lower software version. I have not actually clicked update to see what the actual results are.

Or is this a symptom of OpenEVSE/openevse_esp32_firmware#584 ?

Status icons suggestions

I am confused by the Charging status icon div using the class "is-warning" / yellow color? I would think this would be a normal condition, and green in color instead?

The waiting to charge icon is a green background checkered flag:

This, to me, means "completed". Change it to a blue background hourglass icon, or maybe a clock icon?

Status icon label "Sleeping" does not have much meaning to me. What is this status communicating? It seems to me to be redundant with the red paused icon?

Demand Shaper not saving MQTT Topic "is Missing"

When I click Save on the Shaper setting, I get an error " Live Power mode MQTT is missing"

this setting has been carried over from the v1

Tried changing it, Still get the same error.

Error state more prominent?

Currently, when the unit enters and error state on UI V2 it's quite subtle, and it's not possible to tell at a glance what the error is:

Compared to normal charging:

I think as a minimum the status border colour should glow red.

Personally I quite like the text on the old UI e.g Charging | Waiting | Vent error | GND fault etc. I understand if for UI aesthetics you prefer not to have text for 'Charging' or 'Waiting', however in the event of an error I would prefer the error message to be displayed clearly in text without having to mouseover or tap a logo.

MQTT topic for ECO and shaper must be different?

This is v4.7.1 on GUI v2.

I tried current shaper and it does not seem to work. I put this on a different issue, but Guillaume thought it was out of topic, so I'm making a new one for this. I'm not sure if this is a GUI v2 issue or a 4.1.7 issue. I have no problem moving this to the "general/official" section.

Guillaume thought in the current implementation the MQTT topics for ECO and Shaper must be different. Since Shaper was built separate as an add-on I understand why that is. In my opinion both should be using the same topic by default. as it is essentially the same "process value", only logical.

FW upload success message

When FW upload completers on UI V2 there does not seem to be any success message, it would be a good idea to add a message like this if FW upload is successful:

Missing library posix_tz_db ?

I did a git pull into a fresh directory this morning (09 NOV 2022, ~1300UTC), npm install, and npm dev run. However, the GUI stalls with this error displayed onscreen and in npm terminal:

44 |  import { utc2evseLocalTime } from "../../../lib/utils.js";
45 |  import { httpAPI } from '../../../lib/utils.js';
46 |  import timeZone from "../../../../library/posix_tz_db/zones.json";
   |                        ^
47 |  import { onMount } from "svelte";
48 |  import ButtonFetch from "../../ui/Button.svelte"; 

Did npm not pull in all the dependencies?

Half vs full width blocks, number of blocks per tab

So I really like the icon bar across the bottom for the menu. Good call switching to that @KipK !

On desktop, though, the fact that some blocks are half the width of the status block (i.e.) schedule, and some are full width (i.e. charge) feels inconsistent to me.

I do not think charge needs to be full width. Consider forcing it to half width and promoting the schedule block back to the default first loaded screen? Would cut down by one the number of icon bar items needed.

I would be in favor of "always" showing two half width blocks per icon bar entry. Thoughts?

todo: add some check to prevent OTA on _dev debug builds

https://community.openenergymonitor.org/t/openevse-new-user-interface-testers-translations-needed/22371/250?u=guillaume_s

With Charge ON, mask Next Event

If Charge ON is selected (aka manual_override: 1), Current Event and Next Event trigger times are ignored (as they should be). This should be communicated to the user somehow visually. Some options:

• Hiding these altogether
• Greying these out
• Strikethrough?

Typo

Typo on line 10 of

https://github.com/KipK/openevse-gui-v2/blob/master/src/lib/vars.js

Priority is misspelled.

Current vs Power mismatch in Status Block

Using Energy Meter + attempted schedule fix, and using Energy Meter only editions from Google Drive:

I found a case where disabling the OpenEVSE caused the displayed current to go to 0A as expected, but the Power block was stuck at the pre-disable value. This mismatched display continued after page refresh:

Schedule event actions have timezone conversion bug(s)

Using nightly build from 03 March. If OpenEVSE has no manual override or active claims, adding a "disable" schedule entry does not activate on save.

Steps to reproduce:

1. Start from no schedule set, no override set, no claims set
2. Add an active timer entry later than the current time of day
3. Add a disable timer entry that is later than today, but should would have fired yesterday instead if it had been set at that time.
4. Note that the resulting OpenEVSE mode is "active", during the period of the day defined by the new schedule as "should be disabled"

IIRC, in a previous revision of the GUI v2 this was working as expected.

Cleanup: Energy Meter precision

Session gives hundredths of a kWh (2 numbers right of decimal point), the rest of the items give only tenths (1 number right of decimal). It would be more legible to have all the same precision. I think tenths of a kWh is plenty of precision....

Network shows as disconnected on Wired ethernet

LCD is corrupted during FW update

I'm not sure what the correct repo is for this issue, I first noticed it after updating to UI V2. Let me know if you think I should move it to the main repo?

PXL_20230404_184324607.mp4

FR: OpenEVSE Alias on GUI

I now have two OpenEVSE's on my network. It would be helpful to have them marked or designated in the status block with some kind of friendly name or alias, so I can be sure to tell them apart.

Red colour should be reserved for error states

I've been in communication with @chris1howell and we both feel that red colour in the UI should be reserved for error states.

This is related to #13, I think the colours in the UI should match the colours on the RGB LCD where possible i.e sleeping / disabled is a purple colour. Although I'm not too fussed about the actual colour used, but I definitely think red should not be used unless there's an error.

Currently, red is used in a number of places in the UI. I propose changing all instances of red to be purple, or dark blue to match other UI elements?

LED brightness is optional

LED support is only built in to some of the builds, if the firmware support is not enabled the option should not be enabled in the GUI. If the led_brightness property is not returned from /config then LED brightness control is not supported.

Manual setting of time requires a change of date to work

Trying out your GUI against my live 7.1.3 / 4.1.5 OpenEVSE, I found something that is not too intuitive:

If you switch from NTP to manual time, then click the date/time field to pull up the popup:

1. Current time is not loaded into the popup, instead it comes up as 00:00
2. If you change only the time then click close, the date/time field is not populated.

If you do change the date, then the date/time field is populated.

(If it is not helpful for me to be testing / trying while you are actively dev'ing, let me know, this can of course wait until later)

Test report for RC3

I have pushed RC3 here :
https://github.com/KipK/openevse-gui-v2/releases/tag/1.0.0-rc3

There's a binary build for openevse_wifi_v1 module that can be installed safely.

@fhteagle, @jeremypoulter If you can give a look.

About states colors

On the old UI, I thought there was too much state color displayed around the status bar, make it confusing.
To keep it clear for users, I propose to keep only 3 color states:

• Disabled ( red )

• Active ( not charging ) ( green )

• Charging ( yellow )

When charging, box-shadow around status bar animates in fading, all bolts Icons on page will display also in Yellow.

Any thoughts on it ?
@jeremypoulter
@fhteagle

FYI: Time handling bug affects Current Event and Next Event time display

Looks like the time bug in OpenEVSE/openevse_esp32_firmware#467 and OpenEVSE/openevse_esp32_firmware#302 can affect the event display in status block. Opening this as a reminder to confirm fix after those upstream bugs are fixed on here too.

Bottom Nav Bar issue when running Chrome on Android

Just giving this an initial test and when using the new interface using Chrome (v: 109.0.5414.86) on Android (v:11) the bottom of what looks to be all pages are covered up by the bottom navigation bar. At this time I've not tested any other browsers or OS. I will do some more testing and update as I go.

Is there any further information that you need to assist in resolving this anomaly.

Time limit expiration display

Using nightly build from yesterday, after time limit expired, time remaining jumps up to 23:59:59, and charging enabled button remains green:

https://photos.app.goo.gl/KQWbXGcUuDWyoWcQ8

Add the ability to set the time from the browser

The V2 GUI is missing the ability to set the time on the host browser. This is really handy should you be in a standalone setup with no internel access. Obviously you can use the manual time but this needs you to carefully set the correct time on the UI first, in the vast majority of cases the browser will have the correct time so it would be great to just use that. Probably should also set the timezone of the browser as well (that being said NTP should also default to the time zone of the browser if it doesn't get a sensible one from the EVSE).