Koordynator Zigbee CC2652P + ESP32 + LAN8270 sternicz.uk (LeMo cc2652p LAN)

Próbował ktoś flashować CC2652P nową wersja fv - 20221102 ?

Ja dostaje błąd jak niżej. Coś z pobranym plikiem jest nie tak ? Poprzednią wersję wgrywam bez błędów.

Initiate access to target: COM5 using 2-pin cJTAG.
Reading file: C:/Users/zaawi/OneDrive/Pulpit/CC1352P2_CC2652P_other_coordinator_20221102.hex.
Unknown record type: 3.
Reset target ...
Reset of target successful.

Tą wersją jeszcze nie, ale poprzednią która była pełna błędów tak.
I z tego co pamiętam jest tam inny układ partycji (i jak sądzę zmiany nadal będą dążyły w tą stronę, więc zapewne w tym najnowszym też tak jest).
Więc musisz najpierw skasować flash w MCU, a potem dopiero wgrywać nowe FW.

Pierwotnie był to wątek o zmianie koordynatora w router, teraz robisz odwrotnie?
W takim razie i tak powinieneś kasować flash przed programowaniem.

Tak mam dwa urządzenia, jedno jest koordynatorem drugie routerem. Szukam rozwiązania bo od tygodnia moja sieć oszalała. Codziennie wypadają mi jakieś urządzenia, muszę je ponownie parować i tak w kółko. Tak źle nie działało to nawet na CC2531. Próbuje nowego FV bo już nie wiem co się stało.

Co do kasowania - mam zaznaczone jak niżej ale i tak nie przechodzi:

Piszesz, że 20220219 jest pełna błędów, którą w takim razie wersję polecasz ?

EDIT:
Wgrywam wersję z Z-Stack-firmware/coordinator/Z-Stack_3.x.0/bin at develop · Koenkk/Z-Stack-firmware · GitHub
Plik: CC1352P2_CC2652P_other_coordinator_20221102.zip

Nie piszę, że 20220219 tylko, że poprzednie beta (bo jakbyś raczył zauważyć wgrałeś sobie betę), a nie miałem nawet czasu na dokładniejsze sprawdzanie co konkretnie wgrywasz (ludzie czemu żałujecie linków? najlepiej do katalogu na repo + info który plik, bo sam link do pliku jest zazwyczaj bezużyteczny)

Akurat 20220219 jest OK i jest to najświeższa stabilna wersja.
20220928 jest zwaloną betą (była dostępna w kanale dev, ale jest śmieciem)
20221102 nie flashowałem (jest w kanale dev = jest to beta)
20221220 jest dzisiejszym wypustem na nowszym stacku (więc teoretycznie może powodować problemy)


A teraz wróćmy do tematu, nie musisz wgrywać nowego softu by skasować firmware jeśli dobrze pamiętam.
Jeśli masz problemy z kasowaniem, to albo masz wgrane FW od innego typu dongla i się pozbawiłeś BSL, albo coś robisz źle, albo (uwaga to zła wiadomość) - posypał się flash w donglu (co mogą też sugerować problemy z “zapominaniem” urządzeń, o których wspominałeś).

Aby nie było, że ja też żałuję linków

gałąź stabilna
https://github.com/Koenkk/Z-Stack-firmware/tree/master/coordinator/Z-Stack_3.x.0/bin

dev
https://github.com/Koenkk/Z-Stack-firmware/tree/develop/coordinator/Z-Stack_3.x.0/bin

i gałąź eksperymentalna
https://github.com/Koenkk/Z-Stack-firmware/tree/6.10.01.01/coordinator/Z-Stack_3.x.0/bin

1 polubienie

Po kilu nieudanych próbach flashowania wersji 20221102 wrzuciłem 20220219 i wgrała się bez problemu dlatego tym bardziej nie wiem o co chodzi.

Właśnie nie widzę tu nigdzie opcji samego kasowania:

Co do zapominania urządzeń to może źle się wyraziłem. Urządzenia są cały czas widoczne ale nie ma z nimi komunikacji. Fragment logów:

Error 2022-12-20 23:11:52 `Publish ‘set’ ‘state’ to ‘Ikea05’ failed: ‘Error: Command 0xbc33acfffe5f9b2a/1 genOnOff.off({}, {“sendWhen”:“immediate”,“timeout”:10000,“disableResponse”:false,“disableRecovery”:false,“disableDefaultResponse”:false,“direction”:0,“srcEndpoint”:null,“reservedBits”:0,“manufacturerCode”:null,“transactionSequenceNumber”:null,“writeUndiv”:false}) failed (Data request failed with error: ‘No network route’ (205))’

I tak kilka razy dziennie po kilka urządzeń. Już mi się pomysły skończyły co może być przyczyną dlatego postanowiłem wrzucić nowy fv i sparować od nowa wszystkie urządzenia. Dodam że ok roku działało bez większych problemów.

Ten obrazek nie mieści mi się na ekranie w laptopie, naprawdę okno nie musi być zmaksymalizowane by zrobić wszystko mówiącego screnshota.
Jakkolwiek erase to kasowanie.

Jak dasz mi trochę czasu (powiedzmy parę dni) to przeflaszuję dongla (ale mam prawdopodobnie innego) na te 2 ostatnie softy i może cokolwiek potestuję?

PS a jednak chyba mamy bliźniaczy sprzęt (Egony v1.5), więc zwróć uwagę na niekontaktujący przycisk, u mnie pomogła ultradźwiękowa kąpiel w IPA

Dodam tylko od siebie, że posiadam wersje 20220219 i na CC2652P działa ona w mojej sieci ultra stabilnie. Kilka prób aktualizacji do najnowszych wydań zakończyło się fiaskiem więc zrezygnowałem i zostałem przy tej w/w. W sieci Zigbee mam 26 urządzeń.

1 polubienie

W poprzednim urządzeniu miałem uszkodzony przycisk i Grzegorz mi go wymienił na model w pełni sprawny. Wiem na 100%, że teraz działa bo poprzednią wersję fv flashuje bez problemu.

Wyczyściłem pamięć i wgrałem ponownie stabilną wersję 20220219. Zobaczymy czy coś to pomoże. Gdzieś czytałem, że takie przeflashowanie czasem rozwiązuje niektóre problemy.

Tak jak obiecywałem u siebie właśnie wgrałem dzisiejszą świeżynkę, mogę sobie na to pozwolić - ten dongle jest i tak tylko w instalacji eksperymentalnej, ale kiedy będę mógł powiedzieć coś sensownego nie wiem, bo planuję dłuższy wyjazd na święta.

Po wyczyszczeniu pamięci i przeflushowaniu na nowo (tej samej wersji) drugi dzień (odpukać) jest wszystko ok i żadne urządzenie jeszcze się nie zgubiło.

EDIT
Cofam powyższe. Przez tydzień było dobrze i problem powrócił. I moje pytanie - macie w Zigbee2MQTT włączoną opcję Device-Availability (Dostępność) ?

Na tę chwilę gdy od tygodnia nie ma mnie w domu 11 z 48 urządzeń wypadło z sieci. Całkowicie losowo. Żarówki, czujki ruchu, głowice. Nie ma z nimi komunikacji. Już mi się pomysły kończą. Chyba po powrocie zmianie koordynator i wrócę do Sonoffa. Obecnie używam CC2652P w wersji LAN od Grzegorza.

Ktoś coś podpowie ?

Raczej nie podpowiem, ale testowałem parę dni wersję “alfa” (20221220, która jest już tak swoją drogą niedostępna, bo jest w tej chwili jakaś nowsza, z czego wnoszę, że tamta ma błędy) w bardzo skromniutkiej instalacji testowej i działa raczej w porządku.

Można pomyśleć o próbnym wykorzystaniu “bety” (skoro nie masz i tak nic do stracenia, to może i nawet “alfy” na najnowszym stacku?).


W ramach gdybania

  • po pierwsze używanie Dostępności nie jest obowiązkowe, jeśli sieć działa to działa i bez tego (@macek uświadomił mi, że jest możliwa obecnie konfiguracji dostępności “per urządzenie” jak dotąd nie testowałem tego)
  • po drugie - jeśli problemy zaobserwowałeś po dołożeniu jakiegoś specyficznego urządzenia do sieci, to się go pozbądź (źle zaimplementowana funkcja routera może rozwalać sieć, niestety tu by była wróżka potrzebna jeśli nie rozbudowywałeś sieci po kawałku, trafiłem problemy ze starymi modelami żarówek Osram, właściwie nie ja tylko syn, ale ponieważ nie byłem w stanie stwierdzić czy maczał w tym palce czy sprzęt się po prostu sypał podmieniłem mu je na Ikea, u mnie GU10 nie mają zastosowania, więc po prostu nie wiem jak jest, ale przynajmniej jedna z nich nie przeszła poprawnie OTA i raportuje nową wersję, ale pod spodem ma stare firmware, co widać po parowaniu ze starożytnym oryginalnym mostkiem Osram)
  • po trzecie - jeśli masz dostępne aktualizacje OTA dla jakichś swoich urządzeń, to z nich skorzystaj (jest szansa, że usuną one przyczynę)
  • po czwarte (to raczej zła lub bardzo zła wiadomość) - potencjalnie problemy mogą wynikać z błędnych zapisów do flasha w donglu (konfiguracja sieci jest zapisywana w nim lokalnie), może dongle ma problem z zasilaniem (za niskie napięcie na USB (typowe w starszych RPi, dlatego dedykowane zasilacze mają napięcie nieco wyższe od 5V)? wadliwy port? kiepska przedłużka? - jeśli ma 2 wtyki A to wykorzystaj oba), ale możliwe że jest wadliwy i flash się po prostu sypie (nie udowodniło tego flashowanie, ale weryfikowany jest obszar firmware, a nie partycja na dane, jedynie nieudane czyszczenie mogłoby na 100% potwierdzić problem, niestety udane nie jest pewnym dowodem na sprawny flash).

Jak pisałem tak niestety musiałem zrobić bo nie miałem już pomysłu. Wróciłem do Sonoffa. Dziś jest trzeci dzień od ponownego sparowania całości i (odpukać) na razie wszystko śmiga. Być może rzeczywiście urządzenie od Grzegorza jest wadliwe.
Dzięki za sugestie.

Nigdzie wcześniej chyba się nie zająknąłeś, że to wersja LAN.

Może problem dotyczy firmware ESP?
Jak masz (miałeś) to podpięte? (po LAN czy po USB, ma PoE, czy wymaga zasilania USB?, można odpiąć ESP od zasilania w trybie USB?)

Bo wątek ten od początku dotyczył wersji USB. Chciałem z niej zrobić router gdy przesiadłem się na wersję LAN - to cała historia.
A Sonoffa kupiłem kiedyś w promocji na wypadek awarii głównego dongla i jak widać się przydał.

A odpowiesz na pytania, bo ciekaw jestem sprzętu, z którym masz problemy.
Jak rozumiem jest w nim identyczny moduł MCU Zigbee jak w donglu USB Egony v4 tj. Ebyte E72-2G4M20S1E, ale oprócz tego interesuje mnie reszta konstrukcji, bo wszyscy cedzą informacje jak fusy przez zęby…

1 polubienie

Firmware ESP - najnowszy. Firmware CC2652P - 20220219.
Zdecydowałem się na to urządzenie z dwóch powodów:

  1. Jednym urządzeniem ogarnę Zigbee oraz czujniki BLE
  2. W miejscu gdzie stoi mój HP z Proxmoxem mam też NASa, router W-Fi, konwerter światła na lan, modem od kablówki oraz całą skrzynkę bezpieczników. Dlatego nie wydawało mi się ono najlepsze na dongla. Nawet przedłużka USB nie pozwalała na jakieś sensowne oddalanie od tych urządzeń. Miałem przez to opóźnienia na czajnikach ruchu czy żarówkach.
    To był główny powód aby wynieść się do innego pomieszczenia i podłączyć po LAN. Urządzenie od Grzegorza ma PoE ale ja u siebie nie mam więc zasilić musiałem przez USB. Po przesiadce lagi praktycznie zniknęły i długo wszystko działało bez zarzutów.

Co do Twojego ostatniego pytania

to nawet nie wiem. Wrzucę tu instrukcję konfiguracji zworek którymi można zmieniać tryby pracy urządzenia:

Ustawienia DIP switchy:
- programowanie esp32 poprzez USB: 5, 7 i 8 w dół
- używanie esp32 poprzez USB: 7 i 8 w dół
- programowanie cc2652p poprzez USB: 1, 2 i 6 w dół
- używanie cc2652p poprzez USB: 1 i 2 w dół
- używanie cc2652p poprzez esp32: 3 i 4 w dół - default

Co do samej konstrukcji - tak to wygląda:




Jeśli chcesz potestować mogę wysłać, u mnie i tak leży. Może zareplikujesz problem i uda się go rozwiązać. :wink:

Ten sprzęt ma jakąś nazwę handlową? (wiem, że to DIY, ale wypłynęło naraz tyle nowych informacji, że chyba czas na osobny wątek i chciałbym to co odetnę jakoś sensownie zatytułować)

Jak rozumiem ESP32 lata na ESPHome - stąd info że soft “najnowszy”.

Zupełnie przy okazji - wrzucisz kompletnego YAMLa z ESPHome?
Próbowałeś wyłączyć obsługę BT?

Co do kwestii replikowania problemu - nawet nie mam gdzie tego zrobić, musiałby się znaleźć ochotnik z okolicy, bo nie jestem w stanie u siebie zbudować kolejnej sieci Zigbee by zawierała chociaż kilkanaście urządzeń (choć jakiś sprzęt bym na to znalazł :stuck_out_tongue: ), tzn. ochotnika to może i bym znalazł, ale on też by pragnął mieć niezawodną instalację :smiley: a nikt nie ma czasu na taką zabawę w kotka i myszkę (bo mam znajomych którzy marzą o ID, ale takim “gotowym z pudełka”, a na to by świadczyć darmowe wsparcie indywidualne to ja też nie mam czasu).

Jesteś pewien?
Zastosowana w nim płytka prototypowa z Ethernetem wygląda na WT32-ETH01 (a o ile mi wiadomo ona nie ma PoE, swoją drogą na zdjęciach nie widać też przetwornicy, o ile wiem, że SMSC LAN8720 można spiąć z przetwornicą PoE to ten moduł raczej takich możliwości nie daje).

Pomijając tę kwestię, z doświadczenia z podobnymi konstrukcjami wiem, że do zasilania czegoś takiego niezbędnym minimum jest zasilacz 5V 1A (ale w dobie wszechogarniającej chińszczyzny wziął bym taki, który ma deklarowane 2A). Płytka z Ethernetem jest naprawdę prądożerna. A skoro używałeś tego w trybie Ethernet…

Jest do tego w zestawie coś takiego:

Nazwy handlowej to chyba nie ma. Grzegorz nazywał to CC2652P wersja LAN.

Nie bo wcześniej działało bez problemu razem z BLE.

Konfiguracja ESP:

substitutions:
  device_name: cc2652p2lan
  friendly_name: LeMo cc2652p LAN
 
esphome:
  name: ${device_name}
  platform: ESP32
  board: esp-wrover-kit
 
 
ethernet:
  type: LAN8720
  mdc_pin: GPIO23
  mdio_pin: GPIO18
  clk_mode: GPIO0_IN
  phy_addr: 1
  power_pin: GPIO16
 
#wifi:
#  ssid: MyHomeNetwork
#  password: VerySafePassword

# Optional manual IP
  manual_ip:
    static_ip: 192.168.1.78
    gateway: 192.168.1.1
    subnet: 255.255.255.0
 
logger:
  level: DEBUG
 
api:
  reboot_timeout: 0s
 
ota:
web_server:
  port: 80
 
time:
  - platform: homeassistant
    id: homeassistant_time
 
#External component Stream Server
external_components:
  - source: github://oxan/esphome-stream-server
#  - source: components
#  - source: github://thegroove/esphome-zeroconf
 
sensor:
  - platform: uptime
    id: uptime_s
    update_interval: 300s
#FLORA
  - platform: xiaomi_hhccjcy01
    mac_address: '80:EA:CA:62:0B:B0'
    temperature:
      name: "mi temperature Flora"
    moisture:
      name: "mi moisture Flora"
    illuminance:
      name: "mi llluminance Flora"
    conductivity:
      name: "mi conductivity Flora"
#ŁAZIENIKA
  - platform: atc_mithermometer
    mac_address: "A4:C1:38:60:14:3E"
    temperature:
      name: "Lazienka Temperatura"
    humidity:
      name: "Lazienka Wilgotnosc"
    battery_level:
      name: "Lazienka Battery-Level"
    battery_voltage:
      name: "Lazienka Battery-Voltage"
    signal_strength:
      name: "Lazienka Signal"

## reszta urzadzen BLE
 
switch:
  - platform: restart
    name: "${friendly_name} Restart"
  - platform: gpio
    pin: 33
    id: zRST_gpio
    inverted: yes
    restore_mode: ALWAYS_OFF
  - platform: template
    name: "cc2652p RST"
    icon: mdi:toggle-switch
    id: zRST
    turn_on_action:
      - switch.turn_on: zRST_gpio
      - delay: 15ms
      - switch.turn_off: zRST_gpio
  - platform: gpio
    pin: 32
    name: "cc2652p BSL"
    icon: mdi:toggle-switch
    id: zBSL
    inverted: yes
    restore_mode: ALWAYS_OFF
    internal: true
  - platform: template
    name: "cc2652p firmware update"
    icon: mdi:cellphone-arrow-down
    turn_on_action:
      - script.execute: fw_update_mode
    turn_off_action:
      - switch.toggle: zRST
 
script:
  - id: fw_update_mode
    then:
      - switch.turn_on: zBSL
      - delay: 1s
      - switch.turn_on: zRST_gpio
      - delay: 1s
      - switch.turn_off: zRST_gpio
      - logger.log: "Delaying ~10 seconds for TI chip to be ready"
      - delay: 10s
      - switch.turn_off: zBSL
      - logger.log: "Update with cc2538-bsl tool now!"
      - logger.log: "Usage: cc2538-bsl.py -p socket://ip_or_hostname:6638 -evw firmware.hex"
 
#UART Settings
uart:
  id: uart_bus
  rx_pin: GPIO5
  tx_pin: GPIO17
  baud_rate: 115200
 
#Serial Bridge Settings,uncomment #port to change default 6638 TCP port
stream_server:
  uart_id: uart_bus
#  port: 1234
 
esp32_ble_tracker:
#zeroconf:
#  - service: LeMo_cc2652p2lan
#    protocol: tcp
#    port: 6638
#    txt:
#      version: 1.0
#      radio_type: znp
#      baud_rate: 115200
#      data_flow_control: software

Podłączone to było do zasilacza 5V 2A.

To chyba nie jest PoE tylko po prostu po 2 żyłkach przesyła sobie zasilanie. i po stronie płytki jest to po prostu osobny kanał zasilania. W takim wypadku jeśli się nie mylę lepiej ten zasilacz wpiąć przy samym urządzeniu a nie po stronie switcha.

To wiele tłumaczy - to jest splitter PoE (możliwe, że niezgodny z 802.3af/ 802.3at - nie mi to oceniać - wystarczy podpiąć do switcha PoE i się wyjaśni) - z punktu widzenia naszego urządzenia po prostu zewnętrzny zasilacz (sam zasilany z PoE)…

No cóż, problem z ESPHome jest taki, że się cały czas rozwija, więc coś co działało kiedyś może teraz mieć błędy (a nie przypuszczam byś miał stary bin, na którym problemów z Zigbee nie było), przy połączeniu po Ethernecie pracują oba MCU, więc trudniej znaleźć winowajcę…

Nie łączysz problemów z Zigbee z wprowadzeniem obsługi BLE w ESPHome? (a konkretniej z dokompilowaniem bramki BLE?)