Ijust checked and I think the database was exported after than device was changed. It is usually exported about once a week.
The easiest way to update the binding is with the install script. you then need to delete the Tghing from OH (NOT exclude) and rediscover it to get the new settings.
What version of script and where are the logs? My guess is that you supplied the wrong password the first time when you got an error about the serial transport. Rather than hijacking this topic, it would be better to troubleshoot this in your own topic or the script topic.
I would strongly suggest not to post direct links to SNAPSHOT files like this - in a couple of weeks this will no longer work and people will ask the same question again after trying to follow your dead link.
What version of openHAB are you running?
Why do you think you need the latest stable jar? Usually if needing updated device support people need the latest snapshot which is easiest to get with the install script. The snapshot version of the zwave binding is extremely rarely broken.
I have had this happen 3 times now. Some background is I had some ghost devices I could not get rid of. I hadn't done much automation yet inside Hubitat so I decided to rebuild from my system from scratch. Removed everything and did full Z-Wave reset and reset on Hub. I then added most of my devices back in (around 40). I first noticed this happen a week or so later when trying to add in a device and it would not pair. I checked and found the list blank. I still see all the devices under the device section and automation still work. So shutting down the hub and powering off for a few minutes does fix this. However this is the third time it has happen now in a couple weeks. Restarting does not fix the issue. Only full shutdown and pulling power. Should I try doing a Z-wave repair.
The one time I've had this happen to me was immediately after the 7.17 upgrade, but IIRC there have been instances where a device caused a similar issue; in my instance a power down restart corrected it. Your devices look good, so I'm going to bow out and let HE Master Jedi @bobbyD do his magic.
Soft Reset is not very likely to bring a Z-Wave radio back online. When devices are not listed in Z-Wave Details table, power cycling the hub by shutting it down from Settings and unplugging it for 30 seconds when the led on the hub turns red may help. If the problem persists, you are likely dealing with a hardware malfunction and the hub will need to be replaced.
Hi,
I'm experiencing a similar issue. None of my z-wave devices show up on the z-wave details page. They are all on the devices list.
Here's the sequence of events that occurred prior to the disappearance:
-update the hub to latest firmware ca 1 week ago.
-added new IKEA motion sensors (Trdfri & Vallhorn), updated firmware on those.
-started migrating zigbee bulbs & 1 dimmer switch from Philips Hue Bridge to Hubitat due to issues w/Hue Bridge
-paired new IKEA trdfri outlets & zigbee repeaters to support the zigbee bulbs.
-added automations for the bathroom with a motion sensor & 2 bulbs.
Yesterday evening the lights I have in the kitchen (on 2 Qubino mini dimmers) started flashing and doing weird things. I tried to do some troubleshooting, but it was late and I couldn't find an obvious answer. I decided to do a z-wave repair, started after 11pm.
When I woke up the repair was complete, but the z-wave details page was empty, and the z-wave dimmers in the kitchen were completely unresponsive. Another Fibaro 2 dimmer in an adjacent room was also unresponsive. Ie, the physical switches work, but none of these respond to commands from Hubitat. None of my other z-wave devices seem to be communicating with Hubitat, including 4 Aeotec multisensors & an Aeotec nano switch.
I just finished wiping the database, restoring the hub to previous firmware & a backup from a week ago. I then updated firmware again to the latest. Unfortunately the devices are still not showing up under z-wave details. They're also not communicating with Hubitat.
The suggestion of the power down and unplugging for 10+ seconds is the only way to bring it back.
A Soft Reset and local backup restore does not touch anything on the Z-wave radio, so that does not help.
yes, I did a shutdown and unplug before I wiped the database & restored. Forgot that in my sequence of events. But I shutdown. Left it for ca 30 min. unplugged for 30-60 sec. then plugged in again. Then when the z-wave details page was still empty I did the wipe & restore.
One last thing I thought of, how is the hub being powered? The supplied block or PoE with a splitter? If you are using PoE, switch to a regular 1a power block. That issue however usually causes an issue 100% of the time, and would leave z-wave partially functional, not dead.
I just this this the other when I was testing the rolling back and upgrading firmware on a Vera 2.
One of the Vera 2 were migrated to Vera 3. This is unit one I performed it on, so it was the same situation and conditions as described.
Reset factory defaults will not reset the z-wave dongle and therefore, must reset your z-wave network. This did not interfere with my Vera 3 configuration or any z-wave devices because it is only performing the reset on my Vera 2.
This is similiar to what I did for you to test your iPad connection but you can either leave it associated to your current account (allow quick switching between unit from with in the UI) or remove it after step three is completed.
Note: Once you logged into your unit, on the top left of your browser it displays the current unit name, if you have multiple units, if you click on this, it will display a drop down list of all your units and their current IP address.
ZWave is a wireless home automation protocol with reliable two way communications between nodes. It supports a mesh network where mains powered nodes can route messages between nodes that could otherwise not communicate with each other. The network supports hop distances of up to four hops.
A wide range of devices are supported from lights, switches and sensors to smoke alarms, window coverings and keyfobs. Z-Wave certification guarantees that certified devices will be compatible with each other and the network.
The binding uses a standard Z-Wave serial stick to communicate with the Z-Wave devices. There are many sticks available, and they all support the same interface so the binding does not distinguish between them.
The ZWave binding provides support for a large number of devices (currently 802 devices from 114 manufacturers).See the full list of supported things. Note: As of OpenHAB 4.1 Controllers based on Silabs SDK 7 are partially supported.For SDK 7 controllers "Classic" inclusion (node numbers 1-232) is supported, but the higher power Long Range inclusion (node numbers over 255) is not.
Once the binding is authorized, and an adapter is added, it automatically reads all devices that are included into the network. This is read directly from the Z-Wave controller and new things are added to the Inbox. When the discovery process is started, the binding will put the controller into inclusion mode for a defined period of time to allow new devices to be discovered and added to the network. Device discovery occurs in two phases - first the device is added to the inbox as an Unknown Device to provide the user immediate feedback that the device has been discovered. Once the device type is known, the inbox entry is updated with the actual device name and manufacturer.
When Controller Is Master is true, the binding expects to be the main Z-Wave controller in the system. This is not related to the type of controller (Primary or Secondary), but is related to how devices will be configured. This will instruct the binding to perform configuration of the device to send network related information such as device wakeup to the binding.
Many functions in Z-Wave only allow a single node to be set, and this is normally reserved for the main system controller. For example, battery device Wakeup Node, and Lifeline association groups usually only allow a single device to be set.
The secure command classes allow you to secure communications between devices in your network. Secure communications is a good thing, and for devices such as locks that protect the security of your property, it's mandatory. However, most devices support the same communications and functions over the standard communication classes, without security. The secure classes come with some negative points - they communicate more slowly, and consume more power in battery devices. This is because there is roughly twice as much communication required for the security classes. You should therefore consider if you need all devices secured, or if it is acceptable for your system to only secure entry devices.
This sets the maximum time that the controller will remain in inclusion or exclusion mode. Once inclusion is enabled, it will be disabled either when the first device is discovered, or when the timeout occurs. Generally this should be kept to a minimum as it increases the opportunity for unwanted nodes to be included into the network.
This sets the maximum awake time for battery nodes (in seconds). This should be set high enough to allow initialization and healing to proceed uninterupted by a "Go to Sleep" command. The "Go to Sleep" will normally be sent much earlier (when the device is fully initializated and no messages remain in the device queue). This is just a backstop for when Zwave communications breakdown between the controller and the device. (see #### Message Routing)
This sets the system wide default wakeup period. If a battery device does not have the wakeup period set to a value, then the system will configure it to use this value during the device configuration.
There are a large number of things supported by the Z-Wave binding, so configuration can not be covered here and you should refer to the device manual. A summary of supported devices can be found here and this links to the list of configuration parameters the binding provides.
3a8082e126