Hotelowe IT to nie tylko Wi-Fi dla gości. Rezerwacje, recepcja, płatności, zamki, telewizory, monitoring i stanowiska personelu muszą działać razem — a awaria jednego elementu nie powinna otwierać drogi do pozostałych. Ten przewodnik porządkuje architekturę od łącza internetowego po pokój, pokazuje zależności i podpowiada, co sprawdzić przed modernizacją.

1. Mapa systemów: od recepcji do pokoju

Przed zakupem infrastruktury narysuj prostą mapę zależności. W recepcji mogą znajdować się stanowiska personelu, PMS (property management system), terminale płatnicze i programator kart. W pokojach działają zamki, telewizory, telefony, access pointy lub urządzenia automatyki. W zapleczu: serwery, NAS, kontroler sieci, rejestrator kamer i urządzenia operatora.

2. Fundament: łącze, firewall, sieć przewodowa i Wi-Fi

Najpierw sprawdź okablowanie, szafę teletechniczną, zasilanie i topologię. Liczbę i położenie access pointów dobiera się na podstawie planu budynku, materiałów ścian, zagęszczenia klientów i pomiarów — nie wyłącznie deklarowanego zasięgu urządzenia. Pokój, korytarz, restauracja, lobby i sala konferencyjna mają inne warunki radiowe i szczytowe obciążenie.

Firewall powinien oddzielać sieć gości, personelu, serwerów i urządzeń technicznych. Switch PoE trzeba dobrać do liczby AP/kamer, ich standardu zasilania, sumarycznego budżetu mocy i rezerwy. UPS powinien podtrzymywać krytyczne elementy: bramę, przełączniki, kontroler lub serwer oraz modem — czas pracy sprawdza się pod rzeczywistym obciążeniem.

Wi-Fi gości projektuj jako usługę: określ wymagany zasięg, liczbę jednoczesnych urządzeń, przepustowość, roaming, zasady logowania oraz obsługę recepcji. Captive portal, vouchery lub dostęp przez numer pokoju mają sens tylko wtedy, gdy rozwiązują realny proces i są poprawnie zintegrowane. Zobacz techniczny przewodnik po Wi-Fi dla hotelu.

3. Oddziel gości, personel i urządzenia techniczne

Przykładowe segmenty to: goście, stanowiska personelu, serwery i usługi, kamery, automatyka/telewizory, zarządzanie urządzeniami oraz infrastruktura operatora. Konkretna liczba VLAN-ów zależy od skali i możliwości obsługi. Ważne są reguły firewalla, nie sama nazwa sieci: gość nie powinien widzieć recepcji, kamera nie powinna inicjować połączeń do komputerów, a panel zarządzania powinien być dostępny tylko administratorom.

Wyjątki — na przykład dostęp PMS do systemu zamków, drukowanie, DNS, NTP, multicast lub komunikacja z serwerem producenta — muszą mieć określone źródło, cel, porty i właściciela. Po zmianach sprawdź również działanie IPv6, awarię kontrolera i dostęp recepcji do procedury offline. Więcej przykładów opisuje poradnik o segmentacji sieci firmowej i VLAN-ach.

4. PMS, zamki i karty: integracja nie jest „automatyczna”

Zanim połączysz PMS z zamkami, telewizją hotelową, portalem Wi-Fi lub płatnościami, ustal po stronie obu dostawców: dostępne API/protokół, licencję, kierunek przepływu danych, wymagany serwer/usługę pośredniczącą, harmonogram synchronizacji, sposób autoryzacji i odpowiedzialność za wsparcie. Sama informacja „system ma API” nie potwierdza, że obsługuje konkretny PMS ani wszystkie procesy hotelu.

Testy powinny obejmować nową rezerwację, zmianę pokoju, wcześniejszy check-in, przedłużenie pobytu, checkout, anulowanie, duplikat komunikatu i utratę połączenia. Określ, co dzieje się przy opóźnieniu synchronizacji oraz jak personel ręcznie wydaje dostęp. Integracja nie może być jedyną procedurą awaryjną.

W systemach offline karta może być kodowana lokalnie zgodnie z harmonogramem, a w online uprawnienia mogą być aktualizowane przez sieć — szczegóły zależą od rodziny zamków. Zamek hotelowy nie zastępuje systemu przeciwpożarowego ani wymogów bezpiecznej ewakuacji; zgodność drzwi, okuć i funkcji awaryjnych trzeba potwierdzić dla obiektu. Osobno omówiliśmy zamki hotelowe na kartę i oprogramowanie oraz zamki TTLock i możliwości integracji API.

5. Monitoring, telewizory i systemy budynkowe

Kamery, rejestrator, telewizory, casting, centrale automatyki, kontrola dostępu i urządzenia recepcji powinny mieć określone miejsce w architekturze: osobny segment lub precyzyjnie ograniczony dostęp. Dla każdej usługi zapisz, czy wymaga Internetu, komunikacji lokalnej, zdalnego wsparcia producenta i dostępu do danych gości.

W CCTV uzgodnij, kto ma dostęp do podglądu i eksportu nagrań, jak działa uwierzytelnianie, gdzie przechowywany jest materiał i kto ustala retencję. Konfigurację należy dopasować do zasad ochrony danych i obowiązków administratora obiektu — sprzęt ani sam wpis techniczny nie przesądza o zgodności prawnej.

Nie wystawiaj rejestratora, panelu zamków ani interfejsu administracyjnego bezpośrednio do Internetu. Zdalny serwis prowadź przez kontrolowany VPN lub uzgodnioną bramę dostępową, z indywidualnymi kontami, MFA tam, gdzie jest dostępne, zakresem minimalnym i logowaniem działań.

6. Awaria: zaprojektuj tryb pracy, nie tylko normalny dzień

Lista scenariuszy powinna obejmować utratę łącza, awarię głównego switcha lub firewalla, restart kontrolera, niedostępny PMS, awarię serwera zamków, brak zasilania i uszkodzenie NAS-a. Dla każdego ustal wpływ na check-in, dostęp do pokoi, płatności, bezpieczeństwo oraz kanał kontaktu i osobę decyzyjną.

• Sprawdź, czy goście zachowują działające sesje Wi-Fi po utracie kontrolera i czy nowy klient może się zalogować.
• Opisz legalną i bezpieczną procedurę awaryjnego wydawania kart/kluczy, w tym późniejszą synchronizację zmian.
• Przechowuj kopie konfiguracji firewalla, switchy, kontrolerów, PMS-integracji i rejestratora w miejscu odseparowanym od urządzeń.
• Przetestuj zasilanie awaryjne i odtworzenie konfiguracji, zamiast zakładać, że migawka lub kopia jest użyteczna.
• Ustal, jak przywrócić działalność etapami oraz jak poinformować personel, gdy kanały IT nie działają.

