Was able to flash OpenBK7231N_QIO_1.12.54.bin, but it crashes within a minute of booting (whether wifi is configured or not).
I can only read the first 1150976 bytes, and observe the OpenBK images are 1220464 bytes - so maybe they're too big? idk
Had to boot up a Windows system to use encrypt.exe to decrypt the factory firmware backup and get it back to stock...
Added after 10 [minutes]:
P.S. If someone wants me to try anything, the clock is ticking: I got this specifically because it said it supported below freezing, but it doesn't (the LED display went nuts). So regardless of firmware hacking stuff, I'm returning it.
P.P.S. Any suggestions for a non-cloud-able (preferably open source firmware) temperature/humidity sensor that runs on batteries and I can stick in freezers?
Info:MQTT:MQTT_RegisterCallback called for bT obk8C000000/ subT obk8C000000/+/set
Info:MQTT:MQTT_RegisterCallback called for bT cmnd/obk8C000000/ subT cmnd/obk8C000000/+
Debug:CMD:Adding command publish
Debug:MAIN:Initialised other callbacks
Note that explicitly rebooting the device does NOT start the "timer" over - it still dies after 25-30 seconds from the initial boot (not the reboot).
Added after 29 [minutes]:
Pressing the button on the device appears to reboot the CB3S.
I'm wondering if the TuyaMCU is only supposed to power it up "as needed" to report data - I notice it shows the temperature even after/while the CB3S is dead.
But the paper included with it says it has an "AP Mode" which sounds like it would need the CB3S constantly active...
(I actually think I'd prefer it to spawn OpenBK only as-needed to report temperature, but I need to get OpenBK configured for that first at least! But I also note that when I _did_ manage to configure my wifi, OpenBK failed to connect saying the password was wrong - it wasn't)
Added after 35 [minutes]:
Ok, so the CB3S power comes from R2, which comes from C1 - which I am guessing is a capacitor (sorry, I'm not an electronics person so not sure) that the TuyaMCU charges when it wants to.
Connecting 3.3V directly to CB3S gets it to survive beyond the 20 seconds.
"AP mode" is apparently _just_ for setup, and not a persistent AP. So that may not help me either. :/
Added after 1 [hours] 4 [minutes]:
Perhaps a bigger issue: I'm not seeing any useful data from TuyaMCU when I have it running.
The command used in autoexec (or in short startup command) is in the topic I linked before. You start two drivers - tuyaMCU and tmSensor driver. The latter resides on top of tuyaMCu driver and sends packets.
Regarding 3 seconds... no real reason, I just wanted to let things settle up. It's an experimental setup. I am not sure if it will work for your device. Remember that also you might need to discover dpIds later - which variable ID is temperature, which is humidity, etc. Still, it should be easy, just look at integer values and look at the screen.
The temperature might be send as integer even if it has fractional part on screen - it's just sending eg. 255 for 25.5C, 199 for 19.9C, etc. I saw that in TH06 temperature sensor, if I remember correctly.
Remember, this is an experimental setup.some things may be missing, but I can help with implementation if that's needed
There are many things that can go wrong. Even a different baud ratio for UART is possible.
What I'd try doing, is disconnecting RX/TX from WiFi module and trying to interface the MCU with PC, sending packets from RealTerm and checking if it responds.
If you have an original 2MB firmware backup, then it should be also possible to connect RX pin from UART to USB converter to either TX-RX or RX-TX line and watch the communication between MCU an WiFiModule.
This is the way I use to debug TuyaMCU IoT devices.
Then maybe let's go with non-soldering route - restore original flash and then try watching the communication between TuyaMCU module and WiFi module, see what happens on both RX-TX and TX-RX lane. Determine what is being sent by original WiFi module to TuyaMCU so TuyaMCU is not turned off after 30 seconds. See how is the LCD data sent (temperature? date? etc?).