Fix incorrect validation model for charger update#352
Conversation
api/chargers/{id}/update only returns an empty response (with a 200/401/403 response code). Not sure if this is due to a change in the API or if it's just a sleeper-bug that was introduced in custom-components#183 and never triggered because the validation code was not executed.
|
LGTM This is a dilemma. We need input validation so it doesn't crash deeper into the integration. However, it's a merry chase if Zaptec keep changing the data. |
|
Does the code handle getting empty responses to update? |
|
Yeah, we don't use the return value for anything as far as I can tell (and it works just fine in 0.8.3). I'm leaning more towards this being an artifact of switching from the old internal settings-api to the charger/update-api and not changing the validation model used. In my defense, that was my first commit here, so I didn't really know what I was doing yet 😛 |
|
(adding full test coverage of the api-functionality to my Christmas wish list) |
|
Can you update a new draft section in CHANGELOG.md for the upcoming 0.8.5, please? So we don't forget. I'm a bit on and off this project these weeks. |
|
Included a reference to the |
|
LGTM. I'm happy to push a 0.8.5 tonight if you are up for prepping the release PR. |
|
api/chargers/{id}/update only returns an empty response (with a 200/401/403 response code). Not sure if this is due to a change in the API or if it's just a sleeper-bug that was introduced in #183 and never triggered because the validation code was not executed previously.
Fixes #351