How to Check Internet Connectivity

#1

Hi All,

Is there a way to check internet connectivity to the hub? It seems the IDE has to ping the hub to know if it’s online or offline. If the internet goes down to the hub, the IDE should know and be able to send out a message.

Is there any way to approach this in WebCore?

I just switched from Vera three days ago. All of my sunset pistons fired today, but no lights were activated. They worked perfectly the previous two nights. I know there were a lot of connectivity issues in North America today so I’m guessing the pistons fired but commands didn’t get through.

#2

This question comes up every so often…

  • If you mean your little white box going offline:
    The easiest way is to use alternative software to query your router. When the ST hub is no longer visible to your router, then alert you. Unfortunately, you cannot use webCoRE to do this because if the hub is offline, then so is webCoRE.

  • If you mean the SmartThings IDE going offline:
    The easiest way is to use alternative software to ping the IDE server every so often. When the website is no longer visible, then alert you. Unfortunately, you cannot use webCoRE to do this either because if the server is down, then so is webCoRE. (and we can’t forget to mention that if we ping their IDE too often, we may actually contribute to more frequent ‘outages’)

Long story short:
A 3rd party app needs to make repeated queries, and alert you when something is not visible.

One interesting observation though:
If your local hub is down, and the SmartThings IDE is up, then scheduled pistons will continue to run.
(even though most things will not be seen until after your hub is back online)

To clarify a bit:
Motion sensors, door contacts, and lightbulbs will NOT report or change, but data can still be gathered from sources outside the house. (IE: Timed pistons will still gather weather data, and SMS can still be sent)

If you only are interested in your white box going offline (and not the IDE) then you could probably use a version of this method to be alerted. (or follow Ike’s suggestion below)

All that being said, I think my combined total downtime the past year was only a couple of hours. (spread out over 4 or 5 short events) While this is not perfect, that is an “acceptable” level in my opinion. Especially for a budding technology such as this… and one that is likely handling millions of requests per minute…

To be honest, I am actually impressed by the reliability.

#3

I get a push notification “You Hub is Offline now”" or “Your hub is online now”
I don’t remember doing anything about it, I believe it’s by default. (But of course check your phones notifications settings with ST APP)

#4

Yeah, I think that’s from Samsung’s end. That said, it takes awhile to get that notification after the initial outage, so they apparently don’t ping very often.

#5

in my experience it’s about (just a guess never tested) within 5-6 minutes or longer.

#6

Thank you all for the excellent information.

My initial thought was that IDE was up and my hub was down. When I checked IDE, I could see it pinging my hub every minute. I don’t really know how to read that page so I can’t tell what actually happened to those pings.

I’m just going to post one of the pistons that didn’t fire in case it’s user error. *** Please note that I changed the task scheduled policy to N, but this is after the pistons fired and the lights didn’t go on. *** I could be missing something coming over from Vera and PLEG to WebCore.

Sunset%20On%20Piston
Sunset On Piston.png1178×463 69.9 KB

#7

The only thing that concerns me is:

  • How would the piston know the random time without running first?
  • How can the piston run without knowing the random time?

I would make a slight variation such as this:

temp
temp.jpg469×597 45.9 KB

This one grabs a new random number every day at 11am, and then immediately schedules a wake up time for sunset + random that evening.

#8

Ha! Thank you for clarifying that!

I found another thread where you said that had to be done and I could not find my way back to it for more information. Because WebCore had scheduled a next time to run countdown on the dashboard I thought it had set the next time to run before exiting the piston. Although $nextscheduledtime is currently listed as “invalid”…

#9

Just keep in mind that the piston will never update variables or randoms etc until the piston actually runs.

For example:
On your first day, it might have been sunset + 20 minutes.
On day two, it runs at sunset +20, but the new random number is 10.
(which was ten minutes in the past)
So the lights would not turn on that day, and the piston would reschedule for tomorrow at sunset +10 to try again.

Grabbing a new random number prior to the event is the key.

#10

Got it.

Once the routine schedules a wake up time, does it then become a local processing event or is it still cloud based?

#11

In general terms, everything is cloud based. (although there are a few exceptions)

#12

Thanks for your help with this!

#13

No problem at all! Glad to be able to help.

#14

Oh, one last tidbit:

If your current time is AFTER 11am, this piston may not begin working until tomorrow.
(after it grabs the first random number)

You could resolve this by changing the line:
every day at 11 AM
to
every day at 10 minutes before sunset

#15

Ok - so this had a strange result. When I ran it I had the task execution policy set to Never. It triggered the lights at sunset and then ran again at sunset + random.

image
image.png1178×602 57.2 KB

