I am wanting to first thank all the people here active in this awesome community who has helped my endless times in the past. Active when asking questions or just reading through your experiences. I have been here since V1 and did all the migrations to V5 where we are. Approximately of 10 years with a steep learning curve and lots of changes over the years.
What are my considerations:
My overall goal when I started was to have a robust and reliable system to control my rollershutters. Being in a lot of office buildings, most of the time their control sucks and the shades are never where they should be. I think I succeeded in doing it better. Eventually more and more actors and sensors have been added, multiple system changes on the hardware side in between. It is a heck of a grown system, I’ve been mostly working with file based rules and items. As the concept with the things came up, and paper UI - it slowly grew out of control. So I made up my mind and wanted to redo most of it to make things easier to understand and maintain. Touching a running system is always difficult and some improvements came into place, never finished as new topics, projects came up.
So it is mid of 2025 and I’ve got a new robot vacuum noticing it won’t really integrate with OH, tried some workarounds via Alexa (not using it today) and IO broker but not satisfying. And I always wanted to see if there is something better, different or an easier system out there. Since I have a VMS, firing up a HomeAssistant and just see what it can was a quick thing. Also a great or even larger and more active community. And I was impressed what it auto detected and how it supports 3rd party systems. All control options for my vacuum have been there and some other things I actually put aside (dishwasher which does not run stable in OH and also my shelly BLU devices where I need a workaround with a MQTT solution adding additional complexity). Plus all my standard homematic, Shelly, Sonos etc.
Started doing some transfers of my rules (since I wrote most in JS and NodeRed also supports it, the migration was less painful than expected) and optimized some of my flows/rules. It was a few weeks and nights of work, almost there. Still the small things which take a lot of programming and time (e.g. time table of busses at my house displayed at screen in hallway or some indications on situations). Most of it is much simpler to do or maybe I am just more experienced since starting in 2015.
Not all is great. The organization and visualization is a pain. Either you have an app which displays all „shit“ or you have to do it manually. I really like the sitemap concept of OH. Also what I already noted, the concept with Things is perfect. I had to change a sensor to another brand since starting with it and one need to go into every rule/automation etc. where you use it and change it. That is perfectly done in OH with another layer.
What’s next? I don’t know yet. Since I always wanted to be the master of my home, all my automations are easily halted with the flip of a switch thats how I did it and also how I started implementing HA. I also need to be cautious due to the WAF ; it caused many discussions and I do not want to get back there. I suspended OH and activated HA yesterday night. Already a couple of bugs and improvements noted. If this does not cause too many family protests, I try to solve one by one and looking forward having a more robust, cleaner and fresh system. Otherwise, I might be back.
Thanks again and sorry for my long goodby, it is not easy…
It would be great for us if, as you gained more and more experience with Home Assistant, to provide sort of a list of what needs to be improved in openhab.
I’ll start:
support for/integration with more devices
easier/quicker way to get things up and running, in terms of UI, and that it comes with all the stuff as you mentioned, but ideally a way to turn off individual elements.
To improve openhab integration I have been wondering if we could build a framework in which we could directly import/use Home Assistant’s integrations and plug them through a translation layer into openhab’s event bus
It may be doable in a similar manner as the current mqtt Home Assistant binding with the help of graalpy.
This way, we can instantly benefit from any new or improved integrations that are available in home assistant.
I too use home assistant for the more reliable connection to some services. OH is slower, in many cases, to get the service integration for reasons that have been been covered many times in other threads.
However, what I can say is that with the new matter binding it is easier than ever to bridge between HA and OH and you can have the best of both worlds. A short while ago, I found MatterBridge
MatterBridge is a simple container install and once you setup the HASS plugin in MatterBridge and connect MatterBridge as a node in OH, any HA entities you want to designate (or all of them if you wish) are exposed as matter endpoints that immediately show up in your OH inbox. It’s nearly effortless and has been 100x improvement over setting up MQTT channels in HA and then setting up MQTT things in OH.
If, as I do, you really prefer the OH interface and stability, I recommend giving this a try before moving away from OH altogether.
That kind of sounds perfect. All HA integrations will live within their native HA environment, and they would then appear to OH just like any other matter device? Is it kind of like adding devices directly to Alexa (or Google Home), and then importing them into OH?
So when OH needs to send a command to the device, it goes: OH → Matter → Home Assistant → HA Integration for that device → Device?
And the other direction Device → HA → Matter → OH
Provided that the Matter standard provides the required attribute / data / command, then it should work great. In practice there may be some limitations.
In this case, Matter is similar to MQTT, acting as the communication layer, and Home Assistant + HA Integrations take on the role of “XXX to MQTT” (e.g. Zigbee2Mqtt) except it’s done over Matter?
So far, for the few things I’ve used it for, it has been that simple. Now, I had the matter binding set up already, so that made it easier. Adding that to a first time setup will add a minor level of complexity.
Yep. The MatterBridge HA plugin directly interfaces with HA API, so OH Matter controller talks to the MatterBridge node and that then goes over HA API directly.
Yeah, there are still the limitations of what information types matter supports, but for basic devices it has been rock solid for me.
@parachutesj I hope you find what you are looking for with HA and if not, we’ll be here. Good luck!
It’s probably on par with setting up MQTT in my experience. Only you don’t need to start up an external service (i.e. the broker) and everything is done through OH.
The IPv6 requirement can be a problem for some though. Luckily I was lazy and left it enabled on my network.
Just be aware that interfacing with HA is not the only use for the HA binding. HA MQTT is a standard of sorts and lots of third party services (e.g. Theengs, zigbee2mqtt, etc.) use it. So an add-on that interacts with the HA API cannot be a replacement for what we have now.
But having something to more easily bridge between HA and OH would be a benefit to both ecosystems I think. The big advantage of using Matter is it will bridge not just to HA but to all the big players.
You still need the 3rd service, in this case it’s just replacing the MQTT broker with MatterBridge. The improvement there, at least in my experience is that (just as with OH) setting up MQTT in HA is not a beginner level task. In this case you spin up the MatterBridge container, enable the included HA plugin add an HA API token, and you can be off and running.
Exactly. If it wasn’t for that requirement, I’d be saying that MatterBridge was no-question more beginner friendly than MQTT.
I’ve bridging some of my items over from HA using MQTT long before the home assistant binding was in a workable state so I had my own system for that and it was never worth switching over so I haven’t tested that. Honestly, my MQTT connections were reliable and fast, as expected, so I didn’t really plan to move away, I just saw a write-up about MatterBridge and decided to play with it for a little bit out of curiosity and it was so dead simple, that I decided to switch over for production devices almost immediately.
Similarly, MatterBridge has more than just an HA plugin. There are several pre-made plugins. For example, if I recall, OH users were having difficulty for a while with roborock vacuums (don’t know if that’s still the case). There’s a roborock plugin so MatterBridge might be a really easy solution for those users.
There’s also a pretty open system for creating your own plugin (which I have not tried yet). There’s no need to make an OH plugin for it because it basically replicates what the matter binding does when you configure the matter bridge and expose Items to that bridge, but for some users missing some ecosystem in OH a MatterBridge plugin might be a more approachable dev option than a OH binding.
Or possibly it’s a niche node in an already too-complex web of services…but for me at least it works very well for this use. As it is, when OH reaches parity with HA in terms of a service integration I move my devices over to OH (as I have just recently done now that the homekit client binding is up and running).
I do think that a direct HA API binding is a great idea, however.
It is. With whitelisting (or blacklisting) in the Matterbridge, you can choose which devices to expose and bring to OH. If you have an HA system up for devices not supported in OH, Matterbridge is great. MQTT is fine, but I found keeping track of automations on either side became tedious.
I installed HA some time ago, mostly out of curiosity. Have been using OH since 1.something.
I was impressed with the fact that it recognized my Ecobee thermostats, Lutron Caseta devices, TVs, NAS devices, etc., and it was trival to add them to the system, and that UI controls appropriate to the context were automatically generated. Having climbed the conceptual mountain of OH long ago, it’s not a hurdle to me anymore, but I think there are some things that could make setup easier… setting up a group for a Thing for example, and automatically including any items set up via the channels on that thing in that group.
I like that Homekit is used for the Ecobees, avoiding the cloud.
I haven’t explored the UI setup – although I see very nice dashboard setups in various online groups. The fact that when you add a new device you can immediately access all of its data and controls is really convenient.
I’m currently using it to feed status of our GE washing machine to OH so I can deliver notifications. I’m using MQTT, but may take a look at MatterBridge in case I want to extend to more devices where HA has better support than OH. IPV6 runs nicely on my internal network.
I just installed home assistant and it is still confusing.
I haven’t had a good look at it yet.
It feels primitive. It found a few of my devices but I don’t know what or how to use them yet.
Editing yaml and restarting after changes is different.
I also use HA and OH next to eachother. OH for the interface and the brains of the system. I use HA as a “switch” to read/control devices, such as the aqara FP2 for human presence. Works like a charm with MQTT but as I read here, the Matter integration in combination with the matter binding looks like a simple version of MQTT. Using it will also drop the bar for integrating other “non-OH” devices with OH via HA.
Just to elaborate a bit on @hmerk’s reply, since OH 3 and bringing the semantic model as more of a main feature of OH this has been supported, and the latter statement is enabled through this ability.
There are several ways to do this. If you’ve already an OH system set up and configured and are just adding new devices the most common approach is:
From the Inbox discover your new Thing(s) or manually add the new Thing(s).
From the new Thing’s page, under the Channels tab there is the option to “Add Equipment to Thing”.
Clicking that will open a form where you can choose the location where that Equipment will be placed in the semantic model, name the Equipment, and choose the Channels you want to create the Items for.
Fill out all the details and click save and the Equipment Group Item and all the Items linked to the Channels will be created in one go.
Also, once created, the Equipment and all its Items will appear in the Locations, Equipment and Properties tab of the Overview Page in MainUI automatically.
As mentioned, you can also get to “Add Equipment to model” from the Model Settings page in MainUI. You can also “add Points to model” which is what you would use if the Equipment already exists and you want to add more Items to that Equipment.
Installed home assistant.
Tried a few things. It broke my zigbee2mqtt.
Too confusing. Couldn’t be bothered trying to learn it.
Gave up.
Stick with what I know for now.
I have some features that’ve been in OH for a while to check out. I’ve haven’t been thorough enough about the semantic model, but this should nudge me back into it.
I also just saw that there’s a Homekit binding on the way. Yay!
The additional integrations are surely a plus. I do not have too much experience with special ones to be honest. I am mainly using homematic & shelly. Plus MQTT. That all worked quite well in the past with minor hickups.
While driving a Volkswagen, the integration didn’t work and I accomplished that with IO-Broker in between. Same worked for a while with Roborock until they changed the firmware.
What impresses me on HA is the end2end. I didn’t like the presentation of all the devices and sensors in the first place, I need to find a way how to make this better organized once the migration is complete. What I first did was my central dashboard to have the most important things displayed. If you click on the temperature card for example, you get a chart the whole history for a certain period. All out of the box. Same for the other devices.
Also I have a few ESP32 with a display and using the openhasp integration. With OH and MQTT it was quite some coding to get everything working, in HA it just works.
Again, don’t get me wrong, OH is a fantastic system - I never wanted to do some bashing. And it still has a lot of advantages.
That is something to consider… The devices are synced anyway - both are running together at the moment. The only thing which is important for the control at the end are the helpers from HA, I will try if I can get them synced to OH and then use the app for my mobile devices at least until I found an option which has enough WAF.
That is a bit my concern. I tried to have in my OH the items in the file, the rules in the file and the things in the UI to be able to find it when I look back after 1-2 years without searching for hours.
The major issue I see with HA in that regard - I used NodeRed for the coding and tried to avoid the YAML files as much as possible, but it cannot be completely ignored as far as I understood.
And the other thing: if I have to change a sensor or actor, I need to change all my automations, scripts etc. where it is used
; it caused many discussions and I do not want to get back there. I suspended OH and activated HA yesterday night. Already a couple of bugs and improvements noted. If this does not cause too many family protests, I try to solve one by one and looking forward having a more robust, cleaner and fresh system. Otherwise, I might be back.
