Well, there are currently 3 ways of controlling this integration - using panel, service calls or MQTT commands.
MQTT commands can be sent from HA automation or from third-party code via MQTT broker.
Service calls can be made from HA automation.
This integration currently does not do anything in case of alarm so it is up to you how to implement it and there are two ways:
Have automations that react to changes of state of this integration and do what’s required. Obviously it can be done in HA automation and you have access to the integration’s attributes.
Listen to MQTT state topic of this integration and do what’s required. It can be done from HA automation OR in a code that is external to HA (in which case you have no access to the integration’s attributes).
So the answer is yes if I get it right.
You can find some basic examples of automations in doc/examples/ folder.
By the way, I can see that there is something in the code that calls turn_on on entities supplied if the integration goes into WARNING and TRIGGERED states, and turn_off when it leaves them, but I haven’t paid any attention to it so far - does it make sense to have something like that at all?
for when alarm component changes state to triggered, use that to set of your sirens/flashingligths.
For when alarm component changes state to disarmed, use that to turn off your sirens/flashinglights.
At the moment I use HA to set of the sirens. And Node-Red to send notifications to phones running Ariella (HA Android App) with updates on the state of the alarm.
I’m wondering how difficult it would be to add additional buttons to the alarm panel? Such as “Arm Garage Only” or something similar. I’m not necessarily asking for you to do this, I’m just curious what all I would have to change in the code to do this? I’m not great at writing code, but I can usually figure it out with some direction. Thanks!
I understand what you mean. And when I say “button” I also mean the functionality behind the “button.” My point is that it would be nice to be able have more modes than just “Home” “Away” and “Night.” It works great as it is, don’t get me wrong.
For example, my garage is a separate structure from my home. So having the garage alarm armed while the house is not armed, would be beneficial. I could see where other people may want to arm the first floor and not the second floor. Things like that.
My other point, is that I wouldn’t expect you to build this into the alarm system because it may not be a highly desirable function for many people. But I was curious how difficult it could be for me to add it to my system. Maybe I’m wrong, though. Maybe this is something folks would desire?
I suggested a similar feature to gazoscalvertos a while ago. It was basically Implementing ‘zones’ like a traditional alarm.
Sensors could then be allocated to a zone, and the zones could be enabled/disabled on a per-arming basis.
Could anyone describe what exactly means and does that “zoned” thing as I’m not familiar with traditional alarms at all.
Also, how as a user do you see “Sensors could then be allocated to a zone” and what does “zones could be enabled/disabled on a per-arming basis” mean?
I really want to know. Link to a previous discussion will do as well
Hi AhmadK. A “zone” refers to a group of binary sensors. If any sensor in that zone is tripped, the entire zone trips. For example, I have a zone “Master Bedroom Windows”, which encompasses all the window sensors in the bedroom.
A partition is a group a zones that can be armed independently.
As mentioned above, a “zone” is a group of sensors. This could be a single room in the house, or an area, garage, etc.
Traditionally this was used so you could see which zone was tripped when an alarm had been triggered. It was also used so you could arm different areas of your house as needed.
ie. first floor, second floor, garage, areas, etc.
How I imagine it working with bwalarm is like this:
Settings > Zones > Create New zone > Select which sensors are located in this zone.
(You can create as many “zones” as you like)
Alarm panel
The zone created are displayed on the front end as toggles. These are all enabled by default. However, before arming, the user can toggle the zones on/off as needed.
Just getting started with this component. I see the instructions on the new fork say that we just need the resources folder and the custom_component, but doesn’t make mention of the panel folder. Should I be following the original instructions, or just the new fork instructions?
I’m not getting any error messages after including the custom_component, other than the warning that its a custom component and may cause problems, and I see the new alarm entity that can arm and disarm my alarm, but I can’t figure out how to access the custom alarm panel.
Well, I can hardly see a point of taking code from one place and try to configure it using instructions to code from another place (unless it says the code is identical).
The code of this integration is significantly different to the original code. And yes, currently all that panel magic happens inside, no need to have a separate folder/yaml.
@jwilliams, @onkytonk Thanks for the info.
So currently we kind of have only one zone which is always active, and you want a feature that allows user to a) create several zones (and sensors associated with them) and b) being able to select which zones are active when setting alarm, right?
That would possibly make different modes (Night/Home) redundant, wouldn’t it?
Night and home mode will still have their place in setting perimeters or disabling motion sensors.
Zones would be a more advanced function, allowing you to only arm (or not arm) one or multiple zones in your house.
