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 Deepinder Singh, CEO of 75F. 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
Disclaimer: James is a researcher at the National Renewable Energy Laboratory (NREL). All opinions expressed via Nexus emails, podcasts, or the website belong solely to James. No resources from NREL are used to support Nexus. NREL does not endorse or support any aspect of Nexus.
I walked away from this conversation even more excited about 75F than I already was. As I’ve said before, 75F and Passive Logic are the only two companies I know of who are doing the “blank sheet of paper” approach to fixing controls. I haven’t compared pricing apples to apples, but strategically, I think every new building and retrofit project should be using the blank sheet of paper approach. Since PassiveLogic isn’t on the market quite yet, I think every building being built today should be using 75F’s controls. Disagree with me? Let’s hear your argument in the comments!
Like Passive Logic, it seems like 75F intends to take an overlay approach if a BAS already exists in an existing building. I say “seems like” because I'm not quite sure we were on the same page here. Definitely a follow-up item for Deep/75F, or maybe Dave can answer in the comments! Can 75F be an open supervisory layer for multiple BASs across a portfolio? Seems like the answer is yes, with a BACnet->Haystack data pump, but someone needs to perform that tagging of the legacy BASs. So it's not plug and play, but it would work.
Finally, I really enjoyed the part of this episode about over the air control sequences. It was a wow moment when Deep talked about how controls standards (like ASHRAE Guideline 36) are brought down to the lower common denominator. So when ASHRAE/CDC made recommendations for COVID, they had to do the same, and that’s what led to the “100% ventilation 24/7" recommendation. Luckily, everyone can follow 75F’s lead and copy their epidemic mode approach. Deep would love that and so would I. Here’s how:
[00:10:00]
Today it's inconceivable to not walk into a mall and you want to buy an iPhone in three minutes. Of course, you can't walk into malls these days without wearing a face mask, but that's a different story, right? But if it ever takes you five minutes, you're probably screaming bloody murder. It's like, ah, this thing is not right. But it's kind of weird in the controls industry, we still accept that, that system integration, taking the product from Schneider and then taking another sensor from ECI and then tying them together through custom code is acceptable, right. And, and that to me is kind of weird. It's part of it.
Yes, standards exist for interoperability, but they also make it harder, that nothing works out of the box, right. And if you look at it, I mean the standards, I believe don't necessarily need to exist at a device level. Really, if you want to have-, these days, I mean, the system should work out of the box. I mean, you don't really care what standard your iPhone camera uses to communicate with the rest of the processor. What you do care about is about the base level of functionality and like, how does it interact? Like is the file system, which is supported, is the photo a JPEG or PNG, which can be exported out of the unit, right. So if we accept that kind of modularity, I mean, if we accept that that is a black box, then that really allows us, things to be more efficient. Not everything needs to be interoperable at every stage is how I look at it. Right.
So our take was that, alright, let's make sure that, instead of saying that the humidity sensor itself needs to talk BACnet and go right to a controller, let's make sure that the humidity sensor and the temperature sensor and the organic compounds and the CO2 to sensors, let's not even make them optional. Right? Let's put in all of these sensors out of the box. Because the hardware has grown, in all honesty, it will be super reliable and cheap, right. We end up using the same sensors. When I started originally on the, on the residential side, I mean, we use the Fluke temperature sensors were about $350. To get a reference quality Fluke sensor. We have the same sensor in every one of our rooms now. Wow, right. So overall, if you look at just how, and it's part of the mobile revolution, right? I'm not taking credit for it. What I'm saying is that, I mean, the consumer electronics have really driven, the mobile revolution has driven such good standards in terms of sensors and overall technology that what we really need to do is keep pace, take advantage of that.
And that's what we're doing. We're packing all of these sensors, packing in all of this functionality out of the box, right. And the second piece that we wanted to do is we wanted to have that instead of having a dedicated application-specific controller, if you have one controller that takes on different personalities, depending on what equipment you connected to. So it's kind of like your iPhone is one box. It's got all the sensors, got all that functionality baked in depending on what app you're using. You end up having a different profile, right. Because the value is in not necessarily going and integrating and putting these things in one at a time. So it's not unique in terms of what the industry is doing in the consumer side, right. We accept this in our phones. We accept this in our cars. We've just not somehow got it in our HVAC and our buildings yet. Right. We look at it as a totally different scenario. Nobody talks about like hey is my car talking BACnet.
[00:17:57]
Deep: What we did find is that buildings under 10,000 square feet, which I thought would be the primary market to begin with, right. Those folks are not as concerned about actually having temperature control or about energy because the numbers are too small. But the sweet spot, I think is really somewhere between 20,000 square feet to about 200, 250,000 square feet beyond which I think controls are kind of accepted.
It is better. Right. But the sweet spot is really, can you go address that? And that's kind of an important, very important segment for us specifically now, given where we are with the COVID situation, right. And where the CDC and ASHRAE guidelines are right. So we are going back to a lot of not only our customers, but new customers, churches, schools, right, business manufacturing facilities, which are specifically working 24/7 as an example, right. Light manufacturing. We're going back to them and making sure that their workplaces are safer, even where we are. So specifically we introduced something called epidemic mode which implements the CDC and ASHRAE guidelines, right. So that's a very important segment, spot on.
James: Totally. And it sounds like, you know, before they might not have any, any automation at all, and you're going in and saying basically, Hey, this is an opportunity to start controlling, measuring, measuring your ventilation, right. And making sure that you have enough. Cool. So before we get into epidemic mode, I do want to hit that next, but I think like your platform enables epidemic mode, because you're able to push sequence updates to controllers. And I think that's a huge differentiator, you know, compared to the old way to do controls. So can you talk a little bit about why you did that and, how that works?
Deep: Again, I do believe in the future this is what we will see, right. I mean, we take it for granted that your phone is going to keep updating. Yeah, right , and now you have the cars which keep updating. So, so why aren't your HVAC system?
Right. And so even day one, I mean, that's what we started with over the air firmware upgrades, and also, our central control unit, which actually runs the algorithms holistically for the building. So those, that keeps updating regularly. And in fact, It keeps updating both from the sequence of operations, but also on a daily basis, it actually gets updated in terms of the tuners, because we create a ML model. So we look at the weather and we look at the past history and we'll figure out what's going to be the optimum tune points, set points for making the building work. Right.
And these are not just temperature. We don't change temperatures, temperature set points, because I think. That's kind of-, I have another beef with this, right. I don't understand. I think it's, it's a Kluge to try to change set points, to get your controllers to do something different. Right. And it's primarily because I think that the controllers are locked in terms of the sequences that they have. So the only option normally available is like, how do you fool them into doing something different?
And, and that's really hard science, in my opinion, and a hats off to companies who are trying to fix that because every manufacturer, every deployment has a different understanding of what the controller should be doing anyway, right. So now you have lots of different variances that you really have to account for in your ML models, which is why I don't think machine learning and tweaking has truly taken off because every building is an exception.
Right. And ML only works if you can tune the model and if you can train the model. So we decided that we want to standardize this. So the idea is that out of the box, I mean, we use like true software processes and test harnesses to make sure that it's not just the software, which is working, but the sequence of operations are doing what they should, right. So unless you have regression tested with the point of like continuous commissioning is to me, so weird. Right because I mean, that should be a given the fact that we have to go back and recommission buildings makes no sense at all.
It should work out of the box and this stuff should self-tune. I mean, that's the whole point. If we look at our apps, if you look at where the world is with, like, we actually have continuous integration and continuous deployment things, right. In terms of microservices and how we update the web as an example, right. None of those things have somehow carried over to this domain, right. But from my perspective where I came from, I mean, that was a given that things work. They always keep changing and you can push them out as sequences get better, technology gets better, our understanding gets better. You keep on pushing these updates out. And that's what we really did, over the air upgrades, as I said, not just for central unit, which is running Android, the gateway, but even for each of the edge devices themselves.
…
The biggest difference is our machine learning is really looking at loads in the building. Okay, so it doesn't have to keep changing set points. What it does is it, we have a concept of what we call tuners. Tuners are things which can affect the functioning of an algorithm. As an example, we have a bias towards saying that, Hey, if you already have an ML model and you know that it's going to be sunny, then your load in the building is going to shift more.
And it already knows that from the weather forecast model, But it doesn't actually-. So it's really saying that the load is shifting by 2:00 PM. The load is going to be 30% more in this part of the building. What it doesn't have to do is like the set points don't have to be changed because that's really a hint to the system that you're going to start putting more air before the set points have to be tweaked.
The problem is that everyone's using proportional integral systems, right. And because you use using PI controls, what you're doing is you're trying to use the Delta T between the set point and the current temperature to try to fool the system to get it to do something else.
Whereas the true problem is really that you've got an increased load coming down. You should really be conditioning beforehand. There's no reason that you really need to be trying to tell the PI loop and fool it to do anything different, right? So I look at the PI loops and stuff. Those are really far more reactive, for course correction in tweaking, but if you already know that the load is going to be more in a part of the building, let's just open up the dampers predictably proactively, right? If it's going to be a cloudy day, then you really know that the loads going to be more uniform. It's occluded so that there's not going to be as much directionality to the load.
So that's one piece, right? You can use things like, even things like, when do you turn on for preconditioning, right? I mean, you already know that based on what the current temperatures are and where the outset temperatures are. And so, you know, what a cooling rate or your heating rate should be, and, you know, the Delta T and the temperature and set points. So don't change the set point. Let's just figure out the right way of doing it.
[00:26:20]
The current BAS systems are the tail wagging the dog, right. It's like your PI loop is typically running in your room. And it's really controlling the VAV damper opening as an example. Right? So your communication back to your actual BAS is typically by duct static pressure, right?
No one is actually saying what should be happening in all the zones, which are being served by an AHU. You're not figuring out what the total load is. You don't know which part of the building really requires a load. All you're doing is you're using duct static pressure has some kind of a mechanism of figuring out. Yes, there is more required load in some part, right?
I think the closest we've come to is now with the, with GPC 36, the ASHRAE Standard Advanced Sequences for HVAC Operations. I mean, what they started doing is sending some feedback back in terms of trim and reset, trim and respond. And that's a mechanism that is in some ways, of course, PI loop mechanism, the requests are the equivalent of showing some load in the terminal units, right. But I mean, there are far more interactive, far more real time systems available that we've implemented. We also implement GPC 36, by the way. Right. Because some engineers really want the assurance. That is a very well-defined mechanism, which is well known. And so we implement GPC 36 and we we've committed to the fact that as GPC 36 evolves, we will keep updating our sequences. And more importantly, we do reference quality GPC 36. It's like using software techniques, crude test harness stuff, which does regression or not. And so we run it through the whole shebang.
So you don't really have to commission them. It works out of the box. Totally, right. But the key is that, I mean, from our perspective, GPC, that is the lowest level of, I think, current control solution that I would actually consider acceptable.
[00:37:39]
Deep: So we had a theory. The two things that we wanted to test out is A) from our perspective, you don't need the ventilation all the time. You really only need it when the building is occupied. Second, the other thing was that the reason that the CDC said you want to run it 24/7 is because the concept of a purge means that you can, you cleanse the building with a high amount of outside air for a short duration. And the ASHRAE sequences at some point talk about the purge creepers and the post-purges as well, right. But the CDC did not because they already had to bring it down to the lowest level.
So we actually tested these out and we did some pretty interesting experiments. So obviously, no one's detecting the COVID virus itself, but what we did is we did some experiments in which we use, you know, we, since we've already got volatile organic compound sensors built into the product, we actually use meth paint and alcohol as the two substitutes. And we use cotton balls dipped in alcohol. And when you took it out, figured out how long it would take for those cotton balls, the VOC levels to decline.
So in normal mode, in a normal AHU operating normally, and the average Hertz was about 50% of capacity. It took about two hours for the VOC levels to decline to baseline. When you raise that up to about 60%, 65%, it took about one hour. Now, when you raised it over to 80%, it only took 12 minutes. The primary reason is, is because the air flow starts becoming turbulent, right? So your actual ability to extract and entrain the air and extract it is far more efficient, right? Which is what, in my opinion, like, no one's done these studies before, but we wanted to test it out and it's like, yes, so if you truly wanted to do this, what you want to do is you want to run the fan at high speed. You want to get a whole lot of outside air for a shorter period of time and get it all cleansed, right. So that's what we did.
We introduced this concept of a pre-purge and a post-purge. So it's prior to occupancy and after occupancy, and back to your point, you can turn them on and off as simple as just a slider on a phone. And the system automatically does that. But when you're doing these purges, at that point, you really don't want that the set points should be maintained. So it's not the same as saying, Hey, let's move my schedule earlier. Because if you try to maintain set points, then you have a very tight temperature debt when you're getting in a whole lot of outside air. And you're really going to be consuming a huge amount of energy to make that happen, right.
So what we said is it's going to be in setback, right? So it's going to be, the temperature bands are going to be way more relaxed. You get in this air. All you're doing is diluting the air inside and purging it out. And then when the purge is complete, then you tighten the temperatures back to set point and you also reduce the amount of outside air that you're getting so the system can maintain these temperatures. So that's unoccupied.
So during occupied mode, you bring down-, you still get enhanced ventilation, but not a hundred percent, right. And that enhanced ventilation knob is tuneable. It's again using ML, but we normally set it as a 50% as a baseline, is what we set.
So back to the energy impact study with NREL. So that's the mode that we implemented and we asked NREL to actually go back and do this validation and the results are, are eyeopening I think in terms of the energy impact, as you might imagine, right. And, but just following the CDC guidelines is going to be somewhere between three to five times, in some cases, in some climate zones, three to five times of what your baseline energy is… Just the HVAC piece.
James: Yeah, right. Okay. So they basically ran three-, the way I understand it, three OpenStudio models : one with normal operation, one with the CDC guidelines, and then one with epidemic mode. And what were the average savings for the epidemic mode from the CDC?
Deep: Right. We actually ran it in four. So we ran a normal mode, we ran it in CDC guidelines, and then we ran epidemic mode, and we also have in within epidemic-, remember that we have occupancy sensors. Right? So we have a concept that was just something that we're seeing that many of our customers are not getting in all the teams, all the employees in on the same day. So if you have staggered days of occupancy using the occupancy sensors, it saves a fair amount of energy as well, because you're only trying to condition those parts of the building which are going to be occupied. So, so when they ran that, what we found is that the CDC-, on average, the CDC guidelines are end up about three extra, 2.5 to three times over the baseline energy usage for the HVAC.
The epidemic mode in an office scenario was about 30% over the normal mode, right? The, which is about 50% savings over the CDC guidelines, which is significant, since now the top line is so large. And if you actually use the epidemic mode with the staggered occupancy, we were only about 15% higher than the baseline, which is like exceptionally nominal.
So back to your point, the point I was making is that if your buildings are adaptable, now you can make them healthy without necessarily incurring a huge cost as well.
[00:48:43]
As we decided that we were going to go scale the technology up, we actually made it so that it is exceptionally modular in a true platform, right? So we actually, one of the key things that we did is-, it's kind of weird, I keep dissing standards like BACnet, but on the other hand, I'm really gung ho on places like Haystack. And I know you were talking in the last episode on BACnet, 223, right, ASHRAE 223 and, and Haystack. So we have made everything within our product layer now in the software stack as 100% Haystack compliant.
So all our apps, all our portals are actually running reference implementations of Haystack apps. They ended up using the same API that we would actually expose to our customers, right? So I'm a big fan of interoperability, as I said, not necessarily at lower layer level, but at the right scale. And to me, I think Haystack is probably the first place where we've actually started getting some standardization around that piece, right. So, and especially when Haystack 4, gets completely flushed out or, or whatever ASHRAE comes out with on the 223 Committee, I think that's going to be exceptionally important.
So when we designed it, we made it super modular now. And so it's completely originally, it was just cloud hosted, but now we call it completely because some of our customers want it hosted in their own private data centers on, we have some countries which have restrictions in terms of the data should be stored locally. So we call it a hybrid public-private cloud. So it's completely containerized and dockerized so you can actually deploy it with what's called CICD continuous integration, continuous deployment. So it's, it is as good an architecture from a software perspective as can be, right. And that's because we decided to rearchitect it, as I said recently.
And now it's to the point that, I mean, we really look at like how are smart cities going to scale on a platform like this because we have some partnerships as an example with Singapore Power, they're the world's largest district cooling utility. But what they're doing is they're going and replicating the entire package of how to do district cooling to other countries and other districts, not just Singapore. Right? So they're selling it as a service. And so we are the technology stack on the building automation side for that. Right? So whenever there's a new smart city or a smart district, which is going to use Singapore Power they're all going to be using 75F technology.
So we decided to go back and make sure that the technology would scale to those levels. Because as we go in the future, I mean the whole concept with this distributed energy resources, as solar and wind become more prevalent, it's no longer going to be the case that the grid is going to scale up to the load; the load is going to have to adapt to the grid, right? So if that's the case then we really need bi-directional data models, which allow massively parallel computing in terms of machine learning, et cetera. And so that was the whole genesis behind making sure that we had semantic model in addition to just storing the data, right. So, so Haystack really fulfilled that.
[01:02:54]
What's kind of interesting is because of the fact that we are all IoT and we have our own knock for monitoring all of our deployments, what we do is we allow the white labeling of the monitoring service and that's kind of interesting thing, right? So if you're a smaller shop and you don't have a full knock, right. You could actually basically take our, get managed services from us, but put it under your own umbrella.
So you would end up getting the mechanical contractor or the service contractor would actually end up saying here's the service contract to their own customer, but we would be providing it, servicing it in the backend. Right. And what's kind of interesting with that is because we have so much data coming in, I mean, we can actually dive back directly and send out service tickets as well to dispatch mechanical guys if needed. So it's an interesting piece in terms of the managed services part, what this allows us to do so that you can be far more proactive, right. Because the knock is running all the time.
So it's truly a network operating center, which is like looking at all the buildings, looking at all the data and all the loads which are coming in.
[01:04:41]
Deep: One of the things that we've had a fair amount of success with is, is OEMs of equipment. Okay. Right. So you have the big guys, you have the Carriers, and you have the Tranes, and JCI who have their own controls. But you also have a large number of people who are making HVAC equipment, but who don't necessarily have their own controls line. And for those, I mean, we have really started becoming an OEM out of the box because now it's a huge differentiator, right?
No longer do you actually have to rely on someone else to do that system integration because it's now working out of the box. And so as a packaged solution especially for these midsize buildings that you're talking about under 200,000 square feet. I mean, it's a huge differentiator.
James: Totally. What would be an example of a piece of equipment that, you know, you could then just, it comes natively with a 75 F controller?
Deep: Dual cool, swamp coolers, things like AHUs, a lot of customized AHU folks out there, right? Small RTU guys. So we don't do the equipment control, but we provide the building control aspect of it. Right. So we wouldn't necessarily go in and replace an RTU controller itself, but we would go and interact with that RTU controller and make sure that they have, they basically are making it IoT enabled.
James: Okay. So a smaller building that only has, you know, five RTUs, and then you'd throw a 75F building controller. And now all of a sudden it has all the intelligence that-.
Deep: Yeah.
James: Okay, cool. I love that.
[01:08:35]
You want to have a consistent platform. You want to have the same hardware rather than having application specific stuff. In my opinion, that brings down your cost because you're doing volumes. It allows for more reliability because it's the same product. You're not saying, is CO2 sensor optional. Now, is this going to be for a water source heat pump or is this going to feed before a heat pump, right? Or is this a fan coil unit, right? I mean, I think it changes the supply chain game dramatically, and I think in 2020, that's where we should be.
What did you think about these highlights? Let us know in the comments.
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: [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.
One more quick note before we get to this week's episode. I'm a researcher at the National Renewable Energy Laboratory, otherwise known as NREL. All opinions expressed on this podcast belong solely to me or the guest. No resources from NREL are used to support Nexus, and NREL does not endorse or support any aspect of Nexus.
Episode 13 is a conversation with Deepinder Singh, CEO of 75F. I walked away from this conversation even more excited about 75F than I already was. As I've said before, 75F and PassiveLogic are the only two companies I know of doing the blank sheet of paper approach to modernizing and improving the performance of building control systems.
We unpacked 75F's founding story, what makes them unique, and why they decided to create the whole stack rather than just an overlay. We talked about their over the air sequence upgrades, how they're similar to Teslas, and how they enable the new epidemic mode for minimizing the energy penalty that comes along with the increased ventilation recommended by the CDC and ASHRAE to prevent the spread of COVID-19. Finally, we talked about their software platform, what makes it unique, and their hardware layer, and what makes it unique.
This episode of the podcast is directly funded by listeners like you who have joined the Nexus Pro membership community. You can find info on how to join and support the podcast at nexus.substack.com. You'll also find the show notes there, which has links to Deep's LinkedIn page.
Oh, and by the way, if you take a look at your podcast feed and you're missing Episodes 10 and 12, 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 all the episodes.
Without further ado, please enjoy Nexus Podcast Episode 13.
So hello, Deep. Welcome to the Nexus podcast. Can you go ahead and introduce yourself?
Deep: [00:02:49] Thanks for having me over, James. Yeah. So I'm Deep. I'm the CEO of 75F.
James: [00:02:54] Alright. And what is 75F? A for those that don't know?
Deep: [00:02:59] Yeah. Plainly speaking, we think of ourselves as building automation in a box, right. So what we've done is instead of trying to go and attack a very small layer in terms of putting in a software layer or just making smarter sensors, we decided to actually do the whole stack. So we actually start-, we have our own sensors. We have our own controllers. We make our own gateway and aggregation units. And on top of it, we put our own software, which is both in the building as well as in the cloud. So that includes things like remote access and portals. But also the machine learning stacks that we've created.
So all of that is really part of 75F. So it's a complete building intelligence solution, is how we call it. We don't just call it building automation. But we make it simple enough that it works out of the box. So it really doesn't require a huge amount of system integration actually requires zero amount of system integration.
James: [00:03:51] Cool. Cool. Yeah. I'm super excited to dig into a lot of this. I've been waiting to interview you for awhile.
So why don't we start with like the founding story of the company. So, I mean, I've talked a lot about how I think the building automation industry is broken. So I don't want to throw that story out there. I want you to tell me how it actually came about. So how was it born?
Deep: [00:04:12] Yeah. So it's an interesting thing. So I'm not at all from this industry, right? I'm a computer geek, mostly a network dude. So, if you use Verizon as an example, there's a 95% chance it goes over a back haul that I did. I had one of the world's first terabit routers sitting in my garage for five years.
But when my daughter was one, we just moved her into her own bedroom and she would wake up in the middle of the night crying. I was trying to figure out what's going on. And we found out that it's because the temperature in her room was dropping about 10 degrees at night, right? So she would be very extremely uncomfortable and get up. So as a self respecting engineer, I wanted to fix the problem. So I quit my job and here we are, we're chatting.
James: [00:04:55] Okay. Well, fill in some more of those details. So, how did you go from say, you know, fixing the air in your house to the commercial buildings industry, and what made you feel like the, you know, the controls market in this industry was an opportunity for a startup?
Deep: [00:05:12] I mean, I already started to fix my own personal problems.
So when we originally started, we were really looking at the company called Keene, went and eco home. They started making this way after us. But we used to-, I started a company called sun bullet, which really made these motorized dampers that you could put into each room in a house to control, to turn on and off the airflow in there, right? So it's kind of primitive zoning, but it's at the terminal side. What it's doing is instead of going and putting a damper in the duct work, you really using the resister to control it automatically.
And as we progressed to that, we actually went to a pretty late stage. we were in talks with GE to produce it and Best Buy to distribute the stuff. We found that there was basically about 25 different skus, the units that you sell, that we would have to create, because the resisters come in so many different sizes in the residences, in the U.S., right. And because of that, I mean, it was from a logistical perspective, very expensive proposition. So we abandoned that piece because it required too much shelf space.
But the idea as part of the journey, I mean, I found that if it was an issue in residences, it was a bigger issue in commercial buildings. And I was a little bit surprised by that. I mean, with due reverence to Johnson Controls, I go into the headquarters, they have the steam-powered zone-controlled systems going back 150 years, right. But the industry really hasn't progressed that much in the last couple of decades, right. Even what we see now, the DDC controllers, and the BACnet pieces really came in the mid nineties.
So we haven't really caught onto the true IoT revolution. A lot of companies are claiming they're IoT, but IoT is more than just saying that we're connected to the internet, right? IoT is really about being current, being over the air upgrades and just taking this connectivity ubiquitously as, as granted, which is not necessarily the case in the industry. Right.
So when I came in from the telecom side, I was a little bit surprised that this is an industry, which I mean controls the large amount of energy, I mean the fourth largest emitter of GHG gases is our buildings, right. And all of a sudden we have technology, which is very outdated. And I primarily think it's because most of the folks come from the mechanical side. And not necessarily from the IT side. So most of the standards are not necessarily have caught up with the same pace that we've seen in consumer electronics as an example.
So for me, this was an opportunity that commercial buildings presented more standardization. The dampers are more accessible. You have, right, the more commonly configured sizes. You don't have to stock them. They're also available more easily. So we actually shut down the old company, sun bullet, and I recreated this new company, 75F, specifically focused on commercial buildings.
James: [00:08:02] I got it. And what year was that, that 75F started?
Deep: [00:08:06] 2012 is when we started. And I was primarily originally focused on the light commercial buildings. So I was thinking of the same thing, residential, no, let's go into smaller buildings under 10,000 square feet. People can buy a solution from a distributor and essentially once you've got that, they can go put it in themselves. So that was the whole Genesis that let's keep it relatively simple for smaller buildings.
Things have evolved over the last few years though, right? I mean, it's, interesting. I mean, you know, you start seeing these cracks in what's out there and you keep wondering like why it's not been addressed. And I do believe that this business case, I think you've discussed about it as well, that it's a question of how are people incentivized to make money, right. How the channel has grown over the years. Right? So there's a technical issue, but there's also a business issue as well. Right.
And if you're not from the industry, then you're not encumbered by either. You don't have to support legacy customers, and you're not necessarily beholden to say that, Hey, we have to serve the same channel that is going to market. So go to market can be a little bit different. And I think we brought that fresh approach being outsiders and not necessarily knowing what we were doing.
James: [00:09:18] Yeah, totally. Cool. So, I want to just hit on a couple of these. I mean, you've mentioned a lot of these differentiators already. So maybe just take us through like why you decided to create a full stack. So you recognize this as an issue, but you're actually creating sensors, controllers, controller software, cloud software, the whole gamut.
So why did you decide to do that?
Deep: [00:09:44] Primary reason is like, I look at the controls industry as kind of like the computing industry back in the seventies, right. Back then, when you bought an Apple: one, you brought it home, you sorted it together; and then you learned programming basic to solve your own problems, right.
And today it's inconceivable to not walk into a mall and you want to buy an iPhone in three minutes. Of course, you can't walk into malls these days without wearing a face mask, but that's a different story, right? But if it ever takes you five minutes, you're probably screaming bloody murder. It's like, ah, this thing is not right. But it's kind of weird in the controls industry, we still accept that, that system integration, taking the product from Schneider and then taking another sensor from ECI and then tying them together through custom code is acceptable, right. And, and that to me is kind of weird. It's part of it.
Yes, standards exist for interoperability, but they also make it harder, that nothing works out of the box, right. And if you look at it, I mean the standards, I believe don't necessarily need to exist at a device level. Really, if you want to have-, these days, I mean, the system should work out of the box. I mean, you don't really care what standard your iPhone camera uses to communicate with the rest of the processor. What you do care about is about the base level of functionality and like, how does it interact? Like is the file system, which is supported, is the photo a JPEG or PNG, which can be exported out of the unit, right. So if we accept that kind of modularity, I mean, if we accept that that is a black box, then that really allows us, things to be more efficient. Not everything needs to be interoperable at every stage is how I look at it. Right.
So our take was that, alright, let's make sure that, instead of saying that the humidity sensor itself needs to talk BACnet and go right to a controller, let's make sure that the humidity sensor and the temperature sensor and the organic compounds and the CO2 to sensors, let's not even make them optional. Right? Let's put in all of these sensors out of the box. Because the hardware has grown, in all honesty, it will be super reliable and cheap, right. We end up using the same sensors. When I started originally on the, on the residential side, I mean, we use the Fluke temperature sensors were about $350. To get a reference quality Fluke sensor.
We have the same sensor in every one of our rooms now. Wow, right. So overall, if you look at just how, and it's part of the mobile revolution, right? I'm not taking credit for it. What I'm saying is that, I mean, the consumer electronics have really driven, the mobile revolution has driven such good standards in terms of sensors and overall technology that what we really need to do is keep pace, take advantage of that.
And that's what we're doing. We're packing all of these sensors, packing in all of this functionality out of the box, right. And the second piece that we wanted to do is we wanted to have that instead of having a dedicated application-specific controller, if you have one controller that takes on different personalities, depending on what equipment you connected to. So it's kind of like your iPhone is one box. It's got all the sensors, got all that functionality baked in depending on what app you're using. You end up having a different profile, right.
James: [00:13:07] Totally. Yeah.
Deep: [00:13:09] Because the value is in not necessarily going and integrating and putting these things in one at a time.
So it's not unique in terms of what the industry is doing in the consumer side, right. We accept this in our phones. We accept this in our cars. We've just not somehow got it in our HVAC and our buildings yet. Right. We look at it as a totally different scenario.
Nobody talks about like hey is my car talking BACnet.
James: [00:13:37] I agree. Yeah. So, it sounds like also one of the benefits of it being full stack is it's also super easy to install, right? I mean, like you kind of hinted at with that, with the iPhone example, but it can be very quick, right. And I think that's one of the things you guys were going for initially too, right?
Deep: [00:13:56] Right. You're spot on with that. Right. I mean, that was the whole idea that we wanted to make it very easy.
But back to my roots, I was really thinking that like, why, why did this control solution in our home not work? And it's primarily because we made overly-complicated. We've got all these pieces to tinker around. We're not looking at it as a solution. We're really looking at small pieces that needed to be brought together. So we had this program, we did a project in elementary school and we asked the kids who are eight and nine years old to go put in our system ourselves, right.
So the idea is that, so we always have this thing. I mean our system's gotten, in all honesty, a little bit more complex. Now we're doing much larger buildings, a million square feet sometimes, right. But, so maybe the same students could do it now. Right? They're a little bit older, 10 and 12 year old kids could do it now. But at that point it was revolutionary that you could go put in a control solution that the kids who had no training at all could go put it in.
We've kind of kept it as part of what we look at when we add features is like, does it increase the complexity and the debt in terms of cognitive burden on the person who's installing it, right? Because we can give you all of these options, but if you, the more options you add, the harder it becomes to actually use, right. So like your grandmother, it's pretty hard for them to pick up an iPhone these days and use it out of the box, right. It works out of the box, but if you ever went to settings and tried to configure everything, I think it's a little bit more complex than the initial system, right. So we've been pretty mindful about that.
It's like, how do you hide all of that complexity and make it so that the machines can do that, right? So I think we were talking about Descript, all the things that you can do with Descript. I mean, that's absolutely amazing to try to do that by hand would be nuts. Right.
And yet the computing power is available. It's abundantly available and all you got to do is harness it, right.
James: [00:15:51] Right.
Deep: [00:15:52] Awesome. So that's what we did is like let's harness the technology curve very aggressively. Because the way I look at it, purely from an energy efficiency perspective, CO2, the emissions, if you look at where we are, we are not, our CO2 levels and GHG is not rising linearly, it's rising exponentially, right. And so the only thing that I know of that we can actually use, the only other thing there is Moore's law, right. Like our computing power is the only other thing which is nonlinear that I know of in terms of technology. So we got to be very, very aggressive in making sure that we are always keeping ahead and keeping track where technology is.
Right. And making sure that we are very aggressive price points for computing.
James: [00:16:42] Totally . So since we just talked about plug and play, I also wanted to talk about small buildings. And so it sounds like you guys are, you started with small buildings and now you're progressing into, you know, bigger and bigger buildings as the company expands, but can you talk a little bit about the opportunity with small buildings?
I mean, I don't know a whole lot about it. I spent most of my career with, you know, big, big, big, big buildings and campuses. but the way I understand it is like, there's a huge opportunity for automation in smaller commercial buildings, medium sized commercial buildings across the country, across the world.
So what are you guys seeing there?
Deep: [00:17:20] You're right. I mean, 90% of the buildings are under 200,000 square feet, right? So there's a relatively large number of buildings in that stock. We have traditionally looked at the buildings, which are obviously much smaller, right? Because we can go in, as a retrofit, we are much easier to put in.
And what we're trying to do is make it more accessible so that people who didn't think that they had a cost effective solution. And out of those buildings, I mean, most of them don't have BMS. And the primary reason is because they're too complex and too expensive. Right. So we were really looking at these smaller buildings and saying, that's the sweet spot that we really want to address.
What we did find is that buildings under 10,000 square feet, which I thought would be the primary market to begin with, right. Those folks are not as concerned about actually having temperature control or about energy because the numbers are too small. But the sweet spot, I think is really somewhere between 20,000 square feet to about 200, 250,000 square feet beyond which I think controls are kind of accepted.
It is better. Right. But the sweet spot is really, can you go address that? And that's kind of an important, very important segment for us specifically now, given where we are with the COVID situation, right. And where the CDC and ASHRAE guidelines are right. So we are going back to a lot of not only our customers, but new customers, churches, schools, right, business manufacturing facilities, which are specifically working 24/7 as an example, right. Light manufacturing. We're going back to them and making sure that their workplaces are safer, even where we are. So specifically we introduced something called epidemic mode which implements the CDC and ASHRAE guidelines, right.
So that's a very important segment, spot on.
James: [00:19:06] Totally. And it sounds like, you know, before they might not have any, any automation at all, and you're going in and saying basically, Hey, this is an opportunity to start controlling, measuring, measuring your ventilation, right. And making sure that you have enough. Cool.
So before we get into epidemic mode, I do want to hit that next, but I think like your platform enables epidemic mode, because you're able to push sequence updates to controllers. And I think that's a huge differentiator, you know, compared to the old way to do controls.
So can you talk a little bit about why you did that and, how that works?
Deep: [00:19:43] Again, I do believe in the future this is what we will see, right. I mean, we take it for granted that your phone is going to keep updating. Yeah, right , and now you have the cars which keep updating. So, so why aren't your HVAC system?
Right. And so even day one, I mean, that's what we started with over the air firmware upgrades, and also, our central control unit, which actually runs the algorithms holistically for the building. So those, that keeps updating regularly. And in fact, It keeps updating both from the sequence of operations, but also on a daily basis, it actually gets updated in terms of the tuners, because we create a ML model. So we look at the weather and we look at the past history and we'll figure out what's going to be the optimum tune points, set points for making the building work. Right.
And these are not just temperature. We don't change temperatures, temperature set points, because I think. That's kind of-, I have another beef with this, right. I don't understand. I think it's, it's a Kluge to try to change set points, to get your controllers to do something different. Right. And it's primarily because I think that the controllers are locked in terms of the sequences that they have. So the only option normally available is like, how do you fool them into doing something different?
And, and that's really hard science, in my opinion, and a hats off to companies who are trying to fix that because every manufacturer, every deployment has a different understanding of what the controller should be doing anyway, right. So now you have lots of different variances that you really have to account for in your ML models, which is why I don't think machine learning and tweaking has truly taken off because every building is an exception.
Right. And ML only works if you can tune the model and if you can train the model. Right. So we decided that we want to standardize this. So the idea is that out of the box, I mean, we use like true software processes and test harnesses to make sure that it's not just the software, which is working, but the sequence of operations are doing what they should, right. So unless you have regression tested with the point of like continuous commissioning is to me, so weird. Right because I mean, that should be a given the fact that we have to go back and recommission buildings makes no sense at all.
James: [00:22:02] Right, right.
Deep: [00:22:03] It should work out of the box and this stuff should self-tune. I mean, that's the whole point. If we look at our apps, if you look at where the world is with, like, we actually have continuous integration and continuous deployment things, right. In terms of microservices and how we update the web as an example, right. None of those things have somehow carried over to this domain, right. But from my perspective where I came from, I mean, that was a given that things work. They always keep changing and you can push them out as sequences get better, technology gets better, our understanding gets better. You keep on pushing these updates out. And that's what we really did, over the air upgrades, as I said, not just for central unit, which is running Android, the gateway, but even for each of the edge devices themselves.
James: [00:22:48] Okay. So just so I'm, I'm learning here too. How does the-, so if you think about like a machine learning product that is tweaking set points, how does, how does your machine learning work differently than that?
Deep: [00:23:01] Right. The biggest difference is our machine learning is really looking at loads in the building. Okay, so it doesn't have to keep changing set points. What it does is it, we have a concept of what we call tuners. Tuners are things which can affect the functioning of an algorithm. As an example, we have a bias towards saying that, Hey, if you already have an ML model and you know that it's going to be sunny, then your load in the building is going to shift more.
Right. And it already knows that from the weather forecast model, But it doesn't actually-. So it's really saying that the load is shifting by 2:00 PM. The load is going to be 30% more in this part of the building. What it doesn't have to do is like the set points don't have to be changed because that's really a hint to the system that you're going to start putting more air before the set points have to be tweaked.
James: [00:23:54] Right.
Deep: [00:23:55] Right. The problem is that everyone's using proportional integral systems, right. And because you use using PI controls, what you're doing is you're trying to use the Delta T between the set point and the current temperature to try to fool the system to get it to do something else.
Whereas the true problem is really that you've got an increased load coming down. You should really be conditioning beforehand. There's no reason that you really need to be trying to tell the PI loop and fool it to do anything different, right? So I look at the PI loops and stuff. Those are really far more reactive, for course correction in tweaking, but if you already know that the load is going to be more in a part of the building, let's just open up the dampers predictably proactively, right? If it's going to be a cloudy day, then you really know that the loads going to be more uniform. It's occluded so that there's not going to be as much directionality to the load.
So that's one piece, right? You can use things like, even things like, when do you turn on for preconditioning, right? I mean, you already know that based on what the current temperatures are and where the outset temperatures are. And so, you know, what a cooling rate or your heating rate should be, and, you know, the Delta T and the temperature and set points. So don't change the set point. Let's just figure out the right way of doing it. Right?
James: [00:25:13] Yeah. And I've talked in the last couple of essays I've written about this, there's like, I think everyone that at least reads Nexus is like, okay, we agree that the existing BAS paradigm is broken. Right. Okay.
Now there's two solutions to that, in my opinion, there's the overlay, which I think we're describing the overlay. And then there's the, the, throw it out the window, build it from scratch approach, which I put you guys in that, throw it out the window, build it from scratch approach. And I think what we're highlighting here is like two major differences.
So I just want to kind of restate it to you cause I'm, I'm learning this out loud, but the overlay approach would say, okay, I have all these PID loops that are operating based off of set points. And the only thing I can do in my overlay is just start overriding set points. Right? Whereas what you're saying is no, actually we can, if we're building it from scratch, we can actually just take that PID loop sort of, not totally out of the equation, but we can start operating the system directly, essentially.
Yeah.
Deep: [00:26:13] And you're spot on. Right. And you do it holistically. I mean, that's the biggest difference that I look at is, the current BAS systems are the tail wagging the dog, right. It's like your PI loop is typically running in your room. And it's really controlling the VAV damper opening as an example. Right? So your communication back to your actual BAS is typically by duct static pressure, right?
No one is actually saying what should be happening in all the zones, which are being served by an AHU. You're not figuring out what the total load is. You don't know which part of the building really requires a load. All you're doing is you're using duct static pressure has some kind of a mechanism of figuring out. Yes, there is more required load in some part, right?
I think the closest we've come to is now with the, with GPC 36, the ASHRAE Standard Advanced Sequences for HVAC Operations. I mean, what they started doing is sending some feedback back in terms of trim and reset, trim and respond. And that's a mechanism that is in some ways, of course, PI loop mechanism, the requests are the equivalent of showing some load in the terminal units, right. But I mean, there are far more interactive, far more real time systems available that we've implemented. We also implement GPC 36, by the way. Right. Because some engineers really want the assurance. That is a very well-defined mechanism, which is well known. And so we implement GPC 36 and we we've committed to the fact that as GPC 36 evolves, we will keep updating our sequences. And more importantly, we do reference quality GPC 36. It's like using software techniques, crude test harness stuff, which does regression or not. And so we run it through the whole shebang.
So you don't really have to commission them. It works out of the box. Totally, right. But the key is that, I mean, from our perspective, GPC, that is the lowest level of, I think, current control solution that I would actually consider acceptable.
James: [00:28:19] Right, right. Well, I mean, let's just pause on GPC 36 real quick. So, ASHRAE is coming out with these new sequences, and ASHRAE saying these are the top sequences, right? So in the old controls paradigm, I just want to kind of lay this out for people that are new to this topic. The old control paradigm is that every single building that's been programmed in the past, right, now someone has to physically go there and say, okay, let's upgrade these new control sequences and basically program them by hand. And what you guys are saying is no, I mean, every building that's ever had 75F installed on it now can get these control sequences automatically just like the Tesla that everybody wants. Right. It's, it's getting control sequences essentially automatically pushed to them. So it's just like this huge upgrade for the whole industry, if all controls companies did it like that.
Cool. Alright. So one of those newer sequences, right, is, what you guys have kind of used to respond to the pandemic, which is epidemic mode. So first I want to kind of get your take as a leader in our industry, kind of where you see the industry being at right now. So it's, it's middle of July, 2020 if someone's listening to this five years from now. But we're kind of still in the middle of this pandemic. There could be a second wave. It does certainly seems like there's a second wave coming. So how are you feeling about the state of the buildings industry and the smart buildings industry specifically?
Deep: [00:29:51] It's a loaded question. I think there's going to be some winners and losers. I think the existing building stock is not going to be utilized the way it was before. I think this change that we're seeing of working from home at least partially is, is irreversible. We've kind of accepted it. So the two things which are going to be at looked at, as like building owners and we've talked to bunch of them, right? Real estate folks. Should be really worried and they are, right. Because I don't think the tenants at this point, we're laying it down to the second wave, but it's not just the second wave. I think this is going to be a longterm proposition.
The same thing with, with air travel. Right. We're doing it now as an immediate reaction, but I think even longterm, the acceptance of digital communication. It's just going to be so much higher. I don't think, believe that we're going to go back to that same way anytime soon. Definitely not in the five years that we were talking about, perhaps.
Right. But, so if that's the case, I mean, what you really want to do is like figure out, like, how do you make buildings safer? Right. I also think this is an opportunity to make buildings more adaptable because this is just one thing.
So the buildings that, as an example, that had the 75F system, it's seamless for them to get these updates, right. But it's not just us. I look at it as like, if you want to change, use the right technology so that you can keep on harnessing change, right. So that you can be adaptable, whether it's epidemic mode now, or it's a better energy-saving sequences later on.
So, what we are doing is we're going back to a lot of these buildings we talked about, the 20,000 square feet to 200,000 square feet, and saying, Hey folks, like, how can we actually help you make your buildings adaptable? How can we make them more healthier now? Right. And, and how at some point when we have a vaccine and things go back to normal and more people are coming back, can you actually go back and start using modes, which are more energy efficient?
Right, because there is obviously a cost associated with any of these modes that we're talking about, which are talking about enhanced ventilation as an example, to dilute the load, the viral load in a building. Right. And the flip side of which is, I think we're going to come out of this and people are going to say that it's not just the viral load, but it's also, there's going to be enhanced awareness in terms of the indoor air quality in general, right. We've been talking about it for a number of years, but I don't think we've actually truly taken steps towards that. So now we can come back and it's like, there's going to be more just overall awareness is going to be much higher in terms of IAQ and healthier buildings and being more adaptable and intelligent.
And that's one part of the message that the building owners that we're talking to understand that. Like, they want to say that, Hey, our building, our building stock is the healthier one, is what would they call it, a clean asset is how they look at it. It used to be the clean asset term was used primarily from an energy efficiency perspective, but now you're looking at it from a wellbeing as a healthy building standard, right.
James: [00:33:01] Okay, cool. Yeah, totally. So let's, let's nerd out on epidemic mode real quick. So, I've been putting in the newsletter each week, I've been kind of saying like, here's the the best articles I've seen on the pandemic so far, here's some good ones that if people are looking to keep up with it and what I haven't seen really at all, and I've been saying this, is like everyone's talking about more ventilation. No one's talking about the impact on the energy consumption.
And I watched your, your webcast from last week. So I learned a lot about it, but I want to hear like what, where you guys are coming from in terms of this epidemic mode. And again, it sounds like it's a control sequence that you're able to push out and let operators decide whether they want to turn it on or turn it off. But what does it actually do and what are the benefits of it?
Deep: [00:33:50] Right. So back to where the CDC and ASHRAE guidelines are, what they're recommending right now is that you run your systems 24/7, and you run them with increased amounts of outside air, right.
James: [00:34:02] Which as an energy engineer, I've been undoing that for my entire career. Right. So it was just like, Oh wait, wait, we've been undoing that for so long.
Deep: [00:34:12] I know it was like, let's put them on schedules, right. So, and there are reasons behind that in the primary, we talked with some of the folks on the task force, right, both on ASHRAE and on the CDC side. And the primary reason for that is that in some ways, if you think of a current building or a BAS system, you only have a concept of occupied or unoccupied. There is no concept of saying, Hey, let's have a pre purge or post purge, or alright, let's have an epidemic mode sequence right in there, right. So there is no state called epidemic over there. So. In terms of safety. What they've had to do is they've had to bring down the standards to the lowest common denominator.
And it is kind of an interesting thing. You go back, this thing is more rampant than just these, these current CDC guidelines. It's actually rampant in everything we do. It's rampant in ASHRAE 62.1, which is the IAQ piece, right. It's rampant in even GPC 36. If you look at GPC 36, the original predecessor to that RP 1455, when they were looking at it, they were looking at not just the best control sequences, they were looking at the best control sequences that could be implemented in a existing controller. And with people who were at the level of like a master system integrator, not at a rocket scientist kind of level, right. They were trying to figure out like, what can we push out which can actually practically get consumed?
James: [00:35:47] Got it. So that makes perfect sense. I never thought about it like that before.
Deep: [00:35:52] And those are the constraints of the folks who are making these recommendations because they have to go back and make sure that they apply to everyone. Because if they put in an advanced sequence that people can't comply with, then like, what do you do with that building? Do you throw it out? Do you shut down the building? Right.
So, so they've actually tried to simplify it, dumb it down and said, Hey, run the system 24/7. Run it at enhanced ventilation rate, as much as a hundred percent outside air, if possible, if not as much as you can, right?
Because there's no epidemic mode, because the system was not ready to run a hundred percent all the time, what you have to do is now figure out what is the amount of outside air it can do under extreme design days. Most of the days it perhaps has capacity, but on some days, if you try to get in that enhanced ventilation, the system cannot keep up, right. Because it's not adaptable. So that's kind of the way the recommendations were. And so that's the baseline that we took.
So it's interesting. We were actually doing a project with NREL as part of the IN2 program, right? So the Innovation Network 2 program, and they were specifically looking at the energy impact and savings of 75F across multiple climate zones and different building types, right. So when the pandemic came around, we looked at the literature. There was absolutely zero literature talking about what's going to be the potential impact of these recommendations that the CDC and ASHRAE are putting out.
So, we actually talked to NREL at that point. So, Grant -sp?-, who leading the project over there and decided, Hey, let's divert some of the resources that were going to look at normal operation and use them specifically for this epidemic mode.
And so we had a theory. The two things that we wanted to test out is A) from our perspective, you don't need the ventilation all the time. You really only need it when the building is occupied. Second, the other thing was that the reason that the CDC said you want to run it 24/7 is because the concept of a purge means that you can, you cleanse the building with a high amount of outside air for a short duration. And the ASHRAE sequences at some point talk about the purge creepers and the post-purges as well, right. But the CDC did not because they already had to bring it down to the lowest level.
So we actually tested these out and we did some pretty interesting experiments. So obviously, no one's detecting the COVID virus itself, but what we did is we did some experiments in which we use, you know, we, since we've already got volatile organic compound sensors built into the product, we actually use meth paint and alcohol as the two substitutes. And we use cotton balls dipped in alcohol. And when you took it out, figured out how long it would take for those cotton balls, the VOC levels to decline.
James: [00:38:40] Hmm. Okay.
Deep: [00:38:41] Alright. So in normal mode, in a normal AHU operating normally, and the average Hertz was about 50% of capacity. It took about two hours for the VOC levels to decline to baseline. When you raise that up to about 60%, 65%, it took about one hour. Now, when you raised it over to 80%, it only took 12 minutes.
James: [00:39:05] Oh, wow. Okay.
Deep: [00:39:07] The primary reason is, is because the air flow starts becoming turbulent, right? So your actual ability to extract and entrain the air and extract it is far more efficient, right? Which is what, in my opinion, like, no one's done these studies before, but we wanted to test it out and it's like, yes, so if you truly wanted to do this, what you want to do is you want to run the fan at high speed. You want to get a whole lot of outside air for a shorter period of time and get it all cleansed, right. So that's what we did.
We introduced this concept of a pre-purge and a post-purge. So it's prior to occupancy and after occupancy, and back to your point, you can turn them on and off as simple as just a slider on a phone. And the system automatically does that. But when you're doing these purges, at that point, you really don't want that the set points should be maintained. So it's not the same as saying, Hey, let's move my schedule earlier. Because if you try to maintain set points, then you have a very tight temperature debt when you're getting in a whole lot of outside air. And you're really going to be consuming a huge amount of energy to make that happen, right.
So what we said is it's going to be in setback, right? So it's going to be, the temperature bands are going to be way more relaxed. You get in this air. All you're doing is diluting the air inside and purging it out. And then when the purge is complete, then you tighten the temperatures back to set point and you also reduce the amount of outside air that you're getting so the system can maintain these temperatures.
James: [00:40:35] Right, got it. Okay. So what about during occupied mode?
Deep: [00:40:39] So that's unoccupied. So during occupied mode, you bring down-, you still get enhanced ventilation, but not a hundred percent, right. And that enhanced ventilation knob is tuneable. It's again using ML, but we normally set it as a 50% as a baseline, is what we set.
So back to the energy impact study with NREL. So that's the mode that we implemented and we asked NREL to actually go back and do this validation and the results are, are eyeopening I think in terms of the energy impact, as you might imagine, right. And, but just following the CDC guidelines is going to be somewhere between three to five times, in some cases, in some climate zones, three to five times of what your baseline energy is.
James: [00:41:24] And is that total building energy or just HVAC?
Deep: [00:41:27] Just the HVAC piece.
James: [00:41:29] Yeah, right. Okay. So they basically ran three-, the way I understand it, three OpenStudio models : one with normal operation, one with the CDC guidelines, and then one with epidemic mode. And what were the average savings for the epidemic mode from the CDC?
Deep: [00:41:45] Right. We actually ran it in four. So we ran a normal mode, we ran it in CDC guidelines, and then we ran epidemic mode, and we also have in within epidemic-, remember that we have occupancy sensors. Right? So we have a concept that was just something that we're seeing that many of our customers are not getting in all the teams, all the employees in on the same day. So if you have staggered days of occupancy using the occupancy sensors, it saves a fair amount of energy as well, because you're only trying to condition those parts of the building which are going to be occupied. So, so when they ran that, what we found is that the CDC-, on average, the CDC guidelines are end up about three extra, 2.5 to three times over the baseline energy usage for the HVAC.
The epidemic mode in an office scenario was about 30% over the normal mode, right? The, which is about 50% savings over the CDC guidelines, which is significant, since now the top line is so large. And if you actually use the epidemic mode with the staggered occupancy, we were only about 15% higher than the baseline, which is like exceptionally nominal.
So back to your point, the point I was making is that if your buildings are adaptable, now you can make them healthy without necessarily incurring a huge cost as well.
James: [00:43:07] Totally. And what are your customers saying about epidemic mode? What are you hearing from them? What kind of problems is it solving for them?
Deep: [00:43:15] It's solving some problems. It's also highlighting some problems, which I had not anticipated by the way. So it's solving the problem that obviously you end up-, we give this nice decal, a sticker because one of the key things is many of the things that we're doing-, we don't know everything about the, about COVID-19 right ,or the coronavirus. What people are looking for is visible, they're looking for visible signs that you care, right? So one part of it is like we made these large decals, which let people know that the air in this building is being purged. Right? So from a confidence perspective, I think it's been absolutely fantastic for employees and customers.
And especially some of our retail customers have adopted this. And when their people come in to buy into that store, they now know that the building is safer. Right. So they've actually seen, it's a big differentiator. Back to the point of like, even from a marketing perspective, like which store would you want to go to, the healthy store or the not so healthy store?
James: [00:44:14] Yeah.
Deep: [00:44:15] Right, so they've seen those kinds of responses. One of the things that we found out that we didn't necessarily expect is that we keep talking about how bad people maintain equipment sometimes. Right. We found out, I mean, the economizers obviously are notorious, and we had obviously tracked this in terms of like, is the economizing working or not based on mixed air temperatures with our piece, what we found was pressure problems.
We hadn't done as much economizing at such scale. Right. All the time. Right. So a huge amount of positive and negative pressure differences started popping up in many places where you ran all the systems at a hundred percent outside air, as an example, during purge cycles.
James: [00:45:02] Got it. Right.
Deep: [00:45:04] And it's an interesting thing.
I mean, we keep thinking that for the first time you start recognizing why you need variable capacity fans on the return side as well.
James: [00:45:14] Absolutely. That's something to watch out for. And this is where all of our commissioning agents, shout out to all them, this is where we, we don't really need them to be tuning sequences, but we do need them to go figure out these issues and that are popping up.
Deep: [00:45:28] That's true, yeah.
James: [00:45:30] Cool. So, there's a couple other issues I think that I'm seeing as you start to increase ventilation, it seems like there's going to start to be, and you touched on this a little bit, but equipment capacity issues. Right. So if someone's out there just opening ventilation dampers a hundred percent, not just pressure, but also like chillers can't keep up. Chilled water coils can't, can't keep up. When we get around into the winter, there's going to be a lot of preheat coils that can't keep up, those types of things. So I feel like these dynamic sequences can help find that edge. Right. A lot better.
And then with humidity. So we're in the middle of July and the United States, maybe not in Minnesota where you're at, but, well, it actually gets pretty humid there in the summer, but, managing humidity as well, I feel like it's super important. Right.
Deep: [00:46:16] Right. And that was actually, that's something that got highlighted in the simulations that came up from NREL as well.
So it looked at two other aspects in addition to the energy piece, It's like how well is the temperature being regulated? And that, I think back to your point, that like, we actually had to turn down the amount of outside air which is coming in terms of the CDC models, because they're running 24/7, right. And it gets really, really cold in some of those places. So like extreme Minnesota winter was a pretty decent example, that the building temperatures were dropping and the system was not able to keep up. Right. So, so that's something definitely worth keeping in mind and ditto with humidity as well, specifically with the outside air coming in consistently, it just in Houston 2A was strapped like during a design day, the humidity was almost 70% inside the building, which is, which is getting out there.
James: [00:47:11] Yeah, definitely. Okay, well, cool. I mean, I'm super excited. I was pumped up watching the webcast about this, so I'm excited to see where that goes. And I hope people start copying off of you, frankly, because, because I think it's, this is a needed upgrade to control sequences.
Deep: [00:47:30] I think that's a good point, James. I mean, when we did this, even when we talked with NREL, yes, we had our funding, but that's why we wanted to share it with everyone is that these are the results and these are the sequences. So we are actually super crystal clear. So even if anyone else is ever looking for like our sequence of operations, what we've implemented by all means, I mean, we are making these public.
I think if a medical, a vaccine makers can collaborate, I think HVAC companies can collaborate as well.
James: [00:48:01] Exactly. I love it. So let's, let's kind of pivot back to the product itself. So, you know, you and I have talked a couple of times, so I feel like I understand the product pretty well. But let's, let's kinda start with software.
You guys again, had the chance to just throw the existing automation, you know, front end paradigm is totally out the window. So how have you, like what makes a good software layer and how have you guys approached creating that, in the, in the product?
Deep: [00:48:29] I'm glad you're talking about it now than maybe two years earlier because our understanding has evolved as well, right? So when we started, we were really looking at a small as a product, right. But about two years ago, as we decided that we were going to go scale the technology up, we actually made it so that it is exceptionally modular in a true platform, right? So we actually, one of the key things that we did is-, it's kind of weird, I keep dissing standards like BACnet, but on the other hand, I'm really gung ho on places like Haystack. And I know you were talking in the last episode on BACnet, 223, right, ASHRAE 223 and, and Haystack. So we have made everything within our product layer now in the software stack as 100% Haystack compliant.
So all our apps, all our portals are actually running reference implementations of Haystack apps. They ended up using the same API that we would actually expose to our customers, right? So I'm a big fan of interoperability, as I said, not necessarily at lower layer level, but at the right scale. And to me, I think Haystack is probably the first place where we've actually started getting some standardization around that piece, right. So, and especially when Haystack 4, gets completely flushed out or, or whatever ASHRAE comes out with on the 223 Committee, I think that's going to be exceptionally important.
So when we designed it, we made it super modular now. And so it's completely originally, it was just cloud hosted, but now we call it completely because some of our customers want it hosted in their own private data centers on, we have some countries which have restrictions in terms of the data should be stored locally. So we call it a hybrid public-private cloud. So it's completely containerized and dockerized so you can actually deploy it with what's called CICD continuous integration, continuous deployment. So it's, it is as good an architecture from a software perspective as can be, right. And that's because we decided to rearchitect it, as I said recently.
And now it's to the point that, I mean, we really look at like how are smart cities going to scale on a platform like this because we have some partnerships as an example with Singapore Power, they're the world's largest district cooling utility. But what they're doing is they're going and replicating the entire package of how to do district cooling to other countries and other districts, not just Singapore. Right? So they're selling it as a service. And so we are the technology stack on the building automation side for that. Right? So whenever there's a new smart city or a smart district, which is going to use Singapore Power they're all going to be using 75F technology.
So we decided to go back and make sure that the technology would scale to those levels. Because as we go in the future, I mean the whole concept with this distributed energy resources, as solar and wind become more prevalent, it's no longer going to be the case that the grid is going to scale up to the load; the load is going to have to adapt to the grid, right? So if that's the case then we really need bi-directional data models, which allow massively parallel computing in terms of machine learning, et cetera. And so that was the whole genesis behind making sure that we had semantic model in addition to just storing the data, right. So, so Haystack really fulfilled that.
James: [00:51:52] Totally. And anyone who's listened to the last episode knows that this is a different perspective for someone that's in the building automation world to design their product with Haystack natively, basically is what I'm hearing. So what makes-, why did you do that when you're a controls company, and why do other controls companies not build like that?
Deep: [00:52:16] It's like their legacy, right? I mean, if you already have a database, I guess you don't really care. But I mean, to me, it makes a lot of sense. I know you come from the energy auditing piece as well. Right? So you probably use SkySpark, but it's kind of weird to actually connect SkySpark to a building, which has BACnet and then manually map all the data over, right. And I mean, it is a huge amount of work and it's like, it boggles me. It befuddles me, why others won't do it natively, but I can only think it's because of legacy. That's how it's always been, right.
But we decided to do it natively out of the box, everything, even our algorithms, when we did RP 1455, GPC 36, it's kind of weird. We don't even look at current temperature. We look at points. So we actually make a call to say the Haystack tags, which would actually allow you to save point his current zone. Right. So it's really a call every time we use-, there's no variable names in all of our algorithms. So we are like hardcore.
James: [00:53:18] Truly native Haystack. That's amazing
Deep: [00:53:21] Truly native Haystack. I mean, if you look at our analytics, our widgets, which go and display all of the data, every one of them is a true Haystack point.
James: [00:53:30] Wow. Yeah. I'm sure Brian Frank and the guys that started that are pumped about that. So, cool. So a couple of different questions about the software: first is, you know, you mentioned SkySpark, for instance. Are you guys in your front end, I guess, to use it an analogous term to a traditional building automation system, are you guys adding in analytical capabilities, like fault detection, diagnostics and that type of thing? And how are you thinking about that?
Deep: [00:53:59] Absolutely. So, I mean, all the analytics are built in. The slight difference, I think versus SkySpark is the SkySpark allows those rules to be set or sparks, which gets right. And they're highly customizable. We've tried to do that out of the box. Right? I think we have the luxury in our case that we already know what those FDD pieces are going to be.
So like with GPC 36, of course they have their own concept of what the FDD should be. And that's already built into that product. And. What's kind of cool is that every one of the-, again, back, I go giddy over this so kudos to Brian, as you said, and gang, but I mean, even all our analytics and FDDs are all making Haystack calls, right?
So it becomes, that allows you to scale, right that allows you to specifically, if you have equipment which has been replicated. Right. You don't have to do that for each and every point; now you just have to do it for the tags that match that value. And I mean, that to me is, is the true value.
Like if you go shoe shopping or if you go to best buy, we use tags all the time, right? You go search for TV. Then you go search for 40 to 50 inch. You're searching for a price point between $400 to $700. And if you look at what, if you go to their site, that's what they do. They really put those tags right at the top as a filter map, filtering mechanism. Right? And to me, it's the beauty of what Haystack has really done.
And we really took it to heart as like, go all the way in and make sure that every algorithm, every FDD, even our customized code sequences, we call it Iott. Like if this, then that logic uses the same concept. It's like, if these tags are this value, then do this command.
James: [00:55:48] Got it. So how do you guys deal with-, you mentioned sort of waiting on Haystack 4. How do you guys deal with those sort of limitations to the data model as it exists today?
Deep: [00:55:58] Yeah, I think we've made our own customized extensions for the time being right. I think the primary shortcoming that we found was that in the reference model that it always goes and references one site or one equip and it's not bi-directional. So, so those are some of the limitations that we have in Haystack 3.
So we added more references, which are 75F custom, or just the tags, but more references to like floor or zone, which are constructs, which are not as well defined in Haystack 3 in terms of the reference models.
James: [00:56:30] Got it. Yeah. And I'm assuming you can, whenever the standard gets updated, you guys can just update your model and push updates out.
Deep: [00:56:37] Yeah. That's that's the plan.
James: [00:56:39] Cool. Okay. You mentioned the platform aspect of it too. So I'm thinking there's a thousand different acronyms, but if you think about all the end uses in the building, they have the, digital twin platforms coming out where you're pulling in HVAC and lighting and access control and elevators and everything down the line.
So how are you guys viewing how 75 F connects with those types of platforms or are you viewing 75 F as that type of platform? Or is it both?
Deep: [00:57:09] I think it's the last it's it's both, right. Okay. So obviously we're talking about much larger buildings, right? Class A buildings, so some folks have already implemented, what we call a true building intelligence system or IBS as sometimes they call it. Right. So for those folks, I mean, we would feed, be the authoritative reference source for the HVAC lighting and space management. So those are, that's how we look at it. Those are the three key parameters that we look at. We do good on lighting on the HVAC side and also space management, figuring out which parts are being utilized.
For folks who are looking for other data sources to come in. I mean, we welcome it. I mean, we have a very scalable database model, whether it's just for a building or even for OEMs. Right? So the whole piece was that we were originally quite monolithic in terms of a tech stack, but we just launched this in April. Now it's the new renatus version, we call it and with Athena as our cloud, but it's highly modular, which is what allows the public private deployments. It also allows for us to work with OEMs who perhaps want just the ML layer or they want the database layer, right. Or they want just, if you want GPC 36, right? If you, if there's OEMs out there who don't want to run their own version of GPC 36, all they really care about is if they're Haystack compliant, well you can just take our algorithms and put it on there. Right.
Well idea was that it's not just GPC 36. We want to do the converse as well. If someone's come up with a better way of doing GPC 36 or their own custom way of sequences, right? It's a hundred percent compliant Haystack layer underneath on the hardware side. All you got to do is write an algorithm which uses Haystack, right. It's as easy as that.
James: [00:59:04] Yeah. So do I hear you correctly that those three verticals, HVAC, lighting space management, are you guys planning on expanding beyond that? Or could you pull in data from other verticals or is that kind of where you're headed? You don't have to tell me this, by the way, this is roadmap stuff.
Deep: [00:59:22] It's not; it's public roadmap stuff. We're definitely putting in data from other places as well.
James: [00:59:27] Right. Okay.
Deep: [00:59:28] So the whole point is all about API level integration. The sky's the limit in terms of what we can do over there.
James: [00:59:35] Okay. And would that include like other legacy BAS, or are you pulling in other hardware to pull into the platform?
Deep: [00:59:44] We will be soon. We have not, we've got some orders, customer deployments where we, are going to be doing that.
What we're really doing is we using a BACnet to Haystack data pump. Right, because that's already commercially available. So rather than us trying to reinvent that whole piece about-, so we are just, you know, I keep dissing BACnet, but I mean, we are BACnet compliant, so we have BACnet server. Right. And we've implemented it just because of the interruption. If you are in a larger building and you already have a, BAS, which is BACnet. I mean, there's no reason that we should be excluded from that. Right? So specifically we go into like a large building, which a tenant might actually want to put us in.
So you can go put it in for that one tenant. And then you just expose ourselves using the BACnet interface to the rest of the building.
James: [01:00:33] Okay.
Deep: [01:00:33] Right. So that's a, that's a possibility what we have not done is include direct BACnet client functionality. So taking in legacy hardware and trying to integrate it back, because to me that's a lot of work it's manual. It goes against the ethos of like trying to make this out of the box.
James: [01:00:53] Yeah. So I think what I'm hearing is if say a client has 12 different types of BAS across their portfolio, but then they decide, Hey, in the 75 F building we have over here, we really like their software layer. I mean, most traditional building automation system, software layer is poor as talked about, and I've talked about endlessly over the last few months. but what if they say, okay, we really like 75F software and we want to deploy that across all of our whole portfolio without replacing all the hardware underneath and all the other buildings.
And they want to do things like standardize their schedules, standardize their set point, standardized their sequences. Is that a direction you guys are headed and can you do that today?
Deep: [01:01:36] We can't do it natively, but we can with the data pump, right? So on BACnet. So you would have a BACnet to Haystack converter, which would allow that first layer of mapping. And then we would talk Haystack API to API, to the data pump.
James: [01:01:52] To the data pump. Okay. And so you could send overrides in whatever you wanted to do.
Deep: [01:01:57] Exactly. Yep.
James: [01:01:58] Okay. Alright, well, we've got about, I don't know, a couple of minutes left here, so I want to ask about services. So how are you guys like going to market today? And specifically I'm wondering, the BAS service contract is something that I kind of wanted to dig into next for Nexus. And so it's kind of on my mind, and I wonder, how you guys are thinking about servicing your hardware and software in a new way.
Deep: [01:02:25] That's an interesting, I mean, that's part of the whole innovation, So two things that we do is we work with existing control guys, or even mechanical contractors to go service their existing customers. We also do work directly with large enterprise customers ourselves directly as well, right? So, but general preferences, if it's one offs, then we would actually go use the same existing service relationship that they have with their service contractor. I mean, we are not here to try to disrupt that piece.
What's kind of interesting is because of the fact that we are all IoT and we have our own NOC for monitoring all of our deployments, what we do is we allow the white labeling of the monitoring service and that's kind of interesting thing, right? So if you're a smaller shop and you don't have a full NOC, right. You could actually basically take our, get managed services from us, but put it under your own umbrella.
So you would end up getting the mechanical contractor or the service contractor would actually end up saying here's the service contract to their own customer, but we would be providing it, servicing it in the backend. Right. And what's kind of interesting with that is because we have so much data coming in, I mean, we can actually dive back directly and send out service tickets as well to dispatch mechanical guys if needed. So it's an interesting piece in terms of the managed services part, what this allows us to do so that you can be far more proactive, right. Because the NOC is running all the time.
James: [01:03:55] Wow.
Deep: [01:03:55] So it's truly a network operating center, which is like looking at all the buildings, looking at all the data and all the loads which are coming in.
James: [01:04:04] Okay, cool.
Deep: [01:04:06] Also some of our customers, like in some places it's mandatory to have a engineer onboard 24/7 for some critical facilities, right. But they petition cities and counties to get waivers without getting the specific customers that the engineer only needs to be there during the day shift. And during the evening and the night shift, it actually gets pushed over to the NOC.
So we provide the managing and the observation of making sure that the building, the critical facility is running correctly. And in case someone needs to dispatch, we can do that proactively.
James: [01:04:38] Okay, cool.
Deep: [01:04:40] But one of the things that we've had a fair amount of success with is, is OEMs of equipment.
Okay. Right. So you have the big guys, you have the Carriers, and you have the Tranes, and JCI who have their own controls. But you also have a large number of people who are making HVAC equipment, but who don't necessarily have their own controls line. And for those, I mean, we have really started becoming an OEM out of the box because now it's a huge differentiator, right?
No longer do you actually have to rely on someone else to do that system integration because it's now working out of the box. And so as a packaged solution especially for these midsize buildings that you're talking about under 200,000 square feet. I mean, it's a huge differentiator.
James: [01:05:24] Totally. What would be an example of a piece of equipment that, you know, you could then just, it comes natively with a 75 F controller,
Deep: [01:05:33] Dual cool, swamp coolers, things like AHUs, a lot of customized AHU folks out there, right? Small RTU guys. So we don't do the equipment control, but we provide the building control aspect of it. Right. So we wouldn't necessarily go in and replace an RTU controller itself, but we would go and interact with that RTU controller and make sure that they have, they basically are making it IoT enabled.
James: [01:06:00] Okay. So a smaller building that only has, you know, five RTUs, and then you'd throw a 75F building controller. And now all of a sudden it has all the intelligence that-.
Deep: [01:06:10] Yeah.
James: [01:06:11] Okay, cool. I love that. Alright. So the only thing we didn't hit was on the hardware layer. So I got a couple more minutes as long as you do.
So like what makes a good hardware layer since you guys-, the same kind of question as earlier, you guys designing it from scratch, how did you approach that?
Deep: [01:06:31] Biggest thing was like, I mean, all digital. Right. It's like no sensor is analog. So you're always look for sensors, which are, I mean, it starts truly with the sensors. Right? You want to make sure that you get sensors, that don't require calibration, that don't drift. Right. And so if you start with that technology, I mean, then you're assured that it cuts down not only your calibration in the factory, but also in the field. Cause that's super expensive stuff. Right, right.
And so the second thing that we took on is that like, In my aspect was that, I mean, throwing all the functionality that you think you'll ever need into the hardware right upfront, right. Don't chance on it, don't say, Hey, can I save this? I don't know the small module. And like, we've got BLE, IR blasters so much other stuff, which is like this out there.
And we keep adding new services because it's software upgradable. Right. So let's go in all of this stuff, even if we don't think that we're going to be. We know what, what we're going to do with it right now. So
James: [01:07:35] Sensors too, right?
Deep: [01:07:37] Absolutely different, different sensors as well. So, and so now we started like in the new generation of hardware, we've actually started throwing in dedicated CO2 sensors as well.
Right. So it's not just derived, but it's like, I mean, those are used to be damn expensive, but I mean, you're saying that it's not even optional. It's like there is part of the product, every zone, every room. Which brings me back, like originally alluded to where 62.1 was. If you go back to where we thought the ventilation rates were, it's purely based on bio fluence from human beings, right back in the mid nineties when there was no sensing technology around that. So I do believe that at some point we can show ASHRAE data that with intelligent sensing, you perhaps don't need fixed ventilation anymore, as an example.
Yeah. So the hardware layer, in my opinion, is it needs to have all the sensing, all, all the functionality built in. And the second piece that really needs to do is it needs to, you want to have a consistent platform.
You want to have the same hardware rather than having application specific stuff. In my opinion, that brings down your cost because you're doing volumes. It allows for more reliability because it's the same product. You're not saying, is CO2 sensor optional. Now, is this going to be for a water source heat pump or is this going to feed before a heat pump, right? Or is this a fan coil unit, right? I mean, I think it changes the supply chain game dramatically, and I think in 2020, that's where we should be.
James: [01:09:08] Got it. Cool. Well, thanks for this conversation. I learned a ton, so thanks for, thanks for coming on the show.
Deep: [01:09:16] Thank you so much for having this. I'm glad you're doing what you're doing in general. It's always nice to listen. And so I'm looking forward to the next, next episode as well as you said.
James: [01:09:26] Awesome. Well, we'll talk soon.
Deep: [01:09:28] Sounds good. Take care. Thanks.
James: [01:09:30] 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 Deepinder Singh, CEO of 75F. 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
Disclaimer: James is a researcher at the National Renewable Energy Laboratory (NREL). All opinions expressed via Nexus emails, podcasts, or the website belong solely to James. No resources from NREL are used to support Nexus. NREL does not endorse or support any aspect of Nexus.
I walked away from this conversation even more excited about 75F than I already was. As I’ve said before, 75F and Passive Logic are the only two companies I know of who are doing the “blank sheet of paper” approach to fixing controls. I haven’t compared pricing apples to apples, but strategically, I think every new building and retrofit project should be using the blank sheet of paper approach. Since PassiveLogic isn’t on the market quite yet, I think every building being built today should be using 75F’s controls. Disagree with me? Let’s hear your argument in the comments!
Like Passive Logic, it seems like 75F intends to take an overlay approach if a BAS already exists in an existing building. I say “seems like” because I'm not quite sure we were on the same page here. Definitely a follow-up item for Deep/75F, or maybe Dave can answer in the comments! Can 75F be an open supervisory layer for multiple BASs across a portfolio? Seems like the answer is yes, with a BACnet->Haystack data pump, but someone needs to perform that tagging of the legacy BASs. So it's not plug and play, but it would work.
Finally, I really enjoyed the part of this episode about over the air control sequences. It was a wow moment when Deep talked about how controls standards (like ASHRAE Guideline 36) are brought down to the lower common denominator. So when ASHRAE/CDC made recommendations for COVID, they had to do the same, and that’s what led to the “100% ventilation 24/7" recommendation. Luckily, everyone can follow 75F’s lead and copy their epidemic mode approach. Deep would love that and so would I. Here’s how:
[00:10:00]
Today it's inconceivable to not walk into a mall and you want to buy an iPhone in three minutes. Of course, you can't walk into malls these days without wearing a face mask, but that's a different story, right? But if it ever takes you five minutes, you're probably screaming bloody murder. It's like, ah, this thing is not right. But it's kind of weird in the controls industry, we still accept that, that system integration, taking the product from Schneider and then taking another sensor from ECI and then tying them together through custom code is acceptable, right. And, and that to me is kind of weird. It's part of it.
Yes, standards exist for interoperability, but they also make it harder, that nothing works out of the box, right. And if you look at it, I mean the standards, I believe don't necessarily need to exist at a device level. Really, if you want to have-, these days, I mean, the system should work out of the box. I mean, you don't really care what standard your iPhone camera uses to communicate with the rest of the processor. What you do care about is about the base level of functionality and like, how does it interact? Like is the file system, which is supported, is the photo a JPEG or PNG, which can be exported out of the unit, right. So if we accept that kind of modularity, I mean, if we accept that that is a black box, then that really allows us, things to be more efficient. Not everything needs to be interoperable at every stage is how I look at it. Right.
So our take was that, alright, let's make sure that, instead of saying that the humidity sensor itself needs to talk BACnet and go right to a controller, let's make sure that the humidity sensor and the temperature sensor and the organic compounds and the CO2 to sensors, let's not even make them optional. Right? Let's put in all of these sensors out of the box. Because the hardware has grown, in all honesty, it will be super reliable and cheap, right. We end up using the same sensors. When I started originally on the, on the residential side, I mean, we use the Fluke temperature sensors were about $350. To get a reference quality Fluke sensor. We have the same sensor in every one of our rooms now. Wow, right. So overall, if you look at just how, and it's part of the mobile revolution, right? I'm not taking credit for it. What I'm saying is that, I mean, the consumer electronics have really driven, the mobile revolution has driven such good standards in terms of sensors and overall technology that what we really need to do is keep pace, take advantage of that.
And that's what we're doing. We're packing all of these sensors, packing in all of this functionality out of the box, right. And the second piece that we wanted to do is we wanted to have that instead of having a dedicated application-specific controller, if you have one controller that takes on different personalities, depending on what equipment you connected to. So it's kind of like your iPhone is one box. It's got all the sensors, got all that functionality baked in depending on what app you're using. You end up having a different profile, right. Because the value is in not necessarily going and integrating and putting these things in one at a time. So it's not unique in terms of what the industry is doing in the consumer side, right. We accept this in our phones. We accept this in our cars. We've just not somehow got it in our HVAC and our buildings yet. Right. We look at it as a totally different scenario. Nobody talks about like hey is my car talking BACnet.
[00:17:57]
Deep: What we did find is that buildings under 10,000 square feet, which I thought would be the primary market to begin with, right. Those folks are not as concerned about actually having temperature control or about energy because the numbers are too small. But the sweet spot, I think is really somewhere between 20,000 square feet to about 200, 250,000 square feet beyond which I think controls are kind of accepted.
It is better. Right. But the sweet spot is really, can you go address that? And that's kind of an important, very important segment for us specifically now, given where we are with the COVID situation, right. And where the CDC and ASHRAE guidelines are right. So we are going back to a lot of not only our customers, but new customers, churches, schools, right, business manufacturing facilities, which are specifically working 24/7 as an example, right. Light manufacturing. We're going back to them and making sure that their workplaces are safer, even where we are. So specifically we introduced something called epidemic mode which implements the CDC and ASHRAE guidelines, right. So that's a very important segment, spot on.
James: Totally. And it sounds like, you know, before they might not have any, any automation at all, and you're going in and saying basically, Hey, this is an opportunity to start controlling, measuring, measuring your ventilation, right. And making sure that you have enough. Cool. So before we get into epidemic mode, I do want to hit that next, but I think like your platform enables epidemic mode, because you're able to push sequence updates to controllers. And I think that's a huge differentiator, you know, compared to the old way to do controls. So can you talk a little bit about why you did that and, how that works?
Deep: Again, I do believe in the future this is what we will see, right. I mean, we take it for granted that your phone is going to keep updating. Yeah, right , and now you have the cars which keep updating. So, so why aren't your HVAC system?
Right. And so even day one, I mean, that's what we started with over the air firmware upgrades, and also, our central control unit, which actually runs the algorithms holistically for the building. So those, that keeps updating regularly. And in fact, It keeps updating both from the sequence of operations, but also on a daily basis, it actually gets updated in terms of the tuners, because we create a ML model. So we look at the weather and we look at the past history and we'll figure out what's going to be the optimum tune points, set points for making the building work. Right.
And these are not just temperature. We don't change temperatures, temperature set points, because I think. That's kind of-, I have another beef with this, right. I don't understand. I think it's, it's a Kluge to try to change set points, to get your controllers to do something different. Right. And it's primarily because I think that the controllers are locked in terms of the sequences that they have. So the only option normally available is like, how do you fool them into doing something different?
And, and that's really hard science, in my opinion, and a hats off to companies who are trying to fix that because every manufacturer, every deployment has a different understanding of what the controller should be doing anyway, right. So now you have lots of different variances that you really have to account for in your ML models, which is why I don't think machine learning and tweaking has truly taken off because every building is an exception.
Right. And ML only works if you can tune the model and if you can train the model. So we decided that we want to standardize this. So the idea is that out of the box, I mean, we use like true software processes and test harnesses to make sure that it's not just the software, which is working, but the sequence of operations are doing what they should, right. So unless you have regression tested with the point of like continuous commissioning is to me, so weird. Right because I mean, that should be a given the fact that we have to go back and recommission buildings makes no sense at all.
It should work out of the box and this stuff should self-tune. I mean, that's the whole point. If we look at our apps, if you look at where the world is with, like, we actually have continuous integration and continuous deployment things, right. In terms of microservices and how we update the web as an example, right. None of those things have somehow carried over to this domain, right. But from my perspective where I came from, I mean, that was a given that things work. They always keep changing and you can push them out as sequences get better, technology gets better, our understanding gets better. You keep on pushing these updates out. And that's what we really did, over the air upgrades, as I said, not just for central unit, which is running Android, the gateway, but even for each of the edge devices themselves.
…
The biggest difference is our machine learning is really looking at loads in the building. Okay, so it doesn't have to keep changing set points. What it does is it, we have a concept of what we call tuners. Tuners are things which can affect the functioning of an algorithm. As an example, we have a bias towards saying that, Hey, if you already have an ML model and you know that it's going to be sunny, then your load in the building is going to shift more.
And it already knows that from the weather forecast model, But it doesn't actually-. So it's really saying that the load is shifting by 2:00 PM. The load is going to be 30% more in this part of the building. What it doesn't have to do is like the set points don't have to be changed because that's really a hint to the system that you're going to start putting more air before the set points have to be tweaked.
The problem is that everyone's using proportional integral systems, right. And because you use using PI controls, what you're doing is you're trying to use the Delta T between the set point and the current temperature to try to fool the system to get it to do something else.
Whereas the true problem is really that you've got an increased load coming down. You should really be conditioning beforehand. There's no reason that you really need to be trying to tell the PI loop and fool it to do anything different, right? So I look at the PI loops and stuff. Those are really far more reactive, for course correction in tweaking, but if you already know that the load is going to be more in a part of the building, let's just open up the dampers predictably proactively, right? If it's going to be a cloudy day, then you really know that the loads going to be more uniform. It's occluded so that there's not going to be as much directionality to the load.
So that's one piece, right? You can use things like, even things like, when do you turn on for preconditioning, right? I mean, you already know that based on what the current temperatures are and where the outset temperatures are. And so, you know, what a cooling rate or your heating rate should be, and, you know, the Delta T and the temperature and set points. So don't change the set point. Let's just figure out the right way of doing it.
[00:26:20]
The current BAS systems are the tail wagging the dog, right. It's like your PI loop is typically running in your room. And it's really controlling the VAV damper opening as an example. Right? So your communication back to your actual BAS is typically by duct static pressure, right?
No one is actually saying what should be happening in all the zones, which are being served by an AHU. You're not figuring out what the total load is. You don't know which part of the building really requires a load. All you're doing is you're using duct static pressure has some kind of a mechanism of figuring out. Yes, there is more required load in some part, right?
I think the closest we've come to is now with the, with GPC 36, the ASHRAE Standard Advanced Sequences for HVAC Operations. I mean, what they started doing is sending some feedback back in terms of trim and reset, trim and respond. And that's a mechanism that is in some ways, of course, PI loop mechanism, the requests are the equivalent of showing some load in the terminal units, right. But I mean, there are far more interactive, far more real time systems available that we've implemented. We also implement GPC 36, by the way. Right. Because some engineers really want the assurance. That is a very well-defined mechanism, which is well known. And so we implement GPC 36 and we we've committed to the fact that as GPC 36 evolves, we will keep updating our sequences. And more importantly, we do reference quality GPC 36. It's like using software techniques, crude test harness stuff, which does regression or not. And so we run it through the whole shebang.
So you don't really have to commission them. It works out of the box. Totally, right. But the key is that, I mean, from our perspective, GPC, that is the lowest level of, I think, current control solution that I would actually consider acceptable.
[00:37:39]
Deep: So we had a theory. The two things that we wanted to test out is A) from our perspective, you don't need the ventilation all the time. You really only need it when the building is occupied. Second, the other thing was that the reason that the CDC said you want to run it 24/7 is because the concept of a purge means that you can, you cleanse the building with a high amount of outside air for a short duration. And the ASHRAE sequences at some point talk about the purge creepers and the post-purges as well, right. But the CDC did not because they already had to bring it down to the lowest level.
So we actually tested these out and we did some pretty interesting experiments. So obviously, no one's detecting the COVID virus itself, but what we did is we did some experiments in which we use, you know, we, since we've already got volatile organic compound sensors built into the product, we actually use meth paint and alcohol as the two substitutes. And we use cotton balls dipped in alcohol. And when you took it out, figured out how long it would take for those cotton balls, the VOC levels to decline.
So in normal mode, in a normal AHU operating normally, and the average Hertz was about 50% of capacity. It took about two hours for the VOC levels to decline to baseline. When you raise that up to about 60%, 65%, it took about one hour. Now, when you raised it over to 80%, it only took 12 minutes. The primary reason is, is because the air flow starts becoming turbulent, right? So your actual ability to extract and entrain the air and extract it is far more efficient, right? Which is what, in my opinion, like, no one's done these studies before, but we wanted to test it out and it's like, yes, so if you truly wanted to do this, what you want to do is you want to run the fan at high speed. You want to get a whole lot of outside air for a shorter period of time and get it all cleansed, right. So that's what we did.
We introduced this concept of a pre-purge and a post-purge. So it's prior to occupancy and after occupancy, and back to your point, you can turn them on and off as simple as just a slider on a phone. And the system automatically does that. But when you're doing these purges, at that point, you really don't want that the set points should be maintained. So it's not the same as saying, Hey, let's move my schedule earlier. Because if you try to maintain set points, then you have a very tight temperature debt when you're getting in a whole lot of outside air. And you're really going to be consuming a huge amount of energy to make that happen, right.
So what we said is it's going to be in setback, right? So it's going to be, the temperature bands are going to be way more relaxed. You get in this air. All you're doing is diluting the air inside and purging it out. And then when the purge is complete, then you tighten the temperatures back to set point and you also reduce the amount of outside air that you're getting so the system can maintain these temperatures. So that's unoccupied.
So during occupied mode, you bring down-, you still get enhanced ventilation, but not a hundred percent, right. And that enhanced ventilation knob is tuneable. It's again using ML, but we normally set it as a 50% as a baseline, is what we set.
So back to the energy impact study with NREL. So that's the mode that we implemented and we asked NREL to actually go back and do this validation and the results are, are eyeopening I think in terms of the energy impact, as you might imagine, right. And, but just following the CDC guidelines is going to be somewhere between three to five times, in some cases, in some climate zones, three to five times of what your baseline energy is… Just the HVAC piece.
James: Yeah, right. Okay. So they basically ran three-, the way I understand it, three OpenStudio models : one with normal operation, one with the CDC guidelines, and then one with epidemic mode. And what were the average savings for the epidemic mode from the CDC?
Deep: Right. We actually ran it in four. So we ran a normal mode, we ran it in CDC guidelines, and then we ran epidemic mode, and we also have in within epidemic-, remember that we have occupancy sensors. Right? So we have a concept that was just something that we're seeing that many of our customers are not getting in all the teams, all the employees in on the same day. So if you have staggered days of occupancy using the occupancy sensors, it saves a fair amount of energy as well, because you're only trying to condition those parts of the building which are going to be occupied. So, so when they ran that, what we found is that the CDC-, on average, the CDC guidelines are end up about three extra, 2.5 to three times over the baseline energy usage for the HVAC.
The epidemic mode in an office scenario was about 30% over the normal mode, right? The, which is about 50% savings over the CDC guidelines, which is significant, since now the top line is so large. And if you actually use the epidemic mode with the staggered occupancy, we were only about 15% higher than the baseline, which is like exceptionally nominal.
So back to your point, the point I was making is that if your buildings are adaptable, now you can make them healthy without necessarily incurring a huge cost as well.
[00:48:43]
As we decided that we were going to go scale the technology up, we actually made it so that it is exceptionally modular in a true platform, right? So we actually, one of the key things that we did is-, it's kind of weird, I keep dissing standards like BACnet, but on the other hand, I'm really gung ho on places like Haystack. And I know you were talking in the last episode on BACnet, 223, right, ASHRAE 223 and, and Haystack. So we have made everything within our product layer now in the software stack as 100% Haystack compliant.
So all our apps, all our portals are actually running reference implementations of Haystack apps. They ended up using the same API that we would actually expose to our customers, right? So I'm a big fan of interoperability, as I said, not necessarily at lower layer level, but at the right scale. And to me, I think Haystack is probably the first place where we've actually started getting some standardization around that piece, right. So, and especially when Haystack 4, gets completely flushed out or, or whatever ASHRAE comes out with on the 223 Committee, I think that's going to be exceptionally important.
So when we designed it, we made it super modular now. And so it's completely originally, it was just cloud hosted, but now we call it completely because some of our customers want it hosted in their own private data centers on, we have some countries which have restrictions in terms of the data should be stored locally. So we call it a hybrid public-private cloud. So it's completely containerized and dockerized so you can actually deploy it with what's called CICD continuous integration, continuous deployment. So it's, it is as good an architecture from a software perspective as can be, right. And that's because we decided to rearchitect it, as I said recently.
And now it's to the point that, I mean, we really look at like how are smart cities going to scale on a platform like this because we have some partnerships as an example with Singapore Power, they're the world's largest district cooling utility. But what they're doing is they're going and replicating the entire package of how to do district cooling to other countries and other districts, not just Singapore. Right? So they're selling it as a service. And so we are the technology stack on the building automation side for that. Right? So whenever there's a new smart city or a smart district, which is going to use Singapore Power they're all going to be using 75F technology.
So we decided to go back and make sure that the technology would scale to those levels. Because as we go in the future, I mean the whole concept with this distributed energy resources, as solar and wind become more prevalent, it's no longer going to be the case that the grid is going to scale up to the load; the load is going to have to adapt to the grid, right? So if that's the case then we really need bi-directional data models, which allow massively parallel computing in terms of machine learning, et cetera. And so that was the whole genesis behind making sure that we had semantic model in addition to just storing the data, right. So, so Haystack really fulfilled that.
[01:02:54]
What's kind of interesting is because of the fact that we are all IoT and we have our own knock for monitoring all of our deployments, what we do is we allow the white labeling of the monitoring service and that's kind of interesting thing, right? So if you're a smaller shop and you don't have a full knock, right. You could actually basically take our, get managed services from us, but put it under your own umbrella.
So you would end up getting the mechanical contractor or the service contractor would actually end up saying here's the service contract to their own customer, but we would be providing it, servicing it in the backend. Right. And what's kind of interesting with that is because we have so much data coming in, I mean, we can actually dive back directly and send out service tickets as well to dispatch mechanical guys if needed. So it's an interesting piece in terms of the managed services part, what this allows us to do so that you can be far more proactive, right. Because the knock is running all the time.
So it's truly a network operating center, which is like looking at all the buildings, looking at all the data and all the loads which are coming in.
[01:04:41]
Deep: One of the things that we've had a fair amount of success with is, is OEMs of equipment. Okay. Right. So you have the big guys, you have the Carriers, and you have the Tranes, and JCI who have their own controls. But you also have a large number of people who are making HVAC equipment, but who don't necessarily have their own controls line. And for those, I mean, we have really started becoming an OEM out of the box because now it's a huge differentiator, right?
No longer do you actually have to rely on someone else to do that system integration because it's now working out of the box. And so as a packaged solution especially for these midsize buildings that you're talking about under 200,000 square feet. I mean, it's a huge differentiator.
James: Totally. What would be an example of a piece of equipment that, you know, you could then just, it comes natively with a 75 F controller?
Deep: Dual cool, swamp coolers, things like AHUs, a lot of customized AHU folks out there, right? Small RTU guys. So we don't do the equipment control, but we provide the building control aspect of it. Right. So we wouldn't necessarily go in and replace an RTU controller itself, but we would go and interact with that RTU controller and make sure that they have, they basically are making it IoT enabled.
James: Okay. So a smaller building that only has, you know, five RTUs, and then you'd throw a 75F building controller. And now all of a sudden it has all the intelligence that-.
Deep: Yeah.
James: Okay, cool. I love that.
[01:08:35]
You want to have a consistent platform. You want to have the same hardware rather than having application specific stuff. In my opinion, that brings down your cost because you're doing volumes. It allows for more reliability because it's the same product. You're not saying, is CO2 sensor optional. Now, is this going to be for a water source heat pump or is this going to feed before a heat pump, right? Or is this a fan coil unit, right? I mean, I think it changes the supply chain game dramatically, and I think in 2020, that's where we should be.
What did you think about these highlights? Let us know in the comments.
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: [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.
One more quick note before we get to this week's episode. I'm a researcher at the National Renewable Energy Laboratory, otherwise known as NREL. All opinions expressed on this podcast belong solely to me or the guest. No resources from NREL are used to support Nexus, and NREL does not endorse or support any aspect of Nexus.
Episode 13 is a conversation with Deepinder Singh, CEO of 75F. I walked away from this conversation even more excited about 75F than I already was. As I've said before, 75F and PassiveLogic are the only two companies I know of doing the blank sheet of paper approach to modernizing and improving the performance of building control systems.
We unpacked 75F's founding story, what makes them unique, and why they decided to create the whole stack rather than just an overlay. We talked about their over the air sequence upgrades, how they're similar to Teslas, and how they enable the new epidemic mode for minimizing the energy penalty that comes along with the increased ventilation recommended by the CDC and ASHRAE to prevent the spread of COVID-19. Finally, we talked about their software platform, what makes it unique, and their hardware layer, and what makes it unique.
This episode of the podcast is directly funded by listeners like you who have joined the Nexus Pro membership community. You can find info on how to join and support the podcast at nexus.substack.com. You'll also find the show notes there, which has links to Deep's LinkedIn page.
Oh, and by the way, if you take a look at your podcast feed and you're missing Episodes 10 and 12, 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 all the episodes.
Without further ado, please enjoy Nexus Podcast Episode 13.
So hello, Deep. Welcome to the Nexus podcast. Can you go ahead and introduce yourself?
Deep: [00:02:49] Thanks for having me over, James. Yeah. So I'm Deep. I'm the CEO of 75F.
James: [00:02:54] Alright. And what is 75F? A for those that don't know?
Deep: [00:02:59] Yeah. Plainly speaking, we think of ourselves as building automation in a box, right. So what we've done is instead of trying to go and attack a very small layer in terms of putting in a software layer or just making smarter sensors, we decided to actually do the whole stack. So we actually start-, we have our own sensors. We have our own controllers. We make our own gateway and aggregation units. And on top of it, we put our own software, which is both in the building as well as in the cloud. So that includes things like remote access and portals. But also the machine learning stacks that we've created.
So all of that is really part of 75F. So it's a complete building intelligence solution, is how we call it. We don't just call it building automation. But we make it simple enough that it works out of the box. So it really doesn't require a huge amount of system integration actually requires zero amount of system integration.
James: [00:03:51] Cool. Cool. Yeah. I'm super excited to dig into a lot of this. I've been waiting to interview you for awhile.
So why don't we start with like the founding story of the company. So, I mean, I've talked a lot about how I think the building automation industry is broken. So I don't want to throw that story out there. I want you to tell me how it actually came about. So how was it born?
Deep: [00:04:12] Yeah. So it's an interesting thing. So I'm not at all from this industry, right? I'm a computer geek, mostly a network dude. So, if you use Verizon as an example, there's a 95% chance it goes over a back haul that I did. I had one of the world's first terabit routers sitting in my garage for five years.
But when my daughter was one, we just moved her into her own bedroom and she would wake up in the middle of the night crying. I was trying to figure out what's going on. And we found out that it's because the temperature in her room was dropping about 10 degrees at night, right? So she would be very extremely uncomfortable and get up. So as a self respecting engineer, I wanted to fix the problem. So I quit my job and here we are, we're chatting.
James: [00:04:55] Okay. Well, fill in some more of those details. So, how did you go from say, you know, fixing the air in your house to the commercial buildings industry, and what made you feel like the, you know, the controls market in this industry was an opportunity for a startup?
Deep: [00:05:12] I mean, I already started to fix my own personal problems.
So when we originally started, we were really looking at the company called Keene, went and eco home. They started making this way after us. But we used to-, I started a company called sun bullet, which really made these motorized dampers that you could put into each room in a house to control, to turn on and off the airflow in there, right? So it's kind of primitive zoning, but it's at the terminal side. What it's doing is instead of going and putting a damper in the duct work, you really using the resister to control it automatically.
And as we progressed to that, we actually went to a pretty late stage. we were in talks with GE to produce it and Best Buy to distribute the stuff. We found that there was basically about 25 different skus, the units that you sell, that we would have to create, because the resisters come in so many different sizes in the residences, in the U.S., right. And because of that, I mean, it was from a logistical perspective, very expensive proposition. So we abandoned that piece because it required too much shelf space.
But the idea as part of the journey, I mean, I found that if it was an issue in residences, it was a bigger issue in commercial buildings. And I was a little bit surprised by that. I mean, with due reverence to Johnson Controls, I go into the headquarters, they have the steam-powered zone-controlled systems going back 150 years, right. But the industry really hasn't progressed that much in the last couple of decades, right. Even what we see now, the DDC controllers, and the BACnet pieces really came in the mid nineties.
So we haven't really caught onto the true IoT revolution. A lot of companies are claiming they're IoT, but IoT is more than just saying that we're connected to the internet, right? IoT is really about being current, being over the air upgrades and just taking this connectivity ubiquitously as, as granted, which is not necessarily the case in the industry. Right.
So when I came in from the telecom side, I was a little bit surprised that this is an industry, which I mean controls the large amount of energy, I mean the fourth largest emitter of GHG gases is our buildings, right. And all of a sudden we have technology, which is very outdated. And I primarily think it's because most of the folks come from the mechanical side. And not necessarily from the IT side. So most of the standards are not necessarily have caught up with the same pace that we've seen in consumer electronics as an example.
So for me, this was an opportunity that commercial buildings presented more standardization. The dampers are more accessible. You have, right, the more commonly configured sizes. You don't have to stock them. They're also available more easily. So we actually shut down the old company, sun bullet, and I recreated this new company, 75F, specifically focused on commercial buildings.
James: [00:08:02] I got it. And what year was that, that 75F started?
Deep: [00:08:06] 2012 is when we started. And I was primarily originally focused on the light commercial buildings. So I was thinking of the same thing, residential, no, let's go into smaller buildings under 10,000 square feet. People can buy a solution from a distributor and essentially once you've got that, they can go put it in themselves. So that was the whole Genesis that let's keep it relatively simple for smaller buildings.
Things have evolved over the last few years though, right? I mean, it's, interesting. I mean, you know, you start seeing these cracks in what's out there and you keep wondering like why it's not been addressed. And I do believe that this business case, I think you've discussed about it as well, that it's a question of how are people incentivized to make money, right. How the channel has grown over the years. Right? So there's a technical issue, but there's also a business issue as well. Right.
And if you're not from the industry, then you're not encumbered by either. You don't have to support legacy customers, and you're not necessarily beholden to say that, Hey, we have to serve the same channel that is going to market. So go to market can be a little bit different. And I think we brought that fresh approach being outsiders and not necessarily knowing what we were doing.
James: [00:09:18] Yeah, totally. Cool. So, I want to just hit on a couple of these. I mean, you've mentioned a lot of these differentiators already. So maybe just take us through like why you decided to create a full stack. So you recognize this as an issue, but you're actually creating sensors, controllers, controller software, cloud software, the whole gamut.
So why did you decide to do that?
Deep: [00:09:44] Primary reason is like, I look at the controls industry as kind of like the computing industry back in the seventies, right. Back then, when you bought an Apple: one, you brought it home, you sorted it together; and then you learned programming basic to solve your own problems, right.
And today it's inconceivable to not walk into a mall and you want to buy an iPhone in three minutes. Of course, you can't walk into malls these days without wearing a face mask, but that's a different story, right? But if it ever takes you five minutes, you're probably screaming bloody murder. It's like, ah, this thing is not right. But it's kind of weird in the controls industry, we still accept that, that system integration, taking the product from Schneider and then taking another sensor from ECI and then tying them together through custom code is acceptable, right. And, and that to me is kind of weird. It's part of it.
Yes, standards exist for interoperability, but they also make it harder, that nothing works out of the box, right. And if you look at it, I mean the standards, I believe don't necessarily need to exist at a device level. Really, if you want to have-, these days, I mean, the system should work out of the box. I mean, you don't really care what standard your iPhone camera uses to communicate with the rest of the processor. What you do care about is about the base level of functionality and like, how does it interact? Like is the file system, which is supported, is the photo a JPEG or PNG, which can be exported out of the unit, right. So if we accept that kind of modularity, I mean, if we accept that that is a black box, then that really allows us, things to be more efficient. Not everything needs to be interoperable at every stage is how I look at it. Right.
So our take was that, alright, let's make sure that, instead of saying that the humidity sensor itself needs to talk BACnet and go right to a controller, let's make sure that the humidity sensor and the temperature sensor and the organic compounds and the CO2 to sensors, let's not even make them optional. Right? Let's put in all of these sensors out of the box. Because the hardware has grown, in all honesty, it will be super reliable and cheap, right. We end up using the same sensors. When I started originally on the, on the residential side, I mean, we use the Fluke temperature sensors were about $350. To get a reference quality Fluke sensor.
We have the same sensor in every one of our rooms now. Wow, right. So overall, if you look at just how, and it's part of the mobile revolution, right? I'm not taking credit for it. What I'm saying is that, I mean, the consumer electronics have really driven, the mobile revolution has driven such good standards in terms of sensors and overall technology that what we really need to do is keep pace, take advantage of that.
And that's what we're doing. We're packing all of these sensors, packing in all of this functionality out of the box, right. And the second piece that we wanted to do is we wanted to have that instead of having a dedicated application-specific controller, if you have one controller that takes on different personalities, depending on what equipment you connected to. So it's kind of like your iPhone is one box. It's got all the sensors, got all that functionality baked in depending on what app you're using. You end up having a different profile, right.
James: [00:13:07] Totally. Yeah.
Deep: [00:13:09] Because the value is in not necessarily going and integrating and putting these things in one at a time.
So it's not unique in terms of what the industry is doing in the consumer side, right. We accept this in our phones. We accept this in our cars. We've just not somehow got it in our HVAC and our buildings yet. Right. We look at it as a totally different scenario.
Nobody talks about like hey is my car talking BACnet.
James: [00:13:37] I agree. Yeah. So, it sounds like also one of the benefits of it being full stack is it's also super easy to install, right? I mean, like you kind of hinted at with that, with the iPhone example, but it can be very quick, right. And I think that's one of the things you guys were going for initially too, right?
Deep: [00:13:56] Right. You're spot on with that. Right. I mean, that was the whole idea that we wanted to make it very easy.
But back to my roots, I was really thinking that like, why, why did this control solution in our home not work? And it's primarily because we made overly-complicated. We've got all these pieces to tinker around. We're not looking at it as a solution. We're really looking at small pieces that needed to be brought together. So we had this program, we did a project in elementary school and we asked the kids who are eight and nine years old to go put in our system ourselves, right.
So the idea is that, so we always have this thing. I mean our system's gotten, in all honesty, a little bit more complex. Now we're doing much larger buildings, a million square feet sometimes, right. But, so maybe the same students could do it now. Right? They're a little bit older, 10 and 12 year old kids could do it now. But at that point it was revolutionary that you could go put in a control solution that the kids who had no training at all could go put it in.
We've kind of kept it as part of what we look at when we add features is like, does it increase the complexity and the debt in terms of cognitive burden on the person who's installing it, right? Because we can give you all of these options, but if you, the more options you add, the harder it becomes to actually use, right. So like your grandmother, it's pretty hard for them to pick up an iPhone these days and use it out of the box, right. It works out of the box, but if you ever went to settings and tried to configure everything, I think it's a little bit more complex than the initial system, right. So we've been pretty mindful about that.
It's like, how do you hide all of that complexity and make it so that the machines can do that, right? So I think we were talking about Descript, all the things that you can do with Descript. I mean, that's absolutely amazing to try to do that by hand would be nuts. Right.
And yet the computing power is available. It's abundantly available and all you got to do is harness it, right.
James: [00:15:51] Right.
Deep: [00:15:52] Awesome. So that's what we did is like let's harness the technology curve very aggressively. Because the way I look at it, purely from an energy efficiency perspective, CO2, the emissions, if you look at where we are, we are not, our CO2 levels and GHG is not rising linearly, it's rising exponentially, right. And so the only thing that I know of that we can actually use, the only other thing there is Moore's law, right. Like our computing power is the only other thing which is nonlinear that I know of in terms of technology. So we got to be very, very aggressive in making sure that we are always keeping ahead and keeping track where technology is.
Right. And making sure that we are very aggressive price points for computing.
James: [00:16:42] Totally . So since we just talked about plug and play, I also wanted to talk about small buildings. And so it sounds like you guys are, you started with small buildings and now you're progressing into, you know, bigger and bigger buildings as the company expands, but can you talk a little bit about the opportunity with small buildings?
I mean, I don't know a whole lot about it. I spent most of my career with, you know, big, big, big, big buildings and campuses. but the way I understand it is like, there's a huge opportunity for automation in smaller commercial buildings, medium sized commercial buildings across the country, across the world.
So what are you guys seeing there?
Deep: [00:17:20] You're right. I mean, 90% of the buildings are under 200,000 square feet, right? So there's a relatively large number of buildings in that stock. We have traditionally looked at the buildings, which are obviously much smaller, right? Because we can go in, as a retrofit, we are much easier to put in.
And what we're trying to do is make it more accessible so that people who didn't think that they had a cost effective solution. And out of those buildings, I mean, most of them don't have BMS. And the primary reason is because they're too complex and too expensive. Right. So we were really looking at these smaller buildings and saying, that's the sweet spot that we really want to address.
What we did find is that buildings under 10,000 square feet, which I thought would be the primary market to begin with, right. Those folks are not as concerned about actually having temperature control or about energy because the numbers are too small. But the sweet spot, I think is really somewhere between 20,000 square feet to about 200, 250,000 square feet beyond which I think controls are kind of accepted.
It is better. Right. But the sweet spot is really, can you go address that? And that's kind of an important, very important segment for us specifically now, given where we are with the COVID situation, right. And where the CDC and ASHRAE guidelines are right. So we are going back to a lot of not only our customers, but new customers, churches, schools, right, business manufacturing facilities, which are specifically working 24/7 as an example, right. Light manufacturing. We're going back to them and making sure that their workplaces are safer, even where we are. So specifically we introduced something called epidemic mode which implements the CDC and ASHRAE guidelines, right.
So that's a very important segment, spot on.
James: [00:19:06] Totally. And it sounds like, you know, before they might not have any, any automation at all, and you're going in and saying basically, Hey, this is an opportunity to start controlling, measuring, measuring your ventilation, right. And making sure that you have enough. Cool.
So before we get into epidemic mode, I do want to hit that next, but I think like your platform enables epidemic mode, because you're able to push sequence updates to controllers. And I think that's a huge differentiator, you know, compared to the old way to do controls.
So can you talk a little bit about why you did that and, how that works?
Deep: [00:19:43] Again, I do believe in the future this is what we will see, right. I mean, we take it for granted that your phone is going to keep updating. Yeah, right , and now you have the cars which keep updating. So, so why aren't your HVAC system?
Right. And so even day one, I mean, that's what we started with over the air firmware upgrades, and also, our central control unit, which actually runs the algorithms holistically for the building. So those, that keeps updating regularly. And in fact, It keeps updating both from the sequence of operations, but also on a daily basis, it actually gets updated in terms of the tuners, because we create a ML model. So we look at the weather and we look at the past history and we'll figure out what's going to be the optimum tune points, set points for making the building work. Right.
And these are not just temperature. We don't change temperatures, temperature set points, because I think. That's kind of-, I have another beef with this, right. I don't understand. I think it's, it's a Kluge to try to change set points, to get your controllers to do something different. Right. And it's primarily because I think that the controllers are locked in terms of the sequences that they have. So the only option normally available is like, how do you fool them into doing something different?
And, and that's really hard science, in my opinion, and a hats off to companies who are trying to fix that because every manufacturer, every deployment has a different understanding of what the controller should be doing anyway, right. So now you have lots of different variances that you really have to account for in your ML models, which is why I don't think machine learning and tweaking has truly taken off because every building is an exception.
Right. And ML only works if you can tune the model and if you can train the model. Right. So we decided that we want to standardize this. So the idea is that out of the box, I mean, we use like true software processes and test harnesses to make sure that it's not just the software, which is working, but the sequence of operations are doing what they should, right. So unless you have regression tested with the point of like continuous commissioning is to me, so weird. Right because I mean, that should be a given the fact that we have to go back and recommission buildings makes no sense at all.
James: [00:22:02] Right, right.
Deep: [00:22:03] It should work out of the box and this stuff should self-tune. I mean, that's the whole point. If we look at our apps, if you look at where the world is with, like, we actually have continuous integration and continuous deployment things, right. In terms of microservices and how we update the web as an example, right. None of those things have somehow carried over to this domain, right. But from my perspective where I came from, I mean, that was a given that things work. They always keep changing and you can push them out as sequences get better, technology gets better, our understanding gets better. You keep on pushing these updates out. And that's what we really did, over the air upgrades, as I said, not just for central unit, which is running Android, the gateway, but even for each of the edge devices themselves.
James: [00:22:48] Okay. So just so I'm, I'm learning here too. How does the-, so if you think about like a machine learning product that is tweaking set points, how does, how does your machine learning work differently than that?
Deep: [00:23:01] Right. The biggest difference is our machine learning is really looking at loads in the building. Okay, so it doesn't have to keep changing set points. What it does is it, we have a concept of what we call tuners. Tuners are things which can affect the functioning of an algorithm. As an example, we have a bias towards saying that, Hey, if you already have an ML model and you know that it's going to be sunny, then your load in the building is going to shift more.
Right. And it already knows that from the weather forecast model, But it doesn't actually-. So it's really saying that the load is shifting by 2:00 PM. The load is going to be 30% more in this part of the building. What it doesn't have to do is like the set points don't have to be changed because that's really a hint to the system that you're going to start putting more air before the set points have to be tweaked.
James: [00:23:54] Right.
Deep: [00:23:55] Right. The problem is that everyone's using proportional integral systems, right. And because you use using PI controls, what you're doing is you're trying to use the Delta T between the set point and the current temperature to try to fool the system to get it to do something else.
Whereas the true problem is really that you've got an increased load coming down. You should really be conditioning beforehand. There's no reason that you really need to be trying to tell the PI loop and fool it to do anything different, right? So I look at the PI loops and stuff. Those are really far more reactive, for course correction in tweaking, but if you already know that the load is going to be more in a part of the building, let's just open up the dampers predictably proactively, right? If it's going to be a cloudy day, then you really know that the loads going to be more uniform. It's occluded so that there's not going to be as much directionality to the load.
So that's one piece, right? You can use things like, even things like, when do you turn on for preconditioning, right? I mean, you already know that based on what the current temperatures are and where the outset temperatures are. And so, you know, what a cooling rate or your heating rate should be, and, you know, the Delta T and the temperature and set points. So don't change the set point. Let's just figure out the right way of doing it. Right?
James: [00:25:13] Yeah. And I've talked in the last couple of essays I've written about this, there's like, I think everyone that at least reads Nexus is like, okay, we agree that the existing BAS paradigm is broken. Right. Okay.
Now there's two solutions to that, in my opinion, there's the overlay, which I think we're describing the overlay. And then there's the, the, throw it out the window, build it from scratch approach, which I put you guys in that, throw it out the window, build it from scratch approach. And I think what we're highlighting here is like two major differences.
So I just want to kind of restate it to you cause I'm, I'm learning this out loud, but the overlay approach would say, okay, I have all these PID loops that are operating based off of set points. And the only thing I can do in my overlay is just start overriding set points. Right? Whereas what you're saying is no, actually we can, if we're building it from scratch, we can actually just take that PID loop sort of, not totally out of the equation, but we can start operating the system directly, essentially.
Yeah.
Deep: [00:26:13] And you're spot on. Right. And you do it holistically. I mean, that's the biggest difference that I look at is, the current BAS systems are the tail wagging the dog, right. It's like your PI loop is typically running in your room. And it's really controlling the VAV damper opening as an example. Right? So your communication back to your actual BAS is typically by duct static pressure, right?
No one is actually saying what should be happening in all the zones, which are being served by an AHU. You're not figuring out what the total load is. You don't know which part of the building really requires a load. All you're doing is you're using duct static pressure has some kind of a mechanism of figuring out. Yes, there is more required load in some part, right?
I think the closest we've come to is now with the, with GPC 36, the ASHRAE Standard Advanced Sequences for HVAC Operations. I mean, what they started doing is sending some feedback back in terms of trim and reset, trim and respond. And that's a mechanism that is in some ways, of course, PI loop mechanism, the requests are the equivalent of showing some load in the terminal units, right. But I mean, there are far more interactive, far more real time systems available that we've implemented. We also implement GPC 36, by the way. Right. Because some engineers really want the assurance. That is a very well-defined mechanism, which is well known. And so we implement GPC 36 and we we've committed to the fact that as GPC 36 evolves, we will keep updating our sequences. And more importantly, we do reference quality GPC 36. It's like using software techniques, crude test harness stuff, which does regression or not. And so we run it through the whole shebang.
So you don't really have to commission them. It works out of the box. Totally, right. But the key is that, I mean, from our perspective, GPC, that is the lowest level of, I think, current control solution that I would actually consider acceptable.
James: [00:28:19] Right, right. Well, I mean, let's just pause on GPC 36 real quick. So, ASHRAE is coming out with these new sequences, and ASHRAE saying these are the top sequences, right? So in the old controls paradigm, I just want to kind of lay this out for people that are new to this topic. The old control paradigm is that every single building that's been programmed in the past, right, now someone has to physically go there and say, okay, let's upgrade these new control sequences and basically program them by hand. And what you guys are saying is no, I mean, every building that's ever had 75F installed on it now can get these control sequences automatically just like the Tesla that everybody wants. Right. It's, it's getting control sequences essentially automatically pushed to them. So it's just like this huge upgrade for the whole industry, if all controls companies did it like that.
Cool. Alright. So one of those newer sequences, right, is, what you guys have kind of used to respond to the pandemic, which is epidemic mode. So first I want to kind of get your take as a leader in our industry, kind of where you see the industry being at right now. So it's, it's middle of July, 2020 if someone's listening to this five years from now. But we're kind of still in the middle of this pandemic. There could be a second wave. It does certainly seems like there's a second wave coming. So how are you feeling about the state of the buildings industry and the smart buildings industry specifically?
Deep: [00:29:51] It's a loaded question. I think there's going to be some winners and losers. I think the existing building stock is not going to be utilized the way it was before. I think this change that we're seeing of working from home at least partially is, is irreversible. We've kind of accepted it. So the two things which are going to be at looked at, as like building owners and we've talked to bunch of them, right? Real estate folks. Should be really worried and they are, right. Because I don't think the tenants at this point, we're laying it down to the second wave, but it's not just the second wave. I think this is going to be a longterm proposition.
The same thing with, with air travel. Right. We're doing it now as an immediate reaction, but I think even longterm, the acceptance of digital communication. It's just going to be so much higher. I don't think, believe that we're going to go back to that same way anytime soon. Definitely not in the five years that we were talking about, perhaps.
Right. But, so if that's the case, I mean, what you really want to do is like figure out, like, how do you make buildings safer? Right. I also think this is an opportunity to make buildings more adaptable because this is just one thing.
So the buildings that, as an example, that had the 75F system, it's seamless for them to get these updates, right. But it's not just us. I look at it as like, if you want to change, use the right technology so that you can keep on harnessing change, right. So that you can be adaptable, whether it's epidemic mode now, or it's a better energy-saving sequences later on.
So, what we are doing is we're going back to a lot of these buildings we talked about, the 20,000 square feet to 200,000 square feet, and saying, Hey folks, like, how can we actually help you make your buildings adaptable? How can we make them more healthier now? Right. And, and how at some point when we have a vaccine and things go back to normal and more people are coming back, can you actually go back and start using modes, which are more energy efficient?
Right, because there is obviously a cost associated with any of these modes that we're talking about, which are talking about enhanced ventilation as an example, to dilute the load, the viral load in a building. Right. And the flip side of which is, I think we're going to come out of this and people are going to say that it's not just the viral load, but it's also, there's going to be enhanced awareness in terms of the indoor air quality in general, right. We've been talking about it for a number of years, but I don't think we've actually truly taken steps towards that. So now we can come back and it's like, there's going to be more just overall awareness is going to be much higher in terms of IAQ and healthier buildings and being more adaptable and intelligent.
And that's one part of the message that the building owners that we're talking to understand that. Like, they want to say that, Hey, our building, our building stock is the healthier one, is what would they call it, a clean asset is how they look at it. It used to be the clean asset term was used primarily from an energy efficiency perspective, but now you're looking at it from a wellbeing as a healthy building standard, right.
James: [00:33:01] Okay, cool. Yeah, totally. So let's, let's nerd out on epidemic mode real quick. So, I've been putting in the newsletter each week, I've been kind of saying like, here's the the best articles I've seen on the pandemic so far, here's some good ones that if people are looking to keep up with it and what I haven't seen really at all, and I've been saying this, is like everyone's talking about more ventilation. No one's talking about the impact on the energy consumption.
And I watched your, your webcast from last week. So I learned a lot about it, but I want to hear like what, where you guys are coming from in terms of this epidemic mode. And again, it sounds like it's a control sequence that you're able to push out and let operators decide whether they want to turn it on or turn it off. But what does it actually do and what are the benefits of it?
Deep: [00:33:50] Right. So back to where the CDC and ASHRAE guidelines are, what they're recommending right now is that you run your systems 24/7, and you run them with increased amounts of outside air, right.
James: [00:34:02] Which as an energy engineer, I've been undoing that for my entire career. Right. So it was just like, Oh wait, wait, we've been undoing that for so long.
Deep: [00:34:12] I know it was like, let's put them on schedules, right. So, and there are reasons behind that in the primary, we talked with some of the folks on the task force, right, both on ASHRAE and on the CDC side. And the primary reason for that is that in some ways, if you think of a current building or a BAS system, you only have a concept of occupied or unoccupied. There is no concept of saying, Hey, let's have a pre purge or post purge, or alright, let's have an epidemic mode sequence right in there, right. So there is no state called epidemic over there. So. In terms of safety. What they've had to do is they've had to bring down the standards to the lowest common denominator.
And it is kind of an interesting thing. You go back, this thing is more rampant than just these, these current CDC guidelines. It's actually rampant in everything we do. It's rampant in ASHRAE 62.1, which is the IAQ piece, right. It's rampant in even GPC 36. If you look at GPC 36, the original predecessor to that RP 1455, when they were looking at it, they were looking at not just the best control sequences, they were looking at the best control sequences that could be implemented in a existing controller. And with people who were at the level of like a master system integrator, not at a rocket scientist kind of level, right. They were trying to figure out like, what can we push out which can actually practically get consumed?
James: [00:35:47] Got it. So that makes perfect sense. I never thought about it like that before.
Deep: [00:35:52] And those are the constraints of the folks who are making these recommendations because they have to go back and make sure that they apply to everyone. Because if they put in an advanced sequence that people can't comply with, then like, what do you do with that building? Do you throw it out? Do you shut down the building? Right.
So, so they've actually tried to simplify it, dumb it down and said, Hey, run the system 24/7. Run it at enhanced ventilation rate, as much as a hundred percent outside air, if possible, if not as much as you can, right?
Because there's no epidemic mode, because the system was not ready to run a hundred percent all the time, what you have to do is now figure out what is the amount of outside air it can do under extreme design days. Most of the days it perhaps has capacity, but on some days, if you try to get in that enhanced ventilation, the system cannot keep up, right. Because it's not adaptable. So that's kind of the way the recommendations were. And so that's the baseline that we took.
So it's interesting. We were actually doing a project with NREL as part of the IN2 program, right? So the Innovation Network 2 program, and they were specifically looking at the energy impact and savings of 75F across multiple climate zones and different building types, right. So when the pandemic came around, we looked at the literature. There was absolutely zero literature talking about what's going to be the potential impact of these recommendations that the CDC and ASHRAE are putting out.
So, we actually talked to NREL at that point. So, Grant -sp?-, who leading the project over there and decided, Hey, let's divert some of the resources that were going to look at normal operation and use them specifically for this epidemic mode.
And so we had a theory. The two things that we wanted to test out is A) from our perspective, you don't need the ventilation all the time. You really only need it when the building is occupied. Second, the other thing was that the reason that the CDC said you want to run it 24/7 is because the concept of a purge means that you can, you cleanse the building with a high amount of outside air for a short duration. And the ASHRAE sequences at some point talk about the purge creepers and the post-purges as well, right. But the CDC did not because they already had to bring it down to the lowest level.
So we actually tested these out and we did some pretty interesting experiments. So obviously, no one's detecting the COVID virus itself, but what we did is we did some experiments in which we use, you know, we, since we've already got volatile organic compound sensors built into the product, we actually use meth paint and alcohol as the two substitutes. And we use cotton balls dipped in alcohol. And when you took it out, figured out how long it would take for those cotton balls, the VOC levels to decline.
James: [00:38:40] Hmm. Okay.
Deep: [00:38:41] Alright. So in normal mode, in a normal AHU operating normally, and the average Hertz was about 50% of capacity. It took about two hours for the VOC levels to decline to baseline. When you raise that up to about 60%, 65%, it took about one hour. Now, when you raised it over to 80%, it only took 12 minutes.
James: [00:39:05] Oh, wow. Okay.
Deep: [00:39:07] The primary reason is, is because the air flow starts becoming turbulent, right? So your actual ability to extract and entrain the air and extract it is far more efficient, right? Which is what, in my opinion, like, no one's done these studies before, but we wanted to test it out and it's like, yes, so if you truly wanted to do this, what you want to do is you want to run the fan at high speed. You want to get a whole lot of outside air for a shorter period of time and get it all cleansed, right. So that's what we did.
We introduced this concept of a pre-purge and a post-purge. So it's prior to occupancy and after occupancy, and back to your point, you can turn them on and off as simple as just a slider on a phone. And the system automatically does that. But when you're doing these purges, at that point, you really don't want that the set points should be maintained. So it's not the same as saying, Hey, let's move my schedule earlier. Because if you try to maintain set points, then you have a very tight temperature debt when you're getting in a whole lot of outside air. And you're really going to be consuming a huge amount of energy to make that happen, right.
So what we said is it's going to be in setback, right? So it's going to be, the temperature bands are going to be way more relaxed. You get in this air. All you're doing is diluting the air inside and purging it out. And then when the purge is complete, then you tighten the temperatures back to set point and you also reduce the amount of outside air that you're getting so the system can maintain these temperatures.
James: [00:40:35] Right, got it. Okay. So what about during occupied mode?
Deep: [00:40:39] So that's unoccupied. So during occupied mode, you bring down-, you still get enhanced ventilation, but not a hundred percent, right. And that enhanced ventilation knob is tuneable. It's again using ML, but we normally set it as a 50% as a baseline, is what we set.
So back to the energy impact study with NREL. So that's the mode that we implemented and we asked NREL to actually go back and do this validation and the results are, are eyeopening I think in terms of the energy impact, as you might imagine, right. And, but just following the CDC guidelines is going to be somewhere between three to five times, in some cases, in some climate zones, three to five times of what your baseline energy is.
James: [00:41:24] And is that total building energy or just HVAC?
Deep: [00:41:27] Just the HVAC piece.
James: [00:41:29] Yeah, right. Okay. So they basically ran three-, the way I understand it, three OpenStudio models : one with normal operation, one with the CDC guidelines, and then one with epidemic mode. And what were the average savings for the epidemic mode from the CDC?
Deep: [00:41:45] Right. We actually ran it in four. So we ran a normal mode, we ran it in CDC guidelines, and then we ran epidemic mode, and we also have in within epidemic-, remember that we have occupancy sensors. Right? So we have a concept that was just something that we're seeing that many of our customers are not getting in all the teams, all the employees in on the same day. So if you have staggered days of occupancy using the occupancy sensors, it saves a fair amount of energy as well, because you're only trying to condition those parts of the building which are going to be occupied. So, so when they ran that, what we found is that the CDC-, on average, the CDC guidelines are end up about three extra, 2.5 to three times over the baseline energy usage for the HVAC.
The epidemic mode in an office scenario was about 30% over the normal mode, right? The, which is about 50% savings over the CDC guidelines, which is significant, since now the top line is so large. And if you actually use the epidemic mode with the staggered occupancy, we were only about 15% higher than the baseline, which is like exceptionally nominal.
So back to your point, the point I was making is that if your buildings are adaptable, now you can make them healthy without necessarily incurring a huge cost as well.
James: [00:43:07] Totally. And what are your customers saying about epidemic mode? What are you hearing from them? What kind of problems is it solving for them?
Deep: [00:43:15] It's solving some problems. It's also highlighting some problems, which I had not anticipated by the way. So it's solving the problem that obviously you end up-, we give this nice decal, a sticker because one of the key things is many of the things that we're doing-, we don't know everything about the, about COVID-19 right ,or the coronavirus. What people are looking for is visible, they're looking for visible signs that you care, right? So one part of it is like we made these large decals, which let people know that the air in this building is being purged. Right? So from a confidence perspective, I think it's been absolutely fantastic for employees and customers.
And especially some of our retail customers have adopted this. And when their people come in to buy into that store, they now know that the building is safer. Right. So they've actually seen, it's a big differentiator. Back to the point of like, even from a marketing perspective, like which store would you want to go to, the healthy store or the not so healthy store?
James: [00:44:14] Yeah.
Deep: [00:44:15] Right, so they've seen those kinds of responses. One of the things that we found out that we didn't necessarily expect is that we keep talking about how bad people maintain equipment sometimes. Right. We found out, I mean, the economizers obviously are notorious, and we had obviously tracked this in terms of like, is the economizing working or not based on mixed air temperatures with our piece, what we found was pressure problems.
We hadn't done as much economizing at such scale. Right. All the time. Right. So a huge amount of positive and negative pressure differences started popping up in many places where you ran all the systems at a hundred percent outside air, as an example, during purge cycles.
James: [00:45:02] Got it. Right.
Deep: [00:45:04] And it's an interesting thing.
I mean, we keep thinking that for the first time you start recognizing why you need variable capacity fans on the return side as well.
James: [00:45:14] Absolutely. That's something to watch out for. And this is where all of our commissioning agents, shout out to all them, this is where we, we don't really need them to be tuning sequences, but we do need them to go figure out these issues and that are popping up.
Deep: [00:45:28] That's true, yeah.
James: [00:45:30] Cool. So, there's a couple other issues I think that I'm seeing as you start to increase ventilation, it seems like there's going to start to be, and you touched on this a little bit, but equipment capacity issues. Right. So if someone's out there just opening ventilation dampers a hundred percent, not just pressure, but also like chillers can't keep up. Chilled water coils can't, can't keep up. When we get around into the winter, there's going to be a lot of preheat coils that can't keep up, those types of things. So I feel like these dynamic sequences can help find that edge. Right. A lot better.
And then with humidity. So we're in the middle of July and the United States, maybe not in Minnesota where you're at, but, well, it actually gets pretty humid there in the summer, but, managing humidity as well, I feel like it's super important. Right.
Deep: [00:46:16] Right. And that was actually, that's something that got highlighted in the simulations that came up from NREL as well.
So it looked at two other aspects in addition to the energy piece, It's like how well is the temperature being regulated? And that, I think back to your point, that like, we actually had to turn down the amount of outside air which is coming in terms of the CDC models, because they're running 24/7, right. And it gets really, really cold in some of those places. So like extreme Minnesota winter was a pretty decent example, that the building temperatures were dropping and the system was not able to keep up. Right. So, so that's something definitely worth keeping in mind and ditto with humidity as well, specifically with the outside air coming in consistently, it just in Houston 2A was strapped like during a design day, the humidity was almost 70% inside the building, which is, which is getting out there.
James: [00:47:11] Yeah, definitely. Okay, well, cool. I mean, I'm super excited. I was pumped up watching the webcast about this, so I'm excited to see where that goes. And I hope people start copying off of you, frankly, because, because I think it's, this is a needed upgrade to control sequences.
Deep: [00:47:30] I think that's a good point, James. I mean, when we did this, even when we talked with NREL, yes, we had our funding, but that's why we wanted to share it with everyone is that these are the results and these are the sequences. So we are actually super crystal clear. So even if anyone else is ever looking for like our sequence of operations, what we've implemented by all means, I mean, we are making these public.
I think if a medical, a vaccine makers can collaborate, I think HVAC companies can collaborate as well.
James: [00:48:01] Exactly. I love it. So let's, let's kind of pivot back to the product itself. So, you know, you and I have talked a couple of times, so I feel like I understand the product pretty well. But let's, let's kinda start with software.
You guys again, had the chance to just throw the existing automation, you know, front end paradigm is totally out the window. So how have you, like what makes a good software layer and how have you guys approached creating that, in the, in the product?
Deep: [00:48:29] I'm glad you're talking about it now than maybe two years earlier because our understanding has evolved as well, right? So when we started, we were really looking at a small as a product, right. But about two years ago, as we decided that we were going to go scale the technology up, we actually made it so that it is exceptionally modular in a true platform, right? So we actually, one of the key things that we did is-, it's kind of weird, I keep dissing standards like BACnet, but on the other hand, I'm really gung ho on places like Haystack. And I know you were talking in the last episode on BACnet, 223, right, ASHRAE 223 and, and Haystack. So we have made everything within our product layer now in the software stack as 100% Haystack compliant.
So all our apps, all our portals are actually running reference implementations of Haystack apps. They ended up using the same API that we would actually expose to our customers, right? So I'm a big fan of interoperability, as I said, not necessarily at lower layer level, but at the right scale. And to me, I think Haystack is probably the first place where we've actually started getting some standardization around that piece, right. So, and especially when Haystack 4, gets completely flushed out or, or whatever ASHRAE comes out with on the 223 Committee, I think that's going to be exceptionally important.
So when we designed it, we made it super modular now. And so it's completely originally, it was just cloud hosted, but now we call it completely because some of our customers want it hosted in their own private data centers on, we have some countries which have restrictions in terms of the data should be stored locally. So we call it a hybrid public-private cloud. So it's completely containerized and dockerized so you can actually deploy it with what's called CICD continuous integration, continuous deployment. So it's, it is as good an architecture from a software perspective as can be, right. And that's because we decided to rearchitect it, as I said recently.
And now it's to the point that, I mean, we really look at like how are smart cities going to scale on a platform like this because we have some partnerships as an example with Singapore Power, they're the world's largest district cooling utility. But what they're doing is they're going and replicating the entire package of how to do district cooling to other countries and other districts, not just Singapore. Right? So they're selling it as a service. And so we are the technology stack on the building automation side for that. Right? So whenever there's a new smart city or a smart district, which is going to use Singapore Power they're all going to be using 75F technology.
So we decided to go back and make sure that the technology would scale to those levels. Because as we go in the future, I mean the whole concept with this distributed energy resources, as solar and wind become more prevalent, it's no longer going to be the case that the grid is going to scale up to the load; the load is going to have to adapt to the grid, right? So if that's the case then we really need bi-directional data models, which allow massively parallel computing in terms of machine learning, et cetera. And so that was the whole genesis behind making sure that we had semantic model in addition to just storing the data, right. So, so Haystack really fulfilled that.
James: [00:51:52] Totally. And anyone who's listened to the last episode knows that this is a different perspective for someone that's in the building automation world to design their product with Haystack natively, basically is what I'm hearing. So what makes-, why did you do that when you're a controls company, and why do other controls companies not build like that?
Deep: [00:52:16] It's like their legacy, right? I mean, if you already have a database, I guess you don't really care. But I mean, to me, it makes a lot of sense. I know you come from the energy auditing piece as well. Right? So you probably use SkySpark, but it's kind of weird to actually connect SkySpark to a building, which has BACnet and then manually map all the data over, right. And I mean, it is a huge amount of work and it's like, it boggles me. It befuddles me, why others won't do it natively, but I can only think it's because of legacy. That's how it's always been, right.
But we decided to do it natively out of the box, everything, even our algorithms, when we did RP 1455, GPC 36, it's kind of weird. We don't even look at current temperature. We look at points. So we actually make a call to say the Haystack tags, which would actually allow you to save point his current zone. Right. So it's really a call every time we use-, there's no variable names in all of our algorithms. So we are like hardcore.
James: [00:53:18] Truly native Haystack. That's amazing
Deep: [00:53:21] Truly native Haystack. I mean, if you look at our analytics, our widgets, which go and display all of the data, every one of them is a true Haystack point.
James: [00:53:30] Wow. Yeah. I'm sure Brian Frank and the guys that started that are pumped about that. So, cool. So a couple of different questions about the software: first is, you know, you mentioned SkySpark, for instance. Are you guys in your front end, I guess, to use it an analogous term to a traditional building automation system, are you guys adding in analytical capabilities, like fault detection, diagnostics and that type of thing? And how are you thinking about that?
Deep: [00:53:59] Absolutely. So, I mean, all the analytics are built in. The slight difference, I think versus SkySpark is the SkySpark allows those rules to be set or sparks, which gets right. And they're highly customizable. We've tried to do that out of the box. Right? I think we have the luxury in our case that we already know what those FDD pieces are going to be.
So like with GPC 36, of course they have their own concept of what the FDD should be. And that's already built into that product. And. What's kind of cool is that every one of the-, again, back, I go giddy over this so kudos to Brian, as you said, and gang, but I mean, even all our analytics and FDDs are all making Haystack calls, right?
So it becomes, that allows you to scale, right that allows you to specifically, if you have equipment which has been replicated. Right. You don't have to do that for each and every point; now you just have to do it for the tags that match that value. And I mean, that to me is, is the true value.
Like if you go shoe shopping or if you go to best buy, we use tags all the time, right? You go search for TV. Then you go search for 40 to 50 inch. You're searching for a price point between $400 to $700. And if you look at what, if you go to their site, that's what they do. They really put those tags right at the top as a filter map, filtering mechanism. Right? And to me, it's the beauty of what Haystack has really done.
And we really took it to heart as like, go all the way in and make sure that every algorithm, every FDD, even our customized code sequences, we call it Iott. Like if this, then that logic uses the same concept. It's like, if these tags are this value, then do this command.
James: [00:55:48] Got it. So how do you guys deal with-, you mentioned sort of waiting on Haystack 4. How do you guys deal with those sort of limitations to the data model as it exists today?
Deep: [00:55:58] Yeah, I think we've made our own customized extensions for the time being right. I think the primary shortcoming that we found was that in the reference model that it always goes and references one site or one equip and it's not bi-directional. So, so those are some of the limitations that we have in Haystack 3.
So we added more references, which are 75F custom, or just the tags, but more references to like floor or zone, which are constructs, which are not as well defined in Haystack 3 in terms of the reference models.
James: [00:56:30] Got it. Yeah. And I'm assuming you can, whenever the standard gets updated, you guys can just update your model and push updates out.
Deep: [00:56:37] Yeah. That's that's the plan.
James: [00:56:39] Cool. Okay. You mentioned the platform aspect of it too. So I'm thinking there's a thousand different acronyms, but if you think about all the end uses in the building, they have the, digital twin platforms coming out where you're pulling in HVAC and lighting and access control and elevators and everything down the line.
So how are you guys viewing how 75 F connects with those types of platforms or are you viewing 75 F as that type of platform? Or is it both?
Deep: [00:57:09] I think it's the last it's it's both, right. Okay. So obviously we're talking about much larger buildings, right? Class A buildings, so some folks have already implemented, what we call a true building intelligence system or IBS as sometimes they call it. Right. So for those folks, I mean, we would feed, be the authoritative reference source for the HVAC lighting and space management. So those are, that's how we look at it. Those are the three key parameters that we look at. We do good on lighting on the HVAC side and also space management, figuring out which parts are being utilized.
For folks who are looking for other data sources to come in. I mean, we welcome it. I mean, we have a very scalable database model, whether it's just for a building or even for OEMs. Right? So the whole piece was that we were originally quite monolithic in terms of a tech stack, but we just launched this in April. Now it's the new renatus version, we call it and with Athena as our cloud, but it's highly modular, which is what allows the public private deployments. It also allows for us to work with OEMs who perhaps want just the ML layer or they want the database layer, right. Or they want just, if you want GPC 36, right? If you, if there's OEMs out there who don't want to run their own version of GPC 36, all they really care about is if they're Haystack compliant, well you can just take our algorithms and put it on there. Right.
Well idea was that it's not just GPC 36. We want to do the converse as well. If someone's come up with a better way of doing GPC 36 or their own custom way of sequences, right? It's a hundred percent compliant Haystack layer underneath on the hardware side. All you got to do is write an algorithm which uses Haystack, right. It's as easy as that.
James: [00:59:04] Yeah. So do I hear you correctly that those three verticals, HVAC, lighting space management, are you guys planning on expanding beyond that? Or could you pull in data from other verticals or is that kind of where you're headed? You don't have to tell me this, by the way, this is roadmap stuff.
Deep: [00:59:22] It's not; it's public roadmap stuff. We're definitely putting in data from other places as well.
James: [00:59:27] Right. Okay.
Deep: [00:59:28] So the whole point is all about API level integration. The sky's the limit in terms of what we can do over there.
James: [00:59:35] Okay. And would that include like other legacy BAS, or are you pulling in other hardware to pull into the platform?
Deep: [00:59:44] We will be soon. We have not, we've got some orders, customer deployments where we, are going to be doing that.
What we're really doing is we using a BACnet to Haystack data pump. Right, because that's already commercially available. So rather than us trying to reinvent that whole piece about-, so we are just, you know, I keep dissing BACnet, but I mean, we are BACnet compliant, so we have BACnet server. Right. And we've implemented it just because of the interruption. If you are in a larger building and you already have a, BAS, which is BACnet. I mean, there's no reason that we should be excluded from that. Right? So specifically we go into like a large building, which a tenant might actually want to put us in.
So you can go put it in for that one tenant. And then you just expose ourselves using the BACnet interface to the rest of the building.
James: [01:00:33] Okay.
Deep: [01:00:33] Right. So that's a, that's a possibility what we have not done is include direct BACnet client functionality. So taking in legacy hardware and trying to integrate it back, because to me that's a lot of work it's manual. It goes against the ethos of like trying to make this out of the box.
James: [01:00:53] Yeah. So I think what I'm hearing is if say a client has 12 different types of BAS across their portfolio, but then they decide, Hey, in the 75 F building we have over here, we really like their software layer. I mean, most traditional building automation system, software layer is poor as talked about, and I've talked about endlessly over the last few months. but what if they say, okay, we really like 75F software and we want to deploy that across all of our whole portfolio without replacing all the hardware underneath and all the other buildings.
And they want to do things like standardize their schedules, standardize their set point, standardized their sequences. Is that a direction you guys are headed and can you do that today?
Deep: [01:01:36] We can't do it natively, but we can with the data pump, right? So on BACnet. So you would have a BACnet to Haystack converter, which would allow that first layer of mapping. And then we would talk Haystack API to API, to the data pump.
James: [01:01:52] To the data pump. Okay. And so you could send overrides in whatever you wanted to do.
Deep: [01:01:57] Exactly. Yep.
James: [01:01:58] Okay. Alright, well, we've got about, I don't know, a couple of minutes left here, so I want to ask about services. So how are you guys like going to market today? And specifically I'm wondering, the BAS service contract is something that I kind of wanted to dig into next for Nexus. And so it's kind of on my mind, and I wonder, how you guys are thinking about servicing your hardware and software in a new way.
Deep: [01:02:25] That's an interesting, I mean, that's part of the whole innovation, So two things that we do is we work with existing control guys, or even mechanical contractors to go service their existing customers. We also do work directly with large enterprise customers ourselves directly as well, right? So, but general preferences, if it's one offs, then we would actually go use the same existing service relationship that they have with their service contractor. I mean, we are not here to try to disrupt that piece.
What's kind of interesting is because of the fact that we are all IoT and we have our own NOC for monitoring all of our deployments, what we do is we allow the white labeling of the monitoring service and that's kind of interesting thing, right? So if you're a smaller shop and you don't have a full NOC, right. You could actually basically take our, get managed services from us, but put it under your own umbrella.
So you would end up getting the mechanical contractor or the service contractor would actually end up saying here's the service contract to their own customer, but we would be providing it, servicing it in the backend. Right. And what's kind of interesting with that is because we have so much data coming in, I mean, we can actually dive back directly and send out service tickets as well to dispatch mechanical guys if needed. So it's an interesting piece in terms of the managed services part, what this allows us to do so that you can be far more proactive, right. Because the NOC is running all the time.
James: [01:03:55] Wow.
Deep: [01:03:55] So it's truly a network operating center, which is like looking at all the buildings, looking at all the data and all the loads which are coming in.
James: [01:04:04] Okay, cool.
Deep: [01:04:06] Also some of our customers, like in some places it's mandatory to have a engineer onboard 24/7 for some critical facilities, right. But they petition cities and counties to get waivers without getting the specific customers that the engineer only needs to be there during the day shift. And during the evening and the night shift, it actually gets pushed over to the NOC.
So we provide the managing and the observation of making sure that the building, the critical facility is running correctly. And in case someone needs to dispatch, we can do that proactively.
James: [01:04:38] Okay, cool.
Deep: [01:04:40] But one of the things that we've had a fair amount of success with is, is OEMs of equipment.
Okay. Right. So you have the big guys, you have the Carriers, and you have the Tranes, and JCI who have their own controls. But you also have a large number of people who are making HVAC equipment, but who don't necessarily have their own controls line. And for those, I mean, we have really started becoming an OEM out of the box because now it's a huge differentiator, right?
No longer do you actually have to rely on someone else to do that system integration because it's now working out of the box. And so as a packaged solution especially for these midsize buildings that you're talking about under 200,000 square feet. I mean, it's a huge differentiator.
James: [01:05:24] Totally. What would be an example of a piece of equipment that, you know, you could then just, it comes natively with a 75 F controller,
Deep: [01:05:33] Dual cool, swamp coolers, things like AHUs, a lot of customized AHU folks out there, right? Small RTU guys. So we don't do the equipment control, but we provide the building control aspect of it. Right. So we wouldn't necessarily go in and replace an RTU controller itself, but we would go and interact with that RTU controller and make sure that they have, they basically are making it IoT enabled.
James: [01:06:00] Okay. So a smaller building that only has, you know, five RTUs, and then you'd throw a 75F building controller. And now all of a sudden it has all the intelligence that-.
Deep: [01:06:10] Yeah.
James: [01:06:11] Okay, cool. I love that. Alright. So the only thing we didn't hit was on the hardware layer. So I got a couple more minutes as long as you do.
So like what makes a good hardware layer since you guys-, the same kind of question as earlier, you guys designing it from scratch, how did you approach that?
Deep: [01:06:31] Biggest thing was like, I mean, all digital. Right. It's like no sensor is analog. So you're always look for sensors, which are, I mean, it starts truly with the sensors. Right? You want to make sure that you get sensors, that don't require calibration, that don't drift. Right. And so if you start with that technology, I mean, then you're assured that it cuts down not only your calibration in the factory, but also in the field. Cause that's super expensive stuff. Right, right.
And so the second thing that we took on is that like, In my aspect was that, I mean, throwing all the functionality that you think you'll ever need into the hardware right upfront, right. Don't chance on it, don't say, Hey, can I save this? I don't know the small module. And like, we've got BLE, IR blasters so much other stuff, which is like this out there.
And we keep adding new services because it's software upgradable. Right. So let's go in all of this stuff, even if we don't think that we're going to be. We know what, what we're going to do with it right now. So
James: [01:07:35] Sensors too, right?
Deep: [01:07:37] Absolutely different, different sensors as well. So, and so now we started like in the new generation of hardware, we've actually started throwing in dedicated CO2 sensors as well.
Right. So it's not just derived, but it's like, I mean, those are used to be damn expensive, but I mean, you're saying that it's not even optional. It's like there is part of the product, every zone, every room. Which brings me back, like originally alluded to where 62.1 was. If you go back to where we thought the ventilation rates were, it's purely based on bio fluence from human beings, right back in the mid nineties when there was no sensing technology around that. So I do believe that at some point we can show ASHRAE data that with intelligent sensing, you perhaps don't need fixed ventilation anymore, as an example.
Yeah. So the hardware layer, in my opinion, is it needs to have all the sensing, all, all the functionality built in. And the second piece that really needs to do is it needs to, you want to have a consistent platform.
You want to have the same hardware rather than having application specific stuff. In my opinion, that brings down your cost because you're doing volumes. It allows for more reliability because it's the same product. You're not saying, is CO2 sensor optional. Now, is this going to be for a water source heat pump or is this going to feed before a heat pump, right? Or is this a fan coil unit, right? I mean, I think it changes the supply chain game dramatically, and I think in 2020, that's where we should be.
James: [01:09:08] Got it. Cool. Well, thanks for this conversation. I learned a ton, so thanks for, thanks for coming on the show.
Deep: [01:09:16] Thank you so much for having this. I'm glad you're doing what you're doing in general. It's always nice to listen. And so I'm looking forward to the next, next episode as well as you said.
James: [01:09:26] Awesome. Well, we'll talk soon.
Deep: [01:09:28] Sounds good. Take care. Thanks.
James: [01:09:30] 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.