Marketplace versioning with embedded resource

Nadahar · February 26, 2025, 3:42am

No, the reason I think of it this way is because it is presented as an action. What you are presented with is identical to what you see for a “full rule” with a scripted action. It is presented as a “script”, with a MIME type, which can be “run” by pressing the button in the bottom. It is also stored as an action, so when you look in the REST API explorer, it is also clearly shown as an action. In short, it’s “identical” to a scripted action in every way, except that it isn’t really that at all. It’s the source code for making the rule, not the code that is executed when the rule run.

I don’t know how you came to that conclusion. Again, don’t equate file-based rules with SimpleRules - they aren’t the same thing at all. The original DSL rules aren’t SimpleRules, are you saying that those aren’t file based? Also, you can make “full rules” using whatever scripting language you want from files. It doesn’t have anything to do with files, it has to do with “a more convenient way to write rules” from scripting languages (and there’s nothing wrong with that).

Rule and RuleImpl are both older and “more foundational”, to me this is very clear from looking at the structure. The history backs this up:

Rule was initially created as an interface 2015-03-11
Then, at 2015-11-24, Rule was converted form an interface into a class, and this was “the original rule”.
At 2017-04-28, SimpleRule came into existence, then as a subclass of Rule which was a class, with the description: “convenience Rule class with a action handler. This allows to define Rules which have a execution block.”
Later, at 2018-06-38, the Rule class was split into a Rule interface and a RuleImpl class which basically are the ones we have today. SimpleRule was changed from a subclass into a Rule implementation.

I don’t know why this is so important to you, but I think any attemt to make them “equal” is futile. Rule is the definition, SimpleRule is an implementation that takes some liberties where it sacrifices compliance for convenience. It does so by “hacking” the action module, which is why the execute method of SimpleRule, that is key to the way it is used by scripting languages, still today ends up as an action.

There is nothing the UI or any other part of the system can do about this “link” to action - it’s in the SimpleRule implementation. I get that you don’t think it makes sense, logically, to view it as an action, but you can’t blame the UI, or anything else, for showing it like an action when it is in fact implemented as an action. The “adaptations” in the UI to make SimpleRule “less confusing” is just that - adaptions, they don’t change the fundamentals. In this isn’t just a technicality, as a consequence of the implementation, it also acts like an action. By that I mean that there are triggers and conditions that decide when to run the rule, and only when the rule is run, when the actions are executed, is the execute method of SimpleRule executed.

So, it doesn’t really matter if the helper library “shuffles the deck” and puts some things as triggers and conditions. These are still “regular” just as with any other rule. What isn’t “regular” is the action, and that’s where whatever code which havn’t resulted in a trigger or condition, is found.

jimtng · February 26, 2025, 3:50am

So we’re in agreement that they are different.

Why then, are you trying to display them using the same FullRule page?

Nadahar · February 26, 2025, 4:01am

If so, the misunderstanding is still very much alive. I feel that I have a pretty good overview of how this ties together now, and I still don’t see where you see misunderstandings or different shaped pegs.

This isn’t about “creating their own” or not. It’s about using the “opaque” technique of “rerouting execution” to the scripting engine, and SimpleRule only does this for actions, as can be clearly seen in that in only implements SimpleRuleActionHandler in additon to Rule. You could create similar SimpleRuleTriggerHandler and SimpleRuleConditionHandler interfaces, but SimpleRule as it is today, doesn’t do that.

So, when you speak of “non standard conditions”, you must either mean scripted conditions (which is completely within the realm of a “full rule”) or you must mean conditions that is evaluated when the action is executed, that aborts the execution if the conditions aren’t fullfilled. If the execution of an action is aborted, the “action” itself is still executed.

