FEIT Smart WiFi Light Strip - Model: FETAPE/RGBW/CNTRSC - FCC ID: SYW-TAPRGBWCNTRSC - 7231N
This teardown is complete.
I got everything working now (except of course the BLE wireless remote):
It looks like we have to use the native interface instead of the web app for this device since it is RGBW (warm white.)
It appears that it needs flag 24 in order to work correctly.
(Note that the Web App will not show the correct information on the Status screen - but the native interface will.)
There is nothing on pin 24 - but if we don't set it to PWM3, then the HomeAssistant/MQTT definition breaks into 4 separate lights rather than a single RGBW light. (Might be a bug - Flag 24 should probably automatically fix this so we don't have to find an unused pin.) (This is fixed in latest FW update.)
The "smart" button is on pin 26.
The correct pins with flag 24 set are:
This device with 1.0.9 firmware is now listed on CloudCutter as:.
The CloudCutter profile can be found here: https://github.com/tuya-cloudcutter/tuya-clou...files/potek-lst-fw-1.0.9-sdk-2.3.1-40.00.json
I was able to flash it using only the RX1, TX1, GND and CEN test pads on the back of the board without having to desolder or cut any traces.
I was able to power the board with its included 24VDC power supply to talk to the 7231N.
I successfully completed a UART dump using a Raspberry Pi and the uartprogram from https://github.com/OpenBekenIOT/hid_download_py
The dump is zipped and attached to this post with a test SSID and Password on an otherwise freshly reset Tuya Firmware 1.0.9.
I have tested the CloudCutter profile and can confirm it works on an un-modified device.
As a note, this firmware significantly improves the WiFi performance of these light strips. This is consistent across all 5 of the devices I have updated so far - and the comparison is striking. The performance of the updated devices versus their historical performance and the current performance of the 4 remaining devices I have not yet flashed tells an interesting story. This is not anecdotal improvement - I have the historical performance data to prove it. (I have Unifi APs and a UDM Pro, which keeps device performance history.) The FEIT stock firmware is definitely nerfing the WiFi transmit strength. With the stock firmware, a device that's only 4 meters from a Unifi U6LR (Long Range model) shows fair performance, and a AP/Client Signal Balance of 'poor.' After flashing OpenBK, that same device now shows excellent performance and the AP/Client Signal Balance is 'good.' Here is a comparison of one Tuya Stock device and one OpenBK device - right next to each other:
This is consistent across every one of these devices I have flashed. They have all switched to WiFi 4, good signal balance, and higher speed connection. (Note that I have only seen this improvement on this 7231N device. I also have some FEIT 7231T smart plugs and A19 bulbs that did not improve like this.)
Here is the full JSON configuration I am using:
Here are the photos for this device.
Here is a dump of the original 1.0.9 Tuya firmware after attaching to a test network:
I got everything working now (except of course the BLE wireless remote):
It appears that it needs flag 24 in order to work correctly.
The "smart" button is on pin 26.
The correct pins with flag 24 set are:
"pins": {
"6": "PWM;4",
"7": "PWM;2",
"8": "PWM;1",
"9": "PWM;0",
"26": "Btn_SmartLED;0"
}This device with 1.0.9 firmware is now listed on CloudCutter as:
Feit TAPE16-RGBW-RP LED StripThe CloudCutter profile can be found here: https://github.com/tuya-cloudcutter/tuya-clou...files/potek-lst-fw-1.0.9-sdk-2.3.1-40.00.json
I was able to flash it using only the RX1, TX1, GND and CEN test pads on the back of the board without having to desolder or cut any traces.
I was able to power the board with its included 24VDC power supply to talk to the 7231N.
I successfully completed a UART dump using a Raspberry Pi and the uartprogram from https://github.com/OpenBekenIOT/hid_download_py
The dump is zipped and attached to this post with a test SSID and Password on an otherwise freshly reset Tuya Firmware 1.0.9.
I have tested the CloudCutter profile and can confirm it works on an un-modified device.
As a note, this firmware significantly improves the WiFi performance of these light strips. This is consistent across all 5 of the devices I have updated so far - and the comparison is striking. The performance of the updated devices versus their historical performance and the current performance of the 4 remaining devices I have not yet flashed tells an interesting story. This is not anecdotal improvement - I have the historical performance data to prove it. (I have Unifi APs and a UDM Pro, which keeps device performance history.) The FEIT stock firmware is definitely nerfing the WiFi transmit strength. With the stock firmware, a device that's only 4 meters from a Unifi U6LR (Long Range model) shows fair performance, and a AP/Client Signal Balance of 'poor.' After flashing OpenBK, that same device now shows excellent performance and the AP/Client Signal Balance is 'good.' Here is a comparison of one Tuya Stock device and one OpenBK device - right next to each other:
This is consistent across every one of these devices I have flashed. They have all switched to WiFi 4, good signal balance, and higher speed connection. (Note that I have only seen this improvement on this 7231N device. I also have some FEIT 7231T smart plugs and A19 bulbs that did not improve like this.)
Here is the full JSON configuration I am using:
{
"vendor": “FEIT”,
"bDetailed": "0",
"name": “Smart “LED Light Strip”,
"model": “FETAPE/RGBW/CNTRSC”,
"chip": "BK7231N",
"board": “LST04-BKN1”,
"keywords": [
"RGBW",
"Strip",
"Cloudcutter"
],
"pins": {
"6": "PWM;4",
"7": "PWM;2",
"8": "PWM;1",
"9": "PWM;0",
"26": "Btn_SmartLED;0"
},
"image": "https://obrazki.elektroda.pl/7879920800_1678042069.jpg",
"wiki": "https://www.elektroda.com/rtvforum/viewtopic.php?p=20474832#20474832"
}Here are the photos for this device.
Here is a dump of the original 1.0.9 Tuya firmware after attaching to a test network:
Comments
Keep it up and good luck, I haven't seen that kind of device yet, so it will be definitely interesting! I will help you when it's needed, and also, if you have a 2MB flash dump (backup), please post it... [Read more]
Unfortunately I managed to damage the RX1 diagnostic pad. I will need to clamp a probe onto the chip for RX1 - are the pinouts the same for 7231N and 7231T? I found some pinout diagrams on the site labeled... [Read more]
The pinouts are the same. BK7231 datasheet, pinout, programming, specification, wiki (BK7231T, BK7231N) [Read more]
Unfortunately it doesn't want to talk to me in-circuit: https://obrazki.elektroda.pl/9329478900_1678135578_thumb.jpg Rather than try to modify anything abut this board, I think it will be easier... [Read more]
I think you can solder to that two points: https://obrazki.elektroda.pl/5708118300_1678172127_thumb.jpg Is RX1/TX1 used for anything else in this system? If not, then flashing should work. Removing... [Read more]
I did use that through hole for the RX1 pad I pulled up. The TX1 one is fine. Maybe I will try a couple other things first: 1: I used the 3.3v power pin from the Pi. I can try an external supply. 2:... [Read more]
Are you using the CSN/CEN reset method or just a power off/on cycle RESET method? [Read more]
I have a momentary button that shorts CEN to GND. Is there any reason not to power the board from its own 24VDC power supply and forget trying to power via VDD pad? It is not a mains connected devi... [Read more]
If your 24V DC power supply provides galvanic isolation from mains then it can be used. Actually we have used this approach while flashing BL602 LED strip, we used 12V DC power supply: [Read more]
I got it! Turns out I was using the wrong serial port address on the Pi. Duh. The CRC doesn't match, but I think that's expected when dumping the whole image, right? ReadSector Success 1ff000... [Read more]
Hmm for PWM, there is a limited number of options, there is total 6 PWM pins, so you can even try guessing. It's harder with the button. Maybe try to follow the traces on the board, I have linked to BK7231... [Read more]
I got everything working now (except the wireless remote): It looks like I have to use the native interface instead of the web app for this device since it is RGBW (warm white.) It appears that it... [Read more]
You are correct. The 4 PWM with emulation is so rare that it wasn't handled in discovery code. I have added a fix for that: https://github.com/openshwprojects/OpenBK7231T_App/commit/8741e4079997463f3e9a8816f9c33d820333f400 Can... [Read more]
Excellent! I will test 4 PWM discovery tomorrow. The Kelvin mapping does make it all the way to HomeKit via HA, and HomeKit does care about the color temperature for things like adaptive lighting -... [Read more]
I don't know anything about BT remote, can you provide more technical details so we can investigate it? Is it an external chip or is it supposed to use Beken Bluetooth capabilities? Regarding WiFi,... [Read more]
The way it works in Homekit is there is an absolute min/max. 154-500 are in Mired, which are easily converted to Kelvin. You convert back and forth between Mired and Kelvin by dividing 1M by the other... [Read more]
I will be looking into that temperature units today or tomorrow, I will most likely add a command for that, maybe CTRange <min> <max>, but let me answer your question first: Are you sure... [Read more]
Ahh. I see. I didn’t realize the YAML generator was deprecated. I thought it was the Web App status page that was out of date. A quick test shows that it is indeed discoverable by HA with 4 PWM on the... [Read more]
Web App Status Page is obsolete, it shows raw PWM values. I will add information about that or hide it. The YAML generator works in most cases, but it's separate from HA discovery, what I will fix shortly. Okay,... [Read more]