Learn about NexusCon!
Happy Thursday!
Welcome to this week’s deep dive exclusively for Nexus Pro members. It’s an honor to have you here. This deep dive is a follow up to my recent podcast conversation with Andrew Rodgers, co-founder of ACE IoT. I learned a lot from this conversation and want to share my takeaways and the full transcript with you below.
In case you missed it in your inbox, you can find the audio or video here:
Nexus site | Apple Podcasts | Spotify | YouTube | Add to other podcast apps
Enjoy!
—James
My inner nerd was fully satisfied with this conversation… thanks, Andrew! I learned a ton but want to key in on two things specifically.
The first was the context around the creation of standards in our industry and how they’re different than other industries. Here’s Andrew:
"The folks who participate on those standards committees, while they're generally open committees, like who has time to actually do that? It's people being paid from large vendors to represent that vendor's interests. So when you look at something that is. A hundred percent. I love standards.
Standards are great. Standards should exist and we should be working on, more and better standards, even though it ends up with us having one more standard. We still obviously haven't reached the end, all be all standard. But. The thing with standards is when you have all those large incumbent vendors represented so well on those committees, it means that the standard becomes a least common denominator in almost all instances."
Honestly, this just pisses me off. Why are we letting vendors with a history of lock-in decide what open means? Shouldn’t ASHRAE’s goal be results, not protecting the interests of incumbents?
Anyway, rant over. I do love the unspoken context. It’s thick in our industry.
The second thing I learned was that APIs have three layers of nuance to them. (1) how the API works and (2) what it does and (3) can it do what I need it to do in the future? Here’s Andrew:
"What I’m buying today, what I'm deploying today, what I'm investing my time to learn, those kinds of resources. Is it going to still be of value in 10 years? Is everything I learned about Johnson's proprietary communication protocol from, their edge devices from 15 years ago, is it still valuable today or are there other things that have supplanted it that I really should be thinking about?
When you look at an API, it’s not just from a technologist perspective, but how does the API work? Is it similar to other APIs? That sort of thing, but the individual capabilities are all based on those use cases that you have for your clients.”
By the way, I love this primer on APIs from the Technically blog if you’re new to this topic. It’s got some fun doodles…
(image credit: Technically)
Finally, I’m planning on digging into VOLTTRON with Andrew soon. What should I ask him?
My highlights:
What did you think?
Note: transcript was created using an imperfect machine learning tool and lightly edited by a human (so you can get the gist). Please forgive errors!
James Dice: [00:00:00] Hello, friends. Welcome to Nexus, a smart buildings technology podcast for smart humans. I'm your host, James Dice. If we haven't met before, I write a weekly newsletter on the same topic. It's also called Nexus. Each week I share what I've learned, my opinions, and what I'm excited about in the quickly evolving world of intelligent buildings. Readers have called Nexus the best way to stay up to date on the future of this industry without all the marketing fluff. You can check it out and subscribe at nexus.substack.com or click the link in the show notes.
Since starting the Nexus newsletter, many of you have reached out to me wanting to talk shop, and we have. After a few weeks of those wonderful conversations, I realized I needed to record and share them with our growing community. So here we are. The Nexus podcast is born. This is our chance to explore and learn with the brightest in our industry together.
episode 20 is a conversation with Andrew Rogers, cofounder of ACE IOT. This is a great primer on what the word open means for buildings open as a very controversial and murky topic. I think Andrew clears some of that up in this conversation. It's about choice. It's about self actualization. Just like I said, with Cory in the intro to episode 11, don't let the deep nerdiness of this conversation scare you away.
If we could unlock the data in our buildings and open up communication, we could do things like help mitigate climate change, create healthier indoor environments. And finally actually automate our buildings, Andrew and I talked about openness definitions and walk through each layer of the smart building stack to unpack it in depth, including how we can learn from slime molds, who have it all figured out.
This episode of the podcast is directly funded by listeners like you who have joined the nexus pro membership community. You can find pro on how to join and support the podcast at nexus dot dot com. You'll also find the show notes there, which has links to Andrew's LinkedIn page. Oh, and by the way, if you take a look at your podcast feed and you're missing some episodes, that's because those episodes are exclusive to members of nexus pro sign up for a pro membership to get your personal podcast feed with access to every episode.
Without further ado, please enjoy nexus podcast. Episode 20. alright. Hello, Andrew. Welcome to the show.
Can you introduce yourself for everyone?
Andrew Rodgers: [00:02:22] Yes. I'm Andrew Rogers. I'm a cofounder of ACE IOT solutions. We're a software company that, offers infrastructure as a service for companies who want to use an open source technology called Vultron, in their smart buildings, projects or, systems or platforms.
James Dice: [00:02:39] Cool. All right. And we're going to get into Vultron in a little bit. Let's start though, with your career history, how'd you get to founding ACE IOT. And what have you been up to before that?
Andrew Rodgers: [00:02:48] my career has been pretty varied. pretty broad. I got started at a fairly young age in the industrial automation space, specifically industrial it systems.
At 19, I was in a triple reporting role to a, plant engineering manager, plant maintenance manager, an it manager for a 600 employee, factory with about, 70, connected, HMI it systems, and had to manage those. And. Generate a backup plans. And of course they're all different vendors and they have all the same problems that this space has.
so I did that for awhile. went back into kind of more general it back into industrial automation. a little stint in some buildings, 12 years ago. And then got really involved in smart cities. And so I spent the last five or six years really deep in the smart city space working on, citywide strategy, and research projects with both our local university and our local municipality.
and then that's how I got introduced to Vultron. Can I met some folks through the smart city ecosystem, and then really, dove into the Vultron world, helping. the city of Washington DC deploy and build out their infrastructure for their smart building portfolio.
James Dice: [00:04:01] Got it. Okay, cool.
And before we dive into our main topic, what is, Vultron just like short description for people that have never heard of it before.
Andrew Rodgers: [00:04:10] Vultron is a box of Legos. Okay. You can build a I'm sorry for the, uh, fence out there. Lego system bricks, that you can build smart. And connected grid enabled, buildings, are building integrations with and micro grids.
It's all things distributed energy. it's not necessarily a product in the sense that we think of a lot of, vendor platforms in this space. it's just a technology that can be used. and you can build a lot of other products on top of it.
James Dice: [00:04:41] Cool. And it was developed by the Pacific Northwest national lab originally.
And now it's an open source project. Is that right?
Andrew Rodgers: [00:04:48] That's right. Yeah. It's part of the eclipse software foundation now.
James Dice: [00:04:51] Cool. All right. Sweet. So what does ACL IOT do for your clients and how do you work with your clients?
Andrew Rodgers: [00:04:57] so it varies. we. Our primary business is a software slash infrastructure as a service.
we will use our cloud platform to manage Vultron instances at your customer sites. make sure they're running effectively, fully updated, patched, all that stuff. configuration management. And then send that data to whatever system that you're building. If you're, a software company or another technology company.
we also do some consulting work in the sort of infrastructure, Space for data systems, in both the smart building space and the solar energy space. and then yeah, a part of that, is also focused, not just on what we think of as large scale commercial buildings, but other places where, grid, interactive building technologies are useful.
So like we've got a project right now with Embry and some of the other national labs working on some residential applications where we're using Vultron for behind the meter optimization.
James Dice: [00:05:55] Got it. Cool. All right. So this is the point of the conversation we're asking my favorite question. why are buildings behind, decades behind other technology?
like the technology in our pockets and you know that we're talking over right now. Why are buildings so far
Andrew Rodgers: [00:06:11] behind? So I like to think about it in terms of the pain consumer distance. For consumer facing technology, the feedback in the market, like, you know, people talk about the market working in all kinds of mysterious ways, but if you don't have a feedback path, the market doesn't work.
markets don't work. If there is no feedback. that's when you look at things like the financial crisis in 2008, the housing, that was the problem. The feedback loop was broken. So the market wasn't actually self-regulating, When we look at consumer technologies, if someone releases a phone that is terrible, people don't buy it.
and that's your feedback loop? It's the last one technology cycle. And the people who are paying for the phone or the people using the phone. And I think that's the big difference. the people paying for smart building technologies are not generally the people using the smart building technologies and that is throughout the stack.
So that's, the people buying the buildings are not the people occupying the buildings. The people choosing the vendor relationships are not the people that are deploying and programming the people who are having to do the commissioning and the fact that commissioning needs to exist as something to bring together.
All these systems after they've already been deployed by their respective vendors. aren't the ones selecting or choosing the equipment that's being deployed. so the further you have that, the distance between who feels the pain of the choices you're making and who has to pay for the choices, I think that the slower your progress is, and, the more sort of dystopian, a reality you can end up in I think.
The evidence when you, posted this morning about having this conversation and got pretty, maybe not the most feedback ever, but very fast feedback. I think that's evidence that people know something is broken. but there isn't really change happening to affect that.
James Dice: [00:07:59] Totally. Yeah.
and there's certain words that when you bring them up, people are very, they just jumped in right on them. and that's, yeah. Want to talk about today, but first on that answer, what do you see as the ways like in the marketplace that you're seeing? I guess that feedback loop get closed up.
Andrew Rodgers: [00:08:17] yeah, I think you talk about this a lot. When you talk about, advanced supervisory control 2.0. When people are building platforms that are reaching the tenant. I think that's an important piece. I think that the fact, the tenants themselves elves are starting to make these demands.
they're seeing that it's broken, that it doesn't work like their phone does, et cetera. I think you've had a few guests recently who are all working on platforms that. Are thinking about the user experience all the way out to the tenant level. I think what we're going to talk about on the open side, Mike broom in that conversation, they're definitely thinking about that as user experience, down the stack.
and I think that perspective is what's going to move us forward. I think the old perspective of. how do we have a flashy demo at AHR and get a new distributor signed up for our platform is not how you move the industry forward.
James Dice: [00:09:10] Totally. I love that answer and I love how I'm getting different answers.
So thank you for bringing some diversity to, the answer of the question. cool. So let's dive into our main topic. So Andrea, you were referencing the post I made on LinkedIn this morning. So thanks to everyone who contributed to our outline for what we're about to talk about here. But, it really was.
This conversation about what open means really became clear to me a couple of weeks ago, like how important it was because I posted about JCI is open bloop form and that post got, I want to say 120 comments, something like that by far the most popular yeah. Most engaged with posts that I've ever done.
and I've done a lot of posts and that one seemed to really strike a nerve. And for me, it was what it was about. I don't know it is what was about for you. But for me, it seems like a lot of the comments were debating what open means and like what the definition of it is. And I think mostly everyone was agreeing that JCI has definitions.
Probably not it, but what is it is the question. And I think that's what I want to get to. Today. So with that, we have a lot to cover
Andrew Rodgers: [00:10:18] and there's a lot of different
James Dice: [00:10:19] ways that we could take this conversation. I think, but what I want to start with is around myths. So what are the biggest myths when it comes to the word open in our industry to you?
I guess that's a good place to kick it off.
Andrew Rodgers: [00:10:32] I do come at this from a little different background because, I do have more of a history in the technology space. And, when we talk about open and the technology space, it just has a very different meaning, than what I see, at least marketed as open in this space.
obviously there is open and open ecosystem and then there's open and open source. And I think those are key distinctive things that, there are different, both in technology and in this space. but I think that the people in the technology space seem to be more well versed in the nuance and difference between those two.
And the people in this space seemed to have, not a lot of examples to look at other versions of that. and I think when you talk about open, when the people that are dominant in this industry, talk about open, they talk about open ecosystems and they're worried about things like vendor distributor agreements.
it's, almost, policy-based more than, Practitioner or, individual contributor based like how does an engineer interact with this? and so I think that's, I don't know that I would say it's a myth. I just think it's like a fog of war over the entire thing.
Yeah. There's just because you have some, very dominant players in the space, put out a lot of volume of, content and just marketing. It's hard to find those like concrete answers, and really, open kind of, I was down to an ideological position. you can say, it's only open if it's, in software, we talk about.
Libera which is like this concept of freedom of speech, like free as in speech. And then, you have free, which is, free as in beer. and it's interesting cause like neither of those really play in this space. there's nothing free. It's just whether or not, there's additional restrictions on if you can play once you buy, once you pay for it, can you play with it?
and. Aye. I don't know that like I'm the person to say, here are the myths. Like here are the things that this industry has a hundred percent wrong. I think my perspective and what I want to bring to this is, Hey, there are other industries that have gone through these transitions from closed ecosystems to open ecosystems, or more closed ecosystems to more open ecosystems.
There's a lot we can learn from those. Those transitions and transformations. but we do have to stop navel gazing, whether open blue is open. Is, a concrete answer that is going to depend on a lot of factors of what you care about. And when you say you want something to be open, but do I think that Johnson controls is going to tell this industry what open is?
No, I think if you let a company like Johnson or Siemens or any of the big vendors define that for you, the industry loses. So I think the most important thing about this whole open discussion is that people really are able to enumerate what they care about, why they're making decisions, and get beyond the marketing, honestly.
regardless of. How open. I mean, I think, even the conversation this morning and people contributing to, the questions to ask, it was obvious that there were people coming from very different perspectives. and there were people very happy with, a mostly proprietary system, and calling it open and saying it solves my problems.
And if it does, that's great. But I think we get back to the question of, why are buildings, decades behind other tech? And no one's arguing that they're not, I see very few arguments that they're not,
James Dice: [00:13:58] haven't had that answer yet. No, one's arguing with me,
Andrew Rodgers: [00:14:01] but you hear so many arguments defending the status quo, and why things should be the way they are.
Yeah. and I think you just have to say, okay, we've been doing this for a long time, and this is the result it's gotten. there's gotta be a different way. And I think people coming to that realization on their own is going to be, and learning enough about how other industries have done.
This is going to be much more impactful than you or I, defining here are the rules. I do think it gets down to. What are the capabilities that are unlocked for me. And then once you say, okay, these are the capabilities I need. and this is how an open or proprietary ecosystem solves those, or allows me to solve those for my clients.
then it really can become preference. I don't think anyone's saying you cannot solve problems in a closed way. it's just that if, this is where I would lean back into the workforce discussion because I think where these decisions get made in the stack is very different between BAS I think we talked about the pain consumer distance.
I think that. On average technology workers, specifically, in smaller startups in that, and that sort of ecosystem, the practitioners who are writing the code, who are solving the problems, the engineers that are really, focused on. Problem. Like the thing in front of them have a lot more latitude on picking the tools they want to use.
and that has driven a lot of how open looks and works in the technology space that is just unparalleled in the BAS space. Got
James Dice: [00:15:30] it. Got it. Okay. Yeah. There's a lot there.
Andrew Rodgers: [00:15:33] Yeah. That was a very rambling answer. I'm sorry.
James Dice: [00:15:35] I think what I heard from me, if I could repeat it back, it's myth, number one is there is no definition, overarching definition because it depends on what you're trying to accomplish.
It depends on what you want out of your given project that your given building. I think number two is there seems like there's a myth around. And maybe this is coming from the incumbent vendors when they proport it. But I think that I'm seeing incumbent vendors saying you shouldn't want open because what we're providing is interoperability.
And so it seems like there's these two, like open versus interoperability, it might be some confusion. And so I wonder if that's a place to take this next, which would be like, What are the differences between those two words and like, why would you want open versus inter-operable?
Andrew Rodgers: [00:16:18] Yeah. And I think this goes both ways, you can have systems that are interoperable, that aren't open and you can have systems that are open that are not interoperable.
And, both situations can be very frustrating when you're trying to solve, real world problems. I guess from my perspective, the inter-operable thing is what, backnet has done for the most part. And it's great, right? being interoperable, we all need that.
That's all like version, zero.zero.one of what we're looking for when we talk about this future of smart buildings, it's like getting
James Dice: [00:16:52] the data flowing. Basically.
Andrew Rodgers: [00:16:54] Yeah. Yeah. and you start taking it, her operable up the stack, it gets a little more complicated. but yeah, backnet at the lowest level is solving that inter-operability in a lot of ways, certainly the way we use Vultron we use backnet as an interoperable, uh, layer, the open becomes I've bought a thing and it does X, A month from now, my tenants have completely changed.
Their requirements have completely changed and I really need thing a to do Y and Z and not X anymore. How do I do that? I limited do I have to go back to the initial vendor? Do I, I have to go back to, Someone who is, qualified or authorized to work on that initial vendors equipment.
how can I take over? And when you said that, like the myth is that there isn't a definition. I think what I really am trying to say is that the definition of open is personal. it's very, it's a very intimate thing. my definition of, open, may end up being very different than your definition.
And it does factor in all those things that I care about versus the things you care about. at the end of the day, the sort of sniff test that I say is can you. Can you accomplish what you want to accomplish with what you have without involving other folks. and is that a thing that you know, is going to be really expensive?
I think when you talk about Johnson defining open, Was open blue. the question. That we should all ask ourselves is like, how has that worked with other platforms Johnson's released in the past? Have we felt like they were, future-proof, can we add things onto them?
and I don't think you'll find a lot of people arguing, that, everything was great with, previous versions of Johnson's platform. So yeah. C, C
James Dice: [00:18:37] friendly rant, volume five.
Andrew Rodgers: [00:18:41] I think it really gets down to choice and being able to make those choices, being able to reuse assets that you've invested in and that really gets down like, is it yours? Did you really buy the thing? Or are you just using someone else's thing? and you gotta bag or, Pay if you want it to do something different.
James Dice: [00:19:02] okay. So there's this whole, it seems like two separate questions, interoperability open. And the way I heard you also is like, there's this whole other question around open source as well. So what's the difference there? and how do you think about
Andrew Rodgers: [00:19:16] that? So I think open source is a tool that the technology industry has used to ensure when systems, okay.
So when. When we say something like Vultron is open source. That means that anyone who's using Vultron, whether they're just going out and getting Vultron, off of get hub and running it themselves on their hardware or whatever, or they're paying us to run Vultron for them, with managed hardware.
If any of our customers want to fire us, it's trivial for them to do so. Like if we quit providing value, It's trivial for them to fire us. They have a platform that is running Vultron. The source code for Vultron is available. It is written in Python. They can hire any, general, development agency who, understands, modern language ecosystem to modify change that installation change that deployment to their needs.
they have 100% control. so you see this a lot. that like the, even the companies in the technology space. Yeah. There's this open source business model, that has pros and cons and is under some controversy in that space as well. But at the end of the day, you've got folks who are saying, look, I like what you've done as a technology.
I don't mind paying you to, manage or help us get the most value out of that technology. So we're going to sign a multiyear service agreement. But that core technology needs to be open source so that I know if you go away next year, or if you get acquired by Oracle or whoever, and they, suddenly decide to increase the licensing cost by X or increase the service costs, we can still self-actualize.
And that self actualization is the part that I just don't think exist in this industry. Not at all. whenever I have conversations, it's been. A little bit frustrating, I would say. I mean, once you figure out why the case is and dig into it, it makes sense. But, we had a lot of problems early on.
We would talk to customers about Vultron and there would always be this, like what can Vultron do X? And it's sure can Vultron do Y yeah, sure. And the answer is Vultron can do anything. If there's a business case that, provides enough value for either you to pay or me to see the potential, like, you're going to generate enough deployments that it's going to be worth it for us to build it for you.
Right. and once we build it, that can go back and the ecosystem and everyone can have that capability, but the answer is always yes. Whereas in this space, people just aren't used to that. They're always, they're always limited by what the vendor says as possible. And. when you move away from that paradigm, you get to really spend a lot more time.
I'm working on what does my customer need? How do I build it? And if it costs, maybe it costs more to do with an open source tool because I don't get certain starting points, but I know that as my customers' needs change, I can modify and change that to fit their needs without worrying about whether my vision, of what I want to do for my customers aligns with what my vendor's vision, for what they want to do with, for their customers, develops.
James Dice: [00:22:24] Got it. Okay. Let's, let's dive into the, a bunch of different levels of the stack here. so you're laughing because this is, this can get hairy, but I, the reason I want to do it's because I feel like there are different ways that systems can not be open depending on what level you're at. And I think It'd be good to just walk through. Maybe we try to keep each one brief and try to get through
Andrew Rodgers: [00:22:47] each level.
James Dice: [00:22:48] What about like at the very edge. you have sensor controller just maybe just start there, and what is open mean at that level?
Andrew Rodgers: [00:22:56] Yeah. so I think, again, this gets back to, how deep you want to go and a very different perspective between this space and the, I would say the edge stuff closely aligns with, modern IOT, development.
So we think about IOT systems, for this space. I think the definition of open is can I reprogram my edge devices? Do I have to buy special software to change controller routines? Those sorts of, can I do that without contacted the that's the definition of open currently? And I think it's even rare, right?
there's not a lot of edge platforms that allow you to do that sort of thing. When we move over to, IOT systems, we dive into the hardware a little bit and start talking about what kind of chips that is running that controller. Can we flash a different firmware if we wanted to?
and those kinds of definitions that are a little bit, I think a little bit outside the scope of this industry for all practical purposes, at least at this point. Yeah. But I think the trends happening in that space, there's things like open source CPU instruction sets, which means that now, whether you're a big proprietary vendor or you're just a small startup who wants to build an open controller of some sort.
you can build those edge devices without paying licensing fees for the CPU architecture, which all of the devices you're deploying have that built in right now. Like you don't see it. It's completely transparent to you, but arm is getting a licensing fee or one of the other, technology companies that offers these micro processor, instruction sets is getting a licensing fee.
So you have open happening in that space. You have standardization and interoperability at that level. a lot of the sensors now are, I think when you had, deep her from 75 EFL and he talked about using digital sensors. And I think probably he should've spent a little more time explaining what he meant, because I'm not sure that this audience.
Can appreciate that. they just, it's just a different, it's a different, but when he says that, what he means is that the chips themselves that are doing the temperature, sensing the, humidity. Yeah. Et cetera. they're not putting out a zero to 10 volt value.
They're not putting out a four to 20 million value. They are speaking at digital language with, Yeah, floating point precision over a bus that is local to that device. and you know in that area, it's funny. Cause all those sensors are interoperable. They're all using, a technology generally called I squared C, which allows you to Daisy chain, these sensors on a microprocessor, And so the proprietary layer gets added in the software at the, at a layer above that.
When we talk about, some of these sensors not being inter-operable. When he says, all the sensors are digital, he means it. And he means it all the way to, yeah. At some point there's probably some, physics, physical interaction of material that's being measured, but it's all happening within a piece of silicone, a single chip.
All right. And I think that like that openness and that enablement of the IOT industry development, is democratizing access to, deploying and designing. these systems. There's a guy in California who had a presentation HR this year, Calvin Slater, and he built his own BAS controller. designed it in, what's called like ECAD software for designing electronics, source the microprocessor source, the sensor source, the inputs had the board, printed the PCB printed and had a working example. and the fact that you can do that you don't need to be a billion dollar company to build your own edge device.
I think is a huge change that will have an effect on this industry. It's not having, I don't think it's having much of an effect right now, but I think it will have a huge effect. And that's the open hardware kind of point And Alper as Metzler, is a technology that has been working on where he's really trying to build a open platform controller that, you know, essentially. He has his software layer that can run on it, but it is an open device that you could run any software you wanted to write and have run on that controller.
So I think those are the places where we're seeing transformation at the hardware and edge layer.
James Dice: [00:27:08] Okay. Got it. So how about, okay now controllers are now talking to each other and that's where we had backed up. So help me understand the different, like how come back that be closed.
And let's just assume that everyone understands like where backnet plays. And I think everyone kinda thinks that opens things up. But like, when I understand it is that can actually close things down that you can still close things down. But as you
Andrew Rodgers: [00:27:32] use back then, Yeah, you can still close it.
I think so. So I think this gets back to, that different side. I mentioned earlier about how technology choices are made in this space versus in the broader technology community. and the reason why is that. A lot of things here, like backnet as a standard, that's driven by a standards organization, right?
The folks who participate on those standards committees, while they're generally open committees, like who has time to actually do that? it's people being paid from large vendors to represent that vendor's interests. So when you look at something that is. A hundred percent. I love standards.
Standards are great. Standards should exist and we should be working on, more and better standards, even though it ends up with us having one more standard. We still obviously haven't reached the end, all be all standard. But. The thing with standards is when you have all those large incumbent vendors represented so well on those committees, it means that the standard becomes a least common denominator in almost all instances.
So where a small open ecosystem of practitioners can say, this is what it needs to do, and it needs to do this and needs to be opinionated about these things. when the people involved in making the standard have, the, interest self-interest of these large vendors that they have to take into account, they may be great individuals, but at the end of the day, like they can't, support and build a standard that obsoletes half their equipment.
Like it just isn't gonna going to work. So when you look at, backnet for instance, Backnet is extensible. And this is where we found the most difficulty with. Backnet not really being an open platform. so that's extensible, which is great, but what it means is that a lot of cases.
The vision for how backnet would work and how it would be the inter-operable layer for a building didn't match, a vendor's technology stack. there wasn't a place in the stack for that particular layer. And so they use proprietary extensions, and backnet to enable a previous architecture that they had already, standardized on.
And so you find these instances where they have these extensions that are. they're, they are proprietary. They are not part of the backnet standard. And they are a part of the standard. The standard says you can have these extensions, but they don't fit architecture model that backnet was written for.
so you suddenly have like key things that the building is doing that should be done in the backnet yeah. general a communications model and you should have access to it and it's happening behind a closed curtain. and so that can be a problem with backnet.
I don't know that's one of those things that's I definitely, my stance is not well don't use backnet because it has this problem. It's Hey vendors, like worry about actually being inter-operable, at a level that allows your clients to drive value out of your system.
James Dice: [00:30:25] I see. Okay. Alright. So now we're moving up a little bit, so we have, Device layer controllers. Maybe we're getting to supervisory controllers. We're talking open back that. So now we have a control system, basically. Let's forget the server layer, forget software right now.
We have a control system now. the way I understand it is there's a ton of more ways to then lock a system down. So we're talking about. all the programming graphics, application like that you're using to do the programming. You're using different tools that you're plugging in. So like, how do you think about all of those different ways to make it less open, once you have a control system?
Andrew Rodgers: [00:31:03] Yeah. I think an interesting, Insight into this is that, we've, we've actually not worked with it directly. We've done some work with, a fairly large vendors platform that has an API for the platform, right? So this is at the supervisory layer. They have their own API that, is standards compliant.
It's fairly open. it's a little dated, it works. And this was being discussed, in a, forum the other day and people that deployed and knew that system didn't even know that API existed because it wasn't marketed to, most of their customers. So I think that in that space, like If you've got a building and as a controls vendor, and you have, it working under your proprietary system, there's not a lot of incentive to open it. and. even if you have the capability of making it open, you may not advertise it. Or you may not, put a lot of effort into letting your clients.
So there's, there's just obfuscation is one layer. certainly what we find is even if they do have an API, every vendor's API is different. And so now you're talking about the cost to build up. Product. If we're, stepping up a layer to say, we're a company, building a product for customers who have these technologies deployed.
Now you've got much higher costs to build your product because you've got to reimplement it for, all these different API models. and that's the ones that do have API APIs, right? and not all of them, do, some of them are completely, completely closed off. or, in the case of, I think some, I think when you and, Joe Amador had your conversation, that was, an semi-open.
It was, it was an ecosystem that wasn't open. It was definitely a walled garden that he had worked on. all those years ago. but there was a cost, right? You couldn't just build on top of it. You had to be a partner. You had to, be a, you had to basically guarantee you were building for that platform and not for anyone.
James Dice: [00:33:04] Okay. Yeah. And that'll let me get into the, get a little higher up for the platform. What about all these different. Ways to lock down at that level. Cause isn't there still okay, you might have an API and you didn't know about it, but isn't there still ways to lock people in around like software licenses for the specific programming tools and all of
Andrew Rodgers: [00:33:23] that.
But
James Dice: [00:33:24] there's 20 different
Andrew Rodgers: [00:33:25] ways right there. Isn't there. Yeah. And we see some systems where, Even ones that claim to be open where, they're using a programming language that only they use. And while you may be able to use that programming language for free, somebody has got to learn it.
You've got to pay some costs. You've got to find that workforce. So obviously if you have to buy the tools that enable you to work with that technology, that's a whole nother, that's another way. a lot of it is just locked down to, protected vendor relationships.
So you've gotta be a distributor of this vendor to have access to these tools. that take that self-actualization, that I've talked about away from the end customer. Yeah. Yeah. And I think, the other side of that is when we talk about this. In general, the feedback you hear is like the end customer doesn't care, the end customer doesn't, doesn't have anyone who could do that, et cetera.
But I think it depends. I think we're seeing that change. I think that, we're working with some clients who do care and do invest and do have teams of people who work on this, and are asking the questions of, we can hire app developers to build an app for our tenants, but we can't like.
Just hire developers to build, new operating systems for our buildings or et cetera. So I think, I think we're seeing that being driven at the larger scale, by companies, by operators, facility operators who are becoming more sophisticated about how they view the problem space, on the lower end, I think that, largely you're right, but.
this gets back to Is this open ecosystem, just a technology tool that allow you to solve a problem, or is it an ecosystem that change in the market and change how solutions are delivered and change how rapidly you can deploy and change the value you can deliver to your customer? Because at the end of the day, those customers do start to care.
When it starts impacting comfort, it starts impacting energy utilization, probably comfort more than energy utilization. things like. local law, 97 in New York start really changing that conversation. for much of the industry. When you have like straight up bottom line costs to an inefficient building, you're paying carbon offsets.
So I think then the people, well, who are servicing those smaller, customers who don't have those resources, they're going to have to start competing on, Oh, we can reduce your carbon tax, for your building. Yeah. You only have one building it's, 50,000 square feet, a hundred thousand, whatever.
Yeah. The cutoff is, but. Yeah, we can save you X a year on your carbon footprint. That's when you start to see that, okay. that'll help drive some of these applications with the smaller markets.
James Dice: [00:36:06] Yeah, I I've been thinking of it as like leveling up, like building owners and building owners.
Critters are being asked to level up in many times right now. Like one of them is all these ordinances and local laws. The other one is with COVID being asked
Andrew Rodgers: [00:36:19] to level up,
James Dice: [00:36:20] to entice people back to the building or to keep them safe if they need to be there. And the way I think about it as like the requirements of our systems are going up and up, along with.
The owners being asked at level. And so I think that's going to continue to drive, like if the system doesn't perform and the reason is because it's not open, it'll start to take care of itself. But like you said, today in many ways, we're not there.
Andrew Rodgers: [00:36:43] and I think another thing that came from your discussion with 75 F is they're sending out these stickers that say, we're monitoring and we know our air changes are like, People are actually asking it's the same stuff.
some of it is even if you didn't have new ASHRAE guidelines, even if you just had the old guidelines, you've got people asking questions about whether they're actually happening or not. which I think is a really good force for this industry.
James Dice: [00:37:09] Got it. let's talk about platforms then. So as we continue to go up the stack, so I think what you just alluded to was like one type of platform versus the other.
Maybe I need you to repeat it back to me, but like you're saying one, one type of marketplace or one type of platform has the ability to transform the industry. And other has the ability to keep us in the same place. Is that kinda what you meant
Andrew Rodgers: [00:37:32] by that? And how
James Dice: [00:37:33] would that work?
Andrew Rodgers: [00:37:34] Yeah. So I think, again, this is, I've referenced this, I didn't mention by name, your conversation with Deb from a switch where she talked about, we all have this vision of what we think smart buildings should be.
And when we talk about that, there seems to be such a Gulf between where we are now. And what our vision is and closed ecosystems mean that the way we cross that golf is like brick by brick, just building, one brick at a time. Waiting and, there'll be 10 bridges across the Gulf.
There's 10 vendors and they're all putting their bricks in. They're all doing iterative releases. They're all like, trying to extract as much value from their market at each, you know, every time they lay a brick, they want to get as much money for that particular brick as they can. When we talk about open ecosystems and getting really to where individual contributors and whether that's like engineers, like Kevin later, who are just, working on their day job, deploying, managing programming, BS systems, and then going home at night and building an entire controller like.
who knows that could be the connective tissue that ends up, we all, surround around and build the bridge, across. so when you open up the opportunity for more people to lay bricks and more people to choose different ways, I don't know if you ever looked at slime molds.
Okay. so there's this really interesting property of slime molds that if you lay out a map of the United States and you put. Food resources at all the major cities and let us Lyme mold loose on it. It will build the interstate system.
James Dice: [00:39:08] Wow. It
Andrew Rodgers: [00:39:09] will figure out where the resources are and this is , I guess it's a, organism made up of a bunch of single cell organisms or whatever.
And it solves that problem by just. Covering the map, finding all the resources and then reinforcing the routes that you need to move the resources along then the most efficient right now. we're just, again, just we've got a traveling salesman problem where we're waiting on these vendors to travel to all the cities and figure it out for us.
When we really need as many hands, as many eyes, as many people as possible working on these problems and the way we do that, as we start unlocking and allowing more folks to have access and accessibility to the solution
James Dice: [00:39:46] space. Okay.
Andrew Rodgers: [00:39:47] Beautiful. It really is. it's honestly like one of the coolest things I've ever seen in nature is this, Distributed.
And I think that when we talk about open source and then technology, that's what you're doing. You're saying, Hey, everybody has problems. Everybody has ways they would like to solve those problems. Maybe this is not an equal playing field for everyone, but you're at least welcome to submit your solution.
And if it works and it resonates with the ecosystem. It will be part of the solution. That's it like? That's the only, that's the, bar's not, Oh, you've got to go be a Johnson partner. You've got to go, be a Seaman's authorized reseller. No, you just, you have a solution you're able to deploy it.
You're able to prove it works. The most important thing is proving. It works. and the entire community benefits.
James Dice: [00:40:34] Yeah. So it's really about the reusability of the Rick's right? So you're. you're not building it for one ecosystem or one building even, you're able to build it once somebody builds it once proves it works, deploys it across all the similar buildings and applications.
Andrew Rodgers: [00:40:51] That's right. Exactly. that's exactly. If you look at the development of Vultron over the last, five years, six years, whenever it was initially released by the national labs, All kinds of components in Vultron now that were not developed by PNNL, that were not part of the original solution, but someone came along and they said, Hey, this is great.
It does X, Y I really need Z. So I'm going to build Z by the way. Hey, anybody else that needs Z, you can use the two. and that's how, we've done that for we've taken technologies that our customers and said, Hey, we need to do X. And we go, okay, that'll take a little time. We'll have to go build that.
We go build it. We release it back into the ecosystem. So anyone else who wants to go solve that same problem has the toolkit and doesn't have to reinvent that wheel.
James Dice: [00:41:34] Got it. Okay. So how about the types of platforms that are one level up from Voltron's Voltron's like freeing the data up and providing, edge to cloud, let's pull the data out of existing systems. And do cool stuff with it. Send it wherever you want, basically. And I'm sorry if I'm paraphrasing and skipping over a lot of full Tron details, we'll get to them in a second. but when you get up to like we've talked about open blue, so that's one type of plant form, right?
When you get up to that level where you are providing applications to users, What can we require from those vendors when we're selecting them? If we're a building owner that would promote this sort of, openness and market transformation, rather than I think what we were describing as more of a closed ecosystem, how can we create requirements around, if we're selecting platforms like that?
Andrew Rodgers: [00:42:28] Yeah. I think this. there's a lot of nuance here. because I think in general, the answer most folks will give you is we've got an API it's open. and I think honestly, as an industry, we don't have great standards yet that allow us to push back. we don't really have a lot of good footing to push back and say, ah, you've got an API, but it's not good enough.
but I think as you look at things like ASHRAE two to three. That are developing right now. and that will, I think, emerge and the Google buildings platform that was just released. I think those are the tools that we need. They may not be the end, all be all solutions, but they're are the tools we need to really have a robust conversation.
look at it, a lot of the problems I see with API APIs that we encounter at that platform level. Are, do they even attempt to meet any standard at all? So API is by default, just are very domain specific. it's very hard to standardize on a particular model that is universal, without kind of.
Leaning into an enterprise approach that might not be as flexible or as easy to integrate with as you would really like. so when we talk about that, there's things like open API 3.0, which is a specification specifically, just for how the API works less about what's possible in the API or about, Is there a specific expectation of how that API should work? That is going to be universal across, well-constructed API APIs, previously, You would see things like soap, which are very much the same thing, not specifying what the API does. It's not domain specific, but it is a way to interact with that API that is standardized, that that if you have this type of value, you can read it this kind of way.
when we talk about capabilities, I think this goes back to that sort of personal relationship with open. but I would say that challenge is not just, can it do what I need it to do today. It's can it do what I need it to do to get to the, that future we talked about because part of that whole.
Consumer pain. Distance is time. you, we buy a new phone, I buy a new phone. I try to control myself to keep it to every tourist three years. a lot of people buy a new phone every year. so that feedback loop is much more rapid. And when we talk about buying building systems, we're talking about 10, 15, 20 year cycles.
So you've got to think when you make your decision, you've got to think in a 15 mean your cycle. And I'm not saying we're going to have buildings that are as smart as we really want them in 15 years. I would love to think that, but I just, yeah, not sure that's realistic at this point, you should be thinking, what I buying today, what I'm deploying today, what I'm investing, my time to learn, those kinds of resources.
Is it going to get me. All the way is it going to still be a value in 10 years? is, Everything I learned about Johnson's proprietary communication protocol from, their edge devices from 15 years ago. Is it still valuable today or are there other, things that have supplanted it that I really should be thinking about?
What's the thing that's most universal or that I can. iterate on myself. yeah, those sorts of questions. I think
so I think like what we have to do as an industry is when we think about that vision, we all have of what a smart building is, how we interact with it. What are those individual granular things that your systems need to be capable of? And do you have a roadmap for how, what you're deploying today is going to accomplish that you have, do you understand, when a user says, whatever preference they put in their cell phone app and.
No X happens in the space. Can that happen? Do you have the ability to all those things, are those, actuators even installed in your system? those are the kinds of questions we need to be asking today. And I think that gets back to when you start talking about the platforms it's okay.
can I do like individual room controls through this platform? can I do these set point setbacks at an individual user level. Those are the kinds of questions, that when you look at an API, not just, I think from a technologist perspective, I would look a lot at like, how does the API work?
Is it similar to other API? Is that sort of thing, but the individual capabilities are all based on those use cases that you have for your clients.
James Dice: [00:46:44] got it. And from a platform selection perspective, it's is this ecosystem it's just like the API. Can the API do it, but then from the roadmap of that platform as well, is the roadmap with that platform over the next 10, 15 years?
Is it going to go where we need to go as well? So interesting. that leads perfectly into the workforce question. so when I think about the stack, we've been walking out, we've been walking from a sensor all the way up to some sort of platform with their user interface.
And then of course, there's. The user, but really, I think also there's but users throughout the entire stack. So there's been people that have been setting up these tools throughout this whole entire stack. So how do you think about the workforce and everyone's scaling up and are supposedly shortage in skilled workers and are industry with the proprietary versus open question.
am I my understanding your thoughts around it being. The more open. It is the less of a workforce problem we have.
Andrew Rodgers: [00:47:42] Yeah. I think yes. but there are some very specific ways that's true. so the workforce thing, I find really interesting because, basically as long as I've been deep into this, on the, smart building side with ACE IOT, everyone's saying, look, we've got this aging workforce. our pipeline is empty. we're not putting people into these programs.
But then you see them defending, keeping everything, vertically integrated, the same people who are saying we don't have enough. People are also saying there's only one true way to be in this industry. And you've got to come through, you've got to be an HVHC tech that, upskills into an automation tech, blah, blah, blah.
Or you got to be an electrician who becomes a controls tech. If we then, becomes the BAS programmer. What I see is we're making all these choices on the technologies that are nonstandard. They're not what the rest of the industry, the rest of the technology industry is using. Like when you look at, haystack is great, haystack, is so much better than anything that's been before, but you look at like the haystack API definition and it uses the data format that no one, like it was invented for haystack and, No one outside of haystack ecosystem is using that.
So when you start talking about, where do I hire people? If I have, a great idea and I want to build a company, can I just go hire software engineers? maybe, but you're going to have to spend some money, upskilling them with these like very specific ecosystem skills that. The rest of the technology world, isn't paying that tax.
Like they're just, they're all using the same stuff. They're all using, the same kinds of data formats so those kinds of questions, I think, when I look at well, where is this pool? Like I'm involved in my community quite a bit. I have good relationships with our community college.
I talked to them about some of the stuff, They're not, people aren't just flooding into their HPAC programs, like even with, all this data and all the effort that's been done in the marketing of that particular career path, people aren't just flooding into there.
But people are flooding into data science programs, they're flooding into, Python or full stack web development. So why aren't we as an industry, figuring out how to make those skills more valuable, or at least lower the impedance of people coming from those kinds of programs into this industry.
90%, this is one of those things that is, Kind of a hard truth in the data science world, but like 90% of the data science work is wrangling CSVs around. Like it's like very simple stuff. And it's stuff that this industry has its problems. This industry has. But because this industry, is so vertically walled garden, structured, it's very hard for someone and to just come into the yeah.
Industry from that perspective, like there's, there's this expectation that they know all these proprietary tools that the only way to know those proprietary tools is to already be in the industry. and I'm not saying that the solution to all of our workforce problems is to have more developers like turning screwdrivers.
that's not what I'm saying at all, but what I am saying is that, it seems like we could get a month wider pipeline if we were focused on using and building tools that sort of build off what the broader technology industry is doing. cause I think this is an interesting space and I, I talk to people every day who paid that tax, who did that extra work.
to move from technology into this space. And they did it because, they care about things like the environment they want to make an impact on co two emissions or greenhouse gases. Like it's those kinds of people. So that's possible. It's just that we make it hard. You have to really want to do it.
and I just think that, there are a lot of choices we make on a day to day basis and the technologies we deploy that could simplify that and make it not quite such a hard problem. Love it.
James Dice: [00:51:29] , So one of the things that.
Andrew Rodgers: [00:51:31] I love about your LinkedIn
James Dice: [00:51:32] posts. Andrew is you're often bringing in, other industries and how our industry is find those and they've gone through the same progression from close to open.
So can you give us a few, like examples? And I'm gonna expose my ignorance here, but one of the ones you've put on LinkedIn was Cooper and Cooper or something and
Andrew Rodgers: [00:51:52] yeah,
James Dice: [00:51:52] Kubernetes, I didn't even know how to pronounce it. So like what would be some examples of other industries that you think would be a good for people to study up on?
Andrew Rodgers: [00:52:00] Yeah. I think I specifically was using Kubernetes. I think this is worth talking about. And so there's probably other examples, but I'll go a little deep into this. Hopefully not too long, but it's a Kubernetes is really interest. I was using that as an example of how open source can be a market transformation tool.
And so if you look at. Eight or 10 years ago, there was Amazon web services, maybe not even eight or 10 years ago. This could have been as recently as six or seven, you had a juror just getting started up, but obviously it could eat a lot of market share just because people are going to go with Microsoft because they already had on prem deployment and you had Google cloud and Google cloud, like Google undeniably runs some of the largest systems in the world.
they're, the best at running these larger systems, but. They weren't very customer focused and they didn't have a very good connection. Like it's very hard to meet Google where Google is that. And that's why that's one of the reasons why we see solutions, that there is, a lot of.
work to taking solutions from the technology space and moving them into the BAS space is because some of these solutions are coming from companies that have, a hundred thousand engineers working on these problems. So like, their solution is going to be at such a level of complexity to solve them global problem.
That it's very hard for, smaller entities to reason about how that works. But, they took a technology that they were using internally for running all their services, the stuff like Gmail that you use every day and kind of rewrote it to be more accessible to folks who aren't, running Google.
but it did simplify, running and managing web applications at scale. and scale could be, tens of servers or maybe hundreds of servers. And their incentive for doing so was that they knew more about that system than anyone else. And their cloud platform was better oriented around that system than anyone else's.
So they gave away this technology for free. They started an ecosystem, they supported that ecosystem. They invested their engineer's time in supporting an open source ecosystem. And in return they got huge market share. Tons of people who were frustrated, the developer communities in these organizations are very different from the operators, of the it infrastructure.
And they were frustrated with things like getting databases provisioned on their proprietary database clusters or getting VMs provisioned. And so they would say, let's just spin up our own little Kubernetes cluster, and then we can run our applications and, iterate quickly and bypass all that process.
And then. What do you know, 1% of those applications are successful. Need to scale up. You need to move into a cloud infrastructure and Hey, Google has got the best place to do that. So this, I think also feeds into the comment you made very recently, which is stickiness versus a proprietary.
And that's exactly what it was. It was generating a technology that solved an acute pain. In the community and solved it in an approachable, accessible way that then had to on-road to, Oh, if you need to solve this pain now and you grow, once you get to a point where there's enough value for you to be a useful customer.
Then we have the platform that continues to solve that pain for you. And does it in the ways that you're familiar with, and you won't have to rearchitect your application. You won't have to, hire additional operations folks because it's just going to work the same way. it worked throughout the development process.
James Dice: [00:55:19] Interesting. That's fascinating. I feel like I could absorb these analogies from other industries all day. Cause it's feeds my soul, like knowing that other people have gone through these same issues and then it's worked out in the end. So what are a few others that come to mind besides Kubernetes?
Is that right? Did
Andrew Rodgers: [00:55:39] I say it? Yeah. I think one of the big ones, and , I've been trying to define and help maybe just clear up some of these. Perceptions of open and open source from this industry sector. And I think when I say open and open source, not always is open source the best, like it's not always, the right answer.
you can make. Choices that, open sources might be capable of doing something, but may be focusing you and your company on the wrong value stream that you need to focus on something else. And there's a proprietary solution that allows you to move your focus to the thing that you care about.
So that happens a lot, but I think another example that sort of like Google, but in almost, almost an opposite end result. So this can go good or bad, I guess is what I would say here. This is like a cautionary tale as well, but Mongo DB kind of went through that exact same cycle. So a lot of people have heard of Mongo DB.
It was almost exactly the same pain solution was, I can't get DBS deployed. I've got to hire a database administrators to help me understand how to write an effective schema for this Oracle database solution. I have these are the problems that were happening in large enterprises.
So Mongo came in and said, Hey, you don't have to worry about schema. Like you just build your thing and it'll work. Well, they didn't tell anybody was, it would work up to a certain scale. And then you might have problems, but they were available for you to pay them to solve that problem. And so now when you look at cross enterprise, like Mongo DB made a ton of money off enterprises because a small software team and enterprise, but start building a solution for some business, problem with Mongo, and then it would turn out to work.
Okay. And they would, need to, scale it up across the enterprise. And now all of a sudden they need help and so you've got, Oh, if you pay for our, commercial license version and we solve these problems for you, that aren't solved in the open source version.
So you have to like, buyer beware on open. Like even if you're not buying, you still need to be aware of what you might be buying into. and. Yeah. And the technology, we're all we have this thing of like open sources. There is free as in puppies. So like a free puppy is anything but free, right?
Like, um, we've probably all been in that situation. So I try to be objective about this stuff. So to give you both sides of that story, one side you've got Kubernetes that solves a huge problem for you. like at this point, Kubernetes is available in all the other cloud platforms.
So if you want to run it in Azure, you want to run it on AWS. They have Kubernetes product solutions as well. but Mongo, is a little different system and a different kind of approach. And they end up with a different, way of same kind of lock in, but the, the investment upfront is free.
James Dice: [00:58:19] Got it. Okay. All right, let's bring it back. So we mentioned the people on LinkedIn phoning in their question. So one of them, and apparently there's could be a little bit controversy around this, but let's just circle back to some of these questions in the end here. So they were asking about individual companies as an example.
And so one of them that I want to ask you about for sure is maybe summarizing all that we've talked about so far, which would be like, where is Niagara closed and open and how do you think about that? company specifically, because I think the perception would be that MACRA is fully open and that's at least my perception of how people think about it.
But, is that true? And how do
Andrew Rodgers: [00:59:02] you think about it? I think this is goes back to what your previous question of asking for examples. and this question, we can merge those because this is like a perfect opportunity to compare and contrast about what my expectations, my personal expectations of what open is versus what something like Agra provides you.
and I'll, I'll get very specific on both sides, just so we can have, clear talking points. I'll talk about Niagara as a programming framework and language and tool. And then I'll talk about Vultron and Python as a programming language and framework and tool. and just compare.
So like with Vultron who do I pay to run Vultron on a device? No one. if I want to write Python code that runs inside Vultron. What tool do I need to use to write that or compile it or package it to be distributed? a text editor. so literally like, Anything? what hardware can I run? Vultron on any hardware? I don't need like a sticker that says, licensed for Vultron or licensed for Python. so those are the expectations I bring when I look at things and ask if they're open and under that. I think it's be pretty hard to argue that Niagara falls into this, those expectations, but I'm not here to like, make a concrete judgment on whether something is opening.
I'm just telling you from my perspective, what I look at. Yeah. Yeah. and I think that you look at something like sky spark is very similar. and I think that model works great. it obviously has been great. But I also think, the real test is how long has Niagara been in the market.
And do we have that building future that Deb talked about, that we all aspire to. And so
James Dice: [01:00:43] no
Andrew Rodgers: [01:00:46] don't then, something needs to change and. maybe it's not Niagara's fault. Maybe it's how it's being used. Maybe there's all kinds of ways to talk about it, but I don't think anyone, no one's saying
the buildings are as good as they need to be. But then you do find people defending the tools that are used to make buildings the way they are.
James Dice: [01:01:06] I totally agree. A hundred percent
Andrew Rodgers: [01:01:08] You can't separate those two. There's either things are as good as they need to be.
Or we can improve what is, and I think we can improve what it is.
James Dice: [01:01:16] That's the journey I'm on. And honestly, sometimes I get direct messages or emails that are giving me Slack, because it's like, why are you promoting these new companies? Or why are you giving a platform to these new companies? And my answer is always we haven't solved it yet and we need to keep looking at because the problem still exists.
And as soon as the problem is actually solved by one of the companies, I'll. Give up, I'll go golf or something, but like my pursuit is around like finding the answers. And I think we're still looking at it. Just like you said, about what Deb said, it's we're still trying to realize that vision and it's still out there, so, okay.
So I love that answer. As we close this out, let's talk a little bit about Vultron. How are you using it today? is my first question. And then like, where do you see the tool going? and where do you see the platform headed as the second?
Andrew Rodgers: [01:02:06] I'm going to answer that backwards. I'm going to talk about the vision that traumas belt with, because I think it's important to understand where it came from.
So Vultron was a tool built for researchers by researchers in the national lab system to solve the problem of having a platform where they could build test simulate, and really review. New paradigms for grid operations. So specifically a concept called transactional energy. So the idea that everything that's consuming or producing energy participates in an open market, your chiller is negotiating with your building for energy.
Your. Zones are negotiating with your chiller for energy, and they all have some price they're willing to pay. So you could, you can optimize. You don't need schedules if you don't need like hard schedules, if your schedule is I'm willing to pay this much during this time of the day. And this much during this time of the day for conditioned air and every asset can speak that value, right?
Like they all have that as a universal and you could, you could do it with just saying KWH or KW or whatever as well. But this was the vision that like, that translates all the way up from, Your computer monitor, staying on all the way to gridscale is a negotiation. So Vultron was built to allow the national labs to build out test systems that really showed off that transactional.
So it needed to be able to communicate with building systems. It needed to be able to communicate with IOT systems and needed to be able to communicate with grid, operation systems, switch gear, that level generators, micro grid, inverters, solar inverters, that sort of thing.
and it needed to be able to communicate both ways. So we talk about Vultron a lot and like this data platform layer, but fully supports communications in both directions. So you can. use it for writing values, for pushing set points for doing all the things you would use a supervisory control system for, now to get back to like how we use it.
I think we're squarely right now in I would say our primary use case that our customers bring to us. Is it advanced supervisory control 1.0, where we're bringing back a bunch of stuff. We're allowing them to run analysis. We're allowing them to, look at the data in depth, map, do all their tagging, all that functionality so that they get real insights from their equipment.
In real time, we are starting. And when I talked about that, every project with the residential loads, that's where we're starting to get into. and when we were working with a couple of other platforms that are more on the building side, but, Getting into advanced supervisory control to the point where we can start pushing things, control is happening at that layer.
We're enabling other applications to optimize specific parts of it, of the system. So we can, by using Vultron as this, Meta layer or middleware, we can farm out the parts of the system that are most effectively optimized by various components and give you choice on what you use for which part.
So you're not buying into a particular, optimization vendors ecosystem for your entire. System or your entire portfolio, you can say, this building, this technology really works well in this building, but this is a different type of HPAC system. And it works better with this kind of, you know, optimized.
So you get that sort of, ability to really get it gets back to choice, which is where I think been if you made me give you the, like the one word answer for open it's choice, it's do you have choice? we use Vultron to give our customers choice about how they optimize or how they use their equipment or build advanced control solutions.
James Dice: [01:05:46] Got it. I love that. And yeah. let's do this, let's do this conversation again, sometime because I really want to get into that, the value of that independent data layer. I think that's just as controversial with some of these companies that would rather provide a full stack.
And so I think that's a, another area where. we could get into the weeds and with advanced revisory control, I've been having so many conversations lately where people are skeptical, that's even a real solution and that the market wants that specifically like our building owners wanting that.
so I really want to get into that with you, in the next conversation, but for now we should close this down. I think we could go all day. and, I just want to thank you for coming on the show. Also. Thank you for listening to all the past episodes. I feel like that really helped. yeah, that's on the same page for this one.
So I really appreciate the time you put in there and, all of the knowledge you're dropping. So
Andrew Rodgers: [01:06:37] all the time you put into that, and also the guests you had, you've had some really great guests, so it was time well spent for me. I don't feel like I, I feel like I got more out of that then, than you did with this conversation.
Awesome.
James Dice: [01:06:49] Awesome. let's get another one on the calendar and thanks a lot, Andrew. And I'll talk to you soon.
Andrew Rodgers: [01:06:53] Alright. Thank you.
James Dice: [01:06:54] Alright, friends. Thanks for listening to this episode of the Nexus podcast. For more episodes like this and to get the weekly Nexus newsletter, please subscribe at nexus.substack.com. You can find the show notes for this conversation there as well. As always, please reach out on LinkedIn with any thoughts on this episode.
I'd love to hear from you. Have a great day.
Happy Thursday!
Welcome to this week’s deep dive exclusively for Nexus Pro members. It’s an honor to have you here. This deep dive is a follow up to my recent podcast conversation with Andrew Rodgers, co-founder of ACE IoT. I learned a lot from this conversation and want to share my takeaways and the full transcript with you below.
In case you missed it in your inbox, you can find the audio or video here:
Nexus site | Apple Podcasts | Spotify | YouTube | Add to other podcast apps
Enjoy!
—James
My inner nerd was fully satisfied with this conversation… thanks, Andrew! I learned a ton but want to key in on two things specifically.
The first was the context around the creation of standards in our industry and how they’re different than other industries. Here’s Andrew:
"The folks who participate on those standards committees, while they're generally open committees, like who has time to actually do that? It's people being paid from large vendors to represent that vendor's interests. So when you look at something that is. A hundred percent. I love standards.
Standards are great. Standards should exist and we should be working on, more and better standards, even though it ends up with us having one more standard. We still obviously haven't reached the end, all be all standard. But. The thing with standards is when you have all those large incumbent vendors represented so well on those committees, it means that the standard becomes a least common denominator in almost all instances."
Honestly, this just pisses me off. Why are we letting vendors with a history of lock-in decide what open means? Shouldn’t ASHRAE’s goal be results, not protecting the interests of incumbents?
Anyway, rant over. I do love the unspoken context. It’s thick in our industry.
The second thing I learned was that APIs have three layers of nuance to them. (1) how the API works and (2) what it does and (3) can it do what I need it to do in the future? Here’s Andrew:
"What I’m buying today, what I'm deploying today, what I'm investing my time to learn, those kinds of resources. Is it going to still be of value in 10 years? Is everything I learned about Johnson's proprietary communication protocol from, their edge devices from 15 years ago, is it still valuable today or are there other things that have supplanted it that I really should be thinking about?
When you look at an API, it’s not just from a technologist perspective, but how does the API work? Is it similar to other APIs? That sort of thing, but the individual capabilities are all based on those use cases that you have for your clients.”
By the way, I love this primer on APIs from the Technically blog if you’re new to this topic. It’s got some fun doodles…
(image credit: Technically)
Finally, I’m planning on digging into VOLTTRON with Andrew soon. What should I ask him?
My highlights:
What did you think?
Note: transcript was created using an imperfect machine learning tool and lightly edited by a human (so you can get the gist). Please forgive errors!
James Dice: [00:00:00] Hello, friends. Welcome to Nexus, a smart buildings technology podcast for smart humans. I'm your host, James Dice. If we haven't met before, I write a weekly newsletter on the same topic. It's also called Nexus. Each week I share what I've learned, my opinions, and what I'm excited about in the quickly evolving world of intelligent buildings. Readers have called Nexus the best way to stay up to date on the future of this industry without all the marketing fluff. You can check it out and subscribe at nexus.substack.com or click the link in the show notes.
Since starting the Nexus newsletter, many of you have reached out to me wanting to talk shop, and we have. After a few weeks of those wonderful conversations, I realized I needed to record and share them with our growing community. So here we are. The Nexus podcast is born. This is our chance to explore and learn with the brightest in our industry together.
episode 20 is a conversation with Andrew Rogers, cofounder of ACE IOT. This is a great primer on what the word open means for buildings open as a very controversial and murky topic. I think Andrew clears some of that up in this conversation. It's about choice. It's about self actualization. Just like I said, with Cory in the intro to episode 11, don't let the deep nerdiness of this conversation scare you away.
If we could unlock the data in our buildings and open up communication, we could do things like help mitigate climate change, create healthier indoor environments. And finally actually automate our buildings, Andrew and I talked about openness definitions and walk through each layer of the smart building stack to unpack it in depth, including how we can learn from slime molds, who have it all figured out.
This episode of the podcast is directly funded by listeners like you who have joined the nexus pro membership community. You can find pro on how to join and support the podcast at nexus dot dot com. You'll also find the show notes there, which has links to Andrew's LinkedIn page. Oh, and by the way, if you take a look at your podcast feed and you're missing some episodes, that's because those episodes are exclusive to members of nexus pro sign up for a pro membership to get your personal podcast feed with access to every episode.
Without further ado, please enjoy nexus podcast. Episode 20. alright. Hello, Andrew. Welcome to the show.
Can you introduce yourself for everyone?
Andrew Rodgers: [00:02:22] Yes. I'm Andrew Rogers. I'm a cofounder of ACE IOT solutions. We're a software company that, offers infrastructure as a service for companies who want to use an open source technology called Vultron, in their smart buildings, projects or, systems or platforms.
James Dice: [00:02:39] Cool. All right. And we're going to get into Vultron in a little bit. Let's start though, with your career history, how'd you get to founding ACE IOT. And what have you been up to before that?
Andrew Rodgers: [00:02:48] my career has been pretty varied. pretty broad. I got started at a fairly young age in the industrial automation space, specifically industrial it systems.
At 19, I was in a triple reporting role to a, plant engineering manager, plant maintenance manager, an it manager for a 600 employee, factory with about, 70, connected, HMI it systems, and had to manage those. And. Generate a backup plans. And of course they're all different vendors and they have all the same problems that this space has.
so I did that for awhile. went back into kind of more general it back into industrial automation. a little stint in some buildings, 12 years ago. And then got really involved in smart cities. And so I spent the last five or six years really deep in the smart city space working on, citywide strategy, and research projects with both our local university and our local municipality.
and then that's how I got introduced to Vultron. Can I met some folks through the smart city ecosystem, and then really, dove into the Vultron world, helping. the city of Washington DC deploy and build out their infrastructure for their smart building portfolio.
James Dice: [00:04:01] Got it. Okay, cool.
And before we dive into our main topic, what is, Vultron just like short description for people that have never heard of it before.
Andrew Rodgers: [00:04:10] Vultron is a box of Legos. Okay. You can build a I'm sorry for the, uh, fence out there. Lego system bricks, that you can build smart. And connected grid enabled, buildings, are building integrations with and micro grids.
It's all things distributed energy. it's not necessarily a product in the sense that we think of a lot of, vendor platforms in this space. it's just a technology that can be used. and you can build a lot of other products on top of it.
James Dice: [00:04:41] Cool. And it was developed by the Pacific Northwest national lab originally.
And now it's an open source project. Is that right?
Andrew Rodgers: [00:04:48] That's right. Yeah. It's part of the eclipse software foundation now.
James Dice: [00:04:51] Cool. All right. Sweet. So what does ACL IOT do for your clients and how do you work with your clients?
Andrew Rodgers: [00:04:57] so it varies. we. Our primary business is a software slash infrastructure as a service.
we will use our cloud platform to manage Vultron instances at your customer sites. make sure they're running effectively, fully updated, patched, all that stuff. configuration management. And then send that data to whatever system that you're building. If you're, a software company or another technology company.
we also do some consulting work in the sort of infrastructure, Space for data systems, in both the smart building space and the solar energy space. and then yeah, a part of that, is also focused, not just on what we think of as large scale commercial buildings, but other places where, grid, interactive building technologies are useful.
So like we've got a project right now with Embry and some of the other national labs working on some residential applications where we're using Vultron for behind the meter optimization.
James Dice: [00:05:55] Got it. Cool. All right. So this is the point of the conversation we're asking my favorite question. why are buildings behind, decades behind other technology?
like the technology in our pockets and you know that we're talking over right now. Why are buildings so far
Andrew Rodgers: [00:06:11] behind? So I like to think about it in terms of the pain consumer distance. For consumer facing technology, the feedback in the market, like, you know, people talk about the market working in all kinds of mysterious ways, but if you don't have a feedback path, the market doesn't work.
markets don't work. If there is no feedback. that's when you look at things like the financial crisis in 2008, the housing, that was the problem. The feedback loop was broken. So the market wasn't actually self-regulating, When we look at consumer technologies, if someone releases a phone that is terrible, people don't buy it.
and that's your feedback loop? It's the last one technology cycle. And the people who are paying for the phone or the people using the phone. And I think that's the big difference. the people paying for smart building technologies are not generally the people using the smart building technologies and that is throughout the stack.
So that's, the people buying the buildings are not the people occupying the buildings. The people choosing the vendor relationships are not the people that are deploying and programming the people who are having to do the commissioning and the fact that commissioning needs to exist as something to bring together.
All these systems after they've already been deployed by their respective vendors. aren't the ones selecting or choosing the equipment that's being deployed. so the further you have that, the distance between who feels the pain of the choices you're making and who has to pay for the choices, I think that the slower your progress is, and, the more sort of dystopian, a reality you can end up in I think.
The evidence when you, posted this morning about having this conversation and got pretty, maybe not the most feedback ever, but very fast feedback. I think that's evidence that people know something is broken. but there isn't really change happening to affect that.
James Dice: [00:07:59] Totally. Yeah.
and there's certain words that when you bring them up, people are very, they just jumped in right on them. and that's, yeah. Want to talk about today, but first on that answer, what do you see as the ways like in the marketplace that you're seeing? I guess that feedback loop get closed up.
Andrew Rodgers: [00:08:17] yeah, I think you talk about this a lot. When you talk about, advanced supervisory control 2.0. When people are building platforms that are reaching the tenant. I think that's an important piece. I think that the fact, the tenants themselves elves are starting to make these demands.
they're seeing that it's broken, that it doesn't work like their phone does, et cetera. I think you've had a few guests recently who are all working on platforms that. Are thinking about the user experience all the way out to the tenant level. I think what we're going to talk about on the open side, Mike broom in that conversation, they're definitely thinking about that as user experience, down the stack.
and I think that perspective is what's going to move us forward. I think the old perspective of. how do we have a flashy demo at AHR and get a new distributor signed up for our platform is not how you move the industry forward.
James Dice: [00:09:10] Totally. I love that answer and I love how I'm getting different answers.
So thank you for bringing some diversity to, the answer of the question. cool. So let's dive into our main topic. So Andrea, you were referencing the post I made on LinkedIn this morning. So thanks to everyone who contributed to our outline for what we're about to talk about here. But, it really was.
This conversation about what open means really became clear to me a couple of weeks ago, like how important it was because I posted about JCI is open bloop form and that post got, I want to say 120 comments, something like that by far the most popular yeah. Most engaged with posts that I've ever done.
and I've done a lot of posts and that one seemed to really strike a nerve. And for me, it was what it was about. I don't know it is what was about for you. But for me, it seems like a lot of the comments were debating what open means and like what the definition of it is. And I think mostly everyone was agreeing that JCI has definitions.
Probably not it, but what is it is the question. And I think that's what I want to get to. Today. So with that, we have a lot to cover
Andrew Rodgers: [00:10:18] and there's a lot of different
James Dice: [00:10:19] ways that we could take this conversation. I think, but what I want to start with is around myths. So what are the biggest myths when it comes to the word open in our industry to you?
I guess that's a good place to kick it off.
Andrew Rodgers: [00:10:32] I do come at this from a little different background because, I do have more of a history in the technology space. And, when we talk about open and the technology space, it just has a very different meaning, than what I see, at least marketed as open in this space.
obviously there is open and open ecosystem and then there's open and open source. And I think those are key distinctive things that, there are different, both in technology and in this space. but I think that the people in the technology space seem to be more well versed in the nuance and difference between those two.
And the people in this space seemed to have, not a lot of examples to look at other versions of that. and I think when you talk about open, when the people that are dominant in this industry, talk about open, they talk about open ecosystems and they're worried about things like vendor distributor agreements.
it's, almost, policy-based more than, Practitioner or, individual contributor based like how does an engineer interact with this? and so I think that's, I don't know that I would say it's a myth. I just think it's like a fog of war over the entire thing.
Yeah. There's just because you have some, very dominant players in the space, put out a lot of volume of, content and just marketing. It's hard to find those like concrete answers, and really, open kind of, I was down to an ideological position. you can say, it's only open if it's, in software, we talk about.
Libera which is like this concept of freedom of speech, like free as in speech. And then, you have free, which is, free as in beer. and it's interesting cause like neither of those really play in this space. there's nothing free. It's just whether or not, there's additional restrictions on if you can play once you buy, once you pay for it, can you play with it?
and. Aye. I don't know that like I'm the person to say, here are the myths. Like here are the things that this industry has a hundred percent wrong. I think my perspective and what I want to bring to this is, Hey, there are other industries that have gone through these transitions from closed ecosystems to open ecosystems, or more closed ecosystems to more open ecosystems.
There's a lot we can learn from those. Those transitions and transformations. but we do have to stop navel gazing, whether open blue is open. Is, a concrete answer that is going to depend on a lot of factors of what you care about. And when you say you want something to be open, but do I think that Johnson controls is going to tell this industry what open is?
No, I think if you let a company like Johnson or Siemens or any of the big vendors define that for you, the industry loses. So I think the most important thing about this whole open discussion is that people really are able to enumerate what they care about, why they're making decisions, and get beyond the marketing, honestly.
regardless of. How open. I mean, I think, even the conversation this morning and people contributing to, the questions to ask, it was obvious that there were people coming from very different perspectives. and there were people very happy with, a mostly proprietary system, and calling it open and saying it solves my problems.
And if it does, that's great. But I think we get back to the question of, why are buildings, decades behind other tech? And no one's arguing that they're not, I see very few arguments that they're not,
James Dice: [00:13:58] haven't had that answer yet. No, one's arguing with me,
Andrew Rodgers: [00:14:01] but you hear so many arguments defending the status quo, and why things should be the way they are.
Yeah. and I think you just have to say, okay, we've been doing this for a long time, and this is the result it's gotten. there's gotta be a different way. And I think people coming to that realization on their own is going to be, and learning enough about how other industries have done.
This is going to be much more impactful than you or I, defining here are the rules. I do think it gets down to. What are the capabilities that are unlocked for me. And then once you say, okay, these are the capabilities I need. and this is how an open or proprietary ecosystem solves those, or allows me to solve those for my clients.
then it really can become preference. I don't think anyone's saying you cannot solve problems in a closed way. it's just that if, this is where I would lean back into the workforce discussion because I think where these decisions get made in the stack is very different between BAS I think we talked about the pain consumer distance.
I think that. On average technology workers, specifically, in smaller startups in that, and that sort of ecosystem, the practitioners who are writing the code, who are solving the problems, the engineers that are really, focused on. Problem. Like the thing in front of them have a lot more latitude on picking the tools they want to use.
and that has driven a lot of how open looks and works in the technology space that is just unparalleled in the BAS space. Got
James Dice: [00:15:30] it. Got it. Okay. Yeah. There's a lot there.
Andrew Rodgers: [00:15:33] Yeah. That was a very rambling answer. I'm sorry.
James Dice: [00:15:35] I think what I heard from me, if I could repeat it back, it's myth, number one is there is no definition, overarching definition because it depends on what you're trying to accomplish.
It depends on what you want out of your given project that your given building. I think number two is there seems like there's a myth around. And maybe this is coming from the incumbent vendors when they proport it. But I think that I'm seeing incumbent vendors saying you shouldn't want open because what we're providing is interoperability.
And so it seems like there's these two, like open versus interoperability, it might be some confusion. And so I wonder if that's a place to take this next, which would be like, What are the differences between those two words and like, why would you want open versus inter-operable?
Andrew Rodgers: [00:16:18] Yeah. And I think this goes both ways, you can have systems that are interoperable, that aren't open and you can have systems that are open that are not interoperable.
And, both situations can be very frustrating when you're trying to solve, real world problems. I guess from my perspective, the inter-operable thing is what, backnet has done for the most part. And it's great, right? being interoperable, we all need that.
That's all like version, zero.zero.one of what we're looking for when we talk about this future of smart buildings, it's like getting
James Dice: [00:16:52] the data flowing. Basically.
Andrew Rodgers: [00:16:54] Yeah. Yeah. and you start taking it, her operable up the stack, it gets a little more complicated. but yeah, backnet at the lowest level is solving that inter-operability in a lot of ways, certainly the way we use Vultron we use backnet as an interoperable, uh, layer, the open becomes I've bought a thing and it does X, A month from now, my tenants have completely changed.
Their requirements have completely changed and I really need thing a to do Y and Z and not X anymore. How do I do that? I limited do I have to go back to the initial vendor? Do I, I have to go back to, Someone who is, qualified or authorized to work on that initial vendors equipment.
how can I take over? And when you said that, like the myth is that there isn't a definition. I think what I really am trying to say is that the definition of open is personal. it's very, it's a very intimate thing. my definition of, open, may end up being very different than your definition.
And it does factor in all those things that I care about versus the things you care about. at the end of the day, the sort of sniff test that I say is can you. Can you accomplish what you want to accomplish with what you have without involving other folks. and is that a thing that you know, is going to be really expensive?
I think when you talk about Johnson defining open, Was open blue. the question. That we should all ask ourselves is like, how has that worked with other platforms Johnson's released in the past? Have we felt like they were, future-proof, can we add things onto them?
and I don't think you'll find a lot of people arguing, that, everything was great with, previous versions of Johnson's platform. So yeah. C, C
James Dice: [00:18:37] friendly rant, volume five.
Andrew Rodgers: [00:18:41] I think it really gets down to choice and being able to make those choices, being able to reuse assets that you've invested in and that really gets down like, is it yours? Did you really buy the thing? Or are you just using someone else's thing? and you gotta bag or, Pay if you want it to do something different.
James Dice: [00:19:02] okay. So there's this whole, it seems like two separate questions, interoperability open. And the way I heard you also is like, there's this whole other question around open source as well. So what's the difference there? and how do you think about
Andrew Rodgers: [00:19:16] that? So I think open source is a tool that the technology industry has used to ensure when systems, okay.
So when. When we say something like Vultron is open source. That means that anyone who's using Vultron, whether they're just going out and getting Vultron, off of get hub and running it themselves on their hardware or whatever, or they're paying us to run Vultron for them, with managed hardware.
If any of our customers want to fire us, it's trivial for them to do so. Like if we quit providing value, It's trivial for them to fire us. They have a platform that is running Vultron. The source code for Vultron is available. It is written in Python. They can hire any, general, development agency who, understands, modern language ecosystem to modify change that installation change that deployment to their needs.
they have 100% control. so you see this a lot. that like the, even the companies in the technology space. Yeah. There's this open source business model, that has pros and cons and is under some controversy in that space as well. But at the end of the day, you've got folks who are saying, look, I like what you've done as a technology.
I don't mind paying you to, manage or help us get the most value out of that technology. So we're going to sign a multiyear service agreement. But that core technology needs to be open source so that I know if you go away next year, or if you get acquired by Oracle or whoever, and they, suddenly decide to increase the licensing cost by X or increase the service costs, we can still self-actualize.
And that self actualization is the part that I just don't think exist in this industry. Not at all. whenever I have conversations, it's been. A little bit frustrating, I would say. I mean, once you figure out why the case is and dig into it, it makes sense. But, we had a lot of problems early on.
We would talk to customers about Vultron and there would always be this, like what can Vultron do X? And it's sure can Vultron do Y yeah, sure. And the answer is Vultron can do anything. If there's a business case that, provides enough value for either you to pay or me to see the potential, like, you're going to generate enough deployments that it's going to be worth it for us to build it for you.
Right. and once we build it, that can go back and the ecosystem and everyone can have that capability, but the answer is always yes. Whereas in this space, people just aren't used to that. They're always, they're always limited by what the vendor says as possible. And. when you move away from that paradigm, you get to really spend a lot more time.
I'm working on what does my customer need? How do I build it? And if it costs, maybe it costs more to do with an open source tool because I don't get certain starting points, but I know that as my customers' needs change, I can modify and change that to fit their needs without worrying about whether my vision, of what I want to do for my customers aligns with what my vendor's vision, for what they want to do with, for their customers, develops.
James Dice: [00:22:24] Got it. Okay. Let's, let's dive into the, a bunch of different levels of the stack here. so you're laughing because this is, this can get hairy, but I, the reason I want to do it's because I feel like there are different ways that systems can not be open depending on what level you're at. And I think It'd be good to just walk through. Maybe we try to keep each one brief and try to get through
Andrew Rodgers: [00:22:47] each level.
James Dice: [00:22:48] What about like at the very edge. you have sensor controller just maybe just start there, and what is open mean at that level?
Andrew Rodgers: [00:22:56] Yeah. so I think, again, this gets back to, how deep you want to go and a very different perspective between this space and the, I would say the edge stuff closely aligns with, modern IOT, development.
So we think about IOT systems, for this space. I think the definition of open is can I reprogram my edge devices? Do I have to buy special software to change controller routines? Those sorts of, can I do that without contacted the that's the definition of open currently? And I think it's even rare, right?
there's not a lot of edge platforms that allow you to do that sort of thing. When we move over to, IOT systems, we dive into the hardware a little bit and start talking about what kind of chips that is running that controller. Can we flash a different firmware if we wanted to?
and those kinds of definitions that are a little bit, I think a little bit outside the scope of this industry for all practical purposes, at least at this point. Yeah. But I think the trends happening in that space, there's things like open source CPU instruction sets, which means that now, whether you're a big proprietary vendor or you're just a small startup who wants to build an open controller of some sort.
you can build those edge devices without paying licensing fees for the CPU architecture, which all of the devices you're deploying have that built in right now. Like you don't see it. It's completely transparent to you, but arm is getting a licensing fee or one of the other, technology companies that offers these micro processor, instruction sets is getting a licensing fee.
So you have open happening in that space. You have standardization and interoperability at that level. a lot of the sensors now are, I think when you had, deep her from 75 EFL and he talked about using digital sensors. And I think probably he should've spent a little more time explaining what he meant, because I'm not sure that this audience.
Can appreciate that. they just, it's just a different, it's a different, but when he says that, what he means is that the chips themselves that are doing the temperature, sensing the, humidity. Yeah. Et cetera. they're not putting out a zero to 10 volt value.
They're not putting out a four to 20 million value. They are speaking at digital language with, Yeah, floating point precision over a bus that is local to that device. and you know in that area, it's funny. Cause all those sensors are interoperable. They're all using, a technology generally called I squared C, which allows you to Daisy chain, these sensors on a microprocessor, And so the proprietary layer gets added in the software at the, at a layer above that.
When we talk about, some of these sensors not being inter-operable. When he says, all the sensors are digital, he means it. And he means it all the way to, yeah. At some point there's probably some, physics, physical interaction of material that's being measured, but it's all happening within a piece of silicone, a single chip.
All right. And I think that like that openness and that enablement of the IOT industry development, is democratizing access to, deploying and designing. these systems. There's a guy in California who had a presentation HR this year, Calvin Slater, and he built his own BAS controller. designed it in, what's called like ECAD software for designing electronics, source the microprocessor source, the sensor source, the inputs had the board, printed the PCB printed and had a working example. and the fact that you can do that you don't need to be a billion dollar company to build your own edge device.
I think is a huge change that will have an effect on this industry. It's not having, I don't think it's having much of an effect right now, but I think it will have a huge effect. And that's the open hardware kind of point And Alper as Metzler, is a technology that has been working on where he's really trying to build a open platform controller that, you know, essentially. He has his software layer that can run on it, but it is an open device that you could run any software you wanted to write and have run on that controller.
So I think those are the places where we're seeing transformation at the hardware and edge layer.
James Dice: [00:27:08] Okay. Got it. So how about, okay now controllers are now talking to each other and that's where we had backed up. So help me understand the different, like how come back that be closed.
And let's just assume that everyone understands like where backnet plays. And I think everyone kinda thinks that opens things up. But like, when I understand it is that can actually close things down that you can still close things down. But as you
Andrew Rodgers: [00:27:32] use back then, Yeah, you can still close it.
I think so. So I think this gets back to, that different side. I mentioned earlier about how technology choices are made in this space versus in the broader technology community. and the reason why is that. A lot of things here, like backnet as a standard, that's driven by a standards organization, right?
The folks who participate on those standards committees, while they're generally open committees, like who has time to actually do that? it's people being paid from large vendors to represent that vendor's interests. So when you look at something that is. A hundred percent. I love standards.
Standards are great. Standards should exist and we should be working on, more and better standards, even though it ends up with us having one more standard. We still obviously haven't reached the end, all be all standard. But. The thing with standards is when you have all those large incumbent vendors represented so well on those committees, it means that the standard becomes a least common denominator in almost all instances.
So where a small open ecosystem of practitioners can say, this is what it needs to do, and it needs to do this and needs to be opinionated about these things. when the people involved in making the standard have, the, interest self-interest of these large vendors that they have to take into account, they may be great individuals, but at the end of the day, like they can't, support and build a standard that obsoletes half their equipment.
Like it just isn't gonna going to work. So when you look at, backnet for instance, Backnet is extensible. And this is where we found the most difficulty with. Backnet not really being an open platform. so that's extensible, which is great, but what it means is that a lot of cases.
The vision for how backnet would work and how it would be the inter-operable layer for a building didn't match, a vendor's technology stack. there wasn't a place in the stack for that particular layer. And so they use proprietary extensions, and backnet to enable a previous architecture that they had already, standardized on.
And so you find these instances where they have these extensions that are. they're, they are proprietary. They are not part of the backnet standard. And they are a part of the standard. The standard says you can have these extensions, but they don't fit architecture model that backnet was written for.
so you suddenly have like key things that the building is doing that should be done in the backnet yeah. general a communications model and you should have access to it and it's happening behind a closed curtain. and so that can be a problem with backnet.
I don't know that's one of those things that's I definitely, my stance is not well don't use backnet because it has this problem. It's Hey vendors, like worry about actually being inter-operable, at a level that allows your clients to drive value out of your system.
James Dice: [00:30:25] I see. Okay. Alright. So now we're moving up a little bit, so we have, Device layer controllers. Maybe we're getting to supervisory controllers. We're talking open back that. So now we have a control system, basically. Let's forget the server layer, forget software right now.
We have a control system now. the way I understand it is there's a ton of more ways to then lock a system down. So we're talking about. all the programming graphics, application like that you're using to do the programming. You're using different tools that you're plugging in. So like, how do you think about all of those different ways to make it less open, once you have a control system?
Andrew Rodgers: [00:31:03] Yeah. I think an interesting, Insight into this is that, we've, we've actually not worked with it directly. We've done some work with, a fairly large vendors platform that has an API for the platform, right? So this is at the supervisory layer. They have their own API that, is standards compliant.
It's fairly open. it's a little dated, it works. And this was being discussed, in a, forum the other day and people that deployed and knew that system didn't even know that API existed because it wasn't marketed to, most of their customers. So I think that in that space, like If you've got a building and as a controls vendor, and you have, it working under your proprietary system, there's not a lot of incentive to open it. and. even if you have the capability of making it open, you may not advertise it. Or you may not, put a lot of effort into letting your clients.
So there's, there's just obfuscation is one layer. certainly what we find is even if they do have an API, every vendor's API is different. And so now you're talking about the cost to build up. Product. If we're, stepping up a layer to say, we're a company, building a product for customers who have these technologies deployed.
Now you've got much higher costs to build your product because you've got to reimplement it for, all these different API models. and that's the ones that do have API APIs, right? and not all of them, do, some of them are completely, completely closed off. or, in the case of, I think some, I think when you and, Joe Amador had your conversation, that was, an semi-open.
It was, it was an ecosystem that wasn't open. It was definitely a walled garden that he had worked on. all those years ago. but there was a cost, right? You couldn't just build on top of it. You had to be a partner. You had to, be a, you had to basically guarantee you were building for that platform and not for anyone.
James Dice: [00:33:04] Okay. Yeah. And that'll let me get into the, get a little higher up for the platform. What about all these different. Ways to lock down at that level. Cause isn't there still okay, you might have an API and you didn't know about it, but isn't there still ways to lock people in around like software licenses for the specific programming tools and all of
Andrew Rodgers: [00:33:23] that.
But
James Dice: [00:33:24] there's 20 different
Andrew Rodgers: [00:33:25] ways right there. Isn't there. Yeah. And we see some systems where, Even ones that claim to be open where, they're using a programming language that only they use. And while you may be able to use that programming language for free, somebody has got to learn it.
You've got to pay some costs. You've got to find that workforce. So obviously if you have to buy the tools that enable you to work with that technology, that's a whole nother, that's another way. a lot of it is just locked down to, protected vendor relationships.
So you've gotta be a distributor of this vendor to have access to these tools. that take that self-actualization, that I've talked about away from the end customer. Yeah. Yeah. And I think, the other side of that is when we talk about this. In general, the feedback you hear is like the end customer doesn't care, the end customer doesn't, doesn't have anyone who could do that, et cetera.
But I think it depends. I think we're seeing that change. I think that, we're working with some clients who do care and do invest and do have teams of people who work on this, and are asking the questions of, we can hire app developers to build an app for our tenants, but we can't like.
Just hire developers to build, new operating systems for our buildings or et cetera. So I think, I think we're seeing that being driven at the larger scale, by companies, by operators, facility operators who are becoming more sophisticated about how they view the problem space, on the lower end, I think that, largely you're right, but.
this gets back to Is this open ecosystem, just a technology tool that allow you to solve a problem, or is it an ecosystem that change in the market and change how solutions are delivered and change how rapidly you can deploy and change the value you can deliver to your customer? Because at the end of the day, those customers do start to care.
When it starts impacting comfort, it starts impacting energy utilization, probably comfort more than energy utilization. things like. local law, 97 in New York start really changing that conversation. for much of the industry. When you have like straight up bottom line costs to an inefficient building, you're paying carbon offsets.
So I think then the people, well, who are servicing those smaller, customers who don't have those resources, they're going to have to start competing on, Oh, we can reduce your carbon tax, for your building. Yeah. You only have one building it's, 50,000 square feet, a hundred thousand, whatever.
Yeah. The cutoff is, but. Yeah, we can save you X a year on your carbon footprint. That's when you start to see that, okay. that'll help drive some of these applications with the smaller markets.
James Dice: [00:36:06] Yeah, I I've been thinking of it as like leveling up, like building owners and building owners.
Critters are being asked to level up in many times right now. Like one of them is all these ordinances and local laws. The other one is with COVID being asked
Andrew Rodgers: [00:36:19] to level up,
James Dice: [00:36:20] to entice people back to the building or to keep them safe if they need to be there. And the way I think about it as like the requirements of our systems are going up and up, along with.
The owners being asked at level. And so I think that's going to continue to drive, like if the system doesn't perform and the reason is because it's not open, it'll start to take care of itself. But like you said, today in many ways, we're not there.
Andrew Rodgers: [00:36:43] and I think another thing that came from your discussion with 75 F is they're sending out these stickers that say, we're monitoring and we know our air changes are like, People are actually asking it's the same stuff.
some of it is even if you didn't have new ASHRAE guidelines, even if you just had the old guidelines, you've got people asking questions about whether they're actually happening or not. which I think is a really good force for this industry.
James Dice: [00:37:09] Got it. let's talk about platforms then. So as we continue to go up the stack, so I think what you just alluded to was like one type of platform versus the other.
Maybe I need you to repeat it back to me, but like you're saying one, one type of marketplace or one type of platform has the ability to transform the industry. And other has the ability to keep us in the same place. Is that kinda what you meant
Andrew Rodgers: [00:37:32] by that? And how
James Dice: [00:37:33] would that work?
Andrew Rodgers: [00:37:34] Yeah. So I think, again, this is, I've referenced this, I didn't mention by name, your conversation with Deb from a switch where she talked about, we all have this vision of what we think smart buildings should be.
And when we talk about that, there seems to be such a Gulf between where we are now. And what our vision is and closed ecosystems mean that the way we cross that golf is like brick by brick, just building, one brick at a time. Waiting and, there'll be 10 bridges across the Gulf.
There's 10 vendors and they're all putting their bricks in. They're all doing iterative releases. They're all like, trying to extract as much value from their market at each, you know, every time they lay a brick, they want to get as much money for that particular brick as they can. When we talk about open ecosystems and getting really to where individual contributors and whether that's like engineers, like Kevin later, who are just, working on their day job, deploying, managing programming, BS systems, and then going home at night and building an entire controller like.
who knows that could be the connective tissue that ends up, we all, surround around and build the bridge, across. so when you open up the opportunity for more people to lay bricks and more people to choose different ways, I don't know if you ever looked at slime molds.
Okay. so there's this really interesting property of slime molds that if you lay out a map of the United States and you put. Food resources at all the major cities and let us Lyme mold loose on it. It will build the interstate system.
James Dice: [00:39:08] Wow. It
Andrew Rodgers: [00:39:09] will figure out where the resources are and this is , I guess it's a, organism made up of a bunch of single cell organisms or whatever.
And it solves that problem by just. Covering the map, finding all the resources and then reinforcing the routes that you need to move the resources along then the most efficient right now. we're just, again, just we've got a traveling salesman problem where we're waiting on these vendors to travel to all the cities and figure it out for us.
When we really need as many hands, as many eyes, as many people as possible working on these problems and the way we do that, as we start unlocking and allowing more folks to have access and accessibility to the solution
James Dice: [00:39:46] space. Okay.
Andrew Rodgers: [00:39:47] Beautiful. It really is. it's honestly like one of the coolest things I've ever seen in nature is this, Distributed.
And I think that when we talk about open source and then technology, that's what you're doing. You're saying, Hey, everybody has problems. Everybody has ways they would like to solve those problems. Maybe this is not an equal playing field for everyone, but you're at least welcome to submit your solution.
And if it works and it resonates with the ecosystem. It will be part of the solution. That's it like? That's the only, that's the, bar's not, Oh, you've got to go be a Johnson partner. You've got to go, be a Seaman's authorized reseller. No, you just, you have a solution you're able to deploy it.
You're able to prove it works. The most important thing is proving. It works. and the entire community benefits.
James Dice: [00:40:34] Yeah. So it's really about the reusability of the Rick's right? So you're. you're not building it for one ecosystem or one building even, you're able to build it once somebody builds it once proves it works, deploys it across all the similar buildings and applications.
Andrew Rodgers: [00:40:51] That's right. Exactly. that's exactly. If you look at the development of Vultron over the last, five years, six years, whenever it was initially released by the national labs, All kinds of components in Vultron now that were not developed by PNNL, that were not part of the original solution, but someone came along and they said, Hey, this is great.
It does X, Y I really need Z. So I'm going to build Z by the way. Hey, anybody else that needs Z, you can use the two. and that's how, we've done that for we've taken technologies that our customers and said, Hey, we need to do X. And we go, okay, that'll take a little time. We'll have to go build that.
We go build it. We release it back into the ecosystem. So anyone else who wants to go solve that same problem has the toolkit and doesn't have to reinvent that wheel.
James Dice: [00:41:34] Got it. Okay. So how about the types of platforms that are one level up from Voltron's Voltron's like freeing the data up and providing, edge to cloud, let's pull the data out of existing systems. And do cool stuff with it. Send it wherever you want, basically. And I'm sorry if I'm paraphrasing and skipping over a lot of full Tron details, we'll get to them in a second. but when you get up to like we've talked about open blue, so that's one type of plant form, right?
When you get up to that level where you are providing applications to users, What can we require from those vendors when we're selecting them? If we're a building owner that would promote this sort of, openness and market transformation, rather than I think what we were describing as more of a closed ecosystem, how can we create requirements around, if we're selecting platforms like that?
Andrew Rodgers: [00:42:28] Yeah. I think this. there's a lot of nuance here. because I think in general, the answer most folks will give you is we've got an API it's open. and I think honestly, as an industry, we don't have great standards yet that allow us to push back. we don't really have a lot of good footing to push back and say, ah, you've got an API, but it's not good enough.
but I think as you look at things like ASHRAE two to three. That are developing right now. and that will, I think, emerge and the Google buildings platform that was just released. I think those are the tools that we need. They may not be the end, all be all solutions, but they're are the tools we need to really have a robust conversation.
look at it, a lot of the problems I see with API APIs that we encounter at that platform level. Are, do they even attempt to meet any standard at all? So API is by default, just are very domain specific. it's very hard to standardize on a particular model that is universal, without kind of.
Leaning into an enterprise approach that might not be as flexible or as easy to integrate with as you would really like. so when we talk about that, there's things like open API 3.0, which is a specification specifically, just for how the API works less about what's possible in the API or about, Is there a specific expectation of how that API should work? That is going to be universal across, well-constructed API APIs, previously, You would see things like soap, which are very much the same thing, not specifying what the API does. It's not domain specific, but it is a way to interact with that API that is standardized, that that if you have this type of value, you can read it this kind of way.
when we talk about capabilities, I think this goes back to that sort of personal relationship with open. but I would say that challenge is not just, can it do what I need it to do today. It's can it do what I need it to do to get to the, that future we talked about because part of that whole.
Consumer pain. Distance is time. you, we buy a new phone, I buy a new phone. I try to control myself to keep it to every tourist three years. a lot of people buy a new phone every year. so that feedback loop is much more rapid. And when we talk about buying building systems, we're talking about 10, 15, 20 year cycles.
So you've got to think when you make your decision, you've got to think in a 15 mean your cycle. And I'm not saying we're going to have buildings that are as smart as we really want them in 15 years. I would love to think that, but I just, yeah, not sure that's realistic at this point, you should be thinking, what I buying today, what I'm deploying today, what I'm investing, my time to learn, those kinds of resources.
Is it going to get me. All the way is it going to still be a value in 10 years? is, Everything I learned about Johnson's proprietary communication protocol from, their edge devices from 15 years ago. Is it still valuable today or are there other, things that have supplanted it that I really should be thinking about?
What's the thing that's most universal or that I can. iterate on myself. yeah, those sorts of questions. I think
so I think like what we have to do as an industry is when we think about that vision, we all have of what a smart building is, how we interact with it. What are those individual granular things that your systems need to be capable of? And do you have a roadmap for how, what you're deploying today is going to accomplish that you have, do you understand, when a user says, whatever preference they put in their cell phone app and.
No X happens in the space. Can that happen? Do you have the ability to all those things, are those, actuators even installed in your system? those are the kinds of questions we need to be asking today. And I think that gets back to when you start talking about the platforms it's okay.
can I do like individual room controls through this platform? can I do these set point setbacks at an individual user level. Those are the kinds of questions, that when you look at an API, not just, I think from a technologist perspective, I would look a lot at like, how does the API work?
Is it similar to other API? Is that sort of thing, but the individual capabilities are all based on those use cases that you have for your clients.
James Dice: [00:46:44] got it. And from a platform selection perspective, it's is this ecosystem it's just like the API. Can the API do it, but then from the roadmap of that platform as well, is the roadmap with that platform over the next 10, 15 years?
Is it going to go where we need to go as well? So interesting. that leads perfectly into the workforce question. so when I think about the stack, we've been walking out, we've been walking from a sensor all the way up to some sort of platform with their user interface.
And then of course, there's. The user, but really, I think also there's but users throughout the entire stack. So there's been people that have been setting up these tools throughout this whole entire stack. So how do you think about the workforce and everyone's scaling up and are supposedly shortage in skilled workers and are industry with the proprietary versus open question.
am I my understanding your thoughts around it being. The more open. It is the less of a workforce problem we have.
Andrew Rodgers: [00:47:42] Yeah. I think yes. but there are some very specific ways that's true. so the workforce thing, I find really interesting because, basically as long as I've been deep into this, on the, smart building side with ACE IOT, everyone's saying, look, we've got this aging workforce. our pipeline is empty. we're not putting people into these programs.
But then you see them defending, keeping everything, vertically integrated, the same people who are saying we don't have enough. People are also saying there's only one true way to be in this industry. And you've got to come through, you've got to be an HVHC tech that, upskills into an automation tech, blah, blah, blah.
Or you got to be an electrician who becomes a controls tech. If we then, becomes the BAS programmer. What I see is we're making all these choices on the technologies that are nonstandard. They're not what the rest of the industry, the rest of the technology industry is using. Like when you look at, haystack is great, haystack, is so much better than anything that's been before, but you look at like the haystack API definition and it uses the data format that no one, like it was invented for haystack and, No one outside of haystack ecosystem is using that.
So when you start talking about, where do I hire people? If I have, a great idea and I want to build a company, can I just go hire software engineers? maybe, but you're going to have to spend some money, upskilling them with these like very specific ecosystem skills that. The rest of the technology world, isn't paying that tax.
Like they're just, they're all using the same stuff. They're all using, the same kinds of data formats so those kinds of questions, I think, when I look at well, where is this pool? Like I'm involved in my community quite a bit. I have good relationships with our community college.
I talked to them about some of the stuff, They're not, people aren't just flooding into their HPAC programs, like even with, all this data and all the effort that's been done in the marketing of that particular career path, people aren't just flooding into there.
But people are flooding into data science programs, they're flooding into, Python or full stack web development. So why aren't we as an industry, figuring out how to make those skills more valuable, or at least lower the impedance of people coming from those kinds of programs into this industry.
90%, this is one of those things that is, Kind of a hard truth in the data science world, but like 90% of the data science work is wrangling CSVs around. Like it's like very simple stuff. And it's stuff that this industry has its problems. This industry has. But because this industry, is so vertically walled garden, structured, it's very hard for someone and to just come into the yeah.
Industry from that perspective, like there's, there's this expectation that they know all these proprietary tools that the only way to know those proprietary tools is to already be in the industry. and I'm not saying that the solution to all of our workforce problems is to have more developers like turning screwdrivers.
that's not what I'm saying at all, but what I am saying is that, it seems like we could get a month wider pipeline if we were focused on using and building tools that sort of build off what the broader technology industry is doing. cause I think this is an interesting space and I, I talk to people every day who paid that tax, who did that extra work.
to move from technology into this space. And they did it because, they care about things like the environment they want to make an impact on co two emissions or greenhouse gases. Like it's those kinds of people. So that's possible. It's just that we make it hard. You have to really want to do it.
and I just think that, there are a lot of choices we make on a day to day basis and the technologies we deploy that could simplify that and make it not quite such a hard problem. Love it.
James Dice: [00:51:29] , So one of the things that.
Andrew Rodgers: [00:51:31] I love about your LinkedIn
James Dice: [00:51:32] posts. Andrew is you're often bringing in, other industries and how our industry is find those and they've gone through the same progression from close to open.
So can you give us a few, like examples? And I'm gonna expose my ignorance here, but one of the ones you've put on LinkedIn was Cooper and Cooper or something and
Andrew Rodgers: [00:51:52] yeah,
James Dice: [00:51:52] Kubernetes, I didn't even know how to pronounce it. So like what would be some examples of other industries that you think would be a good for people to study up on?
Andrew Rodgers: [00:52:00] Yeah. I think I specifically was using Kubernetes. I think this is worth talking about. And so there's probably other examples, but I'll go a little deep into this. Hopefully not too long, but it's a Kubernetes is really interest. I was using that as an example of how open source can be a market transformation tool.
And so if you look at. Eight or 10 years ago, there was Amazon web services, maybe not even eight or 10 years ago. This could have been as recently as six or seven, you had a juror just getting started up, but obviously it could eat a lot of market share just because people are going to go with Microsoft because they already had on prem deployment and you had Google cloud and Google cloud, like Google undeniably runs some of the largest systems in the world.
they're, the best at running these larger systems, but. They weren't very customer focused and they didn't have a very good connection. Like it's very hard to meet Google where Google is that. And that's why that's one of the reasons why we see solutions, that there is, a lot of.
work to taking solutions from the technology space and moving them into the BAS space is because some of these solutions are coming from companies that have, a hundred thousand engineers working on these problems. So like, their solution is going to be at such a level of complexity to solve them global problem.
That it's very hard for, smaller entities to reason about how that works. But, they took a technology that they were using internally for running all their services, the stuff like Gmail that you use every day and kind of rewrote it to be more accessible to folks who aren't, running Google.
but it did simplify, running and managing web applications at scale. and scale could be, tens of servers or maybe hundreds of servers. And their incentive for doing so was that they knew more about that system than anyone else. And their cloud platform was better oriented around that system than anyone else's.
So they gave away this technology for free. They started an ecosystem, they supported that ecosystem. They invested their engineer's time in supporting an open source ecosystem. And in return they got huge market share. Tons of people who were frustrated, the developer communities in these organizations are very different from the operators, of the it infrastructure.
And they were frustrated with things like getting databases provisioned on their proprietary database clusters or getting VMs provisioned. And so they would say, let's just spin up our own little Kubernetes cluster, and then we can run our applications and, iterate quickly and bypass all that process.
And then. What do you know, 1% of those applications are successful. Need to scale up. You need to move into a cloud infrastructure and Hey, Google has got the best place to do that. So this, I think also feeds into the comment you made very recently, which is stickiness versus a proprietary.
And that's exactly what it was. It was generating a technology that solved an acute pain. In the community and solved it in an approachable, accessible way that then had to on-road to, Oh, if you need to solve this pain now and you grow, once you get to a point where there's enough value for you to be a useful customer.
Then we have the platform that continues to solve that pain for you. And does it in the ways that you're familiar with, and you won't have to rearchitect your application. You won't have to, hire additional operations folks because it's just going to work the same way. it worked throughout the development process.
James Dice: [00:55:19] Interesting. That's fascinating. I feel like I could absorb these analogies from other industries all day. Cause it's feeds my soul, like knowing that other people have gone through these same issues and then it's worked out in the end. So what are a few others that come to mind besides Kubernetes?
Is that right? Did
Andrew Rodgers: [00:55:39] I say it? Yeah. I think one of the big ones, and , I've been trying to define and help maybe just clear up some of these. Perceptions of open and open source from this industry sector. And I think when I say open and open source, not always is open source the best, like it's not always, the right answer.
you can make. Choices that, open sources might be capable of doing something, but may be focusing you and your company on the wrong value stream that you need to focus on something else. And there's a proprietary solution that allows you to move your focus to the thing that you care about.
So that happens a lot, but I think another example that sort of like Google, but in almost, almost an opposite end result. So this can go good or bad, I guess is what I would say here. This is like a cautionary tale as well, but Mongo DB kind of went through that exact same cycle. So a lot of people have heard of Mongo DB.
It was almost exactly the same pain solution was, I can't get DBS deployed. I've got to hire a database administrators to help me understand how to write an effective schema for this Oracle database solution. I have these are the problems that were happening in large enterprises.
So Mongo came in and said, Hey, you don't have to worry about schema. Like you just build your thing and it'll work. Well, they didn't tell anybody was, it would work up to a certain scale. And then you might have problems, but they were available for you to pay them to solve that problem. And so now when you look at cross enterprise, like Mongo DB made a ton of money off enterprises because a small software team and enterprise, but start building a solution for some business, problem with Mongo, and then it would turn out to work.
Okay. And they would, need to, scale it up across the enterprise. And now all of a sudden they need help and so you've got, Oh, if you pay for our, commercial license version and we solve these problems for you, that aren't solved in the open source version.
So you have to like, buyer beware on open. Like even if you're not buying, you still need to be aware of what you might be buying into. and. Yeah. And the technology, we're all we have this thing of like open sources. There is free as in puppies. So like a free puppy is anything but free, right?
Like, um, we've probably all been in that situation. So I try to be objective about this stuff. So to give you both sides of that story, one side you've got Kubernetes that solves a huge problem for you. like at this point, Kubernetes is available in all the other cloud platforms.
So if you want to run it in Azure, you want to run it on AWS. They have Kubernetes product solutions as well. but Mongo, is a little different system and a different kind of approach. And they end up with a different, way of same kind of lock in, but the, the investment upfront is free.
James Dice: [00:58:19] Got it. Okay. All right, let's bring it back. So we mentioned the people on LinkedIn phoning in their question. So one of them, and apparently there's could be a little bit controversy around this, but let's just circle back to some of these questions in the end here. So they were asking about individual companies as an example.
And so one of them that I want to ask you about for sure is maybe summarizing all that we've talked about so far, which would be like, where is Niagara closed and open and how do you think about that? company specifically, because I think the perception would be that MACRA is fully open and that's at least my perception of how people think about it.
But, is that true? And how do
Andrew Rodgers: [00:59:02] you think about it? I think this is goes back to what your previous question of asking for examples. and this question, we can merge those because this is like a perfect opportunity to compare and contrast about what my expectations, my personal expectations of what open is versus what something like Agra provides you.
and I'll, I'll get very specific on both sides, just so we can have, clear talking points. I'll talk about Niagara as a programming framework and language and tool. And then I'll talk about Vultron and Python as a programming language and framework and tool. and just compare.
So like with Vultron who do I pay to run Vultron on a device? No one. if I want to write Python code that runs inside Vultron. What tool do I need to use to write that or compile it or package it to be distributed? a text editor. so literally like, Anything? what hardware can I run? Vultron on any hardware? I don't need like a sticker that says, licensed for Vultron or licensed for Python. so those are the expectations I bring when I look at things and ask if they're open and under that. I think it's be pretty hard to argue that Niagara falls into this, those expectations, but I'm not here to like, make a concrete judgment on whether something is opening.
I'm just telling you from my perspective, what I look at. Yeah. Yeah. and I think that you look at something like sky spark is very similar. and I think that model works great. it obviously has been great. But I also think, the real test is how long has Niagara been in the market.
And do we have that building future that Deb talked about, that we all aspire to. And so
James Dice: [01:00:43] no
Andrew Rodgers: [01:00:46] don't then, something needs to change and. maybe it's not Niagara's fault. Maybe it's how it's being used. Maybe there's all kinds of ways to talk about it, but I don't think anyone, no one's saying
the buildings are as good as they need to be. But then you do find people defending the tools that are used to make buildings the way they are.
James Dice: [01:01:06] I totally agree. A hundred percent
Andrew Rodgers: [01:01:08] You can't separate those two. There's either things are as good as they need to be.
Or we can improve what is, and I think we can improve what it is.
James Dice: [01:01:16] That's the journey I'm on. And honestly, sometimes I get direct messages or emails that are giving me Slack, because it's like, why are you promoting these new companies? Or why are you giving a platform to these new companies? And my answer is always we haven't solved it yet and we need to keep looking at because the problem still exists.
And as soon as the problem is actually solved by one of the companies, I'll. Give up, I'll go golf or something, but like my pursuit is around like finding the answers. And I think we're still looking at it. Just like you said, about what Deb said, it's we're still trying to realize that vision and it's still out there, so, okay.
So I love that answer. As we close this out, let's talk a little bit about Vultron. How are you using it today? is my first question. And then like, where do you see the tool going? and where do you see the platform headed as the second?
Andrew Rodgers: [01:02:06] I'm going to answer that backwards. I'm going to talk about the vision that traumas belt with, because I think it's important to understand where it came from.
So Vultron was a tool built for researchers by researchers in the national lab system to solve the problem of having a platform where they could build test simulate, and really review. New paradigms for grid operations. So specifically a concept called transactional energy. So the idea that everything that's consuming or producing energy participates in an open market, your chiller is negotiating with your building for energy.
Your. Zones are negotiating with your chiller for energy, and they all have some price they're willing to pay. So you could, you can optimize. You don't need schedules if you don't need like hard schedules, if your schedule is I'm willing to pay this much during this time of the day. And this much during this time of the day for conditioned air and every asset can speak that value, right?
Like they all have that as a universal and you could, you could do it with just saying KWH or KW or whatever as well. But this was the vision that like, that translates all the way up from, Your computer monitor, staying on all the way to gridscale is a negotiation. So Vultron was built to allow the national labs to build out test systems that really showed off that transactional.
So it needed to be able to communicate with building systems. It needed to be able to communicate with IOT systems and needed to be able to communicate with grid, operation systems, switch gear, that level generators, micro grid, inverters, solar inverters, that sort of thing.
and it needed to be able to communicate both ways. So we talk about Vultron a lot and like this data platform layer, but fully supports communications in both directions. So you can. use it for writing values, for pushing set points for doing all the things you would use a supervisory control system for, now to get back to like how we use it.
I think we're squarely right now in I would say our primary use case that our customers bring to us. Is it advanced supervisory control 1.0, where we're bringing back a bunch of stuff. We're allowing them to run analysis. We're allowing them to, look at the data in depth, map, do all their tagging, all that functionality so that they get real insights from their equipment.
In real time, we are starting. And when I talked about that, every project with the residential loads, that's where we're starting to get into. and when we were working with a couple of other platforms that are more on the building side, but, Getting into advanced supervisory control to the point where we can start pushing things, control is happening at that layer.
We're enabling other applications to optimize specific parts of it, of the system. So we can, by using Vultron as this, Meta layer or middleware, we can farm out the parts of the system that are most effectively optimized by various components and give you choice on what you use for which part.
So you're not buying into a particular, optimization vendors ecosystem for your entire. System or your entire portfolio, you can say, this building, this technology really works well in this building, but this is a different type of HPAC system. And it works better with this kind of, you know, optimized.
So you get that sort of, ability to really get it gets back to choice, which is where I think been if you made me give you the, like the one word answer for open it's choice, it's do you have choice? we use Vultron to give our customers choice about how they optimize or how they use their equipment or build advanced control solutions.
James Dice: [01:05:46] Got it. I love that. And yeah. let's do this, let's do this conversation again, sometime because I really want to get into that, the value of that independent data layer. I think that's just as controversial with some of these companies that would rather provide a full stack.
And so I think that's a, another area where. we could get into the weeds and with advanced revisory control, I've been having so many conversations lately where people are skeptical, that's even a real solution and that the market wants that specifically like our building owners wanting that.
so I really want to get into that with you, in the next conversation, but for now we should close this down. I think we could go all day. and, I just want to thank you for coming on the show. Also. Thank you for listening to all the past episodes. I feel like that really helped. yeah, that's on the same page for this one.
So I really appreciate the time you put in there and, all of the knowledge you're dropping. So
Andrew Rodgers: [01:06:37] all the time you put into that, and also the guests you had, you've had some really great guests, so it was time well spent for me. I don't feel like I, I feel like I got more out of that then, than you did with this conversation.
Awesome.
James Dice: [01:06:49] Awesome. let's get another one on the calendar and thanks a lot, Andrew. And I'll talk to you soon.
Andrew Rodgers: [01:06:53] Alright. Thank you.
James Dice: [01:06:54] Alright, friends. Thanks for listening to this episode of the Nexus podcast. For more episodes like this and to get the weekly Nexus newsletter, please subscribe at nexus.substack.com. You can find the show notes for this conversation there as well. As always, please reach out on LinkedIn with any thoughts on this episode.
I'd love to hear from you. Have a great day.
Head over to Nexus Connect and see what’s new in the community. Don’t forget to check out the latest member-only events.
Go to Nexus ConnectJoin Nexus Pro and get full access including invite-only member gatherings, access to the community chatroom Nexus Connect, networking opportunities, and deep dive essays.
Sign Up
Nexus Labs exists to move the smart buildings industry forward, without the fluff.
On Wednesday, we send out the renowned (and free) Nexus Newsletter.