Techniczny plan odzyskiwania powinien zawierać priorytety, RPO/RTO, zależności i wynik próbnego odtworzenia. Zobacz procedurę testowania backupu i odzyskiwania.

7. Plan wdrożenia i odbiór

1. Warsztat operacyjny: przejdź procesy recepcji, housekeeping, gastronomii, technicznego i zarządzania.
2. Inwentaryzacja: zbierz rzuty, okablowanie, urządzenia, umowy operatorów, wersje systemów, licencje i kontakty producentów.
3. Projekt: przygotuj diagram fizyczny i logiczny, adresację, VLAN-y, reguły, Wi-Fi, UPS, backup, integracje i procedury awaryjne.
4. Pilot i migracja: przetestuj przykładowy pokój, fragment korytarza, recepcję oraz scenariusze rezerwacja–zamek–checkout przed wdrożeniem na cały obiekt.
5. Testy odbiorowe: sprawdź zasięg i roaming, izolację gości, wydanie karty, awarię Internetu/kontrolera, backup konfiguracji, konta serwisowe i dokumentację.
6. Przekazanie: szkol personel z procedur, udostępnij mapę kontaktów, instrukcję eskalacji i wykaz czynności cyklicznych.

8. Utrzymanie i odpowiedzialność po uruchomieniu

W umowie serwisowej rozdziel odpowiedzialność za łącze, sieć LAN/Wi-Fi, PMS, zamki, telewizory, monitoring, automatykę i sprzęt płatniczy. Zapis „reakcja w cztery godziny” powinien wyjaśniać godziny obowiązywania, definicję reakcji, kanał zgłoszeń, priorytety i to, kto przywraca usługę. Reakcja nie jest tym samym co rozwiązanie problemu.

Ustal właściciela konfiguracji i dokumentacji, częstotliwość aktualizacji, przegląd kont dostawców, test kopii, dostęp do części zapasowych oraz sposób informowania o zmianach. Obiekt powinien wiedzieć, do kogo dzwoni recepcja i kto koordynuje kilku producentów, gdy awaria przechodzi przez granice ich systemów.

IT hotelu jako spójny system

IT Node pomaga planować i utrzymywać infrastrukturę hoteli oraz apartamentów — od sieci i Wi-Fi przez segmentację po koordynację serwisu i dokumentację. Poznaj obsługę IT dla hoteli i apartamentów albo opowiedz nam o obiekcie. Działamy głównie w Małopolsce i na Podhalu; projekty w innych częściach Polski ustalamy indywidualnie.

Materiał edukacyjny IT Node. Dostępne funkcje, integracje, licencje i tryb offline zależą od konkretnego PMS, producenta zamków, urządzeń, wersji i umowy. Przed zakupem należy potwierdzić interoperacyjność, bezpieczeństwo i procedury awaryjne z dostawcami systemów oraz przeprowadzić test w środowisku obiektu.

Hotelowy zamek na kartę to nie tylko klamka i programator na recepcji. O bezpieczeństwie i wygodzie decydują razem: typ karty, sposób zapisu uprawnień, oprogramowanie, integracja z PMS, tryb pracy zamków i procedura na wypadek awarii. Wyjaśniamy, jak działa taki system, czym różnią się m.in. BIS Hotel, TESA Hotel, SALTO Space i dormakaba Ambiance oraz jak wdrożyć go bez kosztownych niespodzianek.

1. Jak działa hotelowy zamek programowany kartą?

Recepcjonista wybiera rezerwację w oprogramowaniu hotelowym, przypisuje pokój i przykłada kartę do programatora — zwykle czytnika podłączonego do komputera przez USB albo do sieci. System zapisuje na karcie uprawnienia, np. numer zamka lub grupy drzwi, datę początku i końca pobytu oraz dostęp do wybranych stref. Gość przykłada kartę do czytnika w klamce; zamek sprawdza dane lokalnie i otwiera drzwi, jeśli poświadczenie i czas są prawidłowe.

W typowym systemie offline nie trzeba prowadzić przewodu sieciowego do każdego skrzydła. Zamek ma własną pamięć, zegar i zasilanie bateryjne, a programator obsługuje recepcję. Szczegóły różnią się jednak między producentami: część systemów aktualizuje dane zamków przez karty serwisowe, część wykorzystuje czytniki ścienne lub łączność bezprzewodową. Zanim kupisz sprzęt, poproś o demonstrację dokładnego przepływu: meldunek, wydanie drugiej karty, zgubienie karty, przedłużenie pobytu i wymeldowanie.

2. Jakie systemy i oprogramowanie są dostępne w Polsce?

Na polskim rynku można spotkać kompletne ekosystemy hotelowe, w których producent lub jego partner dostarcza zamki, programator, karty, oprogramowanie i integrację z systemem rezerwacji. Do porównania warto włączyć co najmniej:

Uwaga do nazwy: jeśli przez „BLIS Hotel” masz na myśli system do zamków Be-Tech, producent używa nazwy BIS Hotel. To ważne przy pytaniu o ofertę, dokumentację i integrację — warto przekazać dostawcy dokładną nazwę producenta, zamka i wersji programu.

To przykłady platform do rozmowy z integratorem, a nie ranking ani deklaracja, że każdy model jest dostępny od ręki. Dostępność, wersje, kompatybilne zamki i funkcje integracji trzeba potwierdzić dla konkretnego projektu. Zobacz dokumentację i ofertę: BIS Hotel Be-Tech, TESA Hotel, SALTO Space Hospitality oraz dormakaba Ambiance.

3. Karty hotelowe: pasek magnetyczny, 125 kHz, MIFARE i DESFire

„Karta hotelowa” może oznaczać różne technologie. Wygląd zewnętrzny niewiele mówi o tym, co znajduje się wewnątrz i czy karta zadziała w danym zamku.

• Pasek magnetyczny: starszy nośnik, który wymaga przeciągnięcia przez czytnik. Zużywa się mechanicznie, a zgubioną kartę trudno odróżnić od zapasowej bez sprawdzenia systemu. W nowych instalacjach zwykle rozważa się RFID.
• RFID 125 kHz: spotykany w prostych systemach kontroli dostępu, ale nie jest tym samym co MIFARE 13,56 MHz. Sam numer UID nie powinien być traktowany jako silne uwierzytelnienie.
• MIFARE 13,56 MHz: rodzina kart, a nie jeden gwarantowany standard bezpieczeństwa. Be-Tech opisuje swój hotelowy system jako oparty na kartach MIFARE. Konkretna generacja, pamięć, klucze i sposób personalizacji zależą od systemu.
• MIFARE DESFire / Plus: nowocześniejsze układy mogą obsługiwać mechanizmy kryptograficzne, w tym AES, i wiele aplikacji. To nie znaczy, że każda karta DESFire będzie automatycznie działać z każdym zamkiem — producent musi wspierać daną kartę, profil i klucze.
• Telefon lub identyfikator mobilny: osobny wariant dostępu; sprawdź go jako funkcję platformy, nie zakładaj, że pojawi się po zakupie samego zamka RFID.

Kluczowe jest nie tylko pasmo, ale też chip, sektor/aplikacja, klucze kryptograficzne, sposób zapisu i licencja platformy. Nie kupuj dużej partii „uniwersalnych kart MIFARE” bez potwierdzenia na piśmie kompatybilności z konkretnym systemem. Sprawdź także, czy karta może jednocześnie obsłużyć windę, parking, szafkę SPA lub płatności — wymaga to zgodnych czytników, aplikacji i uzgodnionego podziału pamięci. NXP opisuje DESFire jako rodzinę kart z obsługą algorytmów kryptograficznych, a Salto publikuje własne karty EV3/Plus i wymagania platformy; te informacje pokazują, dlaczego samo hasło „13,56 MHz” nie wystarcza.

4. Offline, zapis na karcie czy online — trzy różne modele

Nazwy handlowe trybów różnią się między producentami. Pytaj o zachowanie w konkretnych sytuacjach, nie tylko o etykietę „online”:

• czy utrata Internetu uniemożliwia wejście gościa z już wydaną kartą;
• jak szybko system odbiera zgubionej karcie dostęp i czy musi ona ponownie trafić do zamka;
• czy widzisz, że drzwi zostały otwarte, czy tylko wydano kartę;
• co dzieje się po rozładowaniu baterii, awarii kontrolera lub serwera;
• czy dostęp do parkingu, windy i pokoju ma ten sam cykl życia.

5. Zalety i ograniczenia zamków na karty

Zalety: karta jest intuicyjna, nie wymaga od gościa instalowania aplikacji ani posiadania smartfona; recepcja może szybko wydać kopię lub kartę zastępczą; uprawnienia można ograniczyć do pokoju, okresu pobytu i stref; system da się rozszerzyć o kontrolę windy, wejścia wspólne, parking czy SPA. W wielu obiektach bezprzewodowy zamek bateryjny można zamontować bez prowadzenia przewodów do każdego skrzydła.

Ograniczenia: trzeba kupować i ewidencjonować karty, utrzymywać programator oraz stanowisko recepcyjne; zgubienie karty wymaga sprawdzenia, czy i jak unieważnienie trafi do zamka; starszy offline nie zapewni obrazu bieżącego stanu drzwi; niezgodne karty i systemy utrudniają późniejszą zmianę dostawcy; baterie, zegary, mechanika i procedury nadal wymagają serwisu. Jeśli karta korzysta ze słabego profilu lub identyfikatora UID bez silnego uwierzytelnienia, wygoda nie powinna być mylona z wysokim poziomem ochrony.

6. Integracja z PMS i własnym oprogramowaniem

Najprostsza praca to osobny program zamków na recepcji: operator melduje gościa w PMS, a następnie ręcznie tworzy kartę w drugim systemie. To działa, ale zwiększa liczbę kroków i ryzyko pomyłki. Integracja sprawia, że z poziomu rezerwacji można przypisać pokój, zakodować kartę z datą ważności i ewentualnie nadać dostęp do stref. Producent Be-Tech publikuje informację o integracji BIS Hotel przez biblioteki DLL i podaje listę wybranych programów, a SALTO opisuje protokoły PMS i wymagania dotyczące licencjonowania oraz enkoderów Ethernetowych.

Można też budować własny łącznik lub aplikację, ale to zależy od dokumentacji i zgody producenta zamków oraz od interfejsu PMS. Zanim zamówisz programowanie, potwierdź: czy dostępne jest stabilne API/SDK lub DLL; czy można legalnie używać go w komercyjnym wdrożeniu; kto dostarcza klucze i licencje; jak obsługiwane są rezerwacje, anulowanie, zmiana pokoju i duplikat meldunku; oraz kto utrzymuje integrację po aktualizacji PMS lub systemu zamków. Dla niektórych ekosystemów dostępny jest protokół PMS, dla innych potrzebny jest zatwierdzony partner. Nie zakładaj, że sam programator USB można podłączyć do dowolnego własnego systemu.

W małym obiekcie osobny program może być rozsądny, jeśli procedura jest prosta i każdy pracownik ją zna. W większym hotelu integracja usuwa podwójne wprowadzanie danych i ułatwia obsługę grup, przedłużeń i wymiany pokoju. Własne oprogramowanie ma sens dopiero wtedy, gdy gotowy konektor nie pokrywa konkretnego procesu, a hotel ma właściciela technicznego integracji, środowisko testowe i budżet na jej utrzymanie.

7. Jak wdrożyć system kartowy krok po kroku?

1. Spis drzwi i wymagań: podziel drzwi na pokoje, wejścia, zaplecze, windy, parking i strefy dodatkowe. Zbierz typy skrzydeł, zamków wpuszczanych, grubości drzwi i wymogi ewakuacyjne.
2. Proces recepcji: opisz meldunek, wcześniejszy przyjazd, przedłużenie pobytu, drugą kartę, zmianę pokoju, zgubę, wymeldowanie i dostęp pracowników.
3. Wybór ekosystemu: porównaj program, zamki, programatory, rodzaj kart, licencje, gwarancję, lokalny serwis i możliwość migracji.
4. Sprawdzenie PMS: uzyskaj potwierdzenie producenta obu systemów, czy integracja działa z używaną wersją, licencją i sprzętem. Poproś o pokazanie realnego meldunku, nie samej listy zgodności.
5. Pilot: zamontuj rozwiązanie na przykładowych drzwiach i sprawdź kartę gościa, kartę personelu, windę/strefy oraz odczyt zdarzeń.
6. Test awarii: odłącz serwer/sieć, użyj karty zapasowej, zasymuluj zgubę karty i rozładowaną baterię; sprawdź awaryjne otwarcie i kontakt do serwisu.
7. Instalacja i szkolenie: przygotuj kopię konfiguracji, listę identyfikatorów zamków, role użytkowników, zestaw kart serwisowych i krótką procedurę dla każdej zmiany.
8. Odbiór: przetestuj każdy rodzaj drzwi i dostępu, podpisz protokół, przekaż instrukcję, warunki gwarancji, odpowiedzialność za karty i harmonogram wymiany baterii.

8. Bezpieczeństwo, serwis i plan na awarię

System dostępu dotyka bezpieczeństwa gości, dlatego projekt powinien określać, kto może wydawać karty master, jak zmienia się uprawnienia po odejściu pracownika, gdzie trzymane są karty awaryjne i kto ma dostęp do dzienników zdarzeń. Rozdziel karty gości, housekeeping, serwisu i administratora; karta otwierająca cały obiekt nie może być codziennym kluczem personelu. Ogranicz dostęp do programu i serwera, zabezpiecz kopie bazy oraz spisz, kto odpowiada za aktualizacje i kontakt z producentem.

