That has been reported by others on this forum by others but we are hardly experts on HA’s intentions and we should not spread second hand information as if it were first hand info.
I’ll second that is probably a question better for their forum than ours.
I would suggest not using the word “force” if/when you ask on the HA forum.
Since this is going to keep coming up, I spun up HA on a Dietpi server to get a better sense of it. I was impressed by how it immediately identified devices on my WiFi network, including:
It strikes me that they’re trying very hard to present HA like a consumer-focused web appliance, and that’s a good thing for attracting new users. It’s much closer to the simple Alexa/Google/HomeKit experience that consumers have become accustomed to over the past decade, so it’s not as much of a leap as OH is. I imagine that some HA users never feel the need to touch the Linux command line or manipulate files directly.
I would expect that power users can still get into text-based configuration if they want to do so, but that’s just a guess. I don’t plan on going that deep, as I’m more interesting in evaluating the “average consumer” experience.
As of OH 4.1, OH should recommend addons to install for most of those now too as part of the first run wizard and any time you open the add-on store.
Discovery for hardware plugged into the OH server (e.g. Zwave, Zigbee, etc.) is in work but not yet merged I think.
It sees my printer and Google TV/Chromecast devices. The rest I’ve already installed and use. Work is ongoing to improve that first run experience in OH.
Cool. I’m planning to build a fresh system when openHABian shifts to Bookworm. I’m also keen to try the Network UPS Tools option that’s now available in openHABian.
Yes try it as I and some testers just went through and made some improvements which will come out in the next milestone for Reolink. Jar is already available if you want to run it on any v4 core.
I can confirm this. Overnight a private company (NCasa) made the direction change decision to just stop textual config for all new style integrations. This should not be confused with textual definition of rules/automations, its just the setting up of their form of binding, thing and items(?). It annoyed a lot of long time users and it happened probably two years ago when we were releasing V3 and killing our V1 bindings.
All newer integrations are like our v2 bindings and in HA they can only do UI config. Their form of our V1 bindings cannot use the UI for config, and only work with textual config. This was the same with our V1 bindings, they could not use the UI. So in HA it’s not consistent and a huge pain to be forced to learn two ways and know which one needs to be used.
There’s also talk that their V1 bindings/integrations are not getting upgrades unless they are fully rewritten in v2 style. What the future holds over there is not clear what will happen to the older integrations, it makes sense to get rid of them all, or they appear to be leaving them broken to force people over to the UI only newer integrations instead of making an announcement that will anger users. The result will still be the same. This direction is made by a company and not a group of volunteers that discuss the future.
When these changes went down, they then introduced tracking and data that gets sent home so they could work out how to kill off old code with the least amount of backlash based on statistics of how many users are doing what.
Our projects are similar so we both face the same growing pains, like getting rid of V1 bindings, but we are making different choices and run in a different way.
Yes I agree, and it’s why I am so certain that their old V1 bindings are going to get the axe and very soon, and it may not be a direct shutoff date. Cutting off any improvements and fixes so people have to move, until the tracking shows the use is low enough to remove the code. They are working towards targeting users that want to pay for a cloud service, because it is the easier way to get remote access.
Its great we finally have this after HA has had it for 3+ years. But we are still not close to what they do to ease new setups. Without any steps needed, you can go to a ready setup widget for your chromecast, type in some text and have text spoken out your speakers. Auto thing accepting, auto widget adding to main UI and setup of text to speach and tying it all nicely into a ready made solution. They have done a good job of it, just for everything I like, there are two things I do not like and its only a matter of time and setting up to gain the same stuff here.
Thats all I do, I test and compare how cameras and other bindings I have written work like in their platform to ensure it is better over here.
Textual setup of a binding = NO can not be done for all the modern good ones, it was killed just like we killed V1 bindings to keep it fair.
Textual rules = yes
Textual setup of the UI = yes
I run HA for all those integrations not available in OH then just use the MQTT sensor export function to make them available in OH.
What do you use that is not available?
There is a bluetooth based integration for my Astral Pool Chlorinator, the energy usage stuff is pretty good once you plugin your solar meter, Big Ass Fans integration is working with the new firmware, Tuya Local allows direct connection to tuya devices, there is also a tight integration with Frigate. I also like the HA Phone App, as it can track my location and also works with Android Auto so easy access to open the garage door, etc.
After hearing a lot about HA, I took a look at it and think it’s pretty cool. In fact, I was able to integrate everything except for my robot vacuum (Ecovacs Deebot Slim 10). I’m still struggling a bit with the automations.
It’s interesting that some things that are very complicated in OH are totally easy to integrate in HA, and vice versa. It would be great if both communities could learn from each other.
What I find unbeatable about OH, however, is the rules engine with blockly. It makes even complex tasks very simple and easy to implement for me.
It would be interesting to hear back from you after a while. Perhaps you could provide a deeper insights on how openhab could improve.
I think openhab is lagging a bit on the integrations / bindings, but leading in automation.
There’s a binding now, if you install the SmarthomeJ marketplace.
I remember that it was very time-consuming to set up the weather forecast correctly in OH. In HA, it was simply there out of the box immediately after installation.
On the other hand, I had to fight quite a bit in HA to integrate a simple RSS feed, which in turn was very easy to implement in OH with the binding.
I’m sure that there will be many more examples on both sides.
I believe that there is great potential for optimization at OH in the outdated presentation of the icons. The possibility to use the material and iconify icons is already a step in the right direction, but many of the icons do not seem to be implemented yet or do not work. The classic icons make OH really look ugly in direct comparison to HA and gives the whole thing a very heterogeneous look.
In HA, even the standard view with all entities looks very consistent and clear.
I second this. Good design creates trust to invest time in a modern platform. I think this is a good approach.
Bye
HFM
Testing Homeassistant motivated me to make my OpenHab a little prettier and after several days of working with the icons and dynamic states, it actually looks a lot nicer. But even if you have understood the principle, it is still super cumbersome to provide the icons.
I also find it a pity that the selection of badges seems so random and the customization options are also very limited as existing badges have to be overwritten and misused.
That looks similar to basicui
It is, I just customized the icons. The point is that it took me several days to do it. So either I’m stupid, or it’s not very self-explanatory 
How did you do it and what parts of doing it were challenging? Perhaps something can be done about it. Was it setting expressions? Searching for them?
I hope you didn’t download and put them into the icons folder. OH supports using icons from f7, material, and iconify by name. There’s no need to download them and create files for them.
The challenge was that the icons change dynamically (crossed out for off, different battery levels etc…) and this apparently only works with oh:icons, if i understood it correctly.
So yes, my solution was to download the icons and put them in the icons folder 
Actually no, this can also be managed using expressions in MainUI and in sitemaps there were changes made to support something similar.
For example, here is an expression I use for a light level icon:
icon: '=(Number.parseFloat(items[props.item].state) < 250) ? "f7:light_min" : "f7:light_max"'
This uses f7 icons as the source. Note that most of the time I end up using the same icon and use an expression on the color instead. But in this case it uses the f7:light_min icon when the Item is < 250 and the light_max icon when it’s >= 250.
For sitemaps they provide several examples, here’s one that also uses f7 icons.
Text item=TemperatureTrend icon=["UP"=f7:arrowtriangle_up, "DOWN"=f7:arrowtriangle_down, f7:arrowtriangle_right]
There is a separate parameter in sitemap entries to control the color of the icon.
Text item=NumberItem labelcolor=[>0 AND <50="yellow", >=50="green", "gray"] valuecolor=[>0 AND <50="yellow", >=50="green", "gray"] iconcolor=[>0 AND <50="yellow", >=50="green", "gray"]
See the sitemap docs for more details.
The “download and put files in the icons folder” approach is really kind of a legacy way to do it and IMO only to be used when you cannot use icons from any of the supported sources.