Device not shown in Custom Attribute Trigger list

I have a device (named "IRTrans") that seems to be working properly except that it seems invisible to Rule Machine. The device driver is outputting state events and attribute values of normal types (string, number, etc) that should be able to be accessed. Why is Rule Machine ignoring them?

image

What does the driver code metadata look like, specifically lines (likely toward the top) that begin with "capability" or "attribute"? (Where I'm going with this: my guess is that it either doesn't define any custom attributes or use capabilities that require stock attributes, or that none of these have been initialized to a value otherwise.)

Also installable via HPM. (Hubitat Package Manager)

Here is the driver (it's not very long):

metadata {
    definition (name: "IRTrans", namespace: "hubitat", author: "Garrett Cook") {
		attribute "lastMessageReceipt", "Date"
		attribute "actionReceived", "String"
		attribute "fthis", "Number"
	}

    preferences {
		input name: "infoLogging", type: "bool", title: "Enable info message logging", description: ""
		input name: "debugLogging", type: "bool", title: "Enable debug message logging", description: ""
    }
}

def parse(String message) {
	def msg = parseLanMessage(message)
	displayDebugLog("Message parsed: ${msg}")
	sendEvent(name: "lastMessageReceipt", value: new Date(), displayed: false)
	def matches = ("${msg}" =~ /(?<=header\:GET \/)\S+(?= HTTP)/) /* grabs integers of Pella device number */
	def firstmatch = matches[0]
	displayInfoLog("Action received: ${firstmatch}")
	sendEvent(name: "actionReceived", value: "${firstmatch}")
	state.fthis = 7
}

private def displayDebugLog(message) {
	if (debugLogging)
		log.debug "${device.displayName}: ${message}"
}

private def displayInfoLog(message) {
	if (infoLogging)
		log.info "${device.displayName}: ${message}"
}

Try adding a line like capability "Sensor" along with your attribute... lines. I'm not sure it's legit to have a driver with no capabilities declared at all, but "Sensor" is sort of a catch-all you can use that doesn't actually require any attributes or commands but still lets you specify a capability (with "Actuator" being similar and the difference between them probably not mattering as a result of this, though the former is theoretically for devices that just report and the latter for things that accept commands).

Also, I don't think "Date" is a valid attribute type, but if you're not using this particular attribute in RM (or non-custom apps) it probably won't matter too much. :slight_smile:

1 Like

Yep that fixed it, thanks!! I had left out capabilities as they seemed superfluous for what I was trying to do -- seems they were not :slight_smile:

1 Like

Depends on what it's used for. In the use case shown, it's fine. It does allow the date to be shown in the device state on the device page. I suspect that device.currentLastMessageReceipt would return the date object, if referenced in an app. It probably throws an event with a date object value when set also.

It's not 'valid' as per what is defined in the documentation. It would be simple to see if it works as above.