Thanks!
I do have all the sub devices recognized properly.
Poking around in MQTT explorer for the different COMMAND_CLASS_SOUND_SWITCH ClassIDs, it appears that the values aren’t consumed by OZW unless explicitly asked to read it:
{
"Label": "Doorbell 1 Volume",
"Value": 25,
"Units": "",
"ValueSet": true,
"ValuePolled": false,
"ChangeVerified": false,
"Min": 0,
"Max": 255,
"Type": "Byte",
"Instance": 3,
"CommandClass": "COMMAND_CLASS_SOUND_SWITCH",
"Index": 2,
"Node": 12,
"Genre": "Config",
"Help": "The Volume to play the tone at",
"ValueIDKey": 562950165119025,
"ReadOnly": false,
"WriteOnly": false,
"Event": "valueRefreshed",
"TimeStamp": 1601038507
}
So it seems whatever I implement should set the values, say, on start up, so they are in a known state and can be tracked.
But I can clearly now why we need to implement a new device class in Home Assistant to handle these types of devices.
New platform for siren/chime devices · Issue #375 · home-assistant/architecture (github.com)
My current plan is to implement Home Assistant entities for the controls I need, and configure automations to fire either the correct zwave service call or MQTT command to trigger OpenZWave 1.6 beta to set the desired configuration.
The next step is to figure out how to fire the Zwave Events to trigger the siren to make a sound, but I think that must be done with MQTT and not the hass zwave service, since I don’t believe it supports that.