In the effort to increse reliability of the Zigbee sample, #126 and #130
introduced handling for possibly rare, hard-to-debug events that may be
occurring. While these changes seem to help in practive, we don't know
exactly how often, if ever, they are triggered.
This PR introduces debug_counters in hope to add some visilibty in these
hard-to-debug, rare conditions.
Calling `prst_debug_counters_increment("some_counter")` will increment a
value stored in flash. These values are then dumped via logging when the
device boots. Moving forward we can also consider exposing these values
via a ZigBee cluster.
Nordic has published an errata for the nRF Connect SDK for versions
>1.8.0 where a Zigbee End Device can end up getting stuck if the
parent device does not acknowledge the "Device Announcement packet".
They have a suggested workaround to implement in the SDK, which has
been adapted for the custom signal handler used here.
This is an effort to solve issues where my parasites would occasionally
drop off my network and require a reboot. After 24Hrs, I've not yet
had a device disappear but it has taken >weeks before a device would
fail. Unforunately it's hard to debug the board as the chips are in a
low power state when this occurs.
I've been debugging a Shelly [bluetooth
proxy](https://www.home-assistant.io/integrations/shelly/#bluetooth-support)
feature, which didn't like b-parasite's advertising. It swallowed it before proxying it to HA.
I compared to both ATC and the legacy b-parasite advertising
(pre-nrf-connect) and found it to be related to the
non-connectable/non-scannable settings. Until this PR, we were
mistankenly settings the advertising to scannable, although with no
scannable data. The Zephyr code that sets this parameter based on the
scannable data is [here](c0fcd35531/subsys/bluetooth/host/adv.c (L860)).
My bet is that some scanners like ESPHome are okay with this, but Shelly
is not. Either way, I believe this PR makes the advertisements more
compliant.
This will enable us to transparently use different calibration for
different board revisions. The 2.0.0 revision changes the sensing
circuitry and will need its own coeffs.
In this commit, both models are run in parallel for debugging.
The API for reporting information requires a pointer to the data value,
and cannot deal with a constant directly. The current quantity/size
returned by the device are random values from memory.
Instead move these values into the prst_batt_attrs_t struct and
set their values in prst_zb_attrs_init.
We were previously relying on the default values (100ms, 150ms). This
PR makes it easier to test and configure parameters for different
tradeoffs between range / power consumption (#98).
The new SDK requires 802.15.4 to be enabled in the board DTS file.
Also disable IPv6 explicitly to avoid compile errors related to its
network stack, since it is not used currently.
Closes#94
This is a "tricky" workaround due to the lack of physical buttons:
We can distinguish between the two "power up" modes:
- Power on: when the device receives power for the first time. Example:
swapping batteries, prroviding external power. This _DOES NOT_ reset the
pairing info.
- Reset pin: when the device is manually reset (by shorting the RESET
pin to GND), or when a new firmware is flashed. This _RESETS_ the
pairing info.
