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