Roadmap to Happiness - What is missing in the core framework

Setup, Configuration and Use Runtime
, ,
41

It is not. Depending on the item, you may want to reset it to default or keep the persisted value, so you need a rule in any case. You can deploy a single rule to trigger on ‘System started’ to set all default values in one go, and unlike with a simple item property, you can even apply conditions here.
I’d even go further and say that the ability to set it via config will result in a number of issues where people set defaults and forget about when programming their rules. From someone’s point of view to spend a lot of time on supporting other people debug their rules I’d therefore even vote against having this.
Yes the need to check for NULL is annoying but that’s integral part of proper programming anyway, and the main root problem is the unreliable startup order so rules sometimes get processed while items aren’t available yet. But that issue already is on the list.

Either way, this thread is meant to consolidate needs that several people have in the core framework so developers know what they should focus upon, and my point was that none of your points require any changes to the core but can be solved differently without too much hassle really.

42

On Smart Home Day, @henning reported plans to replace the current scheduler.
I agree it would be great to also allow for user-provided scheduled actions/rules to be managed by the framework, maybe there’s a chance to combine this ?

@kai stated that essentially ESH automation engine is to replace the ‘old’ engine in the foreseeable future (here’s the recording).
But I think there’s still many details that need to be sorted out.

43

I like this point. An automatically updated list of running timers (more than 2 seconds timeout time) would be amazing.

44

As an end user of Openhab, the one thing I would really like to see improved is the App functionality and the ability to do most things that PaperUI and Habmin can do but with greater ease through your phone or tablets Apps.

Currently, to add or exclude zwave devices, enable/disable bindings, and so forth requires a web browser to do those various things. I would really like to see back-end administration functionality added to the Apps. The ability o restart your System via the APPwithout needing rules, and so forth.

Just think about multi-user supports. If/when that gets added. Would I need to add users and permissions via logging in via a web browser?

One other item is the ability to both Upgrade and possibly downgrade your OH2 Version via a GUI and/or thru an app. Currently this can sort of be done with some rules and dummy switches, but a built it upgrade option would be highly desirable.

45

Sorry to be a bit unfriendly here but I think you quite misunderstood the way OH is composed and built.
PaperUI/habmin and BasicUI/HABpanel/ClassicUI are intentionally separated as they serve different purposes. PaperUI/habmin is for administrative tasks only such as to add devices.
These are more or less one-time (or few-times) tasks. This functionality isn’t needed by and not meant to be accessible to end users, so there won’t be any apps to duplicate this. Stick with using the browser.

On upgrades, there’s another (intentional) separation/layering. The OH core is built to run on top of Java but it doesn’t include all the functionality OS, Java and external helper apps such as mosquitto provide.
The upgrade process in turn is highly OS specific and as such out of scope for the OH core framework.
If that’s what you’re looking for, have a look at openHABian or any of the commercial appliance type solutions built on top of Eclipse Smart Home.

46

Not unfriendly at all :slight_smile: And perhaps I misled by saying ‘enduser’, and by that I meant someone like myself who is not a developer, but runs their own OH2 system at home and is familiar with the setup, installing from scratch on a linux or other OS machine, setting up mosquitto, etc.

And by enduser, I was more implying the ‘administrator’ of the system. The person who may be adding devices, enabling new bindings, etc, giving mult-users rights and permissions, etc… I think Zwave may be a good example. You add a new sensor, switch or something. But then need to go a web browser to add this device into your zwave network. Yes, all controllers and hardware different, and I understand that as well.

Having an ‘admin’ account with PaperUI and other access from your Phone or Tablet and not needing a web browser I think would make OH2 more user friendly to the the novice in setting things up. This sort of goes along with the multi user and permissions request. Just adding on to request that the Admin or Super Admin of OH2 should be able to do things without needing to go a web browser. Many of today’s younger generation do everything off their phones and tablets with various apps, and very little actual web browser stuff.

Perhaps this not a core framework item, but is something I think many would like to see.

On a final note, I could one day foresee the Road to Happiness following a similar path of XBMC/Kodi. What started out very small now has various 3rd party vendors selling prebuilt Kodi boxes. Similarly one day to see 3rd parties selling prebuilt OH2 boxes with the main zwave, zigbee, Bluetooth, wifi sensors and a preconfigured OH install.

