Wie kennst du alle Z-Wave-Schlüssel im Voraus? Das ist es, was ich eigentlich nicht verstehe…
Ich habe ein Thema erstellt, um über diese wichtige Debatte zu sprechen, nämlich die Verwaltung von Instanzen, die langfristig bereitgestellt werden =>
Über die Vendor-ID müssen die neuen Schlüssel berücksichtigt werden, also muss das gepflegt werden, aber der Vorteil ist, dass selbst wenn es keine Regel für einen Schlüssel gibt, er weiterhin unter /dev/ttyACM* verfügbar ist
Es ist einfach ein viel aussagekräftigerer symbolischer Link
Okay, ich verstehe. Aber dann, um auf das andere Thema zurückzukommen, muss das in der Docker-Image gepflegt werden oder muss das auf dem System gepflegt werden? (Was wir nicht wirklich tun können…)
Das ist auf dem Host-System (wir verderben gerade den Thread von @Reno 
)
Ich denke, es kostet nicht viel, das zu tun, es ist ein zusätzliches Feature.
Das stört mich nicht, weil es eine echte Frage ist, die ich mir schon seit einiger Zeit stelle und für die ich noch keine Zeit hatte, sie zu posten.
Ich stimme zu, dass es mehrere Themen gibt.
Auch okay, dass wir /dev freigeben, aber ich bin nicht so begeistert von ‹ –privileged ›, aber das entscheidet @pierre-gilles.
Mein persönliches Beispiel ist, dass ich andere Docker-Container, auf RPi oder NAS, verwende, die ebenfalls Geräte verwenden (USB-Soundkarte, TNT-Tuner, …), und ich habe Angst, dass es zu Konflikten kommt, wenn mehrere Container auf dieselben Geräte zugreifen. Ich werde versuchen, Zeit zum Testen zu finden.
Ich habe den USB-Service von Gladys geändert, um den ‹ Hersteller ›, die ‹ VendorID › und die ‹ ProductID › zu melden, um dem Benutzer zu helfen, die richtige Schnittstelle auszuwählen, wenn er mehrere USB-Dongles hat. Für Zigbee2mqtt funktioniert das gut, da der Dongle als ‹ Texas Instrument › angezeigt wird. Allerdings habe ich festgestellt, dass der Z-Wave-Schlüssel, den ich besitze, eine VendorID statt des Herstellers zurückgibt, was für den Benutzer nicht sehr aussagekräftig ist.
Daher wäre es tatsächlich interessant, den Typ des Dongles in Gladys anzuzeigen (Z-Wave oder Z2M oder …). Das erfordert die Referenzierung aller Dongles, aber ich glaube nicht, dass es so viele gibt. In jedem Fall, wenn wir die VendorID in der Benutzeroberfläche anzeigen lassen, können wir im Fall eines nicht unterstützten Dongles die Tester bitten, diese Information weiterzugeben, um sie zu berücksichtigen.
Für die udev-Regel wird sie entweder in das Gladys-Distributionsimage integriert, oder es muss in jedem Fall ein Startskript für den Container mit den notwendigen Optionen bereitgestellt werden, wenn der Benutzer das Docker-Image bevorzugt.
In diesem Fall könnten wir eine Zeile (oder mehrere) für die Erstellung der udev-Regeln hinzufügen.
Daher könnten wir auch eine Zeile für die Erstellung eines Docker-Netzwerks für Gladys hinzufügen, für den Austausch mit den Containern dieser Dienste (ein anderes Thema, das wir übrigens mit @VonOx und @AlexTrovato haben) 
Auf dem Bild läuft Gladys unter Docker auf Raspbian.
Ich werde die Änderungen vornehmen, um die udev-Regeln in das Raspbian-Image einzubinden. (und die Bereitstellung in der Dokumentation)
Allerdings bin ich beim Netzwerk wirklich nicht begeistert, da wir uns auf den Raspberry und diejenigen beschränken, die es manuell erstellt haben.
Das bedeutet, dass ein Benutzer, der ein anderes Netzwerk verwendet, einen unbrauchbaren Dienst hat, da es hardcoded ist.
Für Dienste, die Container erstellen müssen, ist es am besten, sie im gleichen Netzwerk wie Gladys zu erstellen. Das versucht @AlexTrovato mit MQTT. (Daumen drücken 
)
Wenn es funktioniert, können wir das Netzwerk ohne Probleme erstellen, da keine Einschränkungen mehr bestehen.
Und ich denke, das ist gut, um das Netzwerk zwischen Gladys und den von Gladys erstellten Containern zu teilen. Es bleibt nur noch zu testen 
(aber ich habe localhost als URL belassen)
Ich verstehe nicht, warum du sagst, dass man sich mit dem Netzwerk auf den Rpi beschränkt.
Ich verwende viel Docker (auf Arm und Intel) und definiere immer Netzwerke zwischen den Diensten, um die Kommunikation zwischen den Containern besser zu steuern.
Das wird übrigens von Docker in der Produktion empfohlen:
Use user-defined bridge networks zeigt, wie man eigene benutzerdefinierte Brücken-Netzwerke erstellt und verwendet, um Container zu verbinden, die auf demselben Docker-Host laufen. Dies wird für eigenständige Container empfohlen, die in der Produktion laufen.
Zusätzlich ist es möglich, mehrere Netzwerke für einen Container zu erstellen, und es ist sogar möglich, ein Netzwerk zu erstellen, während ein Container läuft, um es dann an dieses Netzwerk anzuhängen, während es läuft.
Zum Beispiel, beim Dienst Zigbee2mqtt, habe ich ein Netzwerk ‹ gladys-net › erstellt, an dem Gladys angehängt ist, und ich verbinde auch die Container ‹ mqtt › und ‹ zigbee2mqtt › damit. Um dem zu folgen, was ich normalerweise anwende, hätte ich sogar ein spezifisches Netzwerk zwischen den Containern zigbee2mqtt und mqtt erstellen müssen, da der Container zigbee2mqtt nicht dazu bestimmt ist, direkt mit Gladys zu kommunizieren.
Bei mir gibt es auch einen InfluxDB-Container, um alle Daten, die über den MQTT-Broker laufen, in einer Datenbank zu speichern. Dafür definiere ich ein zusätzliches spezifisches Netzwerk zwischen mqtt und influxdb.
Das hindert einen nicht daran, auch das network host zu definieren oder das -p 80:80 zu lassen, um eine Verbindung von einem entfernten Computer aus zu ermöglichen.
Zusätzlich wird diese Konfiguration einen Benutzer, der sich auskennt, nicht daran hindern, ein anderes Netzwerk ‹ gladys-external › zu definieren, das an Gladys angehängt ist, um seine eigenen Container anzuschließen…
Weil wir nur ein Raspbian-Image bereitstellen, also sollten wir nichts in den Diensten hardcodieren.
Noch einmal, ich bezweifle nicht die Berechtigung von Netzwerken (ich mache das selbst mit etwa 15 Containern) und die Isolation. Ich möchte nur eine Lösung, die alle zufriedenstellt.
Dazu würde ich mir noch einmal ein paar mehr Erklärungen wünschen! Ich verstehe immer noch nicht, was das bringt.
Beispiel:
Du hast einen Zigbee- und einen Z-Wave-Dongle, Zigbee auf /dev/ttyACM0 und Z-Wave auf /dev/ttyACM1
Du entscheidest dich für einen Neustart, danach ist das Mounting invertiert, deine Gladys-Dienste funktionieren nicht mehr.
Die udev-Regeln erstellen einen Alias, Z-Wave ist immer auf /dev/zwave und der Zigbee-Dongle auf /dev/zigbee verfügbar.
Das hindert dich nicht daran, /dev/ttyACM* (wer viel kann, kann auch wenig) zu verwenden.
Das habe ich verstanden, aber ich habe nicht verstanden, wie diese Magie funktioniert
Wer entscheidet, welches Gerät auf /dev/zwave landet? Jedenfalls ist es großartig!
Ah entschuldige, aber wir entscheiden das, USB-Geräte haben eine Vendor-ID und eine Product-ID (und die ändern sich nicht)
Ich habe das bisher identifiziert (das ist nur ein Beispiel, nichts ist hier endgültig!)
# Aeotec Zwave S2
SUBSYSTEM=="tty", ATTRS{idVendor}=="10c4", ATTRS{idProduct}=="ea60", SYMLINK+="tty-usb-zwave"
# Aeotec Zwave Gen5
SUBSYSTEM=="tty", ATTRS{idVendor}=="0658", ATTRS{idProduct}=="0200", SYMLINK+="tty-usb-zwave"
# ZWave.me UZB1 stick
SUBSYSTEM=="tty", ATTRS{idVendor}=="0658", ATTRS{idProduct}=="0280", SYMLINK+="tty-usb-zwave"
# Nortek Security & Control HUSBZB-1
SUBSYSTEM=="tty", ATTRS{idVendor}=="10c4", ATTRS{idProduct}=="8a2a", SYMLINK+="tty-usb-zwave-zigbee"
# zigbee2mqtt
SUBSYSTEM=="tty", ATTRS{idVendor}=="0451", ATTRS{idProduct}=="16a8", SYMLINK+="tty-usb-zigbee"
Okay, ich verstehe, danke für die Erklärung Und das, wäre es möglich, das direkt im Docker-Image zu machen? So können wir es nach und nach aktualisieren?
Es gibt ein Äquivalent für Alpine Linux: eudev - Alpine Linux packages
Ich würde sagen ja, aber ich muss es testen.
Falls es tatsächlich funktioniert, ist es besser direkt im Docker-Image
Edit: Es funktioniert:
Ich bin derselben Meinung wie @Reno bezüglich der Option --privileged. In der Sicherheit muss man nach dem Prinzip des geringsten Privilegs arbeiten.
Für Debugging und Entwicklung ist das kein Problem. Aber in der Produktion, vor allem bei einem Bild, das Gladys verteilt, ist es wichtig, die Sicherheit auf allen Ebenen zu berücksichtigen.
Mehrere Personen haben sich bereits die Frage gestellt: https://stackoverflow.com/a/24231872
Im Großen und Ganzen ist die sicherste Methode, nur die gewünschte Ausrüstung zu teilen (Link zur Docker-Dokumentation bestätigt dies) ohne die Option --privileged zu verwenden:
docker run -t -i --device=/dev/ttyUSB0 ubuntu bash
Um den Zugriff auf das gesamte Verzeichnis /dev zu ermöglichen, muss die Option --privileged verwendet werden, aber gibt auch alle Rechte auf dem Host!
Docker erklärt es sehr gut:
Mit anderen Worten, der Container kann dann fast alles tun, was der Host tun kann.
Nichts hindert uns daran, alle Devices zu mounten, die uns interessieren:
docker run -t -i \
--device=/dev/ttyACM0 \
--device=/dev/ttyACM1 \
ubuntu bash
In /dev befinden sich alle Geräte des Systems, warum sollte Gladys Zugriff auf die Festplattenpartitionen, Loopback usw. benötigen?
Wenn es auf dem Host installiert ist, würde das Betriebssystem den Zugriff auf diese Geräte verhindern (außer mit root natürlich), aber mit der Option --privileged denke ich, wird das nicht der Fall sein.
Ich bin voll und ganz deiner Meinung, wenn Gladys schwierig zu deployen ist, zu warten und dem Endbenutzer Zeit abverlangt, wird es nicht funktionieren.
Gladys verwendet Docker, um Updates zu erleichtern, daher wird bei jeder neuen Version der Container gelöscht und dann neu erstellt, oder?
Diese Funktionsweise wird es uns ermöglichen, die Startparameter von Gladys leicht zu ändern, um neuen Zugriff auf den RPi hinzuzufügen und den Entwicklungen zu folgen. Sicherheit und Benutzerfreundlichkeit werden also gut berücksichtigt
Letzter Sicherheitshinweis, sobald die Entwicklungsarbeit abgeschlossen ist, könnten wir uns mit den Linux Capabilities beschäftigen. Dies sind Parameter, die dem Container übergeben werden, um Docker zu zwingen, die Zugriffsrechte auf dem Host zu begrenzen. Gladys muss nicht unbedingt eine neue Netzwerkkarte erstellen, mit dem Kernel interagieren, auf Systemdateien zugreifen (außer Geräte), Partitionen ändern, einen Prozess debuggen usw.
Diese Optionen sind sehr nützlich, um sicherzustellen, dass im Falle einer Kompromittierung des Containers (durch ein schädliches Modul oder wenn ein Benutzer seinen RPi direkt exponiert hat, entgegen den Best Practices) dieser den Host nicht ausnutzen und mehr Schaden anrichten kann (Ransomware im Netzwerk, Spionage usw.).
Ich habe versucht, die Rechte der Container, die ich auf meinem persönlichen Server verwende, zu begrenzen, wenn es euch interessiert, hier ist die Dokumentation und die Beispiele:
- Docker-Dokumentation
- GitHub-Repo und Beispiel für docker-compose (alle Rechte werden entfernt und bei Bedarf hinzugefügt)
- Liste der Linux Capabilities
Beispiel aus der Docker-Dokumentation:
Für die Interaktion mit dem Netzwerk-Stack sollten sie anstelle von
--privileged--cap-add=NET_ADMINverwenden, um die Netzwerkschnittstellen zu ändern.
$ docker run -it --rm ubuntu:14.04 ip link add dummy0 type dummy
RTNETLINK answers: Operation not permitted
$ docker run -it --rm --cap-add=NET_ADMIN ubuntu:14.04 ip link add dummy0 type dummy
Danke und Glückwunsch, wenn ihr alles gelesen habt 
Entschuldigung, dass ich euch noch nicht bei der Entwicklung helfen konnte, sobald ich etwas mehr Zeit habe, mache ich mich an mein Smart-Home-Projekt und helfe euch!
Es ist unmöglich vorherzusagen, wie viele Geräte der Benutzer hat.
Ich vertiefe mich in das Thema mit udev-Regeln
Nein, so läuft das nicht, der Container wird mit denselben Befehlen neu erstellt. Wir nutzen Watchtower
Das ist wirklich interessant (ich habe ein bisschen zu lesen), aber Achtung, es gibt nicht nur Linux-Hosts.
Module gibt es nicht mehr Alles ist integriert.
Danke für deine Vorschläge. Jede Hilfe ist willkommen.
Oups, tatsächlich bin ich noch nicht mit der gesamten Funktionsweise von Gladys v4 vertraut
Was die Geräte angeht, stimmt es, dass man sich genauer anschauen muss, was man einrichten soll. Die Umgebungen der Benutzer werden alle unterschiedlich sein, schwer vorherzusagen, was da sein wird.
Zum Abschluss: Meine Anmerkungen zu Docker gelten für Linux und nicht für Windows
Hallo,
Hier ein kurzes Feedback zu meinen Tests:
- Der Konfigurationsprozess ist super (nachdem ich das kleine Problem mit der Erkennung des Zigbee-Sticks überwunden habe), aber ich muss immer noch einen erzwungenen Neuladen durchführen, damit meine Geräte auf der Discover-Seite angezeigt werden, nachdem sie vom Stick erkannt wurden
- Wenn man direkt zum Discover-Tab navigiert (z. B. indem man die URL eingibt), werden die erkannten Geräte nicht angezeigt. Man muss über den Devices-Tab gehen und dann zurück zum Discover-Tab, um sie zu sehen
- Auf dem Dashboard, wenn ich in den Bearbeitungsmodus wechsle, kann ich keine Box hinzufügen und kann nicht mehr zwischen den Seiten wechseln: Alles stürzt ab. (Ich habe überprüft, ich habe dieses Problem nicht auf der „normalen“ Version von Gladys)
Ich habe den folgenden Fehler in der Konsole:
Konsole
RoomSelector.jsx:21 Uncaught (in promise) TypeError: Cannot read property 'map' of undefined
at RoomSelector.jsx:21
at Array.map (<anonymous>)
at t.o.componentWillReceiveProps (RoomSelector.jsx:18)
at b (preact.min.js:1)
at preact.min.js:1
at p (preact.min.js:1)
at h (preact.min.js:1)
at b (preact.min.js:1)
at d (preact.min.js:1)
Abgesehen davon werden meine Geräte gut erkannt und die Werte werden korrekt übertragen. Ich habe die folgenden Geräte getestet:
- Xiaomi Magic Cube
- Xiaomi Temperatursensor
- Xiaomi Türöffnungssensor
- Xiaomi Wassersensors
- Ikea Steckdose E1603/E1702
- Ikea Fernbedienung E1810
- Ikea LED-Lampe LED1624G9 → erkannt mit Schalt-/Helligkeitsfunktionen, nicht als Licht erkannt, und keine Option für die Farbaustwahl (aber ich glaube, das ist eine laufende Diskussion auf höherer Ebene, wie man einen Farbauswahl-Tool handhaben soll?)
(Ich werde bald neue Geräte zum Testen haben, ich werde so schnell wie möglich aktualisieren)
Vielen Dank für diesen Service, das wird super 
PS: Ich habe die getesteten Geräte aktualisiert
Ich hole das Thema nochmal hoch, um Infos zu bekommen.
Welcher „Plug-and-Play“-Stick ist nutzbar?