Battery devices stuck in REQUEST_NIF

Each time I restart my OpenHab server, some of my battery devices never quite complete initialisation, getting stuck in one of the initialisation states. At the moment I have one stuck in REQUEST_NIF. I’ve been jabbing away at the wake-up button and I think the log is showing that it’s sending the NIF but there’s no progression from this. I’ve attached the log in which the device is Node 3.

zwave.log.gz.xml (87.5 KB)

This device is a Stella-Z radiator valve, the documentation states it sends a NIF when the wakeup is pressed, but it’s been stuck in REQUEST_NIF since about 6AM today, with the device waking up itself every 10 minutes, and me pressing the wake-up button at varying intervals (sometimes a minute between presses, sometimes 10, sometimes a few seconds) but despite there appearing to be a NIF sent, it’s still stuck in REQUEST_NIF. Any clues anyone?

Here’s a quick screen grab of the log in the log viewer.

OpenHab Version: 2.4.0~S1447-1
Platform: Debian GNU/Linux 9 (stretch)
Hardware: VM, 2 CPUs, 3GB RAM, 20 GB disc, 15 GB free
java version “1.8.0_181”
Java™ SE Runtime Environment (build 1.8.0_181-b13)
Java HotSpot™ 64-Bit Server VM (build 25.181-b13, mixed mode)

Had the same problem. Request_Nif goes away if i wake up one or more of the devices. Currently moving to release 2.4, but have not checked if this is solved now.

I’m on 2.4 so no, it doesn’t go away unfortunately. I’m going to be trying to beat my system into shape this week if I can, so will be keeping a close eye on it.

I managed to get it to complete initialisation by deleting the device, re-discovering it, then adding it, but despite completing initialisation it’s an “unknown” device, which is frustrating particularly as there are 11 other identical devices in the network. I’ve had this device for many years, it’s a well-known radiator valve so now I have to figure out why OpenHab is no longer recognising it although it can see all its endpoints. It was working fine yesterday but a reboot of the server has broken things. I wouldn’t mind so much but it’s controlling the radiator in my office and it’s freezing :wink:

Deleting and rediscovering work, but server restart bringsup the problem again.

Yes I had to delete and reboot to get the device recognised again but now I have two other devices which were previously working but are now stuck in REQUEST_NIF, they are all Eurotronics Stella-Z devices so it may be a “feature” of these devices but I am puzzled about why the NIF they’re sending seems to be disregarded.

If have the problem with Fibaro dvices and i hav some devices stuck in “Initializing: Ping”

I’m quite surprised at that, I have a few Fibaro devices and they’ve been very well behaved, so far it’s the Eurotronics and Aeon Labs stuff which has given me trouble.

Maybe we should involve @chris, because he is the master of zwave.

All I can think of is that the initialisation sequence has exited due to no response (or some other error). There is a maximum number of attempts that are made, and after that it will exit to avoid continuous looping.

Can you get a log of this from the binding startup, wake up the device a bunch of times, and then provide the log for this and I will try and work out what is happening.

OK will do, but it’ll take a while as I’ll need to reconfigure logging to avoid log flushing, several hours of debugging is more than my current setup will retain. I’ll post again once done. Thanks for the offer.

It shouldn’t need to be several hours - hopefully 5 or 10 minutes should be enough. Wake the device up manually a few times after startup…

I’d suggest the following -:

  • Stop the binding
  • Enable debug logging
  • Start the binding
  • Wait 2 or 3 minutes for the majority of devices to hopefully settle down
  • Wake up the battery device 5 times - waiting 15 seconds or so between each subsequent wakeup
  • Send me the log

Hopefully the log won’t be too big - if it’s larger than 10MB I will have trouble loading it so please ensure the logs are rotated. I wouldn’t really expect the log to be so big if it’s only 5 minutes or so (maybe it will still be a few MB, but that’s fine).


