Open luconedj opened 9 months ago
First your pictures is private so cant taking one closer look on them. The WiFi/Ble module is the one that doing the "tuya things". https://developer.tuya.com/en/docs/iot/wbrg1-module-datasheet?id=Ka015vo8tfztz The 7 row pads (i think its marked P3) for the Zigbee module SWD / debut interface plus comport for the tuya things. (the last is only likely). P1 looks being one comport for console but cant see and you must testing if you is getting some output then booting from it.
Hi @MattWestb , Thank you for your fast reply. Sorry but I didn't get what you mean with private picture.. If i understood well, you are suggesting to test if some UART Output is present on P1 pads since you suspect it is for console right? Somehow it seems that the P2 one is directly connected to ZS3L🤔 ? Anyway, ill try both and ill report here any useful Output. Thanks!
The picture is now working so i can taking one close look later (i have seen the same some times before and its taking some times until being released).
Try find the Linux console then its booting and its very likely on one of the connections. If finding it the next step is trying getting in bootloader mode of the WiFi module but first the local console.
PS: the P2 is the first going to the Zigbee module but the last 3 is going to both but can being used for sortieing interesting.
Hi, You where right, uart out is on P1 :) Here is the log, but i was not able to interrupt boot process.. Tried esc, Enter and all usual key. Thanks! Tuya.log
Great you getting the boot log from the WiFi / Bt module !!
Bad news is not running one Linux like the old Eth box was doing.
[01-01 18:12:15 TUYA N][tuya_device.c:139] SDK INFO: < TUYA IOT SDK V:3.1.7 BS:40.00_PT:2.2_LAN:3.4_CAD:1.0.4_CD:1.0.0 >
Its tuya IOT SDK / System so need looking if tuya IOT is hackebal or one SDK from the chip that is doing one normal Linux.
wbrg1, contains realtek RTL8721CSM wifi+bt with cortex cpu.. so it will be SOC, i think this project could help to write own system, and use it as you like..
@geduxas Or https://docs.libretiny.eu/
@geduxas Or https://docs.libretiny.eu/
It's say's rb8710, not sure is it compatible sdk with 8721 or not.. it could be different products
Hi guys, Thanks Your feedbacks! @MattWestb honestly I was not expecting Linux, but somehow I was expecting a kind of bootloader on it which seems not accessible (maybe?) Via that UART. @geduxas, regarding amebaD, I cannot fine any reference to tuya SoC, I belive this are only for the radio Chip correct? In this case, do you have any suggestion for a way forward on it? @mihsu81 , this is another very interesting project but seems that wbrg1 is in the unsupported board list (even if I see 2 flag on both wifi and bt colums? Not clear:( ) Regardless the alternative compatible SDK, how to flash then? And also this is for WiFi chip, should I do a similar stuff (new firmware) for ZS3L right? Really appreciate your interest guys, Thank you very much! Luca
@luconedj it's truly nothing to do with tuya, chip made bye realtek, and it contains cortex cpu, where all tuya software is running.
Tuya only packed components from shelf and made it's software. So if you wana untie this device from tuya, you need to find out other software, or write in your own.. so SDK (Software development kits) are tool bundle which you're required to build and compile your own software..
Take example other tuya products which runs on ESP chips, they are also wifi chips with cpu, and also as same as @mihsu81 mentioned..
@geduxas thank you, got it. At this point I can pick one of the 2, try to write an hello world and then figure out how to tunnel ZS3L through wifi right?
If can getting one ser2net working all shall being OK its the only thing that is needed. If not putting in one ESP8266 / 32 and cutting the com lines to the Zigbee module and it shall working as we is doing with ESPHome (some problems with the serial server is still there) or somthing else on the ESP. The Zigbee module is pity good (MG21 chip) and can running newer EZSP or RCP / Thread firmware without problems only little week antenna for my taste (compered with Silabs original that IKEA is using).
Hope we can getting one more tuya GW well hacked !!!!!
If can getting one ser2net working all shall being OK its the only thing that is needed. If not putting in one ESP8266 / 32 and cutting the com lines to the Zigbee module and it shall working as we is doing with ESPHome (some problems with the serial server is still there) or somthing else on the ESP. The Zigbee module is pity good (MG21 chip) and can running newer EZSP or RCP / Thread firmware without problems only little week antenna for my taste (compered with Silabs original that IKEA is using).
Hope we can getting one more tuya GW well hacked !!!!!
Yes i hope the same! About EZSP, SWD must be used correct? if so, let me order a Chinese ST-Link V2 from Amazon :)
For ESP only USB-TTL is needed but for the ZS3L if not the bootloader (it shall working) you need flashing new bootloader on the MG21 chip you need one SWD that supporting MG2X devices (not all do it then its have extra hardware security).
Hi @MattWestb , thanks. do you know if this will work? (https://www.amazon.it/gp/product/B0B5WYQ4FT/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8&th=1) sorry page is in italian basically is the st-link v2 clone. Thanks, Luca
Its working 100% on MG1 chips like first and second gen IKEA devices but likely not on MG2X but some users have getting it working but i donnt knowing witch firmware and program they was using (I have one original Silabs WSDK do its one genuine Seeger device and its having extra things for Silabs chips in the firmware).
mmm ok, i'll try, 7 euro is affordable and honestly it's long time that i need one to start playing with STM32 haah Thanks!
Hello guys! Got ST-Link v2 clone and made some progress here. Using opeocd and arm-none-eabi-gdb with the attached configs, i managed to connect to Z3SL and dump memory (I think hahah):
Here is the log: [luconedj@archlinux ~]$ cat st.cfg set CPUTAPID 0x6BA02477 adapter driver hla hla_layout stlink hla_device_desc "ST-LINK" hla_vid_pid 0x0483 0x3744 0x0483 0x3748 0x0483 0x374b 0x0483 0x374d 0x0483 0x374e 0x0483 0x374f 0x0483 0x3752 0x0483 0x3753 0x0483 0x3754 0x0483 0x3755 0x0483 0x3757 transport select hla_swd adapter speed 50 [luconedj@archlinux ~]$ openocd -f st.cfg -f target/efm32.cfg -c "gdb_memory_map disable" Open On-Chip Debugger 0.12.0 Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html adapter speed: 50 kHz
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD Info : Listening on port 6666 for tcl connections Info : Listening on port 4444 for telnet connections Info : clock speed 1000 kHz Info : STLINK V2J39S7 (API v2) VID:PID 0483:3748 Info : Target voltage: 3.246684 Info : [efm32.cpu] Cortex-M33 r0p3 processor detected Info : [efm32.cpu] target has 8 breakpoints, 4 watchpoints Info : starting gdb server for efm32.cpu on 3333 Info : Listening on port 3333 for gdb connections Info : accepting 'gdb' connection on tcp/3333 [efm32.cpu] halted due to debug-request, current mode: Thread xPSR: 0x69000000 pc: 0x0000e6a0 msp: 0x2000b4f8 Info : dropped 'gdb' connection
On the other Terminal with GDB:
[luconedj@archlinux ~]$ cat gdb.cfg target extended-remote 127.0.0.1:3333 set confirm off monitor halt info mem dump memory dump.bin 0x00000000 0x00080000 quit [luconedj@archlinux ~]$ arm-none-eabi-gdb -x gdb.cfg GNU gdb (GDB) 14.1 Copyright (C) 2023 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "--host=x86_64-pc-linux-gnu --target=arm-none-eabi". Type "show configuration" for configuration details. For bug reporting instructions, please see: https://www.gnu.org/software/gdb/bugs/. Find the GDB manual and other documentation resources online at: http://www.gnu.org/software/gdb/documentation/.
For help, type "help". Type "apropos word" to search for commands related to "word". warning: No executable has been specified and target does not support determining executable automatically. Try using the "file" command. 0x0000e6a0 in ?? () Using memory regions provided by the target. There are no memory regions defined. [Inferior 1 (Remote target) detached] [luconedj@archlinux ~]$
Attached also dump.bin. Analyzing it with an hex editor, seems quite valid. I found also some tring related to Gecko bootloader and ember. dump.bin.zip Any feedback really appreciated 👏!! THanks guys, Luca
Great work done @luconedj !!! The first 0x0 - 0x3FFFF is the bootloder and then the "APP" is resident 0x4000 as long its need and after that is one random block of for the NVM file higher in the flash memory. If all is being OK dumped it shall being possible restoring the module also after one chip erase. The main flash is good but some chip information is stored in the aria "user data" that can being needed / interesting if tuya have using it and putting some device specific there we can need it in the future.
Hi @MattWestb thank you very much for the feedback ❤️. Do you know How to extract user data? Meanwhile I'm still stuck on WBRG1, I'm not able to find a way to interact with it. If you look at the boot log, you will find this output: [01-01 18:12:15 TUYA N][af-main-host.c:659] >>>Normal UART bootup with FLOWCTRL<<< And exactly at that point, there is some kind of fixed pause in the output (like waiting for some interrupt character/pin) and then it continues.. My thought is that due to some Hw flow control, it is ignoring my button pressed, what do you think, any suggestion on the WiFi bastard? Thanks!
https://www.silabs.com/documents/public/data-sheets/efr32mg21-datasheet.pdf
Figure 3.2. EFR32MG21 Memory Map — Core Peripherals and Code Space
You shall have it all.
If i remember shall GDB detecting it and you can listing it (at least with MG1P chips) with the information command.
Do one normal dump with start and end dress / range or the name of the memory bank shall working OK like you was doing with the main flash.
Ok cool! To let it works i used this on GDB: -c "gdb_memory_map disable" And in openocd conf: dump memory dump.bin 0x00000000 0x00080000
So i think i don't have all.. i'll try to repeat process according to memory map you shared. Ill let u know thanks! Luca
ok i used this: dump memory flash.bin 0x00000000 0x00100000 dump memory flash_user.bin 0x0fe00000 0x0fe00400 dump memory flash_dev_info.bin 0x0fe08000 0x0fe08400 dump memory flash_chip_config.bin 0x0fe0e000 0x0fe0e400 dump memory flash_reserved_partial.bin 0x0ff00000 0x0ff00400
nothing in user data... This is binwalk out on flash.bin:
19276 0x4B4C Boot section Start 0x57424257 End 0x42703857
What about WBRG1 ? any idea on this? Thank you so much! Luca
Use same st-link for wbrg1 :)
Only the first two is interesting then device info is burned in the factory and we dont have any user of the info stored in the RAM then the processor is running in debug mode. One IKEA 3trd gen controller with Silabs commander:
Use same st-link for wbrg1 :)
Yes.. but how? haah
Only the first two is interesting then device info is burned in the factory and we dont have any user of the info stored in the RAM then the processor is running in debug mode. One IKEA 3trd gen controller with Silabs commander:
Ok Perfect, it make sense. Thanks!
nothing in user data... This is binwalk out on flash.bin:
DECIMAL HEXADECIMAL DESCRIPTION 19276 0x4B4C Boot section Start 0x57424257 End 0x42703857
From https://www.silabs.com/documents/public/user-guides/ug103-06-fundamentals-bootloading.pdf
On EFR32xG21, the main bootloader resides in main flash: • Main bootloader @ 0x0 • Application @ 0x4000
And they is using 2 different bootloaders one for coordinator / CLI apps with X-Modem and one other for devices for OTA updates.
And one good thing putting in the userdata if running EZSP: https://github.com/MattWestb/EFR32-FW/tree/main/Branding_EFR32
Use same st-link for wbrg1 :)
Yes.. but how? haah
As told earlier it's just realtek chip inside.. so need to find out which pins are exposed in tuya board.. i almos sure you should find those easy.
Here is realtek manual i found AN0400 Ameba-D Application Note_v3_watermark.pdf
Use same st-link for wbrg1 :)
Yes.. but how? haah
As told earlier it's just realtek chip inside.. so need to find out which pins are exposed in tuya board.. i almos sure you should find those easy.
Here is realtek manual i found AN0400 Ameba-D Application Note_v3_watermark.pdf
Yes i saw that application note, but i belive is not so useful because related to evaluation board. This should be the pinout of the chip: Pin 33 and 43. I tried all the probable Combination on WRGB1 but i think SWD is not exposed because im not able to see anything. Morover I'm not able to find anything related to SWD for 8721. Thanks! Luca
At least it's possible to open metal cap and solder wires directly to pins :) interesting how it's done in factory.. don't think they have flashed directly to chip and after that it was soldered to board..
Or, forget about wbrg1.. don't think it's worth investigating.. solder it out, pick some well known esp chip, find out required pins and use esp-link .. ZigBee just needs serial bridge :)
At least it's possible to open metal cap and solder wires directly to pins :) interesting how it's done in factory.. don't think they have flashed directly to chip and after that it was soldered to board..
That's very likely, indeed.. I think one of the pin is there because from tuya data 'shit' there is this indication: Which matches with RTL pinout! But nothing related to PIN 43 (CLK). I'll try to dig around a little bit more, then I'm thinking to remove metal shield.. Of course the easy way is to skip it and follow your suggestion on ESP but the challenge is to don't touch original components hahaha. Thank you man! Luca
At least it's possible to open metal cap and solder wires directly to pins :) interesting how it's done in factory.. don't think they have flashed directly to chip and after that it was soldered to board..
That's very likely, indeed.. I think one of the pin is there because from tuya data 'shit' there is this indication: Which matches with RTL pinout! But nothing related to PIN 43 (CLK). I'll try to dig around a little bit more, then I'm thinking to remove metal shield.. Of course the easy way is to skip it and follow your suggestion on ESP but the challenge is to don't touch original components hahaha. Thank you man! Luca
Some interesting pins which exposed in TUYA
Guys, I'm finally in! Good news is that building Realtek SDK, with their image Tool i managed to erase the chip!! Bad one? I don't have the dump but at this point, who cares? Haahh Both Core KM0 and KM4 reachable via minimal console, also connected to a WIFI via AT commands with no issue:
I've also managed to disconnect serial from Z3SL switching (desoldering) two of the jumper near P3. Now UART0 is directly exposed on P3 pads :).
Still lot of work needed but I'm happy, this is definitely a good start. Next step: 1) A lot of study on SDK 2) Play with some example and make it works 3) Try to Arrange a simple serial2wifi sw 4) Flash with Stlink (hopefully) Z3SL 5) Restore jumpers on the board
For step 2 3 and 4 I really need your help 😀 Any feedback on the current status and on the mentioned plan draft is, as always, really appreciated. A big thank you to @geduxas for provide the UART_DOWNLOAD detail!
Is the reset from the Z3SL exposed on PCB pads (on the module it is) ? If yes you can holding the MG21 in reset mode and can communication with the WiFi / Bt module without problems its interference with it.
Thank you! Yes should be last pad of P3 according to my meter. But I think it is pulled up I'll figure out.. anyway currently Z3SL is hard detached, maybe I'll leave it like it is for now. Big challenge is coding now, I'm really rusty with C/C++, and I'm not a good developer in general. I'll start from example and maybe I'll do some frankesnstein. What about chatGPT🤣😅? Luca
Thank you! Yes should be last pad of P3 according to my meter. But I think it is pulled up I'll figure out.. anyway currently Z3SL is hard detached, maybe I'll leave it like it is for now. Big challenge is coding now, I'm really rusty with C/C++, and I'm not a good developer in general. I'll start from example and maybe I'll do some frankesnstein. What about chatGPT🤣😅? Luca
You could try import esp-link project to that sdk.. both written in C++ so maybe it will require adopt some libraries, and will run
The reset and the 2 first SWD pad is hardware locked and cant being changed before the app have booted but the SWD can ding disabled and / or remapped in the APP but very likely its not so the reset i think its active low but you can reading that in the datasheet of the EFR32MG21. Very likely tuya is using hardware flow control to the Zigbee module then its the standard in there reference design but that is not problem we can cooking one updated with no or software if needed.
ESPHome is also working OK i using it with my IKEA "Billy" and "Markus" modules !!!
The reset and the 2 first SWD pad is hardware locked and cant being changed before the app have booted but the SWD can ding disabled and / or remapped in the APP but very likely its not so the reset i think its active low but you can reading that in the datasheet of the EFR32MG21. Very likely tuya is using hardware flow control to the Zigbee module then its the standard in there reference design but that is not problem we can cooking one updated with no or software if needed.
ESPHome is also working OK i using it with my IKEA "Billy" and "Markus" modules !!!
I confirm hw FC is in place, but if we burn Z3SL, can we just not use it right? Yes I'll check the datasheet, meanwhile I found a Chinese site with a DIY opensource zigbee/wifi based on same modules and looking at schematic I would say that is 90% the same of my board! https://oshwhub.com/5ini99/zzhome-getway Thanks, Luca
Then one very brave user have dumping the the main flash we can always going back to factory firmware with the right bootloader then tuya have not protecting it so its good for playing with. Interesting is if they have making one hardware force bootloader pin or only using software commands for getting in the bootloader.
For the same module made of one LIDL LED RGBWW light strips controller: https://github.com/MattWestb/EFR32-FW/tree/main/tuya_ZS3L I using other pins then the LED driver was using some of the standard pins. EZSP 6.10.0.0 is working OK and also the Thread RCP firmware but have not updating then for some time . . .
Hello guys! Here we are again.. After a lot of struggling with AmebaD RTK SDK to make UART0 and wifi works as expected, I finally gave up and I tried to not reinvent the wheel. I discovered that there is an Arduino SDK (not intended to be used with RTL8721CSM) which basically works out of the box for many things! https://github.com/ambiot/ambd_arduino
Wifi driver is working well, UART driver is working too After some patch on PIN definition (this sdk is intended to be used with some EV board which remap the PA/PB PIN in some Arduino fashion style). Result is that I was able to compile a working firmware on WBRG1 which implements serial (UART0) to WiFi on a tcp server socket! Bad thing is that I'm not able to let Hw flow control working properly (seems it is not implemented in the Arduino HardwareSerial wrapper). So for the moment, I would like to go without HW flow control.. is it possible? Didn't check XON/XOFF fc which I think is needed... right? At this point I used Stlink-v2 to load your firmware @MattWestb In the Z3SL, but seems totally stuck.. no signal out of the serial, nothing.. It is still alive, able to connect and dump (comparing Flash content seems it is updated correctly). So I decided to use Simplicity studio to generate a binary from Silab NCP example but somehow, build is failing!! Do you think is possible to have a .bin for EFR32MG21A020F768IM32-B without flow control ? Or any other thing to check if firmware loading is working as expected? Thanks guys! Luca
The problem with WH Flowcontroll shall normally not being any problems as long you not flooding the comport and / or the SOC cant processing the commands it getting and i have some test system running firmware and host without and its working OK but best have the same at both ends. Dont flash the Zigbee mosule aslong you is not knowing all other things is working and we is knowing tuya is normally using standard EZSP so shall working with all normal host system. If connecting with Linux minicom you is getting one output then the SOC is starting up and you can see it here https://github.com/MattWestb/IKEA-TRADFRI-ICC-A-1-Module/tree/master/Firmware#gecko-app--billy-ezsp. You can putting the reset pad on the module for getting it restarting then have the WiFi module working OK and you shall getting some caters on the comport without need the WiFi module restarting and losing the TC/IP connection. Also possible testing if some of the new flash utilities can talking with it and restarting in bootloader mode. Then you can do that we can looking making one updated EZSP and / or RCP firmware for it so can running both Zigbee and / or Thread on it if like.
Hi @MattWestb , Thank you very much♡ I've already flash it.. 😅 I will try to revert the original dump, should be possible. Then I'll check for some character in output at reset. Keep u posted! Cheers, Luca
Hello gents! Let me try to summarize what i've tried and what i managed to obtain here: First of all, i managed to restore the orginal firmware on Z3SL thanks to the dumped flash.bin and After a lot of work with Arduino SDK, i was not able to have a final sketch with HW flow control, even changing SDK UART classes, seems that PIN mapping is not allowing me to have PIN_16 an PIN_17 as RTS/CTS PINs.. If i use the AMEBAD API: void serial_set_flow_control(serial_t *obj, FlowControl type, PinName rxflow, PinName txflow); with those pin Module become unresponsive, needs to figure out why... with other PIN, it seems not behaving bad like this. So i decided to give up for now and to use official SDK, wich is really a pain and has a very steep learning curve :(. I found this very helpful repo: https://github.com/parasite85/rtl_firmware Which i adapted for WBRG1, changing UART PIN and adding also HW flow control section BUT.... it was not working... When everything was almost lost, i found a line in the original tuya boot log which turned on my brain:
[01-01 18:12:15 TUYA N][tuya_bt_sdk.c:141] ty bt sdk init success finish
zigbee_boot_pin(TY_GPIOB4) init output high.
So i've further modified it in order to pull GPIO_PB4 High at boot... and.... BINGO!!! THIS TIME IT STARTED TO WORKS! This is the output from a remote bellow CLI with info command in debug mode:
luconedj@tvbox:~/.local/bin$ ./bellows -d socket://192.168.1.26:80 -v DEBUG -b 115200 info
debug: Using selector: EpollSelector
debug: Registering new OTA provider: <zigpy.ota.providers.Inovelli object at 0xffffb810d850>
debug: Registering new OTA provider: <zigpy.ota.providers.Ledvance object at 0xffffb810d910>
debug: Registering new OTA provider: <zigpy.ota.providers.Salus object at 0xffffb810d9a0>
debug: Registering new OTA provider: <zigpy.ota.providers.Sonoff object at 0xffffb810da30>
debug: Registering new OTA provider: <zigpy.ota.providers.ThirdReality object at 0xffffb810dac0>
debug: Using selector: EpollSelector
debug: Opening a serial connection to 'socket://192.168.1.26:80' (115200 baudrate)
debug: RSTACK Version: 2 Reason: RESET_SOFTWARE frame: b'c1020b0a527e'
debug: Received a reset on startup, not resetting again
debug: Send command version: (4,)
debug: Sending: b'004221a850ed2c7e'
debug: Data frame: b'0142a1a8532845d7cf007e'
debug: Sending: b'8160597e'
debug: Adjusting ACK timeout from 1.60 to 1.51
debug: Application frame received version: [7, 2, 25936]
debug: Switching to EZSP protocol version 7
debug: Send command version: (7,)
debug: Sending: b'7d31422157542a1240277e'
debug: Data frame: b'1242a157542a12b009f175cb7e'
debug: Sending: b'82503a7e'
debug: Adjusting ACK timeout from 1.51 to 1.43
debug: Application frame received version: [7, 2, 25936]
debug: EZSP Stack Type: 2, Stack Version: 6550, Protocol version: 7
debug: Send command getValue: (<EzspValueId.VALUE_FORCE_TX_AFTER_FAILED_CCA_ATTEMPTS: 58>,)
debug: Sending: b'2243215754802f91c37e'
debug: Data frame: b'2343a157548022b232ae7e'
debug: Sending: b'83401b7e'
debug: Adjusting ACK timeout from 1.43 to 1.36
debug: Application frame received getValue: [<EzspStatus.ERROR_INVALID_ID: 55>, b'']
debug: Setting value VALUE_FORCE_TX_AFTER_FAILED_CCA_ATTEMPTS = 1 (old value None)
debug: Send command setValue: (<EzspValueId.VALUE_FORCE_TX_AFTER_FAILED_CCA_ATTEMPTS: 58>, b'\x01')
debug: Sending: b'3340215754812fb358544a7e'
debug: Data frame: b'3440a15754812209317e'
debug: Sending: b'8430fc7e'
debug: Application frame received setValue: [<EzspStatus.ERROR_INVALID_ID: 55>]
debug: Adjusting ACK timeout from 1.36 to 1.30
debug: Could not set value VALUE_FORCE_TX_AFTER_FAILED_CCA_ATTEMPTS = 1: EzspStatus.ERROR_INVALID_ID
debug: Send command getConfigurationValue: (<EzspConfigId.CONFIG_SOURCE_ROUTE_TABLE_SIZE: 26>,)
debug: Sending: b'4441215754780fb6b67e'
debug: Data frame: b'4541a1575478156e5954377e'
debug: Sending: b'8520dd7e'
debug: Application frame received getConfigurationValue: [<EzspStatus.SUCCESS: 0>, 220]
debug: Current config CONFIG_SOURCE_ROUTE_TABLE_SIZE = 220 exceeds the default of 200, skipping
debug: Send command getConfigurationValue: (<EzspConfigId.CONFIG_END_DEVICE_POLL_TIMEOUT: 19>,)
debug: Adjusting ACK timeout from 1.30 to 1.24
debug: Sending: b'5546215754780660c47e'
debug: Data frame: b'5646a157547815b85952147e'
debug: Sending: b'8610be7e'
debug: Adjusting ACK timeout from 1.24 to 1.19
debug: Application frame received getConfigurationValue: [<EzspStatus.SUCCESS: 0>, 10]
debug: Setting config CONFIG_END_DEVICE_POLL_TIMEOUT = 8 (old value 10)
debug: Send command setConfigurationValue: (<EzspConfigId.CONFIG_END_DEVICE_POLL_TIMEOUT: 19>, 8)
debug: Sending: b'66472157547906ba5940d97e'
debug: Data frame: b'6747a1575479152fb97e'
debug: Sending: b'87009f7e'
debug: Adjusting ACK timeout from 1.19 to 1.14
debug: Application frame received setConfigurationValue: [<EzspStatus.SUCCESS: 0>]
debug: Send command getConfigurationValue: (<EzspConfigId.CONFIG_TC_REJOINS_USING_WELL_KNOWN_KEY_TIMEOUT_S: 56>,)
debug: Sending: b'7744215754782d70987e'
debug: Data frame: b'7044a1575478159e589ca77e'
debug: Sending: b'8070787e'
debug: Adjusting ACK timeout from 1.14 to 1.09
debug: Application frame received getConfigurationValue: [<EzspStatus.SUCCESS: 0>, 300]
debug: Setting config CONFIG_TC_REJOINS_USING_WELL_KNOWN_KEY_TIMEOUT_S = 90 (old value 300)
debug: Send command setConfigurationValue: (<EzspConfigId.CONFIG_TC_REJOINS_USING_WELL_KNOWN_KEY_TIMEOUT_S: 56>, 90)
debug: Sending: b'0045215754792de85973387e'
debug: Data frame: b'0145a157547915b6c67e'
debug: Sending: b'8160597e'
debug: Adjusting ACK timeout from 1.09 to 1.06
debug: Application frame received setConfigurationValue: [<EzspStatus.SUCCESS: 0>]
debug: Send command getConfigurationValue: (<EzspConfigId.CONFIG_INDIRECT_TRANSMISSION_TIMEOUT: 18>,)
debug: Sending: b'7d314a2157547807672c7e'
debug: Data frame: b'124aa1575478150a5249917e'
debug: Sending: b'82503a7e'
debug: Adjusting ACK timeout from 1.06 to 1.03
debug: Application frame received getConfigurationValue: [<EzspStatus.SUCCESS: 0>, 3000]
debug: Setting config CONFIG_INDIRECT_TRANSMISSION_TIMEOUT = 7680 (old value 3000)
debug: Send command setConfigurationValue: (<EzspConfigId.CONFIG_INDIRECT_TRANSMISSION_TIMEOUT: 18>, 7680)
debug: Sending: b'224b2157547907b247df3e7e'
debug: Data frame: b'234ba15754791538707e'
debug: Sending: b'83401b7e'
debug: Application frame received setConfigurationValue: [<EzspStatus.SUCCESS: 0>]
debug: Adjusting ACK timeout from 1.03 to 1.00
debug: Send command getConfigurationValue: (<EzspConfigId.CONFIG_STACK_PROFILE: 12>,)
debug: Sending: b'334821575478197d31867e'
debug: Data frame: b'3448a157547815b2591d8c7e'
debug: Sending: b'8430fc7e'
debug: Application frame received getConfigurationValue: [<EzspStatus.SUCCESS: 0>, 0]
debug: Adjusting ACK timeout from 1.00 to 0.98
debug: Setting config CONFIG_STACK_PROFILE = 2 (old value 0)
debug: Send command setConfigurationValue: (<EzspConfigId.CONFIG_STACK_PROFILE: 12>, 2)
debug: Sending: b'44492157547919b0593fca7e'
debug: Data frame: b'4549a157547915a10f7e'
debug: Sending: b'8520dd7e'
debug: Application frame received setConfigurationValue: [<EzspStatus.SUCCESS: 0>]
debug: Send command getConfigurationValue: (<EzspConfigId.CONFIG_SUPPORTED_NETWORKS: 45>,)
debug: Adjusting ACK timeout from 0.98 to 0.97
debug: Sending: b'554e2157547838ba1b7e'
debug: Data frame: b'564ea157547815b35990347e'
debug: Sending: b'8610be7e'
debug: Application frame received getConfigurationValue: [<EzspStatus.SUCCESS: 0>, 1]
debug: Current config CONFIG_SUPPORTED_NETWORKS = 1 exceeds the default of 1, skipping
debug: Send command getConfigurationValue: (<EzspConfigId.CONFIG_MULTICAST_TABLE_SIZE: 6>,)
debug: Adjusting ACK timeout from 0.97 to 0.94
debug: Sending: b'664f215754787d33ebbd7e'
debug: Data frame: b'674fa157547815ba59725e7e'
debug: Sending: b'87009f7e'
debug: Application frame received getConfigurationValue: [<EzspStatus.SUCCESS: 0>, 8]
debug: Setting config CONFIG_MULTICAST_TABLE_SIZE = 16 (old value 8)
debug: Send command setConfigurationValue: (<EzspConfigId.CONFIG_MULTICAST_TABLE_SIZE: 6>, 16)
debug: Adjusting ACK timeout from 0.94 to 0.92
debug: Sending: b'774c215754797d33a2590ce27e'
debug: Data frame: b'704ca157547915c2247e'
debug: Sending: b'8070787e'
debug: Application frame received setConfigurationValue: [<EzspStatus.SUCCESS: 0>]
debug: Send command getConfigurationValue: (<EzspConfigId.CONFIG_TRUST_CENTER_ADDRESS_CACHE_SIZE: 25>,)
debug: Sending: b'004d215754780c911c7e'
debug: Data frame: b'014da157547815b259d6fc7e'
debug: Sending: b'8160597e'
debug: Application frame received getConfigurationValue: [<EzspStatus.SUCCESS: 0>, 0]
debug: Setting config CONFIG_TRUST_CENTER_ADDRESS_CACHE_SIZE = 2 (old value 0)
debug: Send command setConfigurationValue: (<EzspConfigId.CONFIG_TRUST_CENTER_ADDRESS_CACHE_SIZE: 25>, 2)
debug: Sending: b'7d3152215754790cb05907a97e'
debug: Data frame: b'1252a1575479158bfa7e'
debug: Sending: b'82503a7e'
debug: Application frame received setConfigurationValue: [<EzspStatus.SUCCESS: 0>]
debug: Send command getConfigurationValue: (<EzspConfigId.CONFIG_SECURITY_LEVEL: 13>,)
debug: Sending: b'2253215754787d38579b7e'
debug: Data frame: b'2353a157547815b759eb377e'
debug: Sending: b'83401b7e'
debug: Application frame received getConfigurationValue: [<EzspStatus.SUCCESS: 0>, 5]
debug: Setting config CONFIG_SECURITY_LEVEL = 5 (old value 5)
debug: Send command setConfigurationValue: (<EzspConfigId.CONFIG_SECURITY_LEVEL: 13>, 5)
debug: Sending: b'3350215754797d38b759efa07e'
debug: Data frame: b'3450a157547915cf697e'
debug: Sending: b'8430fc7e'
debug: Application frame received setConfigurationValue: [<EzspStatus.SUCCESS: 0>]
debug: Adjusting ACK timeout from 0.90 to 0.88
debug: Send command getConfigurationValue: (<EzspConfigId.CONFIG_ADDRESS_TABLE_SIZE: 5>,)
debug: Sending: b'445121575478104fec7e'
debug: Data frame: b'4551a157547815ba59b0607e'
debug: Sending: b'8520dd7e'
debug: Application frame received getConfigurationValue: [<EzspStatus.SUCCESS: 0>, 8]
debug: Setting config CONFIG_ADDRESS_TABLE_SIZE = 16 (old value 8)
debug: Send command setConfigurationValue: (<EzspConfigId.CONFIG_ADDRESS_TABLE_SIZE: 5>, 16)
debug: Sending: b'55562157547910a25998e17e'
debug: Data frame: b'5656a15754791591717e'
debug: Sending: b'8610be7e'
debug: Application frame received setConfigurationValue: [<EzspStatus.SUCCESS: 0>]
debug: Send command getConfigurationValue: (<EzspConfigId.CONFIG_PAN_ID_CONFLICT_REPORT_THRESHOLD: 34>,)
debug: Sending: b'66572157547837989d7e'
debug: Data frame: b'6757a157547815b059befb7e'
debug: Sending: b'87009f7e'
debug: Application frame received getConfigurationValue: [<EzspStatus.SUCCESS: 0>, 2]
debug: Setting config CONFIG_PAN_ID_CONFLICT_REPORT_THRESHOLD = 2 (old value 2)
debug: Send command setConfigurationValue: (<EzspConfigId.CONFIG_PAN_ID_CONFLICT_REPORT_THRESHOLD: 34>, 2)
debug: Sending: b'77542157547937b059109b7e'
debug: Data frame: b'7054a157547915d5e27e'
debug: Sending: b'8070787e'
debug: Application frame received setConfigurationValue: [<EzspStatus.SUCCESS: 0>]
debug: Send command getConfigurationValue: (<EzspConfigId.CONFIG_KEY_TABLE_SIZE: 30>,)
debug: Sending: b'0055215754780bf63d7e'
debug: Data frame: b'0155a157547815be59b0ff7e'
debug: Sending: b'8160597e'
debug: Application frame received getConfigurationValue: [<EzspStatus.SUCCESS: 0>, 12]
debug: Setting config CONFIG_KEY_TABLE_SIZE = 12 (old value 12)
debug: Send command setConfigurationValue: (<EzspConfigId.CONFIG_KEY_TABLE_SIZE: 30>, 12)
debug: Sending: b'7d315a215754790bbe59bfec7e'
debug: Data frame: b'125aa15754791586b87e'
debug: Sending: b'82503a7e'
debug: Application frame received setConfigurationValue: [<EzspStatus.SUCCESS: 0>]
debug: Send command getConfigurationValue: (<EzspConfigId.CONFIG_MAX_END_DEVICE_CHILDREN: 17>,)
debug: Sending: b'225b215754780489647e'
debug: Data frame: b'235ba15754781592590cfe7e'
debug: Sending: b'83401b7e'
debug: Application frame received getConfigurationValue: [<EzspStatus.SUCCESS: 0>, 32]
debug: Current config CONFIG_MAX_END_DEVICE_CHILDREN = 32 exceeds the default of 32, skipping
debug: Send command getConfigurationValue: (<EzspConfigId.CONFIG_APPLICATION_ZDO_FLAGS: 42>,)
debug: Sending: b'3358215754783f4fa67e'
debug: Data frame: b'3458a157547815b25920387e'
debug: Sending: b'8430fc7e'
debug: Application frame received getConfigurationValue: [<EzspStatus.SUCCESS: 0>, 0]
debug: Setting config CONFIG_APPLICATION_ZDO_FLAGS = EmberZdoConfigurationFlags.APP_HANDLES_UNSUPPORTED_ZDO_REQUESTS|APP_RECEIVES_SUPPORTED_ZDO_REQUESTS (old value 0)
debug: Send command setConfigurationValue: (<EzspConfigId.CONFIG_APPLICATION_ZDO_FLAGS: 42>, <EmberZdoConfigurationFlags.APP_HANDLES_UNSUPPORTED_ZDO_REQUESTS|APP_RECEIVES_SUPPORTED_ZDO_REQUESTS: 3>)
debug: Sending: b'4459215754793fb15905297e'
debug: Data frame: b'4559a157547915bb8b7e'
debug: Sending: b'8520dd7e'
debug: Application frame received setConfigurationValue: [<EzspStatus.SUCCESS: 0>]
debug: Send command getConfigurationValue: (<EzspConfigId.CONFIG_PACKET_BUFFER_COUNT: 1>,)
debug: Sending: b'555e215754781445717e'
debug: Data frame: b'565ea157547815485962bb7e'
debug: Sending: b'8610be7e'
debug: Application frame received getConfigurationValue: [<EzspStatus.SUCCESS: 0>, 250]
debug: Setting config CONFIG_PACKET_BUFFER_COUNT = 255 (old value 250)
debug: Send command setConfigurationValue: (<EzspConfigId.CONFIG_PACKET_BUFFER_COUNT: 1>, 255)
debug: Sending: b'665f21575479144d59c4e27e'
debug: Data frame: b'675fa157547915387f7e'
debug: Sending: b'87009f7e'
debug: Application frame received setConfigurationValue: [<EzspStatus.SUCCESS: 0>]
debug: Send command addEndpoint: (1, 260, <DeviceType.IAS_CONTROL: 1024>, 0, 5, 4, [0, 6, 10, 25, 1281], [1, 32, 1280, 1282])
debug: Sending: b'775c2157542814b658944e25af5192499a4e2dabf4ce668efcc64389fc7b3da27d387d5d7e'
debug: Data frame: b'705ca157542815e52e7e'
debug: Sending: b'8070787e'
debug: Application frame received addEndpoint: [<EzspStatus.SUCCESS: 0>]
debug: Send command addEndpoint: (2, 49246, <DeviceType.CONTROLLER: 2080>, 0, 1, 0, [0], [])
debug: Sending: b'005d2157542817ec99b44225ab5592496f957e'
debug: Data frame: b'015da1575428159c8e7e'
debug: Sending: b'8160597e'
debug: Application frame received addEndpoint: [<EzspStatus.SUCCESS: 0>]
debug: Send command networkInit: ()
debug: Sending: b'7d31622157543db34a7e'
debug: Data frame: b'1262a157543d86d6a47e'
debug: Sending: b'82503a7e'
debug: Application frame received networkInit: [<EmberStatus.NOT_JOINED: 147>]
debug: Send command getEui64: ()
debug: Sending: b'22632157540cde057e'
debug: Data frame: b'2363a157540c2115056ab5fb6de5e04d7e'
debug: Sending: b'83401b7e'
debug: Adjusting ACK timeout from 0.84 to 0.89
debug: Application frame received getEui64: [b0:c7:de:ff:fe:5c:a7:34]
[b0:c7:de:ff:fe:5c:a7:34]
debug: Send command getNodeId: ()
debug: Sending: b'33602157540d7fd27e'
debug: Data frame: b'3460a157540deb4db5417e'
debug: Sending: b'8430fc7e'
debug: Application frame received getNodeId: [0xfffe]
[0xfffe]
debug: Send command networkState: ()
debug: Sending: b'4461215754329fe27e'
debug: Data frame: b'4561a15754321548737e'
debug: Sending: b'8520dd7e'
debug: Application frame received networkState: [<EmberNetworkStatus.NO_NETWORK: 0>]
[<EmberNetworkStatus.NO_NETWORK: 0>]
debug: Send command getNetworkParameters: ()
debug: Sending: b'55662157540291417e'
debug: Data frame: b'5666a157540286b2dd9d33cde6f37a3cb17822a0edce678bfd3e9c8e7a817e'
debug: Sending: b'8610be7e'
debug: Adjusting ACK timeout from 0.88 to 1.04
debug: Application frame received getNetworkParameters: [<EmberStatus.NOT_JOINED: 147>, <EmberNodeType.UNKNOWN_DEVICE: 0>, EmberNetworkParameters(extendedPanId=75:e8:a6:4c:e8:79:09:84, panId=0x362d, radioTxPower=5, radioChannel=11, joinMethod=<EmberJoinMethod.USE_MAC_ASSOCIATION: 0>, nwkManagerId=0x0000, nwkUpdateId=0, channels=<Channels.ALL_CHANNELS: 134215680>)]
[<EmberStatus.NOT_JOINED: 147>, <EmberNodeType.UNKNOWN_DEVICE: 0>, EmberNetworkParameters(extendedPanId=75:e8:a6:4c:e8:79:09:84, panId=0x362d, radioTxPower=5, radioChannel=11, joinMethod=<EmberJoinMethod.USE_MAC_ASSOCIATION: 0>, nwkManagerId=0x0000, nwkUpdateId=0, channels=<Channels.ALL_CHANNELS: 134215680>)]
debug: Send command getCurrentSecurityState: ()
debug: Sending: b'66672157544382997e'
debug: Data frame: b'6767a1575443864348864580664ec78d6512f67e'
debug: Sending: b'87009f7e'
debug: Adjusting ACK timeout from 1.04 to 1.06
debug: Application frame received getCurrentSecurityState: [<EmberStatus.NOT_JOINED: 147>, EmberCurrentSecurityState(bitmask=<EmberCurrentSecurityBitmask.4096|256|128|64|32|HAVE_TRUST_CENTER_LINK_KEY|HIGH_SECURITY_MODE: 4593>, trustCenterLongAddress=f9:c4:55:1b:cc:a5:0f:12)]
[<EmberStatus.NOT_JOINED: 147>, EmberCurrentSecurityState(bitmask=<EmberCurrentSecurityBitmask.4096|256|128|64|32|HAVE_TRUST_CENTER_LINK_KEY|HIGH_SECURITY_MODE: 4593>, trustCenterLongAddress=f9:c4:55:1b:cc:a5:0f:12)]
debug: Send command getMfgToken: (<EzspMfgTokenId.MFG_STRING: 1>,)
debug: Sending: b'7764215754211456cd7e'
debug: Data frame: b'7064a1575421054da66bb5da55aa6db663b1d854123198f3407e'
debug: Sending: b'8070787e'
debug: Application frame received getMfgToken: [b'\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff']
debug: Adjusting ACK timeout from 1.06 to 1.14
debug: Read MFG_STRING token: b'\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff'
debug: Send command getMfgToken: (<EzspMfgTokenId.MFG_BOARD_NAME: 2>,)
debug: Sending: b'00652157542117be2b7e'
debug: Data frame: b'0165a1575421054da66bb5da55aa6db663b1d8541231986ad17e'
debug: Sending: b'8160597e'
debug: Adjusting ACK timeout from 1.14 to 1.21
debug: Application frame received getMfgToken: [b'\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff']
debug: Read MFG_BOARD_NAME token: b'\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff'
debug: Send command getValue: (<EzspValueId.VALUE_VERSION_INFO: 17>,)
debug: Sending: b'7d316a2157548004f82f7e'
debug: Data frame: b'126aa157548015b5e9954c20af55386ec87e'
debug: Sending: b'82503a7e'
debug: Application frame received getValue: [<EzspStatus.SUCCESS: 0>, b'\xb0\x01\x06\x05\x05\x00\xaa']
Manufacturer: None
Board name: None
EmberZNet version: 6.5.5.0 build 432
debug: Connection lost: None
debug: Closed serial connection
So original EZSP is:EmberZNet version: 6.5.5.0 build 432
And this, boot log from Zigbee2MQTT in HA:
[11:48:03] INFO: Preparing to start...
[11:48:03] INFO: Socat not enabled
[11:48:04] INFO: Starting Zigbee2MQTT...
Zigbee2MQTT:info 2024-03-25 11:48:05: Logging to console and directory: '/config/zigbee2mqtt/log/2024-03-25.11-48-05' filename: log.txt
Zigbee2MQTT:info 2024-03-25 11:48:05: Starting Zigbee2MQTT version 1.36.0 (commit #unknown)
Zigbee2MQTT:info 2024-03-25 11:48:05: Starting zigbee-herdsman (0.35.1)
Assertion failed: Command (setValue(EzspValueId.VALUE_END_DEVICE_KEEP_ALIVE_SUPPORT_MODE, 3)) returned unexpected state: {"_cls_":"setValue","_id_":171,"_isRequest_":false,"status":55}
Zigbee2MQTT:info 2024-03-25 11:48:31: zigbee-herdsman started (reset)
Zigbee2MQTT:info 2024-03-25 11:48:31: Coordinator firmware version: '{"meta":{"maintrel":"5 ","majorrel":"6","minorrel":"5","product":7,"revision":"6.5.5.0 build 432"},"type":"EZSP v7"}'
Zigbee2MQTT:info 2024-03-25 11:48:31: Currently 0 devices are joined:
Zigbee2MQTT:info 2024-03-25 11:48:31: Zigbee: disabling joining new devices.
Zigbee2MQTT:info 2024-03-25 11:48:31: Connecting to MQTT server at mqtt://homeassistant:Chitammuorto1!@192.168.1.29:1883
Zigbee2MQTT:info 2024-03-25 11:48:31: Connected to MQTT server
Zigbee2MQTT:info 2024-03-25 11:48:31: MQTT publish: topic 'zigbee2mqtt/bridge/state', payload '{"state":"online"}'
Zigbee2MQTT:info 2024-03-25 11:48:32: Started frontend on port 8099
Zigbee2MQTT:info 2024-03-25 11:48:32: MQTT publish: topic 'homeassistant/binary_sensor/1221051039810110150109113116116_0xb0c7defffe5ca734/connection_state/config', payload '{"device":{"hw_version":"EZSP v7 6.5.5.0 build 432","identifiers":["zigbee2mqtt_bridge_0xb0c7defffe5ca734"],"manufacturer":"Zigbee2MQTT","model":"Bridge","name":"Zigbee2MQTT Bridge","sw_version":"1.36.0"},"device_class":"connectivity","entity_category":"diagnostic","name":"Connection state","object_id":"zigbee2mqtt_bridge_connection_state","origin":{"name":"Zigbee2MQTT","sw":"1.36.0","url":"https://www.zigbee2mqtt.io"},"payload_off":"offline","payload_on":"online","state_topic":"zigbee2mqtt/bridge/state","unique_id":"bridge_0xb0c7defffe5ca734_connection_state_zigbee2mqtt","value_template":"{{ value_json.state }}"}'
Zigbee2MQTT:info 2024-03-25 11:48:32: MQTT publish: topic 'homeassistant/binary_sensor/1221051039810110150109113116116_0xb0c7defffe5ca734/restart_required/config', payload '{"availability":[{"topic":"zigbee2mqtt/bridge/state","value_template":"{{ value_json.state }}"}],"availability_mode":"all","device":{"hw_version":"EZSP v7 6.5.5.0 build 432","identifiers":["zigbee2mqtt_bridge_0xb0c7defffe5ca734"],"manufacturer":"Zigbee2MQTT","model":"Bridge","name":"Zigbee2MQTT Bridge","sw_version":"1.36.0"},"device_class":"problem","enabled_by_default":false,"entity_category":"diagnostic","name":"Restart required","object_id":"zigbee2mqtt_bridge_restart_required","origin":{"name":"Zigbee2MQTT","sw":"1.36.0","url":"https://www.zigbee2mqtt.io"},"payload_off":false,"payload_on":true,"state_topic":"zigbee2mqtt/bridge/info","unique_id":"bridge_0xb0c7defffe5ca734_restart_required_zigbee2mqtt","value_template":"{{ value_json.restart_required }}"}'
Zigbee2MQTT:info 2024-03-25 11:48:32: MQTT publish: topic 'homeassistant/button/1221051039810110150109113116116_0xb0c7defffe5ca734/restart/config', payload '{"availability":[{"topic":"zigbee2mqtt/bridge/state","value_template":"{{ value_json.state }}"}],"availability_mode":"all","command_topic":"zigbee2mqtt/bridge/request/restart","device":{"hw_version":"EZSP v7 6.5.5.0 build 432","identifiers":["zigbee2mqtt_bridge_0xb0c7defffe5ca734"],"manufacturer":"Zigbee2MQTT","model":"Bridge","name":"Zigbee2MQTT Bridge","sw_version":"1.36.0"},"device_class":"restart","name":"Restart","object_id":"zigbee2mqtt_bridge_restart","origin":{"name":"Zigbee2MQTT","sw":"1.36.0","url":"https://www.zigbee2mqtt.io"},"payload_press":"","unique_id":"bridge_0xb0c7defffe5ca734_restart_zigbee2mqtt"}'
Zigbee2MQTT:info 2024-03-25 11:48:32: MQTT publish: topic 'homeassistant/select/1221051039810110150109113116116_0xb0c7defffe5ca734/log_level/config', payload '{"availability":[{"topic":"zigbee2mqtt/bridge/state","value_template":"{{ value_json.state }}"}],"availability_mode":"all","command_template":"{\"options\": {\"advanced\": {\"log_level\": \"{{ value }}\" } } }","command_topic":"zigbee2mqtt/bridge/request/options","device":{"hw_version":"EZSP v7 6.5.5.0 build 432","identifiers":["zigbee2mqtt_bridge_0xb0c7defffe5ca734"],"manufacturer":"Zigbee2MQTT","model":"Bridge","name":"Zigbee2MQTT Bridge","sw_version":"1.36.0"},"entity_category":"config","name":"Log level","object_id":"zigbee2mqtt_bridge_log_level","options":["info","warn","error","debug"],"origin":{"name":"Zigbee2MQTT","sw":"1.36.0","url":"https://www.zigbee2mqtt.io"},"state_topic":"zigbee2mqtt/bridge/info","unique_id":"bridge_0xb0c7defffe5ca734_log_level_zigbee2mqtt","value_template":"{{ value_json.log_level | lower }}"}'
Zigbee2MQTT:info 2024-03-25 11:48:32: MQTT publish: topic 'homeassistant/sensor/1221051039810110150109113116116_0xb0c7defffe5ca734/version/config', payload '{"availability":[{"topic":"zigbee2mqtt/bridge/state","value_template":"{{ value_json.state }}"}],"availability_mode":"all","device":{"hw_version":"EZSP v7 6.5.5.0 build 432","identifiers":["zigbee2mqtt_bridge_0xb0c7defffe5ca734"],"manufacturer":"Zigbee2MQTT","model":"Bridge","name":"Zigbee2MQTT Bridge","sw_version":"1.36.0"},"entity_category":"diagnostic","icon":"mdi:zigbee","name":"Version","object_id":"zigbee2mqtt_bridge_version","origin":{"name":"Zigbee2MQTT","sw":"1.36.0","url":"https://www.zigbee2mqtt.io"},"state_topic":"zigbee2mqtt/bridge/info","unique_id":"bridge_0xb0c7defffe5ca734_version_zigbee2mqtt","value_template":"{{ value_json.version }}"}'
Zigbee2MQTT:info 2024-03-25 11:48:32: MQTT publish: topic 'homeassistant/sensor/1221051039810110150109113116116_0xb0c7defffe5ca734/coordinator_version/config', payload '{"availability":[{"topic":"zigbee2mqtt/bridge/state","value_template":"{{ value_json.state }}"}],"availability_mode":"all","device":{"hw_version":"EZSP v7 6.5.5.0 build 432","identifiers":["zigbee2mqtt_bridge_0xb0c7defffe5ca734"],"manufacturer":"Zigbee2MQTT","model":"Bridge","name":"Zigbee2MQTT Bridge","sw_version":"1.36.0"},"enabled_by_default":false,"entity_category":"diagnostic","icon":"mdi:chip","name":"Coordinator version","object_id":"zigbee2mqtt_bridge_coordinator_version","origin":{"name":"Zigbee2MQTT","sw":"1.36.0","url":"https://www.zigbee2mqtt.io"},"state_topic":"zigbee2mqtt/bridge/info","unique_id":"bridge_0xb0c7defffe5ca734_coordinator_version_zigbee2mqtt","value_template":"{{ value_json.coordinator.meta.revision }}"}'
Zigbee2MQTT:info 2024-03-25 11:48:32: MQTT publish: topic 'homeassistant/sensor/1221051039810110150109113116116_0xb0c7defffe5ca734/network_map/config', payload '{"availability":[{"topic":"zigbee2mqtt/bridge/state","value_template":"{{ value_json.state }}"}],"availability_mode":"all","device":{"hw_version":"EZSP v7 6.5.5.0 build 432","identifiers":["zigbee2mqtt_bridge_0xb0c7defffe5ca734"],"manufacturer":"Zigbee2MQTT","model":"Bridge","name":"Zigbee2MQTT Bridge","sw_version":"1.36.0"},"enabled_by_default":false,"entity_category":"diagnostic","json_attributes_template":"{{ value_json.data.value | tojson }}","json_attributes_topic":"zigbee2mqtt/bridge/response/networkmap","name":"Network map","object_id":"zigbee2mqtt_bridge_network_map","origin":{"name":"Zigbee2MQTT","sw":"1.36.0","url":"https://www.zigbee2mqtt.io"},"state_topic":"zigbee2mqtt/bridge/response/networkmap","unique_id":"bridge_0xb0c7defffe5ca734_network_map_zigbee2mqtt","value_template":"{{ now().strftime('%Y-%m-%d %H:%M:%S') }}"}'
Zigbee2MQTT:info 2024-03-25 11:48:32: MQTT publish: topic 'homeassistant/sensor/1221051039810110150109113116116_0xb0c7defffe5ca734/permit_join_timeout/config', payload '{"availability":[{"topic":"zigbee2mqtt/bridge/state","value_template":"{{ value_json.state }}"}],"availability_mode":"all","device":{"hw_version":"EZSP v7 6.5.5.0 build 432","identifiers":["zigbee2mqtt_bridge_0xb0c7defffe5ca734"],"manufacturer":"Zigbee2MQTT","model":"Bridge","name":"Zigbee2MQTT Bridge","sw_version":"1.36.0"},"device_class":"duration","entity_category":"diagnostic","name":"Permit join timeout","object_id":"zigbee2mqtt_bridge_permit_join_timeout","origin":{"name":"Zigbee2MQTT","sw":"1.36.0","url":"https://www.zigbee2mqtt.io"},"state_topic":"zigbee2mqtt/bridge/info","unique_id":"bridge_0xb0c7defffe5ca734_permit_join_timeout_zigbee2mqtt","unit_of_measurement":"s","value_template":"{{ iif(value_json.permit_join_timeout is defined, value_json.permit_join_timeout, None) }}"}'
Zigbee2MQTT:info 2024-03-25 11:48:32: MQTT publish: topic 'homeassistant/switch/1221051039810110150109113116116_0xb0c7defffe5ca734/permit_join/config', payload '{"availability":[{"topic":"zigbee2mqtt/bridge/state","value_template":"{{ value_json.state }}"}],"availability_mode":"all","command_topic":"zigbee2mqtt/bridge/request/permit_join","device":{"hw_version":"EZSP v7 6.5.5.0 build 432","identifiers":["zigbee2mqtt_bridge_0xb0c7defffe5ca734"],"manufacturer":"Zigbee2MQTT","model":"Bridge","name":"Zigbee2MQTT Bridge","sw_version":"1.36.0"},"icon":"mdi:human-greeting-proximity","name":"Permit join","object_id":"zigbee2mqtt_bridge_permit_join","origin":{"name":"Zigbee2MQTT","sw":"1.36.0","url":"https://www.zigbee2mqtt.io"},"payload_off":"false","payload_on":"true","state_topic":"zigbee2mqtt/bridge/info","unique_id":"bridge_0xb0c7defffe5ca734_permit_join_zigbee2mqtt","value_template":"{{ value_json.permit_join | lower }}"}'
Zigbee2MQTT:info 2024-03-25 11:48:32: MQTT publish: topic 'zigbee2mqtt/bridge/state', payload '{"state":"online"}'
Zigbee2MQTT:info 2024-03-25 11:48:32: Zigbee2MQTT started!
So finally i have a working gateway (needs to be checked stability and everything ).tion I would like to swith back to Arduino SDK because in that way will be really easy to implement other useful things...
What i would like to add is: 1) Smart WiFi configuration (maybe via http web server) 2) Use the native push button to implement some kind of reboot (short press) and factory reset(long press) 3) Improve stabiity with some kind of watchdog on the UART and socket 3) Upgrade Z3SL Firmware
I'll try to upload procedures, dumps and code in a separate repo in short time ( maybe next week) THANK YOU!!! Luca
Is the "boot pin" connected to the Zigbee modules reset pin / pad ? It was looking like they is using the same pin / pads for other com so they is "muting" the module so its not getting strange commands then the main module is booting sound logic for my and its not bad done.
Thank you very much @MattWestb ! Nope is not RST.. My multimeter says it is this:
Which seems strange 🤔 Indeed seems a good design disable during WiFi module boot-up . Thanks, Luca
Then tuya have putting some extra code in the NCP firmware for muting the com to and from the Zigbee module but i think its little strange using the ADC pin then some normal GPIO is free (Silab have also logic for hardware coexistence with WiFi chip that supporting it and is using normal GPIOs) but its not in the standard firmware.
Is the code for this available somewere?
Hello, First of all i would like to say thank you for your commitment and effort on this! I recently bought Tuya Smart Gateway model GW-018 (wifi + ble + zigbee) (https://a.aliexpress.com/_EjwjehJ) My hope is to use it as "open" zigbee Gateway bridge detaching it from Tuya Cloud. From PCB I see the well known ZS3L plus wifi+ble on separate WBRG1.
Do you have any suggestion? Do you think something feasible? Thanks! Luca