When AI Enters the Infrastructure of a Bangkok Hostel

For a while now, I have been talking with AI about the youth hostel that is under renovation.

I wanted to test something. Since almost anyone can now build software with AI-assisted coding, could a small youth hostel build for itself some capabilities that would otherwise only come from buying a commercial system?

Take the door locks, for example. The previous operator left behind several different models of electronic lock, along with a lot of old key cards. I took the locks apart to look at their circuit boards, ports, batteries, and mechanical structure. I read the UIDs, sectors, keys, and data on the MIFARE Classic cards. I re-registered a card in a lock, then compared the card's contents before and after registration.

I found that cards from the same batch looked very similar but were not quite identical. On some cards almost every data area was empty; others had different Keys in sector 0. Once, after I re-enrolled a card that originally had a special Sector 0 configuration into a lock, its sector configuration changed, yet there was still no obvious room number, check-in date, or expiry time on the card.

For the previous operator, issuing a card did not mean writing information like "Room 203, expires at noon on September 8" onto it. Instead, the lock reads the card's identity and then stores the authorization inside the lock itself.

So the AI and I began designing a management dashboard called Page Access. In this dashboard, one Tag can be linked at the same time to Room 203, the luggage room, and the shared entrance; different start and end times can be set; and each lock's own system time, along with its deviation from standard time, can be recorded.

Very soon we ran into a practical problem. If the dashboard could not communicate with the lock at all, everything would be in vain.

The permission model in the software and the device that actually enforces permissions in the real world are not the same thing. So we went on to study the locks' networking features. They have two connection modes, Hotspot and Smart. After a factory reset, the network won't even work right away: you must first set an administrator password and the system time, then add a regular door-opening code, before the network module is activated. After that the lock broadcasts its own Wi-Fi hotspot. This showed that the inside of a lock holds far more complicated states than we had first imagined. From passcodes, cards, and system time to the network module, and on to a possible manufacturer's app, cloud platform, or Gateway, it is not simply a card reader.

We began to realize that if we really wanted one dashboard to manage three or four different kinds of lock in the future, what we should actually be looking for was not how to copy each kind of card, but whether each kind of lock had a stable management interface: an API, an SDK, a Gateway, a standard protocol, or at least a local management process that could be clearly described and audited.

At almost the same time, we were also discussing the hostel's network. At first there was the same very natural temptation: build our own gateway.

There was a Wi-Fi 6 fiber router left behind by True, and we even began studying its model, hardware version, GPON, USB, Mesh, and whatever room there might be for flashing new firmware. We discussed OpenWrt, UART, the bootloader, flash memory, and firmware partitions, and whether, if we opened up the device, we might find more from the circuit board and boot logs. The process was fascinating.

But it also made a fairly abstract question more and more concrete: "being able to flash a system onto it" and "whether I am willing to entrust the network security of an entire hostel to that system" are two completely different questions.

A hostel that is actually open for business is not a laboratory. Guests connect to the Wi-Fi every day. The front-desk system, door locks, cameras, and staff devices are all online at once. Devices crash, lose power, fail to update, encounter abnormal traffic, get scanned, and run into countless edge cases we never anticipated. An AI can quickly help us write code for routing, permission management, device monitoring, even failover. But code that runs is not the same as code that has been through enough of the real world.

Behind mature commercial gateways, switches, and firewalls are many things that don't usually appear on product pages: firmware update mechanisms, configuration rollback, watchdogs, vulnerability response, handling of abnormal traffic, hardware compatibility, long-term maintenance, logging systems, and the countless extreme cases that other users have already run into for us.

In an age when everyone can code, this becomes more important, not less. AI has drastically lowered the cost of building something. But it has not equally eliminated the cost of proving it reliable.

Later, when we discussed CCTV, our conclusions moved closer and closer in the same direction. We don't need to build our own recording system, and there is no need to reimplement mature video protocols for the sake of independence.

The more sensible approach is to choose mature cameras and recording platforms, but require that they support ONVIF, RTSP, APIs, local storage, and network isolation.

The network is the same. We can choose UniFi, Omada, Fortinet, or another mature commercial gateway, rather than maintaining a core routing system of our own that has never been proven over the long term.

We no longer require everything to come from the same brand. What really needs to be unified is the relationships among them. Only once these things have stable identities can we begin to build relationships among them.

For example:

17:42:03, a Tag opened 203.

17:42:05, the second-floor stairwell camera recorded someone entering the floor.

17:42:06, the lock on 203 was still online.

On their own, these three lines are just data produced by three completely different systems. But if they share time, place, device identity, and event structure, we can know which credential entered which space at what time, and what state the corresponding devices and video records were in at that moment.

What is most valuable about AI is that it takes these pieces of data, originally so far apart, and shows me that there are more ways and structures for understanding them.

The lock knows the credential. The PMS knows the reservation. The camera knows the event. The network knows the device. The front desk knows the guest. On its own, each commercial system can see only the small part it is responsible for.

For me, AI has begun to shift from building an interface to replace a system toward understanding the relationships among multiple systems and elements.

I now prefer to use mature commercial infrastructure. A gateway should first of all be a reliable gateway. A camera should first of all be a reliable camera. A door lock should first of all ensure that people can still get in and out of their rooms safely when the network is down or the server misbehaves.

In a real world made up of mature systems, where should AI stand? AI can see these systems, analyze them, make suggestions, connect different data, and even, after authorization and verification, help carry out operations.

Looking back, my earlier experiments, which seemed a bit roundabout, reading cards, taking locks apart, trying to connect to a lock's hotspot, building the Page Access prototype, researching how to flash a router, comparing CCTV platforms, did not lose their meaning because we finally chose mature commercial products.

Quite the opposite. If I had not actually gone to those places, I could easily have understood "open," "self-built," and "AI coding" as a few abstract words.

Only after really getting my hands on the hardware did I discover that openness is not about whether I can crack something. What matters more about openness is whether I can obtain my own data over the long term, reliably, with support, and let it form relationships with other systems.

Text: Leo, Leo's Digital Observations