-
-
Notifications
You must be signed in to change notification settings - Fork 915
FAQ
We will try to answer common questions and issues here in this FAQ.
In OZW we maintain a Device_Database of all Devices that have been tested and work with OZW. Its possible your device is a new device we have not come across yet. Depending upon how conform-ant the device is to the Z-Wave Spec and how configurable it is, Adding the device to our database can be a simple one line change, to adding a complex xml file describing the devices configuration and quirks.
For instructions on adding devices, please consult this page
This is a known issue - You can track updates at issue 111
Sometimes when a perform a action in my Application, it takes anywhere from several seconds to several minutes before the device response
This can be caused by a number of issues:
- you should ensure that OZW has fully started up. During the startup phase, OZW can be busy querying the capabilities and latest values from nodes. OZW has probably received your command, but has queued it up to be sent out, and the reason it takes a while, is your command would most likely be at the end of the Queue. You should ensure that OZW has fully started up (in our Code we emit at AllNodesQueried(_SomeFailed/_asleep) Notification that indicates OZW is ready for "normal" operations. Trying to do anything before that can take a while.
We are investigating reducing this startup time (or eliminating it completely), but this might take a while todo.
-
Your Network might have what I term "unhealthy" devices. When I say unhealthy, I mean that devices that might have quirks in the way they support Z-Wave, and thus, often don't work reliably. The problem with this, is that these devices can "block" OZW for upto 120 seconds (by not acknowledging or sending correct replies). You can see if this is the case, by searching the OZW_Log.txt file for "Retries" or "Timeout". If you see this happening often with a single device, you should check for updated versions of OZW (or at least the Device_Database) to see if these quirks have been fixed, and if not, report to our Mailing List.
-
You are Polling Lots of Values - Polling should be a last resort for getting "updated" values from devices. Unlike modern Wifi, Z-Wave is a low bandwidth protocol. If you are polling to much, then you might be putting a lot of stress on your network. Polling was implemented in OZW to support devices that did not have the option to automatically report updates etc, and should only be used for those devices.
Most devices on the market now days support reporting real time updates via Associations (and in OZW, we always try to add the Controller node to these associations automatically). For other devices, that say report temperature or environmental data, most of the time, you can configure them to automatically push "updates" to your application, rather than have OZW pull the updates. You should consult the Configuration Options for your device in your application, and also consult the user manual that comes with your device to see if you can configure it.
Polling Security enabled Devices (such as door locks etc) is going to be even worse. In Secured devices, for every command we transmit, we have to exchange 2-3 additional packets before hand. Due to the tight timing requirements for the Security Class, these messages "jump the queue" so to say, and thus would starve the rest of the normal classes on OZW. (Additionally, most Security Devices, such as Door Locks are battery powered - Polling them is a great way to start investing in battery companies - As you are going to use lots of batteries)
- The device you are attempting to talk to is Battery Powered and supports the Wakeup Class. These devices are not always listening to the network, so if you send them a command (or request a updated value), OZW can't actually transmit it till the device "wakes up". Wakeup times are generally configurable, but again at the expense of battery life. Most of these devices will wake up and send update messages when a certain action occurs (such as detecting motion) but will not accept new commands till their wakeup time expires.
Sometimes you can manually wakeup the device by hitting a button etc on the device. This might only be useful during start-up phase if you quickly want the device to wake up and appear in your application.
-
First thing you should do is use our Log Analyser. This will parse the OpenZWave Log file and look for common issues, and provide some recommendations. Please create a account on http://openzwave.com/ and follow the instructions at http://openzwave.com/log-analyzer to create a log file you can then upload for analysis.
-
If the Log Analyser does not provide a solution, please search our mailing list. Chances are someone else has also encountered a similar issue.
-
If your still lost, then feel free to ask on the mailing list.
A) Read This - http://www.openzwave.com/knowledge-base/slowresponseduringstartup
- Chances are, yes. You can do a quick search of this file to see if the device is listed, but even if its not, 90% of its functionality should work without us having to add it to the file. Go ahead and test it. If it works, you can move onto the next question/answer.....
- Sure - Please read this: https://github.com/OpenZWave/open-zwave/wiki/Adding-Devices
-
Did you follow the instructions here (https://github.com/OpenZWave/open-zwave/wiki/Adding-Security-Devices-to-OZW) for adding your secure device? - Security Devices have some extra steps that need to be done during inclusion that cannot be done via inclusion buttons on keyfobs or the Aeon Z-Stick.
-
As Security support in OZW is still relatively new, and more and more devices are appearing that support security, there is still some more work to be done to make it robust. You should search the mailing list for your device to see if its been discussed already.
-
Thats Great! But we really do not have the time to hand hold everyone that wants to use OZW. If you are just starting out with OZW, then the basic MinOZW (included in the distribution) will get you started on how to do some very basic reading of Values on a Z-Wave device. If you need more advanced examples, there are lots of apps on places like GitHub and Google Code that use OZW that you can consult.
-
You did read the developer API Documentation didn't you? While not perfect, its covers around 99% of the API you will ever need.
-
Probably Not. A fundamental feature of Z-Wave is called Associations that few people take the time to understand. At a minimum you should ensure that the Controller Node ID is in the relevant Association Group for that device.
-
Some "poorly" (our assessment) implemented devices send what's called a Basic Set message to OZW when their state changes. Basic Sets are as the name implies very simplistic and often cannot convey the exact change on the device. This requires OZW to requery the state of the device, which introduces some latency. If your device is battery powered, this latency can extend for a few hours(!) as the device is asleep and OZW is waiting for it to wake up. Where possible, you should select devices that send full featured CommandClass Reports to association Groups, or at least let you configure what is sent to a Association Group. Avoid Battery Powered Devices that only support Basic Set to association groups, as these will not work that well.
-
You can read more about the limitations of the Basic CommandClass here https://github.com/OpenZWave/open-zwave/wiki/Basic-Command-Class
- Consult the link in the answer to the Question "OpenZWave takes forever to start up" above.