No VLAN. Thing is that it was working fine for quite a while, and then it stopped working right after the 2.2.6 upgrade with no other changes in drivers, apps or physical connections ... but it did not resolve itself when I rolled back to 2.2.5
Almost sounds like a corrupt database. You may want to try to do a manual backup to your PC, (this will clean the database) then do a SOFT reset then reupload the database from the pc and see how it behaves after that
@gopher.ny, here is something interesting. I just went out again, and as expected the light stayed green. But when I pulled the ethernet cable and put it in ... it came back up, so that's very interesting.
Hmmm, something overly chatty on the network causing packet collisions? Can you get logs from your switch or run wireshark and watch whats going on?
But why would it fail with the 2.2.6 update. I might try the backup and restore approach and see if that helps.
Just to confirm, the z-wave network will stay intact, right?
So, how "fun" is that, as I was logging into the switch to check port statistics, Hubitat went offline again, but so did the switch, now mind you, everything else on the switch was working, traffic was flowing, but the admin interface was not loading. I moved Hubitat off that port onto one of the ports of the router and it came right up and so did the switch admin screen. Will run it this way and see what happens... very strange times.
1 Like
Yes, only so a soft reset and all the radios will stay intact. Based on your last message though i’m wondering if something is causing some serious packet collisions.
Are there any devices throwing around large packets on the switch by any chance (MTU > 1500)?
Not that I know of, large packets are generally turned off. It did go down again on a different switch, so I guess it was just a coincidence. What's interesting is that it's not responding to ping ...
and the device is not responding on port 80 or 8081
but it's still showing traffic on the interface:
BTW, turning off and turning on the interface immediately brought up the device back into contact
There are a few endpoints to try on the hub itself:
/hub/advanced/network/lanautonegconfigenable - sets ethernet speed to 100, turns speed auto negotiation off
/hub/advanced/network/lanautonegconfigdisable - turns speed auto negotiation on (default)
/hub/advanced/network/lanautonegconfigstatus - shows current setting (true = speed auto negotiation off).
1 Like
Just looking back through to your first post. I see “known good cable”, but I didn’t see you mention a different cable was tried. Wouldn’t be the first time I saw a cable that was otherwise working previously, suddenly give problems.
All it takes is one tiny break that opens just enough to cause problems when a cable gets shifted, or a connection at one or both of the RJ45 ends that wasn’t optimal and now it’s a problem.
3 Likes
returns:
auto negotiation config true
after:
/hub/advanced/network/lanautonegconfigenable
I get
Complete
after:
/hub/advanced/network/lanautonegconfigdisable
I get:
Complete, please restart
and restarting the hub i get:
auto negotiation config true
Should I leave it on the first one? lanautonegconfigenable
@SmartHomePrimer, good point, I will try a different cable later today.
If it bounces back to true, that means network drops are auto-detected, and the system sets it on its own. In vast majority of cases, leaving it at that has no side effects.
Have you checked your switch/router logs?
I had a situation a few months ago where one of my devices was temporarily blocked by the router because it somehow detected a SYN-FLOOD and the network security protections kicked in.
1 Like
Well, still having the issues. The hub drops off my network every 4-5 days. There is no way to contact the hub to reboot. I have to unplug the USB power and plug back in. I have set up a new static IP through hubitat and still have the problem. I'm going to try to migrate to a new hub. Hope that works... Haven't given up on homeseer just yet.
1 Like
There are a few endpoints in latest 2.2.7 that may help with reconnecting:
/hub/advanced/enableNetworkWatchdog - enables a watchdog process that frequently pings default gateway and attempts to reconnect using DHCP if network dropped. It does not permanently revert hub to use DHCP.
/hub/advanced/disableNetworkWatchdog - disables the watchdog process
/hub/advanced/isNetworkWatchdogEnabled - shows whether watchdog process is enabled
1 Like
Well, I transferred all my z wave devices to a new hub. It has been up and running for a total of three days. Now, both hubs have dropped of the network. Any suggestions... Please
Did you try any of the suggestions gopher.ny gave you above?
I would think if it was two separate hubs doing this, it would most likely be your router causing the issue. Did you try to set a static IP (IP reservation) in the router instead of the Hubitat device?
What router brand/model is the Hubitat plugged into?
I have tried the above suggestions - waiting to see if gopher.ny solution will work. Hasn't had enough time to see.
- I have used static IP addresses from the hub and router and used DHCP.
