[feature] parse alarm command class
sjorge opened this issue · 11 comments
It would be nice that the alarm command clase would be translated to a descriptive string for the value. (Or maybe make it configurable)
https://github.com/OpenZWave/open-zwave/wiki/Alarm-Command-Class
Suggestions?
I saw this:
enum { Alarm_General = 0, Alarm_Smoke, Alarm_CarbonMonoxide, Alarm_CarbonDioxide, Alarm_Heat, Alarm_Flood, Alarm_Access_Control, Alarm_Burglar, Alarm_Power_Management, Alarm_System, Alarm_Emergency, Alarm_Clock, Alarm_Appliance, Alarm_HomeHealth, Alarm_Count }; (you should check the Source of the Alarm CommandClass for updated list as this might change).
But I don't undestand very well how to get the correct aram starting from the valueID
That Wiki page is outdated with 1.6.
In 1.6, the Alarm Class is completely dynamic. All Alarm Types are loaded from config/NotificationCCTypes.xml now. (as its a frequently updated class).
the AlarmType id value in the XML maps to the ValueID index exported from the Alarm CC. You could use the GetLabel Call to get the Type String
The AlarmEvent id is the individual events. On recent devices, only events that the device supports will be populated into a ValueList. Earlier versions will have all Events populated. The Individual labels in the list have the Event Types.
As noted everywhere, many times over, DO NOT code in string comparisions against label's (of any type in OZW). Labels are completely translatable now, and can change based on the language the user selects.
Use the Index Numbers. Once assigned, I guarantee them to be stable and not change over a between minor releases of OZW (meaning all 1.6 releases are stable).
tagging @ekarak and @bibi21000 as they might find this info useful.
Would still be nice to get the string and the ID send via mqtt though
@Fishwaldo Thanks!
As noted everywhere, many times over, DO NOT code in string comparisions against label's (of any type in OZW). Labels are completely translatable now, and can change based on the language the user selects.
I don't make any comparison in my code but I just use the command class label and valueid labels as parameters to compose the values topic in MQTT. This is one of the 2 ways I provede here to map values on the gateway automatically. More info here. Now I don't think that this is so bad just with version 1.6 users must keep the english language (that I think will be the default one) in options or all topics will change
@sjorge I think that what you think is archived with valueid label that is already added in mqtt topic
I could also add a check and if the command class is 0x71 (Alarm) check the index and retreive the correct alarm type label
Like I said - the ValueLabel will contain the string. The ID will be the index.
I don't make any comparison in my code but I just use the command class label and valueid labels as parameters to compose the values topic in MQTT. This is one of the 2 ways I provede here to map values on the gateway automatically. More info here. Now I don't think that this is so bad just with version 1.6 users must keep the english language (that I think will be the default one) in options or all topics will change
The problem is I make "no promises" at all that the labels will not change, even between releases. The labels are now sourced from Localization.xml.
In addition, the labels are dynamic dependent upon multiinstance or single instance classes. So some will be "Instance #1: Switch", others might be "Top Left Switch" and others might just be "Switch".
its all defined in config files. So a label today might not be the same label tomorrow.
I would think very carefully about that. HASS used value labels to map to script variables. Now every single script will break when they upgrade to 1.6 :)
@sjorge I think that what you think is archived with valueid label that is already added in mqtt topic
I could also add a check and if the command class is
0x71(Alarm) check the index and retreive the correct alarm type label
Currently I have this bit of code in node-red
case "zwave/bedroom/multisensor/alarm/burglar": // NOTE: motion + tamper
switch(msg.payload.value) {
case 0:
ret_homekit_motion = {"payload": {
"MotionDetected": 0,
}};
break;
case 3:
ret_homekit_motion = {"payload": {
"StatusTampered": 1,
}};
break;
case 8:
ret_homekit_motion = {"payload": {
"MotionDetected": 1,
}};
break;
}
break;
Where the value of 0 => no alarm, 3 => tamper and 8 => motion it would be nice to have an optional value in the payload which also includes the text version of these. It's fine if they come in via the translation stuff fromn 1.6. It's mostly handy for when debugging and verifying things.
It took me a while to figure out which values were which.
its all defined in config files. So a label today might not be the same label tomorrow.
Yes that's sure, this is why I have provided the 2 ways for "auto mapping". Maybe I could add a warning in readme when using the "named topics" gateway type. Anyway the most advanced feature of the gateway is the manual mode that uses valueid to identify a value so this is not breaking that :)
I have no idea about how to create a better automatic mapping of values between the two protocol that is not sensible to labels breaking changes. If someone has suggestions I will be glad to discuss that here :)
Where the value of 0 => no alarm, 3 => tamper and 8 => motion it would be nice to have an optional value in the payload which also includes the text version of these. It's fine if they come in via the translation stuff fromn 1.6. It's mostly handy for when debugging and verifying things.
No idea how zwave2mqtt exposes ValueLists, but the labels are there in the C++ version for each "event": http://openzwave.com/dev/classOpenZWave_1_1Manager.html#ae137ac3ea0e3ac29784d5e567ca3db77
So once you get the ValueID, you can (via the nodejs wrapper I assume?) call that method to get all the "Events" (and http://openzwave.com/dev/classOpenZWave_1_1Manager.html#ae137ac3ea0e3ac29784d5e567ca3db77 to get the position index in the list).
Maybe I could add a warning in readme when using the "named topics" gateway type.
I would very STRONGLY discourage it in your documentation. :)
I have no idea about how to create a better automatic mapping of values between the two protocol that is not sensible to labels breaking changes. If someone has suggestions I will be glad to discuss that here :)
I will export c++ enums for all available ValueID indexes very soon. If the nodeJS wrapper can stringify that, it might help...
but things like the Alarm (Notificatication CC), SensorMultiLevel (soon), SimpleAV etc CC's will have "dynamic" valueID's so the enums might end up being very generic, like Notification_Type_1, Notification_Type_2 etc.
(my goals is making it possible to support latest devices that export Alarm CC with just a XML update rather than a new version of OZW!).
or - maybe you can read the NotificationCCTypes.xml file and make your own representation?
@Fishwaldo thanks, I will take a look on that stuff and think about a solution!