adafruit / adafruit/Adafruit_Wippersnapper_Arduino

v2.1: seed digitalio input change-detection from a last-known-state initial write in pinAdd

Open
#955 2 comments 0 reactions 0 assignees View on GitHub
api-v2 digital-gpio-api enhancement long-term
Dominant language
C++
Stars
54
Forks
56
Avg merge
2d 12h
Merged PRs (30d)
11

Description

### Context

Deferred from the #943 review ([thread](https://github.com/adafruit/Adafruit_Wippersnapper_Arduino/pull/943#discussion_r3633871850), [deferral](https://github.com/adafruit/Adafruit_Wippersnapper_Arduino/pull/943#discussion_r3638605246)) as a nice-to-have for **v2.1**.

`DigitalIOHardware::CheckEvent()` (src/components/digitalIO/hardware.cpp) currently treats the first read after a pinAdd specially: `_prv_value` starts as a guess, so the first read seeds the baseline from hardware and is always published as the pin's initial state (fixed in dcb1f047 — previously the guess could suppress or fabricate a transition).

### Feature

For **input** pins, IO should supply the last known state in the pinAdd's optional initial `write` (the field already exists in `ws_digitalio_Add` and is currently only meaningful for outputs). The firmware would use that as the starting *previous value* for the on-change trigger:

- current reading == last known state → no redundant initial event; the broker already has this value
- current reading != last known state → a genuine **transition** event fires, so a state change that happened while the device was offline / rebooting / sleeping is detected and published as a change rather than a fresh baseline

### Notes

- Needs IO/broker cooperation: the pinAdd for an input must carry the last value the broker saw (companion change in adafruit/Wippersnapper_Protobuf semantics/docs if the existing `write` field is reused).
- Interaction with `is_inverted` and expander-backed pins (`EXP_0xNN_P`) should follow the logical-value convention used by `ReadValue()`.
- Sleep/wake replay makes this more valuable: every deep-sleep wake re-runs componentAdds (see #952), so today each wake re-publishes baselines for every input.

Refs: #943, #952.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Contributor guide

No contributing guide indexed for this repository

Research direction

Start in src/components/digitalIO/hardware.cpp at DigitalIOHardware::CheckEvent(), then trace ws_digitalio_Add and ReadValue() to understand initial writes, logical values, inversion, and expander pins. Check the referenced Wippersnapper_Protobuf semantics/docs and componentAdds wake path; done means input pinAdd state suppresses redundant events and publishes an offline transition consistently with the broker.

Written by the indexing model from the issue text.

Assessment

Tech stack
arduino, cpp
Domain
embedded-iot
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
48/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.