OH3, Denon AVR, properties/points

Hello,

I am trying to build a semantic model for the Denon AVR. The OH2.5 item definitions are here,

Switch marantz_power    "Receiver" <switch>         {channel="denonmarantz:avr:1:general#power"}
Dimmer marantz_volume   "Volume"   <soundvolume>    {channel="denonmarantz:avr:1:mainZone#volume"}
Number marantz_volumeDB "Volume [%.1f dB]"          {channel="denonmarantz:avr:1:mainzone#volume"}
Switch marantz_mute     "Mute"     <mute>           {channel="denonmarantz:avr:1:mainZone#mute"}
Switch marantz_z2power  "Zone 2"                    {channel="denonmarantz:avr:1:zone2#power"}
String marantz_input    "Input [%s]"                {channel="denonmarantz:avr:1:mainZone#input" }
String marantz_surround "Surround: [%s]"            {channel="denonmarantz:avr:1:general#surroundProgram"}
String marantz_command                              {channel="denonmarantz:avr:1:general#command"}

I added a Point/Property of “Switch” and “SoundVolume” to the definition (See below). However, what Point/Property should i give to the String items like marantz_input?

Switch marantz_power    "Receiver" <switch> (gDenon)  ["Switch"]      {channel="denonmarantz:avr:1:general#power"}
Dimmer marantz_volume   "Volume"   <soundvolume> (gDenon)   ["SoundVolume"] {channel="denonmarantz:avr:1:mainZone#volume"}
Number marantz_volumeDB "Volume [%.1f dB]"          {channel="denonmarantz:avr:1:mainzone#volume"}
Switch marantz_mute     "Mute"     <mute>  (gDenon)  ["Switch"]         {channel="denonmarantz:avr:1:mainZone#mute"}
Switch marantz_z2power  "Zone 2" (gDenon)  ["Switch"]                 {channel="denonmarantz:avr:1:zone2#power"}
String marantz_input    "Input [%s]"                {channel="denonmarantz:avr:1:mainZone#input" }
String marantz_surround "Surround: [%s]"            {channel="denonmarantz:avr:1:general#surroundProgram"}
String marantz_command                              {channel="denonmarantz:avr:1:general#command"}

A recent link to your current choices -

There doesn’t seem to be anything appropriate like “selection”, or non-specific, like “custom control”.

First you need to ask yourself what do you want out of the semantic model? Right now all it does is

  1. Provide a hierarchy and some nice ways to create and manage Items in MainUI which is irrelevant if you are using .items files

  2. Populates the three tabs of the overview page

  3. Allows interactions with HABot.

If none of the above apply, don’t bother with the model.

If 2 applies to you, I strongly recommend importing your Items into MainUI and abandon the .items files. The semantic model is only going to be the first complicated thing that will require research on how to use and constant referral to the reference documentation. You will also have to deal with state descriptions and custom default widgets which are all defined using Item metadata and there are lots of options.

When you have your Items in the UI, you get nice forms that present all the options to you. No need to learn all the options and how they are all used. It’s way less work to implement and figure out.

Also, definitely review Semantic Model | openHAB which explains the general concepts of the model. Things I notice so far with your attempt:

  • There is no Location Group
  • There is no Equipment Group
  • “Switch” is a Point tag. The Property is an additional and separate tag. The Point says what the actuator/sensor is and the Property describes what the actuator/sensor represents. For example, Mute would be tagged with “Switch” for the Point and “SoundVolume” for the Property.
  • “SoundVolume” is a Property tag. Property tags cannot stand on their own and must be paired with a Point tag. The Volume Item would be tagged with “Setpoint” for the Point and “SoundVolume” for the Property.

One reason why this is better in the UI is you can’t apply a Property to an Item without first setting the Point. And it’s impossible to confuse a Location tag with an Equipment tag with a Point tag with a Properties tag. They are all shown and selected from separately. It won’t let you mess it up, or at least makes it much more difficult. And you never have to look anything up because the list of possible tags are all right there to select from.

If using .items files, you’ll have to constantly watch changes to the source code to be aware when new tags are added, which is happening all the time.

An old list of the tags and their types can be found at the link above.

It is entirely possible that there isn’t an appropriate property tag for all Items. I don’t see anything appropriate for Zone 2. For the Point I’d either chose “Control” or “Switch” and maybe choose SoundVolume as the Property or leave out the Property.

