Contact Sensor Reset when away from home? (Ecolink Contact Sensor Errors)


(Paul) #1

I have 16 Ecolink door and window contact sensors and occasionally, one of them will report “Open” even when the window hasn’t been opened in days (probably 4 different ones have done this so far). The only way to fix it seems to be to manually open and then close the window and it will reset and correct itself.

However, this has happened when we were outside the home and it even triggered the alarm. Has this happened to anybody else? Is there a way to “reset” the contact sensor via the app or even the IDE so that it will re-examine its status and correct itself? Any SmartApps that would do this thing?

Thanks!


#2

Hi @paulseverio, I have tons of those contact sensors, and every once and a while I’ll have one that does that. Typically I’ve been back to open/close the window, but I thought more about your questions.

What could be done, in theory, is to simply create your own device type using ST’s exact code, and then in the IDE use the simulator to force a state change. When asked “Choose a device to test with”, pick the real device from the list and simulate an open/close. Just thinking through the process, it should work. The next time this happens to me I think I’ll try that.


(sidjohn1) #3

The support article may help


(Paul) #4

Great idea. However, I got stuck at simulating the “open” in the simulator. Since this isn’t a button or something like that, it isn’t as easy to send a command. Basically, it sounds like you know a lot more than I, so some more help would be greatly appreciated :smile:


#5

Not related at all. This is an Ecolink and they’ve been known to do this at times. I have 1 no further than 10 feet direct line of sight to the hub.

As soon as I can get to my PC at home I’ll try as well.


#6

Hi @paulseverio,

Ok, I finally got around to coming up with a solution that does not require physically touching the sensor. I had an Ecolink sensor do this about an hour ago, so it motivated me to get this done!

NOTE: Please make sure the sensor isn’t really open for any reason. For the sensor I had to this to, I could see the window via a camera, and I knew it wasn’t open and the magnet didn’t fall off.

You can either use the IDE simulator and pick your sensor to force close, or you can edit the device to use this device type and tap on the FORCE CLOSE tile. Either way works, and it will show you the open/close state once you do it. It works, and saved me a trip to the window when I wasn’t anywhere near it!

https://raw.githubusercontent.com/constjs/SmartThings-Devices/master/force_close_contact_sensor.device.groovy


(Paul) #7

Very cool, thanks!

I don’t really know how to test it until this error actually occurs, but I’m looking forward to trying it.

Is this essentially telling the device to “refresh and verify your state” or is it forcibly telling it “your state is closed”?

I’ve tried merging this with the existing z-wave contact sensor device type so that I can quickly access the tile from the app if needed (without needing to go into the ide to change device type). I’ll test this the next time I have the error.

On a somewhat related note, do you know anything about why some of these sensors report “null” on the battery, while the others (of the same brand/model) seem to report an accurate percentage? Any way to force these to start reporting normally?


#8

It’s forcing the state to be closed. The device itself is correct, and it never sends an “open”. Why ST all of a sudden thinks it’s open I have no idea.

Including it in your own device type is going to be handy when/if this happens again, as well as not having to mess with the IDE. I thought of that myself, but I opted to stay with ST’s default device type so I can keep local hub v2 processing in tact.

I’ve had this happen on 2 sensors after I added them to the hub. I think it’s related to something not happening right during the initial pairing, but I can’t validate that. I did make sure that I was within a few inches of the hub when pairing sensors, and I haven’t had issues since.

To resolve one of my incidents, I just opened the cover for a few minutes and then closed it. That caused a “cover was removed” event log entry, and within a few minutes I got a battery reading. The other one I needed to exclude and re-include to resolve.


#9

I just installed 10 of these on Monday, and have noticed the same thing. Does it seem to be ST related? The couple instances that I’ve seen so far (1 bedroom window showing as Open on Weds., and sliding door showing as Open this morning before I left), I see no corresponding messages in the ST history. That makes me think ST is just wrong, and for some reason decided to change the state itself.

Here’s a couple screenshots of the sliding door sensor this morning. The log is scrolled all the way to the top, and the last open/close event was registered as 8:03-8:04pm last night, but the sensor was registering as Open since sometime last night (got the SHM is armed, but sliding door is open warning last night). It was reset by opening and closing the door after taking these screenshots.


#10

I don’t believe this to be an ST issue, it’s more like a sensor issue. I have lots of different kinds of open/close sensors, both zigbee and zwave, and it’s only the Ecolink sensors that cause me grief.

After using these sensors for over 2 years, I’m convinced the reed sensor on these things can be either too sensitive and/or buggy. I have one in particular that whenever the temperature changes too greatly too fast - it will trip. I can repeat that scenario any time I want.

Most of mine work great all the time, but if I were to start over I’d go with the Iris open/close device. I’d still use the Ecolink sensor when I needed a dry contact solution (like my mailbox or doorbell, and others), but not for regular door/window use.


#11

But how does the displayed state change to Open in ST, without showing an event that shows the change? Even if the ecolink was triggering a change due to temperature or other false readings, shouldn’t it show up in ST?


#12

I have no idea, and I don’t disagree with you. ST must be capturing the event because I have a custom rule in SHM notifying me of when I have a window open. Ironically, I just had this happen last night with the sensor impacted by temp changes (happens at least 2 times a month). It’s right next to our large garage door:

@6:49pm I was sitting at my PC when that message happened and I was notified it was opened, so I walked out to the garage and opened and then closed the window (closed at 6:51pm)

I believe the reed sensor did actually trip (notifying ST @6:49) without actually opening. When I really opened the window (not being notified), and then being notified when it closed (@6:51), tells me that moving the magnet past and then back to the reed reset it.

The next time this happens I’m going to leave the window closed and take a stronger magnet to the sensor and see what happens.


(Paul) #13

I hate that these sensors still do this. Thanks again John for creating a great force close button on a device type. I slightly modified so that I had a device type that I could use all the time (containing the force close button). However, to your point, it would no longer be local since it was a custom device type, so I only use it when i need it. Either way, you helped to solve the headache of when these things occur and you aren’t physically able (or willing) to go close them yourself.


#14

Happened again last night, kitchen sliding door was “open”, but no event was triggered or logged under the sensor. When SHM armed last night, it notified me that the door was open, but no record of the state change.