Push notification to cell phone when temperature sensor reaches 80 degrees


I tried to get this working without the while loop and it didn’t work either.

I used the while loop from someone else’s example, however it doesn’t work either.

I am not receiving alerts. Ironically it did start to alert me first think this morning and I had t turn it off. I have since re-created it and it’s not working again.

As you can see from my example I’m setting the temperature’s higher then it currently is in order to test, once it works I’ll reverse the logic to alert when the temp is at or above 80 degrees.

2/3/2020, 2:21:29 PM +121ms

+0ms ╔Received event [Home].time = 1580757690456 with a delay of -1335ms
+116ms ║RunTime Analysis CS > 41ms > PS > 58ms > PE > 17ms > CE
+119ms ║Runtime (38166 bytes) successfully initialized in 58ms (v0.3.110.20191009) (117ms)
+119ms ║╔Execution stage started
+120ms ║╚Execution stage complete. (1ms)
+121ms ╚Event processed successfully (121ms)
2/3/2020, 2:17:20 PM +612ms
+1ms ╔Starting piston… (v0.3.110.20191009)
+228ms ║╔Subscribing to devices…
+237ms ║║Subscribing to Computers.temperature…
+271ms ║║Subscribing to DAVID BEISER’s Dave’s S9…
+272ms ║╚Finished subscribing (52ms)
+298ms ║Comparison (decimal) 72.0 stays_less_than (integer) 80 = true (2ms)
+311ms ║Comparison (decimal) 72.0 is_less_than (integer) 80 = true (2ms)
+319ms ╚Piston successfully started (319ms)



Cross posting where it appears you also brought it up.

And the (possible) solution

Baby's Room Temperature Alert

Can you place this piston in trace, post green snapshot and full logs please?


I had to press Test in order to get it to run, now it seems to be running on it’s own. And I’m getting two alerts, one from ST Classic and one from the new app, where as until now my other pistons only alerted via the Classic app?

2/3/2020, 3:08:29 PM +747ms
+0ms ╔Received event [Home].time = 1580760482586 with a delay of 27160ms
+390ms ║RunTime Analysis CS > 229ms > PS > 152ms > PE > 10ms > CE
+393ms ║Runtime (37841 bytes) successfully initialized in 152ms (v0.3.110.20191009) (391ms)
+394ms ║╔Execution stage started
+399ms ║║Cancelling condition #2’s schedules…
+399ms ║║Condition #2 evaluated true (1ms)
+400ms ║║Cancelling condition #1’s schedules…
+401ms ║║Condition group #1 evaluated true (state changed) (3ms)
+404ms ║║Cancelling statement #12’s schedules…
+462ms ║║Executed virtual command sendPushNotification (55ms)
+467ms ║║Executed virtual command wait (0ms)
+468ms ║║Requesting a wake up for Mon, Feb 3 2020 @ 3:09:30 PM EST (in 60.0s)
+474ms ║╚Execution stage complete. (80ms)
+476ms ║Setting up scheduled job for Mon, Feb 3 2020 @ 3:09:30 PM EST (in 59.994s)
+484ms ╚Event processed successfully (484ms)
2/3/2020, 3:07:37 PM +828ms
+1ms ╔Received event [Home].time = 1580760414250 with a delay of 43578ms
+307ms ║RunTime Analysis CS > 135ms > PS > 164ms > PE > 8ms > CE
+310ms ║Runtime (37840 bytes) successfully initialized in 164ms (v0.3.110.20191009) (309ms)
+311ms ║╔Execution stage started
+312ms ║╚Execution stage complete. (1ms)
+313ms ║Setting up scheduled job for Mon, Feb 3 2020 @ 3:08:02 PM EST (in 24.445s)
+324ms ╚Event processed successfully (324ms)
2/3/2020, 3:07:37 PM +503ms
+0ms ╔Received event [Home].execute = recovery with a delay of 40ms
+65ms ║RunTime Analysis CS > 20ms > PS > 35ms > PE > 10ms > CE
+68ms ║Runtime (37827 bytes) successfully initialized in 35ms (v0.3.110.20191009) (67ms)
+69ms ║╔Execution stage started
+81ms ║║Comparison (decimal) 72.0 stays_less_than (integer) 80 = true (1ms)
+83ms ║║Adding a timed trigger schedule for condition 2
+85ms ║║Cancelling condition #2’s schedules…
+86ms ║║Condition #2 evaluated false (13ms)
+87ms ║║Cancelling condition #1’s schedules…
+88ms ║║Condition group #1 evaluated false (state changed) (15ms)
+90ms ║╚Execution stage complete. (21ms)
+92ms ║Setting up scheduled job for Mon, Feb 3 2020 @ 3:08:02 PM EST (in 24.992s)
+102ms ╚Event processed successfully (102ms)
2/3/2020, 3:07:37 PM +197ms
+0ms ╔Received event [Home].test = 1580760457195 with a delay of 0ms
+82ms ║RunTime Analysis CS > 23ms > PS > 49ms > PE > 12ms > CE
+86ms ║Runtime (37833 bytes) successfully initialized in 49ms (v0.3.110.20191009) (85ms)
+87ms ║╔Execution stage started
+111ms ║║Comparison (decimal) 72.0 stays_less_than (integer) 80 = true (2ms)
+128ms ║║Condition #2 evaluated false (33ms)
+130ms ║║Condition group #1 evaluated false (state did not change) (36ms)
+167ms ║║Cancelling condition #2’s schedules…
+168ms ║║Condition #2 evaluated true (2ms)
+169ms ║║Cancelling condition #1’s schedules…
+170ms ║║Condition group #1 evaluated true (state changed) (5ms)
+175ms ║║Cancelling statement #12’s schedules…
+191ms ║║Executed virtual command sendPushNotification (12ms)
+195ms ║║Executed virtual command wait (1ms)
+198ms ║║Requesting a wake up for Mon, Feb 3 2020 @ 3:08:37 PM EST (in 60.0s)
+211ms ║╚Execution stage complete. (123ms)
+221ms ║Setting up scheduled job for Mon, Feb 3 2020 @ 3:08:37 PM EST (in 59.979s)
+230ms ╚Event processed successfully (231ms)


