YET another take on an alarm system


#1511

Only binary sensors are supported.


#1512

but it supported custom states in the old version, do you think it’s definitely gone now?


#1513

¯\_(ツ)_/¯ Dunno.


#1514

Awesome alarm system! I have just one problem with it. I have an automation that turns the alarm off when I arrive home, but I keep getting an error of Invalid code. It still disarms the system, I have tried the code in the ui and it works fine.

- alias: Disarm the house when blah arrives home
  trigger:
    platform: state
    entity_id: binary_sensor.blah_bayesian
    from: "off"
    to: "on"
  action:
    - service: alarm_control_panel.alarm_disarm
      entity_id: alarm_control_panel.house
      data:
        code: 1234

DEBUG (SyncWorker_27) [custom_components.alarm_control_panel.bwalarm] [ALARM] Invalid code given 1234
DEBUG (SyncWorker_27) [custom_components.alarm_control_panel.bwalarm] [ALARM] Alarm changing from armed_away to disarmed

Can anyone see what I am doing wrong?

thanks


#1515

Do you mean that it disarms the alarm either way, but you get that Invalid code given only when your automation triggers? And the code is actually right?

By the way, what version of alarm are you using? I cannot reproduce it on (see custom_components/alarm_control_panel/bwalarm.py)
VERSION: 1.1.3
MODIFIED: 13/11/18

I made a script with sequence as your action, and it works as expected - wrong code is reported, on right code it disarms.

Are you having log level of your alarm set as debug? It’s not by default…


#1516

From the alarm code I presume that not only binary sensors are allowed.
Have look at these attributes (case-insensitive) and try to change your code if necessary:

“supported_statuses_on”: [
“on”,
“true”,
“unlocked”,
“open”,
“detected”,
“motion”,
“motion_detected”,
“motion detected”
],
“supported_statuses_off”: [
“off”,
“false”,
“locked”,
“closed”,
“undetected”,
“no_motion”,
“standby”
]


#1517

because of the alarm.html:
case ‘message’:
switch (entry[2]){
case 0:
return ‘disarmed the alarm’;
break;
case 1:
return ‘Disarm attempt failed, wrong code!’;
break;
case 2:
return 'The alarm has been triggered! Sensor: ';
break;
case 3:
return ‘set the alarm in Home mode’;
break;
case 4:
return ‘set the alarm in Away mode’;
break;
case 5:
return 'Alarm has been tripped! Sensor: ’ ;
break;
case 6:
return ‘Panel Locked’;
break;
case 8:
return ‘set the alarm in Perimeter mode’;
break;

The easiest way to get the sensors’ names is to add + entry[3] after those strings ending with Sensor: like this
return 'Alarm has been tripped! Sensor: ' + entry[3];

and don’t forget to clear cache/reload page in your browser.


#1518

That used to work (plain sensors with custom statuses) with version 1.0.2 and panel v1.1.2

image

Installing the latest github version with HA 0.86.4 broke it (or at least didn’t work with the new front-end configurator)

Anyway, I’ll read past messages to try to see what can I do.

What are the recommended versions of this component?


#1519

Basically you need to backup your alarm.yaml, copy a new (almost empty) one from github alongside everything else, run configurator, exit and change alarm.yaml manually (it’s obvious when you look inside).

The latest version of this component (with some tweaks) works fine with my Hass.io 0.86.1


#1520

Thank you, I’ll give another try during the weekend :sweat_smile:


#1521

Thanks for the response @AhmadK . Sorry if I wasn’t clear.

So its nothing to do with the automation. Trying a few more things before I replied to you I have discovered that it works fine for user 1 and gives this error on user 2… it still disarms the alarm system just gives an error. I have deleted the user and recreated it but its still the same.

With user 2 it even gives the error in the alarm control panel… but again still disarms it


#1522

Any chance to see your config to reproduce?
Currently I can see little point in different users apart from having per-user codes (what for?).


#1523

So I know who has disarmed the system.

Sure what config do you want to see? alarm.yaml?


#1524

How user 1 and user 2 disarm the alarm?


#1525

They will eventually disarm it by a Bayesian presence detection but this is giving the error with just entering it via the ui keypad


#1526

ok, so the automation does work, but their per-user codes don’t when they enter it via UI?
If yes, do the codes in automation match per-user codes? :wink:
It would be great to see automation(s) and alarm.yaml


#1527

The codes always work its just the 2nd user ones gives that error in the logs but still unlocks the alarm.

I have to dash right now will post the automations and alarm.yaml in an hr or so


#1528

that’s the way I like it more as far as Activity view is concerned


#1529

Thank you so much for your help, that worked a treat.

Just be picky, is there a way for it to display the Friendly Name rather than the Entity ID? Absolutely no worries if it’s not possible.


#1530

yes, there is a way as you can see on the screenshot above.
however, it requires plenty of small changes to bwalarm.py as well.
perhaps I’ll make a PR later.