Sure here is the screen shot of my test rule.
Were you able to trigger any other actions like toggling a switch?
Just to assist me a bit more, are you able to trigger any other actions other than the log action in your rule, eg toggle a switch?
No, but if the trigger matches, I can't imagine the type of actions would matter beyond that. It sounds like, according to your logs, the trigger isn't really matching and no actions are running?
Me neither.
It doesn't make sense to me either but would you mind indulging me and try a different set of actions?
OK, weird, now I can't even get my previous example to work--this does nothing now, though the event (not trigger and definitely not actions) gets logged:
for this:
The only difference I could think of is that the initial value of variable was null when I started and not the second time (above) I tested, but I tried with a new sensor and no set variable value, and it still didn't work, even though this should be the exact same thing I did above... 
Using another custom attribute works fine:
(ignore the fact that I deleted my test sensor without removing the trigger first and the fact that you don't need to use a custom attribute for motion; it was just something I did for testing...tried switching back to custom
variable attribute for my omni sensor, and still no luck)
@bravenel, anything you might see here about the interaction between RM's "Custom attribute" trigger and however the events might get generated for the Virtual Omni Sensor driver that might cause a trigger that should match to not?
Thanks for that - this is the behaviour I'm seeing.
I tried this just now (had to set up a new virtual device in order to get the variable to show up as "null") and the rule still won't trigger on a variable change.
Show the subscriptions for the trigger. I suspect that changed doesn't mean what you think it means for this context. I'll look into it.
Is this what you mean?
No. The App Status page (gear icon) Event Subscriptions section.
Hi, yes. I just tracked down the bug. Fix will be in next release. Sorry it took so long.
2 Likes
No problem - thanks for the fix!
Is the Virtual Omni Sensor variable the only way to pass text back and forth. I want to do something similar by passing text from homeseer to habitat. Isn't there a simple one field device that could do this - or could I create a custom device?
If you want a device and don't want the extra capabilities of the Virtual Omni Sensor device, you could create a global string variable in Rule Machine, then create a connector (same place) for it. This will show up as a device, and--with a string variable--the only commands and attributes you'd see would be ones to get or set the actual string. Without Rule Machine (which you really don't need to use for any purpose except this if you don't want to), you could certainly also create a custom driver. but I'm not aware of any other built-in ones that do only exactly this.
That being said, I'm not sure what your use case is; if you don't need a device at all, you could do this over HTTP and pass whatever you want (e.g., as GET parameters or a POST body). This, of course, depends on what the API or whatever integration you're using on the other side lets you do and what your use for the text is in Hubitat. It would also likely require a custom app, so if you want something built-in, the above is probably what you want.
1 Like
nh.shotftam created this one a while back if you don't want to re-invent the wheel:
Summary
/*
* Virtual attribute
*
* Licensed Virtual the Apache License, Version 2.0 (the "License"); you may not use this file except
* in compliance with the License. You may obtain a copy of the License at:
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software distributed under the License is distributed
* on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License
* for the specific language governing permissions and limitations under the License.
*
* Change History:
*
* Date Who What
* ---- --- ----
* 2020-09-17 nh.schottfam Original
*
*/
metadata {
definition (name: "Virtual Attribute set", namespace: "nh.schottfam", author: "imnot_bob") {
capability "Actuator"
attribute "var1", "string"
attribute "var2", "string"
command "setVar", ["string", "string"]
command "clrVar", ["string"]
}
}
preferences {
input("debugEnable", "bool", title: "Enable debug logging?")
}
def setVar(var, val) {
if(var in ['var1', 'var2']){
sendEvent(name: var, value: val)
if(debugEnable) log.debug "set variable $var"
} else log.warn "improper arg $var $val, variable should be var1 or var2"
}
def clrVar(var) {
setVar(var,' ')
}
def installed() {
log.trace "installed()"
for (v in ['var1', 'var2']){
setVar(v,'')
}
}
def updated(){
log.trace "updated()"
if(debugEnable) runIn(1800,logsOff)
}
void logsOff() {
log.debug "debug logging disabled..."
device.updateSetting("debugEnable",[value:"false",type:"bool"])
}
Hubitat made the code available for the Omni sensor and you can delete all of the Capabilities you don't need.
Hah! So that's what the connectors do 
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.
