What dou you mean by that ? Custom metadata namespace, e.g. uiSemantics already exist and can be used on all items.
I am afraid, your understanding is not correct, as not all existing hardware will support matter, so the bindings will still be needed. But don‘t let us start a matter discussion here, there has enough been said regarding this in other topics and issues.
1 Like
openHABian offers you a menu for all relevant administration tasks, providing enormous value:
you don’t have to know the commands, it validates the input for you, you cannot mistype, it automates and shrinks a series of commands you would need to enter correctly to single clicks menu selections.
That’s a big improvement over and not to be confused with what is commonly understood by the term “command line”.
Any user that would be able to do maintenance task X with a web version can do exactly the same in the text version today. A web UI replacement would not add any benefit whatsoever.
That’s just a pseudo argument, often misused in comparisons or “reviews” done by people that don’t understand how the systems they write about work, probably never even used 'em.
PS and off-topic. Thread is a wishlist on openHAB.
3 Likes
I mean that anything beyond this list: openhab-webui/bundles/org.openhab.ui/web/src/assets/definitions/metadata/namespaces.js at 3.4.0 · openhab/openhab-webui · GitHub does not get any form. End user is forced to write configurations by hand using yaml, even if openhab-webui/bundles/org.openhab.ui/web/src/components/item/metadata at 3.4.0 · openhab/openhab-webui · GitHub components which are used could be defined using config descriptors and core functionality of framework. Even if complexity of ie. homekit or alexa exceeds designed capability of config descriptors other binding-rule-misc-specific cases might be perfectly fine with regular metadata descriptors.
I can think of for example persistence service using metadata for specifying base untis for stored quantities or generic purpose rules which could use metadata for their work.
1 Like
As you are a dev yourself and don‘t be satisfied with what’s existing, why not contribute to that then 
Come on! That’s a lame excuse in my eyes.
We’ve come a long way from downloading bindings and dropping them in some (seemingly everchanging) directories to first PaperUI, where I could do that with a click and some typing and then to OH3-GUI, where it is even more comfortable.
You can’t just weep away some legit requirements especially for entry-level users!
Experienced users and those capable of differentiating between SSH, openhab-cli, openhab console and openhabian-config will have no trouble whatsoever using openHAB. #
But the learning curve wouldn’t be so steep if the menu and some of the heavyily used functionality only possible with a bash would be reachable within openHAB-GUI: getting SSH activated, SSHing to my raspberry, knowing the difference between the console and openhabian-config and knowing what to type in in the console do just adjusting log-levels… that’s a pretty steep learning curve for somenone just wanting to walk some first steps into openHAB.
doesn’t mean, openHABian is superflous - it’s not.
13 Likes
I wonder what is the right way to handle a device disconnected from the network :
- Having the thing “ONLINE” (meaning the handler is functional) and a dedicated channel “online” like network binding does it
- Having the thing “OFFLINE” without dedicated channel (like done in Netatmo binding).
I’d like your insights on this and OH4 could be a good time to enforce a single way of operating on this.
Other thing I thought would be to standardize some very common configuration items like :
- ip Address,
- hostname,
- macAddress
We could this way progress in associating a Network Device to a thing hosting one of these components.
My thought on this is still fuzzy, but I wanted to share.
1 Like
Add the ability to associate tags with things the way it is done for Items.
Interesting wish, could you please elaborate your usecase, don‘t get it.
This would allow retrieving a list of things by tags in helper libraries, the way it is done for items.
Doing so, you could for example easily define of list of things would want to monitor ONLINE/OFFLINE status.
I understand your point, but I think it needs way more than just adding tags to things. Even the UI rule editor would need to alow filtering things by tags, not just bindings with wildcards for the things.
Defining it at core level would already be a good starting point if the use case seems valid, then make it available through rest api, then …
Indeed, there needs to be a starting point, which would be the core.
Excuse for what ? Me not sitting down right away and start developing it for you?
That’s nothing I think I need to excuse for.
It’s straight wrong, most relevant maintenance of ‘the system’ can be done from the GUI already.
Sure there’s some minor stuff like config backup that could be added in the OH GUI, but that’s not openHABian hence not my business and not what the OP asked for.
Most of what openHABian offers is functionality on top of what the smarthome systems like OH and HA provide so you must not criticize that for being text based, particularly as it’s functionality mostly pertaining to OS administration that HA and others don’t even offer.
And the request is from people that don’t understand the (huge) implications of what they are demanding. They are asking for a feature that cannot be built (well, not without fundamentally changing most of the openHAB code base) because openHAB is an ecosystem and will never become an all-UI appliance.
What an inadequate response of yours. If I hadn’t been moderator myself I would have flagged it as such.
My reply was to the point. Making existing openHABian functionality available through UI clicking will add ZERO new benefit and will not enable any more users to operate OH or ease their life in any other way. For the additional functionality openHABian provides you will need access on text level anyway.
So why should I or anyone waste lots of time just to move the working menus over to a browser ?
4 Likes
Now you’ve done it!
OK, to make this thread a little more usable I’d like to make a suggestion.
-
@joriskofman, take it upon yourself to keep a running list of all the wishes posted in the original post, maybe with a count of how many times it’s mentioned or something.
-
We can turn this into a wiki and everyone can post to the OP themselves. Someone will still have to scan the replies for stuff because some people will simply refuse to edit a wiki post.
You should be able to go to the Group and add the Item from there all in one go.
The REST API part of this is already implemented. We are only missing the UI updates.
I’d call this a bug. Please file an issue on this one.
@binderth and @mstormi, this thread is going to really long with lots of stuff. I’d like to keep it on topic and especially avoid defending the status quo. It’s a brain storming exercise. When/if any of these ideas get submitted as issues, we can defend the current approach there. I’m already worried this thread is going to become a mess, arguing about some idea is only going to make it worse.
Rich’s wish list (there is some overlap with what’ already been mentioned):
-
Drag and drop in the Semantic Model UI to more easily move Points and Equipment around in the model.
-
I’ll second @splatch’s idea to get support in the UI for custom metadata (note, see UoM default units and consequences for a relevant discussion on units and persistence). Even if we can just get the namespaces of the metadata already applied to that Item it would be a boon.
-
I know it’s hard, but a “Code” tab for Items with a YAML representation of the Item’s JSON. Even if it doesn’t include the links and metadata it’d be useful.
-
Full text search; I want to search for an Item name (for example) and see which rules, widgets, links, etc. it’s used in by name, even inside the script actions and conditions. Maybe this should be part of the developer sidebar. Finding all the Items with a given metadata would be another use case.
-
All lists should be sorted alphabetically based on the most prominent element. Things and rules are already handled well. Items should be sorted based on the label. (This one’s a quibble).
-
Ability to post a “collection” of rule templates and ui widgets to the Marketplace. For example, I have three separate posts for each of my MQTT Event Bus rule templates. It would make more sense to have one post with the three rule templates. Another case is the Scene Control which includes both multiple rule templates but also a UI widget. It would be easier to manage if we could include them all in one comprehensive post to the Marketplace.
-
Ability to create and deploy a rule template locally. Right now to install and test a rule template one must post it to the Marketplace. This greatly slows down the edit/test loop when creating or enhancing a rule template.
-
UI support for rule templates similar to UI Widgets.
-
Ability to package library functions in a rule template.
-
Support for a functional language for rules (Clojure perhaps) strictly because I love to code in such languages.
-
GraalVM Python support because a lot of Jython users are in danger of losing support.
-
Honeywell Residio add-on.
-
Subaru Starlink add-on
-
Wyze camera support
-
ability to copy uids (e.g. Item name) from pinned objects in the developer sidebar.
If wishes were fishes we’d all swim in riches.
7 Likes
-
One of my biggest wishes from only using while openHAB do the work is information inside the “Schedule” section of the UI. I had only rules written in text files and many of them make use of astro binding events and cron time jobs. But no rule is listed in the UI. On the other side, all this rules are listed (not editable) in the “Rules” section. This is fine. But I think it should be possible to calculate the “next” schedule in the same way, as if a had created this rules over the UI directly.
-
Smaller, but useful thinks could be in persistence to have control over the latest data, which is stores. I am actual thinking about creating a fresh linux machine and searched for information, how much space I need on the “hard drive”. More information about used resources, how to get free space, would be nice.
-
And the last, for me big point, is the support for creating a individuell modern UI with Textfiles. It is such a big deal with openHAB to create only a fresh Maschine, install openHAB, copy all text files to the new target and start the system and everything runs. And no defect databases or something could be a problem. Perhaps it could be solved, that the UI is only a assistent and saved the result in files, which could be edited.
1 Like
Stronger data typing/definition of types available in Rules DSL…To this day, I have problems understanding when to use val, var, or itemTypes for my helper variables…Maybe with the UOM improvements, it’s better to stick with the item type route (but then, state conversions toString, intValue, etc. are still required)…
2 Likes
I’ve been eagerly following the non-action on this for some time…