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

[Anpro (Andreas Probst)]

But surely there is some double, some are already quite old - some certainly still in the clock state from 2018 when I started with zero experience.

As always a prioritization and time problem - time and desire to come over and help - alternatively, I can send you the VPN access

For new rules I already rely on Copilot to have less dublicates.

But for example I got at least 100 of those two:

rule "batteriewarnung-62"
//Batteriewarnung KiZi 2 TM
when
   Item TM_KiZi_2_NiedrigerBatteriestatus changed to ON
then
    sendNotification("xxx@icloud.com", "🔋 Die Batterie im Thermometer im KiZi 2 ist leer (Zwei AAA-Batterien).", "battery", "Battery Tag", "Da Hoam", "KiZi_2-bat-id-5", null, null, null, null, null)
    sendNotification("xxx@gmx.de", "🔋 Die Batterie im Thermometer im KiZi 2 ist leer (Zwei AAA-Batterien).", "battery", "Battery Tag", "Da Hoam", "KiZi_2-bat-id-5", null, null, null, null, null)
end

rule "batteriewarnung-63"
//Batteriewarnung Bewegungsmelder vor EZ
when
   Item BW_EG_vEZ_Batterie changed
then
    if (BW_EG_vEZ_Batterie.state instanceof Number && (BW_EG_vEZ_Batterie.state as Number) < 10) {
        sendNotification("xxx@icloud.com", "🔋 Die Batterie im Bewegungsmelder vorm Esszimmer ist leer (Eine CR2450-Batterie).", "battery", "Battery Tag", "Da Hoam", "Treppenhaus-bat-id-2", null, null, null, null, null)
        sendNotification("xxx@gmx.de", "🔋 Die Batterie im Bewegungsmelder vorm Esszimmer ist leer (Eine CR2450-Batterie).", "battery", "Battery Tag", "Da Hoam", "Treppenhaus-bat-id-2", null, null, null, null, null)
    }
end

or those for my motion sensors:

rule "eingang_treppenhaus-2"
//Motiontimer aus falls waehrend Laufzeit der Bewegungsmelder wieder angeht
when
  Item BW_TH_vWZ changed
then	
    if (motion_timer_one !== null && BW_TH_vWZ.state==ON) {
      motion_timer_one.cancel
      motion_timer_one = null //Abbruch Timer
    }
    else if(BW_TH_vWZ.state!=ON && Lampe_Treppenhaus_WZ_Schalter.state==ON) {
    motion_timer_one = createTimer(now.plusMinutes(2), [| 
            motion_timer_one = null
            Lampe_Treppenhaus_WZ_Schalter.sendCommand(OFF)
            ])
    }
end

or those for every room:

rule "buero-8"
//Heizung Buero wenn Buerofenster offen/geschlossen
when
    Item Buerofenster changed 
then 
if (Buerofenster.state== ON && Allgemeine_Heizungssteuerung.state != '3' && Heizkoerper_Buero_BoostMode.state==ON){
    Heizkoerper_Buero_BoostMode.sendCommand(OFF)
    Buero_Temperatur.postUpdate(Heizkoerper_Buero_SetTemperature.state)
    Heizkoerper_Buero_SetTemperature.sendCommand((Window_open_Temp.state as Number).floatValue)
   }   
else if (Buerofenster.state== ON && Allgemeine_Heizungssteuerung.state != '3' && Heizkoerper_Buero_BoostMode.state!=ON){
    Buero_Temperatur.postUpdate(Heizkoerper_Buero_SetTemperature.state)
    Heizkoerper_Buero_SetTemperature.sendCommand((Window_open_Temp.state as Number).floatValue)
   }   
else if (Buerofenster.state== OFF && Allgemeine_Heizungssteuerung.state != '3'){
	Heizkoerper_Buero_SetTemperature.sendCommand((Buero_Temperatur.state as Number).floatValue)
   }
end

and so on and on…
very much potential to optimize, but lack of time and the bigger problem the WAF - everytime something does not work as expected it drops and makes future purchases harder

[codefox (David Tucker)]

That only works for thermostats that are native to Resideo. Honeywell has a second (older) app called Total Comfort Connect. It also provides an API but there is not a binding for it currently.

I actually really like the thermostats I have so I won’t swap them unless the app ever gets shuttered. But maybe I’ll try to write a binding for 5.0.

[hmerk (Hans-Jörg Merk)]

@Anpro

But for example I got at least 100 of those two:

There indeed is a lot room for improvement.
You could group those items and work with triggeringItem on group changes. The are some good posts around that topic….

[mpuff (Martin Puff)]

File Explorer and editor to edit all files like item files, sitemap, things and so on from the config folder from the gui

[rlkoshak (Rich Koshak)]

@Anpro

Sorry for the question, does this mean that DSL rules will continue to be supported as before or do you think here I have to prepare for breaking changes.

