+1 for reliable startup ordering.
@henning mentioned in his presentation he’s working on it or at least is planning to.
@mstormi, That is excellent news! Thank you for the report, Markus.
I wish you a speedy success, @henning.
He definitely didn’t say that - it is just one of the things we consider important to be implemented.
Henning is not working on it.
Good news is, I had some discussion today about a new feature in Apache Felix that should soon be implemented there and which will hopefully be an ideal basis for us to do a proper startup. The related issue in ESH is Introduce a "ESH start level" functionality · Issue #1896 · eclipse-archived/smarthome · GitHub.
2 Likes
Thanks for the clarification, @Kai. Regardless, I’m happy to know the issue isn’t dead (as well as now knowing where to monitor discussion and progress on the related ESH issue.)
I would like to see in the Addons/Bindings page of PaperUI that the version numbers of available and installed bindings show the full version number.
Currently the version shown is only the prefix, not the full version number. When working with snapshots and testing new features it would be nice to look at a GUI instead of querying the Karaf console for that information.
This method would also be a visual confirmation when attempting to upgrade a binding, you could confirm the version number change once you have uninstalled and reinstalled the binding.
An indicator of an updated version of the binding being available next to the version number would be a great addition as well.
1 Like
The Karaf Webconsole would not be in PaperUI, but a UI addon. I have it in my backlog to build this… I’m surprised nobody has done it yet. It is nice to have a UI for Karaf! You can adjust log levels, but the logging view appears to only have the event.log. But you can view a Karaf console in a browser, so there’s all the logging you’d like.
To install, modify /userdata/etc/org.ops4j.pax.url.mvn.cfg to include the Maven repo. Mine looks like this…
org.ops4j.pax.url.mvn.repositories= \
https://openhab.jfrog.io/openhab/online-repo-snapshot/2.4@id=openhab@snapshots, \
https://repo1.maven.org/maven2@id=maven.central.repo
Then feature:install webconsole in Karaf. More info here.
+1! To be more specific, System Notifications.
And another +1 for reliable startup.
My list:
- Update Thing definitions automatically when a binding is updated, rather than having to manually delete/rediscover Things to update the definitions.
- A generic UPnP binding, with separate addons for specific devices, as suggested here. The bulk of the Sonos binding would work for this. Here is the previous discussions about this, and an example project that is currently functional. Not so much core framework, but it makes sense to me that UPnP renderers would be auto-discovered as audiosinks.
1 Like
One more thing:
NESTED TRANSFORMATIONS in bindings please
2 Likes
Maybe a good backup plan?
Today I use the /usr/share/openhab2/runtime/bin/backup /backup/openhab2.zip.
But a GUI backup/export would be a nice feature?
And since today, these kind of servers start to be very important. Will be a nightmare if it crash today.
A kind of cluster configuration? Where you can run fe 2 servers in a clusters, just in case?
3 Likes
I am a fan of the rrd4j persistence as it is ( working for me). I’m using year charts (plural!) with no problem. What isn’t working for you?
This thread is on requests to the CORE framework.
Backup and HA (highly available) servers can be/need to be implemented well outside of this.
Btw, there’s openHABian to include Amanda.
I’m not sure about the backup topic in how far the core should be aware of it.
At the moment the way you would create a backup is to copy the user files, I guess?
If that is the case the core should be notified to synchronize in-memory values to files first.
Hi,
Here is my two cents:
-
The ability of sending command from an item to an item without a rule in the middle - As I am using proxies, it will be great as the rules is just one line that send the command.
-
Ability to set default values to items within the items definitions - I am using rules just for that.
-
Last update item - is an example where in a lot cases, I just define extra item as a companion item and write a rule just to set it. If the core has the ability to add such “pattern” items it will simplify things.
-
Namespaces - Items today are called Light_Ceiling_Living_Room , Light_Wall_Living_Room etc. If there was a way to use name space , e.g by prefixing items with the group name (by the core) I assume it will simplify names and give more flexibility
-
Rule priority - I don’t know how the rules ordering is done today, but I think adding priority is important.
I’m not 100% sure but I believe there’s no need for this.
Ideally yes, but I believe that to backup/restore latest jsondb is well sufficient (it syncs config changes to disk, I forgot the exact value but it was just a couple of seconds at most).
I think your wishes don’t translate into real requests to the core framework.
On 1) items never send commands to other items. If you use proxies you intentionally do so, and you WANT this to be initiated by a rule else you cannot properly control the exact conditions to apply.
You can also bind items to multiple bindings.
On 2) does not make sense. NULL is the default on OH startup, using rules is the right way to set a default.
For item states to survive restarts, persistence is the way to go.
On 3) you can use item.lastUpdate
On 4) you are absolutely free in defining names for things and items and that’s fine the way it is.
OH mustn’t mandate a namespace. Yes this might ease a beginner’s path towards a proper config, but that’s not the core framework’s job.
On 5) what do you want to prioritize ? If you want actions A, B and C to take place in that order on changes to item X then write a single rule to trigger on X and have it execute A before B before C.
Here are two more things that have been rolling around in my head, but I do not believe there are associated ESH issues for them (yet)…
-
For the Basic and Clasic UIs, it would be really nice to be able to use Item StateOptions, without having to link the Item to a Channel with a DynamicStateDescriptionProvider. A simple use case is to select from a list of radio stations… but to really be useful, you’d need the ability to update the list programmatically.
-
A user interface for viewing and editing Item metadata. I’m close to sitting down to build one, since I am using Item metadata in my JSR223 rules and would like an easy way to modify it. The REST API lets you add/remove metadata, but does not allow for reading it. The use of Item metadata has so many useful possibilities! I expect the lack of the ability to create/edit it in a UI is simply due to how new it is.
1 Like
I know that NULL is the default, but why not to have the ability to have different default? Writing a rule is overkill just for default values. If the item gets the value from persistence, the default value will not have any affect.
Then it’s not a default anymore.
There are plenty of examples on how to deal with Null values at start up. Changing it will only change the value not the process
Have you opened an issue on Github? It would be even more awesome if you indeed could supply a pull request to add this missing piece.
Yes please, but with grep like filtering. 
I’d be very interested in SSL certificates with the embedded MQTT broker.
Yes please.
This one is huge. I can’t tell you how much time I and others spend on this one issue on the forum. I just spent 10 minutes helping someone with this very issue. The big deal is rules start running before Items are done being loaded and restoreOnStartup causing havoc.
I think David’s comment means that GUI based Rules editing is already in work. We don’t need to open new issues for stuff that is already being worked. I don’t think anyone is saying that the ERE is done and usable yet. As you mentioned, the documentation isn’t there yet.
The ERE will make this very easy FWIW. You can do this right now with just a few clicks.
NOTE: depending on what you are using these for, there might be other options. I documented a few in Design Pattern: Encoding and Accessing Values in Rules
The problem with this is Groups, despite how many people use them, are not strictly hierarchical and Items can belong to any number of Groups. I’m not sure using a Group name would work in this context.
Rules are event driven and are processed fifo. An event occurs and Rules configured to trigger based on those events. And no two events ever really occur at the same time. And unless there is something wrong with your Rules there should always be a thread available to start processing the event.
Given this is how it works today, how would you define the priority and what would you do in all the various cases? For example, I have a Rule that is already running at a lower priority, do I kill it if a Rule at a higher priority comes in?
I’m not arguing against the idea, just trying to understand how it fits.
Then one would argue you need to make sure the events occur in the order you want them to run. Short of a complete rewrite for how pretty much all of ESH/OH works I don’t see how priority can come into it. Maybe instead of fifo a priority queue could be used to assign a Rule thread to an event, but unless you have long running Rules, which is a problem unto itself, there should be no wait. No wait, no priority.
From an architectural purity perspective I agree with you. However, I have helped many users over the years with use cases that became somewhat needlessly complex because of this.
I think the sticky point is if one wants to display the lastUpdate on the sitemap there is a need to create separate Items and Rules to populate those Items. I’m personally kind of meh about the idea since it is so easy to solve with Design Pattern: Associated Items but I do understand the annoyance.
My list:
Generic Transformation Service
Can I expand nested transformations to pulling transformations out of the bindings entirely into a generic transformation service? Why is it I can only use a transformation with certain bindings (e.g. HTTP, Exec, MQTT, etc) but not others (e.g. Zwave, Zigbee, etc)? Why are the bindings involved at all? I’d like to see a way to link a Channel to an Item and apply a transform to the Channel at the Item, not on the Thing.
For a relatively trivial use case, let’s say I have a bunch of Contact door sensors. Contact is the appropriate Item type for this type of sensor. But all the Zwave door sensors require the use of a Switch. Now I either need to create a bunch of proxy Items and Rules to convert the Switches to Contacts so I can now use a Group:Contact for all of them or I have to deal with a Group:Switch and Group:Contact and duplicate the logic.
For another simple use case, I sometimes want to use a Number Item to store the result from an Exec script, but the output channel only lets me store the result in a String. Maybe a generic transformation service would let us write transformations that frees us to use the appropriate Item type for our home automation model instead of what the binding developers decided was appropriate.
Higher Default Number of Rules Execution Threads, Dynamically Sized Pools, Error Logs When Threads Are All in Use
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.
Sitemap Widgets for Filling out DateTime Items
It’s pretty self explanatory but one just needs to look at the massive complexity and pain involved in all the Alarm Clock examples to see how nice this would be.
It would be nice if it handled full DateTime as well as just a Time.
This may not fit with the core framework but it is a prerequisite for…
Dynamic Scheduler
Related to the previous, a built in scheduler. Lots of people go to great lengths to be able to dynamically set up a schedule for things to happen at certain times on certain days of the week on a repeating basis. For now all we can do is rely on something like the CalDav binding, which doesn’t work well for a lot of users or the creation of dozens of Items and complicated ugly sitemaps.
This is a major weakness in OH right now.
What people need is a way to say from their sitemap/HABPanel “Send MyItem the ON command every weekday at 8:30am” and create a Rule that triggers when MyItem receives the ON command. The Scheduler is smart enough to interpret the Item’s state and schedule the events accordingly.
Maybe this belongs in it’s own binding, but I’m pretty sure there is a need for at least one new Item type to make this work which does impact the core.
Add/Edit Tags in PaperUI
This one is a real challenge for less technical users who want to use Alexa/Google Assistant/Hue Emulation.
Elimination of Contact or Creation of A Standard that Gets Enforced
Contacts are supposed to be used for sensors, Switches are supposed to be used for actuators. But this convention has not been followed by the binding developers. In fact, rarely do I see Contact used at all. While there will be much wailing and gnashing of teeth, I’d like to see either the binding developers follow the standard convention or the elimination of Contact as an Item type.
Status Update on the ERE
This probably doesn’t deserve a an issue and may not even belong here, but what’s the status of the ERE? I know simple Rules can be set up but it is hard to judge it’s maturity. Can we access Actions (I know executeCommandLine is not available yet based on a recent thread)? Logging? Timers?
I’m willing to take a shot at starting the documentation for it but don’t want to start unless it is nearing completeness.
I’m sure I’ll think of more in the shower tomorrow morning. 
Improve Performance of Rules DSL Parsing
There might not be much that can be done with this but users are reporting start up times of 10-40 minutes on RPi 3s due to Rules parsing. I suspect the main focus is on the ERE right now, but the Rules DSL will be around for a bit and we shouldn’t ignore this pain point.
3 Likes