Bwalarm (akasma74 edition)

I think not.

My understanding is as following (please correct me if I’m wrong): there are three essential sections where sensors can be used: immediate, delayed trigger and ignored (house mode).

When the alarm is armed any sensor in the immediate section will trigger the alarm instantly.

A delayed trigger sensor would allow for 20-30 seconds before triggering during which time the alarm needs to be disarmed (ie. the main door sensor; you enter the house and have some time to input the alarm code or exit the house, arm the alarm and the 20-30 seconds to exit).

Ignored sensors are the ones like the PIR on the second floor or in the bedroom and will not trigger the alarm if the alarm is in house mode. However, these sensors will instantly trigger the alarm if in away mode.

If you have a open window/door sensor that is faulty and want it to only trigger if there is movement from PIR sensor in the room, it is unlikely to find a solution: say the window is open/closed and there should be a time delay until the PIR sensor will trigger the alarm, then the open window sensor will never trigger the alarm (only PIR sensor will do it).

What I would suggest (assuming you want the alarm to remain in armed mode after the window is open/closed; if using this sensor in delayed area then you would need to disarm the alarm in 20-30 seconds) is either:

  • include the current open window sensor in ignore section; thus it will not trigger the alarm if in house mode but will immediately trigger if in away mode;
  • set a template binary sensor that is triggered if the current open window sensor is not reset within 5 minutes (ie by pressing a wireless smart switch or a input_boolean in the frontend); this is actually the opposite of your initial question, as the open window sensor will trigger the alarm however only after 5 minutes if the user doesn’t take action.

Hope it makes sense.

There are currently 2 main sensors’ groups: immediate and delayed.
Any sensors that can be active WHEN one sets the alarm should be included in override group to avoid Open Sensors warning dialog. It does not affect reaction to these sensors in any armed mode and they will always trigger the alarm immediately or after warning_time depending on which group they’re in.

I think your initial solution (template sensor) should work but cannot comment on the Bayesian sensor as I’m not familiar with it (yet :slight_smile: )

My bad.

So basically, to have what I’ve described as ignored I should include in armed_away immediate and not include in any section of the armed_home, right?

Have anyone fund a video tutorial on how to setup this after installation? Would help a lot, a bit lost here.

well, I don’t know as I don’t quite get the goal :wink:

Sorry, there is no such thing yet (should I add it to the todo list? :wink: ).
What help do you need?

I would like to cover (pretty basic):

  • some overal things; set pincode, how arm away/home works, show numpad on “frontend”/lovelace
  • how motion sensors are handled (delay, trigger etc)
  • how the motion sensors trigger a siren (when armed)
  • how the motion sensors trigger a email or/and a notification when triggered)
    -reset alarm after it has been triggered

Im willing to donate eur 50 for this

Well, it’s doable, more likely in September when I’m back from hols.
In the meantime, you can ask here/pm me if you have any specific questions.

Would be really great, appreciate your effort in the project!

It’s possible to have 2 separate alarm with this component? I use 2 alarm, one for my house, one for my Garage. Thanks

I haven’t tried that yet and suspect that in the current version it won’t work for technical reasons (custom view creation), but in the (near) future it should be possible.
You can test it for yourself with the release prior to HACS.

A new release is available to try.
It contains mainly 3 bug fixes.

I’m a little confused about this statement in your repostiory instructions on updating through HACs:

Bear in mind that if you use this method, it only updates custom_components/bwalarm/ folder and ALL user data inside that folder will be lost upon every update!

I thought all user data for this component are stored in the /resources folder, as per the note in updating manually?

Please note that you DON’T need to overwrite resources folder in Home Assistant structure as it contains your integration’s configuration file (and possibly some additional resources).

Basically, can I add bwalarm in HACS (to get this latest update) over the top of my manual installation without losing my settings?

that’s correct. the note you’re referring to is for any HACS user that would try to use the HACS folder for any user data. I thought it’s good to mention as not anyone is aware of that.

I’d say yes. If you try and it works, you could even update the Readme.md :wink:

1 Like

I added bwalarm to HACS upgraded, restarted and cleared my browser cache. All appears to be well. None of my manual install settings were over written.

PR created for a short note about this in the readme.

1 Like

Thanks for the update!
The keypad on my Lovelace view is now back :smile:

Is it possible to run 2 types of alarm in 1 home assistant configuration?
I now have this in the bwalarm.yaml:

- platform: bwalarm
  name: Alt Thuis Alarm
  code: '1245'
  panic_code: '0000'
  alarm: automation.alarm_triggered
  warning: automation.alarm_warning
  armed_away:
    pending_time: 30
    trigger_time: 120
  armed_home:
    pending_time: 10
    trigger_time: 120
- platform: manual
  name: Thuis Alarm
  code: 4565
  pending_time: 30
  delay_time: 5
  trigger_time: 120
  disarmed:
    trigger_time: 0
  armed_home:
    pending_time: 0
    delay_time: 0

The manual platform works, but bwalarm not…

This component is not working

Check the Home Assistant log for more details.

This integration: v1.10.2

Home Assistant: v0.97.2

However, no info related to bwalarm can be found in the log

Ok, after scanning the existing issues it seems to be related to the “-” before platform. No time to look into this but might try once to remove 1 platform to see if this solves my issue. However, it would be nice to have the possibility to use 2 platforms, at least for testing purposes.

Well, I can accept the it’s nice to have some extra features, but at the moment I have no justification to change behaviour of this integration just because of other integrations mentioned it this integration’s config file - I personally would store them separately as they have no relation to this integration at all. Or am I missing something?

It might be resolved somehow in the future, but again, no promises atm…

I have had the same issue using the old version of this integration using the arlo platform as an alarm entity.
Same issues and as far as I know - it haven’t been solved.

If I get it right, it’s down to YAML syntax, not this integration.
When I say “it might be resolved”, I mean that this integration might have a separate config file, that’s the only way to resolve it properly afaik.