Roadmap to Happiness - What is missing in the core framework

[opus (Jürgen Baginski)]

@travellingkiwi
That sounds correct. I recall reading that the openHAB version of rrd4j is (or was) not compatible with the rrdtool. However I can’t find that spot again.

[mstormi (Markus Storm)]

@rlkoshak

Thank’s for the video link! Are there any others from the recent meet up in Germany? I must have missed the announcement if they were previously announced.

Here:

Join us at the Smart Home Day 2018 in Ludwigsburg on Oct 21!

For all the ones who couldn’t make it to Ludwigsburg today, you might like that fact that the recordings of the talks are uploaded while the event is still running - check out our YouTube playlist or media.ccc.de! Enjoy

[SteveDowling]

I’d like global functions that can be called from any rule or a way to include a file with a lambda in a rule file. Lambda’s work pretty well for me at the moment but they force me to include everything that uses them in the same rule file and I’d like to break out my rule files in a different way.

[5iver (Scott Rushworth)]

@SteveDowling

I’d like global functions that can be called from any rule or a way to include a file with a lambda in a rule file. Lambda’s work pretty well for me at the moment but they force me to include everything that uses them in the same rule file and I’d like to break out my rule files in a different way.

This functionality that has already been included in the new rule engine.

[SteveDowling]

Ah, so I need to change my existing rules? I must have missed that, sorry.

[rlkoshak (Rich Koshak)]

@SteveDowling

I’d like global functions that can be called from any rule or a way to include a file with a lambda in a rule file. Lambda’s work pretty well for me at the moment but they force me to include everything that uses them in the same rule file and I’d like to break out my rule files in a different way.

There are currently several approaches to solve this.

1. Use Design Pattern: Separation of Behaviors to have a Rule “call” another Rule. This is great for cross cutting concerns like sending alerts that get called from all over the home automation.

2. Use Scripts like discussed in A simple scene management: finally a good use of scripts. This is less generically useful because of limitations in Scripts (can’t pass in arguments or receive a return value) but can be useful in some situations.

3. Organize your Rules according to function, not location or some other organization approach. If you put all your lighting Rules in the same file, there is less chance that it will need to call a lambda defined outside of the same .rules file. And if it does, see 1.

4. Write Rules in a more generic way taking advantage of Member of triggers, triggeringItem implicit variable, and Design Pattern: Associated Items. When all the processing takes place in one Rule there is no need for lambdas in the first place.

If you apply all 4 of the above I think you will find that this particular problem will go away.

@SteveDowling

Ah, so I need to change my existing rules? I must have missed that, sorry.

So the new Rule Engine does all Rules to call each other directly. But I can’t recommend moving to the new Rule engine just yet until some more documentation gets written.

But the larger point is we will be unlikely to see any new major additions to the capabilities of Rules DSL. Eventually (soon?) there will be a way to convert Rules DSL Rules to the new Rules Engine and the old Rules Engine will be deprecated.

I’m starting to gather the information to document the new Rules Engine at: Experimental Next-Gen Rules Engine Documentation 1 of : Introduction

It’s more just random notes at the moment but I intend to build it into a first draft for the docs that will go into the official docs. So stay tuned.

[5iver (Scott Rushworth)]

@SteveDowling

Ah, so I need to change my existing rules? I must have missed that, sorry.

Here are a few more useful links for the new rule engine, which besides the ability to create rules in Paper UI, allows for JSR223 scripting…

Next-Gen Rules

JSR223 Scripting

JSR223-Jython
https://github.com/OH-Jython-Scripters

Simplified Jython rule definition (similar to Rules DSL) using a universal decorator

