Differences between SniffUART and TuyaMcu Analyzer: Improved USB Adapter Communication

There is a further Windows program available on GitHub named "SniffUART".



What is the difference to TuyaMcu Analyzer?
- improve communication to serial USB adapters.
- all Tuya messages specified by Tuya are decoded.
- maintainable, means errors can easily be fixed & further decoding can be added.

A lot of work - hopefully worth it to you.
Please have a look at the Readme.md on GitHub.
https://github.com/MkMunich/SniffUART

I appreciate your feedback.
Best Regards,
MK_Munich

Nice work! I will definitely try it out when I get next TuyaMCU device.

Do you also decode date (calendar) packets?

p.kaczmarek2 wrote:

Do you also decode date (calendar) packets?

For sure. If these messages are specified in either McuSerialPort
https://developer.tuya.com/en/docs/iot/tuya-c...ess-protocol?id=K9hhi0xxtn9cb#QueryServerTime
or McuLowPower
https://developer.tuya.com/en/docs/iot/tuyacl...niversalserialaccessprotocol?id=K95afs9h4tjjh

then they are already included.

I started with spec McuHomeKit
https://developer.tuya.com/en/docs/iot/wifi-m...lopment-overview-for-homekit?id=Kaa8fvusmgapc

Is the HomeKit protocol different than standard TuyaMCU? In which devices is it used? I haven't looked into that protocol yet.

At first glance, the messages are very similar. Most messages look identical, but I saw one response having a different meaning...

From the 'header' of the Tuya spec:
"This topic describes how to interface your MCU with Tuya’s Wi-Fi module that can be connected to both the Tuya IoT Platform and the Apple HomeKit platform. After implementing the serial protocol, your product can communicate with Tuya’s Wi-Fi module and interact with ‘Powered by Tuya’ products and HomeKit-compatible products."

So far I've seen from examples, which were uploaded to TuyaMCU Analyzer, there were some devices using this protocol.

Added after 29 [minutes]:

In case the messages are identical, I'll delegate decoding from McuHomeKitMsg to McuSerPortMsg. This has the advantage that code is not duplicated and it can be seen (inside source code) that the message is the same.

@mkmunichmk

Nice job!!

Decided to give this a test as me and @p.kaczmarek2 are working on something TuyaMCU related but I am not having luck decoding the messages so far. Any idea?

You have set decoder MCU Low Power?

Capture in HEX looks to be alright and we can decode them using TuyaMCU Analyzer from @p.kaczmarek2

It looks like SniffUART has a problem finding the end of a message. You'll need to play around with the parameter "Read Timeout" in the port settings. This time in ms defines the gap time between messages. Normally, a serial port will send all bytes at once (using an internal 16-byte buffer if the chip). Of course, the Windows driver could 'divide' the byte stream, so the first byte could come immediately and the 'rest' with a second call to ReadBytes. For this, I'd configured a minimal message length of 2 bytes. Maybe I should increase this fixed value in the code.
But first, you should try to increase the Read Timeout to e.g. 100 ms.

One last-minute change has been to increase the thread priority. If you can compile the source code, you could comment this out
in PortHandler.cs at line ~33
_readThread.Priority = ThreadPriority.Highest;
Maybe "AboveNormal" would help? Please let me know.

Hmm so you don't buffer them together? I have taken a different approach in my flasher, you can check my ring buffer code for more info.

p.kaczmarek2 wrote:

you can check my ring buffer code

I wanted to avoid this, as in general messages could have different (how to say) structures. In the past I had a protocol, where it was (nearly) impossible to find a start and the end of a message. I agree, Tuya messages are more structured e.g. having a 2 byte header.
Unfortunately I do not have many different Tuya devices to test with. But I'm sure, we'll find a solution (e.g. your ring buffer).

My last comment seems to be lost So again:
I updated the SniffUART.exe on GitHub (as I do not know whether you are able to compile the sources).

I took back the thread priority to normal and increased the ReceivedBytesThreshold=75; (Maybe it is still too low for messages having a length > 75 bytes).

A hint to Read Timeout: This time should not be too short, as it defines the 'distance' to the next following message. I'm assuming this can't be quicker than 100 ms in a Tuya device.

Please let me know whether this helped.
Best Regards, MK_Munich

I'll try that soon and will report back.

One thing I noticed is that you only have 9600 bps, you do know there are 115200 bps devices out there??

Tasmota allows you to choose between 9600 and 115200 with a flag, in OpenBK, you can specify any reasonable baud.

SniffUART supports all (typical) baud rates. Hint: you could also specify different settings for each port, but normally you'll set the flag File->Port Settings->One port.

I completed McuHomeKitMsg. So all known (to me) Tuya messages should decode.
To get a feeling of how the decoded messages look, download SniffUART.exe from GitHub, start it, and open the menu File->Decode Messages dialog. Then paste the example test messages "Test Mcu*.txt" into the dialog and press 'Decode'. Enjoy!

I did not have many messages from real Tuya devices. In case the spec gave examples, I took them over into "Test Mcu*.txt". If there was no example given, I invented my own.
The quality of the Tuya specs is sometimes okay, sometimes I was only able to guess and decode as I understood it. I do not expect it to be error-free. The decoding has ~3,500 lines of code...
Please use GitHub to report issues.

A hint for @p.kaczmarek2 who asked about differences in the decoder classes: whenever possible, I redirected the decoding to McuSerPortMsg. You can see in the source code where the decoding takes place. One major difference is in the data unit, which is completely different in McuHomeKitMsg.

@mkmunichmk

Do you mind sharing a compiled binary here? Or create a new build on GitHub?

An actual build is found on GitHub.

Good news: I improved the UART communication. The end of a messages is now detected by timing out after the last byte of a message had been received.
I used my battery powered Tuya door contact (old version with reed contact and TuyaMCU) to test. I'm not sure,whether I found an issue...
As my Tuya door contact is not a DS06 device and looks from hardware very similar to https://www.elektroda.com/rtvforum/topic3914412.html#20350672 I do not know, whether to open a new thread? @p.kaczmarek2 Please advice.

@mkmunichmk if you can do a detailed write-up of new device, you are welcome to do so. Add some photos, configuration info, packet captures... we can send you a free gift for contributing a good, detailed device description:
https://www.elektroda.com/rtvforum/topic3950844.html#20500470

Here's my Door sensor topic:
https://www.elektroda.com/rtvforum/topic3914412.html
if yours is different, please share the information.

I did so ... https://www.elektroda.com/rtvforum/topic3914412-30.html#20686497
Best Regards MK_Munich