Türschließung

[AlexAn]

die Pro kann MQTT - Loxberry
Loxone Miniserver V2 kann per Matter nur Infos an einen Router (z.B. HomePodmini) schicken - von Home/Matter zu Loxone geht noch nix.
Hab die Pro in 3 und 4 und würde nur noch die 4er kaufen wegen Matter

[surus]

Wenn ich kein Loxberry habe, bringt die Pro Version (egal ob 3 oder 4) überhaupt was? Oder muss ich trotzdem ein Nuki Bridge haben, damit alles über die API läuft?

[Wing_Stefan]

Benötigt man mit der V3 bzw. jetzt V4 noch die Brdige? Wie ist die Akkulaufzeit in dem Gerät? Besitze noch die erste Version glaub ich. Nutze kein Loxberry, sondern Nuki über IOBroker, weil das lässt sich prima als Docker auf der Synology einbinden. Das müsste darüber dann auch wieder gehen oder?

[AlexAn]

Mag sein dass es mit der Bridge auch geht aber da würde ich eher einen Loxberry einrichten auf einem Raspberry oder eben auch auf einer Synology:




Akku hängt immer von der Temperatur, Wlan usw. ab.

[Wing_Stefan]

Temperatur , Zimmertemp, okay Tür ist etwas kühler denk ich, WLan TOP Signal keine 3M Luftlinie ohne Hindernis ist ein AP. Komme jetzt ca. 2-2,5 Monate durch mit 4 Batterien, AkkuPack ist leider schon länger defekt und ist auch nichts anderes als 4 Akkus.

Hab mich gegen Loxberry entschieden, da es mir zu unübersichtlich war, mit dem MQTT immer Probleme gab und iobroker einfach Problemlos läuft seitdem ich den hab, ca, 2 Jahre.

[AlexAn]

Den IOBroker hab ich schon vor längerer Zeit begraben da er mir zu viel Pflegeaufwand benötigt hat.
V3 Loxberry läuft bei mir 1A

Hatte früher einiges auf NodeRed, IOBroker, FHEM usw. aber jetzt läuft im wesentlichen nur noch der Loxberry

Im Prinzip aber egal wenn bei dir MQTT am IOBroker läuft oder der Loxone Adapter - sag bitte nicht dass du mit simple API arbeitest

[surus]

Gibt es irgendwo eine Anleitung wie man Loxberry auf Synology installieren kann? Ich möchte nun doch versuchen Nuki über MQTT - Loxberry anbinden.

[AlexAn]

Im Prinzip die hier: https://wiki.loxberry.de/installatio...loxberry/start

[Wing_Stefan]

Nuki Bridge über API und Web Nuki über API. Was spricht dagegen? Hatte Loxberry über MQTT und leider lief es einfach nie sauber, sodass ich mich verlassen konnte. Daher Loxberry und MQTT gekübelt IOBroker Nuki Adapter und da über API. Aber ich bin hier kein Profi wenn mir erklärt wird warum API schlecht sein soll... werd ich auch über Synology der MQTT versuchen

[AlexAn]

weil http bei Loxone 10sec bedeutet
weil MQTT der große Topf ist wo alles reinkommt und bei Bedarf das raus geholt wird was man braucht

ist aber deine Entscheidung...

[towal]

Hallo! Ich verzweifle leider gerade an der integration meines Nuki 3.0 in Loxone. Hab schon alles nach der Reihe gemacht aber leider passiert nichts wenn ich den öffnen oder schließen befehl sende. Kann mir da bitte jemand helfen?

[Labmaster]

Ich gehe sogar noch viel weiter (aber ich arbeite auch in dem Bereich) und würde grundsätzlich Zutrittssysteme nicht über eine IP Verbindung (intern oder extern) und schon gar nicht über eine externe IP Verbindung betreiben.

Wer für viele Jahre Ruhe haben möchte (ohne ständige Sicherheitsupdates und das Risiko irgendwo im Haus einen Bot der so etwas in Zukunft angreifen könnte zu haben) sollte sich auf dedizierte NICHT IP Verbindungen konzentrieren.
Bei NUKI kann ich (wenn man mal das allgemeine Risiko von Nukis Bluetooth außer Acht lässt) das NUKI Hub hier ( https://github.com/technyon/nuki_hub ) empfehlen.
Außer für die Kommunikation beim Konfigurieren (kann dann auch eben nur temporär sein) benötigt man während des normalen Betriebs hier nur Digital I/Os für die Steuerung.
Alternativ, wer zumindest mit interne IP Verbindungen keine Problem hat kann auch direkt per MQTT mit der Bridge kommunizieren. Wenn man z.B. einen Olimex ESP32 POE Board verwendet dann sogar über LAN mit POE Versorgung.

Das ganze System läuft auf einem ESP32 relativ schlank, ohne Linux oder einem sonstigen komplexen und angreifbaren OS.

[Jan W.]

Hab schon alles nach der Reihe gemacht

Bei Nuki gibt es viele Wege zum Ziel: via Nuki Web und somit Cloud, via Bridge und Loxberry Plugin, mit MS Gen. 2 direkt via Bridge. Vielleicht schickst Du nähere Infos, welchen Weg Du verfolgt hast und ein paar Screenshots? Mit den spärlichen Infos wird Dir hier niemand helfen können. Aus meiner Sicht ist es auch zielführender ein neues Thema zu erstellen, als die Frage in so einem alten Beitrag von 2021 zu stellen, der inzwischen schon von mehreren Usern mit irgendwelchen Fragen gekapert worden ist.

Es ist zwar Off-Topic, aber der von Labmaster angesprochene Sicherheitsaspekt muss aus meiner Sicht ganzheitlich betrachtet werden, also unter Einbeziehung aller Komponenten. Die erwähnten Sicherheitsupdates beziehen sich wahrscheinlich auf einen Loxberry (Linux), denn die Bridge aktualisiert sich automatisch, sofern sie mit dem Internet kommunizieren kann. Der MS hat auch eine IP-Adresse und lässt sich ebenfalls via API ansprechen. Eine Erreichbarkeit des MS aus dem Internet über ein Port-Forwarding ist sicherlich sehr bedenklich und daher auf keinen Fall zu empfehlen. Aber auch im LAN gibt viele Angriffsvektoren: sehr viele IoT Gerät verbinden sich mit einer Cloud des jeweiligen Herstellers und in vielen dieser Geräte steckt ein SoC mit Linux als OS. VLANs mit zentraler Firewall können das Risiko deutlich reduzieren, sind aber im Home-Bereich nicht sehr verbreitet.

Die Kommunikation des Hubs über GPIOs kannte ich nicht, aber dafür muss eine Verkabelung vom MS zum Hub möglich sein, der sich in Bluetooth Reichweite zum Lock befindet. In vielen Fällen ist das bei einem Eigenheim wahrscheinlich kein Thema. Der zeitliche Aufwand für die Einrichtung ist beim Hub aus meiner Sicht deutlich höher, als bei der Bridge und bei der Verwendung von MQTT muss man sich schon tiefer mit Security beschäftigen.

[Labmaster]

...
Labmaster angesprochene Sicherheitsaspekt muss aus meiner Sicht ganzheitlich betrachtet werden, also unter Einbeziehung aller Komponenten.
...

Ja, im gesamten Haussteuersystem sollte der Sicherheitsgedanke ganzheitlich betrachtet werden.
Jeder holt sich bedenkenlos immer mehr IoT Zeugs ins Haus ohne überhaupt überblicken zu können was das im Endeffekt bedeutet und was für Auswirkungen das haben kann wenns dann mal kracht.
Es kann ja schon eine "böswillige" Glühbirne reichen welche als Relay nach außen fungiert, wenn dann auch noch alles weitere im Netzwerk hängt ist halt nichts mehr sicher.
Jeder sollte sich auch bewusst sein, dass sobald er Geräte mit komplexen Betriebssystemen und Netzwerkstack einsetzt, diese regelmäßig gewartet und upgedatet werden müssen. Solche Geräte sind keine Selbstläufer und brauchen über Ihre gesamte Laufzeit Aufmerksamkeit. Sobald dann auch noch externe Services dazu kommen noch viel mehr und in kleineren Abständen.
Mein Befürchtung ist, daß sich viele dessen nicht bewusst sind und irgendwann, einfach weil das generische Interesse sich mit der Haustechnik auseinanderzusetzen nachlässt und mal wieder andere Hobbys oder Lebensumstände in den Fokus geraten, das permanente "sich drum kümmern" nachlässt.

Ich ziehe mittlerweile jede einzeln spezialisiert Opensource BareMetal Lösung einer Betriebssystem basierten Lösung vor, vor allem wenn so ein BareMetal System dann noch zwar standardisierte jedoch nicht global vernetze IP Kommunikation verwendet (RS485, CAN, Tree, KNX, DALI, viele Sub GHz RF, ...).

Und ja mir ist bewusst daß der Trend genau in die andere Richtung geht aber das heißt ja nicht das dies richtig ist.

Mit der Geldgier der Anbieter und sorry dafür, "Hirnlosigkeit" der Anwender steuern wir wie auch in vielen anderen Bereichen der Welt direkt in die nächste Falle.
Aber das ist hier sicher das falsche Diskussionsraum. Also sorry für OT