You need to turn notifications off for one or the other app to avoid getting both messages. Once you run them both, they both want to notify you.


I was just going to post and ask to make sure the sensor was below your set temperature since it would still be looking for that change that we specified. There had not been a change in temperature from the sensor for it to have started the piston which you did by hitting test.

That is because I selected to store in messages. I believe on the line dealing with the notification notification, if you set store to messages as false under the options that should only notify you in classic now. This is going to be a thing to deal with with the transition between the two apps. I have turned off notifications in the settings of my new ST app to cut down on double notifications as well.



I’ll eventually remove the Classic.


That also explains why my wife didn’t get notified, she only has the new app…

OK, so back to the actual alerting on Temp. Should it not start alerting immediately once I save the Piston and the temp is lower or higher then (however I have it set)?


The piston subscribes to the device and then runs your piston against the data coming out of that sensor. So if the sensor has not reported a change then there would not be anything for it to reference. So for example if your sensor is currently 78 degrees and your threshold is 80, it wont be until the sensor reports the next temperature (whichever way thats going) that WebCore can then look at that new value and the piston runs or not.

So if the sensor currently already is 80 degrees, nothing will happen until it reports the next temp change.


Makes perfect sense!

Which is why the test forced it to run…

OK so now that it’s working.

Why again am I able to address my phone directly for a push notification in my door script and not here?


In the rt3h piston you posted notifications are sent as a “PUSH” which does not allow granular control over who receives it. Everyone who is part of your ST app would get that notification. If you clicked on that line and instead changed it to a “SMS” notification it would allow you to then send it to just your phone number.


OK, so since I was not storing the messages only the old app was receiving the notices, I’m the only one with it, so it appeared it was sending to my phone, when in fact it was just pushing it to the Classic app and ignoring the phone entry. Which is why you mentioned it should be set to Location instead?

Here’s the Piston for reference.


That sounds correct. Even though you can still place the command to send a notification under a device I like to keep things orderly by actions capable of that device. I wouldn’t expect a light bulb to set a different temperature on my thermostat for example. In the end (for me) its just better practice to prevent making any mistakes or future headaches.

So you can keep it the way you have it and it would still work as you just surmised, but personally I would update that line 27 in 04pe since that’s all its doing anyway. If you wish to do so, just click on that device and then un-select it from the list of devices, hit save without selecting anything else. It should automatically revert back to “Location” at that point.

Edit: the function of storing the messages works different by app. In the new app you get the notification and its in the list of events. On the old app you will get the notification but if you do not select the store function it will not be in the list of events in that app. For what its worth. Since I still rely mostly on the old app I select the store for instances where I want to go back and review that notification.


I’ve already updated line 27, thanks!

My understanding is that Webcore doesn’t need the Classic app to operate and if that was the only SmartApp left I could completely remove the Classic. However, I have the Amazon Alexa and IFTTT SmartApps that only show up in the Classic if I’m not mistaken? I don’t even think I’m using IFTTT anymore but I am using Alexa.


WebCore as it exists right now needs the classic app to run as you know it. There are things that WebCore can only do through the classic app such as the alarm function and routines if you still have them, etc. So its not a bad idea to hold on to the classic app in the background even if its sole purpose is for your WebCore to run properly as you have written it.

The classic app will eventually be phased out and we all will have to figure out to move forward from there. More then likely there will not be a migration tool but the future might look very familarly WebCorey to begin with so not all is lost. Some good insight on the topic in this thread here --> How long will WebCoRE be available


OK, thanks!


I’m not sure this is exactly right. The piston is actually looking for the value to stay below the threshold for a certain period of time. If that period of time has already gone by when the piston is started, the trigger will never fire unless the temperature goes above the threshold and then comes down again.


Here’s what I have now. at or above 80 for 25 seconds.
Alert every 5 min until it drops below 80. Usually by opening the closet door because someone closed it too far.


You are correct, I was hastily in my explanation and at the time figured this was the more likely scenario he was in to use as an example. The point I was trying to convey was that without the sensor reporting a change, either positing or negative, he wouldn’t see actions on the piston.

Looks good, have you tested it by closing the door and waiting past 10x minutes to see that you keep getting notifications?


Yes, it worked.

That was the 2nd to last ST automation I had to replace, the last I did last night and that was simply to turn my crawlspace fan on between 12 noon and 4pm. All my automation’s have now been migrated.