Z-Wave setup

[alf]

Hi everybody,

So, I'm new here. I have installed DomotiGa and intend to manage a z-wave network. I have installed DomotiGa and Open Z-wave, using Aeon Lab Z stick. So far, for test purpose, I have only included one light dimmer in my network.

When using Z-Wave commander I can control the light but when I am back in DomotiGa main windows, in the tab control, nothing happens when I try to change the light.

Another issue is that when I do a change from the Zwave commander, device status is not properly updated, even after clicking the refresh button.

I guess there is something wrong in my setup but I struggle to fix it.

Thanks for you answer

[emvee]

Already solved?

If not, try to delete the device in the DomotiGa device windows and then enable under Setup -> Main the "Auto Device Create" checkbox. Restart DomotiGa, wait until the device is added and try again.

Hope this helps.

[alf]

So the issue is partially solved. I have re-installed the last version of Domotiga (1.0.015) from scratch and also installed RRDtool that I missed in the former installation. Now Z-wave works in the way that I can interact with the z-wave devices from the control tab.

Then I must say that the behavior is quite erratic :
I start the software with light off, in the control tab the dimmer track bar is on 0, and device is off in the device grid. A this point everything looks fine.
Then, I click on the button in the control tab. Light switch on, but the track bar stays at 0 (maybe after jumping briefly somewhere), in the devices grid, the dimmer value is off, even after refresh. In z-wave commander, the dimmer status is off.

Then I slide the track bar to a higher value, nothing happens. I move it a bit further, light intensity is adjusted but the track bar jump away from where I have clicked and reported value looks far from the real light value. And so on.

So I have made some progress but I can not say that it works. Sorry for the late answer, I have been away for a while and not able to answer.

[raymonvdm]

Is it working when you set the device to an on/off device and not a dimmer device ?

[alf]

So far, I have two nodes in my network :
- Fibaro dimmer FGD211
- Everspring Dimmer AD142

I have noticed that the Fibaro Dimmer was not properly recognised because the id doesn't exist in the manufacturer_specific.xml. I have changed this file so that it uses the configuration file for the previous version of this device. Then I have removed the zwcfg*.xml file and restarted Domotiga. The device appears to work properly (but sometime it is not responding any more, neither from domotiga nor from the button).

I have also seen that the table devices_zwave is empty. I don't how how to deal with this.

About the AD142, looking at the debug log, it looks like the device report its old state at each change. That is why I get this erratic behavior. The state is correctly updated (so for example the light is on 50%) but the devices reports "Off" after the change, so domotiga shows it is off. So it seems that the issue comes from the device itself but I don't know how to fix it

[emvee]

I have noticed that the Fibaro Dimmer was not properly recognised because the id doesn't exist in the manufacturer_specific.xml. I have changed this file so that it uses the configuration file for the previous version of this device.

Could it be that your version of open-zwave is too old that the Fibaro Dimmer was not properly recognized? If not, it is probably good to open a with the changes you had to make ticket on https://code.google.com/p/open-zwave/issues/list so the release can be updated.

About the AD142, looking at the debug log, it looks like the device report its old state at each change. That is why I get this erratic behavior.

Which debug log are you looking at? domotiga/logs/debug-2014-0?.log or domotiga/wrappers/domozwave/OZW_Log.txt?
The last one is probably the better one to look at as it gives low-level information.

[alf]

I have updated open-zwave and the Fibaro module is now recognized. As far as I can see, it works properly.

About the AD142, I was looking at the debug log inside Domotiga. I have had a look at the OZW_Log.txt but it is a bit too obscure for me. I have joined a sample below. At the beginning light is off and track bar level is zero. I move the trackbar to a given level (should be 70), the light is on to the specified level but the track bar moves back to zero.

Code: Select all

