Transcript.

Erik: Welcome to the Industrial IoT Spotlight, your number one spot for insight from industrial IoT thought leaders who are transforming businesses today with your host, Erik Walenza.

Welcome back to the Industrial IoT Spotlight podcast. I'm your host, Erik Walenza, CEO of IoT ONE. And our guest today is Rob Rastovich, CTO of ThingLogix. ThingLogix is a platform and service provider that simplifies the process of building, deploying, and scaling IoT solutions. In this talk, we discussed the existing suite of IoT development tools available, and tradeoffs between the leading infrastructure providers. We also explore the evolution of IoT development from bottom up engineer-led projects towards top down strategic initiatives.

If you find these conversations valuable, please leave us a comment and a five-star review. And if you'd like to share your company's story or recommend a speaker, please email us at team@IoTone.com. Thank you. Rob, thank you so much for taking the time to speak with us today.

Rob: Thanks, Erik. Thanks for having me. I appreciate you having me on.

Erik: So Rob, I think ThingLogix is a super interesting company. It's interesting that I understand that actually in addition to being the CTO at ThingLogix, you're also a cattle rancher in Bend, Oregon, which maybe a year ago would have probably seemed a little bit more on than right now I guess the feeling that you can actually be effective while also renting. CTO is maybe something that's more common, but how did you end up in that situation?

Rob: You don't find a lot of CTO ranchers around. The ranch we live on in Bend is 102 years old. We're actually the first ranching in the huge county to reach 100 years old that still owned and operated by the original family. So it's actually my grandfather's, he homesteaded here in Bend back in 1919. The technology bug kind of hit me in 80s when I first saw a Macintosh, and I thought that was the coolest thing ever, and never kind of looked back.

We've been ranching here for a long time, and it's actually people always ask me how do you get those two? How do they play together? I think everybody should, you should be a rancher or farmer, and technology because they complement each other quite well. And I always tease that in Bend when I'm around, most of the people that I know here are ranchers and farmers, and if I talk to them about IoT, they kind of look at me like I have three heads.

Thinglogix is actually headquartered in the Bay Area. So when I'm in Silicon Valley, I mainly know tech people down there, and when I talk to them down there about where ground beef comes from, they kind of look at me like really, it comes from an animal? So it's kind of a foot in both worlds, but they do complement each other quite nicely in terms of being able to be very cerebral in one and very hands on quite literally in the other.

Erik: When I saw ranch, I kind of assumed that it was the story of CTL made some money in a startup and then decided to go play with some animals in a fire by, I see this is really in your blood.

Rob: It's more like I don't know how not to raise cattle.

Erik: You've been with ThingLogix, have you been with the company since it was founded? Or because I think it might have been founded a couple years before you joined? Were you one of the founders or did you kind of get recruited as the technical head early on in the company's life?

Rob: Yeah, we're actually one of the founders. So ThingLogix was actually born of a company called 2lemetry. 2lemetry was a startup that myself, my current two partners, and a couple other partners started in 2012 timeframe. And what 2lemetry was, back then we called it machine-to-machine or MBM, but we set out to create a platform by which to ingest all this data. Because we believe even back then IoT or machine to machine was the next big thing and so we wanted to create a platform where you could do these enormous amounts of simultaneous connections and have millions of devices connected and whatnot.

And our goal actually was to sell it to salesforce.com because we actually came from, all of us, worked at a consulting company for Salesforce. We ended up selling that, 2lemetry actually was acquired by Amazon, and is today what is known as AWS IoT. So the IoT service that runs on Amazon was the technology that we pioneered over and back in Denver, that’s where we were headquartered.

Thinglogix was born out of that. Myself and my two other partners that founded ThingLogix, when after the acquisition to Amazon, we didn't want to go to Seattle, because there's no place to put cows in Seattle. And so we decided to take the customers and provide professional services against the technology that we just sold to Amazon. So, ThingLogix was actually born out of that idea of providing professional services around IoT and the technology that we had developed for AWS.

Erik:  And that was a very quick sale to Amazon when it was only a little bit over 12 months, or a little bit more than a year and a half or so between when you founded the company and when Amazon acquired it. Was that always the intent that you thought, okay, somebody is going to want to buy this technology, we just have to get it to the point where we've validated that it works. So was that clear from the start?