Sprawdź też mechanikę i bezpieczeństwo pożarowe: zamek nie może utrudniać swobodnej ewakuacji od środka ani kolidować z drzwiami przeciwpożarowymi. Wybór okuć i ingerencję w drzwi skonsultuj z producentem drzwi lub właściwym projektantem. Zamek elektroniczny nie zastępuje klucza/trybu awaryjnego uzgodnionego dla danego obiektu.

Dane o wejściach mogą być powiązane z gościem i jego pobytem. Ustal, kto widzi logi, jak długo są przechowywane, jak wydaje się kopię karty i jak dokumentuje incydent. Nie eksportuj danych dostępowych do arkuszy i logów PMS bez potrzeby. Umowy i ustawienia prywatności trzeba dopasować do konkretnej platformy i sposobu pracy hotelu.

Co wybrać?

Jeśli najważniejsze są prosta obsługa i mały koszt instalacji, zacznij od porównania lokalnego systemu z programatorem recepcyjnym — np. BIS Hotel, jeśli rozważasz Be-Tech. Jeśli zależy Ci na jednolitym zarządzaniu pokojami, strefami, personelem i wieloma typami drzwi, sprawdź pełne platformy TESA Hotel, SALTO Space Hospitality lub Saflok/Ambiance. Gdy potrzebujesz natychmiastowego odbierania uprawnień albo widoczności stanu drzwi, wyceń wariant online; pamiętaj jednak, że to większa zależność od sieci, licencji i utrzymania.

Poproś dostawcę o zestawienie kosztów całego cyklu: zamki i montaż, programatory, karty i zapas, software, PMS, dodatkowe strefy, aktualizacje, baterie, serwis i czas pracy recepcji. Najlepszy system to nie ten z najdłuższą listą funkcji, tylko taki, którego działanie personel potrafi utrzymać i awaryjnie obsłużyć.

Planujesz sieć oraz systemy IT dla hotelu lub apartamentów? Zobacz także poradnik o Wi-Fi dla hoteli oraz nasz artykuł o TTLock, API i integracjach. Więcej o naszej ofercie znajdziesz na stronie IT dla hoteli i apartamentów lub skontaktuj się z nami przez formularz kontaktowy.

Dokumentacja i źródła

• Be-Tech: BIS Hotel — funkcje, integracja i wymagania
• Be-Tech: baza wiedzy o BIS Hotel i kartach
• ASSA ABLOY: TESA Hotel — tryby zarządzania
• ASSA ABLOY: zamek TESA i-volution i obsługiwane systemy
• SALTO: Space Hospitality
• SALTO Support: integracja PMS i wymagania enkodera
• SALTO: specyfikacja kart RFID
• NXP: rodzina kart MIFARE DESFire
• dormakaba: Ambiance Access Management

Opis dotyczy rodzin platform i publicznie dostępnych materiałów producentów sprawdzonych 26 września 2026 r. Nazwy funkcji, karty, licencje, interfejsy PMS i dostępność w Polsce zależą od wersji oraz konkretnego projektu — potwierdź je z producentem lub autoryzowanym integratorem przed zakupem. Poradnik nie zastępuje audytu drzwi i wymogów ewakuacyjnych.

Zamki TTLock mogą uprościć samoobsługowe zameldowanie, wydawanie kodów i odbiór dostępu po wymeldowaniu. Dopiero integracja z PMS lub własnym systemem rezerwacji pozwala jednak spiąć dostęp z rzeczywistym przebiegiem pobytu. Poniżej pokazujemy, jak działa TTLock, co daje jego API, kiedy potrzebna jest bramka i jak zaprojektować rozwiązanie, które nie zawiedzie gościa po północy.

1. Jak działa TTLock w aparthotelu?

TTLock to ekosystem zamków elektronicznych, aplikacji i platformy integracyjnej. Sama nazwa nie oznacza jednego identycznego zamka: rozwiązania różnych producentów mogą używać technologii TTLock, ale różnią się mechaniką, elektroniką, firmware’em, wersją obsługiwanych kodów i akcesoriami. Do wdrożenia liczy się dokładny model i jego dokumentacja, nie tylko logo aplikacji.

Typowy zamek komunikuje się lokalnie z telefonem przez Bluetooth Low Energy (BLE). Gość może dostać kod PIN ważny wyłącznie w czasie rezerwacji, e‑key w aplikacji albo — jeśli dany model to obsługuje — kartę, odcisk palca czy inny identyfikator. W wynajmie krótkoterminowym kod PIN zwykle zmniejsza tarcie: gość nie musi instalować aplikacji, zakładać konta ani mieć kompatybilnego telefonu.

Jeśli operator ma zdalnie sprawdzać stan zamka, wysłać polecenie albo synchronizować uprawnienia bez podchodzenia do drzwi, potrzebna jest ścieżka komunikacji online: najczęściej zgodna bramka BLE–Wi‑Fi/LAN w zasięgu zamka albo zamek z łącznością komórkową. Bramka nie sprawia, że sam mechanizm drzwi staje się niezależny od chmury. Jej zasilanie, Internet, zasięg BLE, konto TTLock i usługa API stają się elementami łańcucha.

2. Trzy modele obsługi gości — od aplikacji po automat

Praktyczny przepływ nie powinien opierać się na samym „utwórz kod”. Ważne są też zmiana terminu, anulowanie, przedłużenie pobytu, zmiana pokoju, nieudane płatności, wcześniejsze wymeldowanie, awaria API i ponowienie żądania. W każdym z tych zdarzeń integracja musi wiedzieć, które uprawnienie należy utworzyć, zmienić lub odebrać.

3. API TTLock — co można zintegrować i napisać samodzielnie?

Tak — TTLock udostępnia Open Platform API, a producent publikuje także SDK dla aplikacji. To umożliwia integrację z PMS, systemem rezerwacji, panelem recepcji lub własnym portalem gościa; można też zlecić napisanie pośredniczącego oprogramowania dopasowanego do konkretnego obiektu. API nie jest jednak magicznym przełącznikiem: dostęp wymaga aplikacji i poświadczeń platformy, a możliwości zależą od modelu zamka, wersji kodów, gatewaya i konkretnego endpointu.

W oficjalnej dokumentacji Cloud API V3 opisano między innymi operacje na zamkach, e‑key, czasowych kodach PIN, gatewayach i rejestrze otwarć. Przykładowo endpoint dodawania kodu przyjmuje identyfikator zamka i początek/koniec ważności jako znaczniki czasu w milisekundach. Dokumentacja zaznacza, że własny kod dodawany przez API wymaga zamków z wersją kodów V4; tryb dodania przez gateway jest odrębny od scenariusza Bluetooth wymagającego operacji SDK przy telefonie. Zgodność trzeba sprawdzić na konkretnym egzemplarzu i firmware’ze, zanim zbuduje się logikę produkcyjną.