I’ve pushed a major update to the openhab-scripters repo, with a number of changes to the openhab.triggers module, openhab.rules module, and updated the documentation. The biggest changes are a new rule decorator and a single unified trigger decorator that will work for (almost) all of the triggers available in the Rules DSL, and the trigger definitions should look familiar… from openhab.rules import rule from openhab.triggers import when @rule("This is the name of a test rule") @when("Item Te…

JSR223-Javascript

GitHub - lewie/openhab2-javascript: JSR223 JavaScript Code openHAB 2.x...

openhab2_pub_001/automation/jsr223 at master · illnesse/openhab2_pub_001

You’ll also find some more JSR223 related links and discussion in the forum under the tag jsr223.

[mhilbush (Mark)]

@rlkoshak

I’m hesitant to request this as at best if masks a problem in people’s configurations. Five should be enough, but for some power users it seems not to be.

And 2 is definitely not enough for the Quartz thread pool. Especially with the natural human propensity to schedule events to happen at midnight or on the hour.

Very simple changes but I don’t know the overall implication.

Even better would be a pool that grows to some maximum and then starts logging errors when we get to the maximum.

At a minimum, it would be nice to get some logs stating that we have X rules awaiting an execution thread. Right now it kind of fails silently.

This for sure.

And, it would be really nice to be able to see and set the thread pool sizes in Paper UI.

[dotorg (G H)]

Having used quite a few commercial ($, and $$$) automation systems, and some OSS ones, there are three big things that have stuck out… especially where use by people who are not extremely technical are concerned:

• Instability and inconsistency in the common interface bindings, Z-wave being the worst offender. Its not a core OpenHAB issue, but the need to run non-standard builds for typical things like security bindings in Z-wave. It makes it hard to keep up to date on anything because you just never know what is supported where, if your entire install is going to blow up, etc. This is, IMO, the #1 issue I’ve had, and I’ve heard from others, where switching to OpenHAB is concerned. Its one thing for ESH to say “hey, we’re the framework, that’s a binding thing”, but OH needs to work – and work properly, out of the box, every single time – with the big two or three automation standards. With that and simple-to-install systems like OpenHABIAN would make OH the automatic choice for people who want more capability than Smartthings or Vera can provide.
• One UI. This is an issue that really hurt Linux as an OSS solution on the desktop for most of the 90’s and naughties – too many desktops, too many ways to do things. Its a huge issue for OH that you need to use Paper for some things, Habmin for others, BasicUI for yet more. Nevermind the confusion over which scripting engine is best to use, or NodeRED, etc… Like the last bullet, lacking this OH will never be the choice of people who want their automation to just work, and it’ll be stuck as a “this is my hobby and what I’m spending my free time on” sort of solution.
• Better state management for devices, and clearer association between things/channels/etc. This is really a core architectural “issue” in ESH, but causes a lot of non-developers confusion. People don’t think about channels, they think about things. A non-developer doesn’t think “when the power status of this channel
  associated with this light changes and the value is ON, do this other thing”. They think “when the light turns on, do this other thing”. Every other automation system treats things as a more concrete concept.

In terms, though, of smaller things that really should be in the framework and probably could be, the most useful thing for me would be a simple way for implementing the “when something has been happening for x amount of time, do y” or the inverse “when something hasn’t been happening for x amount of time, do y” pattern. There’s a lot of manual-intensive ways of doing it in scripting, but that’s a core eventing capability in pretty much every other system, and one of the most common one people use. (“My door has been unlocked for ten minutes, lock it”, and things like that) There are so many things ESH/OH make vastly better than other products in the space, but that one is just a head scratcher every single time I have to do it. You almost want automatic sub-channels associated with channels where you can consistently and quickly see the time the channel last updated or elapsed time since that update, so you don’t have to write a bunch of code to set timers, reset timers, check timer values, etc …

[chris (Chris Jackson)]

@dotorg

the need to run non-standard builds for typical things like security bindings in Z-wave.

This is no longer the case - this was merged a month or more ago and there is only a single binding.

[rlkoshak (Rich Koshak)]

@dotorg

Instability and inconsistency in the common interface bindings, Z-wave being the worst offender. Its not a core OpenHAB issue, but the need to run non-standard builds for typical things like security bindings in Z-wave. It makes it hard to keep up to date on anything because you just never know what is supported where, if your entire install is going to blow up, etc. This is, IMO, the #1 issue I’ve had, and I’ve heard from others, where switching to OpenHAB is concerned. Its one thing for ESH to say “hey, we’re the framework, that’s a binding thing”, but OH needs to work – and work properly, out of the box, every single time – with the big two or three automation standards. With that and simple-to-install systems like OpenHABIAN would make OH the automatic choice for people who want more capability than Smartthings or Vera can provide.

One can counter with this that the non-standard build was an alfa test intended for testers to exercise the new features in the binding. In the commercial world there simply would not have been and still would not be any support for security until OH 2.4 gets released. What you are describing is not standard operating procedure for typical OH users. It was intended for the alpha and beta testers. The only reason so many people who are not necessarily testers went down that path is because many people would not or could not wait for the fully tested and merged in version became available.

@dotorg

One UI. This is an issue that really hurt Linux as an OSS solution on the desktop for most of the 90’s and naughties – too many desktops, too many ways to do things. Its a huge issue for OH that you need to use Paper for some things, Habmin for others, BasicUI for yet more. Nevermind the confusion over which scripting engine is best to use, or NodeRED, etc… Like the last bullet, lacking this OH will never be the choice of people who want their automation to just work, and it’ll be stuck as a “this is my hobby and what I’m spending my free time on” sort of solution.

Many on this forum, myself included, would argue there should be two UIs. One UI created for the users of the home automation and one UI created for the builders of the home automation. You don’t want to present a UI designed around managing Things and Items and bindings and such to your house guests.

But ultimately this is not something that OH can control short of shutting off the REST API entirely. Anyone can write any UI they want. It’s an open interface. And it’s an opensource issue. I don’t think you will ever see this addressed until and unless someone creates a commercial offering based on ESH.

OH is and always will be a more open and inclusive platform. And I think that is an important point for people to realize. OH is not intended to become some polished and unified commercial offering. The trademarks and licensing would prevent that. This is why there is an ESH in the first place. So from that perspective, OH is and always will be something more on the bleeding edge and more something used by enthusiasts and hobbiests. That is what it is here for.

@dotorg

Better state management for devices, and clearer association between things/channels/etc. This is really a core architectural “issue” in ESH, but causes a lot of non-developers confusion. People don’t think about channels, they think about things. A non-developer doesn’t think “when the power status of this channel
associated with this light changes and the value is ON, do this other thing”. They think “when the light turns on, do this other thing”. Every other automation system treats things as a more concrete concept.

You mean something like this?

@dotorg

In terms, though, of smaller things that really should be in the framework and probably could be, the most useful thing for me would be a simple way for implementing the “when something has been happening for x amount of time, do y” or the inverse “when something hasn’t been happening for x amount of time, do y” pattern. There’s a lot of manual-intensive ways of doing it in scripting, but that’s a core eventing capability in pretty much every other system, and one of the most common one people use.

Have you explored the Expire based binding? I’m not arguing against the idea (I like it), just offering less code intensive ways to do this now. See Design Pattern: Expire Binding Based Timers.

I’m still exploring the Experimental Rules Engine but I think this is something that might be doable with a minimum amount of code.

[dotorg (G H)]

Oh man, do I wish I could post some kind of animated emoji or something. But none would be sufficiently grand.

That’s awesome.

[David_Graeff]

@dotorg

In terms, though, of smaller things that really should be in the framework and probably could be, the most useful thing for me would be a simple way for implementing the “when something has been happening for x amount of time, do y” or the inverse “when something hasn’t been happening for x amount of time, do y” pattern. There’s a lot of manual-intensive ways of doing it in scripting, but that’s a core eventing capability in pretty much every other system, and one of the most common one people use. (“My door has been unlocked for ten minutes, lock it”, and things like that)

The new rule engine will have delayed execution. You would basically start a rule after the door triggered and execute another rule with a delay. The delay resets on every new trigger.

A counter is not yet implemented.

[begleysm (S)]

I’m fairly new to OpenHAB but what is making me consider moving away from the platform are the following 2 elements:

1.) Absolute URLs. Absolute URLs are making it difficult to run OpenHAB behind a ReverseProxy. I am having limited success working through this issue (with custom Rewrite Rules and research on some others who are having this problem) but it has been a pain in the butt so far. It is making it hard to use the website remotely and making it really hard to use the Android App remotely which is limiting the functionality of OpenHAB for me. As an example, software like MediaWiki works flawlessly from behind a ReverseProxy with a simple ReverseProxy redirect.

