Can you not include logic to look for this? Or are you meaning it would be nice to have some indication of what triggered via the endpoint? That may be hard to do without introducing an optional (internal) parameter, given the endpoint can be triggered from outside HE (I believe).
I was asking whether you can check for a null value, but I'm likely missing the bigger picture of what you are trying to to do and what is needed.... Plus endpoints weren't mentioned specifically in the OP, so probably best to cover them elsewhere if you are interested, though not sure I can help.
Though something catching the IP address of the sender might be useful
2 Likes
While it's hard to say more without knowing exactly what to want to do, in general, if you want a rule to do different things in response to different triggers, what you really want to do is make different rules. You're doing different things anyway, and it eliminates the need for awkward conditional actions like "fragile" ones that depend on a device name (which you can change independently of the rule). The "simple" example in the OP actually demonstrates this point quite well, though again, a practical example may have other ways to achieve the goal. For example, a trigger-less rule could be written to "share" identical actions among multiple rules, among other options.
This is entirely dependent on the driver. Rule Machine plays no role except reading the value.
1 Like
These are not devices; they do not have drivers (only devices do); they are not events (in the platform sense); and, as documented, the "built-in variables" for trigger events are only guaranteed to have meaningful values when the trigger was an event.
1 Like
Pondering out loud here-
All the "make Multiple Rules" suggestions aside....
I think I like your concept of "one place" to look at all the control logic affecting a particular actionable device. There's something here that may be/could be...potentially...possibly...(with expanded RM capability along the lines you suggest and more) ....a Best Practice.
While this could get complicated, so is managing multiple rules and wondering which is in effect, which is overriding another, and maintaining multiple rules relative to the use/activity of said device. As things expand in one's environment the cross collaboration, and consideration/avoidance of stepping on another rule, becomes more pertinent. It's something you often discover is a problem when you least expect it and go "oh, of course that's why it's on/off and back on etc...".
Preparing for the barrage of counter opinions, and that's fine cause I'm still pondering the implications of what you're doing.
1 Like
I respectfully disagree. Once you start having multiple rules acting on a given device, it becomes hell to debug and hard to have a full picture of what can act on the device.
The ideal scenario to make sense of what happens to a device is to have a single rule that acts on it and nothing else so that all of the logic is in a single place.
And thatās why I asked if it was possible to know which trigger fired off, not which device.
Regardless of the Ā« time Ā» issue not being a device, I may very well want to do something if a contact sensor is open, and something else if it is closed. Same device, different triggers. Contact sensor is an easy workaround, just check its binary state, but not all sensors are binaryā¦ I may want to control the state of a fan based on a temperature sensor: if it is lower than X, stop the fan, higher than Y, start on low, higher than Z, start on medium, increased more than A, start on high
I understand this concern, but there are two things that can help:
-
the "in use by" section on the device detail page shows you what apps are using device, so you do not have to guess (or remember); and
-
the "Events" page for the device, accessible from the device detail page, shows you what commands were sent to a device and by what app (not just actual events generated by the driver, contrary to its name -- this is a fairly new feature I think many people missed)
This is in addition to other tools you may have, like Logs or careful app naming, which may also help.
It should also be noted that common advice in the community is that multiple, smaller rules are easier to troubleshoot than one large rule.
2 Likes
Thanks, Iām already aware of these. They help, thatās true, but not nearly as much as having all of the logic in a single rule.
Another example, I installed a vibration sensor on the dryer, to know when itās on, but itās reset time is short and it is very sensitive, so it turns on and off frequently while the dryer is running, and it also turns on sometimes when the washer is spinning. So what I want is:
If the motion is on for more than 1 minute: turn the virtual switch Ā« dryer Ā» on
If the motion is off for more than 1 minute: turn the virtual switch Ā« dryer Ā» off
Trivial to do in one rule if I can know which one triggered, but impossible two do without. It requires 2 rules when both are dead simple.
In this case, it is not about making the logic simpler to see, it is about removing redundant rules that have no reason to exist other that they canāt not exist, and pollute the logs and list of rules. Itās really the same automation
In that case can't you just trigger the rule on a change and say if the motion is active wait for a minute before turning switch on else wait for a minute to turn it off, making sure the wait action will be cancelled by any subsequent triggers of the rule?
maybe ? How do you cancel wait actions when a new trigger happens ?
@bertabcd1234 example is probably better. In my example I'm relying on what I believe to be one of the types of wait/delays that are cancelled automatically .. just not sure which (or if, if I"m honest).
Maybe, but you would at least need to prevent multiple executions of this in parallel for a rule that runs over a duration of time. Wouldnāt you ? It also means that if something change the switch state while the wait is happening, itā¦ screws it up ?
I prefer having the waits before the trigger, and the rules to be instantaneous, rather than having the rule last a long duration and have to deal with concurrency within the rule execution
A trigger will cancel any waits. I'm not sure what concerns you would have for simultaneous execution based on that, or what you mean with "Wait before trigger" since you cannot start running rule actions (including waits) without a trigger.
Nothing is stopping any other app from running commands on your virtual switches, but that is true no matter what approach you take. But this rule doesn't care what the state of the virtual switch is--it just sends the commands specified by the actions.
See also:
Another idea: create such a rule, enable all logging, and see if it does what you want or could be modified to do so. 
(Maybe don't use your "real" devices if you have concerns--or other apps/rules that would change their state.)
1 Like
Do you mean because the wait is on the same device ? Or do you mean that in general that if a rule is triggered while the same rule is running, any wait event will be cancelled ? Thatās highly counterintuitive
You may want to read the document I linked to.
Any trigger event for the rule, regardless of whether it is the same as any device in your actions or whether it's a device at all, will cancel any "Wait" actions.
5 Likes
Ok, I learned something about wait events. Interesting, and it will simplify some of my rules. It does not address the other types of multiple triggers, but it is indeed helpful in that specific situation. Thanks
3 Likes
What do Wait statements (event or expression) do in case of a hub reboot ? Does it keep waiting in the rule upon reboot ?
Edit: I found the answer here Is there documentation on what type of wait events survive a hub reboot? - #11 by bravenel
Necroreply I know, but this technique which I accidentially rediscovered for myself, and then found in @pseudonym's post proved really handy for me tonight.
I have a rule which watches for particular state changes, (doors, locked, closed, open, etc), which beyond using the changed trigger, also has a time trigger that validates the lock states every minute. (Probably unnecessary, but I've had sensors that reported slowly in the past...).
However, i log these events, and every minute I ended up with a "Triggered" event being logged. Using a local variable set to the string value of %device% allowed me to filter out "Triggered" events and not bother logging them.
Useful to me in any event.
It would be nice to use %device% and other built in variables in conditions without first mapping them to strings, though!
Thanks for suggesting this technique @pseudonym, I just wish I'd read it before beating my head against the virtual keyboard so many times....lol
S.
4 Likes