It’s not that I “insist on displaying a round peg as a square one”, it’s that I don’t see these as separate entities as you do, and I don’t think there are grounds to view them as such. I think you get the greatest flexiblity, and the most “user friendly” system if things are logical and consistent. To me, that means handling all the “corner cases” and not just focus on the “most common use pattern”. Because, if you just focus on the “most common use patterns” for a while, pretty soon so many things have been done that prevents the “less common use patterns” that they are effectively impossible to use - and flexibility has been lost. Today’s “less common” can be tomorrow’s “most common”, if you just make sure not to kill it in the meanwhile - and even if it isn’t, those that have needs that don’t align perfectly with “the masses” still have their needs.

jimtng · February 26, 2025, 4:08am

Then why do you have to special case them and come up with “Opaque Triggers” and “Opaque Conditions” and also display the script with warnings? Won’t that imply that you too realised that they are different? In fact you are treating them differently here too.

I don’t understand this whole bit.

Nadahar · February 26, 2025, 4:25am

No, “Opaque Triggers” and “Opaque Conditions” is something that, as far as I know, doesn’t yet exist. SimpleRule doesn’t provide for them. But, there is support for them “deeper in the system”, so why not make sure that when somebody decides to use them, they will be treated appropriately by the UI?

I guess the benefit is the same as the reason why people want the triggers and conditions included as comments. In reality, they are “redundant information” if the whole rule creation script is there. But, again, my guess is that it’s not so clear for everybody what ends up as what, so they like to see what has “ended up” as triggers, conditions and actions. Even though they can’t “see” the action, they can deduce that anything that hasn’t ended up as triggers or conditions are in the action. So, the “rule page” is a way to show how the rules are built structurally, what mechanisms trigger them and what conditions prevents them from running.

Not at all. The bugs that prevents DSL rules was fixed in no time, so they are no more “in my version”. I don’t think the lack of a “script source” is a big deal, in fact I think it in ways could be called less confusing. My motivation is simply to try to find a way to get everything to work consistenly with a “common logic” so that it makes sense to people and that the learning curve isn’t so steep.

I see the idea that “these are just two different concepts” as way to avoid having to deal with “difficult corner cases”. The problem is just that is doesn’t reflect the reality underneath - the reality is that they are very much related, and “difficult situations” will continue to arise. That will mean that these “dual concepts” will either have to multiply into many concepts, or will have to go through some “forced reconsolidation” in the future.

The example with rule bulilder that came up is a good example of what I mean by “difficult situations”. The “SimpleRule is a separate concept that should be displayed only as the rule building source” idea won’t work with rule builder, because it’s probably close to impossible to split the source code into meaningful chunks that “each build one rule”. So, what do you do then? Just show nothing? In that case, the “rule page” showing an “opaque action” is certainly more informative than a “blank” script page. The alternative is to make yet another “special concept” for rule builder, to try to make something meaningful out of that. And the same for the next situation, and the next situation…

Nadahar · February 26, 2025, 5:11am

I don’t come up with special cases - I think they are well taken care of in the standard “rule page”. Trigger, conditions and actions that can be shown are shown, those that can’t, the opaque, are merely represented so that you can see that they exist, but you can’t see the details, because they aren’t available.

With that intact, there’s nothing wrong with adding “convenience functions” on top - that make life easier for users. So, even though I don’t really think that the “rule creation source” has a place as “part of the rule”, I see how those with the knowledge to read that code can use the “creation source” to build a mental model of what the rule does. Thus, I think it’s reasonable to offer this functionality, when it’s possible, on top of the structured rule system. The warning was suggested only because I think they were presented so similar to “actial actions” that I would be very reasonable to expect users to perceive them as actions. And, if you view them as actions, they are misleading. Thus, the text to try to clarify that they aren’t the actual actions.

The only thing that is “different” with a SimpleRule for me, is that no source exists for the action, so you can’t read what it does. Instead, you must read the rule creation source code, and “extract from that” what is the action. For a human that understands the script, that’s not hard. For a computer program, it’s close to impossible to do. Other than the “drawback” that they can’t display their action, and that they can’t be persisted or copied because they rely on the referenced memory object and won’t work without it, they are “just another rule” as far as I am concerned.

