Daniel sent us this one — he's been thinking about hotels. Not the thread count or the breakfast buffet, but what's actually behind the wall when you tap that sleek glass panel to dim the lights or adjust the thermostat. He's asking what serious buildings use when they integrate smart technology — not the buggy home assistant stuff, not Zigbee or MQTT, but the industrial-grade systems that actually run a hotel. What hardware, what software, who installs it, and how it scales from a boutique property to a global chain. And he's right — this is a completely different world from what most people imagine when they hear "smart room.
It connects directly to something we talked about ages ago — why airports don't use smart bulbs. Same principle, different building type, but hotels add this fascinating twist: the guest needs control. In an airport, the passenger doesn't get to dim the gate area. In a hotel, you absolutely get to set your own thermostat, but you also can't be allowed to, say, lock out the fire alarm or reprogram the elevator. That tension between guest control and building integrity is what makes hotel systems uniquely interesting.
Also, quick note — DeepSeek V four Pro is writing our script today. So if the prose is unusually crisp, now you know why.
Welcome aboard, DeepSeek. Don't let Corn nap through the whole episode.
I make no promises. So where do we even start? Because Daniel's right — most people's mental model of "smart building" is a few Alexa speakers and some Philips Hue bulbs that disconnect when the WiFi blinks. Hotels are not running on that.
They're absolutely not. When a hotel deploys "smart room" technology, they're not buying consumer products and hoping for the best. They're buying what's called a Guest Room Management System, or G. These are dedicated, purpose-built systems that have been around in some form since the nineteen eighties, though they've obviously evolved enormously.
So it's a whole category. Who are the main players?
The big one historically is INNCOM, now owned by Honeywell. They've been doing this since the mid-eighties and they're in over a million hotel rooms globally. Their flagship product line, the INNCOM e-squared, is a modular system that handles lighting, HVAC, drapery control, occupancy sensing, and door monitoring all through a central processor in each room. Every room has its own dedicated controller — a small embedded computer — that talks back to a central server.
It's distributed intelligence. The room still functions if the central server goes down.
That's the fundamental architectural principle. Each room controller is autonomous for local functions. If the network link to the front desk dies, the guest can still control the lights and the temperature. The system degrades gracefully rather than failing catastrophically. That's the opposite of how most home smart systems work, where if the hub goes offline, everything becomes a dumb switch — if you're lucky.
This is where the home versus industrial distinction really bites. In a consumer system, the cloud is the brain and the devices are just endpoints. In a hotel, the room is its own brain, and the central system is more like a nervous system that coordinates across rooms.
It gets more interesting when you look at how these things communicate. Daniel mentioned we're not talking Zigbee or MQTT here, and he's right — but it's worth explaining why. Zigbee is not a bad protocol in principle. It's a low-power mesh networking standard used in plenty of commercial applications. The problem is that in consumer deployments, it's often poorly implemented, with cheap radios and interference from WiFi on the same two point four gigahertz band. Hotels can't afford that kind of flakiness.
What do they use instead?
The dominant approach is wired communication for anything critical. INNCOM systems, for example, use a proprietary protocol over a dedicated RS-four-eighty-five bus — a serial communication standard that's been around since the eighties and is rock solid in industrial environments. It's a differential signaling system, highly resistant to electrical noise, and can run over twisted pair wiring for thousands of feet without a repeater. Each room controller connects to a floor-level network bridge, and those bridges connect back to the central server over standard Ethernet.
It's a tiered architecture. Room controller talks to floor bridge, floor bridge talks to central server. And the room-to-bridge link is not Ethernet, not WiFi, not anything a guest could accidentally interfere with.
The RS-four-eighty-five bus is completely isolated from the guest network. A guest can't even see it, let alone mess with it. It's physically separate wiring, often run through conduit alongside the high-voltage electrical. The only thing the guest interacts with is the user interface — the thermostat on the wall, the light switches, the glass panel in the bathroom that Daniel mentioned.
Let's talk about those interfaces, because that's where the guest experience lives. Daniel mentioned "electrical glass things" in bathrooms — he's talking about switchable privacy glass, where you press a button and the glass goes from transparent to frosted. That's not a consumer product either.
No, it's not. Switchable privacy glass uses polymer dispersed liquid crystal, or P. Liquid crystal droplets are suspended in a polymer film between two layers of glass. With no voltage applied, the crystals are randomly oriented and scatter light, making the glass opaque. Apply a voltage, the crystals align, and the glass becomes transparent. The whole thing is controlled by a dedicated driver unit integrated into the room's G.
This isn't a novelty add-on. Hotels install this as a standard feature in higher-end properties because it solves a real design problem — an open-plan bathroom that feels spacious, but the guest can still get privacy. No blinds, no curtains, just a button.
From a systems perspective, that button is not directly wired to the glass. It goes through the room controller, which means the hotel can program behavior. For example, some systems automatically switch the glass to opaque when the room is unoccupied, or integrate with the booking system so that when a guest checks in, the glass defaults to transparent to make the room feel welcoming. That level of programmability is what separates a G. from a bunch of smart devices cobbled together.
That's a great example of the hub and spoke model Daniel was asking about. The room controller is the hub, and all these different subsystems — lighting, HVAC, privacy glass, motorized drapes, door locks, occupancy sensors — they're all spokes. The guest sees a unified experience, but underneath, each spoke might be a completely different technology from a different manufacturer, all coordinated by that central room controller.
That brings us to another key player: Lutron. Most people know Lutron for their high-end residential dimmer switches, but they have a massive commercial division that does hotel lighting control. Their systems, like Lutron myRoom plus, integrate directly with the major G. So the hotel might spec an INNCOM controller for overall room management, but use Lutron for the actual lighting ballasts and dimmers, because Lutron's hardware is best-in-class for that specific function.
It's not a monolithic system from one vendor. It's an integration job. Different specialists for different subsystems, all tied together by the G.
And this is where the skill set Daniel was asking about comes in. Setting up a hotel smart system is not something a general electrician can do. It requires a systems integrator who understands not just the hardware, but the software configuration, the network architecture, and — crucially — the hospitality workflow.
What does that mean in practice?
It means the system has to understand the operational logic of a hotel. When a guest checks in, the front desk system — the property management system, or P. — sends a signal to the G. to switch the room from "unoccupied" to "occupied" mode. That changes the HVAC setpoints, enables the lighting scenes, and might trigger a welcome sequence — lights fade up gently, drapes open, thermostat adjusts to a comfortable preset. When the guest checks out, the room goes into "vacant" mode: lights off, HVAC set back to energy-saving levels, privacy glass defaulted to opaque. All of this happens automatically, driven by the integration between the P. and the G.
That integration is not trivial. You're connecting two completely different software systems — one that handles reservations, billing, and housekeeping, and another that handles physical hardware in hundreds of rooms. If that integration breaks, you've got rooms that don't know they're occupied, thermostats running in the wrong mode, and guests walking into dark, stuffy rooms.
And the hotel industry has learned some hard lessons. In the late nineties and early two thousands, there were spectacular failures where hotels installed cutting-edge systems that looked great on paper but crashed constantly. The issue was almost always integration complexity — too many vendors, too many protocols, not enough testing. The industry has since consolidated around a smaller number of proven platforms and standard integration patterns.
What are those integration patterns? Daniel specifically asked about the actual systems being deployed.
The most common integration standard in hospitality is B. net — Building Automation and Control Network. It's an open protocol specifically designed for building automation, and it's an ISO standard. Most major G. platforms speak B. net, and so do the major P. vendors like Oracle Hospitality, which used to be Micros, and Amadeus.
net is the common language. But you mentioned earlier that INNCOM uses a proprietary protocol over RS-four-eighty-five for room-level communication. How does that square with using an open standard?
This is pragmatic engineering. net is used for high-level integration — between the G. server and the P. , or between the G. and the building's main HVAC plant. But at the room level, where you need very fast, very reliable communication between the controller and the thermostats, switches, and sensors, many vendors use their own protocol because they can optimize it for their specific hardware and guarantee performance. The floor bridge acts as a translator — proprietary protocol on the room side, B. net or standard Ethernet on the building side.
That's clever. It means the integrator can swap out one vendor's room controller for another without redoing the entire building-level integration, as long as the new controller speaks B. net on the upstream side.
In theory, yes. In practice, it's never quite that clean, but the principle holds. And this modularity becomes even more important when you scale from a single property to a chain.
Right, Daniel asked about that — going from a few hundred rooms up to a major chain with thousands of properties. What changes at that scale?
At the chain level, you get an additional layer of management. Individual hotels have their own G. server on-site. But the chain might deploy an enterprise management platform that sits above all of those individual servers, providing centralized monitoring, analytics, and configuration management. The big players here are companies like Schneider Electric with their EcoStruxure platform, and Siemens with their Desigo C.
What does that enterprise layer actually do? Is it just dashboards, or is there real operational value?
There's enormous operational value. The most immediate is energy management. A major hotel chain might spend tens of millions of dollars a year on energy. If you can reduce that by even five or ten percent through centralized HVAC optimization, that's real money. The enterprise platform can analyze occupancy patterns across hundreds of properties, identify rooms or entire hotels where the HVAC is running inefficiently, and push updated setpoint policies globally.
It's not just about guest experience — it's about the balance sheet. But I'd imagine there are also maintenance benefits.
Huge maintenance benefits. The enterprise platform can monitor the health of every room controller, every thermostat, every lighting ballast. If a particular model of dimmer is showing elevated failure rates across the portfolio, the chain can proactively replace them before guests complain. They can also push firmware updates centrally rather than having a technician visit every room. And when something does break, the system can generate a work order automatically and dispatch it to the right maintenance team.
This is starting to sound less like a smart home and more like an industrial control system — which, of course, it is. But there's one thing I want to dig into: security. In a home, if someone hacks your smart lights, it's annoying. In a hotel, if someone hacks the G. , they could potentially control door locks across an entire property.
That's the nightmare scenario, and the industry takes it very seriously. The key principle is network segmentation. network is physically or logically separate from the guest WiFi network, the point-of-sale network, and the corporate I. In many properties, it's an entirely air-gapped network with no internet connectivity at all. The room controllers communicate over that isolated network, and the only bridge to the outside world is through the B. net interface to the P. , which itself is heavily firewalled.
Air-gapped networks are harder to maintain remotely, which you just said was one of the benefits of the enterprise layer. There's a tension there.
There is, and different chains resolve it differently. Some use a unidirectional data diode — the G. can send telemetry out to the enterprise platform, but no commands can flow back in. That gives you monitoring without the remote attack surface. Others use a dedicated V. tunnel with multi-factor authentication and session recording, so every command is auditable. The approach varies, but the underlying philosophy is consistent: the guest room network is treated as a secure operational technology environment, not as an I.
Operational technology — O. That's the term of art, right? As opposed to information technology.
is the world of industrial control systems, S. , programmable logic controllers — the stuff that runs factories, power plants, and, increasingly, smart buildings. The mindset is completely different from I. , you prioritize confidentiality — keeping data secret. , you prioritize availability — keeping the system running. A hotel room that can't turn on the lights because of a security patch is a bigger problem than a hotel room whose lighting data might theoretically be intercepted.
That's a really useful distinction. So who actually does this work? Daniel asked about the specialized skill set. Is this electricians, software engineers, or something in between?
It's a niche role called a building systems integrator or a hospitality technology specialist. These are companies that typically start as either electrical contractors who've developed software expertise, or control systems engineers who've learned the hospitality domain. The big names include companies like A. Control Systems, which does large-scale hospitality integration, and smaller regional firms that specialize in specific hotel brands.
I'd imagine the hotel brands themselves have approved vendor lists and certification programs.
If you want to install G. in a Marriott property, you need to be certified by Marriott's engineering and facilities team. Same for Hilton, Hyatt, Accor. These certifications are not trivial — they involve training on the specific hardware and software stacks the brand has standardized on, as well as the brand's operational requirements. A Marriott Courtyard has different system requirements than a Ritz-Carlton, even though they're both Marriott properties.
That makes sense. The guest expectations are different, the room configurations are different, the operational workflows are different. But what about the actual hardware in the room? You mentioned INNCOM and Lutron. Who else is in this space?
Another major player is VingCard, now part of Assa Abloy. They're best known for electronic door locks — those RFID card readers you tap to enter your room — but they've expanded into full room energy management. Their system uses the door lock as the occupancy trigger: when you insert your key card into a slot by the door, it activates the room's power and HVAC. When you remove it to leave, everything goes into energy-saving mode.
That key card slot is actually a clever bit of passive occupancy sensing. It's not perfect — guests sometimes leave a spare card in the slot to keep the A. running — but it's simple, reliable, and requires no sensors that could fail.
And the newer systems supplement or replace the card slot with actual occupancy sensors — passive infrared or ultrasonic — that detect whether a person is in the room. The combination of door lock state, occupancy sensor data, and P. status gives the G. a very reliable picture of whether the room is occupied, vacant, or in a "do not disturb" state.
Let's talk about the user interface side. Daniel mentioned the thermostat, but modern hotel rooms have moved way beyond a simple thermostat on the wall. What's the state of the art?
The trend over the last five years has been toward multi-function touch panels that consolidate all room controls into a single interface. Instead of separate switches for lights, drapes, temperature, and privacy glass, you get one panel — often a seven or ten inch touchscreen — that controls everything. Some are custom-designed for specific hotel brands, with the brand's visual identity baked into the user interface.
This is where the guest experience design gets interesting, because a touch panel can do more than physical switches, but it can also be more confusing. A light switch is universally understood. A touch panel with nested menus is not.
That's a real tension in the industry. Some hotel brands went all-in on touch panels and then pulled back after guest complaints. The sweet spot seems to be "tactile first" design — physical buttons for the most common functions like master lights and temperature up/down, with a touchscreen for secondary functions like drape position or scene selection. The best systems give you both.
From a reliability standpoint, physical buttons are inherently more robust. If the touchscreen controller crashes, the guest can still turn the lights on and off with a physical switch wired directly to the lighting circuit, bypassing the G. entirely for that basic function.
That's actually a code requirement in many jurisdictions. Life safety functions — emergency lighting, fire alarm interfaces — must work even if the smart system fails completely. can enhance and coordinate, but it cannot be a single point of failure for anything safety-critical.
Which brings us back to the core principle: graceful degradation. The system is designed with the assumption that components will fail, and when they do, the room should still be habitable and safe. That's a fundamentally different engineering philosophy from consumer smart home products, which tend to assume everything will work and fall over completely when it doesn't.
This is where the cost difference becomes stark. A consumer smart thermostat costs maybe a hundred fifty dollars. A commercial-grade hotel thermostat from INNCOM or Schneider Electric can cost five to eight hundred dollars per unit. The room controller itself might be another five hundred to a thousand dollars. A full G. deployment for a three hundred room hotel can easily run into the mid six figures, before you factor in the integration labor.
When you amortize that over the life of the system — which in hospitality is typically ten to fifteen years — and factor in the energy savings and operational efficiencies, the return on investment is usually there. Hotels aren't doing this for fun. They're doing it because the math works.
And the math works even better at scale. A chain like Marriott or Hilton can negotiate volume pricing on hardware, standardize the deployment process, and spread the integration engineering costs across hundreds of properties. The enterprise management layer also means they can optimize energy usage across their entire portfolio in ways a single independent hotel simply can't match.
Let's circle back to something Daniel mentioned — the hub and spoke model. We've talked about the room controller as the hub for the room's subsystems. But in a hotel, there's also a building-level hub that coordinates across rooms, and potentially a chain-level hub that coordinates across properties. Is that a fair characterization?
It is, and it's worth making that explicit because it's exactly the model Daniel was asking about. At the room level, you've got the room controller. At the property level, you've got the G. server, which might be a physical server in the hotel's equipment room or increasingly a virtualized instance running on the hotel's I. At the chain level, you've got the enterprise platform. Each layer has its own scope of control and its own failure domain.
The communication between layers is designed to be asynchronous and resilient. If the property server loses connection to the enterprise platform, the hotel keeps running. If a room controller loses connection to the property server, the room keeps running. Each layer caches the last known good configuration and continues operating independently.
This architecture is sometimes called "loose coupling" in systems design, and it's one of the reasons these systems are so reliable. Tight coupling — where every component depends on every other component being available — is fragile. Loose coupling is resilient. Consumer smart home systems tend to be tightly coupled, which is why they break so often. Hotel systems are loosely coupled by design.
There's a lesson in there for anyone designing distributed systems. But let's get specific about the protocols, because Daniel seemed genuinely curious about what's running on the wire. We've mentioned RS-four-eighty-five and B. What else is in the mix?
Another important protocol is D. — Digital Addressable Lighting Interface. It's a dedicated protocol for lighting control, used extensively in commercial buildings including hotels. allows individual light fixtures to be addressed and controlled independently over a two-wire bus. What's interesting is that the bus provides both power and data, so you don't need separate power supplies for the control electronics in each fixture.
How does D. interface with the G.
Typically through a D. gateway that translates between D. commands and whatever protocol the G. uses — often B. net or Modbus. doesn't need to speak D. It just tells the gateway "set room three twelve to scene two" and the gateway handles the individual fixture addressing.
Modbus — that's another industrial protocol, right? Very old, very simple.
Modbus dates back to nineteen seventy-nine. It was developed by Modicon for their programmable logic controllers. It's incredibly simple — basically just read and write operations on registers — and that simplicity is why it's still widely used. It's easy to implement, easy to debug, and rock solid. In hotel systems, you'll often find Modbus used for communication with HVAC equipment, especially the variable air volume boxes that control airflow to individual rooms.
We've got RS-four-eighty-five as the physical layer, and on top of that you might have Modbus, B. net, or proprietary protocols. for lighting, and standard Ethernet for the backbone. It's a layered stack, but each layer is chosen for a specific purpose, not because it's trendy.
And that's the fundamental difference from the consumer world. In consumer smart homes, protocol choices are often driven by what's popular or what works with a particular ecosystem. In hospitality, protocol choices are driven by reliability, determinism, and long-term maintainability. Nobody cares if the protocol is cool. They care if it works for twenty years without surprises.
Twenty years is a long time in technology. How does the industry handle obsolescence? If a hotel installs a G. today, what happens when the manufacturer discontinues a component five years from now?
This is a real challenge, and it's one of the reasons hotels tend to stick with large, established vendors. Companies like Honeywell, Siemens, and Schneider Electric have a track record of supporting their building automation products for decades. They also design for backward compatibility — a new generation of room controller will work with the existing thermostats and sensors, so the hotel can upgrade incrementally rather than rip-and-replace everything at once.
Again, a very different design philosophy from consumer products, where the expectation is often that you'll replace the whole system every few years.
There's an emerging trend that's going to make this even more interesting: the move toward I. -based room controllers. Instead of using RS-four-eighty-five for the room-level bus, newer systems are using standard Ethernet all the way to the room, with each device getting its own I. This opens up possibilities for more sophisticated functionality, but it also introduces new security and reliability challenges that the industry is still working through.
I can imagine the security team's reaction to the idea of every thermostat having an I. That's a lot of attack surface.
It is, and the industry is being cautious. The current best practice for I. -based room systems is to put them on a dedicated V. that's completely isolated from the guest network and the internet. The room devices can talk to the G. server and to each other, but they can't initiate connections to the outside world. It's essentially a private network that happens to use Ethernet as the physical layer.
That's probably the direction the industry is heading. Ethernet cabling is cheaper and more widely understood than RS-four-eighty-five, and I. networking skills are easier to hire for. But the transition has to be managed carefully.
There are hotels running G. installations that are fifteen or twenty years old and still working fine. The industry doesn't move fast, and that's a feature, not a bug. When you're responsible for the comfort and safety of hundreds of guests every night, you don't experiment with unproven technology.
Let's talk about the guest data side, because there's an interesting privacy dimension. These systems know when you're in the room, what temperature you prefer, whether you've got the "do not disturb" sign on. In a chain hotel, that data could potentially follow you from property to property.
It can, and some chains are doing exactly that. If you're a frequent guest at a particular brand, your preferences — preferred room temperature, lighting scenes, even pillow type — can be stored in your loyalty profile and automatically applied when you check in at any property. pulls your preferences from the central reservation system during check-in and configures the room accordingly before you even walk in.
That's either delightful or slightly unnerving, depending on your perspective. Personally, I'd appreciate walking into a room that's already set to my preferred temperature. But I can see why some guests might find it creepy.
The industry is aware of the creepiness factor, and most chains are careful to frame it as a convenience feature that you opt into, not something that happens without your knowledge. The data is also typically limited to room preferences — not behavioral data like when you sleep or how long you spend in the bathroom. There are legal constraints too, especially in Europe under G. , where room occupancy data could be considered personal information.
has some specific implications for hotel systems. Occupancy sensor data — if it's detailed enough to reveal patterns about a specific identifiable guest — could be subject to data minimization requirements. The hotel has to justify why they're collecting it and how long they're keeping it.
Most chains have responded by anonymizing or aggregating the data at the property level before it ever reaches the enterprise platform. Which is probably good engineering practice anyway. You don't need per-guest granularity to optimize HVAC schedules. Aggregated occupancy patterns are sufficient.
Where does all this leave the independent hotel? Daniel asked about the spectrum from a few hundred rooms up to a major chain, but what about the boutique property with fifty rooms and no corporate I.
That's a tough spot. The full enterprise G. stack is overkill for a small property, both in cost and complexity. But there are scaled-down solutions. Companies like Control four and Crestron, better known for high-end residential automation, have hospitality-specific offerings that are more accessible to smaller properties. They're not as robust as the Honeywell or Siemens systems, but they're also a fraction of the cost.
I'd imagine there are also cloud-based solutions emerging for the independent market, where the room controllers are simpler and the intelligence lives in the cloud, reducing the on-site infrastructure requirements.
That's definitely a trend. Startups like Virdee and Ariane Systems are offering cloud-based check-in and room control platforms that integrate with off-the-shelf smart devices. The trade-off is that you're more dependent on internet connectivity and a third-party service, but for a small property that can't afford a dedicated on-site server and a systems integrator, it's a viable option.
Though I'd worry about what happens when the internet goes down. If your room controls depend on a cloud service, and the hotel's internet connection fails, you've got a building full of guests who can't adjust their thermostats.
That's the exact concern, and it's why the more reputable cloud-based systems maintain local fallback. The room controller — even if it's a simpler, cheaper device — still has enough onboard intelligence to run basic functions without a cloud connection. The cloud adds the nice-to-have features, but the must-have features are local.
Even at the budget end, the architectural principle holds: local control for essential functions, cloud for enhancement. The industry has learned that lesson too many times to forget it.
That's really the through-line of this whole discussion. Whether you're talking about a three thousand room Marriott Marquis or a thirty room boutique inn, the fundamental engineering principles are the same: distributed intelligence, graceful degradation, network isolation, and loose coupling. The specific hardware and protocols vary, but the architecture doesn't.
Which brings us back to Daniel's original observation — this is a completely different world from home assistants. And once you understand the architectural principles, you start to see why consumer smart home products fail so often, and why serious buildings don't use them. It's not that the consumer products are badly made. It's that they're designed for a completely different set of requirements.
A consumer smart home is designed for affordability, ease of setup, and integration with a consumer ecosystem. A hotel G. is designed for reliability, security, maintainability, and a fifteen-year service life. You can't optimize for both sets of requirements simultaneously. They pull in opposite directions.
There's a broader lesson here about technology adoption. When people see a technology that works well in one domain, they often assume it can be transplanted to another domain with minimal changes. But the constraints are different, the failure modes are different, and the economics are different. What works in a home doesn't work in a hotel, and what works in a hotel doesn't work in an airport or a factory.
Yet there's cross-pollination. The occupancy sensing techniques developed for hotels are finding their way into office buildings. The energy management algorithms from the hospitality sector are being adapted for retail. The integration patterns are becoming more standardized across building types. So it's not that these are completely separate worlds — it's that you have to understand the specific requirements of each domain before you can adapt solutions from one to another.
Alright, I think we've given Daniel a pretty thorough answer. Hotel smart systems are purpose-built industrial control systems, not consumer gadgets. They use distributed intelligence with room-level controllers, industrial protocols like B. net and Modbus over dedicated wiring, and they're designed for graceful degradation and fifteen-year service lives. The integration is done by specialized firms, and the whole thing is managed through a tiered architecture that scales from individual rooms up to global chains. And the key principle throughout is that the guest gets control, but within boundaries that preserve safety, security, and operational integrity.
That's a solid summary. The only thing I'd add is that this field is interesting from an engineering perspective because it sits at the intersection of so many disciplines — electrical engineering, software architecture, network design, user experience, and even privacy law. It's one of those domains where the complexity is mostly invisible to the end user, which is exactly how it should be.
Great design is invisible. If a guest notices the G. , something has probably gone wrong.
And now: Hilbert's daily fun fact.
Hilbert: The national animal of Scotland is the unicorn. It has been since the twelfth century, when it was adopted as a symbol of purity and power in Scottish heraldry. Scotland is one of the few countries whose national animal does not actually exist.
...right.
This has been My Weird Prompts. Thanks to our producer, Hilbert Flumingtop. If you enjoyed this episode, leave us a review wherever you get your podcasts — it helps other people find the show. We'll be back soon with another one.