2.) Difficultly with AutoRefresh. For me, my SiteMaps don’t AutoRefresh reliably, which, again is making me consider checking out an alternate platform.

[mstormi (Markus Storm)]

Not sure what you’ve configured but I’m inclined to believe the problem is with your proxy setup and not OH.
A lot of people use OH with an nginx proxy, and it’s working well with both, browser and app access. openHABian even has an option to auto-setup nginx.

On 2) not sure what your problem is there, but usually it’s working well.
Now apart from the fact that that should not be a selection criterion for a platform, if it does not work for you, open a thread here and describe your setup and problem. You can also file a Github issue and usually it gets resolved within a reasonable amount of time (if it’s really a bug).
Either way, this is a bug at most so please don’t continue in this thread as this isn’t really a request to the core framework.

[begleysm (S)]

@mstormi thanks for the quick reply. I posted a bit prematurely, apparently, but I still don’t think I’m totally off base. Using this tutorial (Apache2 reverse-proxy with LDAP-authentication, HTTPS and URL-path-prefix) I was able to get my Reverse Proxy working (ironically in the 10 mins between my first post and this post). But you’ll notice these lines

                RewriteRule "/openhab/openhab/(.*)" "/openhab/$1" [R,L]

		RewriteRule "/openhab/?(.*)" "http://xxx.yyy.zzz:8080/$1" [P,L]

