Please let us know the sound basis for imposing an extra step on users in order to maintain backward compatibility, as only capricious reasons come to mind absent your explanation. Thanks.
Xtend has cause copious problems with maintaining, updating and continuing development of OH core.
For most of OH 3 it was a major source of performance issues due to a bug upstream which could not be fixed nor avoided because it’s part of core.
On the other side of the coin, keeping up with the latest version of Xtend is also difficult because it’s part of core meaning that it can take months or years for updates to make their way into OH. As an add-on this isn’t as hard because the changes are limited to the add-on, not all of core.
Some issues and discussions over on the Xtend repo forecast that Xtend development may come to an end.
Beyond that, Rules DSL’ implementation of the OH API is incomplete:
- lacks access to Item metadata
- lacks ability to call another rule
- lacks ability to create a rule inside a rule
- lacks ability to be called from another rule
- has no access to the ThingRegistry
- only has access to the ItemRegistry if you import it in a unusual way
As a programming language it is incomplete lacking:
- true functions
- classes
- libraries
And as a programming language it has a broken type system. For example this will fail: myNumberVariable + " some string" but this will succeed "some string" + myNumberVariable. It tries to be typeless and punishes you if you try to force the type all the time with huge load and parsing times. And even then, if you define a variable as one type and then assign it something else later, it ignores the original type and happily accepts the new. For example:
var Number foo = 7
foo = "seven" // no error *most* of the time, foo is now a String
On top of that, it completely fails to detect the type in some situations because it never looks down the type hierarchy, only up. That’s why you have to constantly cast the state of Items like MyNumberItem.state as Number in order to do anything with them beyond what State offers.
Because it’s a custom DSL and niche, the use of AI to help code rules is always going to work less well than the other options.
Of all the options available today in openHAB, Rules DSL is the least good option (this wasn’t always the case and I was an advocate for Rules DSL for many years). It’s not easier to use in any way and its flaws make it significantly more difficult to use in many ways. It should not be given a place of privilege by keeping it a part of core where it will continue to hinder development of core. New users should be discouraged from using it when getting started.
Rules DSL is no longer fit for purpose. If I were to be “capricious” I’d say Rules DSL should be eliminated entirely. But I won’t go that far.
It’s not necessarily an extra step. I would advocate for the upgradeTool to notice if there are any Rules DSL rules in place and install the add-on automatically as part of the upgrade process.
But this is just my opinion, and I’m not going to be the developer to submit the PR that does it so 
. It didn’t happen for OH 4 when this idea first came up. I see no reason it will happen for OH 5 either.
Thanks for the lengthy reply. I have a different view, where the idea of “place of privilege” is not valuable from a product management perspective, and if DSL rules ossify in subsequent releases due to language flaws or no further updates, so be it, as it presents no actual problem compared to the predictable outcome where it’s broken off into an add-on, no one maintains the add-on, it stops working in a new openHAB release, and now you’ve well and truly broken compatibility with users’ investment in their DSL rules. Stranding those users by the back door by moving the functionality into an inevitably unmaintained add-on feels more like dirty pool.
I’d rather not see more users abandon openHAB for alternatives, and breaking off aging components to enable their ultimate abandonment, just because newer, slicker alternatives are now possible, only puts a bad taste in users’ mouths. IMHO.
If there truly is no one interested in maintaining the capability, then it’s already dead. Keeping it a part of core doesn’t change anything except make it disappear more suddenly when the core maintainers get tired of dragging it along. The core maintainers have already shown a disinterest in keeping it up and it’s already ossifying even as a part of core.
IMO it has more likelihood of being kept up and maintained into the future as an add-on. Especially if one or two developers decide they really want to take it over and keep it up. It’s easier to work and get PRs approved in add-ons than core.
And even as an unmaintained add-on it can last a good long time. The Jython add-on basically had no-one maintaining it for about four years (between OH 3.0 release and OH 4.2) and it never stopped working. Breaking changes were fixed to keep it working (at least to the add-on).
As I see it, Rules DSL will have an extended life as an add-on (with the Jython add-on as evidence that it would) and that’s one reason why I want to move it to become one. I know lots of users have a lot invested in Rules DSL rules. But I also do not want any new users using it.
It’s important for new users to have an understanding that core maintainers can easily become bored of components relied on since 1.0, and exert just enough effort to drop those previously core features at their whim. If that were truly the contract with users and users all knew this, it would be a wonder there would be any users.
Aside from that, yes I’m aware of the “no developer owes any user anything” nature of open source software, but users will migrate to the work products of open source developers who are inclined to show them some basic consideration from years-long investments.
I rather see it as a way of stealthily changing the “contract terms” with users so that developers feel less guilty when they strand users when it no longer works. And wouldn’t that be consistent with your desire to see it no longer be an option for new users?
Some new users will not be interested in your preferences, in cases where they see a value that you are unaware of. This is a common pitfall in product management, where the scope of a product is only as big as what can fit in one person’s imagination. In any case, discouraging new users from using DSL rules is as easy as documenting that it is not their best option, perhaps with a helpful, editorial-free table listing various benefits so they can choose for themselves. The fact that Rich doesn’t favour it should be as important as some other user does, right?
Maybe I am not enough involved in core development but I do not remember of such a situation and I am there since many many years.
Is this different from any software? Or hardware for that matter? Which alternative home automation systems out there makes that commitment? Which ones even make an attempt at that? I want to go use that!
To be clear, I want Rules DSL as an add-on to protect current users of Rules DSL into the future as long as possible. I believe making it an add-on to makes it easier to support and work with and not be beholden to the whims of the core developers.
Even though it’s a crappy language on almost every measure, and is no longer the easiest to learn and code rules in, I don’t want to force everyone to have to rewrite all their rules for as long as possible.
The way Nashorn and Jython has been supported and continue to work all these years is evidence that supports this.
My opinions are my own. I will continue to express them or not as I see fit, as “capricious” as they may be. I like to think that the amount of time I’ve spent working with and supporting others to use OH would warrant the term “informed” but .
I think not expressing them at all is the better course going forward.
I do remember it because I followed it at the time with quite some interest, but I don’t care enough now to dig back up the issues here and at the Xtend repos to prove it.
Let’s just pretend I’m making the whole thing up and being disingenuous to improve my point (which seems to be your implication). That should make everyone happy, and we can put this all to bed.
What’s the most hurtful in all of this is after all the years and all the hours I’ve spent working with OH, advocating for users, and helping everywhere I can, I’m being accused of having nefarious motives.
Yep, I’m out of the Rules DSL business. I have no opinions. I have no experience. I have no knowledge and no ability to help and more. If I’m duplicitous enough to try to kill it through the back door, how could you trust me anyway.
Rich, you have a very pronounced opinion against DSL rules, no problem that’s your opinion and you provided arguments in favor of other rule engines.
I don’t know how many users are relying on DSL rules today but imagine it is 75% for example, you can maybe understand that you can afraid some of them.
I did not say you were lying but rather that I don’t remember problems to core maintenance due to DSL rules. Maybe I am wrong and I just do not remember, that’s fully possible especially if you have in mind a problem we had 5 years or more in the past for example.
My current and only personal feeling is rather that DSL rule is something very stable requiring minimum maintenance in core repo. We just upgrade Xtend/Xtext versions when new versions are released. And that’s true there are not a lot of enhancements provided for this rule engine since a long time. That’s true that Xtend)Xtext is complex when you want to make enhancements and requires skills.
Once time again, I may have a wrong idea of the difficulties currently caused by DSL rules in core framework maintenance. Or not 
And of course you can expose your wishes like everybody, especially with your big experience, and everybody can discuss your wishes or disagree with you or challenge your arguments. That’s one of the goal of this discussion, no?
I misunderstood your intent but I still feel like I’ve been accused of having false motives which hurts a little. I am going to drop Rules DSL as a topic I advocate for our against. I’ll simply let it be for better or worse.
If the mere suggestion on a brain storming post of making it an add-on to save it is scary, imagine how scared people would be if I really had my way, which of course could never happen since I don’t submit PRs nor review them (which is also no secret).
However, I didn’t bring this up because it’s not one of my reasons, but with the requirement to use 64-bit coming with OH 5, waisting a bunch of RAM dedicated to bundles that are not being used is going to be problematic for some users. Maybe we can have a way to turn them off through a setting or something? If it was an add-on it’s easy enough to not install it or uninstall it but if it’s party of core 
. I have plenty of resources but others are not so lucky
I think having DSL as an add-on is a good idea. I don’t use DSL and not having it come up as an option and not use resources sounds good.
I removed all my DSL rules when oh3 came out. I also stopped using file base stuff as well.
UI only. Oh yeah and no site maps.
Haven’t missed it at all.
As Xtend/Xtext is by the way still required for things, items, sitemaps … creating an add-on for DSL rules in addons repo will I believe make maintenance more complex than how it is today as Xtend/Xtext versions should evolve at the same time in two repo and so more PRs to create and coordinate.
Certainly doable but more complex to maintain than what it is today.
This is as generic as it gets and not an argument pro or against keeping Feature-A.
I also stopped using UI-based stuff as well.
Files only. Oh yeah and only sitemaps.
Haven’t missed it at all.
And now what? Is your preference more valid than mine?
I can follow arguments like
“Xtend/Xtext made it hard in the past because of blockers that couldn’t be merged and slow developement which slowed down openHAB”.
But personal preference is neither an argument pro nor an argument against.
Just saying having it as an option and if you want to use it then use it.
I don’t care if you use DSL or not. I am saying I don’t miss it.
I would like to suggest that we have the ability to Group Items in the Main UI so that they can be secured together as an Object. I have a group of Switches where I have 4 x Switch icon, 4 x Text for the switches descriptions and the background and these are all separate items -editing them is painful because they all can move out of alignment and then you have to go to each individual item to amend the x & y components not to mention that the z ordering becomes important because trying to click for an action is important on what you click.
The ability to cut and paste this group from the code section would be beneficial in the development of pages because it could be created, aligned grouped and copied the pasted as an grouped item on the page and moved to the needed place.
You may need to open a new thread to explore this more, but you should already be able to copy and paste any part of any page or widget from the code tab. You have to be careful with indentation and stuff like that depending on the level you are coping from and pasting to though. Maybe you are referring to that?
In addition, it’s my understanding that you can create custom widgets built from custom widgets. So you could create your button group as a custom widget and then include that custom widget as part of another widget or reuse it in multiple places on a page.
Hi Rich
Thanks , I will create a separate topic but just for context here i have created widgets and yes I can copy and paste from the code but there is no relationship between the items - see the screenshot there are 9 items here - the background, the 4
switches and the 4 descriptions so think a grouping would solve all of these (as a locked set of items)
When you create a custom widget (Developer Tools → Widgets) you define properties. Those will let you select the Items for that instance of the widget.
The idea would be to take some existing foundational model (like Llama) and perform some type of fine-tuning. Fine-tuning can be hardware intensive (but not as intensive as training a foundational model). Once the model is tuned, using it, called inferencing, is not nearly as hardware intensive.
One thing that’s missing, that’s very much needed, is data. Certainly current documentation and code can help, but I think it’d be really helpful to have sample configurations, examples, and perhaps working file-based configurations.
Do we have any existing sample configurations or examples outside of the documentation? Does anyone else know of any public OpenHAB repositories other than openHAB · GitHub that is up to date and accurate?
I do not know if these ideas are repeated or not, honestly haven’t checked much of the ideas shared but the ones I’ve read were not like these ones, so here goes my 50 cents:
- Improving the UI page builder in a way that makes it easier to work with dozens or even hundreds of devices, in a way that we can quickly duplicate one item (without codding) and quickly change the respective item
- Having bulk options to set in things and items, selecting multiple ones at the same time and setting attributes and other options at once instead of getting in of each one to set options (this would save a TON of time with large installations)
- Have the possibility to view more details (maybe as an “admin view”) both in things and items listings page
- Having the possibility to add multiple things at the same time and customizing them at the same time (for instance, in a table like format where we could select the ones we wanted and for each line, customize whatever we wanted)
- Possibility to create more than one “startup page” so that we could use in the APP as homescreen, for different tablets for instance
- Possibility to add different users and set custom permissions to certain pages and even certain options (like this, we could set a user that would have access only to a specific page, let’s say, Guest Room, where that room would have a tablet with only things for that room and bathroom, no access to anything else, this could also apply to hotels)
- Having a user management page where admin could see common things about those users like last login, last item used, we could even keep a log of what each user did (perfect to debug eventual “user problems”)
I have some more ideas but I’ve noticed similar ones were already shared, so I keep these here for now.
These were based on experiences I had already using OH in the past, which I’ve been doing since OH2.