One Sensative comfort strip is working fine, while other two are not

Add-ons Bindings
1

Hi, I purchased total three Comfort strips, and they all get included fine on my z-wave network via aeotec z-stick and I can see their values in openhab. But shortly after, two stopped working.
First I purchased one Comfort strip and that one worked fine for few days, but then openhab just stopped receiving values from it. I tried reset as described from the website, but I never managed to include it back to the controller again, it would only blink red twice and never get included.
I then purchased second one, and it included fine and is still working few weeks later. I returned the first one to the seller, and they were kind enough to send me another one. That one got included fine, worked fine for few days, but again stopped reporting the values. They are in 1-2m from controller in my office, I also tried moving them around, manually waking them (which works fine) but no value is coming to the controller/openhab. Now the second one is red in openhab, and I can reset the strip with magnets, and it will blink as it has been waken. But again no values in openhab

I contacted Sensative with same description of a problem and they suggest it is openhab that is not integrating the device profile “This sounds like a problem with the controller actually, openhab has not integrated our device profile so we cant ensure that the values will be present in the UI. The best thing to do is contact the people at openhab and ask for a proper integration of Strips Comfort device profile.”

Do you guys have any suggestions how can I ensure that it is not the strip that is problematic? Or how I can check what could be the problem? Some alternative controller perhaps or?

Again, one comfort strip is working fine, two stopped reporting after few days (first and the third one). I also have two guard strips from Sensative and they are working perfect, and I have total 18 z-wave devices, all working as expected.

2

Hard to help without knowing what version of OH you’re running. And the zwave binding version, if you’ve manually installed it.

3

Right, sorry. I am running 2.4 of openhab, with its stable version of the plugin (however, this was the problem before I updated as well, from 2.3 stable).

First comfort strip I included in 2.3 version, it worked for few days but it stopped, so I waited for 2.4v and then I included second strip and it worked fine (still is), and I was thrilled. Then I tried to re include the the first strip, but never managed to do it. Then I purchased third strip, and it included fine, and worked for few days, and then just stopped reporting data (or openhab/stick stopped receiving it).

I am now running openhab from docker, but it was same before I migrated to docker. I am using aeotec z-wave stick, on a old laptop running ubuntu server 18.

4

I found your other posts about these devices. Are you sure the associations are set? There was an issue found in the binding where they’d get lost. This was fixed after 2.4 went out. Habmin has a bug in the display of associations, and they will always look empty (unless you’ve just changed it), so this is one of the only things I recommend using Paper UI for. But if they are empty in Paper UI, go back to Habmin to make the change!

If the associations are OK, you could also try putting zwave in debug and take a look in the logs to see what the device is communicating, if anything. Actually, it may be good to monitor the log while setting the associations, which will require a wakeup of the device, to make sure they get set.

1 Like
5

Thank you @5iver, it took me some time to come back to this due to other issues I had after migrating (and life had other plans). Anyway, back to the case… After some time the good one stopped working as well, after I manual wake it just woke without giving any data, however after another waking it started working again (log is attached)
.
The bed one, after some fiddling, removing and re-adding it, it started working now and reports data. However, before I conclude it is working (as it always worked for few days and then stopped), I would like to check associations as you suggested. Am I looking at the right value, when for both strips it says:

dbReference 747
defaultAssociations 1

? Is that what you ment for associations?
I do see communication in logs now, and messages being sent and all.

As I mentioned, when I woke up the good one manually, it sent something to the controller, but no data (I lost the log). But then logs started showing bunch of

2019-02-19 21:53:24.305 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 17: WakeupTimerTask 1 Messages waiting, state REQUEST_NIF

2019-02-19 21:53:26.805 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 17: WakeupTimerTask 1 Messages waiting, state REQUEST_NIF

2019-02-19 21:53:29.305 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 17: WakeupTimerTask 1 Messages waiting, state REQUEST_NIF

2019-02-19 21:53:31.805 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 17: WakeupTimerTask 1 Messages waiting, state REQUEST_NIF

2019-02-19 21:53:34.305 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 17: WakeupTimerTask 1 Messages waiting, state REQUEST_NIF

2019-02-19 21:53:36.805 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 17: WakeupTimerTask 1 Messages waiting, state REQUEST_NIF

2019-02-19 21:53:39.305 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 17: WakeupTimerTask 1 Messages waiting, state REQUEST_NIF

