* Introduce a `StringOrObject::Value` variant that captures the
undeserializable JSON value
* Generate an error with the undeserializable JSON value when
deserialization is attempted
* Introduce the `Error::Response` variant so services can raise errors
if the API response are not valid but a relogin will not help
* Indicate that a login failed for status (error) code 1
* Indicate that an API request failed and relogin is necessary for
status code 1 or 100
* Raise an error on any non-zero status code otherwise with the message
As a result, services don't always have to provide a `reqwest::Error`
but also return other errors. The error variant `Error::NotAuthorized`
in particular specifies that requests are not or no longer allowed and a
login should be (re)attempted. This way, services can indicate that it
is in this state and not have to provided a 403 status code
`reqwest::Error` to show this.
Add a depend on the `thiserror` crate for this.
In Hoymiles, the date of the last update is part of the API response.
Parse it and use that in `Status` instead of the timestamp provided by
the update loop.
Add a depend on the `chrono` crate for this.
Sometimes it can be that `today_eq` is reset when the day switches but
it has not been added to `total_eq` yet. The `total_eq` should always be
non-decreasing, so return the last known value until this is corrected
(this most suredly happens during the night).
Also, allow for `login` and `update` to mutate the state of the service
to be able to update things like the last known total produced energy
value.
* Also deserialize the status (error) code and message
* Handle `data` fields having the value `""` in API responses if there
is an error
* Add missing documentation for API struct fields
Add support for retrieving solar panel data from Hoymiles.
* Add the Hoymiles service
* Update the documentation
* Add a depend on the `md-5` crate for password hashing
Reviewed-on: #6
Paul van Tilburg