Sometimes some of my door sensors get stuck on open, even if they’re closed. Is it possible to remotely reset the sensor without manually opening and closing the door?
1 Like
Is it a zigbee sensor? I have an override feature on a dth i found a little while ago and slightly modified. I havent had to use it yet so im not really sure if it works. I can share it with you though of course if you want to try it out.
Is this Smartthings Multi sensor? I have same issue with that… totally unreliable.
I’ve never had that issue with the SmartThings multi sensor but I AM having the exact issue with the monoprice Z-Wave plus recessed door sensors. It seems they stick “open” even when closed randomly. Re-opening and closing the door fixes it but I’ve had enough and will be switching them out soon.
-Allan
I have the issue periodically with both ecolink and monoprice sensors.
I’ve had both Iris and Ecolink sensors do this.
I had one Iris Contact that was giving me the Blues…Replaced it and same thing. Found out it was the placement. I had the magnetic piece too close. Since moving it out a little, I no longer have this issue.
Worth a shot. As far as the original question…I have no idea.
1 Like
Interesting all of you are seeing this issue. Just last night I threw together a DTH as a test case to attempt to “prove” whether this is a sensor issue or ST randomly “thinking” the sensor is open when it isn’t.
My case: one of three door sensors is reporting “open” at a second home 1500 miles away! No motion was sensed when the door “opened” and my homewatch folks confirmed the door is closed.
If I come up with anything conclusive, I will let y’all know! 
EDIT: the OP’s question is about re-checking a sensor & that’s what I’m attempting to do…
1 Like
Sorry, can you explain the 1500-mile-away part again?
It is a second location: I have two hubs in two locations 1500 miles apart. I can’t just pull the battery or open & close the door and say, “Hmm. Looks fine now!”
I have two contact sensors and a motion sensor that got stuck in incorrect status during the hub/cloud update today. Would be great to have a way to reset the status without having to physically cycle them.
1 Like
The trick with ‘Sleepy’ (battery operated) devices, particularly when you don’t have physical access to that device, is you can do whatever you need only when the device wakes up!
On my test device here on my desk in New England, I was able to cause the device to send its current state at wake-up: good, so far.
Have added a little more logging & want to see it wake one more time…
Then I will deploy the modified DTH on the contact sensor in Florida. But I don’t want to send that sensor out-to-lunch doing anything stupid. So am forcing myself to be patient and verify all is well with the DTH before doing so 
2 Likes
Awesome!!!
Give this a try. It has a reset for either open or closed. Also has a tile for when it was last opened and in the main tile it tells you the last time it talked to the hub. Can add a tile for last time closed if that is something you would want as well.
I haven’t had to try it myself just a heads up so not 100% sure how well it works. just thought I would share this
I don’t have a GitHub quite set up which is why this is in the form of a google doc. Copy and paste just the same.
1 Like
Thanks, Jordon! I’ll take a deeper look at this.
The DTH I’m playing with now has “last contact” and “last wake-up” on its display – plus a mess of logging for debug.
The main difference right now is I’m not forcing a new open/closed status down its throat. Rather, when it wakes I’m asking, “What’s your current open/closed state?” and updating accordingly.
I want to know if it was an errant message that set the state to “open” or if the contact sensor itself has lost its way.
We’ll see in the near future: I just switched the contact sensor to the experimental DTH 
2 Likes
OK, results are in! 
On Sunday, July 16 at 8:15pm, a GoControl Door/Window sensor on a slider (with extra pins locking it closed) caused SHM to alarm. I watched the interior motion sensors, as well as the remaining two doors – all of which reported “all is well!”
Seeing no other issues, I eventually removed the sensor from SHM, re-armed, and things continued as normal. Other than the bi-weekly visits from our homewatch company, nothing has alarmed since. They confirmed the door was closed.
Today’s Experiment: modified the stock DTH to make it always request open/closed sensor state, instead of only the first time after pairing with the hub. Also put in some additional logging & added tiles to display wake-up & last-contact times.
Eventually, the device woke up & said the door is “closed.”
Conclusions: some anomaly occurred (no kidding!) and the leading causes, so far, seem to be:
-
the GoControl open/closed sensor sent an “open” report and nothing since but battery updates. Seems possible, but unlikely, as no other contact sensor I have installed has ever done this in several years.
-
there is something wrong in the stock DTH. I’m going to do a code review & try to come up with some ideas – but that seems unlikely, since the sleepy device only woke to send battery reports. Still, there could be a bug in the way those ZWave messages are parsed.
-
something could have gone wrong in the ST cloud ecosystem. But, it has changed (probably) more than once since July 16th. It could be some race condition, which makes it nigh on impossible to track down – not to mention no public knowledge of the architecture or code. Perhaps ST folks on the inside might find this report useful in development or troubleshooting in the future…
In the meantime, this particular out-of-sync problem might be easily remedied by simply having “sleepy” devices occasionally update their status when they wake.
That’s what worked in my case.
2 Likes
Great work Barkis. Would you be willing to share the modified DTH?
Thanks! And sorry for the delay: we had company here and the dust is just now settling!
The change is pretty simple, if you want to hack it. I’m still tweaking my DTH modifications and would be happy to share it once I wouldn’t be embarrassed by it! 
The big issue is the stock SmartThings DTH either has a lot of leftover code in it or is trying to be-all for a number of device types (other than contact sensors). My mod clearly hasn’t been tested with anything but a contact sensor. So, it might break one of those other devices and I don’t want the heat, LOL! Perhaps I’ll rip it out and make this just for contact sensors: haven’t decided if it is worth it.
Here’s what to do: make a copy of the stock “Z-Wave Door/Window Sensor” (from the official ST repo). You might want to change the name and namespace in the metadata definition at the top of the file to make it unique for you. For example, here’s what I used:
definition (name: “TEST Z-Wave Door/Window Sensor”, namespace: “barkis”, author: “Barkis2”, ocfDeviceType: “x.com.st.d.sensor.contact”)
Then, simply comment out the conditional in the wakeup handler, as follows:
def zwaveEvent(physicalgraph.zwave.commands.wakeupv1.WakeUpNotification cmd)
{
log.debug "*** ${device.displayName} WOKE UP"
sendEvent(name: "lastWakeup", value: convertToLocalTimeString(new Date()), displayed: false, isStateChange: true)
def event = createEvent(descriptionText: "${device.displayName} woke up", isStateChange: false)
def cmds = []
if (!state.MSR) {
cmds << command(zwave.manufacturerSpecificV2.manufacturerSpecificGet())
cmds << "delay 1200"
}
// if (device.currentValue("contact") == null) { // Incase our initial request didn't make it
cmds << command(zwave.sensorBinaryV2.sensorBinaryGet(sensorType: zwave.sensorBinaryV2.SENSOR_TYPE_DOOR_WINDOW))
// }
if (!state.lastbat || now() - state.lastbat > 53*60*60*1000) {
cmds << command(zwave.batteryV1.batteryGet())
} else { // If we check the battery state we will send NoMoreInfo in the handler for BatteryReport so that we definitely get the report
cmds << zwave.wakeUpV1.wakeUpNoMoreInformation().format()
}
[event, response(cmds)]
}
Note I also added some logging in this function just to convince myself the device actually woke up and sent a message to the hub.
The next time the sleepy device wakes, the DTH just asks for the current state of the contact sensor by issuing a sensorBinaryGet command. The response will update the main tile to the current sensor state – not whatever is left over from the last time the sensor reported -or- whatever errant event caused the screw-up 
This change will affect battery life, so you may want to temporarily use this hack to get the device back in sync, then revert to the original SmartThings DTH. An obvious tweak is to add a ‘Refresh’ tile that sets a flag to make the extra request only when you ask, not all the time.
Good Luck and I’d be interested to know if this helps…
Once again: a false positive. But this time SmartThings thought an Aeon Multisensor 6 reported ‘motion’ when there was no motion. That caused Smart Home Monitor–which was set to ARMED(AWAY) since I was away from that location–to go into alarm & report an intrusion.
Different device, different hub, different location than the last time. I was, of course, at the other location at the time or probably wouldn’t have even noticed. Since I have no faith in using ST as a replacement for my alarm system, I still have the ADT system which has a motion sensor covering the same area. Sure enough, no intrusion detected by ADT. I took a look with a remote camera and saw nothing going on, cleared the alarm, mumbled to myself for awhile, and had a glass of liquid refreshment.
Fast-forward to today. As I had done before (see above), I modified the DTH to simply request the current status of the motion detector by adding
zwave.sensorBinaryV2.sensorBinaryGet(sensorType: 0x0C) //motion
in the refresh handler. Kicked off logging, switched to the modified handler, forced it to reset and…
the sensor reported ‘no motion’ as expected. Sigh. Here’s the log:
364d017b-900e-42b6-89c7-b6660399ff0a 4:33:43 PM: debug UV Report: 0
364d017b-900e-42b6-89c7-b6660399ff0a 4:33:43 PM: debug Illuminance Report: 13
364d017b-900e-42b6-89c7-b6660399ff0a 4:33:42 PM: debug Humidity Report: 32
364d017b-900e-42b6-89c7-b6660399ff0a 4:33:42 PM: debug Temperature Report: 78.7
364d017b-900e-42b6-89c7-b6660399ff0a 4:33:39 PM: debug Battery Report: BatteryReport(batteryLevel: 100)
364d017b-900e-42b6-89c7-b6660399ff0a 4:33:37 PM: debug * Dining Room Multisensor motion has stopped
364d017b-900e-42b6-89c7-b6660399ff0a 4:33:37 PM: debug SensorBinaryReport: SensorBinaryReport(sensorType: null, sensorValue: 0)
364d017b-900e-42b6-89c7-b6660399ff0a 4:33:35 PM: debug Dining Room Multisensor refresh()
This is the third false positive (that I noticed) in two years: the first last winter on a GoControl motion sensor, the second last summer on a GoControl door sensor, and now this Aeon Multisensor 6. All devices are still in service, still reporting correctly, and NOT needing a ZWave Repair or NOT needing to be removed/replaced like ST Support always tells us to do. Why on earth does Support think that is a solution for those of us with remote deployment?
At the moment I’m on the road traveling between locations and took some time to prove this again before arriving back home and walking into the field of the motion sensor–which would have corrected the problem once it generated a ‘no motion’ event.
@Kianoosh_Karami is this something of interest to you? I suspect a similarity to the issue you recently resolved for @LadySapphy. If not you, is anyone inside ST Engineering following these false positive events and attempting to get to the bottom of the problem for once and for all?
1 Like