Yes, that's the point 
1 Like
I'll try pulling the C-8 ethernet cable as a simulation, without restarting.
Upon reflection, the C-7 couldn't shutdown the C-8 gracefully, because it can't ping it!
The best it could do would be to cycle power!
That's the inherrent risk with something like this.... The detection mechanism, network connectivity, can be restricted by more than just one root cause, there can be any number of reasons one device cannot talk to another. The problem can be with the "monitor" or with the device being monitored.... If the monitor cannot see the device it is monitoring but can communicate with the plug, then you may power cycle an operational hub.... Causing potential database corruption. Unless you implement some fail-safes to detect the shutdown... But even those could be prone to similar flaws in detecting the hub is in fact shut down.
I didn't want to play down your endeavours in this space, and even my opinions here are not definitive or based on some long-standing experience, but it would make sense to me that there can be plenty of opportunity for false readings. For me, personally, monitoring is good, and I would encourage it. But responding, in situations like these, is best done with some level of human involvement, to introduce a broader assessment of the situation before taking action. Make that assessment and action as easy as can be, but still a decision by someone who knows the environment well... well, as well as can be expected....
I guess I don't know what Private Boolean means.
I though it would evaluate True if it could ping the C-8, and False if it failed.
Instead, it remains False.
Perhaps I should test on value?
It was 0, when the Ethernet cable was connected, and now it is 100.
Maybe I should test at something in between, for a degraded, but not gone, connection.
I wonder what that number should be?
edit: If I can test on %value%...
There is an action to set the private boolean. You need to include that action based on whatever logic you want to include. @thebearmay can perhaps comments on how (or if) the ping option can be used in this way.... But in terms of setting a Private Boolean in general:
1 Like
I created a string variable that I set to %value%.
This variable is 100, which is 100% loss with cable disconnected, and 0, 0% loss when connected.
Now I have to figure out what would be a good loss number to test for.
It's local, so numbers should be strong.
Is it a matter that when the hub 'gives up', due to whatever, it just goes to 0?
So maybe testing if it is 0 would do it.
Or, is there some middle number that would indicate deteriorating conditions?
I'm thinking it's all or nothing.
@thebearmay ?
Give it some time.... IMHO.... If you restart your network router, not all devices may come up at the same time..... or if you restart the hub, how long do you wait before checking whether to restart it again....
1 Like
I'm re-pinging every 10 minutes.
Would that be good?
Like most things, I tend to adopt the POV that.... it's complicated.... Not to say you have to adopt the same viewpoint...
If, for example, you take the hardline approach, that even a single miss of a ping response, what happens if you restart the hub manually after a platform release... And the ping check kicks in...
I give you an easy answer, at least one that I can easily construct at the moment... I would encourage you to think about it some more and once you feel you have something that handles some common scenarios you have faced in the past, then look at how to handle those. Don't rush into it....
1 Like
I felt that way with my gate automation, until it got crumpled by a truck while closing!
1 Like
But seriously, it's very hard to dream up all the different scenarios. This rule would be by definition drastic, since there would be no question of gracefully shutting down the production hub-it would be a brute force power cycle.
Perhaps, rather than doing a last ditch power cycle autonomously, it would be better to have the C-7 do a Pushover notification and let the operator, (me), remotely power cycle the C-8 production hub.
On a side note, what does the alternating red/green light on the hub actually mean?
It seemed that it continued to flash even while reconnected, but went solid green when I brought up a page for that hub.
Exactly.... 
On another side note, it's cool that I can't tell that the hub is disconnected from the web. Everything works as it should (except maybe Envisalink, my only cloud based integration.
Similar to my earlier comments, connectivity of any kind can be affected or report as down for various reasons that don't always mean what you expect them to be. Being unable to connect to one cloud service does not mean you don't have any cloud connectivity.
1 Like
I can tend to come across as a little negative or downplay others ideas in this situation. I'd re-interate my comment earlier that I don't want to completely dismiss the idea of monitoring and responding to that. It is not wrong or somehow a waste of time to keep tabs on the status of various aspects of the HE hub's access or responsiveness to requests. It is just that I suggest understanding or expecting limitations in what some kinds of monitoring can deliver, accepting this and accounting for it in how these approaches are implemented.
That sounds really wordy.... No solution is perfect, try something, post about it, seek comments here on the Community and evolve the solution. It's nothing new in this space....
1 Like
I've just seen a fair number of "I'm out of town and my hub is non-responsive" kind of comments. An autonomous graceful shutdown (where the hub can still communicate) and power cycle seems to be hard to come by. Many people might have a spare hub laying around. So....
This ping thing would be a last ditch thing.
1 Like
Just go in with your eyes wide open, so-to-speek... which I think you are now... Keep an eye on whatever you decide to setup and review any "incidents" to see how the logic holds up for your setup.
2 Likes
I have chosen a solution very much in line with what @sburke781 has suggested. I have Node-RED running on a separate platform. It monitors all of my Hubitat hubs and then simply sends me a Pushover notification to let me know there may be a problem with a hub not responding. (Note: I use Pushover directly within Node-RED, so as not to need to rely on Hubitat for anything.)
When I get a notification (usually only when I am doing some HE hub maintenance), I can then connect into my UniFi home network (via Wireguard VPN if offsite), and then troubleshoot the issue. If necessary, I can power cycle my Hubitat hubs via the UniFi console as I use PoE splitters to power each HE hub, as well as my Lutron Caseta and Phlips Hue hubs. And since my UniFi network hardware is on UPS, so are my home automation hubs.
Like @sburke781, I am not trying to dissuade you from your goal. Just trying to point out that what initially may seem like a simple task, often ends up to be much, much more complicated due to all of the edge cases that are hard to foresee. This is exactly why my garage door openers have no automation whatsoever as well. Too much risk with them either opening or closing when not desired. However, I do have manual control over them via Hubitat.
2 Likes
I agree, however, I would think that something like a Z-wave radio crash would be a little more cut and dried. I haven't been able to simulate that.
ZigbeeRadioOff, yes, that can be induced. But if it were permanent, say > 10 minutes, I think it also would be straightforward.
Not so the Ping Thing.
You have Node Red on a separate platform. I have a spare Hub.
