so far im really happy with openhab, using it since 2.4.
I migrated to 3.0 a while ago, and now i want to start over and really use the new modelling functions.
One point i came accross:
it is really painful to configure several similar items multiple times. I would really like to use the UI and go away from the textual definition, as it is much easier to do for the first item.
However, after configuring like 10 different options, metadata and other stuff for an item i just want to copy it and change its name.
For example a batterystate-point. I dont want to edit 10 different metadata, channel linking, pattern and other settings for like 50 batteries.
The same goes for lights, sensors, switches, etc.
I know you can add a point in “expert mode” as textual definition through the UI.
Is it possible to see what the textual definition of a point is, which was added through the UI?
It would really save me some time.
A better solution would be a copy-paste function.
Also the ability to rename Items (not labels) after creation, as a correction here is quite painful after you just set up metadata for 10 minutes.
Update: I went through it and edited metadata of like 150 items one by one.
I hope I don’t need to make adjustments…
I guess I’m not needing it now but I think this is something that should be addressed at some point to be able to manage more than a few demo items consistently.
The fastest way to configure lots of Items and keep them configured in a similar way is to use the “Create Equipment from Thing” or “Create Points from Thing” options. That will let you create all the Items linked to one Thing in one go and it preconfigurs a lot of the Item definition so it’s pretty easy to keep similar devices with similar configuration. It will also situate all those Items into the model, creating the Location and Equipments Groups where they don’t exist saving some work.
If you are using custom default list widgets or default standalone widgets, it helps to define those as a custom UI widget (under developer tools) and then all you have to do is select it and configure it on the Item. That way if you decide to change how it looks later (e.g. change the icon) you only have to change it in the one place and it will apply everywhere.
No because it’s not just one entity. A single line of a textual Item definition could result in:
1 entry in the Item registry
N entries in the Links registry
N entries in the metadata registry
The APIs do not exist at this time to fetch everything in one go. That’s why the Item is the only entity in MainUI to lack a “Code” tab. It’s not technically feasible to have one at this time.
The name of the Item is its UUID. You can never change a UUID once its assigned. You can only delete the old and create a new Item with a different UUID. It appears to be possible to rename Items in text files because what happens is all the Items in a .items file are deleted when the file is unloaded and then created anew when the file is loaded.
And if you do “rename” an Item in that way in text files, it will orphan the metadata, links, and persistence storage and it does not update the UI or rules that reference it. Especially in rules, it’s not even feasible to even find all references to an Item because there are lots of indirect ways to reference an Item.
Again, it is this way because it’s not technically feasible to support a rename.
Perhaps someday these things will become easier (things are already getting better) but for now it’s not as easy as it could be but there are some major additions to the REST API required to make it possible.
Of course this is from a users perspective, and the drawbacks in comparison to textual definition, all though in General I really like it and will use it nonetheless.
Here are some things that I have to do which the auto creation does not help with:
-some sensors have different things for different values (brightness, temp, etc.)
-things are not necessarily my equipment: I have to create groups manually and assign the right points
-naming is usually not what I want so I have to adjust every single name (better not make a typo)
-metadata has to be set (usually state description, default list item widget)
-many points are just point.none which is wrong. So I have to set that
-some channels need a different profile (hysteresis with values for low battery from battery percent)
-i have some points without things filled with rules (scene, auto value, presence and others).
this is error prone and not so nice to do.
I know the reasoning is it’s hard to implement. I know that has to get into account. But the usability would be insanely good with a few adjustments (this is from a user perspective).
My suggestions would be:
Renaming items: it’s okay to get a warning that it can mess some things up or might need a restart of openhab if the code is not able to delete orphaned stuff. This would help so much after spotting an error.
Modelling:
-copy/paste, or export/import, an element or subtree, or a generated definition what would lead to the same element in the tree
-drag and drop
I know this is an open source project so I’m thankful for what openhab is. This is just a few points that really would rule out openhab if my setup was a little bigger.
I created items and modelled them for like 3 days and I just did the lightning and some sensors with stuff for scenes, automatic lightning and other intelligence still to come.
That’s what “Create Points from Thing” is for. It doesn’t create the Equipment and Location tags but lets you choose an already existing one. You’s use this to add Items from the second Thing to the already existing Equipment.
I’m glad to see you are doing this. Too many think there is a one-to-one relationship between a Thing and an Equipment but in truth the Points for an Equipment could come from more than one Thing.
Again, this is what “create points from Thing” is for.
Copy and paste helps here.
I’m not arguing against the flaws, just pointing out some techniques to make things easier.
Unfortunately, this would be a fundamental change to how Items are stored, managed, and exposed in OH. It would touch pretty much every one of the repos that make up openHAB. Renaming Items is simply not going to be supported.
However, the JSONDB where everything is stored is just plain text. So you can stop opemnHAB and manually edit those files. Persistence will still become orphaned and if you mess up you could corrupt your whole DB, but this is about the only option that will be possible without taking openHAB completely apart and rebuilding it from scratch.
Anyway, you are free to file issues. I’m not here to say everything is gum drops and sunshine. I’m just explaining why things are the way they are now and why they are unlikely to change in the near future.
Okay, so basically I know all the ways already.
It doesn’t help with setting metadata and the things listed by me sadly.
Kinda if in a Word-Document:
-you are able to select between Standard and Header preset for every word you add. Which words go into which sentence is predefined and needs to be adjusted one by one later.
-you would not be able to edit multiple words and have to manually adjust size, if it’s fat and others. You have to adjust it letter by letter.
-you can’t correct your words. You have to delete them and readd them, afterwards adjust each letter one by one again.
Again I know it’s open source and effort has to be weighted against use.
I guess most like me just go through the pain as it’s only done once. But it’s not user friendly and a step back in that regard, even if I really like the model itself.
In a commercial application this would be a no go. Think about Microsoft telling us word can’t handle it right because they already designed it otherwise and it’s hard now to implement.
Again I’m happy with openhab and really impressed what open source can do. I do not demand that, I just suggest it
yes - commercial software does indeed have some kind of “mass update” functionalities, especially PIM software, which handles millions of product data. and you don’t want to update each product manually then!
but yeah, this is software, which is ripe since years.
It would be really nice to have an easy to access wishlist for openhab, not needing to have people file a ticket in git, where you just can up/downvote directly from this community. This would give a nice idea of what users would really like.
If they get implemented would be a total different story.
The model problem here is one that you only face once. Nobody bothers to file a ticket for that.
Anyway, thanks for your help and efforts in the community. You have solved quite a few problems I had over the time, either directly or indirectly in other topics I found.
You can create a post and have a poll in the post. It’s not hard to do and you don’t have to be a forum moderator to do so. But ultimately the problem is not too many of the developers spend a lot of time here on the forum. If you can’t implement it yourself, you need to get it in front of a developer willing to volunteer their time to implement it. To do that you must file an issue.
Over the years there have been dozens of such wish list posting and thousand+ reply mega threads discussing the future direction of openHAB. I can’t think of a single one that actually led anywhere productive though. They’ve all quickly become heated arguments and both users and develoeprs en up rage quitting the whole project. Based on this I’m really not in favor of these, they cause far more damage than good.
The not so secret behind all volunteer open source development is that for the most part the developers don’t care what the users want (that’s a bit of hyperbole to make a point as some do care). They solve their own problems and work on what they want to work on for their own reasons (it’s their time they are donating so who can blame them) independent of what crowds of their users might want/demand. They are not in it to compete with other solutions. They are not trying to gain marketshare. There is no grand future goal being worked toward.
