Unexpected behavior of the semantic model

Semantic Model

Hi, I am a new openHAB user. I am learning quickly thanks to the excellent documentation and community. I am currently seeing unexpected behavior in the Semantic Model tree, so I would like to know if I am doing something wrong.

In summary, I expected that the position of the Items on the Semantic Model page would depend only
on the definition of that Items and not on how they are distributed in the .items files, or if they
are modified while the system is running.

I will show two cases. The first one shows the same definition of the Items but in one case they are
all in the same files and in another case they are distributed into two files. Then, I will show that
two equal configurations give different results, and those results depend on the previous Items
definition.

openHAB Docker version: openhab/openhab:3.2.0.M3-debian

1) Location of the Items in the files

1.1) All Items in a single file

test.items

Group gHouse  "House"  <house>          ["SummerHouse"] {widgetOrder="0"}
Group gLiving "Living" <sofa>  (gHouse) ["LivingRoom"]

Switch Boiler          "Boiler"   <heating>  (gHouse)  ["RadiatorControl"]
Switch Living_Radiator "Radiator" <radiator> (gLiving) ["RadiatorControl"]

I start openHAB and create the admin account.

The image shows that it works as expected:

  • Radiator is in Living
  • Boiler is in House

1.2) Items in separate files

The same definition as before, but now in two files.

groups.items

Group gHouse  "House"  <house>          ["SummerHouse"] {widgetOrder="0"}
Group gLiving "Living" <sofa>  (gHouse) ["LivingRoom"]

heating.items

Switch Boiler          "Boiler"   <heating>  (gHouse)  ["RadiatorControl"]
Switch Living_Radiator "Radiator" <radiator> (gLiving) ["RadiatorControl"]

I start openHAB and create the admin account.

The image shows that the result is not the same as before:

  • Radiator is in the root
  • Boiler is in the root

Summary: The same definition of the Items produces different results.

2) Items modified while the system is running

2.1) Modifying some Items while openHAB is running

Lets start with the same config than the last test.

groups.items

Group gHouse  "House"  <house>          ["SummerHouse"] {widgetOrder="0"}
Group gLiving "Living" <sofa>  (gHouse) ["LivingRoom"]

heating.items

Switch Boiler          "Boiler"   <heating>  (gHouse)  ["RadiatorControl"]
Switch Living_Radiator "Radiator" <radiator> (gLiving) ["RadiatorControl"]

I start openHAB and create the admin account.

Of course, we have the same unexpected results:

  • Radiator is in the root
  • Boiler is in the root

Then, I add “Equipment” in the Boiler and Radiator Items while openHAB is running:

heating.items

Switch Boiler          "Boiler"   <heating>  (gHouse)  ["RadiatorControl","Equipment"]
Switch Living_Radiator "Radiator" <radiator> (gLiving) ["RadiatorControl","Equipment"]

The Semantic Model is updated and now we see that:

  • Radiator is in Living
  • Boiler is in House

It seems that adding “Equipment” solves the problem, so in the next test I will add “Equipment” from
the beginning.

2.2)

Now I try to reproduce the same result as in the last test but having the Items already configured
for the openHAB first start instead of modifying the files while openHAB is running.

groups.items

Group gHouse  "House"  <house>          ["SummerHouse"] {widgetOrder="0"}
Group gLiving "Living" <sofa>  (gHouse) ["LivingRoom"]

heating.items

Switch Boiler          "Boiler"   <heating>  (gHouse)  ["RadiatorControl","Equipment"]
Switch Living_Radiator "Radiator" <radiator> (gLiving) ["RadiatorControl","Equipment"]

I start openHAB and create the admin account.

The same configuration files as in test 1.2), but now with a different result.

The image shows that:

  • Radiator is in the root
  • Boiler is in the root

Summary: The same file contents produce different results. That results depends on when the Items were configured (before o after openHAB first start).

The playbook

This is the Ansible playbook used to run the tests:

- name: Ensure containers are running
  hosts: infra
  vars:
      openhab_image: openhab/openhab:3.2.0.M3-debian
  tasks:

#    - name: Copy openHAB test items file
#      tags: openhab
#      ansible.builtin.copy:
#        src: files/test.items
#        dest: /opt/openhab/conf/items/test.items
#        force: no

    - name: Copy openHAB groups items file
      tags: openhab
      ansible.builtin.copy:
        src: files/groups.items
        dest: /opt/openhab/conf/items/groups.items
        force: no

    - name: Copy openHAB heating items file
      tags: openhab
      ansible.builtin.copy:
        src: files/heating.items
        dest: /opt/openhab/conf/items/heating.items
        force: no

    - name: Ensure openhab is up
      tags: openhab
      docker_container:
        name: openhab
        image: "{{ openhab_image }}"
        state: started
        detach: yes
        interactive: yes
        tty: yes
        volumes:
          - /etc/localtime:/etc/localtime:ro
          - /etc/timezone:/etc/timezone:ro
          - /opt/openhab/conf:/openhab/conf:Z
          - /opt/openhab/userdata:/openhab/userdata:Z
          - /opt/openhab/addons:/openhab/addons:Z
          - /opt/openhab/.java:/openhab/.java:Z
        network_mode: host
        restart_policy: unless-stopped
1 Like

Would the results be because you are using item files and not the UI.
I know some things don’t work properly if you mix them.

If you browse to the Items configuration pages, do they belong to the right groups?
In openhab.log, do you see both of your .items files being loaded?

Explain more about what you mean by this. Why are you creating the admin account every time? That should only happen on the very first start of openHAB.

The issue might be that while it’s possible to apply an Equipment tag to a regular Item, it’s more typical to apply those tags to a Group Item. Then the members of that Group will have a Point/Property tag pair.

This implies that there is something wrong with OH recognizing the “RadiatorControl” tag as an equipment tag.

I did more tests reaching new conclusions. First, I answer some of your questions:

No, they do not belong to the right groups.

Yes, both items files are being loaded.

For troubleshooting, I want to be sure that no files were left that could modify the results, so I remove the container and the /opt/openhab directory before starting each test, then I have to create the admin account.

New results

The problem seems to be in the order in which the Items are loaded.

For example, this Item file works properly:

Group  gHouse "House"  <house>              ["SummerHouse"]     {widgetOrder="0"}
Switch Boiler "Boiler" <heating>  (gHouse)  ["RadiatorControl"]

but this file doesn’t work as expected:

Switch Boiler "Boiler" <heating>  (gHouse)  ["RadiatorControl"]
Group  gHouse "House"  <house>              ["SummerHouse"]     {widgetOrder="0"}

On the other hand, Items seems to be loaded in the same order that the files are loaded (not 100% sure that files are loaded alphabetically).

These .items files produce the expected results:

$ cat /opt/openhab/conf/items/a.items  
Group  gHouse "House"  <house>              ["SummerHouse"]     {widgetOrder="0"}

$ cat /opt/openhab/conf/items/b.items   
Switch Boiler "Boiler" <heating>  (gHouse)  ["RadiatorControl"]

Screenshot_20211011_232456

but the following files do not produce the same results. Note that I only swapped the file names:

$ cat /opt/openhab/conf/items/b.items   
Group  gHouse "House"  <house>              ["SummerHouse"]     {widgetOrder="0"}

$ cat /opt/openhab/conf/items/a.items                    
Switch Boiler "Boiler" <heating>  (gHouse)  ["RadiatorControl"]

Screenshot_20211011_233242

$ tail -f /opt/openhab/userdata/logs/openhab.log      
2021-10-11 23:28:43.007 [INFO ] [org.openhab.ui.internal.UIService   ] - Started UI on port 8080
2021-10-11 23:28:48.213 [INFO ] [.core.model.lsp.internal.ModelServer] - Started Language Server Protocol (LSP) service on port 5007
2021-10-11 23:28:48.264 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'a.items'
2021-10-11 23:28:48.555 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'b.items'
2021-10-11 23:28:53.321 [INFO ] [e.automation.internal.RuleEngineImpl] - Rule engine started.
1 Like

OK, then the problem isn’t with the model nor the model view but in the loading of the Items from the .items files. Group membership is how that hierarchy is created.

I don’t know if the order that .items files are loaded is defined. The order you see now may not always be the order that they are loaded in forever,

The best I can offer now is to open an issue on GitHub to address the problem that Items that are loaded before their Groups are loaded never become members of that Group. In the mean time, using managed Items will work.

No need - there’s already one:

1 Like