Smart Home Monitor bug

General Discussion
1

I have a siren which is set to go off if there is an “Intrusion Detection”, and all of my lights should come on as well. I have about three motion sensors that are "armed’ at night - any motion signals an intrusion. And Scout is monitoring faithfully.

So last night, I was woken up at home at 2:00am by Scout, asking if I needed assistance. I didn’t know why they were calling so half asleep I gave them the code and told them I was fine. I disarmed the alarm (which was showing intrusion and i had a notification on my phone too) and went downstairs (past a very motion sensor) to check it out. There was one light on indicating motion in the playroom, which is the sensor Scout had said had motion. Clearly no break in, so I breathed a sigh of relief.

As I was going upstairs, past the motion sensor I had already gone past to get down the stairs, the siren went off and all of my lights came on.

There was some difficulty turning off the siren because according to the app out was already off. But my main thing is… Wth. Scout was notified but the siren wasn’t triggered by SHM? Then three minutes later, after I had specifically disarmed it, my motion triggers the sirens and lights (but no call from Scout.)

This is not acceptable to me. This is a feature I’m paying monthly for.

1 Like
2

I have had something very similar, I had a ticket opened on it as well.

The ST app shows and confirms SHM is disarmed. A sensor set to trigger SHM is then tripped and SHM goes to alarm state. The issue I had was that Local SHM was not disarmed, despite the cloud SHM showing as disarmed. Remember SHM runs locally on v2.

IMO this should never happen, I think they need to make some code improvements to eliminate this possibility.

From my support ticket - on or about July 13th:
“I took a long look at the logs. The conclusion I came up to is that since you didn’t get an intrusion alert, the alarm state did change in the cloud to disarm. This information didn’t reach the Hub’s local processing though. Alert with Lights and Alert with Sirens both run locally, and it seems the Hub either missed the command or got it late. That is the reason the lights and sirens went off.”

IMO:
1) Cloud SHM should never change status until a complete handshake is done with local SHM to confirm all SHM apps are armed or disarmed. This seems like common sense since SHM executes locally, and Cloud SHM should be a slave to that status and never report or act upon any other status.

2) Perahps Local SHM should always do a cloud SHM status check each time something is triggered, and if it shows disarmed - cancel all, if it cannot reach the cloud, alarm in any event.

Something like that. These seem like fail safes that should be part of the way it operates.

I can PM/DM my ticket to @Aaron . Support was looking to reproduce this, I wasn’t able to get it to do it again, but didn’t try very hard. If you can supply logs showing the same, I’d ask them to link the issues and resolve it. Especially if we can get to the magical reproduction. Not sure what all the dynamics are, one maybe able to induce it by interrupting their internet connection for example, but I don’t know if that’s ideal.

EDIT:
One of the reasons I deployed ST, was I am eventually interested in using an IOT system for security as the data is rich and the access is better. ST or another IOT system will need much more proven reliability before I can disable my old school alarm panel with monitoring. I look forward to be able to do so, and then I can spend my monitoring dollars on ST or another IOT.

I think the IOTs focused on security maybe doing a better job, perhaps because of the singular focus, simplification and closed ecos - such as Scout and Abode.

ST is definitely not there yet, so I use it as an overlay. I get the rich data from ST, with the reliability from the old school panel.

2 Likes
3

Per Vlad’s post yesterday, we are seeing reliability improvements - both in timeouts and misfires (which is sometimes attributed to reconciliation between local and cloud processed SmartApps).

@JH1 we are a bit hamstrung if this happened in July because most of our customer event data is only available for seven days.

@red5 if you haven’t already, submit a ticket to support for investigation. We can dig into the logs and see what’s going on.

2 Likes
4

I sent the exact text of this post to support from the Android app this morning right after posting this, but haven’t gotten any ticket or acknowledgement back yet.

5

Can you DM the ticket number?

6

Done. 7890

7

Similar thing happened last night. Got home. Disarmed the system. Received text that the alarm was disarmed (triggered by alarm status changing to disarmed). Opened the door - all the lights came on and siren went off.

2 Likes
8

Mine did it this morning. Pressed my button to chagne to home mode from night and disarm alarm. The house went into day mode. About 5 minutes later I opened the front door the let the dog out and the alarm went off.

1 Like
9

Please continue flagging these instances for support so we can dig into them. Thanks for the patience!

1 Like
10

I am curious what additional information ST needs on this. When I worked my ticket way back, support confirmed the issue and acknowledged a fix was needed after gathering the logs.