TUYA Dimmer behaves erratically (1.14.1, 1.14.2-dev)

[Moonbase59]

Bug description

1. When switching ON, channel #0 gets reset to 1. Visual effect: The connected light appears to be switched on with the last brightness, then turns off (flashes briefly). This behaviour is the same using either the Web UI switch or the physical switch on the device.

2. Cannot be switched to "ON" if brightness isn't set to "255" before. Lower levels lead to an immediate automatic switch OFF.

3. Brightness control a) switches the light OFF when set to zero (seems ok to me). b) sometimes also moves the Channel #0 slider, sometimes doesn't.

4. Channel #0 seems to be the only way to set the light’s brighness but appears to "jump", apparently adding 16 to the value. Also, the brightness slider has to be 255 initally for this to work.

Steps to reproduce See above.

Expected behavior

1. Should switch on to the last brightness set.
2. Should be able to switch regardless of slider settings. 3a. OK 3b. For a one-channel light, brightness should be the same as channel #0.
3. Channel #0 should keep the set value.

Screenshots None

Device information [975817] [MAIN] ESPURNA 1.14.2-dev (2dcf1b2b) [975817] [MAIN] xose.perez@gmail.com [975817] [MAIN] http://tinkerman.cat

[975817] [MAIN] CPU chip ID: 0xF9244C [975817] [MAIN] CPU frequency: 80 MHz [975817] [MAIN] SDK version: 1.5.3(aec24ac9) [975817] [MAIN] Core version: 2.3.0 [975820] [MAIN] Core revision: 9826c6d [975820] [MAIN] Build time: 1586397641 [975820] [975821] [MAIN] Flash chip ID: 0x1540C8 [975821] [MAIN] Flash speed: 40000000 Hz [975821] [MAIN] Flash mode: DOUT [975821] [975822] [MAIN] Flash size (CHIP) : 2097152 bytes / 512 sectors ( 0 to 511) [975827] [MAIN] Flash size (SDK) : 1048576 bytes / 256 sectors ( 0 to 255) [975827] [MAIN] Reserved : 4096 bytes / 1 sectors ( 0 to 0) [975827] [MAIN] Firmware size : 527520 bytes / 129 sectors ( 1 to 129) [975828] [MAIN] Max OTA size : 495616 bytes / 121 sectors ( 130 to 250) [975828] [MAIN] EEPROM size : 4096 bytes / 1 sectors ( 251 to 251) [975828] [MAIN] Reserved : 16384 bytes / 4 sectors ( 252 to 255) [975828] [975829] [MAIN] EEPROM sectors: 251, 250 [975833] [MAIN] EEPROM current: 250 [975833] [975833] [MAIN] EEPROM: 4096 bytes initially | 425 bytes used (10%) | 3671 bytes free (89%) [975834] [MAIN] Heap : 30488 bytes initially | 17832 bytes used (58%) | 12656 bytes free (41%) [975834] [MAIN] Stack : 4096 bytes initially | 1424 bytes used (34%) | 2672 bytes free (65%) [975834] [975834] [MAIN] Boot version: 7 [975834] [MAIN] Boot mode: 1 [975838] [MAIN] Last reset reason: External System [975838] [MAIN] Last reset info: Fatal exception:0 flag:6 (EXT_SYS_RST) epc1:0x00000000 epc2:0x00000000 epc3:0x00000000 excvaddr:0x00000000 depc:0x00000000 [975838] [975839] [MAIN] Board: TUYA_GENERIC_DIMMER [975839] [MAIN] Support: ALEXA API BROKER BUTTON DEBUG_TELNET DEBUG_WEB DOMOTICZ HOMEASSISTANT LED MDNS_SERVER MQTT NTP SCHEDULER TELNET TERMINAL THINGSPEAK WEB [975839] [MAIN] OTA: ARDUINO ASYNCTCP WEB [975839] [MAIN] WebUI image: LIGHT [975840] [976081] [MAIN] Firmware MD5: c71b3e21481540a09d4cdcb9f99a44ea [976086] [MAIN] Power: 3252 mV [976086] [MAIN] Power saving delay value: 10 ms [976086]

Tools used

• Desktop operating system Linux Mint 19.3; Ubuntu 14.04.5

• Browser & version Firefox 66.0.3

• IDE & version No IDE, esptool.py to initially flash espurna-1.14.1-tuya-generic-dimmer.bin. Web UI OTA to flash a) espurna-1.14.2-dev.nightly20200409+git2dcf1b2b-espurna-core-webui-1MB.bin then b) espurna-1.14.2-dev.nightly20200409+git2dcf1b2b-tuya-generic-dimmer.bin.

• Compiler & version (if not embedded in IDE) None used.

Additional context Please let me know if and how I might help. I have two of these devices and should very much appreciate if we could make them work. All my other devices also use Espurna and I really wouldn't like to be forced to move to another platform.

Since all the basic functionality is there, I think these might only be some small bugs, maybe in the communication with the MCU?

[mcspr]

We do log every input and output commands btw, see [TUYA] ... tagged messages.

At #1729 something like this was already mentioned, values returned from the other controller were not the same values as we sent it. Including 1 when off and weird increments by 16. We do have a simple filtering: https://github.com/xoseperez/espurna/blob/2dcf1b2bd80ea2474275254bec722aa8905bf6c5/code/espurna/tuya.ino#L161-L162 In the current code, set tuyaFilter 2 & reboot will ignore all integer values (as to why ignore value type... if i rememeber this right, to avoid ignoring each channel individually)

Brightness == channel#0 can be simplified, but it is related to the overall lights module. Do you mean they should be mirrored on the API level or just a hidden slider from the UI part?

[Moonbase59]

Honestly, wouldn’t know. Would love to know more about this dimmer but had to get something going, so I flashed Tasmota 8.2.0 for the time being. It is still a little steppy but gives a much better overall user experience – using MQTT and HomeAssistant, mainly.

I somehow suspect these dimmers work in steps and maybe don’t cover the complete dimming range.

[mcspr]

I don't have the hardware, so we are just guessing here. But, I can switch filtering to ON by default though, that may help with these devices specifically.

[dreamcat4]

In the current code, set tuyaFilter 2 & reboot will ignore all integer values

Hey @mcspr I was just wondering if this is fixed by the commit referenced here https://github.com/xoseperez/espurna/issues/1729#issuecomment-539852020

As I just checked and that commit is missing from latest official release 1.14.1. However it is included in the nightly builds now on dev branch. Reference:

https://github.com/xoseperez/espurna/pull/1997

So it would seem that is OK now?

Otherwise if theres something else I need to do other than just flash the latest nightly build ? For example do i still need to install Arduno IDE, edit such value set tuyafilter 2 and recompile it myself instead?

[mcspr]

@dreamcat4 comment you refer to is from October, tuya was already merged in 1.14.0. From that point onward there were no changes to the module.

set tuyaFilter 2 command refers to the Terminal, set updates key-value storage that is on the device.

[dreamcat4]

yeah sorry i got mixed up. Yes according to git the commit you are talking about is indeed in 1.14.1 release. However at least the latest / newest commit of PR #1997 is not. That was about a month later so it seems to have missed that release. However it is in dev branch ant that is what I should have been referring to instead. Sorry for the mixup.

My device is now flashed and it seems to be working... thank you!

[Moonbase59]

Okay, so I thought I’d come back after a while and installed espurna-1.15.0-dev.nightly20200608+git7aec0c57-tuya-generic-dimmer.bin from the nightlies. I also set set tuyaFilter 2 and rebooted, because without this the device would behave as originally said.

Works quite nice now, and I’m Tasmota-free again (almost all devices Espurna’ed). The visible range of dimming (using 4x Philips dimmable E27 LED lights) is much better as before, from almost dark to full brightness. tuya.show says it uses datapoints 1&2, I had 1&3 with Tasmota. Odd.

I use Home Assistant as a frontend. I assume this light works like a 1-channel RGB light? Because I had to set channel #0 manually to 255, and HA seems to adjust the brightness only. But well, it works just right now!

Is there any documentation on how to set any of these Tuya parameters? Or the debug window commands in general?

I’m using these dimmer modules (bought off Amazon):

The LED is actually a dual green+red LED: RED shows the dimmer state (brightness or off), the GREEN whatever you set up in Espurna’s Web UI (GPIO14, WiFi state in my case). The button can be used as a local ON/OFF switch.

