How to Create a Modern IIoT Monitoring Solution on iOS Using Swift, MQTT and InfluxDB

Session date: Nov 24, 2020 08:00am (Pacific Time)

MOXIE IoT uses industry standards and cutting-edge technology to create a monitoring solution which provides their manufacturing customers with a single source of truth. Their iOS iPad app equips their customers to visualize and analyze industrial factory data in real time. Discover how they use a time series database, MQTT and Ultra-Wideband to accurately measure and track any object, device, personnel or machinery.

In this webinar, Dr. Austin Gurley will dive into:

• MOXIE's approach to app-centric asset monitoring
• Their ability to help customers streamline operations while bridging the gap between hardware and software
• How a time series database improves customer experience by enabling them to query, filter and parse their data
• Techniques for performing Flux queries in iOS Swift

Click here for the presentation

Watch the Webinar

Watch the webinar “How to Create a Modern IIoT Monitoring Solution on iOS Using Swift, MQTT and InfluxDB” by filling out the form and clicking on the Watch Webinar button on the right. This will open the recording.

[et_pb_toggle _builder_version=”3.17.6” title=”Transcript” title_font_size=”26” border_width_all=”0px” border_width_bottom=”1px” module_class=”transcript-toggle” closed_toggle_background_color=”rgba(255,255,255,0)”]

Here is an unedited transcript of the webinar “How to Create a Modern IIoT Monitoring Solution on iOS Using Swift, MQTT and InfluxDB”. This is provided for those who prefer to read than watch the webinar. Please note that the transcript is raw. We apologize for any transcribing errors.

Speakers:

• • Caitlin Croft: Customer Marketing Manager, InfluxData
  • Austin Gurley: CTO, MOXIE IoT

Caitlin Croft: 00:00:03.942 Welcome, everyone, to today’s webinar. My name is Caitlin Croft. I’m very excited to have Austin from MOXIE IoT here to present on how they have created an IoT monitoring solution using iOS Swift, MQTT, and InfluxDB. Once again, this session is being recorded and will be available for replay. Please feel free to post any questions you may have for Austin in the Q&A Box down at the bottom of your Zoom screen. Without further ado, I am going to hand it off to Austin.

Austin Gurley: 00:00:42.744 All right. Thanks, Caitlin. And thanks, everybody, for joining. Yeah. We’re going to be talking about industrial IoT and kind of the end-to-end process that MOXIE uses to get our data out of our IoT devices all the way into our iOS app and look at all the pieces of that. Going to start out with a little bit of background about who we are if I can get this to go. So I am the CTO at DEFT Dynamics. DEFT is a startup studio based out of Birmingham, Alabama. And a startup studio, or a venture studio as they call it, is similar to an incubator. The main difference is that we’re internally funded. So we have a [inaudible] capital, and we have engineering and a business team that all work together in the same building. We come up with products, create prototypes, and bring them out, raise money all from an internal fund. And we’ve done several kind of different branches of that. We started out in some material science and composites which we still work on. We’ve since moved to being heavily focused on embedded electronics. That includes some robotics. And what we’re talking about today which is IoT especially for industry. So MOXIE Industrial IoT is IoT for industrial teams. And we think of that kind of in three different pieces. That’s your industrial business has an operations team, technology team, and a maintenance team, and there’s a lot of electronics tools for the different elements of that business. And we try and keep our tools so that everybody at a company can benefit from it. It makes it easier to integrate across all the teams at your business. And it’s easier for people to kind of grow with the technology. As a startup, that helps us with adoption that there’s many ways for someone to take this technology into their company and kind of spread it throughout the workflow for your business.

Austin Gurley: 00:02:39.165 And so these three groups, kind of the central elements of an industrial business, they have kind of individual goals, operations, interested in bringing in business, how much are we selling, these sort of things, management of your personnel. Maintenance is, in particular, interested in keeping the equipment running. Kind of the same goals of minimizing downtime to the operations would have, but they approach it a different way, and the things that they’re most interested in: seeing end data and how to act on it. And the technology team which, oftentimes, is either branching what’s happening on the floor to operations, kind of creating dashboards, these sort of things, or working now on preventative maintenance or predictive - the deep learning. And a lot of people, probably, on this webinar may be in that part of the business where you’re trying to take insights from IoT information, bring it to the operations team, and show them how to be more efficient. These are kind of the three elements. And we approach that, mostly, maybe, the big differentiator about MOXIE is that we’re very heavily focused on our iOS app. So we think of it as app-centric industrial IoT. Everything starts from, “Can we get the interface to show real time? What does your facility look like? Can we make it intuitive to know how your systems are performing, how your people are performing?” And then directly leading from that, “Can we get the history of your facility?” And with Influx and the time series database, we’re able to go back in time and see historic performance, compare it to recent performance, and get insights that way over time.

Austin Gurley: 00:04:18.679 So some of the main things that we’re trying to get out of our system that I’m going to be showing you today is low latency for a visualization. So we have a way to visualize facilities in 3D. It’s all built from within the app. We also want to be able to have dashboards in our app and be able to export data to other solutions. Power BI is very popular with the larger industrial businesses. At some point, every industrial business of a certain size will have Power BI. So we make it easy to get our data out multiple different ways. We’ll be showing some of that in a minute. But again, it’s very app-centric so that all the industrial teams are able to use our app as kind of a center point of reference for how things look, a nice way to keep track of everything that’s going on in your facility, and then we have several ways for the tech team or anyone to get information out.

Austin Gurley: 00:05:08.637 We do this with four major pieces of technology that are kind of in the network flow. These are the pieces we’re going to be talking about in detail in a minute, but I’m going to go through just a slide each on these four elements of our IoT solution so that you understand kind of the overview, and then we’ll dive into the details of how do we actually do MQTT, what do we store in Influx, and how does it end up in iOS Swift. So first of the four pieces, well, first, who do we do this for? Industrial business is pretty broad. So we started out especially focused on bridge cranes. I guess you saw in the previous slides some animations of that, and we’ve since moved towards machine health. That’s mostly CNC machines spindle load or coolant tanks, these sort of things, and we’re moving towards other vehicles, forklifts, indoor and outdoor, railcars, things like that.

