My last column introduced some of the many Connected Hotel applications that can be valuable for hotels, especially in an age of labor shortages. This week, I will cover key questions to ask to decide whether, when and how to deploy them. While my primary focus today is how to move from an unconnected hotel towards a fully connected one, some of the material should be useful even if you are just looking at adding one or two capabilities to an existing infrastructure.

As before, I want to thank the companies who generously contributed their wisdom and experience in this area, including Auverte, Enseo, Honeywell, Interel, Nomadix, PwC, TraknProtect, Transcendent, VDA, and VivoAquatics. It’s a very big field and I couldn’t speak to every company that plays in it, but I believe these are a representative sample and they are all quality companies worthy of a look.

Of course, some hotel brands have established standards for Connected Hotel ecosystems, and these may constrain your options, for better or worse. Nevertheless, the questions and recommendations here may be useful to you in understanding how to get the most out of your solution.

‍

Your Connected Hotel Infrastructure

As mentioned in the previous column, many hotels already have an infrastructure that is usable for Connected Hotel applications. There are three common infrastructures used in hotels. Most hotels will have at least one of these; some may use two or even all three.

First is your existing local area network. It’s theoretically possible to build a Connected Hotel architecture solely on top of this, but more commonly ethernet and Wi-Fi serve alongside one or more of the other infrastructures, for the simple reason that many sensors, switches, actuators, and other edge devices are not IP-enabled. Even if they are, Wi-Fi is comparatively power-hungry, and Wi-Fi-based edge devices will need cabling for power. On the other hand, ones that use protocols like ZigBee or Bluetooth can run on a coin-sized battery for as long as ten years, and most will last at least three.

A second type of infrastructure, commonly found in guest rooms, uses a gateway. This may be a standalone device but is more commonly built into a thermostat, set-top box, or smart bedside device; in the future we may see them incorporated within smart TVs or speakers. One gateway in each guest room connects to edge devices such as door locks, window and balcony door sensors, occupancy detectors, thermostats, flood and water flow sensors, minibars, televisions, telephones, speakers, and smart light switches. The gateway can also communicate with transient devices, such as guest mobile phones and staff panic buttons. The device connections use short-range radio communications protocols like ZigBee or Bluetooth, while the connection to the local area network is via ethernet or Wi-Fi.

The gateway typically orchestrates in-room device coordination. It can, for example, monitor the occupancy detector and door lock to decide that the room is unoccupied, and decide to adjust the thermostat and turn off the lights. This design offers some natural resilience; the room can continue to function even if the main network is down. Many gateways can function outside of guest rooms as well; whether this is practical depends on the available form factors. For example, it may not make sense to use a gateway embedded in a guest-room thermostat for public spaces.

A third type of infrastructure is found in some staff alert solutions. It consists of a network of Bluetooth receivers placed throughout the building; these are often now built into Wi-Fi access points but can be independent. Edge sensors, devices and beacons that support Bluetooth can communicate with these receivers, which are also connected to the local network. Messages are typically passed up the network to a central server (premise or cloud), which receives them, decides what actions to take, and initiates them.

Energy management is often the first Connected Hotel project for many hotels, because the available energy savings (typically 10-30%) can quickly cover the costs. Getting an energy management system (EMS) with the right infrastructure can also greatly reduce the cost of future connected devices and applications, because the infrastructure is already paid for.

Gateways are by far the most common way to implement EMSs. ZigBee and Bluetooth gateways and devices can vastly reduce the amount of cabling required. And since cable installations can be extremely costly, so there is obvious benefit to avoiding them. Most sensors used in guest rooms support ZigBee and/or Bluetooth and now have battery lives in the range of five to ten years, so neither power nor ethernet connections are needed. The gateway device itself will need power and network connections, but the network connection is increasingly accomplished by Wi-Fi, meaning that the entire cabling needed for a guest room should consist of just low voltage power cable for the gateway (such as in a thermostat), and a network connection (which can include power) to the access point in the room or nearby hallway. A bonus that can come with Wi-Fi-connected gateways is the ability to monitor Wi-Fi signal strength in each guest room and for each nearby access point in real time. This can be extremely useful in proactively identifying or diagnosing Wi-Fi issues.

A gateway can also be put into a set-top box used to control the television, and this can make sense especially in an older building where the television signal and Wi-Fi are both distributed over coaxial cable. I would hesitate to select it otherwise, however, as I expect that innovations in smart TVs may soon render set-top boxes obsolete.

It is no longer necessary to choose ZigBee vs. Bluetooth support in the gateway device; most now support both (and often other less common protocols as well). Z-Wave is an older protocol that is often used to support legacy edge devices, but its longer range can make it more difficult to manage when the number of devices gets large. Unlike ZigBee and Bluetooth, Z-Wave does not support the formation of mini-networks for a single guest room, which can simplify setup, administration, and troubleshooting.

