For capturing communication I assume you connect only GND and RX so there should be totally no problem with that. Keep in mind that if you power WiFi module artificially for the time of the capture by connecting external 3.3V, the logic of Low Power TuyaMCU communication will break and you will not get meaningful results.
This is because the WiFi module is the one who starts the transaction after it's power on event.
correct, and also no weekday. we have only the date format: day/month/year, and hour format is 24 hours
Quote:
It's a pity U8 has its markings erased (BTW, @auntlydia, Are they also erased in your units?)
Do you mean that all the values are reset when the device uses power? Yes, with every loss of power, values are reset to factory then MCU pulls new data from firmware, the whole process takes only few seconds. If the battery is low, the device keeps losing power upon attempt to connect to wifi, if the voltage is too low to establish a connection.
Quote:
Also, @auntlydia: Which voltage did you use when you flashed OBK?
I used standard 3.3V from my UART USB module. From my experience, the modules with BK7231 chips function also with 3.0V or less, but I wouldn't go higher than 3.3V...
I just connected wires and flashed as usual, very easy, takes only few minutes
It's a pity U8 has its markings erased (BTW, @auntlydia, Are they also erased in your units?)
Do you mean that all the values are reset when the device uses power?
No, what I was asking is if you can read the physical markings on the ICs; as you can see in the following photo, I can't read anything on U3 and U8 while the marks on U1 are perfectly readable:
On the other hand, I've already prepared the setup for sniffing the traffic on TX1 and RX1:
I've tried to add all the relevant information shown in the display while reading the serial port although, in some of them, I couldn't take notes fast enough, hence the "?" in some information.
Anyway, in this screenshot you can see we have the same FW version:
Let's see if @p.kaczmarek2 can analyze the sniffings and obtain some helpful information... thanks in advance!
If you need some specific captures, please let me know.
BTW: do you know of an easy method to sniff the I2C bus using Arduino, for example? I'll Google for it, but it'd be better if you could give me some advice...
Sorry for the late response! I've been fighting against my scope... I hadn't used it for a long time and wanted to use it for this device, but I found it doesn't work well (if interested, lots of details here and following posts; strange failure, it worked well last time I used it...)
The details of the error are as follows (unfortunately, in Spanish, hope they're still meaningful):
Consulte el final de este mensaje para obtener más detalles sobre cómo invocar a la depuración
Just-In-Time (JIT) en lugar de a este cuadro de diálogo.
************** Texto de la excepción **************
System.ArgumentOutOfRangeException: El índice estaba fuera del intervalo. Debe ser un valor no negativo e inferior al tamaño de la colección.
Nombre del parámetro: index
en System.ThrowHelper.ThrowArgumentOutOfRangeException()
en System.Collections.Generic.List`1.get_Item(Int32 index)
en TuyaMCUAnalyzer.FormTuyaMCUAnalyzer.parseDPData(List`1 p, Int32 ofs)
en TuyaMCUAnalyzer.FormTuyaMCUAnalyzer.displayPacket(List`1 p)
en TuyaMCUAnalyzer.FormTuyaMCUAnalyzer.refresh()
en System.Windows.Forms.Control.OnTextChanged(EventArgs e)
en System.Windows.Forms.TextBoxBase.WmReflectCommand(Message& m)
en System.Windows.Forms.RichTextBox.WmReflectCommand(Message& m)
en System.Windows.Forms.RichTextBox.WndProc(Message& m)
en System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
en System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
************** Ensamblados cargados **************
mscorlib
Versión del ensamblado: 2.0.0.0
Versión Win32: 2.0.50727.9174 (WinRelRS6.050727-9100)
Código base: file:///C:/Windows/Microsoft.NET/Framework64/v2.0.50727/mscorlib.dll
----------------------------------------
TuyaMCUAnalyzer
Versión del ensamblado: 1.0.0.0
Versión Win32: 1.0.0.0
Código base: file:///D:/Archivos%20de%20programa%20(portable)/TuyaMCUAnalyzer-v0.4/TuyaMCUAnalyzer.exe
----------------------------------------
System.Windows.Forms
Versión del ensamblado: 2.0.0.0
Versión Win32: 2.0.50727.9149 (WinRelRS6.050727-9100)
Código base: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Windows.Forms/2.0.0.0__b77a5c561934e089/System.Windows.Forms.dll
----------------------------------------
System
Versión del ensamblado: 2.0.0.0
Versión Win32: 2.0.50727.9171 (WinRelRS6.050727-9100)
Código base: file:///C:/WINDOWS/assembly/GAC_MSIL/System/2.0.0.0__b77a5c561934e089/System.dll
----------------------------------------
System.Drawing
Versión del ensamblado: 2.0.0.0
Versión Win32: 2.0.50727.9149 (WinRelRS6.050727-9100)
Código base: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Drawing/2.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll
----------------------------------------
mscorlib.resources
Versión del ensamblado: 2.0.0.0
Versión Win32: 2.0.50727.9174 (WinRelRS6.050727-9100)
Código base: file:///C:/Windows/Microsoft.NET/Framework64/v2.0.50727/mscorlib.dll
----------------------------------------
System.Windows.Forms.resources
Versión del ensamblado: 2.0.0.0
Versión Win32: 2.0.50727.9149 (WinRelRS6.050727-9100)
Código base: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Windows.Forms.resources/2.0.0.0_es_b77a5c561934e089/System.Windows.Forms.resources.dll
----------------------------------------
************** Depuración JIT **************
Para habilitar la depuración Just In Time (JIT), el archivo de configuración de esta
aplicación o equipo (machine.config) debe tener el
valor jitDebugging establecido en la sección system.windows.forms.
La aplicación también se debe compilar con la depuración
habilitada
Por ejemplo:
<configuration>
<system.windows.forms jitDebugging="true" />
</configuration>
Cuando esté habilitada la depuración JIT, cualquier excepción no controlada
se enviará al depurador JIT registrado en el equipo
en lugar de controlarlo mediante el cuadro de diálogo.
If I copy-paste the hex codes from the first block of the TXT's of my previous post to TuyaMCU Analycer, the error appears sometimes
The messages on your screenshots seems to be normal.
On your capture, I can see:
- dpID 1 value 320, which is 32.0 temperature
- dpID 2 value 47, which is 47% humidity
- dpID 3 value 2, which is a battery state enumeration
The "invalid date" is normal, it's just that this protocol has few bytes reserved for date and first byte tells us whether date is included or not:
I see you have also attached files as well. I will check them out later today or tomorrow, as I am not on my main machine right now and the fixed TuyaMCU analyzer is on my main machine.
I also tried TuyaMCU Analyzer, but got some errors:
Hi, did you try https://github.com/MkMunich/SniffUART/tree/V1.0 ?
This smart tool allows you to sniff both USB serial ports in parallel, if you have 2 USB serial adapters.
I decoded the first txt file using this tool. Please find it attached.
You could do me a favour and use TuyaMCU Analyzer to record. Please let me know, if this works.
BR MK_Munich
Or... maybe C vs F setting? We could try changing that in the app.
I'm attaching the captures with your app. First two blocks are after power on and waiting 2 min. for the first update. Then, change ºC to F in the app and wait for the next update. Finally, changing again to ºC and wait for update.
BTW, using today's version (V0.5) and the error no longer appears!
As menu item "Open Ports" is directly opening both serial ports configured in Settings, I would guess, that Port Settings->UART0 and UART1 need to be configured first.
With File->Import you could load the Sniff file, which I had attached above. So you can see, how the decoded messageg look like.
Ok, it's a pity... Once I flash OBK we could probe the commands for that in similar models; maybe it's programmed in Tuya MCU but the app doesn't use it. Is this possible?
mkmunichmk wrote:
morgan_flint wrote:
I hit "Open ports" it closes
As menu item "Open Ports" is directly opening both serial ports configured in Settings, I would guess, that Port Settings->UART0 and UART1 need to be configured first.
I did select the relevant ports in Port Settings->UART0 and UART1, Is there anything else to configure?
The file import works OK
EDIT: I made some new captures with TuyaMCU Explorer and could check:
- After 2 min it doesn't update if there's no change in temperature
- If I heat the sensor, it immediately reports a change (if the 2 min. have passed)
- If I heat again and press the button it reports the change inmediatelly.
I also disconnected the USB port with TuyaMCU Explorer opened and it forced the attached error. I understand it's not relevant, as you're not supposed to do that, but just in case it's interesting for @p.kaczmarek2
Maybe, just maybe, executing a tuyaMcu_sendQueryState command may cause more dpIDs to be sent, but as far as I know, it would only work on non-battery powered models. So I wouldn't bet on that.
Maybe, just maybe, executing a tuyaMcu_sendQueryState command may cause more dpIDs to be sent, but as far as I know, it would only work on non-battery powered models. So I wouldn't bet on that.
Ok, I'll try that when I flash OBK; maybe I'll have to ask you how to do it...
I'll also extract a backup of the original FW, don't remember now if @auntlydia already sent it, but if it's not the case and you're interested I'll do so.
Please, look also at the edit of my previous message I did while you were sending yours, maybe you're interested in the reported "error"
Ok, finally today I soldered the additional wires and changed the connections to be able to use BK7231flasher and make a backup of the original FW.
In the beginning, I only used TX1, RX1 (both from the islands at the PCB) and GND (directly from the module, as module's GND is connected to the main GND via Mosfet Q1), and it seemed to work, even without connecting 3.3V or the battery, presumably taking power from the RX and TX lines (I've read this can happen in other threads here; seems like te developer didn't read this), but the reading halted before completing. So I also soldered a cable to the module's 3.3V pad and fed it from the USB to serial converter. This way, after rebooting the module with the CEN signal, I got a full backup. Curiously, and despite the Q1 thing, the full module got power, the display showed the correct time, etc, just the low battery icon was flashing and sending low battery alarms to Tuya App.
Considering this, I think it's, I think it's important to read/flash the module about 15-20 seconds after powering it, but not much later than that, to allow the TuyaMCU to start and end initial communication with the module, but not give enough time for the next cycle to happen (about 2 minutes after that). This way, the reading/flashing happens while the MCU thinks the module is sleeping.
At the end of the FW backup, BK7231flasher came up with the following screen:
The full content of the message in the left window is in the attached TH08_BackupMessage.txt and the full dialog in BK7231flasher main screen is at TH08_BackupDialog.txt, also attached. Finally, I'm also attaching lastRawDecryptedStrings.bin, generated at the end of the backup. I'm not very sure about how to interpret them, but maybe @p.kaczmarek2 can get some new information from them.
I'm not attaching the full FW as @auntlydia already did it at post #3, but if it's of any help I can also attach it. I masked some info as keys and MAC address for privacy, but if it's relevant I can send it privatelly
The only thing more that we can try is the Tuya API approach, but I don't know much about it. I've seen that if you create Tuya developer account (or something like that), you can see some extra list of dpIDs available. Maybe @DeDaMrAz knows more about it.
I had already followed those steps (I think all of them) and I can see the device in HA. But still can't find there anything related to changing the update period.
This is the screenshot of Integrations:
This is the screenshot of "Devices" under the previous one:
The device of interest is the last one, and this is the screenshot of its page:
Curiously, the Google translation of the Chinese part of the name is "Old interface mass-produced".
If I hit "descargar diagnósticos" there (download diagnostics), I get the attached txt (sorry for the strange name, but I conserved the original in case it's meaningful). I can't find anything new for me there...
Does it reveal something to any of you? Is there anywhere else where I can look? (I tried on Tuya Developer's project page, but got lost very soon).
Thank you!
EDIT: I navigated a little more in the Tuya's website and found this:
Apparently, the only instruction that can be sent is related to the ºC - F conversion. Am I right?
Hi @morgan_flint - unfortunately I don't have that device.
I was just giving out the links to help you create a Tuya IoT account and project
Ok, thanks!
I understood you didn't have it, but I thought that maybe you could guide me to where I can find more info about it in the Tuya place.
I've continued looking there and came to this point:
If I try to change to "DP Instruction" it gives a warning:
I changed it anyway, but couldn't see anything else:
And then I went to another device:
And could see that, in this one, there's effectively one more entry in the DP side, something that didn't happen with the sensor... So I'm afraid the sensor doesn't have any hidden feature, unless undocumented features don't appear here... What about sending something not listed from here to see what happens?
Added after 2 [minutes]:
DeDaMrAz wrote:
But if that setting is not available in the phone app it is unlikely that it is avaliable/active on that device.
Hello, DeDaMrAz. I hadn't seen your post as it came up while writing this one. Sorry!
Is it worth trying to send something from similar products as I said before, or could I brick the device?
Ok, most probably, that's the case, but I thought, maybe, as the developers of these products frequently copy each other, some features could exist in the MCU FW, although not used officially, if this FW was an evolution of a previous one...
Do you have the code of the instruction to change the update time in a similar product to give it a try?
EDIT: Tried instructions from here and here, but no luck:
With the standard one, no problem:
Just to check, also tried the non-standard function in the switch Values taken from here:
But gives "offline" and I can't bring it online as it's flashed with OBK now... So no conclusions from this
If you have flashed the device to OBK the Tuya IoT wont be able to send anything to the device.
You have to flash Tuya firmware back on it (from your backup if you have one) and then try. But even then I am not sure what these options will do as I have never tried them.
If you have flashed the device to OBK the Tuya IoT won't be able to send anything to the device
Yes, I expected that, the only objective of the attempt was to see if it gave the message "command or value not support", supposing this was checked by Tuya website instead of the device.
Changing the subject, I made several more measurements with the original FW: sniffing I2C to ATH20 and LCD, and trying to find out the traffic between U3 and U8.
From the I2C sniffing, I found that the sensor is polled quite often, every few seconds. This explains why it reacts to (significative?) changes in temperature, powering the module and sending the information even if the two-minute "standard" period hasn't passed. Also, the traffic in LCD_SDA and LCD_SCL has more or less the same frequency. I used rather crude tools for this (Arduino Nano and ESP32), so I don't know if the logs I obtained are useful, but if someone wants to analyze them, I'll post them here.
I've not been able to obtain any conclusions about the traffic between U3 and U8 (pins 4 and 5 to pins 8 and 10). I've tried supposing it was I2C or RX-TX, both with no results.
Then, after these experiments, I finally flashed OBK in the TH08. In the beginning, like @auntlydia , I tried to do it without interrupting TX1 and RX1 (I had been able to read a backup like this), and, apparently, the flashing went OK, but for some reason, the device didn't work. The next flash attempts failed so I ended up having to interrupt the connections between U3 and M1 (RX1, TX2, and CEN) to be able to flash it again. I think the first time it worked without interrupting as I managed to do it in the 2 min "refractory period" during which the Tuya MCU thinks the module is powered off (by disconnecting its GND from the main GND with Q1). But, once the original FW was lost, I found that the Tuya MCU insisted on talking with the module for a longer period, so it interfered with the flashing, not only at the RX and TX, but also resetting it (CEN is connected to pin 8 of U3). More on this later.
Finally, I managed to get it flashed well, connect it to the AP, and set SSID and password. Then, browsed to its IP, launched the web application, used the same autoexec.bat as @auntlydia at post #3, and got confirmation of connection to the NTP server and correct values for temperature and humidity at the initial screen. (IP/index). In the beginning, the device's display didn't show the date/time, but later it did; I'm not sure if this was after configuring MQTT or if this was just a coincidence.
Channels 1 and 2 are temperature (x10) and humidity, as stated in the autoexec, and Channel 3 (ReadOnly there) seems to be the battery status (1=ok 2=low).
So everything seems to go well, except for one detail: As I said before, once removed the original FW, the "on" cycle of M1 (the time Q1 is switched on) goes from about 10 seconds to more than one minute. I think this must be because the Tuya MCU is waiting for some kind of confirmation from M1 (something like "successfully connected to WiFi or to the cloud") that the original FW gave bot OBK doesn't, so it keeps activating the module for a longer time and/or resets it via CEN to try to get a connection. Then, after about 1 min, it gives up until the next reconnection time (after 2 min, a change on temp or when pressing the button).
Could it be like this? In this case, Is it possible to include that confirmation in OBK (Tuya MCU driver)? It would be good, as the longer the module is on, the higher the battery consumption.
EDIT: I've captured the traffic between the module and the MCU with TuyaMCUAnalyzer, with OBK flashed, and compared it with previous captures with the original FW. I'm attaching two files with the comparisons in RAW and decoded formats. You can see the original FW sent the following message after receiving each of the three messages with the measurements (temperature, humidity, and battery status) from the MCU
That OBK doesn't send. Also, the end of the traffic is different; the original FW sent to the MCU just one packet:
While OBK sends 3 packets instead:
Could this be the cause for the higher WiFi on time with OBK?
There are also two other differences (in orange in the attached documents), but as they are sent from the MCU, I don't think they are relevant. In case they are necessary, I have the captures in .txt and the comparisons in .xlsx formats.
The discussion revolves around the TH08 LCD Calendar/Clock/Temperature/Humidity device, focusing on its teardown, firmware flashing, and integration with OpenBK. Users share experiences with the device's functionality, including issues with sensor readings, MQTT communication, and NTP server configuration. Key points include the necessity of desoldering RX and TX pins for successful firmware flashing, the importance of correct NTP server settings for time synchronization, and methods to maintain Wi-Fi connectivity. Users also explore power management strategies for the device, including the implications of using external power sources and the impact on battery life. Solutions for ensuring accurate temperature and humidity readings are discussed, along with troubleshooting steps for connectivity issues. Summary generated by the language model.
![[ZIGBEE] 20A Zigbee socket with energy metering (Tuya TS011F_plug_3)](https://obrazki.elektroda.pl/1000454900_1749493372_thumb.jpg)
![[W600 / TW-03] Door Sensor - Bootloop on 1.18.110/109 Firmware](https://obrazki.elektroda.pl/5552096400_1749191730_thumb.jpg)
