Ah I did define the things trough the .things file, but I -could- set the parameters in openhab paperUI (I am using the development binding and fibaro dimmer 2). Just wondered if it was also possible to set the params in text because it would be a bit faster to set up. But I think then only trough the UI?
Yes - as described above. There are limitations with being able to configure devices, but it works if that’s what you want to do. As above though, it’s only available in the development branch - I’ll look to merge this into master in a few weeks (after 2.3 release).
This doesn’t look like a development binding version?
Can you please tell me what is the syntax to set a configuration parameter in a configuration file ?
For example, for a FGD211, I would like to set config_14_1 to 1 (default is 0). When I use config_14_1=1 it is not taking into account. Maybe the problem is that this parameter is inside a parameter group named configuration. I don’t know what is the syntax to use in such a case. I tried configuration:config_14_1=1 but it is not a valid syntax.
This is not possible. It is currently not possible to configure devices at all if you are using thing configuration files. This is something that is in the list of additions in ESH, but currently it’s blocked.
If you want to configure devices, then you need to use PaperUI/HABmin to define your things.
But I don’t understand why it is not possible to take into account a parameter from my configuration file. I don’t want to update it. Isn’t it possible for your binding to consider these configurtation parameters and update the device configuration in case the current value is different ?
There is no way for the binding to know what parameters are defined in a config file - it just gets a list of ALL configuration. So, the only possibility is to send ALL parameters to the device - even if you only specify a single parameter. Many devices in ZWave have 30 to 50 configuration parameters, and many people have well over 100 devices in their network - that’s a LOT of configuration parameters.
So, means when the binding starts, it would need to somehow send a few thousand configuration commands, plus the same number of read-backs to confirm the settings, and this would add a huge load to the binding startup that would take a long time to clear (and for battery devices, a very long time!). It would also be difficult to manage as I’d either need a queue that can handle this number of frames (normally we only queue up to 100 messages - not the many thousands we are talking about here!) or I’d need to somehow manage this configuration update through some other sequencer.
As was discussed last time we looked at this, something could of course be implemented - it would take some time, may not work well, and would likely cause a lot of performance issues that would need to be explained…
Even this requires the reading of the commands - so that halves the number of messages we’d need to send - again assuming the 100 devices with 40 commands, that’s still 4000 messages we’d need to send on startup to get the state. We could alternatively assume that we know the value already and nothing has changed since last time, which might cover many cases, but it’s not going to be reliable in all cases.
I hope that helps explain it a little at least? It’s not a simple problem .
Ok, I understand.
Does it mean that the device parameters are currently never checked against the ones in the thing configuration ? They are only pushed to the device when the user changes a parameter using Paper UI ?