Testing Z-Wave binding on openHAB-2

[chris (Chris Jackson)]

@Christer_Akerlund I’ve updated the JAR with 4 more devices that I think are from you…

[shorty707]

@chris

Ok - that’s useful. Can you get a longer log please. I’d like to see what’s happening as we should see the different events I described above (update from UI, read the parameter from device, bit-magic, and then update)…

well there is not that much more to add.
I tried to remove and add that thing a couple times… because it seems to get corrupt (value for sound gets sticky)

currently the value is 515 (which must have been updated by the subparameters somehow)
when I try to update it again … lets say to value 10 … it just throws errors in log.
Habmin itself says updated successfully … by reloading (F5) the value 515 is again there

[chris (Chris Jackson)]

@shorty707

well there is not that much more to add.

I think that’s because you don’t have debug enabled…

The errors aren’t errors - they should be debug messages, but they are just logged incorrectly (which is useful, otherwise you wouldn’t have seen them ).

Any chance you can enable debug logging and repeat this?

[shorty707]

@chris

Any chance you can enable debug logging and repeat this?

sure thing I hope you find what you are looking for

12:43:32.134 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 2: Configuration update received
12:43:32.136 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 2: Configuration update config_37_2 to 12
12:43:32.137 [DEBUG] [class.ZWaveConfigurationCommandClass] - NODE 2: Creating new message for application command CONFIGURATIONCMD_SET
12:43:32.139 [DEBUG] [ve.internal.protocol.ZWaveController] - Enqueueing message. Queue length = 1
12:43:32.139 [DEBUG] [ocol.ZWaveController$ZWaveSendThread] - Took message from queue for sending. Queue length = 0
12:43:32.140 [DEBUG] [class.ZWaveConfigurationCommandClass] - NODE 2: Creating new message for application command CONFIGURATIONCMD_GET
12:43:32.141 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 0D 00 13 02 06 70 04 25 02 00 0C 25 79 E6 
12:43:32.141 [DEBUG] [ve.internal.protocol.ZWaveController] - Enqueueing message. Queue length = 1
12:43:32.143 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - NODE 2: Sending REQUEST Message = 01 0D 00 13 02 06 70 04 25 02 00 0C 25 79 E6 
12:43:32.155 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 04 01 13 01 E8 
12:43:32.208 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
12:43:32.209 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 04 01 13 01 E8 
12:43:32.211 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 04 01 13 01 E8 
12:43:32.215 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class = SendData (0x13), type = Response (0x01), payload = 01 
12:43:32.217 [DEBUG] [l.serialmessage.SendDataMessageClass] - NODE 2: Sent Data successfully placed on stack.
12:43:32.236 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 07 00 13 79 00 00 09 9B 
12:43:32.269 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
12:43:32.271 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 09 00 13 79 00 00 09 00 00 95 
12:43:32.319 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 09 00 13 79 00 00 09 00 00 95 
12:43:32.320 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class = SendData (0x13), type = Request (0x00), payload = 79 00 00 09 
12:43:32.321 [DEBUG] [l.serialmessage.SendDataMessageClass] - NODE 2: SendData Request. CallBack ID = 121, Status = Transmission complete and ACK received(0)
12:43:32.324 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Sent message Message: class = SendData (0x13), type = Request (0x00), payload = 02 06 70 04 25 02 00 0C 
12:43:32.332 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Recv message Message: class = SendData (0x13), type = Request (0x00), payload = 79 00 00 09 
12:43:32.335 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: class=SendData, expected=SendData, cancelled=false
12:43:32.337 [DEBUG] [.serialmessage.ZWaveCommandProcessor] -          transaction complete!
12:43:32.339 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveTransactionCompletedEvent
12:43:32.341 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 2: Got an event from Z-Wave network: ZWaveTransactionCompletedEvent
12:43:32.342 [DEBUG] [ocol.ZWaveController$ZWaveSendThread] - NODE 2: Response processed after 198ms/3763ms.
12:43:32.343 [DEBUG] [ocol.ZWaveController$ZWaveSendThread] - Took message from queue for sending. Queue length = 0
12:43:32.344 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 0A 00 13 02 03 70 05 25 25 7A E8 
12:43:32.345 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - NODE 2: Sending REQUEST Message = 01 0A 00 13 02 03 70 05 25 25 7A E8 
12:43:32.356 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 04 01 13 01 E8 
12:43:32.358 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
12:43:32.359 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 04 01 13 01 E8 
12:43:32.361 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 04 01 13 01 E8 
12:43:32.363 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class = SendData (0x13), type = Response (0x01), payload = 01 
12:43:32.365 [DEBUG] [l.serialmessage.SendDataMessageClass] - NODE 2: Sent Data successfully placed on stack.
12:43:32.465 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 07 00 13 7A 00 00 0B 9A 
12:43:32.467 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
12:43:32.468 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 09 00 13 7A 00 00 0B 00 00 94 
12:43:32.469 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 09 00 13 7A 00 00 0B 00 00 94 
12:43:32.471 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class = SendData (0x13), type = Request (0x00), payload = 7A 00 00 0B 
12:43:32.472 [DEBUG] [l.serialmessage.SendDataMessageClass] - NODE 2: SendData Request. CallBack ID = 122, Status = Transmission complete and ACK received(0)
12:43:32.474 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Sent message Message: class = SendData (0x13), type = Request (0x00), payload = 02 03 70 05 25 
12:43:32.475 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Recv message Message: class = SendData (0x13), type = Request (0x00), payload = 7A 00 00 0B 
12:43:32.476 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: class=SendData, expected=ApplicationCommandHandler, cancelled=false
12:43:32.492 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 0E 00 04 00 02 08 70 06 25 02 02 01 00 00 AD 
12:43:32.494 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
12:43:32.496 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 0E 00 04 00 02 08 70 06 25 02 02 01 00 00 AD 
12:43:32.497 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 0E 00 04 00 02 08 70 06 25 02 02 01 00 00 AD 
12:43:32.498 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class = ApplicationCommandHandler (0x04), type = Request (0x00), payload = 00 02 08 70 06 25 02 02 01 00 00 
12:43:32.499 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 2: Application Command Request (ALIVE:DONE)
12:43:32.500 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 2: Incoming command class CONFIGURATION
12:43:32.501 [DEBUG] [class.ZWaveConfigurationCommandClass] - NODE 2: Received Configuration Request
12:43:32.502 [DEBUG] [class.ZWaveConfigurationCommandClass] - NODE 2: Node configuration report, parameter = 37, value = 513, size = 2
12:43:32.503 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveConfigurationParameterEvent
12:43:32.504 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 2: Got an event from Z-Wave network: ZWaveConfigurationParameterEvent
12:43:32.506 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 2: Got a value event from Z-Wave network, endpoint = 0, command class = CONFIGURATION, value = org.openhab.binding.zwave.internal.protocol.ZWaveConfigurationParameter@b70fbc
12:43:32.506 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 2: Update CONFIGURATION 37/2 to 513
12:43:32.508 [WARN ] [ding.zwave.handler.ZWaveThingHandler] - NODE 2: Configuration invalid action_reinit
12:43:32.509 [ERROR] [ding.zwave.handler.ZWaveThingHandler] - NODE 2: Sub-parameter config_37_2 is 00000201
12:43:32.510 [ERROR] [ding.zwave.handler.ZWaveThingHandler] - NODE 2: Sub-parameter config_37_2 is 513
12:43:32.510 [WARN ] [ding.zwave.handler.ZWaveThingHandler] - NODE 2: Configuration invalid group_1
12:43:32.511 [WARN ] [ding.zwave.handler.ZWaveThingHandler] - NODE 2: Configuration invalid nodeid
12:43:32.636 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 0E 00 04 00 02 08 70 06 25 02 02 01 00 00 AD 
12:43:32.682 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Sent message Message: class = SendData (0x13), type = Request (0x00), payload = 02 03 70 05 25 
12:43:32.683 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Recv message Message: class = ApplicationCommandHandler (0x04), type = Request (0x00), payload = 00 02 08 70 06 25 02 02 01 00 00 
12:43:32.684 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: class=ApplicationCommandHandler, expected=ApplicationCommandHandler, cancelled=false
12:43:32.684 [DEBUG] [.serialmessage.ZWaveCommandProcessor] -          transaction complete!
12:43:32.685 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveTransactionCompletedEvent
12:43:32.685 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 2: Got an event from Z-Wave network: ZWaveTransactionCompletedEvent
12:43:32.686 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
12:43:32.686 [DEBUG] [ocol.ZWaveController$ZWaveSendThread] - NODE 2: Response processed after 340ms/3763ms.
12:43:32.687 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 0E 00 04 00 02 08 70 06 25 02 02 01 00 00 AD 
12:43:32.688 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 0E 00 04 00 02 08 70 06 25 02 02 01 00 00 AD 
12:43:32.689 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class = ApplicationCommandHandler (0x04), type = Request (0x00), payload = 00 02 08 70 06 25 02 02 01 00 00 
12:43:32.690 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 2: Application Command Request (ALIVE:DONE)
12:43:32.691 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 2: Incoming command class CONFIGURATION
12:43:32.692 [DEBUG] [class.ZWaveConfigurationCommandClass] - NODE 2: Received Configuration Request
12:43:32.692 [DEBUG] [class.ZWaveConfigurationCommandClass] - NODE 2: Node configuration report, parameter = 37, value = 513, size = 2
12:43:32.693 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveConfigurationParameterEvent
12:43:32.694 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 2: Got an event from Z-Wave network: ZWaveConfigurationParameterEvent
12:43:32.694 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 2: Got a value event from Z-Wave network, endpoint = 0, command class = CONFIGURATION, value = org.openhab.binding.zwave.internal.protocol.ZWaveConfigurationParameter@b70fbc
12:43:32.695 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 2: Update CONFIGURATION 37/2 to 513
12:43:32.696 [WARN ] [ding.zwave.handler.ZWaveThingHandler] - NODE 2: Configuration invalid action_reinit
12:43:32.697 [ERROR] [ding.zwave.handler.ZWaveThingHandler] - NODE 2: Sub-parameter config_37_2 is 00000201
12:43:32.698 [ERROR] [ding.zwave.handler.ZWaveThingHandler] - NODE 2: Sub-parameter config_37_2 is 513
12:43:32.698 [WARN ] [ding.zwave.handler.ZWaveThingHandler] - NODE 2: Configuration invalid group_1
12:43:32.699 [WARN ] [ding.zwave.handler.ZWaveThingHandler] - NODE 2: Configuration invalid nodeid
12:43:32.862 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Sent message Message: class = SendData (0x13), type = Request (0x00), payload = 02 03 70 05 25 
12:43:32.864 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Recv message Message: class = ApplicationCommandHandler (0x04), type = Request (0x00), payload = 00 02 08 70 06 25 02 02 01 00 00 
12:43:32.864 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: class=ApplicationCommandHandler, expected=ApplicationCommandHandler, cancelled=false
12:43:32.865 [DEBUG] [.serialmessage.ZWaveCommandProcessor] -          transaction complete!
12:43:32.865 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveTransactionCompletedEvent
12:43:32.866 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 2: Got an event from Z-Wave network: ZWaveTransactionCompletedEvent

[chris (Chris Jackson)]

@chris

for me on chrome this button comes up but there is no response when clicking it neither is it copied to the clipboard.

Hmmm - this does seem to be broken. I’ll take a look since it was working a few days back…

This will be fixed in the next update. Note that it requires a recent version of most browsers (Chrome 43+, Firefox 41+, Opera 29+ and IE10+) and doesn’t appear to work in Safari (at least not on the version on my Mac ).

EDIT: I’ve updated HABmin JAR…

[chris (Chris Jackson)]

@shorty707

sure thing I hope you find what you are looking for

Currently, this is not configured as a set of sub-parameters - it’s just the normal parameter. My guess of what’s happening is that the device is rejecting the setting of value 12 since it’s invalid. The documentation says that parameter 37 contains the sound in the lower byte, and this can be 0 to 5, so a value of 12 is not valid.

It’s then returning the value of 513 (hex 201), which is its current setting. This is a volume level of 2, and a sound value of 1).

What I’ll do is configure this channel to use sub parameters and we can try this again

[shorty707]

@chris

The documentation says that parameter 37 contains the sound in the lower byte, and this can be 0 to 5, so a value of 12 is not valid.

am I misenterpreting the documentaton? I thought the values there are already decimal
and I just can enter something like 31 to have the siren in mode sound no 3 and vol, 88db

[chris (Chris Jackson)]

Yes - you are misinterpretting this. Check the diagram just above this in the document - it shows that value 1 is the low byte, and value 2 is the second byte. The table you have shown here also says this (although it says value 2 is the high byte which isn’t strictly correct).

This emphasises why we need sub-parameters - this can be confusing to people who (mostly ) know what they are doing, let alone beginners…

Can we continue this sub-parameter discussion on the linked thread -:

Z-Wave Sub-parameter testing

Continuing the discussion from Testing Z-Wave binding on openHAB-2: @shorty707 I’m starting a new thread on this just to avoid confusion in the main ZWave test thread… I’ve now configured the siren to use sub-parameters -: [image] The original parameter 37 I made an advanced parameter so will only be shown if advanced mode is enabled. In theory, you should now be able to control the sound and the volume separately without having to deal with bitshifts, hex numbers and other fun conversions …

[Christer_Akerlund (Christer Åkerlund)]

No worries, i was just looking for a way to make troubleshooting easier.
Is there any way to check? Are the xml files embedded in the jar or are they merged into some other format?

/C

[Christer_Akerlund (Christer Åkerlund)]

Awesome!
Thanks

/C

[chris (Chris Jackson)]

@Christer_Akerlund

Is there any way to check? Are the xml files embedded in the jar or are they merged into some other format?

The files are in the JAR so you can look there if you really want…

If you just want to know what’s included, then use the manual thing add button (in HABmin, it’s the + at the top of the config page). This will give you a list of all the things that the zwave binding supports…

[Christer_Akerlund (Christer Åkerlund)]

Ah true! Thanks.

/C

[Kai (Kai Kreuzer)]

@shorty707

however an update button would save a click and execute both steps on its own … or even an option for auto update

Yes, would both be nice, but will mean quite some efforts. So for the time being, the extra click is hopefully acceptable

[xsnrg (Jim)]

@chris

Good question… It’s something I’ve thought a bit about, but not come to a conclusion… Do we set ‘default’ to the manufacturers default value, or do we set it to a user value that is better… At the moment, I don’t try and set any configuration when the device is initialised, so it doesn’t really matter…

I like the idea of a community defined default value that is applied when a device is initialized. One device comes to mind instantly that is completely worthless without setting a new value. In many other cases changing the value enables more or all features of a multi device than what you would otherwise have in the manufacturer default.

There are a couple options. The easiest is the person editing the device database entry can simply change the default and the binding can load all the defaults when a device is initialized.

Another option - perhaps a custom field in the database that if it exists, only that parameter is changed in the device by the binding at initialization. This would be a little more work, but would only update settings that the community would have wanted changed.

The third option was described by another user previously. Simply make the description to contain some sane options for the parameter. For example, I worked on the Aeon water sensor to map the bits into some of the possible settings and in the description simply said if you want it to work this way, set this parameter to X, and if you want it to do that, set it to Y. The disadvantage here is a user is required to set a parameter on the device before it does anything at all in the case of tthis device.

Other ecosystems set these parameters when the device is added and the user never knows otherwise. This is nice for a user experience as long as all the features are enabled.

[Christer_Akerlund (Christer Åkerlund)]

How about community presets, like Factory default, All enabled etc… They would be usable only from habmin i guess but thats not so bad.

[chris (Chris Jackson)]

I think the answer lies in implementing a few options…

@xsnrg

Other ecosystems set these parameters when the device is added and the user never knows otherwise. This is nice for a user experience as long as all the features are enabled.

Yes - and I think we should also do this to get the device working in the first place. The first time the device is added as a thing we should configure it so that it works in some ‘standard’ way…

@xsnrg

The third option was described by another user previously. Simply make the description to contain some sane options for the parameter. For example, I worked on the Aeon water sensor to map the bits into some of the possible settings and in the description simply said if you want it to work this way, set this parameter to X, and if you want it to do that, set it to Y.

This is also valid under all circumstances since it provides the user options depending on how they might want to configure it. This sort of thing can easily be added now into the Overview are in the parameter (similar sort of thing to what @shorty707 did above).

The more I think about it though, for the ‘initial standard configuration’ it’s probably best to have a separate field in the database so it’s clear what it’s for…

[chris (Chris Jackson)]

@Christer_Akerlund

How about community presets, like Factory default, All enabled etc…

Hmmm - now that’s an interesting idea . This is very flexible as it builds on what @xsnrg mentioned above, but I’d need to think about how that fits into the database since it’s likely more work…

Leave that one with me - I like it if it’s not too much work…

[bhuism (Bas Huisman)]

I just installed org.openhab.binding.zwave_2.0.0.201602211459.jar, I see that my 4 greenwave one port’s socket switches are not regognised (my 6 port version is nicely recognized and working):

2016-02-21 16:43:50.615 [WARN ] [wave.discovery.ZWaveDiscoveryService] - NODE 3: Device could not be resolved to a thingType! 0099:0002:0002::4.21
2016-02-21 16:43:50.615 [WARN ] [wave.discovery.ZWaveDiscoveryService] - NODE 7: Device could not be resolved to a thingType! 0099:0002:0002::4.27
2016-02-21 16:43:50.621 [WARN ] [wave.discovery.ZWaveDiscoveryService] - NODE 12: Device could not be resolved to a thingType! 0099:0002:0002::4.21
2016-02-21 16:43:50.623 [WARN ] [wave.discovery.ZWaveDiscoveryService] - NODE 6: Device could not be resolved to a thingType! 0099:0002:0002::4.28

I do see them in the database here: http://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-list/devicesummary/102.

I have NS310 types. I see them in Habmin as unknown with no channels. Are they included in the newest jar? thanks!

[chris (Chris Jackson)]

@bhuism

I have NS310 types. I see them in Habmin as unknown with no channels. Are they included in the newest jar?

It looks like the problem is they are defined for a different version of the firmware than yours (version 3.0 to 4.0 and you have a number of versions around 4.2).

I’ll remove this constraint - it probably doesn’t matter. There will no doubt be an update in an hour or three…

[bhuism (Bas Huisman)]

A, that explains it then, thanks!