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…
Yes, a good half of everything mentioned so far already has an issue open. some have been opened for some time.
First a big “thank you” to all the maintainers and contributors of openHAB 
Appreciated would be
- support for Aeotec Z-Stick 7 and an as easy and comprehensive Z-Wave console as Z-Wave.js offers
- a more reliable and stable HomeKit support
- a browser based setup like Home Assistant (move away from openHABian)
2 Likes
The UI stores everything in readable and editable JSON files, you just have to stop openHAB before editing.
And this is not going to change.
That is not what I want. The storage space of the JSON files when edited by the UI is not as clearly marked as in the “ITEMS”, “THINGS”, “RULES”, etc. folders. These JSON files are a bit of an exaggeration to describe a grain of sand in a desert. This was better solved in openHAB’s original way of working.
1 Like
Unfortunately there is no way to define tags for .rules files based rules. To appear on the Schedule page the “Schedule” tag needs to be added to the rule.
So this is a more generic “add tags support for rules in .rules files.” While we’re at it, name, uid, and description would be nice too.
Some of this is already possible.
“control over the latest data”: managed through the persistence strategy and/or rules and the .persist function on the Item if you only want to store some values.
“home much space”: rrd4j is 738k per Item. mapdb appears to be about 365k. per Item. For any other database you’ll need to look at their docs for how they store data.
“more info about used resources”: there’s the system info binding and in MainUI a lot of info is available under in MainUI under Help and About.
That’s not going to be helped with strong typing. And here’s a simple heuristic you can use:
- Always use
val - If you get an error along the lines of “attempted to change a constant val” change it to
var. - Never specify the type of a
valand only specify the type of avarif you are initializing it tonull(e.g.var Timer myTimer = null, compared tovar mytimestamp = now)
But in this case, the typing system comes from the upstream Xtend language upon which Rules DSL is built. If you want stronger typing you’ll likely have to move to a different language with stronger typing (Groovy perhaps?) or add this wish to the upstream Xtend project.
If you have QuantityTypes, doing math is fine if you are doing it with QuantityTypes. For example, to compare the state of an Item to 20 °C in Rules DSL:
if((MyTempItem.state as QuantityType<?>) > 20 | °C)
or if you reverse it you don’t need the cast
if(20|°C < MyTempItem.state)
All the math operators work. You should only very rarely be calling intValue() on any numerical value in Rules DSL. It causes problems.
2 Likes
No, what you are refering to was from the openHAB 1.x times.
JSON config had been introduced with openHAB 2.x and PaperUI.
You don‘t need to use MainUI for configuration of Items, Things and Rules and still can use textual configured Sitemaps in BasicUI.
But for MainUI, you will need the UI for config.
I know this and I don’t like the last point. And because we are in a “wish” thread, I wish a change of this behavior.
2 Likes
@iLion and @hmerk, I think it’s helpful to point out places where a wish is already partially or in some cases fully met already, or where OH can’t meet the wish at all because it’s out of our control. But we need to be careful not to devolve into defending the status quo.
One other note to everyone, just because it’s listed here as a wish doesn’t mean anything will come of it. Hopefully some developers will look at them to see what’s a pain point for users if they are looking for something to work on. But no one is under any obligation to implement any of these wishes.
3 Likes
Thing is, they don’t have a group at all. They’re hanging around at root level… as I didn’t pick a parent for them… 
For the rest of not fruitful discussions, I’ll stay silent for peace sake.
Create the group and add them from the Group’s page. Should be able to add all the items in one go. The pop-up supports search so if they are named similarly you can get them all at once.
I created a Group and added all those Airthings Items to it in about 15 seconds.
Just for clarity:
- Create the Group. In this case you probably want to create a new Equipment so you can even do this from the Model page.
- Navigate to the newly created Group’s page.
- You should see “Direct Group Members”. Click “Change”, put in a search that will matching all your Groupless Items and click the checkbox to select them and add them to the Group.
This should not be too painful and if this is missing from the docs it needs to be added. It’s a huge time saver if you are going to each individual Item and adding them to the Group one-by-one.
2 Likes