[OBSOLETE] Strips Drip / Strips Comfort

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.

Add this below line 40:

capability "Relative Humidity Measurement"

Add this below line 640:

eventMaps += createEventMaps("humidity", val, "%", false, false)

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.

1 Like

@krlaframboise, Thnx for this dh! Can you add functionality for editing parameter 10 and 11? it would be very 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’ve made the changes, but I haven’t tested them so I’m going to PM you the code.
If everything works OK let me know and I’ll release the new version.

1 Like

Hello @krlaframboise

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:

  1. 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?
  2. 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.

Thanks again for all your work!

/Jonathan Bjarnason

1 Like

I’m going to respond in a PM…

New DTH for each device

I just released a dedicated DTH for each device so that you don’t have to mess with the VID to get it to display correctly in the new mobile app.

I also added some of the missing configuration parameters and changed some default values and wake up interval to preserve the battery life.

Let me know if you run into any issues.

1 Like

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?

The device checks in every 24 hours.

The checkinterval means SmartThings will mark it as offline if it fails to check in within 48 hours.

1 Like

Thanks Kevin! That’ll work out fine I think.

@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?

Were they the original model or the new 700 series?

Hello S.F.B.,

We are in the process of creating a new DTH for Strips Comfort 700 in collaboration with @krlaframboise.

Could you please get in touch with us using the following link, for us to understand the challenges you faced.

7350088520086 is the EAN. If it is a 700-series? Don’t know.

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.

I won’t be converting the Strips Drip / Strips Comfort DTH into an Edge Driver, but the device should be functional with the built-in driver.