It’s not clear if Input is a status or a control. If it’s just a Status I’d tag it with “Status” as the Point and maybe “Frequency” as the Property, though I’d probably leave out the Property. If you can control the input from this Item I’d use “Control” or “Switch” as the Point.

Note, not every Item needs to be a part of the model. If you have an Item that doesn’t need to be in the overview tabs, don’t include it in the model. Unlike with sitemaps, it’s possible to use more than one Item in a single widget. So you might combine some of these Items into a single widget (e.g. volume setpoint and mute button on one widget) in which case you’d only include on of them in the model, or you’d set the visibility on one of them to false through Item metadata.

Which brings me to reiterate my point. For now, the main reason to use the semantic model at all is to populate and customize the the Overview tabs. Given that when it comes to customization of how the Items appear will require custom widgets that can only be created through the UI, and managing the Item metadata required to apply custom widgets to the Items is way easier through MainUI I just don’t see any reason to bother with the semantic model unless you plan on managing your Items through MainUI anyway.

Frankly, it’s going to be more work to figure out how to do it all in .items files so OH can “automatically” generate those pages than it will be for you to just create custom Pages yourself. So I strongly recommend against trying to retrofit the semantic model to .items files. The effort is simply not worth it. But for UI managed Items, the semantic model makes it really easy to create, organize, and manage dozens of Items with relatively little effort.

Personally, after spending a day trying to import my existing Items into the model, I gave up and just recreated all my Items through the UI using “create equipment from thing”. I was able to recreate about 300 Items and have them all properly in the semantic model with custom widgets faster than it took me to import and retrofit 20 items from .items files.

Thanks for the advise. The primary reason i am working with .item files is that they are easier to look at, edit and migrate to another computer. I am not familiar how easy/difficult is the jsondb files to migrate if the computer ever crashes.

I have been using Sitemap until now. The reason I am trying to build MainUI pages so at not be left behind if this is the direction openhab is taking.

1 Like

They are a plain text file just like .items files. The only difference from this perspective is that they are stored in a different location. If you want to move stuff, you should use openhab-cli backup and restore which will grab everything anyway.

Then I wouldn’t bother with the semantic model. Over time, indeed, the model is going to be used for more and more. But wait until you have a compelling reason to use it before going through all the effort to implement it, especially if you have no plans to utilize the only thing the semantic model helps with right now.

And when you do decide to implement the semantic model you will want to abandon the .items files. To put it another way, don’t bother with the semantic model until its utility is great enough to overcome your reluctance to move off of .items files.

If ever to move over to using the UI instead of the files, what directories i need to empty out apart from /etc/openhab/items/ ?

I suppose i can keep the file contents of /etc/openhab/things/.

I never saw the point of .things files in the first place. You can’t do automatic discovery with them. There are limitations for some bindings where you can’t even do some important things when using .things files. Having a static text file you have to write and research to get the syntax correct compared to a text file that gets automatically populated with the right information that can’t ever have a syntax error just never seemed like a fair trade. But everyone has differing opinions and OHI supports them all.

But in general, and entity (Item, Thing, Sitemap, Rule) can only be defined in one place. If it’s defined through the UI it can’t be in a .items/.things/.rules/.sitemap file.

To me, it seems inconsistent for someone to want all the specific control over everything to the point that they won’t even allow OH to do some of the things automatically which it was designed and it excels at doing automatically (e.g. Things) to also want to do all the work with the semantic model so OH can automatically build the Overview tabs. If you won’t let it discover and create your Things, why would you let it discover and create your users’ interface which is far more something that we all will want to highly customize.

So that leads me to push users to choose either:

  1. use OH 3 just as you always have in OH 2.5; everything you’ve always have done is still supported and you can have all the control over everything you need

  2. Move to using MainUI to manage all your Things and Items (and even your Rules though that’s not a strong recommendation at this time until we get some more docs written) to take advantage of all that’s new in MainUI with the semantic model and Pages.

Trying to stick with text based configs and take advantage of MainUI at the same time is simply too much work and leads you to having a split configuration anyway because there are lots of things that cannot be done in text files in MainUI anyway (e.g. custom widgets).

If you were to move to MainUI for configs, be sure to review OH 3 Tips and Tricks which has lots of advice for how to migrate from text configs, even if you have 100 custom Generic MQTT Things and don’t want to have to click enter each one individually (hint, you don’t have to).

1 Like