@rlithgow1's approach will definitely work, no question about it, and it's a quick and easy fix. Many of us find it easier to create a DHCP reseravation in the router's DHCP table. It makes things simpler to manage going fwd. If you do decide to set a static IP address on the Lutron app it would be best to choose an IP address that is out of range of the router's DHCP scope. Otherwise you run the risk of the router reassigning the IP address you just gave the Lutron hub and creating a situation where you have two different devices with the same IP address.
4 Likes
I'd go with the DHCP reservation IMO. That way you don't risk a duplicate IP on the network and if you need to get in the device down the road but your ip scheme changed then you don't have to set up a temporary network just to access the device.
2 Likes
OK, problem here... I just checked Lutron network settings and DHCP was off. Underneath the DHCP button is a place to set IP address. But, again, that was all set properly before. So if DHCP is off, it's not supposed to change IP addresses, right? Right now it's off and the IP address is 10.0.0.148, which is what Hubitat's Lutron App is set to also.... so is there something else I need to do to keep it from changing?
If that IP is in your DHCP scope, an IP might have been handed out with that same IP.
2 Likes
Right and in that case the Lutron app still work because it's cloud-based and does not care about the local IP address. Local integration, which is telnet-based, would fail since it depends on HE knowing the destination IP of the Lutron hub.
2 Likes
I came across this:
"The EmberZNet PRO stack supports sleepy and non-sleepy end devices. The choice of node type must also be considered carefully.
For example, in a very dense network, it is not always advantageous for all line powered nodes to be routers due to possible interference issues which may occur when a child node tries to find a parent node to communicate with. It is important to try to create a balanced network where all nodes have redundant paths, but without too many routers in close proximity to create interference."
So, it looks like having too many repeaters can cause issues. It is something to look at.
When I hear "sleepy device" I have no idea what that is unless you are referring to what I am during a college lecture after pulling an all-nighter.
OK, quick clueless question here.
My router says:
DHCP Beginning Address: 10.0.0.2
DHCP Ending Address: 10.0.0.253
So, does that mean I could tell Lutron to take IP address 10.0.0.254, and with DHCP off as described above, it should only have that address and never be assigned a new one?
I'd change the beginning address from 2 to 51. That gives you 50 statics you can assign to whatever you want.
3 Likes
Wouldn't it be easier to just reserve an IP after the ending address? Problem is some IP addresses in the first 50 are already taken up by other devices, many which I can't identify from the router interface. I assume that taking them away would just make the router assign them new ones within its new range, but knowing my luck, that would lead to some major network disaster.
So, change the range at the other end. Free up .251 - .254. (Btw - .255 is the broadcast address in a class c network. Never use it for a device.
Really, the simplest solution is to reserve IP addresses for each device in your router’s DHCP settings.
1 Like
I wondered about sleepy end device too. Turns out it just means that the radio in the device shuts down between times it needs to check in to save power.
1 Like
Another characteristic of Zigbee end devices is that they can't directly send or receive data to any node except the one 'parent' that they are associated with.
So all messages sent to an end device get stored in its parent and held until the end device wakes up and retrieves them (which it does periodically; usually within several seconds maximum). Likewise all messages originating from an end device first get buffered in the parent repeater which then routes them through the network.
Hence the limit to the number of child devices that a repeater can host, since each end device requires dedicated resources (send/receive message buffers) in its parent repeater.
1 Like
Most battery operated Zigbee devices.
They enter stand-by mode until they are activated (motion in a motion sensor, pushed in a push button, …) or they are programmed to report (battery level in most, luminance level, temperature, …). They also use this second case to check connection quality and in cases decide to reroute if necessary, in a process that may last hours to succeed.
Do a google search for advanced port scanner. Download and run it, it will scan your entire network and give you name to mac address and ip..
1 Like
I’m not familiar with Xfinity routers, but this should be the simplest way to take care of this.
I say should, because it’s possible Xfinity, in their infinite wisdom, locks down the admin interface of the routers they provide to customers.
So I second @aaiyar’s question. What’s the model # of your router? Have you checked out the manual (probably available online)?
@Krishna Or if you post the model # of the router I bet someone here can look it up and give you some guidance.
Looks like it's only compatible with Windows 
Run nmap on your Mac.
I’m not understanding the OP’s seeming hesitation to set a dhcp reservation directly in the router’s settings page (if that’s an option).
If the Lutron bridge already has a static IP outside of the dhcp range, it can be reset into dhcp mode and it’ll reconnect to the router.
Many home routers show the list of connected clients with their mac/ip addresses and a host name (so you can identify which device is the caseta bridge).
Set the reservation that way.
This is why the model # of the router has been brought up btw, this is all speculation without knowing that. But it requires no real knowledge of advanced IP networking concepts or command line dexterity. Just following instructions in a graphical user interface.
3 Likes
