Best ways to capture the user disarming and arming?

[evolv30101]

I think i may have taken not the best path to capturing the user for arm/disarm events due to my lack of experience. So im trying to get an idea of what others are doing.

Please yell at me if i should be posting to HA forum instead of here as im not sure if this is proper etiquette. I will take no offense :)

This mainly being done for my non-ha users that dont interface with the webgui as they are not "computer people" so hence the text message.

Goal was to fire a notification via text (this part works fine) by triggering from the arm_1 sensor changes. Then add the text sensor data to the notification. Idea being something like this: "Alarm Name: "{{ states(''sensor.alarm_name_evt'') }}"'
Which results in: message: 'Epic Alarm: "2024.11.24 09:39 P:1 Disarmed: Access_code:Firstname LastName"'

On disarm triggers I noticed timing isnt the greatest because the event sensor sometimes doesnt update instantly so i just added a 5 sec delay in the automation which i think should be good by looking at the logbook.

But i noticed on an arm on trigger that the event sensor shows the person arming only for like a second or so and then changes the state to "armed_away" for instance. So this would break my logic on an armed event trigger as i cant grab the state quick enough before it changes.

So this got my thinking, am i going about this the wrong way? Should i be possibly just watching the event with some sort of filtering (like regex or something)to fire the trigger. Or is it better to create some sort of helper(input_text) to store the event text data and use that for notify?

Just trying to get an idea of how others are doing this as i got a feeling im going the wrong direction and or not doing it in the most eloquent fashion.

[Dilbert66]

Actually, that is a very good question. It's very pertinent here. I've struggled on deciding how to format the events to be useful for such tasks. Right now, I've made it more user readable but that's not always easy to use as a trigger for automation due to parsing difficulties. Since the sensors outputs are not technically linked to each other, the timing and content will always be different, so your best approach is to only trigger on the contents of the "event" field. Now, you will need to watch for certain content in that field to determine what you want to do with it. So, this brings up this point. What's the best way to format the field in order to simplify parsing it. As to the timing of events, this is all controlled by the panel. The esp code only decodes and publishes it out in a human readable format.

[Dilbert66]

You can always have multiple notifications. One for the armed or alarm, then a following one with the event data. That's what I would recommend. Don't depend on previous notifications to determine if a new notification should be sent or not. Just look for particular data in each sensor value at that time to determine if you should send it out or not. I can add more details to the event text to make this easier, such as adding the arming mode, etc.

[Dilbert66]

To help in doing what you need, what would you like to see in the event data? The format can also be adjusted to make it easier to parse to such as using key:value pairs and such.

[evolv30101]

Hang tight...im writing a different response right now as i think i see it there....you can comment on what i noticed and post

[evolv30101]

Well...you made me feel better by stating what you did about it not being easy :) I understand what you are saying about sensors not being linked etc...it makes sense. Then throw the timing for esp / network /etc... into the mix it gets interesting. This is kind of over my head as i havent worked with text sensors a lot, mainly binary and numerical for other projects. So im probably not going to state this in a proper manner. Just bare with me as i think out loud here, lol.

Its almost like we need another text sensor that holds the "last person arm/disarm" data to make it "easy" for newbs like me. But maybe my thinking is wrong here. This is probably is not most eloquent either. Same thing could be used for last zone triggered alarm data.

Im noticing the text data contains everything i need though in its current state. It has what pertinent to what im trying to do. I just need to figure out how to access it. I noticed it always contains "access_code" in the entries i need. This shows for both arm and disarmed events. So I think this is fine but may not be great for others if they haven't completely filled out yaml with user codes as i did as it may look diffferent for that scenario.

So......my thought is could use a value template here(?) for a trigger (instead of binary sensor), that looks for access_code in the state. ie: "{{ 'access_code' in trigger.to_state.state }}" https://community.home-assistant.io/t/automation-trigger-if-state-contains-string/136247
Im not sure how to write that yet as i have to try to read some examples or ha manual so i can understand how to reference the sensor properly. Im not well super well versed in ha yet. I guess what im saying is im not good at parsing yet so it may take me hot minute to figure this out.