and these lines

                AddOutputFilterByType SUBSTITUTE text/html
		AddOutputFilterByType SUBSTITUTE text/css
		AddOutputFilterByType SUBSTITUTE application/javascript
		AddOutputFilterByType SUBSTITUTE application/json
		Substitute "s|/basicui/|/openhab/basicui/|n"
		Substitute "s|/rest/|/openhab/rest/|n"
		Substitute "s|'/rest'|'/openhab/rest'|n"
		Substitute "s|/paperui/|/openhab/paperui/|n"
		Substitute "s|/inbox/|/openhab/inbox/|n"
		Substitute "s|/icon/|/openhab/icon/|n"
		Substitute "s|http://|https://|n"
		
		Substitute "s|/habpanel/|/openhab/habpanel/|n"
		Substitute "s|/habmin/|/openhab/habmin/|n"
		
		Substitute "s|'/chart'|'/openhab/chart'|n"
		Substitute "s|'/start'|'/openhab/start'|n"

The need for the above types of rules seems, to me, like a shortcoming of the baseline design and not something that people should be expected to do on their own.

I’m still exploring the Auto Refresh problem but it is a problem I’m having right now. Again, perhaps premature but this doesn’t seem like the type of basic functionality that should have problems. Searches on the internet and OpenHAB’s bug tracker suggests that more than just me are having a problem with this (https://www.startpage.com/do/search?q=openhab+sitemap+doesn’t+refresh&rl=ow)

[KidSquid (The Squid)]

THING VERSION

If this is currently accessible, I have definitely missed it.

I’d like to see THINGS incorporate the BINDING version they are associated with. Sometimes when updating bindings you need to rediscover the THINGS. Sometimes I find duplicate things - things I may not have included at one time and left in the Inbox for one reason or another. It would be great if somewhere in the configuration screen there would be a display of the corresponding BINDING version it belongs to, so when it’s time to incorporate the THING i know which one to pick.

Squid

[Confectrician (Jerome Luckenbach)]

I would like to have the ability to give some more “design”-power to Items

The reason is explained basically here:

How to implement Setpoint in items

Hi, I am used the demo.items and demo.sitemap as a basis for my project. As shown in demo.sitemap it uses ‘Group’ to list the items under that group. sitemap demo label="Main Menu" { Frame { Group item=gFF label="First Floor" icon="firstfloor" Group item=gGF label="Ground Floor" icon="groundfloor" Group item=gC label="Cellar" icon="cellar" Group item=Garden icon="garden" } Group gFF "First Floor" <firstfloor> Group gGF "Ground Floor" <groundfloor> Group gC …

If one has a well designed Group structure, he/she can design a structured sitemap with only a few lines.
But it gets difficult, when you want some more than just the default item representation in your sitemap.

A good example for this is a temperature control with a setpoint-sitemap-type.
If i am fine with my group based sitemap and want to add control to my thermostat, if have no other chance than to write the group sitemap definition completely by hand.

It would be nice to have something like (just a rough concept idea):

Number MyThermostat "MyThermostat" {channel="my:heating", sitemap="setpoint:15:30:2"}
// 15 = minValue
// 30 = maxValue
// 2 = step

Which then would override the number peresentation with a setpoint presentation within my sitemap.

This would keep the Sitemap definition flat and you wouldn’t have to maintain the sitemap file, when something changes in the items that are connected through this group.

HabPanel, as suggested in the thread linked above,
can’t (and shouldn’t) be the only solution for things that are not possible with items/sitemaps currently.

[rlkoshak (Rich Koshak)]

@Confectrician

It would be nice to have something like (just a rough concept idea):

Number MyThermostat "MyThermostat" {channel="my:heating", sitemap="setpoint:15:30:2"}

I like the idea but really don’t like putting that config in the binding/channel link part of the Item definition.

Since we can define the icon and the label on the Item there really isn’t any good argument for consistency why we shouldn’t also be able to define the sitemap element that the Item should use by default so when we put it on the sitemap using Group or put it on the sitemap using Default we have a bit more control.

But, unfortunately, this would only be a partial solution because we still can’t control the order the Items appear on the sitemap.

[smhaller (Stefan M. Haller)]

I don’t agree with this:

@dotorg

One UI. This is an issue that really hurt Linux as an OSS solution on the desktop for most of the 90’s and naughties – too many desktops, too many ways to do things. Its a huge issue for OH that you need to use Paper for some things, Habmin for others, BasicUI for yet more

When I have a technical issue with something not running as expected it is in most cases not related to the UI itself. And I think the approach to have administrational stuff splited from the regular use interface is good and IMO the one and only (i.e. Joomla is doing the same).

I would be even very happy if the customizing of openHAB UI would be more easy. Currently it’s more a nightmare than simply done. Even with longtime experience in IT, unix, scripting aso.
I currently work on my LCARS based approach of an interface (if I find time), but I still don’t have a working environment that is far enough to say it’s an alpha. The design itself is more or less ready, but only using PHP and REST which is not the road that I would like to go.