That’s what I did in the end. I bought it on sale on Amazon so it was a cheap lesson.
Also, confirmed on the Tasmota Discord that the minimal firmware has no AP mode.
I have 8 of these currently installed, using SmartLife. As I keep adding more the response time becomes slightly worse, but still acceptable. I am curious if anyone has been able to turn off the white LED circle on these by flashing them. That might make me pull the trigger.
Thanks
As far as I’ve been able to tell, that won’t be possible because the LED circle is controlled by the secondary MCU.
Bummer, but thanks for letting me know.
Need some help… I was able to get esphome. I use node-red (no HA) so trying to get mqtt to work so that i talks to my node-red in following way
- posts status changes on a MQTT topic
- accepts commands on another. Payload would be on/off. Bonus if i am able to control dimmer using mqtt too.
but can’t make it work. the yaml doesn’t compile. here is my current yaml…
esphome:
name: diningroom
platform: ESP8266
board: esp01_1m
wifi:
ssid: "asd"
password: "asd"
fast_connect: on
# Enable fallback hotspot (captive portal) in case wifi connection fails
ap:
ssid: "Diningroom Hotspot"
password: "asd"
captive_portal:
# Enable logging
logger:
baud_rate: 0
level: VERBOSE
# Enable Home Assistant API
api:
ota:
#MQTT
mqtt:
broker: 192.168.1.5
port: 1883
client_id: diningroom
keepalive: 60s
switch:
- platform: "mqtt"
name: "Dining Room"
command_topic: "/localhome/lights/stat/diningroom/POWER"
state_topic: "/localhome/lights/cmnd/DiningRoom/power"
qos: 1
payload_on: "ON"
payload_off: "OFF"
retain: false
# Enable web server
web_server:
port: 80
# My dimmer used this hardware serial port
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: "dining_dimmer"
dimmer_datapoint: 2
switch_datapoint: 1
min_value: 10
max_value: 1000
any help ?
answered my own question. I was finally able to get this dimmer working with my node-red instance. I can now control it using MQTT/REST api. I have documented the steps (and full YAML config) here for anyone looking…
@carefulcomputer Nice write up! Thanks for that. You may find the web_server enabled will cause issues.
Andy
thanks @mxr662 . wasn’t aware of that issue. thanks for pointing it out. i am wondering since i had to disable api and if i disable web_server too , how will i upgrade/make changes ?
Thanks for this thread! I was able to get my switches added to HA with it.
One question, slightly off topic, but it’s the only place I’ve found people talking about these switches: I’m having trouble finding a way to wire one room up in a different 3-way configuration than the official instructions require.
My power comes first to a switch (where I have the smart switch), then to the light, then ends with one 3-wire to another switch. Specifically it’s the second diagram at this link: https://www.do-it-yourself-help.com/3-way-switch-wiring-diagrams.html
If I wire the Feit smart switch in the first switch position with Hot to ACL, Whites to ACN, Red to RDYL, and Black to Load, it works with the exception that when the second dumb switch is flipped towards Red traveler, the Feit smart switch state no longer effects the Light (eg the switch leds will turn green but ceiling light does not actually turn on).
Any suggestions for how I might wire up the Feit switch in this configuration?
If it helps, here’s a mspaint drawing of the current wiring:
Per the Feit instructions the smart dimmer is supposed to be at the end of the run, not the beginning. But I am interested in your way as I don’t have neutral at the end position.
The problem with putting it at the end of the run in this layout is that there’s no way to guarantee power to the smart switch. So when the second switch is in one position the smart switch will work (since it’s powered), but when the second switch is flipped the other way, the smart switch will lose power and stop functioning.
I guess my only hope is to wire it up that way and run power from a nearby outlet. I was just hoping to avoid it.
Richard,
You actually have the recommended install (and required) by having neutral at the end. You do have to tweak how the powered dumb switch is wired. You have to wire the line and T1 traveler together.
Put your dumb switch where your smart switch is, and put the smart switch at the end of the line. Wish I had your setup. I simply don’t have neutral at the end. I can’t use your setup either at the moment.
Unfortunately I don’t have power coming in at both ends. In my configuration, the switch at the end of the run has only 1 set of 4 wires (black, white, red traveler, and ground) coming directly from the light, the other switch has 1 set of 3 wires (black, white, ground) coming from the panel, and 1 set of 4 wires going directly to the light.
Maybe I’m missing something (hopefully that’s the case!), but if I were to put the smart switch at the end of the run, then when power is flipped off at the beginning switch, then the smart switch would lose power too (unless it’s smart enough to draw power from both red traveler and AC/L?). Also not 100% sure how I’d wire it up with only 1 black wire at the end of the line- would it go to ACL or LOAD?
You connect the line with the T1 traveler at the dummy switch. You shouldn’t have power at the end of the run. You are set up perfectly. All you need is the neutral at the end of the line. I only have 3 wires at the end run…no neutral. So I can’t do it.
But I have two other locations that are exactly like yours, and these dimmers are on the end of the run, and dumb switches at the beginning. The key is to connect the T1 traveler with the line.
Thanks for all the info about these dimmers everyone. I just bought these recently and had the same problem with tasmota not updating the light state from physical button presses, so am trying ESPHome for the first time and it seems to work better with these.
Besides the local control, one of the reasons I switched from a Leviton wifi dimmer these the Feit is that I wanted to respond to double-taps and long-presses. Since the buttons on these dimmers are connected directly to the Tuya MCU (as far as I understand) it doesn’t appear you can detect double and long presses from GPIOs, which is pretty straightforward.
The best I’ve come up with is to create a template binary_sensor that reads the state of the light (I had to read the c++ code to figure out id(lightid).current_values.is_on(), I didn’t see it documented anywhere) and perform my action when that template sensor goes from off -> on -> off, which would be considered a click. Here’s the section of my yaml:
light:
- platform: "tuya"
id: tuyalight
name: "test_dimmer"
dimmer_datapoint: 2
switch_datapoint: 1
min_value: 0
max_value: 1000
binary_sensor:
- platform: template
name: "Light on"
lambda: |-
if (id(tuyalight).current_values.is_on()) {
return true;
} else {
return false;
}
on_click:
min_length: 50ms
max_length: 600ms
then:
- delay: 1ms
- light.turn_on: tuyalight
- light.turn_on:
id: tuyalight
brightness: 100%
- logger.log: "Double tap"
Anyone know an easier or better way to detect double taps?
I forked off Tasmota 8.2.0 with a fix for this dimmer. My dimmer currently works as well as I’m able to test it. It appears completely stable but I can’t say for sure whether this fix corrects the issue for everyone else. So I’m looking for volunteers to test it out.
You can find the fork here: https://github.com/TheEebb/tasmota-tuyamcu-fix
Post your results please. Thanks.
EDIT: I forgot to mention please use “Tuya Tx Special” instead of “Tuya Tx” in your module configuration
1 Like
@TheEebb I’m testing this, and so far the main issue I can see is that changing the brightness and/or turning On/Off the switch via WiFi (both on the web server and HA) doesn’t update the switch itself. This makes the switch still think it’s in its previous physical On or Off state if you change it via WiFi (which does still work in both HA and the web server at turning On/Off or adjusting brightness of what the switch controls), which causes you to have to “cycle through” to get it synced up if you change it via WiFi and then again physically at the switch. It also causes an issue if you adjust brightness from both WiFi AND the physical buttons, as on button press the brightness will jump to where the switch thinks it’s at, regardless of where you previously put it via WiFi. I’ll report any changes, good or bad, if they occur. Thank you and bless you Eebb for your work on this, you’re making progress!!! 
edited to correct issue
@TheEebb OK found another issue unfortunately. If you cut power to the switch, it’ll go back to its old Off/On/On/On/Off self again once power is restored… 
Had to console “reset 6” and throw the template back in to get it working as I previously described. Fortunately total power loss is exceeding rare, so it wouldn’t be the end of the world if it can’t be fixed…
The fix has do with how the ESP32 communicates with the MCU. There is an impedance mismatch which requires the TX line to operate as an open drain with a 3.3v pull-up. When you apply power to the dimmer these options are not set. They only become set when configured through software. Its possible that once power is restored there exists a charge on the signal lines which interferes with communication. Does a simple reboot of the switch fix this or do you need to reapply the template. If its the later it might be an issue with the load order of functions for custom templates. Try using the Tuya MCU template directly instead of a custom template and see if that works better.
Does this happen when you change the brightness while the dimmer is already on? Or does this only happen when changing the brightness when the dimmer is off?
I ask because there is a quirk with this. If you shut off the dimmer by setting the brightness to 0. It does turn off the dimmer but the internal power state is incorrect. You should either use POWER command (instead of Dimmer) for on/off or issue power off after setting the brightness to 0. This also applies if you are playing the with dimmer levels and just happen to set it to 0 before trying other settings.
EDIT: I played around with the dimmer some more and I was also to replicate part of your issue. If I power on the dimmer by setting the Dimmer value it does not always take. It needs a power cycle to actually update the dimmer. This function appears similar to how the dimmer originally works-- the dimmer value cannot be changed without first power on. This might be a timing issue where the dimmer value is being updated too quickly after power on.