I'll need to set off the alarm next week while no one is there (holiday break) so i can see what triggered alarm data looks like too so i can see what to parse for that. Ideally i would like to capture the zone name/number that triggered alarm for notifications too. But if a value template works for the arm/disarm i would suspect it would probably be useful for triggered events to once i see the format. The one event i had in my logbook disappeared already.

Long term goal would be to capture those events for notications then grab a pic from the security cam near panel or zone in question and attach to a message. But this far down the road.

[Dilbert66]

Ok, I can definitively simplify it for you by adding alarm/armed states to the event message. For example:

'2024.11.24 11:28 P:2 Armed by user 40 Some Body'

and change it for easier parsing to:

'2024.11.24 11:28,P:2,Event:arm,Status:armed_stay,User:40 Some Body'
or
'2024.11.24 11:28,P:2,Event:disarm,Status:disarmed,User:40 Some Body'
or 
'2024.11.24 11:28,P:2,Event:alarm,Status:triggered,Zone:17'

Then to parse, you split each section by comma, then split the key:value by :.
The keys would be Event,Status and either Zone or User depending on the event.. This way, all the info you would need for the notification would all be in the event message. Would this work for you? Is there any other info you would need in that field or a better format? I can make it anything and include any status.

[Dilbert66]

As to parsing it into HA, i'll work on something as well as I need to get it working for myself too , so I'll post any solution I have here

[Dilbert66]

Here's some example value_templates to extract whatever you want from a text line.
This section '([^,]*)' means extract all characters up to anything that is not a comma. You can put a space there if the delimiter is a space.
The \s* means skip any leading spaces

{% set val = '2024.11.24 11:28,P:2,Event:arm,Status:armed_stay,User:40 Some Body' %}

val can also be your state from the sensor or states('sensor.dscalarmc3_evt'), etc

Partition value:
{{val|regex_findall_index("P:\s*([^,]*)",0)}} returns "2"
Events value:
{{val|regex_findall_index("Event:\s*([^,]*)",0)}} returns "arm"
Status value:
{{val|regex_findall_index("Status:\s*([^,]*)",0)}} returns "armed_stay"
User value:
{{val|regex_findall_index("User:\s*([^,]*)",0)}} returns "40 Some Body"

You can test for a value this way:

{{val|regex_findall_index("Status:\s*([^,]*)",0)=="armed_stay"}} returns true or false

A sample HA entry for Armed

• sensor:
  - name: "User for arming"
  state: '{{states("sensor.dscalarmc3_evt")|regex_findall_index("User:\s*([^, ]*)",0)}}'

The template tab in the developer tools is a great way to test your value_templates

As to capturing and retaining the last user who armed/disarmed the system, I suppose I could keep that as a separate value. It would be nice to have it captured in HA though. If there is no easy solution there, I can definitively add the new sensor, it's not a problem.

[Dilbert66]

Here's an idea, you can create a trigger using one of the templates above, such as the one for user or arm/disarm and when found, you save the evl sensor value in a template sensor field then do your notification trigger using this saved data. You can do whatever you want with it since no matter what happens with the esp event field , it won't impact your saved value.

Edit: Ok, now you got me thinking.. I should really be sending out the event data as a json formatted string.. It would simplify parsing it immensely as you could use HA's default methods without resorting to convoluted regex expressions and templates.
I could then send whatever info and you would just be looking for key:value pairs. You would still need to store the value right away as I noted above, but the extracting of the data would be easier.

[evolv30101]

Lol ... you've been working i see! I think i understand what you are saying above. That's kinda what i was thinking with a "helper" field since the evt sensor is really sort of a logging sensor so it needs to be able to accept log msgs and change fast as those msgs come in.

Im going to digest all this in the morning. I just had my butt kicked with a stuck drain plug on truck. I'll be able to focus much better in the early morning. I'll flash the latest update too. Didnt want to do it earlier as church service was in and i didnt want to have a snafu in the middle of that :)

I do appreciate all your help on this!

[Dilbert66]

It's an interesting challenge and needs to be improved anyhow! Hope you got your drain plug fixed!

