FEIT Smart WiFi Light Strip - Model: FETAPE/RGBW/CNTRSC - FCC ID: SYW-TAPRGBWCNTRSC - 7231N

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 here. Then in worst case you can always restore factory settings.

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 7231T.

Mine is a QFN 4x4 32-pin chip.

The pinouts are the same.
BK7231 datasheet, pinout, programming, specification, wiki (BK7231T, BK7231N)

Unfortunately it doesn't want to talk to me in-circuit:



Rather than try to modify anything abut this board, I think it will be easier to just remove the chip.

They don't use a daughterboard for this device, and it is a wicked small chip - QFN 4x4 32 - so I ordered some of these from Amazon:

https://www.amazon.com/dp/B0B75V1DFP?ref_=cm_sw_r_apin_dp_DVBYW4H7SQENGG29KR9V

I guess I will get a chance to try out my hot air system on some actual SMD work rather than just heat shrink.

Wish me luck.

I think you can solder to that two points:

Is RX1/TX1 used for anything else in this system? If not, then flashing should work.

Removing chip most likely won't work because it might need some basic external circuitry to work, like a crystal oscillator.

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: I believe I set up the Pi properly to use the HW UART, but I have never tested that it works on anything else. I can try a different device than the Pi, maybe Windows and USB UART.

Are you using the CSN/CEN reset method or just a power off/on cycle RESET method?

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 device.

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:

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?




Still no joy.

The circuit is getting a nice 3.3v from the onboard power.
TX1 is connected to RXD0 on the Pi.
RX1 is connected to TXD0 on the Pi.
GND is Connected to GND.
CEN is open until I press a button to bring it low.
VDD is not connected- but I read 3.19v on it.

I have disabled the Pi console I/O to the serial pins.
I have the Pi running dtoverlay=pi3-miniuart-bt which should give the hardware UART to the TXD0 and RXD0 pins and give the software UART to Bluetooth.

Here is what I am sending uartprogram:

Code: text Expand Select all Copy to clipboard

pi@Pi3b31:~/hid_download_py $ uartprogram FEIT-LED-Strip-7231N-1_0_9.bin -d /dev/serial1 -r -s 0x0 -l 0x200000

I have tried -b 115200 and even -b 9600...

Any other suggestions?

Added after 1 [hours] 26 [minutes]:

Okay - so now the fun part. Figuring out the pin assignments for everything.

This is RGBW - so 4 PWN channels.
There is also a momentary button used by the Tuya FW to toggle lights with a tap, and hold to dim, or hold while off to enter pairing mode.
There is also a bluetooth remote that goes with this device that can be used to control it manually.

Any advice on how to start trying to figure all of this out?

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 pinout several posts above. That way you can do that without guessing.

For a button, you can use our SmartLEDButton role. See this video:

(of course, you don't have to solder a button if your strip already has one)

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 needs flag 24 in order to work correctly.
The "smart" button is on pin 26.

So the correct pins with flag 24 set are:



The Web app is confused by skipping a channel and the status page shows some bad information:



0:0 role PWM-Cool White (which is actually Red)
1:0 role PWM-Green (which is correct)
2:0 role PWM-Blue (which is correct)
4:0 role PWM (Which is actually Warm White)

Everything works great in the native interface though!

Added after 1 [hours] 23 [minutes]:

>>20474622
Made lots of progress and updated the top post - but all is not 100% yet:


Question: Is there a way to set the temperature range for the color temp functionality? The PWM6 pin is a 2700K warm white LED - but the native interface assumes that it's 2000K.

Another Question: The HomeAssistant YAML generated for this light seems strange - it exposes it as 4 separate lights rather than a single color-changing light:


For my FEIT RGBCW bulbs and the Smart Plugs, HA added them automatically as soon as they restarted and ran scheduleHADiscovery. For this strip, I had to manually add the YAML, and it's showing 4 entities (R,G,B,W.) Any advice here?
(Maybe a workaround: I have noticed that if I put in the missing CW [channel 3] on an unused PWM pin, then it creates a single RGBCW bulb properly - and it even seems to work with Flag 24 - all within HA as well. Seems like maybe a bug?)

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/OpenBK7231...mmit/8741e4079997463f3e9a8816f9c33d820333f400
Can you check now if HA automatic discovery now works correctly, even with 4 PWMs?

The yaml code does not reflect latest changes. People are now using HASS discovery, anyway.

Web App interface for LEDs is obsolete, I will add a notification to it.

The Kelvins value on GUI is just for cosmetics, but I can add an option to remap it.

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 - so being able to set an actual temperature would be great.

Is there any capability to handle input from a BT remote?

If not, I think this device is pretty much done.

The local performance is fantastic with your FW versus the Tuya stuff - its only been a few hours, but so far I’m very happy.

It also seems like the WiFi performance is better than the native firmware.

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, you can try also 'fast connect' flag in Flags.

So, what is your final flags setting?

I also see you have set a Btn_SmartLED, that's good, we just released a video about it:

Wonko wrote:

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 - so being able to set an actual temperature would be great.

Okay, let's do this, but I don't know much about LEDs from that adaptive lighting standpoint. I know we are using Home Assistant standard:

The Kelvin values are hardcoded:


The range 154-500 is used internally. The Kelvin range is only used for display.
Do you want a command to change led_temperature_min and led_temperature_max or just the displayed one?

I think the correct solution would be to change the internal range 154-500 and then do a better (not hardcoded) Kelvin calculation, but again, I don't have knowledge about that.

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 value. So 154-500 are system min/max. (Of course the direction of warm/cool are inverted - in Kevin warmer is lower, in Mired cooler is lower.)

Any CT bulb also has a min/max. In the case of this strip, the hardware min/max are both 2700K - or 370.37 Mired.

So in Homekit the accessory itself has a min/max that is within the system min/max. (HA does the same.)

With the firmware RGB color mixing, the effective range is increased from 2700-2700 to 2700-???? Due the the ability to add fake cooler colors with RGB.

Anyway - it is a range. I don’t know the proper protocol to define the accessory CT range - but there is almost certainly a way to specify it. In our LED strip case the warm limit is 370.37 (2700K) and the cool limit is defined by the FW CT RGB mixing algorithm, but only with flag 24 enabled. Without flag 24 our range is a single value: 370.37 (2700K).

By the way, it is certainly also theoretically possible to mix more red into the white light on the warmer side to get the true range of the strip to 2000k on the warm side if the firmware color blending algorithm can do it. In this case we would want to make sure that the “zero point” for mixing (no RGB at all) falls exactly at 2700K.

This is basically giving us a calibration for the color temp - the idea being in theory I can set all of the lights in a room to a specific color temperature, and they will all look the same.

I hope this all makes sense.

Moving to the remote. I will take some photos and take one apart. I speculate the stock Tuya FW is listening on BT for this remote at all times except when doing BT pairing. I think the remote is sending BT commands that work via the controller’s built-in BT radio - no extra chip. I could be wrong.

It is possible that it is not BT - but it is definitely some type of RF. I can try listening for RF by attempting to pair the remote with my Bond Bridge which can learn many types of RF remote commands. Maybe that is what Pin 24 is actually used for? Sort of like an IR input?

I will do some digging.

Added after 1 [hours] 22 [minutes]:

>>20475399
Okay - a few things:

1. The 4 PWM fix did not work for me, but it did not break anything new either. I added comments and screen-shots on the commit in GitHub.

2. I am using the following flags: 9, 10, 12, 24, 27, 28. I am curious as to the benefit of the Fast WiFi connect flag. I might be willing to test if I understand what to look for. I really never have device disconnects - so a faster reconnect is not something I would normally notice. Maybe a little more explanation of how it works and how to verify it is working would help. And speaking of WiFi:



The first image is one of these devices running the Tuya firmware, and the second is running OpenBK. They are right next to each other. The one of the right was upgrade to OpenBK about 14 hours ago. Notice the green bar? Yes - your firmware is behaving much better on my network than the Tuya FW. In fact, my APs say the `AP/Client Signal Balance` from all of the 5 OpenBK strips is 'Good' and the same value for the remaining 4 running Tuya FW all report as 'Poor.' This of course means the AP is transmitting a much stronger signal than it is hearing from the devices. This same set of images is consistent across all 9 of my devices - all the OpenBK devices no longer have the yellow WiFi performance areas, and all of the Tuya ones have that same messy pattern and poor signal balance. I have a speculation about this. I believe Tuya FW is transmitting at a lower power level - and I believe it may be to avoid blinding the BLE radio from listening for the remote. I could be wrong about the reason - but nevertheless it is very clear that the OpenBK firmware significantly improves the WiFi performance of these light strips. Fantastic.

3. The remote is indeed categorized as a "BLE Beacon Remote Control" and the details are here: https://fcc.report/FCC-ID/2AMV5TX227-HF Note that the FCC report is for a former version of the device, but FEIT got a new number listed under the old test report. My actual device is registered here: https://fcc.report/FCC-ID/SYW-TAPRGBWREMSC/

So it seems that the Tuya FW does listen for this remote using the BLE radio. I'm sure that's probably quite a bit of work to contemplate for your firmware since BLE is a whole additional set of libraries and protocols and so forth for limited value - but there is the confirmation that at least this one device does indeed use and external BLE beacon as a remote control and not only for "fast" pairing.

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:

Wonko wrote:

1. The 4 PWM fix did not work for me, but it did not break anything new either. I added comments and screen-shots on the commit in GitHub.

Are you sure that it didn't fix the Hass Automatic Discovery? Please keep in mind that the YAML preview is a different, obsolete system. The YAML preview will not change, it still will be incorrect, but I'd expect that real HASS discovery will now add 4 PWM device with "simulate white" flag correctly.

Quote:

(It is worth noting I have Btn_SmartLED configured on P26 - so I don't know if that throws off pwmCount.)

It shouldn't affect anything.

Can you please recheck or confirm that you are indeed referring to HASS discovery and not to the obsolete Yaml generator, which is (I'll repeat) a separate system?

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 new version.

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, so... I am still not sure how to handle that Kelvin problem, but I've added a little command for that:
https://github.com/openshwprojects/OpenBK7231...mmit/d47aae3f99d8ec3b3d7ff4e238bbbf4ef415ced0
I also renamed it later:
https://github.com/openshwprojects/OpenBK7231...mmit/8968872ad0f026264c648a4ccb85901afb38b209

The default values are:

Now current version allows you to change them, and it will still display equivalent Kelvin correctly.

But I think there is a problem with that!
If your Home Assistant still has min temperature set to 154, and you will set it to 250 on your device, then the slider on Home Assistant won't go lower than to 250. It might look strange/broken... but I am not sure, haven't tested yet.

@Wonko, what do you think about this? Is the CTRange good enough solution for you, or can I do something else better?

HA Modifies the slider to work with the range of the light, (or the the largest range in a group and clamps lights with smaller ranges.) So if it is set in the profile, it should just work.

Here is state YAML for 2 different lights with different ranges. The first is a Hue tunable white bulb. The second is a Meross RGBCW LED strip:





So you see these ranges are configurable by device.

So now I should include the current max and min setting in the HASS discovery code so HA can know what is the range of each device?

Yes, I believe this is how it should work. Somewhere in the MQTT schema there should be color temp range values. If you don’t specify, it surely uses the system max range.

Added after 13 [minutes]:

>>20477411
Looks to all be defined here:

https://www.home-assistant.io/integrations/light.mqtt/

So in this section add those and field values from your new commands and that should do the trick.

https://github.com/openshwprojects/OpenBK7231...6131a73f839c4/src/httpserver/hass.c#L274-L279

>>20477411
Hi, I saw a commit for an LEDRange command - is that working now to set temperature range for the bulb?

I tried startup command:

backlog scheduleHADiscovery 10; LEDRange 154 370

but it acts like that is unknown command:

Error:CMD:cmd LEDRange NOT found (args 154 370)

Oh, sorry, it seems I work too much. I was sure that I already wrote to you about that.

Yes, there is a CTRange command (it was LEDRange but I renamed it) which should be working and the syntax is:

it should automatically update the Kelvins on GUI, please check if that's working correctly. However, we still don't include our mired range on HA discovery, I will need to fix that later.

NOTE: this command is only for cosmetics, it does not affect hardware performance of the bulb.

That explains it!

Lol I thought I was going crazy - I looked at the code in the 570 commit and couldn't figure out why it wasn't working.

Yes, it works beautifully - only one minor nit: Looks like it rounds the mired float value to an integer. If I put the range as 153 370.37 it still shows 2707 as the low value.

Not a huge deal - just remember the whole Mired range is pretty small compared to the Kelvin range - so keeping a couple digits of float precision is not a bad idea.

The behavior in HA with it like this isn't awful - it just sort of doesn't do anything with the bulb if you drag the slider below 2702.

Thanks for adding this feature!

Hmmm it's indeed an integer, I will look into possibility of converting it to float.

Regarding the range Home Assistant Discovery:
https://www.home-assistant.io/integrations/light.mqtt/

It seems that now I should include min_mireds and max_mireds fields?

Yes, I believe that should do it!

>>20479539
Hello, still planning to add this to HA discovery?
If you're too busy I might fork it and create a pull request.

@Wonko I haven't started yet, if you know how to do it, then please do, but it should be very, very easy. Just in the CW discovery code add two lines to print correct key and plug the "led_temperature_min" global variable to printf...

Let me know if you can manage it, then I'll happily merge your pull request. If not, I will do it myself in the following days, hopefully.

We have busy days. today we will be hopefully Tasmota Device Groups for wall switch and multiple bulbs configuration video.