SimpliSafe is breaking my heart. It’s the backbone of all automation for me. I do not think this is a HA issue - I’m pretty sure the beautiful work of @bachya is going great, but wanted to throw this out here to see if others have had the issue and have any work around.
It seems like SimpliSafe is not updating the state of the alarm correctly. For example, I set my alarm at night into Home mode. The SimpliSafe app more often than not will continue to show Off. If pull down on the app, which forces a full base sync (the unit says “Your settings have been synchronized”) it will often then update correctly.
HA does not update the state as well. It will update for a split second sometimes and then revert. This is leading me to believe the same backend issue is causing both and it’s not the HA integration.
Remind me: in this case, are you arming the alarm (1) via the keypad, (2) via the SimpliSafe mobile app or (3) via Home Assistant?
Are you pulling-to-refresh the SimpliSafe mobile app or Home Assistant?
While I wait on those answers, you shared a key piece of info:
When I first took over the integration, I learned that every SimpliSafe API call can request cached or fresh values (ostensibly so that SimpliSafe’s mobile app can quickly show the “last” values before the user manually requests an update). We obviously prefer fresh values, but there’s a challenge with V2 systems: every time the system is updated, the audible “Your settings have been synchronized” message that you mention plays.
So, I made a tough decision at the time:
Home Assistant requests cached data from V2 systems (to limit that audible message)
Home Assistant requests fresh data from V3 systems
Thus, V2 systems will return the same data until the cache busts (which, given that the SimpliSafe API is unofficial, has an unknown lifespan).
It’s possible my thinking (that people would get annoyed by regular audible announcements) is incorrect…
Let’s consider the three ways SimpliSafe and Home Assistant might interact:
A user could alter the system via physical hardware (e.g., a keypad).
Home Assistant queries the SimpliSafe REST API every 30 seconds for data (again, currently cached or fresh depending on the system version).
Home Assistant receives near-realtime events for via the SimpliSafe websocket API.
If we consider these scenarios in a V2 system, I would expect:
This should trigger a websocket event, which should update Home Assistant pretty quickly.
This may not work as intended in a V2 system (given that cached data could be returned for quite some time until the cache busts).
Again, I would expect this to update Home Assistant pretty quickly.
Are any of these particularly inconsistent with your experience?
Let’s dig together. Unless there’s something out of our control with V2 systems, I’m reasonably confident we can figure something out.
Got it. Let’s do this: I’ll produce a version of the SimpliSafe integration that you can install as a custom component to test. Once we get everything working, I’ll officially submit it. That work for you?
@bachya - Absolutely. That’s amazing. Thank you! Let me know if you need any other info from me.
One thing that may or may not be helpful. Even though SS is not capturing the state correctly, it is capturing the event. See the screenshot below. Notice the app shows “Home” as the active state but the event shows “System Disarmed by Master PIN via Keypad 9m ago”. The alarm is off. The event captured it, but the state did not update.
I was wondering if maybe the REST polling could look at the events to see the most recent event that changed the alarm state as a way to avoid the issue with SS updates.
Tell me more about how this would work. When polling, the integration would first check if the most recent event was a stage change? And if the REST API is different, prefer what the event shows?
Also, are you able to disable the audible messages on your base station? If we do end up finding a solution, I can imagine people are going to still get annoyed by that audible message… Would be nice if we can help them figure out how to do that.
@bachya … Yep, basically what I was picturing was getting the SS events. And going through the events until the most recent is a state change and using that event to set the current state. Most events are going to be state changes but for example you could have the most recent event is “Power Restored” and next most recent event is “Power Outage” and after that is “System Disarmed”. In that scenario the current state of the alarm should be “off”. I think the three events to look for would be “System Armed in Home Mode”, “System Armed in Away Mode”, and “System Disarmed”. Find the most recent of those three events and that gives the state.
I do not believe there is a way to disable the audio for announcing the base station updating the settings (or if there is, I can’t see it). That might be problematic… My wife puts up with a lot with constant home automation endeavors, but she might draw the line at that being announced every 30 seconds.
Right. That makes me think that rather than trying to coerce the V2 REST API in a way that doesn’t anger everyone, perhaps your idea (look at the last event) might be the right route.
The question: would there be any scenario in which looking at the most recent event would create an incorrect state? Should there be some rule around it (e.g., if it isn’t older than X minutes)?
@bachya - if we are solely looking at the most recent event, then yes there could be an issue where it wouldn’t be a recognizable state. For example, this would be a common scenario for vacations:
11/23/21 10 AM - Power restored
11/23/21 8 AM - Power Outage
11/17/21 8 AM - System Armed in Away Mode
In that example, the third event is telling me it’s in Away Mode and it’s been that way for days because of vacation. So as long as it’s “most recent state change event”, I can’t think of a scenario where that would go awry.
Also - was this a somewhat recent change in the HA SS code? It used to not be an issue. I had a friend that hit a similar issue and he resolved it by restoring to an older snapshot. Curious if it’s just manifesting now or if this was something recent.
Not to my knowledge, but as a V3 system owner, I wouldn’t be in a good position to know for sure. One thought: the latest dev has a lot of new SS code that’ll go into 2021.12.0. If you’d be willing to run either dev or wait for the 2021.12.0 beta, that might give us more info.
You should be able to put a custom_components directory in your config directory. Then, you should be able to download the latest homeassistant/components/simplisafe folder from GitHub (dev branch) into it. More instructions here: Integration File Structure | Home Assistant Developer Docs
EDIT: I’ve created a new branch that alters V2 systems to only listen to the websocket. This may not be the final solution (for instance, this means that V2 systems don’t have the REST API as a fallback), but it’s a good place to start. Since this also contains the changes mentioned above, use this one as the custom component: home-assistant/homeassistant/components/simplisafe at ss-v2-alarm-state · bachya/home-assistant · GitHub
@bachya - initial testing seems to show that this version is working better. i remember a while back when you switched to the web hooks there were some issues with the web hooks failing (hence the introduction of the REST API fallback), but so far all is good with the custom component.
already light-years better! thank you!
EDIT : I might have spoke too soon. It’s fallen out of sync again. HA is showing alarm armed_home while it’s off.
EDIT 2: Is it a safe assumption that HA will use the custom component and it overrides the default SimpliSafe? The log shows it sees the component, but it seems like it’s behaving similar to the polling issue, so wondering if it’s not using the custom component.
When you go to your Integrations page, what icons do you see at the top of the SimpliSafe entry? Do you see what looks like an open box? That will indicate that the custom component is being used.
2021-11-23 19:59:02 ERROR (SyncWorker_0) [homeassistant.loader] The custom integration 'simplisafe' does not have a version key in the manifest file and was blocked from loading. See https://developers.home-assistant.io/blog/2021/01/29/custom-integration-changes#versions for more details
Is that error preventing the custom component from loading?
EDIT 1: Wow. Long day. The message literally says it was blocked from loading. The manifest file is present in the component. Not sure why it’s not being recognized…
EDIT 2: Adding this incase it’s clear there is something wrong:
You’re still using the original integration. Check out that link I shared (Integration File Structure | Home Assistant Developer Docs): you need to add a version key to the manifest in order to get it to load. Just use ”1.0.0” for the value.
Sorry about that - missed that piece. All set now - definitely running the custom component and it seems to be holding state much better now.
I just tested a few back and forth between off and armed_home and it changes within a few seconds and holds the state!
Thanks again for all the help! If it’s not a ton of work and you get a chance to try the event based fall back, let me know and I’ll load that (now that I actually know what to do )
@bachya - update from a little more time with the newest version…
The polling overriding the the state from the webhook is definitely solved (as would be expected for disabling the REST API polling on the V2 systems).
The HA state is being updated maybe 50% of the time from the webhooks. For example, this morning after disabling the alarm at the keypad, HA continued to show armed_home and the automation for morning routines was never triggered.
Similar thing leaving this morning - the armed_away at the keypad did not update the app.
I am see this chunk of logs repeatedly:
2021-11-24 08:53:59 ERROR (MainThread) [custom_components.simplisafe] Error fetching 447616 data: SimpliSafe error while updating: 401, message='Unauthorized', url=URL('https://api.simplisafe.com/v1/users/447616/subscriptions?activeOnly=true')
2021-11-24 08:54:38 ERROR (MainThread) [simplipy] Giving up _async_request(...) after 4 tries (aiohttp.client_exceptions.ClientResponseError: 401, message='Unauthorized', url=URL('https://api.simplisafe.com/v1/users/447616/subscriptions?activeOnly=true'))
2021-11-24 08:55:17 ERROR (MainThread) [simplipy] Giving up _async_request(...) after 4 tries (aiohttp.client_exceptions.ClientResponseError: 401, message='Unauthorized', url=URL('https://api.simplisafe.com/v1/users/447616/subscriptions?activeOnly=true'))
2021-11-24 08:55:56 ERROR (MainThread) [simplipy] Giving up _async_request(...) after 4 tries (aiohttp.client_exceptions.ClientResponseError: 401, message='Unauthorized', url=URL('https://api.simplisafe.com/v1/users/447616/subscriptions?activeOnly=true'))
2021-11-24 08:56:35 ERROR (MainThread) [simplipy] Giving up _async_request(...) after 4 tries (aiohttp.client_exceptions.ClientResponseError: 401, message='Unauthorized', url=URL('https://api.simplisafe.com/v1/users/447616/subscriptions?activeOnly=true'))
2021-11-24 08:57:13 ERROR (MainThread) [simplipy] Giving up _async_request(...) after 4 tries (aiohttp.client_exceptions.ClientResponseError: 401, message='Unauthorized', url=URL('https://api.simplisafe.com/v1/users/447616/subscriptions?activeOnly=true'))
2021-11-24 08:57:51 ERROR (MainThread) [simplipy] Giving up _async_request(...) after 4 tries (aiohttp.client_exceptions.ClientResponseError: 401, message='Unauthorized', url=URL('https://api.simplisafe.com/v1/users/447616/subscriptions?activeOnly=true'))
2021-11-24 08:58:29 ERROR (MainThread) [simplipy] Giving up _async_request(...) after 4 tries (aiohttp.client_exceptions.ClientResponseError: 401, message='Unauthorized', url=URL('https://api.simplisafe.com/v1/users/447616/subscriptions?activeOnly=true'))
I’m staring to wonder if the V2 systems have just run their course… In your opinion, is the upgrade to V3 worth it?
Interesting… Do those log entries correspond to the timeframe in which you checked in the morning?
Not to cop out, but I think it’s worth it. I’m very glad we upgraded. I have the expectation that going forward, all the updates, bug fixes, etc. are going to go to the V3 systems. I know it’s not trivial, cost-wise, but I really would recommend it.
@bachya - not exactly at the moment when I change the state on the keypad. They seem to be happening about once per hour.
I don’t want to ask you to go on a wild goose chase on a legacy system that might not be worth the updates.
I might mess around with the events thing a bit to see if I can hack some solution there before jumping ship on V2. Could you point me to an example in your SS library of how SS uses the new code to authenticate to its API? Any code I’ve written to SimpliSafe used their old authentication sequence.
