[RELEASE] Dome Siren (Official)

Did you go into the IDE and change the device to use the device handler? It looks like it was added to ST, but it didn’t use the DTH you published in the IDE. Give that a shot.

1 Like

Thanks johnconstantelo that fixed it :slight_smile:

1 Like

Hi all,
Not entirely sure if this has been discussed earlier; I’m trying to get a Webcore piston to use two different volumes for two different chimes on the Dome siren., however I’m not seeing much success. Yes I can make webcore fire off any of the sounds I want, yet it would appear the Set Level… action in webcore only affects the Siren sounds in the Dome siren, not the Chimes:

Looking at the DTH’s configuration I see there are two separate volumes, one for the sirens (sirenVolume) and one for chimes (chimeVolume).

I think I read somewhere that one cannot modify the configuration parameters (under the gear icon) for a device from Webcore,. One can only do this if the DTH supports it (how?), one can. Thus, if my presumptionis correct one would need to tweak the DTH’s code in order to expose the secondary volume change to webcore. Am I correct?

If so, could anyone throw me a bone how to do said mod? My Groovy skills are still somewhat on the McGyver stage, i.e. I’d appreciate any help.

Thanks a bunch.

You’re correct, that’s not possible to do from WebCoRE and the handler doesn’t support that at the moment, but in theory, if you make the changes below it should work. I haven’t tested that code so it might need to be tweaked.

You most likely need to wait at least a second after executing the volume command before playing the sound to ensure the volume changes before the sounds starts playing.

Add these commands anywhere below line 274:

def setChimeVolume(volume) {
	return [ configSetCmd(4, volume) ]
}

def setSirenVolume(volume) {
	return [ configSetCmd(1, volume) ]
}

Add these lines near the other command lines around line 94:

command "setChimeVolume"
command "setSirenVolume"

Hi Kevin, thanks for the speedy reply.
I implemented the code changes on the DTH, and after re-saving devices available to webcore, the two new custom commands do appear as expected in the list. I add a parameter with what I presume is the volume percentage, however I am not sure of the range nor datatype of the volume parameter (I’ve tried both integer and string) and put in a bunch of values like 500,250,100,50 and 25. None of them seem to change the volume noticably, unlike if I change the volume manually on the device’s setting page.

I made this little piston to test it:

image

Weird is that even through I’ve configured the cancellation policy to never, it seems chime2() doesn’t run, although it works fine in other pistons.
If it’s any help this is what the full piston log looks like:

6/3/2019, 3:05:26 PM +732ms
+1ms ╔Received event [myswitch].switch = on with a delay of 118ms
+63ms ║RunTime Analysis CS > 20ms > PS > 31ms > PE > 12ms > CE
+66ms ║Runtime (38123 bytes) successfully initialized in 31ms (v0.3.10c.20190522) (64ms)
+67ms ║╔Execution stage started
+77ms ║║Comparison (enum) on changes_to (string) on = true (1ms)
+79ms ║║Cancelling condition #2’s schedules…
+81ms ║║Condition #2 evaluated true (7ms)
+82ms ║║Cancelling condition #1’s schedules…
+83ms ║║Condition group #1 evaluated true (state changed) (10ms)
+86ms ║║Cancelling statement #3’s schedules…
+1042ms ║║Executed physical command [my.siren].setChimeVolume([100]) (949ms)
+1043ms ║║Executed [my.siren].setChimeVolume (952ms)
+1078ms ║║Executed physical command [my.siren].chime1() (31ms)
+1079ms ║║Executed [my.siren].chime1 (34ms)
+1083ms ║║Executed virtual command [my.siren].wait (1ms)
+1084ms ║║Waiting for 2000ms
+3105ms ║║Executed physical command [my.siren].setChimeVolume([50]) (16ms)
+3107ms ║║Executed [my.siren].setChimeVolume (18ms)
+3125ms ║║Executed physical command [my.siren].chime2() (16ms)
+3127ms ║║Executed [my.siren].chime2 (18ms)
+3131ms ║║Executed virtual command [my.siren].wait (1ms)
+3132ms ║║Waiting for 2000ms
+5153ms ║║Executed physical command [my.siren].setChimeVolume([25]) (16ms)
+5155ms ║║Executed [my.siren].setChimeVolume (18ms)
+5174ms ║║Executed physical command [my.siren].chime3() (17ms)
+5176ms ║║Executed [my.siren].chime3 (19ms)
+5179ms ║╚Execution stage complete. (5111ms)
+5180ms ╚Event processed successfully (5180ms)
6/3/2019, 3:05:24 PM +136ms
+2ms ╔Received event [myswitch].switch = off with a delay of 132ms
+83ms ║RunTime Analysis CS > 26ms > PS > 43ms > PE > 14ms > CE
+86ms ║Runtime (38118 bytes) successfully initialized in 43ms (v0.3.10c.20190522) (83ms)
+87ms ║╔Execution stage started
+97ms ║║Comparison (enum) off changes_to (string) on = false (1ms)
+99ms ║║Cancelling condition #2’s schedules…
+100ms ║║Condition #2 evaluated false (7ms)
+102ms ║║Cancelling condition #1’s schedules…
+103ms ║║Condition group #1 evaluated false (state changed) (11ms)
+106ms ║╚Execution stage complete. (19ms)
+107ms ╚Event processed successfully (107ms)

