Problem with Sensor Was Closed At Least X Minutes

#1

Hi guys - I’ve had a piston that’s been working for a few years without any issues. I’m running webCore v0.3.110. Maybe this functionality broken when I updated webCore weeks ago and I just hadn’t noticed, but I can’t think of any changes I’ve made to the system and this piston hasn’t been touched in a long time.

The piston is designed so that (among other things) when th piston contact sensor changes to open, it checks to see if it has been closed for at least 240 minutes. If so, it goes on to do other things such as turn lights on.

For some reason this stopped working a while ago, but I’m not sure when it broke.

I’ve included only the relevant portion of the piston for various reasons, but hopefully its enough to get some ideas. I also included the logging:

image

image

I debugged this today and found something quite odd. As you can see from the log, it did properly detect that the sensor’s contact changed to open, so the first part of the IF statement passed. BUT the second IF condition that checks to see if it had been closed for > 240 minutes evaluated to false according to the log, but should have been true!

I checked the detailed Device Info in SmartThings for this sensor. It shows that prior to this state change, the state had been Closed for 10 hours (600 minutes). See this:

image
image.png1144×135 4.77 KB

It seems the logic of the piston is correct, but for whatever reason webCore doesn’t know the proper amount of time that the sensor had been closed. I’m not sure how long it things it had been closed, but certainly it thinks it was less than 240 minutes or the condition would have evaluated to true. :slight_smile:

Any ideas what may be going on here and how I can troubleshoot it further? I don’t think the issue is with the piston itself since it had been working for a very long time without any changes to it. So perhaps something changed in webCore or SmartThings and therefore I need to take a different approach to determining if the door had been closed for 240 minutes? In fact, I’d be happy to just change it to a different type of condition/check if that may solve it without having to troubleshoot more…

Thanks everyone!

#2

Not sure what is going on. You might try this formula to check the time closed:

(previousAge([Contact Sensor 3 : contact])-age([Contact Sensor 3 : contact]))/60000

The 60000 is to get minutes as the function result is in milliseconds.

#3

Thanks. However when you say to “try” it, try it where and how exactly, please? I suppose you mean add logging to see what the value is. That may give us an idea, like maybe it will show its 0 minutes and somehow the age is getting set to 0 upon the Open, before the logic can execute?

#4

There have been some changes to the device event history of late, but they are more about excluding anything that isn’t defined by a capability, and presumably ‘contact’ is being implemented as part of the Contact Sensor capability so it should be OK. Indeed you can see it in the IDE so it must be OK. It is rather baffling.

#5

Any ideas on how to troubleshoot it further? I suppose the logging statement I added will just confirm that it think its been less than 240 minutes, but then what? :smiley:

#6

I think it may have been offered for use as an expression on the left side of a condition that compared it to 240. As you say if it doesn’t come up with the right number it doesn’t really help.

However it would be interesting to know what it does produce.

#7

To recap, I added the expression that guxdude provided to the logs in the ELSE part of that if statement so I could see what the count was. So far its been logging good values. For instance it was 80 minutes since I last opened the door and when I did, it showed “80” in the log. I’ll know in the morning once its been more than 240 minutes. If that expression prints a number higher than 240, which it should, yet the if statement still didn’t trigger, then I guess my next step will be to replace the “if contact sensor was closed for at least 240 minuts” with if [guxdude’s expression] is < 240 …

That seems like quite an ugly hack to get it to work but hey if it solves it then it solves it. :slight_smile: Although I suppose that would mean that something isn’t right in the depths of webCore/SmartThings, since that shouldn’t be necessary…

#8

Sorry, busy day so haven’t been online until now. Yes, my original intent was to insert this expression into your if statement. Is is an ugly hack as you said but the beauty is it works. :slight_smile:

#9

OK so I changed my original IF statement to use the code suggested by guxdude, instead of the “contact was closed for at least” code, and now it is working perfectly fine again.

So although this does resolve the issue (thank you @guxdude and others!) it does raise the important question - why did the old code work and no longer does? Does this point to an internal issue in webCore (perhaps something is broke) or within SmartThings. Should we let the developer know? If this is broke, maybe other things are broke too without knowing it.

#10

Is there a reason to use that full expression with the -age second part, instead of just using (previousAge([Contact Sensor 3 : contact]) by itself? It seems to do the same thing, I think…?

#11

Just wanted to say the exact same thing happened to me, so so glad I found this post! I had a ‘garage left open’ piston running perfectly for years, which would trigger if I was home, contact sensor was open and the garage motion hadn’t detected any motion for 10mins - worked flawlessly.

But about for the past 4 weeks or so, it woukld pretty much trigger any time the garage was opened - the timer/motion condition just stopped working. I’m currently trying a few other approaches within Webcore, but have yet to be successful. Very strange…

#12

The full expression will always give the time the sensor was at the last value. previousAge() is the time since the value changed to the last value and age() is the time since it changed to the current value. if age() is close to 0 (i.e., the value just changed), subtracting it becomes unnecessary.

#13

Changes were made to the ST event history beginning on the 26th October. They don’t look like they ought to make a difference to events that conform to capabilities, though they would to custom attributes.

#14

How can I officially report this as a bug to the webCore developer(s)? Since a few of us here are reporting the issue now, it seems there may be many others wondering why their pistons are now broken, or who may not have realized it yet.

#15

If the earlier logs are full logs, I would half expect that there ought to be a message about the ‘duration’ appear in the logs, though I haven’t looked into things too deeply.

Out of curiosity, are the devices in question legacy devices or new integrations? Just wondering if that now matters.

#16

In my case the device is about 4 years old.

#17

All of the devices in my piston are ST contact sensors and motion sensors, no custom DTHs either.

#18

What’s the procedure for bringing this to the attention of the webCore developers?

#19

As SmartThings transitions over, there will likely be quite a few commands that need to be tweaked.

Thankfully, @guxdude shared an elegant expression that does exactly what you want.

#20

Sorry I haven’t been around these boards for a while. ST transitions over to what exactly? Yes it is great to have a working solution for this. However I wonder if I have other pistons that need to be tweaked which I haven’t noticed yet, and how many other people out there that are affected by this. So you think it will just naturally be corrected and there is no need to officially report it? I’m not sure what that procedure is these days anyway. Thanks.