47

Not really, it would just be another frontend to the same API, without any added benefit.
You (the user) would still need to understand the meaning of all the settings - and there are so many more than are in Kodi.

What you probably mean is to turn all of OH into an appliance, so it’s rather the following you want:

I don’t, this is illusive. OH is so much more complex and flexible than Kodi is, effectively exponentiating the efforts of turning openHABian or even openHAB itself into an appliance.
For reference as there’s apparently a larger number of people to totally underestimate the efforts involved:
this has been discussed e.g. here.

48

@opus

Export (Dump) and Import. So you can prune the obviously bad entries in the RRD…

49

I must have misunderstood or more likely miss remembered. I wish I could find the thread, it was actually a pretty good one.

I’ll start being a nuisance then. :wink:

It’s kind of minor, but I’ve dealt with several users who, for example, keep trying to toggle the Switches from the Network binding and are confused when nothing happens.

There are three approaches to solve this problem documented in Design Pattern: Manual Trigger Detection.

Either I’m misunderstanding or there already is. events.log only has Item and Thing state changes.

:+1:

I think this would need to be implemented on the Zwave binding and exposed as a Channel.

I believe there is already an issue open for this on the Android app repo. It has been much requested but you are correct, it isn’t really part of the core framework.

See Show Remaining Time of a Timer - #2 by rlkoshak for a way to do this in Rules.

It’s the details that I’m looking for. When ever I try to do anything more than logging from an PaperUI defined Rules I get ClassNotFoundExceptions. I’m mainly looking to know when there is enough there that it becomes a viable replacement for Rules DSL so we can start the documentation efforts.

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.

Perhaps it is worth pursuing making PaperUI a bit more mobile friendly and or making a PaperUI App. Personally I already find PaperUI to be quite mobile friendly but perhaps I’m missing some pain point. @ptmuldoon, what is it about the web browser interface that causes problems for you? On Android at least, you can even “Add to Home Screen” your PaperUI and it will have it’s own icon and pop-up like an app when you tap it.

I completely agree though, managing user permissions, and all the other tasks mentioned are administration tasks and do not belong in the openHAB Phone apps themselves.

We are already starting down that path a little bit. Archived Projects | The Eclipse Foundation

Note, one of the reasons that ESH was split out from OH was to give 3rd party vendors a basis to enable this sort of thing.

50

@travellingkiwi
Changing entries in the database is a problem!
This database by design can have several “archives”, with each archive covering a different timespam starting with the actual time. Entries in archives covering longer timeframes are calculated by several minute-wise entries.
A later change of such an entry would require to restart that calculation, however it would require that all needed data of those other entries is still held. But that is, by design, not the case.
In other words, the later change of entries in a rrd4j database is (IMHO) is not possible.
Note: I am a fan of rrd4j , but not a developer of it. So I migth be wrong here.

51

I understand that, and I am using the third approach from that very post well enough but if there were a native way to detect the source in rules I could eliminate having so many duplicate proxy items or engineering a different workaround for functionality that should be native to the system. For example:

if (item.receivedCommand.source == BINDING) {
 // our command was a manual request
}
else if (item.receivedCommand.source == API) {
// our command was received over API, so some sort of UI
}
else if (item.receivedCommand.source == ESH) {
// our command was internal to the ESH runtime, so a rule
}

is a much more elegant solution than having to have to keep track of five proxy items manually or hacking something together with timers or tons of groups or some other manual approach and less prone to error.

52

I’m not arguing against the request. I’m just presenting approaches that future readers of this thread can use until it does get implemented as part of the core. I just don’t want people to think that the requested feature is simply impossible.

53

@opus
Assuming that RRD4j follows the same basic tenants as RRDTool for generating RRD’s then it doesn’t need to re-calculate the results if you change the data. Data should only require re-calculation at rollover.

1 Like
54

Ah, understood. Good point.

55

@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.

56

Here:

1 Like
57

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.

1 Like
58

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

59

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

60

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.

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.

2 Likes