Firmware for Tuya dimmer

[davebuk]

Hi all. How can I look to build a firmware for the following device:
https://www.amazon.co.uk/OurLeeme-Dimmer-Control-Function-Compatible/dp/B07RHCFKQ2

I have got one coming this week so I won't know what chip setup is inside but will post when I do. I wonder if the Sonoff wall dimmer will work as base code?

[davebuk]

@mcspr @xoseperez
Hi all. The device has arrived. Is it as simple as using a standard dimmer environment and changing the GPIO config, or does a separate environment need to be created?

UPDATE**

Pin locations if others need them. To flash, the fourth pin 'Flash' needs to be held at GND before power applied and kept at GND during flashing. I think it disables Tx/Rx communication to the MCU. You then need to boot with the GPIO 0 pin held to GND, then released a few seconds after boot. The Tx/Rx wires need to be connected directly to the TYWE3S pins.

[mcspr]

Yes. Since you are just testing, anything with LIGHT dimmer would do. Just make sure to use 1MB environment

[davebuk]

Great, I'll have a go at the weekend. Is there a way to find out the GPIO assignments? Looking at the soldered board, GPIO 0, 14 and 15 are connected. I guess the on board button connects to 'RST' and maybe 0 for BOOT, so is the 'BUTTON' GPIO (not sure if this needs to be defined for the dimmer hardware).

Other than that, I also guess 14 / 15 control the two colour LED and the opposite one controls the dimmer output? One will be the 'LED' GPIO and the other will be the 'LIGHT' GPIO.

[mcspr]

Use multimeter? Button thing is interesting, because it kind-of does different things - GPIO0 for flash / some SW button control, but RST will reset the chip itself. No software interaction there.
TX RX are going to the secondary MCU then? (or I am missing some turn)

[davebuk]

The only measurement I got was 9K ohms from one of the ESP pins to one of the LED legs. Other resistances were around 2M ohm.

I need to work out which of the two header pins are TX and RX respectively, but 3v3 and ground are obvious. I guess the through hole header pin pads would be the ones to use for flashing, or should I take wires directly from the ESP chip Tx/ Rx connections?

Thanks.

[mcspr]

Either way. I sure does look like tx rx are right there.

About dimming, it looks like manufacturer used Tuya SDK to set up the secondary controller. Tasmota repo already has an example of what it sends / receives:
https://docs.tuya.com/en/mcu/mcu-protocol.html
https://github.com/arendst/Sonoff-Tasmota/blob/development/sonoff/xdrv_16_tuyadimmer.ino

[davebuk]

How do the dimming signals work for an espurna LED dimmer. Do they send signals using the Tx/Rx lines to a MCU which then controls the output drivers?

[mcspr]

What I mean is we don't have LIGHT_PROVIDER for Tuya SDK dimmer variant (yet), if this thing uses serial communication with secondary MCU.
Most common LIGHT_PROVIDER_DIMMER generates PWM signal on gpio pin, which translates into brightness.

[davebuk]

The two header solder pads that probably are TX/ Rx are not directly connected to the TX/ Rx of the ESP, they are connected to the STM8S003F3 chip below. I was unsure how the dimming was controlled using a single GPIO.

How long would it take to bring serial dimming into espurna? I may go and have a little play with tasmota for this device.

[mcspr]

It would be useful to know if it is really using that serial protocol.
Something like this is already done for rfbridge, so at least writing Serial logic would not be a big problem. Basic idea that I got from the Tuya docs is that ESP should send out heartbeat messages when it boots (every 3s, flagged 0x00) and during normal operation (every 10s, flagged 0x01), then the second controller will accept commands / send out current state.

Another thing to do while it is wired is to download the original firmware .bin via esptool.py (0x100000 as size).
edit: baud setting may vary, maybe use 115200 to be safe

[davebuk]

Trying to upload tasmota using pins on the board or pins wired directly to the TYWE3S fails. I don't get communication. Tried with button held at boot, button still held after boot, GPIO 0 to GND at boot and held to GND after boot with no success. The device is not in normal operation so it's doing something different at boot, plus the status LED flashes green after a few seconds then stays very dimly lit green.