Rob: Yeah. Well, that was certainly our plan at 2lemetry was to do that. We had a couple failures before that. So there was a couple other companies before 2lemetry that we failed pretty good on and then 2lemetry was our last one. So it looks like it went quick, but it sure felt like it took a long time. Our target suitor was always Salesforce because we thought Salesforce would be the natural parlay into IoT. And we had to run some stress tests against our infrastructure in order to prove that we could do the types of volumes of data that we were claiming. And so in order to do that, we had to spin up all these EC2s instances, and we had to spin up a whole infrastructure.

And it was such a large undertaking Amazon actually called and said, what are you guys doing? Why are you spending all this up? Because it looked like maybe there was some hackery going on there. And then they became interested in what we're doing., and they ended up acquiring before Salesforce.

Erik: It's always kind of the story, that entrepreneurship, you see the tip of the iceberg and it looks like these people were successful overnight and then the reality is this tremendous amount of hard work under the water.

Rob: And there's a lot of stress.

Erik: Well, tell me about ThingLogix, so you started as a professional services firm. What does the business look like today, between this mix?

Rob: We started out professional services and their objective was really to be able to deliver IoT solutions quickly. We did come from the Salesforce ecosystem in terms of delivery, and consulting and professional services around Salesforce, and realize what Salesforce did for CRM, I'm sure Parker Harris and Benioff were sitting around one day and they said everybody needs a CRM, and everybody is going to need a database, and they're going to need to have contact in there and it needs to name a first name and last name and email or phone number and need to have an account and needs to be leads and opportunities.

Why don't we just build all that and give it to them? And then let people start to customize it themselves, abstract away all the complexities of DBAs and servlet versions, and all that, given web application where they can actually build a business solution.

Our objective was to take the things the building blocks that you need in an IoT implementation. You need asset management. You need workflows. You need message brokering. You need integrations. You need security. You need all these things when doing IoT delivery. And so our thought initially was, let's just build all this stuff and show up at the door with our bag of tools and say, hey, we can build your solution quicker and faster than the next guy?

Over the years, IoT has evolved actually into its own platform, whereby now you can quite literally spin up an IoT application in matter of minutes and then we give you all those building blocks and very much like the Salesforce paradigm to CRM, you can start configuring your way to an application very, very quickly.

So our platform has become as much of part of our core competency as our delivery. So, we still do professional services around the platform, but it always starts with the platform first.

Erik: So you've built up this micro service library, you have the architecture under underneath. And then it looks like you're building up a lot of maybe half-baked or half-finished templates around particular situations like your Boston Dynamics? So if that's the situation, is it that you've kind of figured out exactly how Boston Dynamics robots work and you've built up the API's and everything to work with them? And if somebody says, hey, I want to do something with Boston Dynamics, you're able then to plug in and say, okay, we've got this 80% of the way there, we just need to now program exactly what you want the robots to do. So is it a situation where you're basically building up these templates and this architecture in advance so somebody can just customize?

Rob: Yeah, exactly. The idea is so we did take and we run on top of AWS, so all of our underlying services are the serverless resources of AWS. So we don't use any easy-to-use, or any of that kind of stuff. Everything is stitching together, these best of breed micro services on AWS into a solution. I always say AWS is like an auto parts store, right? And I think a lot of times, it's difficult for everybody to understand what every service does, they use this one or they use that one. We've combined them all together to make 100% service application.

We actually install our platform called Foundry is actually installed inside your AWS account. So you come in one in instance of our platform, we give you a CloudFormation template, you do a virtual double click and it's installed inside of your AWS account, provisioning all the necessary resources. And provisions is the data stores. All that stuff is now provisioned and ready to go.

And so then we also have add-on applications that install then on top of that. The Boston Dynamics one is a great one, with the duck Spot. We started working with Spot about pre-pandemic. Our goal was actually to take spot to a bunch of tech conferences and walk them around and show up, but that didn't work out very well in the last year. Yeah, you can now have a spot implementation where we install in provision the necessary API's and stuff to communicate with Spot.

We have a people counting solutions, where it does occupancy capacity of a facility. We have a product called Work Watch, which does help text base health screening. We have one for water monitoring, that you can install. And a lot of our customers will actually build up their own type of application on type of foundry, and then they go and they start to resell their own Foundr- based application. So Foundry becomes the foundation to watch. But you're exactly right is this templated vertical solutions that sit on top of it that you can then spin up and reproduce quite easily.

Erik: We've seen interviewed a lot of platform companies, and then IoT ONE, we also do a lot of research in the area. And for a long time, there was this tension where somebody would build a platform, and it maybe has all of the required functionality, but then they find out that their end customer doesn't have the people to actually develop those applications. So you end up with a platform that has great horizontal functionality, but no kind of vertical applications or specific use cases that can be easily deployed.

And then on the other hand, you have the SaaS solutions, which provide one specific functionality Salesforce, for example, which are doing quite well on the consumer, or the traditional internet at least, but it's a little bit challenging in the industrial IoT because things are a bit more customized than they are in the enterprise. I'm curious, was this kind of intuitive from the beginning, this is the direction you had to take? Or was it specific customers that led you down this path and then just saying, okay, this seems to be what the market wants, so let's build our business around a horizontal platform, but just over time build up this library of application templates that we can provide, what was the thought purpose there?

Rob: I wish I could say, yeah, that was my intention, and I knew that from day one, that's exactly what we were going to do. But it really was I had been the architect of the platform. And when we were at 2lemetry, and we were ingesting all this data, let me spend 30 years in consulting and delivery, the first thing I look at is like, where do I put my code. I have data coming up. I have a device, it's connected, it's chirping, it's talking to me, and now I need to put logic in there, I have to put some logic on my things. Everybody needed this ability to put logic and customizations around these devices and interoperability between the devices.

So at first, it was very much alright, and that's ergo, the name ThingLogix, where do you put the logic for your things? And at first, it was really just trying to create a framework so that it was a repeatable pattern, and a scalable solution so that as a developer, I could go in and go, okay, I got a million devices and I need to say if temperature is greater than 100 then do XYZ. Or If water does exist, then tell the pump to turn off, or get some predictive maintenance.

And that's really what we set out to do was to create a platform, and a framework by which to develop IoT applications. It's very difficult to sell frameworks. It's very difficult to sell platforms. VCs don't really want to talk to you about how great of an architecture you got that you're infinitely scalable, and how much time you spend on security and how a lambda function can fire and all these different things. They want to know what is it, you can do what, how can I take this to market?

And we found out very quickly, that the story to talk about a platform is everybody has a platform, and you can't do anything with the platform. It was the first one was this smart home, and we had a customer who said alright, I got 100,000 rental properties and I want to outfit them with smart thermostats, leak detection, smoke, all these things. and I want a solution that I can manage 100,000 these properties with? Well, that's a big ask, and you need a big infrastructure.

But we also realize that, oh, it's easier to go out and sell, here's a smart home solution, okay, we got that. And it just happens to ride on top of our platform, and we can get it going. And the smart home solution can be spun up and installed. If Foundry gets you 80% of the way there, the vertical solution probably gives you a 90 or 92% of the way there and you customize the last part of it to meet your specific business needs. But those types of things, refrigeration, cold chain, manufacturing smart cities, we got a couple cable companies that are using our platform, and then they reuse it, and they build their solutions on top of that and then resell it to their customers.

It became quite evident early on that while I think the foundation was technical in the platform itself, it was important to have a good hardened architecture on it. The sales side of the house works a lot better when you have a specific vertical that you can go after.

Erik: And what is the business or your customer base look like today if you look at different industry verticals and different SMEs and midsize companies, larger corporate? Are you just all over the place, or they’re particular segments dominate your business?

Rob: It's really interesting, because we have municipalities that use our platform. We have startups that use our platform, and pretty much anything in between. And I wish I could categorize it around their traditional KPIs, midsize companies have this amount of revenue or this particular industry.

But right now, it still seems to me the way that I always categorize it even internally is our market are those people who get it. And I think we've always had a solution to a problem that most people didn't know they had. And I called the IoT lifecycle. The IoT lifecycle goes, okay, I want to connect my device, I got a temperature sensor. Can you connect it up? We go, yeah, we can connect that up and look here, data is flowing up and I can show you a little console and you can see messages flowing, you can see your MK HD feed.

And they go, oh my gosh, that's so cool. And then the next thing they say is can you put it on a graph? Well, yeah, put on the graph here, you can see your graphs, that’s so cool. Then they say, well, can you have it send me a text message when temperature gets to be 100? Yeah. But could have to send you a text message? And then they say, okay, can you connect 10,000 of them? Yeah, we can. And then they have what I call the ‘oh, shit’ moment, they go oh, shit! Can you stop the text messages, get rid of the graphs, and can you make the things smart enough that I never have to deal with it again that could be able to fix itself?

And those are the companies that start to get to it and there's that process, and some of them get there quicker than others. We have municipalities that get there pretty quick. We have larger municipalities that take a much longer time to get there. You have entrepreneurs that one day you start to explain what connected device does and talk about, the lights just kind of go on and they go, oh, my God, this is going to be amazing, I can do this and I can do that.

And quite frankly, the whole COVID thing where people have now deurbanized and move home has really started to get people start to thinking about their business model and how they're going to work on that. They have the problem that we solve, and the lights are starting to go on. So it goes across the industries. It goes across size, but I think it's going to start leveling out a little bit in terms of the size of company that we can service.

Erik: Sometimes it's very clear, we build a SaaS application, we are some particular asset class. But often it's a bit challenging, but it does tend to be okay, we work with companies that understand what we do. If they don't understand what we do, then it's too challenging of a process to try to work with them. So it's more important than mindset as opposed to what specific industries are in many cases.

I imagine that also means because you're working with such a variety of companies that the business model also differs. If you're working with a startup, they might just say, hey, this is a great platform I can build on, let me access the platform and run with it. If you're working with a municipality, maybe they say okay, here's the budget, I want you to build the solution and make sure it works. So you have the platform, you have application templates, and then you have your services, so is it three different business models that maybe all three of them could apply to one situation, or somebody might say I just want the platform, or the platform and an application? What does that look like from a business model perspective right now?

Rob: Everyday internally, what do we want to be when we grow up? The answer to that question seems to be different depending on who your audience is. If you're talking to a potential investor, you're talking to a potential suitor or you're talking to a customer, sometimes it varies.

So I think right now, where our revenue is split, or almost 50/50 platform licenses versus professional services, but it does depend on the customer too. So our pricing model is we have a basically an all you can eat model enterprise licenses take all you want and this is the feed. Some of the startups, they come to us and they say, well, we don't have development resources, but can you take care of it for us? The Foundry is a multitenant architected solution. So we actually run a couple are of our own instances that are multitenant that you log in, and we give people the ability to try before you buy.

But for startups, they want a per device model like okay, every time I turn on a gateway, it's $1 a month. Or we have X amount of trailers out there, and I'll pay $0.50 a month for the trailers. Some of them are more in terms of data consumption. Because in IoT, you can have a million devices that trip a little bit or you can have a few devices that triple lot. And in terms of processing power, and actual hard costs, those two could look very much the same.

So in the one where you can have a few devices, and they're really chatting the tripping all the time and it's very complicated and you're doing a lot of integrations. That could be just as expensive in terms of compute power and cost as a million devices all chirping one today. It kind of depends on the model and we try to be flexible for each so that it makes sense for the customer.

Erik: It provides this tremendous array of opportunity for business model innovation, but then it also makes it very challenging to figure out how exactly should we price for something. I mean, for your customers as well, I imagine they have the same challenge, right? They're building some device or some solution, maybe using your architecture and how are they going to charge their end customers.

Rob: We talk a lot about the connected economy or the subscription economy. I think, the more we're actually moving towards this subscription type economy where we have cleaning as a service, we have connected vacuum cleaners that are looking at doing cleaning as a service, instead of you going and buying a vacuum cleaner every two years, and then not knowing what the bag is that it goes in there, and you don't know where the filter how to change it, and the belts break and two years later, new technology comes out.  Actually, they're looking at the idea of doing a vacuum cleaner is a subscription. I'll give you the vacuum cleaner, the filters will show up, the belts will show up when you need belts. We'll swap it out and in two years when new technology comes, we'll give you a new one. And that business model on a subscription based economy depends a lot, obviously, on the per unit transaction, how much does it cost to keep a single unit code?

Erik: Actually, one thing that just struck me as you were describing your model, which is, who are you selling to, because this mentality topic is so important and there's the traditional are much discussed, IT/OT divide, where the IT folks, it's much easier for them to understand your value proposition, but the OT folks are the guys that are really running the core business, and are going to be most directly impacted by anything that you do in many cases. Who are you usually selling to? Is it which functions, which individuals or titles would be the people that you would actually be working with here?

Rob: That has dramatically changed over the last five or six years. So when we first started this, we were working with the engineers in the basement who had heard about machine to machine or IoT, they got a Raspberry Pi, and was able to turn the light on and send some data up. They were going into the enterprises going, I got an idea. Why don't we can connect this and they would have to get support from the top and try and make their case all the way up? But these days, it's really coming top down.

