Zigbee2mqtt Update oder external converter

[udo1toni]

Also doch 32 Bit Um ein neues Image kommst Du also nicht herum, wenn Du den Pi mit openHAB5 verwenden willst.

Der Pi 5 ist natürlich super als Upgrade und da Du dort eh zwingend ein neues Image nutzen musst, kannst Du dann auch bequem auf 64 Bit wechseln.

Alternativ zu openHABian geht wie erwähnt auch docker, welches die einzelnen Dienste in separaten Containern bereitstellt.
Man kann dann einen Stack anlegen, der alle Container automatisch erzeugt und gemeinsam startet.
Als komfortable Verwaltungsoberfläche kann ich Portainer empfehlen, welches ebenfalls als Container unter docker läuft (der einzige Container, den man aus naheliegenden Gründen nicht über Portainer verwalten kann).

[Max84]

Ja, das mit docker werde ich auf jeden Fall versuchen. Hört sich sehr gut an!
Nachdem ja erstmal alles wieder lief, ist Zigbee2mqtt heute wieder ausgefallen. Ich habe schon einige Zeit recherchiert und glaube auch erkannt zu haben, dass irgendwie der Speicher voll ist.
Im log – Verzeichnis von Z2m waren nur alte Daten. Die habe ich gelöscht. Trotzdem startet Z2m nicht
Df -h liefert:

Filesystem...........Size........Used........Avail........Use%........Mounted on
/dev/root............59G........6.5G........50G.........12%........../
devtmpfs.............1.9G........0 ..........1.9G..........0%........../dev
tmpfs.................1.9G........ 0...........1.9G.........0%........../dev/shm
tmpfs..................69M........1.9M........768M........1%........../run
tmpfs..................5.0M........0............5.0M........0%........../run/lock
/dev/mmcblk0p1...255M........51M.........205M........20%......../boot
/dev/zram1..........721M.......148M........521M........23%........./opt/zram/zram1
overlay1..............721M........148M........521M........23%......../var/lib/openhab/persistence
/dev/zram2..........974M........930M........0............100%......./opt/zram/zram2
overlay2..............974M.........930M........0............100%......./var/log
tmpfs..................385M.........0............385M.......0%........../run/user/1000


also auf jeden Fall das /var/log Verzeichnis voll soweit ich das verstehe. Aber warum? Und soll ich es einfach komplett löschen?

Gruß
Max

[Max84]

Das Problem scheint an den beiden Dateien

Syslog und daemon.log zu liegen. Die sind beide über 400MB.

Ich habe dank google mit dem Befehl sudo sh -c 'echo > /var/log/syslog' die syslog leeren können. Die daemon.log klappt leider nicht. "Permission denied"

Aber es hat gereicht, dass Zigbee2mqtt erstmal wieder läuft. Ist nur die Frage wie lange…

[udo1toni]

Wie auch immer Google auf eine solche Variante verfällt...
Was eventuell funktionieren könnte (in dieser Variante) wäre

Code: Alles auswählen

echo '' | sudo tee /var/log/daemon.log

Die Ausgabe von echo (in diesem Fall ein leerer String) wird über die Pipe an das nachfolgende Kommando weitergegeben, in diesem Fall der Befehl tee, welcher die Eingabe sowohl an die Konsole als auch in die angegebene Datei schreibt. Dabei wird tee mit erweiterten Rechten gestartet, das ist der Witz daran
Was auf jeden Fall gehen sollte:

Code: Alles auswählen

sudo  rm /var/log/daemon.log
sudo touch /var/log/daemon.log

Vorher bitte einmal prüfen, welche Berechtigungen für die Datei eingetragen sind:

Code: Alles auswählen

openhab@openhabian:~ $ ls -l /var/log/daemon.log
-rw-r----- 1 root adm 185838 Jul 18 12:56 /var/log/daemon.log

Wichtig sind hier vorne die Buchstaben (Berechtigung für den Besitzer ist Read/Write, für die Gruppe Read, für alle anderen gar nichts) und auch die Besitzverhältnisse, hier gehört die Datei dem User root und der Gruppe adm.
Wenn das soweit korrekt ist, müsstest Du die Rechte für die Datei nach dem erneuten Anlegen anschließend noch mal anpassen:

Code: Alles auswählen

sudo chown root:adm /var/log/daemon.log
sudo chmod 640 /var/log/daemon.log

