C8 Pro - How can I see a log file entry describing the reason(s) for the green/red LED blinking?

🎬 Get Started Using C-8 Pro
1

Hello..

I have a C8 Pro that was doing the green/red blink sequence on power up when connected to my IoT DMZ network.

It had no such problem when plugged into my house LAN.

I went through the C8 Pro log files and did not find any recorded event for the green/red blinking LED on the device.

Where is there recorded information about why the device is doing the green/red blink that I can find after moving the device to a network that at least allows me to log into the device and look at a log file?

IF there is NO current capability to record the reason why the device is doing the green/red blink sequence, can you please put in in the enhancement queue to provide such info so we have a much better means of understanding of what is wrong so we can do a quicker job of figuring out a fix?

Thanks!

Paul

2

I know it's documented somewhere but I THINK the hub led flashing green/red means there is no connection to the internet.

1 Like
3

@bobbles - Yes, that is a consistent theme through a lot of posts.

However, there are many sub-items that go into 'connection to the internet'.

Could it be a DNS problem?

Could it be a ping problem to some site that the C8 device uses to validate general connectivity?

Is it lack of an IP address?

Is WiFi connectivity broken?

Is there a physical problem with the network interface?

Is there a IPV6 issue? If it is actually required by a Hubitat device?

The above is not an exhaustive list of possible problems.

Information about any of the above can be very helpful when recorded into a log file that we can view and determine what to do to fix the problem(s) that show up.

Paul

4

I believe red and green flashing means the hub is configured to request an IP address with DHCP but it didn’t get one from your DHCP server.

My guess would be something related to your VLAN/subnet configurations.

2 Likes
5

@marktheknife - Yes. Please see my reply to @bobbles.

6

Right. It’s not a generic “I can’t reach the internet, you figure out why” flashing light sequence.

It means what I said, “I’m expecting a (ipv4) DHCP IP address and your server didn’t give me one.”

Does that not narrow down the underlying problem?

2 Likes
7

@marktheknife - No, that does not narrow down the problem.

Going back to my 35+ years in datacenters, desktops and networks. "I can't reach the internet' is like a computer neophyte saying my computer won't boot at a remote location.

You end up spending hours to days starting at ground zero and working your way up only to find that for whatever reason, such as the video cable connector into the back of the monitor went crooked when the person rearranged their desk to make it look neater.

As I stated earlier. There are a lot of piece parts that all need to be working in order to get a functional network connection.

Providing helpful information about what part of the decision tree that the Hubitat failed at to establish the network connection into a log file is stunningly helpful and makes it much faster to fix the problem.

8

It seems like you’re not hearing what I’m saying?

The flashing green/red light does NOT mean “I can’t reach the internet.”

It means “I need an IP address from a DHCP server but I can’t find one on this subnet.”

That may not tell you exactly why it can’t, but that’s much more specific than “honey, the ‘WiFi’ is down again, can you fix it?”

1 Like
9

@marktheknife - Ah, no.

In my case, the device got an IP, and I could log into it and then I couldn't and then I could, at which point the red/green lights blinked.

Didn't have anything to do with a bad DHCP or lack of an IP. The network hub in the middle was going in/out on me. And since the Hubitat does not generate sufficient traffic to make the switch port light up solid, there was no visible indicator on the network hub to know there was a problem.

Since the Hubitat reaches out to our own cloud accounts, on some periodic basis, to see what is going on, it can use the inability to communicate with the Hubitat cloud account to tell me that communication channel failed in a log file. That would tell me that DHCP worked, got the IP, had a link to the WWW at some point and then didn't. Which I can then use to correlate to other info about power outages in the house, maintenance on any of the 'middleware network devices', known issues with ISP carrier to the house and other things.

All to shorten the time spent debugging the problem and provide guidance on what to look for.

10

Is the LED flashing red/green now, does the hub have an IP address now and can you browse to the hub UI on that address now?

11

@marktheknife - No, Yes and Yes.

I took the network hub out of the equation for the Hubitat.

Other IoT devices I have on that hub work just fine.

I know it is not a port problem on the hub since I moved the Hubitat to 3 of the 5 ports and it still ended up blinking green/red.

The other IoT devices are apparently not bothered by a hub going up/down. I can communicate just fine with them and they report no problems.

There is no visible indicator on the hub that it is having problems.

Yes, the hub will be replaced since it will eventually fail at the worst possible time.

Just part of the challenge of debugging network problems and ending up with my version of the green/red blinking LED. I had all indications that everything in the network path was working just fine.

Which gets me back to having something written to a log file when a network problem happens that tells us what failed so we can infer what the possible causes could be.

In this case, if the message said it could not contact the cloud account, or whatever it does to periodically validate a live network link, I would know for sure that the physical interface in the Hubitat worked, DHCP worked to get it an IP. And then it failed.

Which would have put me to looking at the hub yesterday evening instead of this morning since the DHCP server is the firewall.

My network topology is:
WWW <> ISP Provider <> Firewall/DHCP <> Hub for isolated DMZ <> IoT devices

The firewall is configured to block all unsolicited network traffic that originates from the WWW and ISP Provider.

My solution for the moment was to fire up another port on the firewall as another DMZ which has its own DHCP scope and firewall rules to talk only with the WWW.