I'm a new Hubitat user. The ability to develop user apps is one of the main reasons I chose this platform. Where is a good place to start -- I looked at the reference documentation online, but where can I find good examples and tutorials?
I looked at some of the things under hubitat on GitHub, such as the average temperature app, but it wasn't clear to me how to go from there and learn more about how to use the APIs.
Here's a post I wrote recently about app (and driver) development for Hubitat that I think addresses what you're asking:
Feel free to look around and see other people's apps/drivers to get ideas. Some are as simple as adding functionality (ZEN31) while others are more involved using thing like OAuth (Echo Speaks)
Do you have prior programming experience? Especially with Java or Groovy? Knowing your background will help know where to guide you.
I've worked as a developer for longer than I care to think about. 
I've done a bunch of server-side Java, but the only Groovy programming I've done is with Gradle, and then customizing some ST apps and DTHs based on existing code, but that was a few years ago -- I haven't really had to touch my ST system until now when they are changing the backend.
Every new platform has its own learning curve and conceptual cliff to overcome, so help is appreciated.
For example, some pointers to explanations of the software stack, how device handlers combine with apps, the I/O or event interaction between devices and handlers, handlers and apps, apps and the Dashboard, etc. If there's an explanation of the parent/child app pattern would be helpful.
For example -- in this GH repo: GitHub - bptworld/Hubitat: Apps for use with Hubitat Elevation, every sample seems to have a device handler, a child app, and a parent app. Is that always the case?
Thanks for the assistance, it is much appreciated!
The thread that
bertabcd1234 was referring to seems to have a lot of pointers. I shall start with those.
Thanks that helps. I’m about to head to sleep but I’ll write something up for you tomorrow evening unless someone else beats me to it!
Nope. Not a rule, just depends what you’re doing. For the most part it’s pretty similar to ST but with more functionality.
I think the Hubitat threads and ST docs I linked to are good places to start, and I'm sure dman2306 will have even better ideas for you in the morning. In the meantime, the development question about apps vs. drivers really sounds like a Hubitat platform question to me. If you're new to Hubitat, you may not have seen the difference yourself yet as a user, which will become more apparent with time.
But in general, drivers tell the hub how to talk to devices (generally translating standard hub commands--ultimately Groovy methods--to Zigbee, Z-Wave, or LAN commands the device can understand, and parsing the same from the device back to the hub by creating events--which change attribute values--as necessary). Apps are things you use to automate devices--for example, turn device X on when device Y attribute Z becomes W (or, more commonly, something more complicated than that, but you get the idea). Some LAN devices also need a "helper" app to facilitate communication to/from the device(s) or their hub/bridge (Hue and Lutron are built-in examples), which is maybe the one place this distinction blurs a bit. These are outliers. (And some apps, particular ones from the aforementioned author, also include driver for reasons like facilitating app output to Hubitat Dashboard, which works only with devices, or to help the app do some work...again, neither probably super common. A built-in app like this would be Zone Motion Controllers, which creates a "motion zone motion sensor" device to output the app's resulting motion status to, though a virtual motion sensor would probably also work if you were making a similar app yourself.)
Thank you so much -- that goes a long way.
If I understand correctly, it sounds like devices play two roles: a) communicating with the actual hardware (or pretending to be HW, in the case of virtual devices), and b) do I/O with the Dashboard.
That dual role was not clear to me.
For example, in the Average Temperature app, there would have to be a virtual device added in order to display the averaged temperature on the Dashboard, rather than just logging it, is that correct?
The ST documentation you referred to is a good overview, so if the Hubitat platform is as similar as you're suggesting, then that's a great reference. It sounds like the Dashboard not communicating with apps is one difference between the platforms.
I hope the docs will be archived somewhere when the old ST backend goes away.
Those aren't just samples, they are actual working app/drivers. 
Of course you are free to use any part of them for your own use. I also except most pull requests.
As for why they are almost all parent/child. To me it just makes it easier (and MUCH cleaner) to make several child apps rather than have to reinstall several app instances, if more than one set of options is needed/wanted.
For me, most of my learning curve came from the old version of the ST docs and Google. Specifically the Grail's Cookbook website. The HE docs have come a long way since then, so I do look there every now and then too.
Hope this helps and welcome to Hubitat!
Sorry -- bad choice of words. It was clear to me that they were not developed for pedagogical purposes, but as actual applications.
I was looking at them for the purpose of learning, however, and that affected my phrasing. No offense intended.
Had to look that one up! lol
No problem there, this is in every one of my apps...
"You are free to change, ripout, copy, modify or otherwise use the code in anyway you want. This is a hobby, I'm more than happy to share what I have learned and help the community grow. Have FUN with it!"
None taken at all... You got to have thick skin to put an app out around here. 
Let alone 30+! lol.
I think you'll find this community more than willing to help and/or point you in the right direction. If you find anything interesting and have a question, feel free to post in the specific app thread and I'll try to answer. With your background maybe you can tell me a better way of doing things!
ST (used to, at least) have a simulation environment -- does anything like that exist for Hubitat?
No, but the ST one never worked very well IMHO. 
On Hubitat, I use virtual devices (select those in the app, which for most apps gives you a good way to test it) until I'm ready to test with real ones, and some people use a dedicated "test/development" hub to avoid messing anything up (or accidentally creating automations that really do things you don't want and forgetting about them...) on their "production" hub.
The app I want to write is a variant on the Simple Automation one, scheduling on/off of lights, but randomized within a configurable interval. For example, individual lights would come on at sunset +/- 45 minutes, and go off at 10pm +/- 30 minutes.
This seems useful for situations when we're away from the house for extended periods of time, to help make it not so obvious to outside observers that the lights in the house are automatic.
Sounds like a perfect candidate for testing with virtual devices to me! That being said, Bryan (the dev above) also already wrote At Home Simulator for what sounds like the same purpose. The actions you describe also sound do-able in Rule Machine by combining time with random delays, so you might not need a custom app at all unless you're just trying to learn. Good luck either way!
I'm just trying to learn; controlling switches / bulbs seems like a simple enough fist scenario.
I just realized that maybe I should have created this topic under 'Developers' instead of 'Support|Apps.'
Apologies of that was a bad thing to do...
You can probably move it yourself, but since you're relatively new, I'm not sure what editing capabilities you have. I've moved it into the "Developers" category as you suggested since I think that's a good idea!
Download the Hubitat app
