You can’t add battery channels - they magically (should!) add themselves when the BATTERY command class is found.
The database has a list of command classes that are considered “user” classes and only these classes can have channels added.
What do you mean by “Association CC”? The command classes aren’t listed anywhere I can think of - do you mean the association configuration parameters? If so I don’t know why they would be treated any differently to any other parameter - HABmin and PaperUI don’t have any specific handling for these…
ZWave devices will act differently depending on how they are included. It’s still the same device, but because it’s not securely included, it’s not presenting the secure command classes. You need to reset it, and try another secure inclusion.
Really? Man… I thought all those stories about magical channels were just faerie tales! This whole time I’ve been thinking all channels needed to be manually added. It’s all starting to make sense now! Maybe they could be a shimmery iridescent color, so we all know which ones are magical?!
Well… unless they are secret magical…
Yeah, the association configuration parameters for all my devices disappeared. This persists even after several OH restarts.
Sorry, but this isn’t correct - you’re not looking at the right code. This feature is only available in the development version and you’re not looking at that version. You need to use node_id.
Please see the testing that was performed previously here -:
Hi @chris i read the writeup and its well done. Followed it perfectly.
Unfortunately, “node_id” didnt work. nor did “nodeid”, “zwave_nodeid”, “zwave_node_id”. Also tried with and without quotes on the Number values (to make em strings and ints). Also tried upper and lower cases.
I’m not sure why this is to be honest. node_id is what the binding is looking for, and it certainly used to work. The binding doesn’t know (or care) if this is specified in a file, or through the UI - it looks for node_id in any case. Clearly from the binding perspective, this is working or the binding simply wouldn’t work for anyone.
I think this started after updating to snapshot 1212, and it doesn’t seem like anyone else is reporting it. I’ll try my archived version. Very strange!
Seems to be reported in the dev version and the master version so I don’t think it’s the binding as such. It might be a problem with combining configuration sources as there are two sources in the ZWave binding - the xml files, and some internal definitions. I suspect this might be broken now as only the internal definitions appear to be displayed…
There’s not a lot I can say really. I’ve no idea why the system isn’t passing the configuration into the binding, but as I said earlier, the binding doesn’t have any visibility of how you are configuring your system. Clearly the binding is working, or it wouldn’t work for anyone. There must be something else in the system that is preventing the configuration from being passed through, although it did work when I tested it here.
Sorry - I missed that (I was unwell at the time ). However I can’t really use short excerpts of the logs - I really need to see a debug log of the initialisation. I don’t care if it’s 10MB - it’s a lot more useful that 10 lines.
I’m not quite sure what the log is - I guess it’s been filtered on node 3? In any case, it’s not got the information that I need and it seems to be some sort of combination with the events log?
Best thing is to simply provide the log file - as it comes from OH - as a text file (ie not PDF as I then need to export it so the log reader can process it. Please don’t filter the log though.
Maybe they could be a shimmery iridescent color, so we all know which ones are magical?!
). However I can’t really use short excerpts of the logs - I really need to see a debug log of the initialisation. I don’t care if it’s 10MB - it’s a lot more useful that 10 lines.