fix: unify iasZone zoneType enum to match ZCL spec

[RobinBol]

Summary

• Extracted shared ZONE_TYPE_VALUES constant so the zoneType attribute and zoneEnrollRequest command use the same enum definition
• Fixed typo: cabonMonoxideSensor -> carbonMonoxideSensor
• Fixed casing: keyfob -> keyFob (ZCL spec says "Key fob" - two words)
• Unified divergent names: standard -> standardCIE, invalid -> invalidZoneType
• Added missing doorWindowHandle (0x0016) zone type from ZCL spec Table 8-5

Breaking changes

Value	Before (attribute)	Before (command)	After (unified)
0	standardCIE	standard	standardCIE
43	cabonMonoxideSensor	carbonMonoxideSensor	carbonMonoxideSensor
277	keyfob	keyFob	keyFob
541	keypad	keyPad	keypad
65535	invalidZoneType	invalid	invalidZoneType

New zone type added: doorWindowHandle (0x0016) - was missing from both enums but present in ZCL spec Table 8-5.

Impact analysis

We performed a comprehensive impact analysis across all publicly available Homey Community Store apps. The conclusion is that this fix is safe to apply - no app depends on the mismatched string values at runtime.

Key findings

• 0 apps compare against any of the mismatched strings in logic (no ===, no switch/case)
• 0 apps read the zoneType attribute via readAttributes and branch on the string value
• 0 apps reference the mismatched values as quoted string literals in executable code
• 1 app stores the zoneType string for display only. In practice it is a water leak sensor (waterSensor, value 42) which is identical in both enums - unaffected even in theory
• 8 apps define their own vendored enum copies and are therefore isolated from this change

Apps handling zoneEnrollRequest

5 apps handle the zoneEnrollRequest command and destructure the zoneType field. None depend on the string value:

Usage pattern	Count	Depends on string value?
Logging/debug output only	2	No
Dead code (commented out handler)	1	No
Passthrough to callback (no inspection)	1	No
Stored as display-only device setting	1	No

Apps with vendored copies (informational)

8 apps define their own IAS Zone enum copies via ZCLDataTypes.enum16() or Cluster.addCluster(). Because they override the enum, fixing node-zigbee-clusters will not change their behavior. These apps could update their local copies independently for consistency, but this is purely cosmetic.

Test plan

• Existing iasZone tests pass (updated assertion for keypad)
• ESLint passes
• Verify downstream consumers update enum key references

[Copilot]

Pull request overview

Unifies IAS Zone zoneType enum keys across the zoneType attribute and the zoneEnrollRequest command to align with the ZCL spec (Table 8-5), while correcting several enum key inconsistencies and adding a missing zone type.

Changes:

• Extracts shared ZONE_TYPE_VALUES and reuses it for both the zoneType attribute and zoneEnrollRequest command in iasZone.
• Renames enum keys to match the ZCL spec (cabonMonoxideSensor → carbonMonoxideSensor, keyfob → keyFob, standard → standardCIE, invalid → invalidZoneType, keyPad → keypad).
• Adds missing doorWindowHandle (0x0016) zone type and updates typings/tests/docs accordingly.

Reviewed changes

Copilot reviewed 3 out of 4 changed files in this pull request and generated 1 comment.

File	Description
test/iasZone.js	Updates assertion to expect renamed zoneType enum key (keyPad → keypad).
lib/clusters/iasZone.js	Introduces shared ZONE_TYPE_VALUES and applies it to both attribute and command enum definitions; adds doorWindowHandle.
index.d.ts	Updates generated TypeScript unions for zoneType and zoneEnrollRequest to reflect unified enum keys and added value.
README.md	Documents breaking changes for the IAS Zone enum unification (but currently misses one rename).

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.