Ok, I’ll try to make an analogy then. Let’s say you have a car, as as time goes by it requires maintenance. One day your gearbox loses its 5th gear, and you must decide what to do. Rather than fix it, you conclud that “where I live there are many turns, so I rarely go fast enough to use 5th gear”. So, instead, you put a plate where the grear lever would have to go for 5th gear, and you continue. Later, your window wipers break down with smoke and “strange sounds” coming from the wiper motor. Again, you decide that it hardly ever rains where you live, so it doesn’t really matter to you. Instead, you remove the switch so that you won’t accidentally cause a fire.

One day your handbrake stops working. But again, it doesn’t matter, because it’s perfectly flat where you park in your garage, and the shopping mall where you usually shop has a flat parking lot as well. So, you just leave it broken.

You now have a car that, functionally fullfills your most common needs, and you have saved money and trouble on repairs “you don’t need”. All is great. But then your family want to go on a car vacation, to places with steep hills where you might need to stop, frequent rain and there’s a lot of high speed highways to get to the destination. Your car is no longer up for the task - you have lost flexibility.

Maybe you have to move to another area for a better job, or whatever reason. This area is hilly with lots of rain. What was “less common” needs has suddenly become “common” needs. Your car is ill suited to this, and you will either have to do a make overhaul of your car, get a different one, or live with severe limitations to where and when you can travel.

That’s the best I can come up with right now - I hope it’s sufficiant. It’s the same thing I’m trying to explain above, it’s not always a good idea to just focus on “the most common use case just now”. It will usually come back and punish you in the future.

jimtng · February 26, 2025, 6:00am

The JS Rule Builder is simply a different syntactical method of creating a SimpleRule using functional programming style. It creates a JSRule for you in its build() method. So it is not yet another kind of implementation. From core’s perspective it’s exactly the same as JSRule, which is an instance of SimpleRule

The fact that UI doesn’t show the correct source code is simply because the JS maintainer hasn’t yet incorporated it into their library. That’s probably fixable.

I don’t know how JS does it but in JRuby this is not a problem at all. I group multiple related rules in one file and each rule shows up individually in the Rules page and shows the correct individual rule source when you click on them.

Thanks for the analogy. It helps explain what you said earlier. However, I’m not sure they’re applicable to the topic. This may be a case of “strawman’s fallacy” - by exaggerating and misreresenting the situation.

I’m aware that I too may be a victim of some logical fallacies here, so please point out if you think I’m wrong.

So let’s get back to the actual things you’re proposing.

Does the rule page show the trigger correctly? YES - in this particular example, but there will be other cases when this will be wrong too.
Does the rule page show the conditions correctly? NO. It does not show any conditions at all. This is incorrect. The rule indeed has a condition. Many of the conditions that you can define in JRuby cannot be represented in the rule page.
Does the rule page show the action correctly? NO. instead it shows the complete rule source. And you know this to be incorrect, that’s why you showed the triangle there.

It says “Opaque Action - executes external code whose content is unknown”. Well that’s once again incorrect. If you look at the source code (as it is now in the Script Editor), everything is there. There’s nothing that’s unknown about it.

Your alternative proposal of showing the rule source code in the Code tab is slightly better. It solves the last problem above, but doesn’t solve the first two problems (trigger and conditions). However it will further confuse people because sometimes the Code tab shows YAML (for Managed / Full rule) vs Ruby / JS / whatever syntax.

There are now even more inconsistencies!

Nadahar · February 26, 2025, 6:18am

I know that it still uses SimpleRule, I’m not saying it’s different conceptually. But, it is different in that they doesn’t seem to easily be able to extract the code that represents one rule. How is this done in Ruby? I assume you can define several rules in one file there as well. Does the helper library manage to send “the correct source code” with the corresponding rule? Because, this sounds to me like a pretty hard syntax parsing/interpretation problem.

