Viesnīcas automatizācija · Oracle Opera · Mews PMS · KNX vārteja · PMS integrācija · 10 min lasīšanai

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ēmaTirgus segmentsIntegrācijas APIKNX vārteju iespējas
Oracle Opera Cloud4–5 zvaigznes, ķēdesOpera REST API v3 + tīmekļa āķiLoytec LIOR-800, pielāgota Node.js programmatūra
Mews PMSMākoņdatošana, boutique/lifestyleMews Webhooks API (REST)Home Assistant + KNX integrācija, pielāgota programmatūra
ApaleoEiropas boutique viesnīcas, apartviesnīcasApaleo Open API (REST)Pielāgota starpprogrammatūra, Zapier + KNX tilts
Micros Fidelio (mantotā)Plaši izplatītas, pilsētas viesnīcasFIAS (Fidelio Interface API Specification) — TCP ligzdaHMS Anybus, īpašs FIAS-KNX vārteja
Protel AirNeatkarīgas Eiropas viesnīcasProtel Webhooks + RESTPielā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 comfort

Izrakstīš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 SSL

Telpas 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 notikumsGrupas adresePMS darbība
DND aktivizētsGA 10/room/1 = 1Opera room status → 'Do Not Disturb'; housekeeping task blocked
DND noņemtsGA 10/room/1 = 0Opera room status → 'Available for housekeeping'
MUR aktivizētsGA 10/room/2 = 1Opera housekeeping task created: 'Make Up Room — room XXX'
Karte izņemtaGA 10/room/2 = 0Housekeeping uzdevums dzēsts vai atzīmēts kā pabeigts
Numurs brīvs (karte izņemta)GA 10/room/0 = 0Optional: PMS note 'Guest left room' (not formal check-out)
Enerģijas patēriņš virs sliekšņaEnerģijas GA diennakts kWhOpera 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 →
Ielādējas...
Uz augšu