My question is if there is a way to manipulate values of thing parameters somehow via a rule?
I am of course aware that channels are provided by a z-wave device that are supposed to be used but sometimes some effect could only be achieved via changing particular parameters.
However, there are seldom cases where I would want to manipulate the parameter of a thing dynamically. To give you an example I have wall switches with a colored ring whose ring color can be changed via a parameter. I though of dynamically setting different colors to use that color to indicate certain situations.
Maybe there is a way to call an openhab API via the rule or even going through the rest API?
Has anyone ever done that or an idea what API had to be used?
Good use case.
Ideally, that kind of uhh thing should be exposed by the binding as a channel, for inspection and manipulation by the run of the mill openHAB workings.
In the specific zwave âset device parameterâ usage, that may not be at all easy.
Exactly what any particular binding may do about an in-flight Thing change is entirely binding dependent. It might need to perform a special dance with the device, or invoke a reinitialisation, or reschedule something, or just do nothing until a reboot.
Thatâs how the GUI does it, so it should be possible.
Note that attempts to modify file based Thing parameter should be blocked, by convention.
Great, Sounds like a feasible approach. Do you know if I always have to provide the full set of parameters or if can leave some of these out and for example only send one parameter like in a put or patch request?
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.
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
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?
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
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.
)
