If you’re comfortable with programming, why not try your hand at Groovy? It is pretty easy and there are tons of example Apps and Drivers between the Hubitat and SmartThings communities. This is definitely the best way to get the best results/performance out of your Hubitat Elevation Hub.
Yeah I wondered about that. The only groovy experience I have is in modifing the DH for my thermostat. It wasn't that hard, but it seemed like a lot of the groovy part was tied in with getting the device to display correctly in the ST app.
Does anybody have a simple example of a groovy "app" with like one motion sensor and one light? From that I could probably figure out how to do the rest of the logic I need. All the examples I've seen are full blown "apps" and, having just perused them a bit I couldn't really figure out where the actual work was being done.
You are absolutely correct about that! When I think back to how much time I spent tweaking DTH's purely for the ST App appearance, I am amazed. The beauty on Hubitat is that none of the 'Tiles' code is used at all and can be tossed.
As for Apps, those are pretty darn close to their ST counterparts. The ST Classic Developer documentation isn't all that bad. That's where I learned a lot about the ST/Hubitat groovy API.
The basic App flow goes something like this...
-
Ask the user for Inputs, most often the devices that will be used in whatever logic you desire.
-
Subscribe to pertinent device events, and register a callback function for those events
-
In the callback function, perform any desired logic, including calling other devices' commands to take action.
That is a very high level picture. When you think about it, it is not much different than what you have to do in webCoRE. webCoRE definitely hides a lot of the ugliness, and streamlines everything, but at the cost of being an interpreter on top of an interpreted language.
Once you write an App, you'll pick it up pretty quickly. Of course, Google is your programmers reference manual when it comes to groovy syntax.
1 Like
Yep thanks. I just went over there and found a "hello world" style "my first app". Gonna mess with it a bit tonight.
Does webcore actually function as an interpreter on top of groovy, or are webcore pistons "compiled" down into groovy apps? I was never clear about that and simply hoped the latter was true.
webCoRE pistons are simply instances of a webCoRE Piston App, with a bunch of configuration data pre-populated. The code is not generated. Since every piston uses the exact same source code, they are relatively huge. Hubitat compiles these the first time each of them are used after a hub restart. Even though they are compiled groovy at that time, they are still huge compared to a purpose-built Groovy App, which only has as the variables and code needed for the specific task.
I see. Alright that makes sense.
Can RE do things like global vars?
I have several "zones" in my house that get different types of light at different times of the day. I have a couple of outdoor luminance sensors that update continually and trigger a piston that sets webcore global level vars for each "zone" based on weather conditions and illuminance. These level globals are then consumed by per-room pistons to set the level of lighting required by the room. This largely works, but I'm not sure how I'd reproduce it in RE, or frankly in groovy without globals. I haven't given it much thought either though because it does work and its mostly fast enough, though of course I always want FASTER.
You can create a Parent / Child App design. The Parent App would store your “globals” in State variables. The Child Apps would call a method of the Parent App to return these values (as a map if multiple values).
Or,each App could subscribe to the events of the same devices and keep track of the same data.
