Sector Alarm

Great work @gjohansson! After implementing your component via HACS though, I experienced missing notifications and strange behaviour in the regular Sector app, in which the alarm and lock history would not show. Could this possibly be related? That your app is spamming the API or such issues?

Yes. Unfortunately this is the case that by implementing this several notifications and other things in the app is delayed. Still works but significant delays into the app.
Anyway the api connection in the integration needs to be rewritten somewhat and hopefully that will solve this problem. It’s on my todo.

However to be clear it only has an effect on the history and therefore also on the notifications of the official app. Turning on/off alarm, locks etc. works fine.

Yeah, I noticed this as well. I hoped I could work around it by creating a dedicated “App user” in the settings of the app, but unfortunately it did not help.

Install the latest beta (v0.2.0-beta2) and give it a try. The connectivity to the api is rewritten so maybe it would now work better (less spamming).
Will of course test myself more before releasing but always welcome with some extra checking.

Hey, thanks a lot.

I have now installed v0.2.0-beta3 and reconfigured with config flow.
I will report back if I find anything.

So far I really like that everything as added as devices where I can add area and so on, while the default name for the entities is the same, so history and existing configuration is intact.

BTW: What is the “Default 4-6 digits. Don’t change” field which is pre-filled with “^\d{4,6}$”?
There is also a small typo in the last checkbox: “dorrlocks”.

I have contacted Secor Alarm about that and they said that “it could be because you always use the webpage”.
So their proposed solution was to use the panel a few days to get it all to work.

Sounds like a made up solution, but it seems to work fine now. Not sure if that is because they did something after I contacted them or if that was because of the “panel solution”.

The reason for the delay is that the constant polling making the alarm system “busy”. The integrations need ease with the polling timer, especially for the temperature.
This is compensated and adjusted with the Sector Alarm app and web but when this integration is just hooking into the API there is no control.
Remember guys Sector Alarm has no official public API so when you use this and complain to their Customer Service and possibly mentioned some home automation setup, they don’t know the technical backend limitations.

Thanks for the typo, I will try to remember to correct it :slight_smile:
Regarding the other question it’s a regex so it allows 4-6 digits to be used as code. Normally it should be 6 digits but I think also sometimes from legacy 4 digits were allowed.
I was considering to remove it from there completely as I don’t see a reason why someone would change it.

Thanks. I was just about to write to @Hellis81 to not call customer service and make inquiries.
I guess you’re right on the polling but I also rewrote the code for the api so I think it’s more “relaxed” now compared to before and possibly even the push messages works better (I have removed them all myself so don’t know, will test before releasing the new version).

So I have only been testing v0.2.0-beta3 for 2 days, but unfortunately the push notifications still does not work, and the History in the app is still not correct.

I think I will remove the integration for some days just to confirm 100% it is the reason, and then reinstall it without the temperature sensors to see if it works better. And I will of course test any new versions when they are available.

I removed the integration today, just so I can verify for a couple of days if the app/notifications works as normal without it in my system.
While removing the integration i noticed a small bug (integration tries to unload locks even if you don’t have any locks configured). I opened issue #13 for this.

Hi,

Have been using sector alarm for a while, it is great! Though faced problems after upgrading home assistant to version “core-2021.1.4”.

“Home Assistant OS 5.10” on Raspberry Pi 3 Model B+.

Have been seen some timeout errors with previous versions, but now sector alarm does not load at all. Log shows:

WARNING (MainThread) [homeassistant.setup] Setup of sector_alarm is taking over 10 seconds.
ERROR (MainThread) [homeassistant.setup] Setup of sector_alarm is taking longer than 300 seconds. Startup will proceed without waiting any longer

Files under “custom components” are latest. Have this setup in configuration.yaml:

sector_alarm:
  email: !secret sa_email
  password: !secret sa_password
  alarm_id: !secret sa_alarm_id
  code: !secret sa_code
  thermometers: false
  alarm_panel: true
  #locks: false

Any suggestions how to solve?


EDIT: believe found solution, if anyone is seen same problem, can try:

  1. Copied asyncsector folder from “https://github.com/mgejke/asyncsector” to "custom_components\sector_alarm\asyncsector"
  2. Modified "custom_components\sector_alarm\asyncsector\asyncsector.py:
         with async_timeout.timeout(10): --> with async_timeout.timeout(30):
        with async_timeout.timeout(10) : --> with async_timeout.timeout(30):
  1. Modified "custom_components\sector_alarm\__init__.py":
    from asyncsector import AsyncSector --> from .asyncsector import AsyncSector

