I’ve submitted a PR that should enable expanding the ontology at runtime, according to our own needs. If that PR is accepted, further work can be done to propagate full support to MainUI as well.
I will split this, but primarily because this thread here isn’t meant to discuss use cases and potential solutions in detail.
But it’s useful to point at any such solution that exist already in OH, today.
Quite some wishes on this list in fact need not be put on here as solutions for what’s the real intent behind such a wish are there but the requestor isn’t aware of.
@liaskt are you aware of profiles ? The timestamp-change one for example ?
Thanks for splitting, let’s continue the discussion at Timestamps and persistence
The timestamp-change (and timestamp-update) profile is another solution for the 1st “Task: Access the item lastUpdated timestamp”, thanks for pointing this out. I will post in the separate thread why it does not work well for my setup, but in any case it is a useful solution for others.
- Energy management with corresponding attractive dashboards (without having to do a master’s degree in software development and hours of studying the documentation and community contributions). With a focus on the operation of a photovoltaic system.
- Data aggregation with persistence of results.
- Full implementation of persistence services (use case with the REST API). Examples:
- Allow the REST API to write data to persistence.
- RRD4jPersistenceService, getItemInfo returns an empty list.
- Better and more attractive charts
- Better and more attractive widgets as part of OpenHAB.
- myUplink Binding
- Backup and Restore from the UI
- Create new item, thing, channel with other item as a template
- Certificate Management from the UI (support to create, sign and install self signed certificates)
- Intuitive and complete schedule concept with configuration of special days (holidays, public holidays, etc.). With a graphical schedule editor worthy of the name.
- Alarm management (alarm lists, alarm classes, alarm history, …)
- Possibility to integrate own HTML/JavaScript/CSS pages. With a templating system such as Velocity (or whatever). The icing on the cake, with a JavaScript library to communicate with OpenHAB (with WebSocket, subscribing changes, etc.).
I consider my wish list as a kind of brain storming. They are ideas, from a developer, but who is an openHAB user here. It doesn’t have to be immediately shot down with “it will never happen, you don’t understand openHAB, it’s too difficult, it won’t work”, or whatever.
And if “Today openHAB isn’t providing applications”, then maybe it should! Without significant improvements, you can stay on version 3.
Version 4 should just get users to switch from HA to openHAB, not the other way around 
I wish you much success and am excited to see what version 4 will bring.
4 Likes
I believe @mstormi has a turn key system built on OH he sells for this. There is also an issue and PR with a lot of activity related to this in core.
This is already possible. If using a Group to aggregate you’ll need a custom .persist file that lists the Group name separately. If aggregated in a rule, put the result in an Item.
This is already supported.
This needs more context. The REST API and persistence actions all work for me.
Grafana has about the best charts you can find. Beyond that, someone will have to find an open source web page library other than the Apache one we use now. Or file some actionable issues on that upstream project.
Actionable and specific issues are welcome. “better looking” isn’t actionable and subjective.
There was an issue and PR opened for this. I’m not sure the status.
I believe there is an issue open on this too. Though I think it morphed into a more general improvements to bulk editing. I’m not sure if any PRs have resulted from this yet. But in the mean time copying the text from the Code tab and pasting that into the code tab for a new one. The Code tab for Items was just merged into main in the last week or so.
Needs more detail. Everything is an Item and the Semantic Model had tags for Alarm and these can be grouped, listed, queried (using HABot), etc.
Should already be possible, unless Velocity requires server side stuff. Anything that Jetty can support serving up, should be supportable. Just place your html files and such in $OH_CONF/html and it’ll be accessible from http://ip:8080/static/filename.html.
It’s all REST API calls. It would be worth checking out what the various UIs do and see if they centralize OH interactions. If so it might just be a quick lift from there to get a working library.
And there are several widgets to integrate Grafana into the openHAB UI available on the community marketplace, e.g. Grafana chart with time ranges (with time range picker) or my fork of it openhab-conf/UI/widgets/community.openhab.org/Grafana_Integration.yaml at main · florian-h05/openhab-conf · GitHub (fullscreen).
I also have a simple full-screen webview widget, see Fullscreen Webview Widget.
There is a GitHub discussion on the WebUI repo, I am super busy right now and will be at least for the next three weeks, however the “Duplicate Item” (and other stuff like Things, Rules) functionality is on my to-do list.
It hasn’t been merged yet, because some REST API improvements are required to make it fully operational, but the code view will come.
3 Likes
Yes, I know. I guess it’s one of the reasons why he thinks it’s a bad idea to have something like that in openHab.
EDIT: Oh dear. I think I used the wrong term. I didn’t mean aggregation. But what is it called? Rollup?
Now, let’s say I have a historicised meter reading. Can I (retroactively) calculate a 1/4 hour interval consumption from it? And from that again a daily consumption? Without gaps if data is missing (interpolation)? And suppose I want to do the same for a level from an oil tank? Without programming a rule? And without Grafana or whatever? Out of the box? That sounds great. Are there any instructions?
Ok. I’m sorry. Either I did something wrong or it wasn’t possible before. I will try this again. Thank you.
API Call for example with rrd4j
/persistence/items
Some persitence service (e.g. influxdb) implement this method. Many return an empty list.
Right. But Grafana is Grafana. Home Assistant has nicer charts than openHAB. Is that why I should switch? I hope not. I thought the point was to improve openHAB. I know that some of these are difficult proposals. They are also just ideas.
You are right here too. Unfortunately, I’m very bad at graphic design. But I can tell what I like and what I don’t like. What is beautiful is always in the eye of the beholder. And what looks beautiful and modern today will look outdated tomorrow.
But somehow there is very little that you can simply use. Not even for the simplest things, which probably everyone (or almost) has.
What I have read so far (from some people) was quite disappointing. According to the motto “a backup does not belong to openHAB”. But there is already a backup via the command line. I just created a script called with Crontab. But to configure something like that via the UI would be nice. Not everyone knows how to do that.
Yes, I realise that. I have to do with BMS professionally. There, it is common to have an alarm management system. For example, I measure a room temperature. This data point (item) has a configurable “alarm extension”. For example, if the value is less than 19°C, an alarm is generated. This alarm can then be forwarded via “Recipients”. I know, until then it is possible in openHAB. Although (I assume) everything with Rules, right?
Then I would like to see the alarms in an alarm list. Is an alarm still pending? Or gone? Has it been acknowledged (i.e. taken note of)?
Then I want to see in an alarm history which alarms (let’s say yesterday) have come and gone (with timestamp) and when and by whom they were acknowledged.
Ok… before I write my fingers to the bone, I’m waiting for the sentence “This doesn’t belong to openHAB” I honestly don’t know if that should be part of it or not. I just miss it.
Ok. That sounds good. I did not know that. I will try that out.
Thank you for your valuable feedback.
Super thing. I hadn’t seen that at all. We must have something like that. Very nice work! Thank you.
1 Like
Please elaborate a bit more.
There are loads of ready to use widgets on the marketplace.
From what I understood, it is quite difficult to determine the underlying installation method and therefore select the correct way to do the backup. I did not see a solution for that.
Before this can be achieved, we would need a complete user management, which does not exist by now.
And yes, this seems far above openHABs scope
Probably but without a rule. But by the time you cover all the different variations and edge cases in but sure it won’t be so complicated you might need a rule anyway.
But just because it requires a rule doesn’t mean you have to program it. That’s the short of thing rule templates and the marketplace are for.
I don’t think there is a template for these right now but they are great ideas to be added.
That’s a bug, please file an issue… It should work the same.
And I explained what you can do now to get better charts and what it will take to get better charts in OH. I’m not sure what the problem is with my response.
And if:
- charts are that big of a concern
- Grafana isn’t an option you want to consider
- You are not volunteering to make OH charts better by finding an alternative library or working to fix the upstream library MainUi uses
you might be happier with HA. Unlike the HA community, we have no animosity and the competition between the two doesn’t drive OH development. We want you to use the tool that you are hallway using and that meets your needs best, even if it isn’t OH.
I suppose this needs specifics too because I have a pretty nice UI that I like the looks of and I didn’t need to do anything but set up the semantic model. So what specific “simplest things” are you looking to do UI wise?
yes
Sounds like a job for a repeater card which can use some logic to show it but show stuff based on Item’s states among other things. There are several on the marketplace.
That one is a little harder but I don’t think impossible. it would probably take a bit more work than it should. There are some new stuff coming which might make it easier too but for now you’d need to model everything using Items with rules and such. It’s short of possible but it’s not going to be flexible.
You can open a new thread and we can brainstorm some options for how to achieve that.
That’s quite the opposite of what’s true and not fair. I’m actually pretty actively supporting the OH development in this area, backporting concepts and even some code.
You should read my earlier post on this and speak for yourself only, please.
2 Likes
OK. I apologize. It really wasn’t fair and I retract my statement. So of course it’s important that there are maintainers like you.
I’ve just noticed that a lot of the answers you’ve given are very negative. But I don’t know the reasons for that. It’s a bit frustrating sometimes when an idea is just immediately crushed without giving it any thought (or so it seems).
We can now extend the semantic model to our heart’s content (included in M2). I have just submitted a PR to make the custom semantic tags integrated into the MainUI Dynamically load the list of semantic tags by jimtng · Pull Request #1850 · openhab/openhab-webui · GitHub
4 Likes
Thank you!!!
I would like a persistence function for item.runtimeSince(ZonedDateTime) that gives the time a switch have been on.
Then i can get rid of some rules.
1 Like
This will have a lot of preconditions but you should be able to do this with the persistence actions that exist now. previousState(true) returns a HistoricItem that comes from the first record found in the database where the state of the Item was saved as a different state than the Item currently has. So if the Item is currently ON, MySwitch.previousState(false) could return the HistoricItem and the .getTimestamp method will tell you when the Item turned ON. And if the Item is currently OFF, MySwitch.previousState(false) could return the time when the Item changed to ON and MySwitch.previousState(true) the time when the Item changed to ON and you can see how long the Item was ON before it was turned OFF.
I use the word “could” because it depends on the strategy being used to persist the states of these Items. You’ll have to use an everyChange strategy only for those Items (which excludes the possibility to use rrd4j for this).
If all you care about is to know how long the Item has been ON if it’s currently ON, you can even use MapDB for this. I’m not sure what the default MapDB strategy is but suspect it’s everyChange so previousState(false) will give you the time when the Item changed to it’s current state.
Another approach is to take advantage of the fact that Switches are stored as 1/0 in some databases (e.g. rrd4j). In that case you can take advantage of the fact that rrd4j stores a record every minute so you can use a MySwitch.sumSince(now.minusHours(1)) and get the number of minutes the Switch was On over that time period.
FYI I am using InfluxDB with persistence strategies everyChange and everyMinute, I am using MySwitch.history.averageSince(now.minusHours(24)) * 24 to get the number of hours my warm-water pump was on in the last 24 hours. This works great, no matter how many points are persisted since the average is time-weighted.
EDIT (for clarification): average since is time-weighted in all persistence services, not only InfluxDB. Influx is just what I use, rrd4j and the others should work the same.
It’s time-weighted in all persistence DBs if I’m not mistaken.
It’s probably a longshot for the wishlist, especially for 4.0 (probably needs to go on a future version) but have been thinking more about ‘simple’ global timers for (and aligned to) items.
Anyway, here’s the basic idea
- Extend the Item class to include a method to set/manipulate a timer associated with the item
- The timer would be managed by something within the OpenHAB core, outside the rule
- There can be ONE and only one timer associated with each item
- This same timer could then be queried/manipulated from any rule/language
- These item timers could almost be simple enough to present in the UI, as an action in the rules section
- The existing timers would still remain available in the context of a scripts for more complex use-cases (triggering functions etc), so this should be a non-breaking change (I think!!).
As a quick example of what I am thinking as a starting point for the conversation(excuse the pigeon-code, I am no Java dev!!), see the following:
-
Item.timer
-
Item.timer.setTimer(time,itemCommand)
- Potentially 3 formats for time:
- now+x
- schedule+x (if timer already scheduled, add x to the current schedule time, if not scheduled, treat as now+x). I had considered a ‘-x’ option, but I can see too many situations where it could try set it in the past
- absolute datetime value
- Any existing scheduled timer would be cancelled and replaced with above
- Potentially 3 formats for time:
-
Item.timer.setTimerDiff(time,command if different)
- Same behaviour as previous, but with send command if different function
-
Item.timer.reschedule(time)
- Potentially 3 formats for time (see Item.timet.setTimer for details)
- Returns nextCommand if timer is already active, otherwise FALSE (?)
-
Item.timer.isActive()
- Returns absolute datetime value if scheduled, otherwise FALSE (?)
-
Item.timer.nextCommand()
- Returns the next command to be run, if the timer is active, otherwise FALSE (?)
-
Item.timer.cancel()
- Cancels the existing scheduled timer
- Returns absolute datetime value if it was scheduled, otherwise FALSE (?)
-
Item.timer.setTimer(time,itemCommand)
Also, taking in to account some of the other wishes on here, maybe it could also include a restart persist flag for the setTimer methods, e.g. Item.timer.setTimer(time,itemCommand,persist{NO|YES|FORCE}) with the flags meaning:
- NO (Default if flag omitted) - timer will not persist during reboot
- YES - Timer will be recreated to execute at previously scheduled time IF scheduledtime >= ‘OH timer engine’ restart time, otherwise will be ignored
- FORCE - Timer will be recreated to execute at previously scheduled time IF scheduledtime >= ‘OH timer engine’ restart time, otherwise will be executed immediately upon ‘OH timer engine’ restart.
I would be happy to be corrected, if there was already an easy way to already do this in OH, but unless my search terms have missed the mark, I can’t find anything in the documentation or community pages. Big wish? Yes. But it is a wishlist after all 
2 Likes
Sounds like a relatively straight forward extension to Expire. The way Expire works now is you define a state the Item should become (update or command) after a certain amount of time after the Item no longer receives an event. For example, update a sensor Item to UNDEF when it doesn’t receive an update for 15 minutes, or command a Switch to OFF five minutes after it last received a command ON.
Using Expire Updater [4.0.0.0;4.9.9.9] you can dynamically change the Expire time at runtime.
A simple rule can handle the restarting of the Expire timers (I should publish this as a rule template Rule template can now be found at: Restart Expire [4.0.0.0;4.9.9.9]).
configuration: {}
triggers:
- id: "1"
configuration:
startlevel: 50
type: core.SystemStartlevelTrigger
conditions: []
actions:
- inputs: {}
id: "2"
configuration:
type: application/javascript
script: >
var {helpers} = require('openhab_rules_tools');
console.loggerName = 'org.openhab.automation.rules_tools.Restart Expire.'+ruleUID;
//osgi.getService('org.apache.karaf.log.core.LogService').setLevel(console.loggerName, 'DEBUG');
helpers.validateLibraries('4.1.0', '2.0.1');
console.info('Restarting Expire timers');
var expireItems = items.getItems().filter(i => i.getMetadata('expire') !== null).forEach( i => {
if(i.getMetadata('expire').configuration['ignoreStateUpdates'] == 'true') {
console.debug('Commanding Item ' + i.name + ' Expire by command');
i.sendCommand(i.state);
}
else {
console.debug('Resetting Item ' + i.name + ' Expire by update');
i.postUpdate(i.state);
}
});
type: script.ScriptAction
You can get pretty close to your requirements today.
1 Like