Zigbee2MQTT und Synology DS920+ unter 7.2, Problem nach Synology-Upgrade

Guten Abend,
Ich habe ein Problem nach einem Update meines Synology NAS DS920+ auf Version 7.2
Egal, ob ich den Dongle am USB-Port anschließe oder abziehe, Gladys zeigt mir immer nur das Folgende an:
Ich habe immer noch diese Liste =>

Dabei wird der Dongle mit einem lsusb korrekt erkannt =>

Wofür stehen die dev* in Bezug auf mein lsusb?

Kann das mit einem Bericht zusammenhängen?

Dort gibt es mehrere Lösungsvorschläge, aber ich kann dir nicht mehr dazu sagen, ich habe keine Synology mehr :wink:

Seit Version 7 von DSM sind die USB-Ports gedrosselt.
Ich habe natürlich die Treiber zurückgesetzt, um dieses Problem zu umgehen.
Mein Z-Wave funktioniert und meine Sonoff wird erkannt, aber ich bin mir nicht sicher, ob das Problem beim Syno lag.

Ich habe einen Neustart des Gladys-Containers durchgeführt und jetzt sehe ich den richtigen Port:

Der meinem Dongle entspricht:

Das einzige Problem jetzt ist, dass ich immer noch einen SRSP - SYS-Fehler habe

Fehler 2023-09-19 07:14:34: Fehler: Verbindung zum Adapter fehlgeschlagen (Fehler: SRSP - SYS - Ping nach 6000ms)

Ich habe meinen Sonoff-Dongle aktualisiert, aber es hat nichts gebracht…

Hilfe @cicoub13 @pierre-gilles :frowning:
Meine gesamte Zigbee-Installation ist im Eimer

@spenceur Ich habe dieses Thema gesehen, aber ich habe keine weiteren Ideen als das, was bereits gesagt wurde :confused:

Hast du eine Nachricht im Zigbee2mqtt-Forum gepostet? Das ist eher ein Problem auf ihrer Seite…

Ihr Forum: Koenkk/zigbee2mqtt · Discussions · GitHub
Ihr Discord: zigbee2mqtt

Beim nochmaligen Lesen des Themas sollte man auch bei Synology nachschauen, das scheint ja eine echte Plage mit dieser Synology-Version zu sein. Vielleicht mal auf den Synology-Spezialforen nachschauen?

Ich habe auch dieses Video gefunden:

Keine Ahnung, ob dir das weiterhilft ^^

Und rein zufällig hast du den richtigen Dongle in der Gladys-Seitenliste ausgewählt? Wenn dein Dongle ein Sonoff P ist, hast du Sonoff P ausgewählt, und wenn es ein Sonoff E ist, hast du Sonoff E ausgewählt?

C’est bien le « p » und ich habe den Dongle richtig ausgewählt :slight_smile:

Auf der Syno-Seite denke ich, dass ich alles richtig gemacht habe, da der Dongle erkannt wird und mein Z-Wave funktioniert.
Und das Gerät wird im cp210x-Treiber erkannt:

Ich habe auf dem GitHub von Koenkk gepostet:

Mein Englisch ist nicht perfekt ^^’

Ich verstehe aber nicht, was « rst » in Gladys zwischen den Containern macht.
In Gladys wähle ich ttyusb0 aus, aber in der Z2M-Konfiguration habe ich ttyacm0 angegeben.
Ich habe versucht, es manuell zu ändern, aber es hat sich nichts geändert :frowning:

Aus dem Gedächtnis (Achtung, falls ich Quatsch rede) bei mir gibt es auch einen Unterschied zwischen dem z2m-Dashboard und Gladys. Eines Tages wollte ich alles gleich machen… Und ich habe alles zum Absturz gebracht :sweat_smile:

Ich bestätige:


ja, ich nehme an, dass das Volume an den anderen Container gemountet werden muss.
Ich habe alles wieder gerade gerückt, aber es ist immer noch negativ :frowning:

edit:

@pierre-gilles wie ist der Link zwischen dem ausgewählten Port und dem gemounteten Port hergestellt?

Also, ich konnte das Problem beheben, indem ich das Bild über Portainer manipuliert habe.

Ich habe den Host auf /dev/ttyUSB0 geändert, der an /dev/ttyACM0 gebunden ist.

Ich weiß nicht, warum es nicht funktioniert, wenn ich es über Gladys auswähle, aber es scheint jetzt in Ordnung zu sein.

Gut, wenn es funktioniert! :tada:

Tatsächlich habe ich den Code angesehen, es sei denn, ich habe den Ablauf dieses Teils nicht verstanden, die Zuordnung zwischen dem Host-Port und dem Port im Container erfolgt nur, wenn der Container zum ersten Mal konfiguriert wird:

Damit diese Änderung wirkt, müsste die Zigbee-Integration deaktiviert/und dann neu gestartet werden, denke ich..

(ich sage das, nachdem ich den Code in 10 Sekunden gelesen habe, ich habe nicht weiter untersucht)

Kannst du ein GitHub-Issue erstellen, damit wir dieses Verhalten überprüfen können? :slight_smile:

Im Container gladys-z2m-zigbee2mqtt ist der Port des Dongles immer /dev/ttyACM0 (das war, um die Konfiguration zu erleichtern).
Sie finden immer in /var/lib/gladysassistant/zigbee2mqtt/z2m/configuration.yaml

serial:
  port: /dev/ttyACM0

Die Zuordnung zwischen dem Host-Port (dem echten) und dem des Containers erfolgt tatsächlich bei der Erstellung des Containers (oder bei der Reaktivierung, falls eine Änderung vorgenommen wurde).

"Devices": [
    {
        "PathOnHost": "/dev/ttyUSB0",
        "PathInContainer": "/dev/ttyACM0",
        "CgroupPermissions": "rwm"
    }
],

Ich habe eine issue erstellt, ich kann einen Blick darauf werfen.

Ist das der richtige Zeitpunkt, um dieses Verhalten zu überarbeiten? Ich meine, den richtigen Port in der Konfiguration festzulegen und eine direkte Zuordnung zu erstellen?
Ich habe Angst vor den Auswirkungen auf bestehende Installationen

Keine Ahnung, aber ich verstehe das Problem. Es lag wohl bei Gladys. Ich werde eine Nachricht im Koenkk-Repo hinterlassen, dass das Problem bei Gladys liegt, die mit z2m (noch in der Testphase) nicht 100% funktioniert.

Nein, ich denke, wir sollten so bleiben, wie es jetzt ist :slight_smile:

Das einzige Problem im Moment ist, dass der Zigbee2mqtt-Container anscheinend (zu überprüfen) nicht neu gestartet wird, wenn sich der USB-Port ändert.

@cicoub13 Hast du an dem Thema gearbeitet oder soll ich mich da ranmachen?

Ich habe angefangen, mich damit zu beschäftigen, aber es ist komplizierter als gedacht.

Ich dachte daran, zu dieser Zeile (während des Speicherns der Konfiguration) eine Überprüfung + ggf. ein Deployment hinzuzufügen.

Aber die Funktion checkForContainerUpdates überprüft nicht die Konfiguration, sondern nur die verfügbaren Versionen.

Es muss also:

  • überprüft werden, ob sich die Konfiguration geändert hat
  • die Funktion configureContainer aufgerufen werden, um die Konfiguration zu schreiben
  • die Funktion installZ2MContainer aufgerufen werden, die den zigbee2mqtt-Container neu starten sollte (ohne sonst etwas zu tun)

So weit bin ich. Ich kann weitermachen, aber es gibt keine kurzfristige Zusage.

Ok, ich habe mich auch auf meiner Seite informiert, tatsächlich ist es eher die Funktion installZ2MContainer, die fehlerhaft ist

Wenn der Benutzer seine Konfiguration aktualisiert, wird der API-Aufruf /setup aufgerufen, der die Funktion setup aufruft.

Diese Funktion aktualisiert die USB-Konfiguration und ruft dann init auf, das installZ2MContainer aufruft.

Allerdings hat installZ2MContainer keinen Code, um den Fall eines bestehenden Zigbee2mqtt-Containers zu behandeln.

Ich denke, dass in dieser Funktion installZ2MContainer Folgendes hinzugefügt werden sollte:

  • Am Anfang der Funktion eine if (dockerContainers.length > 0) {-Bedingung einfügen, um den Fall zu behandeln, dass der Container tatsächlich existiert
  • Testen Sie HostConfig.Devices[0].PathOnHost, um zu überprüfen, ob er mit dem USB-Pfad übereinstimmt
  • Wenn nicht (der USB-Pfad hat sich geändert), dann den Container stoppen und löschen. (Und den Rest der Funktion den Container neu starten lassen)

Was denkst du dazu? :slight_smile:

  1. Gladys
  2. /server
  3. /services
  4. /zigbee2mqtt
  5. /docker
    /# gladys-z2m-zigbee2mqtt-container.json

{
« name »: « gladys-z2m-zigbee2mqtt »,
« Image »: « koenkk/zigbee2mqtt:latest »,

Nur eine kleine Frage: Sollte man hier nicht auch ein festes Image festlegen, da es scheinbar aktuell keine Probleme mit diesem gibt?

Ich beginne zu verstehen, wie der Container-Teil im Gladys-Code verwaltet wird :slight_smile: Ich gehe vom absoluten Anfänger zum Anfänger mit Speck über :rofl: