Troubleshooting and logs

[another tom]

I have been trying to track down a rouge event that is turning off a device.  In doing so, I have ended up becoming frustrated with the current "log" capabilities.  They faithfully show the device being turned on this evening at 4:39, and then turned off at 4:55.  What I can't tell is WHY it was turned off.  Was it an event that fired in the eisy? or a scene activation?  or a local switch pressed?

 

 

I may not be able to track local switch actions - but it would be nice if the log was a bit more structured and could provide some more cause-effect data for things happening within the eisy.  Maybe something like:

This would tell me:  Program "IsNightTime" triggered, and it was what turned on the FrontGang light (notice column 5 doesnt say "system").  Then the Off command actually came from a "HolidayProg" trigger than happened to have run earlier in the day and had a WAIT of 3 hours instead of 3 minutes. (Hint: I found the cause of this problem....)

The last line still saying "System" would be the result of my directly toggling the status of the Device via the admin console.

In summary - can the logging be improved to provide more information regarding the chain-of-events rather than just the actions?

 

[paulbates]

This is not exactly what you're asking, but there are other ways to debug

• Put notifications in key spots in programs to alert you and then remove them once the program is working. I've recently completed several programs and notifications got me around my "bugs"
   
• As an alternative to notifications, set a variable, If your program is setting variables this is a good method and also recently used this method. To see these changes, open the event viewer (as opposed to the log) and look for entries something like VAR[ 2 7]... where 2 = state variable, and 7= variable number on the list of variables.
   

 

Edited December 14, 2023 by paulbates

[DennisC]

13 hours ago, another tom said:

I have been trying to track down a rouge event that is turning off a device.  In doing so, I have ended up becoming frustrated with the current "log" capabilities.  They faithfully show the device being turned on this evening at 4:39, and then turned off at 4:55.  What I can't tell is WHY it was turned off.  Was it an event that fired in the eisy? or a scene activation?  or a local switch pressed?

 

 

I may not be able to track local switch actions - but it would be nice if the log was a bit more structured and could provide some more cause-effect data for things happening within the eisy.  Maybe something like:

This would tell me:  Program "IsNightTime" triggered, and it was what turned on the FrontGang light (notice column 5 doesnt say "system").  Then the Off command actually came from a "HolidayProg" trigger than happened to have run earlier in the day and had a WAIT of 3 hours instead of 3 minutes. (Hint: I found the cause of this problem....)

The last line still saying "System" would be the result of my directly toggling the status of the Device via the admin console.

In summary - can the logging be improved to provide more information regarding the chain-of-events rather than just the actions?

 

Another approach would be to use the find and replace search capabilities and search for programs and seems that have that device in it. Check wiki for details.

You can also right click on the program that turns device on and select status. That will take you to the detail page and look at the last time the program ran. If not at the time of turning off, then check for what might have run at that time.

[another tom]

Thank you both for your ideas.   With the exception of @DennisC's idea about setting vars in the code (brilliant!), I was aware of all these other approaches.  The intent of my post was to request changes to logging to make all these "search and locate" steps obsolete.   It would be a welcome enhancement if the logs could be used to corollate the initial event with the actions taken, rather than just list the events.

[DennisC]

I think you meant @paulbates