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?
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…
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.
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.
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.
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.
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 1.10.0.201702210211).
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)
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?
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…
Will do. Many thanks @chris. However, I paid https://openhab.ci.cloudbees.com/ 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 1.10.0.201703070925 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.
@chris: Unfortunately, still with z-wave binding version 1.10.0.201703070925 under OpenHab 1.8.3, I experienced a timeout / false positive this morning. So the issue is still pending.
