Skip to content

5.18: a device's primary on/off state follows only its own kind of report - #3

Merged
Highsteads merged 1 commit into
mainfrom
claude/onoff-primary
Nov 1, 2026
Merged

Highsteads merged 1 commit into
mainfrom
claude/onoff-primary

Conversation

@Highsteads

Copy link
Copy Markdown
Owner

Summary

Every report the plugin decoded used to write onOffState on every companion device of the node. So a Contact device sharing a node with a siren, lock, dimmer or mains monitor was switched by those reports. For example, a siren going quiet showed an open door as closed. #2 (5.17) fixed this for Home Security events; this PR does the rest.

Changes (plugin.py)

  • PRIMARY_FAMILIES and _set_primary(). A report of a given family sets onOffState only when the device's type lists that family, or the device is Generic:

    Report Primary state of
    Motion, intrusion, glass break Motion (from 5.17)
    Door/window (notification and binary), Barrier Operator Contact
    Lock/unlock (notification and Door Lock CC) Lock
    Switch Binary, Switch Multilevel Plug, Energy
    Central Scene, Scene Activation Scene
    Water, smoke, CO, gas, siren, mains power, binary tamper Generic only

    docs/devices.md already places alarms on the Generic Sensor, which is why the alarm family is Generic only.

  • Sensor Binary. Typed reports go through BINARY_PRIMARY_FAMILY. General-purpose and untyped (v1) reports still set every device's primary state, because their state key is onOffState.

  • Basic is unchanged. It still sets every device's primary state, because it is untyped and older motion and door sensors use it as their only report.

  • Each report's own state is unaffected. States such as contact and sirenActive still update wherever the device declares them.

  • Version 5.18 in Info.plist, the plugin.py header, the README and docs/changelog.md. The changelog tells users to move any trigger that relied on a report of another kind onto that report's own state.

Test plan

  • tests/test_primary_state.py sends every report kind to every device type (253 cases) through _route_zwave_report, plus two mixed-node scenarios.
  • Sabotage check: with the old behaviour (write everywhere) put back at runtime, 180 of those tests fail.
  • pytest: 536 passed. Ruff and compileall are clean. Run Parser Self-Test: 14 passed, 0 failed.
  • Not yet run on the Indigo Mac. Check any trigger on a non-Generic device's primary state that relied on a report of another kind.

Generated by Claude Code

…port

Every decoded report used to write onOffState on every companion device of
the node, so a contact sharing a node with a siren, lock, dimmer or mains
monitor was switched by those. 5.17 fixed this for Home Security events;
this does the rest.

- PRIMARY_FAMILIES / _set_primary(): a report of a family sets onOffState
  only where the device's type lists it, or the device is Generic:
  door/barrier -> Contact; lock (notification and Door Lock CC) -> Lock;
  switch binary/multilevel -> Plug and Energy; central scene / scene
  activation -> Scene; water, smoke, CO, gas, siren, mains power -> Generic.
- Sensor Binary: typed reports use BINARY_PRIMARY_FAMILY (tamper and alarms
  Generic only); general-purpose / untyped reports still set every device.
- Basic reports still set every device (untyped; older sensors rely on it).
- Each report's own state (contact, sirenActive, ...) still updates wherever
  the device declares it.
- tests/test_primary_state.py: every report kind x every device type (253
  cases) through _route_zwave_report, plus two mixed-node scenarios. With the
  old behaviour put back at runtime, 180 fail. 536 passed in all.
- Version 5.18: Info.plist, plugin.py header, README, docs/changelog.md.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019Z2FM7PBbhgq9QjrM5W2HY
@Highsteads
Highsteads merged commit 6b75fff into main Nov 1, 2026
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants