A szálloda már tudja, ki érkezik. A technológia is tudja ezt.
A recepción a PMS-ben szerepel a foglalás, a fűtésnek saját ütemezése van, a zárak pedig további adminisztrációt igényelnek. Ha a tartózkodás meghosszabbodik, vagy a vendég szobát vált, ugyanazt az információt több helyre is át kell vinni. Éppen ezeket az ismétlődő beavatkozásokat veheti át az automatizálás.
Az Ellipse PMS API-n keresztül elérhetővé teszi a tartózkodásokra, a foglaltságra és az aktuálisan érvényes PIN-kódokra vonatkozó adatokat. Az integrációs szolgáltatás rendszeresen letölti ezeket, és parancsokká alakítja át az adott beléptető rendszer, a fűtésszabályozás vagy az okosotthon számára.
Bármely olyan rendszer összekapcsolható, amely megfelelő interfészen vagy átjárón keresztül külső vezérlést tesz lehetővé. Az egyszeri beállítás után az adatcsere automatikusan zajlik. A kompatibilitást és a vezérlés hatókörét az adott eszköz esetében kell ellenőrizni; az Ellipse API önmagában nem helyettesíti a gyártó vezérlőjét.
A szálloda számára ez kevesebb adatátírást, egységes információforrást és a szoba tartózkodásnak megfelelő előkészítésének lehetőségét jelenti. A tényleges energia- és időmegtakarítást üzemeltetés közben kell értékelni. Az API biztosítja az alapadatokat, a konkrét hőmérsékleteket és az üzemeltetési szabályokat pedig az integrátor állítja be a szállodával együttműködve.
Négy hívás, egy adatforrás
Az integráció a https://hotel.example.com/api/stays/ szállodai címről olvassa be az adatokat. A domain csak példaként szolgál; a bevezetéskor a konkrét szálloda címével helyettesítik. Az összes leírt hívás a GET metódust, a HTTP Basic hitelesítést és a stays:read jogosultságot használja. A sikeres válasz állapota 200, típusa pedig application/json.
A meglévő integráció percenként tölti be a hőtérképet, a tűtérképet és a listát, a szobapárok térképét pedig óránként egyszer. Ez egy dokumentált felhasználási mód, nem pedig az azonnali kézbesítés garanciája. A változás a következő sikeres betöltéskor és feldolgozáskor jelenik meg a célrendszerben.
curl --fail --silent --show-error \
--connect-timeout 5 --max-time 15 \
--user "$ELLIPSE_USER:$ELLIPSE_PASSWORD" \
"https://hotel.example.com/api/stays/?type=roompairs"A példában szereplő környezeti változók a hozzárendelt bejelentkezési adatokat jelölik. A hívások a szerverre vagy az integrációs átjáróra irányulnak, HTTPS-en keresztül. A bejelentkezési adatok nem szerepelhetnek nyilvános JavaScript-kódban, sem az URL-ben.
A legfontosabb a szobák leképezése. A válaszban szereplő „12” kulcs az adott egység azonosítója a szálloda térképén. A „name: „202” a szobaszám, az „id_room: „2” pedig a szobakategóriát jelöli. A kategória nem a zár azonosítója. Az integrációban ezért a következő kapcsolat jön létre: 12-es egység → 202-es szoba → konkrét zár és termosztát.
Fűtés: a foglalt éjszakák alapján tervezzen
A heatmap lekérdezés visszaadja az összes aktív egységet, valamint a mai napra és a következő hat napra vonatkozó tervet. A status: 1 érték foglalt éjszakát, a status: 0 pedig szabad éjszakát jelöl. Az a nap, amikor a vendég már csak távozik, nem számít foglalt éjszakának.
GET /api/stays/?type=heatmapA válasz példája egy egységre korlátozódik; mind a hét dátumot megőrzi:
{
"12": {
"id": "12", "name": "202", "id_room": "2",
"statuses": [
{ "date": "2026-10-08", "status": 1 },
{ "date": "2026-10-09", "status": 0 },
{ "date": "2026-10-10", "status": 1 },
{ "date": "2026-10-11", "status": 1 },
{ "date": "2026-10-12", "status": 1 },
{ "date": "2026-10-13", "status": 0 },
{ "date": "2026-10-14", "status": 0 }
]
}
}Gyakorlati példa: a szabályozó a jövőbeli kihasználtság alapján beállítja a kényelmi üzemmódot az érkezés előtt és a leállítást a távozás után. Az előreállítás és a hőmérsékletek a célszabályozás szabályai, nem pedig az API által visszaadott értékek.
Figyelem a távozás napjának reggelére: a status: 0 nem jelenti azt, hogy a vendég már elment. Az időbeli döntésekhez használja a tartózkodási és távozási időre vonatkozó adatokat is. A hőtérkép nem szolgál a szobában tartózkodó személy jelenlétének érzékelésére; ezért ne kapcsolja ki a világítást vagy a fűtést kizárólag egy foglaltsági érték alapján.
Hozzáférés: jelenleg érvényes PIN
A pinmap hívás minden egység aktuális PIN-kódját adja vissza. A PIN-kód az érkezés napján a foglalás érkezési idejétől aktiválódik; ha a foglalásnak nincs saját ideje, akkor a szálloda alapértelmezett ideje kerül alkalmazásra. A távozás napján a távozási időpontig érvényes.
GET /api/stays/?type=pinmap{
"12": {
"id": "12", "name": "202",
"id_room": "2", "pin": "1234"
},
"13": {
"id": "13", "name": "203",
"id_room": "2", "pin": "5678"
},
"14": {
"id": "14", "name": "204",
"id_room": "2", "pin": "0"
}
}A „0” PIN-kód szabad szobát jelöl, amelyhez nincs érvényes vendéghozzáférés. Az integrációnak vissza kell vonnia a vonatkozó vendégjogosultságot; nem állíthatja be a 0 számot hozzáférési kódként. Az egyéb PIN-kódok négyjegyű karakterláncok. Tartsa meg őket szövegként, hogy az esetleges elején álló nulla ne vesszen el.
Vendégcsere ugyanazon a napon: ha az új vendég érkezési ideje már lejárt, az API az új foglalás PIN-kódját adja vissza. Az integrációs szolgáltatásnak át kell vinnie a változást a megfelelő zárba, és ellenőriznie kell a beírás eredményét. Az API sikeres lekérése még nem jelenti a készülék sikeres beállítását.
Ez a hívás az aktuális állapotot adja vissza, nem pedig a kódok jövőbeli érvényességi ütemtervét. Az adat nem tartalmazza a fizetési feltételt, sem a befejezett online bejelentkezést. Ha a szálloda ilyen feltételeket támaszt, azokat külön kell ellenőrizni és rendezni a belépés engedélyezésének folyamatában.
Tartózkodások és szobatérkép: az automatizálás kontextusa
Ha az integrációnak szüksége van a tartózkodás dátumaira és időpontjaira, a listát használja. A date paraméter kötelező, formátuma YYYY-MM-DD. Az acmd=1 beállítás esetén a rendszer visszaadja az adott napon a listán szereplő összes tartózkodást, még a bejelentkezés előttieket is. Ennek hiányában, azaz acmd=0 esetén, csak azok a szobák maradnak meg, ahol a vendég már be van jelentkezve.
GET /api/stays/?type=list&date=2026-10-08&acmd=1[
{
"room": "13", "roomname": "203",
"reservation": "100001", "lang": "sk",
"name": "Név", "surname": "Vezetéknév",
"arrival": "2026-10-07",
"departure": "2026-10-09",
"a-time": "15:00:00", "d-time": "10:00:00",
"pin": "5678", "phone": "+421900000000",
"out_of_order": false
}
]A „room” azonosítja a szobát. az „a-time” és a „d-time” az adott szoba érkezési és távozási idejét jelöli. Az „out_of_order: true” érték műszaki lezárást jelöl, nem a hőmérsékletet. A tartózkodások listájában szereplő PIN-kódot ne használja az aktuális érvényesség igazolására; erre szolgál a pinmap.
Hiányzó vagy helytelen dátum esetén az API 400-as állapotkódot és {"error":"Date"} választ ad vissza. Rendszeres lekérdezés esetén a dátumot módosítani kell; a példaként szereplő dátum nem maradhat rögzítve a termelési integrációban.
A roompairs térkép hozzárendeli az egység azonosítóját a szobaszámhoz. Az alábbiakban a válasz egy részlete látható:
GET /api/stays/?type=roompairs{ "12": "202", "13": "203", "14": "204", "21": "303" }A térképet indításkor töltsd be, majd frissítsd rendszeresen. A vendég áthelyezésekor vagy a szálloda konfigurációjának megváltozásakor ellenőrizd a fizikai eszközökhöz fűződő kapcsolatokat is.
Hogyan jön létre megbízható automatizálás az adatokból
Az Ellipse oldalán elegendő az egységes API olvasása. Az integrációs szolgáltatás ezután összehasonlítja a kapott állapotot a legutóbb sikeresen alkalmazott állapottal, és a gyártó interfészén keresztül végrehajtja a szükséges változtatásokat. Ugyanazon állapot ismételt betöltése nem eredményezhet duplikált hozzáférési kódokat vagy felesleges parancsokat.
Az integrátor számára ajánlott eljárás:
- Szerezzen hozzáférést a szálloda API-jához
a stays:readjogosultsággal, és ellenőrizze a HTTPS-kapcsolatot. - A
roompairsegységeket konkrét zárakhoz és szabályozókhoz kell hozzárendelni. - Töltse be a kívánt állapotokat, ellenőrizze az HTTP-választ és a JSON-szerkezetet.
- Értékelje ki az eltéréseket, és alkalmazza azokat a célrendszer felületén keresztül.
- Erősítse meg a végrehajtást, mentse el az utolsó sikeres szinkronizálás idejét, és jelezze a hibát.
Az API-leállás nem jelenti azt, hogy szabad hely van. Hiba, időtúllépés vagy hiányos válasz esetén ne állítsa a pin-kódot „0”-ra, és ne adjon parancsot a fűtés kikapcsolására. Előre állítsa be az adatok maximális érvényességi idejét, a leállás esetén alkalmazandó szabályokat és a kézi beavatkozást. A hozzáféréseknél az üzemeltetésnek megoldania kell a lejáratot is, ha a szinkronizálás nem elérhető; az aktuális pinmap önmagában nem tartalmaz lejárati időt.
A fűtésnél vegye figyelembe a helyi eszközvédelmet és az üzemeltetési minimumot. A hozzáférések során a vendégszinkronizálás nem módosítja sem a szerviz-, sem a vészhelyzeti jogosultságokat. Az API-jelszavakat és PIN-kódokat ne tárolja a szokásos naplófájlokban. Az endpoint listából csak azokat az adatokat dolgozza fel, amelyekre az integrációnak szüksége van.
Az indítás előtt tesztelje a korábbi érkezést, a későbbi távozást, a tartózkodás meghosszabbítását, a szobaváltást, a vendégek cseréjét egy napon belül, a technikai lezárást és a hálózati kimaradást is. Az API-implementálóval egyeztesse az időzónát, a határidőket és a tartózkodás lemondása esetén követendő eljárást; a mellékelt dokumentáció ezeket nem részletezi.
Ugyanezek az adatok alapul szolgálhatnak további okosotthon-forgatókönyvekhez is, például a szoba kényelmi üzemmódjának előkészítéséhez. Ezek megvalósítása a célrendszer funkcióitól függ. A leírt API kiolvassa a tartózkodásokat; az eszközöknek szóló parancsokat az integrációs réteg hajtja végre.
Szeretné összekapcsolni technológiáit az Ellipse-szel? Küldje el nekünk a beléptető rendszer vagy a szabályozó rendszer nevét és modelljét, valamint integrátorának elérhetőségét. Együtt ellenőrizzük az interfészt, a szobák leképezését és a megfelelő vezérlőt. Egyeztessen konzultációt, vagy tekintse meg az Ellipse szállodai rendszerét.
