I am trying to understand the "Time since event" condition.
I want a condition to be true any time the device has reported a voltage value (any value) within the past 3 minutes and 20 seconds.
The image below shows a voltage report of 123V at 09:53:56.
The data in the image is current and was captured about a minute after the voltage report occurred.
As you can see, the time since event resolves to 29 minutes and 24 seconds. For some reason these voltage reports are not being detected.
That's true. What's displayed here is merely a group of conditions I created for test purposes to try to diagnose/demonstrate why they aren't working as expected.
Even though the conditions are not in use, they still seem to actively update. If I refresh the screen that contains these conditions, the times shown will update and the true/false state will change if the conditions are met.
The problem is that the Time Since Event Function does not always detect and record the time when an attribute updates, even though the attribute change is recorded in the log.
This is true, but generally Rule Machine is not a dynamic webpage. That's why you need to refresh to see the updated values. The same thing would be true if you hit "done" and then went back into the rule. The values are based on when you go into the rules/conditions at that specific point in time. They are continually changing, but not while you are on that page.
@hydro311 is correct in that you need to put the conditions into the rule and turn on logging of the rule to confirm this statement. What is the full rule (triggers and actions)? Post that and the logging associated with the rule showing that it is not working correctly. From there, the community can better help diagnosis the issue.
Thank you. I've never used Rule logging before. Very revealing. In this case I believe it reveals the inconsistency I posted about:
As shown in the log below:
At 5:51:44 a voltage value is logged for the device.
Two seconds later the rule is manually started and the condition is evaluated as FALSE because the Time Since Event value incorrectly shows 4 minutes since the last voltage report (instead of the correct value of 00:02).
At 05:53:46 (after the rule is finished) another voltage value is logged.
Four seconds later the rule is manually started a second time.
This time, the expression is TRUE because the Time Since Event value shows the correct value of 00:05
In both instances the condition should be TRUE.
The first instance uses a faulty Time Since Event value and shows FALSE.
The second instance uses the correct Time Since Event value and shows TRUE.
I really appreciate your help. Is there something I'm missing here?
Your rule doesn't have a trigger - how do you invoke this rule?
In the logs corresponding to your last logs screenshot, the first entry at the very bottom is voltage = 122V at 05:49:41...
In the actual logs, is that the device's first voltage reading? If so, that's where the 4 minutes come from.
And if that's true, then perhaps "Any Value" just refers to any change in value, but not periodic reports of the same value (e.g. 122).
Many of us here have learned to avoid triggers and conditions that are akin to "any changes/changed" since it can very easily get too foggy and messy.
In most cases (dare I say all), better results will be achieved using specifc values instead, even if that means splitting things up across multiple rules.
No and I think @hydro311’s explanation probably answers why you are seeing the results that you are. With that said, what’s the real world thing you are trying to control/solve? If this was not a test, what would be the trigger and actions you would want?
Whether a test or not, do you believe the behavior documented is correct?
Surely you're not saying the reason it displays this behavior is because it is running in a test environment.
I believe that if the event parameter is updated (as the log indicates), the value that the Time Since Event condition uses should then correspond to the time elapsed since that event last took place. Do you not agree? Isn't that what it's supposed to do?
I have a device configured to report voltage readings every 2 minutes. The need is to detect when that device dies or goes offline and to identify as soon as possible when it comes back alive. The condition shown is designed to detect when the device goes back online. It would work with another rule that detects an absence of the voltage event after a period of 4:20.
I am resorting to this method because the "Last Updated" attribute does not always change when it should. I'm willing to believe this behavior may be connected to the device itself, although I have two such devices and they both work the same.
A simpler way to achieve this goal would be to leverage rule re-triggering. Have a rule trigger on any voltage event. Have its action be a wait for elapsed time : something more than two minutes. A new voltage event will re-trigger the rule, cancel the existing wait and set up a new one. If instead the next action is executed, you'll have detected the fault. Suggestion: turn on a virtual switch to indicate the fault state.
Another rule could have a required expression on that virtual switch when on (indicating a fault) and trigger on a voltage event, then immediately switch the virtual switch back to off when triggered.
This is a test rule made to demonstrate the issue. I triggered this test rule manually with the Run Actions button.
Good point about the unchanging voltage. I'm fairly sure I've seen this aberrant behavior even after the voltage reported has changed from the previous voltage. If "Any Value" really means only change in value, then the parameter should be called "changed" as it does for comparisons in Custom Attributes.
I've also tried changing the parameter from Any Value to >100 volts and it does the same thing. If >100 means "only if the previous value was not greater than 100" (which would indeed be strange), then consecutive reports of 122, 121, 117, etc. volts would not satisfy the condition either.
I will run some more tests to see if I can catch it acting up after a change in the reported voltage. I can also try varying the voltage around +/- 115 volts to see if what that does with a 115 volt threshold.
I myself have some rules that use Time Since Event successfully, so I would think the answer is: generally, yes.
What driver are you using for the device that is generating the voltage events? Some custom drivers filter events that are not changes (they shouldn't - the hub already takes care of this). One way to verify this is to go to the device details page and look up the events tab. Do you see all of the events that you are seeing in the logs? This is the list that Rule Machine looks up for Time Since Event.
How do you do this? The only option I see is to trigger if the voltage changes. The device does not report fractional volts so it isn't unusual to see consecutive readings of the same voltage with no change.
One reason I chose the Time Since Event method is because it offers the "any value" parameter rather than only a "changed" parameter. Does anyone know if "any value" really means only if the value has changed since the last report?
I've also tried If Value is > 100 but that does not seem to help.
I see. In that case my suggestion might not work for you.
AFAIK it looks up the event list for the last event of any value on the specified attribute, regardless of if its a change. You can also select « any attribute » which implies any value.
I agree, that is the implication, it's how I want it to work. Only in my case it is isn't working reliably.
What does work is to actually open or close the switch and then test to see if it responded to the command. However, I don't want to exercise the mechanical switch continuously just for that. I tried issuing a Refresh command in hope it would cause the device to respond with it's attributes, but unfortunately it does not.
The reason for the ask is fairly simple. There are a thousand different ways to do things in Hubitat with most folks using the KISS principle when designing rules. The test that was created is similar, but still very different, to what your actual goals are. For instance, we still do not know how you plan to trigger this rule before the conditions even become a factor. Full knowledge of your goals allows the community to be at its best and come up with ideas/solutions that might be simpler in nature.
With the above said, @hubitrep has a good idea. The one change I would recommend is you could use "in between" as your trigger rather than changed. Just set the in between to go from 0 to a very large number. Here is a tiny example using Lux that could possibly work for your needs:
I want to thank everyone for your interest in this issue:
The screens and log entries below demonstrate the following (to me, at least):
1- That the "Voltage Reports within a range" conditional only goes TRUE if the voltage reported has changed since the last report. (and presumably is also within range) If the voltage hasn't changed, it isn't considered an "event".
---The log shows multiple, consecutive reports of 123V which do not trigger the rule. As soon as the voltage changes from 123 to 124, the rule triggers. When it goes back from 124 to 123 the rule triggers again.
2- That the same appears true for the "Time Since Event voltage (Any Value)" conditional.
3- That the "Any Value" argument should be renamed "Changes". IMHO
4-That I still don't know a good method to detect that an unchanging value has been reported by a device and, by extension, to passively detect that a device such as this is still alive and receiving power.
--I welcome ideas to reliably test the "dead or alive" condition of this device (or a similar device) that don't involve "tickling" the device. e.g. sending commands to the device to see if it responds.
Please look over the following data and let me know what you think.
The Log Entries:
dev:4502025-02-26 05:59:23.559 PMinfoPower_Mon B voltage is: 123V
dev:4502025-02-26 05:58:22.316 PMinfoPower_Mon B power is: 0W
dev:4502025-02-26 05:57:21.217 PMinfoPower_Mon B voltage is: 123V
dev:4502025-02-26 05:57:21.061 PMinfoPower_Mon B energy is: 0kWh
dev:4502025-02-26 05:56:19.817 PMinfoPower_Mon B power is: 0W
app:7152025-02-26 05:55:26.082 PMinfoAction: END-IF
app:7152025-02-26 05:55:26.064 PMinfoDelay Over: Delay 0:00:05
app:7152025-02-26 05:55:21.039 PMinfoAction: Delay 0:00:05
dev:3892025-02-26 05:55:21.033 PMinfoVS_Tst_Rst was turned off
app:7152025-02-26 05:55:21.027 PMinfoAction: Off: VS_Tst_Rst
app:7152025-02-26 05:55:21.025 PMinfoAction: IF (NOT Time Since Event: voltage(Any Value ) on Power_Mon B(0:00:02) exceeds 0:03:20(T) [TRUE]) THEN
app:7152025-02-26 05:55:20.907 PMinfoDelay Over: Delay 0:00:02
app:7152025-02-26 05:55:18.881 PMinfoAction: Delay 0:00:02
dev:4552025-02-26 05:55:18.877 PMinfoTST Counter variable is 7
app:7152025-02-26 05:55:18.867 PMinfoAction: Add 1 to TST Counter
dev:3892025-02-26 05:55:18.848 PMinfoVS_Tst_Rst was turned on
app:7152025-02-26 05:55:18.843 PMinfoAction: On: VS_Tst_Rst
app:7152025-02-26 05:55:18.835 PMinfoTriggered: Power_Mon B reported voltage(123) in range 100.0 to 125.0
app:7152025-02-26 05:55:18.822 PMinfoEvent: Power_Mon B voltage 123
dev:4502025-02-26 05:55:18.719 PMinfoPower_Mon B voltage is: 123V
dev:4502025-02-26 05:55:18.563 PMinfoPower_Mon B amperage is: 0A
dev:4502025-02-26 05:55:03.263 PMinfoPower_Mon B power is: 0W
dev:4502025-02-26 05:54:17.471 PMinfoPower_Mon B power is: 4W
dev:4502025-02-26 05:54:17.316 PMinfoPower_Mon B energy is: 0kWh
app:7152025-02-26 05:53:23.292 PMinfoAction: END-IF
app:7152025-02-26 05:53:23.274 PMinfoDelay Over: Delay 0:00:05
app:7152025-02-26 05:53:18.243 PMinfoAction: Delay 0:00:05
dev:3892025-02-26 05:53:18.236 PMinfoVS_Tst_Rst was turned off
app:7152025-02-26 05:53:18.231 PMinfoAction: Off: VS_Tst_Rst
app:7152025-02-26 05:53:18.229 PMinfoAction: IF (NOT Time Since Event: voltage(Any Value ) on Power_Mon B(0:00:02) exceeds 0:03:20(T) [TRUE]) THEN
app:7152025-02-26 05:53:18.181 PMinfoDelay Over: Delay 0:00:02
app:7152025-02-26 05:53:16.152 PMinfoAction: Delay 0:00:02
dev:4552025-02-26 05:53:16.148 PMinfoTST Counter variable is 6
app:7152025-02-26 05:53:16.139 PMinfoAction: Add 1 to TST Counter
dev:3892025-02-26 05:53:16.120 PMinfoVS_Tst_Rst was turned on
app:7152025-02-26 05:53:16.114 PMinfoAction: On: VS_Tst_Rst
app:7152025-02-26 05:53:16.106 PMinfoTriggered: Power_Mon B reported voltage(124) in range 100.0 to 125.0
app:7152025-02-26 05:53:16.093 PMinfoEvent: Power_Mon B voltage 124
dev:4502025-02-26 05:53:16.064 PMinfoPower_Mon B voltage is: 124V
dev:4502025-02-26 05:52:14.819 PMinfoPower_Mon B power is: 4W
dev:4502025-02-26 05:51:13.720 PMinfoPower_Mon B voltage is: 123V
dev:4502025-02-26 05:51:13.565 PMinfoPower_Mon B energy is: 0kWh
dev:4502025-02-26 05:50:12.319 PMinfoPower_Mon B power is: 5W
dev:4502025-02-26 05:49:11.067 PMinfoPower_Mon B voltage is: 123V
dev:4502025-02-26 05:48:10.102 PMinfoPower_Mon B power is: 5W
dev:4502025-02-26 05:48:09.818 PMinfoPower_Mon B energy is: 0kWh
dev:4502025-02-26 05:47:08.567 PMinfoPower_Mon B voltage is: 123V
dev:4502025-02-26 05:46:07.314 PMinfoPower_Mon B power is: 5W
dev:4502025-02-26 05:45:06.376 PMinfoPower_Mon B voltage is: 123V