When it come to the “style” of Rule Builder, I don’t think there’s anything “functional” about it. It looks to me like it’s the traditional “builder” pattern well known from Java. It’s just plain old “setter” methods where you don’t include “set” in the name, and then you return the builder instance instead of void, so that you can chain the setter calls. It’s often convenient to use because it provides flexibility with a relatively short syntax, but it’s not “functional”. I’d say it’s as mcuh imperative programming as any other “normal” code, every “setter” call has a side-effect, which is taboo among functional programming purists.

My point is that as soon as the helper library isn’t able to figure out what source is “the source for that rule”, the current “SimpleRule paradigm” falters.

Then either Ruby’s syntax makes this easy to parse, the JRuby helper library developers should share their genious with the JavaScript library developers or there’s some other problem that prevents extraction of the relevant code. But, in my mind, it isn’t difficult to imagine situations where separating code into what belongs to what rule is difficult or impossible. What if several rules share parts of the code? I don’t know how you do that in Ruby, but there must be lots of cases where finding “the right source code” is a challenge.

Nadahar · February 26, 2025, 6:23am

I’ll address all the rest later, but I’ll just add - we could add a third tab Source instead of hijacking the Code tab. It could still be the default/start tab.

higgers · February 26, 2025, 10:53am

I’ll add my experience as a user here in case it’s of use…

As a user of file based JavaScript rules my workflow for developing rules involves using Samba to share my /etc/openhab directory and using VS Code to edit my rules in Windows. I don’t see what value I’d get from seeing my rules in the MainUI. I know where my rules are and I use VS code to edit them.

rlkoshak · February 26, 2025, 3:30pm

The root problem appears to be that the code seen in MainUI is not complete nor comprehensive. There is stuff you can define in a file based rule that has no corresponding way to show in MainUI.

I’m in agreement with @jimtng that trying to shoehorn these into the full rule view is the wrong path. Not only is it not possible to represent everything, but to see anything useful you need to make at least one more click to get at the code. Adding warnings that what you see here isn’t the whole rule or isn’t the real rule or “isn’t what is actually going to run” is scary and leads users to think they’ve done soemthing wrong.

We need to step back. Who will be looking at their SimpleRules in MainUI and why?

The who is pretty easy to answer, anyone who is creating rules through files.

The why includes:

to manually run a rule
to enable/disable a rule
to see a listing of all their rules

I think @Nadahar would assert that another reason why would be “to understand their rule.” Based on my experience no one does this and MainUI is a really bad way to achieve this. Shoehorning a SimpleRule into the full rule UI doesn’t help in any way. If one wants to understand their rule, they need to look at the actual source code for their rule and that won’t be possible in MainUI. And since they didn’t write their rule there in the first place, it’s unlikely to be a place they think of to look anyway.

I frankly don’t care how a SimpleRule is represented in OH core. All I care is how it appears to the end users. How the end users interact with them.

So what if we didn’t show any code at all? If it’s a read only rule or a jsr223 rule or a SimpleRule or what ever criteria you need to identify these problematic rules, we simply don’t show any code at all? We don’t show the triggers, we don’t show the conditions, we don’t show the actions. It’s just the rule name, the description, the UID and tags. You can run and enable/disable the rule through the UI. If you want to see the code, you need to go to the source.

Or what if we just dumped the whole source code file into the rule and show that? Again the meaningful parts of the rule (name, description, uid, tags) are shown and the controls that are possible through the UI are presented (enable/dfisable and run) and any code shown is just a raw dump of the original source file. If it contains more than one rule . At least it will be complete and accurate.

Either of these do a better job of aiding the end users than what’s been proposed here I think.

Showing them this stuff in the UI isn’t going to help. They can’t change anything there. They can’t experiment there. And to write a rule in a file they will have had to study the helper library quite a bit anyway. But that’s what they signed up for when they decided to use file based rules.

This is my main point.

