This is just a report.
There are few completely separate RM rules which should be triggered at 6:30am.
Today all of them did not trigger which means hub missed an time-based event at 6:30am.
The reason for this report - the same thing already happened 3 times over past couple months.
To my engineering eyes if something happens only once it could be a simple glitch, it happens.
However if the same problem is repetitive even randomly it is something to pay attention for.
1 Like
Did you have all logging enabled for these rules at the time of failure? Without this, it's impossible to say if the rule truly did not trigger or if there was only some problem with the actions. (I'm not saying that it isn't a problem for you or that the outcome wouldn't be the same either way, just that there are different causes and different things to be investigated depending on each.)
1 Like
Of course logging was not enabled. These few rules are very simple and straight forward (basically turning on something). The commonality is - they must be triggered at 6:30am. Since neither one was triggered I am near 100% sure this time-based event simply did not happen or was entirely missed (I have no idea how the same Triggers are processed, i.e. if few rules have exactly the same Trigger Event is it a single Trigger instance (most likely "yes") or multiple) I reported this issue only because I already seen this failure (not exactly the same set of rules but few rules with the same time-based trigger) few times in a past 2-3 month (never seen this before in a past 4+ years). And again, form my past experience: Even random problems which happened more than once should/better be investigated.
Again, without logging enabled, this cannot be said--you only know that there was apparently some problem. With logging enabled, you'd be able to have looked at the logs at this time and see if there was an entry from this rule (app) at this time, since trigger logging would have noted when the rule was triggered.
Without that, the best you can do is look at the App Status page for this rule and see if there is a scheduled job at the expected time (if not, that is certainly a problem and would suggest it probably didn't trigger last time). Beyond that, as you know by now, there is little that can be done without more information, including logs and the actual rule.
2 Likes
I am very confused. Assuming all logging is enabled but Trigger simply did not happen. What do you expect to see in a logs in this case? My good guess - absolutely nothing will be logged in. Or your expectation is to see only a Trigger Event logged without any following Actions? I am sure in this case it will be indication for the huge disaster.
My point is - it is impossible for multiple rules to fail exactly the same way except for the entirely missing Trigger Event which is the only commonality between all these rules.
Nothing, as you expect. But that is still useful information, because there exists the alternative where you would see the expected log entry, indicating that the rule did, in fact, trigger (and that the problem lies elsewhere, perhaps with the actions or devices). Again, without logging, there is no way to determine what or where the problem is.
It is impossible to say anything without logging enabled to show you what did or did not happen when -- either is valuable information.
2 Likes
Why not turn on full logs on all rules you suspect might be exposed to this problem? What's the downside?
You can leave a browser tab open (and active) on the live logs and collect over days
If that's an option for you, a simple shell or python script running on a computer on your LAN can grab everything coming from the log socket (and events socket - you'll see all events, even those that aren't logged anywhere) and save it to disk.
2 Likes
O...o, logs are capable to show what did not happen?
How do I turn this on?
My original post was for Information Only and was not intended for any discussion. At this point the discussion will not produce any reasonable outcome.
BTW, there is a protentional commonality between this reported failure and "Wait for Expression" failure. And the commonality is - Event Generation Engine. It looks like in both cases a "Missing Event" is a source for the problem.
But PLEASE, do not start and/or continue any discussion, it will not be productive.
I am simply thinking loudly trying to put together all little pieces of the puzzle.
It seems you are joking, but I am not. If you have logging enabled and there are no logs when there should be, then yes: it shows you what did not happen (assuming your logs go back that far). Specifically, if a rule with trigger logging enabled has no logs when it's supposed to trigger, only then can you say it didn't trigger.
Again, without this information (or perhaps the App Status in its absence), no one can say anything about your particular case.
2 Likes
In short, yes, logs are very useful tool but not always necessary and required.
Yes, I was joking.
OK, your point is if all logs are enabled and in this specific case multiple rules should log an activity at 6:30am but nothing was recorded is really a useful piece of info.?
In opposite my point is - even without any logs it is a clear indication that time event at 6:30am did not happened because multiple rules relied on this event did not fire. This is possible only if Event did not happened. Is not it? So, why logs are still required? For me this existing info is already enough to think about what could be wrong. These types of failures are very random and really hard to debug but unfortunately they do exist. And to the @hubitrep point I don't want to turn on all logs for every rule (to...o many rules) but I have no idea which one and when will fail next time.
Closing per the OP's request for no discussion.
To troubleshoot a rule or any other app and how to gather logs and any other information necessary if you wish to troubleshoot a similar problem, see: How to Troubleshoot Apps or Devices | Hubitat Documentation
