New app is nowhere near as good as old app. Developers have been working on new app for years now. What gives?
New app does not support WAM 1500, 3500, 5500 speakers but supports Bose and Sonos? Who bricks their own speakers except maybe Sonos and Samsung. Come on now, absolutely ZERO REASON why these should not work in new app.
Lutron Caseta light switches and lighting automation doesn’t work in lighting automation app is written. Have been working with ST for over 1.25 years and they finally gave up. No solution which means Lutron does NOT fully work with ST.
Custom notifications on triggers (voice over speakers for triggers) is terrible at best. Severe limitations on legnth of message. Doesn’t work if you try and customize volume in app. Volume is inconsistent.
I have all my Lutron light switches and Outlets working properly. What is not working for you?
I have a motion detector on my deck and a Lutron Caseta light switch for my deck lights. If I select the following condition for the native smart lighting automation, it fails.
Turn on deck lights if motion is sensed between sunset and sunrise and turn then off after one minute ONLY if the light switch is off.
In other words, don’t want the lighting automation to run if I MANUALLY turned the lights on. Otherwise, I turn the lights on, walk out on my deck and sit down in a chair, the lights turn off one minute after motion stops (I sit down).
Everything works ok until I tell it to run ONLY if the deck light switch is off. What happens is that it turns on and then NEVER turns off.
Smartthings as a platform does not have the ability to differentiate a manual switch on v. an programmatic switch on (this is platform wide - not classic or connect specific)
Yes - it used to. (You can even see remants of it in the WebCore UI: there’s a programmatic v. physical interaction decision on the IF dialog box) The change happened at least two years ago because even though TECHNICALLY some devices have the ability to tell (I think Lutron is in the CAN category) most vendor implementations were poor at best and some not at all - so it left a very bad end user experience. SO ST - pulled it.
That means your automation won’t possibly be able to work because it can’t tell the difference.
To overcome it, you’ll have to do some advanced automation in something like WebCoRE where you set a flag on motion that says ‘Yeah I automagically turned on the light’ and if so run a timer where if that flag isn’t set then don’t do anything. The built-in automations can’t do that - even in Classic.
Now as to ‘this stuff isn’t ready for primetime’ portion - feel free to pile on the Get ready to make the switch! thread. There’s PLENTY that doesn’t work in NewApp yet… I’m in teh same boat, with all my custom smartapps, custom devices, and WebCoRE Pistons, my particular setup will probably one of the very last that fully works. But, I try every time I get an update to Newapp, I try - see what’s stilll broken - and post feedback - at least they’re listening.
In reading your statement above, the first conditional is if it is between sunset and sunrise. Is your second conditional the light being off?
I’m asking because the change you may need to make is to the motion event. In your scenario it is the motion event that is causing the lights to turn off so maybe you need a conditional in your motion event that says that the lights have to currently be off in order for the event to run. That way the lights would continue to stay on regardless of the motion that is detected by the sensor if you then turn the light off the motion event will run normally, and will then shut off the lights.
I hope that helps.
It is a selectable feature in the smart lighting automation, how does it not work?
Yes the second condition is that the light switch is off, thatis how the standard lighting automation is set up in ST.
You can prevent the automation from firing if the light is on - but once its on it will never fire until you manually turn it off - basically a latch. Net result is once its on, it wont turn off, because it does not track HOW the light was turned on - just that is.
To get what you’re asking for you need to track the HOW. Which you need extra semiphores and flags for.
So yes I agree the automation should sense the motion and THEN check the light switch position. If off, the automation should run, if on, then the automation should not run. That is not what happens. I have asked Samsung developers to fix the order but they have not in over 1.5 years. After all, I am using conditions that are in the standard ST app. It is simply broke and remains broke…
I have something similar for my inside garage lights. I use a SmartThings motion sensor to trigger Leviton switches. Inside lights go out after 5 minutes of no motion.
I had issues with the lights turning off when I was using the weight bench. I added a virtual switch that I call “garage motion lockout”. The whole “turn on with motion” automation is conditioned to not run if the lockout is switched on.
So I can switch on the lockout, manually switch on the lights, and they stay on until I want them off.
I’ve got a second one that turns on outside floods on the same motion detector with the same lockout but only between sunset and sunrise
For a more complex situation you can check out our example apps for building complex rules.
Will let you upload customized rules from here:
And here is a GUI version with a small selection of rules with a dropdown picker
The smart lighting automation in the ST app already has the conditions I am desiring as selectable. Issue is, it doesn’t work and ST will not fix it, oddly enough.
I am not sure how to build these or how to apply them to my IDE.
So I don’t understand what the purpose of the condition in the ST app is for then. Just not sure why the app cant be built such that it looks for motion first, checks the light condition and then continues or doesn’t based on that.
Are the lights you want to turn off separated from the light switch that would be detected as off?
The way I understand the design is such that condition is there to prevent the rule from firing at all. Youre asking for thw rule to be evaluated first then react. It’s a completely different design philosophy.
I used to do product support for a major software development house. The criteria we used when a user brought a design change request was
- does it have the potential to break existing use cases… If so it must have a high business impact (we had a dollar value assigned to that)
(your design would almost certainly break existing cases so lets assume we need to meet a certain financial bar)
- if it meets the bar for financial reasons, does the cost of redesign outweigh the financial benefits. (from the publisher’s perspective - not the user)
(I cant see how Samsung makes money by making the change especially when there are other solutions and theyre in the middle of redesigning how the product works at its core. )
So given that, I doubt they’ll ever accept the change.
Now, had I had the case Id have written the user with the design change request and explained it. But I haven’t seen that transparency from the ST Frontline support team.
Since @jody.albritton is one of the most transparent ST staffers I’ve seen on here - if hes suggesting an alternative, I suspect strongly I’m really close.
The new automations work such that you cannot create a recursive loop by mistake. You cannot have the same device on both sides of a automation for this reason. The automation does not know why the light is on. Is it on because the rule fired and turned it on? Or is it on because someone turned it on at the switch. With the rule you described the light would never turn off.
You could create a complex rule with our rule builder or an external app that would do this.
I guess I don’t understand why the condition to select only if light switch…on or off is in the automation them. Seperately, what I am asking it to do is totally normal. I am asking it to NOT turn the light off on me if I manually turn it on and walk out on my deck but at the same time, turn it on if motion is sensed and the light is off. Makes sense to me. If a smart home platform can’t meet these simple requests, it is after all, not very smart or reasonably adaptable to a reasonable smart home environment. Someone seperately told me it works with GE switches so as much as I like the Caseta system switches because they have remotes, I may have to switch. The point still being though ST is just not very smart.
You can use the condition of the light switch to control other devices but you cannot use the condition of the light switch to control the light switch. This is not a bug, it was a design choice. If you want to use the condition of the light switch to control itself, you will need to go beyond the if this then that style automation that comes with the app.
So SmartThings can’t do it but another app can? Speaks volumes that ST app is terrible. I am asking for an app that doesn’t shit off a light in me when I manually turned it on but at the same time turn it on when motion is sensed and the light is off. I would love to be able to make this work outside of ST , I am just not that saavy to know how.
If SmartThings simply looked at the position of the light before it proceeded, it would work just fine. It isnt that hard and again the ST app has this condition selectable so why doesn’t it work?