I’m a longtime Home Assistant user and have HA at the core of my home. I can’t live without it anymore. When I look at the professional building management market I see a huge opportunity for HA to fit in, because of the flexibility and wide range of integrations.
Use cases: Building managent of heat, energy, ventilation, monitoring of sensors, rooms in conjunction with deployed building systems such as door access, etc etc.
However HA is geared towards home enthusiasts and lacks certain features for professional building management installations such as:
A stable long time supported release,
Scaling: performance and sizing,
Redundancy such as clustering of HA instances and on the OS, DB level,
Failover support
etc. etc.
If this is (someday) implemented it would allow businesses to develop services to support and deploy HA as building management software.
I understand this is a new direction but I would love to see HA implemented in production as this is great way to expand user base of HA and it’s applications. Furthermore the existing building management software is very closed and not very flexible. Time for a change.
Please vote this feature request up if you love this idea too!
these two points you can (partially) solve yourself by running the database on something other than the default and set it up with high availability (HA), same can be done on the OS level if you virtualize and set up replication and HA on the virtualization layer.
I’m unsure what Home Asistant would bring to the professional market though. Could you elaborate?
I’m sure you just refer to the DB part, not the Core clustering. As that would mess up the db stats drastically as each instance would write the same state updates.
Failover would even be similar tricky as a second instance should not do anything til the first stopped comletely.
But on the other side, the DB is not the main thing for running HA and benefit its functions. But it all depends on the use cases.
HA is stable enough to run on any site.
Crash recovery is fine if you run indeed the DB seperated. Then your Core deploy is stateless and easy to spin up , you’re back in no time.
I’m not talking about clustering, I’m talking about high availability. You wouldn’t cluster the home assistant installation, but replicate it. In the event of a failure you would lose data equal to point in time you did the last replication. I can do this at my home right now if I saw the need, but I don’t - I do daily snapshot backups instead and have no problem potentially losing 23 hours of data.
Failover wouldn’t be too tricky, you can do that automatically actually. Usually it requires licensing though.
But all in all at the current time I would go another route for the professional marked. I am guessing there’s would be a lot of support work and maintenance involved in using HA in a professional setting too.
Are you currently planing a business that may utilize HA?
HA is open source and if I were planning a business around it I think I would ultimately be or hire a developer, fork it and customize to my businesses needs.
Beyond that everything you requested can pretty much be covered using existing solutions.
That’s very suboptimal because it requires architectural changes. This is why it needs to be part of the HA Core development. Do you know what it takes to run mission critical operational technology? That’s the goal here.
Offcourse HA is only the first step, because you need reliable hardware, commercial support etc. @tmjpugh
So this is interesting thinking. I work for a company that does services on an opensource product. As long as you sell it as services and make it run as how you think it should be done, there is no need for any adjustments.
If mission critical means it needs to achieve 99.99 uptime, you have some challenge but not beyond possible as i see it.
If you’re looking for features to manage multple buildings etc, yes it requires development, but that could still be done outside HA core development. You’re free to expand and built around with anything you need.
Would love to know what architectural changes you’re thinking of…
In general, everything described in this topic has already been proposed in other topics, including by me. Yes, it is clear that HA is aimed at ordinary users who do not need redundancy. But it’s worth looking at what HA was like many years ago, and what it has become now. Now there are actually no breaking changes, and there are yaml migrations. There are warnings that something will become obsolete at some time. There is an automatic repair section. There is even catching of crashes, which is generally not typical for web applications. It would seem that many things are not needed by ordinary users, but they were useful to them. It’s important to continue. Therefore, when it will be additional option, for example, to run 3 cores simultaneously and in case of fails, select readings where the majority is. Also self-diagnosis systems, determining that the main event bus is frozen. Launching demons that watch and detect it. More detailed log levels. Ability to quickly enable sending of logs by email. This is all very positive, no one is asking for it to be added right away. It is enough to do something once a quarter. You have to think that HA is used by the aircraft control, while being only an automation tool. But on the other hand, HA’s mission is huge. For example, many people already use it to notify about fire. Even one life saved due to the super reliability of HA is priceless. Therefore, of course, it is worth investing the time of kernel developers here.
I was faced with the fact that the Philips lamp did not turn on. (when turned on, it switched from the off state) In this case, the device was not offline, there were no errors in the logs. Restarting Home assistant helped. To get closer to production level, there should be no errors that are not logged.
Of course I did so. I’m talking more about fault tolerance here. Perhaps in automation users should choose what to do if a device involved in automation fails. As an option, make an option to roll back the state to the previous ones, for what was changed during automation