[evolv30101]

Would the JSON formatting put the data into the HA attributes fields to allow drilling down? If so i think long term that would be sweet.

I updated everything again this morning and just whipped up a couple test triggers using templates (hope i did this right). Never used before. I'll post what i did if it works as i expect.

Honestly if i can just trigger on the event text and then use the actually triggering event text in the notification im good for the time being. The event text has all the pertinent info needed in there as is. Has the time, partition, user, action... maybe not the prettiest for a "end user" but they can deal with it :). Then just use a couple different template triggers "Access_code" (or "user" if you changed it) and "triggered".

Of course someone already disarmed it before i could get all setup this morning.

[evolv30101]

Looks like the triggers work...although i got an error on one of them that has nothing to do with this software (im emailing to text phone#@carrier's email to text address). Not sure what thats about yet but not your problem.

[Dilbert66]

Yes, the JSON data would make it easier to access values. For example
{% set result ={'time':'2024.11.25 14:10','p':2,'event':'arming','status':'armed_away','user':'40 Test User','zone':0}
%}
The status is {{result.status}} and the user is {{result.user}}
The event logic needed some work so gives me a reason to optimize it and make it more useful. Sounds like your kicking but with the trigger logic! Awesome!

[evolv30101]

JSON is probably the way to go long term than i would think.

I had to tweak a little bit after playing around in dev tools with the various statuses i was seeing to avoid some unnecessary alerts (ie: master code entered would trigger while changing panel stuff). It looks like zone alarm: is now used instead of triggered as well. That one may lead me to some dupes but i'll let it ride and see what happens and possibly put a pause or something in line.

You definitely need to grab the event msg as a variable as it will change in under a second in some instances which caused grief getting the notification out to the second person as they would sometimes get the following event msg. Using the variable seems to fix it.

This could probably be cleaned up and more efficient but it is what it is for now :)

alias: Alarm Notifications
description: ""
triggers:
  - alias: Armed by user
    trigger: template
    value_template: |-
      {% if 'Armed by user' in states('sensor.alarm_name_evt') %}
       True
      {% else %}
       False
      {% endif %}
  - alias: Disarmed by user
    trigger: template
    value_template: |-
      {% if 'Disarmed by user' in states('sensor.alarm_name_evt') %}
       True
      {% else %}
       False
      {% endif %}
  - alias: Template - Triggered
    trigger: template
    value_template: |-
      {% if 'Zone alarm:' in states('sensor.alarm_name_evt') %}
       True
      {% else %}
       False
      {% endif %}
conditions: []
actions:
  - variables:
      eventmsg: "{{states('sensor.alarm_name_evt') }}"
  - action: notify.personb_text
    data:
      message: "Building 1 Alarm:  \"{{ eventmsg }}\""
    enabled: true
  - action: notify.persona_text
    data:
      message: "Building 1 Alarm:  \"{{ eventmsg }}\""
    enabled: true
mode: single

[evolv30101]

Before i forget... and i know this isnt the right place :)

One thing that would be cool in the future is if "zone alarm:" events would show the ESP zone name or friendly name (not sure what its called) in the message. IE "2024.11.25 16:21 P:1 Zone alarm:13 (stairwell door)"

I love the new user name showing on the panel card change you made. That works awesome! was playing with that yesterday saved me a bunch of time going thru my spreadsheet of names/codes/slots.

[evolv30101]

One other thing and i'll leave you alone for awhile unless you need me for something...

I noticed in the event log while i was trying out different scenarios: 2024.11.25 15:15 P:1 Armed: Special

Would the "armed special" be from just pressing away without entering a user code? I believe i did that once and forgot to take note of it. If so im going to add a trigger for this to the automation too.

[Dilbert66]

Very good point about adding the zone name. will do that. As to capturing the disarm and arm events, yes, I'm reworkign the wording of all events. For the user events that arm and disarm, I'll change the event name to be "arming by user" or "disarming by user" and those will be the only that will contain those events with the user so you won't need to filter other events.

