Costco Feit Smart Dimmer Tuya Convert Tasmota

@agglomerator, that “RTNETLINK answers: File exists” message is not on mine when flashing. Did you have another device connected to the AP while flashing. Anything interesting in the log files.

Maybe try again with multiple terminal window connected to the pi and view the different screens while trying to flash.

root@raspberrypi3-2:~# screen -r
There are several suitable screens on:
	3176.smarthack-udp	(05/14/2020 05:05:41 PM)	(Detached)
	3165.smarthack-psk	(05/14/2020 05:05:41 PM)	(Detached)
	3154.smarthack-mqtt	(05/14/2020 05:05:41 PM)	(Detached)
	3143.smarthack-web	(05/14/2020 05:05:41 PM)	(Detached)
	3061.smarthack-wifi	(05/14/2020 05:05:36 PM)	(Detached)


New test build up on github. Please try it out and see if it fixes the issues on your dimmer. https://github.com/TheEebb/tasmota-tuyamcu-fix/releases

Hello Andy - Mine is the same as @Technowizard:
FCC: ID: SYW-DIMWIFI
IC: 20416-DIMWIFI

Your build seems fine so far, have not been able to get it out of sync.

That’s good news. If I can get a few more tester to validate this I’ll push the fix up to mainline tasmota.

I’m not having such luck. As soon as I input the Dimmerrange 10,1000 console command, I’m back to having the missed input again. Until that point it does work, and if I set it back to its default Dimmerrange 0,100 it works fine again. I’ll keep messing with it… maybe I’ll figure something out.

Hello Andy - tried it again with same results. The main console (I didn’t save it) was just generating dots when I cancelled it after 2 hours. Here’s the output from my log files.

Smarthack-mqtt.log

1589764448: mosquitto version 1.4.10 (build date Wed, 13 Feb 2019 00:45:38 +0000) starting
1589764448: Using default config.
1589764448: Opening ipv4 listen socket on port 1883.
1589764448: Opening ipv6 listen socket on port 1883.

Smarthack-psk.log - nothing

Smarthack-wifi.log

