What shows up in HA when you have the Dome device paired up?
The siren shows up as a binary switch. Turning it on/off works as expected for the primary siren. The device also supports a secondary chime which can’t be accessed through HA.
Ah as a switch.
Can you post what your ozw_cfg.xml has for your node 25?
Here you go… the indicator class is mentioned there. Seems like HA just doesn’t do anything with it.
node25.xml (11.8 KB)
I’m wondering if we can’t just class it under the switches section, so its works like the primary siren.
Edit: nope it’s a “byte” type so that won’t work.
Are you using Hassio or would you be able to test some changes with me?
I am not using Hassio, should be able to test whatever. Yeah, as I understand it the indicator class is a one time message - turning it “off” would be meaningless.
It’s toggleable per the docs.
Sorry, I should have been clearer about what I meant -
The class itself may support the concepts of on (00) and off (FF) but that isn’t the way the dome siren uses it - it accepts different bytes 01-0A for the ten different secondary chime sounds it can make. Unlike with the primary siren, there’s no turning the sound ‘off’ after requesting it - the sound just happens once and then is over.
Here’s what I’ve whipped up, not guaranteeing it’ll work properly since I don’t have a way to test it myself.
https://github.com/firstof9/home-assistant/commit/6789da562604c4be9ffd406e84fd636db0a3b1e1
Just 2 files to modify/replace if you want to give it a shot, make sure to backup the original files.
1 Like
OK, I changed your file slightly before implementing given the Dome docs I referenced above:
INDICATOR_ON = 0x01
INDICATOR_OFF = 0x0A
It probably doesn’t really make sense for ‘on’ and ‘off’ to trigger two different sounds but I figured this is at least worth testing. The switch.siren_indicator entity shows up fine in HA. Got the below in the HA log when I tried to turn it on. (I also tried it with your original values for INDICATOR_ON/_OFF and got the same error)
2018-04-05 22:39:09 ERROR (MainThread) [homeassistant.core] Error executing service <ServiceCall switch.turn_on: entity_id=[‘switch.siren_indicator’]>
Traceback (most recent call last):
File “/srv/homeassistant/homeassistant_venv/lib/python3.5/site-packages/homeassistant/core.py”, line 1006, in _event_to_service_call
await service_handler.func(service_call)
File “/srv/homeassistant/homeassistant_venv/lib/python3.5/site-packages/homeassistant/components/switch/init.py”, line 109, in async_handle_switch_service
await switch.async_turn_on()
File “/usr/lib/python3.5/asyncio/futures.py”, line 380, in iter
yield self # This tells Task to wait for completion.
File “/usr/lib/python3.5/asyncio/tasks.py”, line 304, in _wakeup
future.result()
File “/usr/lib/python3.5/asyncio/futures.py”, line 293, in result
raise self._exception
File “/usr/lib/python3.5/concurrent/futures/thread.py”, line 55, in run
result = self.fn(*self.args, **self.kwargs)
File “/srv/homeassistant/homeassistant_venv/lib/python3.5/site-packages/homeassistant/components/switch/zwave.py”, line 92, in turn_on
self.values.primary.value_id = INDICATOR_ON
AttributeError: can’t set attribute
Halfway there at least. I’ll post an update after I work on it some more.
1 Like
Looks like this is as far as we can go at this point in time due to python-openzwave not having full indicator support. There’s no way to send the “INDICATOR_SET” and “INDICATOR_GET” Zwave commands at this time. 
Makes sense - is that library maintained by the OZW project? Thanks for looking into it.
1 Like
As far as I can tell yes, it’s maintained by the OZW devs.
They seem to have been making progress, as there is a “can_set_indicator()” function in their API. So looks like it’s just a waiting game at this point.
2 Likes
Free bump.
And another one.
Hi @murphys_law and @wohlraj,
If you install 0.80 or greater, this should be implemented.
Here’s a feature request thread w/ more info: Event support for Scene Controllers
The gist is that the indicators should get their own entity now, and can be set using a new service (zwave.set_node_value), which takes the z-wave node-id, value-id for the indicator, and the value you want to set. Likewise, there is service for getting the values (zwave.get_node_value).
You can get the value_id and node_id of the indicator entity using a template and the state_attr function.
Here’s a pretty good example of using this to control the indicators of a scene controller: https://www.home-assistant.io/docs/z-wave/device-specific/#rfwdc-cooper-5-button-scene-control-keypad
This is pretty easy to play around with using the developer tools for services and states.
I did run into an issue w/ my setup where my Cooper RF9517 didn’t have the indicator entity created, so I ended up turning on debug logging (probably only necessary to enable for the zwave component), and dug through the log to find the value_id of the indicator. I hard coded the value_id into my config & it has been working since. You can also use the zwave.print_node service to have the node you’re interested in printed to the log & dig through that output–the below pyp one-liner will give you the value_id for the indicator of the last node you called that service on:
grep -A 1 "FOUND NODE" home-assistant.log | tail -1 | pyp "p.replace('<', '\'<') | p.replace('>', '>\'') | eval(p) | dict([(p['values'][value_id]['command_class'], value_id) for value_id in p['values'].keys()])[135]"
Cheers!
2 Likes
I found a way to set the attributes via a script recently and have been using that. I’ll take a look at this to see what it means, but it looks nice.
Tested and works with the Dome Siren. I was able to get the Value ID from the Z-Wave Config panel - it took some fumbling around to find where it’s stashed. (Click ENTITY INFORMATION below the entity drop-down to see the pop-up box with the Value ID.)
