1
Revoking charging authorization via "stop_charging" is not working
- Fixed & released
|
M |
Mike Pieper |
When I configure the charger to require authorization for loading, it waits for authorization before it starts charging.
That means I can send API command resume_charging and nothing happens. Only when I send start_charging the charging starts. That's OK up to here.
But now, when I call "stop_charging" the charging goes on! That's not correct. According to API documentation it should stop charging and revoking authorization.
Charging can be paused with pause_charging, but also here the authorization remains.
Activity Newest / Oldest
Mike Pieper
Many thanks for the fix. I can confirm that it's working now.
Alek Slater
As a rule, its not a good idea to flip settings like Enabled / Disabled using automated tools. Now that stop_charging works again, I hope you don't need to do that anymore :)
Alek Slater
Mike, the API fix has been deployed, so should be working now.
With regard to yer question about EEPROM, I don't think normal use is any issue, but I double checked with the firmware developers and this is what they said:
"in general it should not be a problem, but I'm inclined to say "it depends". we cache the authorized token, i.e. writes it to flash storage. We do this incrementally to minimize wear and we do not updated it unless it changes (e.g. new key, no longer accepted, updated expiration date). So, if he decides to authorize 10 000 times a day with new keys, then yes, it will wear our the flash eventually"
Alek Slater
Status changed to: Fixed & released
Mike Pieper
Do you have at least a work around?
The aim is to keep control over the charger. I don't want that it automatically starts charging after a power loss or on a cloud outage.
Another idea would be to disable/enable the charger. This works for the power loss case. At the last cloud outage I found the charger loading but I am not sure if it was started before by my home automation.
But the question is: Does this wear out the EEPROM?
Alek Slater
Status changed to: Identified
Alek Slater
Yup, this is unfortunately a known issue, that's just not been prioritized yet, sorry about that.