Author
Topic: ZWave API (Read 72321 times)

Domodude

I will receive a usb dongle and the remote in about two weeks. I'll keep you posted on the details.

Excellent! Great work, it seems everytime I log in there is good news from the Zwave department I am happy that Z-wave is catching on so well in Europe, with new products added frequently. Hopefully that will also do good things with the pricing level of most z-wave devices at this moment.Mark

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!

We have tested 'All on' and 'All off' from the ACT remote and the state change for all devices was correctly reflected in the DB and on the floorplan... also very nice :-)

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?

In terms of the unimplemented features listed above in your post from the 13 July can you update us on what is now working?

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% :-)

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 :-)

Quote

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.

Quote

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.

Quote

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).

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.

Ok some further feedback on the above issue;

After resetting the Seluxit Home Controller from Wen Admin and then downloading the device data again from the ACT remote (using your code this time... before the data was from the original RC2 binary)

We have now confirmed that if we use the button on the remote ACT slaved modules to change the state of the module this is dynamically displayed in the floor plan... :-)

But the paired wall switches do not get their state updated... for the reasons you have already explained.

Howeve we can now use the floorplan to control a ACT direct load switch successfully... :-) However if we use the waal switch to change the state this does not get reflected on the floorplan strangely. Still this is nice progress!

Hari we just downloaded that latest revision and built it here and the fix for the direct load wall switches work great!!!! Takes about 6-7 secs for the state of the wall switch to be reflected on the floorplan.

Cool work!

Now we are testing the wall switches that are not controlling a direct load but are paired to control other plug in dimmer modules. When we use the paired wall switch the light responds correctly but the floor plan does not update still. When we look in the logs it appears that a command class is not implemented currently...

I have attached the ZWave.log to a separate email as attachments dont seem to be working here in the forum for me at present (the last entries in the log refer to the paired switches controlling a remote plugin module by the way).

Hari we just downloaded that latest revision and built it here and the fix for the direct load wall switches work great!!!! Takes about 6-7 secs for the state of the wall switch to be reflected on the floorplan.

when I've fixed another issue with the callback handling this should be faster (about a second)

Quote

Now we are testing the wall switches that are not controlling a direct load but are paired to control other plug in dimmer modules. When we use the paired wall switch the light responds correctly but the floor plan does not update still. When we look in the logs it appears that a command class is not implemented currently...

Yeah. This is because we receive the info frame from the remote switch and not the controlled slaves. My plan is to either read the associations from the device and query the targets, or to associate ourself into the groups to catch the command. Btw, the double paddle remote switch only sends a node info frame when the left paddle is pressed. Nothing happens with the right paddle. So maybe the association approach is the better one..

Now we are testing the wall switches that are not controlling a direct load but are paired to control other plug in dimmer modules. When we use the paired wall switch the light responds correctly but the floor plan does not update still. When we look in the logs it appears that a command class is not implemented currently...

Yeah. This is because we receive the info frame from the remote switch and not the controlled slaves. My plan is to either read the associations from the device and query the targets, or to associate ourself into the groups to catch the command. Btw, the double paddle remote switch only sends a node info frame when the left paddle is pressed. Nothing happens with the right paddle. So maybe the association approach is the better one..

Quote

Hi Hari,

We're using rev 21378 now.

We have paired our wall switches to control the ACT Dimmer Modules in our test setup as reported above. But now with rev 21378 we do not see any activity in the logs at all when we change the state of one of the controlled modules using a paired wall switch.... we see no log traffic at all related to the module turning on/off.