It’s a bit difficult to pin down exact nature of the new problems with Google Assistant automation routines running on Sonos speakers that I reported earlier, but I’ve made some progress. It’s complicated by the fact that Google Home is in a state of flux at the moment as Google is making extensive changes that have introduced a lot of new bugs. No help from either Google or Sonos on this of course.
The main item is this: now when a Google Assistant routine runs on Sonos and executes a custom command or query action that generates spoken output, it causes the routine to abort after completing the action.
For example, you can have a routine with a series of actions to make device settings, or to tell you the time, the date. the weather, your schedule for the day, etc., and the routine will run just fine as long as they are standard actions or queries selected from the menu of the new automation editor. But if you insert in there a custom Google Assistant query or command not on the menu that produces audio output, such as “What is the inside temperature?”, the routine will abort after executing that command. I am guessing that it is the fact that it produces spoken output on the Sonos speaker that is responsible, since some time ago Google Assistant on Sonos stopped being able to produce spoken text in routines using the GA command “Say (something)”. In my case the new bug was first triggered by my existing routine having the custom action “Activate (name of scene)”. This was formerly handled silently, but suddenly began generating the response “Ok, activating (name of scene)” on Sonos only, thus causing the rest of the routine to abort.
Possible workarounds:
There are now some new menu actions in the Google Home automation routine editor to execute actions that formerly required a custom Google Assistant command. For example you can now activate a Scene using a menu action instead of the custom command “Activate (name of scene)”. These menu actions do not abort the routine.
If you must have a custom command that might generate spoken output, try moving it to the last command in the routine, where the fact that it aborts the routine won’t matter.
