Just comparing the two, there is a slight difference between the two. I think Bruce's rule "respawns" every 15 seconds, since it uses a periodic trigger and I think yours is persistent since it uses a repeat. @bravenel, is that right? Also, does that even make a difference? Could having one instance of a rule open for that long (by using a repeat) be a possible cause of a slow-down? It's logical that it would since closing the app and reopening it would "clean" up any mess left behind but we all know logic doesn't always apply. I'd test this out myself but my only color bulb is in my outside front door light and I'd rather not have my neighbors thinking I'm crazy (well, crazier than they already do 
)
This is not really what is going on.
Both periodic trigger (and all triggers) and repeat bring up an instance of the app with a specific entry point. Both periodic and repeat are using the scheduler to do this. Scheduled jobs carry some context data as well. So for both, the instance wakes up at the entry point, reads (or not) the context data, and then does something. In the case of periodic it runs all of the Actions. In the case of repeat it runs all of the Actions starting right after the repeat action itself (except for the while loop case, where it starts with the conditional-if-repeat). Those actions run until they hit something that causes the rule to exit -- in both of these apps that is a delay. The delay schedules another wake up of the app with an entry point and context data, and then the app instance exits. When the scheduled job for the delay is fired, an app instance comes up with the specified entry point, and starts running the actions just after the delay action.
Every time an app instance "wakes up" it follows the pattern above. Many things cause an app instance to exit, including anything with a delay. Many things cause an app instance to be created and entered, including trigger events and scheduled jobs. As discussed, those scheduled jobs can come from many different sources. Trigger events can come from the Trigger Events of the rule or Wait for Events/Conditions in the Actions. All such "wake ups" create a new app instance, and do something depending on the entry point and possibly the scheduled context data. Trigger events carry their own context data as well, in the event itself, things like the device, the event value, JSON data, etc.
So there is no such thing as a "persistent" app.
i will pipe up and say that i have run into issues with repeats if the trigger is not managed appropriately. i had a rule that ran calculations on a variable in a while-loop, but i had triggered it manually while testing it. it was supposed to fire every 10min, but because i also had manually triggered it I seemed to have two instances that were running causing it to fire twice as fast.
the solution was to just use a periodic trigger.
Okay. Thanks for the detailed explination. I'm not sure I followed it 100% but ultimately, do you think that one being periodic and the other being a repeat could be a reason one caused an issue and the other didn't?
No, I don't. The only thing weird about his rule is the extra (superfluous) delay at the end. That causes the rule to wake up right after the next repeat, and do nothing but exit. I may mess around with that problem to see if there is something weird going on, but I doubt it.
Meanwhile, my red-white-blue light is going along nicely, hub is working, house is working, dashboard is working, development is working... Now, @waynespringer79, tell me you had no custom apps or drivers running that could have caused the slowdown... 
1 Like
No, as I stated this was a completely brand new hub (replacement for when my previous hub bricked). Literally the only device on it was the HankRGBW bulb (after noticing missed transistions I added an aeotec range extender) and the only app was Rule Machine.
This hub did perform better than my regular house hub, but it still experienced missed transistions from one color to the next everyday after a few hours of running and out of the 10 days I ran the rule, the hub completely locked up (UI unaccessble by morning) probably 2 or 3 days out of the 10.
The very first day I tried this on my home hub, and it locked up within 3 hours of running. My home hub user apps include: HubConnect, Ambient Weather API, NST Manager, and NOAA Weather Alerts, thats it.
Only Drivers (Not relating to the above apps) are the Roku TV drivers.
Pretty basic really.
It's a mystery to me, unless it has to do with the extra delay at the end. I will test that.
I thought it was odd as well. But like I previously posted if possible for you I would test it with that specific HankRGBW bulb, as Everytime I've freshly included that device I noticed communication issues (not mesh related) that appeared to occur within the first 3-5 days of including into the mesh.
If I had any other color bulb I would test this and see if the problem goes away myself, but I don't
I'm trying to figure out how RM4 deals with threading parallel usage of GVs.
For example:
- say you have Rule X that speaks and pushes a message. The content of the message itself has a couple global variables in it: 'blah blah blah %GV1% blah blah %GV2% blah blah'. But Rule X doesn't set the values of these GVs.
- instead, you have a handful of other rules--we'll call them Rules A, B, and C--that each set their own values for GV1 and GV2 and then call Rule X to deliver the message
In such a scenario, will Rule X fire three times and do I have to worry about the values of GV1/GV2 getting jumbled across A, B, and C?
Global variables are maintained by the parent app. Each rule calls the parent app (Rule Machine) to either set the value or fetch the current value. Each GV is kept in atomic state. This effectively serializes the setting of the variable, and means that when a rule fetches the value, it gets the most recently set value. This removes the possibility of parallel instances getting different values.
So in your case, if Rule A sets GV1 and calls Rule X, Rule X is going to get that value as it will run as the same instance of Rule A (unless there is an intervening delay). Likewise, B and C will each get the value they set into Rule X.
There could be indeterminacy if A, B and C are running simultaneously.
Thanks, that makes sense.
I'm interpreting "simultaneous", to mean literally at the same moment or to the nearest millisecond (?). If A, B, and C all call Rule X one millisecond apart, then theoretically I'm good even if it takes Rule X another ten milliseconds to do its thing?
"Indeterminacy" means it can't guarantee what happens. The hub platform software supports multi-threading, so rules can and do run simultaneously. One millisecond here or there is not really possible to predict. Odds are pretty high that you won't have a problem.
Lol, I was/am clear about what you meant by indeterminacy. And I do appreciate that there's no way to control or even know what the ultimate sequencing of A, B, and C's firing of Rule X would be. All I was asking about was the how much time, broadly speaking, constitutes "simultaneous", as you meant it in your note.
An hour apart? No worry.
A minute apart? Still not a worry.
A second? Still okay I'd guess.
A better way for me to have asked the question perhaps...... how close would you imagine the firing of A, B, and C have to get before you'd start worrying about threading logjams.......
I wouldnāt worry about it with any timing. I donāt really know the actual answer to your question. I think the odds of it not working are very low. I also think that the proof will be in the pudding. 
Fair enough. I'll give it try! 
Maybe the real lesson here is that you guys should have a chat-bot reply to all questions like mine that says, "Gee I don't know, why don't you try it and let the rest of us know how it goes." lol
2 Likes
How can we pass variables between hubs? Oh, never mind, have it working. 
Ok. I am about 2 months into Hubitat and I'm loving it. I'm getting a little deeper into Rules Machine and I have a specific logic question that I can't seem to solve on my own. Here is the situation. I have a pantry door that is a contact sensor that I currently have a Simple Lighting Rule setup to Turn On the light in the pantry when the door opens, and off when it closes.
However, the majority of my family manages to leave the pantry door open on a regular basis so I a Rules Machine rule to turn off the pantry light after 15 minutes if the switch was turned on.
The problem I'm running into is that I don't have anything cancelling the delay if the door closes again and/or the light is turned off manually. So I will have times I go into the panty and the light turns on as the door opens and the light will turn off since the delay is still in place. I've thought about using cancelled delayed actions, but since that would cancel all delays, I don't think that will work. I have this issue on a couple other doors lights in the house that are in similar situations. I use this example to solve this in multiple places. How do I cancel a specific delay or emulate that behavior?
You might as well combine the Simple Lighting into the rule. Like this:
Trigger Event: Pantry door *changes*
Actions:
IF(Pantry door open) THEN
On: Pantry light
Off: Pantry light delayed by 15:00 cancelable
ELSE
Off: Pantry light
Cancel delayed actions
END-IF
This will turn on the pantry light when the door opens, and turn it off when the door closes, just like your Simple Lighting rule. If the door is left open, the light will turn off after 15 minutes. If the door closes during that 15 minutes, it will turn off the light, and cancel the delayed off.
Only problem is getting the light back on if the door has been left open for more than 15 minutes.
1 Like
Awesome. Thanks for the quick response. Iāll setup that rule. Wonāt that cancel any other actions I have delayed if I do it that way? Is there a way to avoid that?
Good question!
