Flashowanie Sonoff Zigbee 3.0 USB - będzie potrzebne ponowne parowanie?

Posiadam Sonoff Zigbee 3.0 USB który działa pod HA jako koordynator pod ZHA. Działa świetnie, ale do obsługi sterownika rolet Aqara E1 okazuje się że jest wymagane wyższe firmware (20211114) niż mam obecnie (20210708). Rozważam więc upgrade ale mam jedną wątpliwość - czy po wgraniu nowego firmware będę musiał ponownie parować podpięte do niego urządzenia? Kilka jeszcze bym przebolał, ale 40+ to już nie za bardzo :slight_smile:

  "data": {
    "ieee": "**REDACTED**",
    "nwk": 0,
    "manufacturer": "Texas Instruments",
    "model": "CC1352/CC2652, Z-Stack 3.30+ (build 20210708)",
    "name": "Texas Instruments CC1352/CC2652, Z-Stack 3.30+ (build 20210708)",
    "quirk_applied": false,
    "quirk_class": "zigpy_znp.zigbee.device.ZNPCoordinator",
    "manufacturer_code": 0,
    "power_source": "Mains",
    "lqi": null,
    "rssi": null,
    "last_seen": "2023-05-10T10:55:27",
    "available": true,
    "device_type": "Coordinator",
    "signature": {
      "node_descriptor": "NodeDescriptor(logical_type=<LogicalType.Coordinator: 0>, complex_descriptor_available=0, user_descriptor_available=0, reserved=0, aps_flags=0, frequency_band=<FrequencyBand.Freq2400MHz: 8>, mac_capability_flags=<MACCapabilityFlags.AllocateAddress|RxOnWhenIdle|MainsPowered|FullFunctionDevice|AlternatePanCoordinator: 143>, manufacturer_code=0, maximum_buffer_size=80, maximum_incoming_transfer_size=160, server_mask=11265, maximum_outgoing_transfer_size=160, descriptor_capability_field=<DescriptorCapability.NONE: 0>, *allocate_address=True, *is_alternate_pan_coordinator=True, *is_coordinator=True, *is_end_device=False, *is_full_function_device=True, *is_mains_powered=True, *is_receiver_on_when_idle=True, *is_router=False, *is_security_capable=False)",
      "endpoints": {
        "2": {
          "profile_id": "0xc05e",
          "device_type": "0x0820",
          "input_clusters": [
            "0x0000"
          ],
          "output_clusters": []
        },
        "1": {
          "profile_id": "0x0104",
          "device_type": "0x0400",
          "input_clusters": [
            "0x0000",
            "0x0006",
            "0x000a",
            "0x0019",
            "0x0501"
          ],
          "output_clusters": [
            "0x0001",
            "0x0020",
            "0x0500",
            "0x0502"
          ]
        }
      },
      "manufacturer": "Texas Instruments",
      "model": "CC1352/CC2652, Z-Stack 3.30+ (build 20210708)"
    },

lll

Generalnie zasada jest taka, pilnuj backupu sieci (GUI Z2M → Ustawienia ->Narzędzia - tam można wygenerować i pobrać świeży) jak oka w głowie (skopiuj w bezpieczne miejsce), przed wyjęciem koordynatora zatrzymaj Z2M.

Nigdy zmiana wersji firmware jeśli nie wiąże się ze zmianą stacka nie wywołuje konieczności ponownego parowania, ale bądź ubezpieczony na wszelki wypadek.

Przy flashowaniu możesz całkowicie wyczyścić koodrdynator (po to masz backup sieci w Z2M by sieć z niego została przywrócona).

Nie szukaj starych wersji firmware (ale najlepiej miej ich cała kolekcję w prywatnym archiwum). Obecnie mam wgrany testowy firmware 20230405 (ale ostatnia wersja testowa to bodajże 20230410 po prostu nie miałem czasu na przeflaszowanie), nie pamiętam jaka jest wersja uznawana obecnie za stabilną, ale generalnie zawsze każda zmiana firmware wiąże się z potencjalnym zagrożeniem istnienia jakiegoś nowego nieznanego wcześniej błędu w specyficznej konfiguracji danej sieci (w powszechnym użyciu jest sprzęt który zawiera odstępstwa od standardu, w tym głównie Tuya i Xiaomi, ponadto wchodzą w grę kwestie interoperacyjności między wersjami Zigbee “wstecz i wprzód”…)

2 polubienia

Dzięki za odpowiedź! Czyli tak jak sadziłem - nie powinno się nic stać, ale trzeba być przygotowanym na najgorsze :slight_smile: Używam w większości ZHA, tutaj nieco trudniej z backupem, ale dam rade.

W ZHA są inne narzędzia, jest też toolkit dla zaawansowanych, który można doinstalować np. z HACS

ale, że nie używam ZHA od dawna, to wiele nie podpowiem.
Jakkolwiek wiem, że backup sieci jest wykonalny.
Ponieważ ZHA jest integracją systemową, to sugeruję zamknąć system na czas flashowania (zamiast wyłączać integrację i kombinować naokoło, reszta jak w Z2M.

(nie wiem czy nawet nie wystarcza mieć kompletny backup HA, ale nie idź na skróty)

1 polubienie

@szopen a jak mogę przywrócić taki backup?? Skąd bierzesz aktualny firmware 20230405??
Znalazłem tylko 20221226 na Z-Stack-firmware/coordinator/Z-Stack_3.x.0/bin at master · Koenkk/Z-Stack-firmware · GitHub.

UWAGA
Oficjalny flasher TI nie działa z najnowszymi wersjami firmware, należy użyć alternatywnego flashera, tj albo pythonowego skryptu, albo tego

w razie draki (tj. tylko jeśli sieć nie wstanie) po zatrzymaniu integracji/dodatku itp. nadpisujesz plikami z backupu (trzeba go trzymać "gdzieś na zewnątrz, by nie został nadpisany uszkodzoną konfiguracją gdyby poszło coś nie tak), pliki o tych samych nazwach (po ich wypakowaniu) w swojej instalacji (to dotyczy Z2M, bo w ZHA jest chyba jakieś narzędzie), kasujesz NVRAM po czym uruchamiasz wszystko z powrotem (ale jeśli sieć się wysypała wskutek zmiany firmware, to radzę najpierw wrócić dokładnie do tego samego firmware jakie miałeś wcześniej - po to trzeba mieć własne archiwum tych wersji firmware, które używasz).

Przede wszystkim nie należy wpadać w panikę, po zmianie firmware sieć się czasem długo podnosi (czasem warto zrestartować całego hosta jeśli się nie chce prawidłowo uruchomić, nawiązanie kontaktu z urządzeniami bateryjnymi może nastąpić dopiero w sytuacji gdy będą cokolwiek raportowały samorzutnie)

Podałem wersję jaką mam wgraną, ale ona zawiera błędy (w mojej instalacji nie występują ich objawy)

20230405 to NIE jest aktualny firmware, aktualny stabilny jest sporo starszy - to 20221226 (i taką polecam trzymać w prywatnym archiwum na przyszłość), a aktualny deweloperski to 20230507 (ale może zwierać istotne błędy! i generować nieznane problemy), oczywiście dowolną wersję czyli np. taką taką wersję “z krzaka” jak moja można sobie wygrzebać cofając się w czasie na githubie (ale sam dla siebie bym jej nie szukał - po prostu wgrywałem wtedy to co Koen przygotował jako łatkę dla 20230401 i w zasadzie miałem przejść na 20230410 - nie ma literówki - były to 3 różne wersje w ciągu 2 tygodni, ale nie miałem potem czasu, a już się zdezaktualizowała jako eksperymentalna)

Skąd biorę? ze źródła, wersje deweloperskie są tylko dla osób które ich potrzebują i/lub zamierzają swoimi raportami błędów (lub potwierdzeniem działania OK na sieci w której aktualne firmware stabilne ma problemy) wesprzeć rozwój - więc są w gałęzi developersiej (a nie w master, czy main)

Oczywiście tu mówimy TYLKO o donglach na chipsetach Texas Instruments i tylko tych wspieranych przez projekt (bo firmware do chipsetów innych producentów należy szukać w innych miejscach).

PS dla tych którzy testują firmware deweloperskie tu jest link do issue (tu się chwalimy jeśli naprawiło coś względem aktualnego stabilnego, w pozostałych przypadkach oczywiście zgłaszamy błędy) aktualnie dla 20230507

1 polubienie

Dla potomnych :slight_smile: update firmware Sonoff_Zigbee_3.0_USB_Dongle_Plus

  1. backup HA
  2. wyłączenie HA całkowicie (ja mam w dockerze więc service docker stop)
  3. Backup ustawień sieci:
    python3 -m zigpy_znp.tools.network_backup PORT_SONOFF -o network_backup_zha.json
  4. Backup NVRAM
    python3 -m zigpy_znp.tools.nvram_read PORT_SONOFF -o nvram_backup_zha.json
  5. Backup firmware
    python3 cc2538-bsl.py -p PORT_SONOFF -r --bootloader-sonoff-usb backup.hex
  6. Upgrade firmware
    python3 cc2538-bsl.py -p PORT_SONOFF -evw --bootloader-sonoff-usb CC1352P2_CC2652P_launchpad_coordinator_20221226.hex
  7. Przywrócenie ustawień sieci ZigBee
    python3 -m zigpy_znp.tools.network_restore PORT_SONOFF -i network_backup_zha.json
  8. Przywrócenie ustawień NVRAM
    python3 -m zigpy_znp.tools.nvram_write PORT_SONOFF -i nvram_backup_zha.json
  9. Uruchomienia HA

Wszystko podniosło się bezproblemowo, sieć nienaruszona.

Nie wiem czy pkt 8 jest konieczny, ale zrobiłem na wszelki wypadek i nic się nie stało.