I’m checking out of this thread too. I think the most effective way to deal with this is through pr review
Ok, it was suggeston 1 was referring to, although I might have misunderstood it slightly.
Suggestion 2 is close to what I’m thinking might be the best approach, although I don’t want to hide the UI view for the cases where that’s useful. But, showing the full source code of the rule in addition would IMO be a better solution, and present it as such, not as “the action”. As I briefly mentioned yesterday, it could be done by making a third tab, which was the “default view”, for rules that have “attached source”. But, it would have to be up to the helper libraries to supply this source, there’s nothing OH in itself can do to provide/find it.
Or, that’s not entirely true, because as far as I know, the scripting add-ons use OH’s “file watch” service to pick up the files, so OH actually informs the add-on that a file exist. But, for OH to make the connection between a file it serves to the add on, and the rules it gets back is a very tall order. I don’t actually think there’s a way to do that, that would work in anything but the “most optimal” situations. You’d have to look at the timing between when you served the file and when you got a rule back or something like that, and it would obviously break for multi-rule sources. But, for all intents and purposes, I would say that the responsiblity for providing the source would have to be with the helper libraries.
That’s fair and I agree with that.
That’s where we differ somewhat. Not that I don’t care about the end user’s experience, I absolutely think that is essential. But, I think it should also work for end users that don’t “conform” to a “narrow use pattern”, and I think it matters if it blocks other possibilities - because those other possibilities will never be taken into use if they are “blocked” by how the system works.
Forget the scary warnings, I never meant for them to be scary, and if that’s the way you perceive them, others will probably too and thus they aren’t suitable.
They aren’t really that different, the only “real” difference is that the code for the action isn’t available (to OH/the UI).
That is an interesting approach in that it would enable RuleBuilder rules also to be shown for exaple. But, are you confident that this wouldn’t confuse people further? On the other hand, as long as it’s made clear that it’s the “rule source code”, it shouldn’t really be that confusing - especially since usually the person viewing it is the person who wrote it.
Still, I think this would have to be up to the helper library. I mean, to submit the whole source, parts of it or nothing. It’s very difficult for OH to handle this.
Except that it will never make it to a PR review if I’m not reasonably confident that I have something that is wanted. There’s a lot of formalia required for a PR, all kind of details that must be correct, foratting, references, documentation etc, that I’m not willing to do unless I believe it has a fair chance.
I see no reason why this can’t be implemented by the helper libraries, or not as the maintainers of those libraries choose. I think it makes the most sense overall.
But if that’s the path, then we are pretty much back where we started. MainUI will show whatever code is submitted. When you open such a rule, you jump straight to the code submitted by the helper library. The only difference is we take out the stuff in MainUI to put in the triggers and comments.
You’ve created a full rule programmatically using simple rule. That’s all.
The main problem I see is your unwillingness to receive feedback and make changes. Instead you continue to insist on your original point, refusing to change.
Instead of addressing feedback, you try to invalidate and “disprove” them.
So I see no point in me discussing further here. Someone else might see it differently or can explain it better. It is also quite possible I’m wrong and I can’t see it.
Perhaps a pr review will be more effective because we can address specific points and request specific changes
Furthermore, it will be reviewed by the maintainers. My opinion remains the same but I’m not a maintainer for webui.
No, there’s one, as I see it, major difference. It won’t “block” other “type” of rules from working in the UI. As an added bonus, it should be less “confusion” as to what you actually see, even if I’m the only one in the world that got confused by the current setup.
I’m very much willing to make changes, but not when the “change” is to reverse everything I try to do. That makes my whole attempt pointless.
I’ve said from the moment I introduced this that I didn’t expect it to be “acceptable” for everybody, but some times it’s easier to show something as a starting point than to try to explain “everything” from scratch.
No, I’ve created a rule programatically that displays very poorly with today’s solution, and that I think displays in a much more meaningful way with my proposed changed. That was what I set out to do and what I meant when I used the term “complex rule”, meaning one with more than a single Trigger and a single Action.
So you created one example that is not in common use, which displays perfectly with your proposed changes, yet this same proposed changes would cause all existing file-based rules to display weird and wrong?
What kind of improvement is that?
How do you propose making EXISTING file-based rules to show up correctly and nicely with your proposed changes?
You will not be able to show the correct “Action” in your proposed changes, because as you said, such actions are “java byte code”.
You will also not be able to show the correct conditions in most cases for JRuby, and in some cases you will not be able to show the correct triggers.
So in the end what is the point? So that you can correctly show one example implementation of SimpleRule that:
- Nobody uses
- Is not even what SimpleRules were meant for
You are arguing over the semantics of how conditions are actually implemented (using openhab ConditionHandler vs in the “action code”) and missing the bigger picture. A condition is a condition regardless of how it’s actually implemented.
If my file-based rule says the condition needs to call a lambda, what would you display? An “Opaque condition”? How is that helpful vs showing the actual code in the actual lambda?
Can you separate your changes/additions for displaying your new file-based templates, from the existing file-based simple rule which should still go to ScriptEditor?
If you want to then later change the existing file-based simplerule then treat that as a separate “enhancements” and not try to mix it with the template-file handling.
If everything that you have done was simply about showing file-based simplerule in the fullrule page, then yes, I’d say that the proposal, from what I have seen so far, should be rejected.
No, as far as I know, I’ve not proposed to show existing SimpleRule implentations weird or wrong.
That’s one benefit of the rules being created every time you start OH: If you change how the helper libraries embed their “source information”, it will work just as well on existing rules, since they go through “the creation process” every time.
That I don’t understand. I don’t know everything that’s going on in the helper libraries, but unless then use what I call “opaque” triggers and conditions, I the UI can show them all. There is a difference between a Rule Condition and a conditional expression in the Action. The conditional expression is still a part of the Action. I don’t understand why you refuse to see the difference. The Rule Condition will prevent the Action from being executed, the other one won’t.
No, the point is to be able to show all rules and not be limited to some very specific conditions, or things won’t work. I agree that this probably isn’t a very common use case for SimpleRule, but that’s also a two-way street, because the helper libraries could very well choose to create rules where the details are organized differently then they currently are - but probably won’t do that if the result just looks “like a bug” in the UI.
You also seem to forget that the current solution already doesn’t work for RuleBuilder, which I assume is in relatively wide use.
Again, no, I disagree with that. A condition might have the same end result (as to whether something is “changed” by the rule) if it’s made as a Condition or as a part of the Action, but the way you “get there” is different. Don’t you think it matters at all that the log and the events reports that an Action is executed say every minute 24/7, only to be aborted in the Action in the majority of cases? It makes the event system and log pointless for such rules, it creates a lot of spam, and it might have performance consequences. That said, I suspect that the SimpleRule way of running Actions isn’t the worst performance-wise, without knowing for sure of course. I for one, would, regardless of how the performance of running this Action is, very much prefer to have a rule that is only executed when it actually should, within the limits of what’s possible with the current Conditions and Triggers of course. Only when it’s not possible to “express the condition” you want with those, would I want the Action to do the evaluation and abort.
I’m still confused by this. Are you saying that “opaque conditions” actually exists, or are you still referring to evaluations within the Action? If it’s an evaluation within the Action, it wouldn’t be shown as a Condition, regardless of if it’s a SimpleRule or not. There is nothing “wrong” with that as I see it, I have such rules myself (where some of the evaluation for whether the “action” of the Action should be carried out is in the Action itself), and I don’t expect those evaluations to show up as Conditions.
Yes and no. It would be possible to separate the two if you accept that you can’t regenerate file-based rule stubs as with other rules, but I can’t quite see why that’s a good idea. It would also cause extra work for me.
There lies the problem. I’m not seeing what you’re seeing, and vice versa.
If you think that’s possible, then this would need to be done beforehand.
No they cannot always do it. It can only be done for some very limited cases.
Yet your solution will not add anything other than showing the triggers in a different format.
Try showing the following rules in your proposed scheme.
rule "Execute when item changed to a range of numbers, from a range of numbers" do
changed Alarm_Mode, from: 8..10, to: 12..14
run { logger.info("Alarm Mode Updated") }
end
rule "Execute when item state is changed from an odd number, to an even number" do
changed Alarm_Mode, from: proc { |from| from.odd? }, to: proc {|to| to.even? }
run { logger.info("Alarm Mode Updated") }
end
rule "Execute when item state is changed to something matching a regex" do
changed Alarm_Mode, to: /armed/
run { logger.info("Alarm armed") }
end
rule "Execute rule when item is changed for specified duration" do
changed Closet_Door, to: CLOSED, for: 10.seconds
run do
Closet_Light.off
end
end
rule "Execute rule when item is changed for specified duration" do
changed Alarm_Mode, for: -> { Alarm_Delay.state.to_i.seconds }
run { logger.info("Alarm Mode Updated") }
end
rule "Set OutsideDimmer to 50% if LightSwitch turned on and OtherSwitch is also ON and Door is closed" do
changed LightSwitch, to: ON
run { OutsideDimmer << 50 }
not_if { OtherSwitch.on? }
only_if { Door.closed? }
end
rule 'Turn switch ON or OFF based on value of another switch' do
on_load
run { TestSwitch << ON }
otherwise { TestSwitch << OFF }
only_if { OtherSwitch.on? }
end
rule "Between guard" do
changed MotionSensor, to: OPEN
between "6:05".."14:05:05" # Include end
run { Light.on }
end
rule "Between guard" do
changed MotionSensor, to: OPEN
between LocalTime.of(6, 5)..LocalTime.of(14, 15, 5)
run { Light.on }
end
rule 'Log an entry if started between March 9th and April 10ths' do
on_load
run { logger.info ("Started at #{Time.now}")}
between '03-09'..'04-10'
end
rule "Door alert" do
changed Door_State
debounce_for 10.minutes
only_if { Door_State.open? }
run { Notification.send("The Door has been open for 10 minutes!") }
end
rule "motion sensor triggered" do
changed MotionSensor.members, to: :OPEN
triggered do |item|
logger.info("#{item.name} detected motion")
end
end
rule 'Set Dark switch at sunrise and sunset' do
channel 'astro:sun:home:rise#event', attach: OFF
channel 'astro:sun:home:set#event', attach: ON
run { |event| Dark << event.attachment }
end
# This should be displayed in same way, not in raw cron
rule "Daily" do
every :day, at: '5:15'
run do
Light.on
end
end
rule "item added" do
item_added
run do |event|
logger.info("#{event.item.name} added.")
end
end
rule 'Delay sleeps between execution elements' do
on_load
run { logger.info("Sleeping") }
delay 5.seconds
run { logger.info("Awake") }
end
Just to clarify, when I’m talking about “opaque” Triggers and “opaque” Conditions, I’m talking about implentations of SimpleTriggerHandler and SimpleConditionHandler. They are not used by SimpleRule by default, and I don’t know enough about what is and isn’t possible through jsr223, but I think it should be possible to do it without further modifications to Core. I just haven’t seen anything that indicates that it is done.
It’s absolutely possible, I myself can figure out how to change how the Ruby helper library embeds the inforation. I haven’t looked at the JavaScript helper library since I can’t get the JavaScript add-on to work, but changing how what is currently attached is attached is easy. What it comes to adding source for RuleBuilder, I don’t know the details, but I would assume that it should be possible too, if you accept that you have to include the whole source, not limited to that particular rule.
That’s not true if the helper library attaches the whole source for RuleBuilder. I assume that the reason it’s “currently not supported” is that they haven’t found a way to separate out just the code for that particular rule. But, maybe there’s another problem, I can’t know for sure. One thing is sure: For the source for the rule to be shown, the source has to be attached to/embedded in the rule in some way.
I’ll try after finishing some other things.
no. You’re the one who wants to do things “properly”, why stop now?
Then make it so first.
I’ll disregard these as unreasonable. You are saying that to make any improvements to how the UI handles rules, I have to first solve all current issues with the helper libraries, solvable or not. It’s the same as saying “No change unless you can make horses fly”.
I haven’t made my latest “proposed scheme” yet, so I can’t test them there. But, with the current code, these display just fine as far as I’m concerned, except the one with the lambda. As you already know, only what is registered as Conditions is shown as conditions, and what is evaluated in the Action is not shown unless you look at “the source”.
The same goes for the Triggers. Most of them display just fine, there are some without any Trigger (the on_load ones). I assume that on_load is a “special cue” to the the Ruby add-on to execute the Action as soon as the rule has been registered, so that RuleEngine triggers the action “manually”, just as if you click “Run now” from the UI. After that they probably set up a timer that runs code at intervals without the rule being triggered. None of these are Triggers though, so I don’t know how you’d expect the UI to show them as Triggers when they aren’t registered as such. The intervals could have been (and should have been IMO) triggers though, I don’t know why it’s chosen to use timers instead.
But more generally, when you allow add-ons to run arbitrary code, like is done here, you can’t expect OH to “report on” these things if it’s not informed about it. I just don’t get why you think this is a reason to not show the rules in the UI. As I’ve said before, these “tricks” doesn’t just “hide” from the UI, they “hide” from OH as a whole, events, logs, REST API, other add-ons. In short, they “hide” from the whole system - so if such techniques are used, don’t expect OH reflect it.
Regarding the labda, the reason it’s “displayed badly” is that the helper library has made a cryptic and very long “label” for it:
configuration: {}
triggers:
- id: 0dc6c516-930d-4be2-be8a-d607bac313e8
label: "Alarm_Mode changed for #<Proc:0x3690c7a8
C:\\Repos\\Java\\openHAB\\openhab-distro\\launch\\app\\runtime\\conf\\aut\
omation\\ruby\\multirule.rb:24 (lambda)>"
configuration:
itemName: Alarm_Mode
type: core.ItemStateChangeTrigger
conditions: []
actions:
- inputs: {}
id: "1"
configuration:
privId: i20
type: application/x-ruby
script: |2
rule "Execute rule when item is changed for specified duration" do
changed Alarm_Mode, for: -> { Alarm_Delay.state.to_i.seconds }
run { logger.info("Alarm Mode Updated") }
end
type: jsr223.ScriptedAction
I don’t think Alarm_Mode changed for #<Proc:0x3690c7a8 C:\\Repos\\Java\\openHAB\\openhab-distro\\launch\\app\\runtime\\conf\\automation\\ruby\\multirule.rb:24 (lambda)> is an appropriate label for a Trigger, and it is shown “equally cryptic” in the current “show as script” solution:
# Triggers:
# - When Alarm_Mode changed for #<Proc:0x3690c7a8 C:\Repos\Java\openHAB\openhab-distro\launch\app\runtime\conf\automation\ruby\multirule.rb:24 (lambda)>
It does seem rather harsh, doesn’t it? However, what you’re proposing is:
“Just change it now anyway even though it will not look correct, missing important information and doesn’t really represent the actual rule.” - THAT seems harsh to me.
So far the only information you can gather and display is the inaccurate triggers.
Whereas the conditions and the actual actions will show incorrect stuff.
Yet you insist that this broken display is what we should have instead of the current ScriptEditor, which nobody is complaining about.
All I’m asking is to make your proposed change not to have a negative impact.
There again lies the problem.
Please show me how each and every one of them would look. I have selected them specifically because I think they will not show up properly.
I cannot just take your word for it because clearly our opinions differ. What you say “just fine” may not be what I would consider “fine”.
Fair enough, that can be easily “prettified” to say Alarm_Mode changed for #<Proc> but what is Proc? That’s what I meant by missing details, rendering this screen rather useless.
If this was my system and I saw this, I would still need to make that extra click to see the raw code to understand what it does.
Guess what, that’s what the Script Editor does now. One click, boom, I can see everything without having to wonder or having to click again.
What makes it so impossible to just leave it to go straight to Script Editor like it is now?
We’ve been debating about this for DAYS! I believe you’ve gotten all the information I can offer.
Because it breaks other things. But, at no point have I suggested that you won’t get to see the source as you do in the script editor today, so I really don’t understand why it’s so problematic to also allow other things to work.
Again, no. I’ve never said that. I’ve said “in addition to”. At no point have I suggested to remove the “source” content shown in the script editor. What I didn’t like was that it is presented as an Action when it’s not, but that doesn’t mean that I think the information shouldn’t be there.
There are 16 rules and it would require multiple screenshots per rule to show everything. If you want to see how it looks, check out and build this and this. But, it shows exactly what you’d expect. Only the Triggers and “Opaque Action”. Clicking the “Opaque Action” opens the script editor with the source for now. One rule has two Triggers. None have any Conditions.
By the way, my system has become very sluggish after I installed these rules. This happens from time to time anyway, so I don’t claim that these rules are the cause, but the timing was “suspicious”. I’ll have to reboot to see if things clear up, but that means that I have to open up all the applications I use, place the windows where I want them, open up consoles, cd to the proper locations, wait for Eclipse to do all kind of “preparations” and refreshing - so I’m procrastinating…
edit: I did the reboot, and it sees like the rules had nothing to do with the “sluggishness”.
But your confusion largely comes from the fact that you don’t actually use any of this. You’ve tried to look at the code and back your way into how it should be used. You never went to the docs and approached it from the perspective of how it’s intended to be used. How it’s currently used. Questions around your initial ignorance that it was even possible to write a rule in a .js file in $OH_CONF/automation.js is evidence of that.
And your changes come from that perspective. @jimtng and I come from the opposite direction. How does the documentation say these are supposed to be written and used and how have they been used in the many years they have been available? What and how are various features exposed to the end users? What are the sorts of questions and problems users report and ask for help with?
From that perspective, making changes to how these rules are shown in MainUI do not make sense. They will never show everything correctly every time. They present the rule in a way different from how current users think about their rules. And it’s all in support of use cases that do not exist today and may never exist.
Having slept on it, I think that it really should be the job of the Automation add-on and helper libraries to decide what to show. These are the parts of OH that have the best knowledge about what is and is not relevant and what is or is not possible to show. Which is exactly how it’s shown today.
I have not changed my opinion. MainUI should therefore either show none of the code or it should show what ever the helper library publishes.
Because from the end user’s perspective and for all intents and purposes these are conditions. They are added to their rule syntactically the same as “real” Conditions. They do the same job as a “real” Condition. In every way that matters to the end user, it is a “real” Condition. It adds confusion to show these differently.
I don’t think so actually. Most seem to prefer JSRule.
The way you get there doesn’t matter. That’s what I meant about this all being pedantic.
It hasn’t been a problem up until now.
These are not included in the events.log by default in the first place . And I’ve not tested it but it’s my understanting that the rule transition from IDLE to RUNNING (or what ever state it goes to) happens with “real” Conditions too. The Conditions do not and have never been meant to keep the rule from running at all. They prevent the Actions of the rule from running but the rule still needs to run to evaluate the Conditions. The rule is still triggered.
The way it’s exposed to the end user it’s a “condition” (there is no such thing to the end users of an “opaque condition”). Whether it’s implemented separately or implemented as part of an Action or in some other way is not exposed to them.
- I never really asked for that. I’m not sure I really see the need for that.
- The rule created from a template will will always be a managed FullRule anyway and never a SimpleRule in the first place.
If it means not confusing existing users I’ve no problem giving that up. I would have imagined the way this would work would be the end user modifies the “stub” which causes the regeneration of the rule in the first place. Regenerating the rule from the UI for a file based “stub” would be inconsistant with how every other file based config works.
So if that’s what is driving this, I think that’s the wrong path too.
The “they” in this case is largely @jimtng. He is the one of the maintainers of the jRuby add-on and helper library. He knows far more about how all of this works and how it is used by end users in practice than either of us.
Note that he has silenced this thread now.
And yet, per the syntax for how it’s written and how the end users thinks about their own code, the lambda is a Condition. Not showing it because of some technicality on how it’s represented in OH core adds confusion.
What specifically does it break? If it’s the ability to click a button in MainUI to regenerate a FullRule based off of a template and what you are calling a “stub” I don’t like that name because it’s really just defining the properties, not a bunch of generated code to build upon) that’s already the wrong approach. The managed rule should be regenerated upon modifying either the template or upon modifying the stub files. I’d probably choose modification of the stub file.
If a user is already shown a desire to work in files, they should not be forced into the UI to do this.
Anyway, I’m not going to respond on this thread anymore. You seem convinced “if only they understood” we would agree with your approach. You can’t seem to understand that we do understand and we still do not agree with your approach.
We are at an impasse. Nothing more can be accomplished.
I would absolutely know these things better if I used them, but I’m touching so many different areas here that it would take a lot for me to be familiar with them all. Also, about the .js file was a misunderstanding, because when I talked about “file-based rules”, I was talking about “standard rules” in JSON format - which I couldn’t get to work.
What that mean in reality is that “the die has been cast”, that whatever solution has been chosen is the “right one” because that’s what people have gotten used to. I’m aware of that effect, which is why I try to make changes that don’t “intrude” on people’s habits more than they must to achieve their goal. I can’t quite see that if they are taken to a page similar to the last one I posted or the current page when they click their rule will be much of a disruption - and it will enable other use cases for those that want that.
I agree with that in the sense that it must be up to the helper libraries (the add-ons aren’t really involved in this) to post whatever they “see fit”, also since I can’t see any other way from a technical perspective. But, when the current solution does is to show the code as an Action, and in the process it “hides” the “rule page” so that it’s unavailable. That’s actually all I’m trying to rectify, and it does this for all read-only rules, even when it makes no sense (there is no “source” attached to the rule).
If you open one of these in your existing UI, and then modify the URL by replacing “scripts” with “rules” in the address bar, you will see that the “rule page” is there. It’s just been “hidden” by the “shortcut” that directly opens the Action for read-only rules.
settings/scripts/<rule UID> → /settings/rules/<rule UID>
I do think that that by presenting it as the “source” instead of the Action, it’s “less confusing” to for exaple post the whole source file for RuleBuilder rules.
They do the same job if you look at the rule in isolation. But, if you use events for anything, or read the log, they aren’t the same. Performance wise they aren’t necessarily the same either.
I guess people differ on such matters, but for me, these things absolutely matter also as a user. I need to understand what happens when I use something, or I won’t “trust” it. It won’t make sense to me if different mechanisms are presented as the same, when this isn’t reflected by how the system behaves (logs, events). But, I realize that I’m probably in the minority in this respect. Still, I doubt I’m the only one that function like this, so it’s not completely irrelevant or “just pedantic”.
How can you judge that? By the lack of complaints on the forum? I have had lots and lots of things that I’ve struggled with or been frustrated over with OH that I haven’t posted anywhere. In short, I don’t post unless I think there’s some hope that there is a “solution” that is within reach. It would very much bother me if my log was spammed like this, as it obscures the things I want to see.
I’ll have to triple check that, but that’s not my understanding from the studying I’ve done of RuleEngine this far. The trigger is “triggered” before the condition is evaluated yes, but the action is never executed as far as I remember, and it would be very strange to me if that resulted in a RUNNING state for the rule.
I wasn’t asking about the end-user experience here, but the technical solution. The way @jimtng described it made me unsure if these “opaque conditions” were actuall in use. But, afer getting his file of “test rules” I don’t think it is.
I do. If I’m ever to use rule templates, it would have to be via “file stubs”, as I don’t use “managed” rules.
Yes, but again, the criteria isn’t whether it’s a SimpleRule or not - it’s whether the rule is read-only. Which means that any rule not being managed will be shown solely as a script - even when there’s no script involved so you just see a blank screen.
I know that he’s very involved with the JRuby helper library, I’ve seen him all over the commits. I was referring the the JavaScript helper library and RuleBuilder.
I’ve explained this time and time again. It breaks all read-only rules that aren’t SimpleRules that are made specifically in the way the helper library intended, so that the helper library has attached the “source”.
It is regenerated if you modify the stub file, but not if you modify the template, as that would break the “independence” of the rule after instantiation. If you update the template, and want to update the resulting rules, it’s not natural that you go and edit all the stubs to get them to regenerate.