Google Chromecast Google Mini disconnect (?) problem

Add-ons Bindings
1

Maybe some of you dealed with such problem. My all Google Home Minis after some time throw:

2019-04-06 09:23:39.942 [WARN ] [su.litvak.chromecast.api.v2.Channel ] - Got IOException while reading due to stream being closed (stop=true)
2019-04-06 09:23:41.099 [WARN ] [su.litvak.chromecast.api.v2.Channel ] - Error while reading
su.litvak.chromecast.api.v2.ChromeCastException: Remote socket closed
        at su.litvak.chromecast.api.v2.Channel.read(Channel.java:425) ~[259:org.openhab.binding.chromecast:2.4.0]
        at su.litvak.chromecast.api.v2.Channel.access$200(Channel.java:51) ~[259:org.openhab.binding.chromecast:2.4.0]
        at su.litvak.chromecast.api.v2.Channel$ReadThread.run(Channel.java:137) [259:org.openhab.binding.chromecast:2.4.0]
2019-04-06 09:23:41.100 [WARN ] [su.litvak.chromecast.api.v2.Channel ] -  <--  null payload in message

This results in status change to OFFLINE. They do not disconnect at the same time, but as they are in one speaker group (that is set as default for TTS in OpenHAB), when one of them turns offline, this causes that entire group have the same OFFLINE status (meybe thats because IP of that group is set to specific IP, IP of one of the speakers, and maybe problem occures when that specyfic speeaker is going offline…). Moreover when speaker get back to ONLINE (usually it does) group don’t. Why? When I look into PapuerUI (after all of above) IP of that group is now set to IP of different of my speakers. It omehow automaticly switched to another in group (i don’t know is the port changing too). Maybe this second speaker is not prepared to “host” entire group.

Maybe here is the reason of that strange behavior? Maybe the solution is to define groups manually - but how?

The result of all of this in a final is that periodically my system messages are not read on speakers.

Speakers are defined from PaperUI, from Chromecast autodetect.
Speaker groups are defined in PaperUI and autodetect too.

2

I’ve corrected OH configuration and defined them (speaker and groups) rigidly in files (including all IP addresses and ports).

Due to the fact that I could not find anywhere information on which ports Google Home Mini speakers expect connections from other group members, I used ports that were in my auto-sensing configuration (speakers and groups added automaticly from autoseach in binding).

We will see…

3

Did this solve your problem, or did the errors return? I’ve noted the same, but haven’t concerned myself with fixing them until now.

4

Disconnect still occur, but after my speakers re-connect (when my all configuration is in files now) the IP address of group doesn’t change now between IP’s of speakers contained in this particular group. So my “main groups” is always set to IP of my “main speaker” which have battery case on it. Same thing with ports. Now when ports are defined in files there are no “connection refused” errors.