No problem, added to Github, thank you for your help, let’s move discussion there. Declaring another platform like aarlo shouldn’t matter since its separate platform. Regardless without it I get the same error.
I tried the original directions with resources/bwalarm/bwalarm.yaml and get the same issue, the reason I changed it to /config/alarm.yaml is because that was the original plugin’s directions.
the folders’ structure and naming convention has changed fairly recently so it’s in separate folders now, not in HA config.
Is it somehow possible to not arm the alarm, if certain sensors are open?
Currently I only want the sensor that I already have put into the delayed group to be able to be open when arming. The rest shouldn’t be able to be “open” while the alarm is set.
Today I experienced another thing I wasn’t aware of.
If my alarm triggers, the alarm goes off and my Xiaomi Gateway will sound a sirene. But today I did some testing and unfortunately after some time my alarm changes from Triggered back to Armed Away, wihtout my doing anything.
Can that be changed or have I messed something up?
Heeelp 
@AhmadK Thank you for the work and the effort to keep this bwalarm alive!
There is a behaviour I find a bit strange.
Say, I have two sensors:
In the following scenario:
In my opinion, in this case, the alarm should goes on immediately as Sensor1 is “immediate”. However, at the moment the alarm stays in warning state and is only triggered (if not disarmed) at the end of the warning time, despite Sensor1 being on.
Is there something that I missed? Is this the expected behaviour?
Thanks,
GV
sure. but it depends on how exactly you aren your alarm
Delayed means that your alarm won’t trigger immediately when a sensor from delayed section becomes active - useful for PIRs/door sensors by your main entrance, for example. Quite different thing, isn’t it?
It completely down to your automation as there is almost nothing that the integration itself does - it changes its state, and it’s up to your automation to react to that change.
Please create a new issue and I’ll look into it when I have time.
I arm my alarm through my lovelace interface, by using this card:
- entity: alarm_control_panel.house
type: alarm-panel
Here is my automation:
- alias: '[Alarm] Arm pending'
trigger:
platform: state
entity_id: alarm_control_panel.house
from: 'disarmed'
to: 'pending'
condition:
condition: state
entity_id: alarm_control_panel.house
state: 'pending'
action:
### Turn off gateway mute to play sound ###
- service: input_boolean.turn_off
data:
entity_id: input_boolean.mute_gateway_sounds
### Play ringtone sound in loop until arm is done ###
- service: script.play_sound
data:
ringtone_id: 10001
ringtone_vol: 1
delay: 2
### Google Home Notification ###
- service: script.alarm_arm_google
So my guess is that I should put another condition on and then set a group of sensors I want to prevent the alarm of being set if they are “open”? Or is this somehow possible within the Alarm settings?
Yes you are right. I do understand that part. Sorry if I wrote it in a way that didn’t make sense. I just wanted to state that I know if a sensoor is in that group, then it won’t be triggered while the pending is in progress. And you are right - I do use them for the entrance.
I use an automation that fires a script - which has been taken from the example with the Xioami Gateway, that I use for the Sirene (as for now):
But in the logbook it just looks like the Alarm changes to Armed_Away, I just don’t know why it switches back to armed_away. I don’t trigger that in any of the sound loop script. It happens exactly after 5 minutes:
If you want to be able to arm the alarm even if some sensor are “open” by putting them in override. Say if sensor1 is open and is in override, you can put your alarm on. Then sensor1 going to close won’t trigger the alarm. However, if sensor1 goes “open” again, then it will trigger the alarm, either immediately or after the pending time. If you don’t want sensor1 to trigger the alarm, just don’t put it in the liste!
GV
Can anyone share their bwalarm.yaml with a working MQTT config? I am using SmartThings SmartHomeMonitor (SHM), SmartBridge Hass.io add-on and MQTT Broker Hass.io add-on to send messages to/from SmartThings. I had the alarm states and commands working with the following configuration:
- platform: mqtt
state_topic: "smartthings/alarm system status/alarmSystemStatus/state"
command_topic: "smartthings/alarm system status/alarmSystemStatus/cmd"
name: "Smart Home Monitor"
payload_disarm: "off"
payload_arm_home: "stay"
payload_arm_away: "away"
I am trying to configure bwalarm.yaml the same way, but I can’t get it to send MQTT commands or receive states. This is what the YAML section in my bwalarm.yaml looks like:
mqtt:
enable_mqtt: true
payload_arm_night: ARM_NIGHT
payload_arm_away: away
override_code: true
payload_disarm: off
command_topic: "smartthings/alarm system status/alarmSystemStatus/cmd"
payload_arm_home: stay
qos: 0
pending_on_warning: false
state_topic: "smartthings/alarm system status/alarmSystemStatus/state"
Hi Green, thanks for your reply.
Let me see if I can explain this a bit better…
Lets say I’m about to leave the house and I therefore close all my doors and windows.
That means sensor1, 2, 3 are “Closed” but Sensor 4 which is the window I forgot to close will still be “open”. I then arm my Alarm, and then I leave. If a burgler comes by and enters the house through that Window, then the alarm won’t trigger. I don’t have motion sensors in all rooms yet.
So what I try to achieve was not to delay any sensors, because that part makes sense and I already have that working. I simply just want to do a “CHECK” that all sensors that are a part of the Immediate group needs to be in a closed state when arming.
Does it make sense?
It does. If Sensor4 is in the “immediate” list and not in the override, you won’t be able to engage the arm mode. Or at least that’s what I am seeing 
GV
@AhmadK - I think I found the answer - don’t know how I could misread this:
So it states that when triggered it will return back to armed_away after 300 seconds which is the 5 minute window I see. Maybe setting this to 0 will keep it running forever.
@greengolfer, well that was what I hoped for.
Even though the sensors are in the immediate group, the alarm sets when the pin is entered.
Does your alarm warns you if your sensors are in an open state?
Yes it does. I have configured some of my sensors in the override group. When at least one of those in the immediate group who aren’t in the override group is “open” I have a message from bwalarm saying that I can’t arm it.
Hope it is clear
GV
It is - I just don’t understand why mine doesn’t do that. I don’t have any sensors in the override group. All Sensors are in the immediate group except the one at my main entrance which is in the Delayed.
Maybe this is because I haven’t “upgraded” to akasma74 edition and still runs the version from Gazoscalvertos.
That’s correct.
Currently the alarm won’t set if there are open sensors in immediate or delayed groups, but it will set even if there is an open sensor that is in override group.
I don’t think so. Could you remind me what you want to achieve?
I can see no point in having sensors in more than one group unless you give me an example when that’s beneficial.
Oh man… you’re joking, seriously 
Sorry I forgot to put in a big smiley 
I am on the akasma edition.
Please read this
Add that sensor into override group and set ignore_open_sensors to True via Settings/manually in bwalarm.yaml.
Maybe I misunderstood the concepts behind those terms immediate, delayed and override… but my tests seem to confirm what I am saying.
For me, override is something that come in addition to immediate and delayed. If one sensor is in override (and also in immediate or delayed) then I can put the alarm in away (or home) mode. Otherwise I can’t.
What’s your take on this? What is “override” meaning?
GV
What is it? It’s not a MQTT switch, is it?
And your topics are strange, they should not contain whitespace.
MQTT section of bwalarm.yaml allows you to configure commands the integration (alarm) reacts to, i.e if if RECEIVES ARM_NIGHT to its command topic (weird one again), it’ll set into night mode.
And when mqtt enabled and the integration changes its state, it publishes it in its state topic.
Perhaps you misunderstood how it works as it does not send MQTT commands and receive states, it’s the other way round 