It seems like the assumption is that the MainUI view of the rule is the only insight the user has into this rule and what it does. In fact, MainUI is the last place a file based rule user will look to understand their rules. To even get to the point that a rule shows up in MainUI they will have to already understand the stuff you are concerned they need help with.

Nadahar · February 26, 2025, 4:06pm

I can assure you that there’s no straw man involved here. I’m not “arguing” this - I was trying to explain what I meant when I was originally trying to explain my “motivation”. The “analogy” is of course exaggerated to make the point clear, it’s not supposed to proportional.

Anybody will have to believe what they want about my motivation, all I can do is to try to explain. And, I actually think it’s a valid concern, I’ve seen so many examples of this before across different “fields”, this phenomenon applies to everything from software engineering to mechanical engineering.

I still have no idea what you mean by “wrong” here. As far as I can tell, nothing that is shown here is wrong except the content of the action.

I think this is a part of the fundamental understanding that makes address what feels like different things. I’ll try once again to explain how I see this: It is shown correctly because the rule has no Conditions in OH’s rule system. That doesn’t mean that there are no conditions in the code, but they do not end up as Condition(s) for the rule. This means that they aren’t evaluated by RuleEngine and isn’t used to prevent executing the action. So the Action will be executed every time the item state changed form “PowerOff” (the Trigger). Only once the Action is executed, the time of day/clock will be evaluated. If it’s outside the defined “window”, the execution of the Action will be “aborted” and the notification won’t be sent. But this condition is still a part of the Action, it’s not a Condition. This has consequences, because if you look in the log or watch the events, OH will report the rules as being run at any time regardless of time of day. I think trying to “pretend” like a rule Condition and a conditional statement within the rule Action is “the same thing” is muddying the water. They can both prevent the notification, but does so in different way with different consequences/side effects.

As far as I’m concerned the rule page shows the action correctly, and that there’s very little to show exept that the rule has one Action, and that the Action is “opaque” in that you can’t see in the UI what the action does. There’s nothing scary or alarmist about this, it’s just reporting the facts. It’s when you click the action that you are “mislead” in that the whole rule source is shown, which I tried to make users aware of.

Both you and @rlkoshak seems to misunderstand one fundamental thing here: I didn’t “make” this behavior of the rule page. It was always there. It was just done a “shortcut” in the UI code where, for read-only rules, the rule page would be skipped and the Action opened directly. I removed this “shortcut” because it was obviously wrong, and what appears then is the rule page that shows the rule as seens from OHs perspective. But, the Action in this case was presented as a “script action” (because when the helper library injects the “source code” and the MIME type into the rule, it mimics a script action). What I changed was this, I made it detect “opaque” Triggers, Conditions and Actions and show them as that, instead of “scripts”. Because a scripted Action is also a very real thing, you can make a Ruby or JavaScript “scripted action” that can run when the rule is triggered. Presenting SimpleRule as a scripted action is the core of what I’ve labeled a misrepresentation, and which I’ve tried to find a way to “correct”.

So when you come up with your ideas about “forcing SimpleRule as a FullRule” etc., I feel you’re barking up the wrong tree. I didn’t do any of this, I merely removed the code that was made at one point, that “redirects” MainUI directly into viewing the Action when opening read-only rules. Before that, it was shown in the rule page, and somebody made the decision to make this “redirect” probably because it was considered confusing. I’m simply trying to restore the full functionality of the system while making it less “confusing”.

It’s not incorrect. The “code” of the Action is unknown. And, the “source” is just a string that is “attached to the rule”, it may or may not represent the Action, or the whole Rule, in an accurate way. In this example it represents the whole rule, but that’s not always the case (it depends on how you create the rule from the script) and OH can’t tell the difference. There’s no way for OH to “verify” that the string that is “attached to the rule” corresponds with either the Rule or the Action.

Nadahar · February 26, 2025, 4:32pm

