Yes, it’s a work in progress. This came from a use case to capture the name of a user logging in to the panel. The previous code events did not have user and zone names associated, as well as having ambiguous event descriptions that made identifying the correct event difficult. I rewrote the descriptions and added zone and usernames to the events and figured I’d wrap it in json to make it easier to parse in HA, but HA does not make it easy to use it as json and as you noted, the display format is not user-friendly.
I’m toying with the idea of adding a yaml config to control the type of output for the event record. Either json formatted or as an easy-to-read format. Any opinion or preferred format?
FYI. The user names come from this yaml config option:
Yes, it works and is indeed a fantastic addition with the data embedded in the events. Thank you very much!
Would it be too much effort to add an option to exclude the partition from the event data? I imagine there are many others (like me) with just one partition, where this information would simply take up space without adding any value.
…and maybe (optionally) remove the number for zones and users? For me, this makes the information feel a bit redundant and less human-readable.
For the partition, I’ll add logic that if there is only one partition, don’t display the partition section. No need for an option. I’ll think about the best approach for the users and zones.
Ok, ive removed the partition from showing if there is only 1 partition active as we as removed the display of the user codes and zone numbers if there is an available name to display instead. Lets see how that works.
Pushed to dev now.
However, do you have any idea why do I have two events when arming? It seems like I do have an additional ‘Armed Special’ event both for ‘Armed Away’ and ‘Armed Home’. Is this somehow comes from my dsc configuration?
…and I am just thinking out loudly: do we need the “user:” string before the actual user in the event text? Wouldn’t sound it more natural to just simply have disarmed by xzy?
Yes ,you are right, and I can remove the “user:” from the string since triggers can search for “disarmed by”.
As to the armed special, that’s something that your panel is sending. How are you arming it? Are you using quick arm without needing a code or are you always entering a code to arm it? That might be the difference.
I am using quick arm: no entering the code to arm.
(…but this was not the case before the refactoring of even handling. I always only had one event for arming.)
I’ll do some testing on my end, but that status is definitively sent from the panel.
Anyhow, i’ve simplified the event message even more now as per your good suggestions. Pushed to dev now
Edit: Armed Special is sent when quick arming is active so no user codes are used. Without quick arming you would see “Armed by” instead.
OK, thanks for testing Armed Special. I am just wondering why the panel is also sensing a regular ‘Armed Stay’ or ‘Armed Away’ in addition to the ‘Armed Special’.
Anyhow this is not big deal, and I can also filter this message out from the logbook card.
Thank you for these enhancements and quick responses!
Is it possible to add a sensor that identifies the name of the zone that triggered the alarm state? I know it’s feasible to assemble this using the current sensors (either by extracting from the zone statuses or the new event message), but the solutions I’ve found so far are pretty cumbersome.
Sure, I can do that.
Edit: Updated and pushed to dev. Add this field definition to your yaml config:
#zone that triggered last alarm
#zone alarm id code = (za_ + partition number)
- platform: template_alarm
id: za_1
name: zone alarm (za_1)
icon: "mdi:alert-box"
Edit: Also added a field to capture name/id of arming/disarming user as per a request from someone else.
# 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"
Thank you very much, it works perfectly!
Just one note, maybe for someone new to read the config line in your post: there is a typo for platform. Should be template instead of template_alarm.
Ah, you’re using the old method of using the binary/text_sensor components. I’ve moved to using a new template_alarm external component. If you look a the dscalarm.yaml sample in dev you will see the change. Either will work.
Ah, OK, probably I need to switch over to that one then, to be in the same boat with you
Something else:
I noticed that the sensor.dscalarm_zs is quite sticky following an alarm, and AL:zone number is being kept for very long. Even after another arm/disarm cycle when there is no alarm in the alarm memory any longer. Is this something you can reproduce?
An arm /disarm should always clear it. I can’t reproduce your issue, as it works fine here. You only have one partition, though, and perhaps that makes a difference. It shouldn’t but I’ll do some tests.
