I just updated to 2.3.9.135, and WOW this is a big exciting update! Well done Hubitat team!
I started playing with the new Visual Rules Builder, and this is a very nice step that will help out a lot of people that aren't as text-oriented as us developers. (I've never minded Rule Machine, but can understand why non-devs find it confusing.)
I have a couple feature requests to throw on the backlog. (And if I just missed these, and they already exist, please let me know.)
In Rule Machine, we could trigger if a device attribute *changed*. I haven't seen that in here yet. For example, if I want to trigger when a door locks or unlocks, I had to explicitly add the two triggers with an OR arrow between them.
Could you add IF-THEN-ELSE logic? This would be often used hand-in-hand with the *changed*\ trigger. (If I unlock, do this. If I lock, do this.)
It seems I could solve this by just making two visual rules, but thought I'd put it out there.
The initial release of Visual Rules Builder is targeting the first-time-use demographic, I believe. It's not (initially) intended to grow to be a replacement for ANY of the current rule engine. Time will tell of course, but for today, two+ rules are the intended solution, as you noted.
IMHO the 'changed' test is easier to understand than having two rules. It's also an extremely handy test. I know they want to keep it simple, but to me that seems an odd place to draw the line.
There's no testing (branching) in VRB. And that means no "changed" because you'd end up with an "On True" rule plus an "On False" rule... which is what exists.
I have been messing around with this just a little bit. I don't know if I can comment; many are very touchy lately. I really like what I see so far. I think this is a great jumping-off point for more complicated rules.
I would like to see a "flow or step through" so you can see what the rule is called and why. Better yet, a virtual simulation. Thus, it isn't "activated" that can simulate what it will do, as close to RW as possible. Once you have the way you think, slide it into production.
I have done too much with it yet.
One little thing that I had seen was if you have multiple triggers. You select presence: user1, user2; everyone or all; and then the state. The box should state everyone user1 and user2; instead, it shouldn't be user1 or user2. If you have either one, then it should be OR. Easier to read and step through when looking at the rules.
I recognize that the intent of this new app is for beginners and I respect that. I was initially very excited to see this until I realized that was the target use. While I applaud the devs for offering this, I'm disappointed by this choice. If this is just the start and the plan is to eventually make it the equivalent of RM, that's great. In my opinion, this is most needed for complex situations, especially given the somewhat awkward syntax supported by RM. I'm very comfortable with a conventional coding approach to logic, but RM doesn't really do that - at least not without a lot of work. (Unless there's something I'm missing). The way triggers, conditions and actions are created is much more difficult than just writing some simple logic. To me, that's where this visual flow is really needed. It's not that I don't understand RM, it's just that I hate setting up new complex rules because it's a slog and I find the structure more awkward to debug.
I guess I'll go back to trying to learn node red, which seems like the real visual replacement for RM.
At least for 2024. Certainly 2025 and 2026 will bring improvements, but if you want something in 2024, Node-Red is an answer just sitting there. It runs on practically anything you might have always on, because it's just a NodeJS app. I have, over time, had it run on a rPI then a Linux box and finally it runs natively on a headless Mac Mini media player that has spare cycles.
Yeah, I've already got it set up running under HA on a R Pi and I've set up the integration with HE. Just haven't had the cognitive space to dig in and learn it.
It is intentionally fast paced. The pause button will be used a lot if you are trying to follow along. You can also use your browser's speed control to slow it down.
not sure if there is any consolidated thread for this app - but based on the subject it looks like this might be the right place to ask? Anyway here's two feature requests I currently use in the basic rules that I don't see in visual rules... both in Conditions
there is no "only when not disabled by a switch" and
there is only sunrise/sunset or time of day when choosing between two times... on basic you can use between sunrise/set and time of day (for example I use between sunset and 12am)
