I’m having problems connecting to my C8 Pro. It’s been up and running for a few months now without issues but yesterday I decided to make a change:
My network is a TPLink mesh WiFi system connected to a Starlink router. The C8 was previously connected to the mesh network (192.168.68.x /22) and I had no issues connecting to the C8. But I also run a wired private network (192.168.0.x /24) that contains no DHCP or DNS; just a dumb ethernet switch with all connected devices statically mapped.
So, I’ve heard that for reliability reasons that I should be using this network to admin the C8. So, I assigned a static IP address to the C8 and wired it into this network. Instantly lost connectivity with the C8. It still shows up in my WiFi mesh as 192.168.68.55, at least I "think" that a device called "iot_device_532C" is my C8. I can ping it. But any attempt to connect to it results in “connection refused”. And an Nmap scan of my wired network shows no C8 present. I’ve tried disconnecting the wired ethernet cable and resetting the network several times.
I’ve tried various browsers and security settings…no luck..."connection refused". I’ve reset the C8 with the little microswitch on the bottom several times. The light on the C8 cycles from blue back to a solid green, but still “connection refused”.
Where did you hear this? There's no need for this if the network the hub is connected to is working properly and stable. What you want to do, is set an IP reservation on your router for the hub.
What IP did you assign? Have you tried reaching the C8 using that IP?
That resets the network settings on the hub and defaults to DHCP. If you have no DHCP on the network the hub is connected to, that is your issue.
When you configured the ethernet did you disable the Wifi as it suggested? If so, then Wifi is shut off.
There is a small chance that if you boot it without ethernet it will fire up the onboarding SSID which you can connect to and reconfigure the Wifi.
Otherwise your only other option would be to connect to an ethernet which has DHCP so it can get an IP, then you can connect and try to configure the Static IP again, or put it back on Wifi.
Yes, I did disable the WiFi when I assigned the static IP but I thought that resetting the network via the microswitch would set all networking on the C8 back to defaults. I have a green light on the hub and I had believed that this meant that the C8 had received or set a valid IP address from somewhere. I have unplugged the ethernet and reset the C8 since, but no luck. I can try to connect the C8 via ethernet to the hard wired mesh network input (h has a DHCP server available) and see if that works.
As to the reliability issue, the only problem is our frequent power outages out here in rural Ohio. The C8 then gets a different IP address every time. Not a big deal and not difficult to work around, but I thought that the static IP would remove this minor inconvenience. The static IP that I assigned was 192.168.0.100 /24 which is the same subnet as everything else on that wired network. It's just not there. I ran NMap on that subnet which found all of my wired/static devices but no C8. No ping results either.
As an aside, if I reserve an IP address on my WiFi mesh network, how do I tell the C8 to use this reservation on the WiFi side? Only option I remember seeing for static addressing was on the Ethernet port.
I dont think it messes with the Wifi settings, it just sets the network back to DHCP assuming everyone has a DHCP server (router) in a home environment. I think you found a loophole in the recovery logic.
Set a reserved IP on your router/DHCP, should not be difficult to do. I think every home consumer router and up offers this option. Might be called "IP Binding"
Thats the magic of DHCP, you don't have to do anything on the hub. When the hub pings the DHCP for an IP address, the DHCP will always give it the one you assigned.
Dynamic Host Configuration Protocol (DHCP) is a network management system that automatically assigns IP addresses to devices on a network. DHCP also assigns other configuration information, like subnet masks and default gateways.
How DHCP works
A device (DHCP client) joins the network.
The device broadcasts a "DHCP discover" message.
A DHCP server responds with an IP address and other configuration information
Understood. And thanks for all of the help! But I'm still a little vague about how a DHCP server assigned to WiFi subnet "A" can assign a valid IP address to an interface located on wired subnet "B". Wouldn't you need a separate DHCP server that had access and was configured to that network/subnet? Or a bridge between networks (which I do not want to do...that was part of the reason for setting up the independent wired net to begin with)? But it sounds like jtp10181 might have a workaround that just might work: Wire the C8 to my WiFi network just to get a valid IP that I can then use to gain access and reconfigure. I'm still concerned in that I don't understand why my initial setup didn't work though. I assigned a completely valid IP to the C8 ethernet port, turned off the WiFi and apparently for some unknown reason the C8 just didn't accept the static IP.
First, as @jtp10181 mentioned above, no one suggested this.
Second, in simple terms, DHCP servers are not assigned to WiFi or ethernet/wired. For most home based routers, they are configured to assign IP addresses on the primary network. More advanced routers allow the DHCP server to have multiple scopes and assign addresses to multiple networks or VLANS. DHCP configured for network/VLAN "A" cannot assign addresses for network/VLAN "B" and vice versa. It doesn't matter if the client device connects via wire or wireless, it is assigned an address based on the network it connects to.
Your router needs to be configured to forward dhcp requests to where ever the dhcp server is AND the DHCP server needs to have scopes established from which to issue the correct information. You are getting into enterprise level equipment not often seen in home gear.
I guess that I was trying to be nice and in the form of a question pose what I saw was a problem, but turned out to be just a misunderstanding on my part. My network is not really over complicated. Two separate networks; one WiFi connected to the internet, one wired connected to nothing. Two separate subnets. And never the two shall meet. That was my goal and it's worked just fine until now. The wired network has lots of PLC and utility protective relays on it (SEL) that I do development work on and I want to maintain this as independent from any other network as possible. I know I'm a bit over the hill, but part of my current job involves engineering utility protective relay schemes and SCADA for substations and transmission. Been at it for 46 years. No expert, no dummy. So when I did a stone simple static IP assignment and the device apparently ignored me, I was definitely in WTF mode and came here because lord knows every piece of IP enabled hardware has it's own little implementation quirks. And you guys provided a work around!! I thank you all for your time and knowledge!
Well I know some people do use the static IP and it CAN work. If any field is filled in wrong though, it will fail. That is where the network reset comes into play. It is just so much easier to use a DHCP reservation and not have to worry about it.
As for your setup, if you moved the Hubitat to the wired DHCP-less network, it has no internet connection? So then you would not be able to download updates or use any cloud services. Was that your intention?
It was. But on further thought it definitely isn't the greatest idea I've ever had. Guess I was trying to solve a minor inconvenience (the IP reassignment on power outages) using a static IP when I should have just given my DHCP server a reservation. My bad. My wired network contains hardware that when installed in the field will not have access to DHCP/DNS or even routing tables. So I'm trying to keep that net as close to what the relays will see in the field as possible so if I've misconfigured something in the relay the mistake won't be covered up by services not available in the field. But you're absolutely right: my brain fart in thinking "Well, I've already got this statically mapped network...why not use it?" when the easy answer was staring right at me. Being a utility guy I guess that my default mindset is to not allow ANY device anywhere near the internet if at all possible.
I get where you're coming from - I had the same practice. Started long before DHCP; when RARP and the BOOTP were used to assign addresses. There were random client incompatibilities with both RARP and BOOTP, so I started using static configurations. Broke myself of that habit about 8-10 years ago.
Ahhh! So you've been doing this for awhile too? Yeah, I remember the "good 'ol days" when I built a dial-up ISP service for the local electric cooperative. They wanted to be an ISP and I guess I didn't run away fast enough. But electric utilities are still, for the most part, extremely conservative in their approach to networking. Last substation I worked in was still using pilot wire relaying (bias the power lines with an 18 Hz. comm signal, then filter it out at the other end). Bandwidth so low that you're back to the bit-twiddling days. Working with a full eight bit byte? Heaven! It's slowly changing now with most new facilities using OPGW steel reinforced fiber cable interconnections but I remember all too horribly well trying to trip a high voltage circuit breaker within 3 cycles of a fault using bandwidth better suited to a toaster oven.