IoT is prevalent enough, and enterprises, they got a long way to go in terms of, I think, reengineering their business models to fit an IoT or connected economy. But the C suites are actually starting to take notice and going okay, I think we could have a competitive edge with this. And now, bring it back down to the basement and going okay, this is what we would like to do. I think we can do this, now can you guys help make it happen?

And we still do get the technicians. We have a lighting companies where we're creating mesh networks in the fixtures and whatnot. And it's just now getting up to the point where they said, okay, well, it's stable enough. Yes, we've proven out the concept, let's take it to market. So there are still some bottom up, but I think we've at least crossed the halfway mark. We're talking to the business folks. They're trying to come up with the value proposition for their particular industry, and then bringing it down to the IoT and say, okay, guys, how do you make this work?

There's still a lot of IT departments who say MQTT, they think maybe you misspoke HTTP, right? And so, they're looking to have something to guide them how you handled this event driven type of architecture, as opposed to the old request response stuff that is still most prevalent.

Erik: So you've already described high level what the architecture looks like or that you're at least building on the AWS architecture, is that the same for AI solutions that I understand you're also developing now, for example, there are you primarily building there also on AWS has solutions? So can we understand this as basically you have used AWS as the toolbox, as you say, and then you're using that kind of combining those parts into different modules but underlying would be primarily the AWS architecture. Is that a fair description?

Rob: It is, yeah. Because of the acquisition at the heart of ThingLogix is still the AWS IoT core, which we were part of, it's very different today than it was five, six years ago, but that was at the heart of it, and then everything else starts to surround that event based message bus that comes through there.

So we haven't released but we are in the works of an Azure Stack, and probably way down the road, another stack that may run off of some of the Google platforms. Now, we also have interconnected stacks. We have customers who may be using azures ingestion layer, but their developers want to use lambda functions. And we have the opposite. We have, okay, fine, you can keep your lambda functions and use Cognito for your security and all that stuff. But I want the data sitting in a SQL Server. We can do those hybrids, and move them over. We don't have a full 100% Azure Stack. So we still have the hybrid. But we are looking to do that because we've actually been getting as of late more requests for an Azure Stack, or at least a choice between AWS and somebody else.

Because most people, especially if you're in the consumer retail space, there's a lot of consumer products that are IoT. Of course, there's a bit of a hesitancy to do anything, Amazon. Well, technologically, we know there's really very little that Amazon's going to do or can do with your data, but it does the optics of Amazon coming in and having all your data. Plus, because we have a very large, Middle Eastern Division, so our Middle East and Dubai is probably our fastest growing segment by far. And that data needs to stay resident in the UAE. And so we'll do have a fog type of solution so that the data at rest is actually either maybe sitting in a data center that is in the UAE, but Amazon has just opened up another data center there, but still keeping it in country in Europe till it becomes an issue. So doing some of these hybrid solutions definitely is part of our DNA.

Erik: I'm sitting here in Shanghai and in China, and that's always top of mind, right? How do you manage data across borders? Especially you have a lot of manufacturing bases here, and of course, headquarters would like to see what's happening in production. And I think right now, it's still a little bit of a gray area where you can kind of do what you think works makes most sense. How does that typically work then? So because I guess you have the similar situation where there's somebody outside of the entity that would like to aggregate data, but there's some government regulation that requires data around PCI or something that's held in country? So do you then store that data in country and then somehow aggregate it before sending it abroad? Or how do you manage that? Or how do your customers typically prefer to manage that?

Rob: Well, if the requirement is that it all has to be in country. So right now, if inflight, and at-rest have to be in-country, we don't accommodate that. Inflights of data coming up, and is being ingested, but is at rest in another country, then we can. Because we're all 100% API driven, so everything sits on top of an API, that API happens to be served up through Amazon's API gateway, but it just decides where the data is going to go.

So if the API says okay, well, the data is inflight and I got a store it someplace, don't store it here, store it over there, but then it goes over and gets it. So it switches inside the API and configurations that allow it to move the data to where you want to do it. Actually, for POC, we ingested in on Azure, it was in flight on AWS and stored in big data on Google, and then ran Microsoft functions and Google go on each of their platforms,

It's still for the purists that 100%, and especially in the Middle East, they have one 100%, even inflight data, it can't go exceed the borders. So that is what we're working on and probably not this year, but next year we'll have a fully in-country solution. But it's also we're going to be riding the coattails of some of the partners because like AWS is putting almost a lot of resources in that. And I'm not sure what Microsoft's plans are for that. But I know that they're a little bit more easy to be on-prem.

Erik: I'm curious, your perspective on what differentiates AWS Azure, Google, and you’re maybe a little bit biased here, but my understanding also is that AWS IoT has traditionally been kind of the market leader in terms of bringing functionality to market. But what is this situation look like today? Are there significant differences in their capabilities or in terms of their ease of working with these different platforms, or they kind of converging around a certain set of functionalities and processes?

Rob: It's a moving target. I think that the recognition stuff that Google has been far superior than what Amazon has. Amazon just came out with the text extract recognition. We were using Google's photo recognition and text extract recognition and all that stuff long before we use at Amazon. So for whatever reason they just seem to do a better job of that.

I would say, to me, the Microsoft is a little bit like the Netscape Internet Explorer thing. Netscape was the only browser we had, and Microsoft was a little late to the party. But once they got in and got going, they exceeded Netscape and what it could do in terms of volume of people that were using it. I do think that you're seeing that same kind of paradigm. I think Amazon got the jump on everybody in terms of IoT and the whole serverless thing. But I see it's not going to be a one horse race at all. I think Microsoft is fast approaching and catching up quite quickly.

One of the advantages I think you have obviously with Microsoft is I always think of Microsoft more as a development an IDE, Azure is as much to me an IDE as opposed to more what Amazon is, which is micro services. If you're going to be an Azure developer, and you're going to get in there, you're going to have everything at your fingertips. And you want to make a data store, you just spin it up and you make it and all these things are available within even your development environment, whereas Amazon, you would have to pick and choose and get the services over there.

So I think Microsoft has a little better in terms of their developer network. If you're a Microsoft developer, you tend to be pretty loyal. And I think it is a little bit easier in terms of being able to spin up these solutions than you can on Amazon, because it doesn't like give you that ability, you got to kind of understand each one of them a little bit. I don't know the numbers in terms of amount of users on each one of them. But I would just say from having worked with them, that Amazon has been at the forefront, but I think is going to be a pretty good horse race here.

Erik: Well, that's good competition that’s useful here. On this AI topic, I mean, it makes sense that Google would be a bit ahead there, just based on this really the core of their business. I guess you're using different AI solutions based on what type of problem you're approaching. But AI, there's always been this kind of challenge in the past where you say it's AI, but then under the hood, in the worst case, it's a bunch of monkeys typing code, in the best case is a bunch of data scientists also putting in tons of hours to somehow extract insight. What are the use cases today where AI should work, which is with relatively little human labor you're able to extract some insight from a complex situation?

Rob: I think there's a lot of “AI” out there. There's some AI that people call an AI that's a bunch of “if else” statements. At best, at worst, they're like doing string parsing to see if it does contains a word or something. So AI, getting a result out of artificial intelligence is kind of the easy part. The hard part and the most important part of AI is the learning part, the teaching part: getting it that data that makes it smart enough to actually give you a usable and accurate result.

But what Foundry and Thinklogix can do is where we actually do very, very well at facilitating that learning model. So for example, let's just say you have a connected washing machine, and it's sending up about 12 different points of data, well, in order to get your AI model to do a predictive analysis of when that washing machine is going to break, you need to have a whole bunch of data. Like so let's say the washing machine sends a data every minute, so you need 1,000 minutes a data coming up. But the most important thing you need is somebody to go right there at 0.1023 it broke, that was at the point that it broke. And at 1200, we fixed it. Okay.

So now we have a data set that is reliable, that says, oh, there was good, good, good, good, good, and now we broke it, and now was good, good, good here, and because we have all the data coming up, and we can set those initial alarms and results, and you can see those, you get a good historical data. So once you say, alright, now I've got 100 of those, and I got 100 machine washing machines, and I got 1,000 minutes in each one of them and it shows exactly where the pain points was and I was able to collect that across 100 of them, and give that today sciences, now I can take that model, send it over, and start getting real good data.

Because back in the near the days, the very first thing any of us learned in programming was garbage in, garbage out, right? That is so much more true with AI, if you teach it incorrectly, you can have artificial ignorance probably easier than you can have artificial intelligence, because you can easily get a bunch of bad data and that's kind of the fear that is out there amongst the non-technical is, well, what if the AI, either A, knows way more than I want it to, or what if it's wrong? So I think we really kind of focus on that, alright, let's get those data models so that we can get good clean data, have it verifiable, and then improve the model that teaches them.