It takes about 3-4 hours for my system to settle after a restart, and as the affected devices don’t really make themselves known until about 7 or so hours have passed then it’ll take a bit longer than a few minutes. This is after doing an openhab reboot though, does doing just a binding restart speed the process up?

I’m not really sure what it would be doing for this time :confused: . How big is your network ???

Probably not - it does exactly the same thing unless you have something else happening on system start.

This is the zwave things list, it takes at least 2 hours before things start to respond within a 10 second delay (e.g. turn on a light, wait 10 seconds, it turns on) and about another hour or two before latency drops down to normal levels:

openhab> smarthome:things list | grep zwave
zwave:device:214d29fb:node73 (Type=Thing, Status=ONLINE, Label=Lounge Lights Rear, Bridge=zwave:serial_zstick:214d29fb)
zwave:device:214d29fb:node74 (Type=Thing, Status=ONLINE, Label=Treadmill, Bridge=zwave:serial_zstick:214d29fb)
zwave:device:214d29fb:node71 (Type=Thing, Status=ONLINE, Label=Greenway Powernode 5, Bridge=zwave:serial_zstick:214d29fb)
zwave:device:214d29fb:node72 (Type=Thing, Status=ONLINE, Label=Office Bench, Bridge=zwave:serial_zstick:214d29fb)
zwave:device:214d29fb:node70 (Type=Thing, Status=ONLINE, Label=Fibaro Window Sensor 2, Bridge=zwave:serial_zstick:214d29fb)
zwave:device:214d29fb:node79 (Type=Thing, Status=ONLINE, Label=Main Bedroom Radiator, Bridge=zwave:serial_zstick:214d29fb)
zwave:device:214d29fb:node77 (Type=Thing, Status=ONLINE: Node initialising: REQUEST_NIF, Label=Bedroom Wall Controller, Bridge=zwave:serial_zstick:214d29fb)
zwave:device:214d29fb:node78 (Type=Thing, Status=ONLINE, Label=Office Smoke Detector, Bridge=zwave:serial_zstick:214d29fb)
zwave:device:214d29fb:node75 (Type=Thing, Status=ONLINE, Label=Lounge Display Cabinet, Bridge=zwave:serial_zstick:214d29fb)
zwave:device:214d29fb:node76 (Type=Thing, Status=ONLINE, Label=Mon1, Bridge=zwave:serial_zstick:214d29fb)
zwave:device:214d29fb:node62 (Type=Thing, Status=ONLINE, Label=Office Light, Bridge=zwave:serial_zstick:214d29fb)
zwave:serial_zstick:214d29fb (Type=Bridge, Status=ONLINE, Label=Z-Wave Serial Controller, Bridge=null)
zwave:device:214d29fb:node63 (Type=Thing, Status=ONLINE, Label=Garage Door Sensor, Bridge=zwave:serial_zstick:214d29fb)
zwave:device:214d29fb:node61 (Type=Thing, Status=ONLINE, Label=Office Door Sensor, Bridge=zwave:serial_zstick:214d29fb)
zwave:device:214d29fb:node2 (Type=Thing, Status=ONLINE, Label=Heat and Water, Bridge=zwave:serial_zstick:214d29fb)
zwave:device:214d29fb:node3 (Type=Thing, Status=ONLINE, Label=Office Radiator, Bridge=zwave:serial_zstick:214d29fb)
zwave:device:214d29fb:node4 (Type=Thing, Status=ONLINE, Label=Lounge Radiator Rear, Bridge=zwave:serial_zstick:214d29fb)
zwave:device:214d29fb:node6 (Type=Thing, Status=ONLINE, Label=Lounge Multisensor, Bridge=zwave:serial_zstick:214d29fb)
zwave:device:214d29fb:node8 (Type=Thing, Status=ONLINE, Label=Lounge Fly Zapper, Bridge=zwave:serial_zstick:214d29fb)
zwave:device:214d29fb:node29 (Type=Thing, Status=ONLINE, Label=Hall Top Radiator, Bridge=zwave:serial_zstick:214d29fb)
zwave:device:214d29fb:node24 (Type=Thing, Status=ONLINE, Label=Back Porch Light, Bridge=zwave:serial_zstick:214d29fb)
zwave:device:214d29fb:node68 (Type=Thing, Status=ONLINE, Label=Office Multisensor, Bridge=zwave:serial_zstick:214d29fb)
zwave:device:214d29fb:node69 (Type=Thing, Status=ONLINE, Label=Bedroom Multisensor, Bridge=zwave:serial_zstick:214d29fb)
zwave:device:214d29fb:node25 (Type=Thing, Status=ONLINE, Label=Hall Top Multisensor, Bridge=zwave:serial_zstick:214d29fb)
zwave:device:214d29fb:node66 (Type=Thing, Status=ONLINE, Label=Lounge Multisensor Rear, Bridge=zwave:serial_zstick:214d29fb)
zwave:device:214d29fb:node22 (Type=Thing, Status=ONLINE, Label=Dining Room Radiator, Bridge=zwave:serial_zstick:214d29fb)
zwave:device:214d29fb:node67 (Type=Thing, Status=ONLINE, Label=Bathroom Multisensor, Bridge=zwave:serial_zstick:214d29fb)
zwave:device:214d29fb:node23 (Type=Thing, Status=ONLINE, Label=Downstairs Toilet Radiator, Bridge=zwave:serial_zstick:214d29fb)
zwave:device:214d29fb:node20 (Type=Thing, Status=ONLINE, Label=Garden Room Multisensor, Bridge=zwave:serial_zstick:214d29fb)
zwave:device:214d29fb:node64 (Type=Thing, Status=ONLINE, Label=External Motion Sensor, Bridge=zwave:serial_zstick:214d29fb)
zwave:device:214d29fb:node65 (Type=Thing, Status=ONLINE, Label=Lounge Multisensor Front, Bridge=zwave:serial_zstick:214d29fb)
zwave:device:214d29fb:node50 (Type=Thing, Status=ONLINE, Label=Doorbell Front, Bridge=zwave:serial_zstick:214d29fb)
zwave:device:214d29fb:node19 (Type=Thing, Status=ONLINE, Label=Garage Light, Bridge=zwave:serial_zstick:214d29fb)
zwave:device:214d29fb:node17 (Type=Thing, Status=ONLINE, Label=Garden Room Radiator, Bridge=zwave:serial_zstick:214d29fb)
zwave:device:214d29fb:node18 (Type=Thing, Status=ONLINE, Label=Garden Room Lamp, Bridge=zwave:serial_zstick:214d29fb)
zwave:device:214d29fb:node15 (Type=Thing, Status=ONLINE, Label=Kitchen Light, Bridge=zwave:serial_zstick:214d29fb)
zwave:device:214d29fb:node16 (Type=Thing, Status=ONLINE, Label=Kitchen Radiator, Bridge=zwave:serial_zstick:214d29fb)
zwave:device:214d29fb:node13 (Type=Thing, Status=ONLINE, Label=Office Fan, Bridge=zwave:serial_zstick:214d29fb)
zwave:device:214d29fb:node14 (Type=Thing, Status=ONLINE, Label=Bedroom Fan, Bridge=zwave:serial_zstick:214d29fb)
zwave:device:214d29fb:node58 (Type=Thing, Status=ONLINE, Label=Bedroom Radiator, Bridge=zwave:serial_zstick:214d29fb)
zwave:device:214d29fb:node11 (Type=Thing, Status=ONLINE, Label=Lounge Radiator Front, Bridge=zwave:serial_zstick:214d29fb)
zwave:device:214d29fb:node12 (Type=Thing, Status=ONLINE, Label=Kitchen Multisensor, Bridge=zwave:serial_zstick:214d29fb)
zwave:device:214d29fb:node10 (Type=Thing, Status=ONLINE, Label=Hall Lower Radiator, Bridge=zwave:serial_zstick:214d29fb)
zwave:device:214d29fb:node40 (Type=Thing, Status=ONLINE, Label=Bathroom Radiator, Bridge=zwave:serial_zstick:214d29fb)
zwave:device:214d29fb:node41 (Type=Thing, Status=ONLINE, Label=Bath Temp, Bridge=zwave:serial_zstick:214d29fb)
zwave:device:214d29fb:node80 (Type=Thing, Status=ONLINE, Label=Keyfob 1, Bridge=zwave:serial_zstick:214d29fb)
zwave:device:214d29fb:node81 (Type=Thing, Status=ONLINE, Label=Lounge Lamp, Bridge=zwave:serial_zstick:214d29fb)
zwave:device:214d29fb:node44 (Type=Thing, Status=ONLINE, Label=Hall Top Lamp, Bridge=zwave:serial_zstick:214d29fb)
zwave:device:214d29fb:node42 (Type=Thing, Status=ONLINE, Label=Bedroom Light, Bridge=zwave:serial_zstick:214d29fb)

