ZWave Manual Thing Configuration

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 :frowning: .

1 Like

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.

Hi Chris,

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:

  1. 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?

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

Proposed workaround:
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.

for some reason i cannot get this to work, the bridge is installed correct, but i cannot get the things to install, they do however get discovered.

Bridge zwave:serial_zstick:controller "ZWave Controller" @ "Local" [ port="/dev/ttyACM1", controller_softreset="false", controller_master="true", heal_enable="true", security_networkkey="***" ]
Thing zwave:device:controller:node2 "Node 2: FGWP102 - Schuur" (zwave:serial_zstick:controller) [ node_id=2 ]
Thing zwave:device:controller:node3 "Node 3: FGWP102 - Garage" (zwave:serial_zstick:controller) [ node_id=3 ]

or

Bridge zwave:serial_zstick:controller "ZWave Controller" @ "Local" [ port="/dev/ttyACM1", controller_softreset="false", controller_master="true", heal_enable="true", security_networkkey="***" ]
{
	Thing zwave:device:controller:node2 "Node 2: FGWP102 - Schuur" (zwave:serial_zstick:controller) [ node_id=2 ]
	Thing zwave:device:controller:node3 "Node 3: FGWP102 - Garage" (zwave:serial_zstick:controller) [ node_id=3 ]
}

i get:

if i use the fibaro_fgwp102_03_002 as device i get:

if i leave the things out, and use the auto discovery things i get:



as you can see the devices are both zwave:device:controller:node2 and zwave:device:controller:node3, so why is the things file failing?

What version of the binding are you using?

binding-zwave - 2.3.0

You need to use a recent 2.4 binding to use this feature.

ahh that would make sense :stuck_out_tongue:
Thanks Chris.

1 Like

I have a similar issue with manual thing configuration. My controller is working fine and I can add things via PaperUI and use them as normal. But with the manual configuration for the things I get an ‘HANDLER_MISSING_ERROR’. I’m using version 2.4.0 of the z-wave binding.

My thing configuration:

Bridge zwave:serial_zstick:controller "Z-Wave Controller" @ "Z-Wave" [ port="/dev/ttyACM0", controller_softreset="false", controller_master="true", heal_enable="true", security_networkkey="***"]
Thing zwave:device:controller:node2 "Z-Wave (002) FWP Speaker" (zwave:serial_zstick:controller) @ "home" [ node_id=2 ]
Thing zwave:device:controller:node3 "Z-Wave (003) FWP Repeater" (zwave:serial_zstick:controller) @ "Z-Wave" [ node_id=3 ]

The error:

This appears in the log when I refresh the *.things file:

Am I doing something wrong with this manual configuration?

I’m not sure what the error is, but for starters you have not defined the things correctly. You can’t use the thing type zwave:device:controller:node2 - you need to define the correct type for your device not the generic one which is used if the system is defining the configuration.

Sorry I don’t quite understand the problem with the generic device type. Isn’t it the right way like Mickroz did it above?
If I change something in zwave:device:controller:node2 the thing isn’t recognized anymore in PaperUI and auto discovery finds the thing again so you could add it via PaperUI.