[mcspr]

Check out https://github.com/xoseperez/espurna/wiki/Terminal? help shows all registered commands, keys all the keys that are set. I've added Tuya configuration & commands to the page, but I believe you've already seen all the relevant ones already. I guess filter it can be a safe default at least for dimmer DP's?

Not really sure what tuya.show difference is about... Do you happen to remember what fnid in Tasmota had shown?

[Moonbase59]

Thanks for the pointers, and all your work! Really appreciate it.

I’d assume (not know) yes, filtering Tuya dimmer DPs might be a good default, especially for users that only flash such devices every once in a while (and don’t want to fiddle with PIO or the code).

Unfortunately, I don’t remember the fnid from Tasmota, the only screenshot I kept from above device is this:

[Moonbase59]

If there is a "device wiki" somewhere, it might be nice to add this device and its parameters, because there seem to be many (mostly chinese) out there, and I saw the interest in mains AC dimmers increase lately. And with the latest Espurna (and the filter) it works really well. If you need any more info, let me know.

I’d just love to have transition support with this, but as I understand, this is handled by the Tuya MCU and can’t be influenced easily?

Would be great if one could, say, transition the light going on slowly over a few minutes when it gets dark … this would be a beautiful feature for dimmer devices and set Espurna apart even more ;-)

[mcspr]

If there is a "device wiki" somewhere, it might be nice to add this device and its parameters, because there seem to be many (mostly chinese) out there, and I saw the interest in mains AC dimmers increase lately. And with the latest Espurna (and the filter) it works really well.

We do have https://github.com/xoseperez/espurna/wiki/Hardware list, perhaps add device page and link it there? However, this also can be a 'tuya generic dimmer' page with some devices listed and a general explanation of the 'tuya' build feature?

I’d just love to have transition support with this, but as I understand, this is handled by the Tuya MCU and can’t be influenced easily?

I think those were disabled some time ago, but no longer are. I see entries for both settings keys related to this aren't hidden by the tuya - useTransitions (boolean as 0 or 1) and lightTime (in milliseconds), see WebUI Lights section. Can you try enabling those, since the default is off? Note that while WebUI limits light time to 5000 ms, you can manually set it via the set (yep) command.

[Moonbase59]

Hm. I tried both "Color Transitions: No/Yes" in the UI (is this the same?) and set useTransitions 1 in the debug window. Both didn't change anything. Eventually, of course, I’d like to use Home Assistant's "transition" option, controlling the light via MQTT.

Could this be related to #1564 ?

---

I also think there's still a (minor) bug: When switching the light on, it will "flicker", i.e. start with a low light level for a fraction of a second, then adjust to the brightness set. I try to include a short video, so you can see what it does:

http://kaufen-ist-toll.de/download/espurna/VID_20200629_200310.mp4

Due to the auto-exposure of the smartphone, it’s probably not too good to see, but I had no better. Maybe watch the 2nd time round, I guess one can see it better there.

---

Also interesting: Now (with transition set on), when rebooting the device, it will come up with:

• switch: OFF
• channel #0: 16 (was set to 255 before)
• brightness: 129 (my set value)

