More issues with 4.1.7 - losing MQTT for openevse/amp

[pdhoogh]

This is on 4.1.7 the result of my charging session this morning. There seems to be another issue. MQTT loses the openevse/amp connection when the charger malfunctions in eco mode. This too is new.

It is visible how the MQTT viewer deletes the trace of openevse/amp when the charger malfunctions in eco mode. DS220PLUS/POWER1 is not managed by openevse so this one stays reliable and shows how import power jumps to 3k when openevse/available_current drops to zero. Indicating that at this point the charger switched to charging at max_current.

Later on, when available_current jumps up again, the charger resumes throttling correctly. Then the available_current drops to about 6 amps and the OpenEVSE returns to charging with max current. Really ugly and even worse than previous builds. It looks like putting in the current shaper broke a lot of things.

Let me know when there is a fix. If that fix does not work, I'm quitting waiting for a working release and will start working on my own control code using RAPI commands to set parameters on the OpenEVSE. Far from ideal, but the current situation is costing me money and will end up as hundreds of euros extra on my yearly energy bill.

[jeremypoulter]

Do you have the shaper enabled? If so does disabling the shaper resolve the issue?

[pdhoogh]

Hi Jeremy,

Thank you for the quick response!

I did not have the shaper enabled. I can try to reset to factory settings, something that seemed to work for a while, but in the end still did not solve the issue of eco mode not working properly

[pdhoogh]

Hello Jeremy,

I have done a factory reset and things have improved in the sense that - for the moment - the issue with 4.1.7 will no longer cost me money, just opportunity to charge the EV. Now it no longer seems to jump to max current but just stops charging and does not restart when enough power is available again.

The time axis is 1 hour on all graphs.

It started off doing really well, throttling as it should. This can be seen from the red trace, the power import/export, running around zero.

Then another electricity user kicks in and the EVSE stops charging as it should. But when the other user stops and power becomes available again, the EVSE just sits there. Before the factory reset yesterday it would jump to max, now it stops. Better from a perspective of electricity bill.

The EVSE requires a reset (not the Wifi) and after that it resumes charging, throttling properly.

Again it is noticeable that available_current and min_charge_end do not lose the connection to MQTT, but amp still does and the MQTT Explorer wipes its data when that happens.

This is the second time I've seen that doing a factory reset improves things after a WiFi firmware upgrade. It is annoying to have to set up everything again, but still it seems to be a "Best Practice" to do so.

[jeremypoulter]

I don't quite understand the 'loosing connection'. There is only a single MQTT connection so from a MQTT connection POV it would be all or nothing as far as the topics go, so something else must be going on....

[KipK]

4.1.7 has an important bugs disconnecting mqtt. Please update to latest dev build while waiting for a new stable release that should come shortly.

[KipK]

Also I see you have the #452 bug, it's solved now on latest builds. Want to try the new user interface also, get the UIv2 Builds ( get the files name ending by gui_v2)

[pdhoogh]

You are right of course, Jeremy, I have not been careful enough in my explanation and "losing connection" was a bit of a lazy move on my part. Indeed the "connection" with the MQTT server is not lost, since the other openevse traces happily carry on. But the amp one gets interrupted. I don't know the inner workings of MQTT explorer sufficiently to really know why it deletes the amp trace when openevse decides to send data for amp again. I strongly suspect openevse stops sending data for amp on the MQTT when it malfunctions in eco mode. That is a tell tell tale that some process hangs. That is what I really wanted to say, but was too lazy to spell it all out. Sorry for that.

[pdhoogh]

Guillaume, thanks for your suggestion. 4.1.7 was supposed to have fixed that. But introduced new bugs. It would be too cynical to say this proves OpenEVSE is mature, since the definition of mature software is that every new release introduces as many bugs as it solves. Too cynical because new functionality is being added all the time. And GUI is changed. I understand the wishes and very appropriate drivers for these changes, but if bugs like these keep coming with new releases, we risk loss of interest by the users.

So I will give v2 a go and do a factory reset again to give it max chances to work. But if I see things are still not as they should, I will start writing my own code - and my own bugs for that matter. I'm only a beginner with Python. But I am a very seasoned code writer for industrial control systems... these are "serial" programs. Python is "parallel" and I find this makes it a lot harder to make code that does not find a way to work as the programmer did not intend.

