A recent change in the smartthings platform moved a bunch of automations over to the new rules API, apparently, and in doing so it unchecked pre-conditions for many people. So check your automations to make sure they are still set up to do what you want them to do.
So that’s why some of my Automations were missing some triggers last week which I had to re-add.
I also noticed that they must have also fixed the stateless mode of virtual switches since they didn’t seem to be functioning for me in stateless mode for a while, but now they sure are.
What do people do who do not read this forum… isnt that the majority of the users…Samsung!!!
I think what we are seeing that in the legacy environment it is the device handlers that get to decide what events propagate to apps. The apps can choose to subscribe to particular values but they otherwise have to take what they are given.
The ‘new’ environment seems to allow apps to decide whether they want to subscribe to state changes or not. Whether this is a fundamental shift of responsibility from generation to consumption, or whether there is still control at the device integration end, I wouldn’t know.
Even if you do read the forum you can miss loads of stuff. My first comment about Virtual Switches v Simulated Switches in the context of recent looping was in a thread that was to do with Honeywell devices. I don’t even know how I ended up in there in the first place.
It would be helpful to have a ‘known issue’ tracker for this sort of thing. The status pages are more about service outages than bugs.
Even better, and this is probably going to sound completely crazy, but hear me out. What if the Samsung engineers buy themselves a v2 and v3 hub and set them up in a laboratory environment with a closed off server of the Samsung cloud, with Android and iPhone Connect apps on various phones, then they could bench test their various software changes within the laboratory, find any bugs, create a bug list themselves, then finesse the software to a point that it’s stable and they can THEN deploy their changes to end users. I have zero experience in this kind of thing, but it’s what I would do if I was in charge.
[quote=“orangebucket, post:5, topic:218914”]I
don’t even know how I ended up in there in the first place.
I tagged you when it became apparent that the cause of the issue was above my head, figuring maybe that some other thread I want following had maybe noticed the bug already
That’s crazy talk
Just to be clear that iOS and Android app users are seeing problems that can be 100% explained by the Location Mode precondition setting being dropped, the apps are indicating the precondition setting has indeed been dropped, and users on Android are seeing these problems go away when they put the setting back.
There are reports from iOS users that they are unable to restore the precondition setting as Android users can.
Whether there are any display only issues also going on in iOS isn’t clear.
Update: My best guess is that what we see in the apps is now a mapping back from rules in the Rules API, and the iOS app isn’t doing the mapping quite so well as the Android app, particularly the saving side of it.
Another alternative is a large open Beta so thousands of users can voluntarily test the new code and report their findings before general release. Just sayin’…
The good new is that new app has the ability to do that. Apart from participating through TestFlight the new app has the ability to change servers so it can be tested against a pre prod or staging sever before the code moves to production and then it can switched back to production on the fly.
There’s other weirdness going on too though. I have no preconditions and stuff still isn’t working right. For example, the last person just left my house, and I was notified that my Goodbye automation ran. That automation changes STHM to Armed Away, runs a Scene, and Notifies everyone. Here’s what did not work that has always worked until now:
- Location mode did not change to Away, hence Automations depending on that Location mode did not run. Again, no preconditions for any of that stuff.
- The Scene ran, but it did not turn on a few virtual switches, did not turn on my new ST camera, did not turn off 1 light, and did not open a couple vents.
If what I’m seeing is a precursor of more to come as more stuff is shifted to rules API and other unknown-to-us platform “improvements”, we should be prepared for a rough few months of changes, and ST better get their big person panties on because it won’t be fun for them either.
Yes, I just glimpsed another thread describing a problem and thought it could be explained by a conversion of the Automation into a rule that was running actions in series when they needed to be in parallel. I don’t think I’d like to attempt to implement Automations as rules as it isn’t clear what on earth the Automations were trying to do in the first place. However I am not in the least bit sympathetic as if you quietly implement significant changes and leave your users to wallow in your mess the shoeing that will come your way is somewhat inevitable.
I am actually unusually annoyed by these issues, even though I’ve been barely affected by them myself. It is because ST have somehow contrived to smack the ball from the halfway line into their own net.
This is a known issue. It has immediate impact on customers. Engineering is working on it. Yet there is nothing on the status page.
That alone is enough to infuriate me, and I don’t get annoyed easily.
Yes, if it isn’t considered appropriate for that page there should be one that it is appropriate for.
Investigating - Our fan is clogged with brown stuff. We’re looking into it and will provide additional details as they become available
This sounds like backend migration of Rules from old format to new. I’m sure the team had in mind a logical way rolling/pushing out the migration (by geolocation zone, timezone?).
But the way they migrate puzzles me. It doesn’t sound like they have cloned or set up a Test environment; or if they have, they eye-balled the rules migration and said “98%” ain’t shabby, and that 2% is where most advanced usecase resides. Somebody didn’t take a sample rule set from production (shouldn’t be that hard, just look users with high number of rules/handlers), test-run the migration. Or better yet - COMMUNICATE by request advanced users to participate in small beta (1-2 weeks ahead of actual roll out). Working out that 2% is basically working out the other 98%.
It does, but it also sounds like there may be a lot more going on in the mobile apps than you’d really want in these circumstances. You just want to press a key, do a quick check to make sure you still have the same number of wheels, then go down the pub for an early lunch and hope your phone stays quiet.
As I’ve said previously, I wouldn’t really fancy having to create a one way mapping from Automations to the Rules API, but I’d vastly prefer it to trying to do a reverse mapping from the Rules API to recognisable Automations. That sounds a bit scary.
My preconditions are off. And the new 1.6.59-477 build for iOS will not allow me to turn them on - The change does not "take’ or I get a NETWORK ERROR msg… Samsung strikes again.
Anyone have a work around?
Not a particularly useful one, but the precondition can be set via the Android app and I am told the iOS app then picks it up correctly, as if it is writing it that is the problem.
It has been suggested that the precondition thing is purely a display issue and that there might be other confirmed issues at work. All I know is I’ve seen multiple reports of problems that can be explained by a missing precondition, and that those problems go away when it starts showing as set.
Hi All - I’m confused by all of this since the latest release, the reason for my confusion is that I’m seeing issues seem to be related to your observations. But the whole rules move isn’t clear.
The latest version of the iOS app is painfully slow to load the automations list and managing it is painful. Loading the scenes list and working with them is just as slow. However they do work/save eventually.
I have noticed the pre-condition issue also.
However the thing that baffles me is that if the rules engine has moved then why is the iOS app on an old iPad (don’t have version to hand) appears to be working just fine, with the exception of some automations saying created in later version?
This suggests to me that I may have a partial migration, does anyone have details of exactly what the changes are?