I noted a small inconsistency in the alarm variable type in issue 15. Most of the time it’s a string array, except when the value is Entry Timer Running. It might be impacting certain automations.
Say more. I just read the issue. What is the “alarm variable”? Where do you see that?
I’m in the code right now. The arm/disarm stuff is complex as some of the messages the Elk sends don’t make sense to me (yet).
Ahh. See where it is set. What do you believe are the correct values?
Would disarmed, armed_home, armed_away, armed_, pending be the values you want to see?
Interesting. Looks like the times it’s an array are when I’m setting it using a helper function from @gwww 's library, the other time I’m setting it in my code.
Though I don’t think this should be the cause of @matthewjohn automation troubles since he’s triggering on the state not the ‘Alarm’ attribute. The state is set using HASS constants.
I am glad to see someone working on this. I have been slow to the hass environment because of this reason. My home is full of X-10, being controlled by Elk M1G, and since I have so much invested, it’s hard to change. Especially when it works.
But I have considered doing a Binary setup with a ESP8266 NodeMCU, along with a M1XIN, It would be only for the lighting control, but this sounds promising. With the NodeMCU, I wouldn’t need to buy another XEP for my remote panel in garage.
I’ll do some testing if needed.
When you say “this reason”, which reason are you referring to? There’s a couple of bugs being explored at the moment.
The Elk support in the gwww branch has been pretty solid for some time now, and now this recent activity on the Alarm component support. I’ve been using it for some time now controlling X-10 modules and monitoring the Elk zones from Home Assistant with great success.
In my case, the number of X-10 device is slowly declining as they crap out; most recently, the X-10 PIR floodlights - and there’s really no replacements available. Instead, I’ve been installing Z-Wave switches and bypassing the X-10 PIR in the flood lamp fixtures as they fail.
You can also trigger Elk automations from Home Assistant, and likewise see when they are triggered b Elk rules. I’d say you should dive right in for your lighting control needs…
I have a lot of my ‘Automation’ built into my ELK M1G, there is not really a lot I need to add to it, other than a few small thing (like LED control), so I really didn’t want to move away from it. BUT, being able to integrate it into HASS, there is many more possibilities when I begin to expand.
Although X-10 isn’t the greatest in today’s market, having to purchase multiple devices to utilize another controller ‘HASS’, isn’t worth the expense.
@WSmitty, I think that you might find it easier to implement the automations you have in the Elk in Home Assistant. At least that’s what happened in my case. Even if you don’t swap about any of your X-10 modules, it sure is handy to be able to interact with sensors and other devices outside of the Elk.
The nature of the Home Assistant integration is such that you have visibility into all of the zones and pretty much all of the other state inside the Elk. As you add devices and sensor and other equipment, Home Assistant is a really handy way to integrate over lots of different technologies. I love the fact that I can push a button on an Elk keypad, have that fire a Home Assistant automation which can turn on X-10 lights off the Elk, a floor lamp connected to a Sonoff WiFi swtich via MQTT and maybe some Z-Wave lamps.
The only automations that I have left inside my Elk are to be able to “Chirp” the outside speaker; there doesn’t seem to be any way to do that with the Elk serial protocol, other than to invoke some Elk automations to do so (which I can do from Home Assistant.) I’m pleased that my Elk configuration is fairly minimal and fixed now, as I don’t really find using ElkRP2 all that a pleasant experience - I have find my Windoze VM, launch it and ElkRP2 which takes the Elk “offline” while I’m fiddling with it.
That being said, I’m not making use of any custom voice announcements in the Elk, and I’m not sure what the state of affairs is there…
For what it’s worth, I found having Home Assistant the “center of the universe” work out much better than having automations split between the Elk platform and Home Assistant - especially things like do automatic thermostat setbacks and the like.
You milage may vary, of course 
@lmamakos, There are some programming limits to ELK thats for sure.The more I play around with HASSio and utilizing MQTT, my mind goes crazy with the possibilities. Now I cant wait to add my panel to it. Hopefully within the next few weeks I can set aside some time to review all of the postings to see just how I can do this, the easiest way, from others lessons learn posts.
Thanks for the information, I look forward to reading/hearing more.
Going forward everyone should get their updates from the master branch. We’ll use other branches for testing changes and then merge them to master when they’re ready, versus everyone hoping we don’t break the branch they’re using (as it has been for a while).
I’ll also be making releases via Github to correspond to the updates to master branch, so you can simply download an archive of the code if you prefer rather than having to navigate the details of Git.
I’ve just made a release of 0.3.0, which is really just where things were already for a few a while now - if you’ve updated recently then you probably won’t see any changes. But if you were using Git to update previously you’ll need to switch to master branch going forward or just simply start using the releases and not using Git directly.
awesome, thanks again for all your hard work! Can I suggest an edit to the readme? I’d like to see directions on how to install it for future interested parties.
@BioSehnsucht - I’m still having an issue with the Elk triggering the “Triggered” state right after the entry/exit timer. What I’m seeing is just about a half a second where after the entry timer has been set off, the system goes to triggered then back to normal. It does it very quickly.
The result is my siren chirps for half a second and I get an email alert saying the alarm was triggered each time the entry timer is enabled and I disarm my system.
Does that make any sense?
I need some details.
Are you running the latest code? Version number?
Does it happen on arming? Disarming? Both?
How are you determining “Triggered”? Can you share the config/script that does that?
If I do think of something to try are you comfortable editing some code? I will be fairly basic “cut out these lines and replace them with these lines”.
Can you turn on debug logging and make the log available to us (me and @BioSehnsucht). To do that you should have:
logger:
default: debug
in your configuration.yaml file.
If you DM me I send you my email so that you can send the log.
I’ll look further at the code but there’s nothing obvious. If you are running the latest then the TRIGGERED state only happens when the panel says that it is in alarm state. I don’t see that happen with my panel.
1 Like
Latest code. Only on disarming. I posted this already:
alias: Alarm System - Triggered Sound Outdoor Siren
trigger:
- entity_id: alarm_control_panel.elkm1_area_001
platform: state
to: triggered
condition: []
action:
- alias: ''
data:
entity_id: switch.switch_13
service: switch.turn_on
I can do more when I get home.
Still no ideas from me. I just did a test arming, exit house, wait for fully armed, enter house, then disarmed. Nothing in the code should return triggered state. I captured the logs from the base library, double checked them – nothing there. I’ve looked at the ha-elkm1 code and don’t see anything there.
We’re on to logs to figure out next step.
Just to make sure, latest code is from GitHub last night? Perhaps you could share the file from your config called custom_components/alarm_control_panel/elkm1.py as well as your log.
Nothing in the code looks like it will return a trigger state.
What are you’re entry/exit timers set for in terms of duration on the Elk itself? (trying to think of things that might be changed and different between your system and ours)
Hey @matthewjohn, I’m wondering if your automation is not correct. The formatting/indentation looks a bit off to me and I’m wondering about the keywords. Consider the example under STATE_TRIGGER here: https://www.home-assistant.io/docs/automation/trigger/
Perhaps something such as this might work:
automation:
trigger:
platform: state
entity_id: alarm_control_panel.elkm1_area_001
to: "triggered"
action:
service: switch.turn_on
data:
entity_id: switch.switch_13
Maybe? It was created with the web interface for an automation.
No. Just reading the docs. It’s probably the simplest thing to try. After that we’re onto logs…