Just to make very sure: where do I find the code you want me to try?

[KipK]

https://github.com/OpenEVSE/ESP32_WiFi_V4.x/releases/tag/v2_gui

[KipK]

I insist on the new UI as it's easier to trace some bugs now.

[pdhoogh]

Thanks Guillaume.

I still have a lot of choices... my OpenEVSE is a 2021 model with WiFi. So I guess I need openevse_wifi_v1_openevse-gui-v2.bin

[KipK]

Yes it is this one

[pdhoogh]

Ah! I can see now why the new UI is easier to trace bugs: the OpenEVSE is now a dumb charger that only connects to your iphone when you select the local WiFi AP and are smart enough to then find that you can access it through 192.168.4.1. You get the possibility to change current and set timers and that's it. No eco mode selection, no WiFi config, no MQTT config, no possibility to load firmware, nothing. Indeed, no complaints about eco mode, it is simply no longer there.

HELP!

[KipK]

It's because you probably have reset the settings and are in wizard mode isn't it? Set first the wifi, max amp and co then all the normal setup will appear. Or give me your trash then I'll have good use of it.

[pdhoogh]

Hello Guillaume,

Thanks for responding so quickly.

I did not reset to Factory settings, I simply can't. I cannot set the WiFi, so there is nothing I can do from my local WiFi.

1. I have to go outside in the freezing cold, stand next to the OpenEVSE with my iphone
2. Connect the WiFi to the local OpenEVSE AP
3. Go and look in the connection properties to find the IP address of the gateway: 192.168.4.1
4. Go in Safari and type that address
5. I get a new nice looking page that just tells me that I can start / stop the charge, an overview of the former charge sessions.
6. I can swipe to another page that allows me to set timers and limits
7. There are no other pages, I cannot find any connections on the pages I can access to get to a configuration

The only thing I did is - on the previous GUI - ask to update the firmware with the file you pointed to. And the OpenEVSE went out of the air. With previous firmware upgrades the OpenEVSE always came back on the home WiFi with the same IP address and started to show its GUI. Now it disappeared and I have to do the same steps as if everything was reset to Factory Settings. But the GUI goes nowhere but a manual charge station.

[KipK]

Ok seems something has reset the settings, but it should then display the wizard. For unknown reason it's not. Point manually your browser to 192.168.4.1/#/wizard/

[KipK]

Also you still can rollback to another firmware or access the hidden config by going manually to http://192.168.4.1/#/configuration

[KipK]

May I know what phone & browser you use ? As the nav is not displaying, it means you are in wizard mode already, so I wonder why the wizard boxes doesn't appear on your side.

[pdhoogh]

Weird. I went back out in the cold, accessed 192.168.4.1/#/wizard/ and boom: the OpenEVSE connected to my home network and it is all back now. With the new GUI.

I can access it with my PC via the home network with its previous IP address. What is even more weird: I cannot see the local AP inside the house (well insulated with aluminium on the foam blocks and with windows with anti-theft foils: microwaves do not get through) but using the home wifi I can still access OpenEVSE using 192.168.4.1. I don't know if that is new, I never tried that or saw that with the previous firmwares. I have a Home WiFi access point outside, 5 metres from the OpenEVSE, a Devolo Magic 1, it is there to pick up the signal of the OpenEVSE. After some time - I did not measure or test, I saw after 15 minutes- that access to 192.168.4.1 went away.

I also found how to go to ECO now. There is a small icon representing a high voltage line, probably for "grid". Touching that adds an "AUTO" option on the switch above. On my iPhone via 192.168.4.1, Safari kept showing the grid icon. On my laptop (Opera browser) it now shows a PV panel array instead. On the iPhone/Safari via the home network it also shows properly.

On iPhone/Safari, as long as I access 192.168.4.1 on the iPhone, I only have three pages I can select. And there are only two icons in the bottom bar to access pages: the scheduler and the history. By swiping in all directions I can make it show the charge page too. But I cannot access the wizard or settings from the GUI. I have to type in the url you gave me. That kicked in everything.

On Opera/Windows I see a bottom bar with five selections. The monitoring page and the configuration page are accessible. On Safari/iPhone I can also see all pages and the full GUI when I switch to the home network and the home network IP address for the OpenEVSE.

On the charge page, I cannot change the charge rate. The slider is there, but it seems stuck at 6 amps. But: there is the EVSE page that can be selected from the settings page and that one had a current limit set on 6. I was able to move it to 16 and now the charge page slider can be moved between 6 and 16. Great! That is an improvement!

The MQTT page has new stuff. Reject self-signed certificates toggle and a pw and uid I did not provide. Also a port for "LWT/Announce Topic" with a MQTT address predefined that won't go anywhere because openevse base topic does not exist. In my system it is OpenEVSE.

On the vehicle page there is HTTP Push. Looks great. I'll try to set that up and if I get it to work I'll advertise it on the Peugeot EV fora.

For the energy monitoring page, would I be able to set it to write to Grafana on my NAS i.o. emoncms?

Finally: Congratulations for a really nice GUI v2 ! It looks great. But on iPhone/Safari, the first contact is really scary. I'll put it to operational test tomorrow and see what the EVSE does. I did not reset to Factory Settings. If OpenEVSE acts up tomorrow or later, I will reset to Factory Settings and pray I can get to the settings page :-).

[KipK]

The 192.168.4.1 should only be used used when first configuring but not after. Anyway if you reboot the evse it will shutdown the AP mode. I've never succeed to get the AP mode active after configuration. That's a feature I was looking at to simplify the wizards steps .

It's normal that the home charge current slider is locked to 6amp if your max current has not been set yet. Max value off the slider use this max current setting

If you don't know what LWT for Mqtt is, probably means you don't need it then. You can find more details on Google about what LWT ( Last Will Testament) is .

Be aware that the HTTP push for vehicle has not been deeply tested yet. As you are already using mqtt it seems better to keep it or your ev data.

[pdhoogh]

Well... this morning the OpenEVSE was off the home WiFi again and only accessible through the 4.1 address through its local AP. Also, the MQTT is not updating regularly, not on any of the MQTT parameters. I did not do a factory reset.

This FW is not an improvement in operation. I'll revert to the stable release and write my own control code.

[KipK]

If the wifi is dropping off , mqtt can't stay connected so. I'd rather looks at your wifi link quality first.

[KipK]

Also nothing has changed on the fw network stack, downgrading shouldn't change anything but cognitive bias. Something that improved a lot the signal quality was turning 90° the esp wifi module . It goes from -88db to -63db at home. Antenna polarisation is something to consider

[pdhoogh]

I agree that -79dB is not the greatest WiFi signal, but it has never been an issue with the earlier FWs. At first I did not have a Devolo AP and the signal there was between -92dB and -85dB. That was a problem, OpenEVSE had difficulties connecting. Since I have the Magic 1, the signal is -75dB to -79dB at that location and it has never been an issue any more.

The orientation of the WiFi module is already good. It is -85dB if turned 90 degrees from its current orientation.

[pdhoogh]

This is becoming a really bad experience.... I cannot get the OpenEVSE to talk to me anymore. Even not after going back to the old GUI.

During the day I let it sit there and was monitoring MQTT. The data was coming in intermittently, most of the time there is no data. Also it keeps forgetting the current setpoint and always goes to 16 Amps in "Fast" mode, the set maximum, even if it was set to a lower value earlier. I have never seen this behavior in any of the previous FW. So I decided to go back to the previous firmware. But not with the flaky home network connection, I did not dare. All the previous FW updates with the old GUI FW I did using the home network, it was never an issue. But with this flaky behavior, I did not dare use the home network for this. It was not communicating anyway.

I pulled out the home WiFi and cycled the power on the EVSE to force it to go to local AP. It did. I stood outside in the cold next to the OpenEVSE with my Windows laptop. The WiFi signal was strong. So there is nothing wrong with the WiFi module. I connected to the local AP with the default password. Then went to 192.168.4.1. The new GUI started to appear and then stopped. Opera reported "connection interrupted". Yeah, not surprising... I cycled the call of the 4.1 and the new GUI page now loaded. It appeared as it did on my smartphone: no wizard, no access to setup. Just two pages.

I dialed in the http://192.168.4.1/#/configuration and the config page appeared. I went to the firmware page and that one found that I had the old FW ready in the Downloads folder. I asked it to change the FW and the process started to run. Then OpenEVSE went out of the air. It did not come back.

Then I turned the home wifi on again. OpenEVSE did not connect to it. I reconnected to the local AP with the 4.1 address and the initial page of the old GUI appeared. The configuration of the home WiFi was still there. So I asked it to connect. OpenEVSE went out of the air and stayed out of the air. It did not reconnect to anything. The local AP was gone. Clearing browser data on the laptop or the iPhone did not work. OpenEVSE would simply not respond.

I'm not sure what the best way forward is from here. It does not look good.

[KipK]

If there's no local AP probably means it's connected to your wifi. Check on your router the connected devices if DHCP has not attributed a different IP than before. And try to power cycle the device if not . Also, please post a screen capture when there's only 3 pages(buttons) , I can't figure out how that's possible it has been deeply tested on Iphone already.

[pdhoogh]

Good morning Guillaume,

If there's no local AP probably means it's connected to your wifi. Check on your router the connected devices if DHCP has not attributed a different IP than before.

I actually did these tests yesterday already. Here is the data:

• Signal strength measured at the OpenEVSE: -79 dBm. -75dBm in front of the Devolo Magic 1 AP.
• Network test with iPhone at OpenEVSE location showing good transmission rates, no packet loss
• Typical performance for that spot, unchanged versus earlier performance. If and when OpenEVSE decides to play along it registers the same signal strength, between -75 dBm and -80dBm on the network display.

• IP address unchanged, connected to home WiFi with predefined fixed IP address
• Connection test with OpenEVSE through home network showing latency up to 250ms and packet loss around 50% and sometimes as high as 80%.
• This is significantly worse since before the recent FW updates, but I did not keep a picture to prove it. I remember pings of 50ms and packet loss occasionally going up to 20% but mostly no packet loss.

And try to power cycle the device if not . I've done that many times, but that does not do much.

Also, please post a screen capture when there's only 3 pages(buttons) , I can't figure out how that's possible it has been deeply tested on Iphone already

It is not only on iPhone. On the Windows laptop, I saw the same yesterday. As long as connected through local AP on the 4.1 address. When connected through the home wifi with the 178.50 address, all pages become visible both on the iPhone and the Windows. I did not keep a shot, but I'll give you one as soon as I get to it again.

This is how I read these results:

1. WiFi at the OpenEVSE location is as good as it has ever been
2. The OpenEVSE WiFi chip does connect to the home WiFi
3. The OpenEVSE is not responding, even not showing a page, if connected through the home network, both on the new GUI and old GUI FW.
4. The OpenEVSE does work properly in AP mode, showing only the two pages on the new GUI - which is pretty useless - but shows everything on the "latest stable release".

That means I can now only use it as a dumb charger with a fixed current rating, operating it with my iPhone at the OpenEVSE location. No MQTT, no throttling available any more.

It seems like loading the new GUI FW broke something software wise that does not recover with loading the old stable FW with the old GUI.

[KipK]

Thanks and browser console output ( from Developer tab ) . I bet it's consequencies of network issues. On what you say it looks to me to be wifi issues ( you've just rolled back the fw and it is still the same ) , weather can have a stong influence on wifi signal and embedded PCB antennas are usually really bad performers but for short range.

[pdhoogh]

I totally do not understand how you come to this conclusion based on the data presented.

So, to recap:

1. Testing the WiFi at the OpenEVSE location using my iPhone shows no deterioration of the WiFi
2. The OpenEVSE WiFi chip connects with the home network and confirms the same signal strength if it decides to play along
3. The test of the connection to the OpenEVSE through the home network shows high latency and packet loss
4. The connection in AP mode standing next to the OpenEVSE is strong and works, but even then the "connection" is lost intermittently
5. In AP mode, both in Windows and on the iPhone does not start the wizard in new GUI FW and only shows 2 pages, which is not what you are expecting, but the WiFi connection is strong.

To me, that does not at all point to my WiFi being flaky at the OpenEVSE location. To me that points out the OpenEVSE no longer responds in network connected mode. And there are still issues with the new GUI FW, possibly as a result of upgrading from an older FW.

In the inteterst of data gathering and keeping an open mind, here is what I plan to do:

