Driver Attributes - Current States

Why do some driver attributes result in a Current State that is always showing in the Current States listing on a device view and some attributes are transient and disappear when you refresh the page. Those same attributes that disappear also can be duplicated. I'm using the same sendEvent code for each, I don't understand the difference.

Thanks

Attributes that disappear on refresh are either not defined in any of the drivers included capabilities or aren't explicitly defined in the driver.

Hmmm, so if I'm reading that correctly, I can't make a custom attribute sticky there, because they're not directly associated to the capabilities?

definition (name: "Envisalink Connection", namespace: "dwb", author: "Doug Beard") {
		capability "Initialize"
		capability "Telnet"
		capability "Alarm"
        capability "Switch"
        capability "Actuator"
	   capability "Polling"
        command "sendTelnetCommand", ["String"]
        command "StatusReport"
        command "ArmAway"
        command "ArmHome"
        //command "ArmAwayZeroEntry"
        //command "SoundAlarm"
        command "Disarm"
        command "ChimeToggle"
        command "ToggleTimeStamp"
	   command "poll"
        command "setUserCode", ["String", "Number", "Number"]
        command "deleteUserCode", ["Number"]
        command "configureZone", ["Number", "Number"]

        attribute   "Status", "string"
        attribute   "Codes", "json"
        attribute   "Last Used Code Position", "string"
        attribute   "Last Used Code Name", "string"
	}

It's curious though, because Codes always sticks, while Last Used... doesn't.

I make a habit of camel casing attribute and command names, remember event attribute names were never designed to be sentences, and the display of them in the driver details wasn't designed for readability or as a proxy for a dashboard tile.
Friendly event text should use the displayText attribute in the sendEvent method.

3 Likes

Mike,
What is the purpose of the actuator capability?
I am trying to create a couple of virtual devices for the purpose of dictating the icon in google home and on my google home hub for basic switches. I found that if I use the "Virtual Switch" device to control a couple of lights that google home does not recognize it as a light. I modified your virtual lock example and just have the light capability and now google home recognizes it as a "Light" and uses a light icon instead of a switch. I plan on creating a few more basic virtual devices that associate to a basic plug-in outlet that control items like a coffee maker, dehumidifier and such but based on the capability to define the icon in google home. The only thing i cannot figure out is, why does the actuator capability exist in most drivers? I seem to be able to get a virtual light to function without this capability, but cannot figure out the pitfalls )If any) of not having the actuator capability.

It is simply a catch all for any device that accepts commands, sensor being the catch all for devices that only produce commands.
Neither of these have any inherent attributes or commands and are only used in app device inputs as a very gross device filter.

4 Likes