Outside the guest room, the gateway principle is similar, but other communications protocols such as Z-Wave and LoRaWAN are sometimes preferred in part because of their longer range; these can be used to monitor and control physically dispersed devices, such as main building control systems or irrigation systems. For more details on protocols, you can consult this comprehensive guide from HTNG.

‍

Gateway Considerations

Many of the considerations for gateway selection are covered in the infrastructure discussion above, but there are additional ones. The gateway typically serves as the “brains” of the Connected Guest Room. You want one that supports not only your current set of devices, but any that you might add in the future, meaning it should have plenty of processing headroom and support the major communications protocols (Bluetooth, ZigBee, and Wi-Fi at a minimum). Backup power may be needed for controls that must work when the power is out; this can often be done with a battery in the telecommunications closet or at the building level and then distributed via ethernet cable.

Gateways are often designed for a single function, such as EMS; whether they will support other applications varies and is an important question to ask (some manufacturers offer gateways in multiple form factors for this reason). Think through all the applications you may want to deploy on the same infrastructure and gateways during a 10+ year lifetime (consult my last blog for a checklist!). For example, it may make sense to put hallway lighting controls, security cameras, or panic buttons on the same gateways as the guest rooms.

Look for gateway providers that have lots of hospitality-specific integrations and functionalities available, and that support open standards and APIs, Be cautious with vendors that may produce devices in high volume for other markets but that cannot point to robust, complete solutions in hotels: the devices may be less expensive and may well work fine for their primary purpose, but they will likely lack the integrations needed to get the most value in a hotel, especially with respect to energy savings. Think through what your options will be if one of your device providers discontinues a product you are using and you have to replace a broken one with something totally different – the more integrations and standards support your vendor has, the less likely this will result in a major expense.

Gateways have software and firmware that need updating; make sure this can be done over the network, so you don’t have to send an engineer to every guest room for each update. Gateways should also be able to push updates to the various edge devices they control, and to report back on the current software and firmware releases installed both in the gateway and its connected devices.

Unless you plan to sell the hotel soon, don’t try to save money by buying units with last year’s ZigBee or Bluetooth standards. Even if the edge devices you have today don’t need the latest version, ones you may need tomorrow probably will; you don’t want to have to replace your gateways in a year or two to take advantage of future functionality.

‍

Sensors, Switches, Actuators, and Valves

The biggest investment in Connected Hotel applications (and also often the biggest payback) comes with sensors, switches, actuators, and valves – the so-called “edge” devices that sense what is happening and/or take specific actions, like turning on a light or shutting off the heat or water. While most of these devices are inexpensive, the quantities can be large; depending on what you try to do, there may be five, ten, twenty, or even more edge devices in each guest room.

As with gateways, support for standards is important. But it’s not enough that the vendor claims they support a standard; you need to look for proof. Independent testing and verification almost always find issues even with the best manufacturers, and good ones want to find and fix them before the product hits the market, not after. Further, many standards have numerous optional capabilities that a vendor may or may not have implemented; knowing which ones you need and whether the vendor supports them becomes critical. Many vendor sales reps know their product supports a standard but may have no more knowledge of it than the statement on the product spec sheet. Many projects have run into costly challenges connecting devices or systems that both support a named standard, but in different ways.

Be sure that your edge devices can accept over-the-air updates to firmware. And as with gateways, be cautious about devices that support older versions of Bluetooth or ZigBee, because you may not be able to take advantage of future enhancements without a full replacement. These technologies will continue to improve rapidly from year to year. The next iteration of Bluetooth, for example, will enable a receiver to know not only how far away a device is from it, but which direction, which will open up a whole host of new applications as well as reducing deployment costs for others.

Don’t even think about installing devices made for residential use. They are not designed to operate in a high-density environment like a hotel, and even if they work, they may overload the radio frequencies and interfere with other devices. Furthermore, the security issues in a home environment are very different than in a hotel, and easily compromised residential devices can be a magnet for hackers.

‍

Coordination, Collection, Monitoring, Management, and Analytics

The infrastructure, gateway, and edge device cover the hardware of a Connected Hotel, but the value is in using the collected data to reduce costs, drive revenue, or improve the guest or staff experience. This means software applications, of course. But how should they be organized?

Depending on your infrastructure, you may have gateways in each guest room, another gateway for the hotel, and a cloud-based service as well. The key is to map out which devices need to communicate with which others and to ensure that they can do so via a single known point (gateway or cloud host). If a device needs to communicate with another device that is not connected to the same gateway, then it should communicate through its gateway rather than directly. Without this principle, you will end up with an unsupportable spaghetti network of connections.