Seems to work on couple of restarts, hope it stays tthat way…

There is also GitHub - gjohansson-ST/sector: Integration to Sector Alarm for Home Assistant, also in HACS

1 Like

I just installed this component, and started automating the alarm usage. We have not really used the alarm much before, so before I start triggering my alarm and bothering all our neighbours, I just wonder if any of you can share your experiences.
Basically I want to auto-arm the alarm when we are all away. Detecting if we are home or not works fine, and has been in use for other automations for a couple of years, so I am not worried about that.

However, what might happen is that we leave home without closing all the doors/windows (we live in an apartement, several floors up, so it is not really a big worry). I have added magnet-sensors to the relevant doors and windows, and conditions in the automations to check if they are all closed before auto arming. And that seems to work fine. It will not automatically arm the alarm if they are left open.

But what happens if we leave home with an open window, and then someone decides to manually turn on the alarm from the app? Will the alarm then trigger immediately?

I have created the an automation that hopefully should avoid this kind of problems:
(simplified version)

- alias: Alarm dont arm on open veranda
  trigger:
    - entity_id: alarm_control_panel.sector_alarmpanel
      platform: state
      from: disarmed
  condition:
    - condition: state
      entity_id: binary_sensor.verandadoor_open
      state: "on"
  action:
    - service: alarm_control_panel.alarm_disarm
      target:
        entity_id: alarm_control_panel.sector_alarmpanel

But will the alarm go off before this automation will be able to disarm it if it is armed from the app or web?
Or will the state go from “disarm” to something else in time for the automation to kick in before the siren starts blasting?

My experience is that when you arm the alarm from the webpage/app/Home Assistant there is no check if doors and windows are closed.
It only does that when done from the physical alarm panel.

Perhaps it’s different with different models of the alarm.
But we have left home with the porch door open and the alarm was armed but it didn’t trigger.
I assume, at least the model we have, only triggers on the sensors changing state.

We arm the alarm when everyone is out of the home, and we disarm based on zone, distance from home and wifi connection, whichever comes first.

At night it’s armed when all lights are turned off, and disarmed at a fixed time in the morning.

Thanks for the response. I believe my alarm works the same way. And it is the lack of a check for open doors and windows when arming the alarm from either HA, the app or the web page that troubles me.
So I try to emulate that with an automation that is supposed to disarm the alarm agan (and notify us, I just skipped that part) if someone tries to arm the alarm from the app (or manually in HA, or the web) while the door is still open.
But I don’t know if that automation will actually kick in before the alarm is triggered and the siren starts.

  • And I was hoping I did not have to test it as it is such a hassle when the alarm actually goes off.

If there is a grace period where the alarm state in HA is no longer “disarmed”, but before it is triggered, even if it is armed from the web or app.

The only grace period is the pending state.
That occurs between pressing arm and when it is armed (and active), that time the panel is beeping.
During that time you can disarm the alarm.
The problem is that since the alarm is cloud and polling you may not even see that pending state before it’s armed.

You could have two (or three) scripts to set the state of the alarm (disarmed, armed home, armed away) with a condition and as action the setting the state with code as data.

This means it won’t set the alarm, possibly you could set up a choose and have it send you a notification.

But you will also have to store the pin in the config of HA.

Personally I’m not worried about the check not being done.
Only if the windows and doors can move with the wind I would be worried.
Otherwise you still have the motion detector(s).
Plus an open door/window usually signals “I’m home”, and it’s rare someone breaks in when you are home.

Thanks again,

Setting the alarm using an automation is not what worries me. It is if I or my wife “accidentally” arm the alarm using the app while a window or the veranda door is still open.

E.g we leave home, and forget to close a window. After we left, the automation that tries to arm the alarm won’t run because there is a condition there checking for open windows. That is fine.
But then a bit later somebody checks the app, realizing the alarm is not armed, and just click “arm” in the app.
THEN the alarm will probably go off because the window is open.
Is this assumption correct?

If so - that is the use case I am trying to avoid with the above automation. I am just not sure it will actually work the way I hope.

It has never happened here.
The alarm is armed but it’s not triggered by the open door.
I assume if I was to close the door then open it again it would trigger. But just open when you arm does not trigger the alarm. Perhaps your alarm works different.

Thanks again.
I guess I’ll just have to test it out then, and see what happens if I leave a window open and arm the alarm using different methods.

(And maybe warn the neighbours first).