openHAB 4.0 wishlist

[mueller-ma]

Also +1 for more love for sitemaps!

I’ve been using them since openHAB 1 and IMO they are way easier to configured. Rendering sitemaps in apps can be done with native UI elements which feels much better to me than using the browser.

Things that could be done with sitemaps:

• Display them in Main UI
• Add new widgets, e.g. date and/or time picker
• Add an option that can be set for each subpage and controls the way the widgets are displayed:
  • One or two rows like Basic UI
  • Subpage and parent page, like the Android app
  • Grid, especially suitable for images.

[rlkoshak (Rich Koshak)]

@Oliver2

If you want to have an overview on about all your items with metadata defined, you’ll need to import both
org.openhab.core.items.Item.json
and
org.openhab.core.items.Metadata
and you need to link them by itemName.

No, you need to go to the API Explorer, get all the Items with “.*” for the metadata string and you’ll get it all in one JSON result.

Here’s one of my Items showing all the links and all the metadata.

  {
    "link": "http://10.10.1.112:8080/rest/items/Large_Garagedoor_Sensor",
    "state": "CLOSED",
    "metadata": {
      "listWidget": {
        "value": "widget:rlk_garagedoor_list",
        "config": {
          "name": "Large Garage Door",
          "control_item": "Large_Garagedoor_Opener",
          "sensor_item": "Large_Garagedoor_Sensor"
        }
      },
      "open_rem": {
        "value": "PT30m"
      },
      "name": {
        "value": "large garage door"
      },
      "semantics": {
        "value": "Point_Status_OpenState",
        "config": {
          "isPointOf": "Large_Garagedoor"
        }
      },
      "rem_time": {
        "value": "PT30m"
      }
    },
    "editable": true,
    "type": "Contact",
    "name": "Large_Garagedoor_Sensor",
    "label": "Large garage door",
    "category": "garagedoor",
    "tags": [
      "OpenState"
    ],
    "groupNames": [
      "Large_Garagedoor",
      "DoorsStatus"
    ]
  },

@Oliver2

And that housekeeping, I truly believe, is important to the maintainability of your system.

Maybe understanding what house keeping stuff you are trying to do would be informative.

@Oliver2

even with the best export tools I do not see any link to command options.

Command options are Item metadata. So they would appear under the “metadata” section of the JSON for the Item.

I’m not arguing against a CSV export (even though I do question it’s value over the JSON). I’m just pointing out what is already possible today, and if you really want CSV, JSON to CSV conversion tools are available in plenty (e.g. JSON To CSV Converter).

For the curious, in CSV that Item above would look like

