Changing thing parameters via rule? (Fibaro Walli)

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?

Thanks in advance,

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.

I modify parameters of my Zwave devices using the REST API

The ‘:’ needs to be replaced with ‘%3A’ , ‘a640e92a’ with your Zwave ID

Get config for node16

GET http://username:password@your_ip:8080/rest/things/zwave:device:a640e92a:node16

Set config for node16

PUT http://username:password@your_ip:8080/rest/things/zwave:device:a640e92a:node16/config

with body


The complete API is described at


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?

Single parameters are ok (at least my experience :wink: )
I‘ve tested with Postman, works good

I would suggest updating the zwave db and expose it as a channel instead.

Refards s

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.


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.


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


Sure - I’ll go through a database export tonight or tomorrow.


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

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

@stefan.hoehn @chris

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.


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.