I highly doubt that.
1 Like
I am surprised to hear this.
What makes you being highly doubt?
Ideal HA platform should be very intuitive
and should not demand any specific skills
(neither SW nor HW/EE) from any users.
Don't you agree with this?
With this part? Sure I agree.
The notion that there is one way to achieve that goal, and itās the way you advocate for, is nonsense, however. Regardless of your professional credentials or past failed attempts to get funding for a home automation platform of your own design.
So yes I meant what I said, your specific needs are not exactly the same as everyone elseās.
1 Like
You probably didn't intend this, but that statement is presumptive and comes across as boorish.
The vast majority of Hubitat users (at least the ones active on the community) have used one or more automation platforms in the past. So, you aren't the only person here who has other points for comparison.
Ergo, while your perspective on this issue is valid for you, its validity or value is practically non-existent for others, for instance, me.
4 Likes
Maybe my English is not quite clear.
(Originally I am from Ukraine and my English is not native language.)
I never meant to say "that there is one way to achieve that goal".
I am really sorry if you (and maybe others) feels this way.
The reason I was thinking about starting my company is very simple.
Many of our friends and guests (some of them are very experienced
SW or HW engineers) who visited my house in Newton, MA and these
days my apartment in FL was very excited to see HA in action.
Their first expression was:
"Yes!, we like this and we want to repeat the same in our house/apartment".
However after I explained what needs to be done (and specifically after
I explained, hub needs some minor programming) ALL of them said:
"No, Thanks, not at this time".
If this was a language or cultural mixup then I apologize as well.
The thing is, Hubitat tries to strike a balance between very powerful automation logic with something like rule machine, and much simpler apps like simple automations or basic rules specifically so that users donāt have to have any programming or coding skills.
It still requires more work than a dead-simple mobile app with extremely limited automation logic capability, which is what many consumers are still expecting these days.
But they do a great job of fulfilling power user needs and trying to make this an actual mass market home automation hub, and thatās only with the built in app/driver experience.
For anyone that has the knowledge, or interest to learn, they also allow users to install custom groovy apps and drivers onto their own hubs. Written by the user, or shared here in the community.
Your criticism re: the click-heavy UI is warranted, and one they have acknowledged is a limiting factor on the overall growth of the platform. But itās partially an artifact of how the platform was created. I have no doubt they will do what they can to improve on it over time.
If youāre interested, this post briefly explains how the idea for Hubitat started as an off-shoot of SmartThings:
1 Like
No problem.
Next time I will try to be more careful with my wording.
Thank you very much on the Hubitat history post.
I do understand why things are done the way how they are.
I have few ideas how Hubitat could be improved.
But I guess, this should be discussed directly with Hubitat developers.
Of course if they have any interest in this discussion.
Thereās a feature request sub-category here. Posts often prompt responses from the devs (as this thread did), though of course thereās no guarantee theyāll accept all requests (or even acknowledge all of them).
But even some of the major changes to the platform have been based on user feedback. Dashboards and the mobile app didnāt even exist early on, as a couple examples (neither is truly needed for home automation but many users asked for both).
1 Like
I second the request for a CASE statement in RM. 
I read that as a pretty hard āno.ā
2 Likes
To the extent this thread represents a feature request for CASE in RM, the answer is no --
I could go on and on about why, as this certainly has been given some thought. But there is no point in dragging all of that out...
3 Likes
That's of course your decision, but that doesn't change the fact that IF you did have that tool in your toolbox, I'd be using it and my rules would be better formed.
OK, I'll bite. Show such a rule that would be "better formed". But only show it if you are prepared for feedback as to how you built the rule the way you did, and are open to suggestions about how else it might be better formed.
2 Likes
Consider a rule with different actions based on the day of the week - I do that to add variation in the times lights go on and off. Yes, I can do that with a heck of an if/then/else tool or write separate rules, which is what I did, so I have nothing to show you. How would you write such a rule?
If you made a rule (or rules), why canāt you share that?
2 Likes
I think you would write some pseudo-code showing what you mean. It doesn't have to be an exact format, but something like this.
- If lights are on for 10 minutes, then do XYZ.
- Else do ABC.
Just something to get your point across.
1 Like
Would you not still have to create separate cases for each day of the week? I don't see how an IF/ELSE-IF... is more complicated (I suppose it could save you one single line/action if you assume that cases automatically "break" as they don't in many languages--Groovy doesn't, but RM isn't Groovy or a language at all, so I suppose anything is possible). Perhaps it would help to demonstrate what you would want (though I think Bruce's position is clear and wouldn't count on it changing either way 
).
This is true in compiled Java (or at least what I understand of Oracle's compiler) and probably most languages that pioneered the use of this statement. However, Groovy allows any value as a case in a switch, not just integers. Further, like in all dynamic Groovy, it's possible for a case to refer to a method, property, or object whose type or even mere existence is not known until runtime--so pretty much any chance of compile-time optimizations compared to an if/else is lost.
The second issue is that Rule Machine is not actually code, and even if they add switch/case to the UI, there is no guarantee of how it would be implemented internally (which could theoretically be the same as IF/ELSE with just a word or two different in the UI).
2 Likes
I sometimes wonder about things like this. I ask myself, "why are they setting their lights (or other things) different everyday?". I always think it is unusual when someone has so many different actions like this. I could see weekday vs weekend, but why every day?
Not picking on you, just curious why you need to do this?
1 Like
Can we get thoughts on my original request before this case statement thing came up. Ability to group rules? I have like four completely independent rules relating to goodnight routines depending on what triggers them to fire, what they do, some are just to flip virtual motion sensors so an Alexa routine can act, etc. It's not a particularly substantive change. It would just be less overwhelming when looking at the list of rules if the four sub rules were set in from the group name or parent rule.
Goodnight Rules
- Alexa goodnight
- Button goodnight
- Goodnight action rule
- Nap notifications rule
Etc.
Not sure I understand - different things happen on different days of the week all the time, don't they??
Sorry, didn't mean to hijack this thread... I'm done
