Jump to content

Troubleshooting and logs


another tom
Go to solution Solved by paulbates,

Recommended Posts

Posted

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?

 

image.thumb.png.b259bdec7f69ab11e6ec965c21322711.png

 

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:

image.png.f7d8de9e8900dc9b80a3e37264f2481e.png

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?

 

  • Solution
Posted (edited)

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 by paulbates
Posted
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?

 

image.thumb.png.b259bdec7f69ab11e6ec965c21322711.png

 

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:

image.png.f7d8de9e8900dc9b80a3e37264f2481e.png

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.

Posted

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.

Guest
This topic is now closed to further replies.

×
×
  • Create New...