??
You can only access what is built in. It is not an open source project.
You didn't even ask a question or give examples of what here, so I am not sure how we could even answer it.
I would start a new thread with what you are trying to do, what devices you are using, and see if people have suggestions.
Hubitat's Rule Machine is the Rule Machine that was originally written for ST. The founders got so tired of ST problems that they created their own hub. 
However, it has undergone significant changes since then, perhaps the most notable being Rule 4.0, released about a year ago. (Another change is that it is now a closed-source part of the Hubitat platform. If the license for the old code allows, you could probably port it yourself, but I think you'll end up liking the latest Hubitat version better once you figure it out--as with the older versions, there is some learning to do.) If you mean webCoRE, that's an entirely different app, though a port is also maintained for Hubitat (some people used to have problems with it here and I probably wouldn't recommend starting there, but the current version seems to work well for most people).
I would echo the suggestion above to make a thread about a specific automation you are trying to create. Many people in the community, just like ST, are happy to assist. I'd also suggest reading the docs for the latest Rule version, which contain a lot of examples. And don't feel tempted to head straight for RM; Hubitat has lots of built-in apps designed to create common automations without the need to create your own rules (or apps). Best of luck!
RM Feature Request:
Ok, assuming I'm not missing something obvious (very possible), It would be great if there was an additional Trigger Mode called changed from [X] to [Y] in the RM, Simple Rules, and Notifications Apps.
This would be very useful for House Mode changes in particular - 2 scenarios that I would personally use this trigger mode in are as follows:
There are already some things that have a changed to type state (eg XYZ Presence "Arrives") but I think adding the ability to use precise "changed from to" triggers would add even more power to an already powerful rule ecosystem.
It might, (and I could be talking out of my hat here), even make rules, like my Mode change eg above, use less overheads due to a reduction in rule complexity.
I want to say this has been talked about. From what I remember someone suggested setting up a rule that looks like this
Trigger: Mode Changes
Action:
Set Global Variable to Mode -> Delay 5 min
The way the global variable would be whatever the last mode was for 5 min. This is also a bit crude.
What I do is I have a rule for setting the house to HOME from SLEEP and a rule for setting the house to HOME from AWAY. Both of these rules pause themselves when done.
When I enter Sleep or Home I resume the rule that will be needed
And that is what I'd like to avoid - acting on state changes would have to be the most powerful part of Automation, and being able to act on precise "from to" changes just adds an additional precision tool to the toolkit.
This may be of interest
Hmm, interesting indeed - personally I'd settle for an extra trigger mode in the built-in apps. As frustrating as I find the RM UI, I do like its power and this would be the icing on the cake for me.
Once again, this is simply pushing conditional actions and other functionality into triggers where they don't belong. The idea misses that a trigger is something caused by a primitive event, not the computational consequence of conditional logic and state maintenance.
If you want to be notified of Home to Away, as suggested you'd have to maintain a current mode variable, and test that with a conditional action following a trigger on Away. This is exactly what your proposed extension would have to do.
Notice that when the event 'Mode becomes Away' happens, at that point in time the previous mode is not known, even by the hub. So something would have to remember it. That something could be done with a simple rule as suggested above.
Ah ok, I assumed that HE tracked and logged state changes like Home Assistant does (and Reactor on Vera).
Device events are kept in the database, and prior events can be looked up (not in RM, but in an app). I don't know if it is possible to look at past location events (mode change is a location event). In any case, RM (and other built-in apps) do not have past event lookup features.
Hubitat's computational model is stateless. One can create state information through code, but it's not what the hub is designed to do.
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.
Am I making sense?
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?
There is no overhead at all with a Wait for Event. The rule waiting isn't running anymore. When the event happens, it wakes up to process it.
@Hasty1: Good idea. This is an elegant solution to the problem.
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
Thanks @bravenel! I have been spending a lot of time simplifying rules and looking for better solutions!
I should probably learn groovy...but I just don’t have the patience these days
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.
I would set the trigger as the “From” and then set the first action to wait for event “TO”
Download the Hubitat app
