Another Home-Assistant compare

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.

1 Like

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.


1 Like

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 :wink:

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 :frowning:

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.


thanks for the tip, but I don’t know if thats any easier for me XD

1 Like

It seems that we should have items[xxx].numericState just so we don’t have to do parseFloat in such scriptlets.

1 Like

Is there a chance to get multi-value-icons working (like Level 0 to 100)?

@JustinG posted a tutorial (IIRC) but I can’t seem to find on how to create a dynamic icon that works like that. I don’t think Custom SVG Icon Sets is the one I’m remembering.

In the mean time, most of the icon sets for things representing levels (e.g. batteries) have three or four levels which you can define to correspond with any arbitrary values through expressions.

I don’t remember why I was told it doesn’t support that. I’ve seen your PR and will comment more there later this morning.

That probably is the one you are thinking about. The responses in the thread briefly mention that this would be a good way to make icons that are fully responsive to value even though the tutorial itself doesn’t work through that case.

Recently, @DiegoDF just did a nice job using that framework to make an svg that does just that:

Combining his work with the svg library tutorial would allow you to build an icon set responsive to arbitrary values.

Thinking more broadly, now that the png icons are de-ehpmasized (depreciated?) in the main OH icon server in favor of the svg versions it might be worth thinking about actually making the official icons arbitrary in value.


Is there a Roadmap or something comparable to this for openhab?

Yes and No. Recently we had a nice blog link below that covered it in a similar way, and the addon suggestions and improving the new user experience has been looked at more since the release and blog…

You can see the chat on it here, as we have a forum category for where areas being worked on can be discussed…

Core development is usually talked about in github, so you can see the open tickets and read the subject lines if you wish.

1 Like

No, there is none.