The light then actually ON, at a very low level (roughly what I would get when setting channel #0 to 255 and brightness to 16)!

[mcspr]

Eventually, of course, I’d like to use Home Assistant's "transition" option, controlling the light via MQTT.

Could this be related to #1564 ?

Transition in HA depends on a json or template 'schema' of the HA component itself, but we only support a basic one. https://www.home-assistant.io/integrations/light.mqtt/ But I am not sure I understand what is the payload supposed to be, does it need brightness and transition values at the same time? i.e. when it wants transition, can it use just a single topic in templated mode?

Hm. I tried both "Color Transitions: No/Yes" in the UI (is this the same?) and set useTransitions 1 in the debug window. Both didn't change anything.

Yep, sorry. Another bug is internal transitions actually don't work with tuya, as it only receives a single value right at the start of the transitions process. Need to fix that :) We also don't have a configurable step time, so will need to add that too.

I also think there's still a (minor) bug: When switching the light on, it will "flicker", i.e. start with a low light level for a fraction of a second, then adjust to the brightness set. I try to include a short video, so you can see what it does:

The way communication flow works, it should send 'switch on' and 'brightness set', which probably explains the behavior. I do remember that we could not set brightness to 0 as there is this weird quirk with 16 instead of 0, so switch is there to turn it off, but I wonder if sending ON switch status is redundant and we can just try sending brightness directly. And by communication I mean raw serial stuff as it can be seen in the debug log with [TUYA] <= / [TUYA] =>

Also interesting: Now (with transition set on), when rebooting the device, it will come up with:

We might have different behaviour with or without saved DPs, as autodiscovery overwrites the channel value with whatever MCU sends it. tuya.save is a shortcut to save tuyaSwitchN & tuyaChannelN settings.

[Moonbase59]

Good points. I’ve almost ever, for historical reasons, been using separate MQTT topics for all my lights, and now find out that

• HA seems not to support transitions with "default" MQTT lights (only when using "JSON" schema)
• Espurna apparently doesnt’t send the "right" HA autodiscovery data for the light to work in "JSON" mode

Looks like this needs some further investigation! I will try to to set up the dimmer in "JSON" mode manually in HA and let you know my findings. Looks like they currently don’t support a separate "transistion" topic but allow a JSON value "transition: seconds" in the command topic if "schema" is set to "json" (not "default").

Questions:

• Do you have a HA instance so we could both try?
• Would you have time/interest to follow this further?
• If yes, I wonder where you live and if it would be feasible to send you one of my two devices so we had the same hardware to investigate?

Let me know if I can log anything that might help you.

In any case, I think we should try to investigate the reboot problem first—this could be a safety risk, because after a power fail/reboot the device would switch on, albeit with a low intensity. Just imagine you are on vacation, the house has a power fail, and lots of hot halogen lights turn on for weeks … You might come back to a burned-down home … :-(

~What exactly would I have to type in the debug window for Tuya datapoints, channel and switch?~ I tried

set tuyaChannel0 2
set tuyaSwitch0 1
tuya.save

but that didn't change anything (apart from saying "+OK").

In general, would you (or the project lead) be willing to fix this internal transition thing you mentioned? Seems getting good dimmable (AC, non-DIY) lights is still not easy …

[Moonbase59]

Doh! Seems HA and Espurna aren’t as compatible as I thought! Apparently, when switching on "JSON payload" in MQTT, Espurna only sends a JSON payload to the …/data topic but still wants separate topics for control, while HA assumes it can now send JSON messages like this to the light:

{
  "brightness": 255,
  "color_temp": 155,
  "color": {
    "r": 255,
    "g": 180,
    "b": 200,
    "x": 0.406,
    "y": 0.301,
    "h": 344.0,
    "s": 29.412
  },
  "effect": "colorloop",
  "state": "ON",
  "transition": 2,
  "white_value": 150
}

and transition and flash are only supported in this JSON mode, not via separate topics (what they call MQTT "default" mode). I was assuming Espurna and HA could use something like …/transition and possibly …/transition/set.

In the long run, I wonder if it would be good to enhance Espurna with "full" JSON support (i.e., allowing it to receive commands like above and picking the wanted values out of the JSON messages), and also asking the HA guys if they’d support adding transition and flash via separate topics.

Personally, I mostly use the separate topic approach, but I do see the advantages of JSON for some needs, i.e. reading sensors, or setting lots of params at once.

The situation being as it is, I’d therefore suggest the following sequence:

• Start with fixing the bugs (light goes on after reboot; flickery when switching on), so we get the best possible Tuya dimmer Espurna for everyone.

• Try to fix the internal transition stuff.

• Maybe add a transition (and even flash?) topic even if HA doesn’t support it out-of-the-box, for those of us willing to do it manually (or using other frontends). The unit for this should probably be seconds, expecting people to use it for smooth transitions up to, say, an hour or so. Personally, and looking at other vendors’ interfaces, I’d love this to be a float, since using milliseconds often makes sense, too (like 500ms for color transitions or the like).

• Transitions can be for color changes as well as brightness changes, they should possibly be coded as universal as possible (i.e., not left to a second-level MCU). But I guess the code is already there because my Espurna’ed AI Light E27 bulbs do this just beautifully. (Apart from not being able to control it via HA, that is …)

• Since transitions are mostly used as a "one-shot option", I wonder if it’d make sense to have a general transition time (like we have now in Espurna), and probably reset the transition time received via MQTT after it has expired (or a new value received), to the internal value? Imagine: You set a fade-out transition for a light for 30 minutes. After 10 minutes, you decide you want to switch it back on again. Of course it should then switch back on immediately and not take 30 minutes again to come to full brightness … This is how HA’s light.turn_on and light.turn_off services function currently: If you sepcify a transition, it’ll use it for this single service call (by simply sending the data to the light and letting the light take care of it). This is a situation where combined JSON messages actually make sense … and probably the reason why HA only supports this in JSON mode.

• Maybe (?) eventually work on a "full" JSON implementation (i.e., also receive and decode JSON payloads)?

[Moonbase59]

For completeness, here’s the (telnet) log for me switching the dimmer ON (flickery) and back OFF using the WebUI:

[213248] [WEBSOCKET] Requested action: relay
[213249] [RELAY] #0 scheduled ON in 0 ms
[213255] [RELAY] #0 set to ON
[213257] [MQTT] Sending dimmer/1/relay/0 => 1 (PID 1)
[213260] [TUYA] =>: 55aa0006000501010001010e
[213274] [TUYA] =>: 55aa00060008020200040000000116
[213288] [TUYA] <=: 55aa0007000501010001010f
[213300] [TUYA] <=: 55aa0007000501010001010f
[213324] [TUYA] <=: 55aa00070008020200040000001026
[213337] [TUYA] <=: 55aa00070008020200040000000117
[213357] [MQTT] Sending dimmer/1/channel/0 => 128 (PID 1)
[213358] [MQTT] Sending dimmer/1/brightness => 128 (PID 1)
[213364] [TUYA] =>: 55aa00060008020200040000008095
[213397] [TUYA] <=: 55aa00070008020200040000008096
[213410] [TUYA] <=: 55aa0007000501010001010f
[213434] [TUYA] <=: 55aa00070008020200040000008ea4
[214260] [RELAY] Setting relay mask: 0b1
[218837] [TUYA] =>: 55aa00000000ff
[218860] [TUYA] <=: 55aa000000010101
[227847] [TUYA] =>: 55aa00000000ff
[227870] [TUYA] <=: 55aa000000010101

[365054] [WEBSOCKET] Requested action: relay
[365056] [RELAY] #0 scheduled OFF in 0 ms
[365058] [RELAY] #0 set to OFF
[365060] [MQTT] Sending dimmer/1/relay/0 => 0 (PID 1)
[365063] [TUYA] =>: 55aa0006000501010001000d
[365098] [TUYA] <=: 55aa0007000501010001000e
[365111] [TUYA] <=: 55aa0007000501010001000e
[365124] [TUYA] <=: 55aa00070008020200040000008ea4
[365137] [TUYA] <=: 55aa0007000501010001000e
[365150] [TUYA] <=: 55aa00070008020200040000001026
[365159] [MQTT] Sending dimmer/1/channel/0 => 0 (PID 1)
[365160] [MQTT] Sending dimmer/1/brightness => 128 (PID 1)
[366062] [RELAY] Setting relay mask: 0b0
[371939] [TUYA] =>: 55aa00000000ff
[371963] [TUYA] <=: 55aa000000010101

I did set channel #0 to 255 manually before trying this. (Light would immediately switch off again if channel #0 was zero.) I also manually set the brightness to 128.

Tuya settings:

> tuyaChannel0 => "2"
> tuyaFilter => "2"
> tuyaSwitch0 => "1"

tuya.show
[045542]   tuyaSwitch0 => dp=1 value=0
[045544]  tuyaChannel0 => dp=2 value=128

Keys (redacted):

keys
Current settings:
> adminPass => "REDACTED"
> alexaEnabled => "0"
> boardName => "TUYA_GENERIC_DIMMER"
> brightness => "128"
> btnGPIO0 => "0"
> ch0 => "255"
> desc => "Stehlampe"
> haEnabled => "1"
> hostname => "dimmer1"
> ledGPIO0 => "14"
> lightTime => "500"
> mireds => "326"
> mqttClientID => "dimmer1"
> mqttEnabled => "1"
> mqttPassword => "REDACTED"
> mqttServer => "has1"
> mqttTopic => "dimmer/1"
> mqttUseJson => "0"
> mqttUser => "REDACTED"
> pass0 => "REDACTED"
> ssid0 => "REDACTED"
> telnetSTA => "1"
> tuyaChannel0 => "2"
> tuyaFilter => "2"
> tuyaSwitch0 => "1"
> useCSS => "0"
> useColor => "0"
> useTransitions => "1"
Number of keys: 28
Current EEPROM sector: 250
Free EEPROM: 3589 bytes (87%)
+OK

[mcspr]

Thanks for logs!

[213260] [TUYA] =>: 55aa0006000501010001010e
[213274] [TUYA] =>: 55aa00060008020200040000000116

Kind of weird. It turns ON the switch and sends ...05...0101... to notify the boolean DP on and immediately tries setting brightness via ...08...04...01... to 1 for some reason. But might also explain the boot situation, because lights and switch go in pairs.

HA is a separate issue though and I think I need to re-read the messages above more times than 2 :) We don't even need to mix JSON mode and lights-as-json, HA module can just subscribe to that specific topic and send things when lights status changes. In addition to announcing JSON schema support instead of the basic one. But I rather not mix issues!

In general, would you (or the project lead) be willing to fix this internal transition thing you mentioned?

As de facto maintainer / developer / lead, sure :) I got mixed up in some other stuff, so I'll need to cover some backlog first b/c changes will touch more than just the tuya

