While I await the arrival of my Hubitat in the mail, I'm not clear on the mechanics of development for it.
What's the process you use for writing and debugging code for the Hubitat? AFAICT, you update your app by pasting the new code into the code window.
How do you simulate events so you can observe your app's behavior? I suppose you can just run it--Hubitat's only-local code is awesome that way--at the risk of bugs annoying your family and pets. But that approach makes it hard to debug not-present conditions such as between 2am and 3am when I'm out of the house and the wind is more than 40mph during an eclipse...
If there is no UI-based simulator like the apparently-decaying ST classic simulator, maybe there's a way create fake events for debugging?
What are people doing that gives you a reasonable edit/run/debug cycle?
For specific times, I guess you're out of luck, but configuring the automation to work at another time and testing it then is what I've done (say, 8 PM instead of 2 AM). For automations that respond to buttons, switches, motion, etc., I've done as others have suggested and created virtual devices, which I use to test sometimes (though other times I'll use a real device--I have motion sensors and buttons to spare, and my computer room lights have been the victims of some of my tests because their behavior is easy to observe when I'm coding).
I also bought a second hub for development because I made stupid mistakes that locked up my "main" hub a couple times and I didn't want to keep doing that (this was my fault, though one of these issues something they "fixed" to stop this from happening to others). However, you obviously don't need one if you trust yourself not to make terrible mistakes on your "real" hub or don't mind the occasional unplanned reboot--though if you do get a second one, Hub Link and Link to Hub can integrate your devices and still let you use "real" ones if you want.
Hubitat isn't a development platform. It has no tools to assist in debugging issues in your code beyond 'log.debug" statements sprinkled liberally through your code.
Hubitat Staff say they do all their development using the builtin code editor. I believe them, but I haven't gotten used to that. I'm still stuck in the mode of writing in my fav code editor and then pasting that into the code page.
Virtual buttons/switches/devices are all part of the process, of course, as others have said.
You can always install a Groovy environment on your computer and set breakpoints. (shudder)
I HAD a 2nd Hub for development, but then I decided to split my home by floor. The development Hub is now "Upstairs hub" and is just as production critical as the (newly labeled) "Downstairs hub". That wasn't enough, so I borrowed a third hub -- but that's now the "coordinator" running all my 'whole house' (common) apps, such as Dashboard, Homebridge, Alexa, etc.
Maybe I need a fourth hub? One o' them new fangled C-5's perhaps.
I am just used to using a 'code editor' that has simple things like column edit, syntax coloring, search highlight... nothing special really. I think that list is available in 99% of code editors.
I don't know about you, but I use too many code languages per month and therefore I make typos because I'm using the wrong syntax. As in ending lines with ;
I need an editor that I no longer need to memorize. I have enough hurdles, the editor's quirks aren't needed.
I don't know any coding, but yesterday I did an interview to a guy and I saw he did a BS when he is a full time employee, so I asked and was a distance college, so he did it over the internet. He did a BS in information technology and honestly I'm interested in doing the same. So just asking to the good people here. Thanks.
I actually use this (or an online console) if there's some Groovy syntax I'm trying to test. Unfortunately, such an environment won't do you much good for a Hubitat app as a whole, since there is more than we see to Hubitat's Groovy environment. It's all closed-source, of course, but I'd guess that that apps and drivers are instances of some class, giving them access to Hubitat app and driver methods that you don't find in "standard" Groovy (my understanding is that this is roughly how ST implements SmartApps and DTHs, too).
There's nothing stopping anyone from writing a Hubitat simulator/emulation environment in Java/Groovy, which might help (like the ST online equivalent) in writing apps or drivers. Probably a lot of work though--it's pretty much what Hubitat did to create the product they have now, sans the simulator, and I'm sure that took quite a while. (Though with ST steering people away from "classic" SmartApps, I do think it would be kind of neat for someone to write an open-source environment in which they could be run...or, of course, they could just switch to Hubitat.)
I use IntelliJ IDEA from JetBrains, it spots quite a few of the obvious errors - the community edition is free. It has refactoring tools built in which helps tidy the code up a lot - although watch out for Extract Method, it will often mark the extracted method as returning void, which can cause a few head-scratching moments until you realise.
What's the reasoning behind that ? I'm considering getting a second hub for my basement, but I had just assumed I'd keep running those things off of the main hub.