So, we already have ways of dynamically loading a menu of SVG icons made to react by loading panels if we so desire, but the icons were not actual components. We were able to use a simple trick of bringing in the SVG for each icon and passing it into the Vue application. It was simple enough to generate a list of icons, and each icon reacted in a similar way except for small data differences. The data difference made it possible to bind the name of a panel to each icon in such a way that the handler for the icon’s button click could pass it on.

When a panel is loaded in the form of Vue component, everything about the panel and its components has to be loaded, templates, JavaScript, and more. So, the job of just managing loading the panel is bigger than what we have encountered so far in this discussion.

Let’s look at Vue’s way of providing a hook for async loading. The following snippet is from the Vue guide.

Vue.component('async-example', function (resolve, reject) {   setTimeout(function () {     // Pass the component definition to the resolve callback     resolve({       template: '<div>I am async!</div>'     })   }, 1000) }) 

The guide tells us that the setTimeout function is an example of how to use the synchronicity with Vue components. Notice that where before there had been an object as the second parameter to Vue.component, there is now a function, which is referred to as a factory function. Within the resolve callback is a component definition, that would have been the second parameter to Vue.component before.

So, I had to stare at this example a while before it made sense to me. Here is another example, which suits me better:

Vue.component('async-example', function (resolve, reject) {   // Vue will call this function and promise itself to handle   // it when it gets back with data.    // this function can then call a promising object loader   // here the 'loader' function is some abstract function.   // Most likely the application will use 'fetch'   // but it could be something else.   loader('/my/resource/on/server.json').     then(function (JSON_data) {          var object = transformJSONToJSObject(JSON_data);           resolve(object)     }).catch( (error) => { handle it } ); 

It seems like the right thing to do to make a more general function to go around this form.

function componentLoader(c_name,resource_url) {   Vue.component(c_name, function (resolve, reject) {     loader(resource_url).       then(function (JSON_data) {            var object = transformJSONToJSObject(JSON_data);             resolve(object)       }).catch( (error) => { handle it } ); } 

So, in general, to load a component, we would just need a line like the following:

componentLoader('ThermoPanel','./JSON/thermo-panel.json'); 

So now, just what is the JSON that is being loaded? It can include everything about the component. In this case, as a panel component, it can include thermometers, machine switches, sliders, gauges, and more. While it seemed nicer to keep the components parts on the web page, it may actually work better to use the subcomponent field that is in the longer example for ‘thermo-panel’ that we made before and also for the other similarly constructed panels. The JSON will contain a complete panel structure.

However, if the reader will notice the inclusion of the function call to transformJSONToJSObject, he will understand that JSON might be coded in some way to make transport easier and to make it easier for a server to handle the definition. After all, the definition will include complete SVG templates, function definitions, and other JavaScript expressions. Also, the JSON object may contain more than just the panel definition because some information may simply aid in bookkeeping or validation. So, one can expect that there will be some treatment of the object upon receipt.

As for the encoding, the data coming in from the server may be encoded in a number of ways. Perhaps it will be simply URL encoded. Or more securely, it might be enciphered. For this discussion, we can just use URL encoding.

Some of the tools that are available for creating Vue applications no doubt take care of the JSON transformation. But, this discussion has so far avoided the use of command line tools. This omission is not that bad as we have also used Vue with the minimum of resources, using only one script tag for the referring to the CDN. However, I certainly do recommend looking into the command line tools especially for organizing projects.

When the JSON arrives at the page, given the component is completely assembled with subcomponents, no more work has to be done to fetch the parts. We can make the assumption that all components will come in fully defined for the rest of this discussion. But, assembling complete component hierarchies will require command line tools at some point.

The SVG editing process will also require some work. The SVG editing processes allow a designer to draw a panel and all the components on it. But, each subcomponent has to be identified, called out in a group, or given a place holder. Any approach to using the drawing requires some treatment of the SVG so that Vue component tags can replace the groups or graphic elements. In this way, any artist rendering can become a template. And, the drawn subcomponents will have to be disassembled into templates for Vue subcomponents.

This sort of parsimony is contrary to the workflow of most of the JavaScript frameworks. The frameworks are about assembling pages. But, editing or drawing, results in something already assembled by an artist. In practice, the result of editing does not provide a text file that corresponds directly to a framework component definition.

More about the editing process may be considered in some other discussion. There is a lot to it. But, for now, we have the tools we need in order to load hierarchal components and make them come alive.

The Lazy Application

For our IoT panel construction, we already have a selection bar that responds to searches. And, we have a way of loading components when we need them. We just need to connect up these parts. And, at last, we have to make sure that the panels appear and that they start working when they do.

The lazy loading of panels done by the async code above provides a sketch of an idea. But, thankfully, some people have experimented to find ways of making sure that all kinds of components can be loaded. There is one codepen entry that shows how to update Vue apps with new components of varying types. That is the mechanism that is needed for updating a designated part of the page with different types of panel.

With the ability to add in different kinds of panels and with a simple mechanism to load their definitions, we can, at last, have our panel searching page.

Here is the HTML that we need in our page so that the Vue app can place components in dynamically:

<template v-for="(panel, index) in panelList">   <component :is="panel" :key="panel.name"></component> </template> 

The component tag is a Vue meta tag. See the reference for dynamic components. The properties, special attributes, used for the component tag in this case are is and key. The is attribute exists for dynamic components. And, the key ensures that the new children will have different identities from each other and helps Vue to decide what to draw.

“Children of the same common parent must have unique keys. Duplicate keys will cause rendering errors.”

The template tag will loop through components that are provided in the panelList data field of the application.

So, starting with the application level Vue definition for the icon app, we can make changes to include the panelList in the data elements. (Let’s now call it the panelApp).

var panelApp = new Vue({         el: '#PanelApp',         data: {         iconList: [  // Where is the data? Still on the server.         ],         panelList: [         ],         queryToken : "Thermo Batches"  // picked a name for demo         },         methods : {           goGetPanel: function (pname) {             //               var url = panelURL(pname);  // this is custom to the site.               fetch(url).then((response) => {  // this is now browser native                 response.text().then((text) => {                       var newData = decodeURIComponent(text);                        eval(pHat);  // widgdef = object def, must be assignment                        pHat = widgdef;                      var pnameHat = pname + pcount++;                      pHat.name = pnameHat; // this is needed for the key                      this.panelList.push(pHat);  // now it’s there.                   }).catch( error => { /* handle it */ });           }         }     }); 

Besides adding in the panel, goGetPanel is now in a form required for getting a component definition from a database or other store. The server side must be careful about delivering JavaScript code in the correct format. As for what the object looks like coming from the server, we have already seen it. It is the kind of object used as a parameter to Vue.component.

Here is the complete body of the Vue app that provides a menu as a search result and a place to put panels fetched from the server when the user clicks an icon.

<div id="PanelApp">  <!-- Recognize the name from the Vue doc -->   <div>   <h2 itemprop="name">Request MCU Groups</h2>   <p itemprop="description">These are groups satistfying this query: {{queryToken}}.</p>   <button onclick="GetIcons(11)">Find All</button>   <button onclick="GetIcons(5)">Find 5 Point</button>   <button onclick="GetIcons(6)">Find 6 Point</button>   </div>    <!-- Here is a Vue loop for generating a lit -->   <div class="entryart" style="padding:4px">   <button v-for="iconEntry in iconList" @click="goGetPanel(iconEntry.name)" >     <div v-html="iconEntry.icon">     </div>   </button>   </div>    <div class="entryart" style="padding:4px" >     <template v-for="(panel, index) in panelList">       <component :is="panel" :key="panel.name" :ref="panel.name" ></component>     </template>   </div>  </div> 

In the last div, the component tag now has a ref parameter bound to the panel name. The ref parameter allows Vue app to identify which component to update with data and keeps components separate. The ref parameters also allow our application access to the new dynamically loaded components.

In one test version of the panel app, I have the following interval handler:

setInterval(() => {   var refall = panelApp.$ refs;   // all named children that panels   for ( var pname in refall ) {  // in an object     var pdata = refall[pname][0];  // off Vue translation, but it’s there.     pdata.temp1 = Math.round(Math.random()*100);  // make thermos jump around.     pdata.temp2 = Math.round(Math.random()*100);   } },2000) 

The code provides a little animation, changing thermometers randomly. Each panel has two thermometers, and the app allows the user to keep adding panels. (In the final version, some panels must be thrown away.) The refs are being accessed using panelApp.$ refs, a field that Vue creates given the refs information in the component tag.

So, this is what the randomly jumping thermometers look like in one snapshot:

Connecting The Panel To The IoT Device

So, the last piece of code is a setInterval test updating thermometers with random values every two seconds. But, what we want to do is read in real data from real machines. In order to do that, we will need some form of communication.

There are a variety of ways. But, let’s use MQTT which is a pub/sub message system. Our SPWA can subscribe to messages from devices at any time. When it gets those messages the SPWA can direct each message to the appropriate data handler for the panel mapped to the device identified in the message.

So, basically what we need to do is replace the setInterval with a response handler. And, that will be for one panel. We probably want to map panels to handlers as they are loaded. And, it is up to the web server to see that the correct mapping is delivered.

Once the web server and the SPWA have the page ready for operation, the web server no longer needs to take care of messaging between the page and the device. the MQTT protocol specifies a routing server to handle pub/sub. A number of MQTT servers have been made. Some of them are open source. One very popular one is Mosquito, and there are a few developed on top of Node.js.

The process for the page is simple. The SPWA subscribes to a topic. One good version of a topic is an identifier for an MCU such as a MAC address or a serial number. Or, the SPWA could subscribe to all temperature readings. But, then the page would have to do the work of filtering the messages from all devices. Publication in MQTT is essentially a broadcast or multicast.

Let’s take a look at how the SPWA will interface with MQTT.

Initializing MQTT On The SPWA

There are several client libraries to choose from. One, for instance, is a MQTT.js. Another is eclipse paho. There are more of course. Let’s use Eclipse Paho since it has a CDN stored version. We just need to add the following line to our page:

<script src="https://cdnjs.cloudflare.com/ajax/libs/paho-mqtt/1.0.1/mqttws31.min.js" type="text/javascript"></script> 

The MQTT client has to connect to a server before it can send and receive messages. So, lines setting up the connection also need to be included in the JavaScript. We can add in a function MQTTinitialize which sets up the client and the responses for connection management and message receipt.

var messagesReady = false; var mqttClient = null;  function MQTTinitialize() {   mqttClient = new Paho.MQTT.Client(MQTTHostname, Number(MQTTPort), "clientId");   mqttClient.onMessageArrived = onMessageArrived;   // connect the client   mqttClient.connect({            onSuccess: () => {              messagesReady = true;            }         });   // set callback handlers   mqttClient.onConnectionLost = (response) => {     //     messagesReady = false;     //     if (response.errorCode !== 0) {       console.log("onConnectionLost:"+response.errorMessage);     }     setTimeout(() => {             MQTTinitialize()            },1000); // try again in a second   }; }  

Setting up Subscription

With the connection ready, the client can subscribe to message channels, send messages on them, etc. Just a few routines can do most of the work necessary to connect panels with the MQTT pathways.

For the panel SPWA, the moment of subscription can be used to establish the association between the panel and the topic, the MCU identifier.

function panelSubcription(topic,panel) {     gTopicToPanel[topic] = panel;     gPanelToTopic[panel] = topic;     mqttClient.subscribe(topic); } 

Given that an MCU is publishing on its topic, the SPWA will receive a message. Here, the Paho message is unpacked. And, then the message is passed on into the application mechanics.

function onMessageArrived(pmessage) {   //   var topic = pmessage.destinationName;   var message = pmessage.payloadString;   //   var panel = gTopicToPanel[topic];   deliverToPanel(panel,message); } 

So, now all we need to do is create deliverToPanel which should be somewhat like the interval handler that we had before. However, the panel is clearly identified, and only the keyed data sent in the particular message may be updated.

function deliverToPanel(panel,message) {   var refall = panelApp.$ refs;   // all named children that panels   var pdata = refall[panel][0];  // off Vue translation, but it’s there.   var MCU_updates = JSON.parse(message);   for ( var ky in MCU_updates ) {     pdata[ky] = MCU_updates[ky]   } } 

This deliverToPanel function is abstract enough to allow any panel definition with any number of data points for animation.

Sending Messages

To complete the application loop between the MCU and the SPWA, we define a function to send a message.

function sendPanelMessage(panel,message) {     var topic = gPanelToTopic[panel];     var pmessage = new Paho.MQTT.Message(message);     pmessage.destinationName = topic;     mqttClient.send(pmessage); } 

The sendPanelMessage function does no more than sending the message out on the same topic pathway that the SPWA subscribes to.

As we plan to make the icon buttons responsible for bringing in some number of panels for a single cluster of MCU’s, there will be more than one panel to take care of. But, we keep in mind that each panel corresponds to a single MCU, so we have a one-one mapping, for which we may use two JavaScript maps for the map and the inverse.

So, when do we send messages? Usually, the panel application will send a message when it wants to change the state of the MCU.

Keeping The View (Vue) State In Sync With Devices

One of the great things about Vue is that it is very easy to keep the data model synchronized with the activity of the user, who may edit fields, click on buttons, use sliders, etc. One can be sure that button and field changes will be reflected immediately in the components’ data fields.

But, we want changes to fire off messages to the MCU as soon as the changes occur. So, we seek to make use of the interface events that Vue may govern. We seek to respond to such an event, but only after the Vue data model is ready with the current value.

I created another kind of panel, this one with a fairly artistic looking button (perhaps inspired by Jackson Pollock). And, I went about turning it into something whose click reports the state back to the panel that contains it. That was not so simple a process.

One thing that threw me off is that I had forgotten some of the oddities in managing SVG. I first tried to change the style string so that the display field of the CSS style would either be “None” or “something”. But, the browser never rewrote the styles string. But, as that was cumbersome, I tried changing the CSS class. That also had no effect. But, there the visibility attribute, which most of us recall from old HTML (version 1.0 perhaps), but that is very up to date in SVG. And, that works well. All, I had to do was to get the button click event to propagate.

Vue has designed properties to propagate in one direction, parent to child. So, to change data in the application, or in the panel, you have to send a change event to the parent. Then, you can change the data. The change of the data element controlling the button causes Vue to update the property affecting the visibility of the SVG element we have chosen to indicate state. Here is an example:

Each instance of the squiggly button panel is independent. So, some are ON and some are OFF.

This snippet of SVG contains the odd-looking yellow indicator:

<path      :visibility="stateView"      style="opacity:0.98000004;fill:#faea4a;fill-opacity:1;stroke:#eecd5c;stroke-width:1;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"        id="sunthing"        d="m -36.544616,12.266886 c 19.953088,17.062165 5.07961,-19.8251069 5.317463,8.531597 0.237853,28.356704 13.440044,-8.847959 -3.230451,10.779678 -16.670496,19.627638 14.254699,-2.017715 -11.652451,3.586456 -25.90715,5.60417 10.847826,19.889979 -8.095928,-1.546575 -18.943754,-21.436555 -1.177383,14.210702 -4.176821,-12.416207 -2.999438,-26.6269084 -17.110198,8.030902 2.14399,-8.927709 19.254188,-16.9586105 -19.075538,-8.0837048 9.448721,-5.4384245 28.52426,2.6452804 -9.707612,-11.6309807 10.245477,5.4311845 z"        transform="translate(78.340803,6.1372042)" /> 

The visibility is populated by stateView, a computed variable that maps the state boolean to a string for SVG.

Here is the panel component definition template:

<script type="text/x-template" id="mcu-control-panel-template">   <div>     <control-switch :state="bstate" v-on:changed="saveChanges" ></control-switch>     <gauge :level="fluidLevel" ></gauge>   </div> </script> 

And, this is the JavaScript definition of the Vue panel with its children as subcomponents:

var widgdef = {   data: function () {     var currentPanel = {  // at the top level, values controlling children       bstate : true,       fluidLevel : Math.round(Math.random()*100)     }     //     return currentPanel   },   template: '#mcu-control-panel-template',   methods: {     saveChanges: function() {  // in real life, there is more specificity       this.bstate = !this.bstate       relayToMCU(this.name,"button",this.bstate) // to be defined     }   },   components: {     'control-switch' : {  // the odd looking button       props: [’state'],       template: '#control-switch-template',  // for demo it is in the page.       computed: {         // you saw this in the SVG above.         stateView : function() {           return ( this.state ) ?  "visible" : "hidden"         }       },       methods : {         // the button handler is in the SVG template at the top.         stateChange : function () {  // can send           this.$ emit('changed');  // tell the parent. See on the template instance         }       }     },     'gauge' : { // some other nice bit of SVG       props: ['level'],       template: '#gauge-template'     }   } } 

So, now the mechanism for a single button embedded in a panel has been laid out. And, there has to be a hook for telling the MCU that something has taken place. It must be called immediately after the data state of the panel component has been updated. Let’s define it here:

function relayToMCU(panel,switchName,bstate) {   var message = switchName + ':' + bstate  // a on element parameter string.   sendPanelMessage(panel,message) } 

There is the state change on it’s way to hardware in just two lines of code.

But, this is a fairly simple case. Any switch can be viewed as a function call to a piece of hardware out in the world. So, the string might contain the switch name and several other data elements. So, the component method that registers change will have to have some custom handling in it in order that it might gather together all the pieces of data set on the panel and send them along in one command string. Even the command string is a little simple. If the MCU is quite small, the command string might have to be translated into a code. If the MCU has a great deal of capability, the command string might actually be a JSON structure or perhaps all the data that the panel hosts.

In this discussion, the buttons on the icon panel contain the name of the panel to fetch. That may also be fairly simplified as well. It seems to make sense that that parameter can stand for any panel that might be stored in an enterprises databases. But, perhaps it is some formula. Perhaps, information about the panel should be wrapped around the panel definition that we receive from the server. In any case, the basics can be easily expanded upon once certain headaches are out of the way, like making the SVG respond to clicks properly.

Conclusion

This discussion has laid out some basic steps and decisions that lead to the realization of a Single Page Web App (SPWA) that can interface with IoT devices. We now know how to get panels from a web server and turn them into MCU interface.

There is much more to this discussion with quite a few other discussions that may follow. Starting with Vue is one thing to think about. But, then there is the whole MCU story, which we have only briefly touched upon.

In particular, by selecting MQTT as a communication substrate, we assume that IoT devices on the other end can somehow be ruled by MQTT. But, that may not always be the case. Sometimes gateways are needed if MQTT is to gain access to a device with serial links or Bluetooth. Or, perhaps all one ever needs from on the web page is WebSockets. Nevertheless, we used MQTT as an example to show how Vue could both receive and send data while keeping its data state in sync with devices.

Once again we only have part of the story. This time it is for synchronization because the page should be able to deal with alerts and bother the user if something critical is happening. Sometimes messages can get lost. So, we have to have a mechanism for acknowledgments.

Finally, it is my opinion that Vue makes updating data upon receipt quite elegant. But, sending the state changes is not so straight forward. It does not seem to make the job much simpler than can be done with vanilla JavaScript. But, there is a way and it makes sense.

Perhaps a clean library can be built to make a universal set of components for all panels. The elements for making such libraries and having them stored in a database have been briefly mentioned. Tools that go beyond just making SVG pictures may have to be developed. In any case, there are likely many things that can be done for the next steps.

(dm, yk, il)

The IoT market is still in its early stages, but gathering steam. We are at a cusp in the history of IoT. Markets are quadrupling in the course of five years, 2015 to 2020. For web developers, this IoT growth is significant. There is already a great demand for IoT web techniques.

Many devices will be spread out geospatially, and its owners will desire remote control and management. Full web stacks must be made in order to create channels for teleoperation. Also, the interaction will be with one or more IoT devices at a time. The interaction must be in the real time of the physical world.

This discussion delves into the interface requirements using Vue.js as a catalyst and illustrates one method of webpage to device communication out of many subsitutions.

Here are some of the goals planned for this discussion:

1. Create a single page web app SPWA that hosts groups of IoT human-machine interfaces (we may call these “panel groups”);
2. Display lists of panel group identifiers as a result of querying a server;
3. Display the panels of a selected group as a result of a query;
4. Ensure that the panel display is loaded lazily and becomes animated quickly;
5. Ensure that panels synchronize with IoT devices.

IoT And The Rapid Growth Of Web Pages

The presentation of graphics for visualization and remote control of hardware along with synchronization of web pages with real-time physical processes are within the realm of web page problem solving inherent in this IoT future.

Many of us are beginning our search for IoT presentation techniques, but there are a few web standards along with a few presentation techniques that we can begin using now. As we explore these standards and techniques together, we can join this IoT wave.

Dashboards and data visualization are in demand. Furthermore, the demand for going beyond web pages that provide forms or display lists or textual content is high. The dashboards for IoT need to be pictographic, animated. Animations must be synchronized with real-time physical processes in order to provide a veridical view of machine state to users. Machine state, such as a flame burning or not, trumps application state and provides critical information to operators, perhaps even safety information.

The dashboards require more than the visualization of data. We have to keep in mind that the things part of IoT is devices that not only have sensors but also control interfaces. In hardware implementations, MCUs are extended with switches, threshold switches, parameter settings, and more. Still, web pages may take the place of those hardware control components.

Nothing new. Computer interfaces for hardware have been around for a long time, but the rapid growth of web page use for these interfaces is part of our present experience. WebRTC and Speech API are on a development path that started in 2012. WebSockets has been developing in a similar time frame.

IoT has been in our minds for a long time. IoT has been part of the human dialog since 1832. But, IoT and wireless as we are coming to know it was envisioned by Tesla around 1926. Forbes 2018 State of Iot tells us the current market focus for IoT. Of interest to web developers, the article calls out dashboards:

“IoT early adopters or advocates prioritize dashboards, reporting, IoT use cases that provide data streams integral to analytics, advanced visualization, and data mining.”

The IoT market is huge. This Market Size article gives a prediction for the number of devices that will appear: 2018: 23.14 billion ⇒ 2025: 75.44 billion. And, it attempts to put a financial figure on it: 2014: $ 2.99 trillion ⇒ 2020: $ 8.90 trillion. The demand for IoT skills will be the fastest growing: IoT in Demand.

As we develop clear interfaces for controlling and monitoring devices, we encounter a new problem for developing our interfaces. All the many billions of devices will be owned by many people (or organizations). Also, each person may own any number of devices. Perhaps even some of the devices will be shared.

Modern interfaces that have been made for machine controls often have a well-defined layout specific to a particular machine or installation of a few machines. For instance, in a smart house, a high-end system will have an LCD with panels for carefully placed devices. But, as we grow with the web version of IoT, there will be any number of panels for a dynamic and even mobile stream of devices.

The management of panels for devices becomes similar to managing social connections on social web sites.

“Our user interfaces will have to be dynamic in managing which highly animated real-time panel must be displayed at any one time for each particular user.”

The dashboard is a single page web app SPWA. And, we can imagine a database of panels. So, if a single user is going to access a number of panels and configurations for his devices strewn about the planet, the SPWA needs to access panel components on demand. The panels and some of their supporting JavaScript will have to load lazily.

“Our interfaces will have to work with web page frameworks that can allow incorporating asynchronous component bindings without reinitializing their frameworks.”

Let’s use Vue.js, WebSockets, MQTT, and SVG to make our step into the IoT market.

Recommended reading: Building An Interactive Infographic With Vue.js

High-Level Architecture For An IoT Web App

When designing the interface for the IoT web page, one always has many options. One option might be to dedicate one single page to one single device. The page might even be rendered on the server side. The server would have the job of querying the device to get its sensor values and then putting the values into the appropriate places in the HTML string.

Many of us are familiar with tools that allow HTML templates to be written with special markers that indicate where to put variable values. Seeing {{temperature}} in such a template tells us and the view engine to take the temperature queried from a device and replace the {{temperature}} symbol with it. So, after waiting for the server to query the device, the device responding, rendering the page, and delivering the page, the user will finally be able to see the temperature reported by the device.

For this page per device architecture, the user may then wish to send a command to the device. No problem, he can fill out an HTML form and submit. The server might even have a route just for the device, or perhaps a little more cleverly, a route for the type of device and device ID. The server would then translate the form data into a message to send to the device, write it to some device handler and wait for an acknowledgment. Then, the server may finally respond to the post request and tell the user that everything is fine with the device.

Many CMSs work in this way for updating blog entries and the like. Nothing seems strange about it. It seems that HTML over HTTP has always had the design for getting pages that have been rendered and for sending form data to be handled by the web server. What’s more, there are thousands of CMS’s to choose from. So, in order to get our IoT system up, it seems reasonable to wade through those thousands of CMS’s to see which one is right for the job. Or, we might apply one filter on CMS’s to start with.

We have to take the real-time nature of what we are dealing with into consideration. So, while HTML in its original form is quite good for many enterprise tasks, it needs a little help in order to become the delivery mechanism for IoT management. So, we need a CMS or custom web server that helps HTML do this IoT job. We can also just think of the server as we assume CMS’s provide server functionality. We just need to keep in mind that the server has to provide event-driven animation, so the page can’t be 100% finalized static print.

Here are some parameters that might guide choices for our device-linked web page, things that it should do:

1. Receive sensor data and other device status messages asynchronously;
2. Render the sensor data for the page in the client (almost corollary to 1);
3. Publish commands to a particular device or group of devices asynchronously;
4. Optionally send commands through the server or bypass it.
5. Securely maintain the ownership relationship between the device and the user;
6. Manage critical device operation by either not interfering or overriding.

The list comes to mind when thinking about just one page acting as the interface to a selected device. We want to be able to communicate with the device freely when it comes to commands and data.

As for the page, we need only ask the web server for it once. We would expect that the web server (or associated application) would provide a secure communication pathway. And, the pathway does not have to be through the server, or maybe it should avoid the server altogether as the server may have higher priority tasks other than taking care of one page’s communication for data coming from sensors.

In fact, we can imagine data coming in from a sensor once a second, and we would not expect the web server itself to provide a constant second by the second update for thousands of individual sensor streams multiplied by thousands of viewers. Of course, a web server can be partitioned or set up in a load balancing framework, but there are other services that are customized for sensor delivery and marshaling commands to hardware.

The web server will need to deliver some packet so that the page may establish secure communication channels with the device. We have to be careful about sending messages on channels that don’t provide some management of the kinds of messages going through. There has to be some knowledge as to whether a device is in a mode that can be interrupted or there may be a demand for user action if a device is out of control. So, the web server can help the client to obtain the appropriate resources which can know more about the device. Messaging could be done with something like an MQTT server. And, there could be some services for preparing the MQTT server that can be initiated when the user gains access to his panel via the web server.

Because of the physical world with its real-time requirements and because of additional security considerations, our diagram becomes a little different from the original.

We don’t get to stop here. Setting up a single page per device, even if it is responsive and handles communication well, is not what we asked for. We have to assume that a user will log in to his account and access his dashboard. From there, he will ask for some list of content projects (most likely projects he is working on). Each item in the list will refer to a number of resources. When he selects an item by clicking or tapping, he will gain access to a collection of panels, each of which will have some information about a particular resource or IoT device.

Any number of the panels delivered in response to the query generated as a result of the user’s interface action may be those panels that interact with live devices. So, as soon as a panel comes up, it will be expected to show real-time activity and to be able to send a command to a device.

How the panels are seen on the page is a design decision. They might be floating windows, or they might be boxes on a scrollable background. However that is presented, panels will be ticking off time, temperature, pressure, wind speed, or whatever else you can imagine. We expect the panels to be animated with respect to various graphic scales. Temperature can be presented as a thermometer, speed as a semicircular speed gauge, sound as a streaming waveform, and so on.

The web server has the job of delivering the right panels to the right user given queries to a database of panels and given that devices have to be physically available. What’s more, given that there will be many different kinds of devices, the panels for each device will likely be different. So, the web server should be able to deliver the pictographic information needed for rendering a panel. However, the HTML page for the dashboard should not have to be loaded with all the possible panels. There is no idea of how many there will be.

Here are some parameters that might guide choices for our dashboard page, things that it should do:

1. Present a way of selecting groups of related device panels;
2. Make use of simultaneous device communication mechanisms for some number of devices;
3. Activate device panels when the user requests them;
4. Incorporate lazily loaded graphics for unique panel designs;
5. Make use of security tokens and parameters with respect to each panel;
6. Maintain synchronicity with all devices under user inspection.

We can begin to see how the game changes, but in the world of dashboard design, the game has been changing a little bit here and there for some time. We just have to narrow ourselves down to some up to date and useful page development tools to get ourselves up and going.

Let’s start with how we can render the panels. This already seems like a big job. We are imagining many different kinds of panels. But, if you ever used a music DAW, you would see how they have used graphics to make panels look like the analog devices used by bands from long ago. All the panels in DAW’s are drawn by the plugins that operate on sound. In fact, a lot of those DAW’s plugins might use SVG to render their interfaces. So, we limit ourselves to handling SVG interfaces, which in turn can be any graphic we can imagine.

Choosing SVG For Panels

Of course, I like DAWs and would use that for an example, but SVG is a web page standard. SVG is a W3C standard. It is for carrying line drawings to the web pages. SVG used to be a second class citizen on the web page, required to live in iFrames. But, since HTML5, it has been a first class citizen. Perhaps, when SVG2 comes out, that it will be able to use form elements. For now, form elements are Foreign Objects in SVG. But, that should not stop us from making SVG the substrate for panels.

SVG can be drawn, stored for display, and it can be lazily loaded. In fact, as we explore the component system we will see that SVG can be used for component templates. In this discussion, we will be using Vue.js to make components for the panels.

Drawing SVG is not difficult, because there are many line drawing programs that are easy to get. If you spend the money, you can get Adobe Illustrator, which exports SVG. Inkscape has been a goto for SVG creation for some time. It is open source and works well on Linux, but can also be run on Mac and Windows. Then, there are several web page SVG editing programs that are open source, and some SaaS versions as well.

I have been looking around for an open-source web-based SVG editor. After some looking around, I came upon SVG-Edit. You can include it in your own web pages, perhaps if you are making an SVG based blog or something.

When you save your work to a file, SVG-Edit downloads it in your browser, and you can pick up the file from your download directory.

The picture I have drawn shows an AND gate controlling an integrator. That is not what one would usually expect to see in a panel for an MCU. The panel might have a button to feed one of the AND gate inputs, perhaps. Then it might have a display from an ADC that reads the output of the integrator. Perhaps that will be a line chart on a time axis. Most panels will have graphics that allow the user to relate to what is going on inside the MCU. And, if our circuit is going to live anywhere, it will be inside the MCU.

All the same, our electronic diagram can be used to discuss animation. What we want to do is take a look at the SVG and see where we can get at some of the DOM tags that we would like to change in some way. We can then animate the SVG by using a little vanilla JavaScript and a timer. Let’s make the AND gate blink in different colors.

The SVG that we are looking for is in the following code box. It doesn’t look very friendly for the programmer, although the user will be quite happy. Nevertheless, there are still some cues to go on for finding which DOM element we wish to operate on. First, most SVG drawing tools have a way of getting at object properties, in particular, the id attribute. SVG-Edit has a way, too. In the editor, select the AND gate and observe the toolbar. You will see a field for the id and the CSS class as well.

If you can’t get to an editing tool for some reason, you can open the SVG up in a browser and inspect the DOM. In any case, we have found that our gate had id = “svg_1”.

<svg width="640" height="480" xmlns="http://www.w3.org/2000/svg" xmlns:svg="http://www.w3.org/2000/svg">  <g class="layer">   <title>Layer 1</title>   <path d="m80.59881,87.020171l14.714795,0m-14.714793,-11.938687l14.714797,0.000004m-0.033867,-6.543869l0,24.758504c42.377882,2.221929 43.364812,-27.139117 0,-24.758504zm47.366321,12.333056l-15.303943,0m-48.188699,-6.489897l1.454753,0l0,1.454751l-1.454753,0l0,-1.454751zm-0.068425,11.869359l1.454753,0l0,1.454753l-1.454753,0l0,-1.454753zm63.545246,-6.089294l1.454751,0l0,1.454751l-1.454751,0l0,-1.454751z" fill="#FF0000" id="svg_1" stroke="#000000"/>   <path d="m48.58886,119.662231l18.234678,0l2.523043,-7.173309l4.128604,13.808613l4.587337,-13.987948l4.013933,13.808613l4.35797,-13.629278l4.35797,13.718944l2.408353,-6.72497l18.349357,0m-64.482612,-0.623112l1.515724,0l0,1.515728l-1.515724,0l0,-1.515728zm64.484275,-0.103111l1.515721,0l0,1.515728l-1.515721,0l0,-1.515728z" fill="#FF0000" id="svg_3" stroke="#000000" stroke-dasharray="null" stroke-linecap="null" stroke-linejoin="null" transform="rotate(90.3367 80.0675 119.304)"/>   <polygon cx="108.5" cy="79.5" edge="0" fill="#ffffff" id="svg_6" orient="x" shape="regularPoly" sides="3" strokeWidth="null" strokecolor="#000000"/>   <polygon cx="215.5" cy="192.5" edge="0" fill="#ffffff" id="svg_7" orient="x" shape="regularPoly" sides="3" strokeWidth="null" strokecolor="none"/>   <polygon cx="165.5" cy="164.5" edge="0" fill="#ffffff" id="svg_8" orient="x" shape="regularPoly" sides="3" strokeWidth="null" strokecolor="none"/>   <polygon cx="161.5" cy="138.5" edge="0" fill="#ffffff" id="svg_9" orient="x" shape="regularPoly" sides="3" strokeWidth="null" strokecolor="none"/>   <polygon cx="160.5" cy="161.5" edge="0" fill="#ffffff" id="svg_10" orient="x" shape="regularPoly" sides="3" strokeWidth="null" strokecolor="none"/>   <g id="svg_23">    <path d="m225.016923,53.008793l0,3.419331m-4.558966,-1.709666l9.11791,0m10.303228,4.235512l-25.770656,0m-34.429182,0l24.544724,0m0.220544,-4.058194l1.543807,0l0,8.164451l-1.543807,0l0,-8.164451zm7.939567,-4.473673l1.543805,0l0,16.999955l-1.543805,0l0,-16.999955zm-34.176663,8.126854l1.474036,0l0,0.747515l-1.474036,0l0,-0.747515zm61.677552,0.018809l1.474038,0l0,0.747515l-1.474038,0l0,-0.747515z" fill="#FF0000" id="svg_4" sides="3" stroke="#000000" stroke-dasharray="null" stroke-linecap="null" stroke-linejoin="null" stroke-width="null"/>    <polygon cx="171.5" cy="159.5" edge="43.256342" fill="#ffffff" id="svg_5" orient="x" points="223.47406005859375,91.5 186.01296997070312,113.128173828125 186.01296997070312,69.871826171875 223.47406005859375,91.5 " shape="regularPoly" sides="3" stroke="#000000" stroke-width="null" strokeWidth="null" strokecolor="#000000"/>    <line fill="none" id="svg_12" stroke="#000000" stroke-dasharray="null" stroke-linecap="null" stroke-linejoin="null" stroke-width="null" x1="171" x2="186" y1="103.5" y2="103.5"/>    <path d="m130.801817,80.659041l15.333707,0l2.12165,-4.564833l3.47178,8.787299l3.857534,-8.901421l3.375353,8.787299l3.664657,-8.673176l3.664657,8.730237l2.025206,-4.279526l15.430142,0m-54.224016,-0.396526l1.274586,0l0,0.964554l-1.274586,0l0,-0.964554zm54.225414,-0.065616l1.274584,0l0,0.964554l-1.274584,0l0,-0.964554z" fill="none" id="svg_14" stroke="#000000" stroke-dasharray="null" stroke-linecap="null" stroke-linejoin="null" stroke-width="null"/>    <line fill="none" id="svg_15" stroke="#000000" stroke-dasharray="null" stroke-linecap="null" stroke-linejoin="null" stroke-width="null" x1="171.5" x2="171.5" y1="103.75" y2="135.388167"/>    <line fill="none" id="svg_16" stroke="#000000" stroke-dasharray="null" stroke-linecap="null" stroke-linejoin="null" stroke-width="null" x1="177.75" x2="177.75" y1="58.75" y2="80.255951"/>    <line fill="none" id="svg_17" stroke="#000000" stroke-dasharray="null" stroke-linecap="null" stroke-linejoin="null" stroke-width="null" x1="223.75" x2="266.854524" y1="91.75" y2="91.75"/>    <line fill="none" id="svg_18" stroke="#000000" stroke-dasharray="null" stroke-linecap="null" stroke-linejoin="null" stroke-width="null" x1="241.75" x2="241.75" y1="59.75" y2="91.754167"/>    <line fill="none" id="svg_19" stroke="#000000" stroke-dasharray="null" stroke-linecap="null" stroke-linejoin="null" stroke-width="null" x1="168.25" x2="180.75" y1="135.75" y2="135.75"/>    <line fill="none" id="svg_20" stroke="#000000" stroke-dasharray="null" stroke-linecap="null" stroke-linejoin="null" stroke-width="null" x1="169.75" x2="179.25" y1="138.5" y2="138.5"/>    <line fill="none" id="svg_22" stroke="#000000" stroke-dasharray="null" stroke-linecap="null" stroke-linejoin="null" x1="171" x2="179.75" y1="141.25" y2="141.25"/>   </g>  </g>  </svg> 

All we need now is a little JavaScript. We do take note first that the element attribute “fill” is present. Then there is just the simple program that follows:

<html>     <head>     </head> <body>         <!-- ALL THE SVG FROM ABOVE GOES HERE --> </body> <html> </svg> <script>   // Set up a timer interval flash the color.   var gateElement = document.getElementById("svg_1");   if ( gateElement ) {       setInterval( () => {                     var fillC = gateElement.getAttribute("fill");                     gateElement.setAttribute("fill", (fillC == "#00FF00") ? "#FF0000" : "#00FF00" );                   }, 2000 )        } </script> 

Notice that what we have is a minimal HTML page. You can cut and paste the code into your favorite editor. And, then don’t forget to cut and paste the SVG to replace the comment. My version of Chrome requires the page to be HTML in order to have the JavaScript section. So, that is one browser still treating SVG as something separate. But, it is a long way from the <iframe> days.

If you cut and paste just right, you can bring up the page and see the AND gate go from red to green over and over.

Recommended reading: SVG Circle Decomposition To Paths

Building Panels From VUE Components

We are already on our way to making any single panel come alive, but if we want to manage large collections of panels in sensible ways, we would have our work cut out for us. That would especially be the case if we simply built on our first example.

While the first example shows us how we can asynchronously change an object view, it does not show us how to tie the view to the state of any data object let alone one that manages a machine. We can certainly understand how the setInterval demonstration can be replaced by a fetch handler, but we might not even get the state of a machine from the web server that serves the SVG containing page. Also, when we get the data, our programs are now required to know about the DOM structure of the given page.

Fortunately, frameworks such as Vue have become popular, and they can save us a lot of work.

It’s easy to find out about Vue. The Vue documentation is very accessible. So, if this discussion jumps too far ahead, then you may spend some time learning about Vue on its own web site. But, there are very good discussions within the Smashing pages. Krutie Patel wrote a stunning article on making an infographic. Souvik Sarkar tells us how to build a weather dashboard with Vue.

Group Selection of Related Panels

For the first step, we should address searching for groups of panels. One reason for doing this first is that it is at the framework level of our human interactions.

The user searches for something he is interested in. Perhaps he is interested in all the devices at locations in one town. Perhaps he has many batches of liquid products and he wants to narrow down to one type of product with each batch governed by a small collection of IoT devices. So, the user will first search to get a small list.

Here is the process:

1. Search for groups of panels by features/parameters.
2. View a list of icons representing groups.
3. Select an icon (click/tap).
4. Start using panels identified with the icon when they come up.

Another reason this is a good first step is that we can use Vue in its simplest form. No build tools needed. We will just include vue.js with a script tag in HTML. In fact, we don’t even have to download it. There is a site where a working copy of vue.js is being served.

All we need is the following tag:

<script src="https://cdn.jsdelivr.net/npm/vue@2.6.7/dist/vue.js"></script> 

I copied the script tag directly from the Vue documentation about installation.

Now, we need a web page that can load icons and make them into something that clicks. Vue makes that very easy. In fact, I just wrote a little app to manage a Twitter list using Vue. It just manages text fields. As it is a tiny bit simpler than an SPWA using icons, we can have a look at it and then change it to be our desired single page app framework.

Here is part of what the page looks like:

This looks like a fairly simple page. Each outer numerical entry is a time slot with one or two tweets in it. The second tweet is optional. If you edit a tweet, Vue mechanisms update a JavaScript object. This page leaves it up to the user to click the “update entries” button to tell the server that something has changed, via its button handler function.

In order for the button handler to relay data to the server, it must change the Vue data object into a JSON string. Now, you may wonder just how difficult translating a Vue object to JSON will be. It turns out to be one line of code. You can find the line in the following source code, but if you want to find it faster, it is highlighted in the paragraph after the source code.

The page looks simple. Looks can be deceiving. Of course, the page looks simple, but is the code simple? Yes, indeed it is! Using Vue, the page manages the contents of the fields almost magically. Here is the code:

<!DOCTYPE html> <html lang="en" prefix="og: http://ogp.me/ns#">   <!-- define microdata scope and type -->   <head itemscope itemtype="http://schema.org/Article">         <title>Tweet Keeper</title>         <style>             body {                 margin: 2em;             }             .entryart {                 border: solid 1px navy;                 width: 80%;                 padding: 2px;                 padding-left: 6px;                 margin-bottom: 3px;                 background-color: #EEF4EE;             }         </style>         <script src="https://cdn.jsdelivr.net/npm/vue@2.6.7/dist/vue.js"></script>     </head>     <body onload="GetTweets()">  <!-- some old fashioned handling -->          <!-- The Vue app starts here. This is the HTML part of the Vue object -->         <div id="tweetAppDiv">  <!-- Recognize the name from the Vue doc -->             <div itemscope itemtype="http://schema.org/Article">                 <h1 itemprop="name">mangage tweets</h1>                 <p itemprop="description">My personal Tweet engine.                 This page accesses a personal tweet page that belongs to {{tweetOwner}}.</p> <!-- {{tweetOwner}} is in the data model. -->                 <button onclick="sendTweets(event)">Update Entries</button>             </div>                        <!-- Here is a Vue loop for generating a lit -->           <ol>             <li v-for="tweet in tweets">                 <!-- here is the first tweet represented as an object with a lable and tweet text -->                 <div class="entryart">                     <input v-model="tweet.def[0].label" />                     <input style="width:40%" v-model="tweet.def[0].tweet" />                 </div>                 <!-- here is the second tweet in the slot. But, notice that it is optional.  -->                 <div class="entryart" v-if="tweet.def.length > 1">                     <input v-model="tweet.def[1].label"/>                     <input style="width:40%" v-model="tweet.def[1].tweet"/>                 </div>             </li>           </ol>         </div>         <script>             var twtApp = new Vue({                                   el: '#tweetAppDiv',                                   data: {                                     tweets: [  // Where is the data? Still on the server.s                                     ],                                     tweetOwner : "Lucky Dude"  // picked a name for demo                                   }                             });         </script>     </body> </html> <script>          // Notice that you don’t have to do everything in the Vue framework.     // Here we are using some native API calls          var gDefaultPostInfo = {  // there server is beyond simple - an example from node.js docs         method: 'POST', // or 'PUT'         mode: "cors", // no-cors, cors, *same-origin         cache: "no-cache", // *default, no-cache, reload, force-cache, only-if-cached         credentials: "same-origin", // include, *same-origin, omit         redirect: "follow", // manual, *follow, error         referrer: "no-referrer", // no-referrer, *client                  body: "",         headers:{             'Content-Type': 'application/json'         }     } // // // recall the "onload" function GetTweets(event) {     var url = "http://localhost:8080/twitlist1.json"   // We have a fixed file name.     fetch(url).then((response) => {  // this is now browser native                     response.text().then((text) => {                                          var newData = JSON.parse(text);  // DATA UPDATE! This is it.                                          twtApp.tweets = newData   // the page update right away with new data.                                     });                     }); }  function sendTweets() {  // recall the button up above. This is not a Vue style button, but still in the Vue app.     var url = "http://localhost:8080/"     var data = twtApp.tweets;  // GET THE DATA OUT OF VUE. That’s all folks.     //     // so happens that Vue pulls out the right data and stringifies it.     var jdata = JSON.stringify(data); // data can be `string` or {object}!     //     gDefaultPostInfo.body = jdata;  // that’s for fetch - not Vue related     //     fetch(url,gDefaultPostInfo).then(res => {  // We use fetch to POST as well as GET                                         res.json()                                    }).then(response => {                                         console.log('Success:', JSON.stringify(response)) // promises                                    }).catch(error => {                                         console.error('Error:', error)                                    }); } // // //  </script> 

So, just to highlight the amazing lines that speak to the power of the framework, let’s repeat here:

A. This is pulling the data out.

postOptionsObject.body = JSON.stringify(twtApp.tweets); 

B. This is putting the data into Vue and seeing the screen update:

twtApp.tweets = JSON.parse(text)  // text is the server response 

How much work is that?

It looks like there is going to be a nice way to express how data will update panels for IoT.

Now, let’s turn the tweets into clickable icons designed to fetch components from the web server.

From Tweets to Panel Fetching Icons

People like to use SVG for icons. They like that use for SVG more than for other things as far as I can tell. I am only going on the number of web sites that sell or give away icons made in SVG. The selling point is that line graphics has fewer bytes than images. And, if I were going to ask for lists of pictures with button-like behavior, I might have grabbed for PNGs or JPEGs in the days SVG was in iframes. But, we can even find libraries in the Vue contributor lists that help us to a serving of icons.

We can turn the tweets page into an icon list returned as a search result. Just a little code has to be changed. Of course, there are a few things to be careful about if we want SVG icons to be loaded as buttons. Vue provides mechanisms for putting HTML into the application. These mechanisms have to be used or DOM elements fetched from the server don’t get interpreted.

Here is the kind of rendering you can get from view if you follow your first impulse in creating a handlebars style variable location in the application DOM.

Here is the code that produces the result in the picture:

<div id="iconAppTry">           <div class="entryart" style="padding:4px">             <span class="oneItem" v-for="icon in iconList">                 {{icon}}             </span>           </div>         </div>         <script>             var iconApp = new Vue({                                   el: '#iconAppTry',                                   data: {                                     iconList: [  // Where is the data? Still on the server.                                     ],                                     queryToken : "Thermo Batches"  // picked a name for demo                                   }                             });         </script> 

Notice that we have gone from looping over tweets to looping over icons. tweet in tweets changed into icon in iconList. Our twtApp hooks into the DOM element #tweetAppDiv, while our iconApp hooks into the DOM element #iconAppTry. Within the Vue option object, the data subobject has a tweets in the first app, and iconList in the second. The fields are both empty arrays that receive data when the fetch routine does its job.

But, we have imitated our tweet app too closely. In the code above, the iconList is an array, and the server is expected to send an array of strings. So, let’s say the server has sent us HTML, and we have it properly decoded with the array assigned to data.iconList. Then, the picture above can be seen.

Now, let’s change the code just a little. In this revised code, we can see the following:

v-html="icon">

Vue responds to the v-html syntax by putting in the DOM of the icon element. Notice that the syntax is included after the loop directive as another attribute to the span tag.

By removing the handlebars syntax and using v-html, our picture changes to something more comprehensible:

 <div id="iconAppTry2">           <div class="entryart" style="padding:4px">             <span class="oneItem" v-for="icon in iconList" v-html="icon">             </span>           </div>         </div>         <script>             var iconApp = new Vue({                                   el: '#iconAppTry2',                                   data: {                                     iconList: [  // Where is the data? Still on the server.                                     ],                                     queryToken : "Thermo Batches"  // picked a name for demo                                   }                             });         </script>                  

While v-html is a quick way to do things, the Vue team recommends using components to get the desired HTML into the page. That seems like a good idea, and we shall soon set about doing that.

But, let’s use the v-html syntax for our next example.

It’s time to set up our working example for fetching SVG icons. Let’s have those icons be responsive to a button click. Once those are working, we can get the panels associated with an icon.

Let’s suppose that the SVG required for icons is stored in a database. For our example, we can just fetch a JSON file from the server. The grown-up version of the icon server would store many such files in a database, and deliver them to the page with the same mechanisms.

Also, it’s best if the SVG arrives on the page URL encoded since we will be using JSON parse. The SVG can be decoded by calling JavaScript’s decodeURIComponent function.

In order to simulate the response to searching, we can make use of several JSON files. The page can have one button for each file. Here is the code for the page:

<!DOCTYPE html> <html lang="en" prefix="og: http://ogp.me/ns#">   <!-- define microdata scope and type -->   <head itemscope itemtype="http://schema.org/Article">         <title>Search Bar</title>         <style>             body {                 margin: 2em;             }             div {                 margin: 6px;             }             .entryart {                 border: solid 1px navy;                 width: 80%;                 padding: 2px;                 padding-left: 6px;                 margin: 2px;                 margin-bottom: 3px;                 background-color: #EEF4EE;             }             .oneItem {                 background-color: #EEFFFF;                 margin: 2px;                 padding: 4px;                 border: solid 1px purple;             }         </style>         <script src="https://cdn.jsdelivr.net/npm/vue@2.6.7/dist/vue.js"></script>     </head>     <body>  <!-- some old fashioned handling -->          <!-- The Vue app starts here. This is the HTML part of the Vue object -->         <div id="iconAppTry">  <!-- Recognize the name from the Vue doc -->             <div>             <h2 itemprop="name">Request MCU Groups</h2>             <p itemprop="description">These are groups satistfying this query: {{queryToken}}.</p> <!-- {{tweetOwner}} is in the data model. -->             <button onclick="GetIcons(11)">Find All</button>             <button onclick="GetIcons(5)">Find 5 Point</button>             <button onclick="GetIcons(6)">Find 6 Point</button>             </div>            <!-- Here is a Vue loop for generating a lit -->           <div class="entryart" style="padding:4px">             <button v-for="iconEntry in iconList" @click="goGetPanel(iconEntry.name)" >                 <div v-html="iconEntry.icon">                 </div>             </button>           </div>         </div>         <script>             var iconApp = new Vue({                                   el: '#iconAppTry',                                   data: {                                     iconList: [  // Where is the data? Still on the server.                                     ],                                     queryToken : "Thermo Batches"  // picked a name for demo                                   },                                   methods : {                                       goGetPanel: (pname) => {                                           // `this` inside methods points to the Vue instance                                           alert('Hello ' + pname + '!')                                       }                                   }                             });         </script>     </body> </html> <script> // // recall the "onclick" on the <buttons> function GetIcons(points) {     // special file names instead of search parameters     //     var url = (points == 11) ? "http://localhost:8080/batchQuery-all.json"                              : ((points == 5) ? "http://localhost:8080/batchQuery-five.json" : "http://localhost:8080/batchQuery-six.json")               fetch(url).then((response) => {  // this is now browser native                     response.text().then((text) => {                                          var newData = JSON.parse(text);  // DATA UPDATE! This is it.                                          newData = newData.map(obj => {                                                                    obj.icon = decodeURIComponent(obj.icon);                                                                    return(obj)                                                                });                                          iconApp.iconList = newData;   // the page update right away with new data.                                     });                     });   }  </script> 

Here is one display of icons that have been fetched from the server:

The data being sent is an array with the following kind of structure:

{  "style" : {      "color" : "red",      "backgroundColor" : "yellow"  },  "icon" : svg1,  "name" : "thermos" }, 

Here, svg1 is SVG taken from a file. Of course, a righteous server would have taken the structure from a database, where the SVG would be stored in the structure.

Here is a snippet from the above code. This is the code that fetches the JSON and places the array of structures into the Vue app. You can see the promise structure of fetch in use. The text is parsed, and in the next line, the encoded SVG is decoded. One more line, and Vue updates the page. The number of buttons in the button bar will be equal to the length of the JSON array.

fetch(url).then((response) => {  // this is now browser native     response.text().then((text) => {              var newData = JSON.parse(text);  // DATA UPDATE! This is it.                 newData = newData.map(obj => {                            obj.icon = decodeURIComponent(obj.icon);                            return(obj)                        });              // the page update right away with new data.                iconApp.iconList = newData;           }); });  

Now, just two more snippets. The Vue app. The reader will notice that the @click directive has been included on the buttons. The data element, iconEntry.name, is passed to a method within quotes.

The method is defined within the Vue app:

<div class="entryart" style="padding:4px"> <button v-for="iconEntry in iconList" @click="goGetPanel(iconEntry.name)" >     <div v-html="iconEntry.icon">     </div> </button> </div> </div> 

Here is the snippet for the definition of methods. The methods object is added just after the data object within the app parameter object:

, methods: {   goGetPanel: (pname) => {       // `this` inside methods points to the Vue instance       alert('Hello ' + pname + '!')   } } 

The reader should find the goGetPanel definition, and the use of it was pointed out for the @click handler. In our final application, the alert call can be replaced by a function that fetches panels from the server.

A Component Library For IoT Panels

We could just decide that panels that we fetch from the server can be HMTL or just SVG drawings, but if there are going to be many kinds of panels, we would hope that the job of creating panels could be simplified by having libraries of components to choose from. We can imagine that SVG editors could be improved to allow library components to be dropped onto pictures as part of editing. Then, if the SVG editor could output a version of the picture with component tags, then the use of Vue would allow the picture to be created while ensuring that the JavaScript automation and animation is neatly woven together. For our discussion, some hand editing can help us get there.

If we want to create panels out of Vue components, then we had better figure out how to make the components and then collect them together into something useful. We will have to switch to using command line tools provided by Vue and organize our workflow.

Components

The Vue documentation points out that the component data section (subobject) of the component definition needs to be a function that returns data. The reason for this is that Vue needs to keep data separate among the instances. So, in going from a Vue application initialization to a component definition there is another small code change.

In this first snippet of code a Vue application is being initialized:

var iconApp = new Vue({       el: '#iconApp',       data: {  // this is the data field that can be easily updated       },       methods : {         ...       } }); 

In this new snippet of code, a component is being defined and registered. First, notice that instead of creating a new Vue instance, a component named iconic is being registered. Then, the data field returns custom data for any iconic instance that the Vue app makes. Finally, the template field is present at the end of the component registration. Any HTML that might have been written on the web page to display the component can be part of the template.

Vue.component('iconic',           data: () => {              var instanceData = {                 // data fields named for the                  // variables appearing in the template                 onevar : "test"             }             return(instanceData);           },           methods : {             ...           },           template: '<div>This appears in every instance {{onevar}}</div>'     }); 

So, we can imagine a panel with thermometers. So, if someone provided a thermometer component, we would expect a component definition somewhere in our code. As such:

Vue.component('thermometer',           data: () => {              var instanceData = {                 // data fields named for the                  // variables appearing in the template                 temperature : 0             }             return(instanceData);           },           methods : {             ...           },           template: '<div>Some SVG will go here</div>'     }); 

We are trying to create something that looks like this:

The thermometer component is very similar to the first components that you will come across in the Vue tutorials. But, it’s a little tricky to figure out how to update it. There is a better way of defining the component for reactivity using properties. And, that is in the following:

Vue.component('thermometer', {     props: ['temperature'],     computed : {         y: function() {             var t = this.temperature/100;             var h = 54.724472;             var y_bar = 41.176476  // starts near the top             // pretend the scale is 1 to 100, so that the temperature is a precentage             return((1 - t)*h + y_bar)         },         height : function() {             var t = this.temperature/100;             var h = 54.724472; // as high as the whole range             var y_bar = 41.176476             // pretend the scale is 1 to 100, so that the temperature is a precentage             return(t*h)         }     },     template: '#thermometer-template' }) 

So, instead of representing temperature as a data element. It is represented as a property under props. Then, there is a new section, computed, that provides variables that are functions of the property. We see this.temperature being used for both y and height. These computed variables are being used in the SVG as attributes for a rectangle.

In SVG, y grows from the top down. So, when we want the rectangle to be small at the bottom of the thermometer, the y of the red box has to be lower, and the height has to be reduced so that (y + height) stays at the thermometer zero.

Notice the template field in the definition of the components. It is in fact, a document element ID. The element being referred to is a script section with the special type: type="text/x-template". The script element is where the SVG for the thermometers is. And, the SVG makes use of Vue variables and control terms so that reactivity can be defined.

Here is some of the SVG:

<script type="text/x-template" id="thermometer-template"> <svg    xmlns:svg="http://www.w3.org/2000/svg"    xmlns="http://www.w3.org/2000/svg"    width="20"    height="70"    version="1.1"   >   <g transform="translate(0,-180)">     <g transform="matrix(2.0111869,0,0,1.0489665,-215.11053,144.5592)">       <rect          style="fill:#fffcfc;stroke:#000000;stroke-width:0.68848258;stroke-miterlimit:4;stroke-dasharray:none"          stroke-linecap="null" stroke-linejoin="null" width="2.9665921" height="54.724472" x="111.90748" y="41.176476" />       <rect          style="fill:#e82b0d;stroke:#000000;stroke-width:0.68848258;stroke-miterlimit:4;stroke-dasharray:none"          stroke-linecap="null"          stroke-linejoin="null"          width="2.9665921"          x="111.90748"          :height="height"          :y="y"       />       <g transform="matrix(0.76503813,0,0,1,26.586929,0)">         <line y2="57.306953" y1="57.306953" x2="113.15423" x1="107.22105" stroke-linejoin="null" stroke-linecap="null"            style="fill:none;stroke:#000000;stroke-width:0.787139;stroke-miterlimit:4;stroke-dasharray:none" />         <line y2="74.408356" y1="74.408356" x2="113.15423" x1="107.22105" stroke-linejoin="null" stroke-linecap="null"  

The reader can find id="thermometer-template" at the top, and looking further down to the rect elements, the computed variables can be found.

Here the variable uses are separated out. The Vue shorthand syntax for v-bind is in use, with :height="height" and the same for y:

 x="111.90748"          :height="height"          :y="y" 

When the parent of the SVG elements sets variables that act as input to the thermometer property temperature, Vue recalculates height and y. As a result, the position and height of the red box change.

It helps to have a listing of the Vue app that makes use of the thermometer.

<body>     <!-- The Vue app starts here. This is the HTML part of the Vue object -->     <div id="thermoApp">  <!-- Recognize the name from the Vue doc -->         <div>             <h2 itemprop="name">Set Temperature</h2>             <p itemprop="description">These are groups satistfying this query: {{queryToken}}.</p> <!-- {{tweetOwner}} is in the data model. -->             <button @click="updateTemp(50,50)">mid</button>             <button @click="updateTemp(20,80)">low</button>             <button @click="updateTemp(80,20)">high</button>         </div>                  <thermometer :temperature="temp1" ></thermometer>         <thermometer :temperature="temp2" ></thermometer>      </div>     <script>         var thermoApp = new Vue({                               el: '#thermoApp',                               data: {                                  temp1 : 30,                                 temp2 : 60,                                  queryToken : "HEAT"                               },                               methods : {                                   updateTemp: function (tval1,tval2) {                                         this.temp1 = tval1;                                         this.temp2 = tval2;                                   }                               }                         });     </script> </body> 

That is the whole thing. There are three buttons which call the updateTemp method of the thermoApp Vue application. The data section has two temperature variables. And, each thermometer updates its temperature when the values change.

The code for the two thermometers called out below can be found on the HTML assigned to the Vue app.

<thermometer :temperature="temp1" ></thermometer>         <thermometer :temperature="temp2" ></thermometer> 

Notice that application uses the function formalism for the method definition. Defining updateTemp this way updateTemp: function (tval1,tval2) allows for the instance variable this to be accessed.

Also, defining updateTemp this way updateTemp: (tval1,tval2) => assigns this to an internal data structure that does not react and update the view.

Assembling a Panel

Each IoT panel can be a component. Vue provides a way of defining components with subcomponents. Alternatively, there is a slot mechanism that can be used to yield a component that can wrap around any HTML content.

In the following few paragraphs, let’s look at making a panel out of subcomponents. There are two forms that follow quickly from our examples. In one case, the thermometers can be subcomponents called out in JavaScript. In another case, the components are defined independently but are mentioned in the HTML.

In both cases, the same HTML can be used for the template. Here is our panel as a template:

<script type="text/x-template" id="thermo-panel-template">     <div>         <thermometer :temperature="temp1" ></thermometer>         <thermometer :temperature="temp2" ></thermometer>     </div> </script> 

The only difference between the first detailing of the application is that a div element is surrounding the two thermometers. Vue will throw an error if the template is missing a top level DOM element. The div passes the Vue requirement, and the multiple elements may be included inside of it.

Now, we may see the two thermometers side by side. Passing the temperatures from the top to the final thermometer has values cascading down. At the top level, the panel joins the application when a single line is included in the application DOM.

<themo-panel :temp1="temp1" :temp2="temp2" ></themo-panel>

The template for the panel, although simple, seems to indicate that panels can be easily designed in term of components. It’s as if a language for just IoT components is possible.

Now, the template definition for the panel is simple enough. Here it is with the subcomponents defined independently:

Vue.component('thermo-panel', {               props: ['temp1','temp2'],               template: '#thermo-panel-template'             }); 

That is about as much as is required to make the panel functional. It is true that this version relies on a long list of properties for defining values to be updated as messages come into the page. But, this is a good start. Updating the data object at the top level does the job of animating the thermometers. However, as the panels become complicated, there may need to be another method for showing change.

Having made mention to the other ways of specifying subcomponents, for the panel, we should take a look at it. Here it is:

Vue.component('thermo-panel', {               props: ['temp1','temp2'],               template: '#thermo-panel-template',               components: {                 // a sub component for the labels                 'thermometer': {                   props: {                     temperature: Number,                   },                   template: '#thermometer-template',                   computed : {                     y: function() {                         var t = this.temperature/100;                         var h = 54.724472;                         var y_bar = 41.176476  // starts near the top                         // pretend the scale is 1 to 100, so that the temperature is a precentage                         return((1 - t)*h + y_bar)                     },                     height : function() {                         var t = this.temperature/100;                         var h = 54.724472; // as high as the whole range                         var y_bar = 41.176476                         // pretend the scale is 1 to 100, so that the temperature is a precentage                         return(t*h)                     }                   }               }             }         });  

There is certainly more code, but that is because the JavaScript for the thermometer component is included within the components list of thermo-panel. The two approaches do the same job, but they offer different ways of packaging component definitions.

At the moment, my preference is for the first way. It should be considerably easier to revise panels and have them retrieved dynamically if only changing template and properties is required. To this end, the independently defined components form a component library. But, although that seems better, in the following it becomes more convenient to use the second, seemingly more verbose way.

Given that we can make responsive panels out of components in clearly defined ways, I’ll explain how we can manage them as a database that can make simple queries in the next part of my article. Stay tuned!

(dm, yk, il)