Aidan Zebertavage: [Music] All right, everyone. It is now 1:02 PM. We're going to go ahead and get started. Thank you very much for joining this Deeper Dive webinar. If this is your first time joining us here at Losant for one of our Deep Dives, welcome, and if you're a returning attendee, welcome back. We're excited to have you all here with us today. My name is Aidan Zebertavage. I'm a member of Losant's Education Team, and I serve as our Technical Evangelist. Today, we are very lucky to have Adam Daniel, Losant's VP of Enterprise Solutions, with us, and he's going to be leading us through a topic that is extremely timely and relevant to today's environment which is contact tracing. The CDC has recommended contact tracing as a key strategy for preventing the further spread of COVID-19, and businesses of all types are looking for any and all ways to implement a contact tracing strategy and reopen their doors. Adam will take us through Losant's IoT-based contact tracing solution and speak to not only how enterprise can implement this strategy but also to highlight several benefits of an IoT-based contact tracing solution over some of the more typical mobile-based strategies that you may be familiar with. Afterwards, myself, Adam, and Brandon Cannaday, Losant's Chief Product Officer, will be available to participate in a Q&A here on the Zoom call. Just briefly before we get started, I wanted to touch on a few housekeeping items. For your awareness, this webinar is being recorded, and the replay will be made available to you in a couple different ways. After this webinar, we'll send you an email with a link to the replay. Additionally, the webinar will be made available on Losant's YouTube page as well as on our Deeper Dive webpage. Throughout today's webinar, you may have questions that you'd like to ask. I'd 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 then, at the end of the presentation, as I said, I'll moderate a Q&A session with the posted questions. If you do have to leave early, not a problem. The Q&A will also be posted as a PDF alongside the replay link after today's presentation. So, prior to handing it over to Adam to speak directly about today's contact tracing application, I'd like to do some level setting around Losant and our enterprise IoT platform, especially for those of you on the call who are new to Losant. Losant is an application enablement platform. What that means is that Losant provides enterprises with the building blocks to create their own IoT applications. The platform itself consists of five key components to help customers achieve that. They are edge compute, devices and data sources, data visualization, our visual workflow engine, and end-user experiences. I like to think of these as your building blocks to a full IoT solution. Our customers and partners utilize these tools to create the robust IoT applications that they then put in front of their end-users. Losant is a leader in the industrial, telecommunications, and smart environment spaces, and we've offered this platform to a range of customers including those in the Fortune 100. So, if you are interested in learning more beyond just today's Deep Dive, please reach out, and we'd be happy to set up some time for a much more in-depth discussion. 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. But today specifically, we are here to talk about contact tracing and using IoT to achieve that, and this is especially relevant to today's current business environment. The COVID-19 pandemic has greatly impacted all of our lives and will continue to do so, and enterprise will be challenged to manage their workforce through this pandemic for the foreseeable future. To understand Losant's approach to contact tracing, Adam's going to be taking us through the following. So, to start off, obviously, what is contact tracing? We're going to talk about what we're hearing from our customers about contact tracing and some of their concerns. We'll go into a higher-level, solution overview talking about Losant's approach to contact tracing prior to going into that Deep Dive into the Losant platform and understanding the application itself. And then finally, we'll wrap up with highlighting some of the benefits of our solution over some other strategies. So, really, with that, I'd like to hand it over to Adam to get the Deeper Dive underway. At this time, I'll let him share his screen and get started. Great.
Adam Daniel: Great. Thanks, Aidan. All right. Okay. All right, great. Thanks, Aidan. As Aidan mentioned, I'm Adam Daniel. I'm the VP of Enterprise Solutions at Losant and excited to talk to you guys about our approach to contact tracing. So, first, let's establish what contact tracing really is. Simply put, it is the process of identifying people who may have come in contact with a person that's infected with the COVID-19. Many experts believe this is a key tool that's needed to get the enterprises back to work and to help prevent the spread of COVID-19. So, this isn't really something that we set out to tackle. This was actually something that was brought to us from our existing customers. A number of customers are looking at what's out there from a point solution standpoint and noticed that there are some major concerns that they have in these four major areas: privacy, infrastructure, dependency on mobile devices, and the future, life after COVID. From a privacy standpoint, a lot of the solutions out there rely on real-time location systems, or RTLS, and let's face it, most employees don't want to be tracked. They're uncomfortable with the idea of being tracked all the time either by RTLS or GPS, which a lot of these point solutions depend on. Being able to track an XY coordinate within an enterprise space and compare that to other XY coordinates is a concern all around within the enterprise space. Whether I'm sitting at a desk in a conference room, in a cafeteria, or even in a bathroom, we want to be able to track where contacts happen but allow people to have that privacy as well. From an infrastructure standpoint, again, those RTLS systems require a lot of infrastructure. Some require access points or gateways every 40 feet to grid out in a grid pattern to allow that triangulation of XY coordinates, and the RTLS systems can be extremely expensive. The lower cost solutions may not even get the right resolution to get that coordinate system or the resolution to get the XY in an accurate manner. If you have existing infrastructure for Wi-Fi and access points, a rip and replace is not something you necessarily want to do in order to upgrade your infrastructure to support that. Also, from a multi-site enterprise, you may have different infrastructures across different sites, or some sites may not have any kind of infrastructure. So, a lot of these RTLS systems really are dependent on a heavy-duty infrastructure that's extremely costly. Another common concern with current solutions out there is mobile devices. A poll by Opinion Matters, a polling company, actually showed that 71% of Americans are not interested in installing any kind of mobile app on their devices for contact tracing, and in many work environments like construction and warehousing, mobile devices just aren't available, aren't on the person to provide that tracking. And then, life after COVID. What happens with this large investment? This infrastructure you put in place, platform and tags and gateways, what happens to all of that after COVID? Or, can they be repurposed for asset tracking or other purposes like person-down scenarios? What can we do with that? So, with all of these things in mind, we listened to our customers, and we put together this demo that I'm going to walk you through that we're currently piloting with a few. And it shows our approach and how we can positively address all of these issues. So, from an overview standpoint, there are a couple of key things here. One, we chose BLE tags. BLE tags are inexpensive for the most part compared to some of these ultrawideband or more expensive tags that can get up to the hundreds of dollar ranges for an individual tag. You know we could possibly get a tag down to four to seven dollars depending on volume and depending on the functionality of those tags. So, we started there. We also wanted to make sure that we didn't have a heavy infrastructure that had to be gridded out, and that really set the path for this solution. So, our solution is dependent on the tags communicating with each other. The BLE tags broadcast out specific information. Our demo tags that we have here that we just saw a picture of actually broadcast out more than just contact information. They broadcast out environmental and accelerometer information as well, so they could be used in different scenarios. Those tags are actually broadcasting out and listening for other tags nearby, and they're currently calibrated to collect information from an existing tag or from another tag within a two-meter range. No identifiable information is broadcast or saved on these tags. It is just the MAC address, just a unique ID for the tag itself. Every time a tag sees another tag, it records the timestamp, the signal strength, and the ID of that other tag and stores that in memory, currently up to 500 different contacts within one tag. Again, no reliance on a gateway at this point. At this point, we have a record of that tag within other tags. Now, we need to get it uploaded to the platform. So, as tags get within range of a gateway, and these gateways can be strategically located. They don't need to blanket an entire environment. So, we suggest maybe near an elevator or some kind of area like a cafeteria or vending machines where someone may stand or sit for a few seconds so we can scan the tag and download the contact information from that tag. From there, that information is then sent up to the platform. It's sent as it scans for tags so we get some environmental information, and then if we notice that the contact count on that tag is greater than zero, a special command is sent from the gateway to the tag to download that information in that contact list which is then sent to our platform and processed there. Downstream of the process a little bit, we're also running nightly reports using our notebook functionality where we capture the information, bring it into a notebook, execute some logic around it, and then output a 14-day contact list that can be used either in external systems, or I'll show you an experience that we've created that allows you to search for contacts moving forward. So, with that, I'll switch over to the platform, and we'll dive in here. Okay. So, if you're familiar with Losant, you know that devices are a key part of our platform. The devices allow us to basically represent physical objects since it's essentially a data model within our time series database. So, here we have four demo devices, and I'll click into one to explore a little bit more. Within those devices, we're using the MAC address of the device to capture or to name it, to reference it, and to search for it later. We're also using a couple key tags here. One is the type. We're tagging it as a contact tag, so if we have other tags or other devices within this application, we know this is specifically a contact tag. And here's an example of how we could associate an employee ID with a tag. Now, as I mentioned, privacy is a big concern, so we're not dependent on any employee information being in our platform. We can easily integrate with existing HR systems to bring information in or even to push information out. This is just an example of how you could use device tags to do this association here. Attributes define how we talk to or how we store the information from the devices into our database. Here, we've got contactTag, contactMac and RSSI, which is also the signal strength. Those are the key pieces of information around contact tracing, but we're also storing environmentals like battery power, transmission power, temperature, humidity, accelerometer. Acceleration could be, as I mentioned, a person-down scenario. We could use it so we can detect orientation possibly. With an additional gyroscope, we could make the person-down scenarios and actually, from a security standpoint or a safety standpoint, do additional processing of the information. These attributes are stored in our time series database that we can use in notebooks, on dashboards, within workflows to process the information further. Now, obviously, if you're deploying thousands and thousands of tags, you don't want to have to come in here and register every device independently, so that's where Device Recipes really come in handy. From a recipe standpoint, we've defined a contact tracing tag, and this is essentially a template that we can use to create other tags in the future. So, we've predefined some values for tags. We've pre-defined the attributes here within the recipe, and we can use this recipe and workflows, which I'll actually show. But you can also potentially import a list of tags as well with associated information like employee ID. So, if you already had deployed tags and you had MAC addresses with employee IDs and employee information associated with them, you can come up in here and say, "Create multiple devices," and upload a CSV with that information, and we can see here, we have the ability to add an employee ID as a tag right there. We'll come back to Device Recipes in a second when we're looking at the workflows. Right. So, the other key piece here is the workflow, and with our workflow engine, it allows us to easily respond to information coming in and out of the platform. In this case, we're just simply hooking it up to a webhook. To make things easy and to keep this demo simple, we have a webhook that the gateway is communicating directly to. This workflow shows that we're looking for two different paths on this webhook. State is used whenever a gateway scans or sees a tag out there in the field. So, an advertisement with specific information in it like the telemetry data, the environmentals, and the contact count. What we're doing here is we're taking that state information. We're looking up to see if a device exists with a MAC address that's coming in across this post. If the device is found, then we're going down here, and we're just doing a little cleanup on the data, removing things like the MAC address because we don't actually want to store that in State. That's being used as the device name instead. If the device is not found, then we skip over here to Device: Create, and you can see down here we're actually using a recipe to create that device on the fly. We're taking that information and putting it in, creating the name based off the MAC address, and then creating that device on the fly and saving the state ultimately. From a state standpoint, we're taking that information from the post, passing it straight into our Device: State node, and then capturing the output right here. So, very simple process to register a device on the fly. We don't have to pre-register any tags. It brings the information in, and we immediately have telemetry data. From a contact list standpoint, this is a little bit more complicated because we have to take a binary list of contact data that's coming in from the gateway and parse it. So, you'll see a function note here, and I won't go into all the details of this. But this is a function, a JavaScript, that allows us to parse the binary data, that comes in initially as Base64 encoded, and then break that out into each individual record and save that ultimately, into a state object that we then save on the Device: State. So, after the parsing, essentially, it's the same process. We look up the device. Is the device found? If not, create it. And here, the big difference is instead of one state, we're actually sending in multiple states. So, right here, this attribute or this value, working.state, is actually an array of individual states with individual timestamps because every single one of these contacts is a separate state. And to make that all clear, what we can do is we'll go back to Devices, and I'll show you an example of what that state information looks like. So, here's what /State on the webhook looks like. We're getting information saying it's coming from the gateway. We're seeing accelerometer data, environmental data, and contact count. When I get into the dashboards here, we can actually see what that contact information actually looks like. So, here's a full list of all the contacts made with all of the tags currently in this demo. We can see here's a timestamp. Here's the device that registered or that scanned and saw the initial tags, and then here's an array, JSON-encoded array, of the tags it actually saw with the associated RSSI. And again, this is calibrated to a two-meter range line of sight. If it saw multiple contacts, if it saw multiple tags, then there'll be additional tags here in this array. These over here in the list, we have a dashboard block that shows the tag list with just the names that are clickable. We also see the battery strength over here and the battery voltage, and we see right here 2.4 volts is pretty much the end of life for this battery. Since we're getting that information in a workflow, we can immediately send a message out to the person who owns the tag, that's responsible for the tag, maybe IT or facilities, whoever's ultimately responsible for changing the battery or recharging. We can immediately notify them based off this battery strength that the tag needs to be recharged or the battery replaced. So, if I go into the detail dashboard, we can see specifics around this tag. We can see the current battery. We can see the battery history over time. We can see the contact history over time, humidity, temperature, accelerometer. And we can see there was a big accelerometer change here, so probably the orientation of that tag changed. And then, we can see also the contact list for this specific device itself. So, back on the all tags, we saw everything. Here, we can see the contacts specifically for this tag. So, now that we have all of the information stored in our time series database, one thing that we need to do is actually generate a report. So, the CDC says that the incubation period for the virus is about two weeks. So, what we're going to do here is we're taking our notebook functionality and processing all of the contacts for the last two weeks and outputting that as a report. So, first, we need to go in and define what the notebook looks like. The input of a notebook allows us to define what kind of data we're going to consume, and here, in this case, we're bringing in Device Data for any of the devices that are tagged as type contactTag, again, going back to the device tags that we'd defined earlier both in the recipe and on the device. We want a time range of 14 days, and we're going to save this as the tag-data.csv. This then brings in the information into our notebook and allows us to process all contact information for the last 14 days. We're also bringing in information about the metadata of the device, so these are the additional tags in the name. Remember, we're saving the MAC address as the name of the device, so having access to the metadata is extremely important. With those two pieces of information, we can then use our notebooks to process and output a full contact list for those two weeks. So, I'm going to jump over to the notebook here and kind of go a little in-depth into how we're actually processing this information. Our notebooks are based off of Jupyter, which is pretty much the industry standard for notebook processing. This is a Python notebook. Here, we're importing some libraries that we're going to use throughout the process. Here, we're defining a simple function that's going to parse that JSON information that we saw coming into the Device: State. Here, we're loading our contacts file, contacted context file, and I'll show that here in just a second of how that's coming into the notebook. We defined two inputs, if you remember, back in the notebook definition within the platform. There was tagData and tagMeta. Here, we're reading in both of those CSVs. Here, we're reading in the tagData. We're defining what columns we're most concerned about, and if we switch over here real quick, we can actually see what that input looks like. So, here, we have the ID of the device. We have the timestamp associated with this record. We also have other information, acceleration. We have the battery. We have the contact count, humidity, all the environmentals and telemetry data that we saw on the Device: State. What we're really most concerned about is this column right here, contactMac address. So, we're only going to pull in the ID, which is the device ID, the timestamp, and the contactMac, and remember that contactMac is actually JSON. So, we're setting up a converter here to parse the JSON in that contactMac going back to this definition or function definition right here. Down here, we're actually bringing in the tagMeta information which is the meta information associated with the device itself, and if we skip over here, we can see what that data looks like. Here's the device ID. Here's the name, which again is the MAC address of the tag. We had the employee ID defined as a tag, and we also have the tag type. So, here's an example of how we can bring in an employee ID and use that within a notebook as well. We're just concerned right now about the ID and the name. Here, we're merging the two pieces of information based off the ID, so we're basically combining the name from the meta information with the timestamp and the contactMac of the telemetry data. Now, as I mentioned before, we're only concerned about the contactMac fields only, so what we're doing here is filtering out all of the rows that do not contain a MAC address for the contactMac. This is an interesting piece, the magic of pandas, which is the library that we're using here within the notebook. This function allows us to take a data frame and explode it. So, after we've parsed the JSON object to a JSON array from the contactMac, what that gives us is a JSON array within an actual column. What we want to do is explode that out so we get an unique row for every single one of those items in that array, and the data frame explode allows us to do that. And we'll see that in just a second how that outputs. Here, I'm just doing a little bit of cleanup. So, we're renaming some of the columns to MAC_2 and MAC_1, and then ultimately, we're going to drop the Device_ID column because we don't really need it anymore. And then, we're going to reset the indexes so it puts it in a nice order. Here, we're just writing the output to a CSV, and ultimately, what that report looks like is this. So, we can see it's a lot cleaner, a lot easier to understand. We have a simple timestamp. We have a single MAC address, and we have two MAC addresses that ultimately correspond to the contact that was made. All right. So, let's go back to our workflows and show how this, the notebook, actually gets executed. So, workflows allow you to respond to the information coming into the platform, but they also allow you to trigger based off of things like timers or notebook executions. So, here, we have a timer workflow that is set to execute every night at 11:59:59, and it's going to execute or run this notebook and pass in this context. And if we go back to the notebook real quick, we can see that we bring that context in as a JSON file that we read, and all it's doing is passing in the name of the file that we ultimately want to output and its contact trace report with a timestamp as a CSV. Here's another trigger that we kept inside this workflow as well that responds to the successful execution of that notebook. Here, we're parsing the context so we're getting that name out of the context. We're getting the URL that was defined that it saved the file as, and then we're creating an email that sends me nightly at about 12:02 because it takes about three minutes for the report in the notebook to run. I get an email that says, "A new contact tracing report is available," and it gives me a URL to that CSV file. So, at this point, we've got a URL or we've got an email with a URL, and then we also have a file that is a CSV saved in files that we can reference and search later on. Here we could send this CSV to an HR system to merge it potentially with external data. We could actually bring in external information from another HR system or from another IT system that has web services and combine the data. In this demo, all we're doing here is we're using this CSV in an experience, and this is a very basic experience that's pulling that actual CSV in and allows us to search it. And I'm not going to go into detail on building the experience out. We have another webinar that you can reference back if you're interested in experiences and work within the Losant platform and how to build it. Here, I'm bringing in the CSV, and then I know there's a tag that ends in 72:41, and here we can see I've filtered it out and it filters on either one of the columns here. And I can see over the last 14 days, there have been 1,500 contacts between 72:41 and at least one other tag out of 7,000 total entries. So, this is a really simple way to close the loop. I have the contact information. I've processed it on a nightly basis to give me the last 14 days, and now through experiences, I can come in here and I can search and look for any contacts that have happened. So, let me switch back over here. All right. Now that we've done the walkthrough, I just want to highlight a couple key areas around the benefits. No need for an RTLS infrastructure or mobile apps. Because the tags are communicating directly with each other, we can keep that infrastructure cost down, and as mentioned later in a later bullet here, with strategically placed gateways, we can further reduce the cost of infrastructure. No position information is actually needed or captured, so again, no XY coordinates. Even if the employee were to take the tag home, we're not actively tracking them. We're just looking at the interactions between tags and not any lat and long or XY position. No identifiable information is ever on the tag or transmitted over the network. We're just looking at tag IDs, and then ultimately, whether it's in the platform itself or with an external system, that association can be made. Solutions portable from site to site. If you have employees that go from maybe a construction site to office, you have the option of having gateways on both or on just one. The solution would be portable from site to site. Tags moving from sites can be picked up on a gateway from another site as well. And then, depending on the form factor and the tag technology, which I'll also point out that as a platform, we are hardware-agnostic. We are not dependent on any one tag. If the tag can have the custom firmware on it allowing it to search for other tags nearby, then we'll gladly use it in the solution and get information up and to our platform. So, all of these tags, the platform, and the gateways are potentially reusable after COVID in a asset-tracking solution or any other solution that BLE and gateways in a platform may apply. So, with that, I'm going to stop sharing and send it back over to Aidan, and we can do some Q&A.
Aidan: Awesome. Thank you, Adam. Let me share my screen here again. So, thank you very much for that, Adam. Before we do get into the Q&A, and I'll let Adam catch his breath a little bit after going into that Deep Dive, I do want to point everybody to a couple of educational resources that Losant has available. So, obviously, we have our documentation describing the functionality and how to use Losant at docs.losant.com, and when you're ready to take a bit of a deeper dive into learning how to use Losant, we offer Losant University, which is a great way to come up to speed on how to use the platform and get a better idea of all of the capability and application potential that the platform has. As Adam mentioned, we do have our historical Deep Dive series available as well. Specifically, we have a Deep Dive available on application experiences and really building up that final end-user-facing application portal for your customers to be able to access that data. So, you can find that at losant.com/deeperdive. And then, finally, I want to put in a plug for our blog. We have a numerous hands-on tutorials that show you, walk you through different applications and different hardware types using Losant. And then, finally, our forums are a great place to engage with the community and get answers to any sort of troubleshooting or Q&A sessions that you may want to utilize that for. So, if we are ready, we did get quite a few questions, and so I know Brandon and Adam are available to start working through these. So, I think our first main topic where we got quite a few questions was around the Bluetooth asset tags in general. So, the first question was, "Are these tags similar to the Milwaukee tool TICK or to The Tile tag?" and I believe, Brandon, you had an answer ready for that one.
Brandon Cannaday: Yeah, yeah. Thanks, Aidan. So, the tags themselves, the actual hardware that make up the tag, it's fairly similar as in it's a BLE tag kind of broadcasting some information. The solution behind it is quite a bit different. So, TICK and Tile both have a pretty creative way to determine the actual GPS location of a tag, but it requires the mobile app. So, what Adam was talking about a lot, in this solution, there's no mobile app requirement because we're not really tracking the physical location and GPS coordinates. We just need to know: Were two tags close to each other? So, the TICK and The Tile both work very similarly. When a mobile phone with one of their apps gets near one of those devices, it kind of remembers that and sends it up to the cloud. So, basically, anybody anywhere that has this app, regardless of if they own that specific tag or not, will be contributing to the location information. So, the tags themselves are similar, but the overall solution on how it's determining location is quite a bit different.
Aidan: Great. Thanks, Brandon. And then, moving on in even deeper into the Bluetooth tags, "Are we able to support angle of arrival on our Bluetooth tags using Bluetooth 5.0 specifications?" And I think specifically getting into how our application maybe differs for some of that, reiterating how our application differs for some of that real-time location tracking. And I think, Adam, you might be best suited to answer this one.
Adam: Sure, yeah. So, let me clarify. We do not need, we're not reliant or dependent on angle of arrival to do what we've outlined here, but that does not mean the tags can't support it. So, our reference tags that we're using for our demo here were just a Ruby tag, which is an open-source hardware platform using the Nordic chipset. The custom firmware that we have developed will run on pretty much any Nordic-based tag as well. So, if there is a Nordic tag chip out there or tag out there that supports the Bluetooth 5 angle of arrival, which I know there are, then, yes, we could absolutely use that tag with this solution as well.
Brandon Cannaday: Yeah, and this is Brandon. Just to add a little bit, I think this plays very nicely into the after-COVID scenario. So, although these tags are not being used for angle of arrival now, they're just detecting contacts between two different tags. Once kind of the need for contact tracing is over, you might be sitting on a few thousand of these tags, and that's where especially Adam was talking about, you can repurpose those to maybe then switch to indoor asset tracking implementation that then can utilize some of that angle of arrival technology for a different use case.
Aidan: And I think continuing on and just to wrap up on some of the hardware questions that we are getting, if we wanted to incorporate other attributes on those Bluetooth tags, specifically we have the question, "Are they able to capture individuals' temperature and then provide a heat map of the facility?" I think what other capability on those asset tags do you maybe foresee in the future?
Adam: So, it depends on the hardware chosen. These tags specifically have the temperature, humidity, so you could use, if you combined this with an RTLS to locate the tag, you could essentially do heat maps and humidity maps of your space. So, that is possible, especially life after COVID if that were the use case you wanted to do. From a other tag standpoint, there are manufacturers that are putting audible like speakers, buzzers, little vibration motors to get some haptic feedback. I specifically haven't seen one with an integrated body temperature in it right yet, but it's absolutely completely capable of doing that as well.
Aidan: So, in order to get started then with this application, I mean would we, would Losant recommend a particular Bluetooth tag or gateway type that our potential customers might look to to implement this solution?
Adam: Right. So, right now, what we're doing is with our demo kits and pilots, we're using these Ruby tags. The Ruby tags are easy to get. They're an open-source platform. They are customizable at volume, so they're a great tag to get started with. They are a little on the large side, so when you're talking about form factor with people carrying them around, it may not be the perfect form factor. But what we're seeing is that they're a great place to get started. And then, once the pilot runs and we see what the use cases are because every environment is a little bit different. For example, in an enterprise environment in an office setting, maybe a lanyard or pendant shape form factor might be right, but in a construction or manufacturing setting, things dangling or hanging from a body could be problematic. So, maybe more of a clip-based on a vest or on a belt is a better form factor. So, yes, we can absolutely make recommendations for hardware and get you set up with some pilot hardware to test it out and get started and then kind of evolve the solution over time with you based off of the results of that pilot.
Aidan: Great. And then, I think the last question that I think around the actual hardware piece of this before we get into some of the more specific questions we got around workflows and the actual application data that it's producing, it was just this concept of distance on an XY-coordinate plane versus being able to track distance in the 3D space. So, I'm assuming that this is coming from an application where you might have vertical distance that you have to take into consideration with exposure, so do we have the ability or do we foresee the ability to be able to track in that 3D space the distance required for detecting contact within two tags?
Adam: Right, and again, going back to the infrastructure piece, this solution is not dependent on any kind of RTLS. We wanted to keep the infrastructure costs down. That doesn't mean you can't combine this with an RTLS. So, if you want to, if you already had the infrastructure in place and you had the capability of doing triangulation through something like a Meraki system or Meridian or a Koopa and you had that infrastructure in place and you want to translate to an X, Y, and Z, you absolutely could. We're not limiting in that area, but this demo, this solution is specifically not leveraging those to keep infrastructure costs down and flexibility high.
Aidan: Great. So, I think, obviously, that we have a lot of potential flexibility on the hardware side, but I think for me, looking at this application, it really comes from the value of being able to implement a contact-tracing solution relatively quickly. But I think one of the things, some of the questions that we've gotten here are around: What else can this data tell us? So, specifically, we got a question that says, "So, once an employee tests positive, can you then assign contact tracing as far as time, and then assign a probability of exposure based on how many degrees of contact versus when?" So, I think this is getting into a little bit more of a deeper understanding of what data is relevant to understand contact tracing and who needs to be made aware at the enterprise level that they've been exposed to COVID-19. So, I think, Adam, this would be a question on the backend side on what level of data analysis would we be able to achieve that might be able to get us something close to this?
Adam: Sure, yeah. With notebooks, you can do much deeper analysis than what we showed in this demo. The translating it from just simple contact to more duration-based is possible, so we could essentially put all of the contacts in series in order and then do an aggregation on duration. That's completely doable within a notebook. We could take the count of contacts combined with the duration, and so you could absolutely do some further analysis on that as well.
Aidan: Great. So, I think this is getting and taking another step back, back into the workflow that you showed. "Would all the gateways then be communicating to a single webhook as you had it set up in the demonstration?" And I think that where this is coming from is in a busy office or in a busy area where you might have multiple gateways, do we foresee any hindrance where we have that level of communication going on? And really, I guess what this is leading to is how does this really scale to a thousand-employee operation, 2,000-employee operation? Adam, could you speak to that a little bit maybe on what we've heard even from the customer side?
Adam: Sure, absolutely, and Brandon might have some opinion on this as well. So, what we're showing in this demo is really simple. So, we've created one webhook. We also in the platform, have the concept of peripherals and gateways, which is right in line with this scenario as well. So, a peripheral...And I encourage you to check out documentation on peripherals and gateways as well. It would be a more scalable solution than just a single webhook where you essentially have gateways that are authenticated sending the information up to a workflow based off of that. And then, all of the tags are just registered as peripherals communicating through the gateway, so that's also another option. But as far as scalability goes, Brandon can probably talk to the concept of one webhook and at full scale as well.
Brandon: Yeah, yeah, happy to. So, this isn't a bad approach. I think you can have every gateway, dozens, hundreds all sending to one webhook. The platform does have some safety limits that you might hit, but that's just a matter of contacting us. That just protects us from people doing unexpected things maybe on accident. But webhooks scale extremely well. So, behind the scenes, they trigger workflows, and our workflows scale very well. So, I do like Adam's suggestion of the gateway peripheral model. Basically, that allows all of the gateways to directly report that Device: State on behalf of the peripheral, so you may not have to go through the webhook and then through the workflow kind of layer. However, that pushes a bit of the work back onto the gateway, so that depends on the flexibility or the configurability of your gateway. If it's kind of an off-the-shelf, Bluetooth gateway that might just read the data and push it forward, then the webhook and the workflow will work a lot better. But, yeah, to directly answer the question, from a platform and scalability side, I don't see any difficulty with all of those gateways with thousands of employees all sending to a single webhook.
Aidan: Great. I think we've got a couple other questions here that have kind of come in back to the asset tags themselves, as well as just a couple questions around complying with some of the standards that we see emerging out in the enterprise space as all enterprise starts to deal with contact tracing and social distancing in this new world. So, the first question back on the asset tags, Adam, "You mentioned that they were calibrated to within a two-meter range. Could you speak a little bit more to how exactly that works?" And there's a couple questions then on the level of accuracy using those Bluetooth tags.
Adam: Yep, yeah. So, the tags themselves are consistently transmitting at…All of the firmware is all set to a consistent Tx power. So, we have control over that with the firmware. So, right now, we are broadcasting at a 4 power, actually, and then using some of the firmware logic, we're calculating and based off the transmission power and based off the RSSI that we see from the tags, we're roughly translating that to two meters. It is as, if you're familiar with BLE at all, you know it's not a perfect science, and that's why if you're looking at a lot of the RTLS systems that don't use something like attack of arrival, you know you're looking at a one-meter, two-meter accuracy. What we're going after here is simplicity, and we're looking at the line of sight's distance. So, if you are two meters away from a tag that's mounted on the front of somebody, that's going to be fairly accurate from a line of sight. Obviously, the device or the signal strength will get degraded as it goes through walls or other materials, but if they have a wall between them, we're not so concerned about having accurate XY. We are just most concerned of the distance between them, and if the fact that there's an obstruction between them is okay. So, these are calibrated to about two meters. It's calibrated so kind of on the safe side. So, if they're slightly further away from two meters, it will pick it up. And again, the point of contact tracing is to make sure that people that may have been exposed can be notified, so we're kind of erring on the side of caution here.
Aidan: Okay, great. I think, actually, we've got one last question as I mentioned, kind of coming around to compliance, and obviously, this is a very rapidly changing space as all organizations learn how to move through this and invest in establishing best practices. But maybe, Brandon, could you speak a little bit to Losant's strategy in terms of being maybe compliant with some of the re-occupancy strategies that are being introduced out into the world?
Brandon: Yeah. So, I think where Losant helps here is to enable the customers of Losant and solutions like this for themselves to be compliant. So, we see a lot of similar solutions arriving in the market around not only contact tracing but also occupancy monitoring. It's a really good use case for IoT as well. So, there is a significant amount of regulation that's out right now where bars, restaurants, and venues have to be at half capacity or even less, and a lot of that onus is shifted to the business owner that they have to comply to that. And outside of somebody sitting at the door and counting people entering and exiting, there's really not a lot they can do. So, contact tracing is one solution that can enable some of these re-occupancy regulations, however, I would certainly investigate what else can IoT and maybe sensor-driven applications that might help as well and like the counting people coming and going is a very straightforward one that can help a lot of businesses as well.
Aidan: Awesome, and I think that's actually, that's a great kind of segue here to wrap up our Q&A. We've talked about a ton of information today not only around contact tracing, but we also just talked about the capability that Losant can provide to enterprise. So, if you do want to connect with us, whether it is about compliance and regulations that you're being asked to comply with that you want to understand how IoT can help you support those regulations, or you have other questions around applications within your own enterprise and your own site, please reach out to us. You can reach us at hello@losant.com. We really look forward to helping you figure out exactly how you can leverage an IoT solution in your given business. I want to thank everybody for your attendance today. I also want to thank Adam and Brandon for their time and their expertise and helping me through this Q&A session. I certainly learned a lot. The Deeper Dive series will be back in August again with topics around IoT and how IoT fits into the world's landscape. So, with that, I will wish everybody a great afternoon and again, thank you very much for attending.