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?
Unfortunately at the moment this isn’t possible. As I said, in future this will be supported - hopefully soonish.
No - this isn’t possible either (sorry).
@chris : I would like to know if it is now possible to define Z-Wave things in a config file ?
I tried without success but I am new to the Z-wave binding.
I have done several tries with 3 different parameters:
Thing zwave:nodon_msp31x1_00_000:controller:node2 "Lampe Salon" (zwave:serial_zstick:controller) [ node_id=2 ] Thing zwave:nodon_msp31x1_00_000:controller:node2 "Lampe Salon" (zwave:serial_zstick:controller) [ zwave_nodeid="2", zwave_manufacturer="357", zwave_deviceid="3", zwave_devicetype="1", zwave_version="1.55" ] Thing zwave:nodon_msp31x1_00_000:controller:node2 "Lampe Salon" (zwave:serial_zstick:controller) [ node_id=2, zwave_nodeid="2", zwave_manufacturer="357", zwave_deviceid="3", zwave_devicetype="1", zwave_version="1.55" ]
Unfortunately, the thing systematically remains in INITIALIZING state and I got a warning about NODEID being not set.
I am running OH snapshot build 1262 with Z-Wave binding version 188.8.131.52804230754.
PS: using the thing discovered by Paper UI, it is working well, but I would rather keep everything in config files so that I can easily edit and backup.
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?
Ok thank you.
Can I download somewhere the development version as a jar file or should I build it from git?
Yes - read the first 6 or so messages in this thread -:
Note that you will need to delete and add back all things to transfer to this version.
Thanks a lot, I installed the development version and thing configuration from a things file seems to work.
I already included 3 devices and I have a difficulty only with the device on battery (Everspring ST814). I will come back with a question after I see what happens after few hours.
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.
Oh ! Thatr’s very annoying.
But thank you for the quick answer.
I agree - I tried to get this changed a while back, but it was rejected… There is a move to fix this now, but it’s taking time (sorry).
I see what discussions you are mentionning.
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 ?
Yes - that’s basically correct. When the device is first included, the binding will download all the config parameters, but after that they are only set if you change something in PaperUI/HABmin. Otherwise the traffic could/would be very high.
Ok the device parameters are read at least once. All this makes sense to me now.
Yes - the data is read from the device, so what you see in the UI should be correct on the assumption that nothing else is changing the configuration of the device.
I’ve been following this thread for a while and I fully understand your point that a change in ESH is required.
I have two questions:
you write that there is now a move towards changing ESH, but it will take time.
Can you link us to where that discussion is taking place and is there any view on progress or how much time it would take ESH to change this?
if it would take a very long time, would a workaround like proposed below be an option in the mean time? (if its short term then ofcourse this workaround would probably not worth the work).
For me personally the requirement of configuring through paperUI is holding me back to start using openhab at all.
Other solutions feel better in configuration at this moment. Also configuring once is not an option for me because when I take out a zwave device for example for firmware upgrades, then it looses settings that I need (especially regarding the double momentary switches, which seems to get lost at this point).
I wonder if it is doable to mimic paperUI behaviour while configuring things manually:
- When first adding a thing to openhab using the config files, download all settings once-off from the zwave device to a local cache.
- Compare all manually entered parameters in the config to the local cache
- if any of the parameters in config are different than in local cache, then update it.
This is - as far as I understood - the same behaviour as paper UI does.
In addition to this it would be useful to have a trigger or manual config parameter to force a re-download of all the z-wave settings from all z-wave devices to local cache.
Upon reloading the manual configuration, the manual parameters are again checked against local cache and updated when there is a difference.
With this workaround it would be possible to configure parameters manually and forcing an update of parameters manually.
As a nice to have there could be a setting to schedule the re-download of z-wave settings once a month at night for example (or whenever a user prefers to do it).
Please let me know if you see something in this proposed workaround, in my situation it would solve my issues with z-wave in openhab.
This is always done.
The binding has no way to know what config is manually entered. The binding has no visibility of how a device is configured.
But this is not what other UIs do, and this would stop some important functions in HABmin working.
Again, there is no visibility of your configuration in the binding. The binding sees ALL configuration from the thing definition.
Why? Are you somehow changing configuration using other software? If so, then the above fails anyway.
I know that this issue is causing problems - I proposed the ability to configure unmanaged things temporally, but this was rejected. Previously it was stated that ESH is not designed to configure devices at all (there was a discussion about this on the ESH forum) which I guess is why this issue is not having much priority.
Sort of, I experienced two times that all z-wave config was set back to default:
upon changing controllers and upon firmware update using the fibaro home center (had to learn the device to fibaro controller for upgrading firmware).
Thanks for the link I will read up there.