That would be great, but seeing as it’s primarily (if not completely) Tuya’s firmware code, I extremely doubt that would ever happen. Would love to be wrong on this though.
For those looking for installation options of such dimmer/switch, check out the thread below in a ‘sister’ site.
We should write our code for that MCU… 
1 Like
How to test the queue version of tuya dimmer you posted on GitHub? I work on raspberry pi, compile in HomeAssistant, I tried to replace tuya files in: \config\esphome\XYZ\src\esphome\components\tuya
Seems that those are overwritten by public version when I hit “Compile”.
OK, Those changes are in dev release, so I changed ESPHome plugin version to dev (putting “esphome_version: dev” in configuration and restart plugin).
I just recently got around to firing up my solder station and removing the ESP board from the controller (killed 1 and 2 successes with good technique now.)
I am having problems with the units shutting off uncommanded.
Here is my YAML:
esphome:
name: feit-102
platform: ESP8266
board: esp01_1m
wifi:
ssid: "xxxxxxxxxxxxx"
password: "xxxxxxxxxx"
# Enable fallback hotspot (captive portal) in case wifi connection fails
ap:
ssid: "Feit-102 Fallback Hotspot"
password: "xxxxxxxxxxxxx"
captive_portal:
# Enable logging
logger:
baud_rate: 0
level: VERBOSE
# Enable Home Assistant API
api:
ota:
mqtt:
broker: 192.168.50.25
username: mqttuser
password: xxxxxxxxxx
uart:
rx_pin: GPIO3
tx_pin: GPIO1
baud_rate: 9600
# Register the Tuya MCU connection
tuya:
# Make the light
# Not sure about the minimum dimming range here, 0 might be too low
light:
- platform: "tuya"
name: "xxxxxxxx_office_cans"
dimmer_datapoint: 2
switch_datapoint: 1
min_value: 10
max_value: 1000
Could it be the MQTT client crashing the switch? I don’t see others using it (so I assume they add the switch via the ESPHome integration instead of MQTT auto-discovery.)
Did you try:
logger:
baud_rate: 0
level: NONE
?
My dimmer was turning off by itself when I had issues with supervisor in HomeAssistant. But I don’t think your problem is related to that (I use ESPHome api). Maybe?
Yeah - thanks. I saw other comments on NONE. I had VERBOSE on trying to see if I could catch an event that was causing the shutoff. Of course I never had the logger running when an uncommanded off event happens.
In order to see if I can duplicate or replicate conditions, I have two switches flashed with ESPHome. Switch#1 has the above YAML. Switch#2 has Logging set to ERROR and the MQTT client commented out.
I’ve also set dimming min to 1000 to prevent local dimming which works. The combo of these FEIT dimmers plus 9 FEIT LED can trims causes a hum at anything less than 100% - even though the LED trims are supposed to be dimmer compatible.
Humming is rather normal - I have replaced one of those with Leviton dimmer and the hum is the same.
Humming typically means the load is not ‘correct’. Are you by any chance using those dimmers to drive a variable-speed fan? If so, that’s an absolute no-no and could cause the unit to heat up … and possibly catch fire.
Nope - not a motor. Costco FEIT Smart WIFI Dimmer driving 6 Feit LEDR56/827 1290 Lumen can light trim kits. Had a Lutron dimmer on them before and no hum - so I think it it is the PWM profile.
Just find it interesting that even though they are Feit dimmers and leds, they still hum enough to be distracting.
As to the problem of shutting off - I disabled MQTT, lowered Logging to ERROR and forced the dimmer to Min and Max = 1000. Has been running steady all day. The second one (driving 2 FEIT LED screw in bulbs) is the exact same config except I allowed dimming. Haven’t done much testing on the dimmer version yet since it is my S.O.'s office and I’m not “welcome” to go in and start flipping lights on and off during work.
Here is the YAML that I am currently running on the dimmer version:
esphome:
name: feit-101
platform: ESP8266
board: esp01_1m
wifi:
ssid: "SSID"
password: "PASSWORD"
power_save_mode: none
# Enable fallback hotspot (captive portal) in case wifi connection fails
ap:
ssid: "Feit-101 Fallback Hotspot"
password: "FALLBACK-PASSWSORD"
captive_portal:
# Enable logging
logger:
baud_rate: 0
level: ERROR
# Enable Home Assistant API
api:
ota:
#mqtt:
# broker: 192.168.50.25
# username: mqttuser
# password: xxxxxxxxx
uart:
rx_pin: GPIO3
tx_pin: GPIO1
baud_rate: 9600
# Register the Tuya MCU connection
tuya:
# Make the light
# Not sure about the minimum dimming range here, 0 might be too low
light:
- platform: "tuya"
name: "xxx_office_general"
dimmer_datapoint: 2
switch_datapoint: 1
min_value: 10
max_value: 1000
For the next dummy that comes along and doesn’t RTFM…(I would be that dummy right now.)
Warning
When enabling MQTT and you do not use the “native API” for Home Assistant, you must remove the api: line from your ESPHome configuration, otherwise the ESP will reboot every 5 minutes because no client connected to the native API.
I was connecting to the switch via MQTT only. And I did not comment out the API line. Hence the reboots resulting in a light turning off every five minutes. R… T… F… M!
Have gone back to ESPHome config/monitor only. Turned MQTT on for the switch in my office just so I could validate that I’ve solved that problem. But now that I understand MQTT vs ESPHome, I probably do not need MQTT on. My broker is on my HA machine, so if one is down the other is probably down too.
In my case no motor, just 5 LEDs.
I have 16 such dimmers and none of them ‘vocalizes’ … is the wiring ok (ground/neutral) ?
Yup. The bulbs are making noise, not dimmer itself.
Ah ok sorry I misunderstood. Now, if you connect the bulbs to a regular switch, do the still make noise?
Mine do not make noise on a regular switch - so I definitely think it is a combo of this dimmer and these lights.
The LED light in my office (a fixture rather than a can light trim) does not hum at all and dimming works all the way down to almost nothing.
So it would seem that MQTT is definitely my problem. Whether it is related to these switches or the Mosquitto Broker on my server I don’t know - and am inclined to not troubleshoot anymore.
Here is the log results from the one switch that I have MQTT enabled.
INFO Connecting to feit-103.local:6053 (10.10.10.204)
INFO Successfully connected to feit-103.local
[12:28:37][E][mqtt:282]: Can't connect to MQTT... Restarting...
INFO Connecting to feit-103.local:6053 (10.10.10.204)
WARNING Couldn't connect to API (Timeout while waiting for message response!). Trying to reconnect in 1 seconds
INFO Connecting to feit-103.local:6053 (10.10.10.204)
INFO Successfully connected to feit-103.local
[12:43:44][E][mqtt:282]: Can't connect to MQTT... Restarting...
INFO Connecting to feit-103.local:6053 (10.10.10.204)
WARNING Couldn't connect to API (Timeout while waiting for message response!). Trying to reconnect in 1 seconds
INFO Connecting to feit-103.local:6053 (10.10.10.204)
INFO Successfully connected to feit-103.local
[12:58:52][E][mqtt:282]: Can't connect to MQTT... Restarting...
INFO Connecting to feit-103.local:6053 (10.10.10.204)
WARNING Couldn't connect to API (Timeout while waiting for message response!). Trying to reconnect in 1 seconds
INFO Connecting to feit-103.local:6053 (10.10.10.204)
INFO Successfully connected to feit-103.local
I did notice a flicker in the light each time this error sequence happens.
Has anyone solved the mystery of the dimmer not going to 100% brightness when turned ON (from HA or local button?). I have 6 of these installed now and every one of them has one more “step” of brightness by pushing up on the dimmer switch.
When connected to the humming FEIT LED cans - the hum almost disappears at that brightest setting. But cycling power off and then back on brings the hum back.
It is like the brightness default is 95% and the last click up takes you to 100% (which would explain the hum difference - if there is no wave clipping happening, then no hum. I’ve tried different values for the MAX in the code below and it doesn’t change anything other than it seems to impact the “proportion” of the dimming range.
The two places were I REALLY want a dimmable wifi switch - kitchen with 8 cans and office with 6 cans - both have the hums. So I guess I will try some other dimmer brands - not hopeful though. I suspect they all use leading edge instead of trailing edge management - which seems to be the cause of the hum.
Anyone know of a wifi (ESPHome) capable dimmer that uses TRAILING edge (MOSFET rather than TRIAC)?
light:
- platform: "tuya"
name: "$device_verbose_name Dimmer"
dimmer_datapoint: 2
switch_datapoint: 1
min_value: 10
max_value: 1000
(Edited to correct leading/trailing edge mis-speak.)
1 Like
All my lights are dimmable LEDs, and most are controlled by Feit dimmers. I have 16 such dimmers and none of them hums. Rather than changing the dimmers, have you tried swapping the lights ?
I’m not saying it is the dimmer specifically - as I’ve previously mentioned, the same FEIT dimmer works fine with a LED fixture in another part of my house.
But what I am saying is that I do not get hum on these exact can lights when I use a non-smart Lutron dimmer (DIVA LED+ Gen2) with no hum and decent dimming performance. The DIVA is a leading edge dimmer as well - so it must be the clipping profile that is used in the FEIT.
As to replacing all the can trims - I have about 25 of them around the house - good deal at Costco of course - and so I’m hesitant to exchange out a perfectly functional light because the dimmer doesn’t play well with the light. If they hummed on ANY dimmer I used, I might feel different.
There is a Martin Jerry 3-way Trailing Edge dimmer on Amazon. $38… But might try one to see if it makes a difference. If it did, I could probably swallow that price for the two places that the hum is really annoying.