This is not a wake up transaction.
Double check process for waking up the device.
2 Likes
Sometimes I have had to “get creative” I have one device where the manual says it needs a single button press to wake it up. Apparently, it needs a triple button press to wake it up. When I did that the OH log showed it as AWAKE.
1 Like
That was a good hint, three times shows AWAKE in the log. I will try this a few times to see if I a more lucky…
1 Like
Failing that, try deleting the Thing, rediscovering, & waking it up. Battery devices can be a real pain to get discovered initially.
So deleting and rediscovering the Thing a lot of times finally did the job. Thanks @Bruce_Osborne & @mhilbush.
1 Like
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.
There are both z-wave sniffer logs and openhab debug logs in the link i attached, or is there any data missing there? I followed these instructions to get out the debug logs:
https://www.cd-jackson.com/index.php/openhab/5-zwave-debugging-openhab
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…
Not sure what the request_nif state infers. It does not appear in my debug logs, but appears in Stefan’s. In the debug logs Stefan provided, the request_nif seems to always occur in conjunction with the bridge controller going offline (BRIDGE_OFFLINE), but it goes back online within 10ms. Some sort of soft reset of the controller?
Also, just to be clear, the reason why both mine and Stefan’s units are not getting added correctly is because association is not being set during inclusion interview. Is this a known issue that people are working on? Is there a forum for this issue where this data is of more use?
The controller has requested, and is waiting for a “Node Information Frame” from the device.
I have had issues with battery powered devices that were not responsive and stuck in REQUEST_NIF, I have had luck with going to the settings of the device turning “Heal Device” on, and then performing a wakeup of the device (that saved my from excluding and including the devices)
Not sure if this is the recommended approach, but it seemed to work.
1 Like
Yes, I know - that’s why I said “many are sniffer logs”. The point is still that the logs don’t address the issue described here where the device is stuck in the REQUEST_NIF initialisation state. I wanted to try and address the concern that was raised and not other issues raised subsequently.
Ok, then why is this issue reported as teh device being stuck in the REQUEST_NIF state. I’ve not seen the logs that show this, so apologies for the lack of information regarding this.
The binding DOES set the associations - or at least it should. If the device is stuck in the REQUEST_NIF state, then of course it is not progressing to the stage where it sets the association. Hence I need to address this issue.
No - as far as I’m aware there is no issue. The binding will definately try and set the association - it will do this autonomously if it detects the ZWave+ lifeline group, or it will do it autonomously if it is set in the database. This is standard stuff and there should not be an issue if the interrogation is completing. If it’s stuck in the REQUEST_NIF state, then this will not occur.
This is the forum 
I have a LOT on at the moment and I try to support this as best as I can, but I also have other things that need my support, and unfortunately need to prioritise my time. We are currently going through ZigBee certification and this is taking a lot of time right now.
3 Likes
The point is still that the logs don’t address the issue described here where the device is stuck in the REQUEST_NIF initialisation state. I wanted to try and address the concern that was raised and not other issues raised subsequently.
Ah, i see. My issue might not be the same as Peter’s then, even though the device (Strips in this case) ends up in the same state. I will try and open up a separate forum post for my problem to keep things a bit more organized.
Ok, then why is this issue reported as teh device being stuck in the REQUEST_NIF state. I’ve not seen the logs that show this, so apologies for the lack of information regarding this.
My bad, i will make a post of my own for the issues i faced including Strips.
The binding DOES set the associations - or at least it should. If the device is stuck in the REQUEST_NIF state, then of course it is not progressing to the stage where it sets the association.
In my case, the interview stops before association is set. However, the remaining commands seem to still be queued up since they are sent one by one when waking up the device.
I have a LOT on at the moment and I try to support this as best as I can, but I also have other things that need my support, and unfortunately need to prioritise my time. We are currently going through ZigBee certification and this is taking a lot of time right now.
I know the feeling. 
We currently have some ongoing certifications of our own, so i also have to balance my time between support and development.
Thank you for the detailed reply!
Yes, please start a new thread for this.
New thread here for any interested:
Does anybody have a rule to detect REQUEST_NIF on zWave battery devices proactively? I’ve just noticed I had 2 of my devices stuck in this state and once I woke them up - they fully came online.
Best, Jay
Then they were not stuck in that state - the binding was just waiting for them to report. This is normal - the devices should still work fine if they report, but they must wake up. Normally a device will do that automatically every hour, or every day or so, and when it does, the binding will react - as it did…
Ok, this is an interesting discussion. I am on 2.5.9-1.
I do struggle with exactly the same problems REQUEST_NIF and MANUFACTURER for two of my four battery devices brand Neo Coolcam.
Two are detected properly, the other two remain with these two Node Initialising messages.
What I can see is that all do not show any association. Even the Lifeline association is not set to the controller.
And this is causing my question, how to deal with these association groups when using OpenHab?
Is it required to set these association groups at all?
If YES, do I need to set the Lifeline to the controller or to the routing device what is next to it?
That means the devices have not properly responded with the NIF frames required by the Z-Wave specification. These frames contain device specific information needed and used by the binding.
Battery operated devices can be particularly troublesome, needing to be woken up repeatedly. At times I have removed the battery, wait a minute & re-insert, waking up many times to get through that. Cheap Neo Coolcam battery devices can be very difficult, in my experience. I have replaced some of mine with better ones.
1 Like
Oh Yes, I can second this. I wouldn´t buy these Neo Coolcam devices again. I bought these already 2 years ago and at that time there weren´t that many battery PIRs and I loved the tiny design.
They even show up with a temperature channel but that´s wrong and the luminance sensors aren´t working as good as well.
So I will try your hint with the battery.
But how are you setting up your devices concerning the association groups, do you maintain these?
Is lifeline always associated to controller or to the next routing node?
1 Like
For quite some time now, the binding also automatically detects and sets the Lifeline group if it is not already in the database entry.
1 Like
Thanks a lot,
I will try and play a bit with the PIRs and see if I can get them properly detected.
But again this lifeline association is necessary, correct?
and always assigns the controller and not another routing node?
Correct.
It is usually specified in the database entry for the device I believe Z-Wave Plus always requires Association Group 1 to be Lifeline.
The current home for the binding database is here.