Smart Lighting Automations Broken for 8 Months

SmartApps & Automations
#1

For the past 8 months the Smart Lighting Automations have essentially been broken because they repeatedly send the commands for the current state of the automation. This breaks all sorts of use cases for automations. More details:



I contacted support and the response a while back was that engineers were aware of the problem and working on a fix. Since this has now been a problem for 8 months I’m losing confidence in SmartThings ability to fix this and I’m getting so annoyed with the issue that I’m looking at switching to another system.

So one last ditch effort… SmartThings: Can you actually commit to a date when this will be fixed? Community: Are there any possible workaround, like http://smartrulesapp.com/ ?

1 Like
#2

I consider sending the commands repeatably a feature. Smart lighting checks for a condition, if it met send the command. It does not care about previous state. Its a very basic automation smartApp.

If you want more control over rules, check out CoRe. It has overrides and more conditionals.

The repeated commands in the activity feed is a different issue. I would still want my rule to evaluate repeatedly (on every condition met) but only log an activity if there is a change. It really does no harm, besides adding lines in the activity feed. I think the majority of users don’t look at activity logs that closely, I don’t recall the last time I did.

2 Likes
#3

@desertblade First thanks for all your help that you provide to this community, and please take no offense, Not sure I agree.

I see at least 2 different use cases here, one which sends the command repeatedly and one use case in which it does not.

Use Case 1: Which is the same functionality @jamesward is looking for, he has turned off the light it should not come back on.

  • Opening door turns on light, smart lighting only sends command once; this always works for me, no repeats.

  • Opening door turns on lights. But it is the event “door open” and not that the door "is open state. "

  • So I open the door to the basement, or the laundry room, lights go on, if we turn off the light from the zwave switch, but leave the door open, the light never comes back on, unless the door is then closed and opened.

Use Case 2:

  • Something like turning on a fan when temperature goes above some threshold. This one you might want the command to be sent repeatedly.
1 Like
#4

Yeah, @professordave is right that there are cases for each. My primary use is this:

I have an automation that turns on & off Light A and Light B from Light A’s switch. But if I just want Light B on and Light A’s switch is off, then Light B stays on for about 10 minutes before the recurring automation event turns B off.

So this is certainly a bug for my use case.

1 Like
#5

No offense taken.

For Use case 1:

The trigger is the door opening and not that the door is open. It is triggered off the event of the contact sensor saying it is open. Contact sensors don’t repeatably check their status (battery drain) and only send commands on status change (open/close).

You could probably set up the rule if is not closed to turn on the light. But if you close the door the trigger will turn it off. This is where CoRe adds more power with its conditionals (If/Else)

1 Like
#6

There’s a big difference between sending a command whenever there is a trigger and sending a command repeatedly from a single trigger.

sending a command whenever there is a trigger is often seen as a feature. For example, if you want to send a “light on” command regardless of whether the current status in SmartThings is on or off, then you can also successfully manage the light even if you are using parallel means of control, such as a hue dimmer switch or Yonomi. In these cases, there’s a polling lag. The light was turned off by some other means and it may take smartthings four or five minutes to realize that. So being able to immediately turn the light on again through a SmartThings mechanism is of value. The only downside is that you might be sending an occasional unnecessary command. But these instances should be rare and have little impact on the network.

On the other hand, repeatedly sending the command of the single trigger can be deadly to your network. First of all, you’ve obviously multiplied the number of messages that your network has to handle, and this in itself Could cause other messages to be missed or delayed. Second, as the OP mentioned, it can really mess up “follow me” use cases where the first device going on or off is supposed to trigger something else.

A few months ago I had a single trigger issuing upwards of 30 repeated commands over several minutes. (I posted some of the screenshots at that time.). It did cause actual problems at my house. For one thing, the light couldn’t be turned off because it kept turning itself back on again. There were other issues as well. Support tried a couple of different things and eventually forced a local smart lighting automation to run in the cloud which seem to fix it at that time, but obviously lost the benefits of local processing.

So the impact really depends on what you’re seeing. Multiple triggers generating one command each shouldn’t be a problem. A single trigger generating multiple commands almost always is, if only in the impact on network efficiency.

3 Likes
#7

That is what I would expect. You have a rule to ONLY have light B on it Light A is on. This is a limitation on smartlighiting being too simplistic.

If you use light switches it does trigger on state change and poll. So in this example it does evaluate “is on/is off” every time the switch checks in, which is more often than battery powered devices.

