but it says "to be documented later"
So, what am I missing ?
why do I get "null" to the latestState() ? , is it not set ?
if that's the case, how should I set it ?
note that, when I check the device, I can see "status" attribute is set.
Evt is an event object passed into a subscription handler it will not have a device wrapper, so the device reference is going to be null.
If your subscription is to the status attribute than the event value attribute will contain the latest status value.
the event is subscribed with : subscribe(childDevice, "status.error", eventHandler, [filterEvents: false])
and when I log "evt.device" it shows the device name.
so I had thought that evt.device is actually the device and that I could get the latestStatus
and this was working with ST hub.
what I'M trying to get is the "statusMsg" attribute, when there is a "status.error" event (ignore that I wrote "status" in first post)
now what can I use instead of this ?
I just looked at some apps I wrote, and evt.device is indeed a device wrapper, so I was wrong about that.
you should be able to fetch the current value of statusMsg by using evt.device.currentValue("statusMsg"), if you need to cast that as a string use .toString()
What do you mean "supported"? I don't see it defined as part of any standard capability. You are, of course, free to define whatever custom attributes you want. Did you do that, and if so, what does that line look like in your code?
(Just guessing that you'll get null if you call this on an attribute that doesn't exist, even if you momentarily get it to appear with sendEvent().)
you are correct. After adding it as an attribute, problem fixed.
but this was working on ST without that.
interesting...
I guess a different implementation on Hubitat...
Sorry, I mis-read and thought you were talking about the attribute, not that method (which you are correct is indeed supported). Glad you got it figured out!
I'm not sure what SmartThings does with attributes you don't declare, though from what I recall you're supposed to do it there, too. On Hubitat, the behavior isn't defined either, but as far as I can tell it appears under "Current States" (which you saw) until you reload the page (then it disappears, and apparently fetching the value at any point, as you tried, does not work).
To be complete, I guess I should mention this as well:
The latestState(), currentState(), or currentValue() methods (and the current<AttributeName> property)--which as far as I know are all synonymous, though most Hubitat coders seem to prefer currentValue() from what I've seen--would work with the former. That is, it should return the current value of an attribute (something under "Current States" on the device page--again assuming it is either a standard or properly declared custom attribute).
You probably don't need to do both of these. I'd use an event ("Current States"), as above, if it's something a user would care about (e.g., an event they may want to subscribe to in an app). If it's just something the driver is tracking for internal use, I'd use state instead. To access state values, of course, you don't need any of the above methods and can just use state directly.
ok. but it is already a state event.
state is "error"
but additional information is required from the cloud
that information can be any statement. so it is written to an attribute (statusMsg)
creating states for all possible messages , not possible...
he's talking about reading and writing the value to state.statusMsg...
But if you're sending this as an attribute value, there's no real point in updating the state attribute with the same value, make sense?
