I tried to load the Hubitat Hub Controller from GitHub - dcmeglio/hubitat-hubcontroller with a "New driver" command from Drivers code. It is not found so I did a copy/paste from hubitat-hubcontroller/drivers/Hub_Controller.groovy. The code was not rejected and it shows on The Drivers Code section.
I then attempted to create a virtual driver but the "actuator" type does not show up.
I want to use the code to shut the hub down on a power failure.
The hub -s a C-8 with version 2.3.7.140.
That developer left HE a while back so his projects are not all still being maintained.
This driver has a shutdown option and is functional:
It's not "actuator" that you look for when creating a virtual device. In the Type list, scroll to the very bottom and then scroll up to find "Hubitat Hub Controller"
I agree that the Hub Information Driver v3 is a better choice, since it's actively maintained. However, for SMALL, it's hard to beat Hubitat Hub Controller 
Good call, I was not understanding what the problem was exactly. I think you are right though, they are having a hard time finding it in the Driver/Type list.
Thank you - I loaded the new driver and created a virtual device called 'HubShutdown'. The device contains, among others, the command 'shutdown'. I have a test app that will execute the shutdown command. I create the action type 'Set Variable, Mode or File, Run Custom Action' then select 'Run Custom Action'. I then select the capability as 'Actuator'. I then must 'Select Actuators to act on'. I want the command to act on the Hub to shut it down, but the selection list is just my lighting devices.
How do I get the command to act on the Hub?
Thanks.
What app? Or do you mean a RM rule? I'm not 100% sure what you are referring to here.
Assuming it is an RM rule, the "actuator" to select is the virtual device you made.
Here is an example of a rule that reboots on low memory. My virtual hub info device is "HubInfo".
Sorry, I have a habit of calling RM rules apps. To long programming I suppose.
Your note is exactly what I needed. I am using the Hub information Driver v3. My hub has security set so I hacked the code to explicitly set the username and password. I suspect there are better ways to accomplish this but they aren't obvious in the driver.
Driver has the ability to store and use the user name ad password down in preferences, no need to hack it.
Thanks - I did finally find the fields for username and password. I had looked for them earlier when I found the switches for 'Hub Security Enabled' and 'Allow Hub to be shutdown or rebooted' but missed the others. The code now works correctly for my application.
I have the HUB on a UPS and a Ring Alarm Range Extender. The Ring goes into battery mode when the power goes off and starts a timer in a RM rule. The UPS runs for ca. 50 minutes with its current load and the HUB is shutdown after ca. 30 minutes to be safe.
Again, thanks for all of the coaching.
-Milt
I tried the POST directly to the web address but my hub has security set and it requires a name/password.
I was able to use the web site, as a test, by using the program curl and passing the username and password.
I like the simple way this driver allows me to shutdown the hub, reboot the hub or restart the software. And understand that the developer is no longer active with Hubitat.
Is there a simple way to install a software update using a driver? I want to expand my rule to install an update whenever I set a flag. Then install the update instead of doing the restart.
Note that the "Hubitat Hub Controller" appears to have been broken by Hubitat platform version 2.4.0.146.
The following Rule worked fine for many months before 2.4.0.146, but updating to 2.4.0.146 caused the Rule to restart the hub approx. every 7-9 minutes. Pausing the rule makes the problem go away. Rolling back to 2.4.0.145 and un-pausing the rule makes the problem go away. Upgrading again to 2.4.0.146 and un-pausing the rule, the problem returns.
All the virtual driver does is allow you to reboot the hub. Your rule is telling it to do the reboot.
It sounds like your rule is what is not working right.
In order for your rule to trigger, there would need to be a ZigbeeOff location event. What do the Logs > Location tab show?
The rule has worked perfectly for many months (until the 2.4.0.146 update). It was designed to catch long-term (>5 min) crashes and reboot or restart (user's choice by setting vRebootMode to True or False, respectively).
For shorter crashes (such as the infamous approx. 7 second Zigbee radio crash), the rule does not invoke a reboot/restart but simply lets the hub restart the Zigbee radio on its own.
A ZigbeeOff location event does indeed trigger the rule. The rule got me through a period were my old C-7 hub would crash -- and NOT self-reboot -- several times a day. It also worked in the early days of my C-8 Pro hub (same crash problem). The crashing stopped when I completely re-created the entire Zigbee network from scratch and got rid of all Aqara devices (push buttons and contact sensors).
Ok... so do you currently see any ZigbeeOff location events in the Logs > Location tab?
That should be the only way the rule would trigger, and thus the only way the rule would reboot the hub.
I am not saying there is not an issue, but I fail to see how that virtual device driver is causing the issue when you already have determined it is something with the rule causing the reboots. Either the update is causing a false ZigbeeOff event, or the update broke your rule in some other way.
If you change over to Hub Info v3, it is going to give you access to the exact same reboot command which will not solve whatever problem you are having with the rule. Its going to do the exact same thing.
I changed the Rule over to Hub Info v3 and the crashes don't occur. That was all I changed. So I do suspect that "the update broke [my] rule in some other way." But since Hubitat Hub Controller is no longer supported, and HIv3 works, I'm moving on to do other stuff.
Download the Hubitat app