I see the root problem slightly different. MainUI displays the Rule as it exists in the system. The attachment of the “rule source code” to the rule has been made to try to give the UI something more to “work with” since the opaque Action in SimpleRule has no actual information. This has been solved technically by attaching the rule source code as a scripted Action. This is the reason why it is shown as a script under Action. But, knowing that this doesn’t reflect reality, I’ve tried to find way to indicate that it’s not actually correct, that this is not actually the Action.

Frankly I think attaching the rule source code as a scripted Action probably has been the wrong choice all along. If the rule source code has any “proper place” in a Rule, it’s on the “rule level”, not as an Action. The Rule itself has a configuration property that can hold arbitrary key/value pairs, just like the Actions, Triggers and Conditions, so I’d argue that it would be better to attach the rule source code in the rule “configuration” itself. Then we’d get rid of the erroneous association between the rule Action and the rule source code.

No, not to “understand” their rule, to do that, they should look at their file and the documentation for the helper library they use. I see two potential “uses” in addition to the 3 you have listed:

To see how the rule they make ends up working in OH. They can see what ends up as Triggers and Conditions, which will tell them when the Action will be run, as reflected by OH’s log/events. Since the helper libraries “extracts” parts of this and turnes it into Triggers and (potentially) Conditions, it might be helpful to see the results of this when you write a rule in a particular way.
To help refresh your memory about what a particular rules does. You might be accessing the system remotely or from a device where you don’t have the rule files available, and the name isn’t enough that you remember exactly what the rule does. Maybe you are trying to figure out why something is/isn’t happening (when you think it shouldn’t/should) while not in your “development environment”.

I don’t see the point in that. The rule exists and have Trigger(s) and potentially Condition(s). These can be shown since I don’t think an “opaque” Trigger or Condition exists yet. It’s only the “opaque” Actions that can’t be shown. Any other Actions on the rule can also be shown. The way SimpleRule is written, you can only have one “opaque” Action, so if you want to have more Actions, they will have to be “non-opaque” (a scripted Action or one of the “built in” ones).

What I do agree with is that the content of the “opaque” Actions shouldn’t be attempted to be shown, because it can’t be represented correctly.

Nadahar · February 26, 2025, 4:39pm

I’ve already address this, it’s not about “getting insight”, it’s about using the system when you’re not in your “development environment”.

I’ll just add that it seems to me like there is a need for this information out there, or we wouldn’t have the “solution” we have today, where the rule source code is presented as a scripted Action with the Trigger(s) and Condition(s) are injected into the start of the code as comments. This will always be “better represented” by opening the files in your “development environment”, but people still seems to want to get the information through the UI, so the only logical reason I can see is that they want to access this information when their “primary source” isn’t available to them.

rlkoshak · February 26, 2025, 5:41pm

And we are asserting that you are failing on that last part. The restored functionality is not less confusing. It’s just as confusing if not more confusing than it is now.

Nadahar · February 26, 2025, 6:01pm

That’s your opinion, and although I disagree with that, that’s not the main point. The point is that the current “shortcut” ruins the functionality of all read-only rules, like file-based rules, only to cater for one specific case: File-based scripting language rules made using the helper libraries in way that that the helper libraries can deal with in that they can successfully extract the relevant source.

The cost of this is that it breaks every other case of read-only rules. To me, this is obviously wrong, and I’ve been trying to find a reasonable compromise where you can restore functionality for read-only rules while maintaining the “convenience” for users of this specific case.

I honestly don’t understand the resistance, with my suggested changes, with the configuration option to maintain this “shortcut” for jsr223 based rules, there would be no practical difference except for a little icon on the script screen. No extra button presses.

So, when you assert that “I’m failing” with this, I can only conclude that you think any change whatsoever is wrong, and that the system should remain broken for read-only rules.

rlkoshak · February 26, 2025, 6:35pm

There is nothing ruined about read-only rules. They are fully functional and can do everything they are designed to be able to do.