I've not used esptool other than the espeasy GUI version to flash. I'll have to look at this over the next few days and see if I can first establish communication then get the current firmware extracted.

[mcspr]

Is it the same with GPIO0? Not aware of GPIO2 operation, this wiki states that it needs to be high:
https://github.com/esp8266/esp8266-wiki/wiki/Boot-Process#esp-boot-modes

One thing ESP should always do when resetting is output lines like these on GPIO1 (TX), at 74880 speed:

pressing RST button on d1 mini when GPIO0 is pulled LOW

 ets Jan  8 2013,rst cause:2, boot mode:(1,7)

pressing RST without anything connected

 ets Jan  8 2013,rst cause:2, boot mode:(3,7)

load 0x4010f000, len 1384, room 16
tail 8
chksum 0x2d
csum 0x2d
v8b899c12 < this is eboot from Arduino, after this line things are sw-specific 
~ld

[davebuk]

Sorry, meant GPIO 0 not 2, post above edited. Apologies!

[davebuk]

I'm am having issues trying to confirm I have connection, but connected to ESP chip Tx/Rx and carrying out the above using putty I get:

ets Jan  8 2013,rst cause:2, boot mode:(1,2)

ets Jan  8 2013,rst cause:2, boot mode:(3,2)

load 0x40100000, len 2592, room 16
tail 0
chksum 0xf3
load 0x3ffe8000, len 764, room 8
tail 4
chksum 0x92
load 0x3ffe82fc, len 676, room 4
tail 0
chksum 0x22
csum 0x22

2nd boot version : 1.7(5d6f877)
SPI Speed : 40MHz
SPI Mode : QIO
SPI Flash Size & Map: 8Mbit(512KB+512KB)
jump to run user1 @ 1000

OS SDK ver: 2.0.0(e8c5810) compiled @ Jan 25 2019 14:26:04
phy ver: 1055_9, pp ver: 10.7

rf cal sector: 121
idle_task_hdl : 40107a90,prio:0, stack:384
tim_task_hdl : 40107bd8, prio:2,stack:512

[mcspr]

But it works. Second log is non-Arduino bootloader, logging that it loaded the manufacturer's firmware. Which now can be safely backed up by esptoolpy and something else uploaded instead

[davebuk]

I have tried

esptool.py -p COM3 -b 1155200 chip_id
and
esptool.py -p COM3 -b 115200 read_flash 0 0x100000 flash_contents.bin
after setting GPIO 0 to GND during boot and neither work. Constant time out errors. One time I had, invalid head of packet 0xff but can't get esptool.py chip_id to output anything.

[mcspr]

Does it work without the -b ... param?

[davebuk]

Nope. :-)

c:\Python27\Scripts>esptool.py -p COM3 read_flash 0 0x100000 flash_contents.bin
esptool.py v2.6
Serial port COM3
Connecting........_____....._____....._____....._____....._____....._____....._____

A fatal error occurred: Failed to connect to Espressif device: Timed out waiting for packet header

c:\Python27\Scripts>esptool.py -p COM3 chip_id
esptool.py v2.6
Serial port COM3
Connecting........_____....._____....._____....._____....._____....._____....._____

A fatal error occurred: Failed to connect to Espressif device: Timed out waiting for packet header

c:\Python27\Scripts>

[davebuk]

Trying same thing on a Sonoff Basic V2 with espurna on gives:

c:\Python27\Scripts>esptool.py chip_id
esptool.py v2.6
Found 1 serial ports
Serial port COM3
Connecting....
Detecting chip type... ESP8266
Chip is ESP8285
Features: WiFi, Embedded Flash
MAC: 84:0d:8e:57:a1:15
Uploading stub...
Running stub...
Stub running...
Chip ID: 0x0057a115
Hard resetting via RTS pin...

[mcspr]

Maybe slower? -b 9600 If it fails seemingly at random, maybe wiring is causing problems.
Putty can show boot mode, to make sure uploader mode is on. We want a single line with (1,...). Just make sure to disconnect putty before running esptool itself

[davebuk]

No different at 9600. I'll do some more testing over the next few days and see what I can up with.

[davebuk]