2019-02-19 21:53:41.805 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 17: WakeupTimerTask 1 Messages waiting, state REQUEST_NIF

2019-02-19 21:53:44.305 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 17: WakeupTimerTask 1 Messages waiting, state REQUEST_NIF

2019-02-19 21:53:46.805 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 17: WakeupTimerTask 1 Messages waiting, state REQUEST_NIF

2019-02-19 21:53:49.305 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 17: WakeupTimerTask 1 Messages waiting, state REQUEST_NIF

2019-02-19 21:53:51.805 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 17: WakeupTimerTask 1 Messages waiting, state REQUEST_NIF

2019-02-19 21:53:54.305 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 17: WakeupTimerTask 1 Messages waiting, state REQUEST_NIF

2019-02-19 21:53:56.805 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 17: WakeupTimerTask 1 Messages waiting, state REQUEST_NIF

2019-02-19 21:53:59.306 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 17: WakeupTimerTask 1 Messages waiting, state REQUEST_NIF

I then woke it up again manually and it did report its values then just fine, attached is this part of the log. I would really appreciate if you could just take a look, perhaps you find something unusual.

z-wave-good-one-1-wake-up.log (77.1 KB)

6

I’m not sure what that is.
:slight_smile: Look at Configuration> Things> your device, and check the properties. You will see the Associations. Your log shows node_1 set to group 1, and it completed initialization, so this one looks OK. It is normal for it to take several wakeups for a device to complete initialization. If you keep having issues, you may want to try a recent binding, which would include fixes for associations and wakeups.

1 Like
7

can I ask you @5iver to look at these logs before I try the new binding version (never did manual installation so I am a bit reluctant), I am trying to determine if it is something with the device, or something with the OpenHab binding.
Now both devices stopped reporting data from yesterday. I picked up data from logs for node 19, which reported data last time at 4:13 at night, and it is mentioned in the logs after that several times, but no data coming in.
Could it be device issue?
(btw, would you recommend updating entire docker image to some “semi-stable” version, or just updating the binding itself?)
Thanks again, this has been the issue for me for over a year now, so I would either sell the devices or fix it somehow, I had big plans for them and really like their unique form factor :slight_smile:
z-wave - node19 no activity.txt (62.6 KB)

8

After few days this is what the other one it is showing, no data coming at all, only few lines and log parser says only two offline thing states.

openhab-node17.txt (6.8 KB)

9

Well, it was working fine for a few weeks, then I turned off z-wave debug and it stopped working couple of days after that. It then reported temperature once a day for two days, and then went silent again.
I have now enabled z-wave debugging and all I see for node 19 is two times

2019-04-23 22:47:38.040 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 19: Polling…
2019-04-23 22:47:38.041 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 19: Polling deferred until initialisation complete

@5iver , @chris , anyone, pretty please?

10

Did you upgrade the binding to at least 2.5 M1?

11

I apologize @5iver I got a small panic/depression and forgot about your suggestion. I have now updated z-wave to the latest 2.5.0-SNAPSHOT from the jenkins build, and I am now waiting for device to start reporting something.
I still only get fallowing in the logs:
2019-04-24 20:35:10.556 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 19: Polling…

2019-04-24 20:35:10.557 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 19: Polling deferred until initialisation complete

2019-04-24 21:05:10.556 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 19: Polling…

2019-04-24 21:05:10.557 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 19: Polling deferred until initialisation complete

I tried waking it up manually a few times but nothing in the logs.
I will wait a bit more to see progress, or try to wake it up tomorrow and also try your recommendations from above.

Thanks again!

1 Like
12

Just wanted to report that after a few days on the new binding, after setting lifeline to controller, the device started to report temperature as expected.
I hope it is not just one of its “a week at a time” thing :slight_smile:

Thanks for (patiently) helping me out :slight_smile:

1 Like
13

Hello again @5iver , I had a great run of few months, but then one sensor again stopped working on Saturday, 22/06/2019 23:32. The other one is working fine, they are both pretty much same distance from the controller. The one that is working is actually two walls behind.

Any tips on where to start debugging/testing?

14

actually, I see now that on that date I did update all system packages and rebooted entire server.
After few days I had to manually restart zWave binding from Karaf due to this one No SerialPort Provider error with Ubuntu 18.04 and Zwave 2.5.x snapshot

I did not update openhab though as it is in the docker, I just updated system security and other packages