Is there a way to recheck a door sensor?

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 :sunglasses:



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 :yum:


OK, results are in! :blush:

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:

  1. 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.

  2. 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. :thinking:

  3. 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. :sunglasses:


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! :roll_eyes:

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: “”)

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 :sunglasses:

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

Any comments? @Kianoosh_Karami? Anyone?

Sorry for the late response.

As for false events, I have not heard anything internally about a bug or a known issue that could lead to false events, however I do not want to say that is 100% and deflect the blame else where.

But one thing we can do is, enable extra logging on your hub and once it happens, I can take a look at the Radio to see if the device is the one originating the message.

And maybe… There is a ghost somewhere tripping the motion :slight_smile:

1 Like

Thanks for the reply, @Kianoosh_Karami. Sadly, the false positive events I’ve observed have been far & few between: three times in as many years on two hubs. No false negatives have been observed, but statistically you know they are also there.

Please raise this internally, should any of the developers be looking at anything related. It’s simply a fragment of information, but in my experience sometimes these kinds of things trigger thoughts leading to problem diagnoses.

Thanks for your consideration. At least a ‘refresh’ tile in a DTH might help collectively reduce the load on support. Folks like me with hubs at wildly different locations cannot pull batteries or ‘replace’ a device to make it work again…

It seems like there is a generic SmartThings issue where door sensor status can be lost. I have this same problem with my Dome Door Sensor Pros where the door will report open when it is really closed. The problem becomes almost completely reproducible if I trigger an alarm to my 2 Dome Sirens. So if opening the door triggers an alarm and then the door is closed, the status of the door will remain open.

I’ve reported this to support in the past but since my door sensor and sirens are not officially supported there is nothing they will do about it. I also reported it to Dome, but they say it’s a SmartThings issue. It’s clearly not a device handler issue since using a siren should not affect how a door sensor device handler operates. It also doesn’t matter what application or device handler I use anyway, the problem still remains.

Unfortunately, it appears information like this is simply being dropped on the floor—rather than being reported to engineering for further analysis or additional data points.

Anecdotally, this points to a systematic problem. It happens with more than a single device type or manufacturer. It is intermittent (which makes it even more difficult to diagnose). And, sadly, it’s so random and infrequent it may possibly never come up on a list of issues needing resolution…


In my case, having the door sensor trigger 2 sirens simultaneously makes the issue happen almost 100% of the time. When I use just 1 siren the issue becomes much less frequent, but still happens. When I use no sirens the issue happens rarely.

The point is that the system seems to get distracted managing the sirens and drops status reports from the door sensors on the floor.

1 Like

Any changes on your end, @capfan? Since this last false ‘motion’ report, I’ve had no more false positives. Yet.

I just wanted to thank Barkis for his solution as this worked perfectly for me for 3 open/close sensors using the default DHT modified to exclude the conditional use of zwave.sensorBinaryV2.sensorBinaryGet. OK, it now runs in the cloud instead of locally, but I’ve not noticed any issues so far.

1 Like

Appreciate the feedback, @chirpy!

Just be aware this mod probably affects battery life on the device itself, as it makes the device transmit on extra message every time it wakes. I use this trick just to get the device back in sync, then switch back to the original DTH.

Understood. Though if it’s between reduced battery life and a effective sensor, it’s worth it for me.


Ironically, here we are in November 2022–and there have been NO false events of either motion or door open since the aforementioned. We’ll never know why it happened!

1 Like