I would like to send a notification that indicates that device and attribute triggered a rule. I thought that %text% would do something like this, but unfortunately I am getting ānullā in this case:
I assume this is happening because I am using a custom attribute from a community driver to trigger the rule, as I tried this with virtual devices and it provided the device, attribute and its value within the %text%. (Ex.: āVirtual RGBW Light level was set to 66%ā)
Thoughts?
Probably a driver shortcoming. The "virtual blah light level was set" is set on the description field of the sendEvent method in the driver. I would assume this driver doesn't follow that flow (e.g. the description field is not set with the event).
Link to the driver?
I might be misunderstanding what you're trying to do but won't %device% at least get you the device name? And %value% would get you the value if not the name of the attribute.
You will find that not all drivers and event types populate the %text% variable. However, you may be able to work around that by inspecting %device% (or other event var) instead, and with that information create the necessary custom notification message.
Ah! It is possible that the description field was not set - I didnāt realize that even existed 
. I am trying to achieve this with @thebearmayās really awesome AirTings Integration:
Correct. In this case, I want to know whether the trigger was VOC or one of the PM levels, and I thought that using %text% might provide me with this information.
Gotcha. But since the values of the two attributes vary so widely and the ranges don't overlap could you do what @LibraSun suggests with a conditional? Not as clean as what you wanted but doable.
You can try updating this section:
void updateAttr(String aKey, aValue, String aUnit = "") {
desc = "${dev} set ${aKey} to ${aValue}"
sendEvent(name:aKey, value:aValue, unit:aUnit, descriptionText:desc)
}
Untested and I'm doing this all from my phone 
Yes, definitely an option, though PM could I think go above the VOC thresholdā¦
Will give it a try! Thanks!
The %text% var will not be populated by certain drivers/event types, such as: Rule paused, Private Boolean set, Hubitat Ping presence detected, Local End Point called, Certain Time occurs, among others. It all comes down to the app or driver involved.
Iāve updated the code and it saved, so looking good so far! I might have to burn some toast near the sensor to try it outā¦. Lol
Unfortunately, %text% remains nullā¦ 
Anyone want some burnt toast? They brought up the PM 10 and PM 2.5 up to 291 and 263 respectively, I thinkā¦
I have great analogue smoke detectors in the house - My wife and one of my sons immediately asked who was burning toastsā¦ They do have a distinctive smellā¦
(Note: I could also just split the rule into 3 separate ones each with their trigger - keeping that in my back pocket if we canāt get %text% to work.)
Think I see the problem. Gimme a second to get to a desktop.
For now:
void updateAttr(String aKey, aValue, String aUnit = "") {
desc = "${aKey} set to ${aValue}"
sendEvent(name:aKey, value:aValue, unit:aUnit, descriptionText:desc)
}
Yup! That was it.
I made a small change:
void updateAttr(String aKey, aValue, String aUnit = "") {
desc = "${aKey} value of ${aValue} detected"
sendEvent(name:aKey, value:aValue, unit:aUnit, descriptionText:desc)
}
But I think the following would probably be better:
void updateAttr(String aKey, aValue, String aUnit = "") {
desc = "${aKey} level of ${aValue} detected"
sendEvent(name:aKey, value:aValue, unit:aUnit, descriptionText:desc)
}
@thebearmay, any chance that this could be added around line 136 of the driver?
Should be an easy change, let me lookā¦
Made the change to the device driver, go ahead and import it directly - Iāll update the bundle later today or tomorrow.
Cool! I had made the change locally - just want to ensure I donāt lose it with the next HPM update!
Iāll do a manual update to ensure it works as expected.
For those that might be interested, I have noticed that when we are cooking and would typically need set the air exchanger to turbo to avoid the smoke alarm going off, the PM levels go way up. This rule automatically sets it to turbo as long as the smoke alarm wasnāt triggered.
Tested it and confirmed it works. Yay!
EDIT: Nevermind -- I think I'm just confusing myself with what I've done in Groovy to write descriptionText in the first place? 
I see you've got a solution now, but for anyone running into this kind of thing in the future, even without driver modifications, something like this should have worked too:
%device% %event% is %value%
The key I don't think I see above is that %event% gives you the name of the attribute/event. As noted now, the %text% variable refers to the descriptionText property the event, but this is optional, even though many drivers conventionally set it to something similar to this. (So, no conditionals necessary, no specific driver modification needed, and ... I'm not sure where non-device triggers fit into this discussion, even though they can also affect--or often not--the value of these, since there are none in the rule you posted.)
Download the Hubitat app
