Hello!
Background
By Z-Wave spec if the position of blinds is unknown the value reported should be 254.
This will happen mostly when blinds are not calibrated or are reset and lose calibration.
If you add such blind to the HomeKit integration it will effectively stop updating state of all devices in HomeKit. I cannot say if this is because HomeKit cannot parse 254 or if there is a problem with the integration parsing it. It's not critical but thought I would report it.
How to reproduce
- Have blinds device with state position set to 254
- Add blinds to exported devices in the HomeKit Integration app
What device is this and, most importantly, what driver are you using? Additionally, what do you see under "Current States" on the device detail page/flyout when this happens? 254 is not a valid position or level value for the standard capabilities on the hub, so that shouldn't happen and could explain why HomeKit is choking if your driver happens to be passing that along as-is (there are other ways the driver could convey this information).
Official Shelly Wave Shutter. As I said, 254 is the correct value in terms of Z-Wave protocol if the module does not know the position.
By "official," do you mean a built-in driver (provided by Hubitat) or a custom driver (provided by Shelley)? A link to the driver would be particular helpful in the latter case, as would an answer to the remaining question above.
Sure, but it is the job of the Hubitat driver to abstract protocol-specific information like this into standard Hubitat capabilities (so, for example, a user doesn't need to know that Z-Wave uses 0-99 for levels or Zigbee uses 0-254 or other protocols something different entirely; devices of various types can be easily used together in the same automations this way). Mostly, this means using the standard commands and attributes (and possible attribute values) that any "capabilities" the driver declares require. For a developer perspective on this, see: Driver Capability List | Hubitat Documentation. This is what I meant above:
This is correct, as you can verify with the above document. Specifically, 254 is not be a valid attribute value for position (as might come with a window shade/blind) on the hub. Per the capability spec, an "unknown" value for the windowShade attribute would probably be more appropriate.
In other words, if the driver is reporting 254 for position/level, it needs to be fixed (or switch to using a custom attribute to express this information), and an invalid value like this is likely what is causing problems for you in HomeKit. I am asking the question above because if a built-in driver is doing this for some reason, that driver can be fixed. A third-party driver would require the developer to do the same.
Thanks! I looked at the driver for this, and the next platform version (2.4.1, currently in beta) should have a fix. A value of 254 will report the "windowShade" attribute as "unknown" (rather than "open"), and the "position" event (otherwise reporting the raw number) will be skipped so it will only show the last known/good value. In turn, this should also make HomeKit happy.
1 Like
