-
Notifications
You must be signed in to change notification settings - Fork 387
Separate implementation for TuyaMCU and TuyaMCULE #1795
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
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:
#1795 (comment)
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. 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. |
@openshwprojects check the last commit |
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. |
I think it should for the most part. Except the old driver didn't care if you defined the wrong type for dp. |
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. I got a WIOONI T13. It sends a non-standard state request. Implemented that too. |
I have a P01, TH01Y, T08 works fine. |
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. |
Yeah. I know a few. I rather keep stuff outdated then break things that works perfectly as-is. |
Changed it to warning. |
I can test this PR more extensively this weekend and post some findings. |
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 On this particular device I got so far unseen (by me) MCU request for WiFi module firmware upgrade(?!?):
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. |
That strange. Could you add more details? |
It shouldn't break much, due to the tmSensor hacks. |
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. |
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.