Elektroda.com
Elektroda.com
X

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

Wonko 3126 75
  • 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:

    "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 Strip
    .
    The CloudCutter profile can be found here: https://github.com/tuya-cloudcutter/tuya-cloudcutter.github.io/blob/master/profiles/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:

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

    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.

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

    Here is a dump of the original 1.0.9 Tuya firmware after attaching to a test network:
    FEIT-LED-S..._9.bin.zip Download (1.58 MB)

    Cool? Ranking DIY
    Do you have a problem with Raspberry? Ask question. Visit our forum Raspberry.
    About Author
    Wonko
    Level 4  
    Offline 
    Wonko wrote 29 posts with rating 1. Been with us since 2023 year.
  • #2
    p.kaczmarek2
    Moderator Smart Home
    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.
  • #3
    Wonko
    Level 4  
    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.
  • #4
    p.kaczmarek2
    Moderator Smart Home
  • #5
    Wonko
    Level 4  
    Unfortunately it doesn't want to talk to me in-circuit:

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

    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.
  • #6
    p.kaczmarek2
    Moderator Smart Home
    I think you can solder to that two points:
    FEIT Smart WiFi Light Strip - Model: FETAPE/RGBW/CNTRSC - FCC ID: SYW-TAPRGBWCNTRSC - 7231N
    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.
  • #7
    Wonko
    Level 4  
    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.
  • #9
    Wonko
    Level 4  
    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.
  • #10
    p.kaczmarek2
    Moderator Smart Home
    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:


  • #11
    Wonko
    Level 4  
    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 len 1000
    2097152
    CRC should be ae58a67a
    CRC is 89cc3081
    CRC check failed
    Wrote 200000 bytes to FEIT-LED-Strip-7231N-1_0_9-2.bin



    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:

    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?
  • #12
    p.kaczmarek2
    Moderator Smart Home
    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)
  • #13
    Wonko
    Level 4  
    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:

      "pins": {
        "6": "PWM;4",
        "7": "PWM;2",
        "8": "PWM;1",
        "9": "PWM;0",
        "26": "Btn_SmartLED;0"
      }


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

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

    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:

    mqtt:
      light:
      - unique_id: "FEIT-LED-STRIP-EA8AA2_light_0"
        name: "Lobby-Door 0"
        state_topic: "obk17EA8AA2/0/get"
        command_topic: "obk17EA8AA2/0/set"
        brightness_command_topic: "obk17EA8AA2/0/set"
        on_command_type: "brightness"
        brightness_scale: 99
        qos: 1
        payload_on: 99
        payload_off: 0
        retain: true
        optimistic: true
        availability:
          - topic: "obk17EA8AA2/connected"
      - unique_id: "FEIT-LED-STRIP-EA8AA2_light_1"
        name: "Lobby-Door 1"
        state_topic: "obk17EA8AA2/1/get"
        command_topic: "obk17EA8AA2/1/set"
        brightness_command_topic: "obk17EA8AA2/1/set"
        on_command_type: "brightness"
        brightness_scale: 99
        qos: 1
        payload_on: 99
        payload_off: 0
        retain: true
        optimistic: true
        availability:
          - topic: "obk17EA8AA2/connected"
      - unique_id: "FEIT-LED-STRIP-EA8AA2_light_2"
        name: "Lobby-Door 2"
        state_topic: "obk17EA8AA2/2/get"
        command_topic: "obk17EA8AA2/2/set"
        brightness_command_topic: "obk17EA8AA2/2/set"
        on_command_type: "brightness"
        brightness_scale: 99
        qos: 1
        payload_on: 99
        payload_off: 0
        retain: true
        optimistic: true
        availability:
          - topic: "obk17EA8AA2/connected"
      - unique_id: "FEIT-LED-STRIP-EA8AA2_light_4"
        name: "Lobby-Door 4"
        state_topic: "obk17EA8AA2/4/get"
        command_topic: "obk17EA8AA2/4/set"
        brightness_command_topic: "obk17EA8AA2/4/set"
        on_command_type: "brightness"
        brightness_scale: 99
        qos: 1
        payload_on: 99
        payload_off: 0
        retain: true
        optimistic: true
        availability:
          - topic: "obk17EA8AA2/connected"
    

    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?)
  • #14
    p.kaczmarek2
    Moderator Smart Home
    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 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.
  • #15
    Wonko
    Level 4  
    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.
  • #16
    p.kaczmarek2
    Moderator Smart Home
    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:
    Code: c
    Log in, to see the code

    The Kelvin values are hardcoded:
    Code: c
    Log in, to see the code

    Code: c
    Log in, to see the code

    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.
  • #17
    Wonko
    Level 4  
    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:

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

    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.
  • #18
    p.kaczmarek2
    Moderator Smart Home
    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?
  • #19
    Wonko
    Level 4  
    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.
  • #20
    p.kaczmarek2
    Moderator Smart Home
    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/OpenBK7231T_App/commit/d47aae3f99d8ec3b3d7ff4e238bbbf4ef415ced0
    I also renamed it later:
    https://github.com/openshwprojects/OpenBK7231T_App/commit/8968872ad0f026264c648a4ccb85901afb38b209
    
    CTRange [MiredMin] [MiredMax]
    

    The default values are:
    
    // in the range from 154-500 (defined
    // in homeassistant/util/color.py as HASS_COLOR_MIN and HASS_COLOR_MAX).
    float led_temperature_min = HASS_TEMPERATURE_MIN;
    float led_temperature_max = HASS_TEMPERATURE_MAX;
    

    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?
  • #21
    Wonko
    Level 4  
    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:

    
    min_color_temp_kelvin: 2202
    max_color_temp_kelvin: 6535
    min_mireds: 153
    max_mireds: 454
    supported_color_modes:
      - color_temp
    color_mode: color_temp
    brightness: 255
    color_temp_kelvin: 6535
    color_temp: 153
    hs_color:
      - 54.768
      - 1.6
    rgb_color:
      - 255
      - 254
      - 250
    xy_color:
      - 0.326
      - 0.333
    mode: normal
    dynamics: none
    friendly_name: Living Room Mantle Left
    supported_features: 40
    


    
    min_color_temp_kelvin: 2695
    max_color_temp_kelvin: 6535
    min_mireds: 153
    max_mireds: 371
    effect_list:
      - Night
      - Reading
      - Working
      - Relaxing
      - Party
    supported_color_modes:
      - color_temp
      - hs
      - rgb
    friendly_name: Living Room Hutch
    supported_features: 4
    color_mode: color_temp
    brightness: 255
    color_temp_kelvin: 2695
    color_temp: 371
    hs_color:
      - 28.406
      - 65.883
    rgb_color:
      - 255
      - 166
      - 86
    xy_color:
      - 0.527
      - 0.388
    


    So you see these ranges are configurable by device.
  • #22
    p.kaczmarek2
    Moderator Smart Home
    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?
  • #23
    Wonko
    Level 4  
    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
    max_mireds
    and
    min_mireds
    field values from your new commands and that should do the trick.

    https://github.com/openshwprojects/OpenBK7231T_App/blob/993cd60c909714af7303d928ce86131a73f839c4/src/httpserver/hass.c#L274-L279
  • #24
    Wonko
    Level 4  
    >>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)
  • #25
    p.kaczmarek2
    Moderator Smart Home
    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:
    
    CTRange MinMired MaxMired
    

    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.
  • #26
    Wonko
    Level 4  
    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!
  • #27
    p.kaczmarek2
    Moderator Smart Home
    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/
    FEIT Smart WiFi Light Strip - Model: FETAPE/RGBW/CNTRSC - FCC ID: SYW-TAPRGBWCNTRSC - 7231N
    It seems that now I should include min_mireds and max_mireds fields?
  • #28
    Wonko
    Level 4  
    Yes, I believe that should do it!
  • #29
    Wonko
    Level 4  
    >>20479539
    Hello, still planning to add this to HA discovery?
    If you're too busy I might fork it and create a pull request.
  • #30
    p.kaczmarek2
    Moderator Smart Home
    @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.