Groovy Version Update?

Last I see, HE is still running on Groovy 2.4.x. Any chance of getting Groovy 3 in the near future? Null-safe indexing would be quite nice, beyond just general applicability of things I look up online regarding Groovy syntax.



I just tried to use switch expressions, then discovered they weren't added until Groovy 4. HE is still on 2.4. @gopher.ny, is there any hope or even a timeline?

1 Like

No ETA on this. Updating Groovy version introduces breaking changes, so there are some cost/benefit considerations here. Yes, I tried.


Thank you for trying!

1 Like

I can only imagine those costs are likely to grow the longer the upgrade is delayed. Could the Beta group be utilised in some way to test this upgrade in some way? Or some other limited user-base willing to take the upgrade?


I'd add, would Hubitat consider a Groovy version for their Built-In Apps and Drivers alongside a version for Custom Apps / Drivers? With the user opting to take a more recent Groovy version, at their own risk? I can understand if this would not work for interactions between apps / drivers... But thought I would at least float the idea.... If only a fleeting idea....


If supporting multiple versions in parallel were possible, an app could even declare its desired version in the header. Though I could imagine that getting complex.

1 Like

Yeah, I'm not holding out much hope. Nothing to do with Hubitat's capabilities, more so the complexity of delivering what I have asked for....

M$ handled .net by maintaining multiple branches. I for one feel he must stay current - the bug fix's of the groovy library alone look worth it let and I'm not a groovy fan just a casual user. the groovy devs surely know the cascade effect and felt it was worthwhile. my 2c.

Would not be surprised if hubitat does something similar to

(and probably completely different at the same time.)

Strongly suspect that Scripts (be it drivers or apps) are tied to the same groovy version of the Hubitat code itself.

1 Like

Some thoughts on this, with some suggestions that may be a shorter "reach" (insofar as less breaking changes) than switching to an updated groovy . . .

As a spoiler, to me #3-6 seem, to me, that they could be begin being implemented and bring benefits much faster than #1-2 (at least #5 could be done in stages).

  1. If there were to be a groovy update, groovy 4 rather than groovy 3 should be the target.

  2. As pointed out already, this would likely bring with it some breaking changes. Consider - can two different versions of groovy be run in parallel? I.e., there would be ".groovy" drivers/apps and there would be ".groovy4" drivers/apps with the proper groovy environment selected for running each (i.e., this allows a partial migration of drivers, rather than a wholesale switchover). Perhaps the ability to select the advanced environment would be part of the definition / metadata section.

  3. There are already existing Groovy 2.4 features that can't be used -- some are major Groovy programming features. The most significant of these, IMO, is to allow user-defined classes. If there were consideration given to a more modern groovy (i.e., 3/4), then refinements in the driver model, such as unlocking classes, should be part of that thought. I see this one example as more significant than most of what groovy 3/ 4 offer (though groovy 4 would also be really nice).

  4. On #3 in particular, perhaps allowing access to classes could be permitted for a more advanced "beta" group. Again, this may be a step less than going to groovy 3/4 and any breaking changes could be fleshed out by the beta group.

  5. Before any of this switching to another Groovy is considered, there is much more that could be done at the platform level to make programming easier that would not be breaking. It seems to be a big jump to go from Groovy 2.4 to 3, or 4, but a much smaller jump to add platform features (that could still be brought into a 3/4 environment if that ever happened). For example:

  • For both Zigbee and Z-Wave there are may "static" items of data that a device stores and can be queried. But querying these can add quite a bit of complexity. This could be greatly simplified by querying all static data items at pairing (and after firmware updates) and storing them in a database so that they are always available to a driver.
    • Here I'm talking about "basic" items such as (i) how many endpoints does a device have, (ii) which clusters (zigbee) or classes (z-wave) does each endpoint support, (iii) how many buttons for z-wave central scene and each button's characteristics (z-wave), (iv) which cluster attributes are supported / not supported (zigbee), etc. etc.
    • Basically, any data that can be gathered at pairing, gets gathered at pairing and is thereafter database accessed rather than device queried.
      • This would be a huge step in making it easier to write drivers that are "generic" across devices. Presently, it is easier to take the route of writing drivers that are more device-specific as developers tend to not want to query for this information, but the result is a proliferation of drivers.
  1. And for zigbee, in particular, I'd love to see a parsing option that is more like the Z-wave model where data is parsed into class structures rather than a map (i.e., a "parseDescriptionAsClass" where, analogous to z-wave parsing, you get a different class depending on the profile/cluster of the description and could dispatch that to the appropriate handling method by a simple call using a common method name that receives a parameter of the appropriate class.
    • I.e., like in Z-wave you'd be able to do a class-based method call ...
