The thread asks what I would like for OH 5.0. I (and many others) would like to have a simpler handling of things channels items.
And as I said that’s one of the points HA does better and openhab could too.
An opinion of “take what you get here or go away to the other system” will not make OH better.
Yeah I could name them in sequence from 1 to 9999 which wouldn’t make it any easier.
I know where OH comes from, but this thread is more for where OH can get to in the future. “It was always like that and doesn’t fit quite anymore” is not really an argument to keep it the way it is.
Reach = more people = more supporters = more developers. A project without people will dissappear.
OpenHAB has (and needs) a unique value proposition to separate it from other projects, especially HA.
The big UVPs that OH has:
Superior built in automation capabilities with a standard install - think reliability and consistency between updates. I wrote a wall of text going into the downsides of HAs automation approach, but I don’t think it’s necessary in this thread.
Abstraction of physical location in a model away from unique IDs for coding and automation purposes.
In terms of “marketing”, that means money. However organic reach is far more practical and arguably more effective. The fact is OH has almost zero social media interaction, and certainly nothing recent, meaning anything being reviewed is OH2 or OH3.
If you want to help out in that sense, make a youtube video reviewing openhab. Even a little click bait-ness in the title wouldn’t hurt: “OpenHAB: BETTER than Home Assistant ?!?? ”
I plan to do something like that myself, but I’m just not in a position to do video production at the moment.
HA has a completely different architecture. But in the OH architecture that mapping is key to the normalization which allows everything to work together in the same way. Some minor changes could potentially be made but eliminating it would be fundamentally changing the whole OH architecture and reduce the flexibility of OH overall.
Without that mapping, for example, you couldn’t change the data provided by the “thing” (to use OH termenology) into a more useful form based on what you want. For example, changing a humidity reading to an ON/OFF with hysteresis. You’d need a rule for that.
However, there is work being discussed and pursued to make the whole Thing → Items flow more of a wizard so the user is guided from Thing discovery through Item creation which should improve this somewhat.
It’s an all volunteer project (unlike HA which is backed by a company). No one is stopping anyone from volunteering to do some marketing. However, it’s been tried in the past and didn’t really go anywhere. But that doesn’t mean it can’t be tried again.
I think my main problem is that in order to keep some structure the items have to essentially be named like the place they will be put in the model.
It doesn’t quite fit to the new model hierarchy (because it doesn’t And the model was a second step). Then again I’m not sure what could be done to make it better.
Maybe make the link between channels and items stronger (like having sort of an implicit default item per channel without creating it) so you really don’t have to care about it in many cases. In my setup at least most items are just that, named channels in default settings, and a lot of brute force work for clicking and renaming.
For marketing: I think even small steps would help. Like being active on other portals like reddit, posting updates there also, etc. but I also understand this is essentially people engineering OH for free in their free time and that this is nothing that can be demanded thanks for your work.
Yes. But this is about new features, not “please change behavior to HA”. That’s, what I’m tired of.
No, this is not allowed (no leading digit in Item names). But you really got the point. There is absolutely no need to repeat tags in the Item name, the only thing is to ensure that every single item has a unique name.
That’s only your opinion and isn’t true at all. My point is, the Items aren’t obsolete and they have to be named. If you want a hirachy in the naming, do it, but don’t complain, you don’t need to.
And if it’s a Channel you don’t want and have no use for? OWM has nearly a hundred Channels.
Are you using “add equipment to model”? You should be able to create all the Items in one go. Name the Equipment and the Items will be named “_” with reasonable defaults for label, category, semantic tags, etc. No click and brute forcing required, unless I’m missing something.
We can continue on another thread if we need to go into depth.
Please stick to the topic “What features do you want”.
The thread helped me explore some features I missed - that were already there, and some features gained traction with others, so perhaps somone grabs them. Discussing the overall architecture and structure of openHAB is only spamming the topic - besides, there are already a bunch of “comparison” threads available for that.
okay, another idea thats not as invasive. Basically if using the model, simplify the usage of items.
-in GUI, items are already shown and pickable through the model so the item name really doesn’t matter at all (to the user). Find a way to also make that available in (JS) Scripting, so you can (Pseudocode) myitem = getItem(Home.Floor1.Bedroom.Ceiling_Lamp.Brightness). “Ceiling Lamp” (Name of Equipment) and “Brightness” should not be their item names, as that would need to be unique. Maybe the Label, or some sort of “short name” that doesn’t need to be unique.
-if thats possible, in a system using the model the unique item name doesn’t matter anymore to the user, as you pick items by their location in the model. You still can, though, if you need some additional items, so nothing changes for existing setups
-make a filter available in the item list to filter out items in the model, so you can filter out all the items that are in the model (leaving you with mostly items you added manually).
That way you keep all existing functionality, while shifting from the plain item list to the model. A new user basically doesn’t even need the item list for most usecases anymore. Even the “unique” item name wouldn’t really matter anymore and you basically -could- just live with randomly generated unique IDs while adressing stuff though the model and the (now not necessarily unique) name anymore.
EDIT: sorry, I will stop posting here now. I will also add the suggestion to add a feature voting system of some sort instead of a discussion for finding new features.
First, the semantic model is not required so this would only work for those using the model.
Secondly, my rule of thumb is only about 60% of Items belong in the semantic model. You don’t want to expose Items that doesn’t matter to end users of the home automation (e.g. functional groupings).
But given the semantic actions this should be achievable.
The code one would use now would look something like:
It shouldn’t be too hard to wrap that to make it easier to use. Of course some error checking and generation of meaningful error messages would need to be added but that’s the basic way to implement that.
But you still have to have unique names for the Items to “Brightness” is unlikely to be the name of the end Point Item. And if you do have that unique name then you can just do items.Brightness and save all that navigating and searching of the members of the Groups.
To use the labels change the i.name == to i.label == and you can search on the labels. You can make the search “fuzzy” by using includes instead of ==.
You can use tags, Item metadata, or any other property of the Item in this.
You could also go backwards and search the decendents and use the semantics to find the specific Item that has that place in the hierarchy but I think that approach is less intuitive. It also requires the labels for the Items to be unique at least at the lowest level. You could have two members of Celining_Lamp which has a label that includes “Brightness”.
It depends on the use cases of each one of course, but while I follow your rule of thumb, I do it from the other end of the spectrum.
Let’s say I add a new device (this happened recently when I bought Bosch kitchen appliances).
Having a single place to see all of the thing endpoints at the same time is useful to better understand the Thing itself. So I add all items and the items to my model all in one go. Then I work backwards and delete the ones I find no value in as time goes on.
This is one aspect I would like to see improved in the current ui, to have a tab or panel, where we can see all of the items linked to a Things channel, for “management” purposes.
Or put in another way, imagine having a thing with 10 channels. In a situation like a generic mqtt thing you’d have to click to expand the channels ten times, add item to channel, and if needed, change the metadata and icon type etc, one by one.
This is fine for occasionally handling one of two items, but for setting up a whole bunch, it’s not yet optimal in my view. With the recent changes to mqtt auto discovery I had to adjust many things or change items, and this was painful.
Oh!
And as an enhancement to this, it would be even cooler if we could search for items, abstracting the Thing all together , like “find all light sensors” to make bulk changes: metadata, icons, name updates and so on.
We already have a “select” option, and delete. Missing the edit and improved searching function
Or click “unlink all items” or “unlink all and remove items” to eliminate the links to all the existing Items and then “add points to model” to create the Items anew all in one go. It’s not going to get you all the way there but it’s better than doing it one Item at a time.
I have an issue open to let us select an existing Item rather than needing to create a new Item in add equipment to model and add points to model. There hasn’t been any movement on it though.
if you search for “light sensor” in the developer sidebar it will return those Items with the sensor point tag and the light property tag. There have been some proposals for bulk edit but not much has been done on that yet either. You still have to click through to each Item individually to edit them.
Other Feature request- native support for sankey Charts, which are really helpful for energy consumption for example. ECharts already supports this but openhab does not.
I always wanted to dynamically control the transition time of my zigbee2mqtt lamps with OpenHab. At the moment I can only set a default transition time in zigbee2mqtt or use scenes with different transition times.
My idea would be to add an optional transition time value to the Color items that then would be sent to zigbee2mqtt together with the color value and the brightness by the MQTT binding. (Zigbee2mqtt already supports this)
Does zigbee2mqtt support this? If so, right now you can use the MQTT Action to publish the message(s) needed to make this work. It might be possible to implment something like this in the binding.
If zigbee2mqtt doesn’t, you’ll have to have them add this capability on their end first.
Yes zigbee2mqtt already supports this. They are simply using the HomeAssistant MQTT light interface that has support for light transitions: MQTT Light - Home Assistant
And also yes, with the MQTT action this would already be possible. But it would be much cleaner if the Color Item would support this directly. As an example this could then be implemented as a parameter in the colorpicker UI element.
In Rules UI: Currently, in When and But only if clauses, you can make comparisons with fixed values only. I would like to have the capability to also make comparisons with item states.
thanks for your work.
But you really got the point. There is absolutely no need to repeat tags in the Item name, the only thing is to ensure that every single item has a unique name.
