ZWave binding updates

Nope. Only if your devices need to pick up changes from the database.


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.

1 Like

That did the trick. Thanks for world class support!

1 Like

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      
openhab> bundle:list -s |grep zwave
248 \u2502 Active   \u2502  80 \u2502     \u2502 org.openhab.binding.zwave

I know people have had problems with these… The forum search is however your friend :slight_smile:

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.

Yep. Of all my zwave devices, these easily are the most problematic.

Yes, but I thought Chris had worked out not initializing devices with wakup interval = 0. Hmmm…

He did, but I don’t think it works for the Minimotes. It’s on my list to try to debug, but it’s so far down on the list I forgot about it. LOL.

1 Like

That explains it. I remember testing the change though and it was working properly. This may be a regression.

Possibly so. At restart, or reinitialization, the Minimote sits at REQUEST_NIF until it’s manually woken up.

@chris: Could you find anything or do you need more information?

In the meanwhile I upgraded to 2.4 stable, and I still get this error message:

2018-12-25 10:43:14.069 [ERROR] [core.thing.internal.ThingManagerImpl] - Exception occurred during notification about bridge status change on thing 'zwave:device:gehirn:node13': 1
java.lang.ArrayIndexOutOfBoundsException: 1

Sorry - I missed that (it was when I was travelling to the US).

What device is node 13?

Thanks for taking care of it.

It is a ZD2102-5 Door Window Sensor.

Thanks. I’ve updated the database to hopefully fix this. I’ll do a binding update tonight, so it should be in tomorrows snapshot.


I’ve had FIBARO Dimmers and switches, and other z-wave devices, in my install since at least 2.2, and generally, have received ‘real time’ updates to values such as watts, kWh, etc. that were seen in logs and persisted through to my persistence DB - great for graphing, etc. (was able to prove the lower costs of running heat-pump vs traditional clothes dryers, etc.).

Since 2.4.0 update, I get very occasional value updates from the devices. When I moved to 2.4.0, I built the OH instance from scratch, re-added the devices and copied across any config files for non-zwave devices, and scripts, etc. due to the new architecture.

Are there any config items I’ve missed to get back the level of value updates that I had prior to 2.4.0