void parse(String description) {
    	hubitat.zigbee.Command cmd = zigbee.parseDescriptionAsClass(description)
		if (cmd) { zigbeeEvent(cmd) }

In my view 5/6 would be the shorter term (i.e., next 6 months) focus. The others a longer-term item.


Hopefully someone who named themselves jvm will hold some weight in the conversation :wink: Not to mention the detailed and compelling response you provided.... :slight_smile:

The long awaited developer documentation on the existing Groovy environment would be a nice feature.


Have you checked it out lately? At least four new docs have been added, plus some changes to others. New documents include an overview of the general Groovy environment, plus two documents for apps: an overview and a tutorial for building a fully functional purpose-built app.

A driver overview had also been added. Next will likely be real-world Zigbee or Z-Wave (and maybe LAN) tutorials so you'll get a functional real-world example like for apps. Suggestions for anything that would be helpful are also welcome.


I haven't checked it for a few months at least. Trying again today for the kind of stuff I've needed in the past: 404not found 404 not found
Device Object | Hubitat Documentation still a long list of "to be documented" methods
Zwave Object | Hubitat Documentation documented as "incomplete"
Zigbee Object | Hubitat Documentation long list of "to be documented"
Z-Wave Classes | Hubitat Documentation doesn't load on windows + chrome. Used to load on windows + edge. regardless, it feels very javadoc-autobuilt without any descriptions for the fields or how they are used. (note: finally loaded on chrome. blocks for a LONG time)

The templates/examples how to build an app stuff is nice, but I would really appreciate a complete reference for all the groovy classes, the zwave/zigbee/event/driver stuff specifically. Using other community drivers is a good example too, but doesn't replace actual reference for all the libraries used in HE's Groovy implementation.

I'm still using the (now only via archive sites) SmartThings documentation for most of the Groovy reference, and its not exactly accurate with HE's implemetation.


Absolutely true -- stuff is missing and needs to be filled in. That said, I've found most of the "TBD" methods to be fairly obvious from the name and parallel expectations with the documented methods.

And if course, that's the problem -- it's "good enough" for us to get by, so it doesn't seem urgent, I suppose.


For an example, on the device object documentation in the "to be documented" section:

  • void sendEvent(Map properties)
  • void updateSetting(String name, Map options)
    what properties are available for sendEvent? No idea. Gotta go look at community drivers to see various options people ued.
    what options are available for updateSetting? No idea.

there's also "removeSetting() and clearSetting()". Whats a setting? Whats clear vs remove do? Does clearSetting null it out? Searching the docs for "Setting" doesn't come up with anything helpful.

Instead I'm using ST documentation via an archive site from years ago.

Why aren't the properties for sendEvent() documented? We're not talking something obscure.
This is my frustration with the developer documentation on HE.

This list is very helpful as it exists: Allowed Classes for Import | Hubitat Documentation But how about the documentation on all the and com.hubitat.hub classes? What methods and objects are available? Are the com.hubitat.*Wrapper classes already documented somewhere else and I just don't know where to look? Do I need to include these for special uses or are they just the classes the base Device, State, etc objects come from? No idea.


I agree that this is a pretty commonly-used method that should be better documented, so I've added specific information. Thanks for pointing things like this out!

I am hesitant to do much more with the "raw" object documentation, both because these are often generally less useful than how to actually use at least the most commonly used pieces related to them (which should be demonstrated somewhere...) and the fact that I've been told we'll get better self-generated documentation for things like this in the future, so such effort may be wasted now. But if that doesn't happen, and such information is actually available...

PS - I'm pretty sure that removeSetting() and clearSetting() are just aliases for each other, but this would be pretty easy to verify in an app (not quite as easy with a driver, but I assume they'd be the same) ... but not confident enough to document it as such right now. :smiley:


Requested Dec of last year. The documentation went to a new website with new user docs and such but the developer documentation doesn't appear to have been worked on except for a new nav wrapper.

Maybe I'm the only one. Everyone else seems to get by without it I guess.

1 Like