State changes triggered by Amazon Echo not reflected in SmartThings

alexa
integration
echo
zwave

#1

I have an interaction between SmartThings and some of my Z-Wave devices when commands are sent via Amazon Echo that I don’t quite understand and any guidance on the best resolution route would be appreciated (or even guesses as to what’s going on :slight_smile:)

I have a room where there are no neutral wires (power is through the light), so I couldn’t use the standard on/off smart switch models. Since the fixtures in that room use conventional size bulbs, I decided to try a “software switch” instead pairing an accessory switch (this one) with some Hue bulbs and using SmartThings Routines to sync their state. This seemed to work well and integrated with my Amazon Echo room setups properly, so I got a couple more to deal with the same situation elsewhere.

Problems started when I set up a second of those switches (unsure whether that’s a factor in this but the issue definitely wasn’t present before that point). The switch operations work fine when triggered physically @ the switch (status of switch and bulbs reflected properly in SmartThings, routines linking them properly), however when I configure the devices into my Amazon Echo rooms, when I use a voice command to turn the room that contains the switch off, all of the members of the room (including the switch itself) are properly turned off BUT the switch state is not updated in SmartThings (switch is off, but SmartThings says it’s still in the on state).

This would be benign except that when the switch is off but SmartThings thinks it’s still on, hitting the on button changes the switch state physically but the automation won’t trigger, so to get the lights to turn on then I’d have to hit on (physical switch state changes, no change in SmartThings)/off (state appears as off in SmartThings)/on(switch changes state in SmartThings, triggering my automation).

If I give a second command to Alexa/Echos to turn the room off, the switch state will properly reflect as being off.

The lack of state change updates in SmartThings when the changes is triggered by Alexa/Echo still occurs even if there is no automation tied to the switch and if only one switch is in the room group (tried to eliminate interference as a possibility).

I installed a third of these same switches and found the same behavior occurs there too.


(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy) #2

This differs on a case by case basis.

SmartThings doesn’t assume that a Command successfully changed the State of a Thing… It expects the Thing to report its own State changes.

In ActionTiles testing, we’ve found that most Things do this. I don’t think it should be worse with Alexa… :confused:.


#3

Thank you for the extra info… it makes sense that SmartThings relies on the device to report a state change.

The behavioral difference when commands are initiated from Echo/Alexa is the crux of the issue and the strangest part… why Alexa sending a command to a device via SmartThings consistently results in the lack of a state change when I have almost never seen the same behavior when initiating the same command from SmartThings app I can’t explain. I’d have figured that Alexa telling SmartThings to tell a device to turn off would have identical results to directly telling SmartThings to do so. Anything anyone knows about the relay process that might give some insight?

Also why the issue only occurs with these particular devices and not the dozens of others in the house; not to say there’s never a device where SmartThings status doesn’t reflect physical state but nothing else misbehaves in this very consistent manner.


(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy) #4

The SmartThings mobile native App has a direct API and will always be the most accurate unless the DTH is poorly written.

But all SmartApps (including ActionTiles and Alexa) are using the same third-party API, and thus should have similar results… Unless the SmartApp or DTH is written incorrectly.

So for apples to apples comparison, you can’t compare a command issued from a SmartApp vs a touch in the SmartThings Mobile App.


(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy) #5

Prot, … I didn’t read your post very carefully before my first comment.

Are your Hue bulbs connected directly to SmartThings (i.e., via ZigBee) or are they connected via a Hue Bridge?

If connected via Hue Bridge this is a HUEge difference!

I believe that the API for the Bridge does not inform SmartThings when a bulb has changed state. SmartThings has to periodically poll the Bridge in order to detect changes in bulb state. I think it is every … 5 to 15 minutes.

To recap:

  1. When you use the SmartThings mobile App to turn on or off a Hue Bridge connected bulb, SmartThings “instantly” knows its correct state because the Device Type Handler GUI tiles automatically set the State at the time the tile is clicked.

  2. When you use a SmartApp to interconnect a trigger to a Hue Bridge connected bulb (i.e., a “software switch”), the path is entirely different. The SmartApp calls on() and the DTH sends the command via the LAN to the Bridge; but the Bridge never reports the new State back to SmartThings. So why doesn’t SmartThings assume the command worked: I don’t know. It is worth studying this, if you want to, by taking the Hue DTH and watching live logging, adding more debug statements, etc., etc.,.

  3. When you use a SmartApp that actuates a ZigBee and Z-Wave devices, the response is still not instantaneous, because the ZigBee and Z-Wave packets have to propagate through your local mesh, then to the Cloud, then to the SmartThings App.


#6

It used to be several minutes, but the official SmartThings/Hue bridge integration changed a few months ago and SmartThings now gets a “heartbeat” update about every five seconds which gives it the status of all the bulbs attached to that bridge. This isn’t the same thing as polling, which is good, because it shouldn’t slow down the hue bridge. It’s basically checking the bridge’s own log for the current status of all the bulbs. So I don’t think that’s the issue.

There are a couple of possibilities here so we need to nail down some of the details first.

How do you have it set up so that the switch causes the bulbs to come on? Are you using the smart lighting feature, core, trendsetter, something else?

Second, do you have echo set up to control the hue bulbs and if so did you do that through the Hue bridge or through SmartThings?

Third, when you are telling echo to turn on the lights are you telling it to turn on the Z wave switch or are you telling it to turn on the bulbs or are you telling it to turn on a group that includes both?


(MICHAEL MCGLYNN) #7

I have the exact same issue as Protagonist on two switches in my setup. In my bedroom I have a fan with lights, the lights are connected via enerwave relay. Due to wiring issues, I’ll explain in depth if needed, I had to use accessory switch as software switch. I have an identical setuo in my dining room even the fan and wiring is the same as bedroom right down to enerwave relay and linear software switch. Im using smart lighting feature to turn on zigbee hue bulb (directly connected to smartthings) and fan light in bedroom and in diningroom it’s just the fan light and again using smartthings smart lighting feature. I’m telling alexa to turn on/off switch that is then controlling group through smart lighting. The device handler for the switch is generic zwave switch. tried changing device handle with no change in result.


(MICHAEL MCGLYNN) #8

I have even tried changing from smart lighting to using core to do the same thing and the results haven’t changed.