Tag Archive: getting started

The Outputs on the JNIOR can be controlled via the JnrWebsocket protocol.  These commands are sent using the Control Message.

Each “Control” message must contain a “Command” member which may be one of the following valid values:

  • “Toggle”
  • “Close”
  • “Open”
  • “Reset Latch”
  • “Reset Counter”
  • “Reset Usage”

Each “Control” Message must contain a numeric “Channel” member specifying the input/output channel. This parameter is 1-based where the number ‘1’ specifies either the first Digital Input or first Relay Output. This depends on the specific “Command”.

There is no formal response to these command messages although a “Monitor” message will invariably follow some for obvious reasons.

Toggle Command

Close Command

Open Command

The built-in functions are great, but sometimes you want to have custom logic running on the JNIOR.  This is a huge benefit of the JNIOR and being able to communicate directly with those applications from a web interface is uniquely powerful.  To take advantage of this feature we must have a unique ID assigned to the application we wish to communicate with.  The web application must make the first communication attempt to that application ID using the Post Message command.  Once that command has been sent, JANOS will subscribe this connection to receive further Reply Message messages from the Java application.  Application IDs must be greater than 1024 and must be unique.

Post Message

We use Post Message to send data from the Web Application to the Java Application.  JANOS will place the Content of the message on the internal Message Pump.  Each Java Application running on the JNIOR will examine the application ID associated with the message.  If the application owns the ID then the application will process the message.

    var message = { Message: 'status.get' };
    jnrwbsocket.postMessage(2010, message);

The above is an example of getting the status from the application when the web application first launches.  Again, this message will cause JANOS to subscribe the WebSocket connection to receive future Reply Messages from this application ID.

Note: You will receive all Reply Message messages from this application.  Even if it is a reply to another WebSocket connections message.  care must be given if you don’t want this to happen.

{{ctrl.getFunctions()}}

Functions

Here is an overview of the available Registry Functions:

  • readRegistryKey (keyName, callback) – Executes the callback when the given registry key’s value is retrieved from the JNIOR
  • value = readRegistryKeyAsync (keyName) – Gets the value of a registry key.  Since this function is a async function, it will wait for the result before returning.
  • readRegistryKeys ([keyArray], callback) – Executes the callback when the given registry key’s values are retrieved from the JNIOR
  • registrySubscription (key, callback) – Executes the callback when the given registry key’s value is retrieved from the JNIOR. The callback is also executed any time there is an update to that registry key value

Read Registry Key

Reading a Registry Key is an asynchronous operation.  We don’t want our page to wait for the response, even though it will be quick.  So again, we need to supply a callback.  Our method syntax is readRegistry(keyName, callback);

This may cause you to structure your application differently if you are waiting for one key’s value before executing another code.

Syntax

// With Callback Function
readRegistryKey (keyName, callbackFn)

// With Inline Callback 
readRegistryKey (keyName, function(keyName, value){ /* ... */ })

Parameters

keyNamestring – The name of the registry key that we want the value of

callbackFnfunction – The function to execute when the value is returned. This can be a reference to a function or an inline anonymous function.

        keyNamestring – The name of the registry key being returned

        valuestring – The value of the registry key being returned

Return Value

None

Example

    jnrWebsocket.readRegistry( '$SerialNumber', function (keyName, value) {
        this.serialNumber = value;
        alert('The Serial Number is: ' + this.serialNumber);
    });

Read Registry Key Async

It would be easier if we could wait for the response without supplying a callback.  Well, now we can for a single key request.  We will call the readRegistryKeyAsync() method.  But it does involve a little more care.  The use of async / await will help us do that.  The await operator must be used in a async method.  It cannot be used in a normal method.  Here is how we would do that.

Syntax

value = readRegistryKeyAsync (keyName)

Parameters

keyNamestring – The name of the registry key that we want the value of

Return Value

valuestring – The value of the registry key being returned.  Applies to the Async version only.

Example

        var getJniorInfo = async function () {
            console.log('serial: ' + await jnrwebsocket.readRegistryKeyAsync('$serialnumber'));
            console.log('model: ' + await jnrwebsocket.readRegistryKeyAsync('$model'));
            console.log('boot time: ' + await jnrwebsocket.readRegistryKeyAsync('$boottime'));
        };

        jnrwebsocket.addOnLoggedInListener(getJniorInfo);

Read Registry Keys

More than likely you will need to read more than one key.  Currently, we have the following code where an array of registry keys is supplied.  The callback is then executed for each key and value returned. 

    var registryKeys = ['$serialnumber', '$model', '$boottime'];
    jnrwebsocket.readRegistryKeys(registryKeys, function (key, value) {
        if ('$serialnumber' == key) SerialNumber = value;
        else if ('$model' == key) Model = value;
        else if ('$boottime' == key) BootTime = value;
    });

In this case, the callback gives you the value but you have work to do to assign or use it correctly.  The real benefit comes in when thought is given to the jnior and the amount of communication that goes on.  It is better to send one request and get one response.  The savings go up with the number of keys requested.

Can this be handled better on the client side?  I’m sure it can.  But how?

What if the callback returned an object of key : value pairs?

    var registryKeys = ['$serialnumber', '$model', '$boottime'];
    jnrwebsocket.readRegistryKeys(registryKeys, function (keys) {
        SerialNumber = keys['$serialnumber'];
        Model = keys['$model'];
        BootTime = keys['$boottime'];
    });

Registry Subscription

Hey, a registry key may change sometime in the future.  I want to know when that happens.  Do I have to keep asking to find out if this happens?

No, you don’t.  You need to only subscribe to the registry key.  Let JANOS and the JNIOR do the rest.  JANOS will keep track of the connection that cares about the registry update and alert it accordingly.

The method declaration and use mimic that of the readRegistryKey() method with the only change being that the callback will get called any time that the registry key changes.

Example HTML File

<html>

