I’m new to WebCoRE and Smartthings and haven’t done programming in 15+ years during college.
All I’m trying to do is when motion is detected from a camera, send a text to my phone. I plan to do more than this based on what mode I’m in…but if I can’t get this figured out, no sense in building it.
Webcore has their own forum now where most of their experts hang out. You’ll get the fastest answer if you ask there. 
https://community.smartthings.com/t/introducing-the-new-webcore-community-forum/96259
Also note that daylight savings time appears to have broken some time-based events in webcore:
So you may just have picked a bad day to start. 
The main issue I see with your piston is you are using the only/when blocks but you are not defining them properly. A better structure for your piston would be to use one if/then statement
If
Any of Motion is detected blah blah blah
Then
Send notification.
You can can find example pistons at the link @JDRoberts provided or their forums…
The webCoRE server is only used to statically serve the UI code (HTML+CSS+JS) - it is not directly involved in any execution or subscription. While there was nothing wrong with any webCoRE server, there was a bug in webCoRE that we all discovered the hard way (ouch) - webCoRE uses UTC times internally for timezone and (ironically) DST support. Time operations, however, need to be performed in the local timezone, not UTC. Ironically, while the bulk of math on datetime happens in the local realm, there was one line of code trying to make sure the timer scheduling does not start in the past, adding 86400000 milliseconds (that’s one day) to the current time if that was deemed past. It was doing this in the UTC realm, instead of converting to local time, adding a day, going back to UTC. The problem arose from the fact that while I am adding 24 REAL hours to the time, the distance between (for example) Nov 5 2am EDT and Nov 6 2am EST is really 25 hours, not 24. That meant that adding 24 hours led to the time pointing to Nov 6 1am EST, explaining the one hour off. The worse part came when you had a timer for every 5 minutes for example. Nov 5 2am EDT + 5 minutes would magically result in Nov 5 1:05am EST - note the timezone switch from EDT to EST - which happened to be … well, in the past. That caused the piston to run again immediately, not in 5 minutes as originally intended. From there, pistons started spiking up in executions and ST’s systems entered self defense territory where that particular code version got rate limited, resulting in the apparent “nothing works”. ST reported the issue to me right away (hats down, bows, etc. - exemplary behavior right there) but I was too asleep to notice until some 9am in the morning when I lazily woke up. It took some hours to figure out what is going on and I pushed an update towards the late afternoon that handles the DST change correctly - unfortunately, to my defense, it is very hard to test DST changes - they happen once a year in each direction, and they seem to always happen on Sundays (LOL).
To all, thank you for understanding and bearing with me while I resolved this. Sorry for the trouble today 