ELK M1 Gold integration with Home Assistant (hassio)
- Thread starter MrTea
- Start date
123
Senior Member
Have you posted your question in the Home Assistant community forum?
There's a thread with over 700 posts dedicated to the development and debugging of the ELK M1 component.
There's a thread with over 700 posts dedicated to the development and debugging of the ELK M1 component.
BaduFamily
Active Member
that's an amazing thread, thanks for the reference. ( I'm considering bringing my home brew integration up to MQTT )
MQTT is great. I recommend you install the separate Mosquito MQTT broker. I'm using Hassio (hosted on unRaid) with Configurator / Duck DNS / Mosquitto Broker / and Node RED. I tried going the separate route, but I'm kind of a Geranimals guy, and Hassio just worked better for me.
When you add ELK to Hass, you can talk to it directly without MQTT. I'm doing all my automations in Node RED, so I use MQTT switches to talk to Node RED, then back to Hass to talk to ELK.
I've followed Hass for years, but felt it wasn't quite stable enough. With the newly released Lovelace interface and Integrations like ELK, I'm loving it.
When you add ELK to Hass, you can talk to it directly without MQTT. I'm doing all my automations in Node RED, so I use MQTT switches to talk to Node RED, then back to Hass to talk to ELK.
I've followed Hass for years, but felt it wasn't quite stable enough. With the newly released Lovelace interface and Integrations like ELK, I'm loving it.
Been playing with HASS for a few months. Finally starting to get the hang of it. The documentation is horrible, but eventually you can piece together enough examples from other users to make it go.
I'm UPB-based which isn't directly supported, but I had developed my own MQTT-UPB bridge and using the MQTT-light components, I was finally able to integrate my lights to a usable level.
I added the Elk component about a month ago and it worked great from the start. Initially it had a ton of extraneous devices on the UI, but eventually I excluded them via the Elk configuration.
I've been using Lovelace for a while and initially it was really limited, but the latest release made a big improvement on the editing capabilities and I think it will be a solid platform soon. I recently added an Elk interface to my Lovelace UI. I think it was called "Alarm Panel" or something like that. It presents a UI that allows users to enter the arm/disarm code by clicking buttons. I didn't see that capability when I tried using an alarm component in the regular UI. Much better.
I watched a YT vid over the holidays from a conference in which the HASS developer presented the upcoming plans. They've hired a couple of full-time employees and that should really help things progress much faster.
I'm UPB-based which isn't directly supported, but I had developed my own MQTT-UPB bridge and using the MQTT-light components, I was finally able to integrate my lights to a usable level.
I added the Elk component about a month ago and it worked great from the start. Initially it had a ton of extraneous devices on the UI, but eventually I excluded them via the Elk configuration.
I've been using Lovelace for a while and initially it was really limited, but the latest release made a big improvement on the editing capabilities and I think it will be a solid platform soon. I recently added an Elk interface to my Lovelace UI. I think it was called "Alarm Panel" or something like that. It presents a UI that allows users to enter the arm/disarm code by clicking buttons. I didn't see that capability when I tried using an alarm component in the regular UI. Much better.
I watched a YT vid over the holidays from a conference in which the HASS developer presented the upcoming plans. They've hired a couple of full-time employees and that should really help things progress much faster.
123
Senior Member
gregking said:
Anything you can share? I'm amassing as much UPB driver code as possible in order to study it and eventually develop a Python UPB library to serve as the basis of a UPB component for Home Assistant. A very long-term project for indeed given that I've never programmed in python.
What I'm about to say won't matter all that much to you now, given that you are using the Lovelace UI, but Home Assistant's non-Lovelace UI (what's called Frontend UI) can render a UI for an Alarm Panel component.
I'm still using version 0.80 and can arm/disarm my ELK M1 via the Frontend UI (the widget looks almost the same as the one you see in Lovelace). HOWEVER, I'm using MQTT to communicate between Home Assistant and the ELK M1 (Premise serves as the bridge between the two). Therefore I'm using the MQTT Alarm Control Panel component. Actually, I'm using a customized version of it because, although it requires the entry of a passcode, the stock version doesn't submit the code to connected alarm panel (i.e. my ELK M1). My customized version of the MQTT Alarm Control Panel component takes care of this requirement.
As for staffing, I believe Paulus is employed by Ubiquiti to develop Home Assistant. Paulus started Nabu Casa and hired Pascal Vizelli to continue development of HassOS and Hass.io (the custom operating system and docker version of Home Assistant). Both are also, of course, involved in expanding the (paid) services offered by Nabu Casa (currently limited to offering an easy connection to Amazon Alexa and Google Assistant). Beyond that, I'm not aware of any paid developers (although the goal is to hire more staff) and most development work is done by volunteers (there's a core team of volunteers enhancing the architecture, under Paulus' direction).
BTW, anyone interested in Home Assistant should be keenly aware that this open-source project has a very aggressive release schedule, namely every two weeks. This is not for the faint of heart. If you want conservative progress with few bugs and breaking changes, this ain't it. Every release introduces breaking changes, and bugs, along with the usual complaints from users about borked systems after (foolishly) performing an upgrade (typically without first reading the release notes). FWIW, I'm still using version 0.80 (that's 6 major releases behind the latest one … and 0.87 will be released tomorrow) because it does what I need and runs without hiccups. I'm running 0.86.4 on a test system, sorting out what I need to do to before upgrading my production system. Frankly, this is the sane thing to do otherwise you're rolling the dice if you upgrade your production system the moment a new release is available (you better have a backup handy).
wuench
Senior Member
The Elk component seems to working good for me now. I had some issues with thermostat support before it was included in the release. I agree they aren't big on testing, it's good to have some python knowledge to be able to go in and patch stuff yourself. That seems to be par for the course for the whole open source/python movement. I really like when someone posts an issue and they throw a fit if the user rolls back instead of helping them fix the problem. But on the plus side when harmony dorked things up the HASS guys had a workaround released in less than two days, and the level of noise on the HA sub-reddit was probably a major reason in logitech reconsidering adding API support back in.
I originally had HASS running on linux with a python virtual environment, but after my first upgrade I learned better. I now run HASS in docker, with my config files in Git. So everything is now version controlled and easy to rollback.in a few minutes. I am not ready for HASS.IO that seems a little too limiting for me. 86.4 is ok for me, had a few hiccups but nothing major, mostly due to the node renaming stuff. 86.0 was a disaster though and I had to roll that back.
I originally had HASS running on linux with a python virtual environment, but after my first upgrade I learned better. I now run HASS in docker, with my config files in Git. So everything is now version controlled and easy to rollback.in a few minutes. I am not ready for HASS.IO that seems a little too limiting for me. 86.4 is ok for me, had a few hiccups but nothing major, mostly due to the node renaming stuff. 86.0 was a disaster though and I had to roll that back.
wuench said:
Did you have any problems connecting? I have an Elk M1 I'm migrating from Control4 to Home Assistant. Home Assistant runs as a virtual machine in VirtualBox on a Fedora 32 host. Using the official appliance file (.ova) from Home Assistant. I'm connecting to Elk M1 via serial. Connect to Elk M1 - only use type and serial port (everything else empty/default). Threw some errors at first about not being able to open the port but have fixed that through file attributes. Now the VM starts without errors but still not able to connect
tfmeier said:
Some more info here. I had an older Fedora 25 system (running VortexBox) and installed VirtualBox 5.1 on it (yes... a fairly old version) and the corresponding expansion pack. Same Home Assistant .ova file. Elk M1 interestingly connects on this version on /dev/ttyS0. Attributes as follows
[root@vortexbox ~]# ls -l /dev/ttyS0
crw-rw---- 1 root dialout 4, 64 Sep 30 18:45 /dev/ttyS0
[root@vortexbox ~]# whoami
root
Of course I shouldn't run this as root but I'm still puzzled why this wouldn't work on Fedora 32...
