Bare in mind I’m still using the Wink Hub but say if its dimming level is set to 75%, if I then switch it on it’ll go straight to 75% and not gradually fade up from 0 to 75% and if I switch it off it just goes straight to 0% and not gradually fade off from 75%
Is this not what ST does with GE Link bulbs?
For most devices, fade rate is a parameter that you can set. Some people like it to fade in slower, some people like it to fade in faster, the point is you should be able to set it to be what you want it to be for each individual device that supports variable fade rate.
So, just to clarify, on the ST hub with a GE Link bulb attached, if you turn it on, it’ll ramp up the brightness and not just go directly to the set level? And it’ll fade off too?
I use the community device type and it does this. see post 217 for caveats
@JDRoberts, I agree. Here is the use case. When my wife arrives she usually walls i through the back yard so I have the presence sensor set to turn on the back yard lights. Sometimes she comes in through the garage which means that she does not even see that the back lights are on and they could stay on all night.
Chris
I would like to emphasise on the lack of exemption rules. For instance, I set up my exterior lights to be turned on when I open my window, with a delay to turn them off (3 minutes).
The problem arise when the light is already turned on (I have guests), and someone open and close the window, as the lights get turned off after the delay.
I have a smartapp that avoids this behaviour, but I would really like to use the ONLY local processing!.
There are several examples of this in the ecosystem where an action takes place that, “logically” speaking based on the settings, should not happen. I would definitely like to see some sort of preference available in all SmartApps that allows the user to set whether the SmartApp will or will not override a previous setting, perhaps even under a different mode.
I learned a big lesson today. I have tried to use SmartLights exclusively to get the automation I need and it was working for the most part. Then I added a rule today and decided to uninstall just that rule… It uninstalled over 40 rules instead. Have to redo all of them!
I’d like to see a Statement of Direction on these new uberApps vs. Routines. I am reading some comments about Routines for the same purpose as Apps… Any Wizard is not much less than hard-coded logic in my mind.
Did you report this as a bug? Would be very useful feedback!
I have a few support tickets open. Don’t expect any responses at this point. Plus, it may have been user error - which Uninstall did I press? One in a single light automation? or, one for the whole thing? of course, it should be clear…
Fair enough! Perhaps some testing is required, create a few rules, try and ‘accidentally’ delete them all?
My ST V2 got delivered today! Can’t wait to get home and finally see the app and properly understand what you are all talking about!
I’d like to add something positive here. I did find that if I named the Light(Switch) Automations starting with the Thing, and my Things all start with the Room name, e.g. Garage Light & Kitchen Cans, then not only is the list of Automations in the same order as my Rooms & Things, but when I go to a Things SmartApps, I get a readable list too. Also, using the SmartLights to program my Minimote buttons was more reliable than using the Buttons approach.
Nice, @Benji. I added those 40 rules in less than a week of getting mine. As well as added a dozen switches. Have fun!
This is critical. I use(d) this feature almost every day, riding home after dark and parking my bike in the back yard. All my lights were on hours after I got home yesterday, I was so accustomed to the feature before it took me more than a minute to realize it wasn’t there.
I just can’t stop think that the owner and employees of Smartthings must have a massive amount of custom code(smartapps) running on their own systems. It would be interesting if they were forced to primarily use only the apps and options that natively come with the hub. The smartthings provided solutions could be a little more robust to cover everyday use cases.
In the meantime, until ST adds this feature back, you can get that functionality here:
Like if Alex did his whole entire upgrade by himself w/o development & support to help him? And, then reimplemented his automation using just the logic available? Wow. That would be cool. If he could, we have NOTHING to whine about. But, if he can’t, like you said… priorities.
I agree! This option is available for other methods of turning lights on, e.g. opening a door, why not for presence sensor? I had it set up on my old version. Seems like an oversight. I also tried to outsmart the system by having the lights come on for arrival and on again when the door opens follow by off after 6 minutes. That didn’t seem to work.
One enhancement I would really like to see is support for toggling lights when pushing or holding a button on a remote. Right now it remembers the last button state and doesn’t look at what the current state of the switch. So if I turn on a light with my remote and turn if off at the switch, the next time I hit the button on the remote it will issue a off command and not a on. I have to hit the button a second time to issue the on. Kind of annoying. I have my own button controller which does the toggle, but since the smart lights app is currently the only app which will run locally on the v2 hub, would really like to see it added.
I’d like to see LUX added as a condition when setting up triggers like the Lighting Director app has.