I’ve said multiple times. You don’t have to convince me. You have to convince the maintainers. Especially if you are proposing changing programming languages and core architecture.
As a user and self proclaimed speaker for new users I’m not convinced. It seems a little like 1. Kotlin 2. ? 3. Profit.
But my opinion counts for next to nothing for something like this. I’ve given it. You disagree. That’s fine. If you feel strongly about it, go and open the issue on ESH and get buy in from the people whose opinion actually matters.
Or move on to something else. Something this big and daring is going to take a lot of work and a lot of cooperation from a lot of people, many of whole have strong opinions about OH and where it is going. An add-on you can do on your own. be Fundamental changes but to how OH is built and how it works is going to take the work of many. If you are dissuaded by the opinion of two users who have no influence over the development of OH in the first place then I question whether you would have the commitment and fortitude to see this through to the end.
You have managed to tell several of the developers of OH that their baby is ugly in this thread. Can you stand up to similar criticism from them?
No, I don’t think everything is fine. I’m also not dissuading you from trying. But I’m not yet convinced this would be a viable replacement for the Rules DSL. I could be wrong. And if I am I’ll readily admit it.
Kotlin will be an extension like JSR223 or experimental rule engine. It won’t disrupt the way things are done with Java or rule DSL. It would be optional, those who like it will use it and contribute in that language, its community process.
Lets agree to disagree on merits of rule DSL (less modern but OH specific ) vs Kotlin vs JSR223 bridge (a rudimentary integration with Java ). Let me first come up with a working proof of concept. Then we will see how deep the rabbit hole goes.
I don’t work for JetBrains or Android. It would seem that way, but its not the case. I simply like the Kotlin language, amazing IDE support, flawless integration with Java, modern features and commitment from Android and JetBrains to support it.
So much talk and not a single line of code so far. Why don’t you just start working on it and then open a PR? If nobody else likes it then at least you have a nice kotlin implementation you could offer as bundle.
BTW, do you guys really think teaching Rules DSL to newbies is easier than the few bits javascript they need to know to create rules? I don’t know…
So far in my experience the answer is yes. If you have contrary experience I’d love to hear how you did it. I’ve experience teaching non-technical users Python, Java, and Rules DSL. Getting non-technical users productive and self reliant has been far easier with the Rules DSL than the other two.
Perhaps if one can present a greatly simplified Python/JavaScript/Kotlin/whatever environment that cuts out the need to worry about loads of programming concepts like functions, classes, and data structures in order to get a Rule working that would be easier.
The vast majority of my time is spent helping people with specifics of OH (difference between a command and an update, what are Items for, stuff like that) or with generic programming concepts (what’s a variable?, what’s a function?, why is scope?, stuff like that). I’d say maybe 30% of my time on the forum is providing Rules DSL specific syntax help, and most of the time my answer there is to “use VSCode which will find these problems for you.”
The biggest problem for the non-technical users isn’t the syntax of the Rules DSL, it is the sheer number of abstract concepts they need to learn to understand how OH works. And most of these users are not used to thinking in abstract concepts. So, to take Java as an example, if I have to explain what a class is and explain why they all have to be in separate files, how main is a special function, why you can’t see that one variable in this other class you defined, and so on the number of abstract concepts they need to understand increases.
It’s not a problem of syntax and tooling. If it were then I’d be all over using a more general purpose language. The problem is one of simplicity. I need a Rules environment that eliminates the need to learn as many general programming concepts as possible to get started and becoming productive. Then as the user’s HA system grows and becomes more complex they can pick up those concepts they need when they need them. Ideally, the really advanced ones would then switch to JSR223 or whatever else comes down the way, though many find the Rules DSL to be more than adequate for their needs.
In a perfect world, I’d want something that is as easy to get started in as the Rules DSL but let’s the user grow into the language. Even with the excellent efforts of @RRoe and his Lucid library for Jython Rules (take a look if you haven’t already), coding in Jython just doesn’t have the same degree of simplicity, nor the same degree of documentation to make it a viable alternative to Rules DSL in terms of simplicity for non-technical users. And this is ignoring the fact that installing it and getting it running in the first place can be a barrier too high for many non-technical users to get started.
I bet if we can:
develop Lucid or something like it to the point where all the user’s need to know is the names of their Items, sendCommand, postUpdate, and how to trigger a Rule to get started with very simple Rules and then make it easy to introduce variables, if statements, and working with Groups of Items as the next step the language would be just fine.
have the ability to install and start using JSR223 + Jython + Lucid (or whatever) from PaperUI (I don’t mean the actual coding of the Rules).
bonus points go to the ability to easily create libraries, find libraries, and import libraries of Rules without needing to copy and paste or manually copying files to the right directory (e…g find and download from the IoT Marketplace).
Anyway, my experience is my own. Maybe I’m doing it wrong. And I’m always open to other ideas. But my experience is somewhat extensive as well. And as I’ve said elsewhere, if someone(s) are willing add the code to simplify Rules development in any other language, document it at least as well as the Rules DSL is (not a high bar to pass) and take on helping people on the forum who don’t know an Object from a log statement I’d be all for that. Heck, I might finally be able to try to code up a binding or two (Roku and Dexcom CGM data scraper are the two two on my list).
Sorry for the long reply.
I love your HABPanel tutorials BTW. I hope to see more!
No i don’t have a better idea (except slowly moving the community over to JSR223 Js/Python, offering more copypasta code examples on the forum etc), i was just genuinely wondering if learning a few JS bits wouldn’t be easier for a non-technical person. It’s hard for me to imagine to be a noob so maybe i’m wrong but the rules DSL seems quite cumbersome and quirky in many regards, like datatypes, date and time, lambdas and such, JS is much easier to grasp and is more forgiving on syntax/datatype errors, plus runs and compiles faster, has full IDE support and such.
People wouldn’t be stuck with seeking help on the openhab forum too because this is pretty much the only place on the net where you can get help regarding Rules DSL. On the other hand you can find JavaScript tutorials all over the place, i guess you can google and copy paste your stuff together without even knowing the basics and the error messages you get are much more detailled so you know what went wrong.
Plus JS/Python etc isn’t a dead-end, the knowledge can be easily applied to other projects, so learning a few bits here and there won’t hurt. Xtend / Rules DSL on the other hand, idk. it’s pretty specific to Java stuff.
Anyways, i was just wondering if people actually find it easier to work with Rules DSL
Also Lucid looks interesting and i’m glad you like my tutorial stuff but it’s actually not HABPanel but BasicUI on steroids
I suspect that is one of the reasons why JS is the language the body of Experimental rules is written in.
But the mere process of getting JSR223 installed and properly configured to run JS is a step too far for many. And I will admit I haven’t done any JSR223 Rules development in JS. I have in Jython though and perhaps that is coloring my experience. But at least with Jython, I have to know a lot more about how the language works to get my first Rule running than I do in Rules DSL.
If there is a way to get an experience for installing and setting up JS Rules close to just installing the add-on from PaperUI and the over all structure of writing your first Rule something as simple as:
rule "rule name"
when
// triggers
then
// do stuff
end
I’m all for it. That would be pretty awesome actually!
But as even with JS transforms a lot of users get lost with even the first line.
(function(i) {
// do stuff
})(input)
What’s “i”? Why do I need “input”? What does “input” do? What’s with the parens around everything? These are the types of questions I get asked. I don’t get asked these question with the Rules DSL anywhere nearly as frequently.
The sorts of things notice when I see these Rules:
This looks a lot more like code which will scare a lot of non-technical users
There is a lot more boiler plate, more boiler plate equals more opportunities for syntax errors for new users
What does description: "Line: "+__LINE__, do? (not a rhetorical question, I’m curious)
I have to call “getItem” to access Items taking a rule like “SystemInfo UI” from 4 lines of code to 19
I immediately have to be exposed to the concept of “function”
It isn’t immediately clear to the non-JS developer where one needs a ; and where one does not
I’m also worried about all the usual problems with JS (which ironically map pretty closely to some of the things that trip up Rules DSL users) like == verses ===, variable scope, Undefined verses null, and all the usual complaints about JS. Like I hint at, Rules DSL has these problems too, but JS doesn’t fix them and introduces a bunch of new potential problems new users will encounter.
For experienced programmers these are non-issues. We internalize the conventions of the language and applying it becomes automatic. For new users every { and every ; is a reason to freak out about how hard coding is.
BTW, this is a great set of example rules written in JS. Thanks for posting them.
I completely agree with this. This is why I desperately want them to be a better option. But the documentation isn’t there, the installation is too difficult, and there is more programming type stuff present that the new users have to deal with to get their first Rule running. If we can get either (or Groovy) up to those level I’ll dance in the streets.
Lots of people claim they do, though most of them have no experience with other languages so their opinions came with that caveat.
Pretty much universally those who already know programming in another language find it much more difficult to work in Rules DSL. I always point them towards JSR223 without fail. Limitations in the language takes away many tools we are used to having at our disposal meaning we need to learn new tools. And the barrier to entry for the Rules DSL is actually higher for these users then it is to use one of the JSR223 languages.
I hated it myself until I started coming up with the DPs and started to really understand the the way the language and OH interact. Once I figured out how to use Groups effectively most of the ugly stuff about Rules DSL like lambdas, populating Lists or Maps for data structures, and duplicate code simply disappears because they are no longer needed.
For example, you don’t need lambdas if you only have one Rule that handles setting a reminder alert for all the doors. You don’t need Lists or Maps when all your data are in Items and your Items are in Groups. And you don’t need duplicate code if one Rule can handle all the Items that need to have that Rule run.
actually it comes preconfigured, all you have to do is click “install” at the experimental rule engine entry in paperui.
The actual JS syntax of the rules is pretty easy already but it could be even more simplified by writing a js rule that reads a text file with
rule "rule name"
when
// triggers
then
// do stuff
end
… with js code in between.
description: "Line: "+LINE is just some debug code i came up with, it basically just tells me which rule is in which file on which line.
the getItem() thing is one of a few places where JS is actually “more text” than Rules DSL code, those lines are just for better readability, i could have put them all into one line too. When i moved from Rules DSL to JS i was able to shrink the code by like 40% in size overall.
; isn’t needed
The rest of your points are probably valid.
Actually… the main reason i wish people would use JSR223 more is i’d like to be on the same page with them and share more ideas and code on the forum and github. (And of course they would have a more stable and faster OH experience)
But oh well, i heard Kotlin is around the corner and it’s 100000 times better anyways
Because there are teams behind it okay, teams. teams of russian android devs okay
For the most part one of the big problems with all the JSR223 libraries is lack of examples and lack of documentation. If you start sharing I guarantee you will get some followers and end up on the same page with a few users at least.
Please share your ideas and code! It all helps. And you clearly have a lot of good ideas and if the sample code is any indication your code is clear and concise.
Let’s move the name calling to PMs or off the forum. Sarcasm and joking around is too easy to misunderstand, particularly on an international forum where the bulk of users are not native English speakers. and nuance is lost.
JSR223 has several advantages.
We have it now. (first to market)
There is more than one person using it/pushing it on OH. (better support in OH)
It supports two top ten most used languages now. (networking effects)
It seems to be lost now but a long time ago an essay from Neil Stephenson’s In the Beginning there Was the Command Line entitles “MGB, Tanks and Batmobiles” that circled the Internet. In it he used an extended metaphor comparing operating systems to cars. Windows was a massive station wagon, Mac OS (this was well before OSX) was a hermetically sealed sports car, Linux was a tank and BeOS was the Batmobile.
I used Be in its day. It was phenomenal. Damn I loved working in Be. And that statement definitely ages me.
But today we still have the station wagon and the tank and a new sports car rebuilt from the ground up. The Batmobile is all but gone and frankly has been long since surpassed in capability and features by even the station wagon.
Java looks like the station wagon. Python looks like the tank. I don’t know what the sports car would be, maybe Ruby. Right now, Kotlin looks a whole lot like the Batmobile to me. It may be the most awesome thing ever but that isn’t enough. Superior technologies die out to “good enough” all the time.
I agree, when Amazon echo first can out. I developed a few “Alexa skills” using javascript. Without tons of internet support and tutorials I would still be working on the first skill. I did learn a few things, at the time, through trial and error but I’m no programmer. This was several years ago, I wished I would have kept developing and learning but I ran out of idea’s for new skills.
If JSR223 is similar to javascript, I’ll have to read up on JSR223, I’m willing to give it a try. Worst case, I fall flat on my face and revert back to Rules DSL.
Can I use both Rules DSL and JSR223 with my OH set up (installed via openhabian image on RPI), or would a fresh install on a test server be the better route?
It is a way to write Rules in Jython, JavaScript, or Groovy.
You can use them in parallel.
JavaScript will be easier to set up and started initially. There are more users on the forum working with Jython though so there will be more support with that language. I’d like to see more docs and support for JavaScript and Groovy though.
Just a FTR. Please review below syntax, comment, criticize on improving readability.
You need to trade “a little readability” compared to ESH rules DSL but you get full IDE support, first class Java integration, ESH/OH community no longer has to maintain/improve/promote a rules VM, and robustness+goodies of Kotlin and of course tones of examples/tutors/support from Android and Kotlin community.
FYI this is working! Need to polish certain things and of course adapt as per community feedback.
Since this a generic thread, I would prefer main Kotlin discussion be maintained in below thread, just to spare the Kotlin noise from those who ain’t interested here
I don’t really see how this integration is much different from using Xtend as the base of the Rules DSL. We don’t maintain/improve/promote that. All the work done is on the interface between OH and these Rules which would still be there for Kotlin.
My point isn’t to somehow claim that Rules DSL is good or as good. Just point out these features are not a differentiator. Clearly it is possible to meet all of these criteria and have an unsatisfactory result.
Anyway, I’ll preface this with I like what I see.
Observations:
I would like to have something to differentiate rules a bit more clearly. the fact they both start with “config {” and except for positioning it is not clear that “actions” goes with config or the config before. As it is currently written it is not obvious that the config and actions are a unit. Can I have more than one config per actions? Can I have more than one actions per config?
I’ve some issues with the triggers. The OH architecture is event driven. As things occur the fact of the event goes on the Item Event Bus. These events are Item changes, updates, commands and a smattering of Thing events (ONLINE/OFFLINE), trigger events (Sunrise/Sunset/Dash button). So, when I see item["BedroomLight"].is(ON) it raises a bunch of questions. Does this mean that these Rules can be triggered by state as well as events? I see the equivalent of the changed trigger. What about received command or received update? I have some concerns if you are mixing state based triggering and event based triggering. This is one area where I like the Experimental Rules DSL. There are two clauses, a “When” clause where the event triggers are listed and an “But only if” clause where we check the states of Items to determine whether the Rule should run given the states of various Items. If .is(ON) truly is an event based trigger then I have major concerns about this nomenclature because there is nothing about .is(ON) that implies it is anything but the state, not the event that is triggering the Rule.
I’m very much not in favor of sending commands to Thing’s Channels directly from Rules. The purpose of Items is to “model” your home automation. OH revolves around Items. Items are intended to represent all the pieces of information and actuators in your home automation. Rules should operate on the model. Bypassing the Items means that Rules are bypassing the model and now there are two different ways to interact with your devices instead of just one which will just cause confusion. Furthermore, what happens if I have an Item connected to “Radio1.station” and I send a command to the Channel directly instead of to the Item? Does the Item get that command to? Does it get it as a command or as an update? Or is the Item now out of sync with it’s Channel? I was very much not in favor of Thing triggers in Rules as well but we see they exist. But I only see a mass of confusion and questions like “what are Items even for? when should I use an Item and when should I use the Thing? I sent a command to Foo but it doesn’t show the change in my UI, why?” and so on. It further breaks down the layered architecture OH has. If Things are at the bottom and Rules are at the top, Items are the layer between. This causes all sorts of intrusions from the Things layer into the Rules layer.
What is SUNRISE? Something built in or something defined elsewhere? Does it use Astro or something else?
Is there some sort of builder of full documentation for the scheduling engine? I’ve never been all that much of a fan of cron but at least there are tons of tools to help build them. This looks slightly more intuitive but it isn’t clear how I would do something like “the first monday after the first sunday of the month” or “every minute”.
So this enabled-when/forbidden-when looks a whole lot like the “But only if” clause in the Experimental Rules Engine. This is where checking of Items states or online status of Things and the like should be placed. Oh wait, I see you have a should-not-trigger-when clause. I see no reason to have two separate clauses for this unless there is a very compelling technical reason. Put them in the same clause.
I don’t know what I think about the optional alias-* fields. It’s optional so it probably doesn’t hurt anything, though I’m still against interacting directly with Channels and Things from Rules. I probably wouldn’t include it in any thing I posted because I find that the longer the chain of things to remember the harder it is for non-technical users to manage. Changing the name of the Item for this Rule and this Rule only adds a whole new level of redirection and abstraction that I think many will find confusing. Regardless of whether I agree with having Channels and Things here, there shouldn’t be separate clauses for the three, there should be just one alias clause and the engine should infer from the context what the alias is for. Fewer optional clauses is better than more clauses that do the same thing only with a different type of data. The new non-technical users shouldn’t have to worry too much about type. One of the problems with the Rules DSL is the users must worry too much about type.
Can I put any arbitrary code in the should-not-trigger-when clause so long as it returns a boolean? Like a whole function? Because there may be cases where some significant calculations need to be made to determine if the rule should run that won’t fit on a single line.
Can you explain what an emergency theme is?
Another cool feature of the Experimental Rule Engine is the ability for Rules to disable/enable other Rules. Have you thought about something like that?
val msg = "Intrusion alert, suspicious activity near ${device["Door1"].label}"; Why the ; here? Is ; always optional, sometimes optional?
sendUiNotification(msg) How is scope managed? Where is this function defined?
“device means ESH Item or Channel, thing means ESH Thing” Is there no way to be able to just refer to the Items by name? This is one of my complaints about a lot of the alternatives. They all have indirect access to the Items.
systemConfig.emergencyPersonal.filter(it.name == "Jack" || it.name == "Kim").sendSMS(msg) Does this assume there is only one it with the name Jack? What if there is more than one? What other collection actions are available?
lookup and use OSGI service, with special systemService helper If I’m understanding correctly, this will create a separate JSONDB file under /lib/openhab2/userdata/jsondb. That is really cool, so long as there is no risk of corrupting the other JSONDB files. What other OSGI services are available? I’d prefer this were just available and not something that we would have to look up and extract from the system services.
Will third party Actions be supported?
Are all of the methods on the Item classes available? In particular the persistence methods and group methods?
(How) Can I trigger a Rule based on an update, command, or change to one of its members? How can I determine which member triggered the Rule in the actions section? Or do you have some other approach that makes more sense in a Kotlin context, though it would ease migration if this were more directly supported.
Right now its one config and one actions per file. Re-usable code will go in global functions, libs, classes etc. More on that later.
User will be free to combine conditions. The ones shown are not exhaustive at all. There is also a filtering/pruning in between to avoid lockups/infinite recursions. And the ones who do want to depend on only states vs “change in state” or trigger, will be evaluated regularly (at specified intervals). Imagine a stubborn theme, that must ensure regularly that all devices are in given state, if theme conditions are met.
Items / Things / Channels are all optional. You can use whichever you like. I don’t want to push one paradigm here. Because I got most scenarios covered without using the concept of Item.
Its goodies available from standard kotlin-esh extension libs. They help majority of beginners. If people prefer a more verbose Java approach like TimeUtil.SUNRISE then we can do that.
Yes. There will be a type safe builder available soon for scheduling engine. I have to work hard.
There could be multiple contributors, and it allows experimental new conditions separate from those already working. Same reason most Linux /etc/package.conf are now /etc/package.d/xyz.conf. All those conditions eventually get combined by AND / OR. Its optional anyway.
They are soft referencing mechanism. They make rules re-usable across sites, where exact device names and technologies are different. Like I said earlier, I am no fan of Item concept, its a baggage in my personal opinion. I got a complex system working without even have to deal with single Item. Rule engine should be able to work directly with Thinghs and Channels.
Yes. Where ever you see { // code } , it is a lamda that eventually returns something.
More on that later. Rabbit hole goes deep. You need to take Blue pill first.
There will be Karaf/Rest commands to do that. I am no UI expert, otherwise I would have created nice Enable/Disable UI for installed Kotlin rules.
Its optional so that we can have endless debates about whether to have it or not.
There is an explicit way for those who know Items and Channels are different. item[“MyItem”] or channel[“MyChannelUID”]. But you can’t have MyItem as variable unless you declare it with
val myItem = items["MyItem"]
// Now myItem is org.eclipse.smarthome.core.Item Java object
// You can do anything with it as you would do in Java, plus Kotin extensions if any on that type.e.g method flagForMyCustomInspection below
if(myItem.getState()==OnOffType.ON) { myItem.flagForMyCustomInspection() }
Its a pipeline. A typical language feature in modern langs. You pipe things, filter, map, convert and then take actions available for those types. You can tailor above to your need using many many ways. I will document as much as possible. And IDE also shows possible actions in auto-complete.
There is a security risk here. We need not expose all core services to Kotlin Rule/App unless user has explicitly approved it somehow. Some conscious decisions we can make based on our knowledge and experience, on behalf of our users.
Sounds great for technical users. This is almost a deal killer IMHO for non-technical users.
Great for experienced users. This massively increases the mental load on the new users.
And that is one of the main complaints of new users to Linux. More fields like this increases the mental load on the inexperienced users. It also increases the opportunities for those users to do what they think is intuitive and fail.
Unilaterally deciding that one of THE KEY concepts in OH is “baggage” is not going to endear you or win you any converts among the maintainers.
You misunderstand. I mean I have a Rule that runs and because of something it detects/decides that Rule is able to disable/enable some other Rules. No UI involved.
If its optional
I’d recommending never showing it. It just raises questions and confuses the new users who don’t know how to tell what’s important and what isn’t.
One more thing the new user needs to know that they should have to to write their first Rule.
I’m not totally ignorant of all these new fangled programming languages that all the young whipper snappers are using. Rules DSL/Xtend has this as well. I just wanted to know the parameters about how it works here since in my experience every language handles them slightly differently. In particular, is there an implicit for each on the collection returned by filter or does the filter assume only one result?
So far it would seem that you are rejecting any advise/criticism I might have to offer so I’m not very hopeful this will become something I can recommend for new and non-technical users.
FTR aside from some other improvements, I have added offline-test and offline-test-assert sections for easy testing at build time without having to connect to live instance.
Rich, you are primarily interested in newbie adaptation. In your opinion Rules DSL has already done everything that should have been done and no new language/ enhancements could significantly improve the current situation that we have. I have noted that and I am working hard to make the Kotlin equally good and hopefully better for newbies.
My goal is also to attract dev community. I have already stated that. Title says make rules good for everyone, isn’t it?
Bashing a concept only based on one goal (newbie compliance), is not fair.
Every new minute is an event. People should be able to write conditions against that.
To make things clear I have made explicit expression
retrigger-delay { 23.hours }
in the rule-config section. Above criteria introduces a fixed minimum delay for “My Wakeup” rule while re-triggering. We know sun doesn’t rise again within 23 hours. Or is it 22? You can tune it for your location.
Now you agree its really Xtend behind the scenes. The rules DSL is basically a custom “when” clause and its OH-specific trigger specification combined with Xtend statements in “then”.
Kotlin is much better than Xtend. If your are hung up on beauty of when clause and its semantics then continue using and promoting it.
Xtend and rules DSL IDE support, its VSCode I believe, you guys discontinued Eclipse IDE based support because Xtend is not something even Eclipse folks want to pursue? That VSCode extension is maintained by ESH/OH community members. How many are they anyway? Kotlin’s JetBrains team will obviously surpass them.
How may Xtend examples/tutors/videos are available on internet today compared to Kotlin? Users should do their own math.
Yes, I have rule priorities. Not publicly documented yet. In my model, a rule cannot override a system’s core rule or emergency rule. Allowing any rule to disable any other rule is a rudimentary model in Experimental Engine.
The code installed and available in the osgi container is assumed to be authenticated already with jar signing or osgi installers. The Kotlin rule will be able to execute any installed code. But like I said, we need a user consent on what rule can call what system services, and there are rule priorities as mentioned earlier.
There will be some thin layer between important core classes like Item, Thing, ThingHandler etc. , that layer will ensure non-relevant methods are hidden for clarity. This layer will be different for Kotlin Rules, Kotlin Bindings and Kotlin Apps. The Apps will have least restriction. An App could include Bindings, Rules and UI extensions, although that part is not yet implemented. We have to get there.
In fact, the concept of Thing and Channel is more visible to a newbie than the concept of Item. If you put OH in Item linking simple mode, you see no item concept throughout all the UIs. The Item concept is for experienced users like you, who know OH for a long time. On this point, I am actually making things better for newbies by allowing Channels and Things in rules.
That is not accurate. I see enough reasons to support multiple triggers-when and should-not-trigger-when clauses. Imagine your /etc/sudoers is maintained by 10 different packages, it was a nightmare, that is why there is modularity introduced these days. No one entity contributes everything. Support for multiple when clauses comes from same experience.
Like I mentioned earlier, Item concept is not relevant to a beginner on any of our UIs if item linking is put in simple mode. It was the default mode in 2.1, 2.2, I believe, you guys changed it to off. But I always liked simple mode. I don’t care about items and I have gone so far. So can any other user. Just that he needs a rule language which allows it to express what he already sees on UI.
Items make you write config files, which is OH1 philosophy I believe. Its a newbie barrier.
Who is being unilateral / totalitarian here? The maintainers and hard core users like Rich or new users like me? I wonder.
Like I said earlier, if Items are optional, things will be simpler for newbie. For advanced users may Items make sense, but wait, the group concept can be eloquently expressed in Kotlin based infrastructure, and the group averaging functions can be changed by user easily.
filter produces multiple output items. And map converts them to different objects. Its actually not difficult to understand, you might already know Unix pipelines. Its similar thing but statically type safe. Like in Microsoft Powershell.
Like I said already, we shouldn’t be unfair when evaluating different paths, especially when they can lead us to a common destination. In this this case, making our platform better than it is today.
but OH specific 
) vs Kotlin vs JSR223 bridge (a rudimentary integration with Java 
It would seem that way, but its not the case. I simply like the Kotlin language, amazing IDE support, flawless integration with Java, modern features and commitment from Android and JetBrains to support it.
And you clearly have a lot of good ideas and if the sample code is any indication your code is clear and concise.