Costco Feit Smart Dimmer Tuya Convert Tasmota

drjb · February 22, 2021, 5:03pm

Sorry, I misunderstood your point.

What I learned a while back, I think it was an employee at Home Depot, is that dimmers and lights must be ‘matched’, as some dimmers work well on incandescent and others prefer CFL and/or LEDs. Now, I also replaced my 10× ‘can’ lights in the kitchen by those from Costco (I had no choice, went from CFL to LED) … granted it’s a bit of an investment, but they look way better than the old ones. They cost about $6 a piece … so replacing all of them will set you back ~ $150.

This hobby will have you spending money left/right in no time … All the best, whichever way you need to proceed.

https://www.costco.com/feit-electric-led-5"--6"-retrofit%2C-6-pack.product.100416653.html

flynmoose · February 22, 2021, 5:23pm

This may be straying a little off topic but what the heck.

First - for the geeks who want to know more on dimming LEDs and the difficulties (including an explanation of the Leading and Trailing edge dimmers)
https://www.lutron.com/TechnicalDocumentLibrary/3683586_Challenges_of_Dimming_Whitepaper.pdf

Second, I’m wondering if there is any obvious component differences between the FEIT and Lutron dimmers in the “dimmer” section.

First photos of the FEIT removed showing both sides of the PCB:

And then photos of the guts of the Lutron:

At first I was going to make an argument that the Lutron had more components than the FEIT (excluding the extra components in the FEIT to create VCC for the logic board and allow the MCU to drive the dimmer circuitry) - but the FEIT PCB is double sided and has quite few components on the back. The Lutron only has the power transistor on the back - so perhaps the component count isn’t a big difference.

Maybe an electronics tech or elec. engineer can look at these and tell a big difference on pics alone - I’m not knowledgeable enough to tell things other than size - coil and power transistor are significantly larger on the Lutron.

FWIW

mxr662 · February 22, 2021, 5:29pm

I have bought the 5/6 Feit LED retrofits for different projects. They are not always the same model even though the packaging looks the same. The input wattage varies. Maybe compare yours to what they have in stock currently, you could return yours if the currently stocked model does not buzz.
Andy

agr00m · February 23, 2021, 2:36am

For anyone interested in controlling the Power LED, here’s what you need to do.

Start by selecting which of the TYWE2S GPIO pins you want to use: 4, 5 or 13 (they’re on the top, so make the most sense, but could use 12 or 14 too), and solder a ~28-32AWG wire to it. You could use a bigger wire, but may be more difficult for the steps below. Just don’t solder it to RST or AD.
Cut the trace from the MCU to the LED with an X-Acto knife. Do it far away from the LED, but at least 1/4" from the via.
Scrape away ~3/8" of solder mask over the trace anywhere outside the larger circle around the LEDs, but about 1/2" away from where you cut the trace.
Apply some solder to the exposed trace, then solder the other end of the wire from step 1. Also doesn’t hurt to add a drop of super glue 1-2 places along the wire to keep it tacked down.
Open the module in a browser and configure GPIO4 (or whichever you used) as “Led_i” (inverted) and save (inverted because the LED is connected to +3.3v, so a logic LOW turns the LED on, and logic HI off).
Open the console and type “LedState n” (n = 0-8) to configure the LEDs functionality, and you’re done! For example “LedState 1” will show the power state (LED on when power on). If you want the reverse (LED off when power on), go back and configure GPIO4 to just “LED”. See Tasmota Commands for more details.

If you do all this and it doesn’t work, or want to switch back to the MCU controlling it, just scrape some of the mask off on either side of the cut trace and bridge it with a glob of solder.

If you want to reduce the brightness of the LED, replace R11 (100Ω) with something like a 500Ω-2kΩ. I also replaced the LED with a red one. If replacing the LED or resistor, I highly advise using a microscope or magnifying glass and two soldering irons. My first attempt at removing the led with no scope and a single iron resulted in tearing off both LED pads. Luckily there’s a 2nd set of pads for some reason, so just used that one (also required moving the resistor to R10).

Here you can see the top pad is completely gone and the bottom one lifted off the PCB, though still attached to the trace. If replacing the LED, be sure you get the polarity correct. The anode is the side connected to the resistor.

Since there’s 5 exposed GPIO, you could also do this for each of the 4 brightness LEDs to have full control of those too. Going to try this next chance I get. Didn’t want to do it right away in case this didn’t work.

kiprock · February 23, 2021, 7:59am

Yes I have this exact same problem. It’s driving me crazy. I am running Tuya, but I wonder if the stock firmware did the same.

agr00m · February 23, 2021, 2:38pm

Maybe has something to do with the max wattage the dimmer can handle. LEDR56/827 are 17.2W x 9 = 154.8W Total. Spec sheet says it has a maximum wattage of 150w for dimmable LEDs. Although the Lutron also lists a 150 max wattage, my guess is that the Lutron is better designed to handle power output at the limit.

Have you tried unplugging some of the FEIT LEDR56/827s and seeing if you still get humming? I would even disconnect all but 1, then add them back 1-by-1. It could even be just a single light that’s causing issues.

flynmoose · February 23, 2021, 3:12pm

Thanks Aaron - and good point. I totally missed that rating… As did the electrician who installed the lights and the Lutron dimmer!

Had thought about doing the process of elimination thing - but didn’t get there. May re-install the FEIT dimmer and try that. (both seeing if one light in particular is causing the problem as well as the total wattage.)

Not sure what I will do if it is total wattage. I guess I could blank out one of the cans or replace some of them with lower wattage trims - not sure how that would look aesthetically - but would lower my energy consumption!

But since I’m experiencing the same hum on a bank of 6 (17.5*6=105) - I tend to think it is either individual finicky lights as Aaron has suggested or just general incompatibility of the FEIT dimmer with these particular FEIT can trims (which is particularly humorous…)

flynmoose · February 23, 2021, 4:49pm

@agr00m - have you tried using PWM on that GPIO? I think that is possible and maybe could control brightness of the “bullseye” with software instead of a different resistor?

agr00m · February 23, 2021, 6:55pm

Theoretically yes, and is what I’m hoping to do. Reading through the TYWE2S datasheet does not mention PWM on any of the output pins. However, it uses the ESP8285 which has 4 PWM outputs on pins: 9 (PWM2), 10 (PWM0), 13 (PWM1) and 16 (PWM3). And if I’m correct, the corresponding TYWE2S pins are IO14, IO12, IO15 and IO4, respectively. Since I connected the LED to GPIO4, it should be possible, and just need to figure out how to setup PWM.

agr00m · February 24, 2021, 12:29am

Okay, got it working. Keep GPIO4 set to “LED_i:”, then in the console enter “LedPwmMode 1” (sets control status led mode to pwm). Now you can enter commands “LedPwmOff <0…255>” to set the off brightness, and “LedPwmOn <0…255>” to set the on brightness.

Alternately, you could configure GPIO4 as “PWM_i”, then in the console enter “SetOption68 1” (I think this links PWM1 to Power1). This gives you a slider in the main menu to set the brightness, and the LED will show the power state (LED on when power on).

flynmoose · February 24, 2021, 1:51am

You da man - and the inspiration!

I was de-chipping/re-chipping one tonight so decided to give it a go.

I’m using ESP Home and packages, so here is my “incremental” code in my device-specific YAML to handle the new entity:

light:
  - platform: monochromatic
    output: pwm_output
    name: "FEIT-107 Bullseye"
    
output:
  - platform: esp8266_pwm
    pin: GPIO4
#    frequency: 1000 Hz
    id: pwm_output
    inverted: True

And viola… here it is in Lovelace!

Complete with its own dimmer and toggle:

Full bright:

50% (with main dimmer set to 50% manually to lower the LED count - not programmatic)

And the minimum that I can see the LED lights is 7% (I suspect that once reassembled this level would be barely perceptible - even in a dark room.)