<head>
    <script src="Integ/comm.js"></script>
    <script src="Integ/md5.js"></script>
    <script src="Integ/base64.js"></script>
    <script src="Integ/jnrWebsocket.js"></script>

    <script>
        var jnrwebsocket = new JnrWebsocket();
        jnrwebsocket.connect('ws://10.0.0.155');
        jnrwebsocket.enableCommLogging();
        jnrwebsocket.addOnLoggedInListener(function () {

            /** Below is an example of using a callback function called readRegistryKey that gets
            executed when the result of the registry is read from the JNIOR. The parameter for this
            function is the name of the registry key you wish to read. The value returned is the
            value of the registry key. This example reads the registry key $SerialNumber from the
            JNIOR. */
            jnrwebsocket.readRegistryKey('$SerialNumber', function (keyName, value) {
                var serialNumber = value;
                console.log(serialNumber);
            });

            /** Below is an example of using a callback function called readRegistryKeys that gets
            executed when the result of mulitple registry keys are read from the JNIOR. The parameter
            for this function is and array of registry keys you wish to read. The values returned are
            the values of the registry keys. This example reads the registry keys $SerialNumber,
            $Model, and $BootTime from the JNIOR. */
            var registryKeys = ['$SerialNumber', '$Model', '$BootTime'];
            jnrwebsocket.readRegistryKeys(registryKeys, function (keys) {
                console.log(keys['$serialnumber']);
                console.log(keys['$model']);
                console.log(keys['$boottime']);
            });

            /** Below is an example of using a Async function called readRegistryKeyAsync that blocks
            and waits to execute until the result of mulitple registry keys are read from the JNIOR. 
            The parameter for this function is and array of registry keys you wish to read. The values
            returned are the values of the registry keys. This example reads the registry keys 
            $SerialNumber, $Model, and $BootTime from the JNIOR. */
            (async function () {
                console.log('serial: ' + await jnrwebsocket.readRegistryKeyAsync('$SerialNumber'));
                console.log('model: ' + await jnrwebsocket.readRegistryKeyAsync('$Model'));
                console.log('boot time: ' + await jnrwebsocket.readRegistryKeyAsync('$BootTime'));
            });

        });
    </script>
</head>

</html>

All WebSocket connections must be authenticated. The Web Server has a login as part of its functionality. The WebSockets use that login state since the WebSockets is part of the web server. If the login was handled separately we would see a double login. One login to load the html and another to access the websocket connection.

So, if a WebSocket connection is initialized from a page that was fetched from the protected area in the web server and the user logged in, then the WebSocket GET response will contain an AUTH cookie

If an additional login is required then the WebSocket connection will return a 401 Unauthorized response. The JnrWebsocket library will attempt to log in with the default credentials. If you do not want that to happen then please change the default credentials. That is strongly recommended anyway.  You can also remove the default credentials from the javascript library by issuing the setCredentials(username, password) method.  Calling this method and providing undefined for either or both arguments with disable the use of the default login.

    jnrwebsocket.setCredentials(undefined, undefined);

The OnLoggedIn listener is where you should do any initial work that you want to get done when the connection is established. For example, if you want to read some registry keys when the page loads, you will do it when the JnrWebsocket gets authenticated. The reads would fail if you tried to perform them before the connection has authenticated.

The web browser helps make a WebSocket connection easy.

Built-in WebSocket Service

Once a connection to a configured Web Server port (default 80 and 443) is made and upgraded from the default HTTP Protocol to the WebSocket Protocol, traffic must conform to the WebSocket specification. Except in the case discussed in Section 3.2 the JANOS Web Server uses a built-in server to handle all WebSocket messages then received. These must use the JSON format and the connection must be authenticated.

To initialize communications the client should send a blank or empty message. The following is acceptable.

{
  "Message":"" 
}

The connection will proceed depending on the authentication requirements established by the JNIOR configuration and the environment making the connection (browser, application, etc.).

Default Permissions

The Series 3 JNIOR (Models 310, 312, and 314) were shipped where by default web pages were not protected by login. The login requirement encountered when running the applets was the result of security in the JNIOR Protocol. Access to web pages could be controlled by permissions set on individual files or folders. For instance, removing the read attribute (R) from the /flash/www folder would force the browser to ask for login credentials and thus protect the pages. Unfortunately, a second login would then be required by the JNIOR Protocol which has to be separately protected since control and configuration were possible through it. Modifying folder permissions involved a console command (CHMOD) which tended to be unfamiliar to everyone.

The Series 4 JNIOR (Models 410, 412, and 414) use a new Registry key WebServer/Login to control web page access. This key by default is set to TRUE. The dynamic configuration pages therefore also request login credentials but a second login is not required due to the Websocket Protocol implementation which will be discussed in a moment. The WebSocket Protocol replaces the JNIOR Protocol just as the dynamic configuration pages replace the applets that have been dropped. You may still control access to areas of the JANOS website using file and folder permissions if desired. That would only be necessary should you disable the WebServer/Login requirement.

WebServer Login Enabled

With the Web Server Login requirement enabled any access to the JANOS website is challenged using the standard 401 Unauthorized response. The JANOS Web Server provides the necessary parameters so the browser can request the user’s login credentials. If the proper credentials are entered and verified by JANOS the page is promptly served. A session ID is assigned.

Subsequently, the Authorization information is supplied with requests for other pages required from the website. The JANOS Web Server recognizes the association between those credentials and the original login and therefore doesn’t challenge every page. When the browser then moves to open a WebSocket connection it uses the temporary session ID for authentication. A second is not required. This can be done because all of these connections are handled by the Web Server. This is unlike the JNIOR Protocol which is a separate server entirely and cannot be passed shared authentication information.

Once you have authenticated for the website, you can create WebSocket connections in the browser session without an additional login step. Immediately after opening the WebSocket connection, you will receive a “Monitor” message and you are good to go.

