Well, you can open a new issue on Github and provide your logs and as much information as possible about your config. I’ve never ever seen anything like that if it’s Error as I have my log level at Error.
Guys, I’m currently thinking about questions like
and
Currently the logic in this department is split between the alarm component and the control panel (what you see in your browser).
The reason is probably because the control panel controls the component via service calls and can get data from it by accessing its attributes, but there is no way to have a function like alarm.opensensors that returns True/False and then call it in the control panel and act accordingly.
And without that how would control panel know if there are any open non-overridable sensors? It can only do it itself and if there are and user says override, it calls an appropriate arm service, that’s how it works now.
The alarm’s arm services are unconditional, i.e they arm regardless sensors’ states. That’s why if you call the alarm’s arm service from HA, it just arms the alarm.
Same goes to Lovelace alarm card - (I presume that) the standard alarm card just calls a standard arm_xxx service when user clicks an appropriate button, it does not analyse if the call was successful or anything. So for Lovelace we’ll most likely need a custom card as our alarm is much more than just a standard one.
But the main question now is how to deal with all this as it seems important for people to have more control over the arming process?
After a good night sleep I have another idea: as arm_xxx is a service call, I can try and add an optional parameter allow_open_sensors to it, which is True by default.
That way if you arm it from a script and don’t want to arm with open sensors, call it with
data:
allow_open_sensors: False
With Lovelace it’s trickier though.
Anyone with some experience of creating custom cards (as I have none)?
Any other ideas/correction/suggestions?
p.s I’m about to make a release soon, just need to learn how to do that properly on Github (never done that before).
I’m fine with scripts and automation, just not sure where to begin. I can test and debug though. I have a number of Google hubs around the house and I use Google’s Voice Match and some keywords for arming and disarming. It works perfectly until I accidentally left an entry open and realized when I got home that I could arm with an open sensor!!! I do have camera’s as backup at least.
I like the current setup where the alarm control is done from the side menu in its own screen. The original author made an option to restrict access to the rest of the GUI if the alarm is armed. I think that is great because people shouldn’t have access to the GUI if the alarm is armed, otherwise they have access to switch devices etc.
If you can’t get your Roomba integrated into HA, why not place a wireless Reed/door sensor on the Roomba and dock. When it docks, it will have a “closed” state and an “open” state when opperational. You could then use these in an automation to change your alarm state.
3 Likes
My alarm can be desarmed using the service alarm_control_panel.alarm_disarm without any code. And I already added the code into the alarm.yaml
This is my alarm.yaml:
platform: bwalarm
name: House
code: '1234'
panel:
cameras: []
enable_clock: 'True'
hide_passcode: 'True'
enable_sensors_panel: 'True'
round_buttons: true
states:
armed_away:
immediate: []
delayed:
- binary_sensor.kitchen_door
- binary_sensor.hall_door
override: []
pending_time: '60'
warning_time: '25'
trigger_time: 600
armed_home:
immediate: []
delayed: []
override: []
pending_time: 0
warning_time: 0
trigger_time: 600
armed_perimeter:
immediate: []
delayed: []
override: []
pending_time: 0
warning_time: 0
trigger_time: 600
users:
# sensitive information
enable_persistence: true
code_to_arm: falseYes, that’s the way it works at the moment (you can trace it here).
I think the main reason behind it is as follows:
There are several ways to control the component:
- From web control panel
- By calling a service
- By sending a MQTT message
I think the author presumed that the control panel definitely requires passcode, so does MQTT (but it is possible to disable that).
If we speak about service calls, there is probably little point in restricting it by using a code as that’s not the way an intruder would try to deactivate the alarm.
All the structure is there and that’s mostly question of usability/level of paranoia whether to require code when using any control method or leave it to web/MQTT.
Any thoughts/suggestions?
Is there anyway of getting which sensor(s) that tripped the alarm? I would like to include that information in a push notification and possibly use it to send the respective camera feed.
- service: notify.telegram_general
data_template:
title: '*ALERT*'
message: "ALARM TRIGGERED!!! {{ states[states.alarm_control_panel.house.attributes.changed_by.split('.')[0]][states.alarm_control_panel.house.attributes.changed_by.split('.')[1]].name }}"
By the way, do you know that currently the sensor that triggered the alarm is not necessarily the same that will be reported by your automation? 
Any sensor that changed its state to active after the alarm changed state from ARMED_XXX to PENDING will overwrite change_by.
Perhaps it’s better to keep it and stop updating until it’s DISARMED or goes back to ARMED_XXX?
I’m developing an application the sends services to ha, when the user enters the code, the app simply sends the code into the service data and waits for state changes. Since bwalarm disarms without any code, this doesn’t work
…then you have a code and SHOULD use it as an attribute of your service call.
that’s just because you don’t supply one. add code to your service call and you’ll see the difference. something like
service: bwalarm.disarm
data:
entity_id: alarm_control_panel.house
code: "1234"
by the way, what’s the point of having such an app?
I supply the code into the service data field as code variable but bwalarm disarm the alarm with incorrect codes and even without code insertet into the service data.
The app is to have a digital display alarm panel in the house
Got it all up and running but the buttons look rather odd, is this how its supposed to be?
I would have liked more square buttons, or at least closer together than so spread apart
I think the best option is to open an issue on Github and provide as much info (like your config and service call’s code) as possible.
So what’s inside that wall box, a phone?
I’m afraid that’s the way it is at the moment, just don’t have time and knowledge and made it more useable than it was after the last release when they replaced paper-button with mwc-button.
You can tinker with alarm.css (as I did to get something better that Tom showed).
I’m not an expert in CSS and did it on trial and error basis 
Any expert input appreciated.
it depends on the version, yours is probably not the latest.
that’s great, but the main info is the component’s and the panel’s versions, like
could you explain what is the benefit of that HACS thing when using this component (haven’t got time to read their docs) and how to set it up?
Ah right. I still seem to have an old version of the panel:
Your Versions:
Home Assistant: v0.94.4
This Panel: v1.3.4
Component (Bwalarm): v1.1.6_ak74
Python: v(3,7,3,final,0)
Do you not include that with the component?
When you commit an update I get notified and can easily update from within HACS. Same goes for all my custom components and custom Lovelace cards. It’s a lot easier than having to trawl Github looking for updates to everything.
https://custom-components.github.io/hacs/installation/manual/
And for you in particular, to get the repository included:
https://custom-components.github.io/hacs/developer/integration/
So we don’t have to add it as a custom repository:
powerful and easy to use. I wish all components will use this HACS. Yours works well already, I just updated to 1.4 a minute ago
1 Like