Speaker Volume resets to 45% by itself? Help please!

Configuration
1

This has been driving me nuts for months.

I have several google home mini and Nest mini devices I use JUST for announcements using the TTS function.

They are set to 90-100% volume

They keep resetting to exactly 45%, mostly in the evening when doing a TTS announcement.

Can we try and work out a cause and solution.

Here are some facts to narrow it down:

  • devices have night mode disabled
  • people in a hubitat forum have the exact same issue
  • others report it also happens on other cast enabled devices (like lenovo)
  • I haven’t created any routines in hassio, or google home to do this
  • I created a routine in Google home to set it to 90% at 8am every morning just to try and undo the issue till a fix is found.
  • seems to reset to 45% if you use the TTS say function from sometime in the evening
  • the devices are used only for announcements and have microphone turned off
  • have them set in a group called Bullhorn and that is what I send the announcements to

Any ideas?

Is there a way to send volume commands in hassio?

This is an example of how I send announcements to them

action:
    - service: tts.google_translate_say
      entity_id: group.bullhorn
      data_template:
        message: 'System Initialisation.'
2

I have the same problem! Did you find a solution? (I read about your workaround “routine in Google home to set it to 90% at 8am every morning”)

For your information to set the volume you can create a scritp:

googlehome_set_volume:
  sequence:
    - service: media_player.volume_set
      data: 
        entity_id: media_player.googlehomeXXX
        volume_level: 0.5
3

I ended up just sticking a set the volume command in front of each say something command…

4

I’ve had the same problem for some time. But even sticking a volume-set command in front of each say-something command doesn’t work. Setting the volume once per day (like with a Google routine) is not adequate. I’ve taken to setting it hourly with a Node Red function.

1 Like
5

Oh that’s a good idea with the node red function. I do that too.
The volume set works about 90% of the time so hopefully the node red will make it 95% effective.
It is really annoying. One of the things I use it for is my doorbell. And when it goes to 45% I can’t hear it in most rooms of the house.

6

Setting the volume regularly doesn’t always help. It’s the Google component itself that sets the volume to 45% at random at the start of its output, so it may do that even though you set the volume higher just seconds earlier. There doesn’t seem to be any way to stop it - it’s a built-in bug.

1 Like
7

I might have found another solution because you’re right about the Google component randomly doing it to piss you off just seconds before you use the talk function… :face_with_symbols_over_mouth: Even with the node red routine it’s still getting me with this 45% BS

Try this.
I set the night mode that adjusts the speaker Volume down at night. (turning it off/ disable night mode doesn’t fix it)
So I set it to turn the speaker down to 70% for night mode between 11:55pm and 12:05am
Then it is set at 88% for the rest of the time.

I haven’t had it randomly set to 45% so far, but it’s only been a day, and that’s a small sample size for a “random” bug… Let’s see how it goes…

8

No good on the night mode, but it was worth trying.

9

I’ve found a workaround, clumsy but confirmed that it works after several days of testing.

You know how when you make an announcement on Google Home with play_media, it first makes a bleep sound? Unless it comes immediately after a previous announcement while the GH speaker is still active, in which case it doesn’t do the bleep, it just plays the audio.

I noticed that when I am playing my chiming clock sounds, the sequence is:
bleep - seems to be at 70% volume, as set
first chime - at 45% (volume has dropped!)
all remaining chimes and final time announcement - at 45%

From that I got the idea that whatever is setting the volume to 45% is happening during that initial connection that produces the bleep.

I therefore altered my sequence to:

  • Set GH volume to 10% (attempt to produce a very quiet bleep, if any)
  • play silent clip of 0.2 sec to activate the speaker
  • set GH volume to 70%
  • play my chiming sequence (speaker should already be active)
    (Not showing the delays of a couple of seconds in between commands to make sure they have time to be sent and processed)

This works!

By activating the GH with a brief silent clip a few seconds earlier and then setting the volume correctly immediately after, it is still active when I make my actual announcement. If the initial activation incorrectly sets the volume back to 45%, my sequence has a chance to restore 70% before the actual announcement.

1 Like
10

Can you please share the txt of your automation?

11

actually I got it working…

  action:
    - service: media_player.volume_set
      entity_id: group.bullhorn
      data:
        volume_level: 0.88
    - service: media_player.play_media
      entity_id: group.bullhorn
      data:
        media_content_id: http://192.168.3.230:8123/local/audio/silence.mp3
        media_content_type: "audio/mp3"
    - service: media_player.volume_set
      entity_id: group.bullhorn
      data:
        volume_level: 0.88
    - service: tts.google_translate_say
      entity_id:  group.bullhorn
      data_template:
        message: '{{ ["Ding-dong, ding-dong, . Ding-bloody-dong, . That''s how the doorbell goes. init. " , "Shhhhhh. . .  Be quiet everyone. . . . I think Jehovah''s Witnesses are ringing the doorbell" ]|random }}'

Now my question is, is there a way to make a sort of function or subroutine so I don’t have to cut and paste all that every time I want to do a TTS…

if I could put all this as a routine:
(*VOLUME FIX ROUTINE * )

    - service: media_player.volume_set
      entity_id: group.bullhorn
      data:
        volume_level: 0.88
    - service: media_player.play_media
      entity_id: group.bullhorn
      data:
        media_content_id: http://192.168.3.230:8123/local/audio/silence.mp3
        media_content_type: "audio/mp3"
    - service: media_player.volume_set
      entity_id: group.bullhorn
      data:
        volume_level: 0.88

and then just

  action:
   (* CALL VOLUME FIX ROUTINE * )
    - service: tts.google_translate_say
      entity_id:  group.bullhorn
      data_template:
        message: '{{ ["Ding-dong, ding-dong, . Ding-bloody-dong, . That''s how the doorbell goes. init. " , "Shhhhhh. . .  Be quiet everyone. . . . I think Jehovah''s Witnesses are ringing the doorbell" ]|random }}'

My coding skills are not up to scratch in this department…

12

Glad to hear that pre-playing a small silence clip works for you too.

My automation is in Node Red, so the code wouldn’t be the same, but the basic idea is pretty simple: play a small silent clip first to trigger the faulty volume reduction, then immediately after set the volume correctly, then play the actual output.

Unfortunately I don’t know any way to include a subroutine in HA automations, other than some complicated scheme of triggering a virtual device that runs another automation. Time to learn Node Red!

1 Like
13

Something else I just noticed, if you have the volume set high (like 88%) during the day it also automatically lowers it to 70% when you send a TTS or MP3 file to it.

I also noticed:
It changes the volume when you send a sound to it when its been “asleep” (not used for a while), and the sound is what “wakes” it. Sending a volume adjustment command to it does not “wake” it.
The reason this is important is the order you need to do things to fix it.

  1. Send a mp3 file of silence to it. (mine is 0.2 seconds long). This “wakes” the device. There is a good chance it will set its volume to 45% (at night) or 70% (during the day)

  2. Send a command to it to set the volume to what you want it to actually be

  3. THEN send your TTS or MP3 file you want people to hear and it should play at the volume you want. It will stay at the volume you just set it to in step 2 because its already “awake”

If you omit step 1, then it will change its volume to 45% or 70% just before it plays when you do step 3 because step 3 will be the one that “wakes” it

The other thing to note is that since google had its legal issues and removed the ability to change the volume of a group of google home/chromecast etc you can send a TTS/MP3 file to a single or group of devices, but have to send media_player.volume_set adjustments to the individual devices to get it to work reliably.
Thanks google for breaking something that worked because you’re too tight ass to pay royalties for technology you stole :roll_eyes:

Hope this helps!