Knowledge Base

We showed you how to make an Outgoing HTTP Request. If you would like to make a secure connection you need only add a single line of code.


Here I will securely connect from my development JNIOR to the external HoneyPot JNIOR. From the example in the other topic I have modified the host and the request to attempt to access the JNIOR.

package jtest;
import com.integpg.system.Debug;
public class Main {
    public static void main(String[] args) throws Exception {
        // Location services
        String serverHostname = "";
        int port = 443;
        // Establish a Socket, get streams, and set a timeout
        Socket dataSocket = new Socket(serverHostname, port);
        DataOutputStream sockout = new DataOutputStream(dataSocket.getOutputStream());
        DataInputStream sockin = new DataInputStream(dataSocket.getInputStream());
        // Negotiate a secure connection
        // Issue the HTTP request
        sockout.writeBytes("GET / HTTP/1.1\r\n");
        sockout.writeBytes("Host: " + serverHostname + "\r\n");
        // Process the response header
        int length = 0;
        String response;
        while ((response = sockin.readLine()) != null) {
            // Header ends with blank line
            if (response.length() == 0)
            if (response.startsWith("Content-Length: ")) 
                length = Integer.parseInt(response.substring(16));
        // Obtain the entire response (if any)
        response = "";
        if (length > 2) {
            byte[] resp = new byte[length];
            response = new String(resp, "UTF8");
        // Data (should be JSON)
        // Close the Socket
bruce_dev /> jtest
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Digest realm="JANOS Web Server", qop=auth, nonce="66d0bb430469f01e9153358cfa7f"
Content-Length: 99

 3c 48 54 4d 4c 3e 3c 48-45 41 44 3e 3c 54 49 54    <HTML><H EAD><TIT
 4c 45 3e 34 30 31 20 55-6e 61 75 74 68 6f 72 69    LE>401.U nauthori
 7a 65 64 3c 2f 54 49 54-4c 45 3e 0d 0a 3c 2f 48    zed</TIT LE>..</H
 45 41 44 3e 3c 42 4f 44-59 3e 3c 68 31 3e 34 30    EAD><BOD Y><h1>40
 31 20 55 6e 61 75 74 68-6f 72 69 7a 65 64 3c 2f    1.Unauth orized</
 68 31 3e 3c 2f 42 4f 44-59 3e 3c 2f 48 54 4d 4c    h1></BOD Y></HTML
 3e 0d 0a                                           >..

bruce_dev />

So we get the response expected. But was it done securely? Here’s the transaction from the Wireshark point of view.

Timeouts are often required. JANOS supports timeouts on most inputs. Sometimes though you just need to implement an overall timeout. For example, if you leave an UI unattended for some period of time you might want it to return to a default Splash Screen or something along those lines.

This is easily achieved and we usually use the uptime in milliseconds as a reference. The approach is to add the timeout period to the current uptime and when the uptime exceeds that perform the timeout action. In the meantime if events occur (such as UI leypad activity) you reset the tmeout by recalculating.

Here is example code:

public class Main {
    static final int TIMEOUT = 120000;
    public static void main(String[] args) throws Exception {
        // Print time
        System.out.println(new Date());
        // establish and initialize a timeout
        long timer = JANOS.uptimeMillis() + TIMEOUT;
        while (JANOS.uptimeMillis() < timer) {
            // some event would reset the timer
            // timer = JANOS.uptimeMillis() + TIMEOUT;
        System.out.println("Timeout expired.");
        System.out.println(new Date());
bruce_dev /> jtest
Wed Dec 06 09:16:31 EST 2017
Timeout expired.
Wed Dec 06 09:18:32 EST 2017

bruce_dev />

And there you go. Close enough to 2 minutes (120000 milliseconds). Typically such timeouts need not be precise. You do not want to load the CPU doing little else than checking for timeout. If you are trying to implement an accurate delay or scheduling an event at a precise time there are other approaches. This is your quick and dirty timeout.

Note that you do not want to use the RTC time of day for this kind of timeout. That can jump discontinuously when for instance the clock is adjusted manually or through the NTP protocol.

It seems that more often than not these days (at INTEG at least) when we need to store or transfer data we are using the JavaScript Object Notation (JSON). This is also known as ECMA-404 The JSON Data Interchange Standard. I have attached the document. If you are not at all interested in JSON you should at least visit if for no other reason but to see how amazingly clearly and impressively concisely the format is described in just a single page.

JANOS uses JSON in numerous ways. Firstly, it is the data format that we use for the built-in Websockets interface that replaces the original binary JNIOR Protocol. That interface provides remote monitoring and control of the JNIOR. It is the underlying connection that makes the DCP (Dynamic Configuration Pages) possible. Secondly, the MANIFEST command uses JSON as a database format for the manifest.json reference files. And also, the JSON functionality is exposed through the JANOS Runtime Environment where it has been employed by applications for communications, databases, and configuration. The CAT command even has an option (-J) that will format a JSON text (including manifest.json) file making it readable.

From the applications point of view, JSON is handled through the java.util.Json class supplied by the etc/JanosClasses.jar runtime library. The JANOS programming environment is not your standard Java environment. This is one of many classes that we have provided allowing you to benefit from the underlying operating system. I am going to dive into this JSON class to show you what can be achieved and some of the tricks.

  ECMA-404.pdf [ Jul 19 2018, 1 MB, MD5: a2e87492ab7c03f557c98c8ecde9c79a ]

I have to admit that I have been recently developing applications that utilize JSON and this forced me to refresh my memory of the java.util.Json class. There are few enhancements to that class that I might implement. So I thought that I would do that here and out in the open. I will be clear though as to what is new for JANOS v1.6.3 and what you already have available in your JNIORs.

So to start I have attached the current JavaDoc for the class. In this there is one new method getBoolean() that I have just added. Before this you needed to use the get() method and cast the returned Object it to a boolean to retrieve the logical. That by itself is not a problem. But, it wouldn’t be clear to you that you could do that.

Ok, in the process I will give the JavaDoc some attention too. Please feel free to jump in and comment.

  Json-JanosRuntime-JavaDOC.pdf [ Jul 19 2018, 190 KB, MD5: 7ad7bc53e195b896aba20960e0013d18 ]

By the way, if you are programming and want access to this JavaDoc you need to get the runtime JAR from us. You can develop using the etc/JanosClasses.jar runtime but that does not contain the JavaDoc. Elsewhere I describe how to configure Netbeans to build your application specifically for our runtime. Here I have attached the enhanced Runtime JAR for JANOS v1.6.2. If you configure for it you can confirm that the Json getBoolean() method is absent from the class.

[Download not found]

To get started we could use some examples of JSON with which to work.

You can run the MANIFEST -U command and generate an updated manifest.json for your JNIOR. That file actually is stored in two places: /manifest.json and /flash/manifest.json. One is the backup for the other. Here is what it looks like. I have to apologize as my development JNIOR has a crap load (technical term) of files on it so its a long listing. We’ll use CAT -J to format it.


bruce_dev /> cat -j manifest.json
  "date":"12/01/17 13:04:04",
bruce_dev /> 

I can get some small ones say from the protocol we are defining to the Cinema UI project. Here’s the response to a GetInfo request. And, I’ll get the response to a MacroList in a bit.


bruce_dev /> cat -j getinfo.json                                                                
  "Information":"Cinema v2.4.0.473"
bruce_dev />

Okay so here is a response to a MacroListRequest that we are using in the Cinema UI implementation. It is just another JSON example that we can work with here.


bruce_dev /> cat inforesponse.json -j
    "Preshow Start",
    "Preshow End",
    "Flat Start Trailers",
    "Scope Start Trailers",
    "Feature Start",
    "Feature Credits",
    "Feature End",
    "Start Intermission",
    "Stop Intermission",
    "Extend Intermission 15 Seconds",
    "Shorten Intermission 15 Seconds",
    "Intermission End",
    "Fire Alarm",
    "Fire Alarm Clear",
    "Lights Dim",
    "Lights Half",
    "Lights Full",
    "ticket sold",
    "no ticket sold",
    "LED Off",
    "LED Green",
    "Core Command 1",
    "Core Command 2",
bruce_dev /> 

So the file actually contains one huge string. Here I will manually wrap it.

{"Message":"GetMacroListResponse","MacroList":["Preshow Start","Preshow End","Flat Start Trailers",
  "Scope Start Trailers","Feature Start","Feature Credits","Feature End","Start Intermission",
  "Stop Intermission","Extend Intermission 15 Seconds","Shorten Intermission 15 Seconds","Intermission End",
  "Fire Alarm","Fire Alarm Clear","Lights Dim","Lights Half","Lights Full","Multiple","Test","ticket sold",
  "no ticket sold","violet","LED Off","LED Green","Core Command 1","Core Command 2","RWB"]}

let’s access the MacroListResponse and fetch data from it. The following program creates a Jason object from the content of the specified File. We need to use a File object here since we can also instantiate a Json object directly from a string. So we can’t just directly specify the filename. Once we have the object we search for the “message” name-value pair and retrieve its String content.

package jtest;
import java.util.Json;
public class Main {
    public static void main(String[] args) throws Exception {
        // Obtain Json Object from a file
        Json jdb = new Json(new File("inforesponse.json"));
        // Fetch String content
        String msg = jdb.getString("Message");
bruce_dev /> jtest

bruce_dev />

In this JSON object we know that the MacroList is an array of Strings. So it is a simple matter to itemize or list them.

package jtest;
import java.util.Json;
public class Main {
    public static void main(String[] args) throws Exception {
        // Obtain Json Object from a file
        Json jdb = new Json(new File("inforesponse.json"));
        // List the macros
        String[] macros = (String[]) jdb.get("MacroList");
        for (int n = 0; n < macros.length; n++)
bruce_dev /> jtest

bruce_dev /> jtest
Preshow Start
Preshow End
Flat Start Trailers
Scope Start Trailers
Feature Start
Feature Credits
Feature End
Start Intermission
Stop Intermission
Extend Intermission 15 Seconds
Shorten Intermission 15 Seconds
Intermission End
Fire Alarm
Fire Alarm Clear
Lights Dim
Lights Half
Lights Full
ticket sold
no ticket sold
LED Green
Core Command 1
Core Command 2

bruce_dev />

But if we didn’t know it was an array could we figure it out?

package jtest;
import java.util.Json;
public class Main {
    public static void main(String[] args) throws Exception {
        // Obtain Json Object from a file
        Json jdb = new Json(new File("inforesponse.json"));
        // List the macros
        Object obj = jdb.get("MacroList");
        if (obj instanceof Object[]) {
            System.out.println("MacroList is an array.");
            // first few entries
            for (int n = 0; n < ((Object[]) obj).length && n < 4; n++)
                System.out.println( " " + (n + 1) + ". " + ((Object[]) obj)[n] );
bruce_dev /> jtest
MacroList is an array.
 1. Preshow Start
 2. Preshow End
 3. Flat Start Trailers
 4. Scope Start Trailers

bruce_dev />

It just seems that I can make this a little cleaner. You know, like by providing an isArray() method or something along those lines.

When you are confronted with some JSON and you don’t have an official schema how do you know what is there? The get() methods require that you supply the name (or key) for an object but you might not know what name:value pairs are present. You can enumerate the structure.

Every JSON object encloses 0 or more name:value or string:value pairs in curly braces {}.

The following can enumerate the keys which are guaranteed to be strings identifying each name:value pair. Let’s work now with the MANIFEST database file to decipher its structure.

    public static void main(String[] args) throws Exception {
        // Obtain Json Object from a file
        Json jdb = new Json(new File("manifest.json"));
        // List top level enties
        Enumeration e = jdb.keys();
        while (e.hasMoreElements()) 
bruce_dev /> jtest

bruce_dev />

We can expand this to show the values associated with these keys. Note that we generically fetch the value Object and explicitly convert it to a string for display.

    public static void main(String[] args) throws Exception {
        // Obtain Json Object from a file
        Json jdb = new Json(new File("manifest.json"));
        // List top level enties
        Enumeration e = jdb.keys();
        while (e.hasMoreElements()) {
            String name = (String) e.nextElement();
            System.out.printf("%s = %s\n", name, jdb.get(name).toString());
bruce_dev /> jtest
model = 410
serno = 614070500
vers = v1.6.3-rc4
date = 12/01/17 13:04:04
files = {"/etc/janosclasses.jar":{"length":243492,"date":1512145376,"md5":"ece8d0ebf9b6882e488d1f7c9e764ce0","crc":"bde463c8","sha":"373b88f011b49f65eafd8e293fc185cc2563892e"},"/flash/serialcontrol.jar":{"length":31344,"date":1450364184,"md5":"b349e02b7efc64c0dfe5eb74292a5ee6","crc":"3a005104"},"/flash/serialethernet.jar":{"length":25266,"date":1433505362,"md5":"ee5e266bb8418b4223a666bd046a8c56","crc":"c3961df2"},"/flash/modbusserver.jar":{"length":51907,"date":1502219129,"md5":"77c16d6134dbd7ec93313fbad2b00d93","crc":"b7456b42","sha":"fad4ecc3d1607aafe0a385a10fb5ee90eff521bd"},"/flash/snmp.jar":{"length":239949,"date":1493062048,"md5":"b77d35c322ef6645f1eca9d22b29400b","crc":"a4073dcb","sha":"44a3c2b41a2375ef603063cc9b04642903dad973"},"/flash/www/base64.js":{"length":3493,"date":1433505378,"md5":"1138db1b5a6e165beae3ed81739dd2ec","crc":"baceb6f6"},"/flash/www/configure/index.html":{"length":1349,"date":1433505382,"md5":"0454014aecfd0b7d9e4ce1efe0979139","crc":"11ba5486"},"/flash/www/jr310applet.jar":{"length":287159,"date":1441207703,"md5":"f9c4840e7244824b75858a1a40dfb163","crc":"3d1d0c72"},"/flash/www/jniorprotocol.jar":{"length":115148,"date":1441207710,"md5":"404b40c4293bf3c334e3b88e2fe0dd10","crc":"5143ec4f"},"/flash/www/jniorprotocolhelpers.jar":{"length":34991,"date":1433505394,"md5":"b08e33e0c21e6c075b9b242bf092b68e","crc":"48990308"},"/flash/www/task/index.html":{"length":1415,"date":1433505397,"md5":"bbdc32dce371881b3eebd15f5b3fce96","crc":"cdbe02e4"},"/flash/www/taskmanagerinterface.jar":{"length":123052,"date":1433505400,"md5":"077cddccee476fab552d52a5eefd26a7","crc":"647bb4b3"},"/flash/www/jquery/jquery-1.9.0.min.js":{"length":93071,"date":1433505404,"md5":"2b869ea9c8edd4c2243c5d44f665f632","crc":"6a2a8434"},"/flash/www/jquery/jquery-ui.css":{"length":33441,"date":1433505405,"md5":"c6bd2971b8e625f2ae43ede9f655a27b","crc":"0497b7a6"},"/flash/www/jquery/jquery-ui.min.js":{"length":96395,"date":1433505409,"md5":"8f636d4c90ea0abfcbb25528c635bf7d","crc":"820662f5"},"/flash/www/vendor/bowser/bowser_0.7.2.min.js":{"length":3359,"date":1433505412,"md5":"61a36d48aad1298b17284b53f6ce3fd1","crc":"22deb9e6"},"/flash/www/text":{"length":1336,"date":1434044220,"md5":"bab65804218b18b9e1a79f2d8e873259","crc":"dda17d61"},"/flash/www/cycle":{"length":419,"date":1434044214,"md5":"9eb9bbdae70c1f994ebb7f51b18783b8","crc":"9e496eb9"},"/flash/slaveservice.jar":{"length":73323,"date":1465435094,"md5":"cd6f5e177d75675607e9523d52e133f7","crc":"9a871cd7"},"/flash/ftp.jar":{"length":9563,"date":1475783634,"md5":"793e460054f07867685e87f98fd402e6","crc":"36fd641e"},"/flash/task.ini":{"length":4311,"date":1433782061,"md5":"b1f877ac198306b266311eab557ed1dd","crc":"36a57579"},"/flash/task.jar":{"length":102655,"date":1434645611,"md5":"1979b16970127f2c38912777cb105133","crc":"ed4d6ad7"},"/flash/jnior.ini":{"length":4874,"date":1512052838,"md5":"90740fe1ddcf0ddf0774c2574e234dfe","crc":"c78e61d7","sha":"76aa475db28479a22e748e6181cf11423988c266"},"/jniorsys.log":{"length":32844,"date":1512145587,"md5":"be4968cceb2fe0b2bebf50daac17d739","crc":"637fb821","sha":"2b6b56f5e3a731b933cf6e1594dfe1e003674d6b"},"/jniorboot.log.bak":{"length":1041,"date":1512074628,"md5":"8261c4f9cd12695626755ba6d1b0b9ad","crc":"03e23ea1","sha":"761a2b3fa74a921778d1c6fc438b5bfd0d51bc29"},"/jniorboot.log":{"length":995,"date":1512145452,"md5":"f053bbba44bea8f6333702fef922d950","crc":"fa976c1c","sha":"c2665669c49028a549a2e30e10b27e8f2aba5861"},"/flash/benchmark.jar":{"length":24351,"date":1464873509,"md5":"987f4044786771f31e0656cf91ed73f3","crc":"1eed095a"},"/flash/threadtest.jar":{"length":3601,"date":1434645124,"md5":"902ce61cbd2524ca9b83dea335c395d3","crc":"cd2479ff"},"/flash/test4to20.jar":{"length":3862,"date":1434659455,"md5":"a2e309c9d6dd112e5303aa76d2470740","crc":"976f8208"},"/flash/dirs.bat":{"length":87,"date":1435691869,"md5":"531d655733ee668d829f9b3bdad96038","crc":"6a11f77a"},"/flash/www/console/index.php":{"length":4347,"date":1438974987,"md5":"8728680bbc36d369429f7ca2c73cce7d","crc":"c939c423"},"/flash/clean.bat":{"length":56,"date":1436532855,"md5":"ac9ce6553e1629412fb426b342440493","crc":"3b661614"},"/flash/jnior1024.key":{"length":887,"date":1437746752,"md5":"b76b5351a92fdcc8d9b6b38ca62d8d71","crc":"7983e14c"},"/flash/www/config/md5.js":{"length":5693,"date":1433505379,"md5":"a60fec5a81f207ff99ec1b97e3ccad0e","crc":"e2a43d16"},"/flash/www/config/node.png":{"length":253,"date":1440435886,"md5":"1a8dbfaf1771a06e48dea0e3dc604392","crc":"799c6dfc"},"/flash/www/config/tabs-styles.css":{"length":970,"date":1477590404,"md5":"68bca7015f51e26ab42199b5eb17a356","crc":"f8870a33"},"/flash/www/config/tabs.js":{"length":3662,"date":1449678641,"md5":"ff728c86018341548ee70028062c89e0","crc":"1a813112"},"/flash/www/config/styles.css":{"length":4450,"date":1504814044,"md5":"9ad78cca1b794dbcf9db3c55f1be5f1b","crc":"acbd2e14","sha":"3cf0bbc864840994a49f62d0ae00df6d8eb47ef3"},"/flash/www/config/comm.js":{"length":3541,"date":1507912287,"md5":"e7d2e56a443176d6150bbcc8b56e1911","crc":"0ac0ed26","sha":"5e66b96227779c5ef3736a7ca891a43cacffbbf1"},"/flash/www/config/console.js":{"length":5137,"date":1504815652,"md5":"33289e4b09f462efdb50e8d30d22d791","crc":"b89fe380","sha":"c2f3ea4fc0344d43b0c30b7f60b2b6c79c1f4817"},"/flash/www/config/config.js":{"length":12639,"date":1507912576,"md5":"75bf22a88d8a23b17de267607b88a14c","crc":"d693e2f4","sha":"cf9e9bcf7cc7d79ae648b241af16ee194199d7b3"},"/flash/www/config/index.php":{"length":22103,"date":1510262716,"md5":"6fe98e5238c5834d55b0140a7172fec6","crc":"81f11698","sha":"b5b440d43bb19da0396e8ab615161be9200e6180"},"/flash/www/jnior.ico":{"length":3262,"date":1439548680,"md5":"1c3b3dda6b10c6259fcf7c068b760f09","crc":"051803eb"},"/flash/www/favicon.ico":{"length":156790,"date":1486410493,"md5":"07cb90c7f3573eff80222269625ed1dd","crc":"7e367afa","sha":"284add71fe3d3ba48fba059b88ff5143d3964b1d"},"/flash/analogpresets.jar":{"length":163902,"date":1441372806,"md5":"25eacc647412535e320302d3680ce327","crc":"e6b656fc"},"/flash/www/config/config.css.php":{"length":1045,"date":1475072901,"md5":"1692861e9abd7f8d81f5b7cf8a176046","crc":"4c386a21"},"/flash/www/config/inputs.png":{"length":18047,"date":1443116143,"md5":"e2151c93b6cdeaa154d15fab486ae61b","crc":"16290877"},"/flash/www/config/loading.gif":{"length":3236,"date":1264096270,"md5":"d96f6517e00399c37a9765e045eaaf22","crc":"16f442ed"},"/flash/jtest.jar":{"length":1832,"date":1511984925,"md5":"89f28d11945790915112f0a4880b6adc","crc":"cf00edbe","sha":"df53eab9f4eb1360c7ab48f30298ce7c48b0e440"},"/flash/www/vendor/angular_1.3.15/angular.min.js":{"length":125909,"date":1449498838,"md5":"ca1a58818682c3e858a585f283ab9beb","crc":"9d8147d7"},"/flash/www/vendor/bootstrap_3.3.0/css/bootstrap-theme.css":{"length":21740,"date":1449498835,"md5":"c64043a3388612233d7eb947918a9bfc","crc":"638f58a3"},"/flash/www/vendor/bootstrap_3.3.0/css/":{"length":41933,"date":1449498838,"md5":"c5da8241305bfe7e19919e6e943739eb","crc":"11260772"},"/flash/www/vendor/bootstrap_3.3.0/css/bootstrap-theme.min.css":{"length":19199,"date":1449498840,"md5":"374df0ad5809a5314b0577802430a272","crc":"8b3c47b7"},"/flash/www/vendor/bootstrap_3.3.0/css/bootstrap.css":{"length":137590,"date":1449498845,"md5":"ad6381ebfa541b55b0152349c6cabf76","crc":"371e67da"},"/flash/www/vendor/bootstrap_3.3.0/css/":{"length":366866,"date":1449498854,"md5":"4ba278e0c420d166e5a0eb71545f9509","crc":"b7c9868d"},"/flash/www/vendor/bootstrap_3.3.0/css/bootstrap.min.css":{"length":114011,"date":1449498852,"md5":"78e7f91c0c4cca415e0683626aa23925","crc":"34387388"},"/flash/www/vendor/bootstrap_3.3.0/fonts/glyphicons-halflings-regular.eot":{"length":20335,"date":1449498855,"md5":"7ad17c6085dee9a33787bac28fb23d46","crc":"f171b590"},"/flash/www/vendor/bootstrap_3.3.0/fonts/glyphicons-halflings-regular.svg":{"length":62926,"date":1449498857,"md5":"ff423a4251cf2986555523dfe315c42b","crc":"385cd4ad"},"/flash/www/vendor/bootstrap_3.3.0/fonts/glyphicons-halflings-regular.ttf":{"length":41280,"date":1449498858,"md5":"e49d52e74b7689a0727def99da31f3eb","crc":"0617f1ff"},"/flash/www/vendor/bootstrap_3.3.0/fonts/glyphicons-halflings-regular.woff":{"length":23320,"date":1449498858,"md5":"68ed1dac06bf0409c18ae7bc62889170","crc":"cec1a35c"},"/flash/www/vendor/bootstrap_3.3.0/js/bootstrap.min.js":{"length":34653,"date":1449498862,"md5":"281cd50dd9f58c5550620fc148a7bc39","crc":"32d6c689"},"/flash/www/vendor/bootstrap_3.3.0/js/bootstrap.js":{"length":65813,"date":1449498862,"md5":"d5a03d9cca57637f008124916b86b585","crc":"f504a7b3"},"/flash/www/vendor/bootstrap_3.3.0/js/npm.js":{"length":484,"date":1449498863,"md5":"ccb7f3909e30b1eb8f65a24393c6e12b","crc":"cc50e34d"},"/flash/www/vendor/jquery_1.11.1/":{"length":141680,"date":1449498870,"md5":"ffbeb16578d8cdf58104889baacbbef2","crc":"e4e92bfd"},"/flash/www/vendor/jquery_1.11.1/jquery-1.11.1.min.js":{"length":95786,"date":1449498869,"md5":"8101d596b2b8fa35fe3a634ea342d7c3","crc":"804ff984"},"/flash/www/config/integlogo.png":{"length":5773,"date":1449163436,"md5":"9111308273dadea73f5d09a5e02c7311","crc":"60c4e184"},"/flash/utility.jar":{"length":106794,"date":1449773066,"md5":"ac559b91b537dfa70720a416f32f2960","crc":"888936f1"},"/flash/generators/json/colour.js":{"length":4327,"date":1449774238,"md5":"c67e10d0e0e698fcdbbbadcaa55600d4","crc":"19e8a38f"},"/flash/generators/json/ethernet.js":{"length":1409,"date":1449774238,"md5":"1b6bae08feb93f6bd345a3780c3acb69","crc":"848097a7"},"/flash/generators/json/inputs.js":{"length":2825,"date":1449774239,"md5":"6959db5a769ff3ceea45bf606bda940a","crc":"c544d780"},"/flash/generators/json/lists.js":{"length":12006,"date":1449774239,"md5":"5cc489ac77db7a3369b2ffc30cbd3a86","crc":"ba761254"},"/flash/generators/json/logic.js":{"length":4404,"date":1449774239,"md5":"9cd1cf854976ebb69a6c20a7ac88d2f9","crc":"6c2189f9"},"/flash/generators/json/loops.js":{"length":6040,"date":1449774239,"md5":"e8e9021b5d4eb2e0cc43f11ad5b3bfd7","crc":"b30a758a"},"/flash/generators/json/math.js":{"length":14673,"date":1449774240,"md5":"fa22c29efc362e02d8f35838fcca46e5","crc":"8fc62e67"},"/flash/generators/json/other.js":{"length":983,"date":1449774240,"md5":"dd77f555bc9b50ed17a215d7935f10ab","crc":"3e07810d"},"/flash/generators/json/outputs.js":{"length":3861,"date":1449774240,"md5":"72a118cd7829b5a510e5a901d8863d6e","crc":"bdd5e320"},"/flash/generators/json/procedures.js":{"length":3945,"date":1449774240,"md5":"cb9fb880bebb3375273353fafc12dc9c","crc":"20d43aad"},"/flash/generators/json/text.js":{"length":1363,"date":1449774241,"md5":"a0bd39f638202a0800c100b4eac3cbc3","crc":"b17b24d6"},"/flash/generators/json/timing.js":{"length":2638,"date":1449774241,"md5":"b1ee803dd8e6e00de74e0a3269f0a2ff","crc":"489061b8"},"/flash/generators/json/variables.js":{"length":1500,"date":1449774241,"md5":"fecce79a400d5e4e1edbe521699fa604","crc":"cb724c91"},"/flash/generators/json.js":{"length":4115,"date":1449774238,"md5":"cc72f2468eb970110f3f6f0278f43467","crc":"25a98f30"},"/flash/www/config/link_to.png":{"length":259,"date":1450466976,"md5":"b1ed68183be4f97ce1793139496dbbb4","crc":"a067876a"},"/flash/www/config/collapsed.png":{"length":232,"date":1452087215,"md5":"ef7dd392142824ec54b7b7188717411c","crc":"c7bd8428"},"/flash/www/config/linked.png":{"length":174,"date":1452088114,"md5":"56d2755d08a0857ff6e7750c4b2822dd","crc":"ff59187e"},"/flash/www/config/expanded.png":{"length":238,"date":1452097812,"md5":"905b26e96849524dd6c37e1878f66779","crc":"68686921"},"/flash/www/config/registry.js":{"length":8276,"date":1452271284,"md5":"fc35855793b2bbfe577e420f34cb0dda","crc":"6c73e25a"},"/flash/www/config/deletex.png":{"length":240,"date":1452284181,"md5":"2750f1e60d0222d7f3c0752207fb41e7","crc":"386b823b"},"/flash/www/config/modules.js":{"length":13520,"date":1484149578,"md5":"5d79964a8ca70cc7dc0504c343be3e3c","crc":"3c09b9e2","sha":"d6f0b3ec60796662acd105694ef39543e3dc50a2"},"/flash/www/logging.php":{"length":4853,"date":1463582298,"md5":"170c17bd0962f434eebe699129491912","crc":"dce15f4e"},"/flash/www/":{"length":113815,"date":1465493787,"md5":"b3e85080154b5a7dc10078a6c6fe75c7","crc":"975c987e"},"/flash/0-10vtest.jar":{"length":5053,"date":1438104444,"md5":"3a7be82077e29c598bdd8694d47805f4","crc":"05e27897"},"/flash/4routtest.jar":{"length":2993,"date":1373644405,"md5":"14381605ec8f2f0d0dbe34843b7178b8","crc":"8240fc03"},"/flash/environ.jar":{"length":3881,"date":1476102546,"md5":"8d738f0145516d287174a00dda32dabc","crc":"ff1ecc8b"},"/flash/current.key":{"length":898,"date":1455116261,"md5":"035a0d79bd6c8258c12111479fe7353e","crc":"cbdd8ffe"},"/flash/serialtest.jar":{"length":4532,"date":1457448880,"md5":"48fc4bd9421a5cf275b42235d2f4e2cb","crc":"6d86943b"},"/flash/intellij.jar":{"length":969,"date":1464918560,"md5":"aea445862e32190fa61abc5d97e5b25f","crc":"959a1596"},"/flash/jmodule.jar":{"length":5580,"date":1465240063,"md5":"af7d42f427d0e711c4a79c8e1c1d341d","crc":"40058988"},"/flash/udptest.jar":{"length":5811,"date":1465328251,"md5":"5bbc399b4eb1f5ec427ccbf93c8b135d","crc":"3d976325"},"/flash/buffer.jar":{"length":95325,"date":1467321013,"md5":"0c66b2a130de483b64b91d87471eb952","crc":"5d0819e2"},"/flash/display.jar":{"length":2992,"date":1468953410,"md5":"efcfc78470e98842f52579c81c088a2d","crc":"5ec67fd0"},"/flash/rz.jar":{"length":13079,"date":1469638127,"md5":"c4b7e9f4072d64e3dde9fe5a62406a1e","crc":"20367148"},"/flash/www/config/folder.png":{"length":329,"date":1454662486,"md5":"316b7810fa502618b4e85788a82617a8","crc":"55f20187"},"/flash/www/config/file.png":{"length":286,"date":1454662486,"md5":"1b75c23448e9c6eed675404f6130491d","crc":"d327c449"},"/flash/www/config/warning.png":{"length":3068,"date":1332275646,"md5":"9c96d831cfc50fdedfdc980bc2abb2cf","crc":"e90bb05a"},"/flash/www/config/folders.js":{"length":19270,"date":1504815735,"md5":"c7a59ef1aea3aad95d3315627d3a3b29","crc":"6b1adf25","sha":"93d7e851c9a1a65ed45b7c1bbe4368d3d941b32f"},"/flash/clktest.jar":{"length":2616,"date":1470249535,"md5":"345b4a9a22ec05bc89bb291b7b047e0e","crc":"270f1d8b"},"/flash/timesearch.jar":{"length":4180,"date":1471371624,"md5":"bf719e65d8f4be9d7348a621ac69bc2b","crc":"25075aa7"},"/flash/janosruntime_1.5.1.jar":{"length":1621696,"date":1472744987,"md5":"b8beb71b94b36129534ef4d6ec13f5ab","crc":"abc7b327"},"/flash/www/config/relays.js":{"length":4189,"date":1484587793,"md5":"803af5c2431b8f58c110260b3f317838","crc":"ee9ab3af","sha":"21ec766fe220bd0618b43050851f9cd67dd1bf54"},"/flash/www/config/temperature.js":{"length":2870,"date":1475245816,"md5":"262c339513007cd746ee01da9a4a843f","crc":"d062a444"},"/flash/www/config/dimmer.js":{"length":8255,"date":1475265861,"md5":"e7213c6fb8c263ac71acb766e62dc4ce","crc":"b9edf051"},"/flash/www/config/range.css":{"length":2212,"date":1475499110,"md5":"6932c76ab79879ea4c5d826d9cb60db9","crc":"3334dfd1"},"/flash/www/config/analog.js":{"length":7267,"date":1484587793,"md5":"87abcaf68dea5e2e203326a55bc2bca5","crc":"9766b532","sha":"dd788111904d41826164ea151f78dd4b3e3b84e6"},"/flash/www/config/ledon.png":{"length":626,"date":1475506220,"md5":"6018d69896fcba49da54c39d8ee19803","crc":"32a65f15"},"/flash/www/config/panel.js":{"length":2038,"date":1475509052,"md5":"e0631cb06777f63f0a071f7aa5d198d0","crc":"a38a7db3"},"/flash/www/config/ledoff.png":{"length":757,"date":1475509575,"md5":"4bb71e412a20ae6f098a29b195b10e13","crc":"3fd16f7a"},"/flash/jpanel.jar":{"length":3142,"date":1358430294,"md5":"39825ccddf7b61c1ad41d261d84f4950","crc":"446bee7f"},"/flash/www/config/syslog.js":{"length":1929,"date":1496773328,"md5":"4e8ecca50284c2aeae8e8b90db27ded8","crc":"ac2a2541","sha":"e413d70cc2bb6717448bc84c2980abc764bc3dd6"},"/flash/www/config/peers.js":{"length":5885,"date":1505835290,"md5":"2536fc521f916341b98183f6ce0b2453","crc":"f2a44392","sha":"5d949b8daa8e5081f19c88e42af968b24955e02c"},"/flash/www/index.php":{"length":356,"date":1477657721,"md5":"3ba20cf61f44f9ace09104261acf2711","crc":"7f8eaed3"},"/flash/www/":{"length":85751,"date":1477663620,"md5":"296baa71d70bf40c1ad6ee0c71066c49","crc":"69922bd1"},"/flash/www/download1.php":{"length":465,"date":1480616431,"md5":"1f69c84031dbdbe9aeecd634c0ab9607","sha":"9770a8f6534f17f86eeb332309b7cbe07441022e","crc":"c7b59619"},"/flash/www/short.php":{"length":273,"date":1481120537,"md5":"2fb318c42bd07c0ec34551502bc20c73","sha":"9b9831ca6abda2a14a922e058430fe114b8b34e0","crc":"fbca8ae2"},"/flash/ctrlc.jar":{"length":1510,"date":1482421756,"md5":"b7ce2da5b761674e626ae62c4b9edbcc","sha":"51a17a3f092333a0a48aa8e6dcebe0ce99cef3de","crc":"bd2a0810"},"/flash/":{"length":87642,"date":1510262835,"md5":"b2cb6f23c2fc91d8f5d79a6e62c5ee10","sha":"a24717087011d3b87b1135ad27556c2337598d98","crc":"df0db0a9"},"/flash/www/config/favicon.ico":{"length":766,"date":1486410493,"md5":"07cb90c7f3573eff80222269625ed1dd","sha":"284add71fe3d3ba48fba059b88ff5143d3964b1d","crc":"7e367afa"},"/flash/www/map.html":{"length":1170,"date":1485380108,"md5":"901c9971c3c591b3d736cd91516960de","sha":"5ded94156ca71884af1afae0fcaf1e78d3bac23d","crc":"71f8c837"},"/flash/jmanifest.jar":{"length":5651,"date":1485192866,"md5":"dfb84226c647a42295d9f671cfb99fa5","sha":"a7331cca377c1f96e400ddd5044c01a175ee230f","crc":"1a64c6d6"},"/flash/jping.jar":{"length":2174,"date":1485201152,"md5":"0d533008847888e0dfcf497c0cff1a96","sha":"75fbff5a973b8dac3408fdda46e47e708b585e58","crc":"f1203f43"},"/flash/jaccess.jar":{"length":4820,"date":1485805203,"md5":"29ce866873686dd133a724e4db29c690","sha":"239bf75c1597a25fdbbbb78798fe72971ca15f63","crc":"e5ae0d1c"},"/flash/somepath/path2/testx.php":{"length":5282,"date":1486397961,"md5":"ce1a071b258c936c65679d6bb67db198","sha":"30342828ebaeb69cd8ecefd75f2dd01e80c6388b","crc":"ecd9251a"},"/flash/bruce_dev.cer":{"length":902,"date":1487172768,"md5":"e9917f27384ddee36817c04c8cde9199","sha":"4b2b82a042a0019679c1b071956278f6ddd1f27b","crc":"115ed2ae"},"/flash/www/config/registrydoc.css":{"length":21460,"date":1504201641,"md5":"15423ca727b03e6b1581910c6ca2eab5","sha":"f521b53a4518e7490768d2a8ae0e707c1dfb943b","crc":"0d5fd8c9"},"/flash/www/config/registrydoc.html":{"length":169108,"date":1509114127,"md5":"e30fe001dfab22c848d1d440f79c96db","sha":"a6edec26f5cbfd249e9f1b3947e92a4766d3bacb","crc":"25c25ccc"},"/flash/www/panel/comm.js":{"length":4715,"date":1498074333,"md5":"44aa80868230fbfeee0a3c48c390896d","sha":"37b479f65e7e8221d6fd9349439a8193cc645ba7","crc":"0d5e92bd"},"/flash/www/panel/index.php":{"length":2648,"date":1501526934,"md5":"923ce6739971521191f9000662f38323","sha":"a35d1d5f24da487be376595b46598e162e0f5310","crc":"ffd86d7b"},"/flash/www/panel/panel.js":{"length":993,"date":1501527049,"md5":"9d9a2cbb435ffe8af5bd9d8c0598dccd","sha":"2ef881dc8d90b4b0fb80a59d717c7125ca23fb04","crc":"4fcd0f37"},"/flash/www/panel/panel.css":{"length":2586,"date":1501527291,"md5":"2a3a66d14d7bc6d4b01dfbd745205c7d","sha":"886770297a07a594b88430d5db4ae9e23738d118","crc":"2dd8a81d"},"/flash/www/":{"length":556637,"date":1506536442,"md5":"891b1dfa8d774b85aefcbd8791abe11f","sha":"e5d204333658bd5c2f7c5b5ff682911124a10766","crc":"62d153fb"},"/flash/public/":{"length":181914,"date":1504795829,"md5":"655e8587293f35f11c5c24fc38201d2f","sha":"5fcfd8e38826e648f98f8d50f3613deb0d6312b6","crc":"da99b7d0"},"/flash/test.txt":{"length":304,"date":1495131459,"md5":"fc9f1f5e67928ccb9be3aeaa66cd9e52","sha":"6100d999f484f98ab476408c801dd000e579a62c","crc":"765047c5"},"/flash/dmx.jar":{"length":4476,"date":1500567859,"md5":"3fd35bbe6bbf53a32aecf273275d1839","sha":"4f702a87adb060294b553e6bd212672727d5d25f","crc":"e81db9aa"},"/flash/juptime.jar":{"length":3201,"date":1506713589,"md5":"d4c2482fae18482727c1b2afabcf94b4","sha":"86268b720b99760a4ebdb803db53f3f7fd18fd18","crc":"44b0878c"},"/flash/jscan.jar":{"length":2189,"date":1507141493,"md5":"a0a42e17f003cedcac9c8e662ada6b36","sha":"f1cafb56fdae33b66fff9b20cd2ff2705d96da9e","crc":"60f00fe2"},"/access.log":{"length":177,"date":1510081848,"md5":"914113dd52c4e74d2675eb1094ba10c6","sha":"0212252f4f04ab136ce74ab0425cd7fce26b7c47","crc":"e9a7f8d8"},"/auxio.log":{"length":1589,"date":1511288557,"md5":"a52713575d5c449ff8e8cdbeb7e10ba6","sha":"22106e83ff429cc08fe16f21dc32623850f5673c","crc":"a29ad191"},"/jniorio.log":{"length":3332,"date":1511289076,"md5":"d3c685fde34b343f2ba53dd60e4bf11d","sha":"dd001970b69d61ab619745853addaf2910aabb31","crc":"1bbc78de"},"/flash/hmi.jar":{"length":8329,"date":1511283865,"md5":"1a1b247ccb5e3eb9623d12578c1ba833","sha":"7a1f5868817e8a3e60fe8fb2c4d9ed168e53d141","crc":"fb2a0367"},"/flash/ckeypad.jar":{"length":11194,"date":1512145569,"md5":"71288ea4ffa40e936dbecfd010fff785","sha":"23f944b627705716697ece761c6c95f8c1f873bb","crc":"3d9fc092"}}

bruce_dev />

So beyond identification header information such as model, serial number, JANOS version and timestamp the last entry files appears to be another JSON Object, That seems to be the database content.

In manifest.json the files element is another JSON Object. So let’s load that and enumerate the keys it contains.

    public static void main(String[] args) throws Exception {
        // Obtain Json Object from a file
        Json j = new Json(new File("manifest.json"));
        Json jdb = (Json) j.get("files");
        // List top level enties
        Enumeration e = jdb.keys();
        while (e.hasMoreElements()) {
            String name = (String) e.nextElement();


bruce_dev /> jtest

bruce_dev />

So here we see that there is basically an entry for every file on the JNIOR. The files are defined by their absolute path from the root.

Let’s enumerate the content of the first file entry. I’ll just break in the loop to do one.

    public static void main(String[] args) throws Exception {
        // Obtain Json Object from a file
        Json j = new Json(new File("manifest.json"));
        Json jdb = (Json) j.get("files");
        // List top level enties
        Enumeration e = jdb.keys();
        while (e.hasMoreElements()) {
            String name = (String) e.nextElement();
            System.out.printf("%s = %s\n", name, jdb.get(name).toString());
bruce_dev /> jtest
/etc/janosclasses.jar = {"length":243492,"date":1512145376,"md5":"ece8d0ebf9b6882e488d1f7c9e764ce0","crc":"bde463c8","sha":"373b88f011b49f65eafd8e293fc185cc2563892e"}

bruce_dev />

So the file entry is yet another JSON Object/ It looks to contain file information.

Okay. Let’s see what it has to say about the first file.

    public static void main(String[] args) throws Exception {
        // Obtain Json Object from a file
        Json j = new Json(new File("manifest.json"));
        Json jdb = (Json) j.get("files");
        // Get first entry whatever it is and enumerate it
        Enumeration e = jdb.keys();
        while (e.hasMoreElements()) {
            String name = (String) e.nextElement();
            Json jfile = (Json) jdb.get(name);
            Enumeration efile = jfile.keys();
            while (efile.hasMoreElements()) {
                String name2 = (String) efile.nextElement();
                System.out.printf("   %s = %s\n", name2, jfile.get(name2));

We see the file size in bytes, some kind of encoded date, and three difference checksums or digests (MD5, CRC, and SHA). The CRC is CRC32 by teh way and SHA is SHA1.

The date is in Unix format GMT timezone.

So that pretty much is the structure of the MANIFEST database. That is a good example of using the JSON format for database storage.

By the way, the JanosClasses.jar file was just changed. The database has an earlier reference. So the date and checksum don’t match. This is how MANIFEST knows to indicate that the file has been “Modified”.

bruce_dev /> manifest etc
JNIOR Manifest      Tue Dec 05 15:26:12 EST 2017
  Size                  MD5                  File Specification
 265756   f26d0f63dd5cc055dad699f117bb4f17  [Modified] /etc/JanosClasses.jar
End of Manifest (1 files listed)

bruce_dev />

We could update our database with a MANIFEST -U command and examine it again. If we did you would see that the MD5 then matches.


We’ve been experimenting with ride-thru power supplies. Basically the JNIOR continues to run after power is removed even though the unit is not battery powered. The hold time is relatively short and only a matter of seconds depending on the load on the supply at the time. But it is sufficient to weather short power outages and glitches that would otherwise cause the JNIOR to reboot. This ride-thru supply design makes sense for controller applications. It may save you the cost of a UPS if dirty power appears to be your issue. It will debut for INTEG in our 412DMX JNIOR.
One advantage of this is that we know when power has been removed or lost. We also know when it has been restored. That means we can now tell if the JNIOR has been left powered off and then booted up by looking at the log. With product without this technology you cannot tell from the log if there was a spontaneous reboot or what may have occurred.
This 412DMX prototype (the first) had been off for a couple of days and, well, it can’t hide that fact.

We see now that the unit was powered down for roughly 74 hours. When NTP re-synchronized the clock it had gotten 2.87 seconds fast. That is an error of about 1%. It goes to the importance of clock synchronization through NTP. If your JNIOR does not have access to the Internet and the host of NTP servers out there, maybe there is one on your internal network. If not perhaps there is another approach you can use to keep accurate time.
It is surprising that in this day and age that clocks in our computers are not much more precise. Some devices now get accurate time through the GPS system. Others over the cellular networks. Nether are generally available to a JNIOR. Don’t ask me about the RTC in the Renesas RX63N. I’ll go off on a rant!
So here is what you would see for a brief power outage. In this case the JNIOR never skipped a beat. There was no reboot and the DCP never had to reconnect.

Here power was out for some 7 to 8 seconds (I yanked the plug). Subsequently the ride-thru supply recharged itself so it would be ready to do it all over again.
Okay, not so impressive given that we are spoiled by all of our battery devices like phones, tablets and laptops. But there isn’t the cost of the battery nor the risk of fire. And, given that the JNIOR controller is generally powered 24/7 that extra hardware isn’t justified. But it does piss you of when the power company decides to reboot all of your unprotected equipment when the reconfigure the Grid. This handles that.
By the way, this R00 prototype has a 5F capacitor in which it stores the holding energy. The R01 prototype has 10F and that is likely what we will be shipping. You can see here using the STATS command that the average hold time for the 5F unit is about 12.5 seconds (no real load). The 10F units pushes 20 seconds.

Applications receive command line arguments just as any standard Java program would. You can use these to establish new default configuration settings. For example we are developing a UI for our Cinema application. The UI application (called “Cinekey” right now) when run makes a TCP/IP connection to a host running the Cinema application. By default localhost is used and the default port is 9610.

The command line syntax is:

cineky [Ip_address [port]]

You can even include these parameters in a Run key. If the optional host Ip_address is specified it will be recorded as the new default. If you specify the host you can also optionally specify the port. That will also be save as default. That means that if you do that once then you can just use the program name from that point forward to run it and it will use the last specified socket default.

Here is the code for that. You can see how it can be adapted perhaps to your configuration needs.

    public static void main(String[] args) throws Throwable {
        String host = "";
        int port;
        // obtain port
        if (args.length > 1) {
            port = Integer.parseInt(args[1]);
            JANOS.setRegistryString("Cinekey/Port", Integer.toString(port));
            port = JANOS.getRegistryInt("Cinekey/Port", 9610);
        // Obtain host
        if (args.length > 0) {
            host = args[0];
            JANOS.setRegistryString("Cinekey/Host", host);
            host = JANOS.getRegistryString("Cinekey/Host", "localhost");
        // Establish connection
        conn = new CineConnect(host, port);
        new Thread(conn).start();

While JANOS strives to create a secure environment we generally fall short in that arena when it comes to applications. An application can listen for connections and process its own custom protocol. That is not so complicated to do but it is another big step to insure some level of security. We hardly ever get that done.

If the custom protocol first requires a username and password, you can use the method that JANOS provides User.validate() to validate the login. The issue here is that the username and password are transferred in the clear unless the protocol requires a secure SSL/TLS connection.

When an application implements the client side of a connection there is the User.digestMD5() method that can be used in combination with a NONCE to transfer credentials securely. Unfortunately we don’t have method available to validate digest encoded credentials on the server side.

By the way, I think it is better to transfer the username and password in the clear than to not implement authentication at all. Note also that the vast majority of our applications run on a physically secure network.

Still we can certainly ramp this up a level.

Also, applications run with Administrator privileges and merely authenticate the supplied username and password. The supplied account then does not limit the application. So you can define a guest level account solely for authenticating access. If those credentials are then compromised perhaps by being transferred in the clear they are really not a security issue otherwise. In other words, you shouldn’t use an administrator account to log into these application protocols. In addition, an application protocol shouldn’t implement capabilities that compromise the security of the JNIOR by allowing configuration changes.

We’ve been using a “nonce” string to encrypt credentials for transfer over clear text channels. The approach was first employed as an option in the JNIOR Protocol. It works like this.

Nonce String

The “nonce string” is any string of random (usually printable) characters. It is generated by the server and supplied to the client either upon request or as part of an announcement on connection. The nonce can only be used once to authenticate a set of credentials. It should only be valid for a brief period of time, usually 1 or 2 minutes.

The Hash

The client uses an MD5 message digest function to obtain a hash from a combination of username, password and nonce. Our procedure combines the username followed by the nonce followed by the password each separated by a colon ‘:’. Therefore:

hash = MD5( username + ":" + nonce + ":" + password )

The hash produced here is a 16 byte binary array. It is converted to a 32 character hexadecimal (case-insensitive) representation before it is used.

Encoded Credentials

The credentials are then supplied with the username in plain text as follows:

encoded_credentials = username + ":" + hash_hexadecimal

The encoded credentials string is supplied to the server for authentication. The server takes the username from the string and looks up the password for the account. It then uses the nonce it supplied to calculate the digest as defined above. If the calculated digest matches that sent by the client the login is valid.

Since it is practicably impossible to reverse the hash to determine the password for the account this limits risk when transmitted in the clear. It does not matter if the attacker knows the nonce. It is imperative that the nonce be single use and if possible only valid for the one socket connection. This is to prevent a replay attack where the encoded credentials are repeated by the attacker to gain access.

An issue with the above is that applications do not have access to user account passwords in clear text in order to calculate the digest. JANOS needs to provide some assistance here. A validation method is needed.

So it can be done. The following takes encoded credentials as if they were from a client to which we had supplied the random nonce. We then process the authentication without access to the password for the user.

package jtest;
import com.integpg.system.ArrayUtils;
import com.integpg.system.User;
import java.util.StringTokenizer;
public class Main {
    public static void main(String[] args) throws Exception {
        // supplied encoded credentials and original nonce
        String creds = "jnior:4f163e3fdaee54babdc0a8aaad7df1c1";
        String nonce = "jhfjh23k4k3489ysf989(*(98a98a9835h2k3";
        // parse credentials
        StringTokenizer tokenizer = new StringTokenizer(creds, ":");
        String username = tokenizer.nextToken();
        String digest = tokenizer.nextToken();
        // obtain binary digest
        byte[] hash = new byte[16];
        for (int n = 0; n < 16; n++)
            hash[n] = (byte)Integer.parseInt(digest.substring(2*n, 2*(n+1)), 16);
        // obtain digest using digestMD5()
        int userid = User.getUserID(username);
        byte[] hash2 = User.digestMD5(userid, username + ":" + nonce + ":", "");
        // compare hashes
        if (ArrayUtils.arrayComp(hash, 0, hash2, 0, hash.length))
            System.out.println("Login successful!");
bruce_dev /> jtest
Login successful!

bruce_dev />

I am sure there are other ways to parse the credentials and to convert the hexadecimal string to a byte[]. JANOS does not implement the String.split() method. You can use Regex.

As an alternative to processing the hexadecimal string you could convert hash2 into the hex string and compare. I am not sure which is faster.

Here’s the split done using Regex.

    // parse credentials
        String[] parts = Pattern.compile(":").split(creds);
        String username = parts[0];
        String digest = parts[1];

I had thought that I had implemented the String.split() method but no. I am probably thinking of the split() function in the PHP scripting.

And here’s another way to convert the hexadecimal digest string into the byte array.

        // obtain binary digest
        byte[] hash = new byte[16];
        for (int n = 0; n < 32; n++)
            hash[n/2] = (byte)(16 * hash[n/2] + Character.digit(digest.charAt(n), 16));

JANOS implements a file permission scheme modeled after Unix file permissions. Those familiar with the Linux recognize the permissions in JANOS file listings.

bruce_dev /> ls -v
total 12
drwxrwxrwx   1 root      root          10 Nov 28 10:23 .
drwxrwxrwx   1 root      root          10 Nov 28 10:23 ..
dr-xr-xr-x   1 root      root           1 Dec 31 1999  etc
drwxr-xr-x   1 root      root          49 Nov 28 10:16 flash
drwxrwxrwx   1 root      root           0 Dec 31 1999  temp
-rw-r--r--   1 root      root       39023 Nov 28 14:50 jniorsys.log
-rw-r--r--   1 root      root        1011 Nov 28 10:23 jniorboot.log
-rw-r--r--   1 root      root        1082 Nov 28 10:16 jniorboot.log.bak
-rw-r--r--   1 jnior     root       20585 Nov 22 11:52 manifest.json
-rw-r--r--   1 jnior     root        3332 Nov 21 13:31 jniorio.log
-rw-r--r--   1 jnior     root        1589 Nov 21 13:22 auxio.log
-rw-r--r--   1 root      root         177 Nov 07 14:10 access.log
  1891.7 KB available

bruce_dev />

There are 3 groups of ‘rwx’ permissions. The first is for the file owner. The second for the group associated with the file. And, the third is for everyone else. This implies some kind of User Groups. Note that on the Series 3 there are no User Groups and so file permissions were somewhat shortened.

JANOS allows you to define a User Group using the GROUPADD command. There is a root group by default to which noone belongs.

The GROUPS command lists the defined user groups and any users associated with each.

bruce_dev /> groups
 root        0    
 techadmin   2    
 techs       1    tech      

bruce_dev />

Back during JANOS development Kevin brought it to my attention how the TAB key was being used on the command line in other systems. Basically it served as an auto-complete function.

The TAB has been implemented in JANOS with some twists. Once you work with a Series 4 at the command line you just can’t handle a Series 3 where you have to type every character.

Where a file path or file name is expected the TAB will cycle through all of the valid names. For example In the following video I will type CAT and space and then hit TAB a few times slowly. When the desired file name appears I can hit ENTER. Let’s see jniorboot.log without typing jniorboot.log.

In the above post Bruce showed us how to use the TAB as an autocomplete for the commands that are available from the command line.

My favorite feature of the TAB autocomplete is filling out file names. In this quick video you will see that there are two files that names that begin with ‘jn’. You will see that i start typing the filename for ‘jniorsys.log’. I use the TAB key to cycle through the file names that start with “jn’.

Another great place that the TAB work is when working with the registry from the command line. “Who does that?” you ask. I do. Yes the registry tab in the DCP is wonderful but for some, yours truly, the command line is faster. Especially when the TAB is utilized!

In this video I want to change the hostname. Yes, there is a hostname command but I want to show how to use the registry from the command line.

You will see that i use ‘reg’ which is the alias for registry. I type ‘i’ then TAB to look through registry keys that start with ‘i’. I select the ‘IpConfig’ folder. Now I use TAB to cycle through the available registry keys. Once i find hostname I type ‘ =” and TAB again to see the value.

Use of the up arrow will enter the previous command and then I edit the key value using backspace and enter my change. Now the hostname is ‘kev-dev’

Take a look

In general the TAB performs context specific auto-complete.

By using TAB repeatedly each valid completion is displayed. If you find the a form of the entry that is appropriate you simply continue to build the command line and hit ENTER to execute. Generally TAB offers matching file and folder names from the current working folder or other folder if specified by preceding content on the command line.

You may begin to type an entry and then use TAB. Only those completions which incorporate the starting characters are shown. So if you wish to filter the possibilities you can enter the first or first couple of characters. Similarly you can enter a path to a folder and completions will be content from that folder.

A TAB used within the first word on a line will auto-complete valid commands and lines from those previously entered. Recently entered command lines are preserved in a history (See HISTORY command) which you can normally access using UP-ARROW and DN-ARROW. The TAB auto complete will include your history. So if you want to execute a MANIFEST command with the same options that you had previously run, you could hit ‘m’ followed by TAB and that complete command line will be one of the completions offered. Completions for the first word on a line will also include normal file entries which may be useful if you want to execute a program.

If the REGISTRY or REG command is being built, TAB instead offers completion options from the set of matching Registry Keys instead of folder content. In this case too the TAB can be used immediately after the ‘=’ to complete the balance of the REGISTRY command with the current content of the specified key.

With some experience you learn to use TAB efficiently and rarely need to enter an entire filename or Registry Key.

For example once you have copied a UPD file to the /temp folder you can generally execute the JRUPDATE command very quickly with the following keystrokes. This assumes that the UPD file is the sole occupant of that temporary folder.


Note that TAB presents you with optional auto-completion text alphabetically.

JANOS remembers the last 16 unique commands entered during a single session. This allows you to user the UP_ARROW and DOWN_ARROW keys to scroll through the recent commands. A command can easily be re-executed by scrolling back to it and hitting ENTER. A prior command can be first edited. That may be useful when wanting to add an option to its execution.

The HISTORY command displays the recorded commands. They are numbered but the HISTORY command does not give you the means to select from the list.

bruce_dev /> history
1: history
2: whoami
3: help passwd
4: passwd tech
5: passwd
6: users
7: useradd -cd tech
8: useradd
9: userdel
10: usermod
11: help usermod
12: help

bruce_dev />

Note that in addition to scrolling using the up and down keys you can use the TAB key to retrieve from the list.

TAB when used at the beginning of the command line offers valid commands in addition to file names. It includes those from the recent HISTORY. If you want to recall the ‘help usermod’ command given the above HISTORY you can simply type ‘h’ followed by TAB until you get the line that you are seeking. Note that TAB presents options alphabetically.

The WHOAMI command can be used to verify your login. While it seems trivial this command may be useful if you walk up to an existing login and need to confirm its permissions.

bruce_dev /> whoami
 jnior       1  Administrator
bruce_dev />

A password may be changed using the PASSWD command. The PASSWD command is available to all active accounts but only an Administrator can use it to alter the password of another account by specifying the account user name.

In addition, if you are not an Administrator changing the password on another account you will be asked to enter the current password before you can provide a new password. This is an added level of security.

bruce_dev /> help passwd
PASSWD [user]

Sets the password for the user. Defaults to the current user.

bruce_dev />

The USERDEL command removes 1 or more users from the system. This is not reversible. If you are uncertain about the deletion of a user you can add the Disabled tag to temporarily close the account using the USERMOD command. Multiple users can be removed by listing the users on the command line separated by spaces. The following would remove the ‘admin’, ‘user’ and ‘guest accounts.

userdel admin user guest

Note that there is no confirmation so use this command carefully. The command has no options and you must specify at least 1 user.

bruce_dev /> userdel
USERDEL user...

Removes one or more users from the system.
Multiple users can be specified separated by spaces.

bruce_dev />

You cannot remove yourself by the way. This command is also only available to an Administrator account.

The USERMOD command allows you to add or remove user account privileges or tags.

bruce_dev /> help usermod

 +A,-A          Add or remove Administrator rights
 +C,-C          Add or remove Control rights
 +D,-D          Disable or Enable the account

Modifies user privileges.

bruce_dev />

The Series 4 uses three different tags: Administrator, Control, and Disabled. These are described under the USERS command topic. Basically accounts tagged as Administrator can do everything. An account tagged for Control can only manipulate I/O status. And, a Disabled account is just that, disabled.

The USERMOD command actually violates the JANOS standard for command options. This command uses the plus sign ‘+’ as well as the dash ‘-‘ to designate an option. This is a legacy thing left over from the Series 3.

The following command disables the ‘user’ account by adding the Disabled tag:

usermod +d user

This would re-enable the account by removing the Disabled tag:

usermod -d user

Note that the USERMOD command can only modify a single user. So you cannot add a tag to a set of users. You must also specify a user.

If you are at all concerned about security the USERS command is important! The JNIOR ships with four (4) default user accounts each with an obvious password. Two (2) of those accounts are Administrators. Most customers are not aware of this. We have seen where a customer will change the password for the ‘jnior’ account and think they are good to go. In reality the ‘admin’ account remains active and accessible with the default password. The USERS command is the only way you can see what accounts are active.

The USERS command is part of JANOS and new to the Series 4. While the account situation, as far as having two (2) administrators, is the same with the Series 3 you can only see the active accounts on those older JNIORs by viewing the content of the /etc/passwd file. That file is not present on the Series 4.

Here is a default account status as shipped.

412dmx_r00 /> users
 admin       3  Administrator
 guest       0  Disabled
 jnior       1  Administrator
 user        2  Control, Disabled

412dmx_r00 />

In addition to the two (2) active administrator accounts there are two other account. Not that those are Disabled by default. JANOS allows you to disable an account without deleting it. It was not possible to do that with the Series 3. In that case the ‘user’ and ‘guest’ accounts are active.

The USERS command has no options. It lists each account and the tags associated. There are 3 possible tags:


An account tagged as Administrator has full access to the JNIOR. An administrator can access any file regardless of its permissions. An administrator can utilize every command available at the command line and can fully configure the JNIOR. An account with the Administrator tag has access to all of the capability afforded by the Control tag.


An account tagged as Control can manipulate I/O. This includes toggling relays and adjusting external module I/O settings. These users cannot configure the JNIOR and are subject to all file permissions.


You cannot log into a Disabled account. The account still exists and can be restored at any point. This tag can be used to temporarily make an account inaccessible.

The account tags can be added or removed using the USERMOD command. Users can be added or removed using the USERADD command or USERDEL command respectively.

The MODE command is rarely used and has one specific purpose. It controls whether or not the RS-232 (COM) port at the bottom of the JNIOR next to the LAN port is to be used for boot messages and command line interaction.

Issue the MODE command without parameters and it will display the current status of the “diagnostics port”. By default it is enabled. You would disable this if you were to use that serial port as part of your application to communicate with another device. In that case any spontaneous messages or command line interception would cause your protocol communications to fail, so you disable it.

To disable the diagnostics port issue the MODE -S command. You can think of the ‘S’ option as being “Silent”.

To enable the diagnostics port issue the MODE -V command. Okay in this case the option perhaps means “Verbose”. This is the default.

Now there is an Easter Egg here. JANOS has a few undocumented command options. There are very few and most of them provide some cryptic debug information more or less for my use. But here’s one for you.

The MODE -A command is undocumented. This enables the AUX port for command line interaction. Once you issue the MODE -A command any character received on the AUX port will start a command line process there. You cannot disable this mode. It is reset on reboot.

This “feature” was added to facilitate production program and test. The builder that initially programs the JNIOR and tests all of its I/O uses a command line connection through the AUX port to test the AUX port.

Here we see that a command line process is now active on the AUX port.

bruce_dev /> ps -v
      runtime       mem  hnd stk frm     id    desc
          36.667                          0: Idle Process
           1.395    2.6K   7   9          1: Network Service
           1.320    1.3K   7  17          2: System
           0.048   34.5K   7  12          4: Command/AUX
4 total          39.547 uptime

bruce_dev />

For this to work, you must not have an application running that uses the AUX port for communications. If you have used an application on that port you may need to prevent it from running on boot and to reboot the unit. The application may program timeouts and other port features that will interfere with the command line use. The port must also be set for 115,200 baud.

In order to breath life into a being you must get its heart beating. For a generic operating system the heart is it’s multitasking capability. In developing JANOS one of the very first modules that was created was the one responsible for coordinating the execution of multiple independent processes.

Practically every microprocessor program that has been written is responsible for, and therefore juggles, more than one task. Even those that seem to be so specific so as to be focused on one single task end up responsible for two or more sub-tasks. That doesn’t imply though that every program need implement sophisticated multitasking algorithms. In most cases a simple loop need be employed to cycle through the various tasks at hand.

With a focused application a control loop is often sufficient. In this case task A, B, C, etc. are executed in sequence if they are needed. Once all tasks have been given the chance to run the loop is repeated. Depending on the needs of the application a loop may repeat as often as possible or it may have the luxury of sleeping. The latter being helpful in reducing power requirements.

The rate at which a control loop repeats is variable and dependent on the number of tasks that needs to execute in each cycle and the amount of time each task takes to complete. If there is one task that is time sensitive there can be issues. If the total time required by the other tasks that need to run delays the loop too long, the time critical task may fail. The programmer has to take this into consideration. This can be a real problem if any task becomes dependent upon an external event and must wait for an indeterminate amount of time.

When a task has to wait it is prudent to move on and let other activities be performed in the meantime. We can employ a state machine. Here we break the current task down into a set of sub-tasks where a variable is used to keep track of the current sub-task. If a task has to wait it exits allowing other tasks in the main control loop a chance to run. When the main loop returns to the task at hand, the state machine takes us back to the point where we left off. If we still have to wait we exit again otherwise we handle the next step in the current task.

With fairly complex applications, the main control loop can become complex. The programmer may need to implement some kind of priority scheme. This would increase the time allotted for a set of tasks and force others to take a backseat. Then if multiple tasks require state machine implementations the overall dynamics start to become fuzzy. The programmer suddenly finds situations where the system may behave strangely leading to tweaks and eventually a feeling of careful balance. It works but you are now cautious not to add much more to it. Not without emphasizing testing.

Consider a generic operating system such as JANOS. Here there is a spectrum of system tasks that may be optionally running. Then there can also be multiple programs developed by others (of varying skill levels) running in the system and requiring CPU time. The resulting set of tasks can be so unpredictable that a simple tasking loop is doomed to failure.

A program may need to wait on a communications channel and the third-party programmer does not realize the need to return to allow other tasks to run. At a minimum this slows the system down and suddenly the task handling network traffic might start to cause timeouts and protocol failures. You just cannot predict this let alone control it with the simple loop approach.

So rather than to even try, JANOS employed a preemptive approach right from the start. Now every task becomes a process. Each process executes within its own context. Every context is isolated from other contexts creating independent processes. A timeslice is defined. For JANOS a timeslice is 32 milliseconds. JANOS allows each process to run for up to one timeslice before forcibly moving on to another. A process can relinquish its timeslice when it is waiting on something but it cannot monopolize the CPU.

In coding JANOS the main.c program was the first created. It performs some initial configuration and starts the Process Engine. From that moment on the system became capable of executing more than one process. The main.c procedure then dubbed itself the “Startup Process”. Once it completes its required steps it renames itself as the “Idle Process” and falls into the tight wait loop. From that point forward it becomes solely responsible for collecting unused CPU time. This being the equivalent of twiddling your thumbs.

Before becoming the Idle Process mode the Startup Process initializes the Network Service. This process runs at all times and with priority to insure that all network traffic is handled properly and in a timely fashion. The Startup Process also starts the System process. The System process consists of a simple control loop executing low-priority background tasks such as logging, memory cleanup and event notification. These are the three low-level processes in the OS that run always and cannot be stopped.

Here some of the complexity becomes apparent. In addition to the three base processes that I have described we see some others. The jaccess.jar program is running. This is an application that the HoneyPot uses to create the Mirai Botnet Map web page that it serves to the public. While the Web Server process is required for you to access those pages it is likely running here because I have the DCP open in my browser. In fact the Console process there is mine as well. This results from a session in the Console tab of the DCP and that is where I executed the PS command you see above.

Finally there is a Command process running for some other random IP address. That indicates that there is a Telnet session open. On the HoneyPot those are generally from a Mirai infected host trying (unsuccessfully) to log into this JNIOR. Under JANOS there can be as many as 16 separate processes (including the Idle Process) running at one time.

So what is in the Process Engine that creates this preemptive multitasking environment? It may or may not seem complex to you. I have managed to create a preemptive environment on a variety of processors including the Z80, HP’s early entry into the minicomputer market, CP/M running on early Intel processors and many others. Notably I added this to the Dallas DS80C400 which created the multitasking capability found in the Series 3 JNIOR. The TINI OS that forms the basis of the Series 3 OS is not originally capable of multitasking. JANOS runs preemptive multitasking quite successfully on the Renesas RX63N.

To create a preemptive multitasking environment you need a few basic things. The first is a good 1 millisecond interrupt forming a process tick. You also need a way to switch program context with a minimum of overhead. And finally there needs to be a good atomic means to create a mutex (mutual exclusion object). That being a synchronization technique to control access to system resources when multiple processes are contending for them.

The main.c program during the initialization of JANOS sets up one of the timer registers in the RX63N to divide down the system clock and generate an interrupt every millisecond. The Process Engine first uses this to tally milliseconds and thereby track uptime and to create a real-time software clock. Then on every 32nd tick the Process Engine moves forward to see if another process is pending execution. In that case the context is changed and the next process is allowed to run.

The RX63N uses two stack areas. There is a User Stack which programs normally use to PUSH and POP data. The C Subroutine entry implementation also allocates local variables on that stack. For software to be re-entrant and therefore functional in such a multitasking environment it must store all of its variables on the stack. Now that can include pointers where each instance of that subroutine might allocate its own memory blocks and save the pointers. Later the route needs to release those blocks to avoid memory leaks. The point being that the “context” is really the stack content.

In addition to the User Stack the RX63N also uses an Interrupt Stack. When an interrupt occurs, for instance when the internal timer register is ready to signal 1 millisecond, The program pointer and certain critical resisters are save on the Interrupt Stack before running the interrupt service routine.

So for JANOS to change processes it simply saves the User and Interrupt stack pointers in the Process Table for the current process and then locates the next process that is ready to execute. The User and Interrupt stack pointers are updated from the Process Table for that process and we return from the tick interrupt. Ahh, but now we are not returned to where were just interrupted but to where the new task was interrupted before and so it continues. The originally interrupted process then waits for its turn to run again.

To change processes and context we swap two stack pointers. This is an extremely efficient (time wise) and low-overhead task swap. We do have to push all of the other registers onto the stack before swapping to insure and complete context swap. It happens very quickly. JANOS jumps cleanly from one process to the next without any process realizing it had been set aside temporarily.

This approach requires that we pre-assign 16 independent User Stacks and 16 independent Interrupt Stacks in the Process Table. Fortunately the RX63N has sufficient internal high speed RAM. The Process Engine initialization called by main.c gets that done before enabling the 1 millisecond tick.

Now to create a new process a PROC_create() method is provided that defines the starting point for the new process and passes a couple of useful parameters. The Web Server for instance starts at an entry point named HTTP_process(). An new entry is added to the Process Table for the new process. The name of the new process is one of the parameters supplied. The User and Interrupt stacks for the new process are initialized with content and initial values as would be expected when a return from the 1 millisecond interrupt is executed. Once everything is in order a flag for the new process is set allowing it to execute. We return from the creation routine to do other things but when our timeslice is up, the new process also proceeds from the point we defined.

If a program runs non-stop for its 32 millisecond timeslice it will be preempted. It then waits until it can continue after other tasks get their time in the sun. If a process needs to wait it can release its timeslice by calling PROC_yield(). This call generates a software interrupt that then performs the process swap and starts a new timeslice. The yielding process will continue once others have had a chance.

Often we know about how long we will need to wait. In this case we can release our timeslice for a certain number of milliseconds by calling PROC_sleep(). Here we not only allow our process to swap but also set a timer telling the Process Engine that we won’t be ready to execute for a while.

Along these lines to keep options open and flexible there is also a PROC_delayed() call. This sets the wait time so our process won’t run again until the specified time (uptime as opposed to RTC time). Add to this a PROC_pause() method that stops a process until another process specifically allows it to run again.

Finally there is a PROC_terminate() method which, like it says, terminates the process. This removes the process from the Process Table .

A process may be preempted at any time. This is likely to be in the middle of the assembly language executing a C statement. There are times when critical system structures are being read and updated. An interruption an an inopportune moment can invalidate an update and cause system issues. This is handled through the implementation of a CRITICAL SECTION.

A process can execute an ENTER_CRITICALSECTION macro. This establishes a section of code that cannot be swapped. Once the critical system structures are updated the EXIT_CRITICALSECTION macro restores normal swapping. While this seems to violate our statement earlier that the CPU cannot be monopolized, the Critical Section functionality is only available for use in JANOS system code and not by external application programs. It is not available to third party programmers. Those programs cannot monopolize the system. At least not so easily.

Critical Sections can be nested. That is just handled as a counter which is incremented upon section entry and decremented on exit. As a result there are very few situations where system interrupts must be disabled to prevent issues. This keeps the interrupt processing system ready at all times to service interrupts. Interrupts are not missed.

As a result of all this, the Web Server for example can be written without concern for anything else that may be running. It can also execute processes of its own. An example here is the PHP Scripting Engine which is started by the Web Server. This allows the Web Server to service other requests while a PHP program is compiled and then executed. Such complex interactions occur very smoothly and cleanly.

When a tick generates an interrupt only some registers are preserved on the stack. JANOS uses some inline assembly to also push R6 thru R13 and FP register. The two stack pointers are then passed to the scheduler which may or may not update them depending on what else need to run.


/* -- inline asm -------------------------------------------------------------
** inline_call_tick()
** Saves processor state in a consistent manner and manages the stack 
** pointers independent of C optimization effects.
** -------------------------------------------------------------------------*/
#pragma inline_asm inline_call_tick
static void inline_call_tick(void)
	PUSHM	R6-R13		; save balance of registers
	PUSHC	FPSW		; save FP register

	MVFC	USP,R1		; snapshot both stack pointers
	BSR.W	_tick_proc	; perform task processing

	MVTC	R2,ISP		; update both stack pointers

	POPC	FPSW		; restore
	POPM	R6-R13

These are the additional registers that I mention needed to be saved.

Once the Process Engine became available the main.c proceeded to start Network and System processes as I have mentioned. Eventually in development of JANOS the Network process has to start receiving and then sending packets over the Ethernet LAN. That makes sense but we are kind of blind. That makes it difficult to develop and debug.

So the next process that we created was designed to handle command line interaction through the serial RS-232 (COM) port. The main.cprogram had been outputting notification strings on this port as the various events were occurring but we couldn’t interact with it. Just prior to becoming the Idle process the main.c program outputs a “Hit any key to login” message. We are not going to start a process for command line interaction until we know that there is someone there to use it.

This established the need for Polling Routines. A polling routine is a routine that can optionally be associated with a process class. It is called once every millisecond tick. Obviously these routines cannot do anything lengthy or they would significantly add to the overhead in the process engine. We would use this to detect an “any key” condition on the port and to then start the command line process.

So a structure for process design had started to evolve. The main.c program calls an initialization routine for each subsystem. For the command line process it calls CMD_initialize(). This initialization routine would indicate that it is “Starting command services” and issue the “Hit any key” message. Eventually when we got the network up and running it would start a Telnet server. The CMD_initialize() routine registers the CMD_polling() routine before returning. That polling routine merely checks the status of the serial port buffer and if a character is pending (the ANY key) and the command line process is not running, the CMD_process() is started.

Eventually we will use polling routines to check and handle timeouts and watchdogs among other tasks. It is a key aspect of the process engine and perhaps even a necessity.

FIND, GREP and EGREP are all aliases for the same command. These allow you to search a text file for matches to another string. For example:

HoneyPot /> find NTP jniorsys.log     
10/24/17 10:16:38.000, Clock synchronized via NTP (-5)
10/24/17 12:21:59.000, Clock synchronized via NTP (-35)
10/24/17 12:23:21.000, Clock synchronized via NTP (+5)
10/25/17 13:55:55.000, Clock synchronized via NTP (-23)
10/25/17 14:13:59.000, Clock synchronized via NTP (-5)
10/26/17 15:38:34.000, Clock synchronized via NTP (-21)
10/26/17 18:37:50.000, Clock synchronized via NTP (-52)
10/26/17 20:17:50.000, Clock synchronized via NTP (-28)
10/27/17 14:03:21.000, Clock synchronized via NTP (-27)
10/27/17 14:48:22.000, Clock synchronized via NTP (-5)
10/31/17 09:53:57.000, Clock synchronized via NTP (-43)

This can be very useful if you are looking for a specific entry in a log file. Here is the HELP for the command. The only difference in the aliases is that the EGREP usage assumes the -E option allowing the search string to be a standard REGEX expression. It is the same as GREP -E or FIND -E.

HoneyPot /> help egrep
EGREP regex filespec

 regex          Regular Expression to match
 filespec       File specification
 -E             Use Regular Expressions (EGREP default)
 -C             Count lines
 -H             Print filespec
 -N             Print line numbers
 -I             Case-independent comparisons
 -M             Underline match

Peforms text file search.

HoneyPot />

The search string (or regex) is case-dependent. You can use the -I option to perform a case-independent search. For eample:

HoneyPot /> find manifest jniorsys.log     
11/22/17 08:26:27.567, FTP/ transferred /flash/manifest.json [116.6 kbps]

HoneyPot /> find -i manifest jniorsys.log     
11/02/17 08:28:32.943, Manifest updated.
11/02/17 08:32:43.210, Manifest updated.
11/02/17 11:31:03.541, Manifest updated.
11/20/17 07:38:17.390, Manifest updated.
11/22/17 08:26:27.567, FTP/ transferred /flash/manifest.json [116.6 kbps]

HoneyPot />

You will need to enclose you search string in quotes if searching for something containing a space. For example:

HoneyPot /> find -i "manifest updated" jniorsys.log     
11/02/17 08:28:32.943, Manifest updated.
11/02/17 08:32:43.210, Manifest updated.
11/02/17 11:31:03.541, Manifest updated.
11/20/17 07:38:17.390, Manifest updated.

HoneyPot />

The -C option counts the lines.

HoneyPot /> find -ic "manifest updated" jniorsys.log
 6 lines matched
HoneyPot /> 

Alright now there are 6 lines because I just updated using the MANIFEST command twice having seen that it has been a while.

HoneyPot /> find -i "manifest updated" jniorsys.log 
11/02/17 08:28:32.943, Manifest updated.
11/02/17 08:32:43.210, Manifest updated.
11/02/17 11:31:03.541, Manifest updated.
11/20/17 07:38:17.390, Manifest updated.
11/22/17 10:20:35.847, Manifest updated.
11/22/17 10:20:45.876, Manifest updated.

HoneyPot />

The -N option will include the file line numbers with the matched lines. And, if you know the case of what you are searching for you don’t need the -I option.

HoneyPot /> find -n "Manifest updated" jniorsys.log
  356: 11/02/17 08:28:32.943, Manifest updated.
  357: 11/02/17 08:32:43.210, Manifest updated.
  362: 11/02/17 11:31:03.541, Manifest updated.
  812: 11/20/17 07:38:17.390, Manifest updated.
  930: 11/22/17 10:20:35.847, Manifest updated.
  931: 11/22/17 10:20:45.876, Manifest updated.

HoneyPot />

As a general rule (with very few exceptions) options on the command line can be entered separately or combined. The may appear anywhere on the command line.

HoneyPot /> find -i "manifest updated" jniorsys.log -c 
 6 lines matched
HoneyPot />

Commands and options are not case-sensitive by the way.

The -H option not only provides the line number in the file but also includes the file specification which some error processors like to use.

HoneyPot /> find -h "Manifest updated" jniorsys.log   
/jniorsys.log[356]: 11/02/17 08:28:32.943, Manifest updated.
/jniorsys.log[357]: 11/02/17 08:32:43.210, Manifest updated.
/jniorsys.log[362]: 11/02/17 11:31:03.541, Manifest updated.
/jniorsys.log[812]: 11/20/17 07:38:17.390, Manifest updated.
/jniorsys.log[930]: 11/22/17 10:20:35.847, Manifest updated.
/jniorsys.log[931]: 11/22/17 10:20:45.876, Manifest updated.

HoneyPot />

Note that the output at the command line can be sent to a file using the traditional ‘>’ (create new file) or ‘>>’ (append to file) syntax.

HoneyPot /> find -h "Manifest updated" jniorsys.log > updates.txt

HoneyPot /> cat updates.txt
/jniorsys.log[356]: 11/02/17 08:28:32.943, Manifest updated.
/jniorsys.log[357]: 11/02/17 08:32:43.210, Manifest updated.
/jniorsys.log[362]: 11/02/17 11:31:03.541, Manifest updated.
/jniorsys.log[812]: 11/20/17 07:38:17.390, Manifest updated.
/jniorsys.log[930]: 11/22/17 10:20:35.847, Manifest updated.
/jniorsys.log[931]: 11/22/17 10:20:45.876, Manifest updated.

HoneyPot />

The Underline match option -M is interesting and unique to JANOS. This is especially useful when debugging a REGEX search. It works for any search as for example:

HoneyPot /> find -m "Manifest updated" jniorsys.log              
11/02/17 08:28:32.943, Manifest updated.
11/02/17 08:32:43.210, Manifest updated.
11/02/17 11:31:03.541, Manifest updated.
11/20/17 07:38:17.390, Manifest updated.
11/22/17 10:20:35.847, Manifest updated.
11/22/17 10:20:45.876, Manifest updated.

HoneyPot />

Finally, what about using REGEX? Regular Expressions are a kind of search language which can be used to specify some very complex search requirements. When the -E option or the EGREP command is used the search string can specify a standard REGEX. JANOS implements most but not all aspects of standard Regular Expressions. Here is an example:

HoneyPot /> egrep "NTP \\([+-][0-9][0-9]+)" jniorsys.log   
10/24/17 12:21:59.000, Clock synchronized via NTP (-35)
10/25/17 13:55:55.000, Clock synchronized via NTP (-23)
10/26/17 15:38:34.000, Clock synchronized via NTP (-21)
10/26/17 18:37:50.000, Clock synchronized via NTP (-52)
10/26/17 20:17:50.000, Clock synchronized via NTP (-28)
10/27/17 14:03:21.000, Clock synchronized via NTP (-27)
10/31/17 09:53:57.000, Clock synchronized via NTP (-43)
10/31/17 13:03:01.000, Clock synchronized via NTP (-53)
11/01/17 01:37:37.000, Clock synchronized via NTP (-17)
11/02/17 08:28:06.000, Clock synchronized via NTP (-54)
11/07/17 14:27:47.000, Clock synchronized via NTP (-46)
11/14/17 09:07:59.000, Clock synchronized via NTP (-42)
11/15/17 07:59:34.000, Clock synchronized via NTP (-27)
11/17/17 14:01:52.000, Clock synchronized via NTP (-57)
11/21/17 01:37:48.000, Clock synchronized via NTP (-25)
11/21/17 08:57:01.000, Clock synchronized via NTP (-56)
11/22/17 01:33:16.000, Clock synchronized via NTP (-14)

HoneyPot /> egrep "NTP \\([+-][0-9])" jniorsys.log -c   
 14 lines matched
HoneyPot />

Here we listed all of the Clock synchronization events that made adjustments of 10 or more milliseconds in either direction. Then we count how many others (less than 10 milliseconds).

It is important to note that when escaping characters in a REGEX on the command line you must escape the escaping character. So in Regex you would escape the open parenthesis (which would normally start a group) using \(. On the command line this must be entered as \\( as you can see.

Try the last search with the -M to underline matches.

HoneyPot /> egrep "NTP \\([+-][0-9])" jniorsys.log -m  
10/24/17 10:16:38.000, Clock synchronized via NTP (-5)
  \0(8) "NTP (-5)"
10/24/17 12:23:21.000, Clock synchronized via NTP (+5)
  \0(8) "NTP (+5)"
10/25/17 14:13:59.000, Clock synchronized via NTP (-5)
  \0(8) "NTP (-5)"
10/27/17 14:48:22.000, Clock synchronized via NTP (-5)
HoneyPot />

You can see that with a Regex the matching groups are also displayed along with its length. With Regex, Group 0 (\0) is the entire match. We can separate the magnitude of the adjustment into its own group as follows.


HoneyPot /> egrep "NTP \\([+-]([0-9][0-9]+))" jniorsys.log -m
10/24/17 12:21:59.000, Clock synchronized via NTP (-35)
  \0(9) "NTP (-35)"
  \1(2) "35"
10/25/17 13:55:55.000, Clock synchronized via NTP (-23)
  \0(9) "NTP (-23)"
  \1(2) "23"
10/26/17 15:38:34.000, Clock synchronized via NTP (-21)
  \0(9) "NTP (-21)"
  \1(2) "21"
10/26/17 18:37:50.000, Clock synchronized via NTP (-52)
  \0(9) "NTP (-52)"
  \1(2) "52"
10/26/17 20:17:50.000, Clock synchronized via NTP (-28)
  \0(9) "NTP (-28)"
  \1(2) "28"
10/27/17 14:03:21.000, Clock synchronized via NTP (-27)
  \0(9) "NTP (-27)"
  \1(2) "27"
10/31/17 09:53:57.000, Clock synchronized via NTP (-43)
  \0(9) "NTP (-43)"
  \1(2) "43"
10/31/17 13:03:01.000, Clock synchronized via NTP (-53)
  \0(9) "NTP (-53)"
  \1(2) "53"
11/01/17 01:37:37.000, Clock synchronized via NTP (-17)
  \0(9) "NTP (-17)"
  \1(2) "17"
11/02/17 08:28:06.000, Clock synchronized via NTP (-54)
  \0(9) "NTP (-54)"
  \1(2) "54"
11/07/17 14:27:47.000, Clock synchronized via NTP (-46)
  \0(9) "NTP (-46)"
  \1(2) "46"
11/14/17 09:07:59.000, Clock synchronized via NTP (-42)
  \0(9) "NTP (-42)"
  \1(2) "42"
11/15/17 07:59:34.000, Clock synchronized via NTP (-27)
  \0(9) "NTP (-27)"
  \1(2) "27"
11/17/17 14:01:52.000, Clock synchronized via NTP (-57)
  \0(9) "NTP (-57)"
  \1(2) "57"
11/21/17 01:37:48.000, Clock synchronized via NTP (-25)
  \0(9) "NTP (-25)"
  \1(2) "25"
11/21/17 08:57:01.000, Clock synchronized via NTP (-56)
  \0(9) "NTP (-56)"
  \1(2) "56"
11/22/17 01:33:16.000, Clock synchronized via NTP (-14)
  \0(9) "NTP (-14)"
  \1(2) "14"

HoneyPot /> 

As we hoped Group 1 (\1) contains the part of the match representing the magnitude of the adjustment. You can probably figure out how to include the sign of the adjustment in the group now if that was what you really wanted.

The -M option can be very useful in creating and debugging a Regex for use elsewhere in an application or PHP script.

I should probably cover Regular Expressions in some detail someplace. I put that on the TODO list.

By the way, we have been searching the system log (syslog) as stored in the /jniorsys.log file. That is not all of the event history available. You might notice in the Syslog tab of the DCP that entries go further back in time. So if we had wanted to search all of our syslog history then we could do the following.

HoneyPot /> cat jniorsys.log.bak > syslog.txt

HoneyPot /> cat jniorsys.log >> syslog.txt

HoneyPot /> egrep "NTP \\([+-][0-9])" syslog.txt             
09/27/17 10:40:32.000, Clock synchronized via NTP (+4)
10/24/17 10:16:38.000, Clock synchronized via NTP (-5)
10/24/17 12:23:21.000, Clock synchronized via NTP (+5)
10/25/17 14:13:59.000, Clock synchronized via NTP (-5)
10/27/17 14:48:22.000, Clock synchronized via NTP (-5)
11/14/17 09:23:24.000, Clock synchronized via NTP (+7)
11/14/17 10:08:44.000, Clock synchronized via NTP (-9)
11/15/17 02:13:57.000, Clock synchronized via NTP (+2)
11/15/17 08:06:37.000, Clock synchronized via NTP (+2)
11/15/17 08:11:08.000, Clock synchronized via NTP (+4)
11/15/17 08:15:41.000, Clock synchronized via NTP (+0)
11/15/17 08:18:55.000, Clock synchronized via NTP (-1)
11/15/17 08:21:40.000, Clock synchronized via NTP (+5)
11/17/17 14:45:24.000, Clock synchronized via NTP (-7)
11/18/17 03:26:33.000, Clock synchronized via NTP (-2)

HoneyPot /> rm syslog.txt

HoneyPot />

Seems that there is only one such event prior to October 24th. The syslog ages to a .BAK file when it grows to about 64KB in size.

This shows how you can concatenate files under JANOS. I haven’t implemented some of the syntax of the DOS COPY command that would let you do that. Maybe some day. There doesn’t seem to be much demand for it.

Did you know that every JNIOR since the beginning of time has used the same isolated digital input design? It is not that this design is particularly special. It is more that a better one hasn’t been suggested or required.

Here it is from external connector to the RX63N processor pin (right to left).

The input is optically isolated by the device U12. That means that you can bring a signal from a distance and not have to worry about it being referenced to any local GND. You won’t create any ground loop. There is no common connection between signals (they all need not be referenced to GND). To activate the input then all you have to do is turn that LED on.

The diode D34 protects the isolator LED from high voltages. You can put 30V on this input and not risk LED damage. The extra voltage above 5V is dropped across the 910 Ohm 1 Watt resistor. The input is limited by that 1W power rating. The maximum voltage is 35VDC. And 1 Watt is a lot of heat so you probably want to limit the amount of time that the input sits at that voltage.

To deal with that limitation you could add a series resistance. The maximum voltage is 5V above the square root of the series resistance assuming 1W resistors. So if you want to sense the presence of a 120VAC signal you might insert a 20K series resistance. I will leave the Ohm’s Law exercise to you. Just make sure that you can dissipate the power.

The input can be considered to have about a 1200 Ohm input impedance. It is not a high-impedance input. Therefore any signal used to drive an input must be able to deliver current into a 1200 Ohm resistance and turn on the isolation LED.

The circuit after the isolator creates a 2 KHz low-pass filter. Basically we’ve specified that input signals should not exceed 2000 Hz. The reasoning behind this lies in the need to be kind to the processor. Each input transition generates a software interrupt and executes some code. This allows JANOS to know when the state of the input changes, perform some debounce, and log the event. If this happens too fast the system can be overwhelmed having to execute interrupt code back to back and not get anything else done. That’s not ideal. So the hardware prevents it.

The processor can handle faster signals to be sure. But not if several of the inputs are cranking like that. Besides, the JNIOR is not targeted into applications that process high speed signals.

Now the RED LED that you see when the input is active is driven by the output of that filter. In other words, if the after the filter the hardware thinks that the input is ON then it turns the LED on. So those LEDs are software driven. They illuminate when the input is high enough to activate regardless of how the input is configured internally.

I’ve been meaning to see if there is a more cost-effective and compact implementation for that filter. It was implements old-school with separate gates. Works though.

The input signal then interrupts the processor. In the Series 4 each separate input has its own interrupt channel. That was not the case in the Series 3 where we had some trouble insuring that all of the input channels were properly counted when triggering simultaneously. There is no issue in the Series 4. Each input can be configured.

This shows the input signal processing. In this case we go from left to right. The DIN input generates interrupts. It can be optionally inverted by configuration prior to the debounce logic. This is consistent with the Series 3. Logically though you might want to invert an input afterprocessing. That inversion can be performed by the Conditioning block which finalizes the input state for the system. This is an extension in the Series 4.

The debounce delay by default is set to 200 milliseconds. Basically when an input that has been in one state for a while changes the new state is recognized immediately. The debounce timer then is started. During the delay time additional transitions restart the debounce timer and those state changes are ignored. The reported state is then refreshed once the timer does expire. The trigger is rearmed at that point.

This debounce approach effectively stretches an input pulse until it has been stable for the delay period. So if you want to detect the presence of a 60 Hz AC signal then you need to set the debounce delay long enough to ignore the time when the AC signal does not drive the input. That would be at least 17 milliseconds.


Input Latching is optional. When not enabled the function is bypassed as indicated in the flow diagram. When enabled it can be configured to latch either the HIGH or LOW state. Once latched the input state will remain the same until the input is reset. This would allow you to catch and deal with a pulse or otherwise not lose track of the fact that some alarm condition had triggered.

The latching can be configured to time out. This will latch a pulse and allow it to reset itself after a period of time. You can use this to stretch a short pulse so logic downstream has the time to detect it and to deal with it.


Once the input has been debounced and optionally latched it will be counted. The counter can be configured to count a LOW to HIGH transition (0->1) or a HIGH to LOW transition (1->0). Each counter can be reset to 0 or set to any initial value. These can even be manually incremented by an application.

When counters are displayed they can be scaled and shown with unique units. A counter can trigger an alarm when it reaches predefined values. Alarms can send email notifications.


The Usage Meter totals the length of time that an input has been active. You can tally time for the HIGH state or for the LOW state depending on configuration. Usage meters can be reset to 0. This can be useful in monitoring the operating time of a piece of equipment. An alarm can be triggered when the usage meter reaches a configured amount of time. Alarms can send email notifications. This could be helpful as a reminder for the performance of preventive maintenance.


All input and output signal transitions are by default logged. The IOLOG command can be used to review I/O activity.


Finally the input state can be conditioned (Series 4 only). Here the input state can be optionally inverted or forced to a HIGH (1) or LOW (0) state. The forced states may be of use in debugging applications or disabling an input without having to physically disconnect it. A forced input is masked but continues to be counted and metered.


Note that alarms are available for Counters, Metering, and Input State. Alarms can be configured through the Registry or DCP. These can send unique email notifications.

In summary…

A digital input seems like it is a simple thing with just a HIGH or LOW input state. There is however a lot more to it. We have seen here what effect the hardware has and how the input can be configured. All of this before the input state ever affects any application.

We are all familiar with logs. These are text files someplace that list events such as logins, configuration changes, errors, etc. On the JNIOR the jniorsys.log file is one such log. These things are useful for systems and web servers. The JNIOR is also a controller and it can be very useful to have a log of I/O activity either digital or serial. This is provided by the IOLOG command.

bruce_dev /> help iolog

 -T             Indicate transitions
 -R             Reset logs
 -A             AUX Serial log
 -S             Sensor Port log
 -O             Output to stdout

Generates jniorio.log file from available logs.

bruce_dev />

The above HELP alludes to some different logging capabilities. There is something with transitions. That is a detailed log of recent Digital Input and Relay Output transitions. That even includes relays contained in the external expansion modules. The AUX port supports a bidirectional Transmission Log that details communications traffic that includes both the bytes and the timing. There is also a log for the Sensor Port.

The Series 4 JNIOR by default logs all all of this activity to internal buffers. At any time you can dump the log buffers into a file or to the display using the IOLOG command. The IOLOG -R command can be used to reset a log. This can be useful in debugging where you don’t want to be distracted by prior data. I will show some examples.

Let’s start with the AUX Serial Port since it is fresh in my mind. Here the IOLOG -AR command will remove historical data from the AUX port transmission log. The does not affect the other logs. The IOLOG -AO comand will display the log content. For example…

bruce_dev /> iolog -ao
--  11/21/17 12:13:04.991
 FE  56  01  FE  56  02  FE  56  03  FE  56  04  FE  56  05  FE     ~V.~V.~V.~V.~V.~
 56  06  FE  58  FE  52  FE  9D  13  FE  9C  40  FE  42  01  FE     V.~X~R~..~.@~B.~
 47  01  01  34  31  30  20  53  4E  20  36  31  34  30  37  30     G..410 SN 614070
 35  30  30  20  20  20  20  4A  41  4E  4F  53  20  76  31  2E     500    JANOS v1.
 36  2E  33  2D  72  63  33  20  20  20  20  62  72  75  63  65     6.3-rc3    bruce
 5F  64  65  76  20  20  20  20  20  20  20  20  20  20  20  31     _dev           1
 30  2E  30  2E  30  2E  35  39  20  20  20  20  20  20  20  20        
 20  20  20  FE  42  01                                                ~B.
--  11/21/17 12:13:14.872  +9.741
-43- FE  47  01  01  7E  44  69  67  69  74  61  6C  20  49  6E     C~G..~Digital In
 70  75  74  73  20  20  20  20  20  20  52  65  6C  61  79  20     puts      Relay 
 4F  75  74  70  75  74  73  20  20  20  20  20  20  20  43  6C     Outputs       Cl
 6F  63  6B  20  20  20  FE  47  01  04  20  53  70  6C  61  73     ock   ~G.. Splas
 68  20  53  63  72  65  65  6E  FE  42  01                         h Screen~B.
--  11/21/17 12:13:24.860  +9.873
-48- FE  47  01  01  20  FE  47  01  02  7E  FE  42  01 -48- FE     H~G.. ~G..~~B.H~
 47  01  02  20  FE  47  01  03  7E  FE  42  01                     G.. ~G..~~B.
--  11/21/17 12:13:31.967  +6.306
-45- FE  47  02  01  20  20  20  20  20  20  20  20  20  20  20     E~G..           
 20  20  20  FE  47  01  02  54  75  65  20  4E  6F  76  20  32        ~G..Tue Nov 2
 31  20  31  32  3A  31  33  3A  33  32  20  45  53  54  20  32     1 12:13:32 EST 2
 30  31  37  FE  47  02  04  20  20  20  20  20  20  20  20  20     017~G..         
 20  20  20  20  FE  42  01  FE  47  13  02  33  FE  42  01  FE         ~B.~G..3~B.~
 47  13  02  34  FE  42  01  FE  47  13  02  35  FE  42  01  FE     G..4~B.~G..5~B.~
 47  13  02  36  FE  42  01  FE  47  13  02  37  FE  42  01  FE     G..6~B.~G..7~B.~
 47  13  02  38  FE  42  01  FE  47  13  02  39  FE  42  01  FE     G..8~B.~G..9~B.~
 47  12  02  34  30  FE  42  01  FE  47  13  02  31  FE  42  01     G..40~B.~G..1~B.
 FE  47  13  02  32  FE  42  01  FE  47  13  02  33  FE  42  01     ~G..2~B.~G..3~B.
 FE  47  13  02  34  FE  42  01 -44- FE  47  02  01  44  69  67     ~G..4~B.D~G..Dig
 69  74  61  6C  20  49  6E  70  75  74  73  FE  47  01  02  20     ital Inputs~G.. 
 52  65  6C  61  79  20  4F  75  74  70  75  74  73  20  20  20     Relay Outputs   
 20  20  20  7E  43  6C  6F  63  6B  20  20  FE  47  02  04  53        ~Clock  ~G..S
 70  6C  61  73  68  20  53  63  72  65  65  6E  FE  42  01         plash Screen~B.

bruce_dev /> iolog -ar
AUX logs reset
bruce_dev /> iolog -ao

bruce_dev />

Here we see data in a traditional dump format with 16 bytes displayed in hexadecimal on the left and an ASCII representation of each byte on the right. If the byte does not represent a printable ASCII character it is replaced with a period ‘.’ in the text display.

The AUX serial communications can be bidirectional. Bytes received by the JNIOR are shown enclosed by a dash ‘-‘. In the example above there are single characters received (keypress codes). When a longer message is received the dashes make the incoming data appear to be desplayed over a background line. It is just a way to distinguish direction.

If the channel remains quiet for a couple of seconds, the IOLOG output includes a timestamp and includes the duration of the pause. All of this can be very helpful in debugging a serial communications based application.

The data displayed here is actual results from an HMI test. The content is explained in detail in a different thread. Here is the link to that discussion viewtopic.php?f=5&t=158&start=20#p316. The interface program generating these communications was developed in the thread.

The AUX Transmission log can be sent to a file using the IOLOG -A command.

bruce_dev /> iolog -a
 auxio.log generated.
bruce_dev />

The file will then contain the data in the same format displayed in the prior post.

The Digital I/O log has quite a different appearance. This is generated using the IOLOG -O command. The digital log is the default log assumed by the command.

bruce_dev /> iolog -o
11/15/17 08:40:27.085, DIN ---- 0000 0000, RLY ---- ---- 0000 0000
11/21/17 09:45:27.073, DIN ---- 0000 0000, RLY ---- ---- 0000 0001
11/21/17 09:45:27.848, DIN ---- 0000 0000, RLY ---- ---- 0000 0000
11/21/17 09:45:29.549, DIN ---- 0000 0000, RLY ---- ---- 0000 0100
11/21/17 09:45:30.330, DIN ---- 0000 0000, RLY ---- ---- 0000 0000
11/21/17 09:45:31.582, DIN ---- 0000 0000, RLY ---- ---- 0000 0010
11/21/17 09:45:32.619, DIN ---- 0000 0000, RLY ---- ---- 0000 0000
11/21/17 10:05:55.007, DIN ---- 0000 0000, RLY ---- ---- 0000 0010
11/21/17 10:05:56.056, DIN ---- 0000 0000, RLY ---- ---- 0000 0000
11/21/17 10:05:58.144, DIN ---- 0000 0000, RLY ---- ---- 0000 0100
11/21/17 10:05:59.943, DIN ---- 0000 0000, RLY ---- ---- 0000 0000
11/21/17 10:06:05.996, DIN ---- 0000 0000, RLY ---- ---- 0000 0100
11/21/17 10:06:09.173, DIN ---- 0000 0000, RLY ---- ---- 0000 0000
11/21/17 10:06:11.282, DIN ---- 0000 0000, RLY ---- ---- 0000 0010
11/21/17 10:06:12.518, DIN ---- 0000 0000, RLY ---- ---- 0000 0000
11/21/17 10:10:58.434, DIN ---- 0000 0000, RLY ---- ---- 0000 0010
11/21/17 10:22:00.468, DIN ---- 0000 0000, RLY ---- ---- 0000 0000
11/21/17 10:25:21.980, DIN ---- 0000 0000, RLY ---- ---- 0000 0010
11/21/17 10:28:43.913, DIN ---- 0000 0000, RLY ---- ---- 0000 0000
11/21/17 10:44:08.223, DIN ---- 0000 0000, RLY ---- ---- 0000 0001
11/21/17 10:44:09.621, DIN ---- 0000 0000, RLY ---- ---- 0000 0000
11/21/17 10:44:10.585, DIN ---- 0000 0000, RLY ---- ---- 0000 0010
11/21/17 10:45:39.208, DIN ---- 0000 0000, RLY ---- ---- 0000 0000
11/21/17 10:48:23.797, DIN ---- 0000 0000, RLY ---- ---- 0000 0100
11/21/17 10:48:24.859, DIN ---- 0000 0000, RLY ---- ---- 0000 0000
11/21/17 10:51:09.241, DIN ---- 0000 0000, RLY ---- ---- 0000 0010
11/21/17 10:52:02.613, DIN ---- 0000 0000, RLY ---- ---- 0000 0011
11/21/17 10:52:04.316, DIN ---- 0000 0000, RLY ---- ---- 0000 0010
11/21/17 10:52:05.107, DIN ---- 0000 0000, RLY ---- ---- 0000 0011
11/21/17 10:52:05.891, DIN ---- 0000 0000, RLY ---- ---- 0000 0010
11/21/17 10:52:08.636, DIN ---- 0000 0000, RLY ---- ---- 0000 0000
11/21/17 10:52:09.168, DIN ---- 0000 0000, RLY ---- ---- 0000 0010
11/21/17 10:54:14.726, DIN ---- 0000 0000, RLY ---- ---- 0000 0011
11/21/17 10:54:25.912, DIN ---- 0000 0000, RLY ---- ---- 0000 0010
11/21/17 10:55:35.680, DIN ---- 0000 0000, RLY ---- ---- 0000 0000
11/21/17 11:00:48.609, DIN ---- 0000 0000, RLY ---- ---- 0000 0010
11/21/17 11:00:52.456, DIN ---- 0000 0000, RLY ---- ---- 0000 0000
11/21/17 11:05:50.782, DIN ---- 0000 0000, RLY ---- ---- 0000 0100
11/21/17 11:07:27.885, DIN ---- 0000 0000, RLY ---- ---- 0000 0110
11/21/17 11:09:21.747, DIN ---- 0000 0000, RLY ---- ---- 0000 0100
11/21/17 11:09:22.243, DIN ---- 0000 0000, RLY ---- ---- 0000 0110
11/21/17 11:40:23.259, DIN ---- 0000 0000, RLY ---- ---- 0000 0100
11/21/17 11:40:24.670, DIN ---- 0000 0000, RLY ---- ---- 0000 0000
11/21/17 11:59:31.745, DIN ---- 0000 0000, RLY ---- ---- 0000 0010
11/21/17 11:59:33.136, DIN ---- 0000 0000, RLY ---- ---- 0000 0110
11/21/17 12:00:18.043, DIN ---- 0000 0000, RLY ---- ---- 0000 0010
11/21/17 12:05:08.749, DIN ---- 0000 0000, RLY ---- ---- 0000 0000
11/21/17 12:05:10.141, DIN ---- 0000 0000, RLY ---- ---- 0000 0010
11/21/17 12:42:49.123, DIN ---- 0000 0000, RLY ---- ---- 0000 0000

bruce_dev />

This log is generated by combining separate input and output logs. Each can contain up to 500 transitions. Depending on how frequently inputs and relays change you could have data spanning weeks or simply minutes.

Each line represents at least one transition. There is a timestamp to the millisecond. A ‘1’ indicates when an input (DIN) is activated or a Relay (RLY) closed. The inputs and relays are shown from right to left. So the last transition in the above log shows Relay Output 2 opening. There can be up to 16 relays and 12 inputs logged.

The IOLOG -R command will reset the digital log and not affect others. The IOLOG command without options will store the digital log in a file.

bruce_dev /> iolog
 jniorio.log generated.
bruce_dev />

There is also a log for the Sensor Port but unless you are intimately familiar with Dallas 1-Wire communications none of it will make sense. You can write an application to take control over the Sensor Port and communicate with a custom device or non-standard device. It you are working at that level then this log could be very helpful. The Sensor Port log follows the same format as the AUX Transmission Log.

So you’re developing an application. It works, but you question if it is efficient or not. That is where the THD command comes in. The THD command will show all of the threads that are active in each Java application that is running.

This command will also show other useful JVM information. Information such as the number of unique classes that have been loaded, the amount of memory that has been allocated to hold that class information, process time, heap memory usage, stack usage and class object memory usage.

Then each thread is listed showing its processor usage time, thread name, the class that implements the thread, parent thread, state and whether or not the thread is a daemon thread.

Lastly any Watchdog that has been activated is listed with its name, the action that will be carried out should the watchdog be triggered and how long until the watchdog will be triggered should it not be fed.

Here is a quick application that tests the Watchdog. You can see that at the time the thd command was executed the Watchdog was about to expire, within 1 second.

kev-dev /> thd
   9 classes loaded.   44.7 KB
   1 JVM instances active.
Command/         0.557   mem: 20.9K  pid: 36  stk: 0.3K  obj: 2.1K  cls: 12.4K
         0.150  1: main, java/lang/Thread, main, SLEEP
     Watchdog: 'Watchdog Test', WDT_REBOOT, remaining = 0.880s

Here is the code listing for the above test application.

package watchdogtest;
import com.integpg.system.JANOS;
import com.integpg.system.Watchdog;
 * This application tests the watchdog. A watchdog will be registered with the operating system. It will be fed a few
 * times and then left to be triggered. When it gets triggered we should see the registered action get carried out.
public class WatchdogTest {
    public static void main(String[] args) throws InterruptedException {
        // instantiate the watchdog and register it to reboot when it gets triggered
        Watchdog watchdog = new Watchdog("Watchdog Test");
        // log to the syslog so that we can see exactly when the operating system reboots
        JANOS.syslog("Watchdog Started");
        // sleep for 30 seconds and then feed the watchdog.
        JANOS.syslog("Watchdog fed");
        // sleep for longer than the watchdog duration.  This will allow the watchdog to get triggered.  We 
        // should see that the reboot occurs 60 seconds after the last time the watchdog was fed

And here is the associated log entries from the jniorsys.log. As expected the timing works out. The watchdog was started, 30 seconds later we log that it was fed and then 60 seconds later we get the Assertion indicating that the reboot sequence has been commenced. 15 seconds are given to applications and system processes for safe shutdown.

11/17/17 14:13:19.302, Watchdog Started
11/17/17 14:13:49.368, Watchdog fed
11/17/17 14:14:49.487, ** Assertion: Watchdog Test watchdog triggered reboot (Line 1139)
11/17/17 14:14:49.496, ** Terminating: System
11/17/17 14:15:05.937, ** Reboot on assertion: Watchdog Test watchdog triggered reboot (Line 1139)
11/17/17 14:15:05.945, -- JANOS 412 v1.6.3-rc2 initialized (POR: 58)