What are these use cases? What other read only rules do we have or have planned?

then you can handle the flood of postings to the forum of users freaking out thinking that they are doing something wrong or worse, thinking this is the first move toward removal of file based rules entirely. I won’t do it.

I’ve recommended two other approaches, both of which are huge changes in how it currently works. Yet I’m resistant to change?

You’ve done this before. If I fundamentally disagree with you, it must be because I am completely resistant to change. It can’t possibly be that I possess knowledge you don’t, have experience you don’t, and based on that I come to different conclusions. No, I must be obstinate.

I guess you’ve chased me out of yet another thread.

Thank you for your contributions. I wish you luck in your future endeavors. I can do nothing more here.

Nadahar · February 26, 2025, 7:33pm

You see it that way because you equate read-only rules with JavaScript or Ruby file-based rules implemented using SimpleRule. I don’t - I claim that those are two different things entirely.

In principle, that can be a lot of things, but to list what I can think of:

Rules DSL rules that you can place in conf/rules.
YAML/JSON based rules that I have made support for.
Scripting language file-based rules that doesn’t use SimpleRule, doesn’t use a helper library, doesn’t have a helper library that inserts the “source code” (e.g Groovy) or where the helper libraray doesn’t manage to extract the “source code” (e.g JS RuleBuilder).
Add-on provided rules created programatically or retrieved from some other storage (database, cloud, file system)

I have no intention of causing such a situation. This why I’m trying to do this whole feedback/discussion thing, instead of just submitting whatever I see fit “take it or leave it”. I’m completely open to change how this is indicated, in fact, I made a suggestion yesterday that haven’t gotten a single comment. What I’ve been “holding on to” is that it should be indicated in some way that what you see isn’t the actual Action.

I must have missed one of them then, because the only suggeston I’m aware of is the suggestion to block jsr223 rules from being viewed from the UI. I don’t think that’s an improvement or necessary, I think there are way to make it work.

It has nothing to do with disagreeing with me, it has to do with now aknowledging the things I’m trying to explain and only repeating previous arguments like the “pieces I added to the puzzle” don’t exist.

I also never said “obstinate” or anything like that, I just get the impression that you don’t want the “problem” I’m trying to solve, solved. Maybe it’s because you don’t see it as a problem.

Also, I wasn’t just addressing you, it was just as much aimed at @jimtng.

Please don’t do that. It is not my intention or wish, and I need the few of you who bothers to give feedback. I don’t want to spend time making something that will never be used because it misses major points in how people use the system.

It’s just that at this point, we seem to have gotten stuck in a situation where you give me “the responsibility” for having caused things that has nothing to do with me, that is caused by how the system is designed, how the helper libraries do things, SimpleRule design decisions etc, which has all been hidden by making this “shortcut” to directly open read-only rules in the script editor. Every attempt to mitigate this I can come up with is just deemed as “wrong”, “incorrect”, “scare people” etc., which makes me feel that what you both want is just for everything to stay like it is.

What would be useful for me was suggestions for how this could be done without causing the “negative side effects” that you percieve from the way I’ve attempted to mitigate the already existing “unfortunate” factors that has caused read-only rules to be “broken” in the UI in the first place.

rlkoshak · February 26, 2025, 8:31pm

That is neither of my suggestions.
Suggestion 1:

don’t show any of the code from these rules
still show the rule exists
still allow controlling of it
show the name
show the description
show the tags
if possible, show the path to the file that generated the rule
don’t show anything else

Suggestion 2:

show all the code; dump the full contents of the file that created the rule into what ever gets shown

Neither suggestion is to not show anything from these rules at all in the UI.

No. I don’t blame you or anyone really for how OH is now. But making changes to user facing parts of OH does have to do with you. You are proposing user facing changes and those changes need to actually consider the ways that users operate OH.

I don’t care if that’s inconsistent with the code. I don’t care if it blocks off future use cases which might get implemented some day. I don’t care that it’s a hack. I care about the end user’s experience.

