BlueOnyx 5210R/5211R Debugging

BlueOnyx 5210R and 5211R provide different and better forms of tracking problems and errors in the GUI. This guide explains how to use the new mechanism.

CodeIgniter 4 debugging via CI4 Env:

On your BlueOnyx 5210R or 5211R open up the file /usr/sausalito/ui/chorizo/ci4/.env in an editor (as "root").

Normally it looks like this at the top:

#--------------------------------------------------------------------
# ENVIRONMENT
#--------------------------------------------------------------------

#CI_ENVIRONMENT = development
CI_ENVIRONMENT = production
#--------------------------------------------------------------------

Change it to this:

#--------------------------------------------------------------------
# ENVIRONMENT
#--------------------------------------------------------------------

CI_ENVIRONMENT = development
#CI_ENVIRONMENT = production
#--------------------------------------------------------------------

That switches the BlueOnyx 5211R GUI from "production" to "development" mode. When you now use the GUI the first visible change will be the CodeIgniter Icon in a foldout in the lower right corner. You can click on it to extend it to show run time information of the GUI. See below for some examples.

CodeIgniter Debug toolbar icon on the right-hand side. Click on it to extend it:

CodeIgniter Debug toolbar extended:

CodeIgniter Debug toolbar extended and expanded:

CodeIgniter Error Message display in case a GUI page throws an error:

As you can see: Now all errors will show a very detailed GUI page with the exact module, code line and error message, with the code in question displayed, variable status and what not. VERY useful and neat.

But please note: There are 3-4 GUI pages will not display right if development mode is enabled. Such as the integrated Webalizer statistics, where the status bar code is automatically injected into the display of the GUI page in a disruptive way. But most work just fine with development mode enabled.

Just don't use 'development' mode in production as it could reveal environment variables to users that you might not want them to see.

/var/log/gui-debug.log & /etc/DEBUG

The new logfile /var/log/gui-debug.log logs accesses to the GUI interface. So you can see which logged in user went where. Nice to have, but not essential. It's more or less useless for debugging.

Now run this command: "touch /etc/DEBUG" (this creates the empty file /etc/DEBUG) and then run a "tail -f /var/log/gui-debug.log" while you do something in the GUI.

It can't get more detailed that that - right down to the exact CCEd transactions that each GUI page performed. With all data being shown.

Be sure to run "rm /etc/DEBUG" once you're done, though. Otherwise that logfile will quickly grow and consume much space. The daily logrotate will rotate the logfile, though.