OK, there's something I might not be understanding in the process here.
This is triggered by a time cycling of 15 min
You do the PING to test the connectivity
You get a response and test it with conditions that dictate what you do next...
And you proceed incrementing a counter to decide about consequential actions.
BUT.... have I missed something big on how RM works! Do LOCAL variables actually persist beyond one triggering of the same rule to the next in an evergreen manner? Your code ends and re-triggers by the clock, there's no Delay or Wait "for 15" keeping the rule "active". So this must be the case. Duh. So a reboot in the interim does what to these variables?
yea, basically the rule was planned to not reboot every time the networked dropped. I fully understand that a network can at times have heavy traffic, say lunch hour, or when everyone is on netflix, etc
I didn't want to reboot just for a short abnormal network. Anyway, that was the plan
So, the rule will ping every 5 mins, if no response, then it will add 1 to the accum variable, then try again in 5 mins, then still if no response, Add another 1 to the accum variable, then wait another 5 mins, and if no response add a 1 to the accum variable, then if no response in 3 attempts within the 15mins, run reboot
If during the 15 mins the C8 gets a response, then the accum variable is reset back to zero, then the logic starts over, repeat, etc
Does this answer you question?
BTW, I just received a call from our condo HOA IT department, I explained this to the IT guys, and he just made a change on the corp router which he claims could be causing a problem on the network. So we are waiting to see how long the C8 stays online (meaning, remote access to the C8)
Yes local variables do persist, the reason I test 3 times is to not reboot for times where a pings are not going through for any reason that might not be a big problem like heavy traffic, interference, etc.
The rule ends and next time it will be run, it will add to the count or reset the counter, after 3 misses, it will reboot the hub.
Yup, this local variable state persistence (between triggerings of the particular rule) is something I never realized. Seems obviously beneficial now. So what does happen to these when the hub gets rebooted, I mean in general...not where you are controlling that through this Rule?