Backing up NetworkManager.cfg...
Restarting NetworkManager...
Backing up /etc/dnsmasq.conf...
Writing dnsmasq config file...
Creating new /etc/dnsmasq.conf...
Writing hostapd config file...
Configuring AP interface...
Applying iptables rules...
Starting DNSMASQ server...
Starting AP on wlan0 in screen terminal...
Configuration file: /etc/hostapd/hostapd.conf
Using interface wlan0 with hwaddr 74:da:38:89:be:38 and ssid "vtrust-flash"
wlan0: interface state UNINITIALIZED->ENABLED
wlan0: AP-ENABLED
wlan0: STA 84:ad:8d:8d:0a:ac IEEE 802.11: authenticated
wlan0: STA 84:ad:8d:8d:0a:ac IEEE 802.11: associated (aid 1)
wlan0: AP-STA-CONNECTED 84:ad:8d:8d:0a:ac
wlan0: STA 84:ad:8d:8d:0a:ac RADIUS: starting accounting session AC36834D5C18B0C7
wlan0: STA 84:ad:8d:8d:0a:ac WPA: pairwise key handshake completed (RSN)
wlan0: AP-STA-DISCONNECTED 84:ad:8d:8d:0a:ac
wlan0: STA 84:ad:8d:8d:0a:ac IEEE 802.11: deauthenticated due to local deauth request
wlan0: STA 84:ad:8d:8d:0a:ac IEEE 802.11: authenticated
wlan0: STA 84:ad:8d:8d:0a:ac IEEE 802.11: associated (aid 1)
wlan0: AP-STA-CONNECTED 84:ad:8d:8d:0a:ac
wlan0: STA 84:ad:8d:8d:0a:ac RADIUS: starting accounting session 51F0E103FFFC914E
wlan0: STA 84:ad:8d:8d:0a:ac WPA: pairwise key handshake completed (RSN)
wlan0: AP-STA-DISCONNECTED 84:ad:8d:8d:0a:ac
wlan0: STA 84:ad:8d:8d:0a:ac IEEE 802.11: deauthenticated due to local deauth request
wlan0: STA 84:ad:8d:8d:0a:ac IEEE 802.11: authenticated
wlan0: STA 84:ad:8d:8d:0a:ac IEEE 802.11: associated (aid 1)
wlan0: AP-STA-CONNECTED 84:ad:8d:8d:0a:ac
wlan0: STA 84:ad:8d:8d:0a:ac RADIUS: starting accounting session 76C48C5573289A51
wlan0: STA 84:ad:8d:8d:0a:ac WPA: pairwise key handshake completed (RSN)
wlan0: AP-STA-DISCONNECTED 84:ad:8d:8d:0a:ac
wlan0: STA 84:ad:8d:8d:0a:ac IEEE 802.11: deauthenticated due to local deauth request
wlan0: STA 84:ad:8d:8d:0a:ac IEEE 802.11: authenticated
wlan0: STA 84:ad:8d:8d:0a:ac IEEE 802.11: associated (aid 1)
wlan0: AP-STA-CONNECTED 84:ad:8d:8d:0a:ac
wlan0: STA 84:ad:8d:8d:0a:ac RADIUS: starting accounting session 58690E8CCF9BFCC2
wlan0: STA 84:ad:8d:8d:0a:ac WPA: pairwise key handshake completed (RSN)
wlan0: AP-STA-DISCONNECTED 84:ad:8d:8d:0a:ac
wlan0: STA 84:ad:8d:8d:0a:ac IEEE 802.11: deauthenticated due to local deauth request
wlan0: STA 84:ad:8d:8d:0a:ac IEEE 802.11: authenticated
wlan0: STA 84:ad:8d:8d:0a:ac IEEE 802.11: associated (aid 1)
wlan0: AP-STA-CONNECTED 84:ad:8d:8d:0a:ac
wlan0: STA 84:ad:8d:8d:0a:ac RADIUS: starting accounting session 43472F26C3436B41
wlan0: STA 84:ad:8d:8d:0a:ac WPA: pairwise key handshake completed (RSN)
wlan0: AP-STA-DISCONNECTED 84:ad:8d:8d:0a:ac
wlan0: STA 84:ad:8d:8d:0a:ac IEEE 802.11: deauthenticated due to local deauth request
wlan0: STA 84:ad:8d:8d:0a:ac IEEE 802.11: authenticated
wlan0: STA 84:ad:8d:8d:0a:ac IEEE 802.11: associated (aid 1)
wlan0: AP-STA-CONNECTED 84:ad:8d:8d:0a:ac
wlan0: STA 84:ad:8d:8d:0a:ac RADIUS: starting accounting session 690175F2992B8797
wlan0: STA 84:ad:8d:8d:0a:ac WPA: pairwise key handshake completed (RSN)
wlan0: AP-STA-DISCONNECTED 84:ad:8d:8d:0a:ac
wlan0: STA 84:ad:8d:8d:0a:ac IEEE 802.11: deauthenticated due to local deauth request
wlan0: STA 84:ad:8d:8d:0a:ac IEEE 802.11: authenticated
wlan0: STA 84:ad:8d:8d:0a:ac IEEE 802.11: associated (aid 1)
wlan0: AP-STA-CONNECTED 84:ad:8d:8d:0a:ac
wlan0: STA 84:ad:8d:8d:0a:ac RADIUS: starting accounting session 9FDED6CBBC62E6DD
wlan0: STA 84:ad:8d:8d:0a:ac WPA: pairwise key handshake completed (RSN)
wlan0: AP-STA-DISCONNECTED 84:ad:8d:8d:0a:ac
wlan0: STA 84:ad:8d:8d:0a:ac IEEE 802.11: deauthenticated due to local deauth request
wlan0: STA 84:ad:8d:8d:0a:ac IEEE 802.11: authenticated
wlan0: STA 84:ad:8d:8d:0a:ac IEEE 802.11: associated (aid 1)
wlan0: AP-STA-CONNECTED 84:ad:8d:8d:0a:ac
wlan0: STA 84:ad:8d:8d:0a:ac RADIUS: starting accounting session F9967055A5D7261E
wlan0: STA 84:ad:8d:8d:0a:ac WPA: pairwise key handshake completed (RSN)
wlan0: STA 84:ad:8d:8d:0a:ac WPA: group key handshake completed (RSN)
wlan0: AP-STA-DISCONNECTED 84:ad:8d:8d:0a:ac
wlan0: STA 84:ad:8d:8d:0a:ac IEEE 802.11: deauthenticated due to local deauth request
wlan0: STA 84:ad:8d:8d:0a:ac IEEE 802.11: authenticated
wlan0: STA 84:ad:8d:8d:0a:ac IEEE 802.11: associated (aid 1)
wlan0: AP-STA-CONNECTED 84:ad:8d:8d:0a:ac
wlan0: STA 84:ad:8d:8d:0a:ac RADIUS: starting accounting session 7A24D8F3DB1C3082
wlan0: STA 84:ad:8d:8d:0a:ac WPA: pairwise key handshake completed (RSN)
wlan0: AP-STA-DISCONNECTED 84:ad:8d:8d:0a:ac
wlan0: STA 84:ad:8d:8d:0a:ac IEEE 802.11: deauthenticated due to local deauth request
wlan0: STA 84:ad:8d:8d:0a:ac IEEE 802.11: authenticated
wlan0: STA 84:ad:8d:8d:0a:ac IEEE 802.11: associated (aid 1)
wlan0: AP-STA-CONNECTED 84:ad:8d:8d:0a:ac
wlan0: STA 84:ad:8d:8d:0a:ac RADIUS: starting accounting session 28AAB943B55B7184
wlan0: STA 84:ad:8d:8d:0a:ac WPA: pairwise key handshake completed (RSN)
wlan0: AP-STA-DISCONNECTED 84:ad:8d:8d:0a:ac
wlan0: STA 84:ad:8d:8d:0a:ac IEEE 802.11: deauthenticated due to local deauth request
wlan0: STA 84:ad:8d:8d:0a:ac IEEE 802.11: authenticated
wlan0: STA 84:ad:8d:8d:0a:ac IEEE 802.11: associated (aid 1)
wlan0: AP-STA-CONNECTED 84:ad:8d:8d:0a:ac
wlan0: STA 84:ad:8d:8d:0a:ac RADIUS: starting accounting session 38666E73EB27A465
wlan0: STA 84:ad:8d:8d:0a:ac WPA: pairwise key handshake completed (RSN)
wlan0: AP-STA-DISCONNECTED 84:ad:8d:8d:0a:ac
wlan0: STA 84:ad:8d:8d:0a:ac IEEE 802.11: deauthenticated due to local deauth request
wlan0: STA 84:ad:8d:8d:0a:ac IEEE 802.11: authenticated
wlan0: STA 84:ad:8d:8d:0a:ac IEEE 802.11: associated (aid 1)
wlan0: AP-STA-CONNECTED 84:ad:8d:8d:0a:ac
wlan0: STA 84:ad:8d:8d:0a:ac RADIUS: starting accounting session 7756A3994CB50326
wlan0: STA 84:ad:8d:8d:0a:ac WPA: pairwise key handshake completed (RSN)
wlan0: STA 84:ad:8d:8d:0a:ac WPA: group key handshake completed (RSN)
wlan0: AP-STA-DISCONNECTED 84:ad:8d:8d:0a:ac
wlan0: STA 84:ad:8d:8d:0a:ac IEEE 802.11: deauthenticated due to local deauth request
wlan0: STA 84:ad:8d:8d:0a:ac IEEE 802.11: authenticated
wlan0: STA 84:ad:8d:8d:0a:ac IEEE 802.11: associated (aid 1)
wlan0: AP-STA-CONNECTED 84:ad:8d:8d:0a:ac
wlan0: STA 84:ad:8d:8d:0a:ac RADIUS: starting accounting session DAEC4198A2418F2E
wlan0: STA 84:ad:8d:8d:0a:ac WPA: pairwise key handshake completed (RSN)
wlan0: AP-STA-DISCONNECTED 84:ad:8d:8d:0a:ac
wlan0: STA 84:ad:8d:8d:0a:ac IEEE 802.11: deauthenticated due to local deauth request
wlan0: STA 84:ad:8d:8d:0a:ac IEEE 802.11: authenticated
wlan0: STA 84:ad:8d:8d:0a:ac IEEE 802.11: associated (aid 1)
wlan0: AP-STA-CONNECTED 84:ad:8d:8d:0a:ac
wlan0: STA 84:ad:8d:8d:0a:ac RADIUS: starting accounting session E065AABD02D5B8F7
wlan0: STA 84:ad:8d:8d:0a:ac WPA: pairwise key handshake completed (RSN)
wlan0: AP-STA-DISCONNECTED 84:ad:8d:8d:0a:ac
wlan0: STA 84:ad:8d:8d:0a:ac IEEE 802.11: deauthenticated due to local deauth request
wlan0: STA 84:ad:8d:8d:0a:ac IEEE 802.11: authenticated
wlan0: STA 84:ad:8d:8d:0a:ac IEEE 802.11: associated (aid 1)
wlan0: AP-STA-CONNECTED 84:ad:8d:8d:0a:ac
wlan0: STA 84:ad:8d:8d:0a:ac RADIUS: starting accounting session 3DE9DD8BD29DF885
wlan0: STA 84:ad:8d:8d:0a:ac WPA: pairwise key handshake completed (RSN)
wlan0: AP-STA-DISCONNECTED 84:ad:8d:8d:0a:ac
wlan0: STA 84:ad:8d:8d:0a:ac IEEE 802.11: deauthenticated due to local deauth request
wlan0: STA 84:ad:8d:8d:0a:ac IEEE 802.11: authenticated
wlan0: STA 84:ad:8d:8d:0a:ac IEEE 802.11: associated (aid 1)
wlan0: AP-STA-CONNECTED 84:ad:8d:8d:0a:ac
wlan0: STA 84:ad:8d:8d:0a:ac RADIUS: starting accounting session B4FCE7278DAE5FCC
wlan0: STA 84:ad:8d:8d:0a:ac WPA: pairwise key handshake completed (RSN)
wlan0: AP-STA-DISCONNECTED 84:ad:8d:8d:0a:ac
wlan0: STA 84:ad:8d:8d:0a:ac IEEE 802.11: deauthenticated due to local deauth request
wlan0: STA 84:ad:8d:8d:0a:ac IEEE 802.11: authenticated
wlan0: STA 84:ad:8d:8d:0a:ac IEEE 802.11: associated (aid 1)
wlan0: AP-STA-CONNECTED 84:ad:8d:8d:0a:ac
wlan0: STA 84:ad:8d:8d:0a:ac RADIUS: starting accounting session ECF732EF6B7FEE95
wlan0: STA 84:ad:8d:8d:0a:ac WPA: pairwise key handshake completed (RSN)
wlan0: AP-STA-DISCONNECTED 84:ad:8d:8d:0a:ac
wlan0: STA 84:ad:8d:8d:0a:ac IEEE 802.11: deauthenticated due to local deauth request
wlan0: STA 84:ad:8d:8d:0a:ac IEEE 802.11: authenticated
wlan0: STA 84:ad:8d:8d:0a:ac IEEE 802.11: associated (aid 1)
wlan0: AP-STA-CONNECTED 84:ad:8d:8d:0a:ac
wlan0: STA 84:ad:8d:8d:0a:ac RADIUS: starting accounting session 0E20B50E3C96E725
wlan0: STA 84:ad:8d:8d:0a:ac WPA: pairwise key handshake completed (RSN)
wlan0: AP-STA-DISCONNECTED 84:ad:8d:8d:0a:ac
wlan0: STA 84:ad:8d:8d:0a:ac IEEE 802.11: deauthenticated due to local deauth request
wlan0: STA 84:ad:8d:8d:0a:ac IEEE 802.11: authenticated
wlan0: STA 84:ad:8d:8d:0a:ac IEEE 802.11: authenticated
wlan0: STA 84:ad:8d:8d:0a:ac IEEE 802.11: associated (aid 1)
wlan0: AP-STA-CONNECTED 84:ad:8d:8d:0a:ac
wlan0: STA 84:ad:8d:8d:0a:ac RADIUS: starting accounting session A6C744A6CA4C1368
wlan0: STA 84:ad:8d:8d:0a:ac WPA: pairwise key handshake completed (RSN)
wlan0: AP-STA-DISCONNECTED 84:ad:8d:8d:0a:ac
wlan0: STA 84:ad:8d:8d:0a:ac IEEE 802.11: deauthenticated due to local deauth request
wlan0: STA 84:ad:8d:8d:0a:ac IEEE 802.11: authenticated
wlan0: STA 84:ad:8d:8d:0a:ac IEEE 802.11: associated (aid 1)
wlan0: AP-STA-CONNECTED 84:ad:8d:8d:0a:ac
wlan0: STA 84:ad:8d:8d:0a:ac RADIUS: starting accounting session 90456BF695C44F07
wlan0: STA 84:ad:8d:8d:0a:ac WPA: pairwise key handshake completed (RSN)

