Sorry I have already thrown them away except this last one which still seems to be working even it does not look that good anymore.
I tried pairing it once more, but again it shows as Z-Wave Device even it is close to the hub now. I have spent hours trying to get this one paired…I almost felt happy it going to pieces yesterday…
I’ve a few Sensative Strips Comforts at 2 locations/hubs, 2015 and 2018 respectively, all updated and using the stock Edge Z-Wave Sensor drivers.
However the strips are NOT adding as “Comforts”, i. e.
thermometers, but as light sensors or leak sensors.
It is inconsistent and plainly in error. Is it possible to update the driver?
Hi S.F.B,
This is regarding the 500-series version of Strips, SmartThings uses the stock Edge driver for these units. Unfortunately, this is out of our hands.
Best regards,
Sensative support
Hey @Alwas, if you still want old dead 500 Series Sensative strips, I have a house full of them.
I loved the concept and they fitted our windows perfectly, albeit fiddly to get the magnets close enough in the right position. I tried a few and then spent £800 ($1000) to kit out every downstairs window and door, 19 in total, with some great automations about windows left open etc. Sadly none survived long enough to get to use the new Edge driver. Battery life was between 2 and 4.5 years on all of them, including some windows that are never opened, which was disappointing to say the least. Great whilst they lasted but they just didn’t last long enough to justify the cost and whilst part of me would love to try some of the new 700 Series Strips, I just don’t have enough confidence in the battery life unless someone else has comments to offer on that. @Sensative perhaps?
Hi,
Strips will last up to 10 years when properly mounted and sending a normal amount of data. To increase the longevity of your device, please consider the follow:
* Mount Strips on a non-metal surface at a distance which is not too far from the gateway or/and repeaters/extenders.
If you are able to change the wake-up interval in your gateway app, then set it to 12 hours or more.
Use the default configurations.
Keep your Z-Wave network healthy by performing network healing or network repair on your gateway when changes are introduced.
I am running this driver and I am seeing regular infoChanged events in the logs. In the past, I have had poor battery life from these strips, so I would like to increase the reporting interval. Are these infoChanged events an issue, and how can I stretch out the reporting interval to 12-24+ hours?
2023-08-11T21:27:13.397629462+00:00 TRACE Sensative Strips Sensor Received event with handler device_lifecycle
2023-08-11T21:27:13.398954795+00:00 INFO Sensative Strips Sensor <ZwaveDevice: XXXXXX (Refrigerator)> received lifecycle event: infoChanged
2023-08-11T21:27:13.411642795+00:00 TRACE Sensative Strips Sensor <ZwaveDevice: XXXXXX (Refrigerator)> received unhandled lifecycle event: infoChanged
2023-08-11T21:27:13.413004129+00:00 DEBUG Sensative Strips Sensor Refrigerator device thread event handled
Hello @blueyetisoftware,
By default the Wake-Up Interval set is 12 hours for the 700 series Strips. The above log shows just one session.
Currently, there is no setting within the driver, that affects the Wake-Up Interval.
Let me bring this back to my team.
Best regards,
Sensative support
I wonder if this inconsistency issue could be added to the backlog @nayelyz ?
Correct. I didn’t grab the entire sequence, but I was seeing these a couple times per hour. This is just an event in the driver, so I don’t know if it actually wakes up the device. In any case, these regular events seemed odd to me.
Hi, @S.F.B
So, your report is only about the categories assigned to the devices as mentioned here?
I checked the Z-Wave sensor driver and I see it includes the capabilities for waterSensor, illuminanceMeasurement, temperatureMeasurement and battery. Are they correct? I saw this is a multi-sensor device here
Which category/icon did they use before? I don’t see a category called “comfort”
Also, in the old DTH, it is also called a water leak sensor and had assigned a moisture icon: https://github.com/SmartThingsCommunity/SmartThingsPublic/blob/master/devicetypes/smartthings/zwave-water-temp-light-sensor.src/zwave-water-temp-light-sensor.groovy
Could you please let us know which Strips 700 series product those shared log items were belonging to?
Also, could you please share more logs for us to understand what would have been going on, using the following support link.
Please add “(For Dhiraj Paryani)” in the subject, so that I get assigned the ticket.
Thank you!
Regards,
Sensative support
I’m no longer seeing it. I have been streaming the logs all day, and I’m only seeing the 12 hour wakeup for battery status. The infoChanged events were happening a few times per hour after the devices were first added. They haven’t showed up all day.
A “somewhat” late reply; as these sensors are located far away and in hard-to-get-to-positions.
Yes.
“Comfort” is the product type name as in
" Strips Comfort is a very accurate temperature and ambient light sensor. The unique design and mounting plate makes it easy to place almost invisibly in your home to measure temperature or control heating, air conditioning and even windows blinds which are connected to your Z-Wave smart home system." (as seen here )
Before, pre Edge, they added with icons for temperature measurement; i.e. with the “Thermometer” icons.
At the moment, it looks like this
in location 1, on a V2 hub, using a “moisture icon”:
in location 2, on a V3 hub, using an “illuminance” icon:
So, as mentioned above, not exactly consistent between product instances, nor, I would say, according to product description.
Does the page not show a field called “Model”? I don’t see it in your screenshots.
In SmartThings, the device’s “fingerprint” is the combination of the exact manufacturer code, and the exact model.
If those two are different, it might explain why they had different profiles in the driver. 
The device on the v2 hub is using the water-illuminance-temperature profile and the one on the v3 is using the illuminance-temperature profile. While the manufacturer’s code is the same on both devices, I’d be curious what the model name/number is. There is clearly a difference between the two devices that causes a different profile to be selected and is likely the reason for the different icon being selected. Also notice that the device name for the one on the v2 is the profile name vs the one on the v3 being a more specific device name.
They are both having model number 0003-000A, curiously enough…
Identical model numbers. And assigned to different device names, the v3 name corresponding well with the product (commercial) name.
Hi @S.F.B
In the Zwave Sensor driver, this device can have two different profiles and depends on the value of parameter 12 of the device.
by default it will be assigned water-illuminance-temperature profile
Then, if parameter 12 has a value = 0 then the profile SENSATIVE_COMFORT_PROFILE = illuminance-temperature is reassigned.
Therefore you can use the zwave device config Mc driver and set the value of parameter 12 to the value 0 or 1, according to your needs.
local SENSATIVE_MFR = 0x019A
local SENSATIVE_MODEL = 0x000A
local LEAKAGE_ALARM_PARAM = 12
local LEAKAGE_ALARM_OFF = 0
local SENSATIVE_COMFORT_PROFILE = "illuminance-temperature"
local CONFIG_REPORT_RECEIVED = "configReportReceived"
local function can_handle_sensative_strip(opts, driver, device, cmd, ...)
return device:id_match(SENSATIVE_MFR, nil, SENSATIVE_MODEL)
end
local function configuration_report(driver, device, cmd)
local parameter_number = cmd.args.parameter_number
local configuration_value = cmd.args.configuration_value
if parameter_number == LEAKAGE_ALARM_PARAM then
device:set_field(CONFIG_REPORT_RECEIVED, true, {persist = true})
if configuration_value == LEAKAGE_ALARM_OFF then
device:try_update_metadata({profile = SENSATIVE_COMFORT_PROFILE})
end
end
end
After changing parameter 12 to the desired value and you need the prifile illuminance- temperature then you have to exclude the device and include it again since the reading of parameter 12 is done in the doConfigure life cycle, which is executed when the device is paired
local function do_configure(driver, device)
device:refresh()
device:send(Configuration:Get({ parameter_number = LEAKAGE_ALARM_PARAM }))
end
It would be interesting to see if he can reassign the profile using the Edge Device Builder without having to change the parameter and exclude/include the device.
I was curious, too. So I tried.
Using the Edge Device Builder I managed to change the profile from “water-…” to "illuminance -…
This is absolutely great! Being able to" change" the function of a device remotely (no physical contact) is very useful.
If only the icon and the tile reading could be tailored, too, e. g. in this case to °C instead of Lux. In a multisensor device like this one I would think that should be standard fare.
But I guess that is for further study?
And, what if alternative profiles used by community developed drivers could be selected in the same fashion as those used by stock drivers…