id: '1594948282'
alias: Alarm panel changed
trigger:
- entity_id: alarm_control_panel.area_001
platform: state
to: armed_away
- entity_id: alarm_control_panel.area_001
platform: state
to: disarmed
condition: []
action:
- data:
message: Alarm has been set to {{ states.alarm_control_panel.area001.state }}
title: Alarm Set To {{ states.alarm_control_panel.area001.state }}
service: notify.mailgun_keith
but I no longer get the alarm state in the message. Suggestions on what else to use?
@keithnet, take a look in the “STATES” thing in developer tools. I just looked on my Home Assistant instance, and my Elk M1 shows up as alarm_control_panel.area001 - Note area001 vs. area_001in your trigger entity_id’s.
Thank you. There was absolutely a typo in my automation that I missed. I used alarm_control_panel.area_001 in one place and alarm_control_panel.area001.state in another. It works now.
Glad it was something simple. I know that I’ve looked really hard at typographic errors that just can’t be seen unless looked at with other eyeballs. Or I go through the process of explaining to someone else how this can’t possibly be wrong…
One thing I’ve found to be amazingly useful is using Visual Studio Code to do editing, and using the Home Assistant extension for it. It connects to Home Assistant, gets a list of all the entity_id’s and then will auto-complete them while you’re editing the YAML. What a huge time saver that is!
And now with the remote editing feature in the June release, you can run the UI front-end on your desktop computer and it will talk to the backend running on the other machine over SSH. No need to screw around with Samba and exporting the file system to the host you’re editing on.
While more M1 than HA related, does anyone have a preference and reasons for using GE/Interlogix versus Honeywell wireless devices with M1? I need some wireless door and window sensors and don’t yet have an M1 wireless interface. I would need to be convinced to spend the extra $ for the Elk two-way wireless an devices over the GE or Honeywell interface and devices.
This is a residential application in a quiet location where glass-break is a greater risk than door/window tampering. Glass-break is hardwired, but some double-hung and casement windows, a double slider, and a couple of exterior swinging doors are not readily able to be retrofit-wired.
I elected to go with honeywell (for no real reason other than stuff is pretty cheap) with my Elk. Haven’t had an issue so far, I put in ~20 window sensors. They’ve been installed for a few months so far.
Hi all - I’ve got the M1 component setup but I’m getting this error multiple times a minute…has any else encountered this? I’m only using the Elk component to track door and window sensor states, not the state of the alarm itself, so it’s working the way that I want; it’s just this error message is blowing up my log with thousands of these entries:
2019-08-18 17:28:03 ERROR (MainThread) [homeassistant.core] Error doing job: Task exception
was never retrieved ValueError: 'd' is not a valid AlarmState During handling of the above
exception, another exception occurred: Traceback (most recent call last): File
"/usr/local/lib/python3.7/site-packages/homeassistant/helpers/entity_platform.py", line 365, in
_async_add_entity await entity.async_update_ha_state() File "/usr/local/lib/python3.7/site-
packages/homeassistant/helpers/entity.py", line 225, in async_update_ha_state
self._async_write_ha_state() File "/usr/local/lib/python3.7/site-
packages/homeassistant/helpers/entity.py", line 256, in _async_write_ha_state
attr.update(self.device_state_attributes or {}) File "/usr/local/lib/python3.7/site-
packages/homeassistant/components/elkm1/alarm_control_panel.py", line 135, in
device_state_attributes attrs['alarm_state'] = AlarmState(elmt.alarm_state).name.lower() File
"/usr/local/lib/python3.7/enum.py", line 310, in __call__ return cls.__new__(cls, value) File
"/usr/local/lib/python3.7/enum.py", line 564, in __new__ raise exc File
"/usr/local/lib/python3.7/enum.py", line 548, in __new__ result = cls._missing_(value) File
"/usr/local/lib/python3.7/enum.py", line 577, in _missing_ raise ValueError("%r is not a valid %s" %
(value, cls.__name__)) ValueError: 'd' is not a valid AlarmState
@Tangston311, I’m running 0.97.2 of Home Assistant, and I’m not seeing these errors, either. “Works for me!” isn’t terribly useful if it’s broken for you, but at least it reduces the debugging.
@lmamakos I’m on 0.93.1. I’m wondering if it has to do with the fact that none of the control panels are actually attached and the system. Full story: our house came with the M-1 system installed, but it wasn’t hooked up properly and I wanted an alarm system that actually had a good mobile app and could integrate with other things (this was before I was aware things like Home Assistant even existed), so I put an alarm.com system in place and removed the Elk control panels.
Fast forward a year and I’ve found HA and realized I can integrate Elk…I manage to get Elk functional (still without the control panels actually in place) because I want to use all of the hard-wired door & motion sensors for automations because they react instantly instead of having a minute or two delay like the alarm.com sensors.
I got the sensors, and my automations, to work, but I’m getting this error constantly all day long. I know it’s an unusual situation; I was just hoping someone else had come across it before and knew of a way from keeping my logs from blowing out to hundreds of pages of text per day from this one error.
I looked and ‘d’ is not listed in the ASCII protocol only 0-b are supported but this may be some sort of error state. I am not sure you can run an Elk without at least 1 keypad, you will want one to troubleshoot with, some tasks can’t be done without it. A lot of people install one at the panel so they can see what is going on while troubleshooting/test while hooking things up/etc.
What state is reported in ElkRP…status annd what do you see in the ElkRP logs?
I’ve taken a look at this. I can’t see what’s wrong from the info I’ve got so far. Couple of questions…
Can you upgrade to latest hass? 0.97.2. Being on the latest will help me look things up.
What version of the ElkM1 are you running?
Is there more in the log that might be relevant? It says “During handling of the above
exception, another exception occurred”. Seems to imply something else is going wrong.
When you say “none of the control panels are actually attached” does that mean no keypads are attached? Control panel usually means the ElkM1 main panel. Having no keypads should not be a problem, in my experience.
How good are you with the command line? If you are then maybe some other debugging we could try.
Perhaps the lack of any keypads at all causes an invalid state to be reported? Perhaps it’s an undocumented error condition ?
Can you try just wiring up a keypad (if you still have one) right off the panel and see if that changes things (no need to install it properly someplace, just wire it up next to the panel)?
I imagine an installation with zero keypads or keypad-type devices (i.e. M1KAM’s) is not an expected situation for the Elk … so there’s no telling what might go wrong if there’s not at least one.
@gwww - I can upgrade, it’ll just take a bit of work as I have a custom component that needs to get updated to be compatible. It’s something I’ve had my mind on doing so maybe I just need to go ahead and get on it.
I’m not sure how to check which version of ElkM1 I’m running - do you know how to do that?
This is the full text from one of the errors this morning, so I’m not sure what other exception it might be referring to (except that these happen so frequently that perhaps the same error occurred while it was documenting the first)
Sun Aug 25 2019 08:50:34 GMT-0600 (MDT)
Error doing job: Task exception was never retrieved
ValueError: 'd' is not a valid AlarmState
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/local/lib/python3.7/site-packages/homeassistant/helpers/entity_platform.py", line 365, in _async_add_entity
await entity.async_update_ha_state()
File "/usr/local/lib/python3.7/site-packages/homeassistant/helpers/entity.py", line 225, in async_update_ha_state
self._async_write_ha_state()
File "/usr/local/lib/python3.7/site-packages/homeassistant/helpers/entity.py", line 256, in _async_write_ha_state
attr.update(self.device_state_attributes or {})
File "/usr/local/lib/python3.7/site-packages/homeassistant/components/elkm1/alarm_control_panel.py", line 135, in device_state_attributes
attrs['alarm_state'] = AlarmState(elmt.alarm_state).name.lower()
File "/usr/local/lib/python3.7/enum.py", line 310, in __call__
return cls.__new__(cls, value)
File "/usr/local/lib/python3.7/enum.py", line 564, in __new__
raise exc
File "/usr/local/lib/python3.7/enum.py", line 548, in __new__
result = cls._missing_(value)
File "/usr/local/lib/python3.7/enum.py", line 577, in _missing_
raise ValueError("%r is not a valid %s" % (value, cls.__name__))
ValueError: 'd' is not a valid AlarmState
Correct, I mean none of the keypads are attached, not the control panel. And unfortunately I’m not great with command line, but I’m awesome at following directions if you have any advice!
@BioSehnsucht, I do still have the keypads so I can see if I can get one to wire up to see what it says. I’ll report back!
If you can add the following to your hass config (configuration.yaml):
logger:
default: debug
And share your entire log. That way I can see all the interactions with the ElkM1 panel.
Warning, you may have something in your log you want to keep private. Happy if you want to send me a DM with the link to the entire log, so only I would see it.
ElkRP is Windows software that is used to configure an ElkM1 panel. If you have the software then there’s a menu item within it to download the ElkM1 logs. These are not so much debug logs as they are events that the panel has detected. In your case there might be some type of error for no keypads found.
Ok I just tried something for giggles and it actually seems to have eliminated the errors (for the past hour anyway): I excluded the unused keypads from my config and am only including the zones with the sensors that I use for automations (previously I was including keypads 1-3). Now the error’s gone, so it’s got to be related to the “missing” keypads.
I’ll still try @BioSehnsucht’s suggestion to hook up at least one of the keypads to see if it resolves the error, but even though it’s a bandaid fix I’m still getting what I need from the system by using the sensors for automations now error-free.
