Action Modes are broken

[dougmaitelli]

Alarmo Version

v1.9.4

HA Version

2022.6

Bug description

The "modes" field on action creation screen claims to be "optional", but it fails to create if no mode is entered. If multiple modes are selected, then save is successful but action does not trigger and modes field is blank when the action is opened again.

Steps to reproduce

No response

Relevant log output

No response

[seannymurrs]

I am also having this issue.

[nielsfaber]

Version v1.9.5 is released and should fix this problem. Please update your alarmo version and test whether the issue is indeed solved. You can close the issue if so, otherwise please let me know.

[dougmaitelli]

@nielsfaber thanks for the update. I can confirm the editor is now working, I can persist the configuration and see it again when editing. However, the actions still don't trigger, if I set a switch to turn on when alarm is armed or triggered, nothing happens when the actual event occurs, but it does work on the "try it" button/

[nielsfaber]

Please share your configuration of the action which is not working. For me notifications and switching the siren work OK.

[dougmaitelli]

I am testing something like: On: Alarm Armed Mode: Blank Entity: Any Light or Switch Action: Turn on or off

If I click "Try It" it does work, but when I save and the event happens no action is triggered.

I can also confirm that, if I go back and try to edit the action to add a "Mode" to it the changes do not persist again.

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days

[dougmaitelli]

Just commenting this so the issue ramains open since the problem still exists

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days

[dougmaitelli]

Just commenting this so the issue ramains open since the problem still exists

[nielsfaber]

I tried to reproduce the issue you are reporting, but for me it doesn't occur.

I configured this action for testing:

Next I armed my alarm to the armed home mode, the light turned on.

I can also see in the debug log that the automation was fired:

2022-10-03 06:27:48.870 DEBUG (MainThread) [custom_components.alarmo.alarm_control_panel] Service alarmo.arm was called, 2022-10-03 06:27:49.432 INFO (MainThread) [custom_components.alarmo.alarm_control_panel] Alarm 'Alarmo' is armed (armed_home) by Admin., 2022-10-03 06:27:49.433 DEBUG (MainThread) [custom_components.alarmo.alarm_control_panel] entity alarm_control_panel.alarmo was updated from disarmed to armed_home, 2022-10-03 06:27:49.433 DEBUG (MainThread) [custom_components.alarmo.mqtt] Published state 'armed_home' on topic 'alarmo/alarmo/state', 2022-10-03 06:27:49.439 DEBUG (MainThread) [custom_components.alarmo.automations] state of alarm_control_panel.alarmo is updated from disarmed to armed_home, 2022-10-03 06:27:49.440 DEBUG (MainThread) [custom_components.alarmo.automations] executing automation 1664771243

In the alarmo.storage file the automation is defined as such:

      {
        "automation_id": "1664771243",
        "type": "action",
        "name": "Set Office light to On upon arming",
        "triggers": [
          {
            "event": "armed",
            "area": "1623385299",
            "modes": []
          }
        ],
        "actions": [
          {
            "service": "light.turn_on",
            "entity_id": "light.office_light",
            "data": {}
          }
        ],
        "enabled": true
      }

I cannot clarify why you are having different experience than me. Could you share the configuration of this automation in the alarmo.storage file? It's located in the .storage folder in your HA configuration directory.

[dougmaitelli]

@nielsfaber I tried the exact same config as you and it doesn't trigger. Only difference I see is that I don't have areas:

[dougmaitelli]

@nielsfaber If I create areas it works, it seems the bug is only when user has only a "General" area

[nielsfaber]

I created the same action, but now without areas (now there is no field to choose an area):

When arming the alarm, the logs are as follows:

2022-10-15 08:27:49.741 INFO (MainThread) [custom_components.alarmo.alarm_control_panel] Alarm 'Alarmo' is armed (armed_away) by Admin., 2022-10-15 08:27:49.741 DEBUG (MainThread) [custom_components.alarmo.alarm_control_panel] entity alarm_control_panel.alarmo was updated from arming to armed_away, 2022-10-15 08:27:49.742 DEBUG (MainThread) [custom_components.alarmo.mqtt] Published state 'armed_away' on topic 'alarmo/state', 2022-10-15 08:27:49.746 DEBUG (MainThread) [custom_components.alarmo.automations] state of alarm_control_panel.alarmo is updated from arming to armed_away, 2022-10-15 08:27:49.746 DEBUG (MainThread) [custom_components.alarmo.automations] executing automation 1665815201, 2022-10-15 08:27:49.748 DEBUG (MainThread) [custom_components.alarmo.alarm_control_panel] entity alarm_control_panel.master was updated from arming to armed_away, 2022-10-15 08:27:49.749 DEBUG (MainThread) [custom_components.alarmo.mqtt] Published state 'armed_away' on topic 'alarmo/state'

This is automation 1665815201 in the alarmo.storage file:

      {
        "automation_id": "1665815201",
        "type": "action",
        "name": "Set Office light to On upon arming",
        "triggers": [
          {
            "event": "armed",
            "area": "1623385299",
            "modes": []
          }
        ],
        "actions": [
          {
            "service": "light.turn_on",
            "entity_id": "light.office_light",
            "data": {}
          }
        ],
        "enabled": true
      }

The office light entity turned on (note that 08:27:49 is the same time as the log entry):

Again, for me all works as it should. Please provide a clear instruction on how to reproduce the issue you are having, otherwise I cannot help.

[dougmaitelli]

I checked my logs and only things I see from alarmo are these:

2022-10-16 15:24:10.067 ERROR (MainThread) [homeassistant.util.logging] Exception in async_alarm_state_changed when dispatching 'alarmo_state_updated': ('1664863292', 'disarmed', 'armed_home')

Traceback (most recent call last):

File "/config/custom_components/alarmo/automations.py", line 123, in async_alarm_state_changed

await self.async_execute_automation(automation_id, alarm_entity)

File "/config/custom_components/alarmo/automations.py", line 223, in async_execute_automation

await async_call_from_config(

File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 166, in async_call_from_config

await hass.services.async_call(**params, blocking=blocking, context=context)

File "/usr/src/homeassistant/homeassistant/core.py", line 1685, in async_call

raise ServiceNotFound(domain, service) from None

homeassistant.exceptions.ServiceNotFound: Unable to find service notify.mobile_app_douglas_pixel_4_xl

Maybe this exception is preventing the actions from triggering. I am not really sure where this notify mobile device is coming from, it is a very old device and I don't see it anywhere in my configs.

[dougmaitelli]

Ok, I found the reason.

If you remove a device and it becomes invalid the notify service for that device goes away and Alarmo does not display the invalid entries on the UI, but keep them in the storage:

These "broken" notifications trigger the exception which them prevents the actions from running. There should be some exception handling there to prevent the actions from failing if notifications are failing. UI should also remove invalid entries upon saving IMO.

[feenx]

@dougmaitelli thank you for explaining that, I wasn't able to figure out how to find the issues similar to you showed, but by removing all the notify actions in the Alarmo UI (I had a previous notified device as you stated) I was able to get my actions to trigger successfully.

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days

[dougmaitelli]

Pinging the issue so it doesn't get closed. This is still an issue that needs fixing. There should be some exception handling there to prevent the actions from failing if notifications are failing. UI should also remove invalid entries of notifications upon saving, since it is saving devices that are not even showing in the UI.

[nielsfaber]

@dougmaitelli If I understand you correctly, the issue you want to report is that in case one action (or notification) is broken (due to an entity no longer existing), it causes other actions (and notifications) to not being executed as well?

For me this report is quite confusing to read since the original issue you reported was about something different, namely the 'modes' input in the editor.

You could help me by opening a separate bug report per topic. I would like to know whether your original report needs follow-up. So far I couldn't manage to reproduce the behaviour you're describing.

[dougmaitelli]

@nielsfaber done https://github.com/nielsfaber/alarmo/issues/617