There is more log history now, as per feedback. Maybe I'll dial it back down a bit since it causes issues.
2 Likes
I'm noticing that Debugging disable is not being honored.
ALL logging is disabled debugging messaging.
I have thousands of messages.. In removed on the c7.. not really using it. I'm testing..
Is it a built-in Hubitat device driver? If so, which one?
1 Like
No it is not.
FYI: This has come in VERY handy--as I've been able to track several things down that were lost to history before. I guess it's a balancing act. 
2 Likes
The slowness is still there.
This isn't a DB issue. this is a process issue with the log service.
Yeah, it's the browser rendering a very long list of events in the log.
2 Likes
I am typically a Chrome user, but I found that using Firefox for Logs seems to perform much better. I'm using that as a temporary workaround; perhaps useful to you guys too.
1 Like
Thanks. I will try it I'm using Chrome and Chrome Edge.
I used FF on my phone VERY MUCH quicker.
@gopher.ny If that's the case, might you consider a way to show the first "xx" number of log entries in the browser, with some way to optionally render more of them ("next page") or something?
It truly is very useful to have the log data available!
Thanks!
2 Likes
Copying this here to make sure it gets seen:
1 Like
Noted.
1 Like
Hi @bravenel
Just been doing some playing using 'Predicate Conditions' in RM5.0.
If I use a repeat as in the rule below, when the Predicate condition is true it runs as expected.
When the predicate condition becomes false it does not stop the rule from repeating. Is this expected or should it stop the repeating schedule.
Ignore the triggers as I've just cloned this and I use the run actions button to trigger the rule.
Here is the rule.
Here is a screenshot showing the repeat still being scheduled.
Just some quick observations about your example, @bravenel will likely have his own input as my understanding may be flawed.
The predicate condition changing just prevents the rule triggers from firing, it won't change the state of an already active rule. The way your rule is written the mode changing away from "evening" would cause the predicate to become false preventing the trigger "mode change" from actually causing the rule to fire.
That being said, there is a known issue with repeats under RM 5 that is preventing a repeat from being stopped by any other means than opening the rule and pressing update rule or done, there is an upcoming hotfix for this.
2 Likes
Thanks for the response.
I fully understand this but I was just thinking that as the rule can no longer fire because of the Predicate condition, I would have thought that all waits, repeats etc. be cleared out of the schedule.
Not that much of an issue as I have rules that work OK without using the predicate condition but was just wondering while I was playing with the new option.
Ah OK. I must admit I missed that.
Like I say, no big deal but thought I would ask.
Something new, I have to use it. 
1 Like
That was also what I originally thought when I read about the new option, but when I finally wrapped my head around it I came to understand that a predicate condition is all about allowing/preventing a rules triggers from firing and not about the actions of the rule I realized I was incorrect.
I find predicate most useful in preventing a rule that is triggered by something like a temperature/illuminance/power meter level from triggering more than once after the first time it runs.
Something like this:
2 Likes
Predicate Conditions stop a rule from being triggered, not from running once already running.
Thank you. It hadn't really occured to me that the predicate is a great way to get rid of some crazy private boolean stuff I have in older rules.
4 Likes
