tuya: physical button directly changes the lights state #2422
Comments
|
It is expected, as we ignore the received state messages via tuyaFilter => 1
Repeating my previous q, does removing relay boot state preservation (our setting, via Switches tab) and pressing the button to turn the light off preserve it on the next boot? |
|
Relay boot is set to After a cold boot, the light goes through its ON/OFF cycle. Once fully booted, pressing the button cycles the light ON/OFF but the webUI doesn't show the same status as the actual output. |
|
I've looked at the hardware again and found that the physical button connects to ground via resistor R16 directly to the MCU PIN 10. There is some info about this at: https://tasmota.github.io/docs/TuyaMCU-Devices/ Can espurna use the signal to the MCU PIN to operate like a standard GPIO type input? I may look to modify the hardware, remove R16 and connect the push button directly to one of the TYWE3S unused GPIOs. |
|
Maybe? If it is interpreted by the MCU as ON, that's the explanation as to why it wants the lights ON on boot. As-is we can't distinguish between the button press and echo MCU sends when it acknowledges the state we send to it (relay toggle, brightness, everything sends it back). TUYA only allows this condensed API, there's no direct GPIO reads / writes and MCU is expected to handle the inputs and outputs btw, if you remember the previous issue: |
|
The button is labelled on the outside as 'RESET'. Maybe that's all the original firmware did? |
|
🤷 |
|
I meant the original TUYA firmware. |
|
I don't get what you mean though, the original fw receives the same status message on the press. From ESP side we receive only two GPIOs to work with:
As a wild guess - does changing LED status to the relay follow mode changes anything on boot? Meaning, it kept low at boot. I don't remember if this was tested |
|
Sorry, I didn't know if you knew what the original firmware was doing with the button press. From what you are saying, it WOULD have toggled the output, the same as espurna does. I'll look at the LED later. |
|
Flashing original .bin will also clear out the remaining questions about the button? Just note that going back to espurna would need a full flash clear to be safe from SDK config remains |
|
Using firmware built around end of Jan 2021, the LED was set to On a side note, the device had been removed from the mains for a few days. On power up, the light went back to the old issue where it would turn itself ON and stay ON with the RED LED ON. Looking at a review on amazon (https://www.amazon.co.uk/gp/customer-reviews/R2ZERWRHD6MTQL/ref=cm_cr_dp_d_rvw_ttl?ie=UTF8&ASIN=B07Q2XSYHS) this seems to be a standard issue with the tuya firmware. It did this every time I cold booted. I noticed in the webUI the channel value was at Due to recent changes in espurna, I built using 7434ea3. I have lost LED from the webUI so tried the same procedure as per the top of this thread. I still didn't have LED but cold boot "auto OFF" now works regardless of channel value before cold boot. I decided to do a factory reset from the webUI to clear out all settings and start again. In doing so I now can't get to the web interface! I can connect to the espurna AP using the default password but the webUI on 192.168.4.1 doesn't open. I may have to look at reflashing using the hardware pins. |
|
I flashed the .bin shown here: #1729 (comment). I didn't setup the device with the Smart Life software but confirmed the button does toggle the light output. The GREEN LED flashed ON then OFF on boot and then was always ON. That might be controllable once the device was setup. I then uploaded I have uploaded a previous version |
|
Thanks! The issue with initial boot is a big of lights code that thinks the lights did not change, because all values stay at 0 so it thinks there is nothing to do (but, I thought I already did in that latest commit...) WebUI / WiFi issues without mains are kind of expected, I'd only try when connected to AC b/c of the power requirements. If it is already mains, I'd try to wait ~20min without power and then try to connect it to the AP. |
|
All testing was done with mains not via USB device. |
|
OTA'd back to 7434ea3. I realise why I may have lost LED. I see you now define the LED GPIO in the build definition rather than it being, I think before, discovered? I still had to However, after a reboot, MQTT brightness changes were all over the place. Checked webUI and the |
diff --git a/code/espurna/light.cpp b/code/espurna/light.cpp
index e2ec0a06..08e5c2be 100644
--- a/code/espurna/light.cpp
+++ b/code/espurna/light.cpp
@@ -1041,7 +1041,7 @@ struct LightRtcmem {
// - aabbccddee are channels (from 0 to 5 respectively)
explicit LightRtcmem(uint64_t value) {
_mireds = (value >> (8ull * 6ull)) & 0xffffull;
- _brightness = (value >> (8ull * 5ull));
+ _brightness = (value >> (8ull * 5ull)) & 0xffull;
_channels[4] = static_cast<uint8_t>((value >> (8ull * 4ull)));
_channels[3] = static_cast<uint8_t>((value >> (8ull * 3ull)));
@@ -1065,8 +1065,8 @@ struct LightRtcmem {
{}
uint64_t serialize() const {
- return (static_cast<uint64_t>(_mireds) << (8ull * 6ull))
- | (static_cast<uint64_t>(_brightness) << (8ull * 5ull))
+ return ((static_cast<uint64_t>(_mireds) & 0xffffull) << (8ull * 6ull))
+ | ((static_cast<uint64_t>(_brightness) & 0xffull) << (8ull * 5ull))
| (static_cast<uint64_t>(_channels[4]) << (8ull * 4ull))
| (static_cast<uint64_t>(_channels[3]) << (8ull * 3ull))
| (static_cast<uint64_t>(_channels[2]) << (8ull * 2ull))Yeah, about that... there was a missing numeric operation, patch above should handle that |
|
LED though. What happened before...
|
|
Above code change works. So LED doesn't show up in tuya stuff now, just standard configs? |
|
Tuya does not run discovery if there are any configuration flags present with DP != 0. I did shuffle things a lot that time, but this should still be possible: diff --git a/code/espurna/tuya.cpp b/code/espurna/tuya.cpp
index 5389ad36..8f280b1e 100644
--- a/code/espurna/tuya.cpp
+++ b/code/espurna/tuya.cpp
@@ -368,13 +368,9 @@ error:
setupSwitches();
}
- if (!configDone) {
- DEBUG_MSG_P(PSTR("[TUYA] Starting discovery\n"));
- state = State::QUERY_PRODUCT;
- return;
- }
-
- state = State::IDLE;
+ DEBUG_MSG_P(PSTR("[TUYA] Starting discovery\n"));
+ state = State::QUERY_PRODUCT;
+ return;
}
sendWiFiStatus();On the first received heartbeat, it will read from settings and run normal discovery, which will read both GPIO values into the cache (at least) |
|
Ah, ok. I thought it was the TUYA code that was doing the discovery and setting the dummy relay output for the dimmer as well as button and LED etc. All seems to be working at the moment. 😁 |
ref. #2422 (comment) stop including mireds into the brightness when unpacking uint64 value clamp brightness via the helper function
|
At least we got one over the stock :) It does not stay ON when power-cycled (unless requested) |
|
And the fact espurna makes the device more secure and configurable. |
|
If I were to re-configure the hardware push button as default high going low on press, directly to one of the spare ESP pins, do you imagine it would effect the TUYA side of things? Pin 10 of the MCU may need to be pulled high and say |
|
Basically, cut the trace and connect the button directly to one of the available pins, but also replacing the GPIO0 button? (that does not do anything anyway, really). |
|
It doesn't seem to be working. I've cut the track so the switched output of the button no longer connects to the MCU via R16. I built adding to my custom.h the definitions below but nothing is shown on the debug screen when I press the button. GPIOs 12 and 13 do not seem to be pulled up and have only 0.2V on the pin, going to 0V when I press the button. I tried with an external pullup resistor onto the GPIO and still nothing happened. Do I need to define a dummy relay? I even removed the GREEN LED leg and removed the LED definition and re-configured I also added some to the |
|
Do basics work? Given these 3 settings on a basic dev board without any other config: Touching GND with the pin (D5 in case of a wemos board) Note that the board may have external pull up or downs. There is also GPIO0 exposed that is definitely already pulled up by default |
|
As in basic functions of the ESP on the TUYA board? If so.....
KEYS With hardware button held down connected to GPIO14 No button events are shown in the debug screen. Interestingly after button release, GPIO14 is still LOW. Next I |
|
That is why my advice is to remove all existing config and simply try to modify the 1st button. |
|
OT: And about So build flag values can be displayed instead of the current blank spaces. There's already a code in place, just some minor tweaks are needed to actually make this work (...some runtime increase is expected as well...) |
|
Rebuilt without any buttons defined and also built a 'generic tuya dimmer' both at f013e04. |
|
|
|
Sorry, I mis-understood what you meant about Anyway, using the default I then tried to reload my custom.h version setting for button 2 on GPIO 14. I did have 2 and 3 defined so I could see which, if any, GPIOs are working on the board. Now typing I'll look to re-configure the hardware, set the LED back to 14 and try the button on 0. I know that is HIGH when OFF. |
|
LED reconnected back to
(TPLCLICK commented out as i'm not sure if that is an option?)
I guess |
|
Just run and
Now have: Actions don't work as defined in my |
|
re. #2422 (comment) espurna/code/espurna/button.cpp Lines 891 to 893 in f013e04 There is no 1st button, unless you have BUTTON1_PIN or btnGPIO0, so subsequent button config is simply ignored. Which is why I suggested to simply change btnGPIO0 and reboot to apply the new pin. Plus, maybe change btnDefVal0 to 2 to make default state what it sees on boot, since it probably treats it as a click of an already pressed button when you connect the wire: espurna/code/espurna/config/defaults.h Line 212 in f013e04 espurna/code/espurna/config/defaults.h Line 237 in f013e04 |
|
Its working! I hadn't set I realised that triple click wasn't right Final button definitions: The final issue is that |
|
My |
|
Either works. Changing brightness will also change the reported channel value though, since it is scaled |
|
But using |
|
Do you want to close this issue? The fix requires a hardware modification and addition of button definitions. Is there any harm in defining the |
|
Perhaps with a comment? I'd close this tbh, discussion went a bit too long a there's much OT to parse out :) I wonder if other implementations of tuya platform do this initial send that causes the issue though: |
|
I'll look to add the device to the wiki at some point and add a few notes and pictures. |
|
Modification to the board to allow ON/OFF/DIMMING using physical button. |
|
On the rear of the board, cut the track between the output of the switch and R16.
On the front of the board, solder a jumper wire between the switch leg and
I used the following build definitions for control. It allows toggling the light ON/OFF with either a |
After doing the factory reset on this device I had to re run: set tuyaChanState 1, set tuyaSwitch0 0 and set tuyaChannel0 2. LED had gone again even though tuya.show listed it and the button GPIO. tuya.save and a reboot has restored the LED in webUI without having to set the keys. Both LED and BUTTON GPIOs are also listed in the keys. The physical button turns the light ON/OFF but doesn't show it's state in the webUI or MQTT.
Debug data when pressing the button from an OFF state, the light then now turns ON at a dim level (webUI shows 102) and then pressing again which returns to OFF. The RED LED goes ON/OFF but the GREEN doesn't.
Originally posted by @davebuk in #2414 (comment)
The text was updated successfully, but these errors were encountered: