Agreed. I should have checked the logs beforehand.
Maybe itās the media player and not google tts. Have you tried a different media player (preferably from a different platform)? What integration is your media player from?
Negative. Seems to be not-working with multiple (google) media players. tts.google_translate_say works, but tts.google_cloud_say is not working
Here is a few more details"
RuntimeError: Unexpected error while running ffmpeg with arguments: ['ffmpeg', '-y', '-f', 'LINEAR16', '-i', 'pipe:', '-f', 'mp3', '-q:a', '0', '/tmp/tmp6orqju_v.mp3'].See log for details.
You can create template switches of your own to replace the deprecated integration switches.
If you rename and disable the integration switches, you can even give your replacement template switches the same names and entity_idās, meaning nothing has to change in your scripts and automations.
It took me 10 minutes to do this with about 15 switches, all done in yaml - youāve got 6 months yet, so plenty of time.
Huh. The media player I tested with is a google nest hub, and itās working fine. Have you tried play other media on the same media players?
Can you posted the entire error from your log? I didnāt find anything searching for the error you posted. We cross posted.
Wonder if has something to do with this.
Just add template switches that share teh same name as the old switches and be done with it. The ammount of effort youāre putting into these posts outweighs the effort fixing your solution. Hereās an example:
switch:
- platform: template
switches:
roku:
friendly_name: Roku
value_template: "{{ is_state_attr('remote.living_room', 'current_activity', 'Roku') }}"
turn_on:
- service: remote.turn_on
target:
entity_id: remote.living_room
data:
activity: Roku
turn_on:
- service: remote.turn_on
target:
entity_id: remote.living_room
data:
activity: PowerOff
Add as many activities as you want. Make the slug (in this case roku:
) equal to whatever the switches used to be named if they were switch.roku
.
Nothing else to change.
And before you get all mad at me and question me 9093424 times about why the change was made: I donāt know. Just adapt and move on, Iām just here to provide this info.
Yeah, that seems like the easiest option and will probably do exactly that thanks.
Just ranting really, after lots of what seem like unnecessary changes just getting a bit fed up with it having to come up with different ways to do the same thing with no real technical answers as to why
I bypassed the issue by removing āencoding: linear16ā from my configuration file! Seems like the default encoding format is mp3. Unsure why I was using the linear16 configuration, but hopefully this fixes other peopleās errors!
Not sure I understand this comment or the attitude implied in it, as far as I was aware I have made 3 post in the last day that are portraying my thoughts on recent HA changes. I will and can fix my issues and am 99% of the time able to do this without having to ask how, but does that in some way mean that I canāt have my option on recent changes or more to the point am I not allowed to voice it here?
Why would I get mad at you exactly, I donāt recall actually asking you anything at all, let alone bombarding you with questions like you have all the answers.
Like you say you do t know, so you offer a solution in one hand and then with the other hand take the opportunity to make snarky comments, you could have simply scrolled past my comments, but I guess the fact I have made 3 posts in a thread that would have currently equaled approx 400 posts before it was split it has clearly grated on you in some way.
I think 2024 should be the year of the user. Before a change is made, proper consideration should be made to the (ever increasing) user base. Developers always always are the worst judges of what changes should be made (Iāve been one, I know). Backward compatibiliry HAS to be one of the most important considerations for any change. Unless thereās a really really good reason, users must be able to have a before change option (and this thread has demonstrated that there is no such reason for any of the changes in this release). This consideration will also mean changes will be harder, and rightly so - how do you make a change while keeping that backward compatibility!
And frankly this ridiculous monthly release cycle should be stopped, 6 months is more than enough. It would give time for robust testing and proper feedback with changes dropped after proper beta testing. Every month weāre terrified that a new release will screw things up for us. Only essential security updates should be more frequent.
If you want a slow release cycle, go to openhab.
And be verrrrry patient.
Iām inclined to disagree. Since HA is evolving so fast six months of changes would be a too great challenge. Have you read the detailed release notes for each release? This would create a huge crowd of angry users.
The devs have already found that 2 months of changes resulted in a release that they couldnāt build on GitHub - it was too big. What 6 months of changes would be likeā¦
I donāt get how trusted networks function. My home range is 192.168.1.x. I get that, but when Iām in a hotel of somewere on somebody elses wifi the is a big chance that I get a ip address in the same range.
That can be on the other side of the world. What is so trusted about that?
People already complain that their requests take too long to implement, imagine if the release cycle was 6 months. The way I see it there are a few ways to approach this.
- read the release notes
- be patient
- contribute to the code base on github
- switch to another system
- Ask for your money back (oh wait itās free)
I appreciate some of what you are saying. I feel that some changes are made without really vetting the process. Since Ping has been bashed so hard in this topic, itās a good example of where the new system that removes it from YAML would have been better if all the previous capabilities came with it.
Now donāt harp on me about Ping, Iām quite neutral, I didnāt use Ping the way others have - for me it was a straight up Ping and I wasnāt impacted at all with it being moved out of YAML.
Iām just saying that there have been a lot of big changes to established systems this year that have sent people into a tailspin. I know there is still fallout from the weather forecasts, and even I havenāt really migrated yet because I have so much tied to it.
This isnāt to say Iām going post my ābig goodbyeā to HA, I still think itās an amazing system, but I think there are instances where - especially with UI/UX changes - you could make sure you offer a way back (without downgrading) through added templating or even a checkbox that says āuse old versionā and this could be applied to some other aspects of HA thatās been rolled out recently.
For me, I used to update every time there was one out there because they were always solid and always useful. Now, like I do with most software, I wait until mid month and at least a few patches because I would estimate that 30-40% of the time the .0 release has caused a lot of problems for me. Now whether thatās because my system has matured to a point that changes cause issues or that the changes are themselves issues Iāll be fair and say it could go either way. I just feel like I have to babysit HA a lot more now than two years ago.
The forum update really wasnāt a fun one for me, I donāt like what was taken away. I get that there was likely a strong underlying reason to update but it just sort of added to the whole āhere we go again with HAā. And I learned from that experience there really isnāt much point to bitching about this stuff, itās never going to be changed as a result of heated forum posts - once changed then, as we used to say in the military: adapt and overcome.
Completely disagree. Just look at the forum posts about just two changes. Can you imagine the uroar that six months of changes and updates would produce.
You donāt have to update.
Firstly, a more considered release cycle with longer alpha and beta testing would shake out a lot of such issues. I read the release notes of every issue but Iād completely missed the impending pingeddon! I donāt take part in the beta programme because I only have a production environment and the idea of my system going t!ts up every month is too frightening. A six monthly cycle would make me think twice.
Secondly, the idea you donāt have to upgrade is unrealistic. Take the example of integrations, if the target of the integration changes, you have no choice but to upgrade to maintain compatibility.
Surely the long term aim for HA is to have a system that upgrades seamlessly without the user noticing it. Iāve never known my Nest thermostat have an upgrade but I know it has. (Also, how do Microsoft, Apple etc manage so much bigger systems with slower upgrade cycles?)
Donāt get me wrong, I love HA but I feel thereās a danger itās going to become a geeky outlier. The danger there is it loses mass support and influence. P!ssing off users is the fastest way to getting there!
Any synology virtual machine owners not able to update like myself Out there?
23-12-08 15:28:55 ERROR (MainThread) [supervisor.homeassistant.core] Home Assistant has crashed!
23-12-08 15:28:55 CRITICAL (MainThread) [supervisor.homeassistant.core] HomeAssistant update failed -> rollback!
23-12-08 15:28:55 INFO (MainThread) [supervisor.resolution.module] Create new issue update_rollback - core / None
23-12-08 15:28:55 INFO (MainThread) [supervisor.homeassistant.core] A backup of the logfile is stored in /config/home-assistant-rollback.log
23-12-08 15:28:55 INFO (MainThread) [supervisor.homeassistant.core] Updating Home Assistant to version 2023.11.3
23-12-08 15:28:55 INFO (MainThread) [supervisor.docker.interface] Updating image ghcr.io/home-assistant/qemux86-64-homeassistant:2023.12.0 to ghcr.io/home-assistant/qemux86-64-homeassistant:2023.11.3
23-12-08 15:28:55 INFO (MainThread) [supervisor.docker.interface] Downloading docker image ghcr.io/home-assistant/qemux86-64-homeassistant with tag 2023.11.3.
Looks like issue opened here. https://github.com/home-assistant/core/issues/105254