Dzięki API można, w zależności od sprzętu i przyznanych uprawnień:

• generować kod dla konkretnego zamka z ograniczeniem daty i godziny;
• automatycznie wysłać gościowi dostęp po potwierdzeniu rezerwacji, a po jej anulowaniu usunąć lub unieważnić;
• przedłużyć pobyt albo utworzyć dostęp dla serwisu z krótszym oknem czasowym;
• sprawdzać listę zamków i gatewayów oraz dostępność gatewaya;
• odczytywać rejestr zdarzeń lub stan baterii — o ile wspiera to model i konfiguracja;
• zbudować panel administracyjny, pulpit recepcji, integrację z CRM/PMS lub przepływ automatyzacji.

Ważny niuans: „jest API” nie oznacza, że każdy zamek da się otworzyć z dowolnej aplikacji w dowolnym momencie. Polecenie z chmury zależy od dostępności połączenia przez bramkę lub odpowiedni wariant sprzętu. Funkcje i nazwy endpointów różnią się między API, SDK i generacjami. Najpierw należy zarejestrować aplikację w Open Platform, uzyskać i przetestować tokeny, sprawdzić wymagania konta oraz potwierdzić warunki dostępu i ewentualne opłaty z TTLock lub dystrybutorem — nie zakładać, że dostęp produkcyjny jest bezwarunkowy lub bezpłatny.

API używamy wyłącznie po stronie serwera. Client secret, access token, kody gości i pełne odpowiedzi API nie powinny trafić do kodu JavaScript w przeglądarce, logów WordPressa ani repozytorium publicznego. Dokumentacja endpointu odczytu historii wskazuje, że rekord może zawierać użyty kod/identyfikator dostępu. To szczególnie wrażliwe dane operacyjne: ogranicz dostęp, retencję i zakres eksportu do tego, co rzeczywiście jest potrzebne.

4. Przykładowa architektura: rezerwacja → kod → wiadomość

Bezpieczna integracja zwykle składa się z trzech warstw: PMS lub system rezerwacji, własny backend pośredniczący i TTLock Open Platform. Frontend nie łączy się bezpośrednio z API zamków.

1. PMS emituje zmianę rezerwacji. Backend pobiera identyfikator lokalu, status, datę/godzinę check-in i check-out oraz niezbędny kanał dostarczenia instrukcji. Nie kopiujemy do zamka ani do logów całego profilu gościa.
2. Backend waliduje reguły. Sprawdza płatność i status, mapuje lokal na prawidłowy lock ID, uwzględnia strefę Europe/Warsaw, zmianę czasu i bufor wejścia/wyjścia.
3. Backend wywołuje TTLock. Używa tokenu przechowywanego po stronie serwera i tworzy dostęp ważny w dokładnym oknie pobytu. Dla nowego wdrożenia warto preferować losowe, unikatowe kody zamiast numeru rezerwacji lub danych osobowych.
4. Zapisuje rezultat i wysyła komunikat. Dopiero po potwierdzeniu powodzenia wysyła gościowi kod oraz prostą instrukcję wejścia. W razie błędu alarmuje obsługę i uruchamia procedurę ręczną.
5. Obsługuje zmiany idempotentnie. Powtórny webhook lub retry nie może tworzyć wielu aktywnych kodów. Każda operacja powinna mieć identyfikator rezerwacji, status i bezpieczną ścieżkę ponowienia.

Jeżeli PMS nie ma gotowego konektora, można napisać własny mostek REST albo użyć narzędzia automatyzacyjnego — ale po sprawdzeniu, czy PMS udostępnia stabilne API/webhooki i czy pozwala na pracę na danych produkcyjnych. Samo posiadanie API po stronie TTLock nie rozwiązuje braku API po stronie systemu rezerwacji. Trzeba również ustalić, kto utrzymuje integrację, aktualizuje ją po zmianach endpointów i odpowiada za komunikację z gościem.

5. Bramka, Bluetooth i co się stanie bez Internetu

Bluetooth jest dobry do lokalnej obsługi przez operatora znajdującego się przy drzwiach oraz do scenariuszy, w których telefon gościa jest kluczem. Zasięg jest ograniczony, a integracja przez SDK oznacza rozwijanie i utrzymanie aplikacji mobilnej oraz obsługę uprawnień systemu telefonu. Dla gościa, który chce po prostu wejść kodem, aplikacja może być zbędnym utrudnieniem.