1. At the OpenEVSE, using it in AP mode, I will let it do a factory reset in original old GUI FW and reconfigure everything in AP mode before connecting to the home WiFi. See what that does.
2. If that does not work, unmount the OpenEVSE from its current location and take it inside the house where WiFi is -45 dBm and see if the results improve. That should at least indicate that the OpenEVSE works with a very strong WiFi signal or not. If it works better, that test only proves OpenEVSE now needs a very strong signal, while it did not for over a year on the old GUI FW.
3. Even if the OpenEVSE works with -45dBm, it is useless to me because it can no longer be controlled when mounted on the driveway.

Another thought: I jumped from 4.1.5 to 4.1.7, never installed 4.1.6. Could that have an influence?

[pdhoogh]

The Factory Reset did not work.

Yesterday locally reverted to FW 4.1.4. This is before Current Shaper was added, that Current Shaper introduced a number of problems so I did not want to go there any more. So this is on 4.1.4.

1. Pulled out home WiFi

2. Cycled power on the OpenEVSE

3. AP comes up with pretty poor signal standing right next to the OpenEVSE with my iPhone:

4. OpenEVSE original GUI comes up OK.

5. I try changing current setpoint. That works. Confirmed on the LCD.

6. I try Factory Reset. It fails. The home WiFi settings are still there, even after leaving Safari and recalling 4.1.

7. When recalling 4.1 the message appears: "Factory Reset Failed".

8. I keep trying, the fourth time the reset is performed.

9. Enter the home wifi settings and connect to home wifi

10. OpenEVSE connects to home WiFi.

11. Accessing OpenEVSE with the iPhone or the PC leave a blank screen. Nothing.

12. Ping is 290 ms with 75% packet loss.

[KipK]

Seems networking issue was not a so wrong conclusion isn't it? This:

AP comes up with pretty poor signal standing right next to the OpenEVSE with my iPhone:

Plus your 75% packet losses , could be hardware issue with the esp32 wifi part or antenna. But something is definitely wrong on an hw level.

[pdhoogh]

Hello Guillaume,

I have tried to go back to the v2 GUI to make snapshots of the 2-page GUI in AP as you asked me to, but I can no longer change FW. The WiFi connection - in local AP mode - is lost within the timeframe needed to do the upgrade. With the PC 30 cm from the OpenEVSE. The PC says it looses the connection, then re-initiates the connection. I tried the upgrade 5 times, but it never succeeded.

I can still use the OpenEVSE in dumb local mode. As long as it is not trying to do a FW upgrade it seems to hold up. But that is not why I bought the thing. Do you think replacing the WiFi board may be an option here?

If yes, I'll purchase a new WiFi board and keep this topic closed as it may be that the WiFi board started malfunctioning and this is the reason for this unpleasant experience. It may also explain the flaky MQTT behavior on 4.7.1 old GUI before I tried the v2 GUI.

[KipK]

Probably an error on the gui that is not catched up because of those intermittent connections. I know there's still some points to improve at this level and how.

[pdhoogh]

Hello Guillaume,

I have reopened to give you a chance to reply to my last comment. Indeed it looks like an issue with the OpenEVSE's wifi board. If a new board would fix the whole issue, the timing of the one that is in it now failing is really a very improbable coincidence but nevertheless not impossible.

[KipK]

If you're not worried about wiring you can try with mostly any dev esp32 board. There's some with ufl connectors for external antennas that will improve a lot wifi range.

[pdhoogh]

I am closing this topic as I'm not sure the WiFi is reliable.

I had the Devolo swipe for neighbour networks and found there is a new nasty guy on the block, NOVA_1CC8, blowing everybody else out of the air. At the Devolo's location, it sees three channels for it that intermittently blast out a -40 dBm signal. Devolo was running on channel 6 and that was in other respects also a crowded channel.

I manually set the Devolo to use Channel 4 and the OpenEVSE is back on home Wifi without packet loss:

I'm now on FW 4.1.4. I'll consider retesting v2 gui / 4.1.7 at a later time. I spent enough on this lately and need to catch up on other stuff. The good news is OpenEVSE is back throttling the car charge.

[pdhoogh]

I found this on internet, can be bought on Amazon:

Tenda Nova Mesh WiFi System (MW6)-Up to 6000 sq. ft. Whole Home Coverage, WiFi Router and Extender Replacement, Gigabit Mesh Router for Wireless Internet, Works with Alexa, Parental Controls, 3-pack.

It seems to make sure your home is covered by blowing the whole neighborhood out of the air. It is the cheapest mesh wifi set on the market. It seems the neighbors pay the price for it...

