I believe the slow page load issues has been identified. Something on the hub side of things in trying to communicate with something on the internet. Because I have the hub blocked from the internet most of the time. the pages load incredibly slow while it is waiting for something to time out.
It seems like hub without cloud might be getting harder and harder to do!
@gopher.ny I know you are looking at this issue now so please let me know what you come up with!
I'll look into the Wait for Mode Home thing. There is a new version of Rule coming in 2.2.5 (Rule-4.1), and one thing that's been gone over is Wait for Mode. So, all of that code is very familiar to me right now, and I'll see what's going on.
Sounds great. Let me know if you need any additional logs or testing on my end Bruce!
It does try to connect to Amazon MQTT, yes. But that's been around for a long time. I'll put an endpoint to turn the cloud off (and back on) in the next version. Nothing critical depends on it. Safe mode, for example, loads without cloud. Anyway, this would be better than cutting the traffic off at the router and having the hub try to pointlessly reconnect all the time. Also, you'd need to turn it back on if you want us to look at the hub.
I don't see anything obvious tying the hub up at the moment. You got plenty of devices but not that many, and average load is low. So this slowdown thing is UI specific, I got all the necessary information off the hub now and will try to see where that slowness comes from.
An endpoint would be great! All of my testing to this point basically points to something server side holding it up (the delay is in the initial HTTP GET for the page)
Right now the only thing my hub can access full time is NTP (Because we still don't have DHCP or an Option to change it (Please 
))
And twilio (because we don't have SMTP)
There is no DHCP setting for NTP, true, but we got these endpoints (since 2.2.4):
/hub/advanced/scanForNtpServers - scans local network for NTP servers and shows the list.
/hub/advanced/ntpServer - shows current NTP server
/hub/advanced/ntpServer/<-value-> - sets NTP server
In my limited experience, emails sent using SMTP from a home IP address are most likely to get rejected outright by the ISPs, anyway. There are too many malware/spambot networks out there. Even with reputed providers, deliverability is hit and miss.
I'm glad to see this. I put in a feature request some months ago and was told by @bcopeland that it wouldn't happen.
Several sites, actually. Just one reason I have a Pi-hole. By denying HE addresses for those domains it doesn't waste time trying to connect and pages load quickly.
There is a community app that lets you select an NTP server of your choice.
I am aware of the community app. I just don't feel like I should need an app to do a OS task.
I am glad to see the Option in 2.2.4
This is the first release I have noticed major lag with page loading due to the internet being blocked. so I wonder if something change or they added something new.
Agreed, but in the mean time I've had NTP from my local server working since shortly after getting my HE in January.
Nice! Does this survive reboots? And platform updates?
There is a DNS timeout setting in 2.2.4 meant, ironically, to recover from a temporary connection drop. The hub is trying to resolve a name on every click.
The good news is that "no cloud" flag is easy to implement, and it appears to solve the "slow UI" issue by the virtue of skipping the offending network request altogether. The bad news is it's not going to be available until 2.2.5.
That doesn't sound quite right as it should be able to resolve the DNS name because it has access to a local DNS server. (which can access the internet) unless it is again using some other DNS sever that is not assigned via DHCP.
Yeah, it's a theory that could be wrong, I haven't tested it. The "no cloud" switch should take care of it either way, though, since network calls will no longer happen.
I was thinking more of an authenticated client, Users provide the Email address and password and server name for SMTP) and the hub connect to that sever and authorizes itself to send
Hey Bruce,
My latest test of this has worked. So I don't know if one of the reboots or something else fixed the issue.
I have turned on logging on both of these rules so if it happens again live, I will have more information.
Exciting!
It's not a big change, just a backwards incompatible one. Adds Wait for Conditions, with full logical expression, replacing Wait for Condition, with a single condition.
And copy/paste I presume...
That's there now. What are you referring to??
Nice. I didn’t know that capability was previously possible.
Download the Hubitat app