As to the arm special, i forget. I got that from the previous source code. I'll have to do some testing. The armed partial happens when you arm with bypass zones active, that I know.

[evolv30101]

I'll test the special and let you know but i believe that happened around the time we pressed just away without a code. IE for guests you want to arm on exit without giving a code to.

[evolv30101]

Sent some coffee's your way for the help. I really appreciate it. Let me know if you need anything from me in future. These two systems should see a fairly decent amount of use as everyone starts using them again.

[Dilbert66]

Awesome! Thank you very much! I'm currently cleaning up the event code and should make it much easier to parse as we discussed! Adding your suggestions as well.

[Dilbert66]

I've made a few changes but have not published them yet. Don't want to mess up your scripts. Here are the new messages. You can use the existing triggers but just change your wording a bit. I also need to figure out the HA handling of the json format but for now you can still use the regular search you are using. Everything will be lowercase.

{'time':'2024.11.26 14:31','p':2 ,'event':'armed by user','user':'40 (Test User)','zone':'','status':'armed_away'}
{'time':'2024.11.26 14:53','p':2 ,'event':'zone alarm on','user':'','zone':'17 (Test sensor (z17))','status':'triggered'}
{'time':'2024.11.26 14:54','p':2 ,'event':'zone alarm off','user':'','zone':'17 (Test sensor (z17))','status':'triggered'}'
{'time':'2024.11.26 14:54','p':2 ,'event':'disarmed by user','user':'40 (Test User)','zone':'','status':'disarmed'}'

Edit: I'm pushing the changes to dev. You can recompile when ready to use them.

[Dilbert66]

Gonna run something by you. I didnt like the limations of force json on the event record and someone else noted how it doesnt look right for just using as is, so I've made a change that allows the output to be controlled by a new yaml config. With this setting you can choose "plain" or "json" for the event. If you choose plain you will see it this way:

[2024.11.28 17:30] Partition: 2, Event: Zone alarm ON for zone 17 (Test sensor (z17)), Partition Status: triggered
[2024.11.28 17:31] Partition: 2, Event: Disarmed by user 40 (Alain Test), Partition Status: disarmed

Judging by how you have your triggers set I think that will work better for you. The default will be to use the "plain" format if you don't have this config setting in your yaml.

The new yaml setting is.

event_format: plain #this is the default

[evolv30101]

Did you already push it to the dev branch?

Good move with the yaml selection option as to not break existing installs but allow future changes if anyone choses to implement. That way if you choose to continue json work you could smooth it all out without having to help a bunch of people utilizing the old style. Im going to assume a lot of people just get it working and never look at it again until there is an issue.

I can check it out once i get back.

[Dilbert66]

Yes, it's pushed to dev. Ya, I should have gone with that first but it's set now. Not sure if you follow the forum on HA regarding this component, but there was a request regarding not adding the user code or zone if the name was available. I'm not sure about that one. Any thoughts?
I will display the event as "User Name (40)" instead of "40 (User Name). Alternatively, if there is a name, I could just display it. Of course, with the *5 code entry, I would display both.

[Dilbert66]

Well, I've pushed more changes to simplify the event message. So now you will see "Armed by xxxx" or "Disarmed by xxxx" or for zones you will see "Zone alarm on for xxxxx" or "Zone alarm off for". Makes the messages more readable this way.

As to the "Armed Special", that is sent by the panel when Quick arm is used to arm the system so no user names or codes are in play. This replaces the "Armed by" message.

[Dilbert66]

Well, this should simplify your parsing... Yes , I know after the work you've already done. Anyhow I had another user request capturing the alarmed zone in a field and figured since you also needed that and capturing the arming/disarming user, I've added them both. Add these two fields to your yaml config.

# name of the zone that triggered the last alarm
# zone alarm id code = (za_ + partition number)
  - platform: template_alarm
    id: za_1
    name: zone alarm (za_1)
    icon: "mdi:alert-box" 

# name or id of the user that last armed/disarmed the partition
# user id code = (user_ + partition number)
  - platform: template_alarm
    id: user_1
    name: Arming/Disarming user (user_1)
    icon: "mdi:alert-box"