Oki. To mamy przyczynę, mój błąd myśle że na przyszłość dla potomnych się ta informacja przyda. A czy ktoś wie może jak teraz przywrócić firmware do działania ?
Trochę poniewczasie ale taka analogia:
Jeśli próbujesz wymienić świecę w silniku samochodu to najpierw gasisz silnik, bo bez tego wymiana świec może się nie udać.
Co dalej? no cóż zgaś silnik i wymień świecę jeszcze raz, zakładam optymistycznie, że bootloadera nie uwaliłeś.
No chyba niestety ale nie mam szcześcia.
Wyłączyłem Z2M.
Włączyłem tryb aktualizacji firmware.
Polecenie
python3 cc2538-bsl.py -p socket://192.168.0.129:6638 -evw CC1352P2_CC2652P_other_coordinator_20211217.hex
Efekt w lini poleceń
Opening port socket://192.168.0.129:6638, baud 500000
Reading data from CC1352P2_CC2652P_other_coordinator_20211217.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)'
Efekt na stronie kordynatora
[D][switch:021]: 'cc2652p BSL' Turning ON.
[D][switch:045]: 'cc2652p BSL': Sending state OFF
[D][switch:021]: 'zRST_gpio' Turning ON.
[D][switch:045]: 'zRST_gpio': Sending state OFF
[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][sensor:121]: 'uptime_s': Sending state 221.36301 s with 0 decimals of accuracy
[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
[D][streamserver:085]: New client connected from 192.168.0.50
[I][ota:046]: Boot seems successful, resetting boot loop counter.
[D][streamserver:050]: Client 192.168.0.50 disconnected
No i jeszcze ponowna próba uruchomienia Z2M
[15:53:37] INFO: Preparing to start...
[15:53:37] INFO: Socat not enabled
[15:53:38] INFO: Starting Zigbee2MQTT...
Zigbee2MQTT:debug 2024-02-23 15:53:39: Loaded state from file /share/zigbee2mqtt/state.json
Zigbee2MQTT:info 2024-02-23 15:53:39: Logging to console and directory: '/share/zigbee2mqtt/log/2024-02-23.15-53-39' filename: log.txt
Zigbee2MQTT:debug 2024-02-23 15:53:39: Removing old log directory '/share/zigbee2mqtt/log/2024-02-23.13-05-05'
Zigbee2MQTT:info 2024-02-23 15:53:39: Starting Zigbee2MQTT version 1.35.3 (commit #unknown)
Zigbee2MQTT:info 2024-02-23 15:53:39: Starting zigbee-herdsman (0.33.8)
Zigbee2MQTT:debug 2024-02-23 15:53:39: Using zigbee-herdsman with settings: '{"adapter":{"concurrent":null,"delay":null,"disableLED":false},"backupPath":"/share/zigbee2mqtt/coordinator_backup.json","databaseBackupPath":"/share/zigbee2mqtt/database.db.backup","databasePath":"/share/zigbee2mqtt/database.db","network":{"channelList":[11],"extendedPanID":[221,221,221,221,221,221,221,221],"networkKey":"HIDDEN","panID":6754},"serialPort":{"path":"tcp://192.168.0.129:6638"}}'
[D][streamserver:085]: New client connected from 192.168.0.111
[D][streamserver:050]: Client 192.168.0.111 disconnected
[D][streamserver:085]: New client connected from 192.168.0.111
[D][sensor:121]: 'uptime_s': Sending state 1721.36304 s with 0 decimals of accuracy
[D][streamserver:050]: Client 192.168.0.111 disconnected
[D][streamserver:085]: New client connected from 192.168.0.111
[D][streamserver:050]: Client 192.168.0.111 disconnected
[D][streamserver:085]: New client connected from 192.168.0.111
ale najpierw odpalasz koordynator w trybie flashowania a poterm go flashujesz?
bo logi podałęś w odwrotnej kolejności…
dopiero na tym etapie
możesz uruchomić to
po kiego grzyba ten z2m?
zgrałeś sobie wszystkie backupy z czasów gdy to działało w bezpieczne miejsce?
Próbowałeś tego narzędzia? (zamiast pythonowego skryptu)
Skoro boiotloader się zgłasza to i flashowanie się powinno udać
Zasilanie jest OK?
Dokładnie tak robie jak napisałeś.
Ten pierwszy krok słownie opisałem jako włączenie trybu aktualizacji firmware:
[D][switch:029]: 'cc2652p firmware update' Toggling ON.
[D][switch:021]: 'cc2652p BSL' Turning ON.
[D][switch:045]: 'cc2652p BSL': Sending state OFF
[D][switch:021]: 'zRST_gpio' Turning ON.
[D][switch:045]: 'zRST_gpio': Sending state OFF
[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
I po takim komunikacie polecenie
python3 cc2538-bsl.py -p socket://192.168.0.129:6638 -evw CC1352P2_CC2652P_other_coordinator_20211217.hex
Teraz też zauważyłem że poniższy komunikat czasem wyskakuje zaraz po uruchomieni czasem po dłuższej pracy.
ERROR: Timeout waiting for ACK/NACK after ‘Get Status (0x23)’
Nie mam możliwości zweryfikowania polecenia, ale narzędzie które podlinkowałem jak dotąd mnie nie zawiodło.
Jeśli masz inne wersje FW (starsze lub nowsze) to spróbuj, oczywiście ma być wersja other flashowanie musi się udać, bo sprzęt reaguje prawidłowo.
Zasilacz jest na pewno OK?
Finalnie się udało.
Okazało się że wifi nie jest najlepszą siecią do fleshowania.
Po kablu się podłączyłem i zadziałało wszystko.
Dzięki wielkie za pomoc i podpowiedzi.
Pozdrawiam
Marcin.
No WiFi bywa nie najlepsze do tego celu, ale chyba miałeś w tym swój udział
nie rozumiem z jakiej paki masz jakieś logi z OTA ESP czyżbyś robił sobie pod górkę i ciągnął logi z ESP po WiFi w trybie OTA równocześnie z próbą flashowania MCU Zigbee?
Ma ktoś sprawdzony i sprawny wsad do ESP ?
Do tej wersji bez DIP switchy.
Nie wiem jak to się mogło stać, ale podmieniłem sobie wsady między urządzeniami, które były w ESPHOME.
Koordynator chodził na 192.168.1.46, dodałem nowe urządzenie ESP32_WMBUS i też wpisałem to samo IP (zapomniałem że koordynator ma już takie).
Poszedł update na ESP32-WMBUS, ale po chwili bramka przestała się komunikować po LAN, i była tylko widoczna po WiFi z takimi parametrami z jakimi ustawiłem ESP32-WMBUS.
EDIT:
Temat już prawie ogarnięty,
Wsad do ESPHOME zładowany - kod znalazłem w tym temacie 
LAN działa,
Jeszcze tylko testy Zigbee
ps. testował ktoś Z-Stack_3.x.0_coordinator_20240710 na tej bramce ?
To nie ma nic wspólnego z “bramką” istotny jest chipset Zigbee
Jeśli masz E72 (taki jest na zdjęciach a “bramki” bez mysiej klawiaturki nie miałem w ręce) to będzie działać tak samo jak na każdym innym koordynatorze na E72.
Od miesięcy mam wersję 20230716 (ktoś inny kiedyś pytał o nią) i działa stabilnie jak skała (ale mam małą sieć).
Ponieważ to żadna sztuka zmienić firmware Zigbee w koordynatorze USB to wrzucę taką o jaką pytasz (akurat mam koordynator też na E72 - dla niego plik to CC1352P2_CC2652P_other_coordinator_20240710.hex).
To się nim podziel jako przetestowanym z tym konkretnie sprzętem (jeśli sprawdzisz też czy funkcje odpowiadające za update MCU Zigbee na nim działają)
Wprawdzie u siebie na repo trzymam a nawet czasami aktualizuję jakieś YAMLe przygotowane kiedyś dla jednego z użytkowników forum, ale chyba ich nie przetestował (to były pod wersję z mysią klawiaturką, bo z takiej odrysowałem schemat gdy miałem ją w ręce)
edit
No cóż nie testowałem nazbyt długo, ale 20240710 oczywiście u mnie działa, więc zostaje do czasu kolejnej wersji.
Po kolei. Mam bramkę jak ty to piszesz “bez mysiej klawiaturki”.
Kod do ESP jednak wziąłem stąd:
wybrałem wersję bez BT - bo nie używam
Potem przyszła pora na firmware Zigbee. Dotychczas siedziała u mnie wersja 20210708 - czyli dość wiekowy soft.
Brak obsługi USB wymusił programowanie przez LAN, z tego co czytałem to trwa to ok 10 razy dłużej niż po USB. Kolejny minus to flashowanie po IP obsługuje tylko wersja cc2538-bsl na pytona. Wersja na Windows cc2538-bsl_x64.exe obsługuje tylko porty COM.
Wszedłem na web od bramki, dałem “cc2652p firmware update”, w logu po chwili pojawia się komunikat:
"Delaying ~10 seconds for TI chip to be ready"
"Update with cc2538-bsl tool now!"
"Usage: cc2538-bsl.py -p socket://ip_or_hostname:6638 -evw firmware.hex"
Odpaliłem CMD, wpisałem to co poniżej i enter.
root@debian:~/cc2538-bsl# ./cc2538-bsl.py -e -w -v -p socket://192.168.1.46:6638 CC1352P2_CC2652P_other_coordinator_20240710.hex
Opening port socket://192.168.1.46:6638, baud 500000
Reading data from CC1352P2_CC2652P_other_coordinator_20240710.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:BF:D5:4A
Performing mass erase
Erasing all main bank flash sectors
Erase done
Writing 360448 bytes starting at address 0x00000000
Write 104 bytes at 0x00057F988
Write done
Verifying by comparing CRC32 calculations.
Verified (match: 0x00ed3911)
Bramka wstała, sprawdziłem wersję:
Wersja Zigbee2MQTT
1.37.1
Typ koordynatora
zStack3x0
Wersja oprogramowania koordynatora
20240710
Jak na razie wszystko ok.
Możesz coś więcej napisać co miałeś na myśli: “jeśli sprawdzisz też czy funkcje odpowiadające za update MCU Zigbee na nim działają”
Coś konkretnego sprawdzić/zweryfikować ?
- Wklej ten kod do posta, ta grupa na FB nie jest dostępna bez logowania = to jest zaprzeczenie idei open-source (sam nie używam FB, podobnie ja wielu z użytkowników forum, więc sobie tego nie wygrzebię z fejsa)
A ponieważ producent sprzętu podobno się wypiął na swoich klientów, to dla potrzebujących trzymam YAMLe w ogólnie dostępnym miejscu w internecie - na swoim repozytorium, ale ich chyba nikt nie zweryfikował, a ja nie mam sprzętu (raz miałem w celach serwisowych wersję z mysią klawiaturką od jednego z użytkowników forum i przy okazji zrysowałem schemat, ale nie zmieniałem wtedy wsadu ESP, bo nie było konieczności i te YAMLe powstały później) - zweryfikować miałeś czy działa flashowanie MCU Zigbee po sieci (E72 czyli CC2652P w takim wykonaniu, że wymagane jest firmware z członem
other) skoro działa to zweryfikowałeś, ale niewiele daje ta informacja bez sprawdzonego YAMLa dla ESPHome - dla użytkowników innych systemów (windows, macos) można sprawdzić czy działa flashowanie MCU Zigbee narzędziem ZigStar Multi Tool (moim zdaniem działa, ale nie mam tego sprzętu to nie przetestuję)
ZigStar Multi Tool - ZigStar
Tak poza konkurencją to na podstawie zdjęć wersji bez dip-switchy (“mysiej klawiaturki”) podejrzewam, że można flashować MCU Zigbee z użyciem podpiętego mostka USB-UART.
No i info dla niezorientowanych - przy flashowaniu po sieci zawsze bezwzględnie zatrzymujemy serwer bramki Zigbee, który w danej instalacji używa koordynatora (Z2M lub ZHA)
konfiguracja ESPHome dla bramki ->bez BT
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
use_address: 192.168.0.78
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
sensor:
- platform: uptime
id: uptime_s
update_interval: 300s
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:
id: uart_bus
rx_pin: GPIO5
tx_pin: GPIO17
baud_rate: 115200
stream_server:
uart_id: uart_bus
pełna konfiguracja bramki:
substitutions:
device_name: cc2652p2lan
friendly_name: LeMo cc2652p LAN
esphome:
name: cc2652p2lan
build_path: .esphome/build/cc2652p2lan
platformio_options: {}
includes: []
libraries: []
name_add_mac_suffix: false
esp32:
board: esp-wrover-kit
framework:
version: 1.0.6
source: ~3.10006.0
platform_version: platformio/espressif32 @ 3.5.0
type: arduino
variant: ESP32
ethernet:
type: LAN8720
mdc_pin: 23
mdio_pin: 18
clk_mode: GPIO0_IN
phy_addr: 1
power_pin:
number: 16
mode:
output: true
input: false
open_drain: false
pullup: false
pulldown: false
inverted: false
use_address: 192.168.0.78
domain: .local
logger:
level: DEBUG
baud_rate: 115200
tx_buffer_size: 512
deassert_rts_dtr: false
hardware_uart: UART0
logs: {}
api:
reboot_timeout: 0s
port: 6053
password: ''
ota:
safe_mode: true
port: 3232
reboot_timeout: 5min
num_attempts: 10
web_server:
port: 80
version: 2
include_internal: false
ota: true
css_url: ''
js_url: https://oi.esphome.io/v2/www.js
time:
- platform: homeassistant
id: homeassistant_time
timezone: UTC0
update_interval: 15min
external_components:
- source:
url: https://github.com/oxan/esphome-stream-server.git
type: git
refresh: 1d
components: all
sensor:
- platform: uptime
id: uptime_s
update_interval: 300s
disabled_by_default: false
force_update: false
unit_of_measurement: s
icon: mdi:timer-outline
accuracy_decimals: 0
state_class: total_increasing
entity_category: diagnostic
name: uptime_s
internal: true
switch:
- platform: restart
name: LeMo cc2652p LAN Restart
disabled_by_default: false
entity_category: config
icon: mdi:restart
- platform: gpio
pin:
number: 33
mode:
output: true
input: false
open_drain: false
pullup: false
pulldown: false
inverted: false
id: zRST_gpio
inverted: true
restore_mode: ALWAYS_OFF
disabled_by_default: false
interlock_wait_time: 0ms
name: zRST_gpio
internal: true
- platform: template
name: cc2652p RST
icon: mdi:toggle-switch
id: zRST
turn_on_action:
then:
- switch.turn_on:
id: zRST_gpio
- delay: 15ms
- switch.turn_off:
id: zRST_gpio
disabled_by_default: false
optimistic: false
assumed_state: false
restore_state: false
- platform: gpio
pin:
number: 32
mode:
output: true
input: false
open_drain: false
pullup: false
pulldown: false
inverted: false
name: cc2652p BSL
icon: mdi:toggle-switch
id: zBSL
inverted: true
restore_mode: ALWAYS_OFF
internal: true
disabled_by_default: false
interlock_wait_time: 0ms
- platform: template
name: cc2652p firmware update
icon: mdi:cellphone-arrow-down
turn_on_action:
then:
- script.execute:
id: fw_update_mode
turn_off_action:
then:
- switch.toggle:
id: zRST
disabled_by_default: false
optimistic: false
assumed_state: false
restore_state: false
script:
- id: fw_update_mode
then:
- switch.turn_on:
id: zBSL
- delay: 1s
- switch.turn_on:
id: zRST_gpio
- delay: 1s
- switch.turn_off:
id: zRST_gpio
- logger.log:
format: Delaying ~10 seconds for TI chip to be ready
level: DEBUG
tag: main
args: []
- delay: 10s
- switch.turn_off:
id: zBSL
- logger.log:
format: Update with cc2538-bsl tool now!
level: DEBUG
tag: main
args: []
- logger.log:
format: 'Usage: cc2538-bsl.py -p socket://ip_or_hostname:6638 -evw firmware.hex'
level: DEBUG
tag: main
args: []
mode: single
uart:
- id: uart_bus
rx_pin:
number: 5
mode:
input: true
output: false
open_drain: false
pullup: false
pulldown: false
inverted: false
tx_pin:
number: 17
mode:
output: true
input: false
open_drain: false
pullup: false
pulldown: false
inverted: false
baud_rate: 115200
rx_buffer_size: 256
stop_bits: 1
data_bits: 8
parity: NONE
stream_server:
- uart_id: uart_bus
1 polubienie
Pewnie tak jest, bo na płytce widać odpowiednio poprowadzone ścieżki do E72
Otwory na piny są też odpowiednio opisane. Więc lutujemy kabelki do odpowiednich miejsc lub wlutowujemy piny.
Twoje repo dla ESP32, też chyba sprawdzałem - wt32-eth01-cc2565p-sterniczuk.yaml
Ale przy validate wywalało mi jakiś błędny komunikat (już nie pamiętam co dokładnie) odnośnie tego wpisu poniżej, i odpuściłem tego yaml’a.
dashboard_import:
package_import_url: github://nepozs/esphome-projects/wt32-eth01-cc2565p-sterniczuk.yaml@master
No tak, zapomniałem jaka była idea (to miały być serwisowe biny dla nie posiadających YAMLa)… tam brakuje prekompilowanych wsadów, nie miał kto przetestować i tak zostało.
te linijki można wywalić…
Ogólnie wyszło na to, że nie mam dość czasu by zajmować się projektami dla sprzętu, którego nie używam (natomiast autor sprzętu mógł to ogarnąć właśnie w taki sposób).
edit
Hmm, dziwne u mnie się kompilują te biny, może powinienem je po prostu wrzucić na repo (bo droga odratowywania sprzętu jest taka - wgrywa się bina factory przez USB następnie Adopcja do IDE i mamy YAMLA który zasysa się sam z repo)
więc jeśli jesteś gotów zaryzykować to je powrzucam na githuba
teoretycznie można pociągnąć temat gdyby był jakiś chętny na testy - z pewnością konieczne są jakieś poprawki, ale wtedy gdy miałem na to czas nie było chętnego ze sprzętem do współracy
(nie ukrywam nie wiem czy dziś są nadal aktualne i działające - powstały jakieś 1.5 roku temu i uwzględniłem ostatnio tylko breaking change dotyczące OTA, natomiast zakładam, że użyte komponenty w aktualnych wersjach po prostu działają, - niektóre wersja YAMLi, które widziałem opierają się na specyficznych starych wersjach komponentów i wiem z czego to wynikało kiedyś - komponent streamowania seriala przez długi czas nie działał prawidłowo)
Jeśli ktoś ma ucegloną bramkę to nie ma nic do stracenia, jeśli ktoś ma ucegloną bramkę, a nie wie jak wgrać moje firmware może mi podesłać - będę miał materiał na testy (nie gwarantuję szybkiego zwrotu, ostatnio serwis bramki trwał kilka miesięcy, kontakt na PW, oczywiście nie gwarantuję naprawy).
oczywiście właściwy link to
Możliwe, że moje wsady są niekompatybilne z softem “z pudełka” bo @Grzegorz_Sterniczuk nigdy się nie podzielił oryginalnymi YAMLami na forum mimo, że ma tu konto…
Taki mały offtopic, ale związany poniekąd z tematem.
Aktualnie używam 2 koordynatorów - dom i garaż.
- jeden wpięty po USB (też od Grzegorza :D) na Dell Wyse 5070 - HA jako VM na Proxmox.
- drugi to właśnie ta bramka LAN.
Oba koordynatory są obsługiwane przez addon w HA (mam zduplikowany Z2M).
Ostatnio testuje Z2M jako Zigbee2MQTT LXC na Proxmox.
Jak przeniosę konfig (pan_id, channel, network_key) Z2M z addona do kontenera to trzeba będzie parować na nowo urządzenia ?
Jak przeniesiesz konfigurację Z2M to nie będziesz musiał parować urządzeń od nowa.
i jeśli użyjesz tego samego dongla
Nie wiem co masz, ale z tego co pamiętam to sprzedawał on też dongle USB zaprojektowane przez @egony (sam mam takiego sticka, ale z innego źródła)
Tak przeglądam konwersację z Grzegorzem i znalazłem takie coś:
Czyżby to był oryginalny wsad do ESP od Grzegorza?
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
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
sensor:
- platform: uptime
id: uptime_s
update_interval: 300s
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
#Update CC2652P/CC2652RB Firmware
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
Takiego mam:
