Readd your device thing and adopted the new channels you may see that behaviour.
The channel for switch and dimmer itemtype is now switch_dimmer1 and is instantly updated through the binding and through the pyhsical switch.
Actually it is working 100% correct for the first time since I have this device
Can anyone suggest what I should look for it my Zwave device pairs fine with the controller, is visible (at least for a little while in OH2) but then subsuquently is offline constantly? despite being powered by mains? Its a problematic Aeotec Dimmer Nano, which I wonder is faulty?
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.
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.
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…
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
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.
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.
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.
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).
, the darn channel names had changed!!!
…