Sensative Binary Sensor - False positive?

Hi there,

I have a sensative strip (binary, z-wave, door/window-contact, aeon zwvave stick) which recently began having false positives. So it get triggered and remains in the OPEN state, until I open and close the door manually.

In the openhab.log I see an entry on that specific moment: “NODE 3: Timeout while sending message. Requeueing - 2 attempts left!”

I do not want the sensor to be triggered when a message cannot be sent. Is this something on the sensor side, controller side or in openhab?

Or is it actually a true OPEN trigger because of the sensor being slightly out of place and is it just a coincidence that it has trouble sending that state to the controller?

Thank you in advance!

Is this reproducable? Or does it happen randomly and (maybe) seldom?

I am using the same combination and haven’t had any false positives. But if there are some strange log entries, you should provide a full debug log when this false positive happens.

Maybe chris can have a look and see if something is going wrong…

Thank you for your reply!

It happens seldom, not reproducible (those are the best). I will go and try to realign the contacts.
I’ve seen other logentries where there’s been a timeout and then there was no false positive. So I’m assuming it is on the contact side.

I happen to have the exact same problem as mentioned by Kerbje.
@Kerbje: did you managed to solve the issue?


After a short root cause analysis, the false positive happens to be triggered when the Sensative strip initiates the wakeup (which happens every 86400 seconds / 24 hours).
So it sounds like the wakeup notification does not properly get it through (timeout report in the log).

However, my devices (2 of them) are properly reporting to openHab the window status when I open/close it.

Hope it helps.

Hi @matsuo3rd,

No, I haven’t had the time to investigate this further. Very useful info you provide here!
I have been in touch with Sensative about this and they have been talking to OpenHAB about it.

I will provide them with this info and see if they can help us.

Thank you for jumping in!

Which version of the binding are you using? Can you provide a debug log of what you are seeing?

Hmmm - ok, 1.8.3 is very old and unfortunately doesn’t support event notifications well. I would at least suggest to update to 1.9, but even this is quite old now. OH2 is really where propper support for the notification class is found.

I’ll take a look at the log though…

Thanks for getting back to me Chris.
I am currently using openHAB 1.8.3 with z-wave binding org.openhab.binding.zwave-1.10.0-SNAPSHOT.jar (version

Incriminated node is NODE 2 (Sensative Strips) which goes from UNINITIALIZED state (openHAB has been recently shutdown and no wake-up occured yet) to OPEN when scheduled (not manual) WAKE UP process happens (and fails).

Logs are attached (again, only consider NODE 2). Hope they will make sense.
(uploaded as XML to fool upload feature)

zwave_sensativestrip_node2.log.xml (33.1 KB)

What do you mean by “and fails” - the wakeup looks like it works, so do you refer to something else when you say the wakup fails?

As you’re using the binary sensor configuration, the binding does appear to be working correctly I think.

I’m discussing with the (very helpful) guys at Sensative so let’s see.

So, it looks like this is indeed a problem with the device - probably the best thing to do is to avoid polling which apparently has an issue with the device firmware.

I assume that with your item configuration, you have the refresh_interval=xxx option set? This configures polling and should not be used for Strips (and really, any other device if it supports associations as it’s generally bad practice).

Can you confirm that this is how you have your item configured?

No, I do not. Here goes my Sensative Strip .items details:

Contact	window_diner1				"Window Diner1 [%s]"	<contact>	(Home)	{ zwave="2:command=sensor_binary,respond_to_basic=true" }

Because the Habmin status icon in regard of NODE 2 remains GREY after wake-up prceoss

I will give 1.9 a try (I will need to deepen my searches to find out where to get it).
I gave 2.0 a try (I love the more plug & play approach) but moved back to 1.8.3 as Homekit Add-on support in 2.0 is limited (no Sensor tag).

Ok, so the only other time that the device is polled is following startup - is this a startup issue or does it happen on every wakeup?

I’ve just thought of another thing we can try to stop the polling so I’ll look to do an update to the database.

Ok - I don’t think the wakeup is failing - it’s fine. It stays grey presumably because it hasn’t completed initialisation for some reason, but without seeing the log it’s hard to say why. If you wake it up again, does it complete?

I missed the fact that you are using 1.10 of the binding so this is ok…

I’ve just done an update to the OH1 binding that will hopefully resolve this so please try the nightly build tomorrow.

Hi Chris, I’ve only used the OH2 binding, did you update something there as well?

No - OH2 already has this for some time now (a few months), so this problem shouldn’t exist on OH2. Do you have a problem with OH2?

Will do. Many thanks @chris. However, I paid a visit to fetch last ZWave binding, but it sounds like your are running out of disk space and builds did not execute properly.

See following message from the website:
Your total DEV@Cloud disk usage is over your subscription’s quota. Your subscription ‘foss-free’ allows 10 GB, but you are using 10454 MB across all services (Forge and Jenkins). To fix this, you can either upgrade your subscription or delete some data in your Forge repositories, Jenkins workspaces or build artifacts.


I tried z-wave binding version for the last 24 hours and so for so good (openHab 1.8.3).
I looked at the log and saw the timeout on the Sensative Sensor Node that used to trigger a false positive (door open). The false positive is not triggered anymore.
I will report back next week to validate this on a longer period of time.

Thanks again @chris.

1 Like

After one week of using z-wave binding version under OpenHab 1.8.3 I can confirm that the false positive issue is solved.

@chris: Unfortunately, still with z-wave binding version under OpenHab 1.8.3, I experienced a timeout / false positive this morning. So the issue is still pending.