WebServer Login Disabled

If you set the WebServer/Login key to FALSE and assuming that permissions on files and folders have not been modified retaining the default Read Access flag, the browser will not need to request your login credentials. When a WebSocket is then made there are no preauthorized credentials. The login handshake in the WebSocket connection will be required before you may proceed using the WebSocket. This behavior assumes that the Websocket/Anonymous registry key has not been defined or is set to 0.

Upon opening the connection a “monitor” message will not be provided. The application needs to send a blank message and will receive the 401 Unauthorized error. The application will then need to request the user’s credentials and calculate the Auth-Digest response on its own. This is the same procedure performed by the browser. The dynamic configuration pages supplied with the JNIOR provide for this requirement. The Javascript can be used for reference.

Once the user credentials are processed the handshake can be completed and will proceed as follows.

{
  "Message":"" 
}

{
  "Message":"Error",
  "Text":"401 Unauthorized",
  "Nonce":"5d894efb48e1c3bc074fe78e7a5f" 
}

{
  "Auth-Digest":"jnior:65f2d1cb66ef63f7d17a764f3a2f2508" 
}

{
  "Message":"Authenticated",
  "Administrator":true,
  "Control":true
}

A “Monitor” message will likely immediately follow. This might even be received before the “Authenticated” message. That is the asynchronous nature of the connection. Please feel free to contact INTEG for assistance in implementing the digest calculation.

Anonymous Operation

If the Websocket/Anonymous registry key is set to a valid user ID (1 is generally the JNIOR Administrator’s ID), then no login will be required. The USERS console command can be used to determine the available user IDs. This, however, is extremely dangerous. Any application can then make a fully functional WebSocket connection. This gives anyone access to the unit with the ability to raise havoc with controls and to modify JNIOR configuration. This is not recommended. If there is physical security, meaning that access is only available to personnel on the local network and all those can be trusted, then this setting may be of use. Otherwise, you are allowing anonymous access to this connection at your own risk.

It is important to note that even if you have WebServer/Login set to TRUE and have to enter a username and password to bring up the website, the WebSocket interface is not secure if anonymous access is enabled. A separate application or copy of the website can get full control of your JNIOR.

With the anonymous key set to a valid user ID, the WebSocket connection will not require login. Immediately after making the connection you will receive the “Monitor” message. The connection is then available for full use.

Easily create your own Web Apps to interact with the JNIOR! The JNIOR WebSockets JavaScript Library is just what the name suggests. It is a library written in Javascript that will aid you in interacting with the JNIOR’s WebSocket Server. The WebSocket server provides access to all of the internal features on the JNIOR including access to the I/O, registry, and file system. You can even pump messages directly to Java applications running on the JNIOR.

The JANOS Web Server listens for connections from clients that are running one of the many popular browser programs. Typically ports 80 and 443 (for secure TLS/SSL communications) are open for connection although those are configurable through the JNIOR Registry. In addition to the default HTTP Protocol a connection may also utilize the Websocket Protocol as described in this document. The Web Server ports are shared by these two protocols. This provides for access to status information and control commands that previously were only available through the JNIOR Protocol. While the JNIOR Protocol remains a viable option for these functions the Websocket approach offers seamless integration into the dynamic web page environment. This capability is new to the Series 4 JNIOR products (Models 410, 412, and 414).

The library discussed below is designed to help you interact with the JNIOR WebSocket server more easily and at a higher level. You can write the web-socket code yourself if you like.

Background

To remotely control the JNIOR you need the ability to obtain I/O status and to affect changes in I/O condition. In the earlier Series 3 JNIOR, this was accomplished through the JNIOR Protocol made available through a TCP/IP connection typically on port 9200. This is a documented binary protocol that requires special programming external to the JNIOR for its use. Care is also required to allow access to the specific port through routers and firewalls. Once successfully implemented the JNIOR Protocol not only provided I/O status and control mechanisms. It also opened access to the JNIOR Registry and thereby the ability to configure and manage the product.

In addition to the JNIOR Protocol, it was also necessary to access the JNIOR Command Line through Telnet. Care again is required to allow access to the Telnet port (Port 23) through routers and firewalls. The Command Line is also accessible using a serial connection to the RS-232 port on the JNIOR. This Console connection provides tools for monitoring I/O status and affecting I/O conditions as well as the use of various kinds of diagnostics. Furthermore, in this environment, the product can be fully configured in all aspects including the network parameters. In addition, this is where application programs can be executed which extend the functionality of the JNIOR product.

Management of the JNIOR also requires the manipulation of files in the local file system. While files may be manipulated through a Console connection transfer to/from an external system is done using FTP. Again care must be taken to allow access to the FTP command port (Port 21) through routers and firewalls. FTP typically opens/accepts data connections which must also be accommodated by the network.

With the introduction of the Series 4 JNIOR running the JANOS operating system, the various I/O and management requirements covered by these other protocols can be additionally handled through a single Web Server connection. Access to the Web Server is typically through ports 80 and 443. The latter connection provides for TLS/SSL up to 256-bit security. While these ports would also need to be accommodated by routers and firewalls this is a much more standard requirement and often routine request for IT personnel. This consolidation of functionality is accomplished using the WebSocket Protocol as specified by the Internet Engineering Task Force (IETF) in combination with JANOS server-side scripting. This can result in a fully functional browser-based dynamic website providing JNIOR monitoring and control. The example is the configuration pages provided with the product. These Javascript[TM] based dynamic web pages have replaced the Java-based applets used by the Series 3 JNIOR products.

Protocol Overview

Most computer languages today accommodate programmatic connection to Web Servers in one fashion or another. It makes sense since the majority of applications developed today involve networking and therefore access to the vast range of data available through the Internet. These web applications needed some form of bi-directional communication between the client and server. For a time programmers attempted to get the job done through an abuse of the HTTP Protocol. A simpler solution has been provided in the form of a WebSocket API which has been quickly accommodated. As a result, most web-based programming environments support Websocket connections and the programmer can utilize them as easily as any other web protocol.

