Recently I actually modified this rule by replacing "wait for event : elapsed time"
statements with cancelable Delays. The reason is/was: I don't want to
retrigger Delays if the Delay already started.
Actually rule is working as expected but apparently I introduced a problem.
What I did wrong and how to fix the problem?
Not causing your issue (I don't think) but you should move the time constraint to a required expression. Right now, the rule will run every time the lux changes. Since you don't care about lux changes outside your time window, the required expression would verify you are in the time window before actually processing the rule.
I'm wondering if having both sensors as a trigger is causing the rule to be trigger twice at the same time. Meaning both sensors see a change in light because of a cloud and it causes the rule to kick off twice within a few milliseconds of each other.
For everyone else (who isn't in the beta group where this was first discussed), the issue occurs if you have a delay inside an IF THEN and another execution of the rule starts while that delay is still pending and then that IF THEN is reached again (regardless of whether it evaluates true or false; just if it is reached at all--it has to be evaluated either way). There isn't inherently anything wrong with a delay inside these conditional actions, just if/when they are reached again. You would have gotten an error previously, too (this phrasing is new in Rule 5.1), just a more cryptic one.
An easy way to prevent rule re-entry is to set Private Boolean false as your first action, set it true as your last action, and add a required expression that Private Boolean is true. There are other options, depending on what you want, Breaking this into multiple rules might also make things easier to work with.
Oh, but in my case this will not be easy.
I do need the rule to retrigger on each event.
What I was trying to achieve - if delay already started nothing should happen
but delay itself must not restarted.
I guess, I have to create a set of rules for achieving what I want.
This is LEAST desirable option because maintaining set of rules is much
harder than one single rule. But it is what it is.
By "you," I meant literally the OP, who indeed is a member of that group and should be able to see the post. Later in my post, I provided a summary for anyone else.
The #1 complaint people seem to have about multiple rules is just how the Apps page looks, which is a different issue--but one you could maybe address with a custom app if you truly want something all-in-one. Otherwise, it looks like the bulk of your actions are different depending on the devices involved (often a sign that multiple rules are a better approach in the first place), so I'm guessing the total number of actions you'll end up creating in the end will be about the same. You can name them something logical so they're grouped together if this is the concern. As mentioned in the other thread, a single rule is a single app and only has one place to store state variables and whatnot, which are shared among all executions of the app, so with a lot of things in one rule, you'll need to be careful about when they trigger and whatnot.
Yes, custom app could be much better solution. I agree 100+% with this statement.
From the other side IF-THEN-ELSE logic is near 100% sufficient for creating
relatively complex but very intuitive Home Automation rules.
In a past I played with many different platforms starting with X10 TimeCommander,
Insteon ISY, etc. so I know what I am talking about.
From the other side, writing custom app for non professional SW developer is
not an easy task. You have to know many things like what functions are available,
how to call them, etc. So learning curve and many trials are imminent.
But my dream is - to see RM_XYZ is an Custom App Compiler instead of what it
is now. The input better to be the same "as is". To my eyes it is very intuitive
and relatively simple. But if RM_XYZ can create and instantiate a Custom App
instead what it does now it will be significant step forward.
Yes, am talking about RM_XYZ as a Compiler for the Custom App with
exactly the same input as it is now. Plus maintaining the RM as a Compiler
should be much easier than maintaining it as giant App with a lot of Child Apps.
Given your background, which I am familiar with because it gets mentioned in nearly every thread, I suspect you would find writing a custom app easy and a better match for your desires than what you are doing now (and what you propose). Rule Machine (and other apps) exists so you don't have to do this, but it's still an option.
As for how: Hubitat's developer docs will have some additional content soon, but in the meantime, there are lots of example apps both here and in the HubitatPublic GitHub repo. Any tutorials on the "classic" SmartThings Groovy environment would also be very similar. And you don't have to do it in your own. Just as they are with Rule Machine and other apps, many in the community are happy to help with development questions, too. Just ask if you get stuck!
If you don't mind (but PLEASE do not spend a lot of your valuable time) could you please
convert my RM Rule above into Custom App? If needed I can provide any additional info.
This will be a very good starting point for me for writing something custom.
Honestly, I have no idea what your rule is supposed to do--or, even if interpreted literally based on your rule actions provided, if it would truly work as you expect 100% of the time. So, I might start with a plain English description of your goal, then someone can work from there.
I have questions...probably more for my edification than anything else. I loosely re-wrote your rule in pseudo to get rid of the white noise. Commented in-line with the questions.
IF ("bed lux" <= 15) THEN
Cancel delayed
Set "bed light" to 100
ELSE-IF ('balcony lux' <= 1400 AND 'bed lux' <= 20) THEN
// Is this actually needed? Isn't the bed light going to get turned on in a minute regardless? Unless the LUX changes during the 1 minute wait I suppose.
IF ('bed light' is OFF) THEN
Cancel delayed
END-IF
Delay 1:00
Set 'bed light' to 100
ELSE-IF ('balcony lux' >= 2000 OR 'bed lux' >= 24) THEN
// Same as above. Is this actually needed? Isn't the bed light going to get turned off after three minutes regardless? Unless the LUX changes during the 1 minute wait I suppose.
IF ('bed light' is ON) THEN
Cancel delayed
END-IF
Delay 3:00
OFF: 'bed light'
END-IF
My read is that your use-case is:
If it's dark in the bedroom, turn the bed light on. (Early dawn/late dusk/thick cloud coverage)
If a little light and stays that way for at least a minute and the light is off, turn the light on. (Late dusk/thick cloud coverage)
If it's pretty bright and stays that way for three minutes, turn the light off.
Well, than forget about it.
I thought all these IF-THAN-ELSE statements somewhat self explanatory.
At least for me this works most of the time (of course, with good naming convention).
In short, all these game with delays is to deal with relatively fast passing clouds.
My previous rule had "wait for event : elapsed time" as a delays.
These delays are restarting on every trigger. I tried to start delay (separate
for ON and OFF conditions) only once. This actually worked as expected
by produced errors. Errors looks like benign but I don't like to see any errors.
I hope this will work as expected without producing any errors.
Of course, more testing is required.
@bertabcd1234 any comments and criticism on my creation is very welcome.
I have few more similar rules for controlling my curtains and I need to know
how stupid I am before rushing to modify all of them.
Thank you in advanced.
Required Expression time between 7:55am and 8:05am
Making the trigger to be if time is 8am
Then the rule would something like,
Repeat every (pick a time frame, say 15 minutes) (stoppable)
If (Illumance of BD MultisSensor is <= Illum_int_low) THEN
Else-IF ...
....
End-IF
Until (Time is between Sunset and 8am)
Nice thing about Rule Machine is there is 5,000+ ways to do something. Bad thing about Rule Machine is there is 5000+ ways to do something. This also cuts down on the number of times the rule is run so that every single change in lux does not cause the re-evaluation of the rule, it uses time of day snapshots instead.
"Stupid" = without knowledge. Depending on the subject, everyone is stupid in something.
I can not count how many times I have re-written my rules after learning something new or a different way of thinking about the issue. I would suggest that is part of the learning curve. Some of these rules are very similar to yours.