Hi,
I’ve been using the Chromecast binding in a DHCP-network for several Chromecast/Google home mini devices. Unfortunately I cannot exert control over the DHCP-process so once in a while the Chromecast devices get new IP-addresses.
The things-configurations use the ip-addresses so on an address change, the chromecast devices are no longer reachable.
Is there a way to make the IP’s dynamic in some way?
best regards
Bob
Chromecast should be found with upnp
They were found with upnp but when the things are created, they get a fixed IP in the configuration.
Bob
Maybe you have a second device that is fixed to the same IP address.
Try to fix the Chromecast to another IP address
Assign a static IP address to each CC in your router. I do this for all of my IoT devices.
That’s a workaround but I’ll have to buy one. I was hoping for a more dynamic way to handle the Chromecast ip address changes.
Bob
I wouldn’t call assigning a static IP address to be a workaround - especially not in a case where the hardware does not allow configuring a static IP address.
A workaround would be to run a process like arpalert which detects DHCP requests, new MAC addresses, new IP addresses for existing MAC addresses and could start a script. This script could be used to trigger a restart the binding.
In my case I would have to buy a separate router since my telecom provider modem/router doesn’t allow static IPs.
I’m looking at a scripted solution based on a chromecast scanner.
Thanks for the feedback.
DHCP is great whenever you don’t care about locating devices by their IP addresses, and bad when you want a device to always be in the same place you left it. Since that’s also the case with your Chromecasts, it’s not so much a workaround as it’s the solution to a limitation of the binding and devices.
My openHAB RPi4, Chromecasts, Google Homes, 3D printer, Tasmota plugs, and phone all have static IP addresses. That means that I don’t have to use local host names (which can be unreliable) and openHAB never has to hunt for devices on my network.
in case you can disable the DHCP on your router you could setup a DHCP service on an other computer.
Ah, that sucks. I’ll take this opportunity to suggest that you get a second RPi and run Pi-Hole on it. It can provide a DHCP server and block advertisements across your entire network. So instead of blocking ads when they reach your device, you block the initial request from the device to the ad server.
Ads don’t actually bother me that much, but web browsing is significantly faster and more pleasant on pages that download tons of ads. I notice it every time I have to connect to the VPN for my office.
You could theoretically run Pi-Hole on your openHAB server, as it doesn’t take many resources, but I feel better having it on a separate RPi. I run it on an RPi3 that used to be my openHAB server (and was replaced by an RPi4).
Just as followup, I made a small python script based on Pychromecast that scans for chromecasts, compares with the things-file and modifies it if necessary. This is triggered in a rule based on a cron-timer.
But I’m planning to go for the separate router option in the near future.
nice. Just for curiosity: how often is the cron job being executed ?
I’m still in doubt about a good frequency. At the moment it’s once an hour. The change in address is pretty rare. It might be better to run it when the Chromecasts disconnect.
I would guess that it’s only getting a new IP when the disconnects coincide with the lease expiring. Are you able to see what the lease times are in your router? I’m assuming not since it sounds like it’s locked down.
then you may have a look at arpalert.
E.g. $> ARPALERT ....
You can use arpalert to detect new MAC-addresses in your network as well as IP address changes for specific MAC addresses.
This means you can trigger your script to update the chromecast thing in realtime once the IP changes.
I have no idea but it’s pretty long. So a more there could be a more economic way. On the other hand, running it every hour isn’t so bad either.