Oh yes, that's why I said interesting information, I had some weird issues and I never tested port 8081
It is also very fortunate that the system OS restore also does a reboot... 
Just as a data point....I've had this happen to me twice before and doing a POST to the reboot link worked for me. I have this setup as a Tasker task on my android phone for just this purpose.
Now you should post how to do that! I'm not a Tasker user 
PowerShell is the easiest from a command line on a Windows system, but I am nothing but seriously dangerously flawed with PS!! I am very, very happy with myself for taking the time & effort to set up a VPN into my system. Without this, nothing would have been possible. (barring a WiFi switch of course!)
Thanks! I will start to play with it and my new "development" hub 
it's a backup hub, just sounds better as development...
Guys, as a heads-up, there is no need to hide 192.168 IP addresses. They are PRIVATE & completely non-accessible. If I manage to access your network on one of your 192.168.x.x IP addresses, you have bigger issues.
5 Likes
reminder... when port 80 is locked, as was true for GatVlieg's hub, the POST will timeout.
1 Like
Oh...I know...but I'm a firm believer in "what you dont need to know...you dont need to know"
2 Likes
Strangely enough...and I know it shouldn't have worked...I had the exact same thought...till I hit the reboot icon and 30 seconds later...I saw the 10% loaded boot screen. And it worked twice 
That's excellent news. Implies that /hub/reboot is running outside of the main Hub program.
I can confirm @stephack comment... I also had, from all appearances, a locked hub several moons ago... I guess it was super, super slow & not completely locked.
Issued a command line reboot, which from appearances failed, and it only responded/rebooted the next day; well I am assuming that is what caused the reboot, based on the log files.
That or the web service has not completely crashed and is just overburdened in some way.
Not being a developer, my gut instinct says it is the web service being overburdened ... A true lock will cause the hub to fail on all ports IMO.
1 Like
Already done apparently. Need some work on firmware to connect to Port 80.
1 Like
It is not
1 Like
Go it working, thanks. How you did the vpn one? It's a command for an app or?
Just wanted to add my experiences to those above: I've also managed to "lock"/freeze my hub, mostly while developing a custom app and accidentally encountering a "bug" of sorts. Despite the port 80 interface not responding (and the port 8081 interface being fine), I was still able to eventually reboot the hub via POST. The PowerShell command someone posted above looks like it should work; Mac/Linux users (or Windows users/anyone with cURL) may want to try this, as I did:
curl -X POST 1.2.3.4/hub/reboot
where 1.2.3.4 is, of course, your hub's IP address.
It sat there for a long time before it responded, and sometimes I had to try twice, but it did eventually work in all cases (minutes, not hours, by the way).
(The lockup could have been caused by webCoRE, but I think it was me writing a link to a page name that didn't exist in my custom app. While that's entirely my fault, it would be nice if that didn't send the app into an apparently endless process-eating loop and just threw an error. webCoRE has been moved off to the second hub I bought for development and testing, and I hope to get rid of it entirely soon, so that should no longer be a problem. I can write a minimal test-case of a "bad app" that causes the behavior I think I self-inflicted if that would help.)
