With a new (expert mode only ) action "Execute Groovy Script" anything could be made possible: Just enter some lines of Groovy and go!
Given a global super variable (maybe "hubitatService") where all Hubitat objects (devices, rules, triggers, etc. pp.) are available as Collections one could implement any Rule that one could only imagine - without having to write a complete new app.
So it would be possible to use the framework Rule Machine offers without having to pay the whole price to decrypt the vague developer documentation.
Hubitat's security model for user apps requires the user to specifically select devices in order to have "access" to them. An app you write cannot use use an arbitrary device on the hub. I'm not sure where you're specifically asking for this feature--as a rule action? So I suppose devices could be accessed by having been selected there. But then it's not clear to me how it should work after that. Maybe I'm not being imaginative enough.
But something you can already do, as you know, is write a custom app. If you start with a "template" with the definition and maybe a basic preferences with a blank page and section defined, all you'd have to do is define your inputs (choose your devices) and then do whatever you want elsewhere: subscribe to events, create scheduled jobs, or run whatever commands you want whenever and however it is that you want. Yeah, you'll have to figure out a bit of how that works (but it's not that hard: if you have a reference to a device, technically a DeviceWrapper, from an input, run a command on it by calling the Groovy method of the same name on it). I don't think anything like the above suggestion would get away from needing to at least understand that much (otherwise that's what RM itself abstracts away from you with human-friendly action names instead of command names). But again, maybe I'm missing something.
I've often thought it would be nice if the community created a small repository of app "templates" that people could use as starting points (without using a "full" app that might be too much to understand as a starting point). I've thought about creating a few to get this started but never really did. Maybe that would help, too?
Seconded. I've tried studying various drivers/apps to get a feel for the language but often get overwhelmed. I'd love to see some basic driver templates as well (in addition to what HE has released publicly)
Yeah, HE at least has some driver code published, but not a lot in the way of apps. And documentation is usually accurate for figuring out things you need (like method signatures) but not super-helpful for beginners to get started if they don't know the environment at all. People used to make fun of SmartThings' SmartApp and DTH docs for various reasons (I think just being out of sync with what the platform actually implemented), but if this (little guidance on how to use them) was one of those reasons, it seems pretty silly now. So I guess better documentation would be a good thing, too, but I know how little devs tend to like writing that. Another area I suppose the community could help with, creating community/peer-created guides, but I'd feel less condifent about doing that myself (even though maybe at least a little "how to get started" thing would be a good idea--ST's classic docs are actually OK there, I think!) given that I can't possibly know how things are implemented aside from what I know about how it works.
But yeah, back to the app and driver thing: if anyone wants to help with that, I think the Hubitat Community repo (that csteele and possibly others manage) might be a good place to put something like that if anyone wanted to collaborate or at least suggest things that would be good starting points, whether "templates" or actually minimal functional apps (I was thinking something like a basic motion-lighting app: pick a sensor, pick a switch....and add whatever code you want beyond that).
I don't understand the security concerns:
Aren't those my devices on my Hubitat in my local network which (than) execute my scripts on my own responsibility? (Therefore "Expert Mode". )
In case of very complex Rules I would like to write my own apps if there would exist a full documentation.
IMHO examples are not a substitute for a full specification, because you can still miss important points (or reinvent wheels)...
Nevertheless I second the idea of a repository of templates, and specifications, and tutorials.
Two years on, did anything happen with this, do you know?. I have a super complex RM rule that I would like to simply write in an app, if for no other reason, ease of editing. I love RM but it's not the same as writing code speedwise. I have looked at examples, tried ChatGPT and gotten som headway but ultimately the threshold becomes to high. So a repository or any other coding DIY would be a welcome and good idea.
What is "this," exactly? Something in the original post or something in mine that was quoted?
If it's more towards the OP, the developer documentation is, IMHO, much better, so writing your own apps should be easier if you want to go that route.
But, again, if is is, the app developer documentation now has an overview of the environment in general plus (on the next suggested page) a how-to on building a simple, functional app that should help someone get started: App Overview | Hubitat Documentation. These did not exist at the time the above was written.
I'm willing to cut Hubitat some slack in terms of how much support is offered in this regard, being grateful for the support we do receive.
Given the language used is a publicly available one, with some control imposed by HE, I can appreciate not wanting to document someone else's tool, but can equally appreciate the need to capture how best to use it within the constructs of the HE platform.
As always I would encourage other developers to link to or capture in Community posts interesting or useful code they develop, to benefit others. Equally, where possible, capturing some of the basics, including in general conversation on the Community, can also help other developers get a start in developing their own drivers or apps.
It's often nice to point to idealistic endeavors that we don't need to work on... I say that as someone who straddles both sides.... Well sometimes.... But it doesn't always (seem) to make sense spending time fleshing out documentation that may or may not get used and may need to change rapidly. It's not always as simple a decision as it may seem....
Not an answer... I know... But hopefully some kind of insight into some of the reasons why some will think twice about embarking on projects like this.... Not to say it won't happen.... Or can't...
Hi @bertabcd1234 ,
Sorry for a late reply. Yes 'this' is basically what @johnwill1 concluded, sample app templates that people could use as starting points, and as @Jost put it
I agree with @sburke781 in that I fully appreciate that no one can expect Hubitat to start documenting a thrid party program language. And I think HE has an exellent documentation covering most parts of the fundamentals.
I used to program plSQL procedures in Oracle databases and xml scripts 20 or so years ago so I have a vague feeling for what to do, but need to apply that in a new context. One situation I encountered when starting to play with an app of my own is that tables, storing and retrieveing data is not the same as in a relational database. So there I need to do some homework to better understand the standard language.
My perception is also that there is a junktion where the standard programming language meets the HE specifics and that becomes, at least for me, a bit tricky to see which is what. An example of that, and I am sure there are better examples of this, is that I realised that he sensor values are not avaialble when I started my script and that I needed to handle that situation and some how need to wait and capture these as they come along, and then store. If I use RM, the sensor values are readily available. Albeit not fresh up to date but there are values, which is a differnt situation than if there are none to start with.
So I realized a first hurdle would be to handle sensors, sensor values and storage of those, before I could actually get to the functionality I want to implement in my app. I think I boldly assumed the values where stored in HE somewhere as part of the standard functionality. As I recall I could not find any info covering capturing and storing data and handling error messages in the context of missing data, but It might of course be that this information is available and I just haven't found it yet, but it was enough of a hurdle to find other more pressing things to do. Again, I am at present not aware of if there exist an excellet description of how to capture sensor values and store them, and if there is, I am grateful for a link.
But that in principal is an example of things I guess most people who will embark on building their first app will need to get their head around. Snippets of code and or examples of how to do that would smooth the way to build more apps i believe, and in turn increase the Hubitat community and availablility of useful apps. A suggestion could be for HE to do a drive for community based repository and provide the infrastructure within the framework of this excellent community site, with a starting focusing on standard modules of code to do specific tasks?
IMHO, the best way you can get help on something like this is to share a snippet of code that is not working as you expect (ideally an entire method or even small working app but with only the piece that demonstrates the actual problem--minimize guessing but also make it easier to see the actual issue for someone else).
In your case, I strongly suspect this isn't really the case and may be related to how you're trying to get the value (perhaps in an event handler instead of using the device wrapper object where you need it). The above could help figure that out. Rule Machine is just an app, even if a very large and complicated one. Anything its author did you can also do in a custom app (with rare exceptions given a couple internal hooks it has into the platform, but this is not one of them).
This is not to say there isn't more to come in the developer documentation (though there is a lot more to help you get started now than there used to be, plus even a couple working app examples) or that anyone couldn't create their own resources, of course.
I don't think Discourse provides that framework. Plus why duplicate what is already available on Github? Speaking of which, there are plenty of really good Hubitat developers whose code is available on Github. Sometimes the code is commented, sometimes it isn't. On occasion, I have used a Groovy reference along with someone's existing code to create an app for some little need of mine.
I think I am a bit hestient of being percieved as a burden in the community with all my noob questions, of which there are many But thanks, I'll give it a go.
Thanks for the tip. And I will have a re-read of the documentation sites and see what new has arrived that I have not digested before.
Personally, I would say never feel that way. This community is great and I can tell you over all the time I have asked questions I have never seen any kind of response that would give that kind of reaction.
I learned allot of my coding from a few places.
Looking at previously written code weather examples or simply other peoples code has helped tremendously.
The Hubitat documentation is great for a start to understand the structure of the code. There really are in general 3 parts to the code. These parts are really layed out well in the Hubitat Documentation Here. That one page shows you all of the parts needed to create a smartapp.
Lastly there are allot of great Groovy sites out there with good tutorials on using various methods in Groovy. One I go to allot when I have questions is Tutorialspoint
I think the big things to remember is that Hubitat is an event based system. So when writing a app you need to think about it from that perspective. If you want to look for a certain temperature then you will write the script to trigger from that event and respond correctly. There are also ways to look at the current state of a device as well when method in Groovy is running.
) action "Execute Groovy Script" anything could be made possible: Just enter some lines of Groovy and go! 
So I guess better documentation would be a good thing, too, but I know how little devs tend to like writing that. Another area I suppose the community could help with, creating community/peer-created guides, but I'd feel less condifent about doing that myself (even though maybe at least a little "how to get started" thing would be a good idea--ST's classic docs are actually OK there, I think!) given that I can't possibly know how things are implemented aside from what I know about how it works.
But thanks, I'll give it a go.