[Moonbase59]

I’m glad about your help! Agreed, as I said, let’s try to fix the bugs first, then care about HA later (maybe in a separate issue).

So I’ll just wait a while and you can do your other stuff. Let me know if you need more logs or anything, and come back here whenever you’re ready. :-)

I think the dimmer DP has a max range of 1..255 and switches OFF when set to 0, maybe that’s the reason it tries to set it to 1 in the first place? Since we should know the desired channel0/brightness value, maybe we could send this value instead of the 1.

[davebuk]

I have been looking to run a more up to date version of espurna on my dimmer. I built using the latest dev branch but the 'relay' does not get found so there isn't a way of switching the output ON or OFF.

I tried the latest nightly 'espurna-1.15.0-dev.nightly20200814+gitff1c9e49-tuya-generic-dimmer.bin'. Although it has the light relay, I keep having watchdog resets.

[175377] 
[175377] [MAIN] Boot version: 31
[175377] [MAIN] Boot mode: 1
[175381] [MAIN] Last reset reason: Hardware Watchdog
[175381] [MAIN] Last reset info: Fatal exception:4 flag:1 (WDT) epc1:0x40000f68 epc2:0x00000000 epc3:0x00000000 excvaddr:0x00000000 depc:0x00000000

I version I built a while ago (1.14.1) seems to be fine other than the initial light being ON after a reboot even though MQTT shows it as OFF until a ON/OFF/ON switch cycle in the webUI resets the dimmer. INFO gives:

[029918] [MAIN] ESPURNA 1.14.1 (62ad7da3)
[029918] [MAIN] xose.perez@gmail.com
[029918] [MAIN] http://tinkerman.cat

[029918] [MAIN] CPU chip ID: 0xA6CCBD
[029919] [MAIN] CPU frequency: 80 MHz
[029919] [MAIN] SDK version: 2.2.2-dev(38a443e)
[029919] [MAIN] Core version: 2.6.3
[029922] [MAIN] Core revision: 3d128e5c
[029923] [MAIN] Build time: 1578583551

Here is a zip of the bin file. It has some support removed to keep the file size down. Built using:

#elif defined(DB_TUYA_DIMMER)

    // Info
    #define MANUFACTURER        "TUYA"
    #define DEVICE              "GENERIC_DIMMER"

    //My config
    #define ALEXA_SUPPORT           0
    #define DOMOTICZ_SUPPORT        0
    #define HOMEASSISTANT_SUPPORT   0
    #define THINGSPEAK_SUPPORT      0

    #define LIGHT_PROVIDER      LIGHT_PROVIDER_TUYA
    #define LIGHT_CHANNELS      0
    #define RELAY_PROVIDER      RELAY_PROVIDER_LIGHT
    #define DUMMY_RELAY_COUNT   0

tuya.zip

[mcspr]

