Routines now limited to 30 actions?

[Kaeris]

I wanted to add a few new actions to my default "Workday" routine in the Google Home app and encountered a message stating that there is a 30 action limit to routines. Is this temporary? If not, would I have this limitation if I ported all of my routines to the script editor?

Thanks for any help.

[TechNation7]

Yeah what's up with only 30 actions?

[Blyitgen]

Same problem here.

[Bethany07]

Same problem here. I rely on my routines heavily. This is frustrating 

[AJR2093]

And some routines with only a dozen actions are also being frozen to new actions being added with the message saying there is a limit of 30.:Looks like a major glitch  Pity their quality control is so poor.

[AJR2093]

Fix is to remove all actions and start again. This is really dodgy code from Google. Makes you question their QA process. Also undermines the value of their whole ecosystem.

[Mkhoury80]

Good luck doing this with the "Good Morning" or "Bedtime" routines... built-in, unable to be deleted, so any "phantom" actions referencing devices which may have been part of the routine once-upon-a-time and were later removed or replaced are basically stuck in these ones permanently... not about to delete my entire google home account and create a brand new one to band-aid fix code that they should have a competent developer on their end dealing with and fixing the right way.

[AJR2093]

If they supported routines running routines then you could nest sub routines and stay within the 30 limit but I’ve got 100 smart globes and other devices so a limit of 30 is very frustrating. The other enhancement would be to allow you to create your own device type for example lamps v ceiling lights v task lights. You could then create groups of device types within rooms. Even better if the device types could be nested…like lamps are a sub set of lights. Then, you can target more specific groups of devices in your routines.

[Mkhoury80]

