gregking said:
...I had developed my own MQTT-UPB bridge …
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.
.. it was called "Alarm Panel" or something like that. … I didn't see that capability when I tried using an alarm component in the regular UI.
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).