OH3: can I/we already ask questions WRT OH3

Is it acceptable to ask questions about OHv3? … given it is a pre-release to check out?

I have run up a OH3 instance in docker and find things that do not work, and the docs do not contain that info… meaning I am stuck.

E.g. time thingies like now.withTimeAtStartOfDay no longer works.

Or adding a rule from file is being ‘sucked’ in, but where does it go, and it cannot be edited, because it was provisioned from file.

Is editing planned in the future?
Or does the current recommendation still apply to use the UI for Things and channels and manage items and rule via files?

Also what is the model for?
Does it interfere with existing groups?
How to get a location under the location.
I do not get it :slight_smile: the model. Any info op that I have overlooked (not found).

Where did the sitemap go?
What do the pages do or stand for?
Masonry and Blocks? Huh?

Yes, these kinds of questions.

Or is it too early with these questions?

But the most important thing is: OH3 looks great! … if not awesome!

in the release description of OH3M1 reference is made to OH3 release tracking board. There is the following issue under done Replace org.joda.time with java.time and drop Joda-Time support #1250 .
“now” based on joda-time. So I think that’s the reason.
It’s just one answer to the many questions :blush:

1 Like

Sure. Just respect that developers are very busy with making OH3 become a great user experience.
So read the announcement notes, read the ‘Wiki’ and other OH3 docs posts first and don’t ask about stuff explained in there. And expect not to get answers to every question.

Of course, though the answer may be “we don’t know” or “not yet” or “maybe.”

One big change between OH 2.5 and OH 3 is the removal of Joda DateTime. It has been replaced with Java’s native Time classes, in particular ZonedDateTime. Unfortunately it’s not 100% compatible with Joda, most notably missing all of the withTimeAt methods. An equivalent for withTimeAtStartOfDay would be now.withHour(0).withMinute(0).withSecond(0).

Text based rules can only be edited from the text file it’s defined in. There is no plan to edit .rules files from the UI. Only rules stored in the JSONDB can be edited through the UI. However, you can enable or disable rules through the UI no matter where they are defined. But I don’t think disabling a rule from a source file will remain disabled when the file is reloaded. I never tired that. NOTE: This is true for Rules DSL, Jython, JavaScript, and Groovy.

It’s becoming more of personal preference. Many of the things that made PaperUI unusable have been addressed in the MainUI and as I’ve mentioned in other places, things tend to work really well when they run out of the JSONDB. But the fact remains, if you define it in text files you can only edit it in text files. You can see them in the UI but it’ll be read only.