Briefly, the client makes a connection to a JANOS Web Server port. This port expects a valid HTTP connection but is also shared by the WebSocket protocol. Transparently behind the scenes, the connection issues the appropriate HTTP headers requesting an ‘upgrade’ to the WebSocket protocol. When the handshake is complete the connection will be ready to handle bi-directional WebSocket messaging. The JANOS Web Server supports a built-in WebSocket service with messaging that can be used to monitor, control, and manage the Series 4 JNIOR. The built-in service employs JSON message formatting.

To provide additional flexibility the JANOS WebSocket connection can, through a parameter in the URL, be redirected to an application running on the JNIOR. In this case, WebSocket messages are routed through the JANOS inter-process messaging mechanism to the application program. The program uses the same messaging system to provide replies and messages outward through the WebSocket connection. In this fashion, a completely custom messaging system can be implemented.

Security

Any protocol providing control and management functions must employ some form of security preventing unauthorized access and disturbance. In addition to being available through a TLS/SSL secure connection, the built-in JANOS Websocket implementation requires authentication. The authentication handshake must be completed before any operations for monitoring, control, and management will be allowed. This login uses active JANOS user accounts and subsequent operations adhere to the account permissions assigned by the administrator.

To facilitate the seamless use of the WebSocket protocol in the implementation of dynamic web pages a mechanism is provided that utilizes any website authentication completed by the browser to pre-authorize the WebSocket connection. This ensures that only a single entry of login credentials is required to bring up a fully functional and secure dynamic website served by the JNIOR. Note that custom applications running on the JNIOR that serve WebSocket connections are free to implement or ignore any kind of authentication requirement.

Installing the JNIOR Supporter requires a Java Runtime Environment in order to run. To avoid running into any trouble when installing the JNIOR Supporter Tool, we’ve prepared different ways to install the application based off your operating system, so that it will hopefully make it easier to setup. 

Windows

Name Version Release Date Size MD5
JniorSupporterInstaller v1.0 Jan 04 2024 38.9 MB cfa86a8521ed798f5eb37aad3383a644

For Windows, we’ve created an installer that should setup an .exe application and a JRE for it to reference. You’ll download and proceed through the installer, and once finished the Java Supporter should be ready to launch.

When launching the installer, the you’ll first be prompted if want to create a desktop shortcut. This is recommended to make launching the tool easier in the future.

Once that is finished, clicking next will ask you to begin the install. Clicking next will start it.

Once the install is finished, you’ll be given the option to launch the JNIOR Supporter tool immediately after finishing its install. After that, you’ll now have the JNIOR Supporter Tool installed and ready to use.

Linux

Name Version Release Date Size MD5
JNIOR Supporter v1.0 Jan 08 2024 2.3 MB cff040d0e79f9e6b3d45ea59c02c8ef1

With Linux, after downloading the jniorsupport.jar file from above, the commands below can be run in a Linux terminal that will install a valid version of Java.

sudo apt update
sudo apt install default-jdk

Once this is done, we’ll now want to set the execution bit for the .jar file we downloaded. The command below will make the jniorsupport.jar file runnable when you double click it.

chmod +x /path/to/your/file/JniorSupporter-1.0-1.jar

You can also launch the jar file by directly running it from a terminal with the following command.

/path/to/your/file/java -jar JniorSupporter-1.0-1.jar

The Cinema Migration Tool is an application that copies a Cinema Setup from a Series 3 JNIOR and loads it on a Series 4 JNIOR. All that’s needed is a snapshot from the Series 3 JNIOR, and the Cinema Migration Tool will use the configuration files inside it to format that Series 3 JNIOR’s Cinema setup on a Series 4 JNIOR. This tool should make moving Cinema setups from Series 3 JNIORs to Series 4 JNIORs much easier. Here is a brief walkthrough on how to use the Cinema Migration Tool.

Name Version Release Date Size MD5
Cinema Migration Tool v1.0 Nov 09 2023 536.3 KB 2433b01bbc7cf107c9e5c275f271aca3

Load the Series 3 Snapshot

To start, once you’ve downloaded the zip file, you’ll want to open it and run the cinema-series3-upgrade.exe application within it. (Don’t unzip). Then as mentioned previously, the Cinema Migration Tool requires that you take a Snapshot of the Series 3 JNIOR whose configuration you are trying to copy over. Once you have the snapshot, you’ll then select the Open Series 3 Snapshot button, where you’ll navigate to the snapshot on your PC and open it in the Cinema Migration Tool.

NOTE: When opened, the device file, macro file, and jnior.ini file should say they are found in the Cinema Migration Tool. If they are not found, this means the pathing to the files in the snapshot isn’t incorrect. Make sure not to unzip or alter snapshots after they’ve been taken.

Publish Configuration to Target Series 4 JNIOR

Once the snapshot is loaded, next you’ll want to enter the IP of the JNIOR you are trying to publish this configuration to. Make sure this JNIOR is on the same network as your PC. Once entered, hitting run will start the Cinema Migration Tool in publishing the Cinema configuration to the Series 4 JNIOR. 

The Cinema Migration Tool will state when it is done at the bottom of its dialog. Once finished, the Cinema Migration Tool can be immediately run again to publish to another JNIOR.

Confirm Your Setup

To make sure this has worked, you can check by going to your Series 4 JNIOR’s web page and navigating to the Folder tab. Once there, check that your root folder contains the device and macro file from your Series 3 Snapshot, along with making sure the Cinema.jar application exists in the flash folder. If this is the case, then you’ve successfully moved your configuration from the Series 3 to the Series 4 JNIOR! If this isn’t the case, INTEG support would like to help you out. You can reach out to us by joining our online chat, or by emailing our support at support@integpg.com.

