Ideas and Discussion: What Features Do You Want in openHAB 5.0?

Development Features
386

A little late to the party, but since Christmas is around the corner my 5.x wishlist would include:

  1. %include-like syntax for sitemaps

    Why? How? (click to expand)
    Why?
    • In typical operation, I use Basic UI and full-on text based configuration almost exclusively. This means my primary sitemap file gets large (> 1500 LOC) which is not too fun to manage.
      Judging from this forum threads, there are others still using OH this way and the very feature of modular sitemap has been proposed years before (but got no traction then).
    • Any reuse of particular widget definition in more than one place (via copy-paste) opens up for them getting out of sync and is just an unnecessary nuissance.
    How? (just some loose alternative proposals as food for thought)
    1. [native] Extend the XText DSL definition of a sitemap and introduce a new keyword (ex. %include(./part1.sitemap.part)). Each part file would be a self-contained sub-definition which parses on its own, the outer parser only handles nesting into Frame or Text elements.
      Have the runtime stitch it at load-time (handling errors just in time, preserving their actual location). This way, the UIs don't need awareness of this feature

    2. [preprocessor] Add native (built-in) support for textual definition pre-processor (ex. #include ../some.text.file). Would work on text-level and require 2-pass processing, but (except error messages and appropriate source location) might be the most generic and easy.
      Arguably can be done today, off-system, by a simple script launching on startup.

    3. [new UI element]Instead of working on definition, have the UI be able to load sitemaps into nested widgets like so:
      Single-file sitemap (today) Multi-file sitemap (future?) 
      //File: main.sitemap
sitemap main label="Main sitemap" {	
    Frame label="Some things" {
        Default item=Item1
        //...
    }
}

      //File: main.sitemap
sitemap main label="Main sitemap" {	
	Frame source="frame1.sitemap"  // NEW
}

      //File: frame1.sitemap
sitemap frame1 label="Some things" {
       Default item=Item1
       //...
}

  2. native support for ~ ‘thingItem’ (thing-properties-as-items indirection)

    Why? How? (click to expand)
    Why?
    • This may be quite controversial to some (I'm aware of at least a few long debates on Things being things and not belonging in user-UIs), but:
    • There are numerous precedents where thing's (physical object's) configuration is modeled as OH Thing property and not a channel (I claim it is intuitive, actually - see how ZWave or Homematic bindings expose device-side configurations). Some of such configurations are not set-once, but may benefit from being directly cotrolled by an User (not an admin!) from a regular UI (incl. Basic UI).
    • Thing's ONLINE/OFFLINE status can be useful to regular users in some contexts.
    How?
    1. [note] All the above (manipulating Thing configuration*, changing state, pushing online/offline state to String items) can be done via Items today using rules
          * - except for changing config of text-configured things.
      I am successfully using this approach myself. However, I think this rule boilerplate rather belongs to the core (as an opt-in) to make user's life easier.

    2. [the idea] I'm thinking OH could allow a first-class concept of a companion item (deliberately calling it a thingItem to distinguish, but technically it could be just new definition syntax for Items).
      A thingItem would be linked to a single trait of a Thing (similar to how items are linked to channels). For example: 
      3. //File: things/sample.things (just a sample - this actually needs to be in JSONDB for dynamic config to work)
Thing zwave:fibaro_fgs223_00_000:controller:node42 "Sample Thing" (zwave:serial_zstick:controller) @ "Bathroom" [
    node_id=9,
    ch1_delay_after_on=900
]

      //File: items/sample.thingitems
Contact thing1Online "Thing 1 - AVAILABILITY"  {
       thingProperty="zwave:fibaro_fgs223_00_000:controller:node42::available"
       //                         ^-- thingId::property syntax ---^^
       //                             'available' maps to thing's ONLINE status
       //                             If linked to a Contact, ONLINE means CLOSED, OPEN otherwise
       //                             If linked to a Switch, similar to above, but turning it off means Disable
       //                             If linked to a String, reports the state verbatim...
}

Number::Time thing1DelayOnTimeConfig "Thing 1 - Built-in delay timer value"  {
       thingProperty="zwave:fibaro_fgs223_00_000:controller:node42::properties:ch1_delay_after_on"
       //                             thingId::property syntax ---^^
}
    3. Add some predefined wildcard/groupings like: 
      //File: items/sample2.thingitems
Group:Contact:OR(OPEN, CLOSED) GOfflineThingsUserCaresAbout "Offline things [(%d)]" 
<contact> {
    thingProperty="*::properties:available"
    // * for all the things or [predicate] syntax for filtering            
}

  3. Opt-in auto-UNDEF linked items on device going OFFLINE

    Why? How? (click to expand)
    Why?
    • Some bindings do it already, can be done by rules (and quite generic), but leads to inconsistencies...
    How?
    1. Have a global (opt-in) setting and built-in support for managing state of Channels/Items when the associated Thing is no longer offline.

    2. Default would be DO_NOTHING (today's behavior), but could add a SET_UNDEF or SET_NULL options together with Item-level override config (ex. don't want to zero a last seen state).

  4. Allow runtime changes of (some!) properties of Things defined via .things file

    Why? How? (click to expand)
    Why?
    • *Not* proposing to revisit the JSONDB vs. .things file discussion. Rather making an observation that in certain bindings and for certain devices, Thing configuration comprises of both:
      1) an actual OH-side immutable configuration, and
      2) device-only configuration (affecting its operation, but not how OH speaks to it) - ex. see how zwave binding models configuration properties.

    • #1 must stay immutable not to risk definition conflicts. #2 however is typically discovered at runtime and never (allowed to be) entered into the .things file in the first place.
      As such, there's no risk of de-sync of state and even though the Thing definition needs to stay immutable, these properties in reality live only in the JSONDB overlay, and there's not much risk 'unlocking' them for edit.
    How?
    1. Extend core APIs to allow binding authors to express which properties are of cat. #2 (above).
      Either prevent these items to be configured via .things file, or force them having no default.

    2. When such a pre-designated (by binding author!) property is not explicitly defined in the .things file -> allow to modify it at runtime even if Thing definition comes from text file (persist changes to JSONDB only).

  5. RBAC for Items

    Why? How? (click to expand)
    Why?
    • This is probably the biggest complexity adder and may be YAGNI, but since there's a skeleton user/role model already, a fine-grained permisson management would be a nice and logical extension.
      I.e. an user with role=Child can't turn off parental controls (item is read-only).

    How?
    1. I think item-level might be good enough (esp. when combined with my idea #2 above)
      Example: 
      //File: items/permission_sample.items
Switch ParentalControls "TV Parental Control" 
{
    channel="some:dev:id:somechannel",
    permissions="" [ visibleForUsersInGroup="Everyone", changeableByUsersInGroup="Parent,Admin"]
             // ^-- could use this name for a predefined permission target
}
    2. UIs could benefit from being smart (hide controls, make them read-only), but merely a core-based implementation might do the trick (serve NULLs if user has no read access and reject commands if no write access).

  6. Allow full sitemap representation to be captured via .items definition

    Why? How? (click to expand)
    Why?
    • With latest changes, sitemaps allow to use quite powerful syntax for element's color or icon. Ex. 
      Switch item=tvPower icon=[==OFF="material:tv_off",material:live_tv] label="TV" iconcolor=[==ON="green"]  //.sitemap definition
    • At the same time, it is possible to define certain elements via .items file syntax. Ex. 
      Switch tvPower "TV" <material:tv_off> { channel="..." }   //.items definition

      or even

      Number:Dimensionless someOtherItem "Thermostat mode" <heating> { 
    channel="...",
    stateDescription="" [ options="0=AUTO,1=BOOST" ],
    commandDescription="" [ options="0=AUTO,1=BOOST" ],
    // widget=, listWidget=, ...
}
    • However, it seems impossible to encode these icon/colors conditionals into item definition and so: 
      Default item=tvPower //sample.sitemap

      displays differently than the sample above.
      This is not an issue when standalone, but makes it impossible to display a group of such items with precise control over each’s display.

    How?
    1. Allow the conditionals from icon/color to be expressed in .things file - either in the place icon is in today, or via metadata.

  7. Autogen/display configuration property keys for things

    Why? How? (click to expand)
    Why?
    • Textual configuration is no longer primary, but still used by some (myself included) and very well supported by core.
    • All of thing's static configuration properties can be defined via a .things file.
      However, the description of what can be configured by which property is input manually into each binding's README.
    • Some binding authors forget about it, and while a property is reachable, its name is undocumented and one needs to grep through binding source/definition XML to find out the name.
      For example, WLED binding offers a parameter called sortEffects but does not document it anywhere.
      One could argue it's a bug in the readme, but to be honest, duplicating definitions are always prone to such omissions and I get that some binding authors don't use text definitions at all, so it is unrealistic to assume they'll all be updating it by hand (I've seen numerous such examples in the past - WLED is merely the one I remembered, don't want to pick on that great binding!).
    • Main UI does display the property, of course so you know something can be configured. When set to default value though, the entry name (key in the parameter map) is not visible in the UI anywhere (or I am blind :))
    What?
    1. Have Main UI display the textual property key next to a property (or on hover, etc.), and/or...
    2. Change the CI/CD pipelines in such a way that these sections of READMEs are always auto-generated from XML (remove duplicate definitions, move textual descriptions straight into XML), or there's a linter/test ensuring all config knobs defined in things metadata are present in the README.

  8. Graalpython / Python3 support

    Why? How? (click to expand)
    • Pretty self-explanatory, I bet (and well discussed here before).
That'd be it for my (heavily opinionated) list of ideas for christmas gifts :christmas_tree:. I know Santa may not like any of them :grinning:, which is why I get by with set of rules in the overlay today. Would like to see what you guys think on this direction for the OH engine however, so feel free to throw darts at them :dart:

Some of these may be quite heavy, so I’m happy to move them to separate threads if there would be any interest of a follow-up discussion. Cheers!

//EDIT: Added no. 8

3 Likes