[SOLVED] Z-Wave Binding Issues with Channels Using COMMAND_CLASS_CONFIGURATION

This means that the binding hasn’t got as far as reading the configuration - this is one of the last things it does as part of the initialisation process.

This is because you are using the standard export, not the export for the development version. This will have a number of mismatches. I didn’t realise you were on the dev version as the bug I fixed in the converter to fix the channel export did not exist in the development version anyway…

So does this now mean that everything is in fact working? There’s no problem with the Decimal type - you can link it to many different item types and it works with the config parameter ok?

This all makes more sense now. When I had channels working earlier, it must have been that initialization was complete. In one of the times it should have been working, it had not worked for several hours, so maybe something had just hung up the initialization.

This makes me think I have a completely wrong understanding of the database export process. What I did was use the export feature on the database website choosing openHAB2. What should I have done in this case?

Yes, for my purposes it’s functional. Thank you for your help and patience. I still suspect that anyone using this device will have problems linking items to channels via the GUI, but I guess that’s not really a binding problem. I will point out that in the cases where there is a channel-type at the end of the XML file with an item-type of “Number”, the channel shows up in the GUI as “Number” and thus no linking problems. It looks like the pattern is that the database exporter is creating these only for channels having defined options. If it could generate these for others that don’t (Volume and Repetitions), it would workaround the GUI problem.

Why is this? If it worked for you, why is there a problem?

This is true, but if it doesn’t work it’s often the binding that gets blamed so I’d like to understand if there’s an issue still :wink: .

From memory, A Decimal type, which is extended by Percent and Number should work NumberItem, DimmerItem, RollerShutterItem, and possibly others. I’m happy to be told I’m missing something here, but I’d like to try and understand why it doesn’t work.

Correct. If there are no options,then it can use the standard channel - there’s no need to create extra channels in this case.

If there’s a GUI problem, then it should be reported and fixed though right? We shouldn’t mess up the binding and add hundreds of extra channels in order to work around a GUI problem (IMHO anyway).

I effectively had to workaround the GUI linking issue by using items files.

I’m probably not in a good position to tell exactly where the problem lies and it may even be debatable. All I can really see is that the UI shows the channel as using a Decimal type and in those cases I can’t create and link a compatible channel through the UI.

I would still like to know how to export the database appropriately. Can you point me to a resource?

But if there’s an issue, it would still be good to raise it so that someone can work out what’s wrong.

Sorry - it’s not easily possible at the moment for the development version. Once the development version is merged, then it will be available in the existing place.

I’d be happy to file an issue. Should I file it against the openHAB repository on GitHub?

Probably it’s best to start with ESH as PaperUI is mainly developed there.

Please post a link to the issue here as well as I’d like to keep an eye on it - just in case there’s something wrong in the binding (although if it can be linked in the item files, then I’d be surprised :wink: ).

Thanks.

Thanks. So this does appear to be an issue with the binding incorrectly defining the Decimal item type - what has thrown me is that it seems to be possible to link to the unknown type using the item files - are you really sure that this actually worked? If so, that would also be a bug in the system.

The two that would potentially be problematic are Volume and Repetitions. I just confirmed that they are both working as intended.

In case it’s any help, here is a debug log of setting the volume back to 10 from 1:

I have the text log too, but it’s too large to upload.

Any ideas how long this should typically take for an AC powered device? Since I tested out the Color Command changes for EzMultiPli, I also got the change which makes the ZW056 Channels be Number type. However, I’m back in this state where it’s reporting “Config parameter 6 not found in converter”.

It should be super quick - although it depends on your network size. If it’s taking more than a few minutes, and you don’t have hundreds of devices, then there’s probably something else happening and you should check the debug logs.

It’s been over an hour and I only have 10 devices, so I’ll start digging :slight_smile:

It should take “seconds” - let’s say less than a minute from the binding starting… Grab a debug log and check what’s happening there…

The part that looks relevant to me is this, but I don’t see any issues:

2018-07-15 12:25:05.428 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 17: Initialising cmd channel zwave:device:937956ae:node17:config_decimal_param8 for DecimalType
2018-07-15 12:25:05.440 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 17: Initialising state channel zwave:device:937956ae:node17:config_decimal_param8 for DecimalType
2018-07-15 12:25:05.440 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 9: Initialising cmd channel zwave:device:937956ae:node9:switch_binary for OnOffType
2018-07-15 12:25:05.441 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 17: Initialising cmd channel zwave:device:937956ae:node17:config_decimal_param2 for DecimalType
2018-07-15 12:25:05.441 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 17: Initialising state channel zwave:device:937956ae:node17:config_decimal_param2 for DecimalType
2018-07-15 12:25:05.441 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 17: Initialising cmd channel zwave:device:937956ae:node17:config_decimal_param6 for DecimalType
2018-07-15 12:25:05.441 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 17: Initialising state channel zwave:device:937956ae:node17:config_decimal_param6 for DecimalType
2018-07-15 12:25:05.442 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 17: Initialising cmd channel zwave:device:937956ae:node17:config_decimal_param80 for DecimalType
2018-07-15 12:25:05.442 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 17: Initialising state channel zwave:device:937956ae:node17:config_decimal_param80 for DecimalType
2018-07-15 12:25:05.442 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 17: Initialising cmd channel zwave:device:937956ae:node17:config_decimal_param42 for DecimalType
2018-07-15 12:25:05.442 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 17: Initialising state channel zwave:device:937956ae:node17:config_decimal_param42 for DecimalType
2018-07-15 12:25:05.428 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 14: Initialising cmd channel zwave:device:937956ae:node14:switch_binary for OnOffType
2018-07-15 12:25:05.443 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 14: Initialising state channel zwave:device:937956ae:node14:switch_binary for OnOffType
2018-07-15 12:25:05.443 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 14: Initialising state channel zwave:device:937956ae:node14:switch_binary for OnOffType
2018-07-15 12:25:05.444 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 17: Polling intialised at 1800 seconds - start in 99000 milliseconds.
2018-07-15 12:25:05.444 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 17: Device initialisation complete.

This is not related to the configuration update - this is part of the thing initialisation.

If you want to email me a longer log (10+ minutes at least) then I’ll have a look. Anything up to ~10MB should be fine.

Sent, thank you.

Well, no sooner than I sent that I did see this message right near the top of that log:

2018-07-15 12:25:00.129 [WARN ] [ore.common.registry.AbstractRegistry] - ItemChannelLink with key ‘Annunciator_Play -> zwave:device:937956ae:node17:config_decimal_param6’ already exists from provider GenericItemChannelLinkProvider! Failed to bulk-add a second with the same UID from provider ManagedItemChannelLinkProvider!

But then things a little later look normal?

2018-07-15 12:25:00.504 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 17: Channel zwave:device:937956ae:node17:config_decimal_param6 linked - polling started.

The log wasn’t so useful as the device initialisation was already completed earlier and just restored from XML. The binding therefore did not download all the configuration, and hence I don’t get to see what’s happening…

As there has been a lot of messing around over the past few days, I’d suggest to reinitialise the device - there’s an option in HABmin menu to do this. It will erase the XML and download everything again. If the problem persists after this, then please send me the debug log for the reinitialisation and I’ll take a look at that.

I looked all over for such an option and just can’t seem to find it. Can you point me in the right direction, please?