matterButton (IKEA BILRESA) events stop after idle on secondary admin — ICD subscription + IPv6-to-Thread-BR + matter-server version

[simons-plugins]

Re-scoped — supersedes the original "urgent/short-interval subscription" framing, which was a misdiagnosis.

Real root cause

Battery GenericSwitch remotes (IKEA BILRESA, node 0x2E) are ICDs (Intermittently Connected / sleepy devices). As a secondary admin, matter-server's subscription succeeds initially and even delivers the first presses, then goes silent after the device idles — while admin 1 (Apple Home) keeps receiving instantly. Indigo applies events correctly when matter-server delivers them; the gap is matter-server maintaining the ICD subscription/connection.

This is a known, widespread matter.js/matter-server reliability area, not Indigo-specific:

• matter-js/matterjs-server #526, #187, #102 (sleepy/IKEA battery devices stop updating; "Subscription Liveness timeout")
• home-assistant/addons #4286 (same symptom)
• home-assistant/core #158789 (BILRESA exposes only a generic event entity)

Two dependencies for reliable delivery (both fixable, neither in plugin code)

1. IPv6 route to the Thread Border Router on the matter-server host (jarvis). The device is reached over a Thread ULA (udp://[fd49:6f5f:23f0:…]:5540). HA users report BILRESA is "rock solid" only with working IPv6 to the TBR; without it the device "won't respond." On this LAN the fd49::/64 route is absent and ping6 to the device = "No route to host" — strong signal the host isn't honoring the HomePod's RA/Thread route. Verify on jarvis: netstat -rn -f inet6 | grep fd49, ping6 <device-ULA>, IPv6 = Automatically / RA accepted.
2. matter-server version. jarvis runs matter-server 0.6.2; current is 1.1.2, whose networking stack was "completely redesigned for more reliable discovery, connections, and reconnects" (it's the same matter.js engine HA now ships in production). Upgrading is the other half. (Caveat: 0.6.x→1.x is a major bump — validate the plugin's WS protocol against it.)

Optional plugin-side mitigation

If upstream ICD handling stays weak, the plugin could periodically re-interview/re-subscribe ICD button devices to refresh delivery — a workaround for the upstream gap, not a true fix.

[simons-plugins]

IPv6 ruled out — it's the sleepy poll cycle + subscription persistence.

ping6 from the matter-server host (jarvis) to the BILRESA's Thread ULA:

20 packets transmitted, 20 received, 0.0% packet loss
rtt min/avg/max = 403 / 4199 / 7524 ms   ← perfect sawtooth (7524→6547→…→690, reset ~8s)

Route present (fd49::/64 via the HomePod TBR link-local), accept_rtadv=1, jarvis has an autoconf ULA. 0% loss = the IPv6/border-router path is healthy. The multi-second latency is the device's ~8–9.5s sleepy poll interval (matches SII: 9.5s), i.e. inherent IKEA firmware, not network.

Implication: button events are outgoing and arrive fast while the subscription is live (sub-second bursts in the log). The failure mode is matter-server letting the ICD subscription lapse after idle and then needing slow (poll-gated) server→device round-trips to re-establish — Apple (admin 1) avoids this by maintaining the ICD subscription via check-in. So the fix is matter-server ICD subscription persistence, addressed by upgrading 0.6.2 → current (1.1.2, redesigned networking/reconnect). IPv6 mitigation is NOT needed.