Smarthack-web.log


Listening on port 80

Smarthack-smartconfig.log

Put Device in Learn Mode! Sending SmartConfig Packets now
Sending SSID                  vtrust-flash
Sending wifiPassword          flashmeifyoucan
SmartConfig in progress
..........
SmartConfig complete.

@TheEebb You sir are a steely-eyed missile man! For those on here still having issues, Ebb’s 4th firmware (v0.52) is working pretty solid for me now! I did have to power cycle it once after loading the firmware, as it wouldn’t take any console commands properly (stuck in the “55aa00000000ff” timeout loop). After that, it works like a charm! Thanks again Ebb, and please don’t hesitate if you need my help for more testing! :slight_smile:

I noticed that the dimmer doesn’t always connect to the MCU when upgrading the firmware after a reset. But I couldn’t make it fail after a power cycle or extended power off. So you should be ok if your home looses power.

There’s still a few other features that have not been implemented so there’s at least another version I’m going to release before submitting the code to Tasmota. But at least the ongoing but looks like its been fixed. fingers crossed

No problem. I have some of these dimmers too so I’m motivated to get them working

@TheEebb I loaded your latest build on a dimmer last night and noticed the issue with the mcu not connecting. This would even occur even after a power cycle, reset, or restart 80% of the time. Once I held the power button down for a few seconds the serial connection between the tuya mcu and the esp module would establish. I would then be able to set the commands to enable the dimmer and dimmer range. I still have more testing to do with it.

