@CAL.hub
See the tasker info below. It's much simpler if you don't have user accounts setup on your HE hub
NO user admin:
If you have user admin setup, see the post below:
Add user authentication to the Update Tool
And my modification to the task @gparra shared here:
Add user authentication to the Update Tool
Ya, that's exactly what I'm suggesting. I totally get the URL not being an endpoint, rather a page.
Thanks @chuck.schwer
Perhaps a watchdog from the 8081 server might not hurt. Though having a bunch of welcome home messages in the middle of the night could be an unpleasant surprise!
Addendum to above .. perhaps have a reboot option displayed on the 8081 server only if the 8081 server detects that the main server is not responding, same check to be performed if actually pressed.
That would prevent malicious reboots, but still make it available in times of crisis?
Add in plenty of checks and limitations or people will use it to auto-reboot on hang (even though that's not a terrible idea)
I have a dual hub setup, one is designated as "devices" and another as "software". Each hub connected to power through a smart switch, that is registered on ANOTHER hub, so each hub can reboot another by turning off / on another hub's power switch.
For now I only reboot "software" hub on a schedule, works like a charm.
It is not recommended to restart the hubs by cutting power. You could corrupt your hubs database. This method is good however if your hub is completely locked up.
You can follow @stephack’s example in the thread below and create a rule in RM that will restart your hub. Here are a few screenshots Stephen posted as examples:
Hi! Does this still work for you? I can't get it to work on my platform... Thank you.
This URL will work for reboot as long as you don't have a username/password setup:
http://he.ip.addr:8080/hub/reboot
If you have a username/password setup for your hub, you can always reboot remotely from another computer using a script like this one:
#!/bin/bash
#
he_login=your_he_login
he_passwd=your_he_passwd
he_ipaddr=he_ip_address
cookiefile=`/bin/mktemp`
#
curl -k -c $cookiefile -d username=$he_login -d password=$he_passwd https://$he_ipaddr/login
curl -k -sb $cookiefile -X POST https://$he_ipaddr/hub/reboot
You cannot do this with a GET message (from a browser). It must be a POST message.
POST to http://<hubitat>:8080/hub/reboot no longer seems to work for me in 2.1.7.121. Has anyone else had an issue with this in the latest platform update?
You need your hub's IP in there.
No issue here. Are you using RM? or something like http-momentary-switch?
I'm using Rule Machine, as follows (in relevant part):
(On my router, the "hubitat" IP address is mapped to the appropriate 192.168.X.Y address, which is statically assigned by MAC address of the HE.)
Haven't had any issues with this line in the past, but since updating to 2.1.7.121, when the rule runs, nothing happens.
Yes, I hadn't realized that you need to escape the open/close angled brackets when I made the original post, so <hubitat> had vanished from my original post. I've edited above to fix this.
Okay....you are using Hubitat's IP, correct? And you are sure that it is right?
That's not the Hub IP though is it? Can you please try using the Hub's IP instead? If you have the domain "hubitat" only assigned for port 80, the command you are using to port 8080 won't work correctly.
No, you're right—I shouldn't have said, "IP address," as it's a mapped local domain name.
No, this isn't a port mapping—it's a mapping of a local domain name to a local IP address. So I can, for example, go to http://hubitat:8081 in any local web browser to access my hub's diagnostic tools.
My local domain name has always worked in the past, but for the sake of being open-minded, I went ahead and followed your suggestion: I replaced the domain name with my Hubitat's 192.168.X.Y address, and the reboot worked. Glad it's working again!
Taking a step back, I would normally think the above suggests a router issue as the most likely cause, but the only thing that changed between being able to use my locally mapped domain name consistently over many months and having to resort to the hub's actual IP address is the update to 2.1.7. In any case, I think the underlying issue is probably not going to get solved on this forum, but at least my reboot rule is working again.
On a tangential but related subject: Does anyone know of any other special URLs that cause Hubitat to do useful things?
I’d love to have rules that install platform updates and repair the Z-Wave network.
Z-wave repair can be done from a url...
http://IPofHUB/hub/zwaveRepair
or from Hubitat itself:
http://IP:8080/hub/zwaveRepair
Also, this is a GET request, not a POST like reboot. I don't think you'll be able to install platform updates since it requires you to agree once you get to the update screen. You have to click the button.
Download the Hubitat app