This is in part why most designs use a single gateway per guest room, which provides all the connectivity to and from the edge devices within the guest room, as well as to guest mobile devices/apps and staff panic alert devices. The gateway can then handle all the orchestration of devices within each room in an isolated and easily managed network. It can also ensure that critical room functions can continue if centralized parts of the network or system fail. If a guest room device needs to connect to a device outside the guest room, the gateway should handle that communication on behalf of the edge device.

Outside the guest room, a gateway may be an onsite server, or virtual and cloud hosted. The choice depends on network reliability and how critical the functions are that the gateway is controlling. Life-safety systems may be better managed by local gateways so that they can continue to function normally in the event of a network outage. Other approaches rely on network redundancy, such as failover from Wi-Fi to cellular networks.

The next questions are what data to collect and where to store it. If you are buying a complete system from a single vendor, such as EMS or a Building Management System (BMS), then some of these decisions may be baked into the solution, others may depend how it is configured. But either way, your ability to achieve specific results can depend on the design. You may have thousands of devices connected, each one capable of reporting its status every second or less; that’s a lot of data! How much you keep, and for how long, can significantly impact total costs.

A common technique is to filter the captured data at each gateway, passing up to the next layer the summary data that is needed to accomplish specific monitoring, reporting, alerting, or analytical objectives. With energy management data, for example, the system may poll sensors every second, but only send up a few summary statistics to the gateway once a minute (or when a more urgent event is detected). A premise-based gateway or cloud service just needs enough data to detect system anomalies and to provide the necessary dashboard reporting, alerts, and analytics. It can be useful for the filtering algorithm to be configurable, so that if your needs change and you require more data, you can easily get it.

Another important question is what network your Connected Hotel uses to move data between gateways, and how that network is managed. Depending on design, you may be adding a lot of traffic to your existing network. That can impact the guest Wi-Fi experience, televisions and telephones, and hotel operations running on the same network. If you do add new Connected Hotel capabilities to an existing network, be sure to monitor the impact and be prepared to add capacity, network management capabilities, or both, to manage any unwanted side effects. A professional network management service, such as the ones many hotels use to manage their existing Wi-Fi networks, can help ensure the right solution. In other situations, an EMS or BMS may run on a separate network. This can help to reduce conflict and improve manageability but may make it more difficult to add new Connected Hotel applications later, since devices that need to talk to each other may be isolated on separate networks. It may also limit some future applications to ones your EMS or BMS provider is willing to support.

In most cases it will make sense for a Connected Hotel to have a cloud-based Network Operations Center (NOC) monitoring the system; this may be provided by an EMS or BMS provider, by the same company providing the hotel’s high-speed internet infrastructure, by a management company or brand, or by a third party specializing in connected building technologies. While it is theoretically possible for a hotel to provide this monitoring itself, the track record for self-management is poor. The systems are complex, are outside the skillset of most hotel engineering and even IT staff, and they tend to lose much of the benefit (especially energy savings) unless they are monitored by companies that know what to look for. Staff turnover at hotels compounds the challenges of self-management.

However you manage it, your NOC should be able to detect, in more or less real time, the status and/or state of every connected device, its current firmware level, and any alarms or error conditions. A technician should be able to pull this up on demand, as well as to get automated alerts or alarms for abnormal situations. It should be possible to clear alarm states remotely, to initiate firmware updates and, for controllable devices, to manually modify their state (turn a light switch on or off, change the set point on a thermostat, etc.). The critical thing to avoid is needing to send field technicians onsite, as this both increases the cost of supporting the solution and can significantly increase the time to resolution.

Good NOC software and dashboards can do most of the central monitoring and management with little or no ongoing human interaction. They may be able to automatically open maintenance tickets or work orders in a preventive management or work order management system, or they may perform ongoing analysis to ensure that the energy savings from an EMS are not deteriorating over time. The NOC software should ideally be able to integrate alerts from key legacy systems without a human having to intervene. Some can, for example, be set up to receive alerts from a legacy system that can only send notifications by email. They monitor the email box and parse, analyze, and convert the contents of anything that comes in. They can then take actions much in the same way as if they were monitoring the system in real time.

When human intervention is required, the best systems offer flexible workflow management tools that can perform different actions. A particular type of issue can cause notification to the right department, whether automatically through an interfaced system or through traditional communications channels like email or text message. Depending on urgency, multiple notifications may be needed, or they may need to go to everyone in a particular department as opposed to just one person. Escalation workflows should be flexible so that depending on the type of issue, its urgency, and even such factors as the VIP status of the affected guest, unaddressed issues can be escalated to a supervisor or manager at the appropriate time – neither too soon nor too late. The goal should be to ensure that as many alerts as possible are both meaningful and actionable to the person receiving them immediately upon receipt. People will miss critical alerts if they don’t receive them at all, but it’s human nature that they will also miss the critical ones if they get too many noncritical ones. Many non-urgent issues (such as many preventive maintenance tasks) should not generate alerts at all, but rather be put into a queue of tasks to be performed when time and staffing permit. But if the queue does not get worked in a reasonable amount of time, an alert to that fact may be needed!

