I really can’t see how that’s possible. If the controller is saying that there’s a device, the binding should report it - can you provide a log of the startup please and I’ll take a look.
I’ll send a log next restart… but I did a replace failed on that node about 2-3 months ago and haven’t seen any oddities since, other than the locks that were reincluded and won’t send alarms (likely association issue)…
If you mean that the device in the database doesn’t have the secure class, I wouldn’t read too much into this - if the person adding it wasn’t using a secure binding, then it may not have been added.
I would suggest to check the manuals to see if the configuration is the same (parameters and groups). If it is, then just use the same database entry - otherwise a new one will be required.
I’m not sure how to verify the color set configuration as it’s not in the manual, it only calls out using any of the myriad of zwave apps to do this. Based on the xml file it appears to need the color switch command class. I’m assuming it’s using that entry from your database since it comes up with 4 channels; but when I link a color item to the color channel it gives me that error. Not sure what I need to do to fix this.
Thanks for your help.
Don’t worry about this - it will be standard. The big question is the configuration parameters and groups.
I guess I’m uncertain what you’re telling me to do. The settings appear to match the zwave specs properly but do not list a few features that seem to be included in the database entry that exists. I’m unsure if you’re saying this is not linked to the database entry from your site as previously I believe that would come up as a unknown device. This comes up known and identified, the brightness dimming works properly as-is. I just can’t set the color without getting that error. What do I need to do?
Considering the manufacturer and type match whats in the database I’m sure that’s what’s linked. It just doesn’t work for the color channel. As I said I link an item:
Color RGBFDoor “RGB Front Door” [ “Lighting” ]
To the color channel and then try to pick a color and get the error:
2017-12-09 12:57:49.296 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 29: Command received zwave:device:c0ffedad:node29:color_color --> 348,64,100
2017-12-09 12:57:49.297 [DEBUG] [ternal.converter.ZWaveColorConverter] - NODE 29: Unknown color mode null.
2017-12-09 12:57:49.297 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 29: No messages returned from converter
It’s nothing to do with the specs. The configuration parameters are device dependant and are normally specified by the manufacturer.
Ok…
In the database, there is an area called Configuration Parameters -:
This information comes from the device manual -:
Question - is it the same for the two devices…
So the manufacturer, device id and device type are all the same? Then I’m not quite sure what the issue is anyway… 
Thats my point, it’s very strange and I have to figure maybe never fully worked when originally added to the database? Something with the color channel is fubar’d. Or I don’t understand what should be linked to control it. Is there a way to email “Honey Yin” who added/updated it?
As for the entries, it’s almost an exact match but the database entry has a few advanced features my manual doesn’t list (for instance parameter 51 and 61). Considering they are the exact same model number and revision I expect it’s the same. I think this is a case of a chinese product being remanufactured or rebadged for other brands.
Also note Color temperature seems to work. Just not Color Control.
The database was not configured correctly - I’ve fixed this now.
It would be great if you can fix the other errors in the database for the device 
Done and review requested. Thanks. Now to wait for another database update. What was the error in the color config? I see it looks a little different but am unsure what change you made.
Thanks - I’ll do an update again in the morning (UK time).
The error was the missing colorMode setting (so colorMode=RGB was needed as an option).
I have an issue after upgrading to the latest Openhab (2.2.0~20171209104822-1) combined with the latest zwave development binding. The polling is not working for any of my channels. I can get things to work by removing the channel link and creating the same channel link. I diff’ed the ItemChannelLink.json files with the backup and noticed that there was a new section under channelUID that existed for all my channels except for the zwave channels:
"configuration": {
"properties": {}
},
I thought I was onto something so I modified the JSON file to add the missing section to all my zwave channel links. Editing the file was far quicker than going through the UI because I have so many channels. However, no such luck. Polling does not work after restarting. Removing the channel link and adding it back fixes polling, but it does not work after a restart. Any ideas? I can include a log if necessary. I just didn’t know what the procedure was since it has a secured device of mine in it.
Hi Chris - just wondering if there was any update on making COMMAND_CLASS_BASIC work (e.g. with the Fibaro universal sensor)
thanks,
Dan
This was mentioned elsewhere as well. I wonder if ESH has changed something - the binding only enables polling for channels that are linked - it seems that this still works, but the link method maybe isn’t being called under some circumstances now.
I’ll add another log entry when this is called so we can see it, and if it’s not being called, then we probably need to raise this with ESH.
I’ll do a binding update this morning…
Sorry Dan - can you refer me to the discussion on this. Was it related to the association issue we had on the device?
I’ve updated the binding and added two new log entries -:
NODE {}: Channel {} linked - polling started.
(and a corresponding one for stopped).
Let’s see if this shows up in the log - I suspect it doesn’t link on startup, but let’s see.
I think it’s unrelated, but caused by new fibaro firmware which uses the basic command class
See: Fibaro universal binary sensor - very confused
and perhaps also Fibaro FGS-213 (relay switch) problems
Not seeing polling started. Here is the output for one of my lights:
2017-12-10 10:38:44.568 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 47: Polling intialised at 300 seconds - start in 300000 milliseconds.
2017-12-10 10:43:44.569 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 47: Polling...
2017-12-10 10:43:44.569 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 47: Polling deferred until initialisation complete
2017-12-10 10:48:44.569 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 47: Polling...
2017-12-10 10:48:44.569 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 47: Polling deferred until initialisation complete
Also, my previous workaround of unlinking the channel and linking it again does not seem to be working. I don’t think your logging change would have broken this so maybe there are other startup issues. I have to head out for a bit. I can try some more things later.
Just linking in this thread in case it helps…
@chris, do you know why with the latest code I am getting that error? It looks like the new binding automatically adds the node somewhere that I can’t figure out so that when it finds it in zwave.things I get a Duplicate channels error. I have nothing in json config for that thing, where else could the duplicate channel be?