Background
siid 4 piid 22 is a packed-int bitfield encoding the AI / obstacle-detection sub-options exposed under "Intelligent Obstacle Avoidance" in the Dreamehome app. Partial decoding so far (verified live against r2532a):
| Bit |
Value |
Meaning |
Status |
| 0 |
1 |
always set in our observations |
role TBD |
| 1 |
2 |
Intelligent Obstacle Avoidance (master toggle) |
verified |
| 2 |
4 |
Pictures (capture obstacle photos) |
verified |
| 3 |
8 |
unobserved (next AI sub-option in the menu) |
TBD |
| 4 |
16 |
Pet Recognition |
verified |
| 5–7 |
32, 64, 128 |
unobserved |
TBD |
| 8 |
256 |
always set in our observations |
role TBD |
JSON mirror: each bit also has a corresponding key in FEATURE_CONFIG_JSON (siid 4 piid 50). Confirmed mirror:
Other suspected JSON mirrors (from FEATURE_CONFIG_KEYS documented names):
StainIdentify, MonitorHumanFollow, FillinLight, MaterialDirectionClean
Cross-coupling observed
Toggling Pet Recognition ON also auto-bumped siid 15 piid 1 (AUTO_EMPTY_PROP.FREQUENCY) from Standard (1) to HighFrequency (2). Disabling Pet Recognition did NOT revert this. Asymmetric cross-coupling — worth documenting and modelling in the lib's typed setters so consumers don't get surprised.
Methodology
Run examples/log-events.ts and toggle each AI sub-option in the Dreamehome app one at a time:
- Human Recognition
- Fluid Recognition
- Furniture Recognition
- Human Follow / "Tag-along" mode
- (any others under "Intelligent Recognition" / "Camera AI" menus)
Record which bit moves with each. Document the bit table in src/miot-spec.ts alongside the existing SCHEDULE_FIELD8 constants. Same one-toggle-at-a-time approach used to map the schedule field 8 — see docs/spec-discovery-methodology.md.
Why I'm not closing this myself
I (the maintainer) don't have pets, so the Pet path was the only one I had a personal incentive to test. The remaining 4-5 bits are mappable in five minutes by anyone who has the hardware + the Dreamehome app — happy to merge a PR or revisit when there's user demand.
Acceptance criteria
Background
siid 4 piid 22is a packed-int bitfield encoding the AI / obstacle-detection sub-options exposed under "Intelligent Obstacle Avoidance" in the Dreamehome app. Partial decoding so far (verified live against r2532a):JSON mirror: each bit also has a corresponding key in
FEATURE_CONFIG_JSON(siid 4 piid 50). Confirmed mirror:PetPartCleanOther suspected JSON mirrors (from
FEATURE_CONFIG_KEYSdocumented names):StainIdentify,MonitorHumanFollow,FillinLight,MaterialDirectionCleanCross-coupling observed
Toggling Pet Recognition ON also auto-bumped
siid 15 piid 1(AUTO_EMPTY_PROP.FREQUENCY) from Standard (1) to HighFrequency (2). Disabling Pet Recognition did NOT revert this. Asymmetric cross-coupling — worth documenting and modelling in the lib's typed setters so consumers don't get surprised.Methodology
Run
examples/log-events.tsand toggle each AI sub-option in the Dreamehome app one at a time:Record which bit moves with each. Document the bit table in
src/miot-spec.tsalongside the existingSCHEDULE_FIELD8constants. Same one-toggle-at-a-time approach used to map the schedule field 8 — seedocs/spec-discovery-methodology.md.Why I'm not closing this myself
I (the maintainer) don't have pets, so the Pet path was the only one I had a personal incentive to test. The remaining 4-5 bits are mappable in five minutes by anyone who has the hardware + the Dreamehome app — happy to merge a PR or revisit when there's user demand.
Acceptance criteria
siid 4 piid 22documented insrc/miot-spec.tsdocs/spec-discovery-methodology.md