OK I’ve done a reboot and captured the log, it wasn’t as big as I expected but still ended up being three files. There are several nodes now stuck in initialising, all stella-z radiator valves from Eurotronics. After rebooting I walked around every 15 minutes pressing the wake-up button on them all, and towards the end of the second log I was sat by one of them (node 4) pressing the button every 10-30 seconds or so but it never got past “DYNAMIC VALUES”. Node 4 was fully initialised yesterday.

Here’s the first log, the bundle restart (after a full machine reboot) happens at 12:58:35. This appears to be where all the action happens, the other two files appear to just have NIFs from the device and nothing useful from the z-wave bundle so probably no need for the other two:

zwave.log.1.gz.xml (540.6 KB)

The boot and 15-minute button-press round then continues through this one:
zwave.log.2.gz.xml (555.3 KB)

Finally my system settles down and starts to work in this log (about 1.5 hours after reboot) and the log ends shortly after I get bored tapping wakeup every few seconds on Node 4:
zwave.log.3.gz.xml (53.8 KB)

Right now, about 3 hours after reboot my system is working with little latency, that’s about how long it takes my system to recover from a reboot which apparently is unusual?

Other nodes that also didn’t finish initialisation are 29, 79 and 23, all Eurotronics Stella-Z radiators, all spent the last 2 hours having wake-up pressed every 15 mins, there are a further 7 of these devices which all completed their initialisation at the same time. All the stuck nodes are also known to have worked previously, the nodes which stick vary from boot to boot.