CoRe should be able to handle this condition. I use a mix of smartlighitng and CoRe for my automations.

#8

@jamesward If after the first time, that you turn off the light and then it gets turned on automatically, if you turn it off again, does it turn on again, or does it only get turned on automatically mistakenly once?

If you have not tried it, please do so.

@desertblade and @jamesward The only time I have seen problems like James describes was in an area where I was having trouble getting a good zwave mesh. It was in the garage, and the problem is that the states of the switches turning on for the first time was having trouble being updated in the hub, so I could turn off something and it might turn on again because the hub did not think it actually went on the first time.

My originally solution was to simulate a three way using a minimote and an aeotec gen 5 switch. But from the garage the zwave mesh was not strong.

In fact one ge-link light bulb in the garage never had this problem because the zigbee mesh was good.

After replacing that solution with 2 ge zwave switches I never have any problems with follow scenarios and other automations.

#9

@desertblade

If smart lighting automations are run whenever state is received from the device, if I manually hit refresh on an open/close sensor, should that cause the automation to re-run, even if it already run?

I think I might do an experiment tonight with switches following switches to see if I can reproduce James scenario.

Is the behavior of wired or battery devices completely different?

By the way, CoRE is Great!! and I just started to use it for a few things! :slight_smile:

#10

@professordave The behavior is indeterminate based on the order in which the events are generated. So sometimes the light turns on & off repeatedly and sometimes it just stays off.

@desertblade I think the problem is the semantics of the Automation setup. The app says “How do you want to trigger the action?” and I’ve selected “Switch Turned On/Off” which to me implies that one event should should have one corresponding state change. If the trigger was something like “Every 15 minutes check the status of the switch” then I’d expect the behavior you are describing.

#11

There was a known problem with some of the Z wave stock device type handlers where polling the device was incorrectly interpreted as a physical “on” event. That should not happen but it had been happening. It messed up a lot of logic, including double tap.

@SBDOBRESCU might know if this has been fixed. I know it was still broken in July.

2 Likes
#12

Refresh is not the same as an event. Wired devices are way more chatty than wireless. Typical wireless devices only send events on change, and maybe every 24 hours for battery.

I take that to implies if the switch is on/off. To @JDRoberts point, hitting a light switch does not always generate an event. The on event was troublesome, kludgey hack that ST removed a few months back. There is an “instant status” patent that prevents most zwave switches from being able to report status immediately, and has to what till a schedule poll (which is usually every minute or so).

Really you are looking for a “is state changed” option for the light switch. Check CoRe I am pretty sure you can get it to do exactly what you want it to.

#13

Smart Lightning is not broken! As @JDRoberts mentioned, the stock zwave switch handler generates physical on/off events every time the device refreshes, which triggeres events in Smart Lightning. This manifests when you have two switches tied into an automation. A work around for this is to change the handler in ide from zwave switch to dimmer. There is no difference, except your Smart Lightning will stop acting up. I would also suggest you to open a ticket specifically for the handler. Mine was closed, with the promise that I would be notified when resolved. I didn’t get a notification so I assume it’s still outstanding. I am still using dimmer handlers for those automations that involve more than one switch.

1 Like
#14

Is not, that’s true, but explain that to ST, because that’s exactly what the zwave switch handler does. Check my post here.

#15

The “instant status” patent only applies to dimmers. Ironically, it was the stock dimmer DTH that worked and the stock switch DTH which was broken with regard to isPhysical events.

I should note, however, that the same symptom was seen with other causes. The one I mentioned at my house where a routine was sending several dozen repeated commands had to do with an error in the scheduler, not the device type handler. :disappointed_relieved:

#16

Not sure if this is the right thread to post this on. I’ve had 2 “smart light automations” screw up in the last 5 days.

  1. ST’s motion sensor is suppose to turn on my 4 Hue can lights in my kitchen in the morning. Now they blink, maybe 1 or 2 will turn on. I have to turn off & on the dumb switch to get them all on. (I almost stubbed my toe on the kitchen island!:grin:) That automation worked perfect & I haven’t changed anything on it.

  2. A outdoor GE smart switch it suppose to turn on and off my pond pump. Worked perfect for a month. Now nothing. Can turn it on with the ST;s app.

#17

@Murray1 if you haven’t already, shoot a note over to support@. They can check out the failed automations, log them for platform improvement, and help get them back on track.

© 2020 SmartThings, Inc. All Rights Reserved.