I have seen the same. Since HA is open source, community-supported, and supports a huge variety of components, also using your wifi network, there is the occasional hiccup in connection. It seems rather robust in reconnecting, but there can be short periods of “unavailable” or “unknown” conditions.
On a recent trip we had three instances (in 2 weeks) in which a sensor “triggered” as it changed form “unavailable” to “closed”. I am guessing that perhaps when reconnecting it defaults to “open” for a brief time than updates to “closed”. Fortunately, we are still transitioning, and only used notifications. Our siren is physically disconnected until I am confident in the system.
We are still using BWAlarm, but looking at your development as an option. So the issue is across multiple applications. Therefore, being able to not trigger on “unavailable” would be a benefit. In addition, it may be needed to require a short debounce period (1 second?) before triggering, in case the restoration of comms results in a brief “open” signal.
Unfortunately, for reasons beyond my current control, we were unable to recover the needed logs from this period (the system was restarted by our cat watcher). If I have another instance I will try to get logs.
@zbuh@ceandra Thanks for your feedback.
I haven’t seen such glitches in my house, but I can imagine the frustration this gives.
I will disabling the triggering on unavailable state by default, and add an option in the sensor configuration to choose if it should trigger the alarm.
A debounce option can be considered, but I think it will be difficult to define a period for it. A wifi dropout for example could last several minutes (depending on your router + sensor).
Yes, the debounce idea was not for the entirety of the time the wifi (or API) link drops. But rather, I suspect that upon reconnection, there is an indeterminate state, in which the channel may go from “unavailable” to “closed”) (it really is closed), or may go form unavailable to a very brief “open” to closed. If it were determinate, then all sensors on that card (each card has 6 sensors connected) would do the same thing every time. But it is only on occasion, and only 1 sensor “tripped” each time. Different sensor each time. I have a total of 5 cards, about 23 window/door sensors (others are motion, fire, etc). In 2 weeks away, had three different sensors “trip” briefly on three different occasions.
Therefore, I was thinking a 1 second, or even 100 ms debounce would be long enough for the reconnecting sensor to “read” properly.
Real answer is getting to a reproduceable problem and diagnose/fix the problem.
I am using ESPHome to manage the ESP NodeMCU cards.
Yeah agreed. Thinking about it some more it would probably create more problems than it would solve. I think the current approach of adding binary template sensors for tampering works well enough. It’s not as elegant as it could be, but hey, lots of thing in HA are a bit like that
Woah I’m not sure if I would trust such a setup for a security system. In any case, if you guys add some way to ignore the unavailable state, please make sure it can be switched off. I think it’s important to be able to trigger the alarm when a sensor goes unavailable. One of the easiest ways to blind a wifi sensor is to create localized 2.4GHz interference around it (there are even smart phone apps that are specifically designed to do this), just long enough to open and close a window or door to get in.
I’m moving from an apartment to a new house soon and I’m prepping my Alarm ahead of time. This tool has been so user friendly and help with a lot of head-ache, so thanks for putting in all this hard work!
I hadn’t even thought about the motion sensors going off with my Roborock, so thanks for the reminder I look forward to seeing that feature soon.
Hey, sorry for being a noob, but how would you go about using the alarm card to receive this sort of message that tells you an sensor is open and stops arming straight away until you choose to “Continue” or “Cancel”?
Good to hear!
It’s brand new with a couple of ideas not worked out yet.
Please give it some time to grow mature
I think it depends on your sensors, if you have ‘pet friendly’ sensors it might work fine.
But for mine, they consistently get triggered, very annoying.
This feature is one of the next steps, will be added within a couple of weeks.
The alarm card in HA is not customizable. It only has arm / disarm buttons, I cannot create some interaction / feedback.
If this project gets a lot of enthusiasm I might take the effort to create a dedicated Alarmo alarm panel card.
It could display the states of your sensors, tell you what’s blocking, display a countdown, etc.
But I would like this component to remain independent of such card.
Greetings,
Looking at switching from Bwalarm to Alarmo so I can keep up with Home Assistant updates. I currently have Fire tablets at the entrance doors and use Fully Kiosk on them. They are wife friendly as they display pictures and time/weather, and then a quick press gives her just the Bwalarm panel for arm/disarm. Is there a way to just show the Lovelace/Alarmo card much the way we do with the old alarm.html page? Thanks.
As already mentioned I too think it would be best to handle this with a duration based trigger, so if the entity is unavailable for longer than x seconds, then trigger the alarm
Currently Alarmo only lives in the background.
So its only used for configuring the alarm behaviour, not for everyday usage.
For creating an alarm panel display, I recommend to make use of Lovelace.
The Lovelace platform has built-in cards for alarm panel, sensor states, camera, weather etc. and allows users to customise the layout.
I’m not planning to create a dedicated frontend as BWalarm did.
It would require a lot of maintenance, and it feels a bit like reinventing the wheel.
For feedback to the user (e.g. entering a wrong code), I recommend to look into browser_mod.
You could create a popup notification that would automatically disappear after a while.
The text in the below screen shot seems confusing to me. ‘Leave time’ and ‘entry time’ sound right but the explanation afterwards does not seem to match. Why does it mention disarming the alarm after the time is up? Surely after those times expire the alarm should trigger if a sensor is activated…
The checkbox is OFF by default.
I made this choice because I sensed that the triggering of the alarm is annoying to users who have sensors with connection glitches.
Still I recommend to keep this setting ON, because the protection of your house cannot be guaranteed while the state of the sensor cannot be determined.
Regarding the request for adding the option for filtering out short glitches in sensor states
I decided this functionality does not belong in Alarmo.
If your sensors experience connection issues, the cause of this should be identified and dealt with.
I don’t experience such problems in my house, and I would be happy to share my hardware set-up if desired.
If you are convinced the glitches cannot be avoided, but you still want Alarmo to trigger when a sensor is unavailable for longer time, you will have to find another way.
Perhaps a possibility would be to create a (template) binary_sensor that represents a filtered version of the original.
As always: please let me know if you have issues with using Alarmo, or ideas for further improvement.
Totally agreed with your statement. To achieve an high quality/security in this project, it should have it’s scope well defined, and not try to answer all the “questions”
Would it be possible to add a seperate trigger mode or similar for smoke sensors?
I see I can add smoke sensors and they’ll immediately be toggled to ‘Always on’, but I’m missing the options to schedule notifications/actions for the smoke sensor that is seperate from the burglary sensors.
Use case would be that I’d want different notifications for a possible fire, also a different audible and visual warning at home. The burglary alarm is set to be as disturbing as possible with deafening sounds and constantly flashing red lights to disorient, but I’d want a fire alarm to turn all lights to full brightness for max visibility, toggle off certain switches and turn on a different siren.
I’m completely aware that this can be setup seperately, just suggesting it would be a great addition for this component
This is a bit of a tricky subject.
As you probably know, currently you can define actions/notifications when alarm is triggered, and if desired you can differentiate between the arm modes.
So, triggering from “armed night” can have different response than triggering from “armed away”.
When an always-on sensor is activated, the alarm switches from state “any” to state “triggered”.
So with what’s currently in place, the response you will get when an always-on sensor is activated, depends:
If alarm was disarmed: only the actions configured for the triggering of the alarm, without restriction to any mode, will be executed
If alarm was in armed night: only the actions configured for the triggering of the alarm, restricted to mode armed night, will be executed (+ the ones from item 1.)
If alarm was in armed away: only the actions configured for the triggering of the alarm, restricted to mode armed away, will be executed (+ the ones from item 1.)
So I agree with you that there is room for improvement.
It is desirable to be able to link actions to a certain event, such as the activation of an always-on sensor.
It leaves me with some questions though:
Would it matter which type of sensor caused the triggering of the alarm? The response of a fire alarm should be the same as a flood or gas alarm?
Would it matter when the triggering occurs? If no one is in the house the same should happen as when you’re at home having dinner? And how about day time vs night?
I have a feeling it will be difficult to satisfy all needs.
I don’t want the actions editor to become a duplicate of the HA automations UI though.
Would like to keep things as minimimalistic as possible.
I have a similar situation as @sondreen. I’m using a number of small, yet extremely loud sirens inside the house. They create a level of sound pressure across most of the house that causes extreme discomfort and just instinctively makes you want to flee the things. These are only activated on armed away mode. Their main function is not to alert us, but to make a possible burglars stay as painful as possible.
So obviously I do not want these sirens to activate when a fire is detected. I have separate alerts for that (both visual and audible, but of course not as deafening loud as the intrusion alert).
That said, in my personal opinion, this is out of scope of an alarm component such as Alarmo. In fact, I have the fire / smoke / leak things on their own automations, completely separate from the alarm and security system. I think a component should only do one thing - but do it really well.
Sorry if this has been answered before.
If I want an open sensor to prevent the arming, how do I set that feature?
I have seen in te “Action” conditions that there is a “Failed to arm” state. How do I get to that state?
My ultimate goal is to call a service when arming is not posible because one of the sensors is on.
I’m not sure if I would trust such a setup for a security system. In any case, if you guys add some way to ignore the unavailable state, please make sure it can be switched off. I think it’s important to be able to trigger the alarm when a sensor goes unavailable. One of the easiest ways to blind a wifi sensor is to create localized 2.4GHz interference around it (there are even smart phone apps that are specifically designed to do this), just long enough to open and close a window or door to get in.
I look forward to seeing that feature soon.
