Lutron "telnet support" disabled itself today.... Nothing Lutron was working

Another question for you... What is the Subnet Mask for your Macintosh, your Lutron Hub, and your Hubitat Hub? (Note: I believe Hubitat may have a fixed subnet mask of 255.255.255.0...)

I found an article from about a year ago stating that Eero changed their default subnet mask to 255.255.252.0, as some users were running out of addresses.

If you do not have more that ~250 network devices in your home, you may want to change the Eero subnet mask to 255.255.255.0 so everything will be able to communicate with everything else on the same LAN.

1 Like

I may have some things messed up. The questions about my IP addresses have me wondering what I may have altered accidentally.

First, both the Eero, Lutron and Hubitat hubs are all plugged in via LAN to switches that come off of the AT&T router. I know some things experienced issues with the switches...perhaps the Hubitat hub is another of those things?

I'm not 100% convinced I gave the correct IP addresses...as in maybe I got that data from the wrong locations. ??

Also, when I look at my Eero interface I can clearly see the Lutron hub, and confirm the IP address is as I had thought. But I'm not immediately seeing the Hubitat hub listed, but that could just be that one of my switches is fed by the Eero and the other is fed straight from the AT&T router. Maybe this is the source of my ills.

Sounds like you may have a 'double NAT' scenario going on. What device is acting as the router and DHCP server for your home network? Sounds like both the AT&T and Eero devices are competing... You should pick one and let it handle the home network.

To get the IP address to the Lutron bridge you can use the Lutron app -> setup -> advanced -> integration (make sure "telnet support" is checked) -> network settings

Also to avoid the power loss I found these nice battery backup devices from "Konnected"
at

I have one at each router / extender and the hub. Works great for several hours in my case for my entire network. They even have a USB port.

Huzzah! ...sorta

So I do have my media closet all messed up I think. Here is my config:

  1. AT&T router brings fiber in to the house
  2. LAN from AT&T router to Eero main (I have two other Eero devices for the mesh)
  3. LAN from Eero main to Switch 1
  4. LAN from Switch 1 to Switch 2
  5. All the LAN cables for rooms throughout the house connected between the two switches.

So the problem earlier was that I had the Hubitat hub connected to the AT&T router directly, and the Lutron hub connected to Switch 1.

I had attempted to connect them both to Switch 1 and I lost connectivity to the Hubitat hub (which is the original problem I had that drove me to connect it directly to AT&T router).

What fixed me just now was connecting both the Hubitat and Lutron hubs directly to the AT&T router, and of course modifying the Lutron Device IP address since it changed once I moved it. Now I'm able to control lights once again from the Hubitat hub and the Lutron app...now I gotta fix Alexa though, it seems.

I'm curious...what am I messing up with these switch configs? Is it that I don't have AT&T acting only as a router? ...that it's competing with Eero for wifi service duty?

Yes. Both the AT&T router, and the Eero Router are trying to be the router for the house, and both are providing DHCP services.

I am sure many others have the same issue you're experiencing. I am not sure if the AT&T device can be put into 'bridge mode' which would then hand over all routing and DHCP services to the Eero router. This would also eliminate the double NAT problem caused by having one router behind another router.

Another option might be to see if the AT&T router can be used as the main router/DHCP server for the house, and put the Eero system in Access Point only mode (to provide just wifi coverage for the house.)

2 Likes

I have ATT Fiber and this isn’t an option. IP Passthrough is only option. My router is plugged into the ATT router and gets the WAN address.

Thanks to all for the help. I'm back up and running after plugging the LAN cables for the Hubitat and Lutron hubs directly in to the AT&T box. Then I called AT&T to work out how to ensure the wifi for that box is off so that my Eero router can handle the wifi.

Most importantly, I'm back in operations for the lights via my Hubitat hub! For the benefit of others that may find this in their hour of need later, the key for me was to resolve the "double NAT" issue between the Hubitat and Lutron hubs.

I appreciate the help.

2 Likes

Because I have unreliable internet and many power outages I placed my Lutron hub and hubitat on a sub net. The ip addresses stay when the main router is down without internet access. Before I did this the hub would grab a new ip address and my local dashboards on devices would quit working. This may be a solution to people where the addresses jump around when your internet goes down.

Well, I think it's VERY important that all 'infrastructure' devices like hubs, gateways and even individual devices have fixed IP addresses. Don't leave it to chance.

My process is let the device connect via DHCP to the router. Look at the router's DHCP lease table, and create a static lease from that. This way you're getting the MAC address right from the device (eliminating the potential for typos with hex addresses).

When creating the static leases I like to group them together, usually at one end of the leasing pool. If for no other reason than making it easier to spot new devices because they'll have addresses at the other end.

Then once you know the static lease you've set up for the device, restart the device and make sure it gets that new address. Once it does, use whatever configuration tools exist for that device to set it to use THAT address as static in it's own configuration.

This accomplishes several things:

  • You know the DHCP router and the devices can 'see' each other.
  • Once the address is in the DHCP tables it won't get given out to something else accidentally
  • You now have a list of the devices in the router. This is useful for future reference, backups and DNS naming.
  • You know the device will get the same address in the future
  • Even if it gets reset it'll still have the static lease putting it right back on that address.

As you connect more things to your network having a SINGLE point of DHCP leases is VERY important. You do not want to have multiple routers on the same subnet issuing addresses. Nor, as you've discovered, want to have routers inside of routers (double-nat).

There are a few situations where segmenting/separating devices is worth doing... but not many.

More often than not attempts to 'isolate' things makes your life worse. Lots of devices expect to use multicast for dynamic discovery and unless you're WELL aware of how to configure this it can cause no end of headaches. Personally, I think dynamic discovery is a BAD PLAN... but many vendors keep pushing for it.

My Telnet was down and when I looked at the Hubitat app the IP address did not match the address in the Lutron app. Aligned these two and it is working fine.

It's probably a good idea to make sure the IP addresses used for your Hubitat and Lutron devices are setup to used fixed IP addresses. Using DHCP leases on the router is a good idea. This way if the devices are reset to factory for some reason they'll still get the same IP address. Even if you set a static IP address in their respective setting options. Setting up a DHCP lease on the router makes sure nothing else will get the IP address either.

1 Like

100% yes, setting on the router centralizes the configuration, also ensures you don't accidentally set two devices to the same IP. Any smart home device that has a network connection (ethernet or Wi-Fi) should be on a fixed IP set on the router.

3 Likes

The only 'downside' to using DHCP leases is they're tied to the hardware ID MAC of the device. For fixed purpose stuff like hubs, routers, switches, this isn't a big deal. You're not replacing them all that often, and then typically only because of hardware failure.

For frequently replaced devices like phones, tablets or laptops it requires the added step of taking out (or editing) the old DHCP lease for "Bob's Laptop" to reflect the MAC of the new hardware.

For things like wifi-connected lightbulbs the same thing applies. Setting up DHCP leases for them is still a VERY good idea. Understanding that "living room lamp" may need a DHCP lease edit if/when that lightbulb (or led 'element') burns out and needs replacement. The upside to a 'fixed' IP address, though, makes it worth the added effort.

Some folks put a lot of planning into 'grouping' their devices in the IP address range. This isn't necessary, at least not from a technical standpoint. It fits into a certain sensibility to try to do this. As in, all DVRs in a sequence of numbers, or game consoles, or lights, or whatever. But eventually you run into hassles when you need to add "just one more" and you bump up against other device numbers. I confess to being of the mindset that tries to do this, and laments when I run into overlaps of 'logical grouping' against the IP lease number ranges.

So using leases is a good idea, just don't get too invested in trying to be really organized about it unless you REALLY know what you're getting yourself into.

5 Likes

LOL, someone has too much money to burn!

:moneybag: :money_with_wings:

But I agree with what you said overall. This DHCP reservation has been a longstanding piece of advice on this community.

2 Likes