First of all - I am very happy Hubitat user (even thought Hubitat is not perfect).
I am former X10/Insteon user (also was very happy) but when couple years ago
I permanently moved to Florida I started to look around how to automate my
apartment in Florida. There was/are many different hubs around but basically
all of them are Cloud based. For me Cloud based Home Automation is
ABSOLUTELY no go. Finally I came across Hubitat Elevation and this hub
immediately became my choice for automating my new Florida apartment.
Right now basically everything is already automated and I am running out
of new ideas what to automate next.
Yes, many of next topics was already discussed one or the other way
but let me summarized my experience and provide some thoughts.
Next are only an ideas.
As of now I moved all my automation to RM.
The reason is - neither of other applications 100% satisfied my
specific needs. This is very common and not unusual because every
application is written for somebodies specific needs. And needs for
every user/case is somewhat different. That is why there are many
slightly different applications covering almost the same use cases.
From other side - RM is very powerful universal application.
Many BIG thanks and respect for @bravenel for the RM existence!
So, RM itself is very power tool but the GUI is somewhat overcomplicated
with all these pull-down menus and dynamic pages. But now after reading
many related posts i have an idea what is behind this approach.
Correct me if I am wrong but it looks like everything could be
accomplished by using "custom actions".
One way to optimize GUI will be to start silently right away from
"custom actions" and then pic a "device" and so on.
Custom Applications.
I saw few posts where some sort of "RM Compiler" was discussed.
The idea was/is - to compile RM Rule into Custom Application.
I really hate Clouds but for this reason (compiling RM into Custom Ap)
one time Cloud interaction will be acceptable.
I am not a SW developer and I have no Idea how difficult it will be to
implement this but my good guess - it is definitely doable.
I think, the compiled RM Rule will be far more efficient vs. RM Rule "as is".
So, If this is doable it will be huge improvement for many (if not all)
ordinary HA enthusiasts and will open a gates for many people who
want to start HA but have no real solid programming skills.
Yes, RM is some sort of pseudo programming language but learning
simple IF-THEN-ELSE logic (some sort of idea behind IFTTT) is far less
complicated (I think) vs. learning whatever real programming language.
Device Drivers.
The Device Drivers "as is" is an Achilles Hill for the Hubitat and
other hubs. But I think, the creation of the Device Driver could be
(and should be) completely automated. I came across at least one
post/project where somebody attempted to accomplish some
sort of creation of Universal Driver. I don't know, what is a current
state of this project but looks like it did not materialized into something
very solid. Too bad.
So, why not to create some sort of automated Driver Creation Tool?
And I am sure, this could be achieved. How easy - is a question.
Again, in this case Cloud based tool will be acceptable.
(Even MS Windows has a "Jungo" - automated Windows Driver Creator tool.)
Instead of writing a real device driver why not to provide all "capabilities"
for whatever device and tool will create driver automatically.
Driver should/must automatically handle all basic/generic capabilities
such as On, Off, Dim, etc. All device specific capabilities should be added
based on provided info for the driver creation tool.
For instance, every Video Card was/is working with Generic VGA Driver.
But all card specific functions became available after installation
of card specific manufacture driver.
Well sometimes it is easier to write a custom app if it would be complicated/impossible to do in RM. But I am not sure of the benefit of turning a working RM rule into a custom app. Having got as far as getting it working under RM why bother with the extra step?
Yes, something custom is always better than whatever universal.
And yes, I am creating left and right custom IPs for all my FPGA projects.
But in order to write a custom application person should/must know
many "little" details such as:
first of all, Programming Language will be used;
how to setup SDK;
finally how to debug your code;
Plus many other details.
What you see after Rule is created in RM is a Pseudo Code.
Mainly this is relatively easy to understand IF-THEN_ELSE statements.
Behind the scene there are many different SW layers involved.
Each layer has an impact on performance.
Modern HW has very powerful multi-core CPUs and relatively
sizeable memory. So, all SW imperfectness is very well masked by
very powerful HW.
However limits are not infinite and sooner a later will be reached.
I am sure, the sort off "compiled" RM Rule into Custom AP will not
produce an executable machine code.
And I could be completely wrong but at least one or more SW layers
could be removed. The result is - better performance.
But again, the benefit could be very minimal and maybe not worth it.
Platform experts could provide a bit more details for the difference
in performance between RM Rule and Custom AP doing the same things.
No, it is merely a description of the selections you have made setting up the rule. It is not any kind of pseudo code. There is no way to create a compiled app from Rule Machine.
This is largely immaterial. Home automation consists primarily of widely separated events (where 1 second is wide separation, but home automation is even less frequent), so app performance is not generally relevant. To the extent responsiveness IS relevant, it is in motion lighting use cases, where the speed of response is visible to an occupant of the house. These automations should not use Rule Machine, but rather Motion Lighting, tailored to this use case.
I am sorry, my wording was not clear enough.
By "pseudo code" I meant just a visual representation of RM Rule.
It looks like very well formalized and formatted.
So, if you "cut-and-paste" this basically plain text into "AP Creation Tool"
it could be converted into Custom Ap. I could be missing something
but I don't see why this cannot be done.
Of course "Ap Creation Tool" must be designed.
And it not necessarily should be even running on a hub.
It could be whatever stand alone PC/Mac/Android application
or even web/cloud based service.
"These automations should not use Rule Machine, but rather Motion Lighting, tailored to this use case."
The above statement clearly tells me the Custom Ap is more efficient vs. RM Rule.
And I am not surprised.
I agree, in many cases the Ap Performance is not critical for the HA.
My point is/was - optimizing overall hub performance and removing unnecessary
processing layers. Yes, little delay for any given HA Task may not be critical and
even visible to the end user. However accumulative effect may create a disaster.
Unfortunately I saw cases like this.
I am EE. Many times SW folks came in tears requesting more memory and faster
CPUs because they overloaded their SW with things like Java, scripts, etc.
The result was - product worked and did its job. But ops, customers were not happy
with an overall performance. The release was delayed, design phase restarted, etc...
Actually, while of course a custom app is more efficient, Motion Lighting has peculiar needs that would take multiple RM Rules to do, while it can be done better in a specialized app. So it's easier to setup what is needed with a specialized app. The efficiency of RM vs Motion Lighting is not a material aspect of this at all, only user interface.
Our hub does run on Java Virtual Machine, so there are inherent inefficiencies that stem from that. One could do a greenfield implementation of a hub to gain efficiency. But, we chose this path and it works well for the intended use, allowing for rapid development. There are always many tradeoffs to be balanced.
You know nothing of what you are talking about (by your own admission, not a SW person, but EE). This is not possible for many reasons.
I am not arguing against Custom Aps.
Yes, anything custom is always better than something universal. No doubts.
The matter of fact, I became EE because when I was a kid and started to play
with electronics I NEVER had something in my hands which exactly covered
and satisfied my specific needs. Everything required some sort of customisation.
First, this was my hobby and finally lead to became EE.
For the HA with Hubitat I started first with Motion Lighting Ap but very quickly ruled
it out because of its limitations.
I was able to do everything what I was needed in RM.
Once again, VERY BIG THANK YOU and RESPECT for the RM existence!
Frankly, I am not even sure if I could use Hubitat without the RM.
So, correct me If I am wrong but the final result is the same regardless
what was used: RM or Custom Ap written in Groovy? Right?
Either one creates the same Data Base entries and main Hubitat Engine
(whatever it is) is simply processing entire Data Base in the endless loop.
I don't have a problem with this approach.
"... allowing for rapid development. There are always many tradeoffs to be balanced."
Yes, I know what you are talking about.
However in my company I am working for all these "rapid development" short cuts
almost always resulted in redoing the same projects some time more than twice.
The actual result is/was - "rapid development" becomes near a show stopper for few
almost released products.
(Unfortunately this was related not only for the SW development short cuts but for
the HW design as well. Thanks to the FPGA technology I was able at least to almost
eliminate the necessity for re-designing PCBs. Some projects are still using near
10 years old PCBs but actual implemented HW is 100%+ different from original.)
"You know nothing of what you are talking about (by your own admission, not a SW person, but EE). This is not possible for many reasons."
I know very well what I am talking about even thought I am not a SW developer.
What is wrong with compiling/converting something with well defined input
into whatever you want? Sure this could be done.
Visualised RM Rule is very well formalized and formatted and sure, it could be a
very clean input into whatever tool/compiler. What is wrong with this?
If you start to write something say, in C/C++ you can start with something
very simple as a Notepad as an input tool.
Then you you use a compiler to create an executable machine code. Right?
Visualised RM Rule looks very similar to the very simple C/C++ code.
So yes, whatever tool (even script) could use this as an input and convert it to
basically anything else.
However more I am learning about what is going on behind the scene all this
effort looks like useless because the way how Hubitat Platform is designed
and works. The final result will be (near) the same - just an entries into Data Base.
So, I am really sorry to take your valuable time.
We have rapidly developed and innovated for four years, and keep turning out major improvements to the product on an ongoing basis.
Nothing. But this would be a major software development undertaking with a very small net payback. Hence, it doesn't pass the basic economic test of a wise thing to undertake.
No, the result would be very different. But that is besides the point. Nothing happens for free, and creating the capability to compile a scripting language for the hub is, while doable, not likely. Check out WebCore, it creates an intermediate language representation of a script (using JSON). But, this too, is levels above what a custom app is capable of. I've made the observation before that a compiler for WebCore to a Groovy app would make sense (given that it starts out with a script). This was not done, could be done, but probably won't be done.
Ultimately, someone has to learn how to express logic and flow in some language, and that language has to somehow run on the hub. For now, Groovy is that language, and it works quite well for that purpose. But, 95% of our customers will not learn to program in Groovy.
Alternatively, some users use Node Red running on an external processor and connecting to the hub via Maker API. For them, this is a better approach than learning a scripting language or a programming language.
Please don't take me wrong.
I am simply thinking loudly.
I am very happy to hear "rapid development" works well for the Hubitat developers.
This is very good news.
I worked for few companies (designing HW but closely interacting with the SW team)
and unfortunately all these "rapid development" attempts resulted in a disasters.
As I mentioned, I love RM (still using RM 4.1) and I am very happy it does exist.
Thank you one more time for the RM Application!
For now RM is my only application for all my HA needs.
But thanks' to all yours explanations I guess, I have to learn Groovy and
start writing my own Applications and eventually Device Drivers.
My (I hope) last question is:
What is a major difference in terms of produced output between RM and Groovy?
(Link for reading and learning is OK.)
If I got this right, the RM is an Interface (GUI) for creating internal Data Base (Rules).
RM itself is an one of many Applications written in Groovy.
But Groovy output is not a compiled machine code.
Maybe Groovy does not generate any output at all but simply processed (interpreted?)
by Java Virtual Machine? Yes?
I am trying to understand all hierarchy and how many different SW layers are involved.
If one of your problems is you don't know how to begin to write custom apps and were hoping a RM-to-App tool would start one off for you, I can sympathise. However, I found that looking at examples of other people's written apps was a great help, if you feel like giving that a try.
I think it might be better if Bruce's time was spent working on the development rather than trying to satisfy your understandable yet academic curiosity Is there anyone else here with the information the OP is after?
I 1000%+ agree, Bruce's time must be spent on development vs. educating
somebody including myself.
Somehow this discussion went into wrong direction and I am really sorry for this.
In short, my main problem for many years - is how to make Home Automation
desired and excited for wide audience vs. relatively small group of educated
people (mostly SW engineers).
I don't think Hubitat is quite the right platform as yet for beginners, although they are making it increasingly easier to use. I started with SmartThings which was simpler, and moved to Hubitat when I started to want more complexity.
Unfortunately nothing is exist for the beginners.
I was using many different platforms starting from X10, Insteon and so on.
Neither one was/is easy to use including Hubitat.
And unfortunately in terms of "easy to use" things in HA area are moving
toward complexity instead of simplicity.
HA also has the problem that the community isn't quite as eager to be helpful as the ST and HE communities. I guess it might be better if you buy the ready-made hub and the full support package. I think casual Smart Home users are possibly looking towards the Alexa zigbee system or even just wifi/cloud app stuff. Hue for lighting possibly?
I see it differently, the real divide has little to do with people who are computer savy (software engineers, people proficient in coding, etc...), but rather is a divide between people who can understand and create the logic for an automation and those who can't.
I find RM to be a great app for me to enter in the logic of an automation that I desire. I do this entirely with plain old English language and use no computer coding at all. The reality is, I have several educated friends, (I am thinking of one with an English Literature degree), who would have great difficulty with this process. It is not there deficiency in English Language, but rather their difficulty with the logic. I am very proud of my HE setup and have even been able to help other users with particular difficulty rule creation in RM. I have no computer programming/coding experience, but as a high school math teacher, I find the logic creation to be fairly straightforward.
The simple reality is that since HE is incredibly customizable and every user's implementation is different, at the end of the day, each user needs to be able to understand and create the logic for the automations they desire. Many people can do this, and many people can't. I would imagine that almost all software engineers can do this, but there are also many others with little to no background in computers who can also do this.
By "HA" I meant "Home Automation" in general, not a Home Assistance hub.
Cloud-based Home Automation is absolute nonsense
(and this is not only my very strong opinion).
Alexa and Google are kind of good supplemental for Voice Assisted Control
but this should not be a primary HA implementation
I guess, this is (all local controls) primary reason why Hubitat exist in a first place.
I have many friends and few are even senior SW developers.
All they are very excite to se my Smart House (now my Smart Apartment) in action.
Their first expression was - "we want this all in our home".
Once they learned what steps must be taken - next expression was either
"No Thank's" or "Not now, maybe later" even I offered some help for
initial setup (but not for continuous maintenance).
When I ask "why?, it looks like you like it" the typical answer was:
"it seems to be too complicated".
Unfortunately, I had to agree with this statement.
The real answer is - HA Setup must be very simple and intuitive.
Furthermore, some basic functions such as "Motion Lighting" should be
(and could be) 100% automatic with very minimal tweaks performed by end user.
Every user has their own thoughts and opinions on what HA (Home Automation) and Hubitat, should be and strive towards. Thoughts in regards to Home Automation and the direction it should take are interesting and everyone has their own take on where it should lead. The business direction of Hubitat, is for the owner's of HE to decide on their own, it is their business.
I have no idea what the business direction of HE is. I imagine the HE staff are happy to have a product that works and appeals to hundreds of millions of people worldwide, but leaves out the many billions of people worldwide who are unable to express the logic of their desired automations. I imagine for HE staff and their business, producing a product that meets the needs of hundreds of millions of people who have the ability and desire to create and maintain the logic of their desired automations is a great thing. I am very happy they have created it.
I don't think you have to worry, about Home Automation setup becoming very simple and intuitive. I imagine this market need will be addressed fairly soon. You are correct in the fact that there are billions of people worldwide that can't create and understand the logic of many typical home automations. I am sure big tech will cater to these people. I don't think it will be fairly long before you can say: "Hey, Google, please turn on my fan when my living room window is opened." Google will then create the automation that only happens when you are home, when the smoke alarm is not going off, when the temperature differential is beneficial, etc....
One may be of the opinion, that home automation should not go down this path, and this may be true, but I fail to see how it is of any concern to HE and their business.
I also have many friends who would never use HE, I don't think it is unfortunate for either them or HE. Companies gear their products to specific consumers with specific needs, wants, and abilities.
Well, if HA is not simple and intuitive it always will be just for DIY enthusiasts only.
And of course, every hub/device/etc. manufacture have their vision on how to
conduct their business and what potential customers to target.
Without the ability to think about logical relationships, it isn't possible for "simple and intuitive". What is intuitive to one person is obscure to another. There is logic involved in even the simplest of automations: when motion is detected turn on this light. Once you explain that to someone, they usually get it. But they may very well not come up with that out of their own intuition. Toss in the additional logic of when to turn off the light, and the complexity of recurring motion, and you will lose most people.
Home Automation requires logical thinking and logical problem solving. Consequently, it is not available to most people. Curated systems, installed by a technician, is the way through this problem. But, the economics of that approach are daunting. There's an economic reason that a typical professional Lutron system installation costs $20,000 and up, and that doesn't even include automation, and why a Control4 installation costs $40,000 and up.
As it stands now with a product like Hubitat Elevation, this is true. The market as such is limited to a small segment of the population. But, the boundaries of this segment are being pushed out slowly thanks to things like Alexa. A friend of ours announced, "Alexa is the gateway drug of home automation." You start there, then realize that all you've done is converted the light switch to a voice activated light switch, but not really automated it. A light bulb goes off...
Is there anyone else here with the information the OP is after?
