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
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ń.
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
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…
Firmware ESP - najnowszy. Firmware CC2652P - 20220219.
Zdecydowałem się na to urządzenie z dwóch powodó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ć. 
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ł 
), tzn. ochotnika to może i bym znalazł, ale on też by pragnął mieć niezawodną instalację 
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?)