[OH3] Z-Wave - Is it possible to force-reinitialise devices without re-pairing?

Correct - it was not included in the M1 version of he binding - hence my point to use the newer version (I’m not sure if it has been released yet - but if not, hopefully tomorrow).

M2 was released a few hours ago.

3.0.0-M2 has the exact same problem.

I am now setting up everything so I can build & debug openHAB myself on Linux, so I can really see what’s going on.

Why Linux?

  • Building on Windows gives problems with line endings on the spotless checks, how and why exactly is a great mystery at the moment.
  • The Eclipse IDE setup on Windows fails with thousands of warning and errors.
  • It is that the current maintainers must be using :wink:

Well, the issue will still be what I said - it’s not in the binding you’re running. Either you’re not running M2, or M2 still doesn’t have this device.

No - at least not me - I use a Mac. Others use Windows, and some use Linux - is doesnt really matter.

My guess it was in the database, but still not recognised in a way.
But you are right…It is not in the database… not anymore that is…

Okay,.It is in the openSmartHouse database.

But not anymore in the openHAB database:

It was introduced a long time ago:

It also was in 3.0.0.M1:

But there the “re-initialisation” without a new install was ‘broken’.

But it is gone on M2 (and master):
https://github.com/openhab/org.openhab.binding.zwave/blob/3.0.0.M2/src/main/resources/OH-INF/thing/eurotronic/spirit_0_0.xml (404)

No idea why…

And on M2 I only tried to get it recognised on an existing network, so no hard reset and adding them again, which most probably also doesn’t work now.

Note: Its Aeotec branded twin is still in the database, but has a different manufacturer id.

Unfortunately there’s not a lot we can do to change that for M2. It should be added back again to the snapshots soon.

No problem. Just reporting :slight_smile: It is still a milestone build and openHAB is made with love in peoples spare time. I’ll never forget that. I’ll add it myself and see if the recognition works

There’s nothing to do - it will simply be in the next update. Someone edit the database so the device got dropped briefly. It was already approved so it will be in the next update.

For testing, I uninstalled the zwave binding. Created a new zwave binding addon jar with the spirit xml file added again. I put it in the addons directory. Did a feature:install openhab-transport-serial on the CLI and restarted openHab (the last step might not even be needed).

And immediately two Eurotronic Spirits show up in my Inbox :smiling_face_with_three_hearts:

I just installed OH3 over OH2.5 and so far a lot it is running. Nevertheless I have the same issues with the Eurotronic valves that were running as intended with the 2.5 installation. I reinstalled the binding, but unfortunately still unknown device. Anything I can do beside waiting?

BTW: Where can I find the log? openhab:9001 is not working anymore. :slight_smile:

Just waiting or moving to a snapshot version will not work.
The z-wave database needs be re-exported to github, because the spirit is still missing at the moment.

Until that time you can add the spirit manually by adding it to the z-wave binding and install this manually:

Logs are in : userdata/logs for a manual install and in /var/log/openhab for an install with a package manager.

Chris just said he did that 4 days agp

Snapshots are built daily. since it has been 4 days it is assuredly in the latest snapshot.

1 Like


It is not there…

And also not in:




To be clear I didn’t say that it had been exported - I said that it was approved and would be in the next export.

So it will be in the binding for the next update. At the moment I’ve not done this for OH3 - only 2.5. I will do this later tonight.


Sorry, I misinterpreted this.

to mean snapshot, not export.


I’ve just triggered the build so it should be done in the next 30 minutes or so…


Unfortunately this is not the “correct” version for the Eurotronic Spirit.
It does not limit to options where it should do so.
It also does not include (all) the min and/or max values for parameters having options outside outside the min/max range.

As discussed here there was nothing wrong with the database definition, but it was a bug in the OH3 UI:

Because @ysc has made a quick fix for this, it works with the original database definition in OH3 M2. https://github.com/openhab/openhab-webui/issues/459

So all recent database changes should be reversed. The one in the spirit definition in the OH3 M1 build is the correct one:

@chris Can you revert this easily or should I edit it back to the M1 version?

Please can you describe the problem? I thought that the limits in parameter 8 (if I remember correctly) were meant to be set to +/- 50?

The strange thing is even the current database and the export on github are not in sync, but ok:

  • Parameter 1 should be limited to the options
  • Parameter 2 should be min 5 max 30 (no min/max on github, max 30 but no min in database)
  • Parameter 3 should be limited to the options
  • Parameter 4 should be limited to the options
  • Parameter 5 should be limited to the options, min should be 0 (not in the database, but on github, not sure 0 is the default if it is left blank in the database)
  • Parameter 6 should be limited to the options
  • Parameter 7 should be limited to the options
  • Parameter 8 should be min -50 max 50 (this is in the database, not on github)

with “should be limited to the options” I mean there is no:
in the definition of the parameter, assuming the default is true and if no options are present this parameter is ignored.

The above might be even more confusing. It just should be as defined here:

If you want I can make the needed changes. Just let me know.

The database should be in sync with the binding - I just exported it an hour or two ago. If it’s incorrect, then there is likely an error in the exporter.

I really don’t have time to look at this now - sorry.