@mikeg1130 I can confirm that the silent arming implementation in the HA custom component matches in the one in the Homebridge node. Unfortunately, closer inspection of the notes in the README indicate there is an issue with that feature in the Alarm.com Web API:
“armingModes”: Object of objects with arming mode options of boolean choices ( WARNING: the Alarm.com webAPI does not support setting silent arming to true and this feature does not work at this time)
So, I’m running two systems (work / home)
Doesn’t appear it’s separating them correctly:
Showing the same sensors/values for both .home and .work unfortunately
The files https://github.com/aechelon/pyalarmdotcomajax in the folder are the older ones. I used the latest ones circled, and not the ones in the folder alarmdotcomajax . Just copy them to the folder on your machine.
@navet sorry about the confusion. The duplicates have been removed and the older files should now be up-to-date with the latest.
@Markus99 does the alarm state for each come up properly (i.e. can one be armed while the other one isn’t?)
I don’t have 2 systems so debugging the issue would take some poking in the dark.
@mikeg1130 I tested silent arming with the python web api example and it works properly, so something must be happening when the ajax implementation pushes the parameter to Alarm.com. There’s hope!
The original Alarm.com integration handled this ok, fwiw (with the same configuration.yaml setup). I also ensure that I have two separate logins, each with ONLY access to only ONE of the systems.
For now I’ve switched and am using BOTH the WEBAPI and AJAX versions. Also, appears that arming to STAY is working w/ the AJAX version, which is a great!
I’ll check for more details when I get a chance to switch back to BOTH using AJAX and let you know. As always, thanks for your hard work @aechelon!
Thanks so much for the information
What am I missing.
I installed the new files and it looks better than before, but it does not fully work.
Here is my config.yaml
alarm_control_panel:
platform: alarmdotcomajax
name: alarm_com
username: !secret alarm_username
password: !secret alarm_password
Here is what comes up in the states.
Here is my binary sensor setup
alarm_office_window:
friendly_name: "Office Window"
device_class: window
value_template: "{{ is_state_attr('alarm_control_panel.alarm_com', 'sensor_status')|regex_search('Office Window is Open', ignorecase=TRUE) }}"
and here is a sample of the binary sensor states output.
As you can see in the states that the Office Window (14) is open, but the binary states show it as off (or closed).
What have I missed in my setup.
Thanks for the help.
carltonb
Try
alarm_office_window:
friendly_name: "Office Window"
device_class: window
value_template: "{{ state_attr('alarm_control_panel.alarm_com', 'sensor_status')|regex_search('Office Window is Open', ignorecase=TRUE) }}"
You answered your own question Carlton. All the sensor is doing is looking for an EXACT MATCH to ‘Office Window is Open’ in the ‘sensor_status’ attribute of the alarm_control_panel.alarm_com entity.
As you can see in the states that the Office Window (14) is open, but the binary states show it as off (or closed).
Therefore you need to regex_search for Office Window (14) is Open, not just ‘Office Window is open’
Battery info is not exposed through the web api
@mikeg1130 uvjustin has packaged a better version of the custom component and I can confirm that silent arming works as advertised with this version. I have deleted my fork to avoid confusion w.r.t. which version should be used.
Note that while the platform name remains unchanged, the parameters values are slightly different. Specifically, the flags force_bypass, no_entry_delay, and silent_arming accept strings, not boolean (true/false) values.
Accepted values are “home”, “away”, “false” (never), “true” (always)
Where “home” means only enable the feature when arming home and “away” means only enable the feature when arming away.
Thanks for all the work on this custom component. Silent arming working here also along with no entry delay.
Thanks! I’ve switched over to uvjustin’s newest version, and it is working great, silent arming and all!
This was the one functionality i always felt the original integration was missing.
@Markus99 if you get a chance, could you try out uvjustin’s newest version to see if it addresses the the sensor_status issue with multiple systems?
Yup, let me do that now - need a break from work anyhow…
Unfortunately, showing the same issue
Also, from what I’m seeing, the name: home instance (the lower of the two) from configuration.yaml is completely ignored. I tested setting our home alarm only and the status in HA didn’t change at all. So it’s using/duplicating the WORK credentials for the HOME sensor apparently…
As mentioned, the (now removed? / original) version was able to have multiple instances/locations of the alarmdotcom integration and allowed them to operate independently. Unsure if anything in that code would be helpful? Let me know if I can assist further!
@Markus99 thanks for testing that! Would you mind opening an issue on the GitHub project page for this?
