Z-Wave siren: ABUS SHSG10000

Add-ons Bindings
,
1

Hi,

another missing Z-Wave device, a siren from ABUS: https://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-list/devicesummary/1084

/cc @chris @sihui

Best regards,
Stefan

2

As you point out, this is in the database - it looks like it’s still work in progress since there hasn’t yet been a request for review.

3

Am interested in comments first. But have requested review now.

@chris Was wondering, to test this out, using the 2.5 snapshot is still the way to go? Is it still the case that one has to remove and recreate all things when coming from 2.4? How often do you update the snapshot? automatically via CI?

4

After the database is updated, you just delete the things from OH and re-discover them. They have the same ID so rules do not break.
To know when the database has been updated to the snapshoit,

  1. Check that the device has been reviewed.
  2. Check here for the last update to GitHub:
    https://github.com/openhab/org.openhab.binding.zwave/tree/master/src/main/resources/ESH-INF/thing
    3.Then check here for a newer snapshot date,
    https://ci.openhab.org/job/openHAB2-Bundles/org.openhab.addons.bundles%24org.openhab.binding.zwave/
2 Likes
5

Wondering, if it is just about these xml files in the jar bundle that must be updated, is there a deeper reason that we don’t support a config folder with xmls provides by the user?

It’s pretty awkward to switch to a developer snapshot just because one device definition is added.

6

Here is my guess.

  1. OH is distributed as one prepackaged system.
  2. If users created their own xml files, there would be even more trouble posts and complaints about binding stability.
  3. Perhaps @chris can give us the real reasons. :wink:
7

This has been discussed at length, but there are a few reasons -:

  • openHAB doesn’t allow it - it will only read the XML files from the JAR. Yes, the binding could rewrite this element of the system, but that’s a lot of work and we are part of a system, so we should work in a standard way.
  • the XML files are closely linked to the code. There will be changes that will only work in the XML when supported by a change to the Java code - if users change XML files, it does not guarantee it would work.
  • the XML file format has changed periodically - this is managed nicely when the binding handles the XML files - again if people can change the XML files outside of the code, we would have compatibility issues.
1 Like