Austin Gurley: 00:06:00.171 All right. So the four key technology pieces. It starts with ultra-wideband, indoor positioning. The easiest way to think of this is it’s like GPS, but it works indoors. So it’s kind of comprised of two pieces. You have the tag which is the IoT device. It’s a kind of a self gateway, so it’s an IoT device which is attached to mobile equipment. It transmits over Wi-Fi or cellular, whatever data you’re tracking, starting with the position and then attaching information to that. So motor spindle load, temperature, pressure, humidity, volatiles in the air. These sort of data points are attached to a physical device that can move around your facility. That’s the tag. To position things indoors, everybody knows GPS is kind of the preeminent way to measure your location outdoors, and there’s different levels of accuracy to that. It’s usually about one to two meters for a common GPS system. And so as soon as you go indoors with the GPS, of course, the signals are blocked to the satellites. It’s going to cut out. So GPS does not work indoors. Ultra-wideband is the solution that can overcome that because we create our own sort of constellation of references for the tags to use as positioning. Yeah. References or constellation that they can look at to find their location. We call these anchors. They’re put around the facility about every 50 to 100 meters around the edges of the walls. And they’re used so that the tag can find its location. We can also kind of combine the ultra-wideband with GPS so that forklifts and things that can travel through a building, outdoors, and back indoors, we can kind of seamlessly move from tracking inside to outside. Most of our customers have a facility that’s focused around one or two buildings, and the workflow of the product or the distribution that happens inside that facility.

Austin Gurley: 00:07:48.644 MQTT, so we’ve got the IoT devices. They are collecting data, position, and other data points. How do we get that data out of a facility? So that starts with MQTT. So MQTT, probably, a lot of people are familiar with this. I’ll probably say MQ so I don’t get my tongue twisted up saying that a lot of times here. So MQ is a publish-subscribe messaging system. It’s not really a message queue in any meaningful way despite the name. And so what this allows is a single-broker computer server acts as an interface between IoT devices and endpoint devices. All of them are clients to streams on the MQ broker. So starting with the IoT device, MQ has some serious benefits for IoT, especially low-powered. Talking about low power in terms of computing, low power in terms of battery life, low power in terms of bandwidth on the internet. It’s great for all of these things. Especially, there’s a lot of cellular carriers, AT&T and others, who now have a Cat-M1 - that’s a LTE category, M1 - way to transmit IoT data, and a lot of the plans are very generous in the monthly cost, but you’re limited in an amount of data you can send per second, the maximum you send per second. So one common solution to battery life on IoT devices is to store maybe a log over the course of a day and then dump all of that at once, up to your historic database. But these new systems on the Cat-M1 kind of encourage a steady trickle of data instead, and IoT - or rather, MQ is great for that. So we can take our IoT data to constantly be streaming it. That gives us real-time information if we want that and it lets us run this at the low power. And low power in terms of transmission strength, battery life, and the amount of computing it takes to get a message out. More about that, probably, in a minute.

Austin Gurley: 00:09:48.851 The MQ broker’s also great for handling IoT devices for special features like Keep Alive timing where if a IoT device dies, it’s an interesting problem because, if your system’s battery dies and you would like to know what happened to it but it can’t transmit - the battery’s dead because it’s dead. So the MQTT system takes care of things like that. It’s able to send all of the subscribers a message in the event that you lose signal or otherwise disconnect. Another benefit is that a single MQ broker can support thousands of devices, and it can be very easily partitioned to have multiple customers and multiple projects all in one broker. So once you’ve got a solution that you’re happy with, they’re easy to partition. You can access this from any programming language you like, anything that can get on the internet. It’s very easy to find or build drivers so that your device can use MQ.

Austin Gurley: 00:10:43.737 All right. Why Influx? So we actually started out, I must say, with Amazon tools. So our background was in mechanical engineering, so we’re comfortable with the embedded devices. Back-end work is not initially where we started. So we go looking for a solution. Amazon hits you pretty hard on the Google ads, and so they have a lot of tools. And we went with some Amazon tools for about a year, starting with the DynamoDB. Well, really starting with Amazon’s IoT system. The hard thing with Amazon’s IoT system, it looks great for the devices that they support. It’s end to end, and they take care of you all along the way. It’s very secure. But sometimes, that gets in the way - the amount of computing processing power that Amazon expects from your IoT device is pretty strong, so you’re thinking about something with the power of like a Raspberry Pi or a embedded computer whereas most IoT devices are much lower power than that. You’re talking about systems that are embedded microcontrollers. They can barely get on the internet. They’re certainly not a full Linux computer running, and you could not handle that very long on batteries, and there’s some other limitations.

Austin Gurley: 00:11:58.907 So [inaudible] IoT, it’s very nice for certain applications. It’s out for us because of the power of our IoT devices. And then Amazon has other tools. DynamoDB seems like a good solution for storing lots of small data points. But it’s built to be queried in a sorting manner. So probably a great application for Dynamo but not for what we’re doing would be if you had a video game and you wanted to record everybody’s scores as they come in, but you want to be able to query for the top-10 or top-100 scores to tell you how they’re performing. It’s a great application for Dynamo. But it doesn’t work great for data that is spread equally across time where you’re trying to go back and look at a certain segment of the history of the device and then find all the information kind of inside that time range.

Austin Gurley: 00:12:48.925 And then when we did find Influx, it works great because it is designed for that, so you go look - and the queries are based around finding a time range, getting the data points you want, and especially, you’re able to offload the work of filtering the data in normal signal processing concepts, moving average filters, sorting, max and min. All these concepts, you can offload that to the query that you make and receive the data and very easily make it show up in the app the way that you want. So it’s really ideal for IoT information. We also use InfluxDB Cloud. Yeah. Another difficulty with Amazon is that it’s often unclear what you’re going to be paying for the system. So actually, one of the things that started us on the path towards InfluxDB Cloud was it was very easy for us to estimate what it would cost us to host X number of devices, streaming data, X samples per minute. And we’ll talk a lot more about the way we built the queries as we move forward.

Austin Gurley: 00:13:47.876 All right. Swift, now, I don’t want to upset anybody here, so let me go ahead and clarify a bit why we do Swift versus - everybody is always asking us, “Why don’t you use React Native or any of these cross-platform tools?” Those have a place. They’re very powerful for certain things. What we’ve learned is that they are not great for connecting to real-world devices. So when we’re talking about having physical hardware that’s on Bluetooth. When you set it up and it’s getting to the real world, it very quickly fell apart to have a cross-platform solution, but then we were making individual drivers to do our inputs and outputs to real-world hardware for each of the platforms we’re trying to support.

Austin Gurley: 00:14:27.960 Since we’re a startup, we’re also very interested in focusing all of our energy on one platform. So we’d rather be excellent at iOS Swift than to be average or mediocre across Java and iOS and things like that. And then once you get into it, there are lots of tools in iOS. And mostly, it is moving to Swift now from Objective C, so tools for 3D visualization, for maps, map tiling, things like this, and inputs and outputs are very robust. So there’s Apple drivers and third-party drivers for all sorts of supporting Bluetooth, MQTT, etc.

