I was thinking a lot about dynamically configuring things from within rules. Especially the Z-Wave things and devices come with very useful and versatile configuration options. While it may seem like they were “set it and forget it”, there are some options that could be automated for even more versatility. Some examples:
At night the dimmer should switch the lights ON and OFF pretty fast, but if it’s sunny outside the dimmer should very slowly and carefully compensate for missing light in the room (cloud shadow compensation, etc)
When it’s light in the room, the power socket outlets’ indicator lights should be enabled to show the outlets’ status; but if the room is dark they should be disabled - even if ON - in the configuration, to allow for a better sleep.
I had a hard time to find any topics about this? Has anyone thought about this, yet. If so, what are the challanges and is there anything I could help with?
Dumb me took a look at the openHAB RESTful API today. It’s all there:
I can send data to the following endpoint:
The data is sent via a PUT request and looks like this: {"config_6_2": 2} where 6 is the configuration setting number. This can be found out using the REST API by sending a GET request to /things/<your thingUID here>. I am not sure what the 2 is, though.
The data ({"config_6_2": 2}) sets the Fibaro Dimmer 2 dimming step interval to 20 milliseconds per step.
While it feels weird to talk to the own REST API from within rules, this could be one way of doing it until hopefully we can implement this as rule actions.
Doing this from the linux shell with curl would look like this:
Specifically, this is configuring a configuration parameter of the Thing. I haven’t found a clean way to configure other things, like the temperature scale, so I grab the whole configuration, modify it, and then send it back. I believe this is what I saw Habmin doing. @chris, is that accurate?
Also, the 2 looks to be the word size of the configuration parameter. You can see these in the database.
No - HABmin only sends back stuff that has changed, but PaperUI sends back everything. Be very careful with this though as it may have unwanted effects as it will send a lot of data over the ZWave network if you update all parameters.
If the data that you want to configure is the sort of thing that people might want to use regularly, then we can simply configure a channel so it can be linked to an item. It’s much easier. I wouldn’t bank on the REST interface being something to rely on once security is added for example.
… that contains the entire Thing configuration of that device with the modifications that were made. That is why I did the same thing in my rule, rather than manually updating the temperature scale on 20 devices. So, I guess I’ve confirmed my own question!
Yes, the entire thing config is sent to update the thing, but not all the configuration parameters - there’s a separate rest endpoint used for configuration.
Yes, but this is most definitely not the case. I think this is a kind of special use case. We can discuss if it was an option to expose any configuration parameter as a channel by ticking a box in the UI or something. But this would cause a load of work to implement and may collide with the current code base of the z-wave binding.
Due to the complex nature of wanting to change thing configuration, a use will most likely use rules anyway, so still implementing a rule action for changing the configuration would be the easiest.
I will post at least a Procedure type function in the next week to come up with some examples.
Sorry for the confusion. In my opinion, my special use-case of changing the dimming speed of a Fibaro Dimmer 2 is not interesting enough for the rest of the world to configure it as a channel for everyone.
This is the followup about how I solved it using rules.
As mentioned above, changing a thing’s config using the openHAB /things endpoint works like a charm. So that’s what I’ll do and thoroughly test now. See my real life example:
rules
rule "Work: Slow down Dimmer when adapting level"
when Item work_lights changed to 0
or Item work_lights changed from 0
then
var Number new_value
if(work_lights.state > 0){
logWarn("work.dimmer.adapter", "Dimmer level adaption. Setting to slow steps.")
new_value = 100
}
else
{
logWarn("work.dimmer.adapter", "Dimmer off. Setting to fast steps.")
new_value = 2
}
val String json = '{"config_6_2": ' + new_value + '}'
logWarn("work.dimmer.adapter", json)
sendHttpPutRequest("http://openhab:8080/rest/things/zwave:device:bridge:node18/config", "application/json", json)
end
This works well with the Fibaro Dimmer 2 FGD212. I just hope they save the settings in a flash memory and not an EEPROM which can only handle a few hundret writes. I’ll report back here if this breaks prematurely.
I’ll also let you hear from any new findings and problems - if any. Until then, I am open to any questions regarding this and wish you guys a nice day!
This is correct. Just like when editing a Thing using the PaperUI or any other UI, as you and @luckymallari pointed out correctly, openHAB will deny changing the unmanaged thing and answer with an HTTP 409 “Conflict” error:
{
"error": {
"message": "Cannot update Thing zwave:device:bridge:node18 as it is not editable.",
"http-code": 409
}
}
If we use a PUT to send configuration parameters, which works fine, how do we delete those parameters? Sending fields blank does not remove them, and it errors.
If I send 1111 to a code, how would I remove 1111 from the REST API
.