Hotel PMS do KNX: Automatyzacja zameldowania/wymeldowania przez bramy Fidelio i Opera
Połączenie systemu zarządzania nieruchomością hotelową z KNX zamienia zameldowanie i wymeldowanie w zautomatyzowane zdarzenia zarządzania budynkiem. Gość meldujący się w recepcji może w ciągu kilku sekund uruchomić scenę powitalną, tryb komfortu HVAC i tryb gotowości telewizora w swoim pokoju – bez dodatkowego działania personelu. Prawidłowa architektura integracji wymaga zrozumienia zarówno modelu zdarzeń PMS, jak i schematu adresów grupowych KNX.
Przegląd systemów PMS
Systemy zarządzania obiektem (PMS) są operacyjnym kręgosłupem hotelu – obsługują rezerwacje, zameldowanie/wymeldowanie, przydział pokoi, rozliczenia, zadania sprzątania i raportowanie. Dla integracji KNX odpowiednią funkcją jest API zdarzeń PMS: mechanizm, za pomocą którego PMS wysyła zdarzenia zmiany stanu pokoju, które middleware może subskrybować.
| System PMS | Segment rynku | API integracji | Opcje bramy KNX |
|---|---|---|---|
| Oracle Opera Cloud | 4–5 gwiazdek, sieci | Opera REST API v3 + webhooks | Loytec LIOR-800, niestandardowe oprogramowanie pośredniczące Node.js |
| Mews PMS | Natywnie chmurowy, butikowy/lifestyle'owy | Mews Webhooks API (REST) | Home Assistant + integracja KNX, niestandardowe oprogramowanie pośredniczące |
| Apaleo | Europejski butik, aparthotele | Apaleo Open API (REST) | Niestandardowe oprogramowanie pośredniczące, most Zapier + KNX |
| Micros Fidelio (starsze) | Szeroko instalowane, hotele miejskie | FIAS (Fidelio Interface API Specification) — gniazdo TCP | HMS Anybus, dedykowana bramka FIAS-KNX |
| Protel Air | Europejskie niezależne hotele | Protel Webhooks + REST | Niestandardowe oprogramowanie pośredniczące Node.js lub Python |
FIAS vs. REST: Starsze instalacje Micros Fidelio używają FIAS – zastrzeżonego protokołu gniazda TCP z tekstowym formatem wiadomości. Nowoczesny Oracle Opera Cloud używa standardowego REST API z webhookami JSON. Podczas integracji ze starszą instalacją Fidelio potrzebny jest dedykowany parser FIAS w warstwie pośredniczącej. Nowe instalacje powinny ujednolicić dostęp do API poprzez Oracle Opera Cloud lub Mews.
Metody integracji PMS z KNX
W przypadku łączności PMS-KNX w hotelach stosowane są cztery różne architektury integracji. Wybór zależy od typu API PMS, wielkości hotelu, dostępności infrastruktury IT oraz wewnętrznych możliwości technicznych do bieżącego utrzymania.
1. Dedykowana bramka PMS-KNX
Urządzenie bramki sprzętowej (np. Loytec LIOR-800) z wbudowanym interfejsem Opera/Fidelio. Łączy się z PMS przez FIAS lub REST; wysyła telegramy KNX przez KNXnet/IP. Zarządzane przez interfejs webowy. Najlepsze dla hoteli 4–5-gwiazdkowych wymagających obsługiwanego rozwiązania jednego dostawcy z SLA.
Zalety: Wspierane przez dostawcę, pojedynczy punkt konfiguracji
Wada: Wyższy koszt (2000–8000 €); zastrzeżone; ograniczona elastyczność
2. Niestandardowe oprogramowanie pośredniczące Node.js/Python
Samodzielnie hostowany serwer (Linux VM lub Raspberry Pi) uruchamiający oprogramowanie pośredniczące, które subskrybuje webhooki PMS, mapuje numery pokoi na adresy grupowe KNX i wysyła telegramy KNX przez gniazdo KNXnet/IP (node-red-contrib-knx lub biblioteka knx w Pythonie). Najbardziej elastyczne; najniższy koszt.
Zalety: Pełna kontrola; niski koszt; obsługiwane dowolne API PMS
Wada: Wymaga programowania i bieżącego utrzymania; brak wsparcia dostawcy
3. Home Assistant + integracja webhooków PMS
HA zainstalowane na lokalnym serwerze ze skonfigurowaną integracją KNX. Webhooki PMS POST do URL webhooka HA. Automatyzacja HA wyodrębnia room_id, mapuje do bloku GA KNX, wyzwala scenę KNX. Praktyczne dla Mews i Apaleo; wymaga publicznego punktu końcowego HTTPS (Cloudflare Tunnel lub dedykowany adres IP).
Zalety: Brak własnego kodu; integracja HA KNX dobrze utrzymana; konfiguracja GUI
Wada: Aktualizacje HA mogą przerwać automatyzacje; nieodpowiednie dla dużych hoteli
4. KNX Virtual / BMS middleware
Platforma systemu zarządzania budynkiem (BMS) (np. Siemens Desigo CC, ABB Ability) z modułem łącznika PMS. Zdarzenia PMS trafiają do BMS; BMS zarządza KNX przez sterownik KNXnet/IP. Klasa korporacyjna; odpowiednia dla dużych sieci hotelowych z istniejącą infrastrukturą BMS.
Zalety: Klasa korporacyjna; pełna integracja BMS; zarządzanie energią
Wada: Wysoki koszt; wymaga wiedzy BMS; przesadzone dla niezależnych hoteli
Przepływ zdarzeń check-in Oracle Opera
Oracle Opera Cloud wysyła webhook przy każdym zdarzeniu cyklu życia gościa. Zdarzenie zameldowania zawiera numer pokoju, nazwisko gościa, datę przyjazdu i przypisany typ pokoju. Oprogramowanie pośredniczące odbiera to zdarzenie i tłumaczy je na telegramy KNX dla przypisanego pokoju.
Webhook zameldowania Opera → przepływ KNX
1. Guest checks in at reception → Opera processes check-in
2. Opera fires POST to middleware webhook:
{
"event": "reservation.check_in",
"room_number": "101",
"guest_name": "Schmidt, Klaus",
"arrival": "2026-06-05T14:00:00Z"
}
3. Middleware receives event:
a. Parse room_number → "101"
b. Map to KNX GA block: main=10, sub=101
c. Build KNX telegram sequence:
→ GA 10/101/5 DPT 18.001 = 0x01 (scene 1: Welcome)
— Lights 70%, blinds 50%, HVAC comfort
→ GA 10/101/4 DPT 9.001 = 21.0 (comfort setpoint)
→ GA 10/101/0 DPT 1.002 = 1 (presence flag: room assigned)
4. KNX IP gateway (KNXnet/IP):
Receives tunnelling request from middleware
Forwards telegram onto KNX TP bus → room 101
5. MDT SCN-RT55 in room 101:
Receives scene 1 telegram → executes welcome scene
Receives setpoint telegram → switches HVAC to comfortAutomatyzacja sekwencji wymeldowania
Zdarzenie wymeldowania uruchamia pełną sekwencję wyłączenia pokoju. Wszystkie ustawienia specyficzne dla gościa są usuwane, obciążenia energetyczne są minimalizowane, a system sprzątania otrzymuje powiadomienie, że pokój jest gotowy do sprzątania.
Sekwencja telegramów KNX wymeldowania
Opera check-out event → middleware → KNX: GA 10/101/5 DPT 18.001 = 0x02 (scene 2: Eco — lights off) GA 10/101/4 DPT 9.001 = 18.0 (economy setpoint — winter) GA 10/101/1 DPT 1.001 = 0 (DND cleared) GA 10/101/2 DPT 1.001 = 0 (MUR cleared) GA 10/101/0 DPT 1.002 = 0 (presence flag: room vacant) Blind control: Blind GA send position 50% (UV protection, neutral) TV: KNX switch actuator GA → TV standby OFF telegram Housekeeping notification: Middleware → housekeeping system API: room 101 vacated Housekeeping app shows room 101 as "Ready for cleaning" (alternatively: KNX GA to housekeeping BMS panel)
Obsługa wcześniejszego wymeldowania: Jeśli gość wymelduje się przed planowanym czasem, Opera natychmiast wysyła zdarzenie wymeldowania. Oprogramowanie pośredniczące musi obsługiwać jednoczesne stany pokoju – jeśli karta jest nadal włożona, gdy nadejdzie zdarzenie wymeldowania, sterownik pokoju pokaże obecność = 1 z przełącznika karty, ale PMS mówi, że pokój jest wolny. Zdarzenie wymeldowania PMS powinno mieć priorytet: oprogramowanie pośredniczące wysyła wartość zadaną ekonomiczną niezależnie od stanu przełącznika karty, a recepcja instruuje gościa, aby pozostawił kartę w recepcji.
Integracja budzenia
Budzenia zaplanowane w PMS mogą wywołać sterowaną przez KNX stopniową scenę oświetleniową w pokoju. Jest to bardziej przyjazne dla gościa niż alarm telefoniczny i pozwala gościowi ustawić godzinę pobudki bezpośrednio w portalu gościa Opera lub na recepcji.
Sekwencja KNX budzenia
Guest requests 07:30 wake-up via Opera guest portal
Opera scheduled task: 07:30:00 → wake-up event for room 101
Middleware receives event at 07:29:50 (10s pre-run buffer):
t+0:00 → GA 10/101/6 DPT 1.001 = 1 (wake-up trigger)
Room display shows: "Good morning — 07:30"
HVAC switches to comfort setpoint (21°C)
t+0:30 → Lighting scene: 10% warm white (gentle start)
t+1:30 → Lighting scene: 30% warm white
t+3:00 → Lighting scene: 60% cool white (fully awake)
t+5:00 → Blind position: 30% (gentle morning light)
Phone call (optional):
Parallel to KNX: middleware triggers PBX phone call to room
(Opera can do this natively — keep as backup)
Wake-up confirmation to PMS:
GA 10/101/6 DPT 1.001 = 0 after 10 minutes
(or: guest acknowledges on room display → GA → middleware → Opera)Integracja webhooka Mews PMS z Home Assistant
Mews to chmurowe natywne PMS z dobrze udokumentowanym REST API i systemem webhooków. Jest preferowanym PMS dla hoteli butikowych i lifestyle'owych. Integracja z Home Assistant zapewnia bez-kodową ścieżkę do automatyzacji pokojów KNX dla mniejszych obiektów bez dedykowanego serwera middleware.
Webhook Mews → Home Assistant → KNX
1. Mews Operations → Settings → Webhooks
→ Add webhook: https://your-ha-instance.domain.com/api/webhook/mews_checkin
→ Events: reservation.check_in, reservation.check_out
2. Home Assistant configuration.yaml:
homeassistant:
packages: !include_dir_named packages/
3. packages/hotel_automation.yaml:
automation:
- alias: "Mews Check-In to KNX"
trigger:
platform: webhook
webhook_id: mews_checkin
action:
- variables:
room: "{{ trigger.json.space_id | default('') }}"
- service: knx.send
data:
address: "10/{{ room }}/5"
payload: 1 # Welcome scene
type: "scene"
- service: knx.send
data:
address: "10/{{ room }}/4"
payload: 21.0
type: "temperature"
4. Public HTTPS endpoint:
Cloudflare Tunnel → HA instance (no port forwarding)
OR: Dedicated public IP with Let's Encrypt SSLMapowanie Space ID: Mews używa identyfikatora space_id opartego na UUID dla pokoi, a nie czytelnego numeru pokoju. Utwórz pomocnika HA (input_select lub template sensor), który mapuje UUID przestrzeni Mews na numery pokoi. Dla 50 pokoi jest to konfiguracja jednorazowa; zaktualizuj mapowanie, jeśli pokoje zostaną przemianowane lub przestrzenie zostaną zrestrukturyzowane w Mews.
Informacja zwrotna o stanie pokoju do PMS
Integracja nie jest jednostronna: zmiany stanu pomieszczenia w KNX powinny aktualizować PMS, aby zapewnić personelowi sprzątającemu i recepcji status pokoju w czasie rzeczywistym. To zamyka pętlę między fizycznym pomieszczeniem a systemem operacyjnym.
| Zdarzenie KNX | Adres grupowy | Akcja PMS |
|---|---|---|
| DND aktywowane | GA 10/pokój/1 = 1 | Opera room status → 'Do Not Disturb'; housekeeping task blocked |
| DND anulowane | GA 10/room/1 = 0 | Opera room status → 'Available for housekeeping' |
| MUR aktywowane | GA 10/room/2 = 1 | Opera housekeeping task created: 'Make Up Room — room XXX' |
| MUR wyczyszczone | GA 10/room/2 = 0 | Zadanie housekeepingu Opera usunięte lub oznaczone jako wykonane |
| Pokój wolny (karta wyjęta) | GA 10/room/0 = 0 | Optional: PMS note 'Guest left room' (not formal check-out) |
| Energia powyżej progu | Energia GA dzienna kWh | Konto gościa Opera: wpis dopłaty za energię (jeśli polityka ma zastosowanie) |
Middleware KNX listener — monitor grup
Middleware subscribes to all GA 10/*/1 (DND status GAs)
using KNXnet/IP group monitor (knx library group_listen):
knx.Group.listen('10/*/1', (msg) => {
const room = extractRoom(msg.destination); // e.g., "101"
if (msg.value === 1) {
operaApi.updateRoomStatus(room, 'DND');
} else {
operaApi.updateRoomStatus(room, 'CLEAN');
}
});
Similarly for GA 10/*/2 (MUR) and GA 10/*/0 (presence).
Run middleware as a systemd service for automatic restart.Pomiar energii w pokoju do rozliczeń z gościem
Niektórzy operatorzy hotelowi pobierają od gości opłaty za zużycie energii elektrycznej powyżej standardowego limitu, szczególnie w przypadku gości długoterminowych lub apartamentów serwisowanych. Liczniki energii podłączone przez KNX na poziomie pokoju czynią to praktycznym bez oddzielnej infrastruktury podliczników.
Konfiguracja pomiaru energii w pokoju
Hardware: Carlo Gavazzi EM110 single-phase MID meter
— DIN rail, Modbus RTU RS485 output
— Accuracy class 1 (MID approved for billing)
— One meter per room at floor distribution board
Interface: Modbus/KNX gateway (e.g., Zennio KLIC-DD or
ABB M2M-WEB-HQ Modbus gateway)
— Poll EM110 register 40097 (kWh active energy) every 15 min
— Write to KNX GA 10/room/10 DPT 14.058 (energy, kWh)
Middleware energy billing logic:
— Read GA 10/room/10 daily at 00:00 (snapshot)
— Calculate daily consumption: today − yesterday
— If daily kWh > 5 kWh threshold:
→ Opera folio entry: "Energy supplement: X kWh × €0.30"
— Monthly report: sum per room per stay
Note: EN 62056 DLMS/COSEM metering is NOT required at
room level — Modbus MID meter is sufficient for hotel
energy billing at the sub-metering level. DLMS/COSEM
is required for utility grid metering only.Odporność middleware i konstrukcja failsafe
Oprogramowanie pośredniczące PMS-KNX musi być odporne na przerwy w sieci, awarie PMS i restarty serwera. Pomieszczenie, które podczas przerwy w sieci pozostaje w trybie ekonomicznym, gdy przebywa w nim gość, stanowi znaczący problem operacyjny.
Wymagania dotyczące odporności
- Oprogramowanie pośredniczące działa jako usługa systemd – automatyczny restart po awarii
- Ponawianie webhooka PMS: jeśli middleware jest niedostępne, Opera kolejkuje i ponawia
- Lokalny przełącznik karty KNX nadpisuje stan PMS (karta włożona = zawsze komfort)
- Watchdog: jeśli brak pulsu PMS przez 60 minut, wyślij komfort do wszystkich zajętych pomieszczeń
- Trwałość stanu: middleware zapisuje stany pomieszczeń do SQLite przy każdej zmianie
- Po restarcie: przywróć ostatni znany stan i wyślij go do KNX
Zasada fail-safe – priorytet przełącznika kart
Wejście przełącznika kart w SCN-RT55P to lokalne wejście sprzętowe – nie zależy od middleware ani łączności sieciowej. Jeśli middleware ulegnie awarii, przełącznik kart nadal steruje obecnością i ekonomicznym przełączaniem HVAC lokalnie w ETS6. Oznacza to, że gość nigdy nie zostanie pozostawiony w zimnym pokoju z powodu awarii oprogramowania. Polecenia PMS są nakładane na lokalną logikę przełącznika kart, a nie zamiast niej.
Potrzebujesz zaprojektowanej i uruchomionej integracji PMS-KNX dla swojego hotelu?
Projektujemy szafy KNX dla hoteli z middlewarem integracji PMS, konfiguracją webhooków Opera i Mews, pomiarem energii w każdym pokoju i pełną dokumentacją uruchomieniową – gotowe do przekazania Twojemu zespołowi IT.
Poproś o wycenę →