@davidcpurdy I have added a flag to select UART
I didn't built it for BL602 yet, maybe I will have time to check this tomorrow, but in case of /dev/ttyS0, it certainly works (but you need to disable logger to UART), in case of /dev/ttyS1 I haven't tested yet.
It assumes that this setting is build, but I also haven't checked that:
Do you happen to know where is the dts file for current build selected?
I am asking because I also see files like bl_factory_params_evb_38.4M.dts with:
@p.kaczmarek2 sorry to pester but any chance you could help with this?
leifmjcb wrote:
Hi all, Happy new year!
As my new years resolution, I've decided to stop pulling my hair out over these BL602 MagicHome LED controllers and come here for some help.
I've flashed 6 of these now originally with 1.15.149 and today with 1.15.273.
The config, operation, wifi & MQTT all seem to be working fine. I have no errors in logs.
However I cant for the life of me get discovery to work. The only way I can connect via HA is by manually adding via YAML conf. But when I do this only an entity appears, no device.
I am still learning HA and MQTT but I'm only having this problem with BL602, I've got many ESP and BK7231T devices working fine and with discovery.
I will try to find more time and check this on BL602 dev board.
No rush, no worries... It looks like you are making progress... I can see the configuration option :
Good work!
I note that I can read/write to UART0 it seems.
With S0 or UART0, if I turn on the driver for CSE7766 then booting + connecting via WiFi takes a long time... and it seems unstable, even with logging turned off. But if I check the Config box and enable S1/UART1, then wifi connects almost instantly.
I can't see any voltage readings ( Zed/zero/ 0.0), but I guess that part still has to be worked on.
I do not know the answer to your question about ...
p.kaczmarek2 wrote:
Do you happen to know where is the dts file for current build selected?
I am asking because I also see files like bl_factory_params_evb_38.4M.dts with:
Code: uart@40010100 {
status = "okay";
id = <1>;
compatible = "bl60x_uart";
path = "/dev/ttyS1";
reg = <0x40010100 0x100>;
baudrate = <9600>;
pin {
rx = <18>;
tx = <20>;
};
feature {
rts = "disable";
cts = "disable";
rx = "okay";
tx = "okay";
};
};
??? No idea on this.
If you think of a way for me to check on my device, then I'll try my best to do that.
Tried flashing a RGB Magic Home led controller which has a BL602 chip.
I was not able to find the software version 1.48 of BLDevCube so had to use the latest (1.81) one that is on their website.
The flashing happened as expected.
Here are some screen shots:
[/img]
I tried using the OpenBL602_1.15.275.bin which resulted in an OpenBeken hotspot but I am unable to connect to it (even after putting a stic IP of 192.168.4.x range)
Hello @timaseth, I am not aware about any changes that could break BL602 in those releases, but let me check... let's say OpenBL602_1.15.281.bin version
It seems to work?
And AP...
Ah, now I see what you mean.
The IP is 192.168.169.1, not 4.1, we must look into changing it soon.
I tried once more to connect to the AP using fixed IP of 192.168.169.99 but failed to do so.
Perhaps the software is creating some issues?
Do you have a link from where I can download the same exe of DevCube which you are using? Many thanks for your help.
Added after 17 [minutes]:
Yipee!!!
I downloaded the entire zip from Github and achieved 100% result.
It works using 192.168.169.1 as the webpage!
I apologize for that IP mess, it seems that there was some trouble with setting 192.168.4.1 as a default IP. I must look into it, but it's hard while there are so few BL602 devices and so many BK7231....
If you have a BL602 device and you are reading this topic, please post here! I need to know how many of you guys with BL's are there!
@davidcpurdy S0 or UART0 is used for log output. You can disable it with "logtype none" in short startup command. But you don't need that, you have your CSE chip on S1/UART1, right?
Can you connect UART to USB converter to S1 TX and then start CSE driver and maybe try "uartSendASCII Test123" command and see if anything is being sent out of EXPECTED TX pin?
That's a strange error, I have never seen it before.
At first, can you try downloading compiled GPIO demo from their SDK, here:
https://www.elektroda.com/rtvforum/topic3889041-90.html#20117857 and checking if at least it works on your device? It has an UART console to control pins. Try commands from the first post from this topic, gpio-func, gpio-set, etc...
Hi,
First things first, thanks to you and everyone else for all of the work on this project, it looks really neat. Secondly I'm seeing the same behavior the previous user was, but I'm seeing it on a magic home RGB variation almost identical to the device in the original post.
theugster wrote:
The error(s) it appears to throw in the console are:
[0m: bl_romfs.c: 146] romfs magic is NOT correct
On my unit I can run the demo gpio firmware provided, I can toggle each of the RGB channels high and see the result at the pin. The order seems to match your unit as well (GPIO3/GPIO4/GPIO21). I've tried OpenBL602_1.15.291.bin along with a fresh build of the main repo and they both result in the same behavior.
Console output from my device (after going back to 1.15.291 after the gpio test):
You can get the latest version on https://github.com/armink/EasyFlash .
[ 28][[1B][32mINFO [1B][0m: hal_uart.c: 364] uart[0] rx_buf_size 512, tx_buf_size 512
[ 29][[1B][32mINFO [1B][0m: hal_uart.c: 379] uart[0] cts status = disable lentmp = 7
[ 30][[1B][32mINFO [1B][0m: hal_uart.c: 379] uart[0] rts status = disable lentmp = 7
[ 30][[1B][32mINFO [1B][0m: hal_uart.c: 402] id = 0, tx = 16, rx = 7, cts = 255, rts = 255 baudrate = 2000000.
[ 31][[1B][32mINFO [1B][0m: hal_uart.c: 410] bl_uart_init 0 ok.
[ 32][[1B][32mINFO [1B][0m: hal_uart.c: 411] bl_uart_init 0 baudrate = 2000000 ok.
[ 33][[1B][32mINFO [1B][0m: hal_uart.c: 364] uart1] rx_buf_size 512, tx_buf_size 512
[ 34][[1B][32mINFO [1B][0m: hal_uart.c: 379] uart[1] cts status = disable lentmp = 7
[ 35][[1B][32mINFO [1B][0m: hal_uart.c: 379] uart[1] rts status = disable lentmp = 7
[ 35][[1B][32INFO [1B][0m: hal_uart.c: 402] id = 1, tx = 4, rx = 3, cts = 255, rts = 255 baudrate = 115200.
[ 36][[1B][32mINFO [1B][0m: hal_uart.c: 410] bl_uart_init 1 ok.
[ 36][[1B][32mINFO [1B][0m: hal_uart.c: 411] bl_uart_init 1 baudrate = 115200 ok.
[ 37][[1B][32mINFO [1B][0m: hal_gpio.c: 202] [HAL] [GPIO] Max num is 40
[ 38][[1B][32mINFO [1B][0m: hal_gpio.c: 177] New CONF: GPIO05: feature 0, active 1, mode 0, time 100
[ 39][[1B][32mINFO [1B][0m: loopset_led.c: 75] [LED] New Trigger: PIN 5, active level Lo, type Blink
[ 39][[1B][32mINFO [1B][0m: hal_gpio.c: 115] [gpio1] status = disable
[ 40][[1B][31mERROR [1B][0m: hal_gpio.c: 216] gpio1: unvalid GPIO config
[ 41][[1B][31mERROR [1B][0m: hal_gpio.c: 130] gpio2: unvalid GPIO config button
[ 41][[1B][31mERROR [1B][0m: hal_gpio.c: 216] gpio2: unvalid GPIO config
[ 42][[1B][32mINFO [1B][0m: hal_gpio.c: 106] gpio3 NOT found
[MTD] >>>>>> Hanlde info Dump >>>>>>
name media
id 0
offset 0x00192000(1646592)
size 0x00057000(348Kbytes)
xip_addr 0x23181000
[MTD] <<<<<< Hanlde info End <<<<<<
[ 43][[1B][31mERROR [1B][0m: bl_romfs.c: 146] romfs magic is NOT correct
Is there anything I can collect that would help in working out whats going on here?
EDIT: for completeness I've tried v1.15.281 as it was confirmed a few posts up to be working fine, still the same issue here though.
Added after 1 [hours] 19 [minutes]:
I'm not great with programming, but I looked at the code and it seems to me its more a hardware thing. I grabbed another new unit out of the bag, soldered it up to see the stock firmware via console, and its doing the same thing.
I had previously used the first unit flashed, but at 24v, a lightbulb moment - checked my 5v PSU and I think it might be bad.
Added after 58 [minutes]:
Well now I'm well and truely confused.
I re-flashed the device, then tried it on the 24v psu, still nothing, infact nothing from console at all anymore? epp did i make a mistake and put 24v where I shouldn't? switched to the other device thinking this one was a goner, flashed with straight to openbl, console stops again, its still responding to flash commands, so back to the gpio demo and its ok, back to openbl and now its fully booting??
wired up the first unit suspected dead, nothing from console, reflashed openbl, working as well?
All I've done is gone round in circles flashing the same mix of firmware, I don't see whats changed. I'll set them up and get them talking on a test network and see if they behave or not.
also many thanks for your great job @p.kaczmarek2 !!!
bought 2 Magic Home Controller a few days ago and flashed one of them with a BL602 succesfully.
the second one has a LF686 ? is it also possible to flash? Flashing ok with BL602, Firmware OpenBL602_1.15.317.bin
Code: Text
Log in, to see the code
what was the exact "Reset Method" for the Controller? 4 Times On/Off? OK, found it! -> It is also possible to reset/safe mode the device by doing 3 or more turn on and off power cycles with running device for less than about 30 seconds (power on, wait 3 sec, power off, etc 3 times). It will enable open access point again and also might disable IO (so don't bother testing GPIO in the safe mode).
do you know about problems with "Fritz Router" 2,4 GHz Wlan Connections? Solved! Only Wlan Security Setting "WPA + WPA2" is working. with all other option you get no connection working.
I've flashed 2 devices Magic Home Led Controller ZJ-BWCE-RGBW V1.0 to BL602,
I was able also to link them both with Home Assistant but only one in a time.
Both can not work together because the MAC address duplication, I am getting the error while trying to change it even in newest build. (OpenBL602_1.15.296)
Is there other way to change the MAC in BL602, but without using development tool and compiling new binary file?
hey guys,
i cant get the mqtt interface to work! server connection runs fine but what is a working example to switch the led controller ON or OFF ? everytime when i send commands like:
obl42A9B04A/led_enableAll/set 0 or 1 nothing happens?
It was a wrong topic, we are trying to use Tasmota syntax.
More updates soon.
@benek194 very good job and thank you for information
@questoculus70 LF686 is under considerations but I don't have that device at hand...
@_Roli_ surprisingly, the Magic Home single colour device is not on templates list - can you share information about it and show your config so we can include it in our database?
https://openbekeniot.github.io/webapp/devicesList.html
@mjleonard you should get at least a console output, even without OpenBL602. Maybe you are missing something, for example, maybe you don't disconnect BOOT pin after flashing and don't reset the chip later?
The firmware won't start itself if you keep device in the boot mode. And you won't get log output.
Hello @p.kaczmarek2 — thanks for putting so much effort and time into this project and helping so many of us out here!
I wanted to report an issue I wasn't able to solve with (possibly?) an unseen variant of a RGB controller, running on the BL602. I brought some photos for others to compare to, maybe you can solve it. Controller is: BL602 L10.
Problem is: I cannot program with 1.4.8 (see error in spoiler below). Does not work.
But, I can program it with BL Dev Cube 1.8.1, but it does not really work after I boot (likely because of the new partition format). When I boot, the bootloader seems to start but then gets stuck (doesn't load your firmware). See the last spoiler all the way down for the boot log I captured via the serial port.
So, to summarize: BL Dev Cube 1.4.8 — no chance to flash, always fails (error in Spoiler below).
BL Dev Cube 1.8.1 — flashes completely, but firmware does not boot correctly.
Here's what I know so far:
- I connect the DL pin to 3.3V on board via 10k resistor during power-on. After programming, I power-cycle without the DL pin connected. If I don't do this, I also can not program even with BF Dev Cube 1.8.1.
- I tried with 230.4k baud (Mac OS), 500k baud (Windows 11), 2M baud (Windows 11), no difference.
- I tried with bfflash (eflash loader works, but for the firmware, it complains that the sha hashes could not be verified). No success.
- I tried with your SDK GPIO demo from this thread, fails to flash with 1.4.8.I can flash it with 1.8.1, and it boots and works (!)
- Every time I try to flash with BLDevCube 1.4.8 (from this thread), the flash process errors out with:
{"ErrorCode": "003D","ErrorMsg":"BFLB FLASH MATCH TYPE FAIL"}
. When I flash with BLDevCube 1.8.1, it flashes okay and I can boot, but the booting process gets stuck (see spoiler at the bottom for serial log)
Is there a chance I accidentally "upgraded" the way the chip stores information/efuses and now it doesn't work with 1.4.8 because that's the old format? Or, in other words, have you ever managed to try and upload with the latest uploader version?
Could I self-compile the BL602 firmware with the new partition format you think?
Do you think they are shipping a new chip and BL Dev Cube 1.4.8 simply does not work anymore?
The official app they're using is called CozyLife. Looked a lot like Tuya, again.
Here is the full programming log on BL DevCube 1.4.8 from this thread (using the 10k resistor between DL and 3.3V on board to boot into flash mode), and an FTDI232 board on 3.3V (jumpered) via USB on Windows 11:
[input_path]
pt_bin_input = "C:\\Users\\roman\\Downloads\\flash_tool2\\flash_tool\\bl602\\partition\\partition_cfg_2M.toml"
boot2_bin_input = "C:\\Users\\roman\\Downloads\\flash_tool2\\flash_tool\\bl602\\builtin_imgs\\blsp_boot2.bin"
cfg2_bin_input = "C:\\Users\\roman\\Desktop\\OpenBL602_1.15.319.bin"
meida_bin_input = ""
romfs_dir_input = ""
mfg_bin_input = ""
img_bin_input = ""
[10:20:19.514] - ========= Interface is Uart =========
[10:20:19.516] - eflash loader bin is eflash_loader_40m.bin
[10:20:19.521] - ========= chip flash id: ef4015 =========
[10:20:19.529] - Update flash cfg finished
[10:20:19.532] - create partition.bin, pt_new is True
[10:20:19.533] - bl60x_fw_boot_head_gen xtal: 40M
[10:20:19.538] - Create bootheader using C:\Users\roman\Downloads\flash_tool2\flash_tool\bl602\efuse_bootheader/efuse_bootheader_cfg.ini
[10:20:19.538] - Updating data according to <C:\Users\roman\Downloads\flash_tool2\flash_tool\bl602\efuse_bootheader/efuse_bootheader_cfg.ini[BOOTHEADER_CFG]>
[10:20:19.541] - Created file len:176
[10:20:19.544] - Create efuse using C:\Users\roman\Downloads\flash_tool2\flash_tool\bl602\efuse_bootheader/efuse_bootheader_cfg.ini
[10:20:19.544] - Updating data according to <C:\Users\roman\Downloads\flash_tool2\flash_tool\bl602\efuse_bootheader/efuse_bootheader_cfg.ini[EFUSE_CFG]>
[10:20:19.547] - Created file len:128
[10:20:19.553] - ========= sp image create =========
[10:20:19.555] - Image hash is b'c5e2ce515a5783ac80efdd4910238a466572f882b53b3284e63c763e1da9847f'
[10:20:19.555] - Header crc: b'52b188af'
[10:20:19.555] - Write flash img
[10:20:19.555] - bl60x_fw_boot_head_gen xtal: 40M
[10:20:19.563] - Create bootheader using C:\Users\roman\Downloads\flash_tool2\flash_tool\bl602\efuse_bootheader/efuse_bootheader_cfg.ini
[10:20:19.563] - Updating data according to <C:\Users\roman\Downloads\flash_tool2\flash_tool\bl602\efuse_bootheader/efuse_bootheader_cfg.ini[BOOTHEADER_CFG]>
[10:20:19.568] - Created file len:176
[10:20:19.570] - Create efuse using C:\Users\roman\Downloads\flash_tool2\flash_tool\bl602\efuse_bootheader/efuse_bootheader_cfg.ini
[10:20:19.572] - Updating data according to <C:\Users\roman\Downloads\flash_tool2\flash_tool\bl602\efuse_bootheader/efuse_bootheader_cfg.ini[EFUSE_CFG]>
[10:20:19.572] - Created file len:128
[10:20:19.576] - ========= sp image create =========
[10:20:19.587] - Image hash is b'3136f3c31a398c12aacbd4426d81fb3b6ae4bbcf1a3c2776802e25ea93f5e06b'
[10:20:19.588] - Header crc: b'd90300fd'
[10:20:19.589] - Write flash img
[10:20:19.599] - FW Header is 176, 3920 still needed
[10:20:19.599] - FW OTA bin header is Done. Len is 4096
[10:20:19.821] - FW OTA bin is Done. Len is 828624
[10:20:20.517] - FW OTA xz is Done
[10:20:20.517] - ========= eflash loader config =========
[10:20:20.591] - =========C:\Users\roman\Downloads\flash_tool2\flash_tool\bl602\device_tree/bl_factory_params_IoTKitA_40M.dts ——> bl602/device_tree/ro_params.dtb=========
[10:20:20.780] - Version: bflb_eflash_loader_v2.0.0
[10:20:20.780] - Program Start
[10:20:20.780] - ========= eflash loader cmd arguments =========
chipname : None
chipid : False
usage : False
flash : True
efuse : False
write : True
erase : False
read : False
none : False
port : COM6
baudrate : None
config : None
interface : None
xtal : None
start : None
end : None
addr : None
mac : None
file : None
data : None
mass : None
loadstr : None
loadfile : None
userarea : None
csvfile : None
csvaddr : None
para : None
aeskey : None
aesiv : None
key : None
ecdh : False
echo : False
auto : False
version : False
[10:20:20.831] - Config file: C:\Users\roman\Downloads\flash_tool2\flash_tool\bl602\eflash_loader/eflash_loader_cfg.ini
[10:20:20.832] - serial port is COM6
[10:20:20.834] - chiptype: bl602
[10:20:20.834] - ========= Interface is Uart =========
[10:20:20.834] - com speed: 2000000
[10:20:20.834] - Eflash load helper file: C:\Users\roman\Downloads\flash_tool2\flash_tool\bl602\eflash_loader/eflash_loader_40m.bin
[10:20:20.834] - Eflash load helper file: C:\Users\roman\Downloads\flash_tool2\flash_tool\bl602\eflash_loader/eflash_loader_40m.bin
[10:20:20.834] - ========= load eflash_loader.bin =========
[10:20:20.834] - Load eflash_loader.bin via uart
[10:20:20.834] - ========= image load =========
[10:20:21.112] - tx rx and power off, press the machine!
[10:20:21.113] - cutoff time is 0.1
[10:20:21.223] - power on tx and rx
[10:20:22.037] - reset cnt: 0, reset hold: 0.005, shake hand delay: 0.1
[10:20:22.037] - clean buf
[10:20:22.149] - send sync
[10:20:22.370] - ack is b'4f4b'
[10:20:22.416] - shake hand success
[10:20:22.432] - get_boot_info
[10:20:22.439] - data read is b'0100000000000000030000005121b14cb97c1a00'
[10:20:22.439] - sign is 0 encrypt is 0
[10:20:22.453] - segcnt is 1
[10:20:22.487] - segdata_len is 30192
[10:20:22.578] - 4080/30192
[10:20:22.669] - 8160/30192
[10:20:22.770] - 12240/30192
[10:20:22.862] - 16320/30192
[10:20:22.958] - 20400/30192
[10:20:23.055] - 24480/30192
[10:20:23.150] - 28560/30192
[10:20:23.198] - 30192/30192
[10:20:23.216] - Run img
[10:20:23.341] - Load helper bin time cost(ms): 2507.72705078125
[10:20:23.452] - ========= flash read jedec ID =========
[10:20:23.452] - Flash load shake hand
[10:20:23.452] - clean buf
[10:20:23.563] - send sync
[10:20:23.785] - ack is b'4f4b'
[10:20:23.843] - Read flash jedec ID
[10:20:23.845] - readdata:
[10:20:23.847] - b'c2201400'
[10:20:23.847] - Finished
[10:20:23.849] - {"ErrorCode": "003D","ErrorMsg":"BFLB FLASH MATCH TYPE FAIL"}
[10:20:23.849] - Burn Retry
[10:20:23.849] - 0
[10:20:23.849] - Burn return with retry fail
This is what the boot process shows if I flash with BL Dev Cube 1.8.1, which I know isn't the one you used/recommended, but it is the ONLY VERSION that produces a serial output after flashing. Unfortunately nothing useful:
------------------------------------------------------
Init CLI with event Driven
help
====Build-in Commands====
====Support 4 cmds once, seperate by ; ====
help : print this
p : print memory
m : modify memory
echo : echo for command
exit : close CLI
devname : print device name
sysver : system version
reboot t file
====User Commands====
gpio-func : gp devname
device name: BL602
I flashed my BL602 with 1.15.342 and it DOESN'T WORK.
The web page is not loading, the LEDs get far too much power and reboots brings it back to AP mode.
But again: the LEDs get far too much power, they get hot ...
I flashed back the 1.15.284 version. That works without flaws.
It seems that Buffalo Lab has a version of chip that is not compatible with older ones, this is why a strange problems with flashing happen. I will look into it later.
Alexa support is a great idea, I'll add it to TODO list.
HA discovery was broken for lights in few releases, but it's fixed now.
Thank you @droege, can you narrow down the issue? Did it broke just in 1.15.342 and 1.15.340 is working, or which one release broke?
EDIT: I looked at my DHT11 humidity/temperature board and it seems that 1.15.342 is fine for me?
I can even set channel label...
obvious and good questions. But as OTA is not there, I have to resolder my programming interface from time to time as I need it also for other devices.
I will report soon on older firmwares. But for logs ... I have no idea how to get them, as I only flash and then the device is connected via wifi. No serial line connection.
What I can tell:
The Web-Site tries to load, as the headline name appears in the browser, but nothing else. So something is alive in there.
And beyond, it seems, that all channels are put to 100%, as it is an RGBW controller, so that may be the overloading, instead of the older firmware, which just turns on one channel for bootup, but then it returns to all zero, as it shoud be.
That's all I can report from now.
It's an RGBW 4 channel LED controller, like others have shown it.
Cheers.
Please do not desolder wires before you make sure that everything work.
You can easily get log from the same port that is used for programming.
The baud setting is 2,000,000. Then you will get text in Realterm.
Please check and post full log, I will also try again today, maybe it's something specific to RGBW or to your config....
If you're saying it's RGBW controller, does it mean that it has set 4 PWM channels? I can simulate that on my dev board.
What if you disconnect LED strip, does the page works okay then?
If I can assist in debugging/figuring out the chip variation (as documented a few posts up here) on the (possible) newer version of the BL620 I have here for this super cheap light strip, then I would love to help. I sit in front of it every evening trying to figure out a solution.
The newer BL Dev Cube 1.8.1 seems to have a slightly modified partition table (firmware starts at the same 0x10000, but seems to be larger now). Only noticed that when comparing the partition toml from 1.8.1 to the version you have here (1.4.8).
I tried using blflash with the latest efloader (read that on GitHub somewhere) in place to see if that maybe does the trick, but it reports constant sha256 mismatches, so that doesn't work.
Programming with 1.8.1 works, but the firmware doesn't boot.
I wonder if I can build your BL602 firmware and somehow use a different partition format? I guess the bin file contains not just the firmware that is placed at 0x10000 but some parts of the boot2 or bootloader stuff, too, and that maybe is in the wrong places?
BL Dev Cube would allow me to flash the firmware at a specific location (like 0x10000), but for that (I think) I would need to have JUST the firmware in the bin to work (unsure).
Would be interesting to see what adjustment it takes for you to successfully flash with 1.8.1 to your dev board. I think if that works, then we could all move up to 1.8.1., regardless of chip version.
Like I said, if you need specific data, I want to help. If you're busy (I am sure you are), no rush. I just have everything connected and ready to debug here and wanted to help.
Due to the larger number of BL602 device reports, OTA has been added to BL602. OTA file is now released here: This is a testing version, but seem to works for me. More coming soon. I will be also adding missing functionality to BL602.
Please tell me what is needed now and if there are any unsupported devices with BLs.
The problems I am aware of so far is:
- Sonoff CSE power metering chip device (but I would need to get that one myself for testing)
- Zain LED driver issues report (but I don't have any devices with LED drivers on BL602...)
- the LED blink on the device during startup (will try to check)
- BL0942 driver works, but BL0937 driver is missing a hardware counter
- new BLs issue (will investigate)
Due to the larger number of BL602 device reports, OTA has been added to BL602.
The chip is soldered directly on the main board, not the module. It is difficult to solder every time.
I already have 6 devices with BL602.
5 pieces were lying and waiting for this hour - to be programmed for the first time, but with the possibility of OTA.
This day has come!!!!!
An anonymous donor (he can speak up if he wants! Thanks!) will provide me a BL602 Sonoff bulb. I still need to get the power metering socket somehow. I may just buy it with further donation funds.
I also fixed that missing version number on BL602 builds.
DHT11 also works with BL602.
Alexa (WEMO) integration is almost ready! I am just waiting for feedback from tester (or can someone else help with testing?)
In a meantime, I fixed some Tasmota emulation stuff and now ioBroker sonoff plugin works as well!
Please see video below (it's taken from OBK Windows Simulator):
ioBroker will of course work with all our platforms, BK7231N, BK7231T, BL602, W800/W801, W600/W601, T34, XR809 (XR3), etc...
The discussion centers on a custom Tasmota-like firmware replacement for the BL602 platform by Bouffalo Lab, enabling integration with Home Assistant via MQTT. Key topics include flashing the firmware using USB to UART converters, SDK compilation, and device pairing. Users report successful flashing on MagicHome LED controllers (RGB, RGBW, single color) and Sonoff devices, with detailed guidance on GPIO pin identification and configuration for PWM and relay functions. MQTT integration supports commands for color, dimmer, hue, saturation, and device control, with ongoing improvements to MQTT topic naming, discovery, and feedback reporting. Challenges addressed include MQTT buffer limitations causing device instability, startup behavior with LED blinking, and the absence of OTA updates for BL602 (unlike Beken platforms). The firmware supports saving and restoring channel states, configurable MQTT reporting flags, and plans for Alexa Hue emulation. Users share troubleshooting steps for flashing errors, network connectivity, and device crashes, with developer responses including bug fixes, feature additions, and testing requests. The project emphasizes open-source collaboration, aiming to free IoT devices from manufacturer servers, enhance privacy, and unify multi-vendor ecosystems under a single firmware solution. Summary generated by the language model.