Cookie Bluetooth protocol and app archive map

send '3' → count header + ba/bb/etc cookie events
queue has 10 slots, append doesn't check capacity. if the reply gets lost, can refresh retry without counting the same cookie twice?

The presentation links both the .ino and the MIT App Inventor .aia, so the companion app is recoverable as source. The archive includes Screen1.bky, Screen1.scm, ControlsScreen.bky and ControlsScreen.scm, plus a notification extension. Screen1 contains the device-picker flow; ControlsScreen holds connection, refresh and disconnect handlers. TinyDB tags include Device Address, numOfChildren and peopleAndCookies.

Enrollment, cookie allowance and app control flow.

Cookie app home screen.

Firmware protocol: the app sends ASCII 3. recieveSignal() recognizes that character (lines 229–244). The reply begins with a queue count padded to two characters for counts below ten, followed by two-character event tokens. ba through be represent dispenses for fingerprint IDs 2 through 6; cc represents the over-three-attempt notification branch (lines 343–375). After transmission, the ten queue slots and queue position are cleared (lines 377–380). The app's refresh handler sends 3 and reads the count/payload; this is a manually polled history flow.

• Code-review questions: queue appends have no visible capacity guard, while transmission scans exactly ten slots. If the announced count exceeds stored/transmitted events, the app's framing assumptions can fail. recieveSignal() also has no explicit return for an available byte other than 3; add a defined invalid-command path before relying on it. Preserve raw serial captures when testing these cases, and check partial reads/timeouts at the app boundary.

• This is a reference to recovered source, not a claim of a tested fix. In particular, the archive does not establish that the current phone app and this firmware snapshot were deployed together.

Cookie app refresh and notification controls.

Cookie counts by child profile.