Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

When developing an exhibit there are 3 different types of logs in 2 locations available for use. Each are controlled independently so it is up to the exhibit developer to decide which is appropriate, though we layout some opinions at the bottom of this discussion. Each logger can use the same severity levels but they end up in different places.

  1. Your logs

  2. gumbandLocalLogger

  3. gumbandCloudLogger

Your Console Log Statements

This one is the easiest. When you are writing your own code and you use console statements you can see those in the node process that is running your exhibit. In the example of The Digital Signage and Game Tutorial I have thrown in some logging statements before and after the socket handlers so I know that all of these were mounted in the addSDKListeners.

// gumband-sdk-tutorial/gumband/gumband-service.js
class GumbandService {
    ... instance variables, constructor
  
    /**
     * Add listeners to the Gumband SDK to handle messages from the Gumband Cloud.
     */
    addSDKListeners() {
        console.log('Adding SDK listeners...')
        // 👆  I added this to my exhibit code to know the function is running.
        
        this.gumbandSDK.on(Sockets.OP_MODE_RECEIVED, (payload) => {
            //Body Ommitted
        })
        this.gumbandSDK.on(Sockets.READY, async (manifest) => {
            //Body Ommitted
        })
        this.gumbandSDK.on(Sockets.SETTING_RECEIVED, (payload) => {
            //Body Ommitted
        })
        this.gumbandSDK.on(Sockets.FILE_UPLOADED, async (manifest) => {
            //Body Ommitted
        })
        //listen for the CONTROL_RECEIVED event
        this.gumbandSDK.on(Sockets.CONTROL_RECEIVED, async (payload) => {
*            //Body Ommitted
        });
        
        // 👇 I added this to make sure all of the `.on` methods completed.
        console.log('SDK listeners added.')
    }
}

You can see those logs as I start up the exhibit.

Gumband Local Logger

When you install the Gumband SDK there is a component of that package called localLogger. This package is what the Gumband team uses to log information to you (the exhibit developer) regarding the operation of your exhibit. As an exhibit developer you will NOT make calls to the local logger, but you can control how noisy it’s output is depending on your personal preference.

const { Gumband } = require("@deeplocal/gumband-node-sdk");
this.gumbandSDK = new Gumband(
    process.env.EXHIBIT_TOKEN,
    process.env.EXHIBIT_ID,
    `./manifest.json`,
    {
      // Additional Configuration Options
      localLoggingLevel: 'debug' 
    }
);

The acceptable values for localLoggingLevel:

  • debug - the ‘noisiest’ of the logs, it includes all levels of severity listed below in addition to console.debug statements. You probably don’t need this log level unless you’re curious as to how the SDK works “under the hood”.

  • info - the second noisiest of the logs, includes all levels of severity below in addition to console.info statements. You may find this useful, even though it increases the volume of logs in your terminal.

  • warn - this log level includes the severity below in addition to console.warn statements. It is helpful because this is where we will post notices of future deprecation, tips/tricks or potential “gotchya moments” to keep you aware. This is the default log level if you don’t set anything in the new Gumband() constructor options object.

  • error - this level is reserved for the most alarming use cases. We try to use it as little as possible, but when it arrives you should probably double check your code/connections etc to ensure the exhibit is functioning as intended as it’s likely that something is awry.

Gumband Cloud Logs

These log messages can be triggered by the exhibit developer during runtime and, assuming a healthy internet connection, those logs will appear in the Logging Tab of the Gumband Cloud UI.

You can trigger these logs by calling commands like:

this.gumbandSDK.logger.debug('This is a debug log');
this.gumbandSDK.logger.info('This is an info log');
this.gumbandSDK.logger.warn('This is a warn log');
this.gumbandSDK.logger.error('This is an error log');

You may have seen this if you followed the Digital Signage and Game Tutorial

  • No labels