All the stella-z devices are set to wake up themselves every 10 mins in addition to me jabbing the button.

Sadly it looks like these Eurotronics devices just aren’t going to work properly. I’ve done a few more restarts of openhab with the devices being re-initialised but still winding up stuck partway through initialisation even with plenty of button pressing and a 10-minute wake-up period but right now, 3 of the 12 devices haven’t completed initialisation in the last two days or so, but a different three to the ones which previously didn’t work.

While I wait to gather the cash together to upgrade 12 radiators with different TRVs and bin these units, is there a way to trigger re-initialisation on some individual devices without a full openhab restart? If I restart Openhab then it will start re-initialisation on all the devices and I’ll end up with a different set of failed Eurotronics devices.

Sorry - I missed your response a few weeks back - you need to either reply to my message or mention me with @chris or I won’t get a notification.

Please can you try with the latest binding to see if it is any better. I did fix a bug a couple of weeks back related to battery devices.

OK I will, thanks. I don’t like pinging you directly as it seems a bit rude considering how much work you already have but I’ll do so if I get desperate in the future.

I’ll see if the new binding helps, although these devices have been a pain on Vera as well as all versions of OpenHab so I’m planning on doing a full refresh once I’ve played a bit more with this new Popp thermostat I have. I’ve had them since 2015 and they’ve never really been that good.

Thanks - I appreciate that. If you reply to one of my messages, then I still get the notification, and you don’t feel so rude :smile:.

Let’s see if this latest snapshot helps - I have some confidence it will help at least a bit, and hopefully a lot.