Log error when alarm fails to be armed

[llamafilm]

I have some Home Assistant automations that arm the alarm at various times. If a door is open when this runs, there is no error message or indication of failure. The addon log shows the error clearly:

2023-02-26T17:59:49.049Z ring-mqtt [Home Alarm] Error: Failed to set alarm mode to "all".  Sensors may require bypass, which can only be done in the Ring app.
2023-02-26T17:59:49.740Z ring-mqtt [Home Alarm] Alarm for location Home failed to enter requested arm/disarm mode!
2023-02-26T17:59:50.871Z ring-mqtt [Home Alarm] No sensors will be bypased
2023-02-26T17:59:50.871Z ring-mqtt [Home Alarm] Set alarm mode: ARM_HOME

But most users won't know to look there. Is there some way to bubble an error up to Home Assistant in this case so the user can decide what to do?

[tsightler]

If users don't know to look at logs, then I'm not sure how to help them, but I'm not sure do-it-yourself project like ring-mqtt or Home Assistant are really for people that don't know how to look at logs. They should probably stick with paid products that have support.

[llamafilm]

I’m used to digging through log files when troubleshooting something but the nice thing about the main HA log is it can fire system_log_event for use as a trigger. Correct me if I’m wrong but I don’t think addon logs can be used like that.

[tsightler]

I have no idea, but it doesn't really make any difference since I'm not aware of any way to surface messages from ring-mqtt to HA. The ring-mqtt project itself is not related to HA. As its name implies, it communicates to HA only via MQTT and it can only do what MQTT allows.

[KruseLuds]

Hey is there any way to turn that on for other log files?

…

On Sun, Mar 12, 2023 at 7:16 PM tsightler ***@***.***> wrote: I have no idea, but it doesn't really make any difference since I'm not aware of any way to surface messages from ring-mqtt to HA. The ring-mqtt project itself is not related to HA. As its name implies, it communicates to HA only via MQTT and it can only do what MQTT allows. — Reply to this email directly, view it on GitHub <#570 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AXBJ5MNHVWGNO2B5NQ4VSADW3ZRN7ANCNFSM6AAAAAAVITAI4A> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

--

-Kruse Ludington M: +1.201.925.4410 H: +1.201.857.8307 F: +1.201.857.7718

[Mincka]

I use an additional automation in HA to monitor this behavior. The idea is to monitor call_service event so it works for all automations, scripts or buttons.
The triggers could be simplified a lot but I'll let people improve them if they want.
They are duplicated because the service call can be done on a single entity or a list of entities so it accounts for both cases.
I created a group of the Ring Contact Sensors that can cause a bypass issue so I can also list them in the message.

alias: Ring Alarm - Check if activated after service call (warn for bypass issue)
description: ""
trigger:
  - platform: event
    event_type: call_service
    event_data:
      domain: alarm_control_panel
      service: alarm_arm_away
      service_data:
        entity_id:
          - alarm_control_panel.xxx_alarm
  - platform: event
    event_type: call_service
    event_data:
      domain: alarm_control_panel
      service: alarm_arm_home
      service_data:
        entity_id: alarm_control_panel.xxx_alarm
  - platform: event
    event_type: call_service
    event_data:
      domain: alarm_control_panel
      service: alarm_arm_home
      service_data:
        entity_id: alarm_control_panel.xxx_alarm
  - platform: event
    event_type: call_service
    event_data:
      domain: alarm_control_panel
      service: alarm_arm_away
      service_data:
        entity_id:
          - alarm_control_panel.xxx_alarm
condition: []
action:
  - delay:
      hours: 0
      minutes: 0
      seconds: 5
      milliseconds: 0
  - if:
      - condition: state
        entity_id: alarm_control_panel.xxx_alarm
        state: disarmed
    then:
      - service: notify.mobile_app_telephone_julien
        data:
          title: Ring Alarm is not arming
          message: >-
            {% set open_sensors =  expand('binary_sensor.ring_contact_sensors') |
            selectattr('state', 'eq', 'on') | map(attribute='name') | list |
            join(', ')  %} Sensors may require bypass. Following sensors are
            open: {{ open_sensors }}
          data:
            ttl: 0
            priority: high
            notification_icon: mdi:shield-home
            importance: high
mode: single

[Mincka]

Of course, to answer to OP, other actions could be done to get feedback, for instance with Persistent Notification.

[llamafilm]

@Mincka thanks for sharing. Meanwhile I came up with the following solution. Every time MQTT tries to arm, it waits 2 seconds and then sends a notification if it's still disarmed. This has been working well so far.

alias: MQTT warn on ring alarm failure
description: ""
trigger:
  - platform: mqtt
    topic: >-
      ring/d40647d4-9559-4be8-9d57-2afd8c029d0c/alarm/34866be9-84a8-47dd-8fb7-04eb21e9338d/alarm/command
condition:
  - condition: template
    value_template: "{{ trigger.payload.startswith(\"ARM\") }}"
action:
  - delay:
      hours: 0
      minutes: 0
      seconds: 2
      milliseconds: 0
  - condition: state
    entity_id: alarm_control_panel.home_alarm
    state: disarmed
  - service: notify.persistent_notification
    data:
      title: Unable to arm
      message: "Payload: {{trigger.payload}}"
  - service: tts.google_translate_say
    data:
      cache: true
      entity_id: media_player.homepod
      message: I was unable to arm the alarm
mode: single

[Mincka]

Even better! Thank you. 😊

[tsightler]

I'm curious if you all could share the use case. What exactly do you do when you detect that the arming doesn't work? I'm trying to understand if the current bypass behavior needs to be improved, or is this just for notification purposes so you can manully check things.

I've also been considering the possibility of including some additional data as part of the json attribute topic, for example, last arming action which could indicate failure/success and perhaps even failure reason, as well perhaps who armed/disarmed (assuming a code was used at the panel). I'm trying to understand if this would be useful or perhaps at least make such automations easier.

[llamafilm]

When this happens, I look at the Ring app to see why it failed to arm. Most likely because a door was open, so I go close the door and arm again. Or I suppose there could be another reason, maybe a temporary glitch in Ring or a network drop. It would be nice to get the failure reason to use in the notification.

[Mincka]

In my case, I have a virtual alarm system with Home Assistant that uses my Zigbee sensors. This alarm is "synced" with the Ring one. So when I arm my HA alarm, it arms the Ring one automatically. When an internal door with Ring sensor is left open, and I arm the HA alarm, the Ring alarm cannot arm because of the required sensor bypass. Without feedback, I am not aware of this issue.