Austin Gurley: 00:15:10.111 All right. So that’s kind of the overview of the pieces. So again, we’re moving IoT data from MQTT stream to store it, and we either display it live or look at historic data all inside the iOS Swift app. Going to really dive into the details of how we do that now, so this is the technical content. Real quick, I should have shown it earlier, but as you can see up in the top corner, this is one of our IoT devices. So I should have pictures, but just for a sense of scale, this is the device that would mount on top of your crane or on top of your forklift made with an external antenna. It also has GPS, and it’s a self gateway or hub so the IoT data for each individual device leaves this system, goes to the internet over LTE or Wi-Fi, and any nearby information, wireless or wired sensors to that box, is kind of tied to a serial number. Show that in a second.

Austin Gurley: 00:16:04.299 All right. So before I show kind of the network architecture in a little more detail, this system with industrial IoT data, there is one difference between what we’re doing and normal time-series data which is that we care a lot about position. It’s critical to us, we think, for our users to be able to visualize the facility as a place that you can see how things move around, where they’re going. It’s not just charts across time. You can see your facility and it makes more sense. So we’ve got data that’s got independent access of time or position and dependent data. Yeah. That can be speed, motor load, voltage sensors toggling on and off, the limits which is anything that you want, normal things. You all know IoT data, but the idea is that we want to be able to pick a time range and then plot whatever our dependent information is against time and against the position in the facility. And we’ll talk a little bit about how we use Flux queries to achieve that and get it to show up in Swift in a minute.

Austin Gurley: 00:17:10.866 All right. The overall network layout for MoxieWorld is like what you see here. And so, starting again from the lowest level - that would be the embedded system - we have this device which, again, is a self gateway. It connects to the Internet on Wi-Fi or LTE Cat-M1, and its only access point to the internet is over MQTT. So there’s several choices on that. Some people would probably have a gateway which would send live data over MQ and would sent historic data directly to the time-series database. We don’t handle it that way. We’re minimizing the bandwidth and the computing needed on that IoT device. So they’re only connected over Wi-Fi or cellular.

Austin Gurley: 00:17:55.516 Typical data rates for an IoT device that updates about once a second. This is where a payload that’s including the position and 12 other data points for our typical system. So position, X, Y, and Z, speed, accuracy of that signal, some data points like vibration level, temperature, these things - it ends up being about 240 bytes per payload that we send, and we update that at 1 Hertz for most of our systems. That’s plenty for it to look nice in a 3D visualization, and the resolution is very nice for display and for the looking back in time maybe over the last hour or day. That’s about all the resolution you need. And that adds up to about 600 megabytes per month, per device, which is well within the limit, as long as it comes in that continuous trickle of data, within the limits of what most Cat-M1 plans will allow you to do with no overcharge for the amount of data you’re sending.

Austin Gurley: 00:18:52.305 But that does actually add up pretty quick for a single IoT device if you’re going to store it all. So we don’t store every data point. We split it up. I’ll talk about that in a minute. We watch the MQTT broker with a EC2 Instance running Python which is able to take the data, sort it into customer accounts, and filter it however we want. And we end up storing it at about once every 10 seconds. So every device has a sample stored every 10 seconds, and then that’s the information that’s pushed to the Influx database. Then looking to how the customer can access this data, first, of course, we have our app. So the app generates the real-time displays from the MQTT stream, historic data. The app is able to make queries to Influx. It’s part of what we’ll be talking about in a minute. Hopefully, that’s some helpful information. How to do that in Swift. And so that app can show whatever you want over the generated kind of facility layout, the digital twin, we call it. You can also create charts and our dashboard and export those as CSV. A lot of people like Influx. Strike that. A lot of people, well, a lot of people do like Influx. What I meant to say though is a lot of people like Power BI. And it’s very powerful, and it actually has a lot of good tools for inputs and outputs, but most of the customers we see don’t use the more powerful ways to update it though. A lot of them are updating it from a spreadsheet. So we do let you make a chart in MOXIE and export a CSV so you can plot the data however you want, maybe in Excel or maybe import that into Power BI for your own dashboards.

Austin Gurley: 00:20:38.832 The app can query Flux to make historic channels, but we can also give our customers access to their bucket in the Influx database for themselves. So kind of, if you’re a customer of ours, you kind of have three ways to get data out. You can use the app, or you can access your bucket on Influx, or you can have access to the MQTT stream if you want the live data as well.

Austin Gurley: 00:21:06.640 All right. So once the data is out of the air on the IoT device and you want to push it to the internet, MQTT, you’ve got to have a system to organize this. Surprisingly, there’s not a very well accepted standard for how MQTT should be organized. In general, MQTT has two elements. There’s a topic structure, and you can think of the topic as like a file system, so there’s a slash-divided string which kind of - think of it as a file folder that a single file resides in. That file’s called a payload. So at any point, a device which has permission can put a single small payload file anywhere in this file system that it wants. But the next time that anything writes to that same location, it will be overwritten. So any device can overwrite another one if it has permission to do so, and so you end up with this structure of deeper and deeper levels in the topic which organize your data, and then at the bottom is the payload or the information you’re trying to carry. So we’re going to do two things with this system which is we’re going to have a topic which allows us to stream data from one customer’s facility all the way to their app and keep it secure and partitioned from other customers. But we also need to have enough information in that topic so that we can take the data and send it to Influx sort of the same way. So from this one MQTT stream which we’re going to watch and transfer some pieces of to Influx, we’ve got to have that information somewhere between the topic and payload.

Austin Gurley: 00:22:49.145 So this is our technique. Kind of talk through it here in its elements. So we start out with just a header. We do this because it lets us have multiple projects on a single MQ broker. So it’s kind of unnecessary, but it’s a nice way to organize if you have multiple ideas or you want to have a generation two with a different system. So we have a header. Next level in the topic is the account name. So this is Acme Company, whatever the abbreviation you want to use for the customer’s account. And this is how the permissions to access the stream are organized so that, if you’re a customer of ours, you’d be given access to all of the topics below MW slash your account name. Anything below that, you have access to, and so it’s a nice way to go ahead and put the account ID up at the top of the topic so that it’s very easy to partition what a customer’s login is allowed to see. They’re able to see things inside their account only. Anything that’s in there.

Austin Gurley: 00:23:50.467 The next level is a device type. So we have a few of these, but just talking from the ultra-wideband example, their tags, the mobile devices, and anchors which have some stationary information about where they’re located in the facility. The next level down is a serial number or a unique identifier for the tag. So the serial number is pretty important. Eventually, we’re going to want users to be able to rename the devices, configure settings, all sorts of adjustments, but it’s critical that, somehow, in an IoT device, you have a unique identifier which, no matter what happens later in the device’s life, even if it’s returned to us and we need to evaluate it, we can see from that serial number, “Where does this information end up?” and always look at that same device regardless of what it’s named, regardless of the settings that it has. So the next level is the tag identifier. Again, that’s just a serial number.