link,state,metadata/init/value,metadata/listWidget/value,metadata/listWidget/config/outline,metadata/listWidget/config/inputmode,metadata/listWidget/config/subtitle,metadata/listWidget/config/placeholder,metadata/listWidget/config/title,metadata/listWidget/config/type,metadata/listWidget/config/sendButton,metadata/widget/value,metadata/widget/config/outline,metadata/widget/config/clearButton,metadata/widget/config/inputmode,metadata/widget/config/footer,metadata/widget/config/placeholder,metadata/widget/config/title,metadata/widget/config/calendarParams/timePicker,metadata/widget/config/calendarParams/dateFormat/hour,metadata/widget/config/calendarParams/dateFormat/minute,metadata/widget/config/type,metadata/widget/config/sendButton,metadata/etod/value,metadata/etod/config/type,editable,type,name,label,category,tags/0,groupNames/0,metadata/listWidget/config/name,metadata/listWidget/config/control_item,metadata/listWidget/config/sensor_item,metadata/open_rem/value,metadata/name/value,metadata/semantics/value,metadata/semantics/config/isPointOf,metadata/rem_time/value,groupNames/1,stateDescription/pattern,stateDescription/readOnly,metadata/listWidget/config/badgeColor,metadata/listWidget/config/icon,metadata/listWidget/config/badge,metadata/listWidget/config/iconUseState,metadata/widget/config/icon,metadata/widget/config/label,metadata/widget/config/iconUseState,metadata/stateDescription/value,metadata/stateDescription/config/pattern,metadata/stateDescription/config/readOnly,metadata/semantics/config/hasPoint,metadata/semantics/config/hasLocation,metadata/listWidget/config/idle_item,metadata/listWidget/config/on_label,metadata/listWidget/config/off_label,metadata/semantics/config/relatesTo,tags/1,metadata/LightsOverride/value,metadata/ga/value,metadata/ga/config/roomHint,groupNames/2,groupNames/3,groupNames/4,groupNames/5,groupNames/6,groupNames/7,metadata/semantics/config/isPartOf,stateDescription/options/0/value,stateDescription/options/0/label,stateDescription/options/1/value,stateDescription/options/1/label,stateDescription/options/2/value,stateDescription/options/2/label,stateDescription/options/3/value,stateDescription/options/3/label,stateDescription/options/4/value,stateDescription/options/4/label,commandDescription/commandOptions/0/command,commandDescription/commandOptions/0/label,commandDescription/commandOptions/1/command,commandDescription/commandOptions/1/label,commandDescription/commandOptions/2/command,commandDescription/commandOptions/2/label,commandDescription/commandOptions/3/command,commandDescription/commandOptions/3/label,commandDescription/commandOptions/4/command,commandDescription/commandOptions/4/label,stateDescription/step,metadata/expire/value,groupType,function/name,function/params/0,function/params/1,metadata/listWidget/config/visible,metadata/listWidget/config/label,metadata/listWidget/config/service,stateDescription/minimum,stateDescription/maximum,metadata/widget/config/iconColor,metadata/listWidget/config/iconColor,metadata/listWidget/config/color,metadata/debounce/value,metadata/debounce/config/timeout,metadata/debounce/config/state,metadata/widget/config/item,metadata/cellWidget/value,metadata/cellWidget/config/icon,metadata/cellWidget/config/item,metadata/cellWidget/config/label,metadata/cellWidget/config/title,metadata/listWidget/config/prefix,metadata/widget/config/validate,metadata/widget/config/name,metadata/debounce/config/command,metadata/listWidget/config/item,groupNames/8,metadata/widget/config/required,stateDescription/options/5/value,stateDescription/options/5/label,stateDescription/options/6/value,stateDescription/options/6/label,stateDescription/options/7/value,stateDescription/options/7/label,stateDescription/options/8/value,stateDescription/options/8/label,stateDescription/options/9/value,stateDescription/options/9/label,stateDescription/options/10/value,stateDescription/options/10/label,stateDescription/options/11/value,stateDescription/options/11/label,stateDescription/options/12/value,stateDescription/options/12/label,stateDescription/options/13/value,stateDescription/options/13/label,stateDescription/options/14/value,stateDescription/options/14/label,stateDescription/options/15/value,stateDescription/options/15/label,commandDescription/commandOptions/5/command,commandDescription/commandOptions/5/label,commandDescription/commandOptions/6/command,commandDescription/commandOptions/6/label,commandDescription/commandOptions/7/command,commandDescription/commandOptions/7/label,commandDescription/commandOptions/8/command,commandDescription/commandOptions/8/label,commandDescription/commandOptions/9/command,commandDescription/commandOptions/9/label,commandDescription/commandOptions/10/command,commandDescription/commandOptions/10/label,commandDescription/commandOptions/11/command,commandDescription/commandOptions/11/label,commandDescription/commandOptions/12/command,commandDescription/commandOptions/12/label,commandDescription/commandOptions/13/command,commandDescription/commandOptions/13/label,commandDescription/commandOptions/14/command,commandDescription/commandOptions/14/label,commandDescription/commandOptions/15/command,commandDescription/commandOptions/15/label,metadata/humi_alert/value,metadata/listWidget/config/actionCommand,metadata/listWidget/config/listButtonColor,metadata/listWidget/config/action,metadata/listWidget/config/visibleTo/0,metadata/listWidget/config/listButton,metadata/listWidget/config/equ,metadata/listWidget/config/actionFeedback,metadata/listWidget/config/actionItem,metadata/widget/config/actionCommand,metadata/widget/config/actionItem,metadata/widget/config/action,metadata/widget/config/visible,metadata/widget/config/prefix,metadata/listWidget/config/device,metadata/listWidget/config/mode,metadata/listWidget/config/setpoint,metadata/listWidget/config/mode_item,metadata/listWidget/config/currentTemp,metadata/cellWidget/config/scale,metadata/cellWidget/config/unit,metadata/cellWidget/config/releaseOnly,metadata/widget/config/trendItem,metadata/stateDescription/config/options/0,metadata/listWidget/config/actionAnalyzerCoordSystem,metadata/widget/config/responsive,metadata/listWidget/config/step,metadata/listWidget/config/min,metadata/listWidget/config/max,metadata/widget/config/min,metadata/widget/config/scaleSteps,metadata/widget/config/max,metadata/widget/config/releaseOnly,metadata/widget/config/step,metadata/widget/config/scaleSubSteps,metadata/listWidget/config/unit,metadata/listWidget/config/scaleSteps,metadata/listWidget/config/scaleSubSteps,metadata/widget/config/unit,metadata/widget/config/scale
http://10.10.1.112:8080/rest/items/Large_Garagedoor_Sensor,CLOSED,,widget:rlk_garagedoor_list,,,,,,,,,,,,,,,,,,,,,,true,Contact,Large_Garagedoor_Sensor,Large garage door,garagedoor,OpenState,Large_Garagedoor,Large Garage Door,Large_Garagedoor_Opener,Large_Garagedoor_Sensor,PT30m,large garage door,Point_Status_OpenState,Large_Garagedoor,PT30m,DoorsStatus,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,

