Open
Conversation
Enable DeFlock mobile app connectivity via BLE GATT notifications, and desktop host detection via USB serial heartbeat. When a companion is connected, WiFi AP is disabled to free radio bandwidth and BLE scan duty cycle is increased for better detection performance. - BLE GATT server advertising service UUID a1b2c3d4-e5f6-7890-abcd-ef0123456789 with TX characteristic (NOTIFY) for streaming detection JSON - Chunked BLE notification sender respecting negotiated MTU - "event":"detection" field added to JSON output for DeFlock parser - Serial host detection via heartbeat timeout (5s) - Companion mode: WiFi AP off + scan duration 2s→3s when connected - Scan interval/duration converted from #define to mutable variables Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
…tSpotter Expand MAC prefix detection with entries sourced from: - Flock WiFi (Liteon/USI): f4:6a:dd, f8:a2:d6, e0:0a:f6, 00:f4:8d, d0:39:57, e8:d0:fc — contract manufacturer OUIs (Liteon Technology and USI/Universal Scientific Industrial) identified via the OUI-SPY firmware ecosystem table and cross-referenced against the IEEE OUI registry. These manufacturers produce Flock Safety's WiFi-enabled camera hardware. - Flock Safety direct: b4:1e:52 — registered directly to "Flock Safety" in the IEEE OUI database (MA-L assignment). This is their own prefix rather than a contract manufacturer's. - SoundThinking/ShotSpotter: d4:11:d6 — registered to "SoundThinking Inc" (formerly ShotSpotter) in the IEEE OUI database. Their acoustic gunshot detection sensors use BLE for local diagnostics and provisioning. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
BLE server callbacks run on the NimBLE host task, not the Arduino loop task. Calling WiFi state changes and delay() from that context can stall BLE processing or trip watchdogs, and mutating scan duration creates a cross-task data race. Fix: callbacks now just set a volatile pending flag. The actual WiFi/scan changes are applied in loop() where they're safe. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Collapse the two-branch snprintf into a single call so every detection message includes is_raven (true/false) and raven_fw, making the format self-describing regardless of device type. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Address Copilot review: contract manufacturer OUIs (Liteon/USI) are now in a separate flock_mfr_mac_prefixes[] array emitting "mac_prefix_mfr" as the detection method. SoundThinking/ShotSpotter gets its own array and "mac_prefix_soundthinking" method. Low-confidence detections (mfr OUIs) suppress buzzer/heartbeat but still emit JSON events so consumers can apply their own thresholds. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
…uffer Low-confidence mac_prefix_mfr hits no longer update fyLastDetTime/fyLastHB, preventing them from keeping the heartbeat alive after a high-confidence device leaves range. Bump FYDetection::method from 24 to 32 bytes so "mac_prefix_soundthinking" (23 chars) has headroom. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Add OUI prefixes for Flock WiFi, Flock Safety direct, and ShotSpotter
Add BLE GATT server, serial host detection, and companion mode
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Summary
Adds basic WiFi Client configuration to project, addressing Issue #34. Build time parameters are added to support this effort:
RAYHUNTER_ENABLED- Bool to handle logic flow for either running in standalone AP mode or as a WiFi ClientRAYHUNTER_SSID- String for Rayhunter's AP SSIDRAYHUNTER_PASS- String for Rayhunter's WiFi passwordSome default values are set if
RAYHUNTER_ENABLEDis true, but no SSID or Pass are included - this will probably fail to connect, but the logic added will fail back to a self-contained WiFi AP in the event that the Rayhunter WiFi is unreachable (either at start up or during operation).The Flock You program will attempt to connect to the given SSID with the password for approximately 20 seconds, and if it is not successful it will fall back to hosting its own AP.
Tests
For all the tests below, the program builds and flashes successfully:
RAYHUNTER_*build parameters, flock you operates as normal (the device acts as a self-contained AP, serving the site onhttp://192.168.4.1RAYHUNTER_ENABLEDset to false, or with noRAYHUNTER_*build variables, flock you operates as normal (the device acts as a self-contained AP, serving the site onhttp://192.168.4.1RAYHUNTER_ENABLEDset to true, but incorrect or missingRAYHUNTER_SSIDandRAYHUNTER_PASSbuild parameters, flock you attempts to connect to the incorrect/missing AP as a WiFi Client for approximately 20 seconds before failing back to a self-contained AP, serving the site onhttp://192.168.4.1RAYHUNTER_ENABLEDset to true, and valid values forRAYHUNTER_SSIDandRAYHUNTER_PASS, flock you connects to the external WiFi AP as a client, and serves the site (reachable as eitherhttp://<DHCP provided IP>orhttp://flockyouOther Thoughts
It occurs to me now that there's no limitation on only connecting to Rayhunter - given the correct SSID/Pass for a home or business WiFi network it should work the same way. If you all want, I can refactor to replace
RAYHUNTERwith something likeWIFI_CLIENTor similar to remove that association.