I posted this originally in the Devices and Integrations thread and was advised to move it here…so here it is
I just got the dome siren (pretty slick little device) however, I have one complaint. The siren has a delay which is pretty darn awesome especially since it will beep to tell you it’s in the pending state. However, if I tell it to repeat the beep x number of times, it beeps that number of times very rapidly then is quiet until the siren sounds.
A preferred operation would be to beep perhaps every couple seconds for the period of the delay. I’m in the process of combing over the dth hoping to remedy this, but thought I would drop a line to see if anyone can tell me if this is proper behavior or a bug. Or if you have found a work around yourself. Thanks.
You can’t load new sounds onto this device, but chime #2 is “beep beep”.
You can either use the custom sound option in SmartApps like SHM and enter “chime2” as the message. It’s also mapped to one of the default sounds shown in the list, I think it’s piano 2.
The “Chime Repeat” feature is built into the device so I have no control over how quickly it plays them.
The Delayed Alarm feature is custom and it’s designed to play the single beep sound every 2 1/2 seconds during the delay.
If you have Chime Repeat set to 1 you will hear 1 beep every few seconds during the delay. (Assuming SmartThings didn’t break something recently.)
In theory, if you have Chime Repeat set to 3 you should hear 3 quick beeps every few seconds during the delay.
The DTH doesn’t have a tile that executes the “both” command so the only way to test the delayed alarm feature is to trigger it through Smart Home Monitor or some other SmartApp.
My Dome DTHs are Official so I wasn’t always able to implement them the way I wanted to…
Thank you, that’s sort of what I thought the design intent was when I saw this event.
// Executes a beep during the beep delayed alarm and creates events for device turning on.
def zwaveEvent(physicalgraph.zwave.commands.indicatorv1.IndicatorReport cmd) {
I didn’t understand what made it repeat. For some reason it beeps the set number of beeps I defined then executes the siren after the delay with no additional beeps. I’m adding some debugs to understand the order of execution and may add a tile for testing. I’ll also read up on the Siren’s documentation. Thanks again for your reply.
It looks like the delay commands are really unreliable right now so the DTH wasn’t receiving the IndicatorReports and was unable to start the next beep.
I just released a new version that should fix the beeping during the alarm delay. I’ve tested it with Chime Repeat set to 1, 3, and 5 and didn’t run into any problems.
Make sure you wait the full delay time before starting another test or the alarm will go off early for the second test.
Example: You have a 60 second delay and you cancel the alarm after 30 seconds. 15 Seconds later you trigger the alarm again, the alarm will sound after 15 seconds instead of 60 because that’s when the first alarms delay finishes.
It looks like we just posted at the same time so I just want to make sure you’re aware that I just released a new version that should fix this problem.
would love to see a map to what siren/alarm/chime maps to which selection in SHM.
I’m trying to get a simple door chime setup for any door/window contact that opens/closes.
Driving me nuts picking each one (still do not have it correct)…
If there was a mapping that said, if you select “Bell 1” then (fill in blank chime/alarm/alert number) will be played.
RIght now it is trial and error.
Or at the least say how the order is… is it:
Default Message=Alarm
Custom Message=Siren1
Bell1=Siren2
Bell2=Chime1 … and so on?
OR
Default Message=Alarm
Custom Message=Siren1
Bell1=Bell1
Bell2=Bell3
Dogs Barking=Bell5 … and so on?
I recently installed 2 Dome Sirens in a system with multiple existing Dome Door Sensor Pros. I’m using the Smart Home Monitor to trigger a chime anytime a door is opened. However, I’ve encountered the following issues and was wondering if anyone was having the same experience:
Door sensors frequently not reporting Closed when chime is used. If I remove the chime functionality from Smart Home Monitor, the door Closed status behaves reliably again. Also, I know the door sensor hardware thinks it’s closed even though the device handler reports open since opening the door will trigger the chime.
Chime status in device handler randomly gets stuck on and can be fixed by pressing Off in the app.
Even though I have the chime set to repeat only once, the chime often repeats multiple times until stopping.
Also, these issues seem much more prevalent when I have 2 chimes installed versus only 1.
So ive gone through this whole thread and have not been able to get the siren to work consistently. I have the latest handler 1.2.2. I get the device added and it shows up correctly. When i click one of the sounds it will play one or two and then nothing. No matter what button i press the siren does not make a sound. The live log shows that the command is being sent out it will say playing chime(whatever number). Ive tried removing and re-adding and every time i re-add i will get one or two sounds to play then nothing. Ive removed the battery for 10 minutes to no effect and tried resetting to factory. Dont know if there is anything else to try before returning.
I’ve had similar behavior that became more frequent after trying the Speaker Companion app for the door chime instead of Smart Home Monitor. I have 2 Dome Sirens and when I enable two Speaker Companion apps it is incredibly unreliable. Sometimes only one chime dings and the number of chimes varies from time to time. When a door chime request is sent out it seems to block the “Closed” status from being reported on my Dome Door Sensor Pros and my GoControl garage door opener at least half of the time, so my open/close sensors are stuck reporting open when they are really closed. Removing SHM and Speaker Companion resolves all of the open/close status issues.
I’m not sure if contacting SmartThings support will accomplish anything since the Dome Siren is not an officially supported device, yet looking at the logs it seems like status commands are simply getting lost and not forwarded to the proper device handlers.
It’s not possible for one DTH to effect the state of another DTH.
I’m not sure about the iOS app, but the Android app has really bad caching issues which cause the states of devices to appear stuck. If you open the device in the IDE you can see what it’s actual value is.
My Zooz DTH has a bug with the status sticking, but I don’t believe this one does so it’s most likely the caching issue mentioned above.
I don’t believe I’ve seen this while using 1 of these sirens with Smart Home Monitor, but I’ve seen it occasionally happen when using 2, and it happens all the time if you’re using 3. The issue is happening outside of the DTH so there’s nothing I can do to fix it.
I will need to check the device status in the IDE as I’ve been relying on the iOS app. However, I have tried the refresh button in the iOS app for the Dome Door Sensor Pro and after refresh it continues to have the wrong status. When this occurs with my garage door controller (mains powered) the status will be wrong until I do a refresh and then it corrects itself.
Also in the IDE Logs I simply do not see the Closed status get reported half of the time while I stand there and open and close the doors with multiple chimes enabled. This just seems like a generic Z-Wave issue where status from any Z-Wave device can get lost when the SHM/Speaker Companion issues audio notifications to multiple Dome Sirens. Would this explain why the Siren status also gets stuck on periodically?
Thank you!!
