Update Rachio example with Rate Limit endpoints, fixed 1700 daily requests #196
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
After adding the rate limiting endpoints to I realized making 2 requests per iteration cut down the total daily calls from 1700 to 850. By forcing a user to first get the PERSONID and paste it into settings.toml that allows for a true 1700 limit by making 1 request per run instead of 2. I never came remotely close to approaching 850 per day but if a user reads the Rachio API documentation they'll be expecting to have 1700 requests per day at their disposal, this fixes that.
I tried to somewhat automate the process. The first run will only show the PersonID and instruct the user to paste the ID/Token into Settings.toml. After that is done then it will ignore the first request every iteration.
The reason for the 'if RACHIO_PERSONID is None or RACHIO_PERSONID == "":' is because sometimes settings.toml would return None and sometimes it returns blank. I'm not sure why that is but having both conditionals solved it. The script is expecting 'RACHIO_PERSONID = ""' to be in settings.toml as a blank env on first run.
@FoamyGuy this isn't something that should be done on Stream as the PersonID is now visible in serial unobfuscated as part of the process. There's really no way around it unless I automated it to be stored in NVM and I didn't feel like going that route for this one.