_12/15/2018, 4:15:59 PM +52ms_
+1ms ╔Received event [Home].time = 1544908560000 with a delay of -950ms
+93ms ║RunTime Analysis CS > 25ms > PS > 51ms > PE > 18ms > CE
+96ms ║Runtime (37039 bytes) successfully initialized in 51ms (v0.3.109.20181207) (93ms)
+98ms ║╔Execution stage started
+153ms ║║Comparison (time) 58559187 happens_daily_at (time) 1544908560000 = true (0ms)
+155ms ║║Time restriction check passed
+157ms ║║Cancelling condition #5’s schedules…
+158ms ║║Condition #5 evaluated true (23ms)
+171ms ║║Cancelling statement #5’s schedules…
+179ms ║║Requesting time schedule wake up at Sat, Dec 15 2018 @ 4:45:00 PM EST
+182ms ║║Cancelling condition #4’s schedules…
+184ms ║║Condition group #4 evaluated true (state changed) (49ms)
+187ms ║║Cancelling statement #6’s schedules…
+209ms ║║Executed physical command [Driveway Porch Light].on() (16ms)
+210ms ║║Executed [Driveway Porch Light].on (19ms)
+221ms ║║Executed physical command [Front Flood].on() (8ms)
+222ms ║║Executed [Front Flood].on (10ms)
+233ms ║║Executed physical command [Garage Flood].on() (8ms)
+235ms ║║Executed [Garage Flood].on (10ms)
+258ms ║╚Execution stage complete. (160ms)
+260ms ║Setting up scheduled job for Sat, Dec 15 2018 @ 4:45:00 PM EST (in 1740.689s), with 1 more job pending
+269ms ╚Event processed successfully (270ms)
12/15/2018, 3:39:59 PM +71ms
+1ms ╔Received event [Home].time = 1544906400000 with a delay of -930ms
+133ms ║RunTime Analysis CS > 26ms > PS > 67ms > PE > 40ms > CE
+136ms ║Runtime (37039 bytes) successfully initialized in 67ms (v0.3.109.20181207) (133ms)
+137ms ║╔Execution stage started
+159ms ║║Cancelling statement #2’s schedules…
+170ms ║║Executed virtual command setVariable (5ms)
+186ms ║╚Execution stage complete. (49ms)
+190ms ║Setting up scheduled job for Sat, Dec 15 2018 @ 4:16:00 PM EST (in 2160.74s), with 1 more job pending
+199ms ╚Event processed successfully (199ms)

#16

My sample code was meant to have the Task Cancellation set to default.

Your log shows the random set at 3:40pm (as expected), and the lights on at 4:16pm.

What time did the sunset in your location? I’d need to see that portion of the log as well.

Also, please turn on TRACE so I can see the numbers after each line of code. It helps when troubleshooting the log files.

temp

#17

I’ll turn trace on for the next go round.

Sunset was at 4:16p today.

#18

Hopefully resetting Task Cancellation to default will resolve it.

I am curious though, what happened at the 4:45pm wake up?

#19

12/15/2018, 4:44:59 PM +105ms
+1ms ╔Received event [Home].time = 1544910300000 with a delay of -896ms
+122ms ║RunTime Analysis CS > 30ms > PS > 55ms > PE > 37ms > CE
+125ms ║Runtime (37044 bytes) successfully initialized in 55ms (v0.3.109.20181207) (123ms)
+127ms ║╔Execution stage started
+201ms ║║Comparison (time) 60299274 happens_daily_at (time) 1544908560000 = true (1ms)
+204ms ║║Time restriction check passed
+207ms ║║Cancelling condition #5’s schedules…
+209ms ║║Condition #5 evaluated true (40ms)
+216ms ║║Cancelling statement #5’s schedules…
+227ms ║║Requesting time schedule wake up at Sun, Dec 16 2018 @ 4:45:00 PM EST
+232ms ║║Cancelling condition #4’s schedules…
+234ms ║║Condition group #4 evaluated true (state changed) (66ms)
+238ms ║║Cancelling statement #6’s schedules…
+248ms ║║Skipped execution of physical command [Driveway Porch Light].on([]) because it would make no change to the device. (3ms)
+250ms ║║Executed [Driveway Porch Light].on (6ms)
+256ms ║║Skipped execution of physical command [Front Flood].on([]) because it would make no change to the device. (3ms)
+257ms ║║Executed [Front Flood].on (5ms)
+262ms ║║Skipped execution of physical command [Garage Flood].on([]) because it would make no change to the device. (3ms)
+264ms ║║Executed [Garage Flood].on (6ms)
+296ms ║╚Execution stage complete. (169ms)
+299ms ║Setting up scheduled job for Sun, Dec 16 2018 @ 3:40:00 PM EST (in 82500.597s), with 1 more job pending
+310ms ╚Event processed successfully (311ms)

#20

I think the Task Cancelling set to never caused this. (yesterdays schedule still lingering)

Let me know if setting it to default still has issues tomorrow, and we can get to the bottom of it.