Every application I’ve seen that mentions relative moisture is referring to humidity which this device doesn’t report.
This is the only water sensor I’ve ever seen that reports more than just wet/dry, but the only way I was able to get it to report a high percentage was by submerging it in water which killed the device because it’s not actually waterproof.
All that being said, if you add 2 lines of code you’ll be able to use the device like a humidity sensor to see the water percentage being reported by the device.
I’ve found the same thing regarding relative humidity. I am also testing some 4-20mA sensors with a MiMOlite but the Drip Strips “form factor” has been interesting enough to kick it’s tires as well.
Thanks for the follow up and code snippets - much appreciated.
@krlaframboise, would that be alot of work? My sunshading automation is dependent of setting param 10 and 11 (param 9 to 2), since the logarithmic reporting of lux just wont work for that purpose.
I’m a tester at Sensative AB. Thank you so much for creating this Device Handler! It has been a lifesaver for us since the default template for Strips Drips/Comfort doesn’t support leakage alarm functionality.
I have been in contact with @raja82 on our support channel regarding the lux-level implementation. We’ve both tested the code you sent to raja, lux level reporting is enabled and functioning as intended. Many thanks for the quick fix!
I have two comments though on the remaining functionality of the handler that i fear will cause Strips’ battery to drain early:
I note that “Water Reporting” is enabled by default. More specifically, this setting tells Strips to send a moisture report every hour, leading to 24 reports/day. This feature is useful when debugging Strips Drips (if leakage alarms aren’t getting triggered when expected), but for any other case it is a drain on the battery. Would it be possible to have this setting be disabled by default?
Strips’ wake up interval is set to 4200 seconds by default on inclusion. This issue seems to exist in the base template as well now, so perhaps it is a general SmartThings behavior? Do you know of any possible way of changing this wake up interval via Device Handler code?
Ideally we want Strips to use the maximum possible wake up interval of 24h. Wake ups are only really used to retrieve updates from the gateway which happens rarely, so there is little reason to use a low wake up interval.
Hi @krlaframboise (Kevin) - thanks for the great work on this app!
I just installed it tonight and saw that by default my ‘checkInterval’ value is set to 173100 s. This equates to almost exactly 48 hours.
Does this mean that the strip will ping the hub once every 48 hours to confirm that it’s alive? I have an app that alerts me when a device hasn’t checked in for 24 hours (see link below).
Just wondering if I can change this in the code somehow?
@krlaframboise@Sensative I was wondering if this is the ideal DTH for the new Comfort 700 devices? The interface looks the same but I haven’t studied it thoroughly. Since the devices are just hitting the market I assume it may not have been tested by the community but for sure has been tested by @Sensative.
I noticed that in the IDE the DTH list has an entry for Sensative Strips Guard 700 and Sensative Strips Drip 700 but of course nothing specific for Comfort 700. So far the Comfort 700 device seems to function with the DTH for the normal Comfort 500 from @krlaframboise with the exception of the new slider switch which causes an “Unhandled Command: CentralSceneNotification(sceneNumber: 1, keyAttributes: 0, reserved11: 16, sequenceNumber: XXX)” error.
Those built-in handlers were written by me so they’re fully functional and they’ve been thoroughly tested.
The Comfort 700 wasn’t ready at that time so I haven’t written a handler for it, but now that drivers are live the IDE will probably be retired soon so I’m not sure if I’ll be writing one for it.
@krlaframboise@Sensative
I just had to turn in 2 Comfort strips as they lasted for a few months (weeks) only. One of the replacements received lasted from mid november until the frist week of january. Previous strips have lasted 2,5 till about 3 years, from early 2018. Still far from 10, as promised. I’ve been using the stock DTH Z-wave temp/light sensor, as I wasnt aware of @krlaframboise’s DTH neither the official stock handler. I like the devices but worried, since it seems that there wont be one for Comfort, but Drip/Guard only.
If you guys will ensure continued sales and operation, maybe you should consider introducing a stock DTH for Comfort, please?
Hi @krlaframboise, thanks for the DTH, it works great! I am now playing with it for a new project, but I am inexperienced and would like to ask here if what I intend to do is possible, before I find myself in a dead end.
I will try to have the device report if it is “under sun” or “under shade”. To do this I will create a new attribute and add preferences to set the illumination limits between sun and shade. Then I will correlate the new attribute with the lighting to determine the state. So at this point everything is OK?
What I am not sure if it is possible to do is the following: I need the device to report every time the attribute changes between “under sun” and “under shade”, immediately after the change happens, not in a time interval. Is this possible?, can anyone guide me?
All other capabilities will stop reporting from “preferences”, to save battery.
The type of change you want to make isn’t as simple as adding an attribute because you’d need to also create a custom capability and a new device config.
If your goals are to save battery life and use under sun/shad as a trigger/condition in automations then you should be able to do that without modifying the handler.
The device only supports the reporting options exposed by the settings so there’s nothing you can do to the DTH that would make the device report less often.
If you set the “Ambient Light Reporting” setting to “Report Only When Selected High/Low Ambient Light Levels are Passed” then it should reduce the frequency that it reports the lux value when the light level crosses those thresholds.
Example, if your sun/shade cutoff is 5,000 lux then you can set the “Low Ambient Light Report Level” setting to 4,999 and the “High Ambient…” setting to 5,000 and I think the device will only send a report when the lux level crosses that threshold.
In automations you’d use above or below 5,000 as the trigger or condition.