Na jednej z realizacji w Trójmieście — wynajmowanym apartamencie — pojawił się klasyczny problem: zamek Tedee działa świetnie ze swojej aplikacji, ale właściciel chciał, żeby otwieranie drzwi i podgląd „otwarte/zamknięte” siedziały w tej samej wizualizacji Loxone co reszta domu. Jedno miejsce, jeden ekran, bez przeskakiwania między aplikacjami. Loxone nie ma natywnego sterownika Tedee, więc trzeba było to spiąć ręcznie — i okazało się to prostsze, niż wygląda. Poniżej cały przypadek od zera do działającej integracji.
Czy Tedee da się połączyć z Loxone bez chmury?
Tak — od firmware mostka 2.2 Tedee Bridge udostępnia lokalne API HTTP, więc Loxone steruje zamkiem bezpośrednio w sieci LAN, bez pośrednictwa serwerów Tedee. Miniserver wysyła proste żądania POST (otwórz/zamknij) i cyklicznie odpytuje stan zamka. Wszystko jedzie lokalnie i działa nawet przy chwilowym braku internetu.
Jeden warunek: mostek Tedee Bridge jest obowiązkowy. Sam zamek komunikuje się tylko po Bluetooth — to Bridge wystawia API w sieci i tłumaczy je na BLE. Bridge potrzebuje dostępu do internetu (odświeża certyfikat), ale samo sterowanie pozostaje w LAN.
Jak działa integracja Tedee z Loxone?
Integracja opiera się na trzech elementach: wirtualnym wyjściu (sterowanie), wirtualnym wejściu HTTP (status) i autoryzacji tokenem. Schemat jest taki:
- Sterowanie: wirtualne wyjście Loxone →
POST http://<IP_BRIDGE>/v1.0/lock/<ID>/unlock(i/lock) - Status: wirtualne wejście HTTP odpytuje
/v1.0/lock/<ID>i czyta polestate— 2 = otwarty, 6 = zamknięty - Autoryzacja: nagłówek (lub parametr)
api_token
Token Tedee ma dwa tryby: szyfrowany i „plain”. Tryb szyfrowany wymaga policzenia hasha SHA-256 z tokenu i znacznika czasu przy każdym żądaniu — czego wirtualne wyjście Loxone po prostu nie policzy. Dlatego wybraliśmy tryb plain, ale tylko dlatego, że mostek siedzi w odseparowanej sieci automatyki (brak dostępu z internetu i z sieci gości). Token to dosłownie otwarcie drzwi — w trybie plain trzymanie Bridge w izolowanym VLAN-ie nie jest opcją, tylko warunkiem.
Od czego zacząć konfigurację?
Zacznij od włączenia lokalnego API w aplikacji Tedee i odczytania ID zamka. W aplikacji: mostek → Settings → API → włącz, zapisz api_token i adres IP (nadaj rezerwację DHCP, żeby się nie zmieniał), wyłącz „Token szyfrujący”. Potem z dowolnego klienta w sieci:
GET http://<IP_BRIDGE>/v1.0/lock z nagłówkiem api_token
W odpowiedzi znajdziesz id zamka, pole state, batteryLevel oraz pullSpringEnabled (czy zadziała komenda dociągania zaczepu). To id wchodzi do wszystkich późniejszych komend.
Najczęstszy błąd: 411 Length Required
Jeśli przy pierwszym otwarciu z Loxone dostajesz 411 Length Required, to znaczy, że POST poszedł bez treści. Loxone domyślnie nie wysyła body przy pustym poleceniu, a mostek Tedee odrzuca żądanie bez nagłówka Content-Length. Rozwiązanie jest banalne, ale nieoczywiste: wpisz {} w pole HTTP body (dla załączenia i wyłączenia). Po tej zmianie mostek odpowiada 204 No Content — i to jest sukces, nie 200.
To była jedyna realna pułapka w całym wdrożeniu. Reszta to przepisanie ścieżek i tokenu.
Jak pokazać realny stan zamka w wizualizacji?
Żeby wizualizacja pokazywała prawdę (a nie tylko pozycję przełącznika), dodaj wirtualne wejście HTTP odpytujące zamek co 30 sekund. Tu jest drobny haczyk: wejście HTTP w Loxone nie ma pola na nagłówek, więc token podajemy w adresie:
http://<IP_BRIDGE>/v1.0/lock/<ID>?api_token=<TOKEN>
Następnie w rozpoznawaniu polecenia wyłuskujemy wartość pola state wzorcem "state":\v. I tu kolejna częsta pomyłka: w składni Loxone \v = wartość, a \i to NIE liczba całkowita, tylko „przejdź za tekst”. Cudzysłów na początku ("state") chroni przed przypadkowym złapaniem pola doorState. Wartość mapujemy na blok statusu: 2 = Otwarte, 6 = Zamknięte, reszta = „w trakcie”. Analogiczne wejście z "batteryLevel":\v daje poziom baterii i alarm mailowy poniżej 20%.
Efekt: w aplikacji Loxone właściciel ma przycisk „Otwórz drzwi”, kłódkę pokazującą realny stan (także po otwarciu kodem PIN albo z aplikacji Tedee) i poziom baterii — wszystko obok ogrzewania, rolet i świateł.
A dostęp dla najemców? Spięcie z systemem rezerwacji
Tu robi się najciekawiej — bo w apartamencie na wynajem dostęp gości można w pełni zautomatyzować. Tedee integruje się z menedżerami kanałów rezerwacji (np. Guesty, Smoobu), które synchronizują się z Booking.com, Airbnb czy VRBO. Dla każdej rezerwacji system generuje tymczasowy kod PIN, wysyła go gościowi mailem przed przyjazdem, a po wymeldowaniu kod sam wygasa. Zero kluczy, zero umawiania się na odbiór.
Kod wpisuje się na Tedee Keypad (model PRO obsłuży do 100 PIN-ów z indywidualnymi uprawnieniami). Tedee rozwija też dostęp przez NFC — kartą lub telefonem (m.in. przez integrację z Doordeck), co zastępuje fizyczne karty zbliżeniem urządzenia. Bez menedżera kanałów też się da: czasowe kody nadasz ręcznie w aplikacji lub portalu Tedee.
A gdzie w tym Loxone? Loxone i ekosystem Tedee grają razem, nie zamiast siebie. Rotacja kodów gości (PIN/NFC powiązane z rezerwacją) siedzi po stronie Tedee + booking, a Loxone odpowiada za codzienną obsługę „domownika” (właściciel, serwis, sprzątanie), podgląd stanu i baterii oraz wyzwalanie otwarcia z dowolnej logiki automatyki — np. jednym przyciskiem na wizualizacji albo scenariuszem. Razem dają pełną kontrolę: automatyczny, bezobsługowy dostęp gości plus realny obraz tego, co dzieje się z drzwiami.
Pamiętaj jeszcze o autoLock (np. 300 s) — zamek zamyka się sam, więc nie buduj automatyki zamykania, która się z tym pobije. Uwaga praktyczna: integracja z menedżerem kanałów to zwykle dodatkowa, płatna usługa zewnętrzna.
To wdrożenie zajęło dosłownie kilkadziesiąt minut, a daje spójność, której nie da żadna osobna aplikacja: jeden ekran na cały dom — i gotowość pod automatyczny wynajem. Jeśli planujesz automatykę Loxone w modelu DIY i chcesz, żeby zamek, ogrzewanie i energia działały pod jednym dachem cyfrowym — zajrzyj do zestawów LOXEM albo napisz, doradzimy dobór.
LOXEM BUILD by RamaR — automatyka Loxone w modelu DIY. Zestawy wysyłamy w całej Polsce, programujemy zdalnie z Gdańska.
Dodaj komentarz