My RM "Wait for event" does not seem to be canceling.
The device its referring to (i.e. the custom attribute) is from a custom ultrasonic distance measurement device. The device will take a reading when
it receives a "@."
It will echo the "@."
It will take a reading and send it to a custom HE driver.
The driver will test the measurement against a number
The driver will report either "present" or "not_present"
The driver will them report a "null" so the next time a mearsurement it taken when it reports the status the status will have changed from "null" to "present" or "not_present"
The log shows when the value of vehiclePresent is updated after a measurement, RM receives it but the Wait for event timeout does not get canceled.
As I understand it, Last Event Device is the device that most recently triggered the rule. Since your Wait has nothing to do with the Xiaomi with hole in body contact the timeout won't get canceled.
Thanks for the reply but I guess I'm still confused.
If the RM rule was triggered by the Xiaomi resulting it the "requestMeasRM()" to be executed what would the wait expect from the trigger that happened (at that point) in the past.
And the Wait for event: specifically calls "Last Event Device is vehiclePresent changed"
However I kinda see what you are saying but I don't see how the two devices are related.
Perhaps the "Last Event Device" might refer to the Xiaomi, however the Xiaomi does not have an attribute "vehiclePresent"
I think the Last Event Device is useful when you have multiple sensor that can trigger your rule but you want a different action based upon which sensor it was. I don't think executing "requestMeasRM()" will have any impact on Last Event Device. I just don't think the Wait with Last Event Device will give you your desired result.
@bravenel
I read the documentation on the "Wait for Event" function, however I seem to be missing something as the logs from my original post seem to suggest all should work, however the "Wait for event" always times out, regardless of the change the exemplar device attributs.
It's a custom ultrasonic distance device working through a 'custom' zigbee radio.
The device driver sets "vehiclePresent" to "null" after a measurement has been completed. So when the rule starts the vehiclePresent = null
The measurement will change vehiclePresent to either "present" or "not_present" which should be considered an event of vehiclePresent changed.
vehiclePresent is a string, could this be an issue?
I'll have to simplify the driver code and see if I can understand what is going on.
You didn't answer my question. What is the name of this device (not the driver)?
And, since you only have a single device that triggers this rule, why are you using Last Event Device instead of that device (Xiaomi with hole in body contact) in the Wait for Event?
I thought I had. It is a custom ultrasonic distance sensor based on an Arduino "talking" to the Hubitat Hub via a Zigbee (again custom) link.
I clearly understand if my driver or device are at fault it is my responsibility, not yours.
I guess I was hoping given the logs and basic information you might see something obvious.
Look, it was explained twice above that the device identified by Last Event Device is Xiaomi with hole in body contact, as that is the device that triggers the rule. So the Wait can never be satisfied by events from some other device. Just put the device you want to wait for in the wait, not Last Event Device.
Ignoring any device confusion here, as that seems to be the problem in this particular case, I was playing around with this feature and still wasn't able to get it to work when configured (I think) correctly. Could there just be something with "Last Event Device" when used with "Wait for event"? I created a simple rule with a virtual omnisensor:
It should satisfy the wait when the sensor (which started as motion active) goes inactive, highlighted below, since it is the "last event device." Instead, it waits for the timeout:
This works fine if I just directly specify the virtual omnisensor device instead, though it's my understanding that "Last Event Device" should be equivalent in this rule (even though this is a contrived example where I'd have no reason to actually use that feature).
Even when using the same attribute as my trigger (but a different value, contact closed), I wasn't able to generate any event that made the wait be satisfied, as far as I was able to figure out.
In case it isn't clear now, the "exemplar device" is just one RM will read to get the list of possible attributes to show you; it's not (necessarily) the device it will actually wait for--that will be the "last event" device, per the name of the selection you made previously. It just needs to work with something so it allows you to choose the options you ultimately need for whatever the real device may be.
If you want a specific device, you'll want to just pick that device directly (by capability, not as "last event device") -- as you've probably seen now.
I wasn't intending to ignore your question. It would be counter productive to do that. I just misunderstood the device you asking about.
I had in my mind the "Wait Event" would wait for an event defined by the "exemplar" defined device. I'm still confused why the "Wait Event" would only respond to the event the initiated the rule and not the "exemplar" device selection. But I now understand the function of the "Wait Event"
It's not Wait for Event, it's the use of Last Event Device. You can Wait for the specific device. Last Event Device is a very special case where there is a need to identify a specific device out of several the might have triggered the rule. In and of itself, it has nothing to do with Wait for Event.
