@nayelyz ermmmm I seem to have lost the local execution icon against newly created routines now though 
Restarted app but no time to fiddle any further at the moment…
@nayelyz From what I can tell it seems to be linked to notifications on Sonos (so maybe the new driver?). For example:
Where …2:
was a direct clone from:
but edited to have only the notification 
This is consistent across app (Android) & hub (v2) reboots as well as devices. I can also confirm that …2 does not execute locally so it does not seem to be just a missing icon for a local routine but genuinely not a local execution.
just curious… does the Sonos speaker show as LOCAL in the AWA?
1 Like
@nayelyz Also adding a step (for example socket off) to the notification step makes the remote routine local…
Hi, @TheHundredthIdiot
Sorry for the delay.
I moved your post here since this requires further analysis. The driver team doesn’t know of any recent changes that could cause this, so I need to check this with the Routines team.
To do so, please provide the following:
- Create a new Routine only with the Sonos device as you described. Take note of the date and time and share it with us, including your timezone
- Then, update that Routine by adding the other “step” as you mentioned, save it, and take note of the date and time and share it with us as well.
- Open support access to your account:
My understanding is that notifications can run locally but if the internet is down they can’t do anything.
So if you have a routine that would run locally without a notification it will still run locally with one, though the notification won’t work without internet access.
If your only action is a notification there arguably isn’t much benefit to having the routine run locally because it won’t do anything at all if the internet is out. A counter-argument could be that if doesn’t have the latest state of hub devices it wouldn’t or shouldn’t need to.
Thanks for sharing that post, @orangebucket.
As I understand the user mentioned that only new routines using the Sonos integration where having this issue. Although, I don’t know if the “old” routines have the exact same configuration but I wanted to check with the Routines team to see how it is being evaluated.
Ah, I understood that the new ones just had the notification icon, so …
… made the new routines have the same structure as the old routines.
Delay and apology this end too 
Account access granted and routines created as requested:
- 11 Feb @ 12:02: ‘Play message on speaker Test 1, notification only’
- 11 Feb @ 12:14: ‘…Test 1…’ updated with action
There was also some fiddling about with ‘…Test 2…’ routine between these times (create, update with action & title change, delete).
UK gmt, behaviour across tests as previously observed.
Hi, @TheHundredthIdiot
The engineering team confirmed that Routines with Notifications as their only action, will not be marked as Local.
The workaround is using another action that will be considered local as well, like a command to a Hub-Connected device, as you did.
I’ll open a report to see if something can be done regarding cases like yours. Once I get feedback about that, I’ll let you know.
1 Like
Thanks @nayelyz
Can you confirm if they are still executed locally or not?
I originally did a brief test and I think they were not local without the additional action but I’m not 100% sure the test was valid - I did it very quickly 
It needs the additional action for it to run locally.
1 Like
It seems to me that the issue is with routines that only have notification actions. Notifications can execute locally but require the hub to be able to communicate with the backend to have an end result.
Currently these routines are set for cloud execution. So is the thought that they should be set for local execution?
If they were executed locally then, in simple terms, they would not work while the internet was down. That’s an absolute.
If they were executed in the cloud then they might still have some functionality if the internet was down, they’d just lose the hub data.
1 Like
@nayelyz I have to admit that I was under the impression that if a routine was marked local then all actions would be locally executed.
Prompted by @orangebucket 's point above and a bit of experimentation I now realise that this is not the case. Rather it is that if any of a routines actions can be executed locally then the routine is marked local.
I had assumed that as Sonos was a LAN device it would be local, which is reinforced by the messaging:
on routine creation. I was incorrect which makes the current local tagging behaviour correct.
I do feel though that tagging a routine as local when only some of its actions will be executed when running locally is misleading. This is also a change in behaviour since local tagging was introduced. I distinctly remember Sonos notifications ‘becoming local’ in the past.
Maybe that is where the tagging needs to be addressed? Either by only tagging 100% locally executed routines or by tagging the individual actions within the routine?
(or maybe just changing the message wording to reflect reality…)
I’ve been wondering this as well and decided to test it this am as I optimize my setup. I have one routine that I trigger when I sleep. It was marked cloud in the advanced app. I removed the one thing I figured was remote (the Microwave hood) and sure enough when I did this it is now marked local. Thus, this means everything needs to be local to be marked local (at least in my case).
Agree except for, as discussed above, routines with notifications (of any sort) which, although cloud, do not cause otherwise local routines to loose their local tagging…
I’m not too involved in the Local execution changes, that is mostly on the Rules team. But based on what I can see, the only case where this happens is with Notifications, and this is because they’re part of a service called TTS (Text To Speech), which needs to be processed and then sent to the speaker (at least that’s what I’ve seen in other investigations).
I created a report focusing on Local/Cloud execution evaluations in Routines including Notifications, being unclear for users to see how we can “explain” the context better for this type of Routines.
1 Like
I think that’s at the heart of the matter, as users are rather invited to equate ‘executing locally’ with ‘still running with the internet off’.
Notifications seem to be unique in wearing two hats depending on whether there are other local Routine actions. However they are not unique in being able to execute locally but still requiring a cloud connection to ‘work’.
Locally controlled LAN devices where the LAN device is internet connected or is indeed purely an intermediary are similar but I would suggest users are likely to be aware of those cases but would not appreciate that Notifications have the same dependence (especially audio ones with local speakers).
More generally, if the internet is not available the hubs and the cloud can get out of sync. There doesn’t seem to be any differentiation between routines that can run perfectly safely either completely locally or completely in the cloud, and those that have limitations because of a dependence on hub to cloud connectivity.