Austin Gurley: 00:24:42.677 So we’ve got an account which has tags, the tracking devices, each of those with a unique identifier, and a tag can have multiple pieces of data. So we’re talking about ultra-wideband which is some position data. You can also see here on the right, there is some information in a JSON structure for motor load. So that would be like a CNC spindle, how much torque, essentially, is on the spindle, how fast is it spinning, etc. We do use JSON. It’s a very nice system. It’s a little inefficient, I guess, if we’re trying to be very careful about the amount of data that we have to send through the air. This structure has a lot of information or a lot of bytes that are spent just renaming information that we know we could have just sent seven values, comma-separated, could have packed them into four bytes each if they’re floats. There’s a lot of ways you could do this. But JSON’s pretty nice, particularly for our solution, first, because when we’re selling a customer on how easy it is to get their data out of MQ, it’s very hard to convince people that they want to split binary data out of something that’s just bytes because they’re floats or ints, whatever they are. So it’s nice because anybody can receive this in MQTT explorer or any tool you like and understand what’s going on. And it’s very nice because it integrates with InfluxDB very well. We can take these packets, payloads rather, and we can pretty directly send these towards Influx for storage, and the keys in this JSON dictionary will be used to create the fields as it’s stored in Influx.

Austin Gurley: 00:26:26.293 All right. So how do we get the data from MQ to Influx? We use, again, a EC2 Instance running Python. There are several ways to do this. Some of our competitors use Lambda’s. We don’t think that’s efficient because a Lambda would have to connect as an MQ client each time there is a message. Connect, connect to Influx, and then send the data again. So we like to run always on EC2 Instance which is just running Python, particularly, because it lets us create custom filtering. Show that in a second. So if you’re looking at this yourself, the main tool people use in Python for MQ is going to be the Paho MQTT client, and InfluxDB has created some very nice libraries for reading and writing information in and out as well. Since we’re trying to transfer information from MQ to Influx, we only use the writer portion of that library.

Austin Gurley: 00:27:21.412 So the process for getting the data out, first off, because our MQTT structure is organized and includes account information, we store the data as it comes in based on taking that topic, and we can crack it apart to see which account does this belong to which will be a bucket on Influx. The payload is JSON. That can directly be turned into fields in Influx. And we get an opportunity - this is why we like being able to run this in Python and manipulate it - because we get an opportunity to filter the data as we reduce it from one second or more MQTT streaming data to once every 10 seconds saved information, we can decide if we want to filter it. You can take the average; you can take maximum. Since we’re using position, we usually take an average rejecting. You have 10 samples, you can reject a couple of bad positions. You send them all a notice or however you please. Take your other information, usually average it is the way to handle it. Some values, you might take the maximum, but it gives us an opportunity to look at that information, filter it a little bit before we send it, and store it once every 10 seconds which is about as fast as we find is useful for any type of historic query. So if you’re looking at the past day, 10-second data is very, very fine resolution, more than most people want. Minute to 15 minutes is actually very nice resolution for a daily summary of the last day. For a week, you’re looking at something like an hour. For a month, maybe you’re looking at even something as simple as one shift, so three data points per day would be the resolution.

Austin Gurley: 00:28:55.307 And that’s one of the great benefits of Influx is that, once we’ve stored the data, it’s in there once every 10 seconds, but we can make queries that don’t overload our device to download a lot of information and create these filters, create these summaries ourselves. So we can design a query. We use Flux to make whatever the output we want to show on the screen comes down almost ready to display with as few values as we need to create the summary. One more time for people that are doing IoT data. We’re organizing this where the account ID is the bucket. That’s just the easiest because then we can give each customer a single token that’s got read access to their bucket. Very clear. The measurement is always going to be the UUIDs. Show y’all how we do this in a minute, but this kind of creates an independent - again, the data that’s coming in the MQ stream can change, but its unique identifier is never going to change, even if we added extra sensors or reorganized the JSON structure, things like that. And then the fields, again, are going to be automatically pooled from the JSON that’s on MQ into Influx as fields that you can filter in Influx.

Austin Gurley: 00:30:09.301 All right. So now, we’re kind of getting close to the iOS Swift part of this. So back to something I mentioned earlier which is that MOXIE is very interested in showing information across time and position. So how do we do that? How do we make a query that can handle that within Flux, and how we do it in Swift? All right. So starting out here, we’ll just take apart the way we handle queries at all in Swift. So this is going to be more useful to people that are trying to replicate these kind of systems in Swift by themselves and less interesting to people that already know you can do HTTP post requests. That’s not the point. The point is how is it done in Swift here for a second. So we create a URL session, and you can make the post request. There’s a few important elements here for the way we’re going to organize the data, again, because of that kind of 3D or time and position query that we want to make. So we use our credentials to go to InfluxDB Cloud authorized by the token for the account. So again, that’s positioning our customers into their own accounts. It’s filled in. You can see how this is filled in by information from whichever project is open in the app. Hopefully, we’ll get to show you the app in a minute. We’re going to be making Flux queries and returning them as a CSV format. So this is how we’re going to be able to take the information. We’ll pivot it - you’ll see in a second - so that we can get position and time and the value that we’re interested in plotting.

Austin Gurley: 00:31:43.891 For people that are familiar with Swift, this is obvious, but people that are new to this, it’s important to create these queries giving yourself a completion which, in some language, I guess, would be called a Lambda. It’s a function that’s [inaudible] a pass as an argument when you make a query that will be run when the query returns. So you’re going to create a function that has the data you’re interested in. It tells you if there’s any errors, and then you can act on that information. So when I make this query, it’s going to take some tenth of a second to several seconds to return the information. And so we want to have the app immediately respond to that as the information appears, after the query. That’s what the completion or handler is. We use the URL session. We create this HTTP post task, and then it’s going to either return with an error which we can hand the user in that completion closure, or it’s going to return with data which we can handle by giving the user the data that comes back. Again, it’s probably going to be in CSV format if we’ve done this correctly, or it could be some message from the server. In this case, the error is going to be usually - that depends on area code that’s returned - but this is, usually, if you formatted something incorrectly in the way you made a Swift HTTP post, it’s going to give you an error here. It could be that Influx returns an error as the data that it returns rather than a CSV, so that’s something to be aware of.

Austin Gurley: 00:33:17.785 Okay. Let’s back up. All right. How we’ve organized this. So that’s how you make a request. Bounce back for a second. You can see that we passed the query. You pass the query itself as a string, so you take the query which is a string as an input, turn it into data because that’s what HTTP expects, of course. So the question is how do we organize this for Swift? Because we don’t want to just have the users having to type in a string to create a query. We need to organize this in just a more intelligent way to make it more versatile. So we create objects for each of the types of what we call Flux operation. So anything that you could use the pipe forwarding in a Flux query to add another line to how your query is going to filter your data. We create these objects that will, given information that’s a little more pliable, it will return the equivalent string. So this is nice because we can create an array of Flux operations starting from the bucket that you want and the time range, and then you can chain these classes or functions down in a list and then compile them in order into a string to become the Flux query which returns the data that you want.

