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 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.
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.
I’d be very interested in SSL certificates with the embedded MQTT broker.
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.
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.
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…
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.
No, not yet, but I plan to… unless someone else gets to it first!
Yes, it would, but very unlikely . I’ve done some other simple pages that used the REST API, so I figured I’d throw one together in the interim, if making changes without a UI bugged me enough… but without the ability to read metadata through the REST API, I don’t believe this would be possible. I don’t have the ESH knowledge to develop the Paper UI, and there would be deeper work needed to be done first. With the recent work in Semantic Tagging, I also expect there isn’t a very firm codebase to work on. I think this is one that would need @Kai’s lead, if he doesn’t kibosh it all together.
Rich also mentioned editting Tags in a UI, which is closely related to this.
2018-10-23 15:51:04.416 [ERROR] [internal.handler.ScriptActionHandler] - Script execution failed: ReferenceError: "executeCommandLine" is not defined in <eval> at line number 1
I know there is some overlap between the ERE and JSR223 but they clearly are not the same and features that are available in JSR223 are not in native ERE. And since the vast majority of ERE users will be writing the scripts like the above that is what I’m looking for status on.
Jython and Groovy are not options under “the scripting language used”.
tl;dr, just because it works in JSR223 doesn’t mean it works in ERE, yet.
I don’t remember disagreeing with this ;). I don’t mind people opening up multiple reports unless they are clearly linked and we’re trying to solve a specific issue. One thing I do dislike is people assuming that two issues are the same when often they aren’t…
I have one: The ability to tell if a device was changed from outside of openHAB (for example a user manually turned on a light) or from within such as a rule. Even something as simple as the triggering source property being either something like “system” or “binding” would be useful I think.
Id like to see the Private cloud of Openhab Cloud being intergrated, ie a component fully installed as part of the install. You either select internal or external. Not that the external cloud is unreliable but I prefer all on premise
Echo the remote access restrictions, there needs to be more granular control over security for other users as Vincent as mentioned. Allowing certain users to see/do certain things would be great
Graphical interface of the debug system with the ability to easy filter based on binding etc