dotMorten
commented
7 years ago Questions here are ok.
The wrapper is just that: A wrapper of the native OpenZwave library. You'll need to manage the node events and maintain the list. I'll probably keep it that way. As you can see in the native doc, no such method exists to get all the nodes: http://www.openzwave.com/dev/classOpenZWave_1_1Manager.html
However as you point out the Node class in the demo app is quite useful, and I am working with an idea to make a second library that sits on top which simplifies the use, has simple events, async methods for querying nodes etc etc.
There's a good overview of the concepts of the manager and the library behavior here: http://www.openzwave.com/dev/
This is also a good tidbit from the OpenZWave doc:
Manager
The main public interface to OpenZWave.
A singleton class providing the main public interface to OpenZWave. The Manager class exposes all the functionality required to add Z-Wave support to an application. It handles the sending and receiving of Z-Wave messages as well as the configuration of a Z-Wave network and its devices, freeing the library user from the burden of learning the low-level details of the Z-Wave protocol.
All Z-Wave functionality is accessed via the Manager class. While this does not make for the most efficient code structure, it does enable the library to handle potentially complex and hard-to-debug issues such as multi-threading and object lifespans behind the scenes. Application development is therefore simplified and less prone to bugs.
There can be only one instance of the Manager class, and all applications will start by calling Manager::Create static method to create that instance. From then on, a call to the Manager::Get static method will return the pointer to the Manager object. On application exit, Manager::Destroy should be called to allow OpenZWave to clean up and delete any other objects it has created.
Once the Manager has been created, a call should be made to Manager::AddWatcher to install a notification callback handler. This handler will receive notifications of Z-Wave network changes and updates to device values, and is an essential element of OpenZWave.
Next, a call should be made to Manager::AddDriver for each Z-Wave controller attached to the PC. Each Driver will handle the sending and receiving of messages for all the devices in its controller's Z-Wave network. The Driver will read any previously saved configuration and then query the Z-Wave controller for any missing information. Once that process is complete, a DriverReady notification callback will be sent containing the Home ID of the controller, which is required by most of the other Manager class methods.
[After the DriverReady notification is sent, the Driver will poll each node on the network to update information about each node. After all "awake" nodes have been polled, an "AllAwakeNodesQueried" notification is sent. This is when a client application can expect all of the node information (both static information, like the physical device's capabilities, session information (like [associations and/or names] and dynamic information (like temperature or on/off state) to be available. Finally, after all nodes (whether listening or sleeping) have been polled, an "AllNodesQueried" notification is sent.]
yesyesuk
Hi, I'm quite new to Z-Wave and this library/wrapper.
Is there a way to get a list of nodes from the manager? I couldn't find a method that would do this. I noticed that the demo app keeps its own list of nodes and their ValueIDs. However, the manager must have an internal list of nodes as far as I can tell since there are methods to get information about nodes if you know their NodeID and HomeID. What is the reasoning behind this?
Also, the Node class in the demo app looks rather useful and even necessary. Why is this not part of the wrapper?
Lastly, is there a better place to ask these questions as they are not really issues/bugs? Should I still use the OpenZWave Google group (now that the wrapper is a separate project)?
Thanks, Chris