Alexa Speaks Issues with SmartThings Home Monitor

I am fairly new to SmartThings and just set-up some home security automations using SmartThings Home Monitor (SHM). For the most part is is working well but I am finding a few quirks with the Alexa Speaks SmartApp.

For starters, Alexa Speaks gives the option of using the SHM mode (arm away, arm stay, disarmed) as a trigger or condition, but after spending way too much time on it I realized that it doesn’t work. I arm my system using a virtual switch that I trigger some other things so I changed the trigger/condition to look at the status of the virtual switch and it seems to work pretty well.

The second issue is that sometimes there seems to be a significant delay between the trigger event and the response from Alexa. It is both intermittent and inconsistent so it is difficult to track down. I am using Actions with Speak(Tiered) and sometimes not all the tiers execute. It may only do the first one or it may do the first and third, but not the second and fourth. It seems very random.

The third I understand, but want to determine the best way of handling. I have a trigger set to look at my Armed Away virtual switch and motion sensor. Motion will trigger the action and the tiered sequence starts, but if the motion stops the sequence stops. I know there is a switch for “Stop responses when trigger is cleared” and it is set to off so I’m not sure why it doesn’t run through all the tiers. I thought of creating a virtual switch that gets turned on if there is motion and keying off of that, then resetting it at the end but I’d rather avoid it if there is a better solution.

Thanks!

SmartThings Home Monitor (STHM) and Smartthings Home Monitor (SHM) are two different things. STHM is the security alert feature in the new V3 app. SHM is the security alert feature in the old classic app.

See the community FAQ:

FAQ: SHM and STHM are different

My understanding is that Alexa Speaks, like Webcore, can only work with the older version. The newer version is reserved for official features.

That would explain what you are seeing with your first issue.

1 Like

Thanks, that makes sense, but is extremely unclear in ST. It would have been helpful if they didn’t make the names so similar. That clears up one issue, but the other issues related to fully and consistently executing the tiered responses is still a mystery.

1 Like

It’s even worse, because originally the names were exactly the same even though the features were different. :scream:

It seems pretty clear that back in 2018 the app designers assumed the classic app would be retired when the V3 app was released, but that didn’t happen because some essential functionality was missing.

They’ve gradually improved the V3 app over time, and the rumor now is that the classic app will be retired by January 2021. We’ll see.

Also: Samsung is just bad at naming things. Look at the names of the various hub models. With the exception of the V2 hub, everything else is confusing and usually requires two sentences and a picture to figure out which model someone has. :disappointed_relieved:

There are multiple places that this will occur and likely not an issue that you can track down.

The rough sequence is:

  1. Event received by your hub
  2. Event sent from your hub to SmartThings cloud
  3. Event received by smartapp (running in ST cloud)
  4. Smartapp executes and sends command to the echo speaks Alexa devices (in ST cloud)
  5. Echo speaks device sends message to Alexa cloud
  6. Alexa cloud sends message to your Alexa device and you hear the response.

At each of these steps, assuming messages are used that are subject to latency and queuing. In addition, Alexa will sometimes reject messages (due to rate limiting or other transient issues) that can result in echo speaks having to retry at step 5.

The end result is that there is almost always a noticable delay and it will vary based on network latency, load on cloud resources, time of day, etc. This is just the nature of cloud computing and asynchronous messaging.

1 Like

Thanks, that makes sense. It works well enough. The goal is to let someone know the alarm has been triggered so the either have time to deactivate it before the siren sounds in 60 seconds or scare them off.