Nugeen Aftab: Hi, everyone. Thank you for joining the Deeper Dive webinar. It's now 1:02 Eastern, so we're going to go ahead and get started. My name is Nugeen Aftab, and I am the senior partnerships growth manager at Losant. Today, I'm really excited to have one of our partners, Lanner, with us. Their head of Americas business development for IoT, Ahmed Khalil, along with our own CPO, Brandon Cannaday, will be going through the dev kit and application template they built using the Losant platform. Our senior software engineer, Erin Thompson, and I will also be here to answer questions at the end. Before we get started, I want to address a couple of housekeeping items. This webinar is being recorded. And the replay will be made available to you in a few ways. After the webinar, it will send you an email with the link to the replay. And the webinar will also be made available on Losant's YouTube page as well as on our Deeper Dive web page. Throughout the webinar, you may have questions that you'd like to ask. I would like to point out a couple of key features in the Zoom conference. You can use the Q&A feature or the chat function to post questions, and I'll be monitoring those throughout the call. And at the end of the call, I'll moderate a Q&A session with the post questions. So, before we get into today's topic, let's do a quick review of Losant and our enterprise IoT platform. Losant is an application enablement platform. What that means is that we provide enterprises with the building blocks to create their own IoT applications. Our platform consists of five key components to help customers achieve that, end user experiences, visual workflow engine, data visualization, devices and data sources, and edge compute. Our customers and partners utilize these tools to create the robust IoT applications they put in front of their end users. Losant is a leader in the industrial telecommunications and smart environment spaces. We've offered this platform for all sorts of customers ranging from startups to companies in the Fortune 100. So, if you're interested in learning more, please reach out and we would be happy to set up some time for a much more in-depth conversation. Now, let's get into today's deeper dive, Modbus Edge Compute with Lanner. Great. So, while Losant provides the software foundation for IoT, there are many other components that have to come together to create an IoT application. So, we've surrounded ourselves with a great ecosystem of partners. This includes strategic partners with whom we share sales and go-to-market strategies, solutions partners who work with clients to develop end-to-end IoT applications. And lastly, technology partners that can provide hardware, connectivity, and other services to complete an IoT solution. That is where Lanner's application template comes in. In March 2020, we released significant functionality to our platform, application templates. These are pre-built templates to help a customer get their application to market more quickly. In previous Deeper Dives, we have showcased asset tracking, equipment monitoring, overall equipment effectiveness, and multiple other partner templates. If you've kept up with Losant's growth, you'll know that our template library including the full-fledged application templates are pivotal part of our IoT platform. Our vision is to make the process of creating end applications as easy as possible, which is why support from our partners is crucial. As we've continued to build out these application templates, we've also asked our partner ecosystem to contribute. Partner application templates are meant to simplify the integration process between Losant and our partners. This means having vendor-specific device recipes, workflows, and dashboards that make getting up and running much easier than ever before. Leveraging the integration work that Losant and our partners have already done helps you get your project started and finished even quicker. Today, we'll be discussing the application template that we've built with Lanner along with the accompanying Lanner development kit. This application template is now available for you to import into your application in Losant. Just click add to create a new application and you'll see the Lanner application template available. Now, I'm going to turn it over to Ahmed to tell us more about Lanner.
Ahmed Khalil: Thanks, Nugeen. And thank you, everybody, for joining us today. I think there's one slide for the introduction, Nugeen.
Nugeen Aftab: My bad.
Ahmed Khalil: Yeah, no problem. And just a quick overview of Lanner. So, Lanner is a global hardware manufacturer of networking products and industrial-grade edge computing systems. Company has about 35 years of experience designing, developing, and manufacturing custom-built hardware for well-known names in various industries including 500 Fortune-listed companies. Our manufacturing is in Taiwan with a global footprint through regional hubs. So, in North America, we have local sales engineering, project management, customer service, and distribution centers in Canada and US. And we do have a satellite office in Mexico. And we obviously comply with the internationally recognized quality certification standards that you would expect from a global manufacturer. Next slide, please. So, all the Lanner industrial-grade edge computing appliances are Intel-based. We are one of their IoT strategic alliances. The product is multifunctional, and it can support a broad range of use cases and different applications. So, Brandon today will show you a live example of the Modbus Edge Compute application template with the Lanner gateway. And what you see here in the slide, just some of the markets that combines different solution, the Lanner gateway and the Losant Edge application can be used for, for example, in process industries or asset-intensive industries like oil and gas. Very common use case using the Modbus communication, remote asset management, oil rates monitoring to optimize assets utilization, power utilities. Very common now with the advancements in the communication, the IEC-61850. You see an IPC-based substation automation. Workload consolidation and virtualization also using the custom-built hardware with a software to do electrical equipment monitoring, advanced predictive maintenance. One another example is the wastewater to use, again, the Modbus communication to gather vibration analysis data for tank [Inaudible 00:07:36], for example, to have a continuous monitoring of the structural integrity of the tanks. Manufacturing, so many use cases. The common ones are the vision systems, condition-based maintenance, overall equipment effectiveness. And then, now you see as the IoT can get expanded into industrial automation, you see those modern application like the digital twin. So, for example, that you could use now the Losant Edge Agent to aggregate the data. The Lanner hardware to run, for example, your virtual reality application or your digital twin for the process control, design, and simulation. Smart series, building automation, control security, video management system. And now, it's a lot more common now to see artificial intelligence-based capability built into the cameras for analytics and whatnot. And finally, in the transportation. Onboard computers for the mass transportation whether that public buses or a railway and a fleet management system. So, like I said, the devices and with the Losant application that you could do so many things as support and so many use cases. So, once we do the deeper dive in the application and understand the use case specifics, we can recommend the hardware solution with the Losant Edge Agent pre-installed as a turnkey supply, like Brandon is going to show you right after I finish here. Next slide, please, Nugeen. So, this is a good example here, the model 7242. Like I said, we have different models. But this one, we've tested it. We've provisioned it on the Losant Edge Agent. It's a ready-to-ship solution that's powered by Intel Atom, the Apollo Lake platform. And it supports in a factory environment like the common interfaces, whether that's serial or Ethernet. And then, the communication side of things, it comes already prepackaged with Wi-Fi, Bluetooth, and cellular connectivity. In this particular model is actually pre-validated to the AT&T network. And now, we hear a lot about the IT and OT integration in cybersecurity being a massive concern. So, this model here, 7242, if the software can take advantage of that feature, it comes with a built-in Trusted Platform Module. And what it does is establish that hardware root of trust to verify the complete software stack, starting from the firmware. Like I said, the 7242 is already been provisioned to the Losant Edge Agent, so it pre-configured, ready to ship. We have them in stock. And we currently sponsor demo programs to facilitate fielded trials, pilot projects. I encourage all of you to go to our website. We have a Lanner corporate website, a dedicated page for the combined solution where you can go and read more on it. And you can also order them or even purchase. And then, of course, as a global manufacturer, we provide end-to-end product lifecycle management services from design, manufacture, to end of life. Next slide, please. This is here the last slide, just to give you an idea of the kind of products that we build for our partners. So, generally Lanner, a portfolio is organized in three different sets. The one that you see here in the top of the pyramid, this is more of platforms focused on virtualized computing and telecommunication environment, kind of more of the network function virtualization, software defined networks, telecommunication infrastructure, core data centers, those type of applications. And in the middle, this is your typical IT infrastructure appliances, also a lot of cybersecurity products, firewall. And one thing, actually, that differentiates Lanner from its peers that the company originally came actually from the cybersecurity business. So, as we work with our industrial customers and our partners, like Losant, we have very solid expertise in the cybersecurity side of things. So, it helps us that as we build the use case, also expand on that cyber security not only from a platform perspective but also at a fundamental level, like the hardware that you're using to run your application and integrate IT and OT. And then, the bottom here is what we're talking about, obviously, is the industrial computer for more demanding and harsh environment like manufacturing utilities. So, with that, I'm going to turn it over to Brandon to give you a quick overview of the Modbus and walk you through a live example of the edge compute application template.
Brandon Cannaday: All right. Thanks, Ahmed. Let me share my screen. All right. So, most of today's deeper dive is going to be centered on Losant's edge compute functionality. So, I thought it was probably wise to provide at least a quick overview of what edge compute is and our edge agent and how that works with gateway providers like Lanner. So, today is all about Modbus. However, our edge agent does have a number of other industrial connectors. So, if your environment contains equipment that may not be Modbus but maybe an other connector, a lot of the lessons and architecture and implementation I'm going to go through today will apply. So, definitely continue listening in and think about how some of these implementations can apply to your own equipment. But the Losant Edge Agent is a software runtime for our visual workflow engine. So, the workflows that I'll show a little bit later, they're designed in the browser, in the cloud, remotely deployed to gateways fielded anywhere around the world. And it's really any Linux capable gateway, we distribute our edge agent as Docker. And then, within that edge agent, it executes those workflows. And then, we have that number of built-in connectors right out of the box. And then, if we don't have a connector, since we are built on Docker, we do have the ability to communicate between Docker containers. It's very easy to bring in additional connectors through other Docker containers running on that same gateway. All right. Let's get into what Modbus is. It's a fairly old protocol, created in 1975...or 1979 by Modicon, which is now Schneider Electric. Modbus is now maintained by the Modbus Organization, kind of an independent entity maintains protocol, maintains the ecosystem. And really, it's a client-server communication mechanism. It's one of the most, if not the most, widely used protocol in industrial manufacturing. In terms of Losant, it is our most popular southbound connector. And one thing that's interesting is a lot of people kind of get the concept of the server and the client reversed in their minds. Especially the Modbus device is kind of a small sensor, they might think of it as a client. But Modbus devices are usually all acting as servers. And the gateway will be connecting to them as a client and in reading and writing the information. I think one of the reasons the Modbus protocol is so popular is because it's really simple. It's divided into a few function codes, either going to be reading some registers, writing some registers in those things called coils which are kind of just individual bits, kind of Boolean values on, off. And you're either going to read a register or write a couple of registers. So, in this case, we've got a small Modbus RTU sensor. I'm going to be actually showing how to interface with a few of those in a moment. The client, the gateways on the right, it's issuing a command function code three which is saying, "I want to read some Modbus registers and holding registers. I want to read those starting at address zero, and I'd like to read two of them." And really, the server just replies with that data. In this case, it's an array containing two of those registers. Modbus registers are always 16 bit integers. So, this is where you usually have some kind of data transformation that's required after you read the information. So, in this case, that Modbus sensor wants to send information with one decimal point of precision, basically a floating point number. But if all you have is 16 bit integers, you have to get creative in how you encode that data. So, what they do is they multiply by 10 and send it over the line. So, what we get back is 247,441. Then, the client, the application logic has to know to divide that by 10 to convert those back into decimal places. What Modbus does is describes how data is communicated between a client and a server. It does not describe what data is in each of those registers. Almost every Modbus device is different. So, one of the first things you have to do is go find the documentation that describes your specific Modbus equipment, describes what all those registers are describes, what date is in all those registers. Modbus only describes, "How do I exchange that information?" So, for example, here's a real world controller, a generator controller from Dynagen, who is another customer of Losant. This is their Modbus reference manual. This is the thing you'll try to find once you start interacting with your own Modbus equipment. So, if I scroll down a little bit, you'll see here's all those registers that this specific piece of equipment exposes. And address 4150 on this equipment, which is engine speed, may be something entirely different on a different device. So, these are all unique to the Modbus equipment you're interacting with. I'm not going to get too deep into the actual bits and bytes of the Modbus protocol. I do want to point out one interesting thing that certainly caught me when I was first starting Modbus is these addresses. It looks like the address might be 40,150. But in reality, what they do is they have address spaces for the different types of data that you can read. So, everything that starts with 40 is basically a holding register. And the address you'll use for engine speed will be 150. You can see if I switch to this page, you can see those address spaces here. So, that's just something to keep in mind when you start interacting with Modbus servers. You might look up the documentation. You'll see something that's like address 40,150. But in reality, you should just be using address 150. That's just a quick gotcha. It certainly hit me when I first started experimenting with Modbus. And it's likely get everyone else to. And then, a little bit about why gateways are required in the world of Modbus. A lot of people think, "Well, I have a Modbus TCP device. TCP is kind of a network protocol. Can't my device just talk straight to the cloud?" And while theoretically it can, really the security side is what blocks that from happening. So, Modbus devices are all servers, which means they accept inbound connections from a client. And the direction of these arrows in this graphic indicates the direction of the connection, who initiates the connection and in what direction. So, in normal IT security, you'd really never allow the cloud, basically open internet, from connecting inbound into your local network. That'd be a really big security problem. Basically, you're opening up devices in your private network to be accessed by anyone in the internet. But as long as you're in your local network, the private network, you can communicate with these devices. Modbus has no security, really, as part of the protocols. There's really no encryption as part of the protocol. But that's okay. As long as you're in your private network, your network implementation is what adds that layer of security. And every corporate network has likely the best practices. It's hard to get on a corporate network. That's how that security is implemented. So, the gateway is providing that bridge between the Modbus devices on your local network. Or if it's serial, it's physically connected to the gateway and then the cloud platform. So, the gateway initiates the connection to the server. It's the one requesting that information. And then, instead of an inbound connection from the cloud to the gateway, the gateway is making an outbound connection to the cloud. And that's a much more secure direction. Think about if you're sitting at your desk in your corporate office, anytime you navigate to a website, your browser then makes an outbound connection to the server hosting that website. And then, communication can flow back and forth. But the server hosting that website would never be able to reach into your network and make a connection to your browser. IT departments are very friendly, very happy with outbound connections like this. And this is generally what we find as an architecture once you start combining Modbus with IoT. And local network doesn't have to be a corporate network. It doesn't have to be your traditional network you think about in buildings. It can also be a very small network inside of a piece of equipment itself. So, think about industrial equipment out in the field, maybe a big generator behind hospitals, a very easy way to basically IoT enable that equipment is to do a retrofit, introduce a small gateway into that enclosure. It's directly connected to the controller. And then through cellular or whatever internet connectivity you can get, it can still make that outbound connection to the cloud. So, the local network describes either a facility or a building. And it can also describe what happens inside a piece of equipment itself. So, this point, let's start jumping into the application of template itself. This template is... I like to describe it more of a development kit. A little different than some of our other templates. Really, we've outlined everything that's necessary for you. And there's a shopping list in the README that you get. And if you go purchase these things, you have a full working development kit, all the workflows, dashboards, everything that work out of the box with a known source of Modbus data. As I mentioned, every Modbus data or source of data is a little different with different registers. So, what we really want to do was craft a known working...a development kit that you can start exploring inside your own environment. And then, as you learn how the edge agent works and Losant workflows work to interface with Modbus data, you can start modifying and expanding this template to suit your own requirements. So, what we really distribute out of the box here is obviously the Lanner gateway. You can reach out to them. It comes with the Losant Edge Agent pre-installed, makes it really easy to get up and running. We provide a link to an inexpensive just off-the-shelf Modbus RTU sensor. And then, we do provide a pretty simple Modbus TCP simulator. And this allows us to do a little more creative things like reading and writing Modbus registers. All right. Let's jump into Losant and start looking at these workflows. Getting access to the template is pretty straightforward. You can get the free developer sandbox that we offer. So, you don't have to talk to us, no credit card required, just jump to Losant and get a developer sandbox. And then, when you create a new application, you'll be presented this page. It has all of our application templates, including the new one I'm talking about today, which is the Modbus Edge Compute with Lanner. And once you create that as an application in your sandbox or organization, you'll be presented something looks like this. This README has all the instructions you'll need to get up and running. This is a pretty long one because there's some setup instructions for the gateway. There's some wiring instructions for that little Modbus sensor, how to connect it to the USB adapter, things like that. I'm not going to go through this step by step. You can certainly read that and follow those yourself. Most important things here at the top, all these required components. So, if you want to do everything that this template provides, here's your shopping list. It's the Lanner gateway, And we link right to the landing page they have for the Losant specific one. That inexpensive RTU sensor, these are just Amazon links. You've got the RS45 USB adapter, a simple DC power supply, some jumper cables and screwdrivers. You may have some of these already in your environment, so you don't have to go buy new ones. But this is just a nice little list if you want to go purchase all these and start exploring Modbus in your own environment. Another thing I will note is we are using the RS45 USB adapter. A lot of gateways, including this Lanner one, do have native support for RS45. I prefer to use the USB adapter because it makes something that's a little more versatile. Really any gateway that has a USB port can then access this serial device. You don't have to go find one that has a native 45 port on it. All right. Let's jump into this template. First, I'm going to go to the devices. How this application is architected uses a gateway and peripheral model. The gateway is an edge compute device that represents the Lanner gateway that's running the edge agent. And then, the template will come with two devices, one RTU sensor and one TCP sensor. I've actually expanded the template to include each because I wanted to show how the implementation that's put in place here is fairly dynamic, fairly flexible. You can introduce new peripherals without having to go deploy new edge workflows. So, I wanted to demonstrate that by adding a few more devices. Let's start a little bit with this gateway. So, this is really an out-of-the-box edge compute device. There's no tags, no attributes. All this gateway is doing and the workflows that's running on this gateway are reading information on behalf of the various Modbus peripherals and reporting those up to the cloud. Switching to the gateway itself. If you do get the Lanner one, there's a folder directly in the gateway from the factory that includes a lot of helpful files. There's a rules file for getting access to serial. There's a placeholder edge agent configuration file. There's a couple run commands for the Docker, and then a really nice full README. So, if you start here, everything you need will be provided right out of the box in this folder. If you use a different gateway... And this template does work with really any gateway capable of running the edge agent. You'll just have to follow our instructions in our documentation for setting up the edge agent, installing Docker, and everything required for that. So, let's now switch to an RTU device. I'll start by showing how to read Modbus RTU data. And then, we expand it. Because we have a simulator, we're able to do a little more interesting stuff that I'll talk about when I get to TCP. So, these RTU devices, they are peripherals. And they are associated with the Lanner gateway. And the gateway and peripheral model is mainly an access control mechanism. So, a Modbus RTU device, serial device, obviously has no ability to talk directly to the internet. So, it's not going to be connecting to Losant either through [Inaudible 00:28:58] or a REST API or anything like that. So, really, by associated with a gateway, we're telling Losant that this gateway is allowed to report state on behalf of this peripheral device. Down here in the tags, really important tag is the serial path. And I'll show in a little bit how that is used. But when the edge agent goes to read all the serial devices, it needs to know where is the serial interface. Every time you plug in a serial device into a Linux gateway, it's going to be mounted somewhere on the file system. And the edge agent needs to know where that is. So, we're using a serial path for that. And depending on your Linux distribution, I'm showing Ubuntu or any Debian-based system, they might be mounted slightly differently. But I can show what it looks like here. So, to find it, once you plug it in, in Linux, all devices just kind of show up under Dev. And it's going to be kind of just one of these, which isn't very useful. All these TTYUSB isn't very useful. You don't know which one is which. But pro tip here, Debian is really helpful and creates a symlink in the by-id folder. So, in this folder, you can... I'm going to just list these vertically. So, these folders you can see, it create symlinks back to that top of dev folder but now they're named by the unique ID for that serial device. This is really important if these devices are unplugged and plugged back in because Linux won't guarantee they show up with the same number here, these just increment. However, it's always guaranteed that these will be the same because they're actually named after the ID of the device itself. So, this is the path you'll need when you're looking for. When you're going through this template and you plug in that serial device, you want to look for the full path of that device in this folder. And that is what is put right here as the tag value. So, in my case, I have three devices. So, I have three different unique paths with serial interfaces. I'll go ahead and add that as a tag here in my device list. If you haven't seen this column editor, it's super nice. Definitely worth checking out. Yeah, I'm going to go ahead and add those in. So, we can see there's my three devices with my three different unique serial paths. And that sensor has temperature and humidity. Modbus registers temperature in Celsius and humidity as a percentage between 0 and 100. The Fahrenheit is just calculated in the edge workflow. When I read the Celsius, I just calculate the Fahrenheit and record both of them. And you can see a reading just came in through the device log here. So, I got humidity and temperature in both Celsius and Fahrenheit. All right. Let's jump to the workflow. So, here is the edge workflow that's running on this device. Looks pretty simple because it kind of is simple. What I've got here is a timer running every 90 seconds. This interval is up to you and how fast you need to read this data. For this template, it defaults to 90 seconds. And instead of having a bunch of hard coded nodes here for each of my individual peripherals, this is where that tag is used. And this is where some of that dynamic workflow implementation comes in. What I'm doing here is querying all of my peripherals that have the serial path tag. And I left the value blank because I just want all devices that have the tag regardless of their value. What's happening behind the scenes is when you associate peripherals with edge compute devices, Losant is synchronizing that information from the cloud to the edge agent. So, anytime you make a change, if the device is connected, it'll pretty much immediately get that update. If it's not connected, the next time it connects, the cloud platform will push all those peripherals to the edge agent device. That allows the edge workflow to query all of its peripherals even if it's running on a gateway separate from the cloud. Since I have three, this will result in three devices. And then, my loop node is looping over all three of those. In here is where the actual read occurs. This is the important node, the Modbus read node. Starting here, that's where I'm using the serial path tag. So, remember the tag on each of those devices is the full path to the serial interface. So, that's what the edge agent needs. All this information here is information specific to the serial device. So, depending on your device, these values may change. These are just the values for this specific sensor. Then, just like that diagram I showed a moment ago, this sensor has two registers starting at address zero. So, I'm doing one read instruction saying, "Read address zero, give me length two." And then if I pause this output, we'll see I've got my Modbus data and my values. And there are my two values. This is the math node. Most of the time, you will require some amount of data transformation after a Modbus read. These values are returned, multiplied by 10 so we can divide these back by 10 to get that 1 decimal place. And then, this is the equation to convert Celsius to Fahrenheit. This is a math node kind of doing some data transformation on the raw Modbus data in order to convert it to something we actually want to send to the cloud. Then, it's the device state node sending that up to the cloud. If you're not connected to device state node, we'll buffer all that and replay that once the connection is reestablished. And really, that's pretty much it for the Modbus RTU. The important takeaway here is to really think about utilizing that information that is synchronized between the cloud and the edge. So, now if I wanted to add a fourth or fifth peripheral, I don't have to change this edge workflow at all. I don't have to deploy anything else to all of my gateways. The next time this runs, as long as the gateway is connected or whenever it reconnects, it will pick up that new peripheral. And this node will start returning it and the loop will pick it up and start reading its information. Quick note on the loop here. A fairly recent addition to the platform, we did add the ability to do parallel loops. By default, prior to the update, all loops ran serially. So, that Modbus read, for whatever reason, maybe the Modbus server was a little slow and maybe it took a while to read that information. You could pretty easily hit the default timeout of a workflow, which is 60 seconds. So, if you're reading 100 peripherals and each 1 takes 1 second to read, you add all that up, you're already at 100 seconds. So, fairly recently, we added the parallel loop. And since this workflow doesn't really require anything, each loop iteration is independent. If I go back in here, each loop iteration is reading from a device and recording a state. They don't really need information about any of the other devices. This is a really good fit to run this loop in parallel. So, if you've been a Losant developer for a while and have an experience with the parallel loop, definitely worth checking out. And then, this template does come with a dashboard for the Modbus RTU. These devices only have the two data points, temperature and humidity, so really straightforward dashboard. I'm not going to dig into this. This is a pretty straightforward dashboard. All right. Switching over to Modbus TCP. A lot of this is the same, but what we did was we added a little bit of interactivity with the cloud and a little bit of local control to kind of show what else can be done with the edge agent and Modbus devices. So, running behind the scenes, I have my TCP simulator. And you'll find these simulator files in the application files once you use that template. There were two files index.js and a package JSON. If you're familiar with Node.JS, this will be very... You'll recognize this. If you're not familiar with node, you can go install Node. It's kind of like Python, just a runtime that allows you to run these scripts. And the simulator script is pretty simple, hopefully easy enough. If you've got a little bit of understanding of JavaScript, you can actually modify this and change what the simulator does to kind of experiment with different types of registers. Maybe you want to change this to more closely mimic your own equipment. But out of the box, it comes with three registers, temperature and humidity multiplied by 10. That's designed to just mimic the actual sensor that we have. And then, we added a third one that's basically running status, a 0 or 1. And this is one that we can do some interesting stuff with. Through local control, we can maybe turn off the device using an edge workflow based on sensor information. So, feel free to explore this script. It's only 50 lines long. You can play with this and modify this if you want. So, the Modbus TCP dashboard contains some ability to work with this information. And I need to restart my simulator. When you run the node script, it will launch, tell you it's running, and then print some useful information whenever a client connects and their activity. So, I have three Modbus TCP devices. They're all pointing to the same Modbus TCP server, which is why I get three client connects. And they're all doing basically the same thing. So, this input controls block on the top left, this allows us to change the values that the simulator is returning. So, we can send a Modbus write instruction to that device to override the default values. So, if I unlock this input controls block and I change the temperature up to 56, update those. Right now, I've got the read interval set to 5 seconds. So after a few seconds, refresh the dashboard and we can see my temperature just changed to 56. So, this allows us to kind of experiment and have control over that simulator. But we also implemented local control. So, we've got a running flag here that I can manually control. But there's an edge workflow that I'll show in a minute that has a rule that if the temperature that it reads ever exceeds 90 degrees, just automatically do a modbus write to set the running attribute or the running register to zero. And this kind of emulates a real world scenario where you may want to protect the equipment from damage. In this case, the temperature is getting really high. If that rule was not already in the controller, you can add that rule, introduce that rule using the edge workflow. So, what I'll do is I'll go ahead and update this value. I'll report that data as 94 degrees. Again, the read interval is every five seconds. It'll take just a moment to pick up that new rule. And then, we can see down here, the running attribute. That register was automatically set back to zero. So, first, let's check out the device. And then, I'll check out the workflows that are powering all of this. Very similar to the Modbus RTU device except instead of a serial port, we have an IP address and a port because now we're talking TCP/IP. So, whenever the edge agent needs to read that information, it needs to know where on the network is this thing located. And the attributes same. We've got the temperature in Celsius and Fahrenheit, humidity. And then, unique to the TCP device is that Boolean for whether or not it's running. All right. What I want to do now is let's trace through what happens when you... Let's switch back to this dashboard momentarily. When you click this update values button, what is happening behind the scenes in Losant. And that's this diagram right here. We've got a dashboard that has user input control block on it. When you click it, it essentially invokes an application workflow running in the cloud. And how those buttons work is it clicks a virtual button for you behind the scenes. And what that cloud workflow is doing, it's doing some data validation. And then, it's actually looking up the appropriate gateway to send a command to. The dashboard I'm looking at is for a peripheral. So, if I send the command to a peripheral, it's not going to go anywhere. The peripheral is not connected. It's not going to receive that. What I need, I need the gateway that is linked to that peripheral because the gateway is what needs to receive the command, perform some kind of action. So, the application workflow will send a command to the appropriate gateway. And that's going to trigger an edge workflow that will receive it. Another round of data validation and that will execute Modbus write that will go to the simulator, the actual Modbus server. And then, that will handle that write request however it needs to. All right. Now, let's come back to Losant and trace through that path. I'll start with going into the input controls block. I won't go through most of these. These are just controls that you can set up however you like. We have a number of controls available. The range sliders are for the temperature, humidity. The toggles for on and off. And then, what you do is you trigger an action using a button. So, nothing will happen until someone clicks a button. So, you can change the value on the sliders all you want. But until you click a button, no action will occur. So, in this case, my action is to trigger a workflow. As I mentioned, we're going to trigger application cloud workflow. The workflow name is update simulator. And then, what happens behind the scenes is it essentially clicks a virtual button in that workflow for you and passes this information. So, I'm passing it the ID of my peripheral. This is a context-driven dashboard. So, you can use the same dashboard to look at all three of my devices. So, I'm grabbing the ID that was passed into context. And then, I am passing the values of my other input controls. And where these labels come from is inside the controls. So, when you add something like this, like my toggle, you can define the template ID. So, that is the ID that you will reference there. Basically, you're naming the variable and that will contain the value. So, now, when that button is clicked, it's going to go and open up the cloud workflow and trigger this virtual button. So, now I'm in the update simulator application workflow. There's the button that that input controls block is going to click. Very, very important whenever you're accepting user input is to validate that input. And what I'm doing here is using the validate payload node to perform that validation. And you can provide the schema directly in line. But what I've done is added a global. It's because I'm also going to validate this on the edge because I'm sending a command to the edge. You really can't trust data, so you must validate whenever you can. So, I have the same schema. So, I didn't want to just duplicate in two places. So, I've defined it in the application globals. Let's go check that out real quick. Application globals. So, in this globals, I have a key named update command payload schema. And globals are also synchronized with edge agents unless you check that box. So, this is another great way to kind of share configuration between the cloud and the edge. So, instead of having to find this big JSON block or just JSON schema twice, I can just put it in the global and Losant will take care of synchronizing that automatically with the edge. I'm not going to go into a lot of details of the JSON validation schema. There's some pretty good resources out there. But essentially, what we're saying is I expect an object. It should have a property named running, that's a Boolean. It has another property named temperature_C that's a number between 100 and negative 100. Another property in humidity, it's a number between 0 and 100. And then, I want a peripheral that's a string. And then, all of those are required. So, this is a way to kind of validate payload data before continuing. So, returning to that workflow. We validate the payload. Here is now where we need to get the full device object for that peripheral. I'm doing that because I need the gateway ID. So, if I look up the peripheral that I just queried based on incoming ID, there's the idea I had in the workflow itself. But what I really wanted was the gateway ID because that's what I need to send a command to. That's what represents the edge agent. Make sure you found the device and then send it a command. So, here is the gateway ID. That's the edge agent that is linked to this peripheral. I'm sending the command named update. And I'm just going to re-encode the data right up here, this data. I'm just going to re-encode it and pass it right to that edge agent. Now, if we switch to the edge workflow for running or querying, interfacing with the Modbus TCP server and the simulator, right here is that command trigger. So, whenever a command is received by this edge agent, it will trigger a workflow. Doing a quick check. Did the command I received was it named update? Maybe some other command I don't know how to interpret was sent to me. In that case, the workflow ends and it just debugs a little message. In here is that duplicated validate payload. So, using the same globals object since Losant takes care of synchronizing this for you. You definitely want to use that wherever possible. So, if you start adding information to this, you don't need to go to the cloud workflow and update it there. And then, go to the edge workflow and update it there, and then go deploy all those all your devices. So, a really easy way to do stuff like that. Now, the peripheral object is what stores the port and address. So, I have the peripheral ID that came through the command. But what I need to do now is query it using that peripheral get node, query by device ID, and I'll get a the peripheral object. Now, I can do a Modbus write. I can connect using the TCP connection to the address and port for that peripheral. And then, I can write those three registers. This is a pretty cool feature here. These values, since I have templates, since I need to take that human readable value, in this case, something like 24 degrees, I have to multiply it by 10 because that's what the simulator expects. That's what's written to its registers. So, this is an example of a nested template. We have a great Deeper Dive called Advanced Templating that goes into a lot of these kind of features. So, definitely check that one out. But really, I'm multiplying what came in by 10. And then, I'm rounding it to 0 decimal places, doing the same thing for humidity. And then another interesting one down here is using a conditional inside the value because what I'm getting is a Boolean, true or false for running. But what I have to send to my Modbus device is a number. So, basically, if running, just send 1, else send 0. So, you can do some pretty interesting templates in these fields. And again, check out that other Deeper Dive for a much more in-depth explanation of our templating engine. So, that's accepting the command, that is this flow all the way through dashboard accepted user input. Application workflow, kind of looked up the appropriate edge agent to send it to. The edge workflow, we just saw triggers from that and then performs Modbus write. And that's picked up by the actual Modbus server. Now, the other part of this was that local control. So, if we come back to this dashboard... And if you recall, when the value was above 90 degrees, the running register was automatically written to 0. So, let's check out that workflow and see how that is done. Now, I've cranked up my interval here to 5 seconds. The template comes with 90 seconds, but I wanted a little bit more interactivity for the demo so we don't have to wait around for a minute and a half. Just like the Modbus RTU, it's doing the peripheral get. But instead of looking for every device with the serial path tag, it's getting every device with the address tag. Using a loop node again. Everything at the top is very similar. I'm using the address and port tags on the peripheral to know where to do my TCP connection. And then, reading the three registers. So, the RTU sensor had two registers, one for temporary, one humidity. This one has that third register for that running zero or one value. The math node to convert the data, reporting up as device state just like before. And then, these two nodes are the local control. This is where things are a little different. So, now I'm checking the temperature. Is the temperature greater than 90? Then, what I'm going to do is just do a Modbus write. And I already have the address and port, so I'm going to actually open another connection to that device. Perform the write on address 2, which is that running register. And I'm going to send it 0. So, this is offline local control. There's no cloud involved in this logic. That's a common problem when it comes to implement and control, especially for industrial settings. Your internet may go down. The latency between the cloud and your environment might be a little too high. So, all of this is done locally. And if you unplug the internet connection from this gateway, this workflow will still run, this rule will still apply. The cloud is not required to perform these actions. All right. And the last thing I want to touch on is a little bit about deploying. So, we've been looking at these workflows, but never really touched on how do I get it to the gateway. Use this button right up here, the deploy button. When I click that, it is going to... Let me go back to the develop. So, the develop version on edge workflows is kind of special. It's the only version you can edit. So, it's the version you're going to be actively editing, modifying, and implementing whatever logic is required. When you're ready to send that to gateways, you will hit the deploy button. And you can give it a version. And now, we default it to the current time. But most people might want to do something a little bit more standard. And then, you can deploy it to any number of edge devices. In this case, my application has one, but you could have hundreds or thousands all grouped together by a tag. And you can select a device tag down here. And then, Losant will ensure this version makes it to all of those gateways. And then, you can see all of your deployments and versions down here. So, in this case, I've got the one Lanner gateway, and that's the version that's deployed. Then, you've got a little control over it. You could change the version deploy to that gateway or you can remove the workflow from the gateway entirely. So, this is kind of your deployment and management side of the edge workflows once they're developed. And then debugging, you can remotely debug from really any gateway that is currently connected. Up here in the selector, you'll just choose your gateway. And then, the platform will open up that connection to the gateway, and any debug node that gets hit by the workflow will show up in the debug panel here. So, super convenient. If you've got a gateway out in the wild that might be doing something a little strange, you can go in there, kind of attach the debugger to it and see what's going on. So, that's really all I wanted to show today. Really, the core of this template is the workflows, these two workflows, the Modbus RTU and Modbus TCP workflows. For you, if you want to get started with this, this is really the best place to start. It's kind of go out, contact Lanner, get that gateway with Losant pre-installed, go acquire these other options. And then, you can enter your personal sandbox account or your organization, install this template, and then just follow these directions. And you should have a fully functional kind of Modbus development kit in your own environment. So, with that, I'm going to toss it back to Nugeen and finish this up and happy to answer all the Q&A.
Nugeen Aftab: Great. Thank you. All right. Thanks, Brandon. Thanks, Ahmed, for going through all of that today. We do have a couple of questions that have come in. Before that, I want to talk about this talk about the Save The Date for the next webinar. So, on May 25th, we have our next webinar. It's called Connect your PLC to Losant. I'm really excited for this one. But make sure to register for that on Losant.com/deeperdive. So, I'm really excited about this Lanner application template as well as the development kit as it really is an end-to-end IoT platform solution. With Lanner's extensive modular gateway designs and global scale, we're happy to be able to offer this integration to the Losant community. We do have a couple of questions that have come in around this offering. So, we'll get to those here in a second. If you do have questions as we're going through these, if you have more questions that pop up, please feel free to add them into the Q&A section or into the chat function. And I'll pass them on to the panelists. So, before we get into them, if you have any questions about this webinar or as you're getting started on your Losant journey, we have tons of resources to help. Losant University is a great starting point. And we also have great thorough documentation and active forums to help you on your journey with Losant. For reference on applications we have built, check out replays of our past Deeper Dives. And if you're ready to start building, try out one of our hands-on tutorials. So, now let's get into some of the questions. So, the first one that I have is actually for Erin. The question is, I noticed your Modbus node has a timeout field. How does that work when you have multiple read instructions?
Erin Thompson: Hey, guys, thanks for the question, Nugeen. So, when using a Modbus timeout on your node, first of all, it's always going to default to 30 seconds. I noticed that Brandon actually didn't have a template or a number in there. And so, by default, that would be 30 seconds for him. The Modbus node is slightly different than other nodes because you can pass multiple instructions for it. So, if you did have a timeout in there, that timeout is going to apply to each instruction, not the group of instructions. And that can be a little confusing. So, for instance, if my timeout is 10 seconds, it will wait a full 10 seconds to try and connect. And if it can't connect, it will timeout. But then if you had 5 instructions, then it will wait ultimately the full 10 seconds for each of those to actually complete and come back.
Nugeen Aftab: Got it. Okay. Thank you. The next question that we have... And actually, there are a couple of questions for you, Ahmed. The first is, are these devices Class 1, Div 2 certified? Can they be used outdoor without enclosure? Referring to, of course, the Losant 7242.
Ahmed Khalil: Sure. Good question. The 7242, which we now have pre-validated with the Losant Edge Agent, is designed for outdoor. And it can support the operating temperature minus 20 to 70 degrees Celsius. But it's not C1, D2. We have other models like the 6032, which is C1,D2. And the same concept, we can supply with the Losant Edge Agent pre-installed.
Nugeen Aftab: Great. Okay. And then, on that same line, what is the order of magnitude cost for the Lanner 7242 gateway?
Ahmed Khalil: For the 7242, it really depends on the final configuration in terms of the RAMs, the storage, and all other features. But a rough estimate is around the $600 per unit.
Nugeen Aftab: Okay. And lastly, around the actual hardware, what are the cellular capabilities of the Lanner 7242? Does it have support for LTE Cat 1 or LTE Cat M? What carriers are supported, the cellular option pre-certified, etc.?
Ahmed Khalil: Okay. 7242, 4G LTE. It's Cat 4. And it's pre-certified to AT&T. We have other models that could support Cat 6 and Cat 12. And they could come pre-certified to a PTCRB, Verizon, AT&T. But specifically, the 7242 is Cat 4, and it comes pre-certified to AT&T.
Nugeen Aftab: Great. Okay. Thank you very much. So, we don't have any other questions around the actual gateway itself. But we do have a couple of more questions for Erin. Are there any other Modbus features or updates coming down the line, Erin, that users should be expecting?
Erin Thompson: Yeah. So, we are actually reworking the Modbus node a little bit to make it more efficient for when you're connecting to the same Modbus instance across multiple workflows. So, now instead of every time that you use the Modbus node, it would make a new connection. It would run your instructions, whether it's reading or writing to registers. Now, it's going to actually share a connection between the nodes. So, if you have two workflows on the same edge agent and both are using the same Modbus connection, those will actually be shared between the nodes. So, it'll make your nodes or make the Modbus node a little more performant.
Nugeen Aftab: Fantastic. And then, one last question. What is the difference between MBUS and Modbus? Do you have any resources on that? And MBUS is used more on water meters, supposedly.
Erin Thompson: Yeah. So, I haven't done like a ton of research into MBUS as I have into Modbus, so I can't really get into the very technical details. But from my understanding of it is that MBUS is used particularly on meter readings. And it's particularly used a lot outside the US. And so, Modbus is used more widely across applications, as Brandon said earlier. So, I think that's why we started with Modbus on our edge agent but that doesn't mean that we couldn't add MBUS as a node onto our Docker edge agent.
Brandon Cannaday: Yeah. I can provide a little more clarity into that. So, MBUS is... For everyone out there that is familiar with the layers of networking one through seven. MBUS is layer one physical. So, it's really, really low down there on the stack. Really, it's kind of the physical layer, how do bits and bytes get over a wire between two pieces of equipment. Modbus is basically all the way at the top. It's an application layer. So, it describes registers in the protocol. And it can live on multiple transport protocols. So, we just showed TCP and RTU as transport protocols. So, MBUS has no defined transport application layers or something like that. So, it's really, really low level. So, slightly harder to work with than something like a Modbus since a Modbus is pretty high level. It's well-defined protocol that can run on lots of different transports on lots of different physical layers.
Nugeen Aftab: Thanks for that context, Brandon. The very last question we have is for Ahmed. How do we get in contact with you? Or if we want to go ahead and get a gateway, what's the best place to go?
Ahmed Khalil: Sure. I mean, we can share our contacts after the webinar with all the attendees. And to get the pre-validated gateway, I don't think we had the link, Nugeen, in the slides. But we can share that with the audience as well where they can just go order the unit online.
Nugeen Aftab: Yep, absolutely. I think Brandon just put into the chat as well...
Brandon Cannaday: Yeah.
Nugeen Aftab: ...a link to the bundled solution. So, you can reach out through there. And you can also buy the gateway from there as well.
Ahmed Khalil: Yep, if you just go to that link and there's a button up top that says buy now. And that way, they can just order one right away. And if we have it in stock, we should be able to deliver in one or two weeks.
Nugeen Aftab: Okay, fantastic. Thank you, everyone, for joining today. And thank you, Ahmed, Erin, and Brandon for providing some great insight into this application template. Once again, look forward to today's webinars replay. And thank you so much for tuning in. We'll see you on the next Deeper Dive.