TuyaMCUv2 multiple issues, Tuyasend6 not working

[blakadder]

PROBLEM DESCRIPTION

I've noticed it's reporting this on the new version:

23:12:54.790 TYA: DP len exceeded dpId=103 type 0 (74 > 16

That shouldn't be implemented like that. Type 0 data has spec length 1 to 255 bytes.

Old version didn't have that complain about length

TuyaSend6 is not working at all and since weblog 3 isn't reporting the sent payload it's impossible to debug

There is something missed in the initialisation process, none of the TuyaSend commands work until I do a SerialSend for that dpId. Again not able to debug because no information shown in the log.

After reverting to release 12.2. everything works as expected. Upgrading back to dev gives same issues.

REQUESTED INFORMATION

Make sure your have performed every step and checked the applicable boxes before submitting your issue. Thank you!

• [x ] Read the Contributing Guide and Policy and the Code of Conduct
• [x ] Searched the problem in issues
• [x ] Searched the problem in discussions
• [ x] Searched the problem in the docs
• [x ] Searched the problem in the chat
• Device used (e.g., Sonoff Basic): _____
• [ x] Tasmota binary firmware version number used: dev
  • [ x] Pre-compiled
  • [ x] Self-compiled
• [ x] Flashing tools used: esptool
• [ x] Provide the output of command: Backlog Template; Module; GPIO 255:

  Configuration output here:

• [x ] If using rules, provide the output of this command: Backlog Rule1; Rule2; Rule3:

  Rules output here:

• [ x] Provide the output of this command: Status 0:

  STATUS 0 output here:

• [ x] Set weblog to 4 and then, when you experience your issue, provide the output of the Console log:

  Console output here:

TO REPRODUCE

Receive a message longer than expected 16 with data type 0.

EXPECTED BEHAVIOUR

Same behaviour as in TuyaMCU v1, just output json values

SCREENSHOTS

If applicable, add screenshots to help explain your problem.

ADDITIONAL CONTEXT

Add any other context about the problem here.

(Please, remember to close the issue when the problem has been addressed)

[github-actions]

This issue has been automatically marked as stale because it hasn't any activity in last few weeks. It will be closed if no further activity occurs. Thank you for your contributions.

[github-actions]

This issue was automatically closed because of being stale. Feel free to open a new one if you still experience this problem.

[btsimonh]

suggestions:
change
TUYA_MAX_STRING_SIZE to 256
TUYA_BUFFER_SIZE to ~270

It will use more storage...

TuyaSend6 - please attach any logs, or examples.
It should be able to send up to 16 bytes (TUYA_MAX_STRING_SIZE) to a DPID.
You can also try TuyaSend7 if you can craft the complete message.

Building with this may reveal more?
#define TUYA_MORE_DEBUG

br,
Simon

[Derek-K]

Sorry to ask, what's the difference between TuyaMCUv1 and TuyaMCUv2 (I do see the code for both) and how to select which version to use? I think by default is TuyaMCUv1, right?

[btsimonh]

I created the V2 version since the V1 version did not obey the complete Tuya protocol, and crashed my dimmers. (the tuya serial protocol is used between the ESP and a separate microcontroller).
It represents at least 4 months of evenings, hundreds of megabytes of logs analysed.

V2 runs a state machine based on the public description of the Tuya protocol on thier developer website (at the time), ensuring that all messages are responded to and timeouts obeyed.
V1 blindly sent some stuff on startup, and when my dimmer microcontroller crashed because the protocol was not observed and the microcontroller code was flawed, the only recourse was power-off (Difficult when in the wall, WAF factor -> 0).

The issue with Tuya devices is that the microcontrollers are developed by the manufacturers of the items. Some are good, some are bad, some observe the protocol, some do not.

At the time I developed V2, I asked for help and testing with other devices for a further 4 months, and apart from those (pleased people) who shared the same or similar dimmer, got no response. Then this issue popped up, and I got no response to the above. I cannot help with making V2 better for other devices, as I don't have other Tuya devices, and am not getting feedback or help relating to them.
@arendst rightly reverted to V1 which works for most people, and most people are happy with.

If you have a device which does not play nice with V1, I AM happy to help where I can with V2 if there is something specific it's not doing. But it was a highly complex and fraught development :(.

br, btsimonh

[benjaminnestler]

Hi @btsimonh,
Are you still working on the Tuya mcu v2 source? Do you have a newer branch in your fork?

I try to use Tuya mcu v2 with my Tuya Thermostat. Basically it works but there are some more commands I want to integrate in your version.

The hints from @Jason2866 regarding the length limit of raw data and string type should be default set to supported protocol length limit.

Wh did you use a shadow-like implementation for a defined number of datapoints? What happens if the shadow is filled with datapoints?

[btsimonh]

ooo.. it's a long while back.
But the main thing was i did not want to blow the memory budget, yet did not want to dynamically allocate and destroy in case of fragmentation.

[benjaminnestler]

What was the reason for this buffer/shadow decision?

[btsimonh]

"What was the reason for this buffer/shadow decision?"

I think basically, the shadow separates the TAS requirements from the actual TUYA sends.
This was for a number of reasons.
The protocol is effectively an async state machine. In V2, a TAS command sets the required values in the shadow, and then the state machine actions them using the 'correct' MCU protocol, with handshakes, etc.
In V1, commands were sent blindly, regardless of the protocol state. (e.g. a command could be send in the middle of receiving status). This is what would crash the MCUs.
Tas could set values more quickly than the MCU could action them, and every TAS command caused TAS to hang until the command was sent.
Also, I seem to remember the dimmers reporting 'old' values after a set - which made reading the current values from TAS read the old value. (Specifically on/off state). The shadow reflected the true (last demanded) state of the MCU.
Also some problems with sending ON twice? Hence if shadow is already ON, we don't need to send again? And sending ON twice caused issues in the MCU?
Also, some 'feedback' loops occurred? Leading to multiple commands because the read value did not match what TAS thought it wanted?

hope this helps, it's been a while...