core: Google Cloud TTS integration failing to load in 0.115
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
arch | armv7 dev | false docker | true hassio | false installation_type | Home Assistant Container os_name | Linux os_version | 5.4.51-v7l+ python_version | 3.8.5 timezone | America/Chicago version | 0.115.0b11 virtualenv | false
- 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
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Reactions: 3
- Comments: 79 (10 by maintainers)
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?
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 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:
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!
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.
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
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,
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.
@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?
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.