Error Logging on ConnectPort X

Question

I'm using an X2 as a zigbee -> ethernet gateway. I've written all the python scripts and everything is working fine.

Now I'm wondering what the best practices are for error handling/logging on these devices? I have the main program loop in a try/except block and on error the program:

1. Prints out error details
2. Sleeps X seconds
3. Attempts a reconnect

When developing the print statements are useful, but only when you are logged into the console.

Is there any logging facilities that help with troubleshooting devices in the field?

Suggestions are welcome...

Answer 1

I suppose you could write a circular buffer into flash, but you risk shortening the life of your product.

For ad-hoc use, you can have people telnet into the X2 and do the "set trace state=on mask=printf:*" to see your print statements in realtime as they occur.

If you want something formal with a better history which you control, the you could write a simple thread-based buffer which waits for a telnet-like connection, then dumps perhaps the last 50 "messages" upon connection, then shows new messages in realtime as they are passed to this thread. This would give you some ability to have some print-like messages real-time only & not buffered, while others might buffer.

Since you are using the X2, you'd need to be careful with memory usage, plus manually force garbage collection at the appropriate times since the 'print' strings will need to be detected as freeable periodically.

Answer 2

> Since you are using the X2, you'd need to be careful
> with memory usage, plus manually force garbage
> collection at the appropriate times since the 'print'
> strings will need to be detected as freeable
> periodically.

The garbage collection idea is possibly good for other reasons. However, the strings will not need manual garbage collection. They'll either be completely persistent because they are not template copies, or if they are will lose all references and be cleaned up immediately right after the print completes.

Using the 'set trace' command is good as mentioned for ad-hoc usage. For more visibility, I recommend offloading the log if possible. I would check out the 'logging' module from the standard library in conjunction possibly with one of its handlers to get the message off the system to syslog or an NT event log for example. You can log to the file system this way as well, you'll just want to consider the impact on the flash. At a fairly low message frequency, erase-write cycles are probably not a large problem.

Answer 3

I know this is very late, but if you use use the standard logging function without a file defined, is there still a memory impact without the file that eats away available RAM?