Does this still occur after everything is completely configured?

I have not noticed this during restarts once everything is correctly running. I did notice this during the upgrade process and occasionally when configuring dpids and dimmer range. Its difficult to say what the issue is. I connected a stock dimmer to my logic analyzer and didn’t see it doing anything special during start up. Unfortunately the WIFI module is not connected to the MCU in anyway where you can issue a reset. The WIFI module is only connected via two serial pins.

I’ll look into this but my gut is telling me this may not be resolvable since Tasmota isn’t specifically written around the function of a single device.

EDIT: It just came to mind… I’m going to make a build that applies the “TX Special” fix during each boot. See if that does anything for you.

EDIT2: A new build is in github with the fix applied

To add to the above, I’ve had to re-power cycle switches I have your previous firmware fix on (v0.52) when I later changed their GroupTopic for Tasmota group control. Also on that related topic, I had a weird group control issue. It might just be a Tasmota issue/bug (your forked v8.2.0 was their 1st release to offer this feature), but when I hit the brightness buttons on the dimmer that is grouped to a WiFi light, the light will simply turn off if the dimmer’s brightness was 1st changed by a direct change to the WiFi light… I have to turn the dimmer off then back on (i.e. button press - not power cycle) to regain control. After that it works just fine. Again might just be a Tasmota bug, but thought I’d point it out. I have some Martin Jerry dimmers I’m going to try it on soon, so I’ll let you know if it’s a Tasmota / v8.2.0 specific bug, or just a Feit dimmer bug.