@Spaceman_Spiff

so why not just add an export to textual configuration.

As I understand it it’s because we don’t really have anyone left who really understands Xtext and therefore we have no one who knows how or is willing to learn it enough to code a writer. All we have are readers for the text configs, not writers.

If someone volunteers to create code that writes out to the Xtext config files, I doubt it would be refused (assuming it’s done in an acceptable way). But it’s been how many years now and no one has stepped up yet to do it.

Of course, if you wanted to write your stuff as JSON, I know for certain a raw JSON rule placed in the automation folder will be imported and work. It wouldn’t be too much of a jump to support JSON for Things and Items too (assuming it’s not already supported), maybe even widgets and sitemaps and all the rest.

[Oliver2 (Oliver)]

@rlkoshak

Maybe understanding what house keeping stuff you are trying to do would be informative.

You probably missed that I added the following paragraph to my post:

@Oliver2

For example if you want to do mass updates on your item’s label or want to double check if you have added consistently the correct tags to your items, it was easier to do it outside of openHAB, e.g. in Excel and upload the xls file for updating your items.

(I made a comment about this here:

@Oliver2

I have seen that my previous post was somehow cut off. I have added the rest which makes my wish clearer.

)

[Spaceman_Spiff (Sebastian)]

@rlkoshak

As I understand it it’s because we don’t really have anyone left who really understands Xtext and therefore we have no one who knows how or is willing to learn it enough to code a writer. All we have are readers for the text configs, not writers.

It’s easy to write a serializer without Xtext.
However it’s necessary to modify the readers (and the file format) to support nested metadata so one can round trip.
And currently no one is stepping up.

@rlkoshak

Of course, if you wanted to write your stuff as JSON,

I’ve already thought about supporting yaml items files in HABApp.
But the current item file are shorter and more concise because fields are specified by different delimiters and brackets.

String MyItem "MyLabel" (myGrp) [myTag] {channel="asdf"}

vs

{type: String, name: MyItem, groups: [myGrp], tags: [myTag], metadata: {channel: asdf}}

Maybe one day I’ll add it or maybe I’ll even add *.items file support.
HABApp can currently already create *.items files so it might make sense.
We’ll see - it’s currently in my backlog.

[J-N-K (Jan N. Klug)]

@Spaceman_Spiff

So you’d also need an import function, too. We already can import from textual configuration, so why not just add an export to textual configuration.