[175381] [MAIN] Last reset reason: Hardware Watchdog ... [029919] [MAIN] SDK version: 2.2.2-dev(38a443e) ...

Note that you downgrade the WiFi driver version, which might not work nicely with the selected AP. Current dev switched to the new SDK as the default, although idk what is up with tuya discovery not working :/ Do manual settings work, by tuya.save (which will save tuyaSwitch#, tuyaChannel#) on the working fw and moving to the new?

[davebuk]

tuya.save then loading 1.15.0-dev now shows relay and works as before.

Which firmware was using the downgraded WiFi driver? All my devices are running SDK 2.2.2-dev. I build using platformio-override.ini. For the tuya I set:

# TUYA In-line Dimmer
[env:db-tuya-dimmer]
extends = env:esp8266-1m-latest-base
src_build_flags = -DDB_TUYA_DIMMER -DUSE_CUSTOM_H

[mcspr]

Which firmware was using the downgraded WiFi driver?

espurna-1.15.0-dev.nightly20200814+gitff1c9e49-tuya-generic-dimmer.bin

Nightly builder used 2.3.0 at that point, and CI here broke right when I switched SDK :/ No nightlies for the time being, need to contact Travis support / ping Xose

[davebuk]

I see. I changed all devices up from 2.3.0 due to the Kasa cameras I use crashing espurna. It was probably that issue again. I'll keep an eye on the current dev build.

[davebuk]

1.15.0-dev on latest core still working fine without any issues for 3 days.

The device will always turn to ON after a power cycle even though it says it's OFF in the webUI. Can an OFF command be sent to the MCU straight away after first boot?

[mcspr]

As noted above, looks like a bug combining lights and relay status and trusting the values device returns back.

Does removing this lime still turns the lights ON? This cuts off the serial communication completely, just for the sake of testing that MCU does not do this on it's own and those combined messages are to blame: https://github.com/xoseperez/espurna/blob/82d5de0b64265585faaedc365354393373f0eab9/code/espurna/tuya.cpp#L552

[davebuk]

With that line removed, the light still turns ON after a power cycle. Obviously there is no control using the webUI but the light does toggle OFF/ON using the hardware switch on the device.

[mcspr]

I think I missed this from the original issue - it is a literal ON / OFF switch toggle or a pushbutton? (i.e., does it hold the state while power is off? does not look like it remembers previous state from MCU side)

From sw side, I will look into boot modes. Otherwise, Tuya is really weird. RFBridge integration also suffers for anything active, since it will send RF codes when booting, too, so some kind of additional 'ignore' mode is needed b/c the original code deals with 'real' GPIOs

[davebuk]

Push button. It's labelled on the outside as 'reset' and I think it connects to GPIO 0. Not sure how the push button actually works with espurna? Is the issue something to do with the GPIO state at boot?

[davebuk]

And maybe worth mentioning, if the dimmer has been working correctly and left in the OFF state, the issue happens if the dimmer is switched OFF then ON at the mains voltage input or a watchdog reset. The dimmer output turns ON and it seems to be at the previous brightness.

You can either go through an ON/OFF cycle in the webUI to resync the control or return the dimmer to an OFF state with the push button. The dimmer will then follow the commands sent to it until it's power cycled.

A software reboot doesn't seem to effect it and if the switch/relay is set to 'same as before' after boot in the switch settings menu, the dimmer will return to that previous ON or OFF state after a software reset but NOT after a power cycle or the watchdog reset I had with core 2.3.0.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.

[mcspr]

While moving stuff around for the relays, I also added changes for tuya that were mentioned here. If someone (still) has this module somewhere not in active use or can pick it up for testing, please check out the tree in the #2414

By default, there are still 2 switches - 1st is global 'lights', 2nd is what MCU sends us as it's own lights state. However, there's a new feature to track the state specifically for this dimmer when our settings are:

tuyaChannel0 => "dp_id_of_the_channel"
tuyaChanState => "dp_id_of_the_switch"

Which will hide the 2nd switch (unless there's tuyaSwitch0 set) and bind 1st switch status to the thing on the other side. It is disabled by default though

(and nvm the CI build failure, TUYA_SUPPORT=1 should still work when built locally)

[davebuk]

I'll give it a go in the next week or so. See #2414