Add simple support for iterator-based event subscription #1
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.
I really like this library and it worked great on my first try! Thanks for doing the work of tracing and prototyping this to make it easy to get a good data feed out of the cloud.
As I integrated it into my standard monitoring system, I debated how often to call the
get_grill_status()
method, and as I read the code in detail, I realized it would actually be pretty easy to convert the status polling into a thread-based subscription method. With this approach, no delay is needed in the polling loop; the MQTT topic controls how frequently the client is updated.Using this approach from the client side is even easier than polling:
The only downside to using this method is that you don't get to control how frequently the updates come, so if (as in your example script) you want a slower or more consistent update frequency, using the existing
get_grill_status()
method is better.