Grundsätzlich wegen Platzproblemen in /var/log/:
Als erstes kannst Du immer alle Dateien mit der Endung .gz löschen. Das sind jeweils Vorgängerversionen der entsprechenden Dateien. Je nach Einstellungen gibt es davon auch mehrere. Natürlich sind diese Dateien gepackt und relativ klein, aber auch das hilft ja.
Auch die Unterverzeichnisse enthalten oftmals viele alte Logdateien. Logs kann man eigentlich immer unbesorgt löschen, wenn man nicht gerade Probleme analysiert (denn dann braucht man ja jede Information...)
Wenn man Logdateien löscht (wie oben) und nicht selbst wieder anlegt, sollte die entsprechende Softwarekomponente die Datei auch selbst wieder anlegen, spätestens wenn das entsprechende Programm neu gestartet wurde, im Grunde sollte also der rm Befehl ausreichen, schlimmstenfalls müsstest Du einmal neu booten.
Aber es immer gut, zu verstehen, wie man auf Dateiebene entsprechende Aufgaben "korrekt" erledigen kann, deshalb die langatmige Anleitung oben...

[Max84]

Vielen Dank für die ausführliche Erklärung, Udo!!
Ich hatte es noch geschafft, die daemon.log zu löschen mit dem sudo rm Befehl. Leider hatte ich vorher nicht die Berechtigungen geprüft.
Nach dem Befehl sudo systemctl restart rsyslog (google) wurde sie aber auch automatisch wieder neu angelegt.

Wenn ich jetzt die Berechtigungen prüfe, sieht es aus wie bei dir:

-rw-r----- 1 root adm 48315 Jul 19 17:13 /var/log/daemon.log

Denke also, es sollte alles passen.
Und seit ich das Log level in Zigbee2mqtt angepasst habe, explodieren die Dateien auch nicht mehr.
Was ich allerdings noch nicht verstehe ist, warum Zigbee2mqtt da überhaupt was rein schreibt. In der configuration.yaml ist als log directory angegeben: /var/log/zigbee2mqtt/%TIMESTAMP%al. Da taucht auch gelegentlich was auf. Als das Problem auftrat, war in dem Verzeichnis aber nichts drin, aber die syslog und die daemon.log waren vollgeschrieben. Das hatte ich nicht erwartet…

Der neue Raspberry ist jedenfalls auch angekommen. Da muss ich aber erstmal noch ne Weile lesen. Bevor es mit docker und Portainer los gehen kann, braucht er ja wohl erstmal ein Betriebssystem. Vermutlich das Raspberry Pi OS?! Aber auch da gibt es ja schon zig verschiedene. Zum Glück läuft ja aber auch erstmal alles wieder. Daher ist keine Eile und ich versuche mal ganz in Ruhe, wie weit ich komme…

Viele Grüße
Max

[udo1toni]

syslog ist der Logger des Betriebssystems, daemon.log ist der Logger von systemctl.
Das heißt, zigbee2mqtt hat sich mutmaßlich verschluckt, und zwar so, dass es trotz automatischem Restart nicht mehr auf die Beine gekommen ist.
In der Folge wird jeder fehlgeschlagene Restart in der daemon.log vermerkt, außerdem wird in syslog ebenfalls ein Logeintrag erzeugt (der dürfte dann jeweils etliche Zeilen lang sein).

[Max84]

Hallo zusammen!
Noch mal eine kurze Zwischenfrage zum Umstieg auf Docker:
Ich habe inzwischen das Raspberry Betriebssystem in 64bit und als Lite Version installiert. Auch Docker und Portainer habe ich geschafft. Ich kriege es auch hin, z.B. OpenHab als Docker Container zu installieren. Für ein großes Problem habe ich bisher jedoch noch keine Lösung gefunden:

Ich wähle beim Erstellen des Containers unter "Network" "host" aus. (Andere Möglichkeiten habe ich auch schon versucht, aber ohne Erfolg)
Es gibt aber anscheinend keine Möglichkeit, den Port festzulegen. OpenHab läuft ja auf 8080, Zigbee2mqtt standardmäßig aber auch. An die YAML Datei komm ich jedoch anscheinend auch nicht ran?!
Beides auf dem gleichen Port funktioniert natürlich nicht.
Ich weiß ehrlich gesagt auch nicht, ob die Auswahl "host" richtig ist. Oder ob die verschiedenen Container auch verschiedene IP Adressen kriegen sollten, bzw. wie das geht. Einfach eine festlegen geht jedenfalls nicht. Dann kommt als Meldung: "user specified IP adress is suupported on user defined networks only"
Ich habe auch versucht, unter Port mapping für Host 81 und Container 80 einzutragen. hat aber auch nicht funktioniert.

Wenn jemand hierzu einen Hinweis hat, würde ich mich sehr freuen!
Viele Grüße
Max

[peter-pan]

Ich weiss nicht wie das mit Docker genau funktioniert, aber bei mir ist Z2M auf Port 8081 eingestellt. Das ist in der Konfigurationsdatei (/opt/zigbee2mqtt/data/configuration.yaml) von Z2M einstellbar.