Gateway pośredniczy między chmurą a zamkiem po BLE. Zgodna bramka umożliwia zdalną administrację i wybrane operacje online, ale wymaga stabilnego zasilania, Internetu i zasięgu radiowego od gatewaya do zamka. Nie należy przyjmować katalogowej odległości jako gwarancji dla grubych ścian, metalowych drzwi, korytarzy czy wielu kondygnacji. Rozmieszczenie trzeba zweryfikować na miejscu; czasem sensowniejszy jest dodatkowy gateway w strefie niż jeden „mocny router”. Przykład gatewaya TTLock G2/G3 można sprawdzić w [polskim cenniku ESC](https://www.escsa.pl/sklep/product-locstar-g2-g3-ttlock-wi-fi-smart-gateway.html).

Awaria Internetu lub chmury: zdalne komendy, synchronizacja i odczyt bieżących danych mogą nie działać, choć wcześniej poprawnie zapisany PIN może nadal działać lokalnie w zamku — zależnie od modelu, sposobu wygenerowania, synchronizacji, zegara i firmware’u. Nie obiecuj gościom działania offline bez testu. Odbiór musi obejmować odcięcie Internetu, restart gatewaya, rozładowaną baterię, błędny czas i sprawdzenie, czy kod wygasa zgodnie z oczekiwaniem.

6. Dobór zamka: drzwi, ewakuacja i codzienna eksploatacja

Dobór zaczyna się od pomiarów i oględzin: grubość skrzydła, rozstawy, kierunek otwierania, rodzaj zamka wpuszczanego, wkładka, szyld, sposób ryglowania i możliwość awaryjnego otwarcia. Klamka elektroniczna lub retrofit nie pasuje automatycznie do każdych drzwi. Przy drzwiach przeciwpożarowych, drogach ewakuacyjnych i wejściach wspólnych potwierdź zgodność z projektem, wymaganiami obiektu i instrukcją producenta drzwi — nie montuj elektroniki, która może utrudnić bezpieczne wyjście.

W aparthotelu trzeba też rozdzielić poziomy dostępu: wejście zewnętrzne, piętro, lokal, zaplecze techniczne i pomieszczenia personelu. Kod do pokoju nie powinien otwierać serwerowni, magazynu ani wszystkich drzwi w budynku. Karty lub e‑key dla housekeeping powinny mieć osobny zakres i grafik. Tam, gdzie to możliwe, zachowaj mechaniczny sposób awaryjnego otwarcia i określ, kto oraz jak może z niego skorzystać.

7. Koszty: zamek to tylko jedna pozycja

Ceny zależą od mechaniki drzwi, wykończenia, czytnika, dystrybutora i zakresu integracji. Jako orientacyjny punkt odniesienia: w chwili sprawdzenia polska oferta modeli TTLock vG/HT wyświetlała przykładowe ceny ok. 1 132–1 513 zł brutto za wybrane klamki/okucia; gateway G2/G3 był prezentowany za ok. 384 zł brutto. Są to ceny konkretnego sprzedawcy i konkretnych modeli, a nie gwarantowany cennik całego rynku; mogą się zmieniać. Zobacz [bieżącą listę TTLock w Altum Polska](https://altumpolska.pl/c/ttlock-smartlock) oraz [przykład gatewaya w ESC](https://www.escsa.pl/sklep/product-locstar-g2-g3-ttlock-wi-fi-smart-gateway.html).

Przy kilku lokalach ręczne klikanie może być najtańsze na starcie. Gdy rezerwacji jest dużo, koszt pracy recepcji, błędne kody i nocne interwencje szybko zmieniają rachunek. Policz koszt całkowity: sprzęt + instalacja + gatewaye + licencje/API + wiadomości do gości + administracja + utrzymanie integracji + awaryjna obsługa. Dostępność i cena usługi Open API nie są tu zgadywane — należy je potwierdzić przed wyceną projektu.

8. Bezpieczeństwo, prywatność i procedury awaryjne

• Oddziel konto właściciela od konta recepcji i serwisu; nadaj każdej roli tylko niezbędne uprawnienia.
• Trzymaj Client Secret i access token w menedżerze sekretów lub chronionej konfiguracji backendu; zaplanuj odnowienie tokenu i jego unieważnienie po incydencie.
• Nie umieszczaj PIN-u, pełnego API request/response ani tokenu w logach aplikacji. Ogranicz historię otwarć do osób, które jej potrzebują, i ustal retencję oraz zasady dostępu.
• Po wymeldowaniu sprawdź, że dostęp wygasł; po anulowaniu pobytu unieważnij go od razu, a nie dopiero przy ręcznym przeglądzie rezerwacji.
• Przygotuj plan, gdy PMS, Internet, cloud API, gateway lub zasilanie nie działa: numer dyżurny, weryfikacja tożsamości gościa, mechaniczny klucz awaryjny, kontakt do osoby na miejscu oraz rejestr interwencji.
• Przed uruchomieniem ustal, kto administruje zamkami po odejściu pracownika lub zmianie operatora. Przekazanie kont, tokenów i kluczy awaryjnych powinno być udokumentowane.

Historia wejść i identyfikatory przypisane do rezerwacji mogą ujawniać informacje o konkretnych osobach. Zbieraj tylko dane niezbędne do obsługi i bezpieczeństwa, ogranicz dostęp oraz uzgodnij role administratora i podmiotu przetwarzającego z dostawcą PMS/IT. Sama obecność historii w aplikacji nie oznacza, że wolno ją przechowywać bezterminowo lub udostępniać każdemu pracownikowi.

9. Plan wdrożenia i testy odbiorowe

1. Inwentaryzacja drzwi: sprawdź mechanikę, kierunek ewakuacji, wariant awaryjny i listę lokalizacji.
2. Pilot: zamontuj 1–2 reprezentatywne modele, sprawdź telefon, PIN, gateway, baterie i codzienny check-in.
3. Integracja: potwierdź konto Open Platform, endpointy, zakres danych, dostępność PMS API, obsługę anulowania i retry.
4. Test awarii: odłącz Internet, wyłącz gateway, zasymuluj opóźnioną/anulowaną rezerwację i sprawdź wejście ręczne.
5. Odbiór i szkolenie: przekaż mapę lock ID, konta i role, instrukcję dla gościa, procedurę serwisową i odpowiedzialność za baterie.

Jeśli dopiero planujesz sieć dla obiektu, zobacz też nasz poradnik o Wi‑Fi dla hoteli. Przy wdrożeniu warto potraktować zamki jako część całej infrastruktury, a nie odizolowany gadżet: sieci gości i urządzeń, zasilanie, dostęp administratorów, PMS oraz procedury recepcji muszą działać razem.

Ceny sprzętu przytoczono jako przykłady z publicznych ofert handlowych sprawdzonych 26 września 2026 r.; przed zakupem zweryfikuj model, cenę i dostępność u sprzedawcy. Zakres API, model zamka i warunki Open Platform należy potwierdzić dla konkretnego konta i urządzenia. Poradnik nie zastępuje audytu drzwi, projektu ewakuacji ani analizy ochrony danych dla konkretnego obiektu.

Dobre Wi-Fi w hotelu zaczyna się od projektu radiowego, okablowania i polityki dostępu — nie od liczby anten ani napisu „Wi-Fi 7” na pudełku. UniFi i TP-Link Omada pozwalają zbudować zarządzaną sieć dla obiektu noclegowego. Różnice ujawniają się w konkretnych modelach, sposobie utrzymania kontrolera i integracjach, a nie w samym logo producenta.

1. Projekt Wi-Fi: liczymy obciążenie, nie tylko pokoje

Rzut kondygnacji jest punktem wyjścia. Potrzebne są informacje o ścianach, stropach, szybach, lustrach, szachtach instalacyjnych, miejscach montażu i trasach kablowych. AP na końcu korytarza może świetnie obsługiwać korytarz i słabo pokoje za kilkoma przegrodami. Mocniejszy nadajnik nie naprawi słabego sygnału zwrotnego telefonu.

Rozdzielamy trzy wymagania: pokrycie (gdzie sieć ma działać), pojemność (ilu użytkowników jest aktywnych jednocześnie) i jakość aplikacji (np. wideokonferencje zamiast samego przeglądania stron). Sala konferencyjna wymaga osobnego bilansu; liczba pokoi nie opisuje jej obciążenia.

Przykład obliczeniowy, nie gotowy projekt: 60 pokoi × 2 osoby × 2 urządzenia daje 240 potencjalnie podłączonych urządzeń. Jeśli przyjmiemy 25% jednocześnie aktywnych klientów i 5 Mb/s średniego zapotrzebowania każdego, otrzymamy 300 Mb/s ruchu użytkowego. To założenie trzeba sprawdzić z profilem gości i ruchem konferencyjnym. Nie określa ono liczby AP ani nie zastępuje analizy airtime, uplinków i łącza internetowego.

Odbiór powinien obejmować pomiary w pokojach, przy biurkach i łóżkach, a nie wyłącznie w drzwiach. Jako punkt wyjścia dla usług wrażliwych na przerwy można przyjąć około −67 dBm RSSI i 25 dB SNR, ale to nie uniwersalna norma hotelowa. Cisco podaje te wartości w kontekście usług głosowych; docelowe progi dobieramy do urządzeń i aplikacji. Sprawdzamy też retransmisje, wykorzystanie kanału, opóźnienia i utratę pakietów. Źródło: Cisco — pomiary WLAN.

2. Pasma, szerokość kanału i roaming

• 2,4 GHz: przede wszystkim kompatybilność ze starszymi urządzeniami i IoT. Punktem wyjścia jest 20 MHz oraz plan kanałów ograniczający nakładanie się sąsiednich komórek.
• 5 GHz: główne pasmo dla większości współczesnych urządzeń gości. W gęstym hotelu warto ocenić 20 lub 40 MHz; 80 MHz dopiero wtedy, gdy plan kanałowy i pomiary uzasadniają większą szerokość. Szerszy kanał daje wyższą szybkość pojedynczego połączenia, ale zmniejsza możliwości ponownego wykorzystania pasma. Cisco: projektowanie sieci o dużej gęstości.
• 6 GHz: dodatkowa przestrzeń radiowa dla kompatybilnych klientów Wi-Fi 6E/7. Nie każdy AP Wi-Fi 7 ma radio 6 GHz. Trzeba sprawdzić model, wersję regionalną i obsługę zabezpieczeń; nie można zakładać identycznego pokrycia jak w 5 GHz. Ubiquiti: wdrażanie 6 GHz.

DFS zwiększa pulę dostępnych kanałów 5 GHz, ale wykrycie radaru może wymusić zmianę kanału. W projekcie uwzględniamy lokalne warunki, zgodność regionu i zachowanie urządzeń podczas takiej zmiany. Nie ustawiamy maksymalnej mocy na wszystkich AP: wielkość komórek musi umożliwiać sensowne współdzielenie pasma i przechodzenie między nimi.

802.11k pomaga klientowi poznać sąsiednie AP, 802.11v umożliwia przekazywanie sugestii przejścia, a 802.11r skraca procedury uwierzytelniania przy zmianie AP. Ostateczny wybór AP nadal zależy od klienta. W Omada funkcja „Fast Roaming” oparta na k/v nie jest synonimem osobnego ustawienia 802.11r. Obsługę sprawdzamy dla wybranego AP, firmware, kontrolera i trybu zabezpieczeń. Omada: zasada działania roamingu.

Nie kopiujemy starych ograniczeń na całą serię urządzeń. Przykładowo firmware EAP613 V2 1.8.0 dodał obsługę 802.11r dla WPA3-Enterprise — nie oznacza to automatycznie tego samego wsparcia we wszystkich modelach. Informacje o wydaniu EAP613 V2.

Minimum RSSI nie jest „przyspieszaczem Wi-Fi”. Zbyt agresywny próg może wyrzucać klienta, który nie ma lepszego AP do wyboru. Najpierw poprawiamy pokrycie i moc, następnie testujemy roaming podczas rozmowy lub wideokonferencji. Ubiquiti: działanie i ryzyka Minimum RSSI.

3. UniFi czy TP-Link Omada — co rzeczywiście porównywać?

Obie platformy warto oceniać jako zestaw: punkty dostępowe, przełączniki, brama, kontroler i procedura utrzymania. Poniższe wnioski są kryteriami doboru, nie wynikami laboratoryjnego testu wydajności.

UniFi OS Server jest według producenta bez opłaty licencyjnej, ale administrator odpowiada za jego aktualizacje i dostępność. Official UniFi Hosting jest innym, płatnym sposobem uruchomienia systemu. Omada oferuje m.in. bezpłatny Software Controller oraz chmurę Essentials i płatny Standard. Zakres tych wariantów nie jest identyczny. Przed zamówieniem sprawdzamy aktualną macierz zgodności, a nie tylko obecność przycisku „Cloud”. Źródła: UniFi self-hosting, UniFi Hosting, porównanie kontrolerów Omada.

4. AP w pokoju czy na korytarzu?

AP typu in-wall pozwala umieścić radio bliżej użytkownika i wykorzystać doprowadzoną skrętkę. To dobry wariant do rozważenia przy tłumiących ścianach i istniejącym okablowaniu pokojowym. Wadami są większa liczba urządzeń, portów i punktów serwisowych oraz konieczność zaplanowania interferencji między pokojami. Montaż jednego AP na pokój nie zwalnia z projektu radiowego.

AP sufitowy ma sens w lobby, restauracji i przestrzeniach wspólnych. Na kondygnacji pokojowej jego lokalizację dobieramy po pomiarach, a nie według zasady „co trzecie drzwi”. Bezprzewodowy mesh traktujemy jako świadomy kompromis tam, gdzie nie można doprowadzić kabla; backhaul radiowy również potrzebuje dobrego sygnału i zużywa zasoby radiowe.

To przykłady architektury pokojowej, nie lista zakupowa dla każdego hotelu. U6-IW ma inną klasę radia niż EAP615-Wall, a typowy telefon 2×2 nie wykorzysta czterech strumieni w pojedynczym połączeniu. Suma szybkości PHY nie jest przepustowością Internetu; znaczenie ma też gigabitowy uplink. Przed zakupem weryfikujemy wersję regionalną, rewizję sprzętu, firmware i budżet PoE. Specyfikacje: U6 In-Wall i EAP615-Wall.

5. Oddzielenie gości od recepcji: VLAN to dopiero początek

Przykładowy podział poniżej opisuje role, nie gotową konfigurację. Numeracja VLAN jest umowna. Samo utworzenie VLAN-ów nie blokuje routingu między nimi — potrzebne są reguły zapory lub ACL i testy ich działania, również dla IPv6, jeżeli jest włączony.

Izolacja klientów na jednym AP nie musi obejmować urządzeń podłączonych do różnych AP lub portów przewodowych. Ubiquiti rozróżnia izolację sieci, klientów Wi-Fi i reguły na przełącznikach. Weryfikujemy cały tor, w tym port LAN dostępny w pokoju. Ubiquiti: izolacja sieci gościnnej.

Chromecast i AirPlay wymagają dodatkowego projektu: pełna izolacja może uniemożliwić wykrywanie telewizora, a globalne przekazywanie mDNS może ujawnić urządzenia z innych pokoi. Potrzebny jest kontrolowany mechanizm powiązania gościa z właściwym odbiornikiem. Ani jeden VLAN dla całego hotelu, ani samo włączenie mDNS nie rozwiązują tego problemu.

6. Captive portal: kiedy pomaga, a kiedy przeszkadza?

Captive portal to strona autoryzacji przed uzyskaniem dostępu. Ma sens przy voucherach z terminem ważności, określonym czasie sesji, płatnych pakietach lub integracji dostępu z pobytem. UniFi dokumentuje vouchery, RADIUS i zewnętrzny portal; Omada również opisuje autoryzację voucherową. Portal UniFi · vouchery Omada.

Nie jest obowiązkowym dodatkiem do każdego hotelu. Przy prostym, bezpłatnym dostępie może tylko zwiększać liczbę problemów: brak automatycznie otwieranej strony, ponowne logowanie po wygaśnięciu sesji czy urządzenia bez wygodnej przeglądarki. Konsola, telewizor i telefon nie muszą zachowywać się tak samo. Portal nie szyfruje sam z siebie otwartej sieci radiowej i nie zastępuje zapory.

• Portal + voucher: kontrola czasu i wygodne wydawanie dostępu, ale dodatkowa obsługa recepcji i zależność od systemu autoryzacji.
• Wspólne hasło: prosty proces wejścia, ale łatwe przekazywanie hasła i trudniejsze odwołanie dostępu pojedynczemu gościowi.
• PPSK: wiele kluczy w jednym SSID, przydatne np. dla pobytów lub grup urządzeń. W UniFi opisywany PPSK wymaga WPA2 i nie działa w 6 GHz. Omada również wskazuje ograniczenie PPSK do pasm 2,4/5 GHz w dokumentacji ustawień zabezpieczeń. Nie należy utożsamiać PPSK z automatycznym checkoutem w PMS. PPSK UniFi · zabezpieczenia Omada.

Logowanie „numer pokoju + nazwisko” wymaga źródła informacji o pobycie i odpowiedniej integracji. Ubiquiti opisuje taki scenariusz z zewnętrznym portalem i API, ale nie oznacza to gotowego połączenia z każdym PMS. Ustalamy obsługę błędów, przedłużenia pobytu, wygaśnięcia uprawnienia i awarii integracji. Nie zbieramy dodatkowych danych gości bez określenia celu i zasad przetwarzania. UniFi: autoryzacja zewnętrznego portalu.

7. Kontroler sprzętowy, programowy czy chmurowy — i ile kosztuje utrzymanie?

Kontroler zarządza konfiguracją i funkcjami systemu. Nie należy mylić go z routerem: osobny kontroler nie zastępuje bramy internetowej. Urządzenia zintegrowane łączą te role, dlatego ich awaria może mieć szerszy skutek niż utrata samego panelu zarządzania.

To nie są cztery równoważne produkty. Zdalny dostęp przez konto chmurowe do kontrolera w hotelu nie oznacza, że kontroler działa w chmurze. Cloud Gateway UniFi ma własną warstwę zarządzania — nie planujemy jego adopcji do zewnętrznego UniFi Hosting. Źródła: architektura UniFi Hosting i warianty kontrolerów Omada.

Koszt przez trzy lata, nie tylko cena pudełka

Porównanie ofert powinno używać jednakowego zakresu: liczby AP i switchy, funkcji portalu, retencji danych, backupu i czasu obsługi. Dla rozwiązania lokalnego wyceniamy też aktualizacje systemu oraz próbę odtworzenia. Dla chmury sprawdzamy jednostkę rozliczenia, okres licencji, zasady odnowienia i cenę zwiększenia liczby urządzeń.

Przykład organizacyjny: przy 30 AP, 4 przełącznikach i jednej bramie potencjalny zakres zarządzania to 35 urządzeń. Jeśli wybrany plan rozlicza wszystkie te urządzenia, budżet licencji liczymy dla 35, a nie 30 sztuk. To założenie do kalkulacji, nie informacja o stawce konkretnego abonamentu. Nie podajemy jednej ceny „Wi-Fi dla hotelu” bez rzutu obiektu i zakresu prac — koszt okablowania oraz pomiarów może istotnie zmienić wynik.

Dostępność: sprawdź nowych klientów, nie tylko podłączonych

Działający ruch na AP nie dowodzi, że po awarii kontrolera nowy gość przejdzie portal. Trzeba osobno przetestować dostęp do Internetu, DHCP/DNS, uwierzytelnienie i zarządzanie. TP-Link zaleca ciągłą pracę kontrolera dla pełnej funkcjonalności portalu, a zachowanie po jego wyłączeniu zależy od metody autoryzacji. Omada: portal a dostępność kontrolera.

Wariant lokalny ogranicza zależność warstwy zarządzającej od dostępu do chmury, ale wymaga aktualizacji, kopii konfiguracji i odtwarzania. Chmura upraszcza utrzymanie samego kontrolera, lecz wymaga sprawdzenia planu, kompatybilności i zachowania podczas utraty łączności. W obu przypadkach potrzebne są konta administratorów z odpowiednimi uprawnieniami oraz zabezpieczenie dostępu zdalnego.

Budżet obejmuje również okablowanie, pomiary, przełączniki, sumaryczną moc PoE, UPS, uplinki i zapas urządzeń. Dwa łącza WAN pomagają tylko wtedy, gdy istnieje poprawnie przetestowane przełączenie awaryjne; zmiana adresu publicznego może zerwać trwające sesje. Ceny samych AP nie opisują kosztu działającej usługi.

8. Lista odbiorowa: co powinno znaleźć się w protokole?

1. Mapa rozmieszczenia AP, portów, VLAN-ów i plan kanałów oraz zestawienie wersji sprzętu i firmware.
2. Pomiary RSSI, SNR, retransmisji i obciążenia w pokojach oraz miejscach wspólnych.
3. Testy lokalnej transmisji i Internetu, także przy obciążeniu kilku klientów równocześnie.
4. Przejście między AP podczas połączenia głosowego lub wideo na reprezentatywnych urządzeniach.
5. Weryfikacja izolacji gość–gość, gość–recepcja i gość–zarządzanie, również między różnymi AP.
6. Logowanie, wygaśnięcie vouchera, ponowne połączenie i działanie portalu na Androidzie, iOS oraz laptopie.
7. Test nowego logowania przy wyłączonym kontrolerze, niedostępnym portalu i awarii łącza WAN.
8. Backup konfiguracji, procedura przywrócenia, zasady aktualizacji i kontakt dla recepcji.

Projektujesz lub modernizujesz Wi-Fi w hotelu?

Zakres projektu radiowego, segmentacji i konfiguracji znajdziesz w usłudze sieci LAN i Wi-Fi. Jeżeli sieć ma współpracować z recepcją, systemami hotelowymi i innymi urządzeniami obiektu, sprawdź obsługę IT hoteli i apartamentów. Działamy z Krakowa, głównie w Małopolsce i na Podhalu; projekty w innych regionach Polski ustalamy indywidualnie.

Opracowanie redakcyjne IT Node na podstawie dokumentacji producentów sprawdzonej 25 września 2026 r. Parametry należy potwierdzić dla zamawianej rewizji sprzętu i wersji oprogramowania. Przykłady liczbowe i VLAN-y są założeniami projektowymi, nie wynikami pomiarów konkretnego obiektu. Materiał nie jest testem porównawczym wykonanym w laboratorium.