I'm trying to go through all my old WC rules and turn them into RM rules where possible.
So far these are two things I can't work out how to replicate - could someone wiser than me let me know how they are done in RM:
currentEventDevice - in WC you can have a rule where the condition is any of a big list of devices meets a certain criteria, then the action will be with the current event device (the device that met the criteria). There are a few rules where I use this. So far the only option I can see in RM is to create a different rule for each device (but that is not practical in some cases)
changes away from trigger. It is sometimes necessary to know when the mode changes away from a particular mode specifically. This is different than the mode just being anything else - it is triggered when the mode moves away from a specific mode.. how do I replicate this?
Variables are not possible in RM, so this would need to be separate rules.
If your use case allows you to use a rule (instead of a trigger), you can use the NOT operator to negate the mode you want to change away from. For example, if you wanted to initiate something when you changed away from Home mode, you can select a condition of "Mode is Home", then in the rule set it up as "NOT(Mode is Home)".
If you need a trigger, this won't work, but unless you are wanting to stack multiple triggers, a rule will allow for the same functionality as a trigger.
Unfortunately this is not practical in some cases (e.g. a rule which reports which battery devices have under 10% left) you'd have to make a separate rule for every one - in my house that will be over 30 by the time Ive finished the move from ST
I don't think this will work because there are more than 2 modes. So if I use NOT home. The the condition would be true if it moved from any other mode to any other mode. However I am looking specifically for moving away from Home.
I wonder if anyone has tried moving the original CoRE (not webcore) to Hubitat. I suspect that may port over better?
@bravenel Either way, if Hubitat's long term vision is to be the best at automation - it needs to have a rule builder that is at least as good as WebCore in terms of functionality, intuitiveness and user experience. As revolutionary as RM was when it first came out on ST (and it was a total game changer), we have now been spoilt by what we were able to achieve with WC and going back for the trade off of a local, no lag hub is still a bitter pill to swallow!
HSM will monitor batteries for you in a single rule. And if you just want notifications, I forgot there are %device% and %value% variables available, so you can set several devices up to trigger something and the use those variables in the notification.
Actions are only executed when the rule changes state from true to false or vice versa, so it would only run when changing from home to something else. You have to forget what you know about webcore, rule machine works differently. The rule will be False only when you are in home mode, and will only change from False to True when you go from Home to anything else. This will do exactly what you are asking for.
RM can do about 99% of what webcore can do. The pieces that are missing are so far away from what most home automation needs to be that they don't really fall into the automation category IMO. Again, in order to be successful in RM you have to unlearn what you learned in WC. They are similar concepts but very different implementations. I had similar feelings when I first looked at RM but after working with it for a little bit I actually started to prefer RM. I went back a few weeks ago to work on a piston to send Harmony events from ST to HE (which isn't necessary anymore) and the WC interface felt slow and clunky to me.
In regards to the original core...RM blows it away. I can see some merit in the WC vs RM comparison, but core to RM....no way.
That is great - didn't know about that, thank you! - and will be very useful.. but can you trigger actions from RM as well from there? (I'm not at home right now so cannot check)
Good point - I didnt think of that
I still don't think this is true (FYI I was using RM on ST before Core and moved over twice before coming back to using it) There a number of things that can't be done or if they can be done are extremely convoluted to do with RM and involve multiple rules and virtual devices which is just very messy.
AFAIK you can't trigger RM actions from HSM, but the device and value variables are available in RM too, so you could create something functionally identical in RM and use it to trigger other actions. What are you wanting to do?
Well just for the times where I'm looking for a particular condition in many devices (there are a few instances where this will be useful) and want to create an action with device from that set that changes the truth to True.
A different issue (as you seem to have some great solutions!) - If I wanted to have actions occur when something changes from one specific state to another specific state (so in the case of the mode example above it would be actions to occur when Mode A changes to Mode B - but in this case specifically only to occur when A changes to B and not any other modes in the mix. I can think of a way to do this but it involves 2 rules and use of a virtual device - is there a more elegant solution?
For the second one, I think it would require 2 rules but you could do it without the virtual device.
If you want to trigger only when you change from A to B, for example:
Rule 1, Trigger type
Trigger: Mode changes to B
Actions: whatever you want to happen
Restrictions: Enable/Disable with Private Boolean
Rule 2: Trigger type
Condition & Restriction: Mode is A
Actions when true: Set Private Boolean True for Rule 1
Actions when False: Delay x seconds (this may need to vary depending on if you have delayed actions in rule 1), set Private Boolean False for Rule 1
I'll think on this one to see if I can come up with something more efficient.
Thanks for that - good to eliminate the use of the virtual device - that is definitely an improvement. You can see though what I mean by convoluted.. in WC that would be one line "when x changes to y". There are quite a lot of these instances in the rules I'm bringing over.. so what will end up happening is I have many hundreds of rules and it will become very messy. It's still better to have this situation than the lag with ST - but I read somewhere that Hubitat's aim was to become no.1 for Automation specifically.. and if this is the case - I think they need to produce something that is less convoluted, functional, and more of a pleasure to use.
For the first one its basically the same as the battery one but for other devices so as an example say I have a load of motion sensors - and I want to monitor if they get stuck - so I make a rule that monitors 10 motion sensors to look to see if their motion has been constantly active for an hour. I would then want to notify or perform an action (e.g. custom command like refresh) to be sent to that specific sensor that was stuck. I don't think this is possible without a rule for each currently