I’m not requesting the removal of Rules DSL. I just want to see it become an add-on instead of part of core. But it’s just a wish. Not a prediction or something that will happen without a volunteer to do the work.

@Anpro

Second question so far I only use 100% test-based DSL rules, if I want to continue to stay with text-based which language would be your recommendation to gradually switch.

They are all good. JS and jRuby probably have the most people on the forum if you run into trouble and need help. But your existing Rules DSL will continue to work too. If I get my wish the only thing that would change is you’d have to install an add-on first.

@Anpro

Oh, I’m very happy about that - I easily have over 1000 rules - that would have been a lot of work to rewrite.

I also do not recommend rewriting what you have. But I do recommend for new development considering the other options.

@Anpro

But the other question for future rules what is a permanent alternative to DSL here?

Nothing in this world is “permanent”. But I don’t see any of the currently offered options going away. And there’s a new kid on the block undergoing testing with the GraalVM Python add-on on the marketplace which will add Python 3 support. Except for JRule and HABApp, all the rules add-ons options are a part of the main OH project so even if a maintainer quits we have the ability to pick up the project and continue supporting it. Any one of them is a safe option. But again, Rules DSL isn’t going anywhere either. It’s just the worst choice among the available options now instead of the best one. in terms of completeness, ease of use, and features.

@Anpro

For new rules I already rely on Copilot to have less dublicates.

Copilot might find it a little easier to deal with a well known language as opposed to a niche custom language. Given the right prompt that is.

@Anpro

But for example I got at least 100 of those two:

Assuming you stuck with Rules DSL an example of what @hmerk suggests…

rule "Battery status"
when
    Member of Batteries changed
then
    if(triggeringItem.state instanceof Number && (triggeringItem.state as Number) < 10) {
        sendNotification("xxx@icloud.com", "🔋 Die Batterie im Bewegungsmelder vorm Esszimmer ist leer (Eine CR2450-Batterie).", "battery", "Battery Tag", "Da Hoam", "Treppenhaus-bat-id-2", null, null, null, null, null)
        sendNotification("xxx@gmx.de", "🔋 Die Batterie im Bewegungsmelder vorm Esszimmer ist leer (Eine CR2450-Batterie).", "battery", "Battery Tag", "Da Hoam", "Treppenhaus-bat-id-2", null, null, null, null, null) // I don't speak German but use triggeringItem.label to get a nice friendly name for the Item to use in your notifications.
    }
   else if(newState == ON) {
    sendNotification("xxx@icloud.com", "🔋 Die Batterie im Thermometer im KiZi 2 ist leer (Zwei AAA-Batterien).", "battery", "Battery Tag", "Da Hoam", "KiZi_2-bat-id-5", null, null, null, null, null)
    sendNotification("xxx@gmx.de", "🔋 Die Batterie im Thermometer im KiZi 2 ist leer (Zwei AAA-Batterien).", "battery", "Battery Tag", "Da Hoam", "KiZi_2-bat-id-5", null, null, null, null, null) // again, use triggeringItem.label to create your notification message
    }
end

That one rule will handle all of your battery Items.

In JS using rule builder this could look like the following:

rules.when().memberOf("Batteries").changed()
     .then(event => {
       if(items[event.itemName].numericState !== null) {
           actions.notificationBuilder("🔋 Die Batterie "+ items[event.itemName] + " ist leer (Zwei AAA-Batterien).")
                  .addUserId('xxx@icloud.com, xxx@gmx.de')
                  .withTitle('Da Hoam')
                  .send(); // see https://www.openhab.org/addons/automation/jsscripting/#cloud-notification-actions for details on how to use notificationBuilder
       }
       else if(items[event.itemName].state == "ON") {
           actions.notificationBuilder("🔋 Die Batterie "+ items[event.itemName] + " ist leer (Zwei AAA-Batterien).")
                  .addUserId('xxx@icloud.com, xxx@gmx.de')
                  .withTitle('Da Hoam')
                  .send(); // see https://www.openhab.org/addons/automation/jsscripting/#cloud-notification-actions for details on how to use notificationBuilder         
       }
     })
    .build("Battery Low Notification", "Sends a notification to the icloud and gmx emails when a battery gets below 10 or ON", ["batteries"], "batteryAlert");

Notice how we can send the message to both emails with just the one call using notificationBuilder.

