Groovy Version Update?

🚧 Developers Coding Questions
9

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....

10

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.

11

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
12

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.

2 Likes
13

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:

14

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

3 Likes
15

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.

6 Likes
16

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:

https://docs2.hubitat.com/developer/command-object 404not found
https://docs2.hubitat.com/developer/state-object 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.

2 Likes
17

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.

3 Likes
18

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.

image
image1112×880 71.4 KB

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 com.hubitat.app 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.

4 Likes
19

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:

3 Likes
20

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
21

I have been using switch statements for years.

	 switch (holidayName.currentVariable.toString()) {
			
		case 'St Patrick':
			log("••• St Patrick's Day •••")
			groupOdd.setColor([hue: 33, saturation: 100, level: 50])
			groupEven.setColor([hue: 25, saturation: 100, level: 50])			
			echoScene1.on()
			break
22

Yes, switch statements are old. Switch expressions are more recent.

def result = switch(i) {
    case 0 -> 'January'
    case 1 -> 'February'
    //...
    default -> throw new IllegalStateException('Invalid number of month')
}
23

On the contrary, there have been many changes. New documents include:

Other changes include a more organized homepage and some changes and additions to other docs (including the above just now), and I'm hoping for more in the future.

It is true, as I mentioned above and for the reasons mentioned above, that some of the "raw" object documentation remained as-is. And again for the reasons above, I'm hoping this, too, will change.

However, I'd say that previous feedback, in general, suggested that things that the new documentation addresses -- how to actually do anything with these methods, how to even get started -- was lacking. These are the first steps to addressing that, and I hope developers find them useful (especially ones newer to the platform, as opposed to more experienced developers who have the skillset to find things out on their own like I suspect you do, though feedback still is certainly welcome!).

11 Likes
24

Why?
Very doubtful... There's really no reason... Flame if you must, just know its deaf ears from staff on this one...
We write over 99 percent of driver and app code with the existing Groovy version the remainder in java. I seriously don't understand the problem.

25

No flaming from me, but as to why, it's annoying that when one gets online Groovy documentation and examples, fewer and fewer are actually usable in Hubitat. My most recent example was finding that Map.retainAll() was added in 2.5, so again not present.

I'm not asking for a specific updated Groovy version, just some plan for moving forward and keeping up. 3 was current back when I posted this, so that's the one I mentioned.

26

Generally a goood reason to upgrade a platform is support. I just did a quick search and from what i can see Groovy 2.4 is EOL and is no longer supported by the apache foundation. I understand the idea of sticking with what works and what you know, but that kind of thing means more issues will start to creep up.

2 Likes
27

I must say the Mike has summed this up above. Sorry, but we do not have any plans at present to update Groovy. Never say never, but that's where it stands now.