Breaking these rules up and showing them like a FullRule is a worse user experience. Scary warnings that what you see isn’t going to be executed is a worse user experience.

These rules are different so continue to treat them differently. I don’t care that it’s all a “hack”. Jumping to a Script editor and showing some code with comments to cover the triggers and such isn’t a lot better than presenting it as a full rule except with warnings that “the code you see is not the code that runs” (then why show it to me?). So do not mistake my pushing back as thinking it’s all great as it works now.

I say either cut our losses and just don’t show the actual code at all. If you can’t tell what the rule does from the name, description, uid and tag then you need to use these to document your rules better anyway. If you write your rules in MainUI, you are not doing much with MainUI → Settings → Rules anyway.

Or go big and show all the code (i.e. every line of code in the file that created that rule). Then you capture every thing outside the rule and everything that went into the creation of the rule. And it’s shown exactly as it’s been written so it will be what the user knows and understands. There’s nothing that gets missed and even stuff outside the rule itself is shown.

If it’s worth showing part of the rule, it’s better to show everything that went into the rule. If it’s not worth it, then don’t show any of it. Either way it’s better than sometimes showing only some of the rule and other times failing to do so.

Those are my recommendations.

Or leave it be and move on to something else and come back to this at a later date.

Nadahar · February 26, 2025, 9:01pm

@jimtng As promised, I’ve finally managed to put together what I consider a “complex rule” using SimpleRule:

$scriptExtension.importPreset('RuleSupport')
$scriptExtension.importPreset('RuleSimple')

class MyComplexRule < SimpleRule
  def execute(_mod, _inputs)
    notify("Window was opened")
  end
end

s_rule = MyComplexRule.new
s_rule.set_triggers([
        TriggerBuilder.create
                      .with_id('aTimerTrigger')
                      .with_type_uid('timer.GenericCronTrigger')
                      .with_configuration(Configuration.new({ 'cronExpression' => '0 0 10-18 * * ? *' }))
                      .build,
        TriggerBuilder.create
                      .with_id('systemStart')
                      .with_type_uid('core.SystemStartlevelTrigger')
                      .with_configuration(Configuration.new({ 'startlevel' => 100 }))
                      .build,
        TriggerBuilder.create
                      .with_id('windowOpened')
                      .with_type_uid('core.ItemStateChangeTrigger')
                      .with_configuration(Configuration.new({ 'itemName' => 'OpenWindowActive', 'state' => 'ON' })) 
                      .build
    ])
s_rule.set_conditions([
        ConditionBuilder.create
                        .with_id('timeRange')
                        .with_type_uid('core.TimeOfDayCondition')
                        .with_configuration(Configuration.new({ 'startTime' => '14:00', 'endTime' => '16:23' }))
                        .build,
        ConditionBuilder.create
                        .with_id('ephemeris')
                        .with_type_uid('ephemeris.NotHolidayCondition')
                        .build
    ])
s_rule.set_actions([
        ActionBuilder.create
                     .with_id('preventHeating')
                     .with_type_uid('core.ItemCommandAction')
                     .with_configuration(Configuration.new({ 'itemName' => 'LimitedHeatingPower', 'command' => '0' }))
                     .build,
        ActionBuilder.create
                     .with_id('announce')
                     .with_type_uid('script.ScriptAction')
                     .with_configuration(Configuration.new({ 'type' => 'application/x-ruby', 'script' => 'Voice.say "The window is open, heating turned off"' }))
                     .build
    ])
added_rule = $automationManager.add_rule(s_rule)

With “my code”, this is displayed on the rule page as this (The UID, name and tags are there, but are scrolled out of view):

With “standard OH” today, this rule is shown as this:

In addition, all the modules in the rule page are clickable, so you can get more information if you want to, e.g

(when clicking the scripted action (not the “opaque” one)):

I think the UI does a much better job at displaying such rules than the current solution.