It’s used by HABot which is a chat bot type UI for interacting with OH. It lets you add the metadata where you can ask it stuff like “Are the lights in Nate’s bedroom ON?” It also makes it easier to build Pages as you can populate a page from the model (e.g. you can create a page for Nate’s Room and populate it from the model and all the devices in Nate’s room will be automatically added to the page.

If neither is something you plan on doing anytime soon you can ignore the model. But also, as I’ve said in another thread, building the model makes the search function on the Items page even more useful as you can search using concepts from the model as well.


Add it as a member to the parent Location Group.

Building a sitemap from the MainUI is in work and not yet completed I believe. To get to BasicUI when you first log in there is a little icon in the upper right corner. Click it and it will let you select one of the other UIs that are installed.

They are an alternative UI and they are really super powerful. I don’t know the future plans for when/if HABPanel or BasicUI will become legacy (not necessarily deprecated but there wont be too much continued development). If you like Sitemaps or HABPanel you don’t need to mess with Pages. But I’ve been playing with them and I find them a little bit easier to customize and build exactly what I want than HABPanel but far far more complex than Sitemaps. Some of the big additions though include:

  • several new concepts to represent data
  • ability to have more complex control over presentation (e.g. only show certain Items based on who is logged in, change the representation of an Item based on other Items, combine multiple Items into one widget)
  • ability to enter text and date times

And I’ve just scratched the surface. I’ve never been a huge fan of HABPanel but I’m really liking what I see with Pages.

They are the concepts that describe the parts of a Page. See [wiki] Building Pages in the OH3 UI: documentation draft (1/3) for the start of the documentation on it.

Absolutely not. They will help us understand where the pain points are and improve the first draft of the docs. And as you learn how to use this new stuff, please consider contributing to the docs. All the pages I linked to are wikis.


Also what is the model for?

It’s used by HABot which is a chat bot type UI for interacting with OH. It lets you add the metadata where you can ask it stuff like “Are the lights in Nate’s bedroom ON?” It also makes it easier to build Pages as you can populate a page from the model (e.g. you can create a page for Nate’s Room and populate it from the model and all the devices in Nate’s room will be automatically added to the page.

Another intended goal with this is that you’d get a way to slice and dice the information however you want depending on your needs using the 4 tabs on the home page (outside the Overview tab where you can do what you want).

For example, if you want to see everything in your master bedroom you’d go to the Locations tab and open the Master Bedroom card.
If you want to see every lightbulb in your house you go to the Equipment tab and open the lightbulb card.
If you’re interested in a consolidated view of temperatures, you go to the Properties tab and open the Temperatures card.
All of this without having to build pages or sitemaps, and it will be updated automatically as you add more items - you only need to have a well-designed model.
It’s hard to get it right, and there are legitimate needs for customization but the intent is that the model will allow you to show your items in different perspectives.


A post was merged into an existing topic: DateTime Conversion (openHAB 2.x)

I read up on Brick and then it clicked, as I have used GraphML and ontologies in a work context. The following slide may help to get a high-level appreciation of the model.

(Source: https://brickschema.org/papers/Brick_Memoori_Webinar_Presentation.pdf)

(A more practical view)

… but, the user can decide on how much ‘abstraction’ to use for their home or setup.

[edit] This Google video may help to understand the impact of an ontology…


Technically speaking there are no blocking points for brick schema. It can be yet another metadata kind stored by openHAB. I am not sure how complex is submission of new UI parts/components, but @ysc been working pretty hard to make it easier to extend.

I would say one of the biggest pain points when expanding the schema is that it’s completely translated into 5 languages, in addition to English (German, French, Dutch, Norwegian and Polish) to allow natural language queries with HABot so if you add more you’d normally need to spin up a translation effort.

@Max_G Thank for your topic. The video is really interessting. Starting a minute 15:00 they talk about ontologys.

Be aware the openhab scheme is not brick

I bet that the translation into different languages will be no problem. But OH scheme is not brick and it has some (from my point of view) serious shortcommings.

I made a round over brickschema inputs (the turtle files) and they are parsable from Java with Apache Jena library. For sure there is a way to query underlying graph in multiple combinations.
I’m going to check if there is a way to scaffold some code from definitions and unify handling of some elements as I am esecialy curious of location modelling which can be used / queried alone.

Moving over a little bit with this one - I was able to parse brick schema and source classes and class hierarchy for points and locations using below code:

import java.io.FileWriter;
import java.io.IOException;
import java.io.InputStream;
import java.io.PrintWriter;
import org.apache.jena.n3.turtle.TurtleReader;
import org.apache.jena.ontology.OntClass;
import org.apache.jena.ontology.OntModel;
import org.apache.jena.rdf.model.Literal;
import org.apache.jena.rdf.model.ModelFactory;
import org.apache.jena.rdf.model.Property;
import org.apache.jena.rdf.model.RDFNode;
import org.apache.jena.util.iterator.ExtendedIterator;

public class BrickReader {

  public static void main(String[] args) throws IOException {
    final OntModel model = ModelFactory.createOntologyModel();

    final TurtleReader reader = new TurtleReader();
    final InputStream resource = BrickReader.class.getResourceAsStream("/Brick.ttl");
    reader.read(model, resource, "");

    PrintWriter out = new PrintWriter(new FileWriter("brick.csv"));
    OntClass clazz = model.getOntClass("https://brickschema.org/schema/1.1/Brick#Location");
    introspect(out, clazz, "Location", true);

    clazz = model.getOntClass("https://brickschema.org/schema/1.1/Brick#Equipment");
    introspect(out, clazz, "Equipment", true);

    clazz = model.getOntClass("https://brickschema.org/schema/1.1/Brick#Point");
    introspect(out, clazz, "Point", true);

    clazz = model.getOntClass("https://brickschema.org/schema/1.1/Brick#Tag");
    introspect(out, clazz, "Tag", true);

  private static void introspect(PrintWriter out, OntClass clazz, String tag, boolean introspectSubClasses) {
    introspect(out, clazz, tag, introspectSubClasses, 0);

  private static void introspect(PrintWriter out, OntClass clazz, String tag, boolean introspectSubClasses, int nesting) {
    final String clazzLabel = clazz.getLabel(null);
    if (clazzLabel == null) {

    out.print(tag + "," + clazzLabel + ",");
    OntClass superClass = clazz.getSuperClass();
    if (superClass != null && superClass.getLabel(null) != null) {
      out.print(superClass.getLabel(null) + ",,");
    } else {
    out.print(clazzLabel + ",");

    Property definition = clazz.getModel().getProperty("http://www.w3.org/2004/02/skos/core#definition");

    if (definition != null) {
      RDFNode property = clazz.getPropertyValue(definition);
      if (property != null && property.isLiteral()) {
        out.print("\"" + ((Literal) property).getString() + "\"");

    for (ExtendedIterator<OntClass> it = clazz.listSubClasses(); it.hasNext(); ) {
      OntClass subClazz = it.next();

      if (subClazz.isClass()) {
        if (introspectSubClasses) {
          introspect(out, subClazz, tag, introspectSubClasses, nesting + 1);


Above program is quite simple, however it is able to navigate over ontology and source labels and descriptions which is pretty much everything needed to process model.

Now, the interesting question is how such thing could actually work with OH, cause OH semantic model is really fitted into items through groups and tags. Brick related metadata could possibly be maintained there too. Comaring quickly both - I see that openHAB have more names for locations (both outside and inside building), while Brick have more diverse pool of point definitions which come from variety of hardware it attempts to cover.

I’ll probably park it here since I currently have no time to continue work in this direction.

Example CSV I was able to generate: https://gist.github.com/splatch/9294a7d096f0d1d2d3374af1a0c68f93 - I even attempted to generate new semantics out of it using generateTagClasses.groovy script, but it produces quite bad results due to whitespaces in tag names.

1 Like

The longer I was spinning around “cloud” service and deployment of OH at “wider” scale the more I am convinced to statement from @David_Graeff: Discussion about OpenHAB Item types.

Major pain point for most of setups, especially repeatable is management of data and user interfaces. While persistence services can be arranged (centralized, delegated or orchestrated) the user interface and remains a problem. I see a great value in new UI and its abilities. It is step forward, but it is still click-through kind of thing.
I believe that what David said about semantics coming out directly from binding (where possible) would greatly improve speed of setup. Till some degree it would also soften entry bearer for new users who would could get an predefined view for heating based on of any supported boiler kind.

Sitemap added in Openhab 3 is not deleted?

This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.