As far as the algorithms, they're just getting better and better. And when we first did this, Amazon came out with machine learning, they had the one algorithm and now with Sage maker, and you kind of pick your flavor, and then Google has several of them. And even the GE, the Predix and IBM, and there was it Watson, I guess they have, so they all going to kind of flesh out to be reasonably good. But to me, it's who's teaching it and what are they teaching it?

We did a test with the NFL like I'm sure everybody else did and we inputted a bunch of player data and then matched up teams and see how we did. And we got pretty close. I think the one interesting one was we had a water polo. We were working with the Olympic water polo team, and they were tracking kids’ stats. They'd run them through basically a fitness course and they tracked how fast they run, how fast they threw the ball, various things outside of the game.

And we put those in the model and then put the teams together, and it was came out to be 100% accurate, as long as the score was greater than I think eight points apart. So as long as it was basically a blowout, we got 100% accuracy, we got really good. But when the score got really close, it came down to intangibles like the coach, and what did they have for breakfast, and he was feeling what?

I think right now, AI is really good at the obvious and the blowouts, but it's going to get better. And in order for it to get better and better and better, the data points are going to have to get more and more granular and more and more accurate. And I think that's one of the things that we do really well at.

Erik: And that's, yeah, I guess that's the other challenge, here is getting access to good, high quality data in a reliable way which you're also working on. Maybe we can run through a few case studies here. Are we trying to get reliable data? Are we trying to automate and apply some sort of machine learning? Maybe you can just give us a little bit of the background of what was the core objective here? What did you do, and then what was the result?

Rob: One that I think is really interesting we're obviously an IoT company. But the United Way had approach to us, they had a grant, and they wanted to create an application that helped people get out of poverty in the Silicon Valley. So what does that have to do with IoT? Well, it occurred to us that a business or an agency is nothing more than something that chirps data. And so what we did is they wanted to create a system by which you could have a common view of someone who needed assistance.

So if they went to the food bank, you would know who they were there, and then they went to a job training, and then if they went for shelter, and then if they went for childcare, being able to all those agencies had different systems, they all couldn't integrate with each other. And so essentially, we just enabled the database because the database is a device too. A database can chirp and send data just like temperature sensor. And we actually have little plugins that go on to all the major databases that allow them to chirp out data that's been deemed chirpable. And it was able to bring it in.

And as we brought that data in, you could follow the care of an individual across the agencies. And the United Way could then look at that, and then provide holistic care to that individual and then also, they would be able to appropriate funding accordingly to where they saw the need and where it was being used the most.

One example that was not IoT related in the sense of it wasn't a device but something that's chirping, and when we talk about the Internet of Things, I always say we should be talking about the Internet of everything, everything is connected. When I say connected, I mean anything that can speak, anything that can chirp, can send a message. And that can be a temperature sensor, it can be a database, it can be a business, it can be a person sending a text message, and all that data, that connectivity needs a place for its logic to go. So that's one that I wanted to bring up is a really good use case and we were able to build an event-based message-based architecture on top of an IoT platform.

Erik: My intuition has always been that this issue in the Bay Area is somewhat of a local issue. But it's also if you pull that string far enough, you might find that, just as engineers from across the world migrate to the Bay Area to work engineering jobs, people that are in a tough straits also probably, to some extent migrate there because they provide good services and they have a nice climate. And if I'm living in Chicago, in the winter I might think, hey, you know what, better to be in San Francisco right now, let me get a bus ticket.

And then you come across this bigger problem, okay, you get the data locally that points to the path people are falling, but how do you track that back to the places where they're first encountering challenges? Maybe there's abuse in the family or drug issues in the school, whatever that may be, and it might be 10 years before You're actually contacting that individual in San Francisco. Like you said, it's just the more data you can pull together especially in a situation like this where there's a human lifecycle, if you don't have that data you're only looking at a snapshot, and very hard to make decisions.

Rob: It'd be the same thing if we talk traditional IoT, you don't want to look at just one device. You want to look at where that device sits in context. What factory is it in? What line is it in? What is around it? And having that context involves a lot of different stuff, it involves actual data from database. It involves metadata. It involves integration with other systems and bringing those in. It involves security. It involves the ability to cause an effect this needs to do this, and you need to be able to put some if-then-else statements someplace. When you start trying to deliver a solution in an event-based IoT world, you come across these problems, and that's what Thinklogix actually became to do, is solve those.

