openshwprojects
Separate implementation for TuyaMCU and TuyaMCULE
Even tuya is inconsistent about naming. Sometimes they refer to "version 0" as low-power other times low-energy. The sdk is called MCU_LE so, i went with that.
With these changes finally my PIR sensor (P01) and Temperature and Humidity (TH01Y) sensors are working correctly.
The changes are breaking and the test needs to be adjusted. Works fine with real devices.
With these changes finally my PIR sensor (P01) and Temperature and Humidity (TH01Y) sensors are working correctly.
Interesting. In layman's terms what is the observed difference now? what is working correctly, what wasn't before etc?
Pretty much none of the tuyaMcu_* script commands worked with LE. Dp cache implementation was incorrect.
Pir sensor went to sleep before it reported the state to HA.
Temp sensor never went to sleep and drained the battery pretty quickly.
The LE protocol has the same structure, but all the commands are different than the general one. It was kinda hacked into it, resulting in the logs being completely incorrect.
On September 15, 2025 8:23:26 a.m. GMT+02:00, divadiow @.***> wrote:
divadiow left a comment (openshwprojects/OpenBK7231T_App#1795)
With these changes finally my PIR sensor (P01) and Temperature and Humidity (TH01Y) sensors are working correctly.
Interesting. In layman's terms what is the observed difference now? what is working correctly, what wasn't before etc?
-- Reply to this email directly or view it on GitHub: https://github.com/openshwprojects/OpenBK7231T_App/pull/1795#issuecomment-3290656381 You are receiving this because you authored the thread.
Message ID: @.***>
This looks very promising, but can you write a bit more what you exactly changed, before I have time to review it?
So you basically split... TuyaMCU mains powered and TuyaMCU battery powered into two files?
Or is there a third TuyaMCU dialect?
Would it be possible to have it without breaking old autoexecs?
[EDIT] I looked into code briefly, you renamed tmSensor to tuyaMCULE, would it be possible to... hack it so starting tmSensors stops main TuyaMCU driver, or something like that? So we don't break old autoexecs?
There are two versions. Generic TuyaMCU and Low-Power TuyaMCU / TuyaMCU LE. (They call that on their website.) They are similar, but pretty different.
I think we could add code that if you start tmSensors it stops TuyaMCU and starts TuyaMCULE then defines some aliases with some warning that the code your are using is deprecated.
So you basically added aliases to notify users that something does not work for LE? Well, it never worked for LE before, anyway...
Ok, what is the compatibility with current OBK standard now? Will it allow 100% seamless transition from old update to your PR?
Related idea: maybe we could just.... merge LE driver into tmSensor itself, so there are no 3 drivers (one unused), but still TuyaMCU and tmSensor, where tmSensor has your LE backend.
Ok, what is the compatibility with current OBK standard now? Will it allow 100% seamless transition from old update to your PR?
I think it should for the most part. Except the old driver didn't care if you defined the wrong type for dp. This one throws an error, see bugfixes in the test cases. You need to have the correct types, otherwise the dp cache will break without sending any feedback.
Well, so what happens if somebody has maped bool to integer and gets this update? It breaks his config?
Well, so what happens if somebody has maped bool to integer and gets this update? It breaks his config?
Yes, it does. It could be changed into a warning. When the sends GET_DP_CACHE and you give back the wrong type, it doesn't send you back an error, just does nothing.
I got a WIOONI T13. It sends a non-standard state request. Implemented that too.
I have a P01, TH01Y, T08 works fine. T01Pro that needs to be tested. That one is a pain to flash due to the screen being soldered over the chips.
Sooo.... change to warning and we will merge it, probably? I can't see any other reasons not to... but as i said, I would really like to avoid breaking old configs for our users. From my experience, I can tell that there are some people who are very eager to update, even if everything is working okay.
there are some people who are very eager to update, even if everything is working okay.
Yeah. I know a few. I rather keep stuff outdated then break things that works perfectly as-is.
Changed it to warning. I got an AirBox01 that uses generic TuyaMCU. I'll look into that code next. I seen a few things that could be cleaned up and fixed there.
Info:CFG:####### Boot Count 134 #######
Warn:CFG:CFG_InitAndLoad: Correct config has been loaded with 15 changes count.
Error:CMD:no file early.bat err -2
Info:GEN:PIN_SetupPins pins have been set up.
Info:MAIN:Main_Init_Before_Delay done
Info:MAIN:Main_Init_Delay
Info:MAIN:Main_Init_Delay done
Info:MAIN:Main_Init_After_Delay
Info:MAIN:Registered for wifi changes
Info:MAIN:Connecting to SSID [Ordinacija]
Info:GEN:We have fast connection data, connecting...
Info:MAIN:Using SSID [Ordinacija]
Info:MAIN:Using Pass [DraganSavatic]
Error:HTTP:Created HTTP SV thread with (stack=2048)
Info:MQTT:MQTT_RegisterCallback called for bT Smoke_detector/ subT Smoke_detector/+/set
Info:MQTT:MQTT_RegisterCallback called for bT Smoke_detector/ subT Smoke_detector/+/set
Info:MQTT:MQTT_RegisterCallback called for bT cmnd/Smoke_detector/ subT cmnd/Smoke_detector/+
Info:MQTT:MQTT_RegisterCallback called for bT cmnd/Smoke_detector/ subT cmnd/Smoke_detector/+
Info:MQTT:MQTT_RegisterCallback called for bT Smoke_detector/ subT Smoke_detector/+/get
Info:MQTT:MQTT_RegisterCallback called for bT homeassistant/ subT homeassistant/+
Info:CMD:CMD_StartScript: started @startup at the beginning
Info:CMD:CMD_StartScript: started autoexec.bat at the beginning
Info:MAIN:Main_Init_After_Delay done
Info:MAIN:Main_OnWiFiStatusChange - WIFI_STA_CONNECTING - 1
Info:MAIN:Started TuyaMCULE.
Info:MAIN:Main_OnWiFiStatusChange - WIFI_STA_DISCONNECTED - 2
Info:MAIN:Main_OnWiFiStatusChange - WIFI_STA_DISCONNECTED - 2
Info:TuyaMCU:Consumed 7 unwanted non-header byte in Tuya MCU buffer
Info:TuyaMCU:Skipped data (part) AA 00 10 00 01 00 10
Info:TuyaMCU:Received: 55 AA 00 10 00 01 00 10
Info:TuyaMCU:ProcessIncoming[v=0]: cmd GetDPCache (0x10) len 8
Info:TuyaMCU:HandleGetDpCache: dpId table:
Info:TuyaMCU:Sent: 55 AA 00 10 00 02 01 00 12
Info:TuyaMCU:Sent: 55 AA 00 01 00 00 00
Info:MAIN:Time 1, idle 197372/s, free 72008, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 2/38
Info:TuyaMCU:Received: 55 AA 00 01 00 24 7B 22 70 22 3A 22 6C 62 6B 6B 79 61 6A 78 72 62 62 74 63 77 6C 63 22 2C 22 76 22 3A 22 31 2E 30 2E 32 22 7D 54
Info:TuyaMCU:ProcessIncoming[v=0]: cmd ProductInfo (0x1) len 43
Info:TuyaMCU:HandleProductInformation: received {"p":"lbkkyajxrbbtcwlc","v":"1.0.2"}
Info:TuyaMCU:Received: 55 AA 00 10 00 01 00 10
Info:TuyaMCU:ProcessIncoming[v=0]: cmd GetDPCache (0x10) len 8
Info:TuyaMCU:HandleGetDpCache: dpId table:
Info:TuyaMCU:Sent: 55 AA 00 10 00 02 01 00 12
Info:MAIN:Time 2, idle 180371/s, free 72048, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 2/38
Info:MAIN:Main_OnWiFiStatusChange - WIFI_STA_CONNECTED - 4
Info:TuyaMCU:Received: 55 AA 00 10 00 01 00 10
Info:TuyaMCU:ProcessIncoming[v=0]: cmd GetDPCache (0x10) len 8
Info:TuyaMCU:HandleGetDpCache: dpId table:
Info:TuyaMCU:Sent: 55 AA 00 10 00 02 01 00 12
Info:MQTT:mqtt_userName dedamraz
mqtt_pass ********
mqtt_clientID Smoke_detector
mqtt_host 192.168.0.75:1883
Info:TuyaMCU:Sent: 55 AA 00 02 00 01 03 05
Info:MAIN:Time 3, idle 184145/s, free 71680, MQTT 0(1), bWifi 1, secondsWithNoPing -1, socks 2/38
Info:MQTT:mqtt_connection_cb: Successfully connected
Info:MQTT:mqtt_subscribed to Smoke_detector/+/set
Info:MQTT:mqtt_subscribed to Smoke_detector/+/set
Info:MQTT:mqtt_subscribed to cmnd/Smoke_detector/+
Info:MQTT:mqtt_subscribed to cmnd/Smoke_detector/+
Info:MQTT:mqtt_subscribed to Smoke_detector/+/get
Info:MQTT:mqtt_subscribed to homeassistant/+
Info:GEN:Channel 1 type changed to OpenClosed_inv
Info:GEN:Channel 2 type changed to BatteryLevelPercent
Info:GEN:Channel 3 type changed to TextField
Info:GEN:Channel 4 type changed to temperature_div10
Info:TuyaMCU:Received: 55 AA 00 02 00 00 01
Info:TuyaMCU:ProcessIncoming[v=0]: cmd WifiState (0x2) len 7
Info:GEN:Channel 5 type changed to Humidity
Info:GEN:Channel 6 type changed to OpenClosed_inv
Info:GEN:Channel 7 type changed to TextField
Info:GEN:Channel 8 type changed to OpenClosed
Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic homeassistant/status
Info:MQTT:HA status - online
Info:MQTT:Publishing val Smoke_detector to Smoke_detector/host retain=0
Info:MAIN:Time 4, idle 169359/s, free 71656, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 2/38
Info:MAIN:Boot complete time reached (3 seconds)
Info:CFG:####### Set Boot Complete #######
Info:TuyaMCU:Received: 55 AA 00 10 00 01 00 10
Info:TuyaMCU:ProcessIncoming[v=0]: cmd GetDPCache (0x10) len 8
Info:TuyaMCU:HandleGetDpCache: dpId table:
Info:TuyaMCU:Sent: 55 AA 00 10 00 2E 01 07 6B 04 00 01 00 65 01 00 01 00 18 02 00 04 00 00 00 00 17 02 00 04 00 00 00 00 10 01 00 01 01 0F 02 00 04 00 00 00 00 01 04 00 01 00 85
Info:TuyaMCU:Received: 55 AA 00 05 00 05 10 01 00 01 01 1C
Info:TuyaMCU:ProcessIncoming[v=0]: cmd State (0x5) len 12
Info:TuyaMCU:HandleState: dpId 16, dpType bool (0x1) and 1 data bytes
Info:TuyaMCU:HandleState: dpValue: 01
Info:TuyaMCU:HandleState: g_HandleStateCbEpectedCount: 1
Info:GEN:No change in channel 3 (still set to 1) - ignoring
Info:TuyaMCU:TuyaMCULE_HandleStateCb: g_HandleStateCbEpectedCount: 0
Info:TuyaMCU:Sent: 55 AA 00 05 00 01 00 05
Info:MQTT:Publishing val OpenBK7231N 1795_merge_1b9218806ab8 Oct 5 2025 13:38:08 to Smoke_detector/build retain=0
Info:MAIN:Time 5, idle 168347/s, free 51352, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 4/38
Info:TuyaMCU:Received: 55 AA 00 10 00 01 00 10
Info:TuyaMCU:ProcessIncoming[v=0]: cmd GetDPCache (0x10) len 8
Info:TuyaMCU:HandleGetDpCache: dpId table:
Info:TuyaMCU:Sent: 55 AA 00 10 00 2E 01 07 6B 04 00 01 00 65 01 00 01 00 18 02 00 04 00 00 00 00 17 02 00 04 00 00 00 00 10 01 00 01 01 0F 02 00 04 00 00 00 00 01 04 00 01 00 85
Info:TuyaMCU:Received: 55 AA 00 05 00 05 10 01 00 01 01 1C
Info:TuyaMCU:ProcessIncoming[v=0]: cmd State (0x5) len 12
Info:TuyaMCU:HandleState: dpId 16, dpType bool (0x1) and 1 data bytes
Info:TuyaMCU:HandleState: dpValue: 01
Info:TuyaMCU:HandleState: g_HandleStateCbEpectedCount: 1
Info:GEN:No change in channel 3 (still set to 1) - ignoring
Info:TuyaMCU:TuyaMCULE_HandleStateCb: g_HandleStateCbEpectedCount: 0
Info:TuyaMCU:Sent: 55 AA 00 05 00 01 00 05
0 00 01
Info:TuyaMCU:ProcessIncoming[v=0]: cmd WifiState (0x2) len 7
Info:TuyaMCU:Received: 55 AA 00 10 00 01 00 10
Info:TuyaMCU:ProcessIncoming[v=0]: cmd GetDPCache (0x10) len 8
Info:TuyaMCU:HandleGetDpCache: dpId table:
Info:TuyaMCU:Sent: 55 AA 00 10 00 2E 01 07 6B 04 00 01 00 65 01 00 01 00 18 02 00 04 00 00 00 00 17 02 00 04 00 00 00 00 10 01 00 01 01 0F 02 00 04 00 00 00 00 01 04 00 01 00 85
Info:TuyaMCU:Received: 55 AA 00 05 00 08 17 02 00 04 00 00 01 10 3A
Info:TuyaMCU:ProcessIncoming[v=0]: cmd State (0x5) len 15
Info:TuyaMCU:HandleState: dpId 23, dpType val (0x2) and 4 data bytes
Info:TuyaMCU:HandleState: dpValue: 00 00 01 10
Info:TuyaMCU:HandleState: g_HandleStateCbEpectedCount: 1
Info:GEN:CHANNEL_Set channel 4 has changed to 272 (flags 0)
Info:MQTT:Channel has changed! Publishing 272 to channel 4
Info:MQTT:Publishing val 272 to Smoke_detector/4/get retain=0
Info:TuyaMCU:Received: 55 AA 00 05 00 05 10 01 00 01 01 1C
Info:TuyaMCU:ProcessIncoming[v=0]: cmd State (0x5) len 12
Error:TuyaMCU:HandleState: Wtf?! g_HandleStateCbEpectedCount > 0 (1)
Info:TuyaMCU:HandleState: dpId 16, dpType bool (0x1) and 1 data bytes
Info:TuyaMCU:HandleState: dpValue: 01
Info:TuyaMCU:HandleState: g_HandleStateCbEpectedCount: 2
Info:GEN:No change in channel 3 (still set to 1) - ignoring
Info:TuyaMCU:TuyaMCULE_HandleStateCb: g_HandleStateCbEpectedCount: 1
Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic Smoke_detector/4/get
Info:TuyaMCU:TuyaMCULE_HandleStateCb: g_HandleStateCbEpectedCount: 0
Info:TuyaMCU:Sent: 55 AA 00 05 00 01 00 05
Info:TuyaMCU:Received: 55 AA 00 05 00 08 18 02 00 04 00 00 00 2A 54
Info:TuyaMCU:ProcessIncoming[v=0]: cmd State (0x5) len 15
Info:TuyaMCU:HandleState: dpId 24, dpType val (0x2) and 4 data bytes
Info:TuyaMCU:HandleState: dpValue: 00 00 00 2A
Info:TuyaMCU:HandleState: g_HandleStateCbEpectedCount: 1
Info:GEN:CHANNEL_Set channel 5 has changed to 42 (flags 0)
Info:MQTT:Channel has changed! Publishing 42 to channel 5
Info:MQTT:Publishing val 42 to Smoke_detector/5/get retain=0
Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic Smoke_detector/5/get
Info:TuyaMCU:TuyaMCULE_HandleStateCb: g_HandleStateCbEpectedCount: 0
Info:TuyaMCU:Sent: 55 AA 00 05 00 01 00 05
Info:TuyaMCU:Received: 55 AA 00 06 00 00 05
Info:TuyaMCU:ProcessIncoming[v=0]: cmd GetLocalTime (0x6) len 7
Info:TuyaMCU:Sent: 55 AA 00 06 00 08 01 46 01 01 00 00 00 04 5A
Info:TuyaMCU:Received: 55 AA 00 05 00 08 0F 02 00 04 00 00 00 64 85
Info:TuyaMCU:ProcessIncoming[v=0]: cmd State (0x5) len 15
Info:TuyaMCU:HandleState: dpId 15, dpType val (0x2) and 4 data bytes
Info:TuyaMCU:HandleState: dpValue: 00 00 00 64
Info:TuyaMCU:HandleState: g_HandleStateCbEpectedCount: 1
Info:GEN:CHANNEL_Set channel 2 has changed to 100 (flags 0)
Info:MQTT:Channel has changed! Publishing 100 to channel 2
Info:MQTT:Publishing val 100 to Smoke_detector/2/get retain=0
Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic Smoke_detector/2/get
Info:TuyaMCU:TuyaMCULE_HandleStateCb: g_HandleStateCbEpectedCount: 0
Info:TuyaMCU:Sent: 55 AA 00 05 00 01 00 05
Info:TuyaMCU:Received: 55 AA 00 10 00 01 00 10
Info:TuyaMCU:ProcessIncoming[v=0]: cmd GetDPCache (0x10) len 8
Info:TuyaMCU:HandleGetDpCache: dpId table:
Info:TuyaMCU:Sent: 55 AA 00 10 00 2E 01 07 6B 04 00 01 00 65 01 00 01 00 18 02 00 04 00 00 00 2A 17 02 00 04 00 00 01 10 10 01 00 01 01 0F 02 00 04 00 00 00 64 01 04 00 01 00 24
Info:TuyaMCU:Received: 55 AA 00 0A 00 00 09
Info:TuyaMCU:ProcessIncoming[v=0]: cmd WifiUpdate (0xa) len 7
Error:TuyaMCU:ProcessIncoming: unhandled type WifiUpdate (0xa)
Info:TuyaMCU:Received: 55 AA 00 05 00 05 10 01 00 01 01 1C
Info:TuyaMCU:ProcessIncoming[v=0]: cmd State (0x5) len 12
Info:TuyaMCU:HandleState: dpId 16, dpType bool (0x1) and 1 data bytes
Info:TuyaMCU:HandleState: dpValue: 01
Info:TuyaMCU:HandleState: g_HandleStateCbEpectedCount: 1
Info:GEN:No change in channel 3 (still set to 1) - ignoring
Info:TuyaMCU:TuyaMCULE_HandleStateCb: g_HandleStateCbEpectedCount: 0
Info:TuyaMCU:Sent: 55 AA 00 05 00 01 00 05
Info:MQTT:Publishing val 33.09 to Smoke_detector/temp retain=0
Info:MAIN:Time 7, idle 112135/s, free 62600, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 4/38
Info:TuyaMCU:Received: 55 AA 00 10 00 01 00 10
Info:TuyaMCU:ProcessIncoming[v=0]: cmd GetDPCache (0x10) len 8
Info:TuyaMCU:HandleGetDpCache: dpId table:
Info:TuyaMCU:Sent: 55 AA 00 10 00 2E 01 07 6B 04 00 01 00 65 01 00 01 00 18 02 00 04 00 00 00 2A 17 02 00 04 00 00 01 10 10 01 00 01 01 0F 02 00 04 00 00 00 64 01 04 00 01 00 24
Info:TuyaMCU:Received: 55 AA 00 0A 00 00 09
Info:TuyaMCU:ProcessIncoming[v=0]: cmd WifiUpdate (0xa) len 7
Error:TuyaMCU:ProcessIncoming: unhandled type WifiUpdate (0xa)
Info:TuyaMCU:Received: 55 AA 00 05 00 05 10 01 00 01 01 1C
Info:TuyaMCU:ProcessIncoming[v=0]: cmd State (0x5) len 12
Info:TuyaMCU:HandleState: dpId 16, dpType bool (0x1) and 1 data bytes
Info:TuyaMCU:HandleState: dpValue: 01
Info:TuyaMCU:HandleState: g_HandleStateCbEpectedCount: 1
Info:GEN:No change in channel 3 (still set to 1) - ignoring
Info:TuyaMCU:TuyaMCULE_HandleStateCb: g_HandleStateCbEpectedCount: 0
Info:TuyaMCU:Sent: 55 AA 00 05 00 01 00 05
Info:MQTT:Publishing val Ordinacija to Smoke_detector/ssid retain=0
Info:MAIN:Time 8, idle 172193/s, free 71656, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 2/38
Info:TuyaMCU:Received: 55 AA 00 10 00 01 00 10
Info:TuyaMCU:ProcessIncoming[v=0]: cmd GetDPCache (0x10) len 8
Info:TuyaMCU:HandleGetDpCache: dpId table:
Info:TuyaMCU:Sent: 55 AA 00 10 00 2E 01 07 6B 04 00 01 00 65 01 00 01 00 18 02 00 04 00 00 00 2A 17 02 00 04 00 00 01 10 10 01 00 01 01 0F 02 00 04 00 00 00 64 01 04 00 01 00 24
Info:TuyaMCU:Received: 55 AA 00 0A 00 00 09
Info:TuyaMCU:ProcessIncoming[v=0]: cmd WifiUpdate (0xa) len 7
Error:TuyaMCU:ProcessIncoming: unhandled type WifiUpdate (0xa)
Info:TuyaMCU:Received: 55 AA 00 05 00 05 10 01 00 01 01 1C
Info:TuyaMCU:ProcessIncoming[v=0]: cmd State (0x5) len 12
Info:TuyaMCU:HandleState: dpId 16, dpType bool (0x1) and 1 data bytes
Info:TuyaMCU:HandleState: dpValue: 01
Info:TuyaMCU:HandleState: g_HandleStateCbEpectedCount: 1
Info:GEN:No change in channel 3 (still set to 1) - ignoring
Info:TuyaMCU:TuyaMCULE_HandleStateCb: g_HandleStateCbEpectedCount: 0
Info:TuyaMCU:Sent: 55 AA 00 05 00 01 00 05
Info:MQTT:Publishing val 3 to Smoke_detector/sockets retain=0
Info:MAIN:Time 9, idle 173613/s, free 70984, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 3/38
Info:TuyaMCU:Received: 55 AA 00 10 00 01 00 10
Info:TuyaMCU:ProcessIncoming[v=0]: cmd GetDPCache (0x10) len 8
Info:TuyaMCU:HandleGetDpCache: dpId table:
Info:TuyaMCU:Sent: 55 AA 00 10 00 2E 01 07 6B 04 00 01 00 65 01 00 01 00 18 02 00 04 00 00 00 2A 17 02 00 04 00 00 01 10 10 01 00 01 01 0F 02 00 04 00 00 00 64 01 04 00 01 00 24
Info:TuyaMCU:Received: 55 AA 00 0A 00 00 09
Info:TuyaMCU:ProcessIncoming[v=0]: cmd WifiUpdate (0xa) len 7
Error:TuyaMCU:ProcessIncoming: unhandled type WifiUpdate (0xa)
Info:TuyaMCU:Received: 55 AA 00 05 00 05 10 01 00 01 01 1C
Info:TuyaMCU:ProcessIncoming[v=0]: cmd State (0x5) len 12
Info:TuyaMCU:HandleState: dpId 16, dpType bool (0x1) and 1 data bytes
Info:TuyaMCU:HandleState: dpValue: 01
Info:TuyaMCU:HandleState: g_HandleStateCbEpectedCount: 1
Info:GEN:No change in channel 3 (still set to 1) - ignoring
Info:TuyaMCU:TuyaMCULE_HandleStateCb: g_HandleStateCbEpectedCount: 0
Info:TuyaMCU:Sent: 55 AA 00 05 00 01 00 05
Info:MQTT:Publishing val -42 to Smoke_detector/rssi retain=0
Info:MAIN:Time 10, idle 173530/s, free 59960, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 3/38
Info:GEN:dhcp=0 ip=192.168.0.68 gate=192.168.0.1 mask=255.255.255.0 mac=c0:f8:53:65:53:2f
Info:GEN:sta: 1, softap: 0, b/g/n
Info:GEN:sta:rssi=-42,ssid=Ordinacija,bssid=70:3a:cb:7d:90:9b,channel=1,cipher_type:CCMP
PR seems to work rather well, dpCache handling is almost perfect and reporting is spot on - great job.
Breaking change is in the driver start and commands:
startDriver TuyaMCU -> startDriver TuyaMCULE tuyaMCULE_setBaurRate 115200 -> tuyaMCULE_setBaudRate 115200 linkTuyaMCUOutputToChannel 1 val 1 -> tuyaMCULE_SetDpConfig 1 val 1
On this particular device I got so far unseen (by me) MCU request for WiFi module firmware upgrade(?!?):
Info:TuyaMCU:Received: 55 AA 00 0A 00 00 09
Info:TuyaMCU:ProcessIncoming[v=0]: cmd WifiUpdate (0xa) len 7
Error:TuyaMCU:ProcessIncoming: unhandled type WifiUpdate (0xa)
as per tuya documentation here - https://developer.tuya.com/en/docs/iot/mcu-protocol?id=K9hrdpyujeotg
So handling of this also needs to be implemented as well.
Overall I am satisfied with the PR, more testing to follow on multiple devices before merge but overall great improvement. Let me know if response to 0x0a command has been implemented and we can proceed with more testing.
Slightly concerned about breaking changes but I think we can solve that in the webapp somehow.
And a question, how does this impact non-battery powered devices with TuyaMCU? I have several that I can test just asking before hand.
Thanks.
I want this merged, but all breaking changes must be fixed. Use the same commands as before, just change the backend.
Further testing is showing that changing a value on any dpID is not retained, the analyzer does show change but on first reboot value is returned to whatever the previous value was.
Something is odd more testing is needed.
Further testing is showing that changing a value on any dpID is not retained, the analyzer does show change but on first reboot value is returned to whatever the previous value was.
Something is odd more testing is needed.
That strange. Could you add more details?
I want this merged, but all breaking changes must be fixed. Use the same commands as before, just change the backend.
It shouldn't break much, due to the tmSensor hacks.
I want this merged, but all breaking changes must be fixed. Use the same commands as before, just change the backend.
It shouldn't break much, due to the tmSensor hacks. . Any particular reason to change the command names? That alone will break all autoexec files.
Further testing is showing that changing a value on any dpID is not retained, the analyzer does show change but on first reboot value is returned to whatever the previous value was. Something is odd more testing is needed.
That strange. Could you add more details?
Well some strange things I got is that one CB3S module froze on me, after reboot. The other is that adjustable values like report time will not persist on reboot for some reason. I need to test a lot more before we can merge this.
Will report more and in detail once I get some free time, probably on the weekend.