Because textual configuration essentially is a DSL and depends on Xtext model. We can only parse them, not write them. That’s the reason why managed configuration is JSON which can be easily parsed and generated.

For items it is probably easy to write a serializer, for things it’s really hard stuff.

[J-N-K (Jan N. Klug)]

@rlkoshak

@J-N-K

I would very much like a simple „Export everything and download as .zip“.

Sounds very much like the backup/restore through the REST API mentioned above. Or do you have something else in mind?

Yes, we would need backend support for taking a snapshot of the JSON databases and archive them (would be nice to be able to select .zip or .tgz). I think that’s not so hard, but we also need UI support for that.

[Konfusius (Reinhold Wagner)]

OH 4 would make me very happy if timers would be persistent (= would survive an openHAB restart).

[florian-h05 (Florian H.)]

Out of interest: What is the use case of this?

[rlkoshak (Rich Koshak)]

@Konfusius

OH 4 would make me very happy if timers would be persistent (= would survive an openHAB restart).

One way you can meet this right now is using a Rule with a Time is <item> trigger. Put the time when the “timer” should go off into an Item that triggers the rule and make sure you have restoreOnStartup configured on that Item. Any data that needs to be preserved needs to be in Items with restoreOnStartup too. Variables would not survive an OH restart.

[J-N-K (Jan N. Klug)]

@Spaceman_Spiff

I’d wish for a perception shift.
I’m under the impression that sometimes HABApp is being viewed being as more or less annoying attachment to openHAB.
I’d like it to be viewed as a chance to make openHAB a better experience for people that want to create rules in python.

It might be that my heart for 3rd party add-ons and tools integration is a bit wider than that of others, but I don’t think that’s the case. The problem with core development is that some things look easier on first thought than they really are.

I fully understand your request for "include metadata in ItemAddedEvent, but in fact with the current code that would lead to inconsistent results that might be different on subsequent starts. I have been working on making the start-up more predictable in the past weeks (mostly related to script loading), but that one would be very hard. A solution would be of course to merge metadata registry with item registry, but as you can see in the discussion, there are side-effects to that. openHAB has a very large user-base, not all of them are so technophile like you and me (you can see that om this forum, but even more if you look e.g. at the German Facebook user group).

When breaking something, we need to make sure we have an answer to the „why“ question and “it makes it easier for 3rd party add-ons that you don’t use” is not a very good answer to that. The same applies to “it’s more consistent”, especially when things that did work before are no longer possible.

From a lot of comments (also here) we hear that keeping breaking changes to a minimum is something that is considered a big pro for openHAB. That’s also the reason why I usually try to port things back to DSL rules or fix issues there, even if it would -from a purely technical point - be much easier to just drop that (I don’t want to discuss that here, I know that neither dropping textual configuration nor dropping managed configuration will happen).

So if some request is not fulfilled, it’s not that we want to make things harder for 3rd party developers or users., In most cases it’s either not enough development/review capacity or the need to protect existing installations.

[Spaceman_Spiff (Sebastian)]

@J-N-K

From a lot of comments (also here) we hear that keeping breaking changes to a minimum is something that is considered a big pro for openHAB.

I absolutely agree for normal version updates (e.g. 3.3 → 3.4).
Nothing is more annoying when things break during a “normal” update.
For main version updates (e.g. 1.X → 2.0, 2.X → 3.0) however breakage can and will be expected.
Otherwise it’ll be impossible to move forward.

Maybe it makes sense to delay the new major versions an additional 3 months so the breaking things can be consolidated better in the new major release?
And after the major release we then have 2 years of stability.

@J-N-K

The same applies to “it’s more consistent”, especially when things that did work before are no longer possible.

Consistent behavior makes it easier for newcomers and not so tech savvy people to understand and use the openHAB concepts. Of course it depends on the degree of breakage, how many users will be affected and how hard it will be to fix the issue (if possible). There is no easy answer to this question yet I’ve found that easy (to grasp) concepts work best and that’s why I try so hard to get e.g. UoM 2.0 to openHAB 4.0.

@J-N-K

