In Figure 1, the procedure needed to create an SVG based Custom Widget into a Dashboard for IoT Control, is reported. The production starts with the creation of the SVG graphic design by using the Inkscape open source SVG Editor (https://inkscape.org/news/2020/05/04/introducing-inkscape-10/). The production of SVG with the editor has to follow a few of guidelines to be sure that the modality in which variables are defined into the SVG are in effect compatible with the successive steps and Snap4Industry tools. The guidelines are accessible on: https://www.snap4city.org/595 The SVG may: contain animations, visualize effects according to the value of some messages received, collect data from the users, be freely zoomed, provide transparent background, etc. The user may access to the SVG of the Custom Widget Templates to change them, and re-upload as modified / improved versions as well. In addition, they can be created by exploiting a large part of the market and open libraries of SVG symbols. Once the SVG of the Template is created, it can be uploaded into the Snap4City service which parses the file to identify the SVG variables in Writing and Reading. They can be integer, float, status, and strings. Thus, a Custom Widget Template is created as private of the user, according to GDPR, and can be shared with other users or published for all only by the owner.
Figure 1. The process for producing Custom Widgets into Dashboards for graphic nitration of IoT Control.
A Custom Widget Template can be instantiated for creating specific Custom Widgets/Synoptics. To this end, the identified variables in Reading and Writing have to be associated with some real variable in the system or directly connected with and IoT App. The processes and the different kinds of connections are discussed in the next section.
Please note that, Custom Widget/Synoptics are considered in the Snap4City environment a HighLevelType. So that, it is possible to select them as internal elements in the composition of a Widget for the Dashboards. Specifically the Custom Widgets are visualized in the External Content Widget and can be placed and recalled in Selector Web to change page / custom Widget when a set of pages are present. Then the dashboard widget into the External Content widget frame can be resized, coloured, etc., just changing the value of the external widget frame.
In the connection and interaction from Synoptic (read as SVG Custom Widgets) and the rest of the infrastructure, including IoT Apps and storage, there are 3 main Cases as depicted in Figure 2.
Figure 2. Connections with SVG Custom widget cases.
In Case 1, the data can be collected from the Synoptic via WS and saved (connected in writing) or read (connected in reading) directly into/from the storage (namely MyKPI or Sensors data for Snap4City terminology). This means that for changing the light intensity the IoT App writes into the storage and it is the storage that provokes an event in the WS for changing the lamp status. It implies that the velocity for closing the loop, round trip (moving the slider and observing the change on the lamp) depends on the velocity of writing/reading on/from the storage. Please note that when the slider is moved a new value is saved into the database of MyKPI and an event is created into the IoT App and to the WS of lamp connected. This approach increases a bit the velocity of the round trip. The IoT App use in this case specific storage Nodes of Snap4City to interfaces with WS and Storage. For this specific case, the presence of the IoT App is optional since the WS of the Slider can be connected to same MyKPI variable of the Lamp, thus closing the loop on storage cloud. With the aim of assessing performance, a series of messages have been saved into the MyKPI and thus they are automatically posted on WS for both slider and lamp (in fact the slider is producing a data but also reading the value if changes and move the slider accordingly). Thus, it has been possible to sustain without loss of messages up to 5 changes per second. Which means 10 WS messages per second (change the lamp and change the slider). Please note that the round loop is closed passing from the web page to the WS Server via internet and on IoT App on cloud, which generates the message. This means that the measure has been performed in real conditions and at the same time is influenced by the capabilities of the internet connection.
The dashboard of example is accessible from: https://www.snap4city.org/dashboardSmartCity/view/index.php?iddasboard=Mjc4NA==
Please note that the elements in the dashboard are: Alarm custom widget, slide custom widget, Lamp custom widget, and the classic snap4city widgets as: Button “Button1”, Single content names “Slider Value”.
The part on the left side: Alarm and button is independent on the rest. He other groups of Slider, SC and Lamp has a separate logic as explained below.
When Button1 is pressed a value 1/0 is written into a MyKPI variable which is automatically read by the Custom Widget Alarm above. So that the IOT App flow need is reported as below.
For the left side: button and alarm we have:
Where the function block is programmed as:
if (msg.payload==="On") msg.payload = { "value": 1 };
else msg.payload = { "value": 0 };
return msg;
The part on the right side of the Dashboard: Slides, Single content and Lamp widgets are connected each other. If the slider is changed the value is used to set the lamp and it is visualized on the Single Content widget.
The resulting flow is as follows, please note that the Slider is writing a value on a MyKPI and the same MyKPI is read by the Lamp without any setting on the IOT App. Thus, the flow only receives an event when the MyKPI is changed and the event is used to send the value to the Single Content:
The function block is used to adapt the message structure:
msg.payload=parseFloat(msg.payload.lastValue);
return msg;
In Case 2, the Synoptic is connected with the WS Server which can be read/written directly from specific Nodes of Snap4City for communicating with Synoptics. This modality has been added to speed up the process and the limit is imposed by the capabilities of WS server and Node-RED to manage event driven processes. In this case, it is possible to save the value in the storage but is not needed to read it again to close the loop that is closed into the Node-RED IoT App on cloud. With the aim of assessing the performance, the IoT App has been subscribed to the WS of the Slider and once the value it sends the value to Lamp and again on the slider with some random changes, so that to create an infinite loop. From the measures performed the round trip is performed at maximum of 20 changes per second without missing data. Which means 40 WS messages per second (change the lamp and change the slider). Please note that, also in this case, the round loop is closed passing from the web page to the WS Server via internet and on IoT App on cloud, which generates a random value on message at each round.
The dashboard of Case 2 example is accessible from:
https://www.snap4city.org/dashboardSmartCity/view/index.php?iddasboard=Mjc4NQ==
This case is a little more complex. The Dashboard contains 4 Custom Widgets: the switch, the alarm, the slide and the Lamp, plus a standard Widget Single Content for rendering the value of the Slider. Changing the Slider the value is set, and it is used to set the Lamp intensity. On the other hand, when the switch is changed to “ON” the Lamp, the Slider and the Single content are set at 100%, and the Alarm is set to blinking; when the Switch is changed to OFF the Lamp, the Slider and the Single Content are set to 0%, and the Alarm blinking is stopped.
The first part of the IOT App flow has the duty to subscribe to the messages which are produced by actions on the Switch and this event is propagated to the Alarm custom widget and to the Slider. Please note that two adapter function blocks have been used the first to set the value to 0/1, the second to scale it from 0/100 by using:
msg.payload = { "value": msg.payload.value*100 };
return msg;
Please note that as soon as the message is sent to the Slider variable S4csvg_val the event is also received by the subscription reported in the flow segment reported below. Thus, the event is propagated to the Lamp intensity and to the Single Content with other two adapters created with Function Blocks.
- Adapt to SC:
- msg.payload = msg.payload.lastValue;
- return msg;
- Adapt to Write
- msg.payload = { "value": msg.payload };
- return msg;
In Case 3, the Synoptics are connected with the WS Server that directly shortcut the reading with the writing and thus the loop is close in nearly real time. Please note that the round loop is closed passing from the web page to the WS Server via internet without the IoT App. The maximum number of messages per second without loss is about 2500 messages per second (3 sender and 1 receiver). On the other hand, this modality is only used for user interaction and may be used for closing the loop from two WS belonging to different parts of the supply chain, for example, an action in the plant and a visualization toward a different partners remotely connected.
The dashboard of Case 3 example is accessible from (the internal name is reported as case 4 for internal reasons): https://www.snap4city.org/dashboardSmartCity/view/index.php?iddasboard=MjgyNg==
Therefore, for connection synoptics with the IoT App, the MicroServices (of the Snap4City library on official Node-RED Palette) reported in Table I have been implemented. In addition, the Synoptics variables can be changed by connecting their corresponding WS to MyKPI or Sensors values of the Snap4City Snap4Industry platform directly in configuration/instantiation phase, see Figure 1.
Table I: MicroServices of IoT App for Synoptics
|
|
Subscribe at an event driven message provoked by the change of the value of a MyKPI. Send a message into the IoT App once a MyKPI is written. |
|
|
Subscribe at an event driven message and sent it into the IoT App once a Synoptic variable is written. |
|
|
|
|
|
Read the last message of a Synoptic variable. |
In the examples above, all the cases have been used except for the last one. Thus, an example is reported below. The example is used to read the value of the WS variable: s4csvg_switch_onoff.
In the development of solutions, the synoptics may use a mixt of the above-mentioned cases according to the needs in terms of velocity and of saving data changes on storage. In extreme IoT Edge configurations, the IoT App could receive IoT messages from IoT Brokers in push and the data can be directly sent on Synoptic without saving them on storage, or just saving a part of them by subsampling values. Thus, saving storage and at the same time making possible the data collection for machine learning and predictions is possible.
Please note that, all the above examples are working exploiting Custom Widget of the users, and MyKPI of the users. It is not possible to change variables value, neither WS variables nor MyKPI values of other users according to thee GDPR and thus to Snap4City solution.