The "coincidence" of upgrading and malfunctioning "shortly after" can also be explained by my own behavior. For three months, OpenEVSE has been powered off. Recently I started using it again and saw issues with MQTT communication. I upgraded to 4.1.7 shortly after and saw even more issues. Then went to GUI v2 and things got really bad. The Tenda NOVA was probably already there from the moment I started to re-use the OpenEVSE. The WiFi connection with my own home network has been compromised all the time.

[pdhoogh]

I tried to upgrade to v 4.1.8 "latest" with a stable WiFi. The first attempt failed, the second worked. I noticed this is still GUI v1, so I guess v2 GUI is still not official?

Then I saw complaints about 4.1.8 and Guillaume indicated v2 GUI was doing better. So I tried to move the FW to the latest v2 GUI. That worked, but the upgrade progress bar was not showing while it was on v1 GUI FW 4.1.8.

When on GUI v2, the issues I ad the first time did not repeat. All the config, including the home wifi connection, were ported to the v2 GUI right away and it showed up with all pages available, no wizard required. GREAT!!

However... the FW version shown now is 4.1.7. So I guess v2 is not on v 4.1.8 yet?

One thing that also seemed to get lost in the transfer to GUI v2 is timezone. I had to set that back to Brussels. Than it worked OK.

No PV power now, dark outside, so I tried "Fast" charging with manual setpoint. That worked. I returned to ECO, charging stopped as it should. The "Setpoint" is set to 14 Amps, though. It is not charging, but the setpoint is set to the max mode 2 charging current I set in the config page. Don't know if that is "as intended".

[KipK]

You can see in monitoring / command tab which service is setting your pilot to 14A

[pdhoogh]

Sunday evening, Guillaume… I’ll remember not to post anything over the weekend… have a great Sunday evening! And of course thanks again for the quick answer!! I did not expect an answer before Monday noon, so you exceeded my expectation by a huge margin :-).

——————————— Philippe D’Hooghe Meidoornlaan 10 9820 Merelbeke +32 485 655 669

zondag 19 februari 2023 om 20:44 +0100 van @. @.>:

You can see in monitoring / command tab which service is setting your pilot to 14A — Reply to this email directly, view it on GitHub , or unsubscribe . You are receiving this because you modified the open/close state. Message ID: <OpenEVSE/ESP32_WiFi_V4 . x/issues/541/1436075140 @ github . com>

[pdhoogh]

Hello Guillaume,

If I have questions or possible issues with v2 GUI, what is the best way to post these? Is there a separate issues list for GUI v2?

Is there a user guide for v2 gui? I can’t figure out how to get scheduling / timers to work. V1 GUI is easier for me to understand J.

From: Guillaume S @.*** Sent: zondag 19 februari 2023 20:45 To: OpenEVSE/ESP32_WiFi_V4.x Cc: pdhoogh; State change Subject: Re: [OpenEVSE/ESP32_WiFi_V4.x] More issues with 4.1.7 - losing MQTT for openevse/amp (Issue #541)

You can see in monitoring / command tab which service is setting your pilot to 14A

— Reply to this email directly, view it on GitHub https://github.com/OpenEVSE/ESP32_WiFi_V4.x/issues/541#issuecomment-1436075140 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AZFKZFVIZFZXQKRMDUHUTWLWYJZZ5ANCNFSM6AAAAAAUT7ID3U . You are receiving this because you modified the open/close state. https://github.com/notifications/beacon/AZFKZFXFIZN6VM7TTT3XG4DWYJZZ5A5CNFSM6AAAAAAUT7ID3WWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTSVTDCII.gif Message ID: @.***>

http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient

Virus-free. http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient www.avg.com

[KipK]

you can post issues here : https://github.com/KipK/openevse-gui-v2/issues

There's no doc on UI v2 yet. The scheduler api allows multiple timers to be set, each with one state value. For simple use you create one for all days with an active state at desired time, and another one for all days with a disable state at wanted time. * Be aware that there's a bug in OpenEVSE fw crashing the fw with only one timer set. You have few seconds to create the second one or try many times until it successfully POST the second timer during this bootloop ( there's 30 sec I think ) ( I couldn't catch it without proper hardware, I let @jeremypoulter solve this one )

414

UI v2 won't be released until this bug has been solved first anyway.