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.
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
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.
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.
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.
This is a PaperUI, ClassicUI shortage and need to be reported as an issue, I strongly agree. There are so many basic widgets missing actually. Like Push Buttons and Multi-State Buttons.
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āve tried several formats and ways to define the script, mostly blind since I donāt know what is appropriate here but I always get something indicating that my JavaScript is completely malformed or it doesnāt know what executeCommandLine is. But based on the JSR223 Actions.js examples that line should work.
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
Thatās a great question thanks for asking! So here are just a few ideas for issues i have had:
Built in user authentication (Instead of using nginx proxy)
Built in SSL generation using Lets encrypt (Instead of manual generation) or manual addition using Paper UI (this would also solve the need for nginx)
Built in configurable proxy (give the ability to access things like camera images and video streams without opening individual ports for each camera on the router)
Built in Terminal client in Paper UI for CLI access instead of using third party tools
Built in DynDNS or other DDNS reporting (auto update dynamic dns)
Built in UPNP client to open router ports (auto open router port for access)
Separate log/register for device state changes (Instead of scrolling through miles of log files)
Tagging support in paper UI (instead of having to manually add them through the console, useful for Alexa integration )
Ability to trigger zwave inclusion and exclusion from sitemap items
Ability to have code generated sitemap items or dynamic drop down lists (Listing radio stations, songs, etc)
Ability to have multi-line sitemap items
Built-in GPS tracking and reporting in the mobile app (This might be a bit out of the core scope)
Built-in Text input fields in the mobile and basic UI (This might be a bit out of the core scope)
I know there was a couple more things that would be nice to see but I cannot remember them right now, so I hope this list helps.
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.
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.