One of the other use cases we had came up during COVID, this is one of our vertical solutions that we spun up was the idea of schools and kids returning to schools or being at schools and being able to do self-health assessments, being able to track who was at school today, who was on campus today, who was in what classroom, all those kinds of things. So we ended up getting again, students as a device, if you will, the system would text message every student and say, alright, you got to take this self-assessments, a little chat bot walks them through their self-assessment for that day, returns them a QR code.

And then we have at the schools, kiosks where they walk up to, they scan the QR code, they recognize who they are, that they have passed, the self-assessment, takes their temperature, but some in, and then the teachers have mobile app version of that. So as they come in the room, they scan them, and as they go out the room, they scan them. So they turned out very useful in the sense of if they had a reported case of COVID, they could track really quickly to where the students were on campus.

And so that we actually worked with the school administrators actually came to us. So we have a compliance issue that it's today, this is a compliance requirement from our particular county in our particular state and then it changed the next week, and it continues to change. It's starting to stabilize a little bit now. But with the platform, we're able to make those adjustments really, really quickly. The platform doesn't require so much changing so much code that as compliance needed to change and paradigms needed to change, we could adapt to that really quickly.

And probably the third one is probably really more as strictly IoT is we do river monitoring. So the challenge there was they didn't have the ability to put a connected sensor in the water where we wanted to measure flows. The idea was to measure flow coming down this river for flood control, and those types of things. But more importantly, like the amount of water coming down this river today determines, and this is what's near and dear to my heart, how much irrigation water the farmer gets a week from now.

And so we put in a recognition video camera that has two fixed points on either side, and some smarter people than me came up with the algorithm to determine the water flow coming through those fixed points. When that data comes in, being able to process that in real time, and then being able to provide water predictions for agriculture and farmers, in some cases hundreds of miles away, because all this water is coming from a particular thing. And that's a really water conservation, being able to manage our resources efficiently, to me, that's really the really exciting part of what we do.

Everybody always talks about our dark side of they think we're collecting too much data and we know where too much things are. Well, I think are a real bright spot in that is being able to do things like do water efficiencies, environmental efficiencies, agricultural efficiencies, and really be a technological solution to some real ecological problems that exist.

Erik: I mean, this is just a very powerful tool and hopefully, we'll use this more often for good things than for bad, but it's certainly a very powerful tool. Rob, this has been really interesting conversation. Is there anything either that we haven't touched on yet that's important, or anything that's maybe around the corner for ThingLogix that you want to share with us?

Rob: Our vision, we did just come out with an edge technology as well. So we're trying to actually take the platform more to the edge. So we obviously started as a pure cloud initiative, but we're taking some of these micro services, down to the edge, our recognition and stuff, we’re doing more processing at the Gateway and level. And our vision really is to become cloud of clouds: a system that doesn't really exist necessarily on AWS, doesn't necessarily exist on Azure, or doesn't exist in Google, and it doesn't exist on prem, but it exists in all those places, and none of those places.

I think that as I look at the future of what this holds, it's just going to become more interconnected. And I think we're going to need that. I imagine a day when we can determine Alright, well compute power happens to be cheaper on Azure today so I'll run it over there, as opposed to run it on AWS. I think you're going to see ThingLogix been coming out with a lot more of these vertical solutions.

We got some exciting ones that I think are in the hopper right now, where we're going to be able to spin them out. And we're actually looking for partners to help run those vertical solutions. We don't want to actually be in the business of running those. So we keep looking for partners who want to run these business IoT types of solutions as well. So that's kind of what our direction is for 2021.

Erik: If a partner or potential customer wants to get in touch with you, what's the best approach?

Rob: Go to our website, we have all the traditional ways of getting a hold of us with email, but no facts. By all means, get a hold of us, and you're welcome to contact me directly, it is Rob@thinglogix.com, and we would love to share the wealth.

Erik: Awesome. So Rob, yeah, thanks again for taking the time. Really appreciate it.

Rob: Erik, thanks so much. I appreciate you having us on.

Erik: Thanks for tuning in to another edition of the industrial IoT spotlight. Don't forget to follow us on Twitter at IotoneHQ, and to check out our database of case studies on IoTONE.com. If you have unique insight or a project deployment story to share, we'd love to feature you on a future edition. Write us at erik.walenza@IoTone.com.