Yes, you have to use port 8080, the "backdoor" internet port because you are sending the request through port 80. Can't send and receive a msg at the same time on the same port. So, if you want hubitat to reboot itself, it would be a POST message to: http://HUB_IP:8080/hub/reboot and to shutdown replace /reboot with /shutdown.
1 Like
OK, now that's clear for me, thanks.
1 Like
If you auto-reboot your hub every couple days how do you keep your panel dashboards up and running after the refresh? Wouldn’t they default back to the dashboard menu at least? That would be a pain. I am experiencing slowdowns every two days. Always seem to start in the morning hours.
LJ.
I do the auto reboots twice per day. The Dashboard stays open on the web browser, and during the reboot the green check in the top right corner turns red for a few minutes until the hub boots back up then turns back green. Happens without issue.
Do you have a hub security password set or a dashboard pin?
No
Has anyone had any luck definitively determining the hub slowdown issues and eliminating them. This one will become annoying real fast and will be deterrent to continuing with Hubitat. The auto-reboot is a workaround, but I would think this would be a priority to the Hubitat team given so many people experience it. I am running a lot of apps (experimenting since I am new on this platform) and a fair number of local z-wave (~50+) and hue devices as well as some necessary web based devices. Sectionalizing this would be extremely difficult and splitting hubs and depending on Hubconnect seems a bit kludgy for the long term unless I get into building custom stub drivers for it.
Just curious about people’s success or failure in curing this and how they did it.
LJ
My bet is on lan and cloud devices, especially any device that the hub has to communicate to through a switch. I think I have been having this issue with the Hue bridge.
Not sure I understand your Response. Are you suggesting that Cloud devices are impacting the Hub Local devices? I am using BPTWorld's Hub Watchdog to alert me when the slowdowns happen. They start to ramp up after about 2 days since a reboot. I am using this tool to check response times of two different Z-wave devices. This app checks their response time to standard actions. I am not checking any of my Hue or Cloud Devices.
So are you saying that something the cloud devices are responding with is causing the hub to slow down other devices or causing the hub to loop or queue something which takes over the processing power of the hub?
This would seem to me to be something the Hubitat Team would want to prioritize high.
LJ
I recently added a zigbee light to turn on with a Hue group and noticed a 3-4 second delay between events if the bulb “on” command was issued after the Hue “on” command. After experimenting with router and switch settings there is less than a second difference between the two. I’m now planning on reconfiguring my network so HE and Hue are on the same switch.
No one knows the cause... It is likely many causes, and different for different users. But it is definitely real.
Since no one, including Hubitat, can seem to figure out what causes it for every user, many that have the problem just reboot periodically... Which likely means the cause will never be known or fixed. 
3 Likes
I’m saying that without a doubt my Hue integration was effecting the performance due to communication issues across my network. The commands are issued in order, so I had a huge delay between Hue and zigbee happening for me. It seems like the hub needs to be able to issue multiple commands simultaneously, which it doesn’t seem to be able to do. I also have seen the same lag between device commands using tp-link devices, of which I have widdled down to 3 devices.
Edit: I should also say that I currently have the Hub connected directly to a Netgear X6S router, the Hue bridge to a tp-link easy-smart switch, and said tp-link bulbs to the Netgear wifi.
i agree, and that is why I call it a workaround which is only masking the problem. I would be willing to grant access to Hubitat to control and log into my hub to trouble shoot or supply whatever info they need. Or they could build a tool to collect all the info they might need about the low level queues and processor load measures or whatever to trouble shoot this.
@support_team To the Hubitat team, I agree that in any environment where users can load third party apps, there are going to be different possibilities for log jams and slowdowns which may or may not be something that you can do something about, either by yourself or by contacting the third party to address the issue . But even if it is a third party causing the issue, you cannot ignore it because the only symptom the users experience is the slowdown and this is most often interpreted by users as being a problem with the whole HE platform. Not having a process and tool to troubleshoot and at least identify the the internal HE process that is actually slowing down, and the apps that are associated with that process which might be causing the process to slow down, this problem will ultimately become a device success killer for you. It may not be your problem, but by not doing anything it will become your problem in the long run. This is a threat to your business and should be high priority. Doing nothing will impact your business and we want to see Hubitat survive and succeed..
LJ
1 Like
I have personally experienced slowness with the Hub when using the in-built Ecobee app, so cloud connected apps in general is the first thing I usually look at when I am having issues. And in my case this was not even a third party app.
2 Likes
Ken, The network delay you are describing may be different than what I and some others here are experiencing. Yours seems like a constant condition between certain devices. I have experienced that too but find it is device specific.
What I am experiencing might best be described as the "Creeping Crud". After a reboot everything seems to respond very well. Over time, Typically a couple of days after reboot, there appears to be a noticeable slowdown in responsiveness of every device (as far as I can tell...I am still experimenting on that point). As time goes on, the delay increases, apparently at an increasing rate of deterioration. This deterioration ultimately becomes annoying and I must reboot again, only to start the cycle again.
LJ
1 Like
No, unfortunately, I have both issues. I currently have scheduled a nightly reboot at 4:10 a.m. which is the solution that fits my patience for this. I am hoping the network issues and the slowdowns after a couple of days are related. It seems logical that the one thing that the hubitat staff can't really test for is the interaction between the hub and the myriad of different home network setups, especially for those of us that are using solutions that aren't garden variety gateway devices set up by the internet provider.
I was troubleshooting the Hue connection (trying to figure out why it was taking 4 seconds to complete a command) and accidentally fixed my wifi printers AirPrint functionality at the same time. It hadn't worked, except for immediately after rebooting the router, since I purchased the router, and the settings I changed (upnp settings for ttl and advertised period, and enabling RIP) were at factory default but fixed my printer and seem to have resolved my hue issues, at least there is no longer a 3-4 second lag.
I've stayed out of this discussion, largely because I haven't been experiencing any major slow-downs or lockups for months and I didn't want to jinx myself. Well, last night the slow-down became so bad that it was taking 10-15 seconds for a rule to fire. Rebooting did not help the situation. I had to do a soft-reset and database restore. Instantly the hub has been responding almost instantly again.
The number of custom apps I have is very low. I do have a bunch of custom drivers but I have not seen any errors in the logs so I have no idea what could be causing the resources to be gobbled up.
The one thing that has to be done if there is going to be any meaningful deep-dive into this issue is an expansion on the logging capabilities of the hub. Whether those logs be exposed to the user or locked down and only accessible by Hubitat doesn't really matter to me as much as it does to others. Hubitat staff has said in the past that resource monitors or other logging ideas that have been proposed would lead people to chasing red herrings. I agree. I don't want Hubitat staff being the doctor to a hypochondriac patient. Their time is VERY valuable and I don't want to waste it. But, at the same time, the only way that this is going to be addressed is if more data on the problem is available.
In the end, I just want the problem fixed. I have no idea what the best type of logs would be helpful or what data they would contain but it seems that there must be something that could be logged that would help discover why this is occurring. Given the number of folks that are experiencing this continues to expand, it has, in my opinion, reached a critical mass of affected users that something has to be done.
3 Likes
As usual @Ryan780, I agree with your whole post. However, I work in the Fintech industry in a very open, REST api exposed, environment. We interface to dozens of third party systems and allow, encourage and even train everyone who wishes, from High School students to retirees how to adapt, extend, and innovate on our Banking Platforms. Thus, it is much like the Hubitat and other Home Automation Platforms. It is codependent on the Third Party Apps and their quality control and compliance with proper coding requirements. Apple discovered this with the iPhone and implemented the Apple Store to control quality. They realized that their products' reputation was inexorably tied to the quality of the apps produced by others and and they could not afford to say "it's not our problem, it's theirs". IF they did, it was their product reputation that took a hit, not the third party. This is because the average non-technical user looks at everything that a device supports as the device's responsibility.
I am not suggesting that hubitat adopt a Hubitat Store model yet ( though as they grow it will become inevitable IMHO), but i am suggesting that they do need some level of resource, and tools/logging support/development dedicated to supporting this effort as things get to the scale of this problem. We all want hubitat to succeed and prosper. I am suggesting to them and the community that they need to get on this or it will keep them from ever becoming a platform adopted by the mass market (translated: Large population of non-technical users. Also Translated: lots of money for further development of the platform.)
Forgive the slight soapbox evangelizing.
LJ
No, that's definitely a valid point. But I run almost exclusively on Native apps. And I am experiencing the same symptoms. So, I don't believe this is contained to user content alone.
Do you happen to have z-wave devices reporting about the same time you experience delays? Or are the delays continuous on all devices? (Sorry didn't read the whole thread, if you already answered this) I ask this because I experience slowness, but only when my z-wave sensor is reporting something though.