Got it. Using info from [(https://github.com/arendst/Sonoff-Tasmota/wiki/Tuya-Dimmer)], I connected GND to the forth header pin while booting and holding GPIO 0 to ground. I now have:

c:\Python27\Scripts>esptool.py chip_id
esptool.py v2.6
Found 1 serial ports
Serial port COM3
Connecting....
Detecting chip type... ESP8266
Chip is ESP8266EX
Features: WiFi
MAC: bc:dd:c2:a6:cc:bd
Uploading stub...
Running stub...
Stub running...
Chip ID: 0x00a6ccbd
Hard resetting via RTS pin...

[davebuk]

Downloaded file is here:
flash_contents.zip

Thanks for your help. Am I ok to try Tasmota on this device now?

[mcspr]

Yes. Thank you for the file! I just tried it with 1M dev board and see the heartbeat on hw serial, as expected. If you don't mind going slightly offtopic, can you try uploading some basic (literally sonoff-basic should be ok for both espurna and tasmota) espurna image first? I was not able to reproduce the issue from #1663 and I wonder if recent dev builds solved it or I am missing some other bug because of espota.py usage. I tried upgrading via Web too, no problems :/

[davebuk]

No problem. Just to be sure, you would like espurna dev uploaded via esptool then once initialised, try tasmota using espurna web OTA?

[mcspr]

Correct. The test is if Tasmota sonoff.bin or sonoff-basic.bin work after updating from ESPurna via Web OTA

[davebuk]

Working correctly for me. Uploaded a self built version of Sonoff Basic 1.13.6dev of espurna using esptool.py. Espurna boots correctly and I connected to my WiFi. Re-booted then used espurna OTA to flash Tasmota 'sonoff.bin'. Rebooted and device is now showing as sonoff device in wireless networks. Connected and setup Tasmota WiFi credentials and device is now connected to my WiFi and accessible using Tasmota web GUI.

Hope that is of some help?

[davebuk]

The dimmer works with Tasmota using device configuration 'Tuya Dimmer 54'. ON/OFF toggle and dimming works using web GUI.

[mcspr]

Great. Thanks for checking the OTA process!

Now the only thing left is to implement tuya dimmer module.

[mcspr]

Nice. Since it does not blow up the runtime anymore, might as well add this to the dev branch and work out further quirks.

Regarding brightness, maybe some constant can control it in the settings.
dev...mcspr:format-fixes adds LIGHT_MIN_VALUE define that is set for every channel manipulation routine as the min value. Also LIGHT_MIN_BRIGHTNESS to accompany it. But idk how it would interact with tuya thing, there could be some bugs. Plus, that branch also should be around 500 bytes less in size
(edit note that it needs to be merged locally, there is no Tuya module there!)

Default configuration total size grew about ~3KB since the latest release.
You can safely disable some of those, like DEBUG_TELNET_SUPPORT & TELNET_SUPPORT (-3KB interestingly enough), THINGSPEAK_SUPPORT (around the same 3KB). Light support somewhat bulky for just white lights and Tuya module itself could also use some size improvements.
Debugging altogether can also be disabled, since those strings take around 16KB, but that's another issue, since terminal is hidden away in the WebUI for some reason.

[riogrande75]

Hi!
Dunno if I'm really correct here, but it fit's pretty good and I did not want to open a new issue yet.
I have a pretty similar Tyua device, called "Smart Garage Door Controller" (https://www.amazon.de/Garagentor%C3%B6ffner-Maxcio-Kompatibel-Steuerung-Betriebsaufzeichnung/dp/B07Q57CQ2B/.
Opened up it looks like this

It is based on a TYWE2S (ESP8285) and a STM8S003F4 mcu just like the dimmer discussed here. It also ran tuya firmware originaly. Also relay, led an door-closed sensor are controlled by mcu via serial tuya protocol commands.

Switch relay: SerialSend5 55 aa 00 06 00 05 01 01 00 01 01 0e
sonoff-2168 ESP-MQT: tele/sonoff/RESULT = {"SerialReceived":"55aa03070005010100010011"}
sonoff-2168 ESP-MQT: tele/sonoff/RESULT = {"SerialReceived":"55aa03070005010100010112"}

Close and open the door-sensor:
sonoff-2168 ESP-MQT: tele/sonoff/RESULT = {"SerialReceived":"55aa0307000565010001007555aa03070005010100010011"}
sonoff-2168 ESP-MQT: tele/sonoff/RESULT = {"SerialReceived":"55aa0307000565010001017655aa03070005010100010112"}

Got feedback from another DpId, guess it's the LED controlled by MCU:
sonoff-2168 ESP-MQT: tele/sonoff/RESULT = {"SerialReceived":"55aa0307000807020004000000001e"}

I managed to flash tasmota and espeasy firmware so far. At least with tasmota I was able to communicate with the device via the "SerialSend5 55aa..." commands.
Unfortunately there is obviously no direct support for it in espurna so far.

Do you guys think, when adding the "tuya" dimmer it would be possible to get support for the smart door controller as well?

[mcspr]

@riogrande75 Hey. The way build works right now, lights support is optional and is enabled by using LIGHT_PROVIDER_TUYA and some automatic dependency resolution in the headers (ref #1729 (comment)). Instead, you can just add TUYA_SUPPORT set to 1 and it will build with just basic switches, since we don't support anything else right now.
edit: and I mean this dev...mcspr:experimental/tuya branch, as it is not yet merged here

2nd SerialReceived shows 2 messages: "55aa03070005650100010075" and "55aa03070005010100010011". Both door sensor and switch send out boolean values which we treat as relay internally (and I would expect that the firmware will create 2 virtual relays on boot).
Specific DPid are 65 (sensor) and 1 (switch)

[davebuk]

@mcspr You said about adding the current code to the Dev branch. If that is there case I'll mark this thread as closed.

[mcspr]

@davebuk issue will auto-close once it is merged btw, since it will be a pr

[davebuk]

Hi @mcspr
I am having some issues trying to build using the 2.5.2 core. The standard build seems fine, but when I change the platform to 2_5_2 I get:

In file included from .pio\libdeps\tuya-generic-dimmer\NoFUSS\src\NoFUSSClient.cpp:21:0:
.pio\libdeps\tuya-generic-dimmer\NoFUSS\src\NoFUSSClient.h:27:31: fatal error: ESP8266httpUpdate.h: No such file or directory

***************************************************************************
* Looking for ESP8266httpUpdate.h dependency? Check our library registry!
*
* CLI  > platformio lib search "header:ESP8266httpUpdate.h"
* Web  > https://platformio.org/lib/search?query=header:ESP8266httpUpdate.h
*
***************************************************************************

 #include <ESP8266httpUpdate.h>
                               ^
compilation terminated.
*** [.pio\build\tuya-generic-dimmer\liba15\NoFUSS\NoFUSSClient.cpp.o] Error 1
==================================================================== [FAILED] Took 203.49 seconds ====================================================================

or

Linking .pio\build\tuya-generic-dimmer\firmware.elf
c:/users/samsung laptop/.platformio/packages/toolchain-xtensa/bin/../lib/gcc/xtensa-lx106-elf/4.8.2/../../../../xtensa-lx106-elf/bin/ld.exe: cannot open linker script 
file ../ld/eagle.app.v6.common.ld: No such file or directory
collect2.exe: error: ld returned 1 exit status
*** [.pio\build\tuya-generic-dimmer\firmware.elf] Error 1
==================================================================== [FAILED] Took 317.96 seconds ====================================================================

Do you have any idea what could be the problem? Thanks.

[mcspr]

Oops, sorry! Second one is because of the build system updates, I thought I had merged the #1559 there, guess not. You can manually cherry-pick the 437424a to make it work right now.
No idea about the nofuss, but if you are not using it just remove the NoFUSS line from the lib_deps = ... list in the .ini

I need to update the tuya branch though... Hopefuly soon

[davebuk]

The cherry pick worked, (once I found out how to do it)! Tuya dimmer now on 2.5.2 @ 559KB.

For my future reference, from platformio terminal, type: git cherry-pick <commit-hash> (git cherry-pick 437424a)

[dreamcat4]

So how difficult is it to get this device working? Because I was thinking about perhaps getting one of these. However my other option might be to use a low voltage control instead (eg esp3288 to 5v adc) and then connect that to a seperate ac dimmer via a potentiometer. Not decided yet.

[davebuk]

The device is working fine. I'm using it connected via mqtt to openHAB. I need to update the flashing details at the top of the post as I have marked the wrong pin on the chip for the GPIO 0 pin. If you are happy to use a soldering iron to get to the Tx/Rx pins, everything else is fairly straight forward.
@mcspr is going to look to get this added to the master branch. It may be easier to build once he's done that.

[dreamcat4]

Thank you @davebuk all of that sounds really lovely. And look forward to that. All very impressive & I look forward to this.

Actually for myself am still considering the other option because this specific dimmer is leading edge Triac. Well the device i wish to drive is probably going to be a 200w AC fan (1 amp on uk mains). What I heard from discussion with somebody else is that: most of these cheaper and more low end dimmer switches (such as this one) are not normally designed with inductive loads in mind. (As in: motors), and therefore might not include a 'snubber'. Whatever that is.

However I was also wondering if maybe this device can actually be modified to include extra components added for to make a snubber, or a capacitor / whatever it is to work against the inductive load. Therefore to be making a better handling for those usage scenarios. Or maybe it doesnt actually matter! so much for a lower wattage load which isn't going to kick back so much. And not to bother. This device is still a leading edge one though again: I don't really know how much that matters either. You get the initial spike and maybe it would be kinder to be smoothing out that leading edge impulse. I mean: kinder to whatever the other equipment is we are connecting to it. This may also be true for certain types of led lighting etc. Which then end up having their own converters inside them with flickering issues and whatnot.

SO what I am really saying is that: this device is already great for many other applications. And I also hope maybe we can figure out how to modify it to make it work even better. If anybody else has any ideas about that. Perhaps we can create a post in some other community to get such help. Like in the eevblog forums or elsewhere.

Personally won't be getting one of these to play with myself for quite a while yet. As thinking to add wifi functionality comes right at the end of my own project. In no hurry. I mean I guess I could just order one anyway from ali. They are only 8 quid from china. But it's also a case of actually finding the time to mess around with it once it gets here.

[dreamcat4]

OK in the end I spent an extra £4 and got this other one instead https://www.aliexpress.com/item/33031283451.html

Being traillng edge. So in about a month or 2 months should arrive and I can open a new separate issue... for yet another dimmer device (more is better, right?). Still very grateful for all the hard work that already went into this issue here. Because it's so well explained, and all may be used to help get the next one working! Thanks again.

[davebuk]

Like you said, I doubt either device circuit will drive an AC fan directly due to the inductive load of the motor. If the fan already has a 3 speed selection it could be controlled with some relays. The other option is to look for a PWM to AC inductive load convertor and use a standard GPIO output from a Sonoff basic setup as a light dimmer. No idea if such a circuit exists!

[falconchips]

Hi, davebuk

I've bought this dimmer a few weeks ago. I'm not planning to change the firmware for now, but I have an easy question: it's dimmable only through the app or voice...is there any way (soldering pins) to get the dimmer function with the physical button?

[davebuk]

@mcspr @falconchips Out of the box I'd say no. There was no indication in the instructions that you could dim with the switch. Max did start looking at a button hold implementation that would allow on/off and brightness up/down functions, but I'm not sure how far he got. The code side is pretty much over my head I'm afraid!

The other option is to have remote mqtt switches that send bright/dim payloads. I'm using openHAB as an mqtt server and interface but you may be able to use another protocol within espurna to achieve this?

[falconchips]

@davebuk

No, I also bought another Tuya dimmer that allows dimmer with the button but it has so much lag (you press the button and light turns on about 1,5 sec after; it's annoying) so I'm not really into changing firmware, just wondering if may be an easy way to add dimmer function with the button.

[keesdekraker]

Hi,

First of all, great work and many thanks for putting effort in supporting Tuya based dimmer modules!

I'm trying to get espurna to work with this Tuya dimmer.(https://www.aliexpress.com/item/33014039692.html?spm=a2g0o.productlist.0.0.20a4267fJQMyXa&algo_pvid=0e68e72d-4480-4f8e-be8c-2534b7ae7e00&algo_expid=0e68e72d-4480-4f8e-be8c-2534b7ae7e00-9&btsid=85f8b6de-845a-497b-8876-f05b80f3ba90&ws_ab_test=searchweb0_0,searchweb201602_8,searchweb201603_55

I am able to flash the experimental/tuya fimware onto the device. But I won't get it to work.
I am receiving serial data from the secondary MCU. But there is no serialdata send, according to the WebUI debug screen.

I've got the device working with Tasmota, using this setup guide.
https://blakadder.github.io/templates/qs-wifi_D01_dimmer.html

Do I need to make changes tot the config header files, prior to compiling?
I just compiled the experimental/tuya branche for the tuya-generic-dimmer environment.

Did I overlook something?

[mcspr]

@keesdekraker Sorry, we are dealing with different devices and serial protocols based on the https://blakadder.github.io/templates/qs-wifi_D01_dimmer.html

Whenever the button is pressed there are 50/60 Hz pulses on the S switch input. The frequency detection circuit (below) is connected to GPIO13 of the ESP8266 chip. These pulses must be processed as a switching signal with a counter. The ESP8266 then sends commands accordingly via the hardware serial interface for dimming operation, which are handled by a second microcontroller (STM8S003F3 MCU). The serial communication at 9600 baud is simple, just one command with changing brightness xx values: >> FF 55 xx 05 DC 0A <<

But, protocol is much simpler, we just need small light provider that does a serial write with that data packet

[keesdekraker]

@mcspr Thanks for your quick reply.

That makes sense.
The switch input on GPIO13 can also be binded as a BUTTON_SWITCH or BUTTON.
The net frequency is used for timing the button press, but timing can also be done using the conventional way in espurna.

My programming skills are far too little to implement the communication protocol.
I will stick to Tasmota for the moment. And will look into the the espurna code in more detail to see if I can grasp the espruna code a bit more.

[mcspr]

@keesdekraker I think the extent of the code for writing would be to add a new PROVIDER check in this function:

espurna/code/espurna/light.ino

Lines 550 to 581 in 383d5a8

	void _lightProviderUpdate(unsigned long steps) {
	if (_light_provider_update) return;
	_light_provider_update = true;
	_lightTransition(--steps);
	#if LIGHT_PROVIDER == LIGHT_PROVIDER_MY92XX
	for (unsigned char i=0; i<_light_channel.size(); i++) {
	_my92xx->setChannel(_light_channel_map[i], _toPWM(i));
	}
	_my92xx->setState(true);
	_my92xx->update();
	#endif
	#if LIGHT_PROVIDER == LIGHT_PROVIDER_DIMMER
	for (unsigned int i=0; i < _light_channel.size(); i++) {
	pwm_set_duty(_toPWM(i), i);
	}
	pwm_start();
	#endif
	// This is not the final value, update again
	if (steps) _light_transition_ticker.once_ms(LIGHT_TRANSITION_STEP, _lightProviderScheduleUpdate, steps);
	_light_provider_update = false;
	}

Channel value would be the "brightness" value, e.g.:

#if LIGHT_PROVIDER == LIGHT_PROVIDER_QSD01
    const uint8_t buffer[6] = {0xFF, 0x55, _light_channel[0].current, 0x05, 0xDC, 0x0A};
    Serial.write(buffer, 6);
#endif

Serial support is a bit complicated to configure though, as we need to have DEBUG_SERIAL_SUPPORT set to 0 and SERIAL_SPEED set to 9600 and some place to actually do a Serial.begin(SERIAL_SPEED). Current place to add such support would be:

espurna/code/espurna/system.ino

Lines 244 to 248 in 383d5a8

	// These devices use the hardware UART
	// to communicate to secondary microcontrollers
	#if (RF_SUPPORT && !RFB_DIRECT) || (RELAY_PROVIDER == RELAY_PROVIDER_DUAL) || (RELAY_PROVIDER == RELAY_PROVIDER_STM)
	Serial.begin(SERIAL_BAUDRATE);
	#endif

[LeandroSPereira]

Good night, I got Tasmota flash via OTA on this device, everything works reasonably well, but the dimmer behaves incorrectly, I would like to know if anyone could properly configure his '' DIMMERRANGE '' in Tasmota.