Thank you for relaying your experience, it mirrors mine.
@bravenel we shouldn't need to RTFM to understand how simple functions work ... when clear labelling will do it instead.
Documentation is always helpful, but giving two discrete functions the same name, is asking to create confusion.
While the following Release Track & Advisory example is a from a much larger company with a much broader spectrum of product and a huge system critical user base needing to know the impact of firmware changes -
I like the concept of calling out the Breaking Changes well ahead of a release.
I am amazed by how much HE staff is able to move the ball forward without "Breaking Changes". While VERY appreciated I wonder how much that is catering to the legacy while holding the platform back and is therefore unsustainable?
https://help.axis.com/en-us/axis-os#upcoming-breaking-changes
I honestly don't have a problem with Hubitat pulling out this feature - I actually agree with Bruce, despite being one of the original vocal folk requesting it.
The proposed method of removal should be low impact, and I always read the release notes, so personally I'd not have missed the comms covering it.
Me too as I had ended up with my share of "stuck" PB's. But now that this alternative has been deemed similarly at risk of the same there's no way I'd want to continue using it for two reasons-
as others have noted, it almost seems better seeing your PB is outta sync than NOT seeing but having to check or discover the alternative locking mechanism is outta sync.
if you want to follow along the firmware Track that agglomerates the best learnings /mendings and evolution of the product then it's best to not purposely and prematurely get yourself into the Cobol Syndrome (reliance on a dead end track that works but handicaps you long term).
Personally, if I had developed this option to PBs and it turned out to be a bad decision I'd be saying one or both of the following:
a) sorry for the inconvenience...but similar issues as seen with PBs call for us to take this recently introduced RM feature completely out of the system by xyz date (release) ...so if you wish to continue on our update path please unwind where you've used it because it will not work in any new or old rules after x.x.y release,
and
b) we will continue to look at the PB function for ways to strengthen it to make it more immune to the problems experienced as we realize they are real for many of you even as we remind you to keep your Rules simple.
I'm just impressed that the system and workload is such that allowing the rules that have already adopted this to continue is possible without teeing up problems for HE support or those users in the future.
Yeah, I have a few rules I need to go back and undo this...yeah I wish I could find them all without lifting the hood...and yeah, I have wished for that capability before as well.
The delay in function-1 is applicable only to this specific action. I will not delay the remaining actions. But function-2 will delay them.
What I learned in a hard way the PB will not prevent fast following triggers (say, from multiple MS in the same area). In some cases the PB effects could be delayed by a second. Logs clearly showed this delay. To be removed option works much better but it looks like it created some sort o hidden problems.
Finally I am thinking about creating Virtual Trigger custom app but unfortunately this is not an easy task for my not sw developer brain. At least I have an idea.
This is a HUGE oversight / assumption on my part. Like seeing a bunch of tools on a bench and going "oh, that'll work". No WONDER I've had confusing results from time to time. So now it makes me want to find every place I used this.
EDIT ADD: *On a broader note: It really is the case that you gotta be thinking beyond basic serial programming in this environment and if you aren't use to that (from other experience) you'll be subject to making mistakes you don't realize or recognize. I know this is stating-the-obvious for a large number of folk that are in the Community. But those aren't the only folk we want to sell this platform to. *
And this is a prime reason for KISS on this platform. Actually, you don't "gotta be thinking beyond basic serial programming" if you keep things simple. When you opt for unnecessary complexity, you are asking for trouble that you can't diagnose or easily fix. It's the nature of the beast. From my perspective, Rule Machine is a needed tool, but a tool that can be misused.
I can't emphasize this enough: KEEP IT SIMPLE STUPID and you won't have problems, and you won't need PBs to prevent stepping on yourself.
Ok, let's take a simple rule with a changed trigger on the switch attribute of a device. I realize that the attribute could possibly change between the trigger event and the time the attribute is queried, leading to the wrong branch of the condition being executed.
So following KISS, we create two separate rules, one with a trigger on the on event and one with a trigger on the off event. Now, what happens if the switch is turned on and off very quickly? Does the platform guarantee that the off event won't fire and trigger the "off" rule until the rule processing the on event completes? I'd be very surprised if that were the case, but happy to learn that events are serialized in that manner.
If not, don't you end up with the same or similar concurrency issues? What if the on rule is far more complex than the off rule? If the off rule fires while the on rule is still processing, how is that better than a single changed rule being invoked multiple times concurrently? Normally this would be solved by a mutex or critical section, but we don't have those constructs.
What's the KISS recommendation here?
I 100+% agree with KISS aproach. But at least in my few cases relatively complex logic is a must. I am trying hard (and basically achieved this goal) to create a real hands/commands free nstansta. This is impossible without creating relatively complex logic.
I donāt see how you can completely avoid using whatever muti-triggering prevention mechanism. In some cases retriggering is desirable but in many cases it is not.
Before HE I was using ISY-994. This platform naturally infoced KISS. There was not Nested IFs,
first IF automatically referenced to Events but could have relatively complex logic. Retriggering did not create mulple instances of the rule but simply reset all scheduled timers/waits.
I really like RM and this my only work horse for all my automations. Very robust/reliable preventing of undesired retriggering happens to be a BIG problem. Finally I figured out how to get it !00% reliable. The trigger for the rule is a Virtual Switch which is turned on by external simple rule(s) but turned off by very last action in triggered rule. This mechanisms is woking very well except now I cannot use a Required Expression and Conditional Trigger because rule always must run in order to reset switch.
I have an idea for a separate (outside the rm) Virtual Trigger apllicatin.
Like RM this app should/must have an ability to select Trggers and create a Required Expression. On a virst run it should/must create a Virtual Trigger device (basically Virtual Switch with different name). When Trigger Event happens it should evaluate a Required Expression anf if the expression is true turn on Virtual Trigger. Unlike RM the Required Expression must be evaluated immediately when Trigger Event happens. Also Virtual Trigger must be turned off on hub reboot.
I went through Groovy examples and few tutorials but realized my current programming skills is not good for creating this simple on a first look custom app.
It's not possible to answer this question absent knowledge of the environment and what's going on. For a switch that is human operated, timing is unlikely to be an issue (humans aren't computer fast). For a switch that is itself driven by automations, who knows?
Whatl I can say from responding to posts here is that the only people who have issues with concurrency are ones pushing complexity. I can't tell you how to avoid complexity in any specific answer. As I said above somewhere, you guys in this thread have vastly more complicated things going on with your automations than I have ever had personally. I just don't go there -- and I don't have concurrency problems AT ALL, never have. That's really all I can tell you.
Sounds to me as though you are pushing the complexity around, and...
My god, do you realize how complex and difficult this is?
In my case, nothing is going on really. I just saw your post about avoiding the use of changed triggers and then conditionals on the value of the event. I'm doing that in a number of rules, and far as I know I'm not having problems with them. But I'm also not opposed to rewriting things to be more "correct". So my question is more about guidance than solving a specific issue. I do have some "complex" stuff, but complexity is subjective.
Would it be possible someday to add some sort of mutex-like thing to RM? (please be kind... 
). There are times when complexity can only be reduced so much. Things like a mutex object could be hidden behind some developer or "advanced" mode to as to not create an undue support burden.
Unfortunately yes.
In theory this app looks very simple:
Trigger Event happened.
IF (RequiredExpression == true) then
{
Turn On Virtual Trigger;
}
Practically it should not be too difficult (I guess) to create a very narrow app for the specific Trigger(s) and Logic for the specific Device(s). But make everything user selectable RM-like not a trivial task. From the other side, creating an individual app for each case will be impractical and therefore useless.
But using a Virtual Switch (set by a simple rule and reset by triggered rule) as a rule trigger so far works 100% reliable.
I don't know, but I'm pretty sure it would only increase the number of people stepping all over themselves unnecessarily. If you aren't having problems, that's great. There is no "correct". The reason I mention *changed* as a possible problem is if you put that on a very chatty device, you could get multiple instances.
It's really not appropriate for you to hijack this topic with your UI preferences. The topic is about concurrency problems, and you want to make it about your UI opinions. Sorry, but I have zero interest in your suggestions. It's plainly obvious that you personally know what these things mean, so you're just trolling me with your posts. Please stop, it's neither helpful nor respectful.
I started the topic, so surely I can hihack my own topic.
You are the one blaming us for not understanding RM functions, an Iām just requesting you help us by using more descriptive naming of them.
You are also the one who accused me of being arrogant. I may not be able to code, but I have real life experience working with end users to make system intuitive and efficient.
Pissing contest. done.....
Download the Hubitat app