Notice how we can set the description, tags, and UID for the rule, not just the rule name (second, third and forth arguments to build().

You could also use tags and/or metadata on the Item for information needed to construct the message on a per-battery basis. For example you can have metadata on the Items that indicate what sort of battery they take to include in the alerting message.

Of the above, only Item tags are supported by Rules DSL.

[mjcumming (Michael Cumming)]

I have the older versions as well and I wrote this python code to glue it to mqtt. GitHub - mjcumming/Somecomfort-Homie: Homie v3 for Honeywell Thermostats

[codefox (David Tucker)]

The code looks fairly straight forward. Do you think it would be difficult to create a binding with this as an example? Since I have it working using IFTTT, I don’t necessarily need this right now but if I could pull it into OH, that would be ideal.

[Anpro (Andreas Probst)]

Great to hear I don‘t have to rework all my rules. Of course I will try to rework them from time to time.
And for new ones I‘ll investigate into those other options.
Thx for your examples.

[Anpro (Andreas Probst)]

However, for now, I have a specific request for openHAB 5: Please make the main UI configurable via text-based files that can be edited using tools like VS Code, instead of solely relying on the web UI as it is currently.

[Lolodomo]

In case you are talking about configuring things, items, rules, … via text-based files, you can use the DSL syntax and edit your files with VS Code. It is there since the first version of openHAB.

[Anpro (Andreas Probst)]

No I really meant changing the main ui Pages via textbased files.
For me it makes the whole thing easier, if I exchange an item, for example, for different reasons, so that at the time of the basic ui I could simply use the vs code search function and knew at a glance where I used the item in the gui. Now I have to look up severall layout pages in the web ui.

But only a modest wish from an enthusiastic user

Or is there an easier way?

You also casually said that you can only edit rules according to the dsl syntax text-based - is this true? According to my understanding, you can use almost any form of syntax for rules based on text, except blocky, right?

[Oliver2 (Oliver)]

@Anpro

Or is there an easier way?

You could search in the corresponding jsondb file in which page that item appears from command line. If you are enthusiastic, you could also make a nice widget around that cli command.

[Lolodomo]

@Anpro

According to my understanding, you can use almost any form of syntax for rules based on text, except blocky, right?

Yes

[Anpro (Andreas Probst)]

Sorry still didn‘t get it - yes to only dls syntax or yes to rules can have any syntax in filebased config?

[Anpro (Andreas Probst)]

Ok I will try it but still hopping somebody investigates if it is possible to make Main ui textfile based.

[rlkoshak (Rich Koshak)]

@Anpro

Or is there an easier way?

There is also the developer sidebar which will let you search. It searches inside everything including UI widgets.

@Anpro

You also casually said that you can only edit rules according to the dsl syntax text-based - is this true

No, you can create script actions, script conditions, and transformations in the UI using Rules DSL.

@Anpro

According to my understanding, you can use almost any form of syntax for rules based on text, except blocky, right?

Yes, as of now that’s the case.

[Anpro (Andreas Probst)]

THX - now I got it.
And sorry for getting so off topic!

[c_r]

I think we should spent more focus on improving the UI capabilities if we want to be able to compete with other Open Source and Closed Source products. I still see many components with limited and/or inconsistent visual design or user interaction options - at the same time it is quite hard to either fix/change these issues (e.g. through CSS fixes) or build new custom components without the restrictions OH puts onto plain F7 components.

I had described more details in this post when I tried OH3:
https://community.openhab.org/t/oh3-ui-some-great-some-not-so-great-design-decisions-and-prioritizations/115165

Some details may have changed since then, but the more fundamental issues persist I believe.

[mstormi (Markus Storm)]

I disagree. We need not improve UI variability to convince more people or to ‘compete’ with whoever. Why should we be investing time right there?

What you’re asking for is even more control and even more complexity. If you have a specific idea of what you want to have your personal UI outcome look like and don’t manage to create it in OH that can be annoying. However, does that mean we really need more variability? Does that apply to a relevant number of users?
Note it’s not about small concrete requests for improvement. Post them here on the forum or open single feature requests for those on GitHub and if sound and pragmatically doable I’m sure you will be heard.
But variability improvement as a fundamental of your wish list is where I disagree as-fundamentally. Variability is boon and bane, it comes at great cost, and we must not be wasting our resources. And we’re very flexible already, particularly when you compare OH capabilities to other HA systems.

What we really need isn’t even more customizable widgets but rather the opposite:
more easy-to-deploy, predefined widgets and applications to select from. Of which there now are some. The marketplace has grown quite some in those 4 yrs since your last post, check it out.

Regarding docs and examples, sure there’s never enough of them or not written to match your expectations.
But they have improved A LOT since your other post, which was right after Main UI release.
You really should be checking back with the current official docs and rewrite your post rather than to simply restate it.

[Oliver2 (Oliver)]

Hi c_r,
absolutely correct.
There has been a small discussion on this topic and it has been agreed to collect ideas and to support these ideas with detailed information in a separate github ticket.

Please see here:

Examples of dashboards

I talked offline with @florian-h05 about your ideas. How about creating one github issue for each of these components? oh-page oh-grid-cells oh-cells oh cell expanded card oh-button oh-list miscellaneous (of course this is too generic) I would recommend though, that for each of the ideas more details should be provided, so it is clear what and how this should be implemented (from a users and UI perspective)- From there individual topics can be discussed and pull request could then be deriv…

and here:
https://github.com/openhab/openhab-webui/issues/3037

There are more tickets to come. Each of them focussing on separate GUI components.