Zwave binding code additions

I have a few additions I’d like to be added to the zwave binding, but unsure of the procedure.

Is it recommended to do a pull request, or simply ask in here for the changes to be made. I’m not very experienced with github, but don’t mind giving it a try.

In particular the changes I’d like made are to the file:
https://github.com/openhab/org.openhab.binding.zwave/blob/main/src/main/java/org/openhab/binding/zwave/internal/converter/ZWaveAlarmConverter.java

where the following needs changing:
To the “alarm_power” notification I need to add “POWER_MANAGEMENT__OVER_LOAD” notification as I have 2 devices that support this, and currently the database is not correct.

To the “alarm_system” notification I need to add “SYSTEM__HARDWARE_FAILURE_MANUFACTURER_CODE” and “SYSTEM__SOFTWARE_FAILURE_MANUFACTURER_CODE”.

To the “alarm_heat” I need to add “HEAT__LOW_DETECTED_UNKNOWN”

Finally I need to create a “WEATHER_ALARM” notification class, and at least add a moisture alarm as per the documentation:
image

My main concern is whether it is enough to just add the entries in the ZwaveAlarmConverter.java file, or if there are other places this needs to be adressed?
I have seen that the weather notifications are included in Alarm Command Class files.

If it is a matter of only changing the AlarmConverter I don’t mind giving it a try myself :grin:

I think the best approach is to open an issue on the repo describing what you want and if you are willing to implement it yourself, how you plan on implementing it.

I’d wait a day or so just in case there’s a discussion from the maintainers on an alternative approach or the like.

Then implement your change and submit a PR.

However, my understanding of how the Zwave binding works is that most of this sort of thing is handled through the database entries, not the code. Are you certain a code change is needed here at all?

Not sure at all. But I have seen a similar issue where a binding update was needed, and also looking at the code, I am pretty confident that it is needed. But it could be that some of the things are handled in other places that where I looked, although I don’t follow the logic, if that is the case.

If I don’t hear anything, then I’ll definitely try reaching out through other channels - but for issue that relate to OH, my experience is that this is the best place to start - especially if someone else has a similar issue, they may not find an answer here, but they will at least be forwarded to the forum where the answer will be. Be that Github or Zwave database.

But thanks for the advice - always appreciated! :+1:

With regard to Z-Wave SDS13713 the ZWaveAlarmConverter is incomplete, e.g. notification type ‘Irrigation’ (0x11) is missing completely.

If the converter is to be extended, I would suggest to add all missing notifications.

To get it right, one would have to read and understand the specifications for alarm classes ALARM and NOTIFICATION (all versions) and the relevant openHAB source code (at least AlarmConverter and ZWaveAlarmCommandClass).

I agree with you - hence my question, whether it is enough to add them to the AlarmConverter file.

I’ve peeked at the AlarmCommandClass file, and all the notifications are enumerated in the file, including weather, irrigation, etc, which is why I would assume it would only be necessary to add them to the AlarmConverter, at least for those whose notification types are already present, like adding “HEAT__LOW_DETECTED_UNKNOWN” to the heat notification type.
For new notification types like irrigation, weather etc, I don’t have the insigt to where in the binding, apart from AlarmConverter these notifications need to be adressed. But if I was shown, I wouldn’t mind having a go at it - from what I’ve seen its pretty much copy paste from the other classes. At least from a Z-wave conversion perspective, but if that also requires changes to the database-side to accomodate new notification types, and also if changes are needed on the OH-side to allow new channels from these notifications I cannot tell - but again, if I’m shown where these things are implemented I think I would manage implementing them on the OH-side, dunno about the database, since I have no idea how that part works on the backend.