Hello,
I really like the possibility to connect measurements to certain properties, but actually, I am at a point where the existing properties of the semantic model are not enough.
So my question is, is there a possibility to add my own created properties to the model like “dew point” or “absolute humidity” or something else?.
Would be great if somebody can tell me if it is possible and if yes, how to do it.
Thank you all in advance!
No, it is not possible to expand the semantic model.
I would also like to mention that „absolute humidity“ is just a humidity property, so already existing.
Please check the brick scheme for included semantics…
Recent versions of brick schema started to add many more properties and classes (ie. Meter, Inverter, etc) which are still missing in OH side. It also allows to define new types based on predefined meta classes, so its a bit ahead compared to what openHAB permits.
@Zampe Have a look on Discussion on ontology improvement · Issue #1791 · openhab/openhab-core · GitHub
Thanks to everyone for the answer.
Even it is not possible in a simple way, the answer nevertheless helps to stop searching.
I find the static model a strange design. I’m in the middle of “moving” from OH2 to OH3, and I’ve already seen a lot of posts instructing us to throw away our existing structure (Sitemap, Basic UI, plain old “Location” etc) in favor of the semantic model (and of course also that we must use the GUI so that it’s hard to back up the configuration properly).
Already I’m missing locations like “Stable”, “Barn” and “Pasture”. I can’t really find anything that fits particularly well, unless I want to somehow keep the horses in a “Shed” or “Garage”. I’m sure my list of missing terms will be long by the time I complete this, and to me this is obvious: People have different needs and live in different types of homes. A list that encompasses everything that everyone would need would be extremely long, and I honest don’t quite see to point of even attempting to make one. Why does it have to be static? Why can’t people just add “terms” themselves, and select “type” and “parent”. This would be easy to do both in a text file structure and a database structure.
I trying to find a reason for the decision, and I’m sure there are reasons I don’t know about. But still, it seems to me at the moment like I’m “being asked” to invest in a system that I know is “broken” from the very start, and it’s not very tempting.
I understand that I will be told to just pick something from the list that is “close”. But that will end up putting things that are completely unrelated in the same “category”, and I have a hard time to understand how the model will ultimately be useful if one has to make so many compromises to make it fit. While the “old system” using groups in sitemaps weren’t exactly elegant, it did at least allow us to make a model that reasonably resembles the place it’s supposed to describe.
At this point I’m not convinced that it will be worth it, and I’m considering just staying with the “old model”. I assume that these things are considered “deprecated” now and that it will become more and more difficult to use in the future as the focus and development don’t really care about that anymore, and everybody that asks about it will be given a standard reply that they should just forget that an use the “new”. Using something that will gradually “disintegrate” while you use it, isn’t very tempting either, so I don’t know what to do at this point.
As such, I guess my question is, are there any plans that can help make the decision easier? Are there plans to make the semantic model dynamic? Are there plans to maintain the two “systems” in parallel, or will one just be left to die a slow death? Will there be a system that is both flexible enough to fit and that will be maintained, or do we have to choose?
This is a complete wrong understanding.
You don‘t have to use the semantic model, and you don‘t have to use the GUI for configuration.
openHAB 3 still does and will in the future support textual configuration via things and items files.
This has already been discussed and confirmed many times. Creating equipment with many points (items) is just a lot easier via GUI. There have been broad discussions regardin pros and cons using either way for configuration. It is totally up to you.
Also adding new entrys to the model has been dicussed. openHAB is following the Brick scheme, therefore we do not have an easy option for adding your own.
But what you can do is open a feature request at github to have the modell extended with, from your perspective, missing entrys. This has already happened in the past and extensions to the modell have been applied.
Coming back to your backup topic, GUI config is stored under userdata/jsondb as plain JSOn textfiles, so easily can be backed up. There are also user configurable backups stored in that folder structure, default is having 5 backups.
I know that I can use textual configuration files, I currently do that now on my OH3 installation (I “migrate” by having the OH2 installation untouched and operational until I am content with “actually moving”). My point was just that my impression from reading different topics on the forum is that it is often “recommended against”/frowned upon by many (not all of course), and that makes me fear that it will become increasingly “hard”/impractical to do. If it’s here to stay, without being marginalized, that’s great.
It’s the same with the semantic model - I fully understand that I don’t have to use it as it is today. But, if Main UI/semantic is the only thing getting attention from now on, and the two aren’t “merged” in some way, chances are that using the “old way” will become increasingly hard in the future and at some point it might just be too impractical to stay.
I have nothing against GUI creation in itself, I just don’t like the way the GUI stuff is stored. Things might have improved, but I learned the hard way in OH2 that the only way to not have strange things happen to my definitions were to do the text file definitions (I’ve never done “things” with text files, but everything else). I also happen to have a number of Fibaro smoke detectors that just forget about their association with the z-wave controller every few months, so that I have to re-associate them and they all get new ID’s. Using find/replace in a text editor is certainly much quicker than setting “building new” objects and relations in the GUI every time. I have also created a Git repo in the $OPENHAB_CONF folder, where I commit and push all changes to a remote server. This is a kind of backup that give me much more control than “automatic backups” where I don’t really know what is backed up and for how long. I can also go back and study the changes I have made if something had an unintended consequence. Ideally I’d wish that those weren’t two different worlds, that GUI creation/modification could manipulate configuration files.
I don’t know the Brick schema, so I don’t know that limitations it poses, but it’s a bit strange if it’s possible to add options via PRs but not dynamically. If it’s rules by some overlord standard, it should be equally difficult to add “missing entries” to the code base. If not, what is the purpose of enforcing this “uniformity” across OH installations? To make it easier for commercial actors that maintains many OH installations?
I know about the JSON storage, and I’ve looked at the files. I just don’t know if they are “standalone” or if they are “relational” so that they contains ID’s or other things that makes them not work on their own. What I mean by that is: Can I take a JSON file from one OH installation, dump it in the JSON storage on another, and then have that thing/item/whatever appear and work on the other installation? If so, the JSON storage is fine by me - it’s not that I particularly love the format of the textual configuration files. I can just as well write JSON files, or YAML, or even XML if I have to - that’s not the important thing. The important thing is that you don’t need other references in other parts of the system from them to be “valid”.
Adding new entries to the model needs to be done in several places, therefore it is not that easy.
That‘s what the userdata folder is intended for. You can copy the JSONDB folder over to another installation and your settings should be back.
Just a littlerning, never edit the json files in there while openHAB is running, this will break your config.
My fibaro motion sensors also do this. With the MainUI and the gui, it is (assuming the z-wave inclusion goes smoothly) less than a dozen clicks and one copy paste to completely swap out the old thing and links for the new one.
There are only a few specific places where I can think of users actually being discouraged from using text config: z-wave thing setup and actually using the semantic model. Otherwise most users in this forum recognize text config vs UI config as a perfectly respectable personal choice.
As for git backup many users who rely on the UI for config use git backup of the jsondb. There’s been quite a bit of intentional development to make this efficient, so that is not the issue you think it is.
If the text config works for you great. The same is true for many users and that’s why it’ll remain a viable option. All I’m saying is be careful about the claims and assumptions you’re making about the UI config, many of the perceived pitfalls have already been identified and dealt with.
I use the snapshot version of openhab and exclusively use textual config for my items, things, rules and sitemaps (the old basic UI).
I have started adopting the semantic model and agree that there needs to be a user definable system.
Currently I just add my own extra tags and groups where I see fit and they can equally help in my rules even though they are not part of the model.