Austin Gurley: 00:34:37.468 And again, it’s important - I think, this will be published - but I think it’s important to study the particulars of that post request so that you get CSV back that’s formatted a certain way. One of the two, well, two of the more important pieces of this that you should always have, for position and time data, is the Flux pivoting and the aggregate windows, so - sorry, aggregate window. Again, that’s going to be our filtering. Do we take the average or the maximum, minimum, mean, whatever, the way we’re going to take data over the last hour and take our 10-second resolution and smear it into an hour? So every request we make, just like, I think, the default is now for the Explorer and DB Cloud, we’re going to aggregate the information into whatever is most relevant for the user. So we create objects for that. And most important for our kind of 3D data is the pivot. So we’re going to, essentially, be making three queries. Well, that’s not true. We’re going to be looking for three fields that we’re allowed to filter with or - show you this in a second. So it’s going to be the value that you’re interested in or X location or y location, and we use the pivot to reassemble that into a single CSV so that we end up with, instead of having three different CSVs returned with timestamps and X timestamp and Y timestamp and the value you’re interested in, the pivot lets us return a single sheet which is already organized and aligned so that you have each row timestamped X, Y, value that you’re interested in. Down and down, and that helps us a lot with the way that we plot the information.

Austin Gurley: 00:36:15.652 All right. So looking at an example, one more thing to keep in mind is that, since we’re trying to make this a good tool for the user, a lot of our users don’t want to see any of this. The important thing to them is to kind of sort and shuffle which devices they’re looking at and what the time range is in the easiest manner possible for them. So the user is going to select a combination permutation of the IoT devices that they’re interested in, again, each tied to a user ID. And in the app, we let people control this either as individual devices or a group. Perhaps, it’s all the trolleys across a single bridge train or all the CNC [inaudible] in one room, things like that. So combinations of devices is controlled within the app. And we translate that automatically for the user every time they make a query. You just press update. They don’t have to see any of this about what’s being filtered, but we convert however they picked which tags are going to be seen into a filter which gets information from any matching tag.

Austin Gurley: 00:37:24.743 The next level is, again, the 3D query system, so if we filter to get whichever value we’re interested in - in this case, the value is OK which is our signal quality, essentially. So the user wants signal quality, and we’re also going to return X and Y, and then we’re going to pivot that, so again, we get a CSV with columns which are time, X, Y, and the value you’re interested in. Finally, of course, we can add maps to reduce that however we want to filter it. All right. So that’s pretty much the complete pipeline of the information. I think I’ve got some time to open the app here in a second and show you a little bit of how it actually looks. Just a couple examples of things we’ve done with our customers. So starting down on the right, actually, we have a lot of interest. Again, we started in bridge cranes, so there’s a lot of things you can do with this, in particular, working with some distributors, it’s interesting to look at how the material placement in the facility can be optimized based on how far the cranes have to move to unload or load a truck and whether you can place the material in better preloading locations so that, on slow shifts, you can be moving material closer to the loading zones so that, when the trucks arrive, you’re not running the crane hundreds of yards down to pick up one piece of metal. It’s already near the truck when the truck arrived.

Austin Gurley: 00:38:54.101 Another thing that’s very interesting is that you can get from this to - you can even see here in the kind of weekly pace of the company, so you’ve got five days of productivity and two which are a little slow which, of course, are the weekends. They only run the third shift, often, like on Sunday night. So that’s, you can see, kind of three shifts. Pink, green, and blue. You can see the weekdays. Then you can also see something that’s interesting which is that that first shift is consistently more active than the other two shifts. So it’s an interesting opportunity to, again, rebalance when are you preloading, when are the trucks coming in for loading, just based on that. Another local machine shop was interested in spindle loads. So we focused a lot on [inaudible] motor current which is very easy to install. Can we look at how much load is on any type of electric motor for braiding machines, CNC machines, spindles, pumps, and compressors, all these things? An example of spindle load, so we consistently were able to see in the data where the spindles were overloaded each morning because we found out the grease was cool, and so running at a certain speed after the machine had been cooled off created a higher load in terms of the electrical load on the spindle before even cutting, actually, than the machine running warm, cutting. So that’s an insight where we can know to warm up the machines for a little bit longer before they start to cut. Also, notice, you’d think if you look in a machine shop, these places are flying, and you’d think that these machines couldn’t be wasting 2 or 4 percent of the time. The tools seem to always be in the material, making parts. But when we actually get the data out, we found a local machine shop that, about 22% of the time, tools were either in the air or being changed in and out of the tool order. So it’s interesting, just by watching the amount of time the spindle’s running, you can see if the spindle’s running loaded or unloaded, again, based on the motor current. And so we’re able to help them reduce 22% of air time to increase the amount of time that we’re cutting from about 70 to 80 percent.

Austin Gurley: 00:41:04.701 All right. I’m going to open a demo and then get ready for questions in a second. So let me get this up.

[silence]

Austin Gurley: 00:41:28.842 All right. I think that looks good. So this is the actual MoxieWorld app. This is a kind of dummy facility. It’s just because customers’ information is kind of sensitive, so this is the building we’re in Birmingham. We don’t actually have a crane, but we can walk around in the back, and it’ll move around as if it’s a crane. We actually do have a CNC machine, so we can look at some information like that. So this is our 3D visualization in Swift. This is done with SyncKit. The CAD, of course, is ours. But the ability to - all the controls for - it’s kind of an interactive 3D experience. That’s all very easy to create in SyncKit. Animations, the layout of the parts, some of the effects like making them glow when they’re operating, things like that. Projects is going to be each customer’s projects, so we’re in this demo project. You can see, again, the way we organize our devices, you have the tag which is each tied to a physical piece of hardware. You can also group this into CNC machines or cranes, so that’s related to the specific data that’s coming off of any tag. Anchors, again, are stationary reference points which are suspended on the walls in the back of the facility. And so this just gives the user an opportunity to select or deselect whichever piece of information they want to see at any given time.

Austin Gurley: 00:42:51.397 We’ll look at one particular example. So I can look at CNC Mill 2 which is running here live right now. So mill two is there. And you can see when the spindles turned on, so the load increases. This is set based on the current. So at four amps, the machine’s considered - well, actually, at three amps, it’s going to be considered heavily loaded. At one to two amps, it’s not loaded at all. You can also look at the frequency of the spindle, things like that. Okay. And you can also see the color of the machine is kind of an indication of how heavily loaded it is. So as the spindle load, based on the current, changes from something high to something that’s acceptable, we can have nice animations for it illustrating to the user, “Is it heavily loaded? Is it cutting?” So it’s working in the part. Or, “Is it overloaded?” That’s going to hurt the machine. This kind of dashboard, this is the live MQTT data. So the screen, you can see it updating once a second, kind of shifting across the screen to show you the last one minute. Can easily go back and look at - nothing would’ve happened in the last hour, but you can see that, yesterday, the machine was running for a couple hours. You can see, this morning, it ran for 20 minutes or so. I can keep going back further. Again, this is our in-house shop. So it’s only active when we’re making prototypes. And so you can kind of see that, for three days, there, we were active, and then for a week before that, the machine was hardly touched, so get some insights like that. I wish I could show you some motion, but I think you understand what’s going on here.