This is the JNIOR Knowledge-base.  Here you will find a collection of articles that will help you learn or troubleshoot the JNIOR.

If you find there is information we should add then please get in touch with us.

Name Version Release Date Size MD5
JANOS - UPD v2.4.2 Jan 18 2024 969.2 KB b7f240e6fba1075dd1088af9b0ef8087
Series 4 All-In-One Update Project v2.4.2 Jan 18 2024 1.8 MB 293c415caba1ff6d9b9a404be3430cc2
Core JANOS Update Project v2.4.2 Jan 18 2024 1.3 MB a9f55f4bd5dcffbbae9bea07a166534f
JANOS Release Notes v2.4.2 Jan 04 2024 484.7 KB 6db6268661a5caf7294663798282cf52

Models

JNIOR, a Network I/O Resource utilizing the JAVA™ platform, is a cost-effective automation controller that communicates over a network using TCP/IP via an Ethernet Port or via its serial port. The JNIOR is a general-purpose automation controller and I/O device that is easily configurable for controlling and monitoring your equipment or process via the built-in web pages, by enabling the built-in software applications, interaction with an application running on another computer, or by adding your own applications.

Currently, there are 4 different Models of the Series 4 JNIOR, each very similar to the other with a few differences.

JNIOR ModelCatalog NumberI/O CountSerial/DMX Ports
410JNR-100-004B8 Inputs, 8 OutputsCOM Port (RS232), AUX Port (RS232 / RS485)
412JNR-200-004B4 Inputs, 12 OutputsCOM Port (RS232), AUX Port (RS232)
414JNR-300-004B12 Inputs, 4 OutputsCOM Port (RS232), AUX Port (RS232)
412DMXJNR-200-004D4 Inputs, 12 OutputsCOM Port (RS232), DMX 512 (5-pin XLR connector)
Each JNIOR Model links to their web page, where more detailed information can be found for them (like their data sheets)

Powering Your JNIOR

The JNIOR uses a 2-piece terminal connector system for all power and I/O wiring connections allowing for easy installation and/or removal of the JNIOR.  Additional installation information and drawings are provided on our website.

The JNIOR can be powered with 12 to 24 volts AC or DC. An optional, wall transformer (AC power converter) for North American outlets is available from INTEG that can be used for converting 120/240 VAC to 12 VDC @ 1 amp. International models are also available as Euro and UK plugs.

The Power Connector is located along the upper left edge of the JNIOR. Note that this is a 4-pin connector. If numbered from one (1) through four (4) from left to right power is always connected to positions 2 and 3 (middle two connectors). The polarity is irrelevant although it is recommended that the positive (+) lead be connected to position 2.

The left two positions (1 & 2) are internally connected together, as are the right two positions (3 & 4). This is to facilitate the interconnection of the supplied power to other devices and circuits such as input or output devices. If you power the I/O circuits with your JNIOR power supply, please make sure the power supply is sized appropriately.

WARNING: Do not connect the transformer leads both to Positions 1 & 2 or both to positions 3 & 4. This will short the transformer and possibly damage it and/or the JNIOR. Always use a fused/protected power source.

When a proper power source is connected and turned on the leftmost LED adjacent to the power connector will glow BLUE continuously. The LED to the right may glow ORANGE for several seconds. This orange STATUS LED remains on through most of the JNIOR boot sequence. Later it will flash whenever an external connection is made to the JNIOR via the Ethernet port.

Wiring JNIOR I/O

JNIOR Inputs

The JNIOR is equipped with optically isolated digital inputs. Each digital input can accept AC or DC voltage sources in the 0 – 30 V range. An LED associated with each digital input displays the current electrical status of the input (off or on). Isolation of each digital input allows you to connect input signals to different voltage sources without the addition of isolation devices. The input voltage must be greater than 2 VDC for the input to register as “on” and then less than 1 VDC to register as “off”. A typical connection would be as follows:

JNIOR Outputs

The JNIOR is equipped with Relay Outputs with most of them being a Form A SPST relay (1 Normally Open Contact) and two of them being a Form C SPST relay (1 Normally Open Contact and 1 Normally Closed Contact – jumper selectable as to which one is available on the JNIOR terminals by removing the lid and changing the jumper setting. Normally Open is the default.) Each relay output is independent and isolated from the other relay output. Each relay contact rating is 1A @ 24VDC and the voltage source must be in the range of 5 – 30V AC or DC. A typical connection would be configured as follows:

Setting the JNIOR’s IP

Starting with JANOS 2.0, the JNIOR is shipped with DHCP enabled for dynamic setting of the JNIOR IP address by a network server. More information is here on finding your JNIOR’s IP address.

If DHCP does not work on your network, then there are two ways to configure your JNIOR IP settings:

  • By using the JNIOR Support Tool (Beacon tab) provided on our website at the following link: https://www.integpg.com/jnior-support-tool/. You can use the JNIOR Support Tool to configure the JNIOR’s IP by right-clicking the JNIOR and selecting Configure -> IP Configuration. A dialog will appear to edit the JNIOR’s IP after that.
  • Via the RS232 Serial Port and a command line window available via the JNIOR Support Tool: http://www.integpg.com/support/jnior/. You can use this command line to set the IP by doing the ipconfig -a IP -m MASK command, replacing ‘IP’ with the IP you want for the JNIOR, and ‘MASK’ with the subnet you want for the JNIOR. For example, on a private network, the IP address may be something like 192.168.1.10. A common mask would be 255.255.255.0. The command would then look as follows:
ipconfig -a 192.168.1.10 -m 255.255.255.0

JNIOR Web Pages

The JNIOR Series 4 contains the JNIOR web page which is a web page used for a variety of functions including monitoring and manually controlling the I/O, changing various configuration items, opening a Telnet/Console session, and several other functions. The JNIOR web page works with Microsoft Internet Explorer, Google Chrome, Firefox, and other browsers.

PLEASE NOTE: The dynamic web page requires a ‘modern web browser’ which is defined as Internet Explorer 10 or greater, Google Chrome or Firefox.

You can launch the JNIOR web page from the Beacon tab in the JNIOR Support Tool by right-clicking on your JNIOR and going to Tools – Open web page or by manually entering the JNIOR IP address in your browser address line. To manually launch the JNIOR web page, open your browser and in the address line of the browser type your JNIOR IP address or serial number, for example: http://10.0.0.146 or jr616010235

After the JNIOR web page is loaded, the user is asked to log in with a valid username and password. You can use the default username (jnior) and default password (junior).

The JNIOR web page will be launched in your browser as shown below.

There are two tools to choose from when working with the JNIOR.

Why two tools?

The JNIOR Support Tool has been around for more than ten years. For much of that time, it has remained unchanged and has been a staple for configuring and maintaining the JNIORs. Within the past few years, we have seen more and more customers using non-Microsoft Windows computers and we wanted to offer a cross-platform alternative—that’s where the JNIOR Supporter comes in. We chose to develop the new cross-platform tool in JAVA. This requires you to have a Java Runtime Environment loaded.

Why not move to the new tool altogether?

The JNIOR Support Tool allows Cinema users to configure devices and macro files. There is A LOT of functionality that we are not ready to replicate. We wanted to get the tool released and not delay while the cinema functionality was being implemented.

Which one should I use?

If you are running a non-Windows environment then you will need to load the new Supporter. If you are looking to use the Cinema application then you will need to use the Support Tool. Beyond that, it is up to you. We try to ensure that they both have the same basic functionality.

The JNIOR is a very reliable device.  I’m sure many devices claim that but as of this writing, in October 2023 we have spoken with customers that are still running Series 3 units from 2005.  The first run of Series 4 units are still operational from 2012.

There are basically two components that would have any endurance data.

  1. The mechanical relays should be able to see a minimum of 100,000 closures.
  2. The battery should have a life of around 6 years. The JNIOR only relies on the battery to maintain the SRAM and the internal clock when external power is not present. The JNIOR can operate without a working battery. The 410, 412, or 414 battery can be replaced in the field. It is a CR2032 coin-cell battery.

Watchdog

The concept of using a watchdog is to ensure that the application continues to run as expected.  JANOS provides a Watchdog class that has a couple of options.  A sample of how to use that class can be found here.

Single Instance

Most times we only want one instance of an application running at a given time.  Use the JANOS.registerProcess() method to check to make sure there is not another instance running. Here is an example of using the registerProcess() method.

String applicationName = "TestApp";
if (1 < JANOS.registerProcess(applicationName)) {
    JANOS.syslog("Another instance of " + applicationName + " is running");
    System.exit(-1);
}

Versioning

A great way to be certain that specific code is running is to implement versioning.  If the application is going to be released or there are going to be multiple releases then versioning is nearly a must.  Many times versioning takes the form of major.minor.build.  This is not always the case. Sometimes you will see version numbers that start with the year that it was released.  For example, Ubuntu uses year.month to get 22.04.  The format you use is completely up to you.

Model and I/O Count

One issue that your application can have is handling the different models of JNIORs and the differing input and output count.  The following code can help you with that.

    /**
     * @return the number of inputs based on the model of jnior
     */
    public static int getInputCount() {
        // if a 412 or 412 DMX then return 4.  If not then check if a 414 and return 12.  If not 
        // then return 8.
        String modelString = JANOS.getRegistryString("$Model", "");
        return (modelString.startsWith("412")) ? 4 : (modelString.equals("414")) ? 12 : 8;
    }



    /**
     * @return the number of outputs based on the model of jnior
     */
    public static int getOutputCount() {
        // if a 412 or 412 DMX then return 12.  If not then check if a 414 and return 4.  If not 
        // then return 8.
        String modelString = JANOS.getRegistryString("$Model", "");
        return (modelString.startsWith("412")) ? 12 : (modelString.equals("414")) ? 4 : 8;
    }

Loading an Application

We recommend that all applications are saved in the /flash directory.  There are multiple ways to upload a file to the JNIOR.  How you decide to do that is up to you but the WebUI is a great tool for accomplishing this task.

Open the WebUI and go to the Folders tab.  Click on the /flash directory in the tree view on the left.  You can now drag and drop your JAR file to the view on the right.

Once you drop the file you will see the transfer progress bar.

Great, the application is on the JNIOR. We now need to decide how and when it should be executed.

Running the Application in the Foreground

When should we run an application in the foreground?

Answer, when we are developing, debugging or when an application needs to interact with the user from a command prompt. Notice I said from a command prompt. There are other ways to interact with the user. For example, a web interface. But that will be discussed later.

To execute an application from the command line we can enter java APPLICATION_NAME.jar or simply APPLICATION_NAME. if only the application name is entered then JANOS will look for a JAR file. If the file is found then it is executed.

Running the Application in the Background

When would we want to execute an application in the background?

Answer, when we have an application that we are running that we will not interact with but we still want to be able to interact with the command line.  To do this we will append a “&” to the end of the command we use to launch the application.  The command line prompt will be returned immediately. 

Setting an Application to Run on Boot

When do we want to execute an application on boot?

Answer, when we have a production application that should always be running.  To set this up we will make a run/ registry key.  The name of the registry key can be anything you want.  The content of the key is the way that you would execute the program from the command line as we did above.  This is the same as executing an application in the background but without the user having to start the application manually.

Next > Other Application Considerations

The JANOS Runtime Library should be installed as a Library in your IDE.  Here is how to do that in the Apache NetBeans IDE.

Open Libraries Dialog

Open the IDE and select Libraries from the Tools menu.

Create New Library

Click New Library…

Give the Library a name. We suggest JanosRuntime_2.0

Add JAR to Library

