Missed motion events; outage?


If you check the smartthings graph event logs, do you see the motion clear events? I’m still thinking my issue is that the event isn’t making it to webcore

No, there are no events. I agree that it seems some events are not even making it to Webcore.


Yes, I do this a lot. The “Every day at X” block stays inside that block, and the normal trigger, ignores what is inside the EVERY block.

So even though they are written in the same piston, they act relatively independent…


Did you see my earlier post, @wjames2020?

The likeliest reasons occasional data is lost is one (or more) of the following:

  • Low battery in the sensor
  • Sensor too far from the hub
  • Poor Mesh network
  • Too much commotion in the home network at the time
    (pistons looping, downloads, gaming, streaming HD etc)


For me things was working fine and all of a sudden motion sensor stays active and lights not turning off. I know WCore gave likeliest reasons but, none of them pertains to me.


Yeah… It is incredibly tough troubleshooting four five different people in the same thread at the same time!!

I am constantly scrolling scrolling trying to only read one person at a time… (so I can respond properly) and then repeating those steps for the next person.

I still think the solution(s) are one of the many found in this thread… but if none of those resolve your issue, I would start a new thread so people can focus on one issue at a time.


Thanks WCore!! I will keep troubleshooting hoping I can figure out something and maybe help someone else in return.


Did you see my earlier post, @wjames2020?

  • Low battery in the sensor: Batteries are fine (multiple sensors)
  • Sensor too far from the hub: One of the sensors with missing events is only 5 feet away.
  • Poor Mesh network: Not sure how to diagnose this
  • Too much commotion in the home network at the time (pistons looping, downloads, gaming, streaming HD etc): Nothing else is using the Internet other than web surfing. (I am the only person here). Is there a good way to diagnose if there are too many pistons looping?

I noticed that if I go to the SmartThings website and look at motion states for the specific devices, the active/inactive list is 100% accurate with nothing missing. When I check my logs on WebCore, there are a few instances missing (and those correspond precisely to missed triggers). I am not sure if this is helpful.


Oh… This seems to contradict what was said earlier… My apologies.

If this second quote is true, then yes, my advice applies to you.

Essentially, if SmartThings is unaware, then webCoRE will be as well…


Oh… This seems to contradict what was said earlier…

My fault, I misread earlier today as I was preoccupied with resetting my SmartThings hub to see if that could help and spent all day putting it back together. (Bad idea, never doing that again.) So it seems that SmartThings is getting the data, but it is not showing up in WebCore. (Hope that makes more sense.)

Additionally, I’m also finding that daily timed events that trigger one piston are running, but not triggering the piston. (Basically, run a lighting scene at sunrise and sunset.) The Sunrise/Sunset piston tries to execute the piston, but the receiving piston doesn’t run. I think whatever is going on is based in my hub (maybe looping too much), but I am at a loss for how to troubleshoot that. :frowning:

Everything worked so well a week ago.


I have been having the exact same problem as OP. The major difference for me is that I have no hub in my setup. All of my integrations are cloud-to-cloud. I can guarantee my hub is not bogged down because it doesn’t exist. :slight_smile:

It seems related to me. My system was working perfectly fine until that outage.

I have a few pistons that trigger on location mode change, and none of them missed an event until after the Dec 19 outage.

I also have a virtual device that has exactly one piston listening to its events, and I have seen that piston fail to fire frequently, even though ST’s log for that device shows the events.

Seems that way to me as well.

Does anybody have any ideas how to troubleshoot this?

Edit, in case this information helps:

I should add that ever since that outage, I’ve seen these exceptions in the live logs, and they seem to correlate with missed pistons:

8:12:17 AM: error org.springframework.jdbc.UncategorizedSQLException: Hibernate operation: could not execute query; uncategorized SQLException for SQL [select this_.id as id88_0_, this_.version as version88_0_, this_.date_created as date3_88_0_, this_.`key` as key4_88_0_, this_.type as type88_0_, this_.value as value88_0_ from server_config this_ where this_.`key`=?]; SQL state [null]; error code [0]; [SimpleAsyncTaskExecutor-626] Timeout: Pool empty. Unable to fetch a connection in 30 seconds, none available[size:50; busy:1; idle:0; lastwait:30000].; nested exception is org.apache.tomcat.jdbc.pool.PoolExhaustedException: [SimpleAsyncTaskExecutor-626] Timeout: Pool empty. Unable to fetch a connection in 30 seconds, none available[size:50; busy:1; idle:0; lastwait:30000]. @line 1149 (processSchedules)

That exception refers to line 1149 in the WebCore Piston SmartApp, which is:

runIn(t, timeHandler, [data: next])


Is this helpful?

The first screenshot is from SmartThings that show four events, 2 Active and 2 Inactive. The very next screenshot shows the logs from WebCore. Both of the Inactive readings are missing. Is this what you are seeing ian_boje and dds82?


That’s exactly what I saw: events in SmartThings, nothing detected by WebCore.


This does appear to be what I was seeing, but it’s difficult to replicate. The one time that I did catch it in the logs, I didn’t screenshot it.


Okay, I’m thinking of trying some crazy things to confirm @dds82, @wjames2020 and my own suspicion.

I’m thinking about creating a virtual motion sensor, flipping the status every 10 minutes. Next, I’ll create a piston that increments 2 variables (ActiveCount and InactiveCount). If those two variables are more than 1 apart, then I feel it would confirm our suspicion. If I do this, can I create a webcore piston to flip the status, or would that exclude the communications with smartthings? In other words, would such a design start with Webcore Flipper Piston -> Smartthings -> Webcore Counter piston, or would it stay within webcore (Webcore -> Webcore)?

I guess I’ll try that this morning and find out. I’ll post my findings either way.


If you’d like to play at home, here’s my test:

Not pictured: A simulated light bulb, and a simulated motion switch created in the samsung graph control panel.


Below are some test results for today.

The flipper:

The counter:

To me, this implies that the counter piston missed 2 each of the active and inactive. I’m not sure if this isolates the issue any more or not, or this this behavior is normal. Has anyone else tried this, or something similar?


I would not expect them to match up.

Your {Flipped} variables change every 20 minutes…
Your {Count} variables only changes when the motion sensor changes.

Pro Tip:

An easy way to keep track of daily totals is to add a “Log to console” command in your code. This lets you easily go back and see what happened throughout the day.


Sorry, blonde moment…

I just noticed that your motion sensor is simulated, and in both pistons…


Wait, why not? Every 20 minutes, I flip the status of the virtual motion sensor.

Oh, you just replied.

I get those a lot.

Do you think this is an issue? Would you be willing to run these two pistons tonight? After posting, I noticed that I had a few of the local variables configured as Dynamic, when they should have been integers.

Do you know if this piston and simulated motion sensor would stay completely in the cloud, or does my local hub get involved?


If memory serves me right, I have never seen a command to a Simulated Switch not be properly processed…

(with the exceptions mentioned above… Pistons looping… multiple pistons firing at once… heavy downloading / streaming / gaming etc)

With SimSwitches, it is never the battery, distance, or poor mesh network… but the other reasons are still a possibility…

Need for back-up (or secondary) pistons)