Viesnīcas PMS integrācija ar KNX: reģistrēšanās/izrakstīšanās automatizācija caur Fidelio un Opera vārtejām
Viesnīcas pārvaldības sistēmas savienošana ar KNX pārvērš reģistrēšanos un izrakstīšanos automātiskos ēkas pārvaldības notikumos. Kad viesis reģistrējas reģistratūrā, viņa istabā dažu sekunžu laikā tiek aktivizēta sagaidīšanas aina, komforta režīms HVAC un televizors — bez papildu personāla darbībām. Lai pareizi izveidotu integrāciju, ir jāsaprot gan PMS notikumu modelis, gan KNX grupu adrešu shēma.
PMS sistēmu pārskats
Īpašumu pārvaldības sistēmas (PMS) ir viesnīcas darbības mugurkauls — tās apstrādā rezervācijas, reģistrēšanos/izrakstīšanos, istabu piešķiršanu, rēķinu izrakstīšanu, apkopējas uzdevumus un atskaites. KNX integrācijai svarīga ir PMS notikumu API: mehānisms, ar kuru PMS pārraida istabas stāvokļa izmaiņu notikumus, kuriem starpprogrammatūra var abonēt.
| PMS sistēma | Tirgus segments | Integrācijas API | KNX vārteju iespējas |
|---|---|---|---|
| Oracle Opera Cloud | 4–5 zvaigznes, ķēdes | Opera REST API v3 + tīmekļa āķi | Loytec LIOR-800, pielāgota Node.js programmatūra |
| Mews PMS | Mākoņdatošana, boutique/lifestyle | Mews Webhooks API (REST) | Home Assistant + KNX integrācija, pielāgota programmatūra |
| Apaleo | Eiropas boutique viesnīcas, apartviesnīcas | Apaleo Open API (REST) | Pielāgota starpprogrammatūra, Zapier + KNX tilts |
| Micros Fidelio (mantotā) | Plaši izplatītas, pilsētas viesnīcas | FIAS (Fidelio Interface API Specification) — TCP ligzda | HMS Anybus, īpašs FIAS-KNX vārteja |
| Protel Air | Neatkarīgas Eiropas viesnīcas | Protel Webhooks + REST | Pielāgota starpprogrammatūra Node.js vai Python |
FIAS pret REST: Vecākas Micros Fidelio instalācijas izmanto FIAS — patentētu TCP ligzdas protokolu ar teksta ziņojumu formātu. Mūsdienīgais Oracle Opera Cloud izmanto standarta REST API ar JSON tīmekļa āķiem. Integrējot ar mantoto Fidelio instalāciju, starpprogrammatūras slānī nepieciešams īpašs FIAS parsētājs. Jaunās instalācijas jāstandartizē uz Oracle Opera Cloud vai Mews, lai nodrošinātu tīrāku API piekļuvi.
PMS un KNX integrācijas metodes
Viesnīcas PMS savienošanai ar KNX tiek izmantotas četras atšķirīgas integrācijas arhitektūras. Izvēle ir atkarīga no PMS API veida, viesnīcas lieluma, IT infrastruktūras pieejamības un iekšējām tehniskajām spējām pastāvīgai uzturēšanai.
1. Īpašs PMS-KNX vārteja
Aparatūras vārteja (piem., Loytec LIOR-800) ar iebūvētu Opera/Fidelio saskarni. Savienojas ar PMS caur FIAS vai REST; izvada KNX telegrammas caur KNXnet/IP. Pārvaldāms caur tīmekļa saskarni. Vislabāk piemērots 4–5 zvaigžņu īpašumiem, kuriem nepieciešams atbalstīts, viena piegādātāja risinājums ar SLA.
Priekšrocības: Ražotāja atbalstīts, vienots konfigurācijas punkts
Trūkumi: Augstākas izmaksas (€2,000–8,000); patentēts; ierobežota elastība
2. Pielāgota starpprogrammatūra Node.js/Python
Pašbūvēts serveris (Linux VM vai Raspberry Pi) ar starpprogrammatūru, kas abonē PMS tīmekļa āķus, kartē istabu numurus uz KNX grupu adresēm un sūta KNX telegrammas caur KNXnet/IP ligzdu (node-red-contrib-knx vai knx Python bibliotēka). Maksimāla elastība; zemākās izmaksas.
Priekšrocības: Pilna kontrole; zemas izmaksas; atbalsts jebkuram PMS API
Trūkumi: Nepieciešama izstrāde un pastāvīga uzturēšana; bez ražotāja atbalsta
3. Home Assistant + PMS tīmekļa āķu integrācija
HA instalēts lokālajā serverī ar konfigurētu KNX integrāciju. PMS tīmekļa āķi sūta POST pieprasījumus uz HA tīmekļa āķa URL. HA automatizācija izvelk room_id, kartē to uz KNX GA bloku un iedarbina KNX ainu. Praktiski Mews un Apaleo; nepieciešams publisks HTTPS galapunkts (Cloudflare Tunnel vai dedicēta IP adrese).
Priekšrocības: Bez koda; HA KNX integrācija labi uzturēta; GUI konfigurācija
Trūkumi: HA atjauninājumi var salauzt automatizācijas; nav piemērots lielām viesnīcām
4. KNX Virtual / BMS starpprogrammatūra
Ēkas pārvaldības sistēmas (BMS) platforma (piem., Siemens Desigo CC, ABB Ability) ar PMS savienotājmoduli. PMS notikumi nonāk BMS; BMS pārvalda KNX caur KNXnet/IP draiveri. Uzņēmumu līmenis; piemērots lielām viesnīcu ķēdēm ar esošu BMS infrastruktūru.
Priekšrocības: Uzņēmumu līmenis; pilna BMS integrācija; enerģijas pārvaldība
Trūkumi: Augstas izmaksas; nepieciešamas BMS zināšanas; pārspīlēts neatkarīgām viesnīcām
Oracle Opera reģistrācijas notikumu plūsma
Oracle Opera Cloud nosūta tīmekļa āķi katrā viesa dzīves cikla notikumā. Reģistrācijas notikums satur istabas numuru, viesa vārdu, ierašanās datumu un piešķirto istabas tipu. Starpprogrammatūra saņem šo notikumu un pārvērš to KNX telegrammās piešķirtajai istabai.
Opera reģistrācijas tīmekļa āķis → KNX plūsma
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 comfortIzrakstīšanās secības automatizācija
Izrakstīšanās notikums iedarbina pilnu istabas izslēgšanas secību. Visi viesa iestatījumi tiek dzēsti, enerģijas patēriņš tiek samazināts līdz minimumam, un apkopējas sistēma saņem paziņojumu, ka istaba ir gatava tīrīšanai.
KNX telegrammu secība izrakstīšanās laikā
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)
Agrīnas izrakstīšanās apstrāde: ja viesis izrakstās pirms plānotā laika, Opera nekavējoties nosūta izrakstīšanās notikumu. Starpprogrammatūrai jāapstrādā vienlaicīgi istabas stāvokļi — ja karte joprojām ir ievietota, kad pienāk izrakstīšanās notikums, istabas kontrolieris rādīs klātbūtni = 1 no kartes slēdža, bet PMS saka, ka istaba ir brīva. PMS izrakstīšanās notikumam jābūt prioritāram: starpprogrammatūra nosūta ekonomisko iestatījumu neatkarīgi no kartes slēdža stāvokļa, un reģistratūra lūdz viesi atstāt karti reģistratūrā.
Modināšanas zvana integrācija
PMS ieplānotie modināšanas zvani var iedarbināt KNX vadītu pakāpeniskas apgaismošanas ainu istabā. Tas ir viesiem draudzīgāk nekā telefona zvana modinātājs un ļauj viesim iestatīt modināšanas laiku tieši Opera viesu portālā vai reģistratūrā.
KNX secība modināšanas zvanam
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)Mews PMS webhook integrācija ar Home Assistant
Mews ir mākoņa PMS ar labi dokumentētu REST API un webhook sistēmu. Tā ir iecienīta boutique un lifestyle viesnīcās. Integrācija ar Home Assistant nodrošina bezprogrammēšanas ceļu uz KNX numuru automatizāciju mazākiem īpašumiem bez atsevišķa middleware servera.
Mews webhook → 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 SSLTelpas ID kartēšana: Mews izmanto UUID bāzētu space_id numuriem, nevis cilvēkiem lasāmu numura apzīmējumu. Izveidojiet HA palīgelementu (input_select vai template sensor), kas kartē Mews telpu UUID ar numuru numuriem. 50 numuriem tā ir vienreizēja konfigurācija; atjauniniet kartējumu, ja numuri tiek pārnumurēti vai telpas tiek pārstrukturētas Mews.
Numura stāvokļa atgriezeniskā saite uz PMS
Integrācija nav vienvirziena: KNX numura stāvokļa izmaiņām jāatjaunina PMS, lai uzkopšanas personālam un reģistratūrai būtu reāllaika informācija. Tas noslēdz cilpu starp fizisko numuru un operacionālo sistēmu.
| KNX notikums | Grupas adrese | PMS darbība |
|---|---|---|
| DND aktivizēts | GA 10/room/1 = 1 | Opera room status → 'Do Not Disturb'; housekeeping task blocked |
| DND noņemts | GA 10/room/1 = 0 | Opera room status → 'Available for housekeeping' |
| MUR aktivizēts | GA 10/room/2 = 1 | Opera housekeeping task created: 'Make Up Room — room XXX' |
| Karte izņemta | GA 10/room/2 = 0 | Housekeeping uzdevums dzēsts vai atzīmēts kā pabeigts |
| Numurs brīvs (karte izņemta) | GA 10/room/0 = 0 | Optional: PMS note 'Guest left room' (not formal check-out) |
| Enerģijas patēriņš virs sliekšņa | Enerģijas GA diennakts kWh | Opera viesu konts: enerģijas piemaksas ieraksts (ja politika paredz) |
Middleware KNX klausītājs — grupu monitors
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.Enerģijas uzskaite pa numuriem viesu rēķinu izrakstīšanai
Dažas viesnīcas iekasē no viesiem maksu par elektroenerģijas patēriņu virs normas, īpaši ilgstošas uzturēšanās vai apartamentu viesiem. KNX savienoti enerģijas skaitītāji numura līmenī padara to iespējamu bez atsevišķas apakšuzskaites infrastruktūras.
Enerģijas uzskaites iestatīšana pa numuriem
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.Middleware noturība un drošības dizains
PMS-KNX middleware jābūt noturīgam pret tīkla pārtraukumiem, PMS dīkstāvi un serveru restartiem. Numurs, kas tīkla pārtraukuma laikā iestrēgst ekonomiskajā režīmā, kamēr viesis atrodas iekšā, ir būtiska darbības problēma.
Noturības prasības
- Middleware darbojas kā systemd serviss — automātisks restartēšana avārijas gadījumā
- PMS webhook atkārtojums: ja middleware nav pieejams, Opera rindā un atkārto
- Lokālais KNX kartes slēdzis ignorē PMS stāvokli (karte ievietota = vienmēr komforts)
- Uzraugs: ja 60 minūtes nav PMS heartbeat, nosūtīt komfortu visiem aizņemtajiem numuriem
- Stāvokļu saglabāšana: starpprogrammatūra saglabā numuru stāvokļus SQLite datubāzē pie katras izmaiņas
- Pārstartējot: atjauno pēdējo zināmo stāvokli un atkārtoti nosūta to KNX
Kļūmjdrošības noteikums — kartes slēdža prioritāte
Kartes slēdža ieeja SCN-RT55P ir lokāla aparatūras ieeja — tā nav atkarīga no starpprogrammatūras vai tīkla savienojuma. Ja starpprogrammatūra sabojājas, kartes slēdzis joprojām kontrolē klātbūtni un HVAC ekonomisko režīmu lokāli ETS6. Tas nozīmē, ka viesis nekad nepaliks aukstā istabā programmatūras kļūmes dēļ. PMS komandas tiek uzliktas virs lokālās kartes slēdža loģikas, nevis tās vietā.
Nepieciešama PMS-KNX integrācijas izstrāde un konfigurēšana jūsu viesnīcai?
Mēs projektējam viesnīcu KNX paneļus ar PMS integrācijas starpprogrammatūru, Opera un Mews tīmekļa pieslēgvietu konfigurāciju, enerģijas uzskaiti pa istabām un pilnu dokumentāciju — gatavu nodošanai jūsu IT komandai.
Pieprasīt piedāvājumu →