Bosch Radion TriTech false alerts

Have 3 Bosch Radion TriTech motion detectors interfaced with HomeSeer via deConz/ConBeeII/Phoscon and the JowiHue plugin. All are registering true motion correctly; however, they are also throwing false motion alerts at very regular intervals (sometimes 30 minutes, sometimes 60). The plugin author looked at my logs and said deConz or the device itself is sending the false motion alert, but all 3 of the devices are doing this consistently.

Any ideas of what is causing this or ways to troubleshoot further? Same sample log exerts below.

21:53:50.2414392 – (WebCommander.HandleWebQueue) Dequeue command: json {“e”:“changed”,“id”:“27”,“r”:“sensors”,“state”:{“lastupdated”:“2022-05-17T02:53:50.239”,“lowbattery”:false,“presence”:true,“tampered”:false},“t”:“event”,“uniqueid”:“00:0d:6f:00:11:de:15:6e-01-0500”} new queue size is 0 on 00212E075D38

21:54:56.8365773 – (WebCommander.HandleWebQueue) Dequeue command: json {“e”:“changed”,“id”:“27”,“r”:“sensors”,“state”:{“lastupdated”:“2022-05-17T02:54:56.834”,“lowbattery”:false,“presence”:false,“tampered”:false},“t”:“event”,“uniqueid”:“00:0d:6f:00:11:de:15:6e-01-0500”} new queue size is 0 on 00212E075D38

22:54:10.5254700 – (WebCommander.HandleWebQueue) Dequeue command: json {“e”:“changed”,“id”:“27”,“r”:“sensors”,“state”:{“lastupdated”:“2022-05-17T03:54:10.524”,“lowbattery”:false,“presence”:true,“tampered”:false},“t”:“event”,“uniqueid”:“00:0d:6f:00:11:de:15:6e-01-0500”} new queue size is 0 on 00212E075D38

22:55:10.8131146 – (WebCommander.HandleWebQueue) Dequeue command: json {“e”:“changed”,“id”:“27”,“r”:“sensors”,“state”:{“lastupdated”:“2022-05-17T03:55:10.811”,“lowbattery”:false,“presence”:false,“tampered”:false},“t”:“event”,“uniqueid”:“00:0d:6f:00:11:de:15:6e-01-0500”} new queue size is 0 on 00212E075D38

23:24:17.5869875 – (WebCommander.HandleWebQueue) Dequeue command: json {“attr”:{“id”:“27”,“lastannounced”:null,“lastseen”:“2022-05-17T04:24Z”,“manufacturername”:“BOSCH”,“modelid”:“RFDL-ZB-MS”,“name”:“Presence 27 Motion”,“swversion”:null,“type”:“ZHAPresence”,“uniqueid”:“00:0d:6f:00:11:de:15:6e-01-0500”},“e”:“changed”,“id”:“27”,“r”:“sensors”,“t”:“event”,“uniqueid”:“00:0d:6f:00:11:de:15:6e-01-0500”} new queue size is 0 on 00212E075D38

00:24:32.0811225 – (WebCommander.HandleWebQueue) Dequeue command: json {“attr”:{“id”:“27”,“lastannounced”:null,“lastseen”:“2022-05-17T05:24Z”,“manufacturername”:“BOSCH”,“modelid”:“RFDL-ZB-MS”,“name”:“Presence 27 Motion”,“swversion”:null,“type”:“ZHAPresence”,“uniqueid”:“00:0d:6f:00:11:de:15:6e-01-0500”},“e”:“changed”,“id”:“27”,“r”:“sensors”,“t”:“event”,“uniqueid”:“00:0d:6f:00:11:de:15:6e-01-0500”} new queue size is 0 on 00212E075D38

00:24:32.0811225 – (WebCommander.HandleWebQueue) Dequeue command: json {“e”:“changed”,“id”:“27”,“r”:“sensors”,“state”:{“lastupdated”:“2022-05-17T05:24:32.079”,“lowbattery”:false,“presence”:true,“tampered”:false},“t”:“event”,“uniqueid”:“00:0d:6f:00:11:de:15:6e-01-0500”} new queue size is 0 on 00212E075D38

00:25:32.2309475 – (WebCommander.HandleWebQueue) Dequeue command: json {“e”:“changed”,“id”:“27”,“r”:“sensors”,“state”:{“lastupdated”:“2022-05-17T05:25:32.228”,“lowbattery”:false,“presence”:false,“tampered”:false},“t”:“event”,“uniqueid”:“00:0d:6f:00:11:de:15:6e-01-0500”} new queue size is 0 on 00212E075D38

00:54:39.0148296 – (WebCommander.HandleWebQueue) Dequeue command: json {“e”:“changed”,“id”:“27”,“r”:“sensors”,“state”:{“lastupdated”:“2022-05-17T05:54:39.012”,“lowbattery”:false,“presence”:true,“tampered”:false},“t”:“event”,“uniqueid”:“00:0d:6f:00:11:de:15:6e-01-0500”} new queue size is 0 on 00212E075D38

00:55:39.2323572 – (WebCommander.HandleWebQueue) Dequeue command: json {“e”:“changed”,“id”:“27”,“r”:“sensors”,“state”:{“lastupdated”:“2022-05-17T05:55:39.230”,“lowbattery”:false,“presence”:false,“tampered”:false},“t”:“event”,“uniqueid”:“00:0d:6f:00:11:de:15:6e-01-0500”} new queue size is 0 on 00212E075D38

To add to this issue, the motion sensor tested here was placed in a way that it could not be triggered by anything. So why is this update send by deCONZ?

You mean to deconz? Not sure.

As far as I can tell, the device sends that to deconz or something is odd in the handler. Nevertheless @de_employees should be able to figure it out.

This can only be judged by a full log containing APS_L2 and INFO_L2 debug levels as they show what truly has been sent from the device. Be aware that this is extremely noisy. However, an excerpt containing 10 seconds around the “ghost” event should suffice for an initial analysis.

Below are some log excerpts from 2 consecutive false alerts, including some lines before and some after. I also included the motion detector resetting to “presence”:false 1 minute after the motion, presumably that’s the timeout. I compared the false alerts in the log to a real alert I triggered and they couldn’t pick up any differences. I guess I just thought it seemed software-related as it is so regular. Thank you for your help.

Can you please put it in Pastebin?

Edited the above post using pastebin. Sorry, I didn’t know/read the etiquette before posting. Hopefully I did that correctly now.

1 Like

Thanks for sharing the logs. Not exactly what I expected, but sufficient as it contains data of interest.

We see such lines:
20:22:48:055 [INFO] - No button map for: RFDL-ZB-MS, unicast to: 0x0000, endpoint: 0x01, cluster: IAS_ZONE (0x0500), command: STATUS_CHANGE (0x00), payload: 21000064B37A, zclSeq: 71

The first two Bytes are the IAS Zone status reported by the device, in this case 0021 (order needs to be reversed). The Bit representation is 00000000 00100001. To better understand the meaning, see below screenshot:

grafik

In your case, the right-most Bit is 1, translating to Alarm1 = true, indicating presence. So it appears the device is reporting wrongly.

Thanks so much Swoop, I was afraid it may be the device. I bought 3 of these for my HomeSeer system, and all of them are doing the same thing. Was looking for Zigbee devices with a short cool-down period that were compatible with deConz, but I’ll look to another brand. I know others online have mentioned using this specific sensor, but the false alerts are a deal-breaker. Thanks again.