Aaron I’m sure knew this going in - but I want to say for anyone reading this - you will lose normal functionality of the light. ie - you will not get a blinking light on bootup that goes steady when WIFI is connected. The light doesn’t do anything on switchpress. It is just a “nightlight” that you can set by software now.

And for the sharp eye - that “blob” on the PCB is some finger nail polish to cover an accidental scratch in the enamel on the ground plane - so I didn’t end up with an accidental solder bridge to ground.

I am like a kid on Christmas morning with this little project! Might see what I can do with it programmatically on chip as well as with a HA automation to see if it is worth the brain damage to take out the dimmers I’ve already installed for this little mod.

Cheers @agr00m - thank you for the prod to do this!

flynmoose · February 24, 2021, 3:24am

ESPHome has a built in component called status_led.

Stripped out the PWM stuff so I could see the impact one item at a time.

Added the following to my device specific YAML.

status_led:
  pin:
    number: GPIO4
    inverted: True

On boot, I get a steady 1HZ blink for about 6 blinks and then it goes out. Slow blink from status_led is a warning - so it must be warning that it is not yet connected to WIFI.

Just to verify, I changed the wifi in my config to a non-existent one to see what happens now at boot.
And I get:
Perpetual slow (1hz) blink. When the captive portal kicks in, there is no change in the blinking light. But I could connect to the AP on the switch, input the correct SSID/Password and the device connected to the network. Once it finally phoned home the blinking stopped. Of note, the blinking starts up again WHILE you are doing a firmware update - which is a nice feature and not something that happens stock.

Now - I added back in the PWM control. I also wanted to restore the bullseye level to last state without having to use HA automation so I added in restore_from_flash, set the main dimmer to ALWAYS_OFF and added RESTORE_DEFAULT_ON to the monochromatic light (the new PWM LED).

On boot, I still get a blinking effect but it is also trying to PWM the light to the last level. So I get some weird PWM artifacts in the boot sequence. But it is still generally “blinking” indicating a boot. And when it is done booting and connected, it goes steady with the brightness set last.