Austin Gurley: 00:44:33.805 We have a channel builder. So again, this is what you saw a tool for. So we can create charts. These are going to be very interesting with the one machine that’s running here today, but you can create a sort of dashboard with customized charts. The information’s all also available on MapKit. So for larger facilities, a lot of times, it’s best to see your information from above, especially, you have trucks or a forklift’s coming in and out of a building, the map concept makes a lot of sense. Again, the same information you see in the 3D scene, just maybe not as fun.

Austin Gurley: 00:45:03.987 So the channels, when you’re creating these little objects that are in the corner, you’re able to make custom channels that are all tied, again, to Flux queries. So I can come in and edit a query based on dropping objects into my query array like we talked about a minute ago, and we can immediately return and see what this is going to look like as a string Flux query, how it’s going to be returned to the table, and then we can act on that, play with whether it’s a pie chart or how we want to display the information. All right. And with that, I think I’m finished running through everything, so appreciate everybody being on today, and we’ll open up for questions.

Caitlin Croft: 00:45:48.245 Awesome. Thank you, Austin. So I know there are a lot of questions that came in, and I just want to give everyone another friendly reminder that this session has been recorded and will be available for replay later today. So the first question is, do you know about Homie IoT? There’s a GitHub project. If so, did you consider it for MOXIE?

Austin Gurley: 00:46:14.919 I don’t know that particular one. I’m sure we ran across it. That might be a way that MQ’s organized - I’m not sure, but I’ll definitely look into that. But no, we didn’t consider that in much depth.

Caitlin Croft: 00:46:28.620 Okay. Can we use the network layer flow with open source MQTT brokers?

Austin Gurley: 00:46:37.498 Yes. So like Mosquitto? I’m not quite sure what you’re trying to do with this, of course, but Mosquitto is a great open source broker system, so you can put that on your Raspberry Pi at home if you wanted to. There’s a lot of people that will host those, usually on Amazon, kind of with a little bit nicer service for creating accounts and filters and things. So how low-level can you get to that? You can do whatever you want. There’s not a lot of freedom probably in manipulating beyond what kind of the Mosquitto client libraries look like. They’re very simple. But yeah. Of course, you can manipulate any of those things you want, and it’s a pretty risk-free thing to do if you can find some benefits to do it. The only thing I’d avoid is we made some mistakes early on trying to have a solution that was built on MQ but had some special elements that were not very MQ-y, and it got us in trouble when we tried to move to a hosted service that didn’t accept those changes.

Caitlin Croft: 00:47:37.255 All right. Maybe I missed it because I was a little late, but how is authentication or authorization implemented for MQTT custom authorization, plugin, username and password, and SSL?

Austin Gurley: 00:47:54.139 Yeah. Okay. Yeah. So I think what you’re mainly - so the first level of that is probably how does MQ handle credentials? So like Mosquitto is a very common open source MQ broker, and you’re going to be able to provide [inaudible] yourself as just a file of username-password pairs that are used to allow or disallow any user based on the topic. So again, MQ is a system which is going to have a topic and a payload, and every message that comes through. And let me show you this again. And so when you’re looking at accounts or having different users, you can only have access to certain information. You create a filter that says something like, “I can access everything deeper in the topic structure than MoxieWorld slash Acme Company,” and then anything past that, you’d give a password that allows access to these things. As far as SSL, most MQ brokers are going to have three ports. At least one is unsecured messaging. One is for SSL, and one is for web sockets. So that’s kind of the default feature. That’s just based on how your client or how your IoT device wants to connect to the MQ broker. And it doesn’t really have all three of those options based on what your devices can support. So it almost always can be secure if that’s what you want. That’s separate from the user accounts.

Caitlin Croft: 00:49:22.999 How do you plan on integrating predicting the rest of life with the machine learning model?

Austin Gurley: 00:49:30.107 [laughter] Yeah. That is a great question. So first up, everybody here should know, is to collect the data because you can’t make predictions from no data. And so the important thing from our side of this is to give value to customers for when you have these data points coming in. They’ve got to be valuable to the operations and to the business team b

ecause you want to be able to make those predictions, but if you’re not getting value out of having this stuff installed on machines until they break, you’re not going to see any events where they do break. And you have to have that information about the breakdown events to be able to predict them later. As far as the end of life, I’m not sure about that. You have to ask somebody smarter than me.

Caitlin Croft: 00:50:11.090 [laughter] How do you manage a lost connection situation? Is that data not sent or locally buffered on the edge device?

Austin Gurley: 00:50:22.178 Yeah. So usually, it depends on how critical it is to have the entire history. It can usually be buffered. Yeah. That’s a great way to do it. It really just depends on the data point because some information is not very valuable to have it, but you do have to consider - so we do buffer it, and it’s important to, if you want to have the data align correctly, like when you go to store it in Influx later, it’s important that you’re timestamping the data yourself as it comes in and as you’re buffering it to dump later in kind of like a voyage log of what’s happened in the past. You need to do the timestamps because, if you try to throw them into Influx all at once, they won’t correctly represent the history that you’re trying to have saved.

Caitlin Croft: 00:51:07.520 InfluxDB is often used together with Grafana. Do you have any experience with that combo? If so, have you used it in the past, present, or are you thinking of using it in the future?

Austin Gurley: 00:51:20.173 Yeah. So we use Grafana in terms of setting up some of our dashboards like when we would play with Influx Cloud. Of course, we’ve done that. It’s not very tightly integrated in our current app, but yeah, that is something that we are looking towards. I think I even missed a slide where I mentioned that a lot of people are becoming more comfortable with Grafana and how to organize these queries. So we’re looking at integrating that into the app. We’re, honestly, not going to be interested in it until it can be run from within an iOS app because that’s what our business is based on. So as long as it’s web-based, it doesn’t fit us very well. But the concept of what Grafana does is very powerful, and it has some opportunity tied with things like InfluxDB to do a good job of moving Power BI away from getting data out of a spreadsheet to something more powerful.

Caitlin Croft: 00:52:11.146 How do you organize your MQTT topics such that it is clear and unambiguous with respect to the InfluxDB structure? So for example, mandatory structure, catalog, single source of truth, or security.

Austin Gurley: 00:52:28.216 I’m not really sure what the question is asking. So as I was explaining it before, the main point is that each UUID, each device gets you into a measurement, and each account gets you into a bucket, and then, from that, there is no more that we’re doing with it. It sounds like you know a lot more about Influx than I do.

Caitlin Croft: 00:52:51.187 [laughter] That question came from Hans. Hans, I actually just allowed you to unmute yourself, so if you want to expand on that specific question, go ahead.

Attendant 1: 00:53:01.741 Yeah. Thank you. Yeah. I was just wondering, since it’s more about arbitrary structure that you impose on your own data, like in the past I’ve had experience with, yeah, with not having a clear description of the data because there is a - I mean, of what data you have. For example, here, on your screen, you have the JSON payloads together with some fields. But how do you keep track of where it comes from or what it actually means?

Austin Gurley: 00:53:40.255 Oh, okay. That’s fair. Yeah. Right. So this is showing you everything that that’s flying through the air. When we create a device, we would sell somebody a motor tag which is going to track things about the spindle. It’s already determined what will be - in this case, you see them on the right - the seven fields that will be available if you bought a motor tag. Those are the seven pieces of data that are available. And it’s expandable, so we do have some what we call Plus One sensors, so we can add - like for a CNC machine, you might want to know the level of the coolant in the tank. So we have a wireless coolant level sensor which can add a field to that. And that’s all written in our kind of API guide of what the information you’re paying for will contain. So in other words, it’s not supposed to change over the life of a device. Is that the question?

Attendant 1: 00:54:31.180 Yes, indeed. And also, what is the management of that stricture, and what data comes from where is actually something that’s not integrated in your Influx trees, but it’s something that is stored in your app database.

Austin Gurley: 00:54:53.247 Yes. Yes. Exactly. So the data that goes and is stored is tied to a unique identifier which was sold to a customer, and that’s stored in a relational database which says which tags are associated with which user account outside of the string that we talked about. Yeah.

Attendant 1: 00:55:10.005 All right. Thank you.

Caitlin Croft: 00:55:14.159 Would you advise against omitting or reducing the keys in the JSON payload to reduce bandwidth requirements?

Austin Gurley: 00:55:23.340 Yeah. It depends. So for us, you’re right. You shouldn’t intentionally make long-string keys because - why? But again, it’s kind of tied to, on Wi-Fi, it’s a little data. It’s not obtrusive. And on the Cat-M1 plans, it’s well within the limits of what you can stream constantly. So that was our balance. Again, you can keep going deeper and deeper levels until you’re saving floats just four bytes each, packed next to each other. So I can get this entire payload into 18 bytes, but I don’t want to explain that to a customer, so it’s just your choice on compromising readability versus, yeah, bandwidth versus how is it going to end up in your InfluxDB system where the keys actually don’t matter at all because it’s stored once for the field that you’re tracking.

Caitlin Croft: 00:56:19.196 All right. So we are at the top of the hour. We are going to continue answering everyone’s questions, and of course, they are going to be included in the recording. How do you handle missing data points in the X, Y, Z pivot query?

Austin Gurley: 00:56:34.335 Yeah. I believe it keeps the most recent. That’s a good question, and I wouldn’t know the answer because the way our data is streamed from our devices, again, it’s in these JSON payloads, so there will never be a time when I have a data point that does not have X and Y data, but I believe you have some options on how to do that. You can either leave them blank or use the next oldest value to fill it in. But I actually don’t know because, again, our data comes simultaneously. This one packet has X, Y, and the value you’re interested in.

Caitlin Croft: 00:57:08.623 How do you query or aggregate the MQTT data over the last 24 hours in the live data view?

Austin Gurley: 00:57:19.810 Yeah. Okay. You can’t. That’s what Influx is doing. So anything that’s more than like a minute, we will keep the last 60 samples just because we know that the most of our devices are on a one-second transmission time. So we’ll keep 60 samples buffered for as long as the app is open and receiving them, but each time you open the app, it’s going to reset to zero. It’s going to add up to a lot of data really quick if you keep more than that. We did that for a while, and we were crashing the app left and right to try and keep that. So anything past one minute, it becomes a query, and so that’s why 10-second resolution is a good start for what you save in Influx because then, if you want to look at the last hour, 10 seconds is a great resolution for looking at a hour. And from there, it’s all Influx. Only the actual live, real-time data is MQ.

Caitlin Croft: 00:58:04.727 Do you also install an MQTT broker on the local subnet of your clients to relay to the MOXIE AWS MQTT broker in case of Internet outage issues that might occur? And can you speak to best practices for this and how you designed this?

Austin Gurley: 00:58:22.922 Yes. And this is similar to a question earlier about whether we buffer the information. So no. We don’t have a local gateway. We do support some limited bridging. I shouldn’t use that word because it’s not an MQ bridge, but we can let our customers have something like that. But no. Each device is its own gateway. It goes offline, it buffers the information till it’s back online, and we’ve learned that with Cat-M1, the data plans are so cheap, it’s almost not worth the hassle of Wi-Fi anymore. Everything, really, we’re learning should probably on a Cat-M1 plan where those problems are very rare, and it’s buffered if they come up.

Caitlin Croft: 00:59:00.653 Cool. Have you considered LPWAN communication like LoRaWAN?

Austin Gurley: 00:59:08.890 Yeah. LoRaWAN. Yeah. We have some good friends that make really good arguments for LoRaWAN. And there are some aspects of the cellular protocol that kind of could work better on - there might be some choices that, for people, are better than MQ. Part of it is we’d like to have a uniform structure for the MQ, so we’re definitely going to use that to get data. Once it’s on the internet, we’re going to use MQ - I don’t think that’s the question though. It’s what we do with local networks. So since we’re looking at these buildings where we’re having indoor trackers, if we send information kind of in a local network, it’s across the ultra-wideband. It’s not just repositioning. It has a full - you can pack data across that network. We also use Bluetooth and Bluetooth Mesh. We have a lot of battery-powered kind of Plus One sensors, so for a given tag, you can add low temperature and vibration probes around the system. If it’s short enough range, we use Bluetooth. But yeah. We don’t use LoRaWAN. I understand the benefits. The ranges that we’re talking, our ultra-wideband, since it’s in place anyway, it works well for us.

Caitlin Croft: 01:00:18.102 Have you notice any issues with collecting data using wireless devices?

Austin Gurley: 01:00:25.173 Yeah. I think, so that’s probably the same series of questions. So yeah. So yeah. There are serious issues. Don’t trust anybody’s Wi-Fi. You’ve got to have a way to buffer it. Cat-M1’s awesome.

Caitlin Croft: 01:00:36.204 And sort of on the same topic, do your devices run solely on battery, and if so, what is the battery life?

