Same here.
I'm not using it currently - has it been deprecated/fixed ?
I wonder if they have supplied a removeDataValue() or deleteDataValue() method instead ?
1 Like
If it was it is not posted in the documentation yet and the obvious names did not work.
@chuck.schwer Any help?
1 Like
Works fine for me, regardless, removeDataValue() will be available in the next release
5 Likes
Probably just String coercion but he'll answer if he comes back.
If you are wanting to store an object you probably want to use state anyway over data. What were you thinking about putting in there?
In my opinion state is where they belong. They're actually more in my face if they are in data. For me, I want data to be clean because that data is never changing, about the device and informational.
An "isConfigured" or "isFirstTime" or "isAnything" var (which it sounds like you are creating) isn't static. It's dynamic even if it only changes once. If it's truly static you can create a static field. There is a weird annotation type thing you can use.
import groovy.transform.Field
@Field static boolean someVar = true
or more Java like would be...
@Field
public static boolean someVar = true
Otherwise, I think state makes sense even though it's in the user's face. State is the part of their face where I think it's intended get dirty.
1 Like
This will be shared between all instances of the driver.. If you have multiple of the same device..
It would be shared between all instances of anything running in the same JVM environment... all the apps, the OS, the drivers, etc.
Yikes, I better go take a look at it. That was like... one of the first I wrote. I think I touched it again a while back but I don't remember what I did to it. I'll make sure it's "okay" before you base all your drivers off of it.
1 Like
That is How I understand it as well.
I was using the field to store certain info such as my zwave driver capabilities and was seeing a lot of strange behaviour on my zwave devices. They were parsing zwave commands that they shouldn’t be receiving. I did a little research on the field stuff and read that it’s public to all. I think I was clobbering the same variable amongst my drivers. So I wrote them all using local getters and don’t have the issue anymore.
I just took a look. It's okay. Some of those weird Groovy getters I would make static fields today. Besides that it's not horrible. I could be more concise but I tend to err towards readability.
*edit: I remember what I did with it. I finally got rid of 0 based source commands... so the commands go from 1 to 6 instead of 0 to 5. When I picked that stuff up from the original dev on SmartThings I think it was that way. I was okay with it but I considered it to be a pitfall of confusion for non-programmers so I changed it last time I was messing with it.
1 Like
This is not consistent with my understanding. All the @Field annotation should do is take something that would normally only be available in the script's run() method and instead "elevate" it for script-wide access as a field. We can't see what's going on behind the scenes with Hubitat's implementation, of course, but generally anything top-level in the script gets shoved into the auto-magically created run() (whose creation we can't normally see but definitely can't in Hubitat), which would otherwise make @Field-less variables local to that method only and pretty much useless in Hubitat. In "regular" Groovy, there is no way this would have an impact on an entirely different script. But again, there are implementation details on Hubitat we can't really see...
(I'm also not sure how Hubitat would handle the difference between static or not, but all of their examples use static, presumably because it doesn't persist between executions--or at least it's defintely not a documented method of doing so--and there's generally no need to manipulate it, so there's no reason to make each instance have its own; I see this more or less as a cleaner method compared to workarounds like getCommandClassVersions()- and getConstantValueXYZ()-type methods you sometimes see.)
1 Like
I don't know a lot about Groovy to be honest but I know enough about Java's architecture that I can guess about what Groovy does.
For Java there are three memory segments; stack, heap and code. Stack, of course, contains local variables and reference variables (a memory address to an object on the heap), etc. Heap is all the runtime objects and their class fields (instance variables that aren't declared static). The code segment is where the compiled byte code is stored and with it... any class members aka static variables. So, while they are editable they are stored in the code segment and they would edit for anybody in the same memory space.
The next question you should ask yourself is what or who defines memory space? That kind of depends on the implementation of how our drivers get loaded by HE. Normally, when you aren't class loading i.e. loading your own classes at runtime with a class loader, there is a system class loader per JVM instance. So, if they don't use a class loader to get the instances of our driver they are using the JVM provided instance and everybody shares the same code segments.
Here's the catch; they could be class loading our driver instances which would give them their own memory segments. Our driver instances might also get cleaned up frequently enough that the driver class is garbage collected and our static variables go away with it and have to be reloaded.
And then there's the possibility that Groovy just changes all of this because... well, Groovy. (It's not very likely though.)
We probably won't get an answer from Chuck about how our drivers/apps are loaded but we probably don't need one. We can probably test this out if we really wanted to with a test driver that created some static variables, modified them or didn't based on something we can do programmatically and then we do that thing at purposeful intervals to test loading of our driver and persistence of our variables. I don't care enough to do that. I treat static like read-only.
I bet nobody expected this topic to go turn this direction, did they?
2 Likes