Which other feature(s) were you looking at implementing / fixing? The big one I was unable to get working on stock Tasmota was the Hold / Long press feature. I haven’t tried this yet with your firmware fix… heck I’m just happy it’s working as a dimmer! :slight_smile:

I’ve never played with that feature so I don’t know how it works. But I’ll look into it to see if it does something different.

That’s not possible. The MCU handles the buttons so the WIFI module has no access to them.

It would take one of the following to make it work:

  • A MCU firmware hack. Unlikely unless someone wants to spend the time to disassemble the code.
  • The simpler option requires a modest amount of electronics skills. You can simply solder a connection from one or more of the buttons to the unused GPIO pins on the WIFI module. All the exposed GPIOs are currently unused except the serial pins. If you’re worried about the warranty-- any module you send back would have Tasmota loaded on it. There is currently no way to restore the stock firmware without using a hot air station to remove the WIFI module.
  • Hijack the WIFI reset. This means you loose this function and you must also hold down the button for 4-5s each time.

The features have more to do with customizing the functions of TuyaMCU. Currently the code rewrite makes it flexible enough to accommodate new unknown devices. However, these settings are not currently exposed so there is no way to configure them. I’m adding in the appropriate options for console/MQTT control.

Simple enough for me to accomplish (25+ years electronics / avioncis tech experience), but honestly not worth the effort. I managed to get my hands on several MJ dimmers as I mentioned @ half price, and have already replaced my Feits that were in areas that I was really wanting that feature. My remaining Feits are in areas where I needed 3-way switches (MJ 3-way dimmers don’t use ESP chipsets), or where aesthetics count a bit more… which let’s face it the Feit is a bit more slimline and slightly easier on the eyes than the MJ dimmers.

