serkri / SmartEVSE-3

Smart Electric Vehicle Charging Station (EVSE)
MIT License
68 stars 28 forks source link

Non persistant mode after reboot/reconect #169

Closed stevoh6 closed 1 year ago

stevoh6 commented 1 year ago

Hi, Im using new 1.7.0 version and Im facing problem, when evse is reboot or rejoin wifi with mode persistance.

When I set mode to OFF, then reboot ( or wifi is reconected), mode is changed to NORMAL. this is unwanted scenario, because today at night my home solar battery discharge to 0 because or this.

The original behaviour was, that mode is persistant during reboots. Can you please bring it back? Its bug? or feature?

stevoh6 commented 1 year ago

I found the issue, automations in example was wrong. Tested, this should help https://github.com/serkri/SmartEVSE-3/compare/master...stevoh6:SmartEVSE-3:patch-1

dingo35 commented 1 year ago

I think your patch only solves part of the problem; I only use MQTT to read out my sensors, and I lost persistence of mode after reboot too.... I'm working on a patch, retaining mode is simple, but somehow retaining the access_bit (OFF vs. ON) has never worked and is not simple to store.....

dingo35 commented 1 year ago

persistence.zip Could you test this; especially with your MQTT config, interesting to see if it interferes.

Thx!

arpiecodes commented 1 year ago

I actually found this peculiar as well, and implemented a default "access on boot" feature in my previous fork. Because writing the mode into nvflash didn't seem to happen for the API, I also didn't do it for MQTT (could have been wrong here though).

In stevoh6's case it's probably cause of using the message persistence feature of MQTT that makes it send out the set command again after reboot. But that's not fixing the actual issue as dingo35 already said.

It should be pretty easy to add persistence for the mode selection in. For the access bit, it is also relatively easy. But it is probably better to wait until there's a solution for the Modem issues with setAccess before implementing something that will set it on-boot, as it will make things a lot easier.

PS: I actually think the capitalisation of Mode OFF is a bug/typo and this is the correct fix; https://github.com/serkri/SmartEVSE-3/pull/173/files#diff-0de9b51ecf098edb2d8fc5c98a3e8dddc0706e494c22ac089e185896ca2a0b25R2444.

dingo35 commented 1 year ago

@arpiecodes you actually (accidentally, I presume) removed the code that was saving the mode in NVP; I reinstated it so now it is saved whenever mode / access bit is changed, either by MQTT, API or webserver.

Should be fixed by fce52a2f44e36a449b88ffdaa8d66099f9abac3e.

On the capitalisation of Mode OFF, I don't get your point; why is that a bug, does it matter other than optics, is something depending on its spelling? EDIT NEVER MIND lets handle this in the appropriate thread of Hmmbob's PR!

stevoh6 commented 1 year ago

OI can test it after weekend. Yes, my problem was caused by MQTT, that smartevse read set mode parameter (( which wasnt properly updated), my fix fixed that part in HA automation example, now its forking for me just fine :-)