Would be nice to hear a response on this, and soon, preferably just revert this terrible decision as it DRASTICALLY breaks home automation in a way that makes no sense, and yeah I have a broken morning routine (built in, can't delete and remake it to try to get around whatever is glitching it) with 22 actions that won't let me add more, previously had 24 and I thought it I deleted a few actions and saved it that would clear it up, now it's stuck at 22??? This is insanity.

I could understand it being limited to 30 if we were back in the 70's and the technology wasn't there yet because of something being stored with 1 byte instead of 2, but umm, it's 2023 guys, if anything we need to be moving FORWARD not BACKWARD with how much technology can do!

[Mkhoury80]

I'd like to add, from a developer point of view, that this is clearly being done to try to tackle what is almost certainly a load bearing issue, because at some point in Google home routines development they basically made it so that any "automate home device" actions in a routine all execute simultaneously / asynchronously, which is great from an end user perspective, but when each one of those is its own separate API call that can lead to overloading remote systems with a deluge of requests.

This change, which came unannounced, with no heads up, warning or apology, actually not only does NOTHING to address the underlying issue, and EVERYTHING to just totally piss off the entire consumer base using it, and seems to have been cooked up as a solution by either the most NOVICE dev who has ZERO experience dealing with multi-threaded apps, or by the most bone-headed technical manager in charge of the dev team.

1: Since this does NOTHING to existing routines, even those with 100+ actions, it makes ZERO immediate net impact on total load or throughput in the back end, which is either proof of sheer ignorance, or proof that the back end is actually fine and this limitation has no real need to exist whatsoever.

2: It breaks trust with existing users, who were used to it working a certain way, who now have less faith in the product.

3: It makes Google look like crap to new users, who may be wanting to switch from another platform like Alexa or something else, only to find Google is arbitrarily limited and incapable of doing what they need it to do.

IF this actually IS being done to try to alleviate a back end throughput issue, it both fails to accomplish that AND peeves the entire customer base, it is completely counter productive and should be reverted IMMEDIATELY.

IF there actually IS a need to reduce load from too many concurrent actions taking place the CORRECT way to fix this would be completely transparent to the end user, allowing them to continue adding an unlimited amount of actions to routines, but simply add background thread limiting and small delays in the back end, like limit it to say, 10 asynchronous actions at once, per ACCOUNT, put a join in place after said 10ish threads meaning they all have to come back as complete before then batching the next 10 actions and so on, perhaps with a subtle like say 100 millisecond sleep delay between each batch, so yeah, 100 actions would take 1 full second minimum to complete, but now the requests are somewhat "throttled" so as to not BOMBARD systems with requests all at once. This thread-throttling need only be put in one spot, wherever the actions actually get batched, and would affect all EXISTING routines, unlike the current terrible implemented "solution"

To the end user: Google home is the most amazing product offering automation "without limits"

To the back end of the server: the amount of data going through it drops dramatically, and load spikes become a thing of the past.

To the developer: it's a couple more lines of code in a different file, rather than this lazy not at all thought out 5 second "fix"

To the manager: it's a sigh of relief because they were able to get the actual problem fixed WITHOUT alienating the whole user base and making new people think that Google home is a crippled piece of garbage.

To anyone at Google reading this: I code in cold fusion and doubt I'd be able to write this fix myself in whatever language you guys are using, but the premise should be fairly clear cut.... In JavaScript it would be a matter of having 10 commands fed into one Ajax call which would then be set to then execute itself again only upon a complete response from the initial call, each time fetching the next 10 items from an array to feed back into itself again, until the array is empty. In cold fusion it would simply be cfthread in a loop with a Mod 10 eq 0 IF condition within which a cfjoin and cfset sleep command would be waiting at every 10th iteration.

Surely this can't be that much of a challenge for your developers ... this is seriously like a 5-10 lines of code solution and is "infinitely" better than the one you put in place (pun intended)

[Bethany07]

This whole change is beyond frustrating. Also, it is not a bug, i spoke with google support (who for the record was rude as hell, didn't listen to what I was saying at all, and kept saying things like "I'm sorry you feel that way". Passive aggressive much?) and they confirmed this is a change they implemented with the latest update, but they would not provide details of WHY the limit was made. They completely ignored that question when I asked. 

I have a workday route with 46 actions on it. I work from home, and rely on it HEAVILY. Now, with no warning, it's saying it's "unavailable". Google support instead just provided the link to *android only* instructions for writing a google home automation script. I let them know I was on apple, and they insisted that I just use the link provided and wouldn't listen that I'm on apple. They want us to all rewrite out long complex routines to be google home script instead. 

I know NOTHING about coding. I've had to learn very quickly. and it's beyond frustrating and frustrating to the point of tears that the code that i wrote will not work (it's not saying there are errors, but the broadcast function will not fire, neither will my music, or having google home announce anything.) I can get part of my lights to come on at the right times, the but not always, and the rest of the routine won't fire. 

and it's SO FRUSTRATING because my routine worked perfectly for over a year. so I KNOW google home is capable of doing what I want it to do, but it just won't now because of the **bleep**ing 30 action limit. 

Do better google. We were relying on this. I have invested a good deal of money into your products and products to make this work. and the idea that you would change this without warning is breaking my trust in you completely. Maybe it's time I look at switching to something like Home Automation so at least chat gpt can write the code for me. 

[zunkman]

My routines are all less than 30 actions, but I've noticed that my "longer" routines (20-25 actions) are stopping at random places.  Maybe it will do the first 11 steps, then stop.  Or the first 3, or the first 8.  I just never know if they are going to run all the way through.  And the real killer is that these routines worked fine for a long time, and only recently started acting up.  Google's QA has gotten SO bad!

[Dan_A]

Hi folks,

@Kaeris, @zunkman, thanks for posting, and apologies for the inconvenience. You should be able to add more than 30 actions to your routine. To make sure, we tried it on our test device, and it went up to 35 actions.

For us to isolate further, what kind of actions are you trying to add? Is there an error message? Which Nest speakers are we working with? Were there any recent changes made?

Looking forward to your response.

Best,

Dan

[AJR2093]

Dan, I had 12 items and it still came up with the message that only 30 activities can be added. I had to remove all activities, save and start again.

[Kaeris]

Good afternoon Dan,

I tried to add various actions to my to my default "Workday" routine (critical for the days I telework) and other routines in the Google Home app on my Google Pixel 5. The error message states that I cannot add more then 30 actions to a routine. I am working with Google Nest Mini (2nd gen) and Sonos One speakers. No recent changes were made as I have moved onto porting all of my routines into Google Home scripts due to the need for a  resolution.

[Mkhoury80]

Mine was for my "bedtime" routine which I had counted through the list which had exactly 22 actions in it. I also tried deleting every action and then randomly adding back actions until it hit the limit again and it once again started saying the 30 limit when I got up to 22 items in total added to the list. Since the "bedtime" routine is built-in with Google Home there is no way to "delete" the action to re-make it, so my theory is that there are 8 "phantom" actions (things that may belong to smart devices that I had to get rid of or replace but which were not removed from routines before I did so) that it may be counting (and which I cannot get rid of, since I can neither see them to delete them, nor delete the routine itself)

Yesterday I went to add another single action to my bedtime routine and it was ok with it, so whatever limit was removed I greatly appreciate it; now I have 23 actions in my bedtime routine instead of 22.

It would be great if any "phantom" actions (actions linked to no-longer-existent/linked smart devices) to be purged from whatever back-end list is being "counted" so that it doesn't run into an incorrect count, if any limit IS still going to be enforced moving forward.

The point in time when the error would come up was literally immediately when the "add action" button was clicked, which happens BEFORE the app asks you for what type of action you want to add... it stops you in your tracks right then and there.

I still stand by my previous long-winded reply to this, in that there should not be any routine-based action limit, as I presume the INTENTION of this restriction is to alleviate back-end load, but this is truly the wrong way to go about implementing such a fix... if you want to throttle the amount of asynchronous API calls your system is doing at a given time it should frankly be done in the form of an action queue in the back-end which would group together clumps of threads from each account and assemble them in a round-robin order.

FOR EXAMPLE:

Let's say that several users all ran some routine of theirs at the same time, and each of these users' routines have 100 actions each, meaning that with no restrictions you are looking at YOUR back-end trying to run hundreds of async API calls all at exactly the same time... THIS is the kind of thing that would warrant the technical manager of a department to give the order to put a limit in place... however the WAY that the limiting was put in place both hinders the users, AND simultaneously does NOT fix the actual underlying problem.

Here's how I would suggest to fix it instead (this method allows users to have NO upper limit on routines, but also results in STABLE data load output which can NEVER spike)

For each routine command issued, have it go into a queue data structure and have a process which runs let's say, every 100 milliseconds to check this queue and compare it against an iterator which starts at 1 and goes up by 1 with each run, until/unless the queue row count is equal to the iterator, in which case the iterator resets to 1, before then acting on the row matching the iterator number, with a max of 20 actions to execute at a time, and each "block" of instructions is cycled through in ascending order, if it exists.

Upon receiving the first 100 actions routine it now has 1 row of data in the queue:

A[100]

It finds there is only 1 row of data in the queue so 20 of those items get processed, leaving 80 in place

before the next tick the another request comes in, adding another row of 100 actions to the queue... the queue "array" or "struct" set now looks like this:

A[80]
B[100]

The parser now sees that the queue data set has 2 rows, and the iterator is set to 1, so the iterator is increased by 1 to now act on row 2, so 20 actions are pulled from row 2 and executed, leaving us with an action queue that looks like this:

A[80]
B[80]

On the next tick, the iterator is now equal to the total number of rows in the queue (iterator = 2, rowcount = 2), so the iterator is reset back to 1, and so it now acts on row 1 and pulls 20 actions from there and executes them, leaving us with:

A[60]
B[80]

And it could then go back and forth from here, pushing out 20 actions from each row every 100 milliseconds, round-robin style.

If more users add more requests then they would then be cycled with equal priority; the total wait time for each users in the queue would continue to increase as the queue size increases, but the amount of data going OUT from your back-end would be fixed to a MAX of 200 requests/sec no matter how many routines, actions, or users push data into the queue at a time, ever.

Obviously these numbers were provided for simplicity and your back-end is capable of FAR more than 200 requests per second... maybe something more in the range of 10k or 100k requests per second, but you get the gist.

It could also obviously be made more sophisticated like such as to set requests-per-second per API (one for Hue, one for Yeelight, one for Vesync, one for LIFX and so on) which would be set in accordance with the processing handling that the respective networks say to not go above, and then cross-check that against an overall "master" RPS limit, but I'm trying to keep my explanation in easy-to-digest terms.

Just put something like this in place and it would 100% fix any data load spikes and keep the output consistent at all times, thus preventing overloading any external systems or APIs.

[zunkman]

Hi Dan.  Please note that I've had these same routines working perfectly for 2 years, and they just recently started screwing up, maybe within the last month.  There are no error messages of any kind.  My routine just stops at some random point.  I have 2 Nest Hubs and 2 Nest Mini's that I have tested with, and all 4 devices give the same results - stopping at some random  point before the end of the routine with no error message.  The worst culprits are my "Good night" and Good Morning" routines, both of which have 24 steps, but some shorter routines stop short as well.  I have made no changes and I have rebooted every device in my home multiple times.

Hope this helps you get to the bottom of things.

Thanks,

Dan