all depends from the direction we community want give to openhab
if we want enhancement for our self, or want create a product that can have an appeal on the market
if we want it for our need, then the human genre is selfish, so at the end no evolution of the product or long time to evolve (a comparison with others home automation is on the view of all us)
if we change the mindset and less selfish (i want this, my needs are this, i would like this, etc)
and thinking to create a product that all the community can have a benefit we evolve more quickly.
this meaning have a product owner that take all the suggestion of the community and makes a summary with some decision
like only one UI, not more
like one or 2 language for the rules
chose a little set of feature to implemented
have a short release cycle in agile mode.
update the documentation with standard
i use openhab from more of ten year, and never use others, but i view that there are products arrived later to market that are ahead of OH in a few years, in terms of usability, features, binding, and integrations
that are used not only by experts, but also by ordinary users
some have become commercial
companies have come in to give support and integrations, the community has grown quickly, and there are more people willing to develop, this is a virtuous loop.
concentrate the developments to evolve the product instead of disperse forces on so many fronts
this is meaning lost the infinite flexibility that openhab is now, to have a modern and update home automation system.
the fact that third-party integrations are clearly inferior to competitors makes sense of my argument
PS
for products on the market
Home Assistant
home kit
google home
alexa smart home
bticino
knx control panel
samsung smarthings
etc
In addition to the PRs that @Mherwege mentions, there is the set of timestamp profiles which you can use to link an arbitrary channel to a DateTime Item which sets that Item to now for updates, commands, or changes.(as desired).
These are what you would need to use to show the timestamps on the UI even with @Mherwege 's additions.
Other ways to handle this includev:
Expire to set the item to NULL or UNDEF if it doesn’t update for a time.
The last one is what I use to set a status item to OFF for an equipment when a sensor doesn’t update for too long of a time.
That’s not how OH development works so . I guess you have your answer. I don’t see what would be a radical change to the OH development process happening short of someone forking the repo and starting something new. It’s definitely a *The Cathedral and the Bazaar " situation. The Cathedral and the Bazaar - Wikipedia. OH is firmly in the Bazaar category.
I would like to be able to cluster notifications. Example: I get a notification when my window was open for 15 minutes as a reminder to close it. Nice and helpful. But if the window gets opened when I am not at home, this is way more important and I don’t want to get a simple notification but an alert to react immediately. I am not aware about such a possibility.
In addition to what @hmerk said, you can set tags on notifications to distinguish between roles of alerts. Then all you need is two different rules, one when the window is opened and you are home that waits 15 minutes to send a notification and another one that runs when you are not home and sends the alert immediately. You can use different tags for the two to distinguish between a reminder and an alert.
The Threshold Alert rule template (link above) can be used for this. Open a new thread and I’ll be happy to help you through it.
Since it’s apparently impossible to change Tado schedules based on the API, I still use the Tado app to change heating schedules. Rather inconvenient, but the tado binding can’t help me…
I just saw @tose’s timeline picker, and that looks valuable! Maybe something like this (or this very solution) can be built into OH5 (without the need for through-hoop-jumping by the end user)? All kudos to @tose, of course! In no way do I want to take anything away from what he’s done and made.
I’ll add to this concept by saying that a feature I would like to see is class based and iterative approaches to things, items and rules (maybe more too).
For example I have light controllers (things) with multiple inputs / outputs. Then I have multiple light controllers. Then each one has associated items and rules.
So far I have been using python scripts to help with this, but it’s pretty tedious for making changes and updates. Something more native and inbuilt would be great.
@MartOs That’s one of the reasons I use file based config. Almost everything you ask for works there (to some degree) when using a proper IDE.
I regularly do bulk renames: last week I changed a common prefix of ~50 items for the whole openHAB project (sitemaps, rules, items) in 5 seconds.
If you already write python scripts to create and maintain items maybe take a look at HABApp? You can do that to and directly attach the rule logic to the items. That way you have a single source of truth.
Exactly. Or make it an option.
The problem is, as soon as things are getting flexible, it means there are stuff to figure out. (otherweise there are no reason to make it flexible).
What I suggest are two options:
The flexible one. This is where the experienced people will work most often.
A less flexible, or finished design/templates.
Thats not quite true, or I simply havnt figured out how to.
You cant have an easy setup, unless you find whatever widget you need. This is where things are getting tricky, as we cant reley on every possible widget beeing available.
But the first step like setting up a page, thats can cause some problems as well. I have personally struggled with the resolution of a page. I know the resolution of the display I use, but it simply doesnt align with the setup of the page.
Next I struggle using widgets, as they dont seem to be scalable to fit the display resolution.
At this stage, I have not even started to configuring the widget.
It may be due to I have not understood semantic model, as I simply dont get it.
I know I can set different atributes for a thing/item. But I have simply failed to understand how the model work, and how to get it into a “better looking” dashboard.
Why? If its an option of choosing “easy setup” (an out-of-the-box setup), or go the “hard way” to build eveything yourself. I dont see how it would eliminate anything.
100 widgets all looking different.
Lets assume a user wants to use 10 of the widgets. To be able to get them to fit and look equal in a design, the user have to fiddle with them, right? Thats why I suggst a template/design option way.
Choose a template design/dashboard.
Choose the widgets to use.
Place the widgets, and configure them.
Dashboard finished.
What may be missing is the resolution of the display the dashboard is meant to be running on and some font options.
I know it may involve alot of work for those hos design the template/dashboard. But I´m pretty sure, many users would prefere to start this way. And when they see the results, they might start digging deeper into openHAB to do even more by them self. And maybe they even share their own stuff in time.
So please open a new topic, post a draft of a dashboard you would like to have and we can see, what can be done.
But this will end up in the next endless discussion, as there will be demands for various dashboard styles/configs. Who will decide what dashboard to implement ???
In the meantime, check out the semanticHomeMenu project (widgets on the marketplace), which was created to get a unique look and feel for widgets and easy setup, as most config is gathered from the semantic model.
I know it may end up in discussions. OpenHAB (someone) just need to draw the line.
If it´s too open for suggestions or too much discussions, things are not beeing done.
My guess is two maybe three different designs could do. As they are mainly meant to get the users of from start in a fast, easy, useable and nice looking way. It all depends on how those two designs looks.
I´m no designer But I could look at different designs, just for suggestions.
In that case… Two designs.
If there is a need of more, the option is open for others to create more designs. No need to endless debates or discussions.
In addition to HABApp that @Spaceman_Spiff recommends, JS Scripting to a lesser degree and jRuby to a greater degree can do this as well.
This is where I’m still confused because we have that now. All the persistence engines have a default streategy, nothing to customize. We have UI widgets yoiu can use as is. We have rule tempaltes you can use as is.
There is certainly more than could be done on this front but it’s not like large portions of OH don’t already support this.
That’s never going to change. There is alwyas going to be something you want to do that no one else does, or at least no one else has published. But it seems like your solution is to say “too bad” rather than “here’s a way you can build what you need yourself since no one else has done it yet”. That’s what I don’t get.
Are you talking about MainUI or HABPanel. MainUI is responsive. It reflows the widgets hbsed on the width of the screen but HABPanel does not.
And to again bring back your “don’t require end users to build it” idea, in MainUI you get an automatically built UI almost for free when you use the semantic mode. Isn’t that the sort of thing you are talking about?
We can open a new thread for more details but if you are building a page and you have a row the options for each widget in that row will have a “Column options” menue where you set what percentage of the row this particular widget takes up based on the width of the screen.
Note clicking on Analyze All will give you a chart of all the properties shown.
I’ve only done some minor customization to these. All of the custum widgets shows I’ve published to the marketplace if you like my icon and color choices.
As an alternative (though I’ve not worked with it yet) is @hmerk et al’s widgets which also build a UI based on the semantic model.
Because I’m saying that you already have that option (i.e. to not custmoize it), and it’s getting better. The only way to eliminate the temtation to customize it is to eliminate the option to customize it.
You can’t have your cake and eat it too. If you can’t have each and every widget look exactly how you want it to and at the same time not modify/configure the widgets to get there. You can take them as they are published or you customize them.
OK, then we are done. We have the options tab and we have the semanticHomeMenu suite.
We can draw the line there. We could even look to see if the semanticHomeMenu could be move to be an official repo if all parties are amenable and it helps somehow.
That’s where I’m comming from. We already hav eoptions for minimally configured UI dashboards and they getting better/easier with every release. But as always happens is 'but I don’t like those, I want a minimally configured dashboard that looks how I want it to, not those but I don’t want to configure anything."
@florian-h05 and myself are already brainstorming to make it installable from the add pages menu, without the need to get all single widgets from the marketplace.
. I guess you have your answer. I don’t see what would be a radical change to the OH development process happening short of someone forking the repo and starting something new. It’s definitely a *The Cathedral and the Bazaar " situation. 
But I could look at different designs, just for suggestions.
