I have a V2 hub that was working fine until i switched out from an Apple Airport router to a Unifi USG router and Unifi Switch. basically what i’m seeing now is the hub comes online, but never gives me a “z-wave ready” in the app. a minute later it ‘disconnects’ and reconnects and cycles through this every minute. ST support said to make sure the router has ports 11111, 9443, 443, 39500, 37, and 123 open, which i’m pretty sure i do now (new to the Unifi USG firewall configuration so i could have it wrong…)
i know the hub is fine bc if i go back to the old setup it comes up w/o problem.
@spikenheimer That pattern actually sounds like a potential crash of the main “hubcore” application software on the v2 Hub. Could you PM me your Hub ID (available in the web IDE) or the email that you use to log in to SmartThings and I can take a look?
ok… so that was interesting… i went out for dinner and a meeting, came back a few hours later to putz around and went ahead and did some network sniffing of the Hub doing its connect/disconnect cycle, noticed some SSDP stuff that distracted me, decided to switch-reset the Hub one more time… and then i notice it doing the blinking magenta led thing… which i hadn’t seen in so long i went to look it up and… lo! hub is downloading new firmware!
and… after its done installing… voila! its up and working like a champ again…
so i’m not sure what happened, or if maybe @nastevens did some magic on his end…
@spikenheimer Good news is that your Hub isn’t crashing. Bad news is I’m not seeing anything specific in the hub logs other than network timeouts leading to a disconnect and reconnect.
If you could, next time you’re testing things out and you see disconnects go into the IDE, to your Hub, then to “View Utilities”, and finally hit “Send” under “Send Hub Logs”. This would guarantee I would have logs available from the exact time you’re seeing issues.
One potential, putting on my home network geek hat for a second. Do you have your DSL modem setup as a DHCP server with your router then getting an address from that? Or did you enable transparent bridging mode and let your router do the PPPoE negotiation? I have no data to back this up, but I feel like higher end equipment (like Ubiquiti stuff) will sometimes get upset if it is behind a firewall instead of itself being the firewall.
so… the long story is long.
i’m setting up a temporary DSL setup at a place i’m moving into in a month and so i was using a spare DSL modem i had… letting my fancy new networking gear do the PPPOE connection and it was working for everything else… so i thought. the one thing i did notice was a weird slowness in the upload bandwidth - the DSL connection is a 5M up / 20 down situation… and i was getting .3M up. didn’t think much of it until nothing was working in terms of punching firewall holes for the ST hub… and seeing no change. (also reading the comments from @kamran and @buddyc48 saying i didnt need to do any firewall changes). so i tried using the fancy DSL modem that my provider gave me that i didnt have time to figure out how to make work in transparent bridging mode… and just hooked that w/ the hub and that proved the hub hardware was working fine so as you saw i then tried doing some network sniffing and finally had a realization that i should figure out how to put fancypants modem into bridge mode and see if that would help… and lo and behold! it did.
of course the extra strange part to the story is the modem that wasnt working combined with an airport router doing the PPPOE was working for a few weeks with the hub… so… shrug ?
also i think maybe telling the ST support peeps to not tell people to open up inbound and outbound firewall settings for all those ports would likely be a good thing. although in reality i think better error logging messages either in app or in the IDE would be good.
There is some confusion around this when giving support advice around this. These ports need to opened outgoing only and I don’t know of any consumer routers that block outgoing ports by default. So this is mostly for the home network engineer who’s tinkering with locking down their network, to remind them to check their settings.
In addition, almost all of these ports are only needed the very first time the hub is plugged in. Once it is up to date only port 443 needs to be available going out to the internet and 39500 needs to be available on the local LAN only (support for LAN devices). 11111, 9443, 37, and 123 were used in the very early manufacturing image - we learned our lesson and condensed everything to go over the common 443 port to avoid headaches. But there are still boxed Hubs with that manufacturing image, so the recommendation still remains for getting things up and running with a brand new device.
Thanks for the reminder on this, I will talk with our support lead and hopefully get these recommendations trimmed up.