Yes, I've pressed/held down the button and let it restart, but no change.
The light is sold blue most of the time, and doesn't respond to ping when it is blue.
The light is off completely (no colors), during the brief times (1-3 seconds every 10-30 seconds or so) that it responds to ping. I have not been able to connect to it using the regular interface or the diagnostic mode while it responds to ping.
Yes, just a flat home network, but using Class A private addresses. No particular reason for that, but it's been working fine for years and no recent changes.
Request timeout for icmp_seq 41424
Request timeout for icmp_seq 41425
Request timeout for icmp_seq 41426
Request timeout for icmp_seq 41427
Request timeout for icmp_seq 41428
Request timeout for icmp_seq 41429
64 bytes from 10.147.1.48: icmp_seq=41430 ttl=64 time=30.845 ms
64 bytes from 10.147.1.48: icmp_seq=41431 ttl=64 time=4.356 ms
Request timeout for icmp_seq 41432
Request timeout for icmp_seq 41433
Request timeout for icmp_seq 41434
Request timeout for icmp_seq 41435
Request timeout for icmp_seq 41436
Request timeout for icmp_seq 41437
Request timeout for icmp_seq 41438
Request timeout for icmp_seq 41439
Request timeout for icmp_seq 41440
Request timeout for icmp_seq 41441
Request timeout for icmp_seq 41442
64 bytes from 10.147.1.48: icmp_seq=41443 ttl=64 time=92.213 ms
Request timeout for icmp_seq 41444
Request timeout for icmp_seq 41445
Request timeout for icmp_seq 41446
Request timeout for icmp_seq 41447
Request timeout for icmp_seq 41448
Request timeout for icmp_seq 41449
Request timeout for icmp_seq 41450
Request timeout for icmp_seq 41451
Request timeout for icmp_seq 41452
Request timeout for icmp_seq 41453
Request timeout for icmp_seq 41454
Request timeout for icmp_seq 41455
64 bytes from 10.147.1.48: icmp_seq=41456 ttl=64 time=41.579 ms
64 bytes from 10.147.1.48: icmp_seq=41457 ttl=64 time=3.743 ms
Request timeout for icmp_seq 41458
Request timeout for icmp_seq 41459
Request timeout for icmp_seq 41460
Request timeout for icmp_seq 41461
Request timeout for icmp_seq 41462
Request timeout for icmp_seq 41463
Request timeout for icmp_seq 41464
Request timeout for icmp_seq 41465
Request timeout for icmp_seq 41466
Request timeout for icmp_seq 41467
Request timeout for icmp_seq 41468
64 bytes from 10.147.1.48: icmp_seq=41469 ttl=64 time=96.357 ms
64 bytes from 10.147.1.48: icmp_seq=41470 ttl=64 time=8.322 ms
64 bytes from 10.147.1.48: icmp_seq=41471 ttl=64 time=3.870 ms
Request timeout for icmp_seq 41472
Request timeout for icmp_seq 41473
Request timeout for icmp_seq 41474
Request timeout for icmp_seq 41475
Request timeout for icmp_seq 41476
Request timeout for icmp_seq 41477
Request timeout for icmp_seq 41478
Request timeout for icmp_seq 41479
Request timeout for icmp_seq 41480
Request timeout for icmp_seq 41481
Request timeout for icmp_seq 41482
Request timeout for icmp_seq 41483
64 bytes from 10.147.1.48: icmp_seq=41484 ttl=64 time=95.447 ms
64 bytes from 10.147.1.48: icmp_seq=41485 ttl=64 time=8.596 ms
64 bytes from 10.147.1.48: icmp_seq=41486 ttl=64 time=8.685 ms
Request timeout for icmp_seq 41487
Request timeout for icmp_seq 41488
Request timeout for icmp_seq 41489
Request timeout for icmp_seq 41490
Request timeout for icmp_seq 41491
Request timeout for icmp_seq 41492
Request timeout for icmp_seq 41493
Request timeout for icmp_seq 41494
Request timeout for icmp_seq 41495
Request timeout for icmp_seq 41496
Request timeout for icmp_seq 41497
64 bytes from 10.147.1.48: icmp_seq=41498 ttl=64 time=51.996 ms
Request timeout for icmp_seq 41499
Request timeout for icmp_seq 41500
Request timeout for icmp_seq 41501
Request timeout for icmp_seq 41502
I was away most of the day. When I got back, I noticed that the old app was able to connect and reported that the database was corrupted.
I was able to restore from backup, and the hub rebooted and seems fine so far.
No physical or configuration changes were made on the network, so it's unclear what happened that now allows the hub to connect and to have a backup restored.
The hub is now back on the version it was on a couple of days ago. I think I'll skip the latest release for now and wait for a newer release before updating.
I've had corrupted databases before and had been able to access the diagnostic menu and restore to a previous database. This case was different in that I couldn't access the diagnostic menu on port 8081, so I thought the hub was really bricked this time. Thankfully it recovered enough to be able to restore the backup, so it's now back in service.
It's a bit concerning though not having a root cause for the problem, and not knowing what changed eventually to allow it to be restored, and why in this case I wasn't able to immediately restore from backup.
The issue of database corruption is a concern. My understanding is that it can be caused by a power outage or ungraceful shutdown. I don't know much about the software on the Hubitat, but I hope that a type of multi-phase journaling (not transaction or logical journaling) can be implemented to prevent database corruption, even in the event of a crash.
Thanks for reading this and for offering suggestions.
I am having this problem again. It's been working fine for the last ~24 days. I did not do any updates to the firmware since restoring it to an earlier version before. Here are the steps I've been through today.
Early this morning, I noticed that my automation rules were not working.
I was unable to connect to the UI or to the diagnostic port 8081, connections were refused.
Tried pinging, but most pings get request timeout. I'd get a response for 1-2 seconds every 5-90 seconds or so, sometimes longer. When it responds, the time usually is 4-120 ms, but there were a few over 1000 ms.
I took a look at the C5 itself. I saw a solid blue light, and the light would go off for 6-8 seconds every 5-90 seconds. Each time shortly after the light went off, there would be 1-2 seconds of ping returns.
I disconnected the network cable from the C5, thinking it might force it to reacquire DHCP address, or maybe do some kind of network reset, but it didn't make a difference. The light cycled blue and off in the same pattern, and all I was getting from ping is host down.
I reconnected the network cable. Ping started responding, but what is interesting is that the ping requests were buffered somewhere, maybe in the router, because I got sevaral responses immediately that showed very long times, but decreasing with each one, until it was down to about 4ms.
Request timeout for icmp_seq 28831
Request timeout for icmp_seq 28832
Request timeout for icmp_seq 28833
Request timeout for icmp_seq 28834
ping: sendto: No route to host
Request timeout for icmp_seq 28835
ping: sendto: Host is down
Request timeout for icmp_seq 28836
ping: sendto: Host is down
Request timeout for icmp_seq 28837
64 bytes from 10.147.1.48: icmp_seq=28781 ttl=64 time=57732.857 ms
64 bytes from 10.147.1.48: icmp_seq=28782 ttl=64 time=56729.530 ms
64 bytes from 10.147.1.48: icmp_seq=28783 ttl=64 time=55725.300 ms
64 bytes from 10.147.1.48: icmp_seq=28784 ttl=64 time=54719.987 ms
64 bytes from 10.147.1.48: icmp_seq=28785 ttl=64 time=53716.357 ms
64 bytes from 10.147.1.48: icmp_seq=28806 ttl=64 time=32632.993 ms
64 bytes from 10.147.1.48: icmp_seq=28807 ttl=64 time=31628.526 ms
64 bytes from 10.147.1.48: icmp_seq=28808 ttl=64 time=30640.210 ms
64 bytes from 10.147.1.48: icmp_seq=28809 ttl=64 time=29637.988 ms
64 bytes from 10.147.1.48: icmp_seq=28810 ttl=64 time=28633.517 ms
64 bytes from 10.147.1.48: icmp_seq=28831 ttl=64 time=7548.978 ms
64 bytes from 10.147.1.48: icmp_seq=28832 ttl=64 time=6543.940 ms
64 bytes from 10.147.1.48: icmp_seq=28833 ttl=64 time=5541.468 ms
64 bytes from 10.147.1.48: icmp_seq=28834 ttl=64 time=4537.726 ms
64 bytes from 10.147.1.48: icmp_seq=28835 ttl=64 time=3535.056 ms
64 bytes from 10.147.1.48: icmp_seq=28839 ttl=64 time=4.768 ms
Request timeout for icmp_seq 28854
Request timeout for icmp_seq 28855
Request timeout for icmp_seq 28856
Request timeout for icmp_seq 28857
Request timeout for icmp_seq 28858
Request timeout for icmp_seq 28859
Request timeout for icmp_seq 28860
Request timeout for icmp_seq 28861
Request timeout for icmp_seq 28862
Request timeout for icmp_seq 28863
64 bytes from 10.147.1.48: icmp_seq=28864 ttl=64 time=103.942 ms
64 bytes from 10.147.1.48: icmp_seq=28865 ttl=64 time=8.852 ms
Request timeout for icmp_seq 28866
Request timeout for icmp_seq 28867
Request timeout for icmp_seq 28868
Request timeout for icmp_seq 28869
Request timeout for icmp_seq 28870
Request timeout for icmp_seq 28871
Request timeout for icmp_seq 28872
Request timeout for icmp_seq 28873
Request timeout for icmp_seq 28874
Request timeout for icmp_seq 28875
Request timeout for icmp_seq 28876
Request timeout for icmp_seq 28877
Request timeout for icmp_seq 28878
Request timeout for icmp_seq 28879
Request timeout for icmp_seq 28880
Request timeout for icmp_seq 28881
Request timeout for icmp_seq 28882
Request timeout for icmp_seq 28883
Request timeout for icmp_seq 28884
Request timeout for icmp_seq 28885
Request timeout for icmp_seq 28886
Request timeout for icmp_seq 28887
Request timeout for icmp_seq 28888
64 bytes from 10.147.1.48: icmp_seq=28889 ttl=64 time=96.759 ms
Request timeout for icmp_seq 28890
Request timeout for icmp_seq 28891
Request timeout for icmp_seq 28892
Request timeout for icmp_seq 28893
Request timeout for icmp_seq 28894
Request timeout for icmp_seq 28895
Request timeout for icmp_seq 28896
Request timeout for icmp_seq 28897
Request timeout for icmp_seq 28898
Request timeout for icmp_seq 28899
Request timeout for icmp_seq 28900
Request timeout for icmp_seq 28901
64 bytes from 10.147.1.48: icmp_seq=28902 ttl=64 time=51.751 ms
64 bytes from 10.147.1.48: icmp_seq=28903 ttl=64 time=9.343 ms
I cycled power on the C5. No change, the C5 goes back into the same pattern.
I reset the C5 by holding the reset button for at least 7 seconds until the light went off and on.
The C5 returned to the same pattern.
It's been several hours now, and I still cannot get a response through the regular UI or through the diagnostic port.
I've tried connecting using a Chrome, Firefox, and Safari on Mac. Also tried using the Hubitat app on IOS and Android.
Is there a way I can get the C5 to respond, even if I have to restore from backup?
Why can't I get it back to a factory initialized state by doing a reset?
How can I make this reliable? If I'm not home, I cannot do anything as far as cycling power, pressing the reset button, or reconnecting cables. I travel often and am away for up to 8 weeks at a time,, so automations won't work until I return and can fix this. Also, I have a concern that once I'm gone forever, no one here is technical enough to troubleshoot and maintain this setup.
I'm wondering now if HE supports any kind of high availability or failover. I admit that I haven't dug deeply in to the documentation, but it would be great if failover is supported. I'm willing to buy another HE if that's what it takes.
Right now I assume that if I can get the C5 to respond that it will again have a corrupted database. I hope that a future update might have a feature to journal database changes such that a corrupted database can roll back to a previous know good state.
I found the source of the problem -- the USB power source.
I was moving cables and switched to a different USB power source. The C5 booted and worked normally.
I tested with different micro-USB cables, and found that the cables are fine.
I don't know yet what it is about the USB power source I was using causing the C5 to have problems, but I suspect low voltage. I'll try to get hold of a USB tester to see what it shows.
I now think that the problem occurring after an update was just a coincidence. I do not think the update caused or was related to the C5 becoming unresponsive. I updated to the latest version last night, and so far no problems.
Thanks for reading and for the suggestions. I'm still interested in the HEha and will be looking into that.
I borrowed a USB power checker, and it doesn't even turn on the display for the power supply in question. I believe that the checker requires a minimum of 3.5V on the 5V output, so I guess the power supply wasn't even putting out 3.5V. I also found that plugging in a Blink sync unit resulted in one of the lights going on, but the unit itself not functioning. So it was definitely a bad USB power source.
