One of the long-lived "bugs" with this project has been with the Dyson login process for cloud services1, 2. For most people, this probably hasn't been a big deal, at least until more recently. Dyson products released in the past year or two don't have stickers with the credentials needed to connect, but the credentials are available from the API. This makes the cloud integration necessary to set up these devices, including:
Formaldehyde models
Humidifier models
The HP07 $200 paint jobupdate of the HP04.
After a few nights of trying to reverse-engineer the API (and learning a LOT about how to actually do this), I got this quick fix that seems to be working just fine.
What's Changed?
Added what's I've arbitrarily deemed a provision_api request at the beginning of any account functions which call the API. The naming is chosen because the API path has "provisioningservice", and in this context it felt more semantically meaningful than something literal like get_version.
There doesn't seem to be any downside to frequently hitting the endpoint, so it's just prepended to all the account methods that could hit the API to "protect" them all.
Other Info
Calling the User Status API initially returns an "Unable to authenticate" error, until after a request for a "version" has been made. Calling this provisioning service version API essentially unlocks the rest of the API.
Background
One of the long-lived "bugs" with this project has been with the Dyson login process for cloud services1, 2. For most people, this probably hasn't been a big deal, at least until more recently. Dyson products released in the past year or two don't have stickers with the credentials needed to connect, but the credentials are available from the API. This makes the cloud integration necessary to set up these devices, including:
$200 paint jobupdate of the HP04.After a few nights of trying to reverse-engineer the API (and learning a LOT about how to actually do this), I got this quick fix that seems to be working just fine.
What's Changed?
Added what's I've arbitrarily deemed a
provision_api
request at the beginning of any account functions which call the API. The naming is chosen because the API path has "provisioningservice", and in this context it felt more semantically meaningful than something literal likeget_version
.There doesn't seem to be any downside to frequently hitting the endpoint, so it's just prepended to all the account methods that could hit the API to "protect" them all.
Other Info
Calling the User Status API initially returns an "Unable to authenticate" error, until after a request for a "version" has been made. Calling this provisioning service version API essentially unlocks the rest of the API.