What’s the recommended setting for alarm duration when adding the siren in SHM if one chooses to use the hardware setting instead?
[RELEASED] GoControl Multifunction Siren v1.3
Numbered settings to make it easier to explain how to do things.
Added Delayed Beep feature with optional strobe.
Added the setting “Allow Siren Only Light” that turns the red light on without having it strobe when the siren command is used. (It requires setting #3 to be enabled and it doesn’t work with a delay)
Fixed delayed alarm bug.
I just released a new version that should fix this bug and should allow you to do the beep,strobe,beep,strobe,siren thing.
You may have to adjust the wait times a bit and if you skip the first beep and wait it will work a lot better.
Let me know if you notice any other problems.
Edit: Make sure setting #1 in the mobile app is set to at least 60 seconds or the both command won’t get executed.
If you go into the device’s settings through the mobile app, setting #1 determines the hardware setting and it can’t be overridden by a SmartApp.
If the device setting is set to 30 seconds and you set SHM to 15 seconds, the alarm will turn off after 15 seconds, but if you set SHM to 45 seconds, the device will turn off after 30 seconds because of the hardware setting.
If you’re using the delay with strobe feature, the device autooff count down starts when the strobe turns on, so if you set it too low, it can potentially prevent the alarm from going off.
When testing, make sure you disable setting #1 because the device’s timer doesn’t reset when you issue new commands. If you leave it on and you don’t wait the full amount of time in between tests, the device will turn off unexpectedly on a future test.
Great, thanks! I just didn’t know if sending an “off” command to the siren after it was already off via hardware would mess anything up. Only one week into smartthings :p.
You sir are a saint, I was using the Monoprice Device Handler and was never able to get a battery status. I load yours and get a battery status instantly. Much love
A suggestion regarding tamper detection – the motion sensor uses Alarm V2 specs (so 0x71: 2 and alarmv2.AlarmReport), and so can distinguish between motion detected and tamper detected via zwaveAlarmEvent:
cmd.alarmType == 7 AND cmd.alarmLevel == 0xff //motion or tamper cmd.zwaveAlarmEvent == 2 //motion cmd.zwaveAlarmEvent == 3 //tamper
Then, use any BasicSet message to clear tamper.
Thank you for the DTH’s!!! They are awesome.
I couldn’t figure out why the manual indicated that it raised the alarm for motion and tampering, but that makes sense now.
I just released a new version that fixes the tamper detection, but I left clearing the tamper detection a manual process since there’s currently a tile that displays it. I may just remove that tile, but I haven’t decided yet.
If the documentation doesn’t specify the version, do you normally just use a higher version and then if that doesn’t work, switch to a lower version?
I saw a difference in tamper vs motion AlarmReport payload from the sensor which was not being parsed, and just for kicks checked with VersionGet. Probably easier to just change the version and see what comes up.
(It’s actually incorrectly not specified as v2 in the zwave conformance database.)
thank you Kevin for this DH. I don’t need all the fancy stuff. I just wanted it to work
- I want to learn how to program DH myself. and
- I also want to know if it’s possible to re-program the GoControl/Linear window switches in any way to act not only as a sensor (input) to ST, but also as an output (although I bet I’d have to use an un-used I/0 on the main zwave board).
I’ve programmed microcontrollers, but zwave devices & ST is new to me!
If you have any advice about where to start, it would be appreciated thanks
The motion sensors and contact sensors sleep so you can only send them commands when they wake up which is usually every 4 hours.
If you want to learn how to program a DTH, you should start here:
Thanks Kevin. I’ll check out your link.
The GoControl Siren must not sleep, correct? in order to be open to receive an alarm command?
Or perhaps, it goes into a low-power wake-on-command state?
Do you have experience building any z-wave devices?
You are correct, the siren doesn’t sleep. Building devices or device handlers?
building devices - at least the interface part of it.
I think most of them use a z-wave module to take care of the z-wave circuit, all that’s left to do is make the interface board to tie the I/Os to the physical elements (sensors, lights, sirens, etc.), and also program the z-wave module for the job it’s suppose to perform.
I’d like to learn all this stuff. I’ll start with learning the DH.
I only have experience with writing DTH for existing products and some Arduino Sketches with the ThingShield.
A buddy of mine gave me a Vision Wireless Siren & Strobe Alarm as a gift this weekend.
It paired with no issues as a Doorbell (I already have the Aeon Labs Doorbell installed).
I went ahead and changed the device handler to the one in this thread.
The alarm is responsive as long as I have “always set alarm type” on. (Without this setting it does not function at all).
The strobe however does not work at all, no matter what settings I have tried (and I have tried them all). The alarm however works with all three options and the beep also works.
I can get the strobe to work occasionally, so I know that the device itself functions but it is not reliable.
Full disclosure, I’m not in any hurry to get this up and running (I’m not even sure what I’m going to do with it) but I would like to use the strobe only function if possible for a nighttime parameter alert (let me know but not the kids).
Anyone have any suggestions or ideas?
_Item No. : ZM1601-5 Wireless Siren and Strobe ZM1601-5 will sound a loud siren and flash a strobe light when an alarm message or alert is received on any Z-Wave enabled network. When the device is secure included into Z-Wave network, above communication will be encrypted.
A EU version of the manual can be found here but this was a US device.
Thanks for any & all help.
The GoControl device doesn’t support the Security Command Class so I didn’t build that functionality into this DTH.
If your device is paired securely, that might explain the behavior you’re seeing. Usually if a device is paired securely, the configuration commands have to use encryption.
When “Always Set Alarm Type” is disabled, the DTH requests the current configuration value, waits for a response, changes the alarm type if needed and then turns the device on. If the device is sending the response encrypted, the DTH won’t receive it so the device won’t get turned on.
When “Always Set Alarm Type” is enabled, the DTH changes the alarm type configuration value and then turns the device on without waiting for a response. Since the alarm type configuration change is being sent to the device unencrypted the device doesn’t get it, which explains why it turns on, but isn’t using the alarm type that you specify.
If you s end me the raw description, which can be found in the IDE device settings, I can verify that your device does support the security command class.
If it does, I think I can add that functionality to this DTH so that it works with and without secure commands, but I’ll need to do some testing to make sure. I probably won’t have time to play around with it until next weekend.
Ahh makes sense, also a fantastic explanation.
I’m not in any rush and I do appreciate you taking a look at it and for all of your hard work on the handler.
Here is the Raw Description:
zw:F type:1005 mfr:0000 prod:0000 model:0000 ver:15.10 zwv:4.05 lib:03 cc:5E,85,59,80,70,5A,7A,72,71,73,98,25,86 role:07 ff:8F00 ui:8F00
Let me know if you need anything further I would be happy to provide it.
That’s weird, it looks like the same device as the GoControl/Linear siren and the zwave configuration settings are the same, but only yours uses secure commands.
When I have a moment I’ll take a look at it, but in the meantime, if you wanted to, you could try removing the device and try to get it to do a non-secure include.
If you move the device as far away from the hub as possible and change the fingerprint line of my DTH to the following, it might work, but I’ve never tried it.
fingerprint deviceId: "0x1000", inClusters: "0x85,0x59,0x80,0x70,0x5A,0x7A,0x72,0x71,0x73,0x98,0x25,0x86"