Closed gredin closed 4 years ago
Thank you for your contributions!
I think we should keep the token methods public, as some applications may want to get/refresh the token according to their own logic - otherwise, this could be considered a breaking change.
I understand the breaking change issue.
What do you think about keeping the methods public, but adding an optional arg automaticToken
* (default: false
) in the constructor that would enable the automatic acquisition/refresh behaviour?
(*The naming needs improvement, but you get the idea.)
I think that's a good idea, then we can check that property in the token methods and throw an error if it's true and the consumer is trying to call it anyways.
Maybe handleToken
?
I'm back. What do you think about the changes?
Also, I fixed the choice of the sign method according to Tuya documentation:
TuyaCloud provide two sign algorithm based on different scenario:
- token related interface(v1.0/token&v1.0/token/{refresh_token}):sign = HMAC-SHA256(client_id + t, secret).toUpperCase()
- business interface(except token interfaces):sign = HMAC-SHA256(client_id + access_token + t, secret).toUpperCase()```
👌 Thanks for the contributions!
Published in v1.1.0.
I'm using your work in my home project (controlling beer fermentation temperature). So, first: thanks!
I think clients of this library don't need to know the token acquisiton details. This PR intends to hide these implementation details.
P.S. Also,
getDeviceStatus
method as a bonus.