This message is not an error - it’s a debug message just indicating the state. It does not indicate a problem at all.
I see a lot of timeouts from node 11 so there is something wrong with that device! You can try a reset/reinclude to see if it resolves it, but the problem is the low level communication, and not the binding.
Other devices in the log appear ok.
I don’t think the issues you have with the “predicted” state is related to ZWave. It sounds like a new feature of the system. I was not personally aware of the link to the thing being offline - the offline state of things works basically the same as in OH1, but it seems that the framework is now trying to be a lot smarter, and this may be causing problems.
I assume you mean is there a way to get logs only from a certain device? If so, then just get the logs, and use the log viewer to view them. The viewer provides a means to filter logs on certain nodes.
Hopefully this question hasn’t been asked all too often. I think I remember that there is or used to be a problem setting up things via config files, and it has or had to be done via Paper UI. Is this problem gone with the latest version of the binding?
When upgrading from OH2.3 to 2.4, can I delete all Zwave things via Paper UI and after the OH update and binding installation add the exact definition via config files?
You can, but be aware that configuration parameters cannot be set/changed once you do this. Here is a post with detail, in a topic all about unmanaged zwave Things.
Ok, guess I’ll have to keep using PaperUI then 
Hi All,
Hope I don’t ask something that has been covered already - if so please forgive me.
With the release of 2.4 I was thinking of setting up a new Raspberry from scratch with OpenHABian and restore a V2.3 backup made accordingly to this approach.
Is this something that would work or would I again have to delete all Z-Wave things?
Would it make a difference if I would plug the controller in and install the Z-Wave binding before restoring the backup?
Having to delete all Z-Wave things (and probably Items as done via PaperUI) is something that really scares me…
Thanks a lot!
Chris
Nope, you still need to delete them as they were created on pre-2.4 OH.
But you can do that in the new system so you needn’t be afraid of breaking anything.
where can i download the actual snapshot version 2.4.0 of z-wave binding?
or does it still make sense to load the snapshot after refactoring? should the binding be loaded via Paper UI?
currently i don’t have any new z-wave devices and all existing devices ran with the development version
my openhab version: 2.4.0 (released version)
Because 2.4 is now the stable release, there are no more 2.4 snaphots.
That one was merged into 2.4 a while ago. So you should be good to go with the 2.4 zwave stable binding installed through PaperUI. Don’t forget to delete any zwave bindings in your addons folder.
thanks … is it necessary to re-integrate all devices when switching from development version 2.4.0 to stable version 2.4.0?
Nope. Only if your devices need to pick up changes from the database.
Hi,
I’ve managed to get the Danalock v3 working with the 2.4 addon - thanks! A minor issue though is that when the lock is activated from zwave I see this in the event.log:
2018-12-26 13:53:42.435 [ome.event.ItemCommandEvent] - Item 'DoorLock' received command ON
2018-12-26 13:53:42.444 [vent.ItemStateChangedEvent] - DoorLock changed from OFF to ON
2018-12-26 13:53:44.192 [vent.ItemStateChangedEvent] - DoorLock changed from ON to OFF
2018-12-26 13:53:44.595 [vent.ItemStateChangedEvent] - DoorLock changed from OFF to ON
That is fairly annoying as I obviously have different rules for the lock turning on and off. I have attached the zwave.log (87.1 KB)
. @chris, perhaps you can see what is wrong?
Try increasing the Command Poll Delay from 1500ms to (say) 2500 or 3500ms. The issue looks like with the delay in the security, the GET request is coming in before the lock has locked. Given that the lock also sends a notification, you could probably set this to 0 to disable it.
That did the trick. Thanks for world class support!
I updated OH2 to 2.4 today, removed all my Zwave devices per these instructions, and added everything back. All my devices EXCEPT my MiniMotes are working.
My Minimotes all show up as Unknown. They log in my zwave log, but I can’t reconnect them to Items since they’re Unknown.
26-Dec-2018 15:30:41.383 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - Initializing ZWave thing handler zwave:device:3bd809fb:node33. \u2502
\u250226-Dec-2018 15:30:41.390 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 33: MANUFACTURER not set \u2502
20\u250226-Dec-2018 15:30:41.390 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 33: Controller status changed to ONLINE. \u2502
20\u250226-Dec-2018 15:30:41.390 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 33: Controller is ONLINE. Starting device initialisation. \u2502
20\u250226-Dec-2018 15:30:41.400 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 33: Updating node properties. \u2502
20\u250226-Dec-2018 15:30:41.411 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 33: Updating node properties. MAN=2147483647 \u2502
20\u250226-Dec-2018 15:30:41.412 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 33: Properties synchronised \u2502
20\u250226-Dec-2018 15:30:41.419 [DEBUG] [ab.binding.zwave.internal.protocol.ZWaveController] - Event listener added. \u2502
20\u250226-Dec-2018 15:30:41.421 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 33: Initialising Thing Node... \u2502
20\u250226-Dec-2018 15:30:41.421 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 33: Polling intialised at 1800 seconds - start in 1760400 millisecon\u2502
20\u2502ds. \u2502
20\u250226-Dec-2018 15:30:41.421 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 33: Device initialisation complete.
Any tips/pointers/ideas?
Edit: I also made sure I updated to the very latest version:
openhab> bundle:update org.openhab.binding.zwave https://openhab.jfrog.io/openhab/online-repo-snapshot/2.4/org/openhab/binding/org.openhab.binding.zwave/2.4.0-SNAPSHOT/org.openhab.binding.zwave-2.4.0-SNAPSHOT.jar
>
openhab> bundle:list -s |grep zwave
248 \u2502 Active \u2502 80 \u2502 2.4.0.201812141755 \u2502 org.openhab.binding.zwave
I know people have had problems with these… The forum search is however your friend 
…
You should note that this isn’t the latest version. Not that this is probably related to your issue, but you have reinstalled 2.4 which will always remain the same. If you want the latest version, then you need to install the snapshot.
(again, this probably isn’t related to your problem, but I just wanted to point this out for information).
Try waking them up.
On a side note, I’m seeing them constantly in Request NIF again after a restart. @mhilbush, are you seeing this again too?
I thought I’d followed those directions, too… but it turns out I was pressing the wrong Minimote button to Exclude it, so I never actually got it excluded/re-included.
Note to Self: You have to use the Join button on the Minimote when you go into Exclude mode, not press just any button like on a normal Zwave device.
I got my Minimotes working again after Exclude/Include. Funny that they are the only devices that I had to go through special maneuvers with, but I guess that’s just the name of the game.
Mine are working fine. The only thing I need to do differently with these devices is manually wake them up after a restart. They never wake up on their own, so the only way to get them to initialize after a restart is to wake them up manually.