Motion Detectors with both 'delay' and 'duration' parameters set unintended delay value

[Monofin]

Hi there: Whilst testing out ZY-M100 sensor with Deconz 2.23.0 (not recommended version, sorry!), I've discovered the following quirk, it may be a DECONZ DDF use issue underlying - but the code here seems fragile:

When a unit with both delay and duration configuration items is present, then the line here causes the delay item to be chosen as the 'activation duration' parameter exposed to HomeKit, whilst on these devices the 'delay' config is actually the trigger time delay (target confirmation time).

This results in some unexpected behaviours when trying to set the 'fading time' of the device:

https://github.com/ebaauw/homebridge-deconz/blob/56dec002a88b83698e7e99cad76fbf78ed56dd65/lib/DeconzService/Motion.js#L18

Most of these devices have very odd behaviours (e.g. setting presence for exactly the fading time only, and not continuing even though there are targets still there!), so it may not be worth bothering to fix (!), but probably should be noted.

[ebaauw]

whilst on these devices the 'delay' config is actually the trigger time delay (target confirmation time)

I have no idea what you’re saying here.

config.duration is for devices that don’t send restore reports (don’t send a “no more motion detected”) message. There’s no corresponding Zigbee attribute for this item, as deCONZ handles resetting state.presence for these devices.

config.delay has two uses. For “decent” motion sensors (that do report “no more motion detected”), it maps to PIR Occupied to Unoccupied Delay, configuring the delay on the device, after which it sends the “no more motion”. For motion controllers (like the Trådfri), it’s read-only and reports the On Time parameter of the. On with Timed Off command that the controller sends.

It doesn’t make sense for a device to expose both.

[Monofin]

Thanks for the clarification: Looks like this is a Tuya + DECONZ + Inconsistent DDF + Bad behaviour issue.

I'll close the issue here, because it seems to be the result of a hack in DECONZ's recent DDFs:

This is how bad it is: The DDF for the device (not my coding!) exposes 'state/angle', 'state/presence' and both 'config/delay' and 'config/duration'.

This is nonsense - in three ways: state/angle: Is configured to actually report range to target from the Tuya Cluster config/delay configures the target detection time - i.e. the time till the device reports motion from the Tuya Cluster config/duration is set up to configure the 'fading time' of no motion before the device stops reporting from the Tuya Cluster - which seems to overlap with the DECONZ definition.

It's not the first time I've met this problem, with DDFs that expose complete nonsense which makes the homebridge interface behave badly.