Has anyone been able to get the leaksmart moister sensor to work. I have tried changing the device type multiple times with no success. Any help would be great.
I use and it works well.
Scott, thanks for the update but unfortunately that is for the valve. I have the valve up and functioning. I cannot get the water sensor to work. Do you use the water sensor?
ahh my apologies, no sorry I don’t use the leaksmart sensors.
I am also interested. My Kit came with one sensor. It was cheaper to buy the kit with installation than to pay just for the valve and installation separately.
Anyone else that was able to figure this one out?
Add my name to the list…
They were on a steep discount at my local HD and I sort of assumed that since the valve showed up in a quick search the sensor would have a device type. I picked up two for $18 each!
Both of them paired right away with an “unknown” device type but I don’t seem to see any data in the logs when they’re triggered. If anyone has any info on these I’d love to get them working.
Same here. I picked up 3 @ 18 each! I have the SmartSense Water Sensor device type currently assigned and am getting temp and battery values updated periodically, but the moisture alarm is not signaling Smartthings.
Same here. I hope someone builds a device handler for this pronto now that these are on a fire sale.
Same here picked up three of them at $18 each. They seem to be built well, but no go on sensing moisture!
I grabbed one also… I couldn’t get it to even be recognized by smartthings.
There is a button on the inside of the battery compartment you have to press to put the sensor in pairing mode, then smartthings will recognize it as a “Thing” when adding.
I tried that, I will give it another shot. My local Home Depot also has the 3/4" valve kit for $73. I am new to smartthings, can someone verify if the on/off function works with the samsung hub. I have been reading though the community posts and I am not very clear on it. Thanks
Someone already wrote a device handler for the valve, so you should be able to get the valve to work. As far as I know we still need someone to write a device handler for the sensor. I’m working on it, but I’ve never written one before so… Don’t hold your breath. Someone with some experience could probably make one in an hour or so.
Here is a link to the valve device handler thread.
interested in getting these sensors hooked up to ST as well… Bought a few earlier at $35 each… cant find any more at the $18 price…
Make sure you update the firmware through a Wink hub before using them with ST (they have a battery drain issue in the old code)
I’ve started as well. I used the SmartSense Water Sensor as a template, as it reports the temp change back to ST. The battery is reporting on refresh, although the code that calculates the percentage is off – new batteries will report “–” and show a message in the logs as the voltage is too high, probably due to differences in the batteries used in the devices. I’ve emailed leakSmart to see if I could get some technical docs for the sensor, no response yet. I am new to this as well, but from what I can see it will be subscribing to the proper cluster and parsing the correct data back. From the raw data after pairing I think I have the following as accurate:
fingerprint inClusters: "0000,0001,0003,0020,0402,0B02,FC02", outClusters: "0003,0019", manufacturer: "Waxman", model: "leakSmartv2", deviceJoinName: "LeakSmart Sensor"
Clusters 0B02 and/or FC02…
I think I resolved the battery issue just by tweaking the getBatteryResult function.
I just modified the function to calculate for 3 1.5 volt batteries I think it was calculating for 4 in the original code.
What I’m not getting is any indication of the actual “Dry” or “Not Dry” It may be because the fingerprint is not correct, or because I don’t know what I’m doing, or a combination of the 2.
Can anyone explain what the purpose of the “shouldProcessMessage” method is?
It looks like shouldProcessMessage() takes in a zigbee cluster and checks that the profileId is not 0x0104, or the command is either 0x0B or 0x07, or the data.size is larger than 0 and the first byte of that data is 0x3e. If any of those “OR” clauses are true it returns false, otherwise it returns true.
That probably made no sense, and it probably doesn’t matter for troubleshooting… yet.
I think that method is just filtering messages to see if the devicetype is really equipped to handle it.
If you tap into the code just before the if (shouldProcessMessage(cluster) statement and dump the cluster to the log you should be able to read out everything that is being taken in from the device. I’ll see if I can capture anything useful from that.