Thanks for the explanations, they got me thinking (dangerous I know).
And, based on the information you have supplied; it occurs to me me that to implement such a feature on Hubitat would be no different from any other rule storing and using 2 variables. For each rule using the "changed from to [Y]" trigger mode, you'd have one variable for the current value, and one for the previous value and that's it. No need to track states your rules don't care about.
As the trigger mode only cares if the current and previous value in the 2 variables matches those it is monitoring for, (and we don't even care about the order because it is logically already taken care of); computationally I'd have thought this is no more difficult than the "Relative" compare function you've implemented.
The implication of your idea to make this a native trigger would be that every rule would have to track prior mode, for all modes. Yet, only a tiny fraction of all rules would need this functionality.
Nothing is "difficult", it's all a matter of programming. The question becomes where to put which functionality. A trigger that compares the value carried in an event to something only applies to rules that needs that comparison, and every such trigger would need a comparison to be of value -- e.g. simply knowing that temperature changed is of virtually no value by itself. So it makes sense for a temperature trigger to compute something that pretty much every temperature trigger needs. Even for mode triggers, only a tiny fraction would need to compare to a saved prior mode. So it makes no sense for this computation to find its way into triggers.
Not at all, it would only need to be implemented on a rule by rule basis when a "changed from to [Y]" trigger mode is selected by the user.
I'm not suggesting a sledgehammer approach here, I'm suggesting a precision scalpel. There is absolutely no need to track any extra variables/states unless users specifically choose the "changed from to [Y]" trigger mode for a rule.
I see the "changed from to [Y]" trigger mode" logic looking something like this (forgive my crude pseudo-code):
User_Variable_X = [user defined "From_state"]
User_Variable_Y = [user defined "To_state"]
Local_Variable_X = Device_Previous_State
Local_Variable_Y = Device_Current_State
Note: re Device_State - I'm not sure how the changed trigger mode is tracked now, this enhanced mode could reuse some of the same logic)
IF [Device_State] = *changed* THEN copy [Local_Variable_Y] to [Local_Variable_X] AND copy [Device_State] to [Local_Variable_Y]
IF [Local_Variable_X] = [User_Variable_X] AND [Local_Variable_Y] = [User_Variable_Y] THEN *trigger Rule*
END IF
END IF
I realize I'm not a developer and the above may be oversimplified, but if you are only tracking extra variables when someone chooses to use the "changed from to [Y]" trigger mode, then you aren't adding any overheads when these aren't in use.
I just thought of something else that would be a possible cleaner way to do this. Let’s use my example of having different actions for the mode HOME when transitioning from AWAY and SLEEP.
For the Home rule the trigger could be Mode is Away and the first action could be Wait for event Mode is Home. Keeping in mind that this just creates a temporary event subscription and will reset any time the rule is triggered.
The wait condition as the very first action essentially puts this conditional item as the trigger and behaves like a trigger (event subscription)
I wonder what the hub overheads would be like using our 2 different approaches? ie Would there be lower overheads on rules with enhanced triggers or lower overheads with a number of triggered rules sitting there waiting for things to happen?
Well one would be a temporary event trigger (so the same as another trigger in any rule) the other would be an additional system variable with additional logic to manage it as well as additional logic that has to be run inside of Rule Machine, which is written in groovy and as I understand it is an interpreted language not compiled, so each line matters
So in that case I would see the "changed from to [Y]" trigger mode working the same way, it would use the * Changed * logic to wait for an event (in this case a state change) and then run its logic.
That is certainly a good approach and I'll use that.
However if Hubitat would like to lower the barrier of entry to RM, for those not used to thinking like a developer, some additional trigger options that take care of that type of logic might be helpful.
This one rule could handle all of the specific pairs of mode transitions you are interested in, by adding ELSE-IF sections for other pairs, e.g. ELSE-IF(PreviousMode = Night AND Mode is Away) ...
I don't understand why you think everything you want to do should be an addition to RM, when it will do what you want already. There isn't some huge efficiency gain to be had here, and the app complexity is disfavorable for adding more features when there is already a way to do it.
So you've implemented my idea as an Action ... nice.
Maybe I've been spoiled by other automation systems that had this as a trigger. In all seriousness, it took discussions across 2 days before you came up with a solution to my scenario and your first solution didn't work, and you are a developer. Imagine how hard it is for non-developers to figure out that solution as they arent used to dealing with that kind of logic.
Well, there is if you consider re-usability - RM's UI does not have any ability to copy and paste code blocks between rules for reuse so you have to build that logic and the variables from scratch every time. Yes, you can clone rules but then you need to tear apart the clone and rebuild it.
Imo, it comes down to ease of use and speed - as an end-user (and this is where I'm coming from), having a "changed from to [Y]" trigger mode greatly simplifies many automation scenarios and not just rules that work with House Mode changes - it also lowers the barrier to entry for non-developers.
Maybe Im on my own wanting this so perhaps Hubitat should have an Official Poll to gauge interest. if the community says no, I'll hop back in my box.
We are simply going to have to agree to disagree. So far, every suggestion you have had fails my basic criteria for changing RM, and your arguments don't impress me. Suggestions to add things to RM that can already be done, or that fundamentally change its conceptual model, are going to fail.
People do come up with suggestions for things to be done, that do get done. But, so far, you're missing the target...
Let me ask this instead, even though I don’t have a dog in this hunt.
Could something like this be added to an app like mode manager. Maybe a section called mode transitions (turn on these switches when moving from X to Y)
(I know that anything can be added to anything, it’s just code. so I guess for the sake of argument would that be a better place for a feature like this)
Note: I don’t use mode manager so I don’t really know what options there might be.
That is because you don't seem willing to consider this from an end-user point of view - just because something can be done already, doesn't mean it cant be improved upon. RM is very powerful and I appreciate that, it is however a UX nightmare.
Not to get us dragged down to the timeout room, but it is my opinion that Hubitat is not a word processor and RM is the most complex part of the system.
By that I mean, when I open a new word processor for the first time I expect that I will know how most of it functions, but I don’t get upset/disappointed when the macro function has a different syntax/input method/structure than I am used to.
Hubitat by isn’t something you see everyday and it is still fairly usable without too much research
