-
Notifications
You must be signed in to change notification settings - Fork 304
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
Discovery filter #565
Discovery filter #565
Conversation
…on. Added example that uses this functionality to find devices by name.
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.
This is really useful, thanks! I have made a few comments and it looks like we need to run black
on the changes.
And please add a changelog entry as well. |
…ameters on the command line
Except for the filter function signature I think it's all there now. I did accidentally mark the "args for examples" discussion as done and I can't see how to undo that. |
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.
This looks good; a welcome improvement.
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.
Looking good, just one more suggestion.
Since we can await the asyncio.Queue, we no longer need an asyncio.Event(). Also remove unused timeout kwarg while we are touching this code.
Merged, thanks! |
An outbound API (notifications) is provided in a separate process. The present implementation uses MQTT and provides timestamped, source-identified, semantically versioned JSON payloads for: * DE1 * Connectivity * State updates * Shot samples with accumulated volume * Water levels * Scale * Connectivity * Weight and flow updates * Flow sequencer * "Gate" clear and set * Sequence start * Flow begin * Expect drops * Exit preinfuse * Flow end * Flow-state exit * Last drops * Sequence complete * Stop-at-time/volume/weight * Enable, disable (with target) * Trigger (with target and value at trigger) An example subscriber is provided in `examples/monitor_delay.py`. On a Raspberry Pi 3B, running Debian Buster and `mosquitto` 2.0 running on `::`, median delays are under 10 ms from the arrival_time of the triggering event to delivery of the MQTT packet to the subscriber. Packets are being sent with retain True, so that, for example, the subscriber has the last-known DE1 state without having to wait for a state change. Checking the payload's `arrival_time` is suggested to determine if the data is fresh enough. The will feature of MQTT has not yet been implemented. One good thing about MQTT is that you can have as many subscribers as you want without slowing down the controller. For example, you can have a live view on your phone, live view on your desktop, log to file, log to database, all at once. Scan For And Use First DE1 And Skale Found Though "WET" and needing to be "DRY", the first-found DE1 and Skale will be used. The Scale class has already been designed to be able to have each subclass indicate if it recognizes the advertisement. Once DRY, the scanner should be able to return the proper scale from any of the alternatives. Refactoring of this is pending the formal release of `BleakScanner.find_device_by_filter(filterfunc)` from bleak PR #565 hbldh/bleak#565
This change adds a new method
BleakScanner.find_device_by_filter(filterfunc)
that finds the first device that matches the filter function.There's a new example
scanner_byname.py
that is similar toscanner.py
but you specify the name of the BLE device you are looking for in stead of the address.(I haven't merged the commits, in case you want to partially accept this).