Yeah I'm testing on both ST and HE now. Looks like we both made similar ST versions!
Not sure, I didn't add debugging to the SmartSense driver to figure it out. Once I got my own driver working my curiosity level (and time) fell dramatically. 
Funny :). I know exactly how you feel. Thank you for doing the dirty work, I was about to embark on it last night but found out that you had already taken the plunge. If you're ever in the Seattle area, hit me up and I will buy you a beer/coffee (assuming I see your message).
1 Like
These sensors are on sale right now Amazon. $14 for one, $44 for a 4 pack. Be sure to clip the coupon):
PIR sensors are $15 (clip the $3 off coupon) at the same link.
3 Likes
Oddly, I'm interested in this device's siren. Can I control the siren directly from the hubitat, as in some other trigger event makes the siren sound off? Or is it directly tied to the water sensor?
So the answer is .... maybe? The generic zigbee driver does not expose the capability. For giggles I tried an old community "Generic Zigbee Alarm" driver and got the alarm to trigger some how - not exactly sure what I did because I could not reliably reproduce.
Since I was actually able to trigger the alarm it seems like there is the possibility for this to work..
2 Likes
I'll see if I can add support for the alarm to my driver.
4 Likes
Looking back thru my notes, I don't think the device's alarm status will be able to be triggered as an external event for a few reasons:
- The device does a long poll of every 5 minutes to save on battery power. The Zigbee standard for long poll frequency is ~7 seconds, after which the "you have a message" flag on the upstream powered coordinator will time out. So by the time the device wakes up and long polls to see if it has anything pending, the "you have data pending" packet will have timed out. My guess is @erktrek was able to trigger the alarm because the event + wake up happened to occur within this 7 second window. (or maybe your hands were just moist while handling the device. )
- The device doesn't support the IAS 0x0502 cluster which is commonly used for alarm devices like sirens.
Theres a possibility that the device may allow you to set the long polling interval down to ~5 seconds (which seems to be the value most SEDs use that need this type of response - sirens, etc) but my notes imply that it will not allow any changes to its 5 minute long poll interval (cluster 0x0020, attribute 0x0001). If I have time later I'll try and set the long poll interval and see what it does.
1 Like
Thanks for looking into - figured that was the case. I may have hit something right as it was polling dunno. I triggered the alarm a few times but have no idea how it happened.
Yes, thanks for looking into it.
Just a word of caution if you decide to mess with the siren driver I linked to. I ended up having to reset my device and re-include it as it was not responding to wet/dry events. No biggie with Zigbee fortunately - just slotted back in with existing HE entry but now the battery reports 100% then reports 200%...
1 Like
A few minutes of debugging shows the following:
- Long polling is set to 1200 qtr seconds (5 minutes) by default reported by the device.
- Trying to write a new value to the long polling frequency (cluster 0x20, attribute 0x01) results in a ZCL_STATUS_READ_ONLY (0x88) error back from the device.
So I'm going to surmise using the siren for something else isn't feasible. I probably wouldn't want to anyway - I'd get an actual zwave/zigbee siren. Let the leak sensor do what its designed to do.
There may be a way to configure the siren itself to not go off when an alarm condition is detected, but that doesn't seem worth digging into to figure out.
I've never seen this with my Linkind driver. Note that mine also gets both voltage and % - I'm always curious how accurate the % curve is as reported from the devices.
2 Likes
This is after the driver switch testing. After I reset and re-included it seems to have settled down a bit. From yesterday:
The Wet/Dry was testing after I switched back. The device was still reporting 200% immediately after 100% but the last report only reported 100%. Will keep monitoring.
Is this with the built in driver [Zigbee moisture sensor - (no temperature) I think its called]? I believe some of those drivers get the battery V updates but convert them to percentage. So you get the device percent (likely the 100%) and then the V update converted to percent. Maybe turning on debug logging for that driver will indicate more info. I've not seen this behavior on my Linkind driver, but I do 1:1 events (battery % update generates a % event, battery V update generates a V event).
3 Likes
Yep it's the standard one but am planning on switching over to yours.
1 Like
Quick question for you owners - can the siren be disabled (without physically disconnecting it from the pcb)? Planning to get one for rain sensing so don't need it going off.
I don't believe the siren can be disabled completely. There is a "mute" function that I started to figure out - once the alarm is triggered the siren can be muted remotely for up to 10 minutes. I never got that far as it didn't seem important or needed.
I don't think I would use it for rain. You'd need the water to collect enough to trigger across the probes, but then evaporate once it was done raining. An actual rain sensor would work better. The Ecowitt rain sensor (thru a gateway) might be a good option.
Thanks. I think I'll just use one of those rain PCBs (already have them) and hook it up to a contact sensor. I already have the ecowitt system but not the rain gauge as it requires a certain amount of rain to collect (as I understand it). I want to use it as a reminder to bring in the laundry at the first sign of rain.
1 Like
I just got a 4 pack of these last week. They seem to be working fine, but they are not reporting back battery levels. They did when first connected, but haven't since. Anyone know how I can configure them to at least report in once a day or so just to make sure they're not dead?
It's been almost 2 days since I last tested it and it's still not periodically checking in. I have it configured as a Generic Zigbee Moisture Sensor (no temp).
What release are you running? Try upgrading to 2.3.4.138 (and then hit Configure on each of your Linkind water sensors).
A change in the release made yesterday says it fixes battery reporting for these devices:
- Generic Zigbee Moisture Sensor (no temp): Fix battery reporting/parsing error with linkind devices.
(Release 2.3.4 Available - #18 by gopher.ny)
If and only if that doesn't work, read on:
While I'm using 2.3.4.138, I've not yet switched back to the (no temp) driver. I'm using the previous workaround that's been necessary since 2.3.4.116, which is to switch to the Generic Zigbee Moisture Sensor driver. After that, explicitly turn off temperature reporting (it's the first preference). Save that change and then click Configure.
3 Likes
