Google Home mini and Google Nest Mini devices disappear after a while

[HectorHumanes]

Problem/Motivation

The Google Nest Mini device is discovered automatically when the aircast service is started and I'm able to send audio from multiple devices. It works correctly for some hours and suddenly it disappears for the AirPlay devices list and it doesn't get back until I restart the Aircast service.

Expected behavior

I expect the device to be automatically discovered and be available while executing the Aircast service.

Actual behavior

The device suddenly becomes unavailable.

Steps to reproduce

Tested with multiple google home devices, both 1st and 2nd generation: Connect the google home to wifi network while Aircast service is running. It quickly becomes available as "nameOfTheDevice+" speaker in AirPlay and you're able to play music on it. After a while (in terms of hours) it becomes unavailable and doesn't show again unless I restart the AirCast service. The restart starts the behaviour loop again.

Proposed changes

Workaround: Restarting the AirCast seems to do the trick... for some hours.

Additional info:

 Add-on: AirCast
 AirPlay capabilities for your Chromecast devices.
-----------------------------------------------------------
 Add-on version: 3.0.0
 You are running the latest version of this add-on.
 System: Ubuntu 20.04.2 LTS  (amd64 / intel-nuc)
 Home Assistant Core: 2021.1.5
 Home Assistant Supervisor: 2021.03.4
-----------------------------------------------------------
 Please, share the above information when looking for help
 or support in, e.g., GitHub, forums or the Discord chat.
-----------------------------------------------------------
[cont-init.d] 00-banner.sh: exited 0.
[cont-init.d] 01-log-level.sh: executing... 
[cont-init.d] 01-log-level.sh: exited 0.
[cont-init.d] aircast.sh: executing... 
[cont-init.d] aircast.sh: exited 0.
[cont-init.d] done.
[services.d] starting services
[services.d] done.
[16:33:17] INFO: Starting the AirCast server...
[16:33:17.699018] main:966 Starting aircast version: v0.2.43.1 (Jan 14 2021 @ 22:17:01)
[16:33:17.699725] Start:727 Binding to 192.168.1.52
[16:33:17.781838] AddCastDevice:664 [0xa470a0]: adding renderer (Habitación)
[02:11:08.685339] mDNSsearchCallback:535 [0xa470a0]: removing renderer (Habitación+) 176
[02:11:08.686678] DeleteCastDevice:512 [0xa470a0]: Cast device stopped
[02:11:45.289985] AddCastDevice:664 [0xa470a0]: adding renderer (Habitación)
[02:11:45.291668] mDNSsearchCallback:535 [0xa470a0]: removing renderer (Habitación+) 176
[02:11:45.293994] DeleteCastDevice:512 [0xa470a0]: Cast device stopped
[02:11:45.295082] AddCastDevice:664 [0xa470a0]: adding renderer (Habitación)
[02:11:45.295207] mDNSsearchCallback:535 [0xa470a0]: removing renderer (Habitación+) 176
[02:11:45.295700] DeleteCastDevice:512 [0xa470a0]: Cast device stopped
[12:00:01.113077] AddCastDevice:664 [0xa470a0]: adding renderer (Habitación)
[12:00:01.113765] mDNSsearchCallback:535 [0xa470a0]: removing renderer (Habitación+) 176

[cromulus]

I am experiencing the same issue. Latest Hassio, RP4.

[clowg]

I am experiencing the same issue.
I use a Chromecast Audio, and AirCast is running on Home Assistant OS 5.12, core-2021.3.4, supervisor-2021.03.6 - in a VM on Hyper-V.

[Mottemania]

Same for me: several Chromecast Audios, Google Minis (1st and 2nd) and the group i created within Google Home.

Home Assistant OS 5.12, supervisor-2021.03.6, core-2021.3.4 on a Raspberry Pi

[cromulus]

I can't seem to find any indication of the drop-off in the logs. It's likely an upstream issue with the upstream Airconnect

Perhaps bumping version to 0.2.50.4?

FWIW: I'm on a unifi network, with IMGP snooping, MDNS reflecion and repeaters turned on. My chrome casts are on the IOT network, and my home assistant is on the Standard network. They can ping and multicast is working across the network. there's no device isolation or firewall between them yet.

[github-actions[bot]]

There hasn't been any activity on this issue recently, so we clean up some of the older and inactive issues. Please make sure to update to the latest version and check if that solves the issue. Let us know if that works for you by leaving a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thanks!

[HectorHumanes]

NOT WORKING WORKAROUND

After some time trying to fix the issue without success I've found an automatic workaround I'd to share with you guys. As I said, it's just a workaround while waiting for the final solution (I'm widely open to test whatever you propose @cromulus). In the meanwhile:

1. Get the hostname of the Aircast Addon running in hassio. There are many different ways to do it, but the easiest one is checking it under Supervisor -> AirCast. Note you have to substitute the dash symbol (-) for a underscore symbol (_) in the name

2. Create a Long Term token. To do so, go to your profile page, go down and create a new long-term token.

3. Once we have this information, add this to configuration.yml

rest_command:
aircastrestart: url: http://**homeassistantIP**:8123/api/hassio/addons/**hostnameofyourAirCastAddonWith/restart method: POST headers: authorization: Bearer yourlongtermtoken** user-agent: 'HomeAssistant/1.0' content_type: 'application/json'

4. Create the following automation:

alias: Restart AirCast Addon description: Temporal fix of the AirCast Addon trigger:

• platform: time at: '04:00' condition: [] action:
• service: rest_command.aircast_restart mode: single

Then, every day at 4 am the AirCast addon will be restarted and the connection with the google home devices will be reset, being avalaible during the day without issues.

Any comment or improvement on this is more than welcome, so feel free to propose new solutions :)

[clowg]

Thanks for the workaround @HectorHumanes. What exactly should the configuration.yaml entry look like?
I get this error:

Invalid config for [rest_command]: invalid slug user-agent (try user_agent) for dictionary value @ data['rest_command']. Got OrderedDict([('aircast_restart', None), ('url', 'http://XXXX:8123/api/hassio/addons/XXXX-aircast/restart'), ('method', 'POST'), ('headers', None), ('authorization', 'Bearer XXXXX'), ('user-agent', 'HomeAssistant/1.0'), ('content_type', 'application/json')]).

[HectorHumanes]

You are supposed to change the 'XXXX' part with your own data.

I've carried out more test with my workaround and it's still failing, so there's no workaround at the moment. Still looking into last @cromulus comment trying to replicate the conditions. I'll keep you posted

[clowg]

Oh yeah, I did. I just replaced the private stuff with XXXX when I pasted the error in here. I'm not a deep HA fanatic, so I'm just not sure if I have the right syntax in the yaml file.

[HectorHumanes]

Finally I thing i've got the solution. I've disabled the aircast addon and tried AirConnect v0.2.53.1 running in Docker as a container (https://github.com/1activegeek/docker-airconnect). Since then, the connection with the google home has been running seamlessly for the whole weekend. So my guess is that something in the home assistant addon wrapper is causing the connectivity issues or there is anything fixed in the latest "official" version which is causing troubles in the home assistant version if it's not updated to latest version from the philippe44's repo.

@cromulus can you confirm your component is running the latest version of AirConnect?

[github-actions[bot]]

There hasn't been any activity on this issue recently, so we clean up some of the older and inactive issues. Please make sure to update to the latest version and check if that solves the issue. Let us know if that works for you by leaving a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thanks!