Hier meine Ergebnisse:

Mit den gewonnenen Erkenntnissen, habe ich den Switch von SDCard System zu SSD-System durchgeführt.

Das was in meinem Fall wichtig war ist:

• Notieren der Zigbee Einstellungen (PAN_ID, ext Pan_ID, Kanal etc.)
• Sofern möglich, vor dem Switch auf ein anderes System ein Komplett-Backup mit Backitup ->iobroker<- + ->zigbee<- (DB) machen.
• Altes System herunterfahren
• Zigbee-Stick (Coordinator) stromlos machen bzw. vom Raspi/System trennen
• Neues Raspian O/S installieren
• Nicht mit root arbeiten! Auch die Nutzung von sudo ist nicht immer nötig und kann hinterher Ärger machen!
• iobroker für raspi über die Anleitung Klick mich! von Thomas Braun installieren.
• Backitup Adapter installieren und so konfigurieren, sodass man an seine Backups ran kommt.
• Mit tail -f /opt/iobroker/log/iobroker.current.log in einer separaten Console laufen lassen und beobachten ob alles sauber läuft.
• Restore "iobroker" über Backitup
• Login über AdminGui - sobald verfügbar machen und einmal in den Bereich "Adapter" klicken und warten. Der Restore des angestoßenen iobroker Backups, läuft mit großer Wahrscheinlichkeit noch. Beobachtet das Log. Wenn sich dort über mindestens 5 bis 8 Minuten nichts mehr getan hat, sollte alles durch sein.
• Restore der Zigbee Datenbank
• Mit ausgeschaltetem Zigbee.Adapter die Konfiguration dessen durchführen (unbedingt auf die korrekten Werte wie Pan_ID oder ext Pan_ID achten!
• Werte nochmal überpüfen ob diese passen.
• Zigbee Stick am Raspi anschließen und den Zigbee.Adapter starten -> Wieder tail -f /opt/iobroker/log/iobroker.current.log Log prüfen!
• Wenn alles geklappt hat, sind die ersten Geräte innerhalb weniger Minuten wieder einsatzbereit. Bei den Battrie-getriebenen wie bsp. Tür/Fenster Kontakte oder Bewegungsmelder, reicht es oft aus, diese von Hand zu triggern (Fenster öffnen/schließen oder mal hurtig vor dem Bewegungsmelder hüpfen.

Den Link und den Inhalt dieses Threads, werde ich mir mal schön abspeichern =). Zu meinen Erfahrungen mit der SSD mit ext. Gehäuse + Mirroring werde ich evtl. in einem separaten berichten.

Danke für die Unterstützung.

Hallo zusammen,

ich habe mehrere Bewegungsmelder von Aqara RTCGQ11LM bei mir im Einsatz.
Mit einem habe ich neuerdings das Problem, dass dieser die Verbindung verliert. D.h. ich lerne das Gerät neu an und nach ca. ein bis zwei Tagen ist es nicht mehr in meinem Zigbee Netzwerk verbunden.
Wenn ich mir die Zigbee Map von zigbee2mqtt anzeigen lasse, sehe ich den Bewegungsmelder, allerdings mit keiner Verbindung zum Coordinator oder Router. Es hängt alleine im Space

Ich hatte zu Beginn eine innr Steckdose im Verdacht, sodass diese evtl. ein Problem für den Bewegungsmelder darstellt. Diese Dose habe ich zwischenzeitlich durch eine Blitzwolf TS0121 (Tuya TS0121_plug) ersetzt. Auch hier habe ich nach maximal zwei Tagen das Problem, dass der Bewegungsmelder nicht mehr damit verbunden ist.

Mir gehen so langsam die Ideen aus. Hat noch jemand von euch eine Idee was ich tun könnte. btw. es gibt in dem Stockwerk auch keine neuen Geräte die dazu gekommen sind.

Nachtrag: Batterie Tausch habe ich natürlich auch schon gemacht.

@amylopektin
Laut Github Comments sieht es aktuell "dünn" aus, was eine Anpassung bzgl. "no_occupancy_since" angeht.

Habe jetzt einen Workaround dafür.
Solange der State "Occupancy" sich nicht verändert, wird bis zu 1200 Sekunden hochgezählt. Danach erfolgt keine Aktualisierung mehr. Sollte sich der State "Occupancy" während oder nach dem Hochzählen verändern, wird von neuem hochgezählt. Initial wird - wenn Occupancy auf true ist, gezählt. Wenn Occupancy auf false ist, wird der eingestellte Maximalwert an Sekunden in den State geschrieben (Default 1200 Sekunden). Der Rest sollte aus dem Script heraus ersichtlich sein.

// Bewegungsmelder-Datenpunkte
const motionSensor1 = "zigbee2mqtt.0.0x00158d0007752803.occupancy";  // Ersetze dies durch den tatsächlichen Pfad zum Bewegungsmelder 1
const motionSensor2 = "zigbee2mqtt.0.0x00158d000775a2dd.occupancy";  // Ersetze dies durch den tatsächlichen Pfad zum Bewegungsmelder 2

// Ziel-Datenpunkte für die Sekunden seit letzter Bewegung
const state1 = "0_userdata.0.Custom_Variables.Treppenaufgang.Bewegungsmelder_EG.no_occupancy_since";
const state2 = "0_userdata.0.Custom_Variables.Treppenaufgang.Bewegungsmelder_OG.no_occupancy_since";

// Maximale Sekundenanzahl (1200 Sekunden = 20 Minuten)
const maxSeconds = 1200;

// Variable für die Zeitintervalle in Sekunden, nach denen der Zähler erhöht wird
const interval = 10;  // Setze diesen Wert auf die gewünschte Anzahl an Sekunden

// Timer-Variablen
let timer1 = null;
let timer2 = null;

// Funktion zum Starten oder Zurücksetzen des Timers für einen Sensor
function startOrResetTimer(sensor, state, timer) {
    if (timer) clearInterval(timer);  // Vorherigen Timer stoppen

    setState(state, 0);  // Zähler auf 0 setzen

    // Neuen Timer starten
    return setInterval(() => {
        let currentValue = getState(state).val;
        if (currentValue < maxSeconds) {
            setState(state, currentValue + interval);
        } else {
            clearInterval(timer);  // Timer stoppen, wenn maxSeconds erreicht sind
        }
    }, interval * 1000);  // Intervall in Millisekunden (z.B. alle 10 Sekunden)
}

// Bewegungsmelder 1 überwachen
on({id: motionSensor1, change: "ne"}, function (obj) {
    if (obj.state.val && !obj.oldState.val) {  // Wechsel von false auf true
        timer1 = startOrResetTimer(motionSensor1, state1, timer1);
    }
});

// Bewegungsmelder 2 überwachen
on({id: motionSensor2, change: "ne"}, function (obj) {
    if (obj.state.val && !obj.oldState.val) {  // Wechsel von false auf true
        timer2 = startOrResetTimer(motionSensor2, state2, timer2);
    }
});

// Initialisierung: Timer oder Initialwert setzen
function initializeState(sensor, state) {
    if (getState(sensor).val) {  // Wenn Occupancy auf true steht
        timer1 = startOrResetTimer(sensor, state, timer1);  // Timer starten
    } else {  // Wenn Occupancy auf false steht
        setState(state, maxSeconds);  // Wert auf 1200 Sekunden setzen
    }
}

// Initialisierung für beide Bewegungsmelder
initializeState(motionSensor1, state1);
initializeState(motionSensor2, state2);

Hallo zusammen,

ich bin aktuell von Zigbee-HomeAutomation (iobroker.zigbee Adapter) auf MQTT/Zigbee2MQTT zu wechsel. Ich habe nur leider ein Problem bei dem ich gerade nicht weiter komme.

Im Zigbee-HomeAutomation hatte ich beim Bewegungsmelder den Wert "no_motion" = Sekunden seit der letzten Bewegungserkennung. Diesen Wert verwende ich in Skripten zum Steuern von Lichtern.

Im MQTT Explorer konnte ich prüfen, dass die Werte korrekt übermittelt werden. Jedoch scheint das den Zigbee2MQTT Adapter in iobroker nicht zu interessieren.

Hat jemand von Euch nen Tipp?

Update:

Vorab vielen Dank für Euren Input. Habe mir alles durchgelesen und bin zwischenzeitlich weiter. Ich muss gestehen, dass die Umstellung von ZigbeeHomeAutomation auf Zigbee2MQTT schon eine kleine Herausforderung ist.

Mein aktuelles Setup ist wie folgt:
Proxmox

• DebianLinux
  -- Docker und Portainer als Mgmt
  --- Docker Stack
  ---- eclipse-mosquitto:latest
  ---- koenkk/zigbee2mqtt:latest

Iobroker

• Adapter: Zigbee2MQTT
  -- Zigbee2MQTT Verbindung: WS zigbee2mqtt.local 8080
  -- Den Rest habe ich auf Default Settings gelassen

Anbei meine aktuelle Portainer Stack-Config. Ich finde man tut sich - gerade am Anfang etwas leichter, wenn man mal eine einfache Beispiel-Config sieht. Was Netzwerk angeht -> ich möchte bei meinen Docker Containern immer gerne eine eigene IP haben. Hier nutze ich macvlan. Daher sieht meine docker-config etwas anders aus als das was man so standardmäßig sieht.

version: '2'

services:
  mqtt:
    container_name: mosquitto
    hostname: mqtt
    domainname: local.xzy
    image: eclipse-mosquitto:latest
    networks:
      network-10:
        ipv4_address: 10.X.X.X
#    ports:
#      - "1883:1883"
#      - "9001:9001"
    volumes:
      - "mosquitto_config:/mosquitto/config"
      - "mosquitto_data:/mosquitto/data"
      - "mosquitto_log:/mosquitto/log"
    environment:
      TZ: "Europe/Berlin"
    restart: always

  zigbee2mqtt:
    container_name: zigbee2mqtt
    hostname: zigbee2mqtt
    domainname: local.xyz
    image: koenkk/zigbee2mqtt:latest
    networks:
      network-10:
        ipv4_address: 10.X.X.X
    volumes:
      - "zigbee2mqtt_data:/app/data"
      - "/run/udev:/run/udev:ro"
    environment:
        - TZ=Europe/Berlin
    devices:
        - "/dev/serial/by-id/usb-Silicon_Labs_slae.sh_cc2652rb_stick_-_slaesh_s_iot_stuff_00_12_4B_00_23_93_32_2B-if00-port0:/dev/ttyACM0"

volumes:
  mosquitto_config:
    external: true
  mosquitto_data:
    external: true
  mosquitto_log:
    external: true
  zigbee2mqtt_data:
    external: true

networks:
  network-10:
    name: network-10
    external: true

Im MQTT Container habe ich User und Passwort gesetzt:

mosquitto_passwd -c /mosquitto/config/password.txt mqtt-user

Danach kommt ein Prompt wo nach dem Passwort gefragt wird. Dieses setzt man entsprechend. Das wars im mqtt Container.

Anpassen der Config für MQTT unter /data/mosquitto/config/mosquitto.conf (relevante Inhalte)

listener 1883
allow_anonymous false
persistence true
persistence_location /mosquitto/data/

Anpassen der Config für Zigbee2MQTT unter
/data/zigbee2mqtt/configuration.yaml (relevante Inhalte)

homeassistant: false
permit_join: false
mqtt:
  base_topic: zigbee2mqtt
  server: mqtt://mqtt.local.xyz
serial:
  port: /dev/ttyACM0

Im allgemeinen kann man sagen, dass die Dokumentation von Zigbee2MQTT m.E. sehr gut und umfangreich ist.

So, nun kann man dieses Thema hier schließen und ich kann das nächste aufmachen -> leider funktioniert mein Aquara Bewegungsmelder mit dem neuen Setup nicht so, wie mit dem alten aaargh

@bananajoe said in Umstieg von ZigBee-HA auf MQTT/ZigBee2MQTT:

@amylopektin was ist den ZigBee-HA ? Zigbee Home Automation?
In den alten Beiträgen von dir warst du doch schon mit dem ZigBee-Adapter unterwegs, mit dem brauchst du doch überhaupt nichts extra außer dem Adapter.

yep. Zigbee HomeAutomation.
Es gibt immer wieder mal Problem(chen) mit diversen Aquara Geräten und andere Kleinigkeiten die irgendwann einfach nerven. Daher dachte ich mir -> why not?

Hallo zusammen,

ich möchte gerne von ZigbeeHA auf MQTT/ZigBee2MQTT umswitchen.

Welche Art des Deployments könnt ihr empfehlen?
Ich hätte die Möglichkeiten:

• LXC Container über Proxmox
• Docker
• oder eben nativ über die IOBroker Adapter MQTT und ZigBee2MQTT

Habe schon gesehen, dass es selbst für MQTT vier verschiedene LXC Container gibt:

• EMQX
• HiveMQ CE
• MQTT
• RabbitMQ

Ich vermute mal dass der ZigBee2MQTT Adapter in iobroker sein muss, da dieser dann das Bindeglied zwischen MQTT und iobroker herstellt. Richtig? Bin noch neu in der MQTT Thematik

Hier meine Ergebnisse:

Mit den gewonnenen Erkenntnissen, habe ich den Switch von SDCard System zu SSD-System durchgeführt.

Das was in meinem Fall wichtig war ist:

• Notieren der Zigbee Einstellungen (PAN_ID, ext Pan_ID, Kanal etc.)
• Sofern möglich, vor dem Switch auf ein anderes System ein Komplett-Backup mit Backitup ->iobroker<- + ->zigbee<- (DB) machen.
• Altes System herunterfahren
• Zigbee-Stick (Coordinator) stromlos machen bzw. vom Raspi/System trennen
• Neues Raspian O/S installieren
• Nicht mit root arbeiten! Auch die Nutzung von sudo ist nicht immer nötig und kann hinterher Ärger machen!
• iobroker für raspi über die Anleitung Klick mich! von Thomas Braun installieren.
• Backitup Adapter installieren und so konfigurieren, sodass man an seine Backups ran kommt.
• Mit tail -f /opt/iobroker/log/iobroker.current.log in einer separaten Console laufen lassen und beobachten ob alles sauber läuft.
• Restore "iobroker" über Backitup
• Login über AdminGui - sobald verfügbar machen und einmal in den Bereich "Adapter" klicken und warten. Der Restore des angestoßenen iobroker Backups, läuft mit großer Wahrscheinlichkeit noch. Beobachtet das Log. Wenn sich dort über mindestens 5 bis 8 Minuten nichts mehr getan hat, sollte alles durch sein.
• Restore der Zigbee Datenbank
• Mit ausgeschaltetem Zigbee.Adapter die Konfiguration dessen durchführen (unbedingt auf die korrekten Werte wie Pan_ID oder ext Pan_ID achten!
• Werte nochmal überpüfen ob diese passen.
• Zigbee Stick am Raspi anschließen und den Zigbee.Adapter starten -> Wieder tail -f /opt/iobroker/log/iobroker.current.log Log prüfen!
• Wenn alles geklappt hat, sind die ersten Geräte innerhalb weniger Minuten wieder einsatzbereit. Bei den Battrie-getriebenen wie bsp. Tür/Fenster Kontakte oder Bewegungsmelder, reicht es oft aus, diese von Hand zu triggern (Fenster öffnen/schließen oder mal hurtig vor dem Bewegungsmelder hüpfen.

Den Link und den Inhalt dieses Threads, werde ich mir mal schön abspeichern =). Zu meinen Erfahrungen mit der SSD mit ext. Gehäuse + Mirroring werde ich evtl. in einem separaten berichten.

Danke für die Unterstützung.

@asgothian said in Geht ein Umzug ohne alle Geräte neu anlernen zu müssen?:

Dieses kann. nur funktionieren wenn:

• die Einstellungen im Zigbee Adapter identisch zu denen sind deiner normalen Installation sind (Ausnahme: Port für den Koordinator)

--> Ich vermute, dass ich die Ursache bzgl. "ständig" neu anlernen gefunden habe. - verdrehte -> PAN_ID <-

Bevor ich mein SSD System wieder hochgefahren habe, notierte ich mir die Einstellungen im Zigbee.Adapter.
Als mein SSD System hochgefahren war, habe ich über Backitup die Iobroker Sicherung und hinterher die Zigbee Sicherung restored. Das lief ohne Probleme.
Als ich dann in die Einstellungen des Zigbee Adapters geschaut habe, ist mir aufgefallen, dass bei der PAN_ID die hinteren zwei Zahlen verdreht waren. Bsp. Statt 3254 stand dort 3245. Warum das bei dem neuen SSD System so war, kann ich nicht sagen. Es wurde ja ein Restore durchgeführt. Ich habe nur die Vermutung, dass durch die noch aktiven Zigbee Router (Steckdosen, Leuchtmittel etc. alles das mit Strom) die alte PAN_ID im Funkverkehr noch aufgetaucht ist. Daher könnte es sein, dass der Zigbee.Adapter oder mein Slaeshs Stick hier eine Veränderung vorgenommen hat. Ist aber nur eine Vermutung.

Im Log kam dann auch die Meldung, dass die PAN_ID nicht zu der gesetzten Adapter ID passt, welche im Backup hinterlegt ist. So oder so ähnlich war die Meldung. Ich setzte daraufhin die PAN_ID auf den eigentlichen Wert. Das wiederum hat zu noch mehr lustigen Fehlermeldungen geführt. Ein paar Kopf -> Tisch Runden + Abendessen haben mich dann zu folgender Aktion gebracht:

• sudo poweroff
• alle aktiven Router ausstecken
• Antenne meines Zigbee Sticks abdrehen
• Wiedereinschalten Raspi
• Deinstallation / Löschen des Zigbee.Adapters
• Installation des Zigbee.Adapters
• rm /opt/iobroker/iobroker-data/zigbee_0/nvbackup.json
• Restore des Zigbee Adapter + Konfiguration mit der passenden PAN_ID
• Start des Zigbee.Adapter

Nach dieser Aktion haben meine Geräte, kurz danach wieder reagiert. Kein langes warten oder ähnliches. Natürlich musste ich alle Router(Steckdosen, Leuchtmittel/Lampen) wieder mit Strom versorgen. Somit dauerte es teilweise bei manchen Geräte etwas, bis diese wieder erreichbar waren. Das Ganze hat sich dann aber relativ zeitnah gelegt.

Während dem Restore, habe ich mir per tail -f /opt/iobroker/log/iobroker.current.log mal angeschaut, was der da überhaupt so treibt. Dieses Logfile sollte ausnahmslos jeder nebenbei offen haben, wenn etwas nicht so funzt wie erwartet. Da erklären sich auch manche Vorgänge von selbst. Ich kannte das Log an sich zwar schon, jedoch war es ca. ein Jahr her, als ich dort das letzte Mal reingeschaut habe <g>. Daher hatte ich das gar nicht mehr sooo auf dem Schirm.

Sollte man einen iobroker Restore fahren, dann kann ich jedem nur empfehlen --> Macht das LOG auf <-- oder geht erstmal 10 bis 15 Minuten Kaffee trinken. Da werden Strukturdaten/States +X hinzugefügt/verändert oder auch mal etwas gelöscht. Sollten beim Restore, Adapter enthalten sein, welche auf dem aktuellen System noch nicht vorhanden sind, werden diese adhoc nachgeladen. Das kann dauern <<- Etwas unglücklich bei dem Restore ist, dass der Anmelde-Dialog relativ schnell wieder da ist. Login funktioniert einwandfrei. Da könnte man denken, dass der Restore schon abgeschlossen ist. Von wegen! Das Ding läd fleißig im Hintergrund noch Adapter nach oder passt etwas an. Entweder sollte man bei laufendem Restore-Prozess den Anmelde-Dialog mit einer Meldung sperren oder man hat während dem Prozess einen dicken Balken oben eingeblendet, der einem sagt, dass der Prozess noch läuft.

• Dein normaler Zigbee Adapter muss angehalten sein UND der Koordinator muss vom Strom weg sein.

Da fehlt mir jetzt noch ein Satz. Meinst du das als Voraussetzung VOR einem Restore?

@jan-s100 said in Geht ein Umzug ohne alle Geräte neu anlernen zu müssen?:

@amylopektin Nein das funktioniert. Mit Backitup alles wieder herstellen. Erst iobroker und dann die Zigbee Sicherung. Im Zigbee Adapter die richtige Adresse zum Stick angeben und dann starten.
Bei mir hat es so funktioniert.

Hallo Jan!

Weißt was -> ich teste das jetzt mal aus und gebe Rückmeldung

@crunchip said in Geht ein Umzug ohne alle Geräte neu anlernen zu müssen?:

@amylopektin sagte in Geht ein Umzug ohne alle Geräte neu anlernen zu müssen?:

und Backitup nur die Zigbee DB sichert/wiederherstellt

weil? und iobroker selbst nicht?

oder meinst du, du hast ohne iobroker selbst wieder zurückzuspielen nur mal getestet mit dem zigbee

@crunchip

Ja richtig. Primärziele waren:

1. herauszufinden, ob und wie ich eine Installation von Raspian O/S mit Iobroker und externen USB Gehäuse und zwei SSD´s im Mirroring Mode geht. Das hat soweit geklappt.

2. ob meine Zigbee Geräte nach einem Restore über Backitup wieder ansprechbar sind oder neu angelernt werden müssen.

Leider finde ich nichts konkretes zu einem Restore des Zigbee.Adapters. Bis auf andere User, welche das gleiche Problem nach einem Restore haben. Angelegte Geräte, jedoch keine Funktion. Das einzige was klappt ist, wenn man die Geräte neu anlernt. Ist das so byDesign? Oder habe ich etwas vergessen zu machen?