On the right side of the dialog you will new click Add JAR/Folder…

Navigate and select the location where the Janos Runtime JAR file was saved.

Adding in the sources

Now that the JanosRuntime library has been created, we want to add the sources so that we can reference them while working with our code.  We do not distribute source code but the method stubs are still extremely helpful.

To do this we will click on the Sources tab and then repeat the steps to Add JAR/Folder as you did when creating the library.

Add Javadoc

Adding the javadoc will enable the NetBeans intellisense. To do this we will click on the Javadoc tab and then repeat the steps to Add JAR/Folder as you did when creating the library.

Next > Creating a Project

So you’re looking to write your own code to run on the JNIOR? You have come to the right place. Writing code for the JNIOR is as easy as writing code for your PC. The JNIOR will run the JAR that is created by your favorite IDE. There are almost limitless possibilities when it comes to what you can program on the JNIOR. Most of the applications that we have written have come from customer requests over the years.

This section of our website is not meant to teach you how to code but rather to show you how to enable your IDE to write JNIOR code that is targeted for the JNIOR.

Note: Additional Libraries cannot be used with JNIOR applications.

Prerequisites

  • Java JDK
  • Java IDE (We use Apache NetBeans)
  • JANOS Runtime Library
  • Understanding of Java Programming

Check for Java

Type java -version at a Command Prompt

JANOS Runtime Library

Applications targeted to run under JANOS must be built against the JANOS Class Library. This library can be found in the etc/ folder on your JNIOR Model 410. This file is OS version dependent although it is likely not to change dramatically from release to release. You might note the date and before you update or finish an application for your JNIOR make sure that you are using the latest version that you have available. INTEG can also send you a copy of JanosClasses.jar on request.

The JANOS Runtime Library does not contain the full JVM that you might be used to programming against. It is close but to save code space we have omitted some classes and methods. Take a look at the JANOS Runtime Javadoc to see what classes and methods are available.

Name Version Release Date Size MD5
JanosRuntime.JAR v2.4.2 Jan 04 2024 1.6 MB 8a23649bc2a174549e37d971fad9b49f

Next > JANOS Runtime Installation

To create a new project go to the File | New Project… menu item.  This will open the New Project dialog.  In the New Project dialog box, you can select Java with Ant under Categories, and Java Application under Projects.

Hit next, and then give the Project a name. In this example the project is named ‘ExampleProject’. After naming it the application can set to where its saved to. This is useful as projects can all be saved in the same location, making them easy to find in one directory. Once a name and location are given to the project a name and a location on your computer, hit finish.

Add JANOS Runtime

Now that the project is created, the JANOS Runtime library needs to be added to the project so its classes can be used in the application. To do this, go up to the file drop-down and select ‘Project Properties’. 

In the Project Properties dialog box, select the Sources option under the Category section. For the Java Platform, use a version of Java 8 as a default platform. 

Next, select the Libraries option under the Category section. Under to the compile tab, select the plus icon next to Classpath and select ‘Add Library’. Then select the JANOS Runtime Library. 

Give JANOS Runtime precedence

In order to ensure that the classes stored in the JANOS Class Library take precedence over any that might be also present in the JDK, you can do this by going to the compiling section of your projects properties and in the additional compiler options entering:

-bootclasspath “${file.reference.JanosClasses.jar}”

This will insure that the JanosClasses.jar file is searched before any other library. As of the time of this writing we do not know of a way to prevent the Java Compiler from referencing the installed platform libraries.

Debug Information

Debugging information is extremely useful if some error arises.  The debug information in the Stack Trace will pinpoint exactly where the bug lies in your code.  The stack trace will show you the call stack containing source file names along with line numbers.  You can enable debug information in the Project Properties dialog.

Next > Running an Application

We offer Series 4 JNIORs that are made to be a great drop-in replacement for Series 3 JNIORs.

If you have a Series 3 JNIOR and are looking for a replacement, they unfortunately hit the end of life in 2015 and we no longer offer them. Series 4 JNIORs are essentially an improved version of the Series 3 JNIOR that offer improved hardware, more applications, and more built-in functionality. Most Series 3 applications have been modified to run on the Series 4 JNIORs as well, but the dimensions and footprint of the Series 3 JNIOR are the same as the Series 4 though.

Here are just a few of the improvements implemented from the Series 3 to Series 4:

  • A faster processor allows for quicker responses from applications running on the JNIOR and quicker reboots for the JNIOR.
  • The Model 410 JNIORs have RS-485 capabilities for their serial connections.
  • Applications such as Tasker, Analog Presets, MQTT, Grapher, and DMX provide new functionality for the JNIOR to use.
  • Easy-to-use configuration pages through web browsers provide more ways to make customizing your JNIOR simpler, such as a folder tab to view files on the JNIOR.
  • Series 4 JNIORs can capture network traffic between the JNIOR and other devices to help investigate and troubleshoot all data being communicated with it.

If you have a Series 3 JNIOR and are looking to replace or upgrade to a Series 4 JNIOR, let us know and we’ll help you transition your setup!

Web Pages have been added for the Cinema application! These web pages have been implemented to make configuring cinema easier. This post will go over the different tabs the Cinema Web Pages have. To start, there are 7 tabs available on the Cinema Web Page. Other then the home page, each tab should display different registry settings to configure for the Cinema application.

Home Tab

The home tab is the opening tab when the cinema web pages are loaded. Unlike the other tabs, this page allows you extra functionality over the cinema application besides editing the registry keys. The first section allows you to enable/disable the cinema application to run on boot. Keep in mind that when changing this setting a reboot is need for it to take effect.

The second section allows you to test the communication settings of an external device. This allows you to test the communication between the JNIOR and an external device before having to create it in the macro and devices files. Below is a quick explanation for each field.

  • Command – This section is where you enter the command you wish to try sending to the external device.
  • IP – This is where you enter the IP address of the device you wish to send to.
  • Port – This is where you enter the Port number of the device you wish to send to.
  • Hex or ASCII – This sets weather the command you send is in ASCII (text), or hexadecimal format.

