Did you check your router to see if it was assigned a different ip address?
Or did you try to go to portal.hubitat.com to see if you can discover your hub again?
2 Likes
Another question: Have you, at any point, pulled the plug on your hub since this started?
yes I did.
- Hub's IP/MAC address do not list in the router's list of clients. When trying to access via IP address that was originally assigned, page does not load, and that IP does not ping either.
- Discovery of hub in portal does not find anything.
- When trying advanced discovery via MAC, portal displays hub icon "found by MAC Address.." which lists the original IP, as per previous point that IP does not respond.
I just noticed that in the router, the Ethernet port where hub is connected lists the connected device at 100Mbps/Half Duplex, so appears that at Data Link Layer Hub is connecting but can't agree on Full Duplex connection.
Are you using a switch?
[EDIT]
The reason I ask is because there are known issues with certain network switches. I've not dealt with it, but there are members here that up on those issues.
yes. unplugged and plugged power back multiple times.
Also unplugged once without network cable connected, thinking maybe lack of network connection will reset something. That did not work either but at the same time router booted via blue to green light which is not I expected... Per the documentation "green" light means hub is on the network, but since network cable was not connected, that clearly was not the case.
I found posts for netgear and asus are you using any of those?
2 Likes
Do you have an extra network switch laying around that you can plug in-between the hub and your current switch/router? That might get things back to a somewhat working status. Pulling the power on the hub should only be a last resort, as the hub is running Linux. Within the OS is a Java Virtual Machine and a relational database. Yanking the power can corrupt the database. This is usually corrected on the next reboot by restoring one of the hub’s automatic backups that occurs between 2 and 3 am every day.
There is definitely an auto-negotiation issue between the C5 Hub and some network hardware. If the hub is left alone for 24 hours, it will automatically apply a tweak to resolve the issue. Hubitat Support can provide assistance to help get things sorted out. Contact them via support@hubitat.com.
2 Likes
- Connected hub to different switch, no changes device boots to green light but does not get IP address
- Tried forcing port speed to 100Mbps/Full Duplex - no difference
I'll leave it connected for 24h, and will share if it recovers.
I do agree that the graceful shutdown from inside of the OS/application is always preferred way. While I'm new to the platform and I do have few things to learn about Hubitat, at the same time I do have a major concern. If the device that I hope to automate the whole house with, can not survive the power outage, that potentially will be a major problem in the future when I'll start relying on the automation for the daily routines. While I can understand the database corruption, the failure my hub is experiencing is surprising, as typically Linux network stack should recover from the unexpected reboot.
Also, there does not seem to be a quick recovery path, no hard reset option that would allow to restore the factory defaults, no option to boot/restore from USB or something similar, which makes the recovery process bit unpredictable.
Hopping my assumptions are not correct, and someone will be able to share different point of view.
These are all valid questions for Hubitat Support. I am tagging @bobbyD as I am sure he can answer most, if not all of these questions.
I have been using Hubitat for over two years now, and it has been extremely reliable. I have my hub attached to a UPS for power, which helps protect it from power blips. I keep offline backups of the hub on my home server, just in case I experience any sort of hardware failure. At least I’ll be able to get all of my automations back and running quickly.
It sounds like you may have somehow hit the perfect storm of events to get things in this state. I hope the support team can get everything straightened out sooner, rathe than later.
Your assumptions are incorrect in my view...
Those exist, but you can't use them if the hub effectively doesn't exist on the network. Put another way, the Hub's primary functionality is via an IP network. tcp/80 specifically.
The Hub will attempt to get a dynamic IP address via DHCP. It will then attempt to use that IP to get to the Hubitat cloud server and 'check-in' (and get info such as is there an update, etc.) Not having a valid IP successfully defeats both. The transition from no led to blue to green is indicative of a successful boot of the platform OS. It believes it's gotten an IP... which can probably include:
" 169.254.x.x: This is what's called an Automatic Private IP address. An IP in this range means that the computer cannot see the network. A computer using DHCP needs to have an external server tell it what IP address to use. Unfortunately, if there's no network connectivity, the computer is unable to talk to the server. In those cases, the computer will actually give itself an IP starting with 169.254, since it must assign itself some sort of number. "
There is an autonegotiation issue that has been resolved BUT requires the aforementioned network connectivity. Specifically this is regarding the speed/duplex of the network connection... the hub get lots of errors and retries to overcome. It does overcome BUT the UI appears VERY slow. This is completely different from not having a valid IP. the hub will detect the autonegotiation problem, report it to the Hubitat Cloud and a fix will be sent to your hub in about 24 hrs. Obviously that requires a 'good enough' network connection.
All of my words above are directly a result of that "clue" you provided.
The hub does NOT require a static/reserved IP but we humans will like it better if it gets one. That way we know where it's supposed to be. Eventually you may add an app or an integration that will need a fixed address.. can't hurt to start now. 
If you can, use the MAC address on the bottom of the Hub to make an IP address reservation in your router. Then unplug the NETWORK wire for 15 mins and when you plug it back in, it should try DHCP again. Watch the lights on your Router when you plug it in.. they should begin OFF and then do a bunch of blinking as it negotiates. While waiting the 15 mins, move some other cable from it's connection on the router and plug it into the socket the Hub has been using. Everything works? Not a bad router socket, right?
100/full into a 100/half will be full of errors BUT it should be able to get DHCP because it's functioning as half duplex in that exchange. The Hub says: "Hey" and switches to Listen. DHCP says "your address sir." they don't overlap.
Do you have some cranky old switch you retired? It might not run into the autonegotiation problem and allow the Hub to get to the point where it can self repair.
3 Likes
Just wanted to share that I was able to recover and hub is back on line. Few key suggestions that helped:
- Configure your router DHCP with the static/reserved IP address for the MAC address of the hub
- Hub has network connection negotiation issues with some routers. If supported by your router seems like forcing 100Mbps/Full Duplex helps
- If you need to change the IP address of your router, seems like clean reboot via web interface works and device gets the new IP as set by DHCP server per #1. When hard rebooted via pulling the power plug, I noticed that device would get confused and did not update the IP address. It maybe isolated case, but definitely as recommended by @ogiewon pulling the power plug should probably be a last resort.
Side note... Wanted to thank @april.brandt @ogiewon and @csteele for all your good suggestions. I did open a support ticket and have to say I'm bit disappointed as 5 days later nobody cared to even respond.
4 Likes
I'm happy you got it recovered and I'm sorry that you felt alone in this. That is very odd for Hubitat as a whole. Usually one of us will alert them of an issue that is ongoing like yours. So, my apologies for not paying closer attention to the situation. I do hope that you enjoy your environment as much as we do now that you've got it up and running.
2 Likes
I would ask you to give the "official" Hubitat support team a chance to explain. Based on my experience, I would be very surprised if "nobody cared to even respond". Not saying you haven't had a bad experience and not excusing it but I suspect something happened to your ticket.
5 Likes
I know this is an old thread but I'm having an issue with my hubitat connecting at correct speed/duplex. I have tried auto-negotiate and hard coding but no matter what the hubitat comes up as 1/2 duplex. This in turn starts to generate errors on my switch:
port 34-Excessive CRC/alignment errors.
this is happening constantly. Is there any way to troubleshoot network settings on the hubitat side?
What switch do you have (brand/model)?
What kind of patch cable are you using to connect the Hubitat?
I've tried cat5e and cat6 both with same result. Just for clarification I have 12 other devices on this switch without any issues.
My colleagues who use a lot of POE devices prefer Cat6A or Cat7. There are others here with much more experience with POE than me - tagging @JasonJoel @lewis.heidrick @ogiewon @marktheknife
so apparently had to shut down the port and set to 100/FD then bring back up. Seems to be working now. Thanks for the replies.......
2 Likes
