Problem with Sensor Was Closed At Least X Minutes

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

#21

It looks like a 12-18 month process, that we are about halfway thru.
I don’t have my links handy, but they are steering away from groovy based code.
(different requirements, limits & capabilities etc)

If looking for problems, one will never be disappointed …

Personally, unless it is security related, I typically only analyze old code when something goes wrong.

I think by you creating this thread, you have. All the devs read these posts.

Personally, the way I look at it is:
SmartThings & webCoRE are designed to work with a lot of different devices. This means, for any device, only SOME of the code will work with it. (IE: It is normal that certain code will not work in certain scenarios)

Going forward, I expect many things to break as the devs implement new changes. Some might “magically” fix itself, and some will need to be re-written, if no longer compatible.

Ultimately though, it likely means that each automation will need to be looked at at some point or another. I am checking out mine if/when I notice anything peculiar. (There is no way I am sitting down to tackle 222 pistons at once, LOL)

All that said, you are more than welcome to create a new topic in the “Bug Reports” category.

pic

You can link back to this thread for reference.

Edit:

Link to Bug Report.

webCoRE Optional Update v0.3.111.20210130