For multiproperty operations, the NOC software should of course be able to compare performance of different buildings on relevant aspects; this can help to build the ROI case for expanding the deployment of different Connected Hotel applications to additional properties. Export of key data to business intelligence systems may also be needed. For example, to compare the staffing impact of a Connected Hotel application that was implemented with a goal of reducing labor, you may need to be able to compare data from the Connected Hotel ecosystem to labor hours from your time and attendance system. If you are implementing for multiple properties, be sure to evaluate not only whether the edge devices and systems in use at various properties are all supported, but whether the data from different systems is normalized so that meaningful comparisons can be performed.

‍

Manageability

One of the biggest challenges many hotels have with Connected Hotel solutions is their manageability. These are complex IT systems and require both IT skills and onsite engineering staff that can – and are willing to – undertake those tasks that cannot be fully automated. Most hotels cannot justify the necessary IT staff onsite, which is why network-managed services are commonly used for all but the simplest systems. Costs will be minimized when hotel engineering or IT staff can perform basic installation, configuration, replacement, and repair of devices. Some of the better solutions offer easy “how to” capabilities, delivered through a wireless configuration app, videos, online resources, and chat or telephone support. These can enable staff with little or no training to do many tasks that would otherwise require field support. However, not all hotel engineers are comfortable with this type of approach. Particularly in a multi-property environment, you will want to pilot Connected Hotel solutions at hotels where the engineering staff is open to change.

One of the biggest complaints I hear about Connected Hotel systems is that the ROI can diminish over time. Many hotels that installed EMS solutions, for example, realize perhaps 20% savings in the first year, but by year three or four, those savings may have largely disappeared. This is usually because of manual overrides that are made (sometimes for good reason, sometimes out of ignorance) and never removed. A good system should detect any trend deterioration in benefits, point to the likely reason(s), and alert someone who has both the incentive and power to take action. A General Manager may not act on a cryptic technical warning, but an email saying “you’re only getting half the energy savings you got last year” (and suggesting how to fix the problem) is much more likely to get their attention.

Another manageability question revolves around the number of analytics systems and dashboards you need. Many commercial offerings are designed only to handle specific use cases, such as core building management systems or guest rooms. But analytics and dashboard systems need people to monitor them, so the more of them you have, the more you need to manage. Core systems that can integrate data from multiple different gateways and their attached devices will likely be more expensive to deploy, but far easier to manage.

‍

Additional considerations

Other issues to think about include device support by your gateway provider and (if different) your analytics provider, not only for devices you plan to connect initially, but for any that might be on a longer-term roadmap. This includes hardware support as well as software integrations with your Property Management System, your BMS, your housekeeping system, your work order management system, your preventive maintenance system, your guest mobile app, and potentially many others. And as before, integrations are not all-or-none. It’s critical to work through each of your important use cases and ensure that any integration that has been implemented will support them, and that vendors on both sides of the integration agree that versions are compatible and that any necessary configuration settings have been identified and can be supported on both sides.

Another question, especially important for gateway and analytics vendors, is whether the company has a long-term proven commitment to hospitality. Companies that are too small can easily fail during the lifetime of a solution, and these can be expensive pieces to replace because of all the custom integrations. Large companies are less prone to failure, but many of them sell the same products to multiple industries including hospitality, and the customizations that many hotels may find important never get built because they aren’t well understood or don’t have enough bottom-line impact to a multi-billion dollar company. Risks tend to be lowest with vendors, regardless of size, that have at least five to seven years of proven commitment to hospitality, and that offer a product line that already incorporates hotel-specific requirements including, where appropriate, hotel-specific hardware.

A final but very important consideration is security. Virtually every device you connect to your network is a security threat. Managing this requires expertise in multiple disciplines that is beyond the capabilities of almost any individual hotel. The larger brands understand this, and the potential for better managed security is a key benefit for the ones that offer brand-specific solutions. For individual hotels, a managed service provider should ensure that both the design and administration and maintenance of a Connected Hotel ecosystem are properly secured. You do not want to be the next hotel to have of its customer data hacked via a connected fish tank thermostat.

‍

Conclusion

A well-designed and managed Connected Hotel ecosystem can greatly reduce labor costs and improve guest experience, but these benefits can be quickly lost if poor design decisions are made or if the hotel is not committed to the necessary management practices. There is much to be said for hiring the right kind of company to manage the process, but there is no “one size fits all” solution. I hope these two articles will help you think about whether, when, and how to move your hotel into the next generation of technology.

‍