Legend! Thank you @finity!! I’m currently using the ‘native’ non-MQTT JS add-on. I’ve hopped from OZW to ‘native’ to JS2MQTT and back to native over the last few months - I’ve resisted going back to JS2MQTT during this project but will probably do so today.
Bigger picture, I’m trying to automate camera feeds on a tablet during doorbell events (will move on to door sensor automation after that). I’ve been using a zwave_js_value_notification events listener and debug node to try and find device IDs - triggering a ‘chime’ on the Siren with the doorbell button surfaced with a different device_id and value 255 (on) / 0 (off) as separate events. Very limited testing, mind you - hard to test when each test produces a 105 decibel chime. edit - false flag, event was from a different / non-related sensor.
Note I have a total of 42 entities registered with my Siren6 - 26 that show up with values, and 16 sensors with ‘unknown’ values (8 alarmTypes and 8 volumeLevels). The ‘unknowns’ were originally registered as hidden after pairing. I’m also pairing unsecure.
Just like a few people commented earlier i have many disabled entities, however i have only 1 Siren active and not such an entity for each virtual device.
My next action would be to exclude and include the doorbell again, but before i do that.
Can i ask which zwave2JS you are using? (i am running the ‘official’ Zwave JS integration and Addon) the all native version or the zwave2mqtt? I should read more of the history in this thread… from what i could read you are using the native integration in combination with zwavejs 2 MQTT addon.
And did you include the doorbell as a secure device? (i never bothered with secure inclusion to get started)
Just a quick update on the progress… (not tested all yet)
i moved to the Zwave JS integration with Zwave JS 2 MQTT using websocket communication and my binary_sensor.indoor_siren_6_and_doorbell_6_siren_siren_active now gives a status ‘clear’…
So small steps, but making progress.
Update… for a short while i received a status, now it is back to unavailable.
did not secure inclusion, that part I see no value yet, maybe later.
I do remember it had some issues being fullyl interviewed, its also the reason for mqtt addon , it offers the config panel for zwave and shows lot more info to play with.
Is your doobell complete with lots of fields in config and soundswitch?
the logic behind disabled entities is not clear to either, in some cases i had to enable a few to get HA work ok. Did not note down all these things. First i played a lot with config panel and triggering doorbell endpoints there. From there I got slowly all entities fine in HA
Thanks for the updates back.
I love the MQTT addon also, simply because of the more advanced admin panel.
what is currently shown in HA is the following
8 times the following set of entities.
Long time back (using some windows tool) i did update the soundswitch settings to lower the volume of the regular doorbell press. (still do not understand why someone would default a doorbell ring to 100 DB. )
I do see the soundswitch in the control panel, so i will update each group and see if something happens in HA.
So yesterday I was looking for battery reporting to HA on this thing and thought to try the re interview for having battery report fixed. Now it only broke my ‘siren active’ state. I’m left with 2 entities one sensor and one binary with active indication, but both unavailable in HA. So instead of adding something, i lost something i liked to have…
Acitivity is properly reported on [35-113-3-Siren-Siren status] Siren (property) in Zwave… but HA dont get this to the entity.
Something else i noticed:
[35-113-0-Siren-Siren status] Siren status is general device state afaik. So i think there is a few missing like 35-113-1 and 35-113-2. I can’t recall if i had them before (as i did exclude/include before i looked further on my issues).
i was correct, after triggereing the different endpoints in soudnswitch, [35-113-1-Siren-Siren status] Siren (property) did appear now… this explains kind of how i got multiple of those entities before (all 8 of them). But none of these now show up nicely in HA
Due to some rebuilding activities in my home i was not working on HA for a while.
I even had the Raspberry PI offline for a while, due to electrical work.
After starting it again there were a bunch of updates both on HA and also on ZwaveJS to MQTT.
When all the dust settled i all of a suddon noticed that the Notification event started working again.
So doorbell press generates events.
Not really sure if the server Idle time or the updates were the reason for it to become active again.
I was poking around to find a way to interact with my Aeotech Doorbell 6 and i found this site with some great help, just like earlier in this string but here are also the YAML text.
HA 2021.8 natively supports this device with the siren platform. Missing functionality is the ability to set the default tone and volume, which will be added in a future release (probably 2021.9), so you’ll still need to use zwave_js.set_value for that.
With the All new Siren support we also now have specific notifications of which siren is going off…
In the case of the ZW162 i now have a dedicated doorbell notification that triggers from the native entities. With regards to tone and volume, if you want to control this in runtime trough automation than indeed the set_value is one way. For me the config is static and i can suffice with using the control panel of zwave-js to MQTT addon.
I was able to get the ZW162 Siren 6 to work in HA without MQTT or manually editing any YAML. The following defined my settings to use a door/window sensor to trigger the number 2 alarm type. My door/window sensor is a Ecolink Model:DWZWAVE25.
Automation:
TRIGGER:
Trigger type: State
Entity: binary_sensor.deckdoor_access_control_window_door_is_open
ACTION:
Actions type: Call service
Service: homeassistant.turn_on
Targets: Indoor Siren 6 (2), Indoor Siren: Siren - Siren active (both are entities)
Those are configuration parameters, and HA doesn’t create sensors from configuration parameters, at least not yet (there is an exception though…). This method of reporting battery methods is not standard (config params can be unique per-device), the integration only supports battery levels provided by the Battery Command Class.
If you want to see these in HA, the easiest option might be to create sensors from the MQTT topics. If you’re not using MQTT, another option is value updated trigger-based template sensors.
Well, isn’t that a strange place to put that info. I never noticed they were under the config section.
I don’t use MQTT for zwavejs so I’ll see if I can suss out how to get them into HA via the trigger method.
Thanks for the info.
One day soon I’m going to have to (finally) complete the switch to zwavejs. right now I’m just going back and forth between zwave1.4 and zwavejs until I can find all the potential little gotcha’s…which are definitely getting fewer as time goes on.
what would I put as the required “property” in the trigger?
I found my device_id in the device registry and I’m pretty sure the “command_class” is 112.
but in this case I don’t know what the property would be.
with my limited knowledge I think for the full parameter:
[30-112-0-53-2147418112]
30 is the node id
112 is the command class
0 is the endpoint
53 is the partial parameter
the last section (2147418112) I’m not sure about - is that the property?
and just as a double check…
here is the trigger I think I will be using (once I figure out the property):