Any ideas as to what could be missing?
/Max

The device has 3 volumes so it only accepts values 1, 2, and 3.

this comment saved me…I could not figure out why the Config options in the app were wrong. Once I changed the Type setting in the IDE it worked correctly…thanks!

1 Like

Thanks for writing this handler. I’m new to Smartthings and learning WebCoRE. Everything works perfectly with the Classic app not so much with the new one. I was planning on using WebCoRE with the DOME siren but it is not appearing as an available device there. Is this normal? Any way around it? Thanks.

Custom handlers have virtually no control over the UI in the new mobile app. It should appear as a siren, but that’s about it.

It should show up in at least the actuator, switch, and Alarm lists in WebCoRE. It’s been a while since I’ve used WebCoRE, but doesn’t it have an authorized device list that you have to add new devices to in order for them to appear in the WebCoRE website?

After having hub issues today I was looking around for many answers. I accidentally found the allowed lists in the WebCoRE App but not on the website. Thanks for the reminder.

I installed the device handler, saved and published it but after connecting by brand new dome siren it still does not have any options for chimes etc. The app does recognize it as a “dome siren” but is only giving me the default alarms. I have updated, excluded, deleted. Nothing seems to work. Any thoughts?

I still have no idea why, but the built-in SmartThings DTH often overrides the fingerprints in my Dome DTHs so you have to open the device in the IDE and change the Type field to “Dome Siren” which will be near the bottom of that list.

The other possible issue is that you’re using the new mobile app because custom tiles are only supported in the Classic mobile app.

Hi, I know I’m late tho this party, but I’m making the switch over from Wink to ST and have two Dome Sirens I’d like to integrate. I followed the directions at the top of the post and pretty sure I have the device handlers installed correctly…but…

  • I see a Configure button in the app but it doesn’t do anything
  • In IDE, the device shows as “Z-Wave Siren” and when I edit it per these instructions to the Dome Siren from the device handlers, I cannot update - I get a “you are not authorized to view this page” error.

Any thoughts??

The SmartThings handler overrides the custom handler sometimes which is why it didn’t get assigned it automatically, but I’m not sure why you can’t change it manually in the IDE…

Does it save if you change it to a different handler like z-wave switch?

try using an icnognito browser window when updating the device type

Kevin,

Will the device handler for the Dome Siren ever be available in the New ST App? if not, are you aware of any smart siren that has similar functionality, meaning can work both as a siren and as a door chime when the motion is detected or someone opens a door open/close sensor?

Thanks!

@Bud_M I edited your post because we don’t allow signatures.

Thanks Jody. Sorry about that.

The UI might not work well in the new mobile app, but you should still be able to use it as a siren and door chime in the smartapps.

Thank you Kevin

© 2019 SmartThings, Inc. All Rights Reserved. Terms of Use | Privacy Policy

SmartThings; SmartApps®; Physical Graph; Hello, Home; and Hello, Smart Home are all trademarks of the SmartThings, Inc.