Bosch Zigbee Motion PIR

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.

Still a lot of pains with these devices. Iā€™ve moved all my devices over from SmartThings and shut that hub off, so now I should have a pretty strong mesh (I have 21 zigbee devices). I have the sensors on the device handlers people were using with SmartThings, so I can try to debug whatā€™s happening.

For some reason my sensors are sending triplicate messages. When motion is detected I will get three active messages, and never an inactive message. Itā€™s happening with all 5 of my WP13 sensors. I never used these with SmartThings, I bought them just to use with this hub. I wanted a local solution I could use to trigger my Blue Iris cameras with. The batteries all report 100%.

Not sure what these messages are for. The device handler handles battery/temp/motion already:

dev:129 2018-04-27 17:14:43.871:debug description: catchall: 0104 0020 05 01 0040 00 B337 01 00 0000 00 01
dev:129 2018-04-27 17:14:33.885:debug description: catchall: 0104 0020 05 01 0040 00 B337 01 00 0000 00 01
dev:129 2018-04-27 17:14:23.902:debug description: catchall: 0104 0020 05 01 0040 00 B337 01 00 0000 00 01

Temperature changes: (Notice the timestamps)

dev:97 2018-04-27 17:17:55.821:debug description: read attr - raw: 20100504020A0000296E09, dni:                 2010, endpoint: 05, cluster: 0402, size: 0A, attrId: 0000, encoding: 29, value: 096E
dev:97 2018-04-27 17:17:45.901:debug description: read attr - raw: 20100504020A0000296E09, dni: 2010, endpoint: 05, cluster: 0402, size: 0A, attrId: 0000, encoding: 29, value: 096E
dev:97 2018-04-27 17:17:35.972:debug description: read attr - raw: 20100504020A0000296E09, dni: 2010, endpoint: 05, cluster: 0402, size: 0A, attrId: 0000, encoding: 29, value: 096E
dev:97 2018-04-27 17:12:27.242:debug description: read attr - raw: 20100504020A0000296E09, dni:     2010, endpoint: 05, cluster: 0402, size: 0A, attrId: 0000, encoding: 29, value: 096E
dev:97 2018-04-27 17:12:17.304:debug description: read attr - raw: 20100504020A0000296E09, dni: 2010, endpoint: 05, cluster: 0402, size: 0A, attrId: 0000, encoding: 29, value: 096E
dev:97 2018-04-27 17:12:07.380:debug description: read attr - raw: 20100504020A0000296E09, dni: 2010, endpoint: 05, cluster: 0402, size: 0A, attrId: 0000, encoding: 29, value: 096E

This is when motion is triggered: (Notice the timestamps)

dev:71 2018-04-27 17:21:48.495:debug description: zone status 0x0021 -- extended status 0x00
dev:71 2018-04-27 17:21:38.501:debug description: zone status 0x0021 -- extended status 0x00
dev:71 2018-04-27 17:21:28.518:debug description: zone status 0x0021 -- extended status 0x00

This can be indicitave of a weak mesh.
When you say you have a strong mesh, how many repeaters do you have paired?

When I added the sensors initially, I only had one zigbee bulb connected. Last night I added the rest of my devices to hubitat (15 zigbee smart bulbs, and 14 z-wave in-wall switches) I have 8 Osram Lightify BR30 bulbs, and 7 CREE Connected A19 bulbs. From my understanding, both of those products should act as repeaters. Now that I have added all these devices do I need to do anything to get the mesh to change its routing?

Some bulbs are not reliable repeaters, and the zwave switches only act as repeaters for zwave devices.

Thatā€™s a shame to hear about the bulbs (I knew z-wave devices wouldnā€™t repeater for zigbee). Iā€™ll remove and add these sensors back to the network and see if it improves any. I would hate to have to buy all new sensors!

You might just need to research ZigBee repeaters and buy a single plug in device that will boost your signal.

YMMV but Iā€™ve found the Zigbee Logging feature very helpful in troubleshooting mesh problems. I had issues pairing and keeping some motion and contact sensors connected (not Bosch). Looking at the Zigbee logs, those devices had terrible LQI values (90s-170s). Long story short, after re-pairing all my devices, with the Osram RGBW bulb that sits 5 feet from the hub disconnected, mesh is now solid (255 across the board) and everything is working as it should.

1 Like

I didnā€™t even notice that tab under Zigbee, I will give it a try, thanks!

