Is it possible to set up an association group with this device (#15270)? The documentation says it supports one association group but doesn’t say which number it is (I assume #1 since I think that is required by Z-Wave+) but I can’t get Z-Wave Tweaker to work with it (to be fair, Tweaker says it is for mains-powered devices only). If I find out that it is possible, I will put some more time into figuring out how to do it. I want the opening of the contact to turn on a couple of light switches directly, without needing to get the hub involved. This sensor and the switches are in a separate garage which has a very long hop to get back to the house and the hub, so it may not be totally reliable. I want it to turn on the lights without hub involvement for reliability and will live with the lights not automatically turning off occasionally.
Works great!! Thanks.
Is there a way to latch the signal in ST for a few seconds so that I can use the signal for an Alexa routine? The momentary switch it’s connected to isn’t depressed long enough for Alexa to see the state change. I appreciate any help with this!!
Official Monoprice Door/Window Sensor Device Type - Version 02.01.04
- Update for new ST app release causing contact sensor to not be displayed for some users
To force ST to use the updated UI after updating/publishing the DTH:
- My Devices -> Click on monoprice door sensor device -> Scroll down and click on Edit -> Scroll down and click on Update
- Force kill and restart ST app
The new ST app is still experimental so it’s recommended to continue using the ST Classic app to get access to all the features of the DTH
I removed an old alarm system and wanted to reuse- my wired basement magnetic window switches that are already installed, but with my Smartthings set up. The monoprice door/window sensor with the 2 screw terminals was exactly what I was looking for. The default smartthings device handler does not support the terminals (as reported in this thread- very helpful). I tried another device handler out there (not the RBOY one) - that was supposed to work and it did not work for me and I tried. I finally tried the RBOY one (requiring a fee to get my login to download)- and it does work - well. The RBOY instructions referenced above are very good and actually helpful. Thank you for those- nice product. You have to keep the magnet attached to the switch- that is counter intuitive to me- but that is mentioned in a couple places. So many possibilities to make unique sensors and to utilize existing wired sensors in old houses (where the wires are run). It is a shame its not easier and that no one makes a native smartthings sensor with two screw terminals for an external contact sensor !
This one works with the native SmartThings device handler, executes locally.
THANK YOU ! I should have purchase this one. next time !
I’m going to ask a stupid question here, but why would I want to use this device handler over what appears to be built into ST? I have 4 of the Monoprice recessed sensors and they seem to work pretty good. They aren’t 100% effective and are slow sometimes, but work decently.
Is that something that gets fixed when using this device handler?
Just to follow up, it looks like there isn’t a reason to use this device handler?
Hey there. Sorry for the delay. This device handler gives you access to devices advanced settings to allow you to customize its behavior, usage and also provides workarounds for quirks/issues in the firmware. Some devices can be used with internal or external triggering which can be configured using this device handler.
You can find more details in the first post.
No problem. That was the reason for the bump. I figured it got lost in the shuffle.
Would this resolve the issue of the sensors reacting slow sometimes? One time it’s almost instantaneous and the next time it takes 5 seconds. I’ll buy it right now if it does.
It sounds like your device is having connectivity or mesh trouble. There could be many reasons for this but usually adding a repeater within 15ft if the device helps make communications more reliable and predictable. See this topic for details, it refers to locks but applies to other devices as well: FAQ: why would I need another beaming repeater if my zwave lock is already close to my hub?
Thanks for the help, but I don’t think that’s the case. I have 37 wired devices and 6 wireless. There are 11 Zwave+ GE dimmers in the basement, and each of the basement wireless door sensors are about 3’ from their dimmer. I’m pretty sure that the GE dimmers are repeaters, so each wireless sensor is right next to a repeater.
An example of what the 24259 mailbox sensor looks like in action:
It has a tamper sensor built in so if anyone tries to remove/tamper with it, it’ll send a Tamper notification to ST which can be processed with a compatible SmartApp like this one to notify you or trigger a siren: [RELEASE] Security System: Intruder Alert with Actions - Entry Delay, Exit Delay, Countdowns, Keypads, Lights, Alarms, Pictures/Cameras, Routines
Any idea what the range is on this?
Depends on the setup but ideal conditions you can get up to 300ft or more. By design it says 500+ft but in practice expect between 50to 300ft depending on your setup, ie. mailbox construction (plastic, metal, brick), trees, landscaping objects etc. In our setup we have it at about 75ft from the building in the mailbox (open to the elements) and it’s been good for about 2 years now.
Do note that it always helps to keep a mains powered Z-Wave Plus device (repeater) connected to an outlet (GFCI) on the outside of the house, in the closest spot/direction of the mailbox and that helps a lots. Without the repeater device the range may drop significantly depending on how many walls/obstructions the signal needs to get through.
Occasionally one of my Monoprice contact sensors will still report “Open” even when the door is closed. I have to go and physically open the door and close it again to get it to report properly. This is an annoyance late at night when arming the SHM alarm, but a real problem when it happens on the front door where I have a lock controlled by the RBoys lock manager as it means the door won’t lock. Is there a way to ping the contact sensor to get an updated status to try to fix this without a physical presence? And if not, is there an easy way to override the “don’t lock if door open” setting in the lock manager to force the door to lock?
Sleepy devices cannot be queried like beaming/active devices. They are designed to wake up, report an event (open/close in this case) and go back to sleep to preserve battery. This DTH allows you to customize the wake up interval but reducing it (default is about 8 hours) to minutes will impact battery life and should be the last resort. It may be more effective to get to the root cause of the intermittent loss of events which is usually caused by a mesh issue or a bad device in the mesh.
Ideally make sure your sensors are within about 20ft of a active mains powered z-wave plus device. If you already have a few of them around then do a Z-Wave Repair and check the logs for any devices which may not be responding as they may be dropping the events. Some of the older zwave devices tend to stop routing messages after a few years (like GE) so it may help to exclude your mains powered devices, repair the mesh until you find the errant device and replace it.
As for LUM, you can skip the door sensor and it’ll re-lock irrespective of the door open/close state after the defined period.
@RBoy Having an issue with MP z+ door/window 15270. While it pairs with your DH on the app it is showing open, the tamper alert is a picture of a slashed cloud, but the battery reports 100%. I have tries to re-pair it a couple of times, but no change. just added another and it is doing the same.
That just means all the packets aren’t reaching the hub. As explained above, if you’re having trouble with pairing or status not updating, try these steps:
- Exclude the device (see first post if you’re having trouble)
- Factory reset it (see the end of the first post for the procedure)
- Test the battery levels (some are defective from the factory)
- Reboot the hub and then
- Pair it within 5ft of the hub (see first post for steps)
Also helps to add a buffering device between the sensor and the hub to buffer packets and avoid being lost in the mesh because the hub doesn’t buffer packets and this is a sleep device (i.e. it sends a packet and goes back to sleep, if the hub doesn’t catch the packet it’s lost without a buffering device in the mesh - as explained in the post one above yours).
The slashed cloud means that the tamper wasn’t initialized (i.e. the packet was lost in the mesh, open/close the device cover to resend the tamper information or follow the steps above until the packets are received by the hub reliably).
so far i managed to get 1 sensor to pair correctly right in front of the hub.