[SOLVED] Reliable Hardware & Software?

The first C-7 hub -- software updates using the phone worked okay a couple of times. After that the phone app showed "in progress" for several hours. Generally, I was able to use Hubitat web UI the next day on the computer browser. However, even that failed. From start to death, the C-7 lasted a few months. Hubitat support sold me a replacement for $60 + shipping.

Setup the replacement, registered the hub and upgraded to the latest firmware using the web browser. I was able to attach the phone app. Couple of days later I could not get the UI on the web browser or the phone app. Ping shows 30 to 60% loss. Hubitat support sent an automated ticket number but has not responded.

I like the concept and would like to use the Hubitat. Why Hubitat? Can you (the community) help?

I'm certainly not suggesting Hubitat is perfect and I'm sure bad hardware sometimes slips through, but twice in a row seems odd. I wonder if there's something else going on... maybe a network issue, bad cable/port, auto negotiate failure, something like that? I don't want to ask you to go through a bunch of diagnostics you have already tried...

2 Likes

I'm with @brad - two bad hubs in a row is either extraordinarily bad luck, or there's something else in common - like the things he has pointed out.

FWIW, I've had two C-5 hubs and one C-7. All of them remain functional. From the first week I owned them, they've remained where I mounted them. They're on a sine-wave UPS, as is the unmanaged switch they're plugged into. The oldest of them is now 2.5 years old. And the newest was purchased right when the C-7 was released (so about a year).

2 Likes

Thanks for the note.

I could change the cable. What are the steps? Just pull the LAN cable and change it? I power cycled the first hub (three or four times). I stopped after I was warned (in the community) that it could damage the hardware. The worked for several weeks after the last power cycle before it died. No ping response. I have not touched the second hub since the setup.

How does one check "auto negotiate failure"?

Nothing wrong with power-cycling, if done as follows:

  1. First, do a shutdown from the GUI
  2. Disconnect power from the wall outlet end, and not the microUSB connector.
1 Like

GUI is dead. Does the hub respond to command line?

Have you tried the Diagnostic Tool at port 8081? And what color is the LED?

1 Like

@ravi.ramnarayan Can you get to yourhubip:8081 ??? If so likely you have a corrupt database. (this typically happens for improper shutdowns, such as just unplugging it). If you can get to 8081, do a softreset and restore. This should clear up the corruption. The next thing to do is post a screenshot of your z-wave settings. Just to ensure there are no ghosts.

2 Likes

No GUI on ports 80 or 8081. This hub was plugged in once. Never unplugged. LED -- green

1 Like

You do have to be able to get to the user interface. Assuming you're on 2.2.8 or later, go to settings, then network, then look for "ethernet speed." Change the drop-down to 100mbs, then click update, then restart the hub. May help, may not.

I would also go into your router's DHCP table, find the entry for your hub, confirm the IP address, and then change the assignment to "static." This will cause your router's DHCP server to issue the same address every time. Each router is a bit different so it's tough to give step-by-step directions.

2 Likes

Yeah, no ping and a green light, my money would be on a different IP being assigned

4 Likes

Mine too but it does not explain the packet loss... unless of course another device responded :slight_smile:

2 Likes

Yeah, pretty much. Though a good reboot of the hub wouldn't hurt. That would cause the hub to reconnect to the LAN and request IP info again.

Could have been midway through reallocating the IP.... Not my area of expertise...

Static address -- part of initial setup. No GUI, no command line. Only power & LAN cable to play with. What would "good reboot" involve?

ravi@toga:~$ ping 192.168.68.116
PING 192.168.68.116 (192.168.68.116) 56(84) bytes of data.
64 bytes from 192.168.68.116: icmp_seq=1 ttl=64 time=14.2 ms
64 bytes from 192.168.68.116: icmp_seq=4 ttl=64 time=6.36 ms
64 bytes from 192.168.68.116: icmp_seq=5 ttl=64 time=6.49 ms
64 bytes from 192.168.68.116: icmp_seq=6 ttl=64 time=6.19 ms
64 bytes from 192.168.68.116: icmp_seq=7 ttl=64 time=12.9 ms
64 bytes from 192.168.68.116: icmp_seq=8 ttl=64 time=6.66 ms
^C
--- 192.168.68.116 ping statistics ---
8 packets transmitted, 6 received, 25% packet loss, time 7049ms
rtt min/avg/max/mdev = 6.191/8.809/14.244/3.394 ms

Try the ping test without the hub plugged into the network.

2 Likes

Hmmm if the static IP was set at the hub rather than reserved at the DHCP server I think just a swap of the cable would be fine... though I would try @sburke781's suggestion too.

What does your network configuration look like?

1 Like

Static address was "fixed" after DHCP allocated it. Unplugged LAN at switch and ping:

ravi@toga:~$ ping 192.168.68.116
PING 192.168.68.116 (192.168.68.116) 56(84) bytes of data.
^C
--- 192.168.68.116 ping statistics ---
8 packets transmitted, 0 received, 100% packet loss, time 7163ms
1 Like

Ok well @sburke781 good try but that does actually appear to be the right device.

To make sure I understand... did you set the static IP at the hub using the network config screen? Or is the hub still set for DHCP but the IP address is reserved in the DHCP table? Practically speaking not much different but if the IP address is set on the hub and not somehow blocked from being reissued by the DHCP server that can cause issues if the DHCP server decides to reissue the IP to another device.

2 Likes

The unplugged result would confirm we have the right device though, so I wouldn't expect a clash all of the time. Or to affect the packer loss...

1 Like