Core: Google Cloud TTS integration failing to load in 0.115

Created on 16 Sep 2020 · 79Comments · Source: home-assistant/core

The problem

I've used the Google Could TTS integration for all my TTS needs for a few months now without issue. I recently switched to 0.115 beta and did not notice any issues with this integration (that I recall). However, the integration now fails to load at startup, each time reporting the same error in the logs. The google_cloud_say service also fails, even though I can reach my google homes through a change volume service call, for example.

Environment

I'm running Home Assistant Container in Docker on Raspberry Pi OS

Home Assistant Core release with the issue: 0.115.0b3 to 0.115.0b5 maybe? Not 100% sure when it popped up
Last working Home Assistant Core release (if known): 0.115.0b1 maybe? I'm pretty sure it was working in the initial 0.115 release.
Operating environment (OS/Container/Supervised/Core): Container in Docker on Raspberry PI OS, RPI4b 4GB
Integration causing this issue: Google Cloud TTS
Link to integration documentation on our website: https://www.home-assistant.io/integrations/google_cloud/

Problem-relevant `configuration.yaml`

tts:
  - platform: google_cloud
    key_file: googlecloud.json

Traceback/Error logs

Logger: homeassistant.config
Source: components/google_cloud/tts.py:7
First occurred: 11:01:33 AM (1 occurrences)
Last logged: 11:01:33 AM

Platform error: tts
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/config.py", line 815, in async_process_component_config
    platform = p_integration.get_platform(domain)
  File "/usr/src/homeassistant/homeassistant/loader.py", line 401, in get_platform
    cache[full_name] = importlib.import_module(
  File "/usr/local/lib/python3.8/importlib/__init__.py", line 127, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 1014, in _gcd_import
  File "<frozen importlib._bootstrap>", line 991, in _find_and_load
  File "<frozen importlib._bootstrap>", line 975, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 671, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 783, in exec_module
  File "<frozen importlib._bootstrap>", line 219, in _call_with_frames_removed
  File "/usr/src/homeassistant/homeassistant/components/google_cloud/tts.py", line 7, in <module>
    from google.cloud import texttospeech
  File "/usr/local/lib/python3.8/site-packages/google/cloud/texttospeech.py", line 19, in <module>
    from google.cloud.texttospeech_v1 import TextToSpeechClient
  File "/usr/local/lib/python3.8/site-packages/google/cloud/texttospeech_v1/__init__.py", line 21, in <module>
    from google.cloud.texttospeech_v1.gapic import text_to_speech_client
  File "/usr/local/lib/python3.8/site-packages/google/cloud/texttospeech_v1/gapic/text_to_speech_client.py", line 22, in <module>
    import google.api_core.gapic_v1.client_info
  File "/usr/local/lib/python3.8/site-packages/google/api_core/gapic_v1/__init__.py", line 18, in <module>
    from google.api_core.gapic_v1 import config
  File "/usr/local/lib/python3.8/site-packages/google/api_core/gapic_v1/config.py", line 23, in <module>
    import grpc
  File "/usr/local/lib/python3.8/site-packages/grpc/__init__.py", line 23, in <module>
    from grpc._cython import cygrpc as _cygrpc
ImportError: Error relocating /usr/local/lib/python3.8/site-packages/grpc/_cython/cygrpc.cpython-38-arm-linux-gnueabihf.so: backtrace: symbol not found

Additional information

I'm in over my head here, but googling led me to a few other examples of this issue:
https://github.com/zeromq/pyzmq/issues/1323
https://github.com/grpc/grpc/issues/6126

google_cloud

Source

andynbaker

👍3

Most helpful comment

Every community has rules. One is that you don't @ in random developers. Maybe you didn't previously know that, you do now.

As I have stated on this issue there is a code owner. He has responded to this issue (albeit not particularly helpfully, as he doesn't have time).

The error seems to be a compilation error 2 packages upstream from this integration.

Finding the code owner is trivial. Look at the manifest.json file in the integration's folder. The documentation has the link to each integration's source code which takes you to the folder on github with the manifest.json file.

Now you might not think you come across as entitled or rude or disparaging, but that is the way you are perceived by others - perhaps you should think about how others are perceiving what you are saying.

All good things take time and 0.115 was a big release. Breakage is expected. What is not expected is a commercial paid support response, nor are code owners expected to have a 24/7 commitment to HA. People have lives.

I'm not sure who I randomly mentioned in this post. I only tagged the code owner and the one other person who made major contributions to this integration. That was a well thought out, searched through the history of edits on github and into the manifest file to find these two users, not random at all. Why is asking for help on this platform such a crime?

makingwilliam on 27 Sep 2020

👍2 👎1

All 79 comments

I just pulled down 0.115b1 and do not see the issue anymore. Just tested with a service call to be sure and can in fact cast a google cloud tts call to my google home minis. So i know for sure the issue was not in 0.115b1.

andynbaker on 16 Sep 2020

me too 114 work nomal , 115 beta i check config google cloud error

Platform error tts.google_cloud - Error relocating /usr/local/lib/python3.8/site-packages/grpc/_cython/cygrpc.cpython-38-arm-linux-gnueabihf.so: backtrace: symbol not found

fancy90 on 17 Sep 2020

I just updated to the birthday release: 0.115.0 and struggling now with the very same exception. The mentioned exception shows up on startup in the log-file and every time I hit the "check configuration" button.

pavax on 17 Sep 2020

Same issue on my end. Running in a docker container in Pi4

wtreur on 18 Sep 2020

I'm having the same issue. Throws this error after clicking the config check button. Was not happening on 0.114.*

user897943 on 18 Sep 2020

Same issue here, 0.114 was ok, showed up in 0.115

alastaid on 18 Sep 2020

Same

artbrayko on 19 Sep 2020

Just finished updating my container to 0.115.2, no longer seeing this issue. Thanks to the developer who fixed it 👍

Spoke too soon, while the error may have gone, I have now lost my tts.google_cloud voice.... ugh 🙄 this is why I didn't get my automation playing that it was time to feed the fish today on my speakers, and I ended up forgetting until much later. 🐟🐠 are not happy 😪

Clicked the configuration check button, still getting the error. Sorry for posting this y'all. Should've tested it more.

Platform error tts.google_cloud - Error relocating /usr/local/lib/python3.8/site-packages/grpc/_cython/cygrpc.cpython-38-arm-linux-gnueabihf.so: backtrace: symbol not found

user897943 on 20 Sep 2020

👍2

115.2 doesnt fix it for me either, I would have thought there would be a lot of people using google TTS, hence this would be getting a lot more focus, which makes me wonder if I just need to change my yaml entry somehow, going back to the docs....

alastaid on 20 Sep 2020

Same issue for me.

rosenbaek on 20 Sep 2020

And me...

dr3men on 20 Sep 2020

I can also confirm I have the same error when checking the configuration.
I had to disable the integration (commented out).

Mincka on 20 Sep 2020

I fired up a copy of HA on HA OS and do not see the issue. Only when running in container do I see it.

Edit: this is on the 5.2 dev build of HA OS

andynbaker on 20 Sep 2020

That's not true, I am using Home Assistant on HassOS under the current Hass.io build and have been experiencing the same problem.

The problem

Google Cloud TTS is not loading and/or cannot be enabled after upgrading to 0.115.1 and after updating to 0.115.2 and 0.115.3.

Environment

Home Assistant Core release with the issue: 0.115.2
Last working Home Assistant Core release (if known): 0.114.x
Integration causing this issue: Google Cloud Platform
Link to integration documentation on our website: https://www.home-assistant.io/integrations/google_cloud/
Operating environment (OS/Container/Supervised/Core): HassOS 4.13 / 245 / 4.19.127-v7

Problem-relevant `configuration.yaml`

tts:
  - platform: google_cloud
    key_file: google_cloud.json
    voice: en-GB-Wavenet-B
    time_memory: 43200

Traceback/Error logs

When checking configuration after enabling integration through YAML config, the following error is displayed:

Platform error tts.google_cloud - Error relocating /usr/local/lib/python3.8/site-packages/grpc/_cython/cygrpc.cpython-38-arm-linux-gnueabihf.so: backtrace: symbol not found

Only found the following in my logs:

2020-09-20 08:29:45 INFO (SyncWorker_37) [homeassistant.loader] Loaded google_cloud from homeassistant.components.google_cloud
2020-09-20 08:29:45 INFO (SyncWorker_37) [homeassistant.loader] Loaded google_cloud from homeassistant.components.google_cloud

Additional information

makingwilliam on 20 Sep 2020

Ahh my apologies, I'm running the dev branch of HA OS (5.2). So I correct my statement, I do not see the error on HAOS 5.2

andynbaker on 20 Sep 2020

Updated to HassOS 5.2 (from HassOS 4.13) and the problem is still there. Seems unrelated.

Mincka on 20 Sep 2020

To be sure it is indeed now working for me, I just called the service from developer tools. The message came through fine using my usual cloud voice profile. The only change on my end was going from Container to Home Assistant OS 5.2. If it helps, I'm booting from an SSD, so my eeprom had been updated. But I was booting from an SSD on container so I'm not sure that's the special sauce.

So as of now, I'm on 5.2, running 0.115.2, have no more TTS issues in my logs, and can successfully make a TTS service call where I couldn't before.

andynbaker on 20 Sep 2020

Could it be related to https://github.com/home-assistant/core/pull/39893 ?

Mincka on 20 Sep 2020

To be sure it is indeed now working for me, I just called the service from developer tools. The message came through fine using my usual cloud voice profile. The only change on my end was going from Container to Home Assistant OS 5.2. If it helps, I'm booting from an SSD, so my eeprom had been updated. But I was booting from an SSD on container so I'm not sure that's the special sauce.

So as of now, I'm on 5.2, running 0.115.2, have no more TTS issues in my logs, and can successfully make a TTS service call where I couldn't before.

I run the container on a Pi4, SSD, the Pi is up to date. Latest everything including the bootloader. I don't think that's it.

user897943 on 20 Sep 2020

Related issue (current version): https://github.com/home-assistant/core/issues/40266
Already happened in the past (no answers): https://github.com/home-assistant/core/issues/27343

Mincka on 20 Sep 2020

Is there a code owner for this integration? I noticed that the issue hasn't been assigned to anyone yet, but it is affecting multiple people.

makingwilliam on 20 Sep 2020

I am having the same issue.

Noahma3 on 21 Sep 2020

This bug seems to be Raspberry OS/Arm related. Google TTS still works on x86/Ubuntu/Docker

harsanyi76 on 21 Sep 2020

Same problem here!

caiocaminoski on 21 Sep 2020

Updated to HassOS 5.2 (from HassOS 4.13) and the problem is still there. Seems unrelated.

arch armv7l
chassis embedded
dev false
docker true
docker_version 19.03.11
hassio true
host_os HassOS 5.2
installation_type Home Assistant OS
os_name Linux
os_version 4.19.127-v7l
python_version 3.8.5
supervisor 245
timezone Europe/Paris
version 0.115.2
virtualenv false

I see everyone with this issue on HaasOS is running the 32bit version of either 4.19 or 5.2. I'm no longer seeing the issue after upgrading to the 64bit version of HaasOS 5.2. This seems like the most glaring difference between my install and others?

andynbaker on 21 Sep 2020

@Mincka looking at https://github.com/home-assistant/core/issues/40266 it does look relevant, especially as it looks like the issue is 32bit. I am new to github projects, what is protocol here do we add in the developer on that PR to this thread and see if we can get him to look at it and get it moving, I have spent a ton of time on my Google TTS automations and am missing them.

alastaid on 23 Sep 2020

I think you meant #39893. I saw that the author was in holiday on Twitter so we may not @ him and leave him enjoy his vacation while we are patient. :smile: Personally, I just fell back to the basic TTS (Google Translate). The voice is not as good as Google Cloud TTS but it does the job. I think it's a reasonable workaround.

Mincka on 23 Sep 2020

Thanks for the guidance, I must confess I didn't realise I can fall back to Google Translate, that will be fine for me and I can wait till its fixed.

alastaid on 23 Sep 2020

The same issue is also affecting other Google components like the PubSub. I don't think there is an workaround for that so I would say that this needs to be fix as soon as possible.

mariwing on 23 Sep 2020

Does anyone else with a Pi4 have an appetite for trying out the 64bit dev version to verify the issues are gone in that build?

andynbaker on 23 Sep 2020

Sure. I don’t mind giving it a go. Which container/tag should I use?

wtreur on 23 Sep 2020

Sure. I don’t mind giving it a go. Which container/tag should I use?

I saw the bug beginning somewhere around 0.115.b4 or so, running Container in Docker on 32 bit Raspberry Pi OS on a Pi4. I switched to the 64bit dev build 5.2 of Home Assistant OS on the same Pi4 and no longer see the issue (I currently get TTS messages cast over my google home minis, no problem).

So in my mind there are at least two things worth trying: 1) do the same as me and load up a 64 bit 5.2 dev build of Home Assistant OS, or 2) maybe try loading up some other 64 bit OS of your choosing and see if the stable build of Home Assistant Container 0.115 no longer shows the issue.

andynbaker on 23 Sep 2020

In my case, I've changed encoding setting from linear16 to mp3 or ogg_opus and then it works now. my version is 0.115.2.

geochilmaru on 25 Sep 2020

In my case, I've changed encoding setting from linear16 to mp3 or ogg_opus and then it works now. my version is 0.115.2.

The encoding was not specified in my case so mp3 already. I tried the other settings, it did not work (= not able to check the configuration / reload the module). Did you have the same error message than the OP?

Mincka on 25 Sep 2020

In my case, I've changed encoding setting from linear16 to mp3 or ogg_opus and then it works now. my version is 0.115.2.

The encoding was not specified in my case so mp3 already. I tried the other settings, it did not work (= not able to check the configuration / reload the module). Did you have the same error message than the OP?

Sorry. It might not help you. I had a problem with google cloud tts but not the same issue. My problem is as follows.
It means what I did is just a temporary solution, then it is still not normal.

[homeassistant.components.websocket_api.http.connection.139898363333840] 'ko-KR-Wavenet-B' not a Frame instance
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/components/websocket_api/commands.py", line 137, in handle_call_service
await hass.services.async_call(
File "/usr/src/homeassistant/homeassistant/core.py", line 1315, in async_call
task.result()
File "/usr/src/homeassistant/homeassistant/core.py", line 1350, in _execute_service
await handler.func(service_call)
File "/usr/src/homeassistant/homeassistant/components/tts/__init__.py", line 167, in async_say_handle
url = await tts.async_get_url(
File "/usr/src/homeassistant/homeassistant/components/tts/__init__.py", line 340, in async_get_url
filename = await self.async_get_tts_audio(
File "/usr/src/homeassistant/homeassistant/components/tts/__init__.py", line 367, in async_get_tts_audio
data = self.write_tags(filename, data, provider, message, language, options)
File "/usr/src/homeassistant/homeassistant/components/tts/__init__.py", line 470, in write_tags
tts_file["artist"] = artist
File "/usr/local/lib/python3.8/site-packages/mutagen/_file.py", line 74, in __setitem__
self.tags[key] = value
File "/usr/local/lib/python3.8/site-packages/mutagen/id3/_tags.py", line 339, in __setitem__
raise TypeError("%r not a Frame instance" % tag)
TypeError: 'ko-KR-Wavenet-B' not a Frame instance

geochilmaru on 25 Sep 2020

Same issue after upgrading to 1.115.2 from 1.114

jacekpaszkowski on 25 Sep 2020

@geochilmaru: Ok, that's what I thought. Maybe you should create a specific issue with your workaround.

Mincka on 25 Sep 2020

@frenck @balloob 0.115.3 installed now, still having this issue, has nobody picked up on this really? It's affecting a ton of users as you can see here.

user897943 on 25 Sep 2020

0.115.3 not fix it yet so sad

fancy90 on 25 Sep 2020

Sure. I don’t mind giving it a go. Which container/tag should I use?

I saw the bug beginning somewhere around 0.115.b4 or so, running Container in Docker on 32 bit Raspberry Pi OS on a Pi4. I switched to the 64bit dev build 5.2 of Home Assistant OS on the same Pi4 and no longer see the issue (I currently get TTS messages cast over my google home minis, no problem).

So in my mind there are at least two things worth trying: 1) do the same as me and load up a 64 bit 5.2 dev build of Home Assistant OS, or 2) maybe try loading up some other 64 bit OS of your choosing and see if the stable build of Home Assistant Container 0.115 no longer shows the issue.

Oh, silly me. 🤦 I can't just simply run a another docker container on my existing OS to check a potentially 64bit related fix when I'm running a 32bit os.
I am afraid testing that is going to be hard for me then, since I only have one Pi4 and I am using it for more than just Home Assistant and I don't have a spare sd-card lying around.

wtreur on 25 Sep 2020

frenck balloob 0.115.3 installed now, still having this issue, has nobody picked up on this really? It's affecting a ton of users as you can see here.

Don't @ people for nothing. Fallback to basic TTS (Google Translate), be patient, reinstall on a 64-bit platform or help to find a solution.

Mincka on 25 Sep 2020

frenck balloob 0.115.3 installed now, still having this issue, has nobody picked up on this really? It's affecting a ton of users as you can see here.

Don't @ people for nothing. Fallback to basic TTS (Google Translate), be patient, reinstall on a 64-bit platform or help to find a solution.

I don't want to use basic TTS, I'm patient, I won't reinstall my entire system because of this just because you think so, I already posted a potential fix on another issue, and finally this is not "nothing", if it's nothing to you what are you doing here? Rhetorical question. Please lets not argue, nobody wins.

user897943 on 25 Sep 2020

😕1 👍1

I have to agree, this was all working before a MAJOR release was made and since that release, many, many users have been affected and reporting this issue. The issue has not been assigned to anyone, meaning there probably isn't a code owner. So it appears as if this integration has been abandoned. The whole purpose of running Hass.io on HassOS is to prevent these types of things from happening to the vast majority of users who are not advanced enough to complete the necessary troubleshooting or have the programming skills to make changes on their own to resolve the problem. That said, it would be nice for someone on the Home Assistant team to at least acknowledge this problem and give us some feedback on it or when a fix might be made or if this integration should be removed because it has been abandoned like the rest of the google/nest integrations which have been abandoned for over a year now.

It's sad to know that all these new important features that are always coming out undermine things that were already working with no problem and then when they become broken by these new features, no one can really spare the time to look at them. The go to answer is to just use another TTS or completely reinstall your system in a manner that you didn't initially intend. No, the answer should be do proper testing and when something new breaks something old, focus on how to repair what was already working and shouldn't have been impacted by the new feature(s) to begin with. And also, where is the undo button on an upgrade, or rollback button. That is what we desperately need, after upgrading when you don't like the way something is working, you can click one button and go back to your previous build with ease. Then you can wait for the problem to be resolved before upgrading again.

makingwilliam on 25 Sep 2020

❤1

Same problem(((

RestOp on 25 Sep 2020

Guys why don't you look: the code owner is in manifest.json.

nickrout on 25 Sep 2020

@nickrout the question still remains, why hasn't the bot assigned this to the code owner automatically as it normally would. That said, The code owner is listed as @shred86 though it appears @lufton has also authored the code. Not sure if either of you could take a look at this issue or not.

makingwilliam on 25 Sep 2020

And also, where is the undo button on an upgrade, or rollback button. That is what we desperately need, after upgrading when you don't like the way something is working, you can click one button and go back to your previous build with ease. Then you can wait for the problem to be resolved before upgrading again.

Downgrade / "rollback" is not so easy...

Use the snapshot feature and this add-on https://github.com/sabeechen/hassio-google-drive-backup if you want to go back to a previous version.

Also, where was you for the "proper testing" during the beta releases?

Mincka on 25 Sep 2020

I just encountered this issue as well after upgrading from 0.114.4 to 0.115.3 .

gannas42 on 25 Sep 2020

@nickrout the question still remains, why hasn't the bot assigned this to the code owner automatically as it normally would. That said, The code owner is listed as @shred86 though it appears @lufton has also authored the code. Not sure if either of you could take a look at this issue or not.

Everything I can tell is it looks like there is something wrong with python-texttospeech library witch is required by this integration and depends on grpc.
But I don't have enough time to investigate, I'm sorry.

lufton on 25 Sep 2020

Downgrade / "rollback" is not so easy...

Easy
sudo ha core update --version=0.114.4

RestOp on 25 Sep 2020

The code owner is listed as @shred86

No it isn't.

@lufton is there anything any of us can do to help? It looks like this is some sort of library problem in alpine builds on rpi 32? It wouldn't be the first time recently.

nickrout on 26 Sep 2020

@thewilliambond > No, the answer should be do proper testing and when something new breaks something old, focus on how to repair what was already working and shouldn't have been impacted by the new feature(s) to begin with

So we'll see you in the next round of beta testing helping out with the testing?

aidbish on 26 Sep 2020

👍1

@nickrout
i wonder if exporting the tts files and setting up as a custom integration will allow upgrading of dependencies to work out which requires changing. looking at the requirements for python-texttospeech, its 0.4.0 the latest release is up to 2.2 and lots of breaking changes when migrating to 2.0, maybe trying the last before 2.0 maybe worthwhile

aidbish on 26 Sep 2020

@nickrout
i wonder if exporting the tts files and setting up as a custom integration will allow upgrading of dependencies to work out which requires changing. looking at the requirements for python-texttospeech, its 0.4.0 the latest release is up to 2.2 and lots of breaking changes when migrating to 2.0, maybe trying the last before 2.0 maybe worthwhile

I think the problem is that there is no wheel for grcp (which is a dependency of python-texttospeech) so hassio has to build it, and that is failing on rpi 32.

I am guessing here, but grcp is a dependency of a dependency, so I am not sure if it is roped in to the home assistant wheel builds.

nickrout on 26 Sep 2020

@nickrout
grpc seems to be listed in the dependencies in wheels

i check the armv7 one and its listed. https://wheels.home-assistant.io/alpine-3.12/armv7/

aidbish on 26 Sep 2020

All I see is

grpc_google_iam_v1-0.11.4-py3-none-any.whl 09-Jul-2020 01:47 16130
grpcio-1.30.0-cp38-none-any.whl 09-Jul-2020 08:36 2502746
grpcio-1.31.0-cp38-none-any.whl 05-Aug-2020 21:06 2696523
grpcio-1.32.0-cp38-none-any.whl 13-Sep-2020 17:13 2107966

nickrout on 26 Sep 2020

i presumed the grpc_google_iam_v1-0.11.4-py3-none-any.whl 09-Jul-2020 01:47 16130 is the one

aidbish on 26 Sep 2020

I think we are looking for a package simply named grpc. (But I am nearing the limit of my knowledge)

nickrout on 26 Sep 2020

I can confirm that it's working fine using the 64-bit version of the appliance.
I just reinstalled my Raspberry Pi 4 with HassOS 4.13 64-bit.
It took me less than an hour with the snapshot restore of the system and everything is fine on this version.
I have Z-Wave + Zigbee (Deconz) + the Wyze bridge + Shelly and a few other things and no worries for the 64-bit version for these.
Of course, to be clear, there is no more error when checking the configuration and the Cloud TTS is working as before.

I think I will stick with the 64-bit version because I wanted to use the VSCode add-on for a while and I don't think I have a specific requirement to go back to the 32-bit version.

Mincka on 26 Sep 2020

@thewilliambond > No, the answer should be do proper testing and when something new breaks something old, focus on how to repair what was already working and shouldn't have been impacted by the new feature(s) to begin with

So we'll see you in the next round of beta testing helping out with the testing?

Sure, how do you signup for beta testing?

Edit: I joined the beta channel in the system section, if that is all that is required.

makingwilliam on 26 Sep 2020

All these salty comments telling users to beta test are pure garbage. The pure and simple truth is that Home Assistant is perpetually in beta when you consider that we are on a forum stating that there's an issue. I don't think anybody minds to wait for a maintainer to fix a problem, this is why we're here, nobody seem to be complaining we are simply making developers aware of the issue. We are in effect beta testing. People making these comments are just being petty and unprofessional.

user897943 on 26 Sep 2020

@thewilliambond > No, the answer should be do proper testing and when something new breaks something old, focus on how to repair what was already working and shouldn't have been impacted by the new feature(s) to begin with
So we'll see you in the next round of beta testing helping out with the testing?

Sure, how do you signup for beta testing?

There is an option in supervisor.

nickrout on 26 Sep 2020

All these salty comments telling users to beta test are pure garbage. The pure and simple truth is that Home Assistant is perpetually in beta when you consider that we are on a forum stating that there's an issue. I don't think anybody minds to wait for a maintainer to fix a problem, this is why we're here, nobody seem to be complaining we are simply making developers aware of the issue. We are in effect beta testing. People making these comments are just being petty and unprofessional.

No, whats garbage is people tagging folks to "make them aware" they are aware of the issue when you logged this request, then going to forums to tag again. then make disparaging comments about what people should work on like fix this instead of adding this. People give up their free time for this and seeing comments like these just seems like a kick to them. Remember people , free time, free software, you gain.

out of this one. hope its fixed in the future.

aidbish on 27 Sep 2020

👍1

I would like to say not one comment I have made has meant to be disparaging by any means. The fact of the matter is that this issue has never been assigned to anyone and when trying to address that and the fact that no one official has acknowledged this, the only other option for us is to reach out to someone on our own. And if we are at fault for that, then what in the world is community about this project? Every time I personally have tried to reach out to anyone from the HA team or community, I have been greeted with what is the normal response to things that no one really wants to address or give any time to. I've been told:

There must not be a code owner, that's why this issue was never assigned.
It's wrong to contact the code owner where there is an issue.
It's wrong to contact anyone related to the code, just sit and wait.
There are many other more important problems that need to be fixed before anyone will ever look at this.
Learn how to fix it yourself or deal with it.
Join the beta program, as if that would have stopped this from happening.
You don't need google_cloud_say just use the normal tts, it works fine.
Upgrade and reinstall your entire system.

Open source or not, this is not the way a community should embrace anyone who is trying to learn and seek help with a problem. Time and time again, some of the most important people in the HA team come off as shunning people and problems away, because they personally don't use a feature or integration, so why bother with it if it doesn't affect them. That is what is saddening and disheartening about issues like this. And in my instance, I don't believe for a minute that joining the beta program and voicing this issue earlier would have stopped or prevented anyone from sending out the birthday release just because of this issue. So I guess I'm just going to sit here in silence while anyone else who cares to chooses to ask the right questions to the right people, because apparently we've been going about this all the wrong way. I want so badly to finish learning all the necessary languages to be a contributor to this community, because I feel this community needs a little more heart to it at times. It's not fun feeling beneath of or less important because I don't have an HA badge of honor!

It would be nice if more people who face the public from the HA team appreciated that as this project grows, more and more people are using Home Assistant, and more and more of those people are not necessarily full-fledged programmers. By its very nature Home Assistant is designed to be adapted and customized to each individual user, regardless of skill-level, to be used in ways that may have never even been dreamed up by the many contributors who have offered their efforts. And if we are to continue to develop and expand upon these very possibilities with each and every new release there is; than as a community, we cannot and should not shun away one another for the way one feature or component may be used or affect that person individually in their configuration over another. Yes, things will happen and sometimes parts that were already working will fail; but when those times occur, there should be a standard precedent for how they are addressed and remedied to the majority of users who do not have the ability to remedy the problem on their own. This community needs to be more accepting that even a lesser used integration like this one, may be just as important if not more-so to one user as one of the most popular integrations is to a larger volume of users. And when something fails, abandonment and avoidance should not be at the top of anyone's list! No one should be criticized for asking for help ever!

makingwilliam on 27 Sep 2020

❤2

Every community has rules. One is that you don't @ in random developers. Maybe you didn't previously know that, you do now.

As I have stated on this issue there is a code owner. He has responded to this issue (albeit not particularly helpfully, as he doesn't have time).

The error seems to be a compilation error 2 packages upstream from this integration.

Finding the code owner is trivial. Look at the manifest.json file in the integration's folder. The documentation has the link to each integration's source code which takes you to the folder on github with the manifest.json file.

Now you might not think you come across as entitled or rude or disparaging, but that is the way you are perceived by others - perhaps you should think about how others are perceiving what you are saying.

All good things take time and 0.115 was a big release. Breakage is expected. What is not expected is a commercial paid support response, nor are code owners expected to have a 24/7 commitment to HA. People have lives.

nickrout on 27 Sep 2020

❤2 👎1

Not sure what help but I got it fixed for my case. :

(1) git checkout dev
(2) bump down the mutagen in tts
--- a/homeassistant/components/tts/manifest.json
+++ b/homeassistant/components/tts/manifest.json
- "requirements": ["mutagen==1.45.1"],
+ "requirements": ["mutagen==1.44.0"],

I think the bumping down mutagen's the key. I'll try to revert back to 0.115 and report here. Exciting to test out other features in 0.115. Cheers,

sjiampojamarn on 27 Sep 2020

👍1

Confirmed on 0.115.3, bumping down the mutagen to 1.44.0 solved the problem.

homeassistant/components/tts/manifest.json
"requirements": ["mutagen==1.44.0"]

Switching back to 1.45.1, error with:
"TypeError: 'en-US-Wavenet-F' not a Frame instance"

in my case.

sjiampojamarn on 27 Sep 2020

❤1

@sjiampojamarn : Can you confirm that you use the Google Cloud Platform integration and not the Text-to-Speech (TTS)? Your error message does not seem related to the one of others here. However, your TypeError references a GCP voice, that's why I am not sure. Can you share your platform: google_cloud configuration?

I understand that you tried this fix as a response to this recent PR #39166

Mincka on 27 Sep 2020

It's Google Cloud Platform for sure as I'm using 'en-US-Wavenet-F' : ) Here is my config:

tts:
  - platform: google_cloud
    key_file: **********
    language: en-US
    voice: en-US-Wavenet-F
    service_name: google_cloud_say
    encoding: linear16
    speed: 0.9
    # pitch: -2.5
    # gain: 5.0
    profiles:
      - medium-bluetooth-speaker-class-device

sjiampojamarn on 27 Sep 2020

Forgot to mention., I'm on virtual python env building up HA from github

source ./bin/activate
python3 -m pip install --upgrade ./home-assistant

run HA as a service in a linux box something like

source /home/***/homeassistant/bin/activate
hass &

sjiampojamarn on 27 Sep 2020

Your error message does not seem related to the one of others here.

@Mincka, you are right. I couldn't get the same error as the original post and others even after synced back to 0.115.0.

all's just complaining about
TypeError: 'en-US-Wavenet-F' not a Frame instance

Perhaps, there are two problems at the same time? Here's my system info

Can anyone with the original error message report the result after bumping down the mutagen to 1.44.0? any luck?

sjiampojamarn on 27 Sep 2020

Every community has rules. One is that you don't @ in random developers. Maybe you didn't previously know that, you do now.

As I have stated on this issue there is a code owner. He has responded to this issue (albeit not particularly helpfully, as he doesn't have time).

The error seems to be a compilation error 2 packages upstream from this integration.

Finding the code owner is trivial. Look at the manifest.json file in the integration's folder. The documentation has the link to each integration's source code which takes you to the folder on github with the manifest.json file.

Now you might not think you come across as entitled or rude or disparaging, but that is the way you are perceived by others - perhaps you should think about how others are perceiving what you are saying.

All good things take time and 0.115 was a big release. Breakage is expected. What is not expected is a commercial paid support response, nor are code owners expected to have a 24/7 commitment to HA. People have lives.

I perceive what you are saying as patronising, that's all I'm saying.

user897943 on 27 Sep 2020

👎1

All these salty comments telling users to beta test are pure garbage. The pure and simple truth is that Home Assistant is perpetually in beta when you consider that we are on a forum stating that there's an issue. I don't think anybody minds to wait for a maintainer to fix a problem, this is why we're here, nobody seem to be complaining we are simply making developers aware of the issue. We are in effect beta testing. People making these comments are just being petty and unprofessional.

No, whats garbage is people tagging folks to "make them aware" they are aware of the issue when you logged this request, then going to forums to tag again. then make disparaging comments about what people should work on like fix this instead of adding this. People give up their free time for this and seeing comments like these just seems like a kick to them. Remember people , free time, free software, you gain.

out of this one. hope its fixed in the future.

Oh you can read their minds to know they're aware? That's fantastic, you could be making millions as a psychic. Everyone knows that open source = free time. We are here to talk about the issue. Nobody has pointed any finger at any developer and assigned any blame. You are just one of "those people" that like to stir. No further responses to you I'll just add to the github blocklist, if you haven't got anything helpful to say about the issue, even if it's to add yourself to the growing list of affected users and your configuration, don't say anything at all? I'm pretty sure that's also another rule from online community forums, to not act like you did when users with less experience come here for help. Like it or not if something breaks because of running on 32 bit architecture it's not something that would've been fixed on a beta test anyway. It's just a cowardly way of telling someone to shut up about it. If that's how you think you should act on a community forum you don't belong here, everyone is welcome to post about the issues and yes I will call out trashy comments like "why didn't you beta test", it's totally irrelevant, anything in HA is a beta test, the product itself is not even 1.x release yet!!!!!!!!!!!! And that's great to be honest, we can just come here and raise issues any time because every second you're running HA you're running a beta version, Gmail has been on beta for 10+ years for example.

user897943 on 27 Sep 2020

👎1 👍1

Every community has rules. One is that you don't @ in random developers. Maybe you didn't previously know that, you do now.

As I have stated on this issue there is a code owner. He has responded to this issue (albeit not particularly helpfully, as he doesn't have time).

The error seems to be a compilation error 2 packages upstream from this integration.

Finding the code owner is trivial. Look at the manifest.json file in the integration's folder. The documentation has the link to each integration's source code which takes you to the folder on github with the manifest.json file.

Now you might not think you come across as entitled or rude or disparaging, but that is the way you are perceived by others - perhaps you should think about how others are perceiving what you are saying.

All good things take time and 0.115 was a big release. Breakage is expected. What is not expected is a commercial paid support response, nor are code owners expected to have a 24/7 commitment to HA. People have lives.

makingwilliam on 27 Sep 2020

👍2 👎1

Every community has rules. One is that you don't @ in random developers. Maybe you didn't previously know that, you do now.
As I have stated on this issue there is a code owner. He has responded to this issue (albeit not particularly helpfully, as he doesn't have time).
The error seems to be a compilation error 2 packages upstream from this integration.
Finding the code owner is trivial. Look at the manifest.json file in the integration's folder. The documentation has the link to each integration's source code which takes you to the folder on github with the manifest.json file.
Now you might not think you come across as entitled or rude or disparaging, but that is the way you are perceived by others - perhaps you should think about how others are perceiving what you are saying.
All good things take time and 0.115 was a big release. Breakage is expected. What is not expected is a commercial paid support response, nor are code owners expected to have a 24/7 commitment to HA. People have lives.

I'm not sure who I randomly mentioned in this post. I only tagged the code owner and the one other person who made major contributions to this integration. That was a well thought out, searched through the history of edits on github and into the manifest file to find these two users, not random at all. Why is asking for help on this platform such a crime?

My two cents: we are in a public forum contributing with feedback, don't allow anyone to silence you by making you feel unwelcome or that you have to act their way, if you have a valid concern and like you said, you even go as far as researching and presenting info, just do it. There will always be someone who's going to feel offended or feel that their way is the right one, unfortunately the world is full of people who feel their way is the only way, it's their problem if they choose to get triggered over nothing and their "rules" aren't the gospel. I'm sure that if there was a problem with anybody's comment someone with actual power will remove it or flag it up with you, I thought your contribution was very useful and thanks for adding to the issue.

user897943 on 27 Sep 2020

❤1 👎1

Your error message does not seem related to the one of others here.

@Mincka, you are right. I couldn't get the same error as the original post and others even after synced back to 0.115.0.

all's just complaining about
TypeError: 'en-US-Wavenet-F' not a Frame instance

Perhaps, there are two problems at the same time? Here's my system info

Can anyone with the original error message report the result after bumping down the mutagen to 1.44.0? any luck?

I have never performed the steps you are referring to before. I do have the Terminal add-on installed if that is all I really need, no direct access to the Pi, it is just connected to the network in a closet.

makingwilliam on 27 Sep 2020

Here's my system info

arch aarch64

Thanks for the confirmation. I see you are already on aarch64 and we confirmed that users (andynbaker and I) who are aarch64 are not affected by the main issue of this topic. I think your issue is related to something else. I didn't have to change anything to the mutagen build in my case. The update to aarch64 was enough to fix the issue.

My working setup after the upgrade.

arch | aarch64
chassis | embedded
dev | false
docker | true
docker_version | 19.03.11
hassio | true
host_os | HassOS 4.13
installation_type | Home Assistant OS
os_name | Linux
os_version | 4.19.127-v8
python_version | 3.8.5
supervisor | 245
timezone | Europe/Paris
version | 0.115.3
virtualenv | false

Mincka on 27 Sep 2020

Alright!

I've locked down the conversation on this issue to collaborators only.

Let me start with: I know what the root cause of the issue is, as I have worked with the part that is causing the issue of this release.

I wasn't aware of this issue, simply because I instantly muted this issue from my notifications. Why? Because I was randomly tagged (with multiple others). Which is sad, because I now missed this issue and the heavy discussion going on here.

I've have marked a lot of responses off-topic, as they didn't discuss the issue at hand. Please keep issues on topic, only comment if it adds value to the issue at hand.

If you are looking for a general conversation, please use the community forum or Discord chat.

Lastly, adding response with just "It is broken for me too", isn't adding value. Instead add a 👍 to the top issue description.

../Frenck

frenck on 27 Sep 2020

I've opened up #40678 to work around the issue for now.

frenck on 27 Sep 2020

Was this page helpful?

0 / 5 - 0 ratings

Related issues

media_player.universal not showing cover for child media_player.roku

ofuangka · 3Comments

Z-wave issues after upgrade 0.84.6 to 0.85.1

moskovskiy82 · 3Comments

"Incorrect HomeKit code" homekit_controller with aqara hub

flsabourin · 3Comments

Spotify source (Google Home) disappearing

Elmardus · 3Comments

Hassio component missing after upgrade to 0.90.0b4

TheZoker · 3Comments

Core: Google Cloud TTS integration failing to load in 0.115

The problem

Environment

Problem-relevant configuration.yaml

Traceback/Error logs

Additional information

Most helpful comment

All 79 comments

The problem

Environment

Problem-relevant configuration.yaml

Traceback/Error logs

Additional information

Related issues

Problem-relevant `configuration.yaml`

Problem-relevant `configuration.yaml`