Pretty sure I have one of those working. There was the rounded ones that were out briefly, those were “gen 1” and then the square ones, and now the oval ones. I haven’t had a single plug in outlet not work. I have about a dozen different ones, Zigbee and Z-Wave.
One other thing I’m trying to figure out… Whenever I open or close the sensor, it reports the new state correctly, then bounces to the opposite, then correct.
For ex:
contact changes to open
*reports open
*reports closed
*reports open
Tried a couple of different drivers (modified Lowe’s Iris for ex) with no luck.
Is this for just one sensor or all of them? I haven’t seen that behavior with mine. What’s the type and make of the sensor?
It’s the same SmartThings CentraLite 3321-S as above. Worked flawlessly with ST.
I only own 2 multipurpose sensors, the other (mailbox) will not be transferred until towards the end, as it’s the most important. I’m taking it slowly
Is the sensor routing through a Zigbee repeater? I have found (by experimenting) if I move a sensor that has been paired through a repeater to within marginal range of both the hub and repeater and activate it (without doing a 'heal' or giving it time to stabilize) I will see what appears to be echoes of the open/closed log messages from the repeater (sometimes two consecutive 'close' messages for a single open/close event (like: open open close open open close close). I suspect its a side effect of some dynamic routing happening. At least, this is my theory. I'm still trying to put together a coherent mental model of how Zigbee works (@JDRoberts taught me 99% of what I think I know) !
I've attached a screenshot log of three consecutive open/close events from a contact sensor that was paired through a repeater and moved closer to the hub (so it is in range of both). Notice there are duplicated open/close messages in the log (6 open messages, 5 close) for three ope/close events). Apparently one close message didn't make it to the repeater. This actually gives me confidence that Zigbee routing is working with this hub. I've never had good luck with relocating Zigbee stuff that have been paired in a SmartThings environment without major pain-- it just seems to remain dead until I pull batteries or shutdown the hub to do a heal, rather than dynamically re-routing itself like you would expect.
You might be onto something. I took a “leap of faith” and paired my mailbox sensor. In initial testing, it’s performing quite well. The Sensor that’s having problems is likely connected to the mesh in a couple of ways. I’ll investigate some more tonight. Including taking down the hub for 10-15 mins, seeing if that helps.
I just noticed the coincidence that you were working with a sensor for your mailbox as well… that’s the first thing I tried to get running on ST.
To force a heal and updated neighbor tables, leave the hub off power for at least 15 minutes while all the other zigbee devices remain on power. It can take a while for all the changes to propagate, so you may not see improvements until the next day.
@JDRoberts You are awesome! I tried doing the force update, no immediate result but hopefully tomorrow will be better.
I decided to pull the battery on the sensor for 10-15 minutes, then put it back in. It seems to work a little better.
What’s the secret for the multipurpose sensor? I’m trying to pair two of the new ones and they just keep flashing blue…
I’m also experiencing some oddities with this sensor. I was able to pair all 7 of mine without issue. Device settings show it identified as SmartSense Motion v4 which I believe is correct.
I get states for acceleration/battery/temperature/xy. But I don’t get any state for contact at all. I’ve tried the non v4 and generic zigbee contact driver with no luck. Any recommendations?
Thanks!
They can take a VERY long time to discover (2 to 3 mins)
That’s the oddest thing. With Home Assistant, same nortek usb stick it’s immediately found and added. Hmm…
I have a few SmartThings SmartSense Multisensor’s as well. It is correctly reporting “Contact” and “Status” which are both either open or closed; however I’m not getting the expected acceleration, temp ,etc.
When paired, they paired as a SmartThings Presence sensor.
I’ve tried with both the SmartSense Multi Sensor V4 and non-v4 drivers. V4 doesn’t report the contact/status values. The non-v4 driver does but nothing else.
Hopefully this information will help create/adjust a driver:
- endpointId: 01
- application: 04
- model: PGC313
- manufacturer: SmartThings
If I set it to V4, I get the following logs:
Tapping on it (causing and ending acceleration):
18:56:36.514:debugparse: listResult []
18:56:36.510:debugdescMap.cluster: null
18:56:36.504:debugparse: catchall: FC01 FC03 02 02 0040 00 473F 01 01 0A11 07 01 B8005C
18:56:33.604:debugparse: listResult []
18:56:33.601:debugdescMap.cluster: null
18:56:33.596:debugparse: catchall: FC01 FC03 02 02 0040 00 473F 01 01 0A11 05 01 01001BFCF5FF
18:56:30.700:debugparse: listResult []
18:56:30.696:debugdescMap.cluster: null
18:56:30.691:debugparse: catchall: FC01 FC03 02 02 0040 00 473F 01 01 0A11 05 01 01001CFCF6FF
18:56:27.811:debugparse: listResult []
18:56:27.809:debugdescMap.cluster: null
18:56:27.805:debugparse: catchall: FC01 FC03 02 02 0040 00 473F 01 01 0A11 05 01 02001CFCF6FF
18:56:24.895:debugparse: listResult []
18:56:24.893:debugparse: listResult []
18:56:24.889:debugdescMap.cluster: null
18:56:24.886:debugdescMap.cluster: null
18:56:24.883:debugparse: catchall: FC01 FC03 02 02 0040 00 473F 01 01 0A11 00 01
18:56:24.880:debugparse: catchall: FC01 FC03 02 02 0040 00 473F 01 01 0A11 07 01 B8005C
Opening the door, I get the following logs:
19:02:52.666:debugparse: listResult []
19:02:52.662:debugdescMap.cluster: null
19:02:52.658:debugparse: catchall: FC01 FC03 02 02 0040 00 473F 01 01 0A11 07 01 B8005E
19:02:49.755:debugparse: listResult []
19:02:49.750:debugdescMap.cluster: null
19:02:49.746:debugparse: catchall: FC01 FC03 02 02 0040 00 473F 01 01 0A11 05 01 FCFF1CFCFAFF
19:02:46.841:debugparse: listResult []
19:02:46.838:debugdescMap.cluster: null
19:02:46.834:debugparse: catchall: FC01 FC03 02 02 0040 00 473F 01 01 0A11 05 01 FAFF1BFC0000
19:02:43.934:debugparse: listResult []
19:02:43.931:debugdescMap.cluster: null
19:02:43.927:debugparse: catchall: FC01 FC03 02 02 0040 00 473F 01 01 0A11 05 01 BEFF1BFCE6FF
19:02:42.374:debugparse: listResult []
19:02:42.368:debugparse: zone status 0x0031 -- extended status 0x00
19:02:41.024:debugparse: listResult []
19:02:41.021:debugdescMap.cluster: null
19:02:41.017:debugparse: catchall: FC01 FC03 02 02 0040 00 473F 01 01 0A11 00 01
Closing the door, I get the following logs:
19:04:22.314:debugparse: listResult []
19:04:22.311:debugdescMap.cluster: null
19:04:22.307:debugparse: catchall: FC01 FC03 02 02 0040 00 473F 01 01 0A11 07 01 B8005C
19:04:19.402:debugparse: listResult []
19:04:19.399:debugdescMap.cluster: null
19:04:19.394:debugparse: catchall: FC01 FC03 02 02 0040 00 473F 01 01 0A11 05 01 01001BFCF5FF
19:04:16.498:debugparse: listResult []
19:04:16.495:debugdescMap.cluster: null
19:04:16.487:debugparse: catchall: FC01 FC03 02 02 0040 00 473F 01 01 0A11 05 01 01001BFCF6FF
19:04:13.573:debugparse: listResult []
19:04:13.571:debugdescMap.cluster: null
19:04:13.568:debugparse: catchall: FC01 FC03 02 02 0040 00 473F 01 01 0A11 05 01 FFFF1CFCFCFF
19:04:12.852:debugparse: listResult []
19:04:12.848:debugparse: zone status 0x0030 -- extended status 0x00
19:04:10.665:debugparse: listResult []
19:04:10.663:debugdescMap.cluster: null
19:04:10.660:debugparse: catchall: FC01 FC03 02 02 0040 00 473F 01 01 0A11 00 01
I just finished the driver for this device a few days ago, and yeah, it’s a special child…
It will be in the next build.
haha that’s funny. With the two I was testing with today, I had all values EXCEPT the contact status.
The driver I built is specific to the PGC313, I would be surprised if it worked with anything else.