Austin Gurley: 01:00:44.074 It depends. The tracking devices can’t because the ultra-wideband requires too much power to do like a one-second update on that. Wi-Fi and LTE are not going to be happy on the batteries, so if you’re trying to transmit one-second, we don’t even try to do those on a battery. If you’re talking about like a daily summary of a motor load, yeah. That works great. We can get two or three years. I mean, especially because we’re talking about industrial equipment. So like, how big a battery can you fit in here? It’s really not much of a problem, but it’s still not going to last very long if you’re trying to stream data once a second.

Caitlin Croft: 01:01:17.945 Can we use this with warehouse management system attaching on forklift additional sensors such as pick and release?

Austin Gurley: 01:01:27.345 Yeah. Yeah. So would be happy to talk to you about that. The great benefit of each of these devices being a gateway is we can add customer-specific extra data points, so forklift, we have that pretty well handled, but it’s not tied to like an RFID tagging system that we use. But for sure, it could be integrated with your system. And again, that’s one of the benefits. The tradeoff, I guess, somebody asked, “Why don’t we have a gateway for the entire facility? Why does each device transmit to the internet?” And that’s one of the benefits is that you kind of have a local network. You can think of it as a forklift hub of information for Bluetooth and, [sure?], data points like you’re talking about to follow the forklift around the facility.

Caitlin Croft: 01:02:08.274 You might have already answered this, but how many devices can be connected with a single gateway?

Austin Gurley: 01:02:14.656 Yeah. So again, the way we organized it is each device is its own gateway. If you met a broker, it’s thousands and thousands. For each of these IoT kind of - these tags like the IoT hub or the way you’re thinking of it, it’s going to depend on how you’re getting that information in. Like on our Bluetooth Mesh, we can have 60 little data points nearby, temperatures and vibrations and things that are wireless that all flow into that one hub, but yes, you can kind of work it out pretty easily because you’re only looking at 10 bytes per data point per second, so we’re nowhere close to the limit on those things. On an MQTT broker, it’s just directly tied to what you’re paying for on the computing power of your broker. So you can have, again, thousands or tens of thousands running at once. I’m sure it’s a mess. We have thousands but not tens of thousands, so I’m sure it becomes a mess when you’re counting on one or two brokers to handle that, at some point.

Caitlin Croft: 01:03:12.495 Do you have any business contacts data such as production orders to correlate with your IoT data? If so, how do you do that?

Austin Gurley: 01:03:23.912 Yeah. That’s a good question. So that’s getting into a lot of our customers are going to have that, and it’s going to be on their Power BI system. So that’s not a place that we’ve had good access to where we can do that within our app. Of course, we’re always working on tighter integration between operations and this IoT data, but currently, a lot of customers have BI. They’re very happy with it. So we’re feeding them data points into BI where they would see something like that. And we’re working towards integrating title - like somebody I said, inventory management and things or the place to start to pick up that data. Most people have a system for that, and we’re going to meet them in the middle at BI.

Caitlin Croft: 01:04:02.358 Great. Why did you say AWS wasn’t ideal for MOXIE? Because someone just wanted a little bit more clarity on that.

Austin Gurley: 01:04:12.556 Oh, yeah. Okay. So the short two pieces is AWS IoT is great if you want to end-to-end use their systems, but if you want to have control of, in our case, we want to control our hardware. We want to control our endpoint which is our app. So it’s not a good fit for us, for the IoT system. Outside of the IoT system, well, and as an aside on IoT, it’s also using some form of MQ, we believe, and some form of a time-series database, but you can’t take those pieces out of the end-to-end system that they’re selling as AWS IoT, last time I checked. And again, this was a year ago since we moved to Influx, and I’m happy with it. The other thing is that, if you look at tools like Dynamo, it’s going to be a tool that, once you make queries against sorting and filtering like a top-10 scores on a video game or looking at things that match across all of time, that match a criteria, so it’s not time series in the way that’s useful for IoT data.

Caitlin Croft: 01:05:14.959 The Flux line seems to be reactive. Would I be correct in assuming this?

Austin Gurley: 01:05:21.747 I don’t know about any reactive in there. What’s -?

Caitlin Croft: 01:05:25.125 All right. Tracy, I’m going to unmute you so you can give a little bit of insight here. You should be able to unmute yourself.

Attendant 2: 01:05:39.613 I’m sorry. Here I come. Can you hear me?

Austin Gurley: 01:05:42.396 Yes.

Caitlin Croft: 01:05:43.175 Yes, we can hear you, Tracy.

Attendant 2: 01:05:45.367 Okay. Thanks. Thanks for taking my question. I’ve been working with this type of architecture for years to introduce it into enterprise, industrial control systems. I’ve managed a large system. But my question was really about I’ve done tons of researching on reactive frameworks such as Angular. A lot of the web frameworks that are being used today. Angular, React, and also in iOS Swift, the Swift language has a library called Combine which looks similar to the type of - it looks similar to the type of language being used in the Flux language for the database queries. I’m just thinking to myself, is this a similar pattern to the type of map filter reduce type stuff that are in these other web languages?

Austin Gurley: 01:06:58.707 Yeah. Yeah. Okay. I’m tracking you. Absolutely. Yes. And then Combine, I just looked that up. It’s new to me. Looks like exactly the same thing, and I’ll be studying that more. So thanks for bringing that up. Yes. So it’s make a query that’s already reduced to a time range and then filter it the way that you want it as it returns.

Attendant 2: 01:07:19.604 My last thing that I would say and I’ll leave you, everyone, that language right there, I’ve worked in industrial automation for 30 years. This is what’s needed. This has to be brought into industrial control systems. That language, right there, is exactly what’s needed. Thanks a lot.

Austin Gurley: 01:07:44.177 Yeah, thanks for [crosstalk] -

Caitlin Croft: 01:07:45.153 Thank you, Tracy.

Austin Gurley: 01:07:45.122 You’re right. And yeah. Hopefully, the guys making the PLCs and things will see that too. Otherwise, you can make a bunch of money translating out of PLC into something the rest of us know how to use.

Caitlin Croft: 01:08:00.132 All right. Well, thank you everyone for all of your awesome questions, and thank you, Austin, for presenting and answering everyone’s questions. Once again, today’s session has been recorded, so the presentation as well as the recording of the actual webinar will be available later tonight, so it will be available for replay for everyone, so you can share it with all of your friends. Thank you so much, Austin, for sharing how MOXIE is using InfluxDB to create your monitoring solution. It was really cool seeing how you’ve built it on Influx and all the different benefits you received. And I really love the demo part. Showing it on the iPad is always really cool. Thank you, everyone, for -

Austin Gurley: 01:08:48.593 Thanks, Caitlin. We appreciate it.

Caitlin Croft: 01:08:48.118 Thank you, everyone for - thank you, everyone for joining today’s webinar. I hope you have a good day.

[/et_pb_toggle]