Ecosystem commands that match the endpoint's current state are silently dropped (observed with Alexa)

[simons-plugins]

Observed

First non-Apple ecosystem test, 2026-08-06. Alexa paired successfully — fabric #3, CASE sessions established, accessories discovered and shown. But the devices did not respond to commands, and Alexa reported them as not responding.

The bridge node received and accepted Alexa's invokes:

12:53:57  indigo-matter-bridge.aggregator.indigo-287885105.onOff.on   (Study Lamp)
12:54:09  indigo-matter-bridge.aggregator.indigo-287885105.onOff.off
12:54:42  indigo-matter-bridge.aggregator.indigo-1736047509.onOff.on  (Study Pendant)
12:54:47  indigo-matter-bridge.aggregator.indigo-1736047509.onOff.off
          … each answered  Invoke (final) » commands: 1

The plugin was attached throughout (Client attached (plugin 2026.8.4) at 11:44:45Z, invokes from 11:53Z). Nothing appeared in the Indigo event log for any of them — no dispatch, no sent "Study Lamp" on from the owning plugin, no error.

Suspected mechanism — NOT yet proven

Command events are emitted from attribute-change listeners (watchCommands → onOff$Changed etc.), not from invocation handlers. If an ecosystem commands a state the endpoint already holds, matter.js accepts the invoke, the attribute does not change, no $Changed fires, and nothing is emitted — so the real Indigo device is never told.

That would make control silently dependent on the endpoint's belief matching reality. Any drift (a dropped state push, a physical switch, a plugin restart between pushes) leaves commands in that direction dead until something else moves the attribute.

This is not Alexa-specific in principle — Apple would behave the same way under the same conditions. Apple control has worked in testing, which is consistent with its endpoint state simply being accurate at the time.

To investigate before fixing

1. Confirm the mechanism: set an endpoint's onOff true via set_state, then invoke onOff.on remotely, and check whether any command event is emitted.
2. If confirmed, emit from the invocation as well as the attribute change — an ecosystem asking for a state is an intent to be forwarded, regardless of what the endpoint currently believes. Mind the echo guard: a plugin-originated set_state must still not round-trip.
3. Check every role, not just onOff — setLevel, setColor, lock/unlock and covering commands ride the same watcher design. Note doorLock and windowCovering are already invocation-driven (E4 made them emit-only), so they may be unaffected — which would be evidence for the mechanism.
4. Re-test with Alexa afterwards; the fabric was removed (removeFabric fabricIndex: 3) when the user deleted the pairing.

Also worth noting