Pretty happy with that. Will play around with some automation on the HA side (perhaps changing bullseye brightness with time of day - or maybe related to overall room level (if any light in room is full bright, make the bullseye bright. If the room is dark, make the bullseye the minimum brightness etc.)

Home automation is fun (if not a huge time sink!)

agr00m · February 24, 2021, 1:29pm

Awesome! I’ve wanted to try out ESPhome one of these days, so this will be very useful. One note about where you soldered the wire. That outer ring around the LEDs on the PCB is where the switch plate shroud sits (hard to explain w/o a picture). Anyway, try to keep the wire soldered outside that so the shroud doesn’t end up resting on the wire. I’m not sure it sit directly on the PCB, but if it does, it could put some strain on the wire and maybe let some light bleed out into the switch too.

flynmoose · February 24, 2021, 6:40pm

Thanks for that @agr00m. Feel stupid now that you pointed that out. Should have been obvious why there was a circle printed on the PCB.

I just looked at a switch that I have open but un-modded and the shroud does sit pretty tightly against the PCB, so I guess I’ll go back and fix the 2 I already modded. I did not notice any light bleed after assembly - but the strain on the solder join, PCB trace, and wire is probably not a good thing over time - especially in an area that is designed to be pushed on by human fat fingers that tend to “mash”…

After a little more looking at the boot cycle - it appears that the slow blink (Warning) is while the wifi is connecting - and it alternates between full on and the dimmer level last stored - unless the dimmer was set to 100% before boot, in which case you get a strange strobing effect.

The strange blinking appears to be a combo of the PWM dimming the light and the status_led simultaneously “fast blinking” (documentation says 2 or 3 hz) for Error. I suspect an error is thrown after the wifi connects but before ESPHome can be contacted and the device is put online with HA. The effect is different depending on whether the backlight is at full brightness or some lower level of brightness - which is why I think it has to do with interaction between Status_Led and Monochromatic/PWM light function.

But the end result is the same - dim level is restored to the last set value. I tried several start frequencies up to 20Khz (which seemed to break the process - the LED wouldn’t come on.)

flynmoose · February 24, 2021, 9:16pm

For completeness and in case someone comes along trying to piece this all together (like I would have been doing several weeks ago), here is all of my ESPHome YAML CODE to go along with Aaron’s hardware modification. No ownership here - I just cobbled together stuff from others’ work and am putting it all in one place as part of this FEIT Dimmer thread.

First I have a subfolder in ESPHOME directory called COMMON. In COMMON I have 3 files. My “base code” file which holds the majority of the common elements for the FEIT / 8266 lights. This allows for each switch to be customized if needed but uses the same base code so no need to copy\ paste all the code over and over if I make a change to the base setup. (Using a similar setup for all of my KMC wifi switchable outlets.)

#FILENAME: config/esphome/common/base.feit.intertek.5014010.yaml

esphome:
  name: $node_name
  platform: ESP8266
  board: esp01_1m
  # Allow "dimmer and toggle" states to be stored in the flash storage to 
  #survive a power cycle.  CAUTION - there are real risks of wearing out flash 
  #storage prematurely with this option. See ESPHome documentation
  esp8266_restore_from_flash: true
  
# Allow a fallback access point to be created.  See wifi-iot.yaml for actual
#ap setup.
captive_portal:

# Enable logging
logger:
  # Do not send logging info on the UART channel - interferes with MCU operation
  baud_rate: 0
  #Has been reported that anything but NONE causes flickering and strange 
  #operation. ERROR has not caused any issues.  
  level: ERROR

# Enable Home Assistant API - no password required
api:

# Enable OTA Updates - no password required
ota:

# MQTT seemed to be causing periodic re-boots.  Disabled for now.  
#Come back to this for possible testing later.
#mqtt:
#  broker: 192.168.50.25
#  username: mqttuser
#  password: xxxxxxxxxxx

# Enable the 8266 to talk to the MCU chip via UART
uart:
  rx_pin: GPIO3
  tx_pin: GPIO1
  baud_rate: 9600

# Register the Tuya MCU connection
tuya:

# Make the light
#Minimum set to 10 arbitrarily at this point.  0 also seems to work.
light:
  - platform: "tuya"
    name: "$device_verbose_name Dimmer"
    dimmer_datapoint: 2
    switch_datapoint: 1
    min_value: 10
    max_value: 1000
    restore_mode: ALWAYS_OFF

# Create a sensor in HA that shows wifi DB and run-time counter.  Mostly for 
#troubleshooting installation issues and reboot issues.  Probably remove once 
#setup is stable. "Geek" info after that. The bigger the negative number - the 
#worse the signal performance. (-55 better than -85)
sensor:
  - platform: wifi_signal
    name: "$device_verbose_name Signal Sensor"
    
  - platform: uptime
    name: "$device_verbose_name Uptime"

Then I have my Wifi common setup which I am using in all of my devices. Again if I reconfigure my IOT network or change password - just one change and recompile/update all sensors.

#FILENAME: config/esphome/common/wifi-iot.yaml

wifi:
  ssid: "XXXXXXX-IOT"
  password: !secret iot_wifi_password
  power_save_mode: none
  
  # Enable fallback hotspot (captive portal) in case wifi connection fails
  #Ensure that "node_name" + " Fallback Hotspot" does not exceed 32 characters
  #Requires captive_portal be set in common device YAML
  ap:
    ssid: "$node_name Fallback Hotspot"
    password: !secret iot_fallback_password

And finally my secrets.yaml for the wifi (evidently ESPHOME uses its own secrets file and it has to be in the same directory as the base file - or at least that was made it work for me. I’m just referring to my primary secrets file in the main HA directory.)

#FILENAME: config/esphome/common/secrets.yaml

#ESPHome Common Secrets pulled from Home Assistant Secrets
<<: !include ../../secrets.yaml

(Side note - the HA File Editor throws a red explanation point warning flag with the space between the colon and the ! but if you remove the space to satisfy the editor, then the overall YAML fails validation. It works for me with the space in there and I just ignore the editor warning.)

I have a separate YAML for each numbered switch where the file name is the nodename (file name actually has nothing to do with the ESPHome process after the file is created - I just do it that way to keep them all separate and easy to find/edit.)

|n the individual device files I put my overrides. So in the case of Aaron’s LED mod, I put the PWM code just in the switch file instead of the base file - since most of my switches do NOT have this modification.

#FILENAME: config/esphome/feit-108.yaml

substitutions:
  node_name: feit-108
  device_verbose_name: "Feit-108 Switch"

packages:
    wifi: !include common/wifi-iot.yaml
    device_base: !include common/base.feit.intertek.5014010.yaml

#Enable status reporting via LED.  Ties to the hardware modified LED connected to GPIO4
#Same LED that is modified below for PWM dimming.  Backlight LED for main switchplate.
status_led:
  pin:
    number: GPIO4
# Inverted: True if you want the "normal" state to be LED-Off and only illuminate on 
# Error or Warning. See documentation for "status_led" in ESPHome
    inverted: True

# Create PWM LED hijacked from switch backlight illumination (hardware mod)
light:
  - platform: monochromatic
    output: pwm_output
#Note - this will expose the led as a toggle and dimmer to HA as a new device.  If you want to
#permanently dim the LED but not have a new device in HA, there is a ESPHome attribute 
#called "internal" that will hide the device from external.  Alternatively you can put name: in config
# but leave blank. See Switch Component in documentation.
    name: "$node_name Bullseye"
#Pull the last value from flash on boot and set dim level of this LED.
    restore_mode: RESTORE_DEFAULT_ON
# Added gamma_correct based on some other comments on the forum regarding non-color output.
#This seems to make the min and max power settings in the output section to work correctly and be
#be honored by the duty cycle slider in HA.
    gamma_correct: 1.0
     
output:
  - platform: esp8266_pwm
    pin: GPIO4
    id: pwm_output
    inverted: True
    frequency: 1000 Hz   
    min_power: 0.08
    max_power: 1

Some observations:

If you use esp8266_restore_from_flash: true, you should put ALWAYS_ON or ALWAYS_OFF for any device that you don’t want restored to last state (and save the write-to-flash wear that comes with it) which is what I did with the main light switch. It appears that the dim level set on the “mains” is still stored in flash - even with ALWAYS_OFF set. I dimmed the mains, cut the power and on reboot the mains were off - but when I turned them on they went to the dim level I had set before cutting power - NOT to 100%… FWIW. But the same behavior happens on the unmodded lights as well. Dim the mains, cut the power. Turn power back on - light is off but dimness level is retained.
As annotated in the code remarks, I added gamma_correct into the light definition of the backlight. This seems to have fixed the Min and Max power not being honored by the duty cycle slider. The slider tells the software PWM what percentage duty cycle to run. Gamma_correct seems to be necessary for non-color LED use like a monochromatic LED or using software PWM to drive another device like a fan.
Software PWM - I’m in over my head on this at the moment. I think the maximum frequency of software PWM on the 8266 is 1000hz. So I think that is what should be specified in the frequency parameter (which is also the default value.) This is a 10 bit value (0-1023) and the input is a duty cycle (0-100%). The ESPHome function takes care of the math and all you do is move the slider.
The software PWM and the status_led slow cycle pulsing seem to fight each other at times. Behavior seems to depend on the duty cycle selected for the backlight. On boot, there is a bit of a light show of different pulse and strobing. There may be more meaningful info encoded in all that strobing - but for me the big “telltale” is that it is blinking which means it is not yet in a “ready” state. Once it is connected and ready - it either goes steady & set dim level - or it goes out completely if you have the backlight turned off.
The blinking during a firmware update is also hit-miss and seems to be related to the dim level selected. That was just an incidental action - so I would not rely on that to tell you something is happening or not.
There are times where a full power cycle AFTER a flash seems to be required to get all of the PWM stuff working correctly. I have been power cycling all of my FEIT dimmers after a flash as a matter of course because there seemed to be post-flash anomolies like the mains on/off not working via software otherwise.
The full brightness (100% duty cycle) seems to be just slightly less than the factory setup. I haven’t used a meter to see what voltage is being delivered and I don’t own an O-scope to look at the waveform at 100%. I can really only notice the brightness difference if I hold two switches side by side. Not a show-stopper for me since “full bright” on the OEM setup is VERY bright to me.
SAFETY CAUTION - the DC side of this switch is floating. Logic ground is not tied to earth ground or AC Common. I discovered this the hard way with AC attached to an open switch on the bench. Goes without saying - but assume anything could shock you if you have mains connected. In fact - Earth Ground is not tied to ANYTHING on the switch except the mounting tabs which is the purpose of earth ground on an AC switch I guess. Otherwise you would be “bonding” ground to common at two places. Just hadn’t personally thought this all the way through until I got zapped.

DISCLAIMER - I am a HA / Hardware hacking newbie. I’m sure some old hands will come along and point out a bunch of things I am doing wrong. But at this point, this combo of ESPHome and hardware hack is working for me and doing what it was intended to do (ESPhome on a FEIT Wifi Dimmer with a dimmable backlight all controlled from HA)

Technowizard · February 25, 2021, 2:46am

A few messages back now, but it’s just the quality of the “dimmable” led bulbs causing the hum. Had this same problem with some EcoSmart brand G25 globe LED bulbs I bought at Home Depot. Anything less than absolute 100% dimmer setting (both this Feit Dimmer and a Martin Jerry Dimmer) would induce a hum. Replaced the bulbs with some higher quality GE branded bulbs, and they are hum-free at all brightness levels.

flynmoose · February 25, 2021, 4:18am

I hear you - except that they dim fine on Lutron manual dimmers with no hum. So the hum is definitely a combo of the cheaper trim/bulb AND the “economy” dimmer. That is why I was looking at a Martin Jerry with trailing edge waveform management.

The MJ dimmer is $38. If that worked, it is WAY cheaper than replacing 6 trims with either 6 new trims ($15-20 a piece) or an aluminum can reflector ($6-10 each) and a lighbulb (~$5 each?)

CHEAP - FAST - GOOD … Pick 2 (maybe). You’d think all my years in project management would have taught me something.

Technowizard · February 25, 2021, 5:03am

I’m pretty certain the cheapy dimmable leds still buzzed with my MJ dimmers, but maybe I’m remembering wrong… I’ve still got those bulbs, so I’ll try one out when I get home. $38 for an MJ Dimmer? Not sure where you’re at or where you’re getting them from, but ouch! If you’re talking about the standard MJ dimmer (MJ-SD01), Amazon has the 3-pack for $46. Heck I got most of mine “Open Box” (essentially 100% brand new and unused from people who couldn’t figure them out / didn’t have neutral wires I’m sure) off Ebay for $10 a switch.

Regardless, the higher quality LED bulbs were better in every respect still, and could dim down to a VERY faint glow. Like you alluded to though, sometimes it’s just better and less stress to avoid the “cheap” check box, and get the higher quality product from the start. Live and learn I suppose, lol.

flynmoose · February 25, 2021, 5:17am

https://www.amazon.com/Martin-Jerry-Trailing-SmartLife-Compatible/dp/B08MQK26JB/

I think the trailing edge dimmers are more because they don’t use a TRIAC to dim - I think they have a couple of MOSFETS.

Technowizard · February 25, 2021, 5:35am

Oops missed you saying trailing edge in reference to the newer designed ones. Yeah don’t have experience with those to know their ins and outs. Do love how they indirectly show off the TYWE3S module in the one pic for the flashers out there!