Google smart speaker static IP address

Something I just noticed yesterday in my Openhab Google Nest mini configuration was the IP address of the device.

May I ask why we are using the IP address of a device and not the mac address. Oh a local network my smart speakers have dynamic IP addresses however I now find I need to allocate static address to every google device. Lucky for me I only have less than 10 devices however It could be rather annoying for others.

I am running OH 3.2, this is a policy decision so no other details are relevant.

So those who have Google devices that are strangely offline check your network configuration, like if I was bored I could write a script to update a configuration file with all of my google devices however it is easier just to allocate a static address.

I do use my ISP’s crappy modem router that they supplied however needed to migrate the DHCP server to another device because of the limitations on the number of devices I could have attached to the network.

I guess you could modify the Chromecast binding to use mac addresses

The MAC address would only work if everything is on the same subnet and I believe they even have to be on the same switch. We can’t guarantee that and that is sort of the whole reason that IP addresses exist in the first place. If you have two switches between OH and the Nest Mini, ARP will tell OH that to talk to the Nest Mini use the MAC address of the switch, not the end device. If you have two Nest Minis behind that second switch, both will have the same MAC address as far as OH is concerned.

Pretty much all of us use static leases in our DHCP server so devices keep the same IP.

No, you can have as many switches as you like between the two devices, but yes; it has to be on the same subnet.

It might not matter to this, but Chromecast speaker groups have one device serve as the “elected leader”. So the group uses that device’s IP address, but with a different port number (which changes periodically). Not sure if that would hold up with MAC addresses.

The way the TCP/IP stack is designed requires an IP packet to encapsulate the layers above, you can’t put the TCP/UDP segments directly in the Ethernet frame. And while ARP enables the discovery of a device’s mac address from a known IP address, there’s (to my knowledge) no way of doing it the other way around.

I have had chromecast on multiple subnets and just they are completely painful to talk to from the google app on my phone. So eventually I moved them all onto the same subnet however I have several access points around the house so they are not all on the same subnet.

Short of putting a wemos d1 mini on each subnet to act as a proxy even just getting it to work on one subnet would be a start and replicate what google has implemented in its own products.

I think those issues are because the mDNS discovery multicast messages doesn’t propagate beyond the the broadcast domain, which means they can’t be discovered on a different subnet (but could still be controlled if you know the IP address). I know that unifi has a mDNS reflector service to work around this, not sure if similar services are available on other routers. This makes services like Spotify connect and (I think) Chromecast work across subnets, but others that use more complex communication (many Sonos users have banged their heads trying to get this to work) are harder.

Does the binding really require an IP address or can you enter a hostname in the field and then use DDNS to update a DNS server from the DHCP server when a device changes IP address.

I use this for all bindings that use IP to communicate with devices (Samsung TV, Tivo, Network, MQTT, Remote openHAB Server)