Alexa pairing itself worked — three fabrics live simultaneously (two Apple, one Alexa), which is the multi-admin proof ADR-0007 asks for (#139), independent of this control bug.

[simons-plugins]

CONFIRMED by user observation — and it exposes a second bug

Reported 2026-08-06: "it had the wrong state when it loaded them. When I change state on Indigo, Alexa sees it and updates, then its next action does work."

That is the suspected mechanism, exactly:

1. The endpoint's attribute disagreed with the real device when Alexa first read it.
2. Alexa commanded the state the endpoint already believed → matter.js accepted the invoke, the attribute did not move, no $Changed fired, nothing was emitted, the device was never told.
3. A state change made in Indigo pushed the true value outward → the attribute moved → Alexa resynced.
4. Alexa's next command was now a real change → emitted → worked.

So there are two defects here, not one.

A — commands are forwarded only when they change the attribute (the original report)

Emit from the invocation as well as the attribute change. An ecosystem asking for a state is an intent to forward regardless of what the endpoint currently believes; the device is the authority on whether that is a no-op. Keep the echo guard so a plugin-originated set_state still does not round-trip.

Prediction that would confirm the mechanism cheaply: doorLock and windowCovering should be unaffected, because E4 made them invocation-driven (emit-only) rather than attribute-driven.

B — the endpoint held a wrong state to begin with

Worth investigating on its own: why did the attribute disagree with the device at load? Candidates:

• Restored endpoints are created with states: {} (role defaults — onOff: false) by the Bridge serves an EMPTY aggregator after restart — Apple resets rooms on every reboot #141 fix. The plugin's attach is supposed to supply true state via the spec, and the reconcile logs N updated — verify that the update path actually applies states, not just label and reachable. If it does not, every restored endpoint starts wrong until its device next changes, which would make defect A fire constantly rather than rarely.
• Or the push happened and Alexa cached its own stale value from before it was resynced.

(B) is the more serious of the two if confirmed, because it is a regression window opened by the #141 fix and it makes (A) far more likely to bite. Test: restart the node, and before touching anything in Indigo, read onOff off a restored endpoint and compare with the Indigo device's real state.

[simons-plugins]

Defect B sharpened — and my "update ignores states" theory is WRONG

User detail: "Alexa showed all off even though some were on."

"All off" matches the role default (onOff: false) that restored endpoints are constructed with (states: {}, node.ts:355), which is suggestive. Apple did not show the problem, consistent with Apple having been connected throughout and holding its own picture, while Alexa paired fresh after the restart and read the attributes directly.

But the obvious explanation does not survive the code. registry.update() (bridge-node/src/registry.ts:413) does call applyStates(live.endpoint, live.role, spec.states), so the attach's update path is not ignoring state. Recording that here so nobody re-derives it.

Two candidates remain, and they need evidence rather than reasoning:

B1 — the plugin supplied no useful states in that attach. endpoint_specs() builds each spec's states from handler.states_for(dev, options). Worth checking whether they were populated at that moment, and whether _pushed (the last-pushed snapshot) interacts: if the snapshot believed the endpoint already held those values, a later device_updated diff would push nothing, leaving a wrong attribute uncorrected.

B2 — Alexa's own initial read. The endpoints may have been correct and Alexa simply showed stale/default state until something moved.

Cheap test that separates them

Restart the bridge node. Before touching anything in Indigo, read the endpoint's attribute directly off the node (get_status, or the matter.js state) and compare with the Indigo device's real state.

• Attribute wrong → B1, ours, and serious: every accessory misreports after a restart until its device next changes, which makes defect A fire constantly instead of rarely.
• Attribute right → B2, Alexa-side, and much less serious.

Do this before fixing anything.

[simons-plugins]

Defect B (wrong initial state) — investigation 2026-08-06, node EXONERATED

Live session on jarvis (plugin 2026.8.4, node 0.7.0, paired to Apple + Alexa). Three ShellyNGMQTT switches — Study Lamp (287885105), Study Pendant (1736047509), Study Bookcase Lights (1664427354) — were un-exported earlier, then re-exported at 13:39 BST while both ecosystems were paired. All three were genuinely ON (SQL Logger confirms 1664427354 was on continuously from 11:10). Both ecosystems showed them OFF.

What is now established

1. The push-on-change path works. Toggling 1664427354 off→on in Indigo reached Alexa within seconds.
2. The update path works. A plugin restart (attach → 5 endpoints, 0 created, 5 updated) corrected all three in both Apple Home and Alexa.
3. The create path is correct in the node. Three new tests in bridge-node/test/restore.test.ts (commit e22e861) cover create-over-an-already-persisted-value: in-process after un-export/re-export, across a node restart (so the value is loaded from disk, not carried in memory), and via upsert_endpoint rather than attach — which is the route the dialog actually takes and parses its spec separately. All three pass. A persisted value does not outrank the spec's initialState.

So the fault is not "the node resurrects a stale attribute". Whatever went wrong at 13:39 is upstream of registry.create or downstream in the ecosystems.

Blind alley — do not re-walk it

matter.js does not flush a constructor-supplied initialState to its store. So …/indigo-matter-bridge/root.parts.aggregator.parts.<id>.onOff.onOff is not a reading of the live attribute — the file only appears once something writes the attribute. On jarvis two of those files said false for accessories that were on and had just been corrected in both ecosystems. Reading them as live state cost a good hour. Use a live channel, not the store.

Remaining candidates, in order

• B1a — the plugin sent onOff: false. ExportHandler.states_for for onOffLight/onOffPlugInUnit is bool(getattr(dev, "onState", False)); that False default and the bool() both turn "absent" and None into a confident off. Not yet observed doing so: indigo.devices[1736047509].onState reads True now, and indigo-mcp-lite reads it the same way. Needs the outgoing spec logged — nothing on the plugin side logs the frame, which is itself the gap that made this hard.
• B2 — the ecosystems never read the new endpoint's initial value. A freshly added bridged endpoint changes the aggregator PartsList and bumps ConfigurationVersion (we do both), but a controller that does not re-read shows its own default until an attribute change report arrives. This fits every observation, including why a restart's applyStates — a genuine write, hence a report — fixed it.

Cheapest experiment that decides it

Export one device that is currently ON while paired, and watch both apps. If it appears ON → 13:39 was a one-off or an ordering effect. If it appears OFF → B2 is live and reproducible, and the fix is to make create emit a real attribute report rather than rely on initialState. Add frame-level debug logging to bridge_client first so the outgoing spec is visible — that is worth having regardless of which branch wins.

Not this issue

The ENDPOINT-NUMBER DRIFT: indigo-459564566 expected 5, got 2 now firing on every attach is #140's aftermath of the factory reset, not defect B. It also leaves endpoint-map.json holding number 5 twice (459564566 and 547447788), which is expected given check() never rewrites a number — but worth naming in #140.

[simons-plugins]

Defect B DECIDED, 2026-08-06 — B2 confirmed, and it is Alexa-only

The experiment from the previous comment was run. Kitchen Spots Hob (772478931) — a zigbee2mqtt dimmer, onOffState: true, brightnessLevel: 58 — was exported while both ecosystems were paired.

Apple Home showed it ON. Alexa showed it OFF.

One spec, two answers. That settles it:

• B1a is ruled out. The plugin sent onOff: true — Apple rendered it correctly from the same attach/upsert frame. states_for's bool(getattr(dev, "onState", False)) default is not implicated here (it remains a latent sharp edge, but it is not this bug).
• B2 is confirmed. A freshly-added bridged endpoint's initial attribute value does not reach Alexa. Apple reads it; Alexa does not, and shows its own default (off) until a real attribute change report arrives.

Why, mechanically

createEndpoint bakes the spec's states into the endpoint's initialState at construction. An attribute that is born true never changes, so matter.js emits no $Changed and no subscription report — there is nothing to push. Apple compensates by reading the attribute after the PartsList/ConfigurationVersion bump; Alexa evidently does not.

This is the same root shape as defect A in this issue: we depend on matter.js's attribute-change machinery for something that is not a change. Worth noting the two halves of #143 are one design fault seen from both ends — inbound (A: an invoke matching current state emits nothing) and outbound (B2: a value born correct reports nothing).

Every earlier observation now fits, including the ones that misled me:

• the plugin restart corrected all three — update() calls applyStates, which is a genuine write, hence a real report;
• my Indigo toggle corrected Study Bookcase Lights — also a real write;
• the three create-path tests in e22e861 pass — the node's stored state was always right. The bug was never a wrong value, it was an unreported one, which no assertion on stateOf(...) can catch.

Proposed fix (follow-up PR — deliberately NOT in #142)

In EndpointRegistry.create, construct the endpoint from the role's own defaults and then applyStates(spec.states) immediately after aggregator.add() — exactly what update() already does. The state then arrives as a real false→true transition, emitting the report Alexa needs.

Notes for whoever picks it up:

• definition.initialState() must still supply the mandatory cluster attributes at construction (colour especially — see the "builds a role whose spec already carries its full initial state" test, which exists because a bad spread there fails endpoint construction outright). Only the spec's patch moves; the defaults stay put.
• Keep statePatchOrRefuse's validation before add(), so an unusable spec still fails without leaving a half-built accessory.
• A spec value equal to the role default still emits nothing — benign, because the ecosystem's own default then agrees.
• Testing this needs an assertion on the emitted report, not on stateOf. Asserting stored state is what let this through.

Workaround until then

After exporting a device, restart the plugin (or change the device's state once in Indigo). Either produces a real write and corrects the ecosystem. Worth a line in the docs regardless of the fix, for anyone on an older node.

[simons-plugins]

CORRECTION to the previous comment — B2 is NOT confirmed; this looks like Alexa-side convergence lag

The "B2 confirmed" verdict above was called too early. Later evidence from the same session contradicts it and the conclusion should be treated as withdrawn pending a proper test.

What actually happened next

Kitchen Spots Hob (endpoint 7, dimmableLight) was exported at 13:13:28Z while both ecosystems were paired. Apple showed it correctly; Alexa showed it off, then unresponsive. Then:

• toggling in Indigo and in Apple Home moved each of those, but not Alexa;
• a plugin restart at 13:15:03Z (0 created, 6 updated — genuine applyStates writes on every endpoint) did not fix it either;
• some minutes later, with no further intervention, Alexa came right on its own and now responds normally.

So the earlier "the plugin restart corrected all three study lights" was almost certainly confounded. Those were exported at 12:39Z and observed correct after the 13:03Z restart — a ~24-minute window in which Alexa could equally have converged by itself. Two observations, both consistent with elapsed time rather than with anything we did.

Outbound reporting is fine — measured, not inferred

A controlled toggle of endpoint 7 at 14:21:22Z produced I/ReportData on all three live sessions — one Apple (@1:66e955c6) and both Alexa Echo hubs (@4:41869fbd537ef01, @4:41869fd51d8b011) — each acked with StatusResponse within ~15ms.

Alexa's fabric (index 4, label Alexa-4, vendor 4631) holds two subscriptions, both wildcard (attributeRequests: [{}]), maxIntervalCeiling: 300000, negotiated maxInterval ≈ 188s.

That kills the "Alexa never receives reports for a newly-added endpoint" reading: it does, promptly, on a wildcard subscription that evidently does cover endpoints added after the subscription was established.

Where that leaves defect B

The born-vs-changed gap in createEndpoint (an attribute constructed true emits no change report) is still real as a matter of code, and the proposed fix in the previous comment is still sound and cheap. But it is no longer supported as the explanation for what was observed, because a subsequent genuine write also failed to move Alexa at the time — and then Alexa corrected itself with no write at all.

Current best reading: Alexa-side convergence lag after a bridge's endpoint set changes, on the order of minutes, during which it reports stale state and then unresponsive. Not obviously our bug. Apple does not exhibit it.

What would actually settle it

Needs a clean run, ideally with beta testers on more than one Alexa setup:

1. Export one device that is on, and record what Alexa shows at t+0, +1, +5, +15 min without touching anything. Establishes the convergence curve, if there is one.
2. Repeat with the create-path fix applied. If Alexa is right at t+0, the fix matters; if the curve is unchanged, it is cosmetic and B is Alexa's.
3. Watch root.subscriptions.subscriptions and the session list across the window — a re-subscribe at the moment it comes right would be decisive.

Defect A (inbound commands emitted only from attribute-change listeners) is untouched by all of this and remains the substantive half of this issue.

Blind alleys, now three

Adding to the two listed above: do not attribute a correction to the last thing you did. Both "the restart fixed it" readings in this thread are unsafe — this system has a background process that fixes things on its own timescale, so any intervention needs a control before causation is claimed.