I totally agree - the issue is if you have a large number of devices then naming becomes very important especially when there is no way to filter devices just yet (I've suggested a simple tag field in devices). You will end up with longer names though.
In my case I originally forgot to tack on the "Light" on my "Upstairs Master Left Closet" switch and that caused confusion when mucking around with the rules.
This is all very well and good. Back when RM was first implemented, there was no way to remove a setting, so once you'd made a selection, changing part of it would not affect the other parts selected. The advice then, still the advice now, if you're going to mess up a rule by changing parts of it, simply delete the rule and start over.
I understand the issue thoroughly. I have no intention at this time of fixing this "hole" in RM. It is not as simple as you might imagine to fix, as it requires the introduction of a lot of extra logic to know that a setting has changed -- namely, keeping track of every setting and testing every setting selection specifically to detect a change in the setting.
So, to avoid problems such as these, don't do what @erktrek and the rest of you have done. If you want to change something fundamental in a rule, remove the rule.
Yup. I agree though....that's not one I think I would have ever found. Very strange. And I hear you with the longer names. You might try abbreviating things. Once you go to put them in a dashboard, that long name is never going to fit anyway.
Ugh. OK. I'll add that to the other 'features' in RM that make it user unfriendly... Like it not updating the wording on conditions/actions if a device is deleted, etc.
Oh, come on. Cut @bravenel some slack. He is totally justified in saying this one is not getting fixed anytime soon. IMHO I would much rather have him working on new features and fixing some of the other issues with HE than devoting his time to fixing something as minute as this.
Look, I think there are a lot of quirks in RM that make it less user friendly than it should be. That's my opinion. Yours may be different.
And I have the opposite opinion on path forward. I would like to see them NOT add a bunch of new features until the fit and finish improves.
Obviously it is their product, and they will do what they want. Much like feedback voting, seeing known issues, not publishing built in drivers, etc I have a feeling that what they are going to do it different than I would like to see.
Their product, their decision though.
Ha! I just found a very simple fix for this particular issue (changing a capability): Simply freeze the capability once selected.
Like the analogy or not it’s applicable.
There’s no argument to be made for raking up a bunch of little leaf piles so that at some point you can gather up all of those little leaf piles and call it a done job.
I’ve had the good fortune to meet some great coders since the mid 80’s. These folks think long hard about what they are going to do and when they execute, they start and finish.
This new method of move fast and BreakThings (Smartthings), looks just like that poor little fellow who thinks it makes sense to create a bunch of little leaf piles when a small breeze blows.
If Hubitat long term is going to be primally for a geek community then how’s things are working is perfect. If it’s shooting to be something more, better adopts some best practices around how things roll.
This is actually how we are proceeding.
However, Rule Machine is a three year old app, predating the existence of Hubitat. The issue now is how much effort to put into cleaning it up. One learns a lot in three years, and most likely RM would be implemented differently today. Some aspects of it are dated and would benefit from being reworked. The result of such an effort would yield the same functionality it has today, minus some warts. So the question is whether that effort should be the highest priority or not.
Listening to our users my impression is that people are more interested in added functionality than cleaned up warts in RM. What's your take on that?
Boy, do I agree with that!!! I look back even 1 year on how I approached and code things and cringe.
I've already said my piece. I vote for cleaning up warts over new functions.
I think there is a threshold - once you get to a certain point with features its a good idea to look at cleanup otherwise eventually you will spend all your time putting out fires.
Ford was not saying don't listen to any users\customers but instead he was saying be very selective. Watch for and listen to wisdom.
Successful companies that hang around for decades, (which there are few), have both a succinct Vision Statements that inform a clear Mission Statement.
Vision > Best platform for home automation
Mission > Fastest automation execution with user privacy being the most important factor. Or whatever you want to come up with.
With those 2 details nailed down however your ownership team sees fit, then you can determine your priorities. An example of making little leaf piles. If you have a clear Vision and Mission like those examples above, you would never have spent 1 minute of resources on Night View here in the community.
Read up on Herb Kelleher who founded Southwest Airlines and has passed away recently after being successful for many years in a brutal business. Night view is the exact type of detail Kelleher wrote about in the case where an employee came to him about adding a chicken salad sandwich to the in-flight menu.
Rule Machine is probably one of the 3 most important pieces of Home Automation. If it has rough edges, then every single type of user is impacted by this.
What??? There are MANY MANY MANY companies that hang around for decades, and are quite financially successful... Did you mean specifically in the tech industry or something? Even then, I can name 30 off the top of my head in that industry alone...
I completely agree with this, though. The tools used to create simple automations are paramount to an automation system's success.
My 2c...... I might be very wrong but I think most of the “adopters” on board with Hubitat are either coming from ST or from quite strong technical back grounds. As such they’ve had the skills and the patience to get around any ‘warts’ in Rule Machine whilst important features have been added. But times change, as do priorities and I feel new comers to Hubitat will be hoping / expecting, less warts. Hoping to find this ‘new HA platform’ has most of the kinks ironed out.
‘Feature Creep’ is a hard one to reign in !
Ill vote for clearing up RM. This unpredictable behavior and quirkiness is a major impediment to the device being intuitive and predictable. It just feels like sloppy UI coding. Im sure it turns off a lot of non-techies when the darn thing doesnt do what you told it to do until and unless you open and close it a magic number of times. I can't believe it would take more than an afternoon to fix.
I vote for added functionality over RM clean-up. Currently RM does everything I need with no issues.
Until it does not and then you will be stuck and likely frustrated.
I think the concern for me at least is by not addressing issues now you run the risk those items coming back and biting you later. Especially if those issues are old frameworks etc.
The larger the codebase grows the more complex and "locked in" things become, it's harder to troubleshoot, code, QA etc etc. The larger the user base expands the more resources limited only by company size and available $$$ are spent on support issues rather than development.
I do not know how things are being done at H. so am really just expressing my point of view - it's likely a completely different scenario - all the people there, the ones I've communicated with at least seem incredibly smart and dedicated and that's a big plus.
For whatever's it's worth, conditions wording does update when a device is deleted or renamed (assuming the page is refreshed). But Actions has stale UI wording that only updates when you drill down into it.
I have cleaned up the RM Actions UI. Those fixes make the UI wording reflect deleted/renamed devices without having to drill down. This will be in the next release.
The remaining part of RM that needs attention is the Rule Definition. That's my next project, and my plan is to completely rewrite it. The UI for Rule Definition is awful, imo, so a cleaner and easier to use UI is top priority. It's not a lot of code, just demanding code due to the nesting of logic terms.
Meanwhile, some cool new features are coming in the next release -- so there's a balance of clean-up and new functionality.
That's great!!! This has bit me multiple times now.