Bwalarm (akasma74 edition)

ceandra · April 3, 2020, 5:20pm

Thank you for continuing to manage and update this system!

I have installed version v1.12.3 on HA v0.107.7, and am using Konnected boards. A few questions:

I used your automation file, with changes to the notify to fit my case. However, it appears that the siren is set to on in triggered, and set to off in disarmed. What turns the siren off at the end of the 10 minute sounding? Do I need to have an automation for when it leaves the triggered state? Or does it cycle through disarm and then to armed? (I have not physically connected the siren yet, still wiring things up).
My alarm will notify me through my phone (works well), and the siren goes off to annoy neighbors. Is it possible to adjust the siren on time based on time of day, through an automation? I would like to make a shorter siren on time from say 10pm to 7am.
I have had cases of an improperly locked window opening and closing in the wind, and therefore repeatedly setting off the alarm (old alarm system). At least with HA I can manually investigate then disable (override) the offending switch (I also have cameras so I can take a look before making decision). However, this always seems to happen late at night when I am offline or otherwise cannot respond. IN the past it meant getting someone with a key to physically go and check it out, then disable the alarm. Is it possible via automation or script to disable a sensor (override) that caused an alarm (or that caused say 2 or 3 alarms) so the repeated siren stops until investigated? Obviously this makes the system less secure, but would make my neighbors much happier.

Thanks again for your awesome work on this!’
Chuck

AhmadK · April 3, 2020, 5:55pm

generally alarm just changes states. it’s up to you to add all automations based on your alarm’s state. so the answer is “you”/“nothing”
for example, you can add an automation that switches your siren off when alarm changes state from triggered to any of arm states. think the examples would do with this addition, will update it.
on the other hand, there is alarm variable here - have you tried it?

based on my previous answer - yes, of course! create an automation that switches your siren on, delays for a set time (template) and switches the siren off.

probably not. what will be the logic of that, can you formulate?

ceandra · April 3, 2020, 5:56pm

Answered question 1 through testing. After trigger and alarm period, the alarm goes back to armed_away, but siren stays on. Added automation for “from: Triggered” and turn off the siren, all is good.

Thanks
Chuck

ceandra · April 3, 2020, 6:05pm

Thanks. I will look at the alarm variable, that may simplify things!

On third one, lets take the simple case:

armed_away is set
Alarm triggers on window_5
alarm is in triggered mode, siren sounds for 10 minutes
Alarm returns to armed_away mode, BUT, sensor window_5 is in override (regardless of whether it is still open when alarm returns to armed mode). I other words, if I could formulate an automation to change sensor 5 to override instead of instant
Alarm disarmed through keypad or remote app. sensor window_5 (and any other sensors that may have auto-moved to override) are returned to instant response for next time the alarm is armed.

A more complicated case would be to track trips based on a given sensor (Window_5 in this case), and after the alarm has tripped 3 times on that sensor without being disarmed, assume the sensor is flaky and move it to override as above in 4 and 5

Thanks
Chuck

AhmadK · April 3, 2020, 6:13pm

the simple case assumes the alarm put every sensor that triggered it in “ignore list” until it’s disarmed, right? (override is already used here and has a different meaning - it means a sensor which state the alarm ignores when setting (not always), check override config variables)

don’t know what to say about the more complicated one… don’t think it’s a good idea to have a flaky sensor on a permanent basis so you’ll deal with it when you disarm your alarm. the thing is adding things like this makes the code more complicated and increases risks of misbehaving. do we need it from a security component?

ceandra · April 3, 2020, 6:15pm

PS: I just tried the alarm variable, worked great.

So, instead of an automation that runs the siren for a given time when triggered, can I run an automation at 10pm and another at 7am that changes the trigger time value? Then I can continue to use the Alarm value in bwalarm for the siren.

Thanks
Chuck

ceandra · April 3, 2020, 6:19pm

The simple case means putting the sensor that triggered the alarm into the “ignore list”, until disarmed. Correct.

The complex case just means you give the sensor a few chances.

In my case, it has (3 times in the past) been a window that was not latched (casement window) that begins moving in high winds. Better training of occupants is the answer! But, since it has happened several times…

The simple case would silence things until I can look at it remotely, so perhaps that is the best case. So is there an automation to put the triggering sensor onto the ignore list?

Thanks
Chuck

ceandra · April 3, 2020, 7:00pm

I did play a bit with changing the value of trigger time while the alarm is armed. However, as soon as it triggers, the trigger time is reset to the value in bwalarm.yaml. Therefore, I’ll need to go with your original suggestion of a timed automation to turn on and then off the siren.

I suspect that it will be similar if I try to set a sensor to the ignore list on the fly?

Thanks
Chuck

AhmadK · April 3, 2020, 8:38pm

that’s correct, currently you cannot change it dynamically.

I don’t know. What do you call “ignore list”?
If you change something via Settings, it’ll possibly be picked up by the alarm immediately.

err… I don’t quite follow you. could you explain?

… remove that sensor from the alarm and rely on say, motion sensor in that room?

well… of course it’s possible, but do we have a valid use case here (as HA devs like to say… )?

the issue is there is no ignore list

ceandra · April 3, 2020, 9:04pm

Thanks for all of your feedback.

I think the easiest solution will be as follows:

Create a new state “alarm_previously_triggered”
Upon triggered, check previously triggered state (condition). If not, then turn on the siren, and set the previously triggered state. Turn on siren for length of time depending on time of day.
When disarm, clear previously triggered state.

Thus, the neighbors only get bothered once, but the alarm will continue to send me notifications each time it is triggered.

This is the simplest workaround and does not require new features.

Thanks
Chuck

AhmadK · April 3, 2020, 9:23pm

