Ok, this is not a ZWave Plus device, so doesn’t have a Lifeline group. The Controller update group is the same though, so make sure the controller is set to group 3.
1 Like
Understood thanks.
Short question: when I’ll have the new S5 (and I will put the S5 in the usb port instead of the old S2, so the S2 will be offline), do I need to exclude all zwave devices before? or simply I will include those in the new S5 controller? Simple search, or do I need to follow the manual inclusion (3 times the button in 3 secs)?
thanks for your support
Andrea
If you’re swapping controllers, then it’s probably easiest to exclude the devices, and reinclude them into the new network. It is possible to transfer the network over, but unless you have a large network, I (personally) think it’s better to reinitialise and have them join the new network.
1 Like
At the moment I have the new OH version, the old controller ONLINE, a new controller in Inbox (as the new zwave binding is ready), and all zwave devices in UNINITIALIZED status
So the steps should be:
- ignore the new ZWave USB Dongle (CP2102 USB to UART Bridge Controller) (that is in facts the old controller)
- remove all Things
- remove the Zwave binding
- reinstall the Zwave binding with S2 still in
- at this moment I should have the old controller ONLINE, and all nodes to be added again
- add all nodes, then exclude with HABmin
or simply:
- remove S2 and put S5 in
- remove all things
- remove Zwave binding
- reinstall the Zwave binding, and re-add all nodes
?? what I’m missing?
For the records.
SOLVED with new S5. Everything is looking good for the moment. No issues at all. All devices seem reporting data correctly. Also some zwave+ devices
thanks
Andrea
1 Like
I did switch my openhab installation to snapshot and updated the binding as advised which is remove all things except controller, uninstall + reinstall binding. Then I had to reboot because serial port was not found but now my “sensative window strip” which is node 002 (which is correct) reports as “Unknown Device”.
Log shows:
2018-09-17 08:12:17.576 [arthome.event.BindingEvent] - org.openhab.binding.zwave.event.BindingEvent@ba8243
==> /var/log/openhab2/openhab.log <==
2018-09-17 08:12:19.599 [WARN ] [wave.discovery.ZWaveDiscoveryService] - NODE 2: Device discovery could not resolve to a thingType! Manufacturer data not known.
==> /var/log/openhab2/events.log <==
2018-09-17 08:12:19.619 [home.event.InboxAddedEvent] - Discovery Result with UID 'zwave:device:81ab7676:node2' has been added.
==> /var/log/openhab2/openhab.log <==
2018-09-17 08:12:19.617 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'zwave:device:81ab7676:node2' to inbox.
How to fix this?
Sensative strips require some patience, it could take some while before they are fully synchronized. You could speed it up by waking it up (by placing the magnet near the rounded edge three times) though. Repeat that procedure a few times and see if it helps 
Unfortunately even with using the new dev version of the zwave bindung I have a problem with my qubino window shutter. Was the same with stable version too.
I often see this message in the logs, sometimes even the device goes offline then:
==> /var/log/openhab2/events.log <==
2018-09-17 09:08:53.764 [hingStatusInfoChangedEvent] - 'zwave:device:81ab7676:node4' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): Node is not communicating with controller
Any idea on how to proceed with this?
These devices typically only wake up every 24 hours, so you either need to wake them manually by waving the magnets around in the appropriate place, or possibly wait a few days for it to initialise.
This typically means that the device is not responding to commands that are sent. Possibly it is too far from the controller.
That’s very unlikely, it’s about 50cm away from the controller stick and the commands are working mostly (strangely sometimes even if device is reported as beeing offline) and the device is mains powered. I have other devices which are even battery powered which are farer away which have no nissues at all. Can I verify this somehow if it’s really too far away?
Please check the debug logs then - otherwise we are guessing. All I can say is that this means that the device is not responding the commands that are sent - for some reason or other.
Hi,
Can you provide me the log file please?
Chris
There are some devices that were recognized but stopped being recognized after the update. These are battery operated Z-Wave devices that worked before the upgrade. Any hints on these.
Furthermore I have a device (FGWP102 Metered Wall Plug Switch) that says controller is offline. In the scripts though the device still works, and I am able to turn on and off the lights being controlled by it through panels and scripts.
Wake them up - they will need to be woken to allow them to be discovered.
I would suggest to check the logs. If it’s offline, then it probably means that the device is not responding - or more correctly, that the binding is not getting the responses. RF can easily work well in one direction, and not at all in another, so this might explain it. Or it might be something else - but the debug logs should help here.
I don’t know - we’re just guessing. If it’s not being recognised, then it means that the binding is not talking to it to download all the information it needs, and this is normally caused by the device not waking up.
Your issue (with the binary sensor not reporting) sounds dfferent to @robjkamp (where the device is not recognised).
If you provide me a log, I will have a look, but I’m afraid without a log I’m at a loss to tell what is happening and we’re just guessing.
As I asked in post #96, I need the logfile please? Some sort of web archive of the webpage is not really very useful to me.
Have anyone tried with 50+ zwave sensors togheter with 200 other sensors on zigbee/433, enocean, bluethoth and so on in one house?
I have been using Openhab since 1.8 and with the old z-wave driver and used Chris binding since 1 year ago. But still i have strugle with speed (can take 1 sec to turn off light, and can take 10 sec). Sometimes the device is not in the network anymore, and need to learn it again, sometimes my fibaro smoke/water stops reporting temp all of the suddent and i have many more strange things.
I have tried to start from scratch many times, this last time with openhabian and the old driver, updated now since it seems to be working good for most of you guys, but i still see this issues. This time i also needed to copy/paste xml for 10 devices. Even power devices 10cm from my GW was not learn correct, and was unknown since for 13 days. With power devices it seems like it did not know what more to do, in logs every wake up was “update thing” but next step never happend.
Anyone that have seen the same issues? is the Z-wave network to big?
I had about 120 powered and over 50 battery zwave devices running for a while.
But a few months ago I swapped out all but a couple of the battery devices for Xiaomi Zigbee devices.
What I noticed was that with all the battery operated devices on the network I was constantly having issues with response time, memory usage and eventually stability of Openhab itself and I was having to reboot at least once a day to restore the system and the zwave network.
Since removing the battery devices, responsiveness and stability have improved immensely and I only very rarely end up needing to restart Openhab.
I must admit I also moved almost all my rules to node-red over the past few months as they were also using a significant amount of memory and performance was poor.
So Openhab is running much leaner. z-wave is now mainly powered devices like switches, motor controllers, wired in AEON multisensors and AEON light bulbs. Response time is normally within a second or two although occasionally get slow, this would be when I look to restart Openhab.
But I now also have fewer occasions of devices reporting not responding to the controller and most of those are older modules.
1 Like
You can revert back to the 2.3 binding by installing it, and reinstalling all the things again (Effectively reversing the process).
Note that the old binding doesn’t support locks, so it won’t work there either.