Code: Alles auswählen

hab4@raspi58:/opt/zigbee2mqtt/data $ cat /opt/zigbee2mqtt/data/configuration.yaml | more
frontend:
  enabled: true
  port: 8081
homeassistant:
  enabled: false
mqtt:
  base_topic: zigbee2mqtt
  server: mqtt://localhost
  .......

[Max84]

Ja, genau. So kenne ich das auch. Aber mit Docker scheint das nicht mehr so zu sein. Jedenfalls habe ich noch nicht herausgefunden, wie ich da die configuration.yaml ändern könnte…

Gruß
Max

[udo1toni]

Aaaalso...

Grundsätzlich gibt es verschiedene Möglichkeiten, das Netzwerk für Docker Container zu konfigurieren. Die bekanntesten sind hierbei bridge und host.

bridge erzeugt eine Network Bridge, d.h. es wird ein Adressmapping zwischengeschaltet. Der Container hat intern ein eigenes Subnetz. Da die Adresse nach außen gemappt wird, kann bei der Gelegenheit auch der Port umgeschrieben werden. Die Anwendung im Container läuft zum Beispiel auf Port 8080, über das Mapping wird aber Port 8081 zugewiesen,

host bedeutet, der Container nutzt die IP-Adresse des Host Systems und somit auch den IP Stack des Hosts direkt. Ein Port Mapping ist somit nicht möglich, die Anwendung im Container belegt direkt den Port auf dem Host.

Selbstverständlich kann man auch den openHAB Container im bridge Mode betreiben, allerdings ist das nicht ratsam, denn es gibt einen großen Pferdefuß im bridged Mode, und das ist das separate Subnetz. openHAB verwendet zeroconf, avahi, mdns und diverse andere Akronyme welche samt und sonders auf Multicast aufsetzen. Multicast ist überaus praktisch im LAN, weil es die verfügbaren Ressourcen schont. Dummerweise wird Multicast aber nicht geroutet, was wiederum bedeutet, dass der Multicast Datenverkehr nicht über die bridge in den Container weitergereicht werden kann.

Aus diesem Grund sollte openHAB im host Mode laufen.

Was die Portzuweisungen betrifft, so kann man die Ports für openHAB über die Environment Variablen setzen (also die Konfigurationsdatei des Containers).

Für die bridge Mode Container gibt es dann gewöhnlich zwei Stellen, um die Ports zu beeinflussen, nämlich die Environment Variablen (falls der Parameter zugänglich gemacht wurde) und zusätzlich das Port Mapping
Beispiel anhand eines openHAB Containers:

Code: Alles auswählen

version: '2.2'

services:
  openhab:
    image: "openhab/openhab:latest"
    restart: always
    network_mode: bridge
    ports: 
      - 8080:8080 # links Host-Port, rechts Container Port
      - 8443:8443 # links Host-Port, rechts Container Port
    volumes:
      - "/etc/localtime:/etc/localtime:ro"
      - "/etc/timezone:/etc/timezone:ro"
      - "/portainer/Files/AppData/Config/openHAB4/openhab_addons:/openhab/addons"
      - "/portainer/Files/AppData/Config/openHAB4/openhab_conf:/openhab/conf"
      - "/portainer/Files/AppData/Config/openHAB4/openhab_userdata:/openhab/userdata"
    environment:
      CRYPTO_POLICY: "unlimited"
      EXTRA_JAVA_OPTS: "-Duser.timezone=Europe/Berlin"
      OPENHAB_HTTP_PORT: "8080" # Port innerhalb des Containers
      OPENHAB_HTTPS_PORT: "8443" # Port innerhalb des Containers
      USER_ID: "998"
      GROUP_ID: "997"

Der Block ports entfällt beim host mode, weil wirkungslos.

So sieht bei mit der zigbee2mqtt Container aus:

Code: Alles auswählen

version: '3.8'
services:
  zigbee2mqtt:
    container_name: zigbee2mqtt
    image: koenkk/zigbee2mqtt:latest
    restart: unless-stopped
    volumes:
      - /portainer/Files/AppData/Config/zigbee2mqtt/data:/app/data
      - /run/udev:/run/udev:ro
    ports:
      # Frontend port
      - 28080:8080
    environment:
      - TZ=Europe/Berlin
    #devices:
      # Make sure this matched your adapter location
      #- /dev/serial/by-id/usb-Texas_Instruments_TI_CC2531_USB_CDC___0X00124B0018ED3DDF-if00:/dev/ttyACM0

Ich habe ein tubeszb-cc2652-poe als Zigbee "over LAN" Coordinator, der wird einfach über die Konfiguration innerhalb des Containers verbunden und taucht nicht im yaml Code des Containers auf.