Hi, I am a long time user and I have a script that goes through a given sitemap and it creates an alternative one but insted of the original items, it creates Grafana graphs showing the historical status of the item.
I have some comments at the beginning of the .items files defining range and these things.
I find the new chart capabilities of OH3 much faster and in general better than Grafana so I would like to do the same but using the OH3 charts.
The problem is that I don’t know where the configuration files for the new OH3 charts are. Any idea?
I read that with the REST API the new charts can be defined. That would be an option, but I cannot find in the REST API explorer where this part of the API is.
Defining more than 800 charts by hand it is not option of course.
Everything in MainUI gets stored in the JSONDB. It is best to use the REST API to interact with the JOSNDB rather than editing it yourself. For one thing you’ll have to stop OH before making any such changes or else OH will overwrite them.
I’m pretty sure you’ll use the ui REST end point but you’ll probably have to research the code or do some queries and experiments to figure out what the JSON needs to look like.
Have you worked out the Semantic Model yet? I’d be willing to bet that most of those charts are already dynamically generated. All Items that are queryable from the DB will be dynamically chartable individually. You can even put an outline of the chart behind the Item’s card.
When you put your Items into a Model a chart with all the Items will be available for all the Items of a given Property type automatically by clicking the “Analyze All” button at the bottom of the card.
The Items shown and the time period can be dynamically adjusted. Changes to the chart config can be saved as a new Chart page.
You can also create custom widgets with a custom Analyze All function to dynamically generate charts in that widget. In short you can add an “Analyze Item(s)” action to any widget which will add that “Analyze All” button and open a dynamically generated chart with the configured Items when clicked.
And again, you can customize these Charts and save them if you want to use them on a Chart Page.
In general, MainUI charts are mostly intended to be dynamically generated in these ways and not statically like your current setup is configured. Also, these charts can’t be used in a sitemap so the use cases you’re after really isn’t supported in MainUI anyway. So it might be worth considering adjusting your use case so it better fits with the MainUI model or sticking with the Grafana model and sitemaps.
Thanks a lot for the useful information. It turns out the even without updating my old openhab file based configuration, a plot for every item is automatically accesible. (http://OPENHABIP:PORT/analyzer/?items=ITEMNAME). It is just a few of them that I need averages and stuff like that which I need to create.
Thanks a lot for pointing me in the right direction. I have now my problem solved.
Anyway, updating my whole setup to use the new artefacts and model structure invented in OH3 is too much effort. With a configuration not file based this cannot be done easily with an awk script or a perl script. I know that the jason internal files are files, but they are not well described for me to transform my old setup into that. OH3 is meant to be setup from the GUI, and that is a big disadvantage in my opinion for big setups.
I’m not sure I completely understand this statement. You can apply the semantic model in your .items files if you so choose. You don’t have to use MainUI to do that. It’s frankly way easier to do so, even with large setups, to apply the model through the UI but it’s not required. And to be specific, it’s easiest to recreate the Items using “Create Equipment from Thing” rather than trying to apply the model to your existing Items.
But if you did want to move from .items files to managed Items (i.e. use the UI to work with Items)…
Just paste in the contents of your .items file there and it will create the Items based on the .items files syntax.
There are very very few things in OH 3 that cannot be supported in the text config files. Items and the semantic model are fully supported in .items files.
I’m not sure what your definition of large setups are, but there are users with thousands of Items fully managed through the UI without problem. Just because stuff is managed through the UI doesn’t mean:
the only way to create/edit them is by clicking with the mouse
there is no such things as bulk updates and changes
you can’t actually see the “code” that represents them
MainUI is not PaperUI. MainUI is actually usable.
I’m not trying to convince you to change anything. But I am compelled to reply to posts like this because there is far too much FUD about working with the UI in OH 3. There are lots of good reasons for using text config files and that’s OK.
Thanks, OH3 does read my .items files. I did not update my config going from OH2 to OH3 and it worked 100% fine. I did not need to ingest it either. What I meant is that I don’t know how to create equipments or any of the new stuff from just the terminal with some scripts manipulating all my config files, like I used to do. It is just a mater of being used to it I guess. I did not want to hurt any feelings.
I can modify 2000 items, 50 things and create 20 sitemaps in just a few command lines in 30 seconds but for an old guy like me, learning to do that through a web interface takes ages, and doing it then it takes forever.
As it turns out, I don’t need (for the time being) any of the new stuff to get what I need. You just solved my problem. Thanks again.
And the new plot capability is years ahead of grafana in my opinion. I am very happy with it. I am never going back to that twelve headed monster that is grafana.
Equipment and Location are just Group Items with one of a predefiened set of Item tags applied. Point Items are your existing Items with at least one of the predefined Point tags and an optional Properties tag applied. And these are standard Item tags, nothing special. See Items | openHAB for the syntax. See HABot Walkthrough (2/n): Semantic Tagging & Item Resolving for how to apply the semantic model using .items files. Yes, the model has been around long before OH 3 and it’s the same model as used by HABot.
So, to create an Equipment, create a Group Item with an Equipment tag. Then add the Items that are part of that Equipment to the Group. Then add Point/Properties tags to the Items you added to the Equipment Group. It’s all done with standard Item concepts (Group membership and Item tags).
Locations are the same. They are just a plain old Group Item with a Location tag. Equipment and Points are made a part of a location through Group membership.
Because the list is changing, you’ll want to look in MainUI for the current list of supported tags for Location, Equipment, Points, and Properties. Just click on the “semantic tag” field and you’ll see a list of the currently supported tags. The link above shows an old set which is still correct but not complete.
Using Thing autodiscovery, “Create Equipment from Thing” and the automatically built parts of the Overview Page based on the semantic model, I can do the same. I’m not saying one way is better than the other, just that both support these kinds of use cases. Thats the part I want future readers to understand. You don’t want to learn a new way of doing things and that is perfectly valid and fine. But I don’t want people to think that it’s impossible to do with managed Items too.
On the other hand, you have read/write access to items through the openHAB Core API so you can use the UI to program a quick ad-hoc JS or Jython or Groovy script (as in Settings > Scripts in the UI) to perform bulk changes.
I’ve done this a couple of times and wanted to do a write-up about this because it can be a huge time saver when you have all your items in the JSON DB.
An example of such a script could be:
// define a "dry run" variable to avoid performing unwanted changes -
// when you're positive the script will perform what you want (based
// on logging) change it to false
var dryrun = true;
// iterate over thems
ir.getItems().forEach(function (item) {
// if the item's name contains "Setpoint"
if (item.hasTag("Point") && !item.hasTag("Setpoint") && item.getName().indexOf("Setpoint") >= 0) {
// note: if print() doesn't work for you, switch to using the logging factory
print(item);
// replace the Point tag, use Setpoint instead
item.removeTag("Point");
item.addTag("Setpoint");
if (!dryrun) ir.update(item);
}
});
The above will match all the items having the “Point” tag and “Setpoint” in their name, and will apply the “Setpoint” tag instead.
Granted, it’s not for everyone and there might be a lot of tinkering but it’s an acquired skill, and using the “dry run” technique - exclude the statements altering your configuration with a variable and some “if” statements, or simply comment out the “dangerous” code until you’re ready - helps keeping you on the safe side.
