Sprawdzić czy koordynator jest pod IP takim jak masz skonfigurowany (chodzi o iksy w x.x.x.x:6638)
Nie wklejaj logów czy czegokolwiek co wymaga przez nas np. skopiowania fragmentu tekstu w postaci tylko obrazka, screenshoty są fajne jako uzupełnienie, ale tekst to podstawa, nie jesteśmy sztuczną inteligencją, która sobie to ogarnie wbudowanym OCR.
1 polubienie
udało mi się go ożywić, znalazłem sposób na jednej z grup FB.
Wiem, ale nie powiem. Sporo to daje do dyskusji 
Jesteś niesamowity , brawo Ty, uważaj tylko i pilnie strzeż tajemnicy bo a nuż ktoś z tego forum byłby zainteresowany rozwiązaniem.
jeśli ktoś jest zainteresowany rozwiązaniem to niech zajrzy na polską grupę home assistant na FB lub napisze do Sterniczuka, w końcu to jego sprzęt.
Nie używam FB, więc na szczęście gdybym potrzebował pomocy w takich sprawach, to mogę liczyć na tutejszych forumowiczów 
1 polubienie
Nikt Cię nie zmusza, przecież zawsze masz drugą opcję.
@Martin_Martin a jednak też zabiorę głos w Twoim stwierdzeniu:
To nic nie wnosi w rozwiązanie problemu, totalnie nic. Szkoda, że takie jest Twoje podejście do pomocy w rozwiązywaniu problemów 
.
1 polubienie
Znalazłem info na FB (dla tych co tam nie bywają), że działa podobno wersja CC1352P2_CC2652P_other_*.zip z tego linku:
Ale nie wiem jaką metodą było wgrywane. Raz była informacja o CLI a raz o ZigStar GW Multi Tool. U mnie ten problem, że wersja pod LAN, więc nie bardzo wiem, jak do tego podejść.
Stopień sobkowstwa co poniektórych użytkowników jest porażający, na tyle, że aż przykro…
Konstrukcja opiera się na projektach open-hardware, więc nie mam skrupułów przed opublikowaniem schematu (jeśli dobrze pamiętam częściowego - jest tam to, co miało umożliwić naprawę sprzętu), szczególnie, że autor olał wsparcie…
Sprzęt będący bohaterem tego wątku ma “mysią klawiaturkę” (dip-switch), służącą do konfiguracji trybów pracy i flashowania.
Miałem w rękach ten produkt już w czasach braku wsparcia, to zrysowałem z niego schemat (dzięki temu, że jeden z użytkowników forum po prostu zasponsorował jego testy pożyczając sprzęt i opłacając przesyłkę w obie strony, sprzęt ten swoją drogą był podejrzany o awarię, ale nie był faktycznie uszkodzony, jedynie był problem z LED statusu połączenia Ethernet - nie wiem czy moduł Wireless Tag WT32-ETH01 był częściowo uszkodzony, czy po prostu dość wczesna jego wersja miała wadę fabryczną, w każdym razie nie przeszkadzało to w pracy koordynatora w żadnym z jego trybów).
Sprzęt jest zaprojektowany przyzwoicie, więc nie wiem czemu autor się poddał (w ramach “śledztwa” domyślam się, że przyczyną były zmiany w bibliotece streamującej serial, jak sądzę ten komponent działa obecnie dobrze oraz druga potencjalna przyczyna to ogólne zmiany w ESPHome, a był tam bodajże też komponent Bluetooth, który po paru aktualizacjach jest mocno zasobożerny, być może należy go wyłączyć dla stabilnej pracy, więc możliwe, że gdzieś wyżej podana konfiguracja może wymagać drobnych poprawek).
Metoda flashowania nie ma znaczenia - finalnie obiema metodami jest flashowany MCU E72 (z jego punktu widzenia tak samo), oczywiście trzeba się trzymać procedury dla danej metody.
Jeśli dacie radę ogarnąć się moimi notatkami, to jest w nich informacja jak uzyskać możliwość flashowania MCU E72 (tego ogarniającego Zigbee) przez USB (można też po sieci, ale jak ktoś nie wie co robić, to zalecam po USB używając ZigStar Multi Tool, oczywiście mysia klawiaturka ma być ustawiona na flashowanie E72 po USB, czyli mysie klawisze 1, 2 i 6).
W ten sposób flashowałem “w tą i z powrotem” bezproblemowo.
Ważna uwaga dla tych, którzy nie są na bieżąco - od pewnego czasu (tj. dla najnowszych firmware, nie pamiętam od jakiej konkretnie wersji, ale z pewnością dotyczy to którejś wersji wersji z roku 2022 i wszystkich od niej nowszych) nie działa oficjalny flasher Texas Instruments, tj. Flash Programmer 2 (przynajmniej w wersji 1.8.2 i chyba nie ma nowszej dostępnej…)
Flashowanie po sieci nie jest opisane na rysunku, wsad w ESP umożliwia przełączenie E72 w tryb BSL, więc nie trzeba zmieniać mysich klawiszy (przy zachowaniu procedury autora softu i sprzętu, tj. 3 i 4 wystarczy).
Potwierdzam, że firmware pasujące do konstrukcji bazujących na Ebyte E72 to właśnie firmware spakowane w plikach o wzorcu nazwy
CC1352P2_CC2652P_other_*.zip
(właściwego hexa trzeba sobie wypakować przed użyciem!)
z tego repo
[brave mode on]
Dla odważnych mam też konfigi pod ESPHome (nie są to wersje ostateczne, więc musicie sobie poprawić, ostatecznie ich nie używałem)
disclaimer: oczywiście ich nie wspieram, jeśli sobie nimi uwalicie sprzęt to robicie to na własną odpowiedzialność.
[brave mode off]
Jeśli znajdę zdjęcia wnętrza to też wrzucę do posta.
1 polubienie
Też mnie to zaskoczyło tutaj. Jak tylko znajduję interesującą rzecz, Choć czasami banalną, to wrzucam. Może nie będzie przydatna, a może zainteresuje jedną, dwie osoby. I to już jest jak dla mnie plus. Ważne by się dzielić informacjami, wiedzą itp.
Nie chcę tutaj bronić autora wypustu, ale on całkowicie zniknął ze wszystkich mediów. Dlaczego? Możemy się tylko domyślać? Czy powodem są te urządzenia, czy coś innego? Nie wiemy. Dodam, że pracował w branży medycznej, wiec tam sytuacje mogą być po prostu różne.
Nie znam gościa i nigdy się z nim nie kontaktowałem (chyba, że występuje pod innymi nickami). Możliwe, że bliżej nieokreślone problemy życiowe uniemożliwiły kontynuację projektu.
Na podstawie tego co czytałem, mogę tylko rzucić teorią spiskową, że przerosła go konieczność świadczenia wsparcia (na to wskazują narzekania niektórych użytkowników, że wsparcia już nie było jeszcze w trakcie sprzedaży, ale tu kontr-teoria, również spiskowa - komuś nadepnął na odcisk i został zniszczony przez potencjalną konkurencję) - cena wypustu, z pewnością pokrywała jego produkcję (i niewątpliwie generowała jakiś niezerowy zysk), ale szczerze wątpię, że ktokolwiek byłby w stanie udźwignąć np. użycie wadliwej partii jakiegoś podzespołu, a kluczowe moduły są chińskie, o ile Ebyte wydaje się produkować z zachowaniem najwyższych standardów, to wypusty Wireless Tag wyglądają na wytanione.
(słowo wyjaśnienia - sprzęt który miałem w ręce miał martwą diodę LED statusu Ethernet, by być szczegółowym nie sprawdziłem tego przyczyny, stwierdzam fakt, że nie zachowywała się jak należy, gdzieś indziej widziałem, że ktoś inny też miał taki problem - stąd podejrzenie, że stara wersja WT32-ETH01 mogła mieć wadliwą konstrukcję, niestety nie mam budżetu na kupowanie takich modułów bez celu i sensu, a moduł luzem, który kupiłem w innym celu, ale potencjalnie był do wykorzystania na serwisową podmianę jest nieco inny konstrukcyjnie - na zdjęciach widać delikatne zmiany w konstrukcji jego nowszej wersji).
Oczywiście te zdjęcia prezentują moduł wlutowany w płytę główną (2147 WT32-ETH01 v1.2) oraz nowszą praktycznie o rok wersję niewlutowaną (2242 WT32-ETH01 v1.4) i widać między nimi różnice konstrukcyjne (w moim module, tym niewlutowanym, mam wlutowane goldpiny w odwrotną stronę, bo to sprzęt do innego projektu, dlatego ma też podpięte kilka przewodów - nie ma to nic wspólnego z konstrukcją z wątku)
Problemem samym w sobie jest użycie w tym urządzeniu kilku projektów open-source, które są niezależne od siebie i podlegają nieprzewidywalnym zmianom (są na to obejścia, ale wymagają poświęcenia sporych środków, a przede wszystkim ogromnej ilości czasu), w dodatku są to komponenty niestandardowe w ESPHome (więc nie są “konserwowane” wraz z ESPHome).
Mini-OFF TOPIC (zupełnie nie związany z tematem, ale pokazujący złożoność niektórych problemów na granicy między open-source, a biznesem) - ESPHome zależy od Platformio, a tymczasem firma będąca właścicielem Platformio wykonuje jak dla mnie nieco dziwne ruchy (kwestia akurat dotyczy wsparcia dla RPi Pico/Pico W), choć ich podłożem są oczywiście pieniądze - np. Espressif płaci Platformio za utrzymanie wsparcia, a fundacja RPi zlała temat, więc mimo tego, że niezależni developerzy wykonali kawał dobrej roboty, Platformio nie chce przyjąć ich kodu… co wiąże się z brakiem oficjalnego wparcia dla RPi Pico/Pico W również w ESPHome, a status eksperymentalny może trwać latami lub skończyć się na braku wsparcia, to samo dotyczy wypustów bekenopodobnych, wprawdzie nie znam ich statusu, ale sądząc po ich taniości raczej producenci MCU nie będą płacić Platformio za wsparcie ich sprzętu(?), więc być może nie doczekamy się scalenia LibreTiny z mainstreamowym ESPHome, jakkolwiek jako osobny projekt LibreTiny funkcjonuje całkiem OK
Edit: do OFF-TOPICa (początek września 2023) - powolutku małymi kroczkami zaczęło się scalanie LibreTiny z oficjalnym ESPHome, więc światełko w tunelu jest, być może taka droga zostanie wykorzystana dla wsparcia wypustów sposd malinowego logo?
Generalnie wypusty typowo DIY należy zawsze traktować jako coś bez wsparcia - gość podzielił się w pewien sposób świetnym projektem (jest kilka podobnych, więc akurat rewolucji w tym nie widziałem), szkoda, że temat umarł.
PS Znalazłem zdjęcia, ale muszę je nieco uporządkować
tu 3 kluczowe, prezentujące użyte moduły oraz moment odrysowywania schematu (tak, robiłem to pół roku temu licząc na jakąkolwiek rzeczową dyskusję w wątku, jednak po sprawdzeniu poprawności działania koordynatora i zmianie firmware Zigbee odesłałem sprzęt właścicielowi, nie miałem wtedy czasu na głębszą zabawę, a odzew wśród ludzi z problemami był zerowy, ale właściwie większość istotnych informacji już była dostępna na forum, tylko komuś musiałoby się chcieć je zebrać w jedno miejsce)
a tu cała reszta (bez obróbki)
1 polubienie
Powiem nieśmiało,iż w/w sprzęt działa u mnie od długiego czasu z małą przerwą gdzie z dnia na dzień po prostu przestał. W tym czasie wydawało mi się, że zrobiłem wszystko - nawet 2 router wpinałem. Ale nie śmigało - zmieniałem zasilacze na kilka innych i nic.
Pomogła zmiana zasilacza na mocniejszy. i koniec problemów. Działa po dziś dzień.
Dziękuje jeszcze raz @szopen.
1 polubienie
Cześć,
Myślałem że już znalazłem rozwiązanie jak zaktualizować swój koordynator, ale jak zajrzałem do środka okazało się że mam inną wersje.
W środku jest przycisk Flash, ale nie wiem jak go użyć.
Wdzięczny będę za podpowiedź jak zaktualizować koordynator.
Wydaje się, że masz coś w guście klona tego projektu
musisz zweryfikować samodzielnie czy oprogramowanie ESP posiada opcje flashowania modułu Zigbee po sieci Ethernet
TYLKO UWAGA
ze względu na to, że jest tam moduł Ebyte E72 musisz użyć wersji firmware
CC1352P2_CC2652P_other_*
a NIE tego z członem launchpad
Oczywiście powyższe przy założeniu, że faktycznie ta wersja umożliwia flashowanie MCU TI w opisany wyżej sposób i o ile nie grzebałeś w oprogramowaniu ESP i nie zmieniłeś dostarczonego przez autora na jakieś inne.
Płyta główna jest wykonana z pewnością jako dwuwarstwowa (inaczej mówiąc jest tylko dwustronna - nie ma żadnych ukrytych wewnątrz warstw, których nie widać), więc z analizą ścieżek nie powinno być większego problemu (cześć z nich z pewnością biegnie pod modułami, ale możesz się oprzeć porównawczo na tej części którą zrysowałem z wersji “z mysią klawiaturką” - schemat powinien być choćby częściowo zgodny).
Przy takiej jakości zdjęć (jest niestety zbyt niska) nawet nie będę próbował analizować czegokolwiek online, jak chcesz możesz wysłać do mnie do analizy, ale nie mogę gwarantować niczego, w drastycznym scenariuszu nawet zwrotu sprzętu - mam problemy zdrowotne, które mogą przeszkodzić we wszystkim.
Jakkolwiek złącze J1 (bez wlutowanych pinów) jest niewątpliwie połączone z modułem E72 i odpowiednio opisane - możliwe, że z jego wykorzystaniem da się zmienić firmware Zigbee, jeśli nie jest to możliwe po sieci.
A złącze J2 (bez wlutowanych pinów) służy do flashowania ESP.
Cześć,
Znalałam wolną chwile żeby zająć się update. Niestety coś poszło nie tak.
Prośba o pomoc.
Więc najpierw napiszę co zrobiłem i jaki jest efekt.
Jak będą potrzebne do tego zdjęcia to zrobie.
Zgodnie z instrukcją dla mac wywołałem z lini poleceni komendy
curl --output cc2538-bsl.zip https://codeload.github.com/JelmerT/cc2538-bsl/zip/master && unzip cc2538-bsl.zip
/usr/bin/python3 -m pip install --user pyserial intelhex
Następnie na stronie koordynatora nacisnąłem przycisk Toggle przy cc2652p firmware update
pojawiło się
[D][switch:025]: 'zRST_gpio' Turning OFF.
[D][switch:045]: 'zRST_gpio': Sending state ON
[D][main:379]: Delaying ~10 seconds for TI chip to be ready
[D][switch:025]: 'cc2652p BSL' Turning OFF.
[D][switch:045]: 'cc2652p BSL': Sending state ON
[D][main:387]: Update with cc2538-bsl tool now!
[D][main:390]: Usage: cc2538-bsl.py -p socket://ip_or_hostname:6638 -evw firmware.hex
z lini poleceń odpaliłęm
python3 cc2538-bsl.py -p socket://192.168.0.129:6638 -evw CC1352P2_CC2652P_other_coordinator_20230507.hex
Efekt w lini poleceń
Opening port socket://192.168.0.129:6638, baud 500000
Reading data from CC1352P2_CC2652P_other_coordinator_20230507.hex
Your firmware looks like an Intel Hex file
Connecting to target...
CC1350 PG2.0 (7x7mm): 352KB Flash, 20KB SRAM, CCFG.BL_CONFIG at 0x00057FD8
Primary IEEE Address: 00:12:4B:00:24:BC:E5:1F
Performing mass erase
Erasing all main bank flash sectors
Erase done
Writing 360448 bytes starting at address 0x00000000
ERROR: Timeout waiting for ACK/NACK after 'Get Status (0x23)'
a na www
[D][streamserver:085]: New client connected from 192.168.0.50
[D][streamserver:050]: Client 192.168.0.50 disconnected
[D][sensor:121]: 'uptime_s': Sending state 5870.84424 s with 0 decimals of accuracy
No i pytanie co z tym można zrobić ?
I tu kluczowe pytanie
czy zatrzymałeś Z2M przed próbą aktualizacji firmware?
bo coś mi się zdaje, że nie…
I to jest właśnie przyczyna.