That might work, i am trying to move all of my automations out of the Elk and ISY into HASS and Nodered where it is easier to maintain.
For function key presses, you can tie these to invoking an Elk task. And then trigger on the Task invocation within Home Assistant; the Task itself on the Elk can essentially do nothing. And the you can also tie each function key to a virtual output (mapped to as Home Assistant switch), and use that to control the state of the lamp on each function key on each keypad.
I not quite understanding you yet. You can see the system_trouble_status on the panel, right? Is that the value is not decoded?
I’m looking at supporting the KC message from ElkM1 – it reports all key presses except the digit keys (for security I presume).
It won’t likely make the 0.83 release… maybe the one after.
Keypress changes now will show up as a device_state_attribute on a keypad sensor, probably on 0.83 assuming that the PR gets merged before ~Friday.
https://github.com/home-assistant/home-assistant/pull/18393
All keys that the ElkM1 supports are supported. The list is here: https://github.com/gwww/elkm1/blob/master/elkm1_lib/const.py#L170-L189
If you want to have the lights turned on by the Elk because you want to be absolutely sure they’re triggered by a fire alarm (vs assuming HASS hasn’t crashed or whatever), that’s understandable. But you don’t need the Elk ‘lights’ enabled in HASS for this, you can set up the Elk to do everything as you want, as a secondary controller, and then just not pass any of the lighting system information to HASS by disabling the ‘light’ config section of the Elk integration. Basically do what you were saying you wanted to do, but skip worrying about any kind of support for secondary controllers and disable the Elk light integration to prevent duplicate entities - that is I’m assuming the lack of support in HASS is not that you can’t set one up, just that HASS won’t be aware of it (which is fine for this purpose).
Then, if you want HASS to know a fire alarm has tripped, you could simply turn on an unused output or activate a task and either of these can trigger automation in HASS… Although I am pretty sure the alarm_control_panel.* entity for the corresponding Elk area should become triggered with the alarm state set to fire alarm anyways …
I figured it out. I had to add the PLC item to the elkm1: configuration. Then simply pairing the Leviton controller to the Z-Wave network did the trick. No need for formal replication. I can now trigger lights from elk to hassio “on-alarm” in the M1 itself.
However, now I’ve got more than I ever wanted in the way of elk light entities in hassio. I see what you meant… Sigh, may have to restore a snapshot and pursue the switch.OutputXXX trigger idea.
Thanks for your help. I’m on a steep learning curve.
1 Like
@DamianFlynn Is this what you were hoping for? https://github.com/gwww/elkm1/commit/321dd11c13ecff3e15b8fdbb562d53a05a200704
Would you change anything?
While the code is on github I have not pushed it to PyPi and have not updated hass to use this code yet.
I have got my 2nd Elk running through a Raspberry Pi Zero Wireless today. There were a few funky things I was dealing with and thought I would first Say Thank you to @gwww & everyone that spent their time getting this thing up and running. This is AWESOME. My second panel is in my garage, about 300 foot away from the main home panel. Originally I was informed that I didn’t need to panels, mainly due to cost, but due to the length of the run, I was unable to effectively use any other method.
Anyways back to the issues. Originally I tried to go cheap and use an older micro sd card 8gb was/is more than enough since all I am doing is echoing all of the states to the main HASS unit. Even though the space was adequate, the speed of the older card really inhibited my readings. So bad that I actually though I burned up the new Pi when I did this next step. Secondly, I wanted to connect direclty from the Pi through the serial pins to the Elk M1G. When I connected the DB9 to the Elk, the system would not communicate through the wireless connection. period, nada, zilch.
Maybe this was due to issue #1? I will go back and revisit this earlier next year, dunno yet. But I found an old usb to db9 (serial) adapter laying around in a box I have. Yes we all have that box of cables. Purchased a new 32gb Sandisk Ultra U1 A1 card that I found on sale. Formatted it and set up a few things to utilize over the network and BAM!!!
This thing is super fast and connected right u to relay my lights and sensors from the Garage. Got the web page looking decent, and about to create the keypad page to attempt to get some Node-Red automation set up for it. Anyone done any MQTT with this yet? Would love to hear what you have done.
Well a huge thanks goes to @BioSehnsucht who got this going and did tons of coding and more importantly understanding the ElkM1 protocol!
Very cool what you are doing!
I’m trying to put together a picture in my head of what you have running. Two ElkM1 systems connected to a single hass instance?
The RPi0 is connected to the ElkM1 using serial. Is hass running on that Pi0, or proxying the serial data over Ethernet?
I have not done anything with MQTT. There are others that are interested… maybe they will help out.
I love hearing these stories!
I am running HASS on the pi0 as well, but I am using MQTT_Statestream & MQTT_Eventstream. They echo every event and state to my main HASS system via mqtt. You can filter what events are sent, but until I am completely set up, I want all details.
Whoever gave you that advice was either misinformed or profited from the sale of a second M1. Unless the combined zones at both locations exceeded a single panel’s capacity of 208, I don’t see why they didn’t just install one or more Zone Input Expander boards at the remote location and run CAT5 back to the panel for the RS485 bus (the RS485 bus can operate over very long distances; 300 feet away is chump change. Perhaps the issue was the difficulty of running a hard-wired line between the two locations?
Nonetheless, I’m glad to hear you established communications via HASS on an RPi with the ELK M1 component. Be advised that one drawback is that, if you need to modify the M1’s programming using the RP2 software, you will have to disconnect the RPi from the M1 to gain access to its serial port. If this proves to be a huge inconvenience (it shouldn’t) you can always pony up for an M1-XEP to provide native Ethernet support. Then you can connect to it with RP2 without physically disconnecting anything.
Speaking of RP2 and the M1-XEP, when the two connect, all other communication ceases. In other words, when the RP2 software is connected to an M1 panel, via Ethernet, the panel stops sending/receiving M1 protocol traffic. From the point of view of an HA system the M1 panel is effectively disconnected.
To be clear, this is how it worked when I wrote an ELK M1 driver over ten years ago. Perhaps subsequent firmware versions have eliminated this blockage. I haven’t kept tabs on the release notes and still use a 4.X version of the firmware (since 2008; if it ain’t broke, etc).
There’s a specific message transmitted that indicates the M1 is engaged with the RP software therefore the driver can handle that situation appropriately. In addition, the driver I created can optionally refresh the configuration immediately after the RP software disconnects. The rationale is that you’ve used RP to modify the M1’s configuration so those changes should be automatically retrieved by the driver (new or renamed zones, new PLC devices, etc).
Having said that, I don’t think that feature would be applicable to Home Assistant because, and correct me if I’m wrong (I’m a Home Assistant novice), a component can’t modify entries in configuration.yaml. In Premise Home Control (the HA system I’ve been using for over a decade), my driver can discover then add/subtract zones, outputs, keypads, etc it can rename them as well. FWIW, I think Home Assistant is heading in this direction with the advent of the JSON-style configuration files used by the discovery process.
I also included a feature called ‘Clock Sync’. It periodically synchronized the M1’s time (with the Premise server). Perhaps others might find this handy as an addition to the ELK M1 component. Similarly, I included the ‘Voice’ feature which allows you to define M1 spoken phrases. You pre-define the phrase (see image above) then trigger it whenever appropriate (for example, from an automation).
If assistance is needed to implement this or other features, I’m willing to help. However, I think I’m very late to this party because 99% of the functionality appears to have already been implemented. 
1 Like
If you’re literally connecting to the Raspberry Pi serial I/O pins on the connector, be aware that the serial port is 3.3v “TTL” signal levels, not RS-232 signal levels that would appear on a DE9 connector. You probably need a TTL/RS-232 level converter to make this work.
1 Like
@Smitty357
Exactly this. The easiest option is to get a generic USB serial adapter and use that, but you can also get TTL to RS232 converter boards if you still want to use the Pi’s on board serial.
1 Like
We do detect that RP has connected and stop sending messages (though we can still receive messages so the HASS state continues to follow the Elk), and when “reconnected” I believe (we were, I think still are) kicking off a background thread to get any changes (i.e. names of things). We don’t add/remove devices, all devices that are included (or, not excluded) via configuration are always there (because reasons - TL;DR doing so dynamically in HASS is hard and it wasn’t a priority when trying to get the integration included into HASS)
We did have some magic to hide entities if they appeared to go away (though this was not available for all types of things as only some things had ways to guess at their existence, the Elk ASCII protocol doesn’t let you see the details the RP2 one does), but we had to ditch that on inclusion into HASS proper because in the new Lovelace UI there’s no such thing as a hidden entity …
I did kick around some ideas for having a service call you could call from the developer tools panel in HASS to kick out a “best guess” configuration section to copy and paste to make setup easier, but haven’t gotten around to implementing it. Alternatively could do it with command line util using Gwww’s library.
I’m using Home Assistant as a frontend to my existing Home Automation system (Premise) which already communicates with my ELK M1 panel (via the aforementioned driver I wrote). The two Home Automation systems communicate via MQTT.
Our garage door is controlled by an ELK M1 Task and Output. We can toggle it using the F5 key on our two keypads. If you examine the Main_Entry keypad in the image I posted above, you’ll see F5 is defined as Garage_Door.
I have the HomeKit component installed in Home Assistant. So now we can control the garage door by speaking to Siri. Here’s how the plumbing works:
The responsiveness is excellent despite the lengthy chain involved in making this magic happen:
- Speak to iPhone: “Hey Siri, close the garage door.”
- Voice is converted to a HomeKit command (probably via Apple’s cloud servers).
- Command drives HomeKit app on the iPhone.
- HomeKit app knows the garage door is connected to ‘Home Assistant Bridge’.
- HomeKit app tells the Bridge to close the garage door.
- Siri responds “Okay!”
- Home Assistant has
cover.garage_door_openerdefined as an MQTT Cover, so it publishes topremise/command/home/house/garage/garagedoor/toggler/state. - MQTT Broker receives the topic’s payload and notifies its subscribers, namely Premise.
- Premise converts the MQTT topic into a native command and triggers
Home.House.Garage.GarageDoor.Statewhich is connected to an ELK M1 Task. - The ELK M1’s Task announces the garage door will close in ten seconds (there’s a speaker in the garage).
- After the 10-second timer expires, the ELK M1 closes an Output for 1 second which triggers the Sears garage door opener to toggle its state.
- The garage door proceeds to close.
- Upon the door’s closure, a reed-contact sensor is closed thereby informing the ELK M1 that the garage door is now closed. Premise receives this information from the ELK M1 and publishes it to MQTT. Home Assistant is subscribed to that topic and displays the result in its Frontend UI. We see the confirmation that the garage door is now closed.
1 Like
I figured that out after the board locked up on me. Luckily I had the 'extra; micro sub to usb to serial adapters.
I may leave it as it is now, since I haven’t used the adapter in a couple of years anyhow. I was looking to complete on as cheap as possible. 
How was this information gathered?
You mention how you have some custom functions on your hass running with your keypad buttons. Can I get a few samples of the way you get the data from your Elk into mqtt? I am drawing a blank here, and the things I have tried doesn’t seem to work.