Rpi3 hass.io with sonos and chromecast media players on separate subnet

Hello peeps,

I’ve been playing with home assistant for some time now and I REALLY like it. I have it running on an Orange Pi +2E running Armbian and it performs quite well. I recently learned about using the Amazon dash buttons to control stuff but apparently the dash button feature is only available by using hass.io. I tried to install hass.io onto a spare Orange Pi +2E that I have but I was unable to get the images to work since they aren’t for that specific model. Anyway, after that I purchased a Raspberry Pi 3 B+ and I installed hass.io on that and I was able to get the dash button working, huzzah!

However, I copied all my config files from my Orange Pi over to the Raspberry Pi and I found quickly that my sonos speakers and my chromecast are showing up as red boxes, saying No state available for media_player.<room name>. I started to dig into this issue a little and I’m realizing that hass.io appears to run everything from docker containers. I installed the ssh module and opened a connection to the system and I found that it’s IP is of the 172.30.32.0/73 variety.

I have two subnets in my house, one for wired things (192.168.0.0/24) and one for wireless things (192.168.1.0/24). I’ve plugged the Raspberry Pi into the wired subnet and I think because these dockers are given a third subnet, they’re unable to talk to the wireless subnet. I’m sort of out of my element because of my lack of understanding of docker containers when it comes to networking. Anyone know how I can fix this so that my hass.io machine can actually communicate with my sonos speakers and chromecast?

Here I ping the wired subnet, no problem.
Then I look at the routing setup,
Then I try to ping the wireless subnet, can’t communicate.

core-ssh:~# ping 192.168.0.1
PING 192.168.0.1 (192.168.0.1): 56 data bytes
64 bytes from 192.168.0.1: seq=0 ttl=63 time=0.933 ms
64 bytes from 192.168.0.1: seq=1 ttl=63 time=0.769 ms
^C
--- 192.168.0.1 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 0.769/0.851/0.933 ms
core-ssh:~# ip route
default via 172.30.32.1 dev eth0
172.30.32.0/23 dev eth0 scope link  src 172.30.33.1
core-ssh:~# ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1): 56 data bytes
^C
--- 192.168.1.1 ping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss
core-ssh:~#

Thanks,
-Greg

Well, this was a weird problem. I have since upgraded my sdcard and restored the snapshot from the old setup. Now the system works and I can see the other subnet. So, problem solved, I guess. It makes me a little nervous not knowing why this was the case before and why it works now but hopefully it doesn’t break again.