Hi Chris,
Can you post the URL link so I can manually download the latest JAR for zWave? I’m having this issue also with 1 of my battery zWave devices also.
I’m running v2.5 already; but it sounds like you changed something recently to address the REQUEST_NIF issue from the thread.
Best, Jay
It would be awesome if there could be section of the forum with the bindings and the latest versions, I too found it difficult to find the latest 2.5 (and can’t again haha!)
You’ll find all of them here… https://ci.openhab.org/job/openHAB2-Bundles/lastSuccessfulBuild/.
It’s looking pretty hopeful so far, from the look of it after updating to the latest snapshot, all devices have passed through initialisation other than a few long-sleepers such as door sensors which take a few days due to long sleep times. All the troublesome radiators have passed through initialisation without needing any coaxing, which hasn’t happened for a long time. The z-wave debug logs have stopped showing “Polling deferred until initialisation complete” for all devices other than the long-sleepers. I’ll start monitoring the disabled channels on the previously-troublesome radiators to see if they continue to update. Maybe I won’t have to change all my radiator TRVs after all! Fingers crossed.
Great stuff - sounds good so far, and thanks for the feedback…
Hi @chris,
I am struggling for 3 weeks already with the sensative strips to get them back into my setup. They used to work and were included but due to a loss of my setup (and the secret)
I have reset and reincluded them several times but the end up in one of the two situations:
The latest situation I went in was pretty weird:
It did discover the manufacturer and the device type as it is says
2019-11-24 15:40:56.569 [DEBUG] [wave.discovery.ZWaveDiscoveryService] - NODE 65: Device discovery completed
2019-11-24 15:40:56.574 [DEBUG] [wave.discovery.ZWaveDiscoveryService] - NODE 65: Device discovery resolved to thingType zwave:sensative_1101011_00_000
now the Thing is “ONLINE” but says “Unknown Device” and when I try to heal it this is confirmed ("Can not start heal as initialisation is not complete (MANUFACTURER)).
then out of despair I deleted the thing, ran the discovery and then the node was discovered WITH the manufacturer information… the only little thing you see in the logs regarding the notes is two lines - this is very weird, is it not?
2019-11-24 18:53:28.472 [DEBUG] [wave.discovery.ZWaveDiscoveryService] - NODE 65: Device discovered
2019-11-24 18:53:28.497 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 65: Got an event from Z-Wave network: ZWaveInclusionEvent
(the logs are attached)
The other thing is that Jonathan from the manufacturer said that the strip only awakes for roughly ten seconds to safe battery. If I run the discovery could it be that because of too many other devices (if have like 40) on the zwave network that there is too much other traffic so that it is just too late for the device to be contacted when it already went to sleep again?
Finally I tried to set the “1:lifeline” to “controller” and when updating the values I get:
2019-11-24 19:37:54.838 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 65: Association 1 consolidated to [controller]
2019-11-24 19:37:54.841 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 65: Unknown association group 1
and the value is not persisted (when I open it up again, the setting is gone)
I am running the ZWave Bundle 2.5.0.201911020359
Would it make sense to run the latest version “2.5.0.201911230756” or would you rather recommend to go back to an older bundle version?
cheers
Stefan
PS: I lately started contributing myself to a different binding (nanoleaf), so I got to know quite something about bundles, hence I am open to help you in any way that would solve that issue - even compiling the latest version on openhab-core or adding logs somewhere in the code (locally) 
…
[node65.txt|attachment]
openhab-zwave-log.log (10.4 KB) openhab-zwave-log4.log (19.4 KB) openhab-zwave-log3.log (35.9 KB) openhab-zwave-log2.log (54.8 KB)
Please provide the full debug log.
The devices tend to be problematic, but I have tested them in the past so they ought to work. They are difficult to wake up though. If the device goes to sleep, then you just need to wake it up again - this is normal for battery devices in ZWave.
Hi @chris
Long time no see. 
I’m the guy @stefan.hoehn has been in contact with at Sensative Support. I downloaded and did some testing with the latest milestone build, 2.5.0.M5 (windows version), and think i may have come across the same issue as Stefan has including Strips Guard, although i’m not sure exactly what triggers it.
I started out with a hard reset on my z-stick to clear it of all previous z-wave devices. I thereafter continued by adding a Strips Guard to the system and got it working ok immediately, no additional wake ups required. I excluded Strips and included again, still fine.
On the third attempt though, the interview was cut short by the controller sending WUNMI (Wake Up No More Information) before the Association Set command was sent to Strips, i could see this in the z-wave sniffer logs. Without the Association Set command, Strips is left without a lifeline and thus doesn’t know who to send open/close commands to. This results in Strips blinking five times for open events (our standard failure LED indication). If i in Strips’ settings assign the lifeline association towards the controller and wake it up 3 times (not sure why it takes so many NIF events for controller to send…) it gets the association ID and is able to send open/close.
In my fourth inclusion attempt i again did not get Association Set. This time i decided to test repeatedly waking up Strips (sending NIF - Node Information Frame -) to see how long it would take to complete the interview. It took a staggering 15 manual wake up commands before association was sent normally. The reason so many wake ups were required is because the controller keeps sending WUNMI after only one or two reports instead of sending all the reports at once.
Link to z-wave sniffer and debug logs:
The .zlf files can be opened with SiLabs zniffer tool if you have it.
I’m currently testing with a milestone build so i imagine there may be some bugs and room for refinement, but i am also quite sure that similar inclusion issues exists in the current stable build 2.4.0. I’ve personally seen association issues in that firmware although wasn’t able to reproduce after accidentally reseting the controller 
I am able to reproduce the issue with my current setup, although i suspect that if i were to do a hard reset on the controller that the issue would disappear.
Best regards
Jonathan Bjarnason
I have attached the logs above, @chris. However, I think the most promising information is most likely the one from Jonathan. I have good hopes that together with him, we eventually get the “beasts” under control.
cheers
Stefan
Hi @chris, do you think you have a chance to have a look at?
Anything where I could support you?
cheers
Stefan
Please can you provide a complete debug log showing the issue that you’re having as I can’t find anything other than the logs posted a few messages back and these aren’t really of any use as they are incomplete (I think they have been filtered).
Thanks Chris,
What I did I is that I filtered them by the node number which probably wasn’t a good idea. I will try reproduce this thing tonight and log everything I get. Does it make sense to filter by zwave, so you do not get other stuff that is not related to zwave or do you intentionally want to have everything around as well?
I will post it later.
What about the information of Jonathan? Doesn’t that help?
Thanks so far Chris,
Stefan
No - this removes a lot of information about what the binding is doing.
There are a lot of files in that repository - many are sniffer logs which don’t show what the binding is doing - they show what is going on over hte air. Others are looking at associations and other issues so it’s unclear how this relates to the device being stuck in the request_nif state as I couldn’t see this in the logs I looked at. I’d like to understand what your problem is…
Hi Chris
Existing and working strips (I edited them which you probably see in the logs)
node 68 and node 69 were trials to be included. Updated them (you can see that in the logs but won’t listen)
Current non-working strip is supposed to be node 69
Strip blinks 5 times when magnet goes over sensor
Waking up strip - nothing in the logs.
Now starting inclusion
Node69 discovered (as several times before)
Node 69 is online (btw, 68 is too even though not existing, probably controller stick knows it still)
Waking up now strip but nothing is shown in the logs
Putting magnet over sensor reveals 5 blinks but no communication in the logs.
See logs attached.
strips.log (137.9 KB)
commandClass:COMMAND_CLASS_SENSOR_BINARY getSupported=false
dbReference 251
defaultAssociations 1
manufacturerId 019A
manufacturerRef 0003:0003
modelId 11-01-011
vendor Sensative AB
zwave_beaming true
zwave_class_basic BASIC_TYPE_ROUTING_SLAVE
zwave_class_generic GENERIC_TYPE_SENSOR_NOTIFICATION
zwave_class_specific SPECIFIC_TYPE_NOTIFICATION_SENSOR
zwave_deviceid 3
zwave_devicetype 3
zwave_frequent false
zwave_listening false
zwave_manufacturer 410
zwave_neighbours
zwave_nodeid 69
zwave_routing true
zwave_secure false
zwave_version 0.0
Setting lifeline in Habmin to controller
2019-12-01 23:30:40.547 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 69: Configuration update received
2019-12-01 23:30:40.552 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 69: Configuration update set group_1 to controller (String)
2019-12-01 23:30:40.555 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 69: Association 1 consolidated to [controller]
2019-12-01 23:30:40.558 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 69: Unknown association group 1
2019-12-01 23:30:40.570 [me.event.ThingUpdatedEvent] - Thing 'zwave:device:77371ce0:node69' has been updated.
2019-12-01 23:30:40.576 [vent.ConfigStatusInfoEvent] - ConfigStatusInfo [configStatusMessages=[ConfigStatusMessage [parameterName=wakeup_node, type=PENDING, messageKey=null, arguments=null, message=null, statusCode=null], ConfigStatusMessage [parameterName=wakeup_interval, type=PENDING, messageKey=null, arguments=null, message=null, statusCode=null]]]
… but isn’t kept!
Is there any way I could patch the data, so the controller is associated to lifeline? Maybe that would help. If I try to do that in the settings this is not persisted.
Would it help to put logging to TRACE?
Trying to heal
2019-12-01 23:34:04.336 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 69: Configuration update received
2019-12-01 23:34:04.343 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 69: Configuration update set action_heal to true (Boolean)
2019-12-01 23:34:04.346 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 69: Starting heal on node!
2019-12-01 23:34:04.349 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 69: Can not start heal as initialisation is not complete (REQUEST_NIF).
2019-12-01 23:34:04.361 [me.event.ThingUpdatedEvent] - Thing 'zwave:device:77371ce0:node69' has been updated.
Anything more I can do?
cheers
Stefan
Try waking up the node repeatedly. I have sometimes found that deleting the Thing from OpenHAB (do not exclude) and re-discovering sometimes helps too.
The binding has not finished discovering the device and, apparently, cannot find Group 1. It is properly defined in the database as Lifeline.
Thx but I am doing that already. In some cases I did up to twenty Times…
Just to add to this conversation: I recently added Zwave to OpenHab (pi), but my first device (Hank HKZW-MS02) is not recognised. I tried everything I could find on the forum, upgraded to the latest OpenHab Test 2.5, but still no success. The device is added, according to the log it is working (alarms are logged), but the Thing stays ‘unknown device’ (woke it up lots of times, waited days, removed and added etcetera). Hopefully someone finds the cause for this, I beginning to doubt if zwave was a good idea. I’ll follow this thread with interest.
Please open a new thread for your issue. I have found the developer, @chris extremely helpful an dediscated.
That device is in the zwave database here.
In HABmin, can you check that the Type:Id reported by the device is among those listed in the database entry? You can find the Type:Id in the Attributes panel of the Thing.
Exactly, I already checked the database before, it is there indeed. The Thing is not reporting the Id, only:
| zwave_beaming | true |
|---|---|
| zwave_class_basic | BASIC_TYPE_ROUTING_SLAVE |
| zwave_class_generic | GENERIC_TYPE_SENSOR_NOTIFICATION |
| zwave_class_specific | SPECIFIC_TYPE_NOTIFICATION_SENSOR |
| zwave_frequent | false |
| zwave_listening | false |
| zwave_neighbours | |
| zwave_nodeid | 2 |
| zwave_routing | true |
| zwave_secure | false |
| zwave_version | 0.0 |