Update of some smoke sensors

[mattreim]

Some improvements to the DDFs.

• Product name adjusted
• Increased intervals
• Add bindings

[github-actions]

Hey @mattreim, thanks for your pull request!

Tip

Modified bundles can be downloaded here.

DDB changes

Modified

• nous/nous_e8_smoke_sensor.json : Smoke sensor E8 ✔️

• tuya/_TZE200_dq1mfjug_smoke_sensor.json : Smoke sensor (TS0601) ✔️

• heiman/hs1sa_smoke_sensor.json : Smoke sensor (HS1SA) ✔️

• orvibo/sf21_smoke_sensor.json : Smoke detector (SF21) ✔️

• schwaiger/zhs20_smoke_detector.json : Smoke detector (ZHS20) ✔️

• woox/woox_r7049_smart_smoke_alarm.json : Smart smoke alarm (R7049) ✔️

• bosch/bsd-2-smoke-alarm.json : Smoke alarm II (BSD-2) ✔️

• multir/mir-sm100-e_smoke_sensor.json : Smoke sensor (MIR-SM100-E) ✔️

• nedis/nedis_zbds10wt.json : Smoke sensor (ZBDS10WT) ✔️

• tuya/_TZE200_TS0601_smoke_detector.json : Photoelectric smoke sensor (TS0601) ✔️

• develco/heszb-120_heat_detector.json : Intelligent heat alarm (HESZB-120) ✔️

• frient/smszb-120_smoke_detector.json : Intelligent smoke alarm (SMSZB-120) ✔️

Validation

Tip

Everything is fine !

_{🕑 Updated for commit d300e16}

[ebaauw]

I think these sensors are all sleepers

Yes all these devices (I assume) have Receiver on when idle set to false, but I think most of them poll their parent at shorter intervals than 7s (the time the parent retains messages for the child). Effectively, these “light sleeper” devices are reachable all the time, and the logic to check whether they’re awake isn’t needed. So in the DDF, sleeper needs to be false.

[mattreim]

These devices have not been modified and they all have sleeper true. Should they remain as they are or be adjusted?

• bsd-2-smoke-alarm.json‎
• hs1sa_smoke_sensor.json
• sf21_smoke_sensor.json
• zhs20_smoke_detector.json

[ebaauw]

The correct setting for sleeper really depends on the polling interval of the device. Some devices implement Poll Control, so you can configure this yourself. For other devices, it's hard coded. I would hope the people that created these DDFs did check in the deCONZ log and/or sniffer how often these devices poll. I would leave the settings as is.

I only have the Develco smoke detector, for which sleeper: false is the valid setting. I suspect the same holds for the frient smoke detector (which is an OEM clone of the Develco) and for the Develco heat sensor (which, I think, has the same firmware as the smoke detector).

I have no idea about the other devices. I would expect sensors that have a Zigbee controllable siren (the IAS_WD cluster) to be light sleepers, or you wouldn't be able to activate the siren. Then again, your mileage may vary.

[manup]

For additional info, the "awake" = true can really be just set correctly when looking in the sniffer if the device does an actual MAC Data Poll after sending the respective command for which awake is set to true. This is often the case but not always, for example Xiaomi is famous for sending reports but don't listen for responses afterwards (except for the hourly report).

Unfortunately this can't be detected easily if the device isn't connected with the coordinator as direct parent, since the coordinator doesn't see the MAC Data Poll requests from end devices to their parent's.

[manup]

@mattreim thanks for looking into this, can you please factor out the `devices/trust/ZSDR-850_smoke_sensor.json into a separate device request PR, it becomes a bit overwhelming to have too many thing in one PR ;)

I'm not sure about setting sleeper = false, for some of the devices. Note that this can cause endless polling which goes into the void. If the sleeper true doesn't cause issues I'd keep it that way. The only real way to be sure is to check respective devices in the sniffer. To detect if a end-device is a "light sleeper" we can observe in the sniffer that they continuously send MAC Data Poll request to their parents with < ~7.5 seconds (this is the case for Hue end-devices). If they don't do this we can't send packets to these until we know that they are awake after they send a report / command and also do a MAC Data Poll afterwards. In this case sleeper should be true and respective commands marked with "awake" = true.

Right now this is rather tedious to figure out per device, guess we need better tooling to gather this stuff automatically.

[mattreim]

I have removed the ZSDR-850 and will create a separate PR.

[mattreim]

@manup I've now reset it back to sleeper = true in the hope that this isn't related to the issue #8521. Sleeper detection in deCONZ would be a huge advantage for me to avoid errors and ensure optimal device communication.

[SwoopX]

Erik is indeed right about the Develco/Frient smoke and heat detector, they're both light sleepers and happily answer any request with the to be expected slight delay. I should still have the Schwaiger lying around here somewhere and if I find it + don't forget, I could surely quickly check it.

Just out of curiosity: what's wrong with the min battery reporting interval of 300 secs? Personally, I'd like to have a change report better sooner than later but if nothing changes, waiting a while is totally fine 🤷‍♂️

[mattreim]

Here are two examples of why a five-minute interval doesn't really make sense. First, the battery consumption of my Tuya thermostat over one day.

Secondly, the battery consumption of my IKEA dimmer switch over two weeks.

They aren't really measuring devices, and I think twelve requests per day are perfectly sufficient. Furthermore, in networks with many battery-powered devices, communication can be reduced somewhat.

Both have a minimum reporting interval of 300 seconds; is the information more accurate?

[SwoopX]

I see, makes sense to me. I have to admit, I never paid too close attention about the jumps in the battery values here.