Yeah it’s the first time I’m messing with this feature as well. I sometimes use Alexa to adjust WiFi lights that the dimmer controls via HA; however, I never liked the automation I used for these switches to match the bulbs’ brightness levels to keep the next button press from significantly jumping levels (it’s a bit twitchy). The Tasmota grouping feature actually works amazingly well at this, and the best part is that it still lets the dimmer control the WiFi bulb without HA being up… definitely saving me from sighs and evil glares from the wife when I need to restart the server! LOL! Like I said it could just be a Tasmota v8.2.0 bug since this was the initial release. I’ll try it out on other switches, newer Tasmota versions, or even with stock Tasmota on the Feits to see what it does, and report back to you.

That’s exactly what I like about them. They are the only dimmers of western design that I know of using ESP chips. Which is really surprising; and a win for a company like Tuya. Most of the ESP dimmers are either direct imports or rebrands. The Feits blend in with all the common decorator style switches you find at a big box store.

I also receive “creative feedback” whenever I monkey with the home automation. Which is why I try never to touch anything the spouse decides she likes using. I ended up running a small Openwrt based device with a lightweight MQTT broker and hardcoded php script that handles basic automation functions. It serves as a failover when I tinker. That’s what I like about Tasmota. There’s a second WIFI AP the device tries to connect to when the first one is down. I simply drop the IOT connections from the house WIFI let it run on the backup device, do my thing, and take down the back up and it swaps back over.

That’s not a bad idea. Currently if I plan to work on the server in a way that might interfere with HA / Node Red server, I use a flow I recently made in Node Red to push out a MQTT command to my Tasmota devices (all or by room) to enable / disable the group control, as well as change rules to simple device-to-device automation control. Sure it loses the more advanced automations I have running, but it keeps all the switches and lights functioning at least as well as non-smart lights/switches would do. It’s part of the reason I really wanted Tasmota on these Feits… ESPhome, besides being a bit twitchy still with these dimmers honestly, just wasn’t able to do this on the fly like Tasmota can. Tasmota also has built-in wemo and hue emulation, which again helps everything work without HA being up and running.

@TheEebb,

Just checking in to see if you need any further testers or if your code has made it into a Tasmota release. Sorry if I missed it in this thread.

I’ve been using 4 of these dimmers from Costco for a while now running Tasmota 8.1.0.2, which occasionally disconnect from my wifi. So I decided to try and upgrade one of them to the newest version 8.3.1.

After doing so, the SW based dimming settings (0-100 percent) don’t match the dim setting of the physical switch and the brightness of the bulb.

For example, if I tell it to go to 50% brightness, I expect to see 3 of the 5 LEDs lite up on the switch itself and a certain brightness level of the bulb. But what I see is only 1 status LED lit up and the blub is very dim.
If I use the physical switch to set the dim value, at 50%, I see 3 of the 5 status LEDs lit and the brightness of the bulb is much brighter.
I did monitor the log when going from dim->bright and I see it goes from 10 to 1000, so I programmed it with:
DimmerRange 10,1000

Which works fine on 8.1.0.2, but not on 8.1.3.

Has anyone else had any problems like this?

Yes, please. Do test the special build and leave feedback if possible.

I’m currently cleaning up the code and rebuilding it for Tasmota 8.3. I’ll release another version shortly. It will not contain additional fixes unless someone reports an issue.

You need to apply “LedTable 0”. This disables gamma correction and should result in a linear mapping as expected by the dimmer.