We tested grabbed the current code in the svn this afternoon and built/installed it. As far as we can tell so far... we cant tell the difference between your new code and the RC2 z-wave binary... which is very nice indeed!
Yeah, the drop in replacement capability is one of my requirements :-)
We have some ACT wall switches that we use to control the state of other load controlling z-wave modules. If we use these wall switches to change the state of the controlled load controlling z-wave modules we do not see this change reflected in the DB or the floorplan. Is there some specific way we need to pair the wall switches to the load baring modules or is it just the case that currently this capability is not implemented?
The older plugs from ACT supported associations in group 1 for that. The newer ones don't support that. But they send an unsolicited node information frame _sometimes_ when operated locally. If the dongle receives that it queries the level and state from the device. I'm still investigating why they don't send it all the time.
After spending a bit on the homeseer and other forums, it depends on the switch type if they work "bidi". It is not a protocol issue. The vendor has to send a node information or support associations to allow bidi.
In terms of the unimplemented features listed above in your post from the 13 July can you update us on what is now working?
* Basic wake-up handling (queue is still missing)
- queue is implemented: if you send a command to a sleeping device (like a PIR), it is queued until the device sends a wake-up notification. The commands are then moved to the send queue, and it sends a wake-up-no-more-information as last command to make the device fall asleep again.
There is one problem with that at the moment, the Z-Wave spec is a bit problematic: there can be sleeping devices that have the "listening" bit set in the node-protocol-info response. So we don't know which are sleeping devices until we get a wake-up notification from a device.
* Download configuration
- implemented. For now it has a hard-coded 60s time slot where the controller replication is enabled. It works best if you start the replication on the primary remote first, and then send the download config command to lmce.
* Multi command handling
- basic bits are there for the ra-plus-w. But there is another challenge. If there are more than one commands on the wake-up queue for a device, they should be concatenated into a single multi command.
* RA-plus-w setback schedule thermostat support
- talking to the device works. I'm just thinking about some final implementation decisions. It will only work in SIS mode. If we are not the primary or SIS we don't see the specific type when fetching device info from the chip. So there is no way to know it is a setback schedule thermostat (that needs multi-command and wake-up settings). This is no real problem as SIS will be supported soon and this is the recommended mode from danfoss. Should work ootb with automatic configuration in a week or two.
* Merten Dongle support
- I must know which usb/rs232 chipset is in there. My best guess was some ezusb stuff. But trying to load usbserial or the ftdi driver with the proper usb ids did not work (the usbserial created 6 ttyusb devices, all not working :-)
* Multilevel sensor support
- I'm awaiting a test sample from Seluxit. This should be a quick one.
* new stuff not listed in the old post:
- Primary mode with AddNodeToNetwork and RemoveNodeFromNetwork implementation. You can also add a ZTH (or other controller) as secondary. Run the AddNode command and do a replication in receive mode on the ZTH. I do not transfer any group information atm (was thinking about automatically grouping lights by rooms), but it is included and you can set up groups on the remote manually.
There is also a new "high power" mode (reported in the homeseer forum), where you don't have to be close to the devices when adding them (in direct reach, of course no routing). That would be nice for small homes as you don't need a remote. Unfortunately only brand new devices from some manufacturers support it and I have no information about that mode, so this is postponed at the moment. Without that mode and a static controller (and all "regular" [read: non-ztrollers whatever] usb dongles are static controllers) the primary mode has limited usage as you can't test-bench z-wave and the distances are too high in a regular flat for low power adding :-)
- SIS (node id server) mode with inclusion controllers. Code is there. Sadly enough the ACT ZTH remotes don't support "inclusion mode" as their library version is too old. They work as secondary remotes in SIS mode. I'm awaiting a Tricklestar remote with a brand new chipset. That should work as inclusion controller. No need to do download configuration any more in that mode. And we have the best possibilities to automatically configure the devices at inclusion, as we get the complete node information frame and the device is awake (if battery powered).
- Implemented proper callback handling. If we don't get confirmation on zw-send (from the device itself, not the z-wave stack on the dongle), it times out after 3 seconds and tries three retries to prevent stalling. Needs a bit of fixing (for other commands than zw-send), but works great for a first try.
Great work by the way...we have 10 devices in our test z-wave network (all lights currently...will try an ACT PIR tomorrow) and the performance excellent and stability was 100% :-)
I've sent over 20 thousand commands with the new driver. I'm sure there are still bugs and some bits need to be cleaned up. But for a first try it behaves pretty stable. Be aware, only the wake-up interval of the PIR gets configured automatically. You have to do the mode setting manually (both work, sensor and binary).
best regards,
Hari
