TUYA Dimmer behaves erratically (1.14.1, 1.14.2-dev) #2222
Comments
|
We do log every input and output commands btw, see 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: Lines 161 to 162 in 2dcf1b2 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? |
|
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. |
|
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. |
Hey @mcspr I was just wondering if this is fixed by the commit referenced here #1729 (comment) As I just checked and that commit is missing from latest official release 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 |
|
@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.
|
|
yeah sorry i got mixed up. Yes according to My device is now flashed and it seems to be working... thank you! |
|
Okay, so I thought I’d come back after a while and installed 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. 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. |
|
Check out https://github.com/xoseperez/espurna/wiki/Terminal? Not really sure what |
|
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: |
|
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 ;-) |
|
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.
… |
|
Hm. I tried both "Color Transitions: No/Yes" in the UI (is this the same?) and 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:
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)! |
Moonbase59
changed the title
Transition in HA depends on a json or template 'schema' of the HA component itself, but we only support a basic one.
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.
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.
We might have different behaviour with or without saved DPs, as autodiscovery overwrites the channel value with whatever MCU sends it. |
|
Good points. I’ve almost ever, for historical reasons, been using separate MQTT topics for all my lights, and now find out that
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:
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 … :-(
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? |
|
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 {
"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 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:
|
|
For completeness, here’s the (telnet) log for me switching the dimmer ON (flickery) and back OFF using the WebUI: 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: Keys (redacted): |
|
Thanks for logs! 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. 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!
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 |
|
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. |
|
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. 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: Here is a zip of the bin file. It has some support removed to keep the file size down. Built using: |
Note that you downgrade the WiFi driver version, which might not work nicely with the selected AP. Current |
|
Which firmware was using the downgraded WiFi driver? All my devices are running SDK 2.2.2-dev. I build using |
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 |
|
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. |
|
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? |
|
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: Line 552 in 82d5de0 |
|
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. |
|
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 |
|
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? |
|
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. |
|
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. |
|
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: Which will hide the 2nd switch (unless there's (and nvm the CI build failure, TUYA_SUPPORT=1 should still work when built locally) |
|
I'll give it a go in the next week or so. See #2414 |
- gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
Bug description
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.
Cannot be switched to "ON" if brightness isn't set to "255" before. Lower levels lead to an immediate automatic switch OFF.
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.
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
3a. OK
3b. For a one-channel light, brightness should be the same as channel #0.
Screenshots
None
Device information
[975817] [MAIN] ESPURNA 1.14.2-dev (2dcf1b2)
[975817] [MAIN] [email protected]
[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?
The text was updated successfully, but these errors were encountered: