You can select multiple targets in the notification editor.
If the telegram and voice integrations have the same format for their notify services that should be sufficient. If not, then you should switch to YAML editor and manually define the 2 actions.
I will take a look at this. This is not intended.
I think there are very few alarm systems that allow switching between modes.
At least the ‘generic’ HA alarm integrations don’t offer this.
Lucky for you I am planning to add such functionality.
My own use-case: I want to have the motion sensors temporarily disabled when my Roborock vacuum cleans up while the alarm is in armed_away.
I noticed that after restarting HA, the actions defined to the initial state would fire again.
I want to avoid this.
Additionally, Alarmo tries to turn off my siren every time the alarm is disarmed.
This would only be needed after the alarm was triggered.
I want to improve stuff here as well.
For example, by allowing actions to be defined on transitions from triggered → disarmed.
In other circumstances, the actions should fire only once. If you see otherwise, let me know.
Be aware that this integration is brand new (literally a month old).
It needs some time to grow mature It’s already better than anything else HA has to offer.
Let’s keep discussing on what’s missing
It seems like if one of my sensors is unnavailable and then becomes available again, even if it’s a door and still locked, that will trigger the alarm. Is it just mine?
Unavailable is an indeterminate state, meaning that Alarmo cannot judge the situation.
This considered as an unsafe situation, hence it will trigger the alarm.
I would assume the triggering occurs as soon as the sensor is unavailable, not when it is reverting from unavailable → available.
Why are your sensors becoming unavailable? You cannot really make a reliable security system with such glitches…
Pretty happy so far with the integration. I’m running it in parallel to my old, fully automation based alarm, hopefully I’ll be able to completely switch over to Alarmo soon.
I’m currently thinking about how to integrate sensor tamper switches in a nice and consistent way. Basically all my sensors (door, window, motion) have some kind of tamper detection which runs separately to their main function. If a sensor detects tampering, the alarm should always be immediately triggered if armed, regardless of mode. So for example, if armed in home mode, a motion sensor doesn’t trigger the alarm on motion, but would still trigger the alarm when tampered with.
Right now I simply created an additional binary template sensor for each sensors tampering trigger and added them as additional immediate sensors to Alarmo. That works but feels a little convoluted. Would it be a good idea to integrate such functionality directly into the component or would that be out of scope feature creep ?
I wouldn’t really know a better way.
Perhaps we could make use of the device_class: opening, have Alarmo automatically recognize it as a tamper switch and do the settings accordingly.
Currently for motion/door/window/fire sensors similar things are in place.
IMO in HA the entities are a bit ‘convoluted’ anyway.
I rather would have users assign complete devices to Alarmo, where a device can have up to 10 entities in HA.
But such thing would only work if all integrations have the device_class set correctly.
These tamper switches you are refering to, how are they represented by your integration?
Or are they represented as attributes of the normal binary_sensor?
Or are separate entities created?
Typically they will be separate entities on the same device. It really depends on the device and integration. For the camera tampering, it’s just another binary entity. For my Aeotec and Fibaro sensors it’s more complicated. Besides a binary open/close (or motion/no motion) entity, they also expose a non-binary ‘burglar’ entity, which encodes different states of the device as different numerical values. A typical zwave type encoding would be 8 = door open, 3 = tampering detected, 0 = all good. I’ve seen that encoding with several manufacturers now, but I’m not sure if it can be considered a defacto standard (probably not). And it’s probably completely different again for Zigbee or even cloud based wifi sensors.
So it’s not straightforward at all. Maybe the only practical way is to create binary template tamper sensors. But I agree with you, ideally you would just add entire devices to Alarmo and have the integration handle all security related aspects of the device.
I guess the real solution here is to have more uniformity in HA integrations.
As long as things are messy as they are now, all that we can implement here is just a workaround and not a real solution.
Regarding:
Currently Alarmo sensors only can be binary_sensor entities. But I don’t really have a good reason for it, it should work for any.
For me it’s OK to allow more entity types, as long as users can provide a mapping to safe / unsafe states.
Ofcourse a consequence is that if your sensor will suddenly have an unlucky value ‘13’, the state would be flagged as undeterminate and you get this situation.
unfortunately unavailable sensors can happen. for example: I have a board ESP32 for managing my wired sensors and siren. and very occasionally it disconnects and reconnects to wifi, at that moment they are unavailable for HA. It would be bad if that triggers the alarm and siren for that.
I’m not sure what’s the correct solution. maybe make it configurable: trigger unavailable states Yes/No.
This way users with more robust systems can go with it. And the others may accept that risk.
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”?
It’s already better than anything else HA has to offer.
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.