2014-06-16 22:55:41.341 Node003, SwitchMultilevel::Set - Setting to level 70
2014-06-16 22:55:41.342 Node003, Queuing (Send) SwitchMultiLevel Set (Node=3): 0x01, 0x0a, 0x00, 0x13, 0x03, 0x03, 0x26, 0x01, 0x46, 0x25, 0x44, 0xe6
2014-06-16 22:55:41.342 Node003, Queuing (Send) SwitchMultilevelCmd_Get (Node=3): 0x01, 0x09, 0x00, 0x13, 0x03, 0x02, 0x26, 0x02, 0x25, 0x45, 0xa0
2014-06-16 22:55:41.342 
2014-06-16 22:55:41.342 Node003, Sending (Send) message (Callback ID=0x44, Expected Reply=0x13) - SwitchMultiLevel Set (Node=3): 0x01, 0x0a, 0x00, 0x13, 0x03, 0x03, 0x26, 0x01, 0x46, 0x25, 0x44, 0xe6
2014-06-16 22:55:41.348 Node003,   Received: 0x01, 0x04, 0x01, 0x13, 0x01, 0xe8
2014-06-16 22:55:41.348 Node003,   ZW_SEND_DATA delivered to Z-Wave stack
2014-06-16 22:55:41.360 Node003,   Received: 0x01, 0x05, 0x00, 0x13, 0x44, 0x00, 0xad
2014-06-16 22:55:41.360 Node003,   ZW_SEND_DATA Request with callback ID 0x44 received (expected 0x44)
2014-06-16 22:55:41.360 Node003, Request RTT 17 Average Request RTT 17
2014-06-16 22:55:41.360 Node003,   Expected reply was received
2014-06-16 22:55:41.361 Node003,   Message transaction complete
2014-06-16 22:55:41.361 
2014-06-16 22:55:41.361 Node003, Removing current message
2014-06-16 22:55:41.361 
2014-06-16 22:55:41.361 Node003, Sending (Send) message (Callback ID=0x45, Expected Reply=0x04) - SwitchMultilevelCmd_Get (Node=3): 0x01, 0x09, 0x00, 0x13, 0x03, 0x02, 0x26, 0x02, 0x25, 0x45, 0xa0
2014-06-16 22:55:41.366 Node003,   Received: 0x01, 0x04, 0x01, 0x13, 0x01, 0xe8
2014-06-16 22:55:41.367 Node003,   ZW_SEND_DATA delivered to Z-Wave stack
2014-06-16 22:55:41.379 Node003,   Received: 0x01, 0x05, 0x00, 0x13, 0x45, 0x00, 0xac
2014-06-16 22:55:41.379 Node003,   ZW_SEND_DATA Request with callback ID 0x45 received (expected 0x45)
2014-06-16 22:55:41.379 Node003, Request RTT 18 Average Request RTT 17
2014-06-16 22:55:41.385 Node003,   Received: 0x01, 0x09, 0x00, 0x04, 0x00, 0x03, 0x03, 0x26, 0x03, 0x00, 0xd7
2014-06-16 22:55:41.385 
2014-06-16 22:55:41.385 Node003, Response RTT 23 Average Response RTT 23
2014-06-16 22:55:41.385 Node003, Received SwitchMultiLevel report: level=0
2014-06-16 22:55:41.386 Node003, Refreshed Value: old value=0, new value=0, type=uint8
2014-06-16 22:55:41.386 Node003, Changes to this value are not verified
2014-06-16 22:55:41.386 Node003,   Expected reply and command class was received
2014-06-16 22:55:41.386 Node003,   Message transaction complete
2014-06-16 22:55:41.386 
2014-06-16 22:55:41.386 Node003, Removing current message

[emvee]

The OZW_Log.txt show exactly the behavior you describe:

• Controller sending a SwitchMultiLevel Set with level 70 that is Acked
  Controller sending a SwitchMultilevelCmd_Get for which the AD142 returns, what it seems, level 0.

Things are done pretty quick after each other, but that should be no problem I think.
When you enable polling, do you see that with a later poll, the correct level (70) is returned?

Seems not like a openzwave problem, maybe contact Everspring?

[alf]

I have tried to change the poll setting (in Open Z-Wave setting, "Deprecated poll setting = 500") but no success.

So far as I understand, the AD142 has a strange behavior.

[uAlex73]

The behaviour sounds like:
- Current dim value is 0%
- Set dim value to 70%
- Request is send to open-zwave library "SetValue to 70"
- The open-zwave will queue this request, BUT also will queue a GetValue request
- The SetValue is executed, within milliseconds the GetValue is also executed
- This way to fast for the dimmer and it still reports the "old" value (or 0 in some cases)

It is more a timing issues of the GetValue and the device isn't reporting fast enough the Dim value ... With dimmers you can also have a behaviour like 0 - 20 - 30 - 50 - 70%, so intermediate steps (also not nice).

As a sort of workaround, you can modify your zwcfg*xml and change the dimmer the multilevel switch line verify_changes="false" to verify_changes="true". This should improve the behaviour, but it isn't perfect. 9 out 10 will work, BUT still a timing issue if 2 polls will report the same value.

BTW: Possible the deprecated poll setting isn't working, i will recheck it in the code and fix it if needed (i am not yet 100% awake - but i can't find a certain line in the code ).

[uAlex73]

Ok, the legacy polling was broken. I fixed it in the beta, which will be released soon as 1.0.016. With a new and shiny Open Z-Wave Commander