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