Elektroda.com
Elektroda.com
X
Elektroda.com

Daybetter 800 Lumens 120V 9W RGB+2700-6500K bulbs (BK7231N/CB2L/BP5758D)

dwildstr 981 9
  • These bulbs are dirt cheap Tuya bulbs (I get them in a 12-pack off of Amazon for between $4 and $5 per bulb, a very reasonable price for bright RGBCW bulbs), and I discovered to my delight that they're OTA flashable using the tuya-cloudcutter exploit. I'll start with notes about the various configurations I used for tuya-cloudcutter and OpenBeken, and then move on to the hardware teardown.

    In tuya-cloudcutter, the device profile "Tuya-Generic/E27-RGBCW-Smart-Life-WB2L_M1" works fantastically. The chipset is BK7231N; flash an OpenBeken firmware designed for that chipset. In OpenBeken, the necessary module setup is to make P7 BP5758D_CLK, and P8 BP5758D_DAT. Additionally the channels needed remapping, so I added in the startup command "BP5758D_Map 2 1 0 4 5". This information is enough to get these bulbs nicely out of the Tuya dungeon and working great on open-source local-control firmware without having to do any hardware surgery.

    Over on an OpenBeken issue I opened, they recommended I post a teardown of this hitherto unknown device, and I had one bricked bulb (onto which I had carelessly flashed a BK7231T firmware) and another I had taken the dome off of and expected to sacrifice. First, some pictures of completely unaltered bulbs:
    Daybetter 800 Lumens 120V 9W RGB+2700-6500K bulbs (BK7231N/CB2L/BP5758D)Daybetter 800 Lumens 120V 9W RGB+2700-6500K bulbs (BK7231N/CB2L/BP5758D)
    They don't really have any model name or number beyond the extensive descriptive text on the bulbs. The translucent dome is glued on and comes off with a bit of heavy-duty twisting and squeezing. Once removed, the light PCB and the tip of the MCU PCB are visible, as is usually the case:
    Daybetter 800 Lumens 120V 9W RGB+2700-6500K bulbs (BK7231N/CB2L/BP5758D)
    This board has 15 warm-white LEDs, 10 cool-white LEDs, and 3 LEDs in each of red, blue, and green. The most significant other components are that IC which is identified by the silkscreen as a BP5758, and a four-pin connector which transmits data and power from the MCU PCB (note that this differs from a lot of bulb teardowns --- 6-pin connectors are much more common!). Based on closer inspection later, I believe the pin closest to the BP5758 (the one on the upper left in the picture above) carries the BP5758 clock signal, the one close to both the BP5758 and the surface-mount resistor (upper right) carries 120V DC power, the one closest to the MCU cutout (lower left) is BP5758 data, and the one close to the cluster of resistors (lower right) is ground. At one point I was trying to determine which pins carried voltage and how much and accidentally shorted out the 120V and ground pins. This killed the bulb and the physical damage is visible in a later photo.



    This board's schematic seems to be extremely close to one found in a Chinese-language report from a expo showing off Tuya bulbs which served as Bluetooth beacons.
    Daybetter 800 Lumens 120V 9W RGB+2700-6500K bulbs (BK7231N/CB2L/BP5758D)

    Disassembling the bulb further required taking off a lot of glue. The light PCB was glued down around the edges, and there was also an enormous glob of glue holding the MCU onto the LED PCB (seen in the photo above. The large glue-glob was easy to cut, and the glue around the edges succumbed to light but consistent upwards prying around the edges of the light board. Removal of this PCB allowed a glimpse of the interior:
    Daybetter 800 Lumens 120V 9W RGB+2700-6500K bulbs (BK7231N/CB2L/BP5758D)
    This board gets a better picture after the physical destruction of the bulb base. It was, as expected, connected to the Edison screw for power by two wires, one of which was an unsoldered contact with the screw wall; the other was soldered onto the button at the bottom. The plastic around the base of the screw was cut until it was possible to take the screw base and the PCB out, whereupon the full PCB, along with its connections to the Edison base, could be photographed.
    Daybetter 800 Lumens 120V 9W RGB+2700-6500K bulbs (BK7231N/CB2L/BP5758D) Daybetter 800 Lumens 120V 9W RGB+2700-6500K bulbs (BK7231N/CB2L/BP5758D)
    Most of what is on here appears to be power-supply stuff. The 4-pin IC on the narrow end is a rectifier with, as far as I can tell, no silkscreen. The 4-pin IC in the wider section is labeled as a KP35026, which seems to be a 3.3V power-supply. The scorch mark directly below the left side of the ICU shows where my careless short seems to have caused a SMD resistor to explode.

    The MCU itself is labeled as a CB2L, which is a pretty standard Tuya Wifi unit built around a BK7231N chipset. As far as I can tell, pins P6, P26, and P24 are not used at all; P7 and P8 have traces to the LED-board connection.

    AFAICT, this is mostly a pretty ordinary 5-channel bulb using a BP5758 for current control. It has the exact same configuration as a Nous P3, and as far as I can tell most of the same hardware although the physical layout on the PCB is a bit different.

    Cool? Ranking DIY
    About Author
    dwildstr
    Level 2  
    Offline 
    dwildstr wrote 2 posts with rating 4, helped 0 times. Been with us since 2022 year.
  • #2
    p.kaczmarek2
    Level 28  
    Thanks for the teardown. I see you also noticed it's similarity to Nous P3. I wonder if that Tuya-cloudcutter profile would work for P3 as well. I didn't test that, as my default routine is always to use wires and provide next flash dump for cloudcutting analysis.

    BP5758 is a nice little chip. Those 4 gold pins routed out of the main board to LEDs board looks strange, without BP5758 (or similar driver) it would not be possible to control 5 sets of simple LEDs with 4 pins.

    I've attached BP5758 datasheet.

    EDIT:
    Quote:

    I had one bricked bulb (onto which I had carelessly flashed a BK7231T firmware)

    have you managed to recover that?
  • #3
    dwildstr
    Level 2  
    Quote:
    Quote:
    I had one bricked bulb (onto which I had carelessly flashed a BK7231T firmware)

    have you managed to recover that?


    Nope. I figure it's probably doable by desoldering the BK7231N chip, hooking it up to a USB-UART adapter, and flashing firmware the good old bare-metal way, but I'm not really much of a hardware person and these things only cost $4 so I'm prepared to write it off rather than try to bring it back to life. The not-being-a-hardware-person is also why I didn't try to recover the stock firmware from an unmodified bulb --- since a generic profile works with cloudcutter, it didn't seem very urgent to get a new profile for this bulb.
  • #4
    leonbotha69
    Level 3  
    Hi dwildstr

    I have a similar bulb - "BNETA" brand - that has the same layout and also use the CB2L chipset.
    I have not been able to successfully get tuya-cloudcutter to work.

    I only have a RPI 3B to run linux on.
    I followed the instructions as per - HOST_SPECIFIC_INSTRUCTIONS.md, but i am not getting anywhere.
    Any pointers will be welcome.

    Z
  • #5
    p.kaczmarek2
    Level 28  
    @leonbotha69 I used Tuya-cloudcutter once and it worked well. Can you be more specific where is your issue?

    For the record, I used it with Ubuntu virtual machine ran on windows and external wiFi USB dongle (that is capable of creating AP).
  • #6
    leonbotha69
    Level 3  
    Hi p.kaczmarek2
    I place the bulb in "AP" mode - fast flashing, but tuya-cloudcutter never see the bulb.
    My android phone with the Tuya Smart app detects the bulb every time.
    I tried to set the bulb via Bluetooth to accept the cloudcutterflash AP, but i get a message that the wifi AP could not be found

    I have tried:
    1. RPI as per the instructions
    2. Win 10 with virtual ubuntu did not see my desktop wifi adaptor, so that was a bust.
    3. Ubuntu on a laptop as per instructions

    Bulb is not detected
  • #7
    leonbotha69
    Level 3  
    Hi p.kaczmarek2

    Just some update.

    I made some progress - reimaged my RPI and it can now see the cloudcutter AP and cloudcutter is detecting my bulb - "SmartLife-7EC4"
    I have not managed to "cut" it as i am getting: SSL Error on 12 ('10.42.42.24', 62644): [SSL: DECRYPTION_FAILED_OR_BAD_RECORD_MAC] decryption failed or bad record mac (_ssl.c:1129)

    I presume that it is then not 100% the same profile as the one in this tread.
    Let me see on the weekend if i can sacrifice one to do a code dump.

    Below is some more info from cloudcutter -

    Scanning for "A-" "Geeni-" "GRID-" "iHome-" "LDV SMART+-" "Merkury-" "Nexxt Home-" "SL-CreeLighting-" "SL-FLSNT-" "SmartLife-" "TreatLife-SL-" SSID...
    Scanning for "A-" "Geeni-" "GRID-" "iHome-" "LDV SMART+-" "Merkury-" "Nexxt Home-" "SL-CreeLighting-" "SL-FLSNT-" "SmartLife-" "TreatLife-SL-" SSID...
    Found access point name: "SmartLife-7EC4", trying to connect..
    Device 'wlan0' successfully activated with '0acdc3d3-55cc-4935-9c31-dcaa4eeda72a'.
    Connected to access point.
    Configured device to connect to 'cloudcutterflash'
    Device is connecting to 'cloudcutterflash' access point. Passphrase for the AP is 'abcdabcd' (without ')
    Cutting device off from cloud..
    ==> Wait for 20-30 seconds for the device to connect to 'cloudcutterflash'. This script will then show the activation requests sent by the device, and tell you whether local activation was successful.
    Using WLAN adapter: wlan0
    Oct 18 14:09:38 dnsmasq[15]: started, version 2.80 cachesize 150
    Oct 18 14:09:38 dnsmasq[15]: compile time options: IPv6 GNU-getopt DBus i18n IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset auth DNSSEC loop-detect inotify dumpfile
    Oct 18 14:09:38 dnsmasq-dhcp[15]: DHCP, IP range 10.42.42.10 -- 10.42.42.40, lease time 12h
    Oct 18 14:09:38 dnsmasq-dhcp[15]: DHCP, sockets bound exclusively to interface wlan0
    Oct 18 14:09:38 dnsmasq[15]: read /etc/hosts - 5 addresses
    Configuration file: /dev/stdin
    wlan0: Could not connect to kernel driver
    Using interface wlan0 with hwaddr b8:27:eb:1d:65:34 and ssid "cloudcutterflash"
    wlan0: interface state UNINITIALIZED->ENABLED
    wlan0: AP-ENABLED
    Oct 18 14:09:44 dnsmasq-dhcp[15]: 842012285 available DHCP range: 10.42.42.10 -- 10.42.42.40
    Oct 18 14:09:44 dnsmasq-dhcp[15]: 842012285 client provides name: wlan0
    Oct 18 14:09:47 dnsmasq-dhcp[15]: 842012285 DHCPDISCOVER(wlan0) a0:92:08:3e:7e:c4
    Oct 18 14:09:47 dnsmasq-dhcp[15]: 842012285 tags: wlan0
    Oct 18 14:09:47 dnsmasq-dhcp[15]: 842012285 DHCPOFFER(wlan0) 10.42.42.24 a0:92:08:3e:7e:c4
    Oct 18 14:09:47 dnsmasq-dhcp[15]: 842012285 requested options: 1:netmask, 3:router, 28:broadcast, 6:dns-server
    Oct 18 14:09:47 dnsmasq-dhcp[15]: 842012285 next server: 10.42.42.1
    Oct 18 14:09:47 dnsmasq-dhcp[15]: 842012285 sent size: 1 option: 53 message-type 2
    Oct 18 14:09:47 dnsmasq-dhcp[15]: 842012285 sent size: 4 option: 54 server-identifier 10.42.42.1
    Oct 18 14:09:47 dnsmasq-dhcp[15]: 842012285 sent size: 4 option: 51 lease-time 12h
    Oct 18 14:09:47 dnsmasq-dhcp[15]: 842012285 sent size: 4 option: 58 T1 6h
    Oct 18 14:09:47 dnsmasq-dhcp[15]: 842012285 sent size: 4 option: 59 T2 10h30m
    Oct 18 14:09:47 dnsmasq-dhcp[15]: 842012285 sent size: 4 option: 1 netmask 255.255.255.0
    Oct 18 14:09:47 dnsmasq-dhcp[15]: 842012285 sent size: 4 option: 28 broadcast 10.42.42.255
    Oct 18 14:09:47 dnsmasq-dhcp[15]: 842012285 sent size: 4 option: 3 router 10.42.42.1
    Oct 18 14:09:47 dnsmasq-dhcp[15]: 842012285 sent size: 4 option: 6 dns-server 10.42.42.1
    Oct 18 14:09:47 dnsmasq-dhcp[15]: 842012285 available DHCP range: 10.42.42.10 -- 10.42.42.40
    Oct 18 14:09:47 dnsmasq-dhcp[15]: 842012285 client provides name: wlan0
    Oct 18 14:09:47 dnsmasq-dhcp[15]: 842012285 DHCPDISCOVER(wlan0) a0:92:08:3e:7e:c4
    Oct 18 14:09:47 dnsmasq-dhcp[15]: 842012285 tags: wlan0
    Oct 18 14:09:47 dnsmasq-dhcp[15]: 842012285 DHCPOFFER(wlan0) 10.42.42.24 a0:92:08:3e:7e:c4
    Oct 18 14:09:47 dnsmasq-dhcp[15]: 842012285 requested options: 1:netmask, 3:router, 28:broadcast, 6:dns-server
    Oct 18 14:09:47 dnsmasq-dhcp[15]: 842012285 next server: 10.42.42.1
    Oct 18 14:09:47 dnsmasq-dhcp[15]: 842012285 sent size: 1 option: 53 message-type 2
    Oct 18 14:09:47 dnsmasq-dhcp[15]: 842012285 sent size: 4 option: 54 server-identifier 10.42.42.1
    Oct 18 14:09:47 dnsmasq-dhcp[15]: 842012285 sent size: 4 option: 51 lease-time 12h
    Oct 18 14:09:47 dnsmasq-dhcp[15]: 842012285 sent size: 4 option: 58 T1 6h
    Oct 18 14:09:47 dnsmasq-dhcp[15]: 842012285 sent size: 4 option: 59 T2 10h30m
    Oct 18 14:09:47 dnsmasq-dhcp[15]: 842012285 sent size: 4 option: 1 netmask 255.255.255.0
    Oct 18 14:09:47 dnsmasq-dhcp[15]: 842012285 sent size: 4 option: 28 broadcast 10.42.42.255
    Oct 18 14:09:47 dnsmasq-dhcp[15]: 842012285 sent size: 4 option: 3 router 10.42.42.1
    Oct 18 14:09:47 dnsmasq-dhcp[15]: 842012285 sent size: 4 option: 6 dns-server 10.42.42.1
    Oct 18 14:09:47 dnsmasq-dhcp[15]: 842012285 available DHCP range: 10.42.42.10 -- 10.42.42.40
    Oct 18 14:09:47 dnsmasq-dhcp[15]: 842012285 client provides name: wlan0
    Oct 18 14:09:47 dnsmasq-dhcp[15]: 842012285 DHCPREQUEST(wlan0) 10.42.42.24 a0:92:08:3e:7e:c4
    Oct 18 14:09:47 dnsmasq-dhcp[15]: 842012285 tags: wlan0
    Oct 18 14:09:47 dnsmasq-dhcp[15]: 842012285 DHCPACK(wlan0) 10.42.42.24 a0:92:08:3e:7e:c4 wlan0
    Oct 18 14:09:47 dnsmasq-dhcp[15]: 842012285 requested options: 1:netmask, 3:router, 28:broadcast, 6:dns-server
    Oct 18 14:09:47 dnsmasq-dhcp[15]: 842012285 next server: 10.42.42.1
    Oct 18 14:09:47 dnsmasq-dhcp[15]: 842012285 sent size: 1 option: 53 message-type 5
    Oct 18 14:09:47 dnsmasq-dhcp[15]: 842012285 sent size: 4 option: 54 server-identifier 10.42.42.1
    Oct 18 14:09:47 dnsmasq-dhcp[15]: 842012285 sent size: 4 option: 51 lease-time 12h
    Oct 18 14:09:47 dnsmasq-dhcp[15]: 842012285 sent size: 4 option: 58 T1 6h
    Oct 18 14:09:47 dnsmasq-dhcp[15]: 842012285 sent size: 4 option: 59 T2 10h30m
    Oct 18 14:09:47 dnsmasq-dhcp[15]: 842012285 sent size: 4 option: 1 netmask 255.255.255.0
    Oct 18 14:09:47 dnsmasq-dhcp[15]: 842012285 sent size: 4 option: 28 broadcast 10.42.42.255
    Oct 18 14:09:47 dnsmasq-dhcp[15]: 842012285 sent size: 4 option: 3 router 10.42.42.1
    Oct 18 14:09:47 dnsmasq-dhcp[15]: 842012285 sent size: 4 option: 6 dns-server 10.42.42.1
    Oct 18 14:10:05 dnsmasq[15]: query[A] h3.iot-dns.com from 10.42.42.24
    Oct 18 14:10:05 dnsmasq[15]: config h3.iot-dns.com is 10.42.42.1
    Using PSK v1 - Received PSK ID version 02
    [W 221018 14:10:05 iostream:1406] SSL Error on 12 ('10.42.42.24', 62644): [SSL: DECRYPTION_FAILED_OR_BAD_RECORD_MAC] decryption failed or bad record mac (_ssl.c:1129)
    Using PSK v1 - Received PSK ID version 02
  • #8
    p.kaczmarek2
    Level 28  
    Please pair your device with a preferrably dummy SSID before doing full 2MB flash dump. Remember that SSID data is stored in this dump, so people would be able to find out your WiFi pass. Doing paired dump is better because then it consists XML schema of the device that is, as far as I know, downloaded at the time of pairing.
  • #9
    leonbotha69
    Level 3  
    Hi p.kaczmarek2

    Yes, i shall use an old Linksys router i have that is not in use to do the dump.

    Regards
    Z