Docker Chromecast audio issue due to URL not being accessible

[Bravo]

Hi,

I have recently changed to using a docker setup and Chromecast has broken. However I can see where it appears to be broken.

Homeseer HS4 Standard Edition 4.1.11.0 (Linux)
Mono JIT compiler version 6.12.0.107 (tarball Thu Dec 10 05:28:17 UTC 2020)
Lan IP 172.17.0.2 (d5f905df362e)

Plugins:
Chromecast 4.0.17.0,
Harmony Hub 3.7.2.0,
mcsMQTT 5.3.0.4,
Z-Wave 3.0.2.0

When I test TTS I get this message

Playing http://172.17.0.2:80/Chromecast/audio/chromecast20210127221412573.mp3 on Bedroom speaker

I am unable to play this file because 172.17.0.2 is the internal IP of the container and not externally accessible.

If I change the IP 172.17.0.2 to the IP of my docker host I can play the audio file.

Ideally it would be good if somewhere we could specify the IP / hostname that is used and this would fix the problem for anyone behind some kind of proxy device or using docker. This does not appear to be an issue for the HomeSeer UI as it seems to be using relative URLs which allows HS to run on one IP:PORT and have me map it to another with Docker.

Brad

[spud]

In Setup > Labs > Bind server to IP Address, enter the correct IP address for your HS server, then restart the Chromecast plugin

[Bravo]

Thanks for the response but this doesn't fix the problem. When running under docker using default networking setups, the container gets an IP in a private range (my case 172.17.0.2) that isn't routed onto the host network (my case 192.168.155.X). If you bind the Homeseer server to an IP on the host network (192.168.155.X) that doesn't belong to the container network it will never get the traffic as no traffic destined for 192.168.155.X will ever be delivered to the HomeSeer server. When I had this setup I was unable to even contact the HomeSeer interface.

The only fixes I can see are attempting to bridge the docker IPs directly onto the LAN, having docker run on a new subnet and then routing between subnets or having URLs return a configurable hostname to use. A configurable hostname would also allow HomeSeer to operate behind other firewall and load balancing setups.

I was playing with the docker networking, I think it might work but will take a bit of custom network configuration to get working.

[wpiman]

Thanks for the response but this doesn't fix the problem. When running under docker using default networking setups, the container gets an IP in a private range (my case 172.17.0.2) that isn't routed onto the host network (my case 192.168.155.X). If you bind the Homeseer server to an IP on the host network (192.168.155.X) that doesn't belong to the container network it will never get the traffic as no traffic destined for 192.168.155.X will ever be delivered to the HomeSeer server. When I had this setup I was unable to even contact the HomeSeer interface.

The only fixes I can see are attempting to bridge the docker IPs directly onto the LAN, having docker run on a new subnet and then routing between subnets or having URLs return a configurable hostname to use. A configurable hostname would also allow HomeSeer to operate behind other firewall and load balancing setups.

I was playing with the docker networking, I think it might work but will take a bit of custom network configuration to get working.

Did you ever get this working?

[Bravo]

Did you ever get this working?

I did. I ended up making my docker give IPs from my subnet to the container and then set the IP to that in HS. macvlan was the solution some of my docker-compose config for this is here. You'll need to look at how to configure macvlan as I forget, I did this ages ago.

networks:
homeseer:
driver: macvlan
driver_opts:
parent: enp2s0 #your ethernet interface
enable_ipv6: false
ipam:
driver: default
config:
- subnet: 192.168.155.0/24
gateway: 192.168.155.1

I then add this do the entries for Homeseer and other containers that I want to have local lan IPs

services:
homeseer:
build: ./docker-homeseer4
volumes:
- /home/brad/HomeSeer:/HomeSeer
- /etc/localtime:/etc/localtime:ro
networks:
homeseer:
ipv4_address: 192.168.155.210
dns:
- 8.8.8.8
- 4.4.4.4
dns_opt:
- use-vc
devices:
- "/dev/ttyACM0:/dev/ttyACM0"
restart: "unless-stopped"

Good luck

[Bravo]

ohh yeah I also used my own custom docker file for Homeseer. I think it was to use my local TZ properly and latest mono. Here it is too but pretty much what the standard dockerfile is.

FROM mono:latest

ENV S6_VERSION=v1.21.4.0
ENV LANG=en_US.UTF-8
ENV LANGUAGE=en_US:en
ENV LC_ALL=en_US.UTF-8
ENV HOMESEER_VERSION=4_1_11_0

RUN apt-get update && apt-get install -y \
chromium \
flite \
wget \
nano \
iputils-ping \
net-tools \
etherwake \
ssh-client \
mosquitto-clients \
mono-xsp4 \
mono-vbnc \
avahi-discover \
libavahi-compat-libdnssd-dev \
libnss-mdns \
avahi-daemon avahi-utils mdns-scan \
ffmpeg aha flite alsa-utils alsa-utils mono-devel \
locales \
&& apt-get clean \
&& locale-gen en_US en_US.UTF-8 pl_PL pl_PL.UTF-8 \
&& dpkg-reconfigure locales \
&& useradd -ms /bin/bash homeseer \
&& usermod -aG dialout homeseer \
&& ln -snf /usr/share/zoneinfo/Australia/Melbourne /etc/localtime \
&& echo Australia/Melbourne > /etc/timezone \
&& touch /DO_INSTALL

ADD https://github.com/just-containers/s6-overlay/releases/download/${S6_VERSION
}/s6-overlay-amd64.tar.gz /tmp/
RUN tar xzf /tmp/s6-overlay-amd64.tar.gz -C / \
&& tar -xzf /tmp/s6-overlay-amd64.tar.gz -C /usr ./bin \
&& rm -rf /tmp/* /var/tmp/*

COPY rootfs /

ARG AVAHI
RUN [ "${AVAHI:-1}" = "1" ] || (echo "Removing Avahi" && rm -rf /etc/services.d/
avahi /etc/services.d/dbus)

VOLUME [ "/HomeSeer" ]
EXPOSE 80 8888 10200 10300 10401 11000

USER homeseer
WORKDIR /HomeSeer
CMD /usr/bin/mono ./HSConsole.exe --log

[wpiman]

Thanks! I’ll take a look at mac vlans in the AM. But what you did makes sense.

[wpiman]

So I made quite a bit of progress on this front. I already had the libraries you have set up. I setup the container to do an ipvlan which does a L3 forwarding and setup the container on that subnet.

I then had to set up a route so the container could see the host machine as I have lots of other things running on the same machine (homebridge.mqtt.etc)

I was able to get the other plugins to work, but this one didn't find ANY chromecasts. Interesting I bought the GoogleCast plugin and it found the other Google Homes no issue.

Maybe the discover process runs on Level 2. I'll try moving to macvlan.

[wpiman]

Ok- figured out my problem!!!!! Kind of asoteric... but for anyone else who runs into a similar problem Ill post it here...

If you are running a Linux server under esx or another hypervisor, you need to allow promiscuous mode to be set on your hosts virtual switch. (ESXi Networking- vswitch- edit- security- enable promiscuous mode). MACVLAN won't run without it-- IPVLAN will.

Once I switch our IPVLAN for MACVLAN, the Chromecasts showed up! I bought the other plugin but I was running into some issues with the Speaker groups. Hopefully this fixes those announcement issues.