well, if you post your code I’ll be able to say something.

ceandra · April 3, 2020, 9:34pm

Not coded yet, just thinking out loud! I’ll post when I get it done.

Thanks again for your patience and explanations

Chuck

ceandra · April 3, 2020, 11:05pm

OK, I think I have a set of automations that do what I want. During an armed session, the outside siren will only trigger once, limiting the annoyance of neighbors, but getting their attention. After that, each new trigger will notify me via cell phone platform, but will not sound the siren. If I disarm, then re-arm the system, it will once again sound the siren on the first violation.

I put the following in the configuration file:

#Add a boolean to keep track of previous trigger in current armed cycle
input_boolean:
  previously_triggered:
    name: Track if alarm already triggered
    initial: off

I then added the following automations:

- id: alarm_disarmed
  alias: '[Alarm] Disarmed'
  trigger:
  - platform: state
    entity_id: alarm_control_panel.house
    to: 'disarmed'
  action:
  - service: notify.notify
    data:
      message: 'Alarm Disabled'
  - service: switch.turn_off
    entity_id: switch.siren_outside
  - service: input_boolean.turn_off
    entity_id: input_boolean.previously_triggered

- id: alarm_triggered
  alias: '[Alarm] Triggered'
  trigger:
  - platform: state
    entity_id: alarm_control_panel.house
    to: 'triggered'
  action:
  - service: notify.notify
    data:
      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 }}'
      title: 'ALARM TRIGGERED'
  - condition:
    condition: state
    entity_id: input_boolean.previously_triggered
    state: 'off'
    
  - service: switch.turn_on
    entity_id: switch.siren_outside
  - service: input_boolean.turn_on
    entity_id: input_boolean.previously_triggered

This all seems to work well. I will tackle the duration of the siren later. For now it turns off after the triggered period ends.

Thanks again
Chuck

AhmadK · April 4, 2020, 4:56am

yeah, looks good to me!
you see, when alarm is not really tied to anything, it’s all driven by changes in state and then you as a end user can build any logic - limit is your fantasy. and that’s cool

glad that you sorted it swiftly and thanks for sharing your ideas and your working code with the community - that’s what we need this topic for!

p.s it won’t change anything but I’d remove that initial: off from previously_triggered - the component is designed to survive HA restarts but your config isn’t atm

ceandra · April 4, 2020, 5:27pm

Thanks for the suggestion.

I removed the initial state. I also moved the reset of the flag from disarm to each arm (away and home), so that the state is known when arming (i.e., when arming, set previously_triggered to off).

Thanks
Chuck

ceandra · April 8, 2020, 9:42pm

Hello:

I have version v1.12.3 on HA v0.107.7, and am using Konnected boards. I just got a new cheap Android 9 (Pie) tablet for wall mount. I have installed Home Assistant app, as well as FullyKiosk app to limit access to just HA app.

I created a limited HA account (user) for the wall tablet, and set it to “always hide sidebar”. In the alarm setup, I selected to Hide Sidebar When Armed.

The sidebar is hidden, but it is still accessible by swiping right on the left edge, even when the alarm is armed. This gives access to the Lovelace interface, where the siren can be turned off.

Is there a way to prevent access to the side bar, for this one user (preferably), either all the time or when armed?

Also, unrelated: I have a few windows open. I override them setting the alarm (testing purposes). Then, with alarm set, if HA reboots (Raspberry Pi), those sensors trigger as “open” and the alarm triggers. The alarm is (correctly) coming up in the armed home state that it was in before the reboot. However, the override that was used does not re-override. I could try auto over-ride, but would rather the user have to approve any over-rides. Perhaps this is a limited problem, as we would rarely if ever have to override, except during testing such as this.

Finally, is there a way, in a given user, to have Lovelace start in the alarm screen, so that if tablet reboots is comes up in alarm screen?

Thanks
Chuck

AhmadK · April 8, 2020, 9:53pm

thanks for your feedback.
to be honest with you, I know that the “hide sidebar” is not working properly, mainly because it’s still using the old method and since then HA’s interface has changed dramatically. the trouble is I haven’t investigated it further as a) anyone who knows how will get through anyway and b) ordinary burglars would rather smash the tablet

All I can say atm is you can try built-in HA features to restrict dashboards/views to certain users or custom header component - that the choice the frontend devs gave me when I enquired.

I also know about the issue with restarts and open sensors, it’s on my to-do list. Just don’t want to rush as all changes should not break anything.

With the latest HA release you might be able to do so, check it out.
I use WallPanel for Android App and it just navigates to an URL I provide (http://hassio.local:8123/alarm) or HA’s ip address instead of name.

ceandra · April 8, 2020, 9:57pm

Thanks for quick response!

I will try Custom Header, looks like it may do what I need

On the Tablet, maybe the “secret” is to use a URL,a s you suggest, rather than the HA app. I’ll try that. The Fully Kiosk system has browser capability, so that may be best way to go. I like the Fully Kiosk because it will wake the tablet when the camera senses motion. But if that does not work out, I’ll give WallPanel a go.

Thanks
Chuck

AhmadK · April 8, 2020, 10:15pm

WallPanel can do both things (but mine struggles to detect motion when there’s not enough light - but then I wake it up via MQTT/REST when nearby PIR/door sensor triggers). Take a look at the website, it’s quick to read.
It has some issues but I’ve been using it for 2 years now and other options are less attractive to me (keep checking them from time to time). YMMV

rgregrowe · April 9, 2020, 12:47pm

From the tablet, go into the sidebar, and then down to your account and select the always hide sidebar. The option, at least in my case with two tablets and fully kiosk, is tablet dependent and not permanent. If you restart the tablet, you’ll have to do it again. It does prevent the sidebar though.

Greg