Window sensor triggered quickly not reporting correctly

I have noticed that a z wave window sensor, if triggered open/closed very quickly, will get stuck, and does not report the correct status.

More details:

I have made several devices from door/window sensors that will report if the power is off on the circuit they are plugged into. I’ve used both types of sensors; those that have contact terminals and those that don’t. The devices report perfectly “IF” the power goes off for at least 2 seconds. When the power goes off, it changes the status of the sensor to open. When the power is on it changes the status to closed. If I manually trigger the power by unplugging the power to the device and plugging in again quickly, say 1 second, simulating a quick power outage, the status will change to closed, but will never change back to open even though power is being supplied to the device. It appears that the device needs at least 2 seconds in the power off / closed position or it will not recognize the open status again.

I’m wondering if this is a limitation of the device or if something could be changed in the stock device handler to accommodate the quick trigger. I’m using Ecolink DW-ZWAVE2 sensors with the internal screw terminals as well as sensors that don’t have terminals that I just cut in the switch.


i use the 2.5 and they work

What is the 2.5?

zwave plus version

Will they show “open” - “closed” as fast as you can trigger them? I have one z wave plus device without the terminals and it gets hung up on quick triggers.

when i tested it before it always reported correctly.

Since window/door sensors probably aren’t designed to be opened/closed within 1 second, I assume this might be a limitation of the device.

1 Like

yes, thats most likely. i do run 2 on each circuit at opposite ends for fall back.

This, although it’s more a limitation of the protocol.

Mesh networks themselves, because they don’t guarantee sequencing, are not intended for sub second reporting. A message can take different paths around the network, or fail and have to be resent, so if you open and close the door really quickly it is entirely possible with a mesh protocol like Z wave or zigbee that the close report will arrive before the open report.

If you need guaranteed sequencing, or even just multiple commands sent in less than two seconds, you really need a protocol like Wi-Fi or something else with continuous connection and a single routing path.

The usual guideline for Z wave and zigbee of the type that SmartThings uses is 2 seconds between transmissions. It might work if you do it quicker, but again, it might not. It just depends on how busy the network is.

Mesh has a lot of positives, in particular excellent power usage which lends itself to battery operated devices and network resiliency, again good for when you have battery power devices and you want to be able to change the batteries without having to do a whole remove and re-join process.

But one of the negatives is no guaranteed sequencing.

1 Like

Thanks JD- I was hoping you would chime in. In my “unscientific” testing, 2 seconds is what I come up with that “works”. I was just testing something else before I saw your post. It seems to say exactly what you said. If I switch the device quickly - right next to the hub - it works 100% of the time. I’m assuming that’s because it is taking a direct route to the hub. This device will not be close to the hub, so it will most likely have 3 jumps.

If I leave it in the “stuck” position, will it ever catch up? Because it would physically be in the “open” state, (using the dry contact in the device), I would think that at some point it would change from “closed” to “open”. Is that possible?

It probably won’t change until a new event is sent from the sensor to the hub. So if your account thinks it’s closed and it’s actually open, The next time it’s closed it will send the closed report and then they will be in sync as closed. But it won’t show as it’s open until it sends an open report, which won’t be until after it closes and opens again.

But again, it depends on the model. There may be some which will send a new status report even without a state change.

I don’t think any of the devices I modified to use as the power sensor are sending an updated status report. The only way I get it to sync is to unplug and plug it back in, hence the updated report. If I’m away, I can log in and change the device type, then change it back. It will then report the correct status. That’s why I wondered if I could modify a DTH to force a status report. I can’t find anything on that yet.

It will depend on the model, there are probably some when you can. But most manufacturers of zwave or Zigbee devices will not set it up that way, because you would be using up battery power to send what might very well be an unnecessary report. Most of these are really designed to be event driven.

So it seems maybe the best solution might be to find a small device like a line conditioner that would smooth out a power Flicker and avoid the quick trigger. I’m not sure if such a device exists that would be small enough not to continuously Supply power to a device that’s only drawing 5 volts after the power actually goes out. I will start my search…

1 Like