The third section displays the current connection status of the cinema application, and allows you to test macros that have been published to the JNIOR. Clicking execute will run the macros across from it. If Cinema doesn’t have a successful connection setup, it will display what isn’t setup correctly to create a connection to the Cinema application. It will also display if macros haven’t been loaded on the JNIOR yet.

Cinema Server Tab

Cinema.JAR can accept one or more connections from an external device using the Cinema Server Client port and this connection can be over the serial port and/or the Ethernet port. The Cinema Server tab allows you to edit the settings of the Cinema Server Client from the web page. Below is a quick explanation for each field.

  • TCP Port – Sets the TCP port that the Cinema Server connects on.
  • Serial Port – Sets the serial connection that the Cinema Server connects on.
  • Send Unsolicited I/O Alerts – Determines if any Alert such as I/O Counts or Date Stamps should be allowed through the Cinema Server Connection.
  • Send Ack – Determines if the Cinema Server Connection allows responses to be returned from the external device through the Cinema Server Connection.
  • Send Counts – Determines if the JNIOR reports each time an input changes to the external device connected through the Cinema Server Connection.
  • Send Date Stamp – Determines if each report of an I/O change on the JNIOR reported through the Cinema Server Connection gets appended with the current data and time.
  • Incoming Termination String – Sets the string that Cinema looks for at the end of each message sent to it to know if that is the end of message being sent.
  • Outgoing Termination String – Sets the string that Cinema adds to the end of each message it sends. The external device being sent to needs to know to look for this Outgoing Termination String.
  • Enable Serial Commands – Enables commands to be sent in Serial Control Format. This allows commands to be sent through that can close or open outputs on the JNIOR.

Control Panel

The JNIOR Control Panel Switches can be configured to trigger a macro to execute whenever the switch is pressed. The Control Panel tab allows you to assign macros to execute on the 12 control panel switches that are available. This requires you to own the control panel and have it connected to the JNIOR through the JNIOR’s sensor port.

Fire Alarm

The JNIOR can be assigned inputs to activate and release a fire alarm macro. The Fire alarm tab allows you to assign the inputs and the names of the macros that activate when the fire alarm is triggered and released.

Logic and Schedule

Cinema can setup logic statements and time events to determine when macros should be executed. The Logic Tab allows you to run macros based off of the current values of the JNIOR’s I/O as well as when other macros execute. The Schedule Tab allows you to set the time of day, the date, and the reoccurrence of when a macro is executed.

Triggers

Cinema can allow I/O to trigger macros similar to how the control panel works. The Triggers tab lets you assign what macros execute off specific I/O. The I/O in the triggers tab will reflect the type of JNIOR you are configuring.

While JNIOR 412DMX units may be unavailable, JNIOR 410s can be made to work as a substitute. Note that this does NOT work for JNIOR 412s and 414s, as 410s RS-485 compatibility is the reason why it can be used as a 412DMX substitute.

Cabling

When trying to connect to a 410 with DMX, the cabling will need to be corrected as you need to go from an AUX port to a male/female 5-pin XLR connector. By splicing into an existing DMX cable, you can attach a DB9 adapter with screw terminals to the end of the cable. It should look something like the picture below.

Here is the pin numbering for splicing the adapter on. Note the wire colors vary.

        Signal           XLR      DB-9 Male
--------------------  ---------  -----------
Signal Ground (GND)       1          5
Data (D-)                 2          2
Data (D+)                 3          8
Not Used (NC)            4,5     1,3,4,6,7,9

This cable allows the JNIOR to be a DMX FIXTURE. THE RESULTING DMX CONNECTION IS NOT ISOLATED. We recommend using an isolated power supply for the JNIOR and not sharing that voltage with other circuits. Take great care in making ground connections. Note that the JNIOR relay outputs are naturally isolated.

Aux Port Application

Below is an application you’ll need to update and install on the JNIOR. This is required for the JNIOR to interpret DMX communication on the JNIOR.

Name Version Release Date Size MD5
DmxPort for enabling DMX on 410 Mar 17 2021 3.5 KB 299c66717c03a9c9b702716d9d56d095

Serial Settings

The serial settings of the JNIOR need to be configured so the AUX port output doesn’t disrupt the DMX communications. Below are the settings you need to set for the AUX Port. This is located on the JNIOR\’s Webpage, in the Serial I/O section under the Configuration Tab.

Once the cabling has been created, the DMX Port application is on the JNIOR, and the Serial Settings have been set, DMX communication should be possible on the JNIOR 410.

If you have any questions about this, contact our support to get help with this setup using pure chat or our email: support@integpg.com.

The DMX application does not ship preinstalled. You MUST obtain the application from our website. There is a download on the website that will be opened in the JNIOR Support Tool and published to the JNIOR. This is called an Update Project.

Here are links to latest versions of the JNIOR Support Tool and the Cinema application. NOTE: The DMX link below is for new installations only. If you already have the DMX application on your JNIOR and only need to update to a newer version, visit our DMX page to download our other update project for DMX that isn’t for new installs.

Name Version Release Date Size MD5
JNIOR Support Tool v7.15 Nov 20 2023 9.9 MB d9f2ddfb2bcd13a886316d61d8909ea1
DMX Application v3.7 Oct 31 2023 656.0 KB b90aa191046fab7c7a0e05137833d95a

After installing both the JNIOR Support Tool and the DMX Update Project, you’ll want to open the Support Tool and click on the Update Tab. Once there, the first thing you’ll want to do is select the Open Project button, and select the DMX Update Project you just downloaded. When you open the DMX Update Project in the Support Tool you will see the following.

DMX Update Project

In the DMX application you can create fixtures, scripts and triggers to control the 512 DMX channels for your external lighting device.