So if some request is not fulfilled, it’s not that we want to make things harder for 3rd party developers or users., In most cases it’s either not enough development/review capacity

Of course. I was never under the impression that someone didn’t want to do anything because he/she wanted to make it harder for me. We all work in our precious spare time which is limited.

And of course as the main Developer I would like it if the time invested would be a little bit more weighted to the HABApp side so I can make things easier for the HABApp users.

[csowada]

I’m not sure if it is possible already. But I want a simple solution to drop values out of range (min, max etc.). No JS Transformation or Proxy Items.

Ex . Sometimes one of the Mqtt sensors send invalid values.

[rlkoshak (Rich Koshak)]

@csowada

But I want a simple solution to drop values out of range (min, max etc.). No JS Transformation or Proxy Items.

The Smarthome/J marketplace has a Basic Profiles add-on which includes a Threshold Profile.

https://docs.smarthomej.org/3.2.15/org.smarthomej.transform.basicprofiles.html#threshold-profile

Installation instructions to access the market: GitHub - smarthomej/addons: SmartHome/J addons for openHAB

[binderth (Thomas Binder)]

@csowada

I’m not sure if it is possible already. But I want a simple solution to drop values out of range (min, max etc.). No JS Transformation or Proxy Items.

That’s something you can adjust within the channel-definition in many bindings. In MQTT-binding you have to click on “show advanced” and then there’s “absolut minimum” and “absolute maximum” for number-items.

[rlkoshak (Rich Koshak)]

@binderth

and then there’s “absolut minimum” and “absolute maximum” for number-items.

I forgot about that! :+1

[Vradatta (Eric Zenz-Matzl)]

I would like to have “input parameter” for functions so i could reuse a function for other items when i need the same logic

My problem now, i have several rules, using the same code. I have to change all rules one by one if i want to change or improve something.
This is tedious and error-prone…

[J-N-K (Jan N. Klug)]

That’s already possible if you use JS Scripting.

[JimT (jimtng)]

Can items and things configurations be maintained in a json format, but not touched by the mainui (other than for display purposes)? Basically the same way as *.items and *.things just in json format?

so openhab would reload changes in them.

That would get rid of xtext, but still satisfies textual configuration people maybe? It’s just a matter of dealing with a different format.

Then an addon can be created to read / reload *items and *things.

[rlkoshak (Rich Koshak)]

@Vradatta

My problem now, i have several rules, using the same code. I have to change all rules one by one if i want to change or improve something.

As @J-N-K indicates, this is already possible in JS Scripting and also jRuby, Jython, and I think Groovy.

When a rule directly runs another rule, it can pass a Map of values to the called rule. You can even do this from Blockly.

Even in Rules DSL, you can define functions and procedures that can take up to seven arguments as a global variable that can be called from all the rules defined in the same file.

If it’s a rule that might have a broader audience, you could publish it as a rule template. Then you can change the code once and reinstantiate rules based on that one template.

Finally, if you truly have the same code across several rules, they almost certainly can be collapsed into one rule using a predictable naming pattern for your Items and/or the semantic model.

There are many already existing ways to achieve this wish now.

@JimT

Basically the same way as *.items and *.things just in json format?

As I mentioned above, this is already possible for rules. It shouldn’t be too much of a leap to support this for Items and Things too.

@JimT

It’s just a matter of dealing with a different format.

It’s a pretty miserable format to work in though, especially for rules. That’s why the MainUI code tabs convert it to YAML which isn’t great, but way better to read and understand and work in than raw JSON.

JSON also doesn’t support comments which is a significant limitation I think.

But perhaps it would be low hanging fruit that can lead to something better in the future.

[J-N-K (Jan N. Klug)]

I don’t think that’s a good idea as it would add a third way of configuring the same object. From the technical POV it’s easy, you can always add as many thing or item providers as you like - as long as they can’t be modified. Just implement ItemProvider or ThingProvider.

But this will make a solution for Update existing Things for definition changes · Issue #1924 · openhab/openhab-core · GitHub even more difficult - if not impossible. My personal opinion is that we should avoid that.