Okay I was wondering about that. Okay - I removed the old elk installs from the custom_components folders. I did have to remove a few configuration parameters that no longer worked with the built in elkm1. This also fixed the new Lovelace alarm panel that I complained about not working earlier. I believe others were having the same issue. If your Lovelace Alarm Panel is not working, try removing the elkm1 files from the custom_components folder. Once everything was working, I upgraded to .88.0 and everything seems to be working fine! Thanks for the help!
I also wanted to post one more observation. In the configuration.yaml file under elkm1 I am using a serial connection. my configuration looks like this:
elkm1:
host: serial:///dev/ttyUSB0
# host: ///dev/ttyUSB0
area:
exclude:
- 2-8
# user:
# exclude:
# - 5-200
plc:
exclude:
- a1-p16
output:
exclude:
- 1-208
task:
exclude:
- 1-32
thermostat:
exclude:
- 1-16
counter:
exclude:
- 1-64
keypad:
exclude:
- 2-16
setting:
exclude:
- 1-20
zone:
exclude:
- 13-208
What I want to point out is that the serial connection needs three slashes ( host: serial:///dev/ttyUSB0) all the documentation online for home assistant shows it with 2 (//)
Ah, that was documented correctly once upon a time before it was merged into HASS. I wonder if someone thought it was a typo…
It’s because we’re doing URI parsing on the host setting ([protocol]://[IP or device]), and serial devices on *nix are going probably going to be /dev/something … so three /'s . Though I guess we could have extra logic that adds the / back in if it’s missing on non-Windows platforms (for Windows, it would be something like COM1 … )
1 Like
Has anyone been able to ‘see’ their ELK sensors / switches via the IOS Home App (via HomeKit)? I see my ELK via home assistant but NOT in my Home App. I’m using HomeKit.
I’ve implemented an improvement to the Elk M1 component to provide support for multiple Elk M1s within the same hass instance. It requires a new version of the elkm1 library from @gwww that he and I have collaborated on. The pull request for the changes to the Elk component is https://github.com/home-assistant/home-assistant/pull/22573 and I could use some help in shepherding it through the integration process as this is my first PR for home assistant.
Any feedback on the PR is appreciated and help getting this in is even better!
2 Likes
how is everybody triggering a momentary relay switch to the M1? I’ve got my garage door openers hooked up to an ELK-M1RB, and when I try to trigger the relay for 150ms, it seems to open then close the door… Any have any thoughts? Here’s the script I’m using
garage_momentary_single:
alias: Single Garage
sequence:
- service: homeassistant.turn_on
entity_id: switch.output010
- delay:
milliseconds: 150
- service: homeassistant.turn_off
entity_id: switch.output010Have you tried using a longer button press duration? Depending on how much if any debounce there is on the garage door opener’s input, it might register a brief pulse as multiple presses.
1 Like
I generally rely on Elk rules to do this activated by tasks then just call the tasks from HA (or other rules, etc):
WHENEVER Open Garage (Task #) IS ACTIVATED
AND Garage Door (Zn #) IS NOT SECURE
THEN TURN Garage Door (Out #) ON FOR 3 SECS
150ms is probably too tight especially since your output is on the bus and you are trying to call it from an outside system via the API.
1 Like
Thanks, this works great now! It’s a much more consistent experience, and totally makes sense now that you explain it this way.
@jsg4 reported an issue trying to arm while using lovelace:
‘Failed to call service alarm_control_panel/alarm_arm_home. invalid literal for int() with base 10’
Which sounds to me like trying to arm without first entering a PIN code. However I don’t remember any recent complaints so I assume it should be working (and letting you enter a PIN code) ? I can’t test at the moment, away from the system to check the behavior… has anyone else had issues with lovelace recently?
I just armed/disarmed via lovelace a few times the last few days, no problems at all. However, I have seen that error though, but I seem to recall it was a few versions back, maybe it was related to something else… I’ve never been able to reproduce it.
Looks like it happens when the alarm is in the processing of arming and I am trying to disarm from the lovelace widget. When I tap on the entity there is no error. Example… Thanks
does anyone have any issues showing all your sensors (zones) from ELK M1 to HomeKit? Zones are suppose to represented as “Sensors”
-
Sensor - Elk-M1 counters, keypads, panel, settings, and zones are represented as
sensorentities.
I tried including Sensor under Domain with no luck. I also tried via the ‘include entities’ still no luck.
Do you already have other sensors/things working from HA in HomeKit, or are these the first things you’re trying to get showing up in HomeKit? (I don’t know anything about HomeKit myself, just trying to ensure we’re diagnosing a Elk platform/component problem and not a HA/HomeKit problem if possible)
This error when trying to disarm during arming sounds similar to one I think we ran into on the non-lovelace interface. I can’t recall if the fix should have been interface agnostic or not, or even if it was fixed, but this sounds familiar. I think part of the problem then was that I had made assumptions about what certain states meant (due to less than clear documentation and my less than perfect understanding of alarm nomenclature).
Is the issue only occurring if you try to disarm during the exit delay? How about trying to disarm during entry delay?
sorry yes i do have others showing up. I have counters and keypads as sensors. also outputs as switches.
I’m just not able to get the zones to show up. seems like everything else does as noted in the document . I’m just not able to see the zones.
My wife is going to hate me. I have been playing around a bit with the elkm1.speak_phrase and elkm1.speak_word services, and what fun!
<BEEP><BEEP> INTRUDER ALERT INTRUDER ALERT EVACUATE IMMEDIATELY WARNING INSIDE MACHINE GUN ACTIVATED <BEEP><BEEP>
Heh, heh.
The vocabulary is limited, but serviceable. There is no “FOR” word, so I can’t have the Elk say
FOR A GOOD TIME CALL EIGHT SIX SEVEN FIVE THREE OH NINE
oh well. I need to use HAVE instead of FOR 
Seriously, I’m pleased to find, either by design or fortunate circumstance that you can invoke a bunch of these individual service calls back-to-back to string together a longer phrase. I found that using hass-cli was handy to play with this by doing:
hass-cli service call elkm1.speak_phrase --arguments number=212
and the just wrap that with a shell script or something…
The words and phrases available are listed in the ELK-M1_RS232_PROTOCOL_v1.xx.pdf document near the back.
1 Like
I never got around to testing it myself, did you have to provide any kind of time padding between commands or did it just simple work as hoped? I had wondered if multiple voice commands in rapid succession would cause the following ones to all step on the previous one and you’d end up with a brief garble and the last word sent …
If it just works with spamming the Elk that’s awesome. I haven’t had much time to mess with Elk but in the back of my mind I always wanted to add a command to speak entire phrases by splitting the words out and automatically waiting but if we can just spam the Elk that makes it even easier.
As for the lack of ‘for’, you could try substituting ‘floor’ or ‘or’ 
@BioSehnsucht, I didn’t add any padding in at all. Just to be clear, I’ve only been invoking the service using hass-cli for the moment with a bunch of calls in rapid succession. But I’ve queued up 8 or 10 word long phrases, word by word, and it seems to work. So the Elk must buffer these things up inside. I see no reason why call the service multiple times from a Home Assistant script/automation should be any different.
I suppose it’s possible there’s some sort of flow-control on the TCP connection vial the Ethernet adapter to the serial connection on the Elk, but I don’t think I’ve ever seen any evidence of that. I’ll have to see if other events or messages generated from the Elk block while it’s working its way through a sequence of queued up words. Maybe see if I get a report of a zone violating while it’s speaking the long phrase. But I doubt that’s going on. According to the protocol manual, there’s not even a response message to the “Speak Word” or “Speak Phrase” command. Feels like there must be some sort of queue in side. It seems like at least some of the phrases you can command it to speak are a sequence of individual words that are also available, so maybe the same mechanism is at work?
So just “fire and forget” seems like it should work for most use-cases. As a bonus, there’s a phrase (238) that will just have the Elk speak the current time, without having to construct it yourself. That should be handy, along with few hundred millisecond long 800Hz tone.
I think the first real automation is greeting my mother-in-law when she drops by to feed the cats. She has her own code on the Z-Wave door lock, so easy to tell who’s coming in.
There is “flow control” in the sense of TCP but easily all the commands would be fully sent before the first word was done speaking. So creating a proper “phrase” service shouldn’t be hard if I have the time to play with it in the future, just split the string and loop sending the appropriate word command for each element.