Welp, it looks like my mesh is pretty weak. Iā€™ll invest in some repeaters.

Device Type LQI RSSI
PIR - Living Room #1 Bosch WP13 92 -91
PIR - Living Room #2 Bosch WP13 255 -63
PIR - Kitchen Bosch WP13 255 -53
PIR - Test (Next to hub) Bosch WP13 255 -48
PIR - Test (Outside next to pool) Bosch WP13 255 -80
Bulb - Living Room #1 Osram Lightify BR30 254 -77
Bulb - Living Room #2 Osram Lightify BR30 231 -79
Bulb - Living Room #3 Osram Lightify BR30 217 -85
Bulb - Living Room #4 Osram Lightify BR30 213 -88
Bulb - Living Room #5 Osram Lightify BR30 255 -78
Bulb - Living Room (Chandelier) #6 CREE Connected 30 -90
Bulb - Living Room (Chandelier) #7 CREE Connected 158 -89
Bulb - Living Room (Chandelier) #8 CREE Connected 227 -84
Bulb - Bedroom #1 CREE Connected 181 -89
Bulb - Bedroom #2 CREE Connected 101 -84
Bulb - Bedroom #3 CREE Connected 165 -84
Bulb - Bedroom #4 CREE Connected 215 -88
1 Like

Iā€™ll also add that when I rebuilt my network, I did it in steps. First, paired the sensors and made sure they had good connections in the logs. Second, paired all my Crees and watched their logs. Last, put the Osrams online. I didnā€™t see any sense in pairing everything only to find out later I had a bad hop somewhere. Good luck!

Thanks! I just unplugged my hub and Iā€™m going to let the zigbee mesh heal and see if that helps any.

Does anyone know if the SYLVANIA SMART+ ZigBee Indoor Smart Plug work well as a zigbee repeater? Iā€™ve seen some mixed comments on it, and the posts on the SmartThings forums arenā€™t really helpful.

Try an xbee maybe? It can be set as a zigbee repeater.

Looking into the xbee. I did get two of the Sylvania zigbee plugs and spread them out and shut the hub off for ~50 minutes. Looking at the zigbee log function I see some devices are a little better on RSSI, 80ā€™s -> 70ā€™s. LQI is still good on most devices but I still have these damn PIR sensors getting stuck on active. Even one that has been sitting less than 5 feet from my hub.

My hubitat hub is on (and has been) on channel 25. My 2.4ghz router is on channel 8, and there are no networks on channel 11, so I canā€™t imagine thereā€™s any interference there.

So just an update, I turned off my smart bulbs for an hour or so to let the sensors try to find a better route, and helped. I also moved my hub out of my network closet and I see better signal levels on my zigbee devices. All in all, I haven't had a single problem with these sensors for 2 days now.

I wonder if the zigbee radio used in SmartThings is stronger than what's in the stick used by hubitat?

Probably. You're dealing with both a zigbee and z-wave antenna in a usb stick enclosure, so it's less than ideal for an antenna. You can just move the stick (via usb extension cable) if you want to keep the hub in your closet.

This device is the bane of my HE existence

I have three of them and they work for an hour to a day then stop reporting motion and temperature they worked flawlessly with ST and when they work in HE they are FAST ... but they are not stable for me

I didn't have these sensors with ST, but with hubitat my sensors were doing the same thing until I moved my hub closer and turned off my zigbee bulbs for a while. I'm thinking the PIR sensors were trying to route through one of the bulbs and it just wasn't working out. They've been stable going on 2 weeks now.

I'm actually going to move my hub again, to an even more centrally located spot because I have a z-wave outdoor door sensor that won't stay connected, even though it is literally right next to a z-wave dimmer switch (also outside), and 6 feet from another z-wave dimmer switch indoors. These mesh networks can be pretty frustrating...

My zigbee bulbs (with 2 exceptions) are all connected to via Hue to avoid that issue and the hub is about 15' from the devices ... and I have repeaters (Iris Wall Outlets) within 5' of them ... I think there is something else odd going on with them.

From the Zigbee device page:

|B80A|00155F006C24FD46||||[id: 327, name: Second Floor Hall - Guest Room Motion, label: Second Floor Hall - Guest Room Motion, deviceNetworkId: B80A, hubId: 1, locationId: 1, deviceTypeId: 52, zigbeeId: 00155F006C24FD46]|Second Floor Hall - Guest Room Motion||
| --- | --- | --- | --- | --- | --- | --- | --- |
|511A|00155F00B44D0739||||[id: 328, name: Second Floor Hall - Master Bedroom Motion, label: Second Floor Hall - Master Bedroom Motion, deviceNetworkId: 511A, hubId: 1, locationId: 1, deviceTypeId: 52, zigbeeId: 00155F00B44D0739]|Second Floor Hall - Master Bedroom Motion|

In regards to the Zigbee Logs - I cant for the life of me get them to even produce a log - so HE still thinks they are attached - they are just black holed

Will try a reset with them for giggles but I think I may need to look for a replacement devices ... not sure which (yet) ... no other zigbee devices have an issue

Frustration? A bit :slight_smile:

I too have one stuck in active.
It seems that hitting the configure button got it unstuck, with this strange sequence:

dev:1102018-10-16 21:36:15.165:info epir_02 is inactive
dev:1102018-10-16 21:36:15.158:debug zone status: alarm1Set:false, alarm1: 0, tamperSet: false, tamper: 0
dev:1102018-10-16 21:36:15.156:debug raw: zone status 0x0020 -- extended status 0x00
dev:1102018-10-16 21:36:14.930:info epir_02 is active
dev:1102018-10-16 21:36:14.923:debug zone status: alarm1Set:true, alarm1: 1, tamperSet: false, tamper: 0
dev:1102018-10-16 21:36:14.920:debug raw: zone status 0x0021 -- extended status 0x00
dev:1102018-10-16 21:36:14.754:info epir_02 is inactive
dev:1102018-10-16 21:36:14.744:debug zone status: alarm1Set:false, alarm1: 0, tamperSet: false, tamper: 0
dev:1102018-10-16 21:36:14.742:debug raw: zone status 0x0020 -- extended status 0x00
dev:1102018-10-16 21:36:14.643:info epir_02 is active
dev:1102018-10-16 21:36:14.631:debug zone status: alarm1Set:true, alarm1: 1, tamperSet: false, tamper: 0
dev:1102018-10-16 21:36:14.626:debug raw: zone status 0x0021 -- extended status 0x00
dev:1102018-10-16 21:35:31.411:debug raw: catchall: 0104 0500 05 01 0040 00 29DA 00 00 0000 0B 01 0000
dev:1102018-10-16 21:35:31.323:debug raw: catchall: 0104 0500 05 01 0040 00 29DA 00 00 0000 04 01 00
dev:1102018-10-16 21:35:31.187:debug raw: catchall: 0104 0500 05 01 0040 00 29DA 00 00 0000 0B 01 0000
dev:1102018-10-16 21:35:30.856:debug raw: catchall: 0104 0500 05 01 0040 00 29DA 00 00 0000 04 01 00
dev:1102018-10-16 21:35:11.689:info epir_02 is inactive
dev:1102018-10-16 21:35:11.683:debug zone status: alarm1Set:false, alarm1: 0, tamperSet: false, tamper: 0
dev:1102018-10-16 21:35:11.681:debug raw: zone status 0x0020 -- extended status 0x00
dev:1102018-10-16 21:35:10.890:debug zone status: alarm1Set:true, alarm1: 1, tamperSet: false, tamper: 0
dev:1102018-10-16 21:35:10.886:debug raw: zone status 0x0021 -- extended status 0x00
dev:1102018-10-16 21:35:01.692:debug refresh called
dev:1102018-10-16 21:35:01.622:warn configure...

@mike.maxwell same device is stuck again, this time hitting configure doesn't help. the device is sending out temperature readings regularly.

I'm only seeing

    profileId:0x104, clusterId:0x20, sourceEndpoint:5, destinationEndpoint:1 , groupId:0, lastHopLqi:247, lastHopRssi:-89
    profileId:0x104, clusterId:0x402, sourceEndpoint:5, destinationEndpoint:1 , groupId:0, lastHopLqi:250, lastHopRssi:-90

    descMap: [raw:29DA0504020A0000296A07, dni:29DA, endpoint:05, cluster:0402, size:0A, attrId:0000, encoding:29, value:076A, clusterInt:1026, attrInt:0]

    raw: read attr - raw: 29DA0504020A0000296A07, dni: 29DA, endpoint: 05, cluster: 0402, size: 0A, attrId: 0000, encoding: 29, value: 076A

any idea?