HA -> Configuration -> Entities.
I selected all the “unavailable” entities then un-checked the entities I was using. Then deleted the selected entities.
1 Like
Has anyone here successfully used the “alarm_control_panel.alarm_trigger” service to manually trigger the alarm with Elk? I was just trying to do that (in order to trigger the alarm prior to the expiration of the entry delay via push notification, if needed), but when I try to activate that service in the Services section nothing happens…no errors in the log either (example data below):
ElkM1 integration does not support the trigger alarm feature. ElkM1 may support it. Can be added to the feature list.
The only command in the Elk protocol I see is a zone trigger, so likely you would need to include a zone if it was supported.
I also don’t see anyway to trigger an alarm directly via the Elk rules, but I suppose you could connect an output to one of your zones to close it and trigger an alarm. Then you could trigger that from HA. as a workaround.
1 Like
Gotcha, thanks for the info…when you say connect an output to one of your zones, do you mean physically connect another output to M1, or is there a way to create a phantom zone in the software that could then trigger the alarm?
What I understood that @wuench meant is to hard wire an output relay to a zone to simulate a zone being triggered. I would wire it to an unused zone and configure that zone to be instant alarm. That way in your scenario you could close the output, which would cause the zone to be violated which would cause the alarm to trigger. Kind of elegant. I like the suggestion!
I did a similar thing when I wanted to trigger an alarm for when my keypad detected low temperature alert. I threw a connection from my m1rb to an empty zone, then put an automation up to flip that relay on low temperature. fortunately, I haven’t had to use it yet (fortunately!), but in my testing, it’s worked well.
Heads up that 0.108 broke a few of my automations that were depending on alarm_control_panel.area001.attributes.changed_by_entity_id. I opened issue 33975.
It looks like this was caused by some clean up in PR 33297 that removed changed_by_entity_id and added changed_by_keypad which references the friendly name of the keypad (not great for automation).
Does anyone have a lead on why 0.108 has caused false temperature readings from my Elk thermostats?
Pre-108 (Working) Readings:
hvac_modes:
- 'off'
- heat
- cool
- auto
- fan_only
min_temp: 1
max_temp: 99
target_temp_step: 1
fan_modes:
- auto
- 'on'
current_temperature: 68
target_temp_high: 71
target_temp_low: 67
current_humidity: 0
fan_mode: auto
aux_heat: 'off'
name: Master Bed
mode: 0
hold: false
fan: 0
current_temp: 68
heat_setpoint: 67
cool_setpoint: 71
humidity: 0
index: 1
friendly_name: Master Bed
supported_features: 74
Post-108 (Not Working) Readings:
hvac_modes:
- 'off'
- heat
- cool
- auto
- fan_only
min_temp: 34
max_temp: 210
target_temp_step: 1
fan_modes:
- auto
- 'on'
current_temperature: 154
target_temp_high: 160
target_temp_low: 153
current_humidity: 0
fan_mode: auto
aux_heat: 'off'
name: Master Bed
mode: 0
hold: false
fan: 0
current_temp: 68
heat_setpoint: 67
cool_setpoint: 71
humidity: 0
index: 1
friendly_name: Master Bed
supported_features: 74
Thanks in advance for any additional info.
I’ve posted a testing fix in the issue and have a PR ready to merge if it solves the issue.
does this only impact thermostats? Because I have a keypad that supports temperature and it is working just fine in 0.108.3
My keypads look OK, too. It’s my Elk-attached thermostat that’s affected. I’m going to try the patched version referenced in the git issue and see how that works…
…and for those following along at home, the patched version seems to fix the issue.
Hey folks,
There’s a discussion going on on GitHub as a bug around the changed_by functionality not working properly when an ElkM1 has more than one area. It is closed as it is considered a feature request. Posting here to keep the discussion going and get a wider range of thoughts on what should happen. Here’s the GitHub thread… https://github.com/home-assistant/core/issues/35310
That was pretty funny in places, given that the core M1 product really hasn’t changed in more than a decade. You think it would have grown on-board ethernet/wifi, maybe a network interface performant enough to up the game a bit…
Still, they still seem suck much less than the alternatives…