Testing Z-Wave binding on openHAB-2

[shorty707]

@chris

CRC3100

that xml was uploaded by me… anything I can do? cant see from the DB what information is vital to be added?

[vespaman (Micael)]

Is the XML the same as before? I don’t suppose there’s anything captured in the log anywhere (maybe grep on NodeNamingCommandClass)?

Yes, still NODE_NAMING.
Thankfully, my shell had it. Or at least I guess this is where it happens!

This log contains the whole transaction from waking to going to sleep again, it was a lot, so the forum wouldn’t allow me to paste.

https://drive.google.com/open?id=0B1-V_L_iOMcSa1R3ZXJGNHR6VDg

[chris (Chris Jackson)]

@shorty707

I added a “recommended” column to the table … and tried to make a demo calculation how this is donehowever that should be posted somewhere else …

I like the table with the detailed information

However, I’m still keen to split these parameters out into separate parameters, then none of this should be necessary (assuming we can get it to work!).

As an example, I’ve add two sub-parameters to parameter 7 to show you what I mean -:

Inside the binding, it does (hopefully ) some magic to stick all this back together! When you update one of these parameters, it detects that they are only part of a parameter. The binding first requests the current value from the device, then does the ‘bit magic’ with the bitmask to put all the right bits in the right places, and then sets the parameter…

This should also work with longer data - eg I’ve seen a Vision siren that has both volume and ‘ringtone’ in a single parameter - we can split these into separate sub-parameters each 8 bits long…

This is something that I’ve not tested yet, so I’d welcome any feedback on wether or not this is a good idea - does it help avoid confusion by eliminating all the bit shifts and bin->hex->dec conversions, or does it confuse matters?

[shorty707]

@chris

Instead of having a dropdown within the dropdown (which would be difficult), we split out the parameters, so, bit 1 becomes a config parameter, bit 2 becomes a separate parameter, and the bitmask in the database is used to split them out…

for my Aeon Siren I cannot change the parameter for Sound and Volume

log says something about that sub parameters

11:50:07.657 [ERROR] [ding.zwave.handler.ZWaveThingHandler] - NODE 2: Sub-parameter config_37_2 is 00000203
11:50:07.658 [ERROR] [ding.zwave.handler.ZWaveThingHandler] - NODE 2: Sub-parameter config_37_2 is 515

[chris (Chris Jackson)]

@shorty707

cant see from the DB what information is vital to be added?

The error is at the top of the page …

I suspect we’re missing some command classes. Currently, the only ‘user’ class is BASIC and I suspect this device supports more than this. We could link a channel to this class, but I don’t think it would work (or at least not well - you might be able to get one button working)…

Looking at the manual, it’s missing multilevel_switch and central_scene I think. There may be some more thought required about how to incorporate the scene class into the binding though, so even adding this today won’t make it immediately work…

[chris (Chris Jackson)]

@shorty707

for my Aeon Siren I cannot change the parameter for Sound and Volume

log says something about that sub parameters

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

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