Now I have four of them stuck on active. I put debug logging on for all of them and Iāve been playing around. When I trigger one of them, messages do come through every time:
[dev:70](http://xxxx/logs#dev70)2018-04-21 12:49:01.765:debugzone status: alarm1Set:true,
alarm1: 1, tamperSet: false, tamper: 0
[dev:70](http://xxxx/logs#dev70)2018-04-21 12:49:01.763:debugraw: zone status 0x0021 --
extended status 0x00
I donāt think it has anything to do with the mesh strength, as all 5 of my units are sending battery and temperature updates. I have two units on my desk here that are less than 4 feet from my hub, and one of them just got stuck on active.
I have one unit that isnāt stuck (also sitting on my desk), and when it triggers, the messages look like this:
[dev:129](http://xxxx/logs#dev129)2018-04-21 12:53:19.781:infoPIR - Unused 2 Red is inactive
[dev:129](http://xxxx/logs#dev129)2018-04-21 12:53:19.769:debugzone status: alarm1Set:false,
alarm1: 0, tamperSet: false, tamper: 0
[dev:129](http://xxxx/logs#dev129)2018-04-21 12:53:19.767:debugraw: zone status 0x0020 --
extended status 0x00
[dev:129](http://xxxx/logs#dev129)2018-04-21 12:53:15.701:infoPIR - Unused 2 Red is active
[dev:129](http://xxxx/logs#dev129)2018-04-21 12:53:15.689:debugzone status: alarm1Set:true,
alarm1: 1, tamperSet: false, tamper: 0
[dev:129](http://xxxx/logs#dev129)2018-04-21 12:53:15.687:debugraw: zone status 0x0021 --
extended status 0x00
So after the active message comes through, the inactive message comes through a few seconds later. It seems for whatever reason the other units arenāt repeating this behavior and theyāre not sending an inactive message. It would sort of be a hacky fix, but since we know these devices go inactive 3 seconds afterwards and then wait 3 minutes to trigger active again, couldnāt we add the logic to set them back to inactive? Iām using the default device handler for these.
edit: It looks like all 5 of my sensors are sending messages every 10 seconds with alarm1 triggered. Itās never not triggered.