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.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add MEATER support #120
Add MEATER support #120
Changes from all commits
5587840
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hopefully PR #114 (Logging for v1.35) will be merged soon.
Would it be reasonable to put the MEATER-specific code into
::device::meater
indevice_meater.tcl
or something similar?This
msg -DEBUG
makes sense for early development, but probably needs a flag to disable or to be removed later on.Passing in
event_time
, even if unused, means that later processing can know when the packet arrived for processing. Depending on how much is inline code of the handlers from previous packets, it can be delayed by 100-250 ms or more. I didn't convert all of the existing calls inbluetooth.tcl
due to the number of changes. Right now, it's on a packet-by-packet basis, but I can definitely see puling events off theble
callback and onto the event queue if I can't get potentially slow things likeskins_page_change_due_to_de1_state_change
out of the BLE handler and onto the appropriate queue.(Reminds me to try to get that onto an event. When I last tried, the GUI failed to render. Hmmm, now it works.)
(and you ruin a coffee because the timestamp fetch is done blocking and locks up the machine for 30 seconds)
In
bluetooth.tcl
:In
device_scale.tcl
:There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To help prevent puzzles
msg -NOTICE [format "Steaming stopped for temperature at %.1f for target %.1f" $value $::settings(target_milk_temperature)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
At a higher level, does it make sense to have a "check for" list somewhere so that the scanner can be stopped, at least at boot? Maybe stop if started from boot (or wake) if configured devices are all found?
I haven't watched in a lot of detail, but it seems that at least DSx dumps the whole set of shot frames and settings onto the BLE queue at load time, often even before the DE1 is connected. Maybe that's a different problem to resolve.