I would agree - that’s the purpose of such channels - ie to allow configuration parameters that have a “user function” to be exposed in a standard way.
1 Like
Ok, fair enough, then how would I “convert” or expose a parameter into a channel?
Let’s take the Fibaro Walli Double Switch. It has the following config parameters:
The device can be found here: OpenSmartHouse Z-Wave Device Database
How do I configure let’s say parameter 11 to become a channel to set the LED FRAME COLOR (when on)? I am happy to work on that.
Stefan
You need to add the channel to the database. From the docs -:
Changing parameters in openHAB rules
To use a configuration parameter in a rule, or display it in the UI, a channel must be add. This should be added to the Configuration command class in the endpoints list. It should be given the type config_decimal and there should be an option parameter=XX where XX is the relevant parameter ID.
Thanks for hinting, Chris. Sounds like a good plan.
I have a question though: I have started editing the the channel as a command_configuration_class_v1
which opens a dialog allowing me to enter the following fields:
Unfortunately the options-field is missing. Any idea, why?
And can you explain what the “specific configuration used within bindings” is used for?
Note I have marked the changed to be reviewed in the database.
Thanks
Stefan
You can’t set options on the channel - the options should be on the parameter so that they are available in the configuration UI. The config channel simply takes a number - not the text.
I just had a look at the database, and you need to add the parameter number into the config box as above. I guess it’s parameter 11 that you’re looking at?
Yes, it is. I will do so right away.
For the record, this is the final definition (note that the options had already been defined with the parameter 11)
I also added another channel for config parameter 12 and 13.
I have modified all Wallis accordingly and they are marked for review.
Can you check why the image of the last one seems to be broken in the database?
@chris do you mind reviewing my updates (not trying to bug/push you - just not sure if you saw my updates in the zwave-database lately).
Thanks
Stefan
Sure - I’ll go through a database export tonight or tomorrow.
Cheers
Chris
1 Like
Just FYI- There was a guide written for OH2 to add an XML file extracted from the database (after editing) directly into an existing .jar For those too anxious to wait a few days before they were added into a build.
I have not used since OH3, but I think the only change is that the ESH-INF directory is now OH-INF
Bob
1 Like
Just to note that the database was updated yesterday, and in general I do one or two updates a week so this normally isn’t necessary.
1 Like
Regarding these devices. You seem aware about the recent database changes. I have restarted my Z-wave network today hoping for better performance starting off fresh.
However, for my Walli Switches I do get the following. The devices did work perfectly fine on the same version of binding 3.1.0 before resetting my Z-Wave controller. The Walli dimmers are just fine.
Ideas?
2021-09-13 22:23:39.092 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 7: Command received zwave:device:8f57dbad:node7:switch_binary1 --> OFF [OnOffType]
2021-09-13 22:23:39.092 [DEBUG] [converter.ZWaveBinarySwitchConverter] - NODE 7: Command class class COMMAND_CLASS_SWITCH_BINARY for endpoint 1 not found
2021-09-13 22:23:39.093 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 7: No messages returned from converter
The only changes I think were to add a few new channels linked to config parameters. It won’t impact your issue here. This sort of issue is normally caused by the device not initialising properly and the XML doesn’t contain all the information so it can’t find the command class to send the command.
Therefore I suspected the database, but just like you I tried to look into the file history on Github but there didn’t seem to be much of a change. The next reason to suspect this were that I could see this on all of my Walli Switch devices, which would seem strange if there was a one off issue on include. Very weird.
Sorry - I don’t know what you mean by this statement?
Why did you suspect the database?
I suspected there had been a change in the database as suddenly none of my Walli Switches worked on re-inclusion.
And as you mention it could indicate an error in the XML due to failed initialization. I thought it would seem unlikely multiple devices failed to initialize by “bad luck” and therefore the XML/database became the main suspect. But since no changes that should affect this seem to be done there it’s all very strange as the devices has worked just fine previously with the same/very similar database.
So you reincluded all your devices?
As I mentioned earlier, this error is normally caused by the command class not being in the XML - what I meant here is the XML that OH produces - not the database XML. When the binding initialises, it downloads all the command classes from the device and stores them in an XML. This is used to create the implementation within the device - it has nothing to do with the database.
The database “just” defines the channels and how this links to the command class. If the command class isn’t there, then the database will still show the channel exists (and I think you have the channel still?).
1 Like
Ok, small confusion from my side there. I think I understand now.
Either way in /var/lib/openhab/zwave my …_node_7.xml I can see “COMMAND_CLASS_SWITCH_BINARY”.
Update: Ok, I’m officially an idiot… I literally had to switch the switches once for this to initalize…
Looking into the XML, there was only “COMMAND_CLASS_SWITCH_BINARY” for the main endpoint not for switch 1 and 2 separately. That is until I pressed each button once…
Thanks for the help 
Good news so far is at least things seem to be faster than before re-doing the entire network!
1 Like
Really, you shouldn’t have needed to do this - the data should have been detected during initialisation, but I suspect that the device doesn’t expose it and in this case it will be added to the XML (ie device definition in the binding) when the binding receives a command from the device.
1 Like
I think it might
I think it might be due to the device having two modes. It can be set as single or dual switch before initialization/inclusion. Dual is the default, but it seems their default initialization adds one switch and then additional in case you press them (confirming dual mode). Oh well, it was solved quite easy in the end.
1 Like