Room Lighting App ghost logs, phantom event triggers,

[dvdptr1]

I've been playing with the Room Lighting app for a few weeks now, and I really do like the concept behind it, but (and there's always a but), I'm noticing quite a few quirks and bugs with it, and I'm finding it very difficult to do a full migration.

As mentioned, I noticed that when I delete an automation, the corresponding log files don't disappear, and as I've been experimenting, my log files are now littered with logs for automations that no longer exist.

The other thing I noticed is that I would see event triggers for an automation run that was supposed to be limited by the current mode. I had 2 automations (long story) for the outside lights. I have one for evening mode that sets up specific colors on my outside lights, and then I have one for night mode that turns on all the outside lights to white if motion is detected, or a door is opened. At one point I had tried to include evening for the night mode to override the colors with white upon motion/contact trigger, but Room lighting seemed to have issues with the restoration, so I removed the evening mode from the night rule, but then saw my outside lights still turn off in the evening. Like, the mode change didn't actually clear.

I also noticed that adding a transition option didn't seem to work on mode changes coming OUT of an automation. I tried to set a transation for my inside lights to turn off when mode changes to night, but the lights never dimmed over the 15 minutes, and then just turned off.

I've also notice some unexpected UI/web behavior when Working with periods. For example, if you have multiple mode periods set up. and you remove a mode, save the automation, and go back in and add the mode back in, it seems to remember the previous setting for that mode. I would have thought it would have either picked a mode to mirror, or had a more-or-less blank mode to edit, but it seemed to remember the way the mode was previously set up. Maybe that's what's also causing some of the phantom events.. the old info is still around, but isn't displayed in the UI (?)..

For motion-based triggers, room lighting seems to be pretty solid. A bit of a learning curve when building in dependencies on other devices, but I'm good ok with a learning curve.

I've seen other requests around "nesting RL groups and scenes in RL automations", and I would agree with that "wish list" item.

Bottom line here is that I've started moving some of my mode-based RL apps back to Rule Machine (which is when I noticed the litter of obsolete log files left around). I'll keep trying to use it first, because, as I said, I like the idea, and I think it might be easier for beginner users rather than Rule Machine. But, it feels like it's still a little buggy.

[bravenel]

@dvdptr1

the litter of obsolete log files left around)

Have you cleared the logs? Are you saying that you removed an app instance, and that it created logs after it was removed? Or simply that you removed it, and old logs it had created were still there?

@dvdptr1

if you have multiple mode periods set up. and you remove a mode, save the automation, and go back in and add the mode back in, it seems to remember the previous setting for that mode.

This is expected behavior, as it doesn't clear out many of those settings. However, if you hit Update after removing a mode, some are removed. The app is possibly not going to function correctly after you make changes until you hit either Update or Done.

@dvdptr1

Maybe that's what's also causing some of the phantom events.. the old info is still around, but isn't displayed in the UI (?)..

I'd have to see Logs proof of this, as I don't think this is actually happening.

[dvdptr1]

re: log files, it's the latter. I remove a Room Lighting instance, and the log file persists (the example was the two images... There is log file for an instance called "Automation: Outside Lights by Mode (Active)", but, in the RL instance list, there is no automation with that name any more *let alone being active". I also just noticed that the "(Active)" tag isn't always consistent across different parts of the system. See attached where the logs page says "Active", but the dashboard with the actuator and the RL app list both do not have that tag.

For the phantom activations, let me see what I can dig out from the logs. Unfortunately, the instances no longer exist in the same form as I try to fix things, or delete and recreate things, so I don't know if I can gather both the original rule and the matching log file to provide the documentation. It is very possible that I've lost track of what I was doing at the time. Let me root around on a proper PC (vs this tablet) and see what I can ferret out from the logs.

[dvdptr1]

Ok. Here's the log entry that makes me think it was ignoring the mode. Unfortunately, the instance that generated that log no longer exists because I dumped it after getting frustrated with it turning off my outside lights all the time.

It seems to say the activation was blocked by evening mode (8:14:02). At 8:15:31, you can see it starts a turn off event even though the activate event was blocked by the mode being evening. And this entire rule had had the period mode defined as "Night".

So, are deactivations independent of activations within a particular RL instance? In other words, can a deactivations will still happen even if the activation was blocked? Perhaps I erroneously assumed that a deactivation would only happen after an activation happened, and if the activation was blocked by a condition, the deactivation would not be an independently triggered event.

[bravenel]

@dvdptr1

So, are deactivations independent of activations within a particular RL instance? In other words, can a deactivations will still happen even if the activation was blocked?

That depends on how it is setup. In general, as a default, it won't Turn Off if not Activated and it won't Activate if already Activated. This can be confusing, especially when there are other things touching the lights involved.

[dvdptr1]

So, I guess let's go back to the first question... when are log files (apps, rules, devices whatever) supposed to get removed/created in Hubitat? I seem to have an Automation that doesn't generate a log file, and I have log files that don't seem to have an Automation any more...

Automation List:

Log list:

And for easy comparison, I put it in a table:

Are my colons in my names causing an issue?

[bravenel]

@dvdptr1

when are log files (apps, rules, devices whatever) supposed to get removed/created in Hubitat?

If you mean when are Past Logs removed, they aren't. They eventually fill up and expire. If this really bothers you, you can do a Soft Reset with the Diagnostic Tool and remove all logs. But generally, there is no reason to worry about this. And, generally, just use the Live Logs to see what is currently going on with your apps and devices.

@dvdptr1

I seem to have an Automation that doesn't generate a log file, and I have log files that don't seem to have an Automation any more...

Perhaps Logging is not turned on in the automation. For many the default is not to log anything. There aren't 'log files' per se, an app doesn't have a log file. If you remove an app, it obviously won't log anything after that. But, it's past logs persist for some time (a good thing if you need to look back in time, but not for very far back, depending on how large your system is and how much logging it generates).