TuyaMCU flashing, setup and configuration guide - configure dpIDs for Home Assistant

>>21791984

I like powerSave, now. Regardless of what it does its purpose is to save power and the battery devices will work without it being on. But I'll do what you think is best.

EDIT:
Can you test it on a non-battery device? What does it do?

EDIT AGAIN:
Maybe you are right. I can see the confusion that will come from the perspective of non-battery powered devices using the command.

PowerSave 1, in OBK, is used to reduce energy usage of OBK. So, by extension, users would think that once you enable TuyaMCU powersave, then you will get smaller energy usage. That's not accurate. They would be trying to enable it on any TuyaMCU device.

>>21791998

I've made the suggested changes the command is now tuyaMcu_batteryPoweredMode and it is ready to be released.

Well, I guess it's acceptable. Thank you!

Now, do we have a teardown for the device that requires it on our forum?

>>21792111

I talk about the device here.

protectivedad wrote:

I purchased some ZY-D02 door sensors from AliExpress.

I can rename the post and add some details with the new command once it is released. I will look at creating a template. One problem is that the "ZY-D02" devices have many different versions all the same name and they don't seem to be consistent. I've seen them mentioned a couple of times.

daherbst85 wrote:

I’m using the ZY-D02, which seems nearly identical to the D06 (mine uses a 2063P hall sensor and lacks the CB3S metal shield).

They removed the TuyaMCU and directly wired the sensors to the WiFi module.

meillagimeil wrote:

I have this device ZY-D02-CB3S-V1.3, BK7231N, firmware 1.18.190.... and it's driving me nuts...

They never got it working.

IF you have this device solved, please consider making a separate guide topic for it, so we can add it to our devices list here:
https://openbekeniot.github.io/webapp/devicesList.html

Is there a way for the tuyaMCU driver to be automatically loaded? One of the issues I noticed trying to program these TuyaMCU battery operated devices is that if the WiFi module doesn't talk to the TuyaMCU in the first few seconds the TuyaMCU will turn it off an on repeatedly. On initial programming this leads to the device AP showings up but never being able to connect to it because it is never available long enough to get the web page. I know there are solutions when flashing the device to change the OBK settings to include a startup command "backlog startDriver tuyaMCU;". I just think assigning the tuyaMCU driver to the RX/TX pins and using that to automatically load the driver is a more elegant solution. Which has the added benefit of documenting in the module screen that the device is a tuyaMCU.

Has this been discussed or thought about before? I was looking for a solution which will make the battery operated devices easier to setup and test.

You are the first one to bring this topic. What would be the use case of that? In order to use TuyaMCU, you have to create autoexec.bat anyway, otherwise you can't map channels, so there is no reason to start TuyaMCU anywhere else, hm?

>>21792372

I get it. You need other stuff for it to function properly, but without the driver loading you can't get access to the battery device without taking it apart. So if you forget to create a backlog entry in the OBK on flash, or the autoexec.bat that loads the driver gets wiped, say on updating the firmware, you are taking the device apart. I also get that forgetting to assign the TuyaMCU to a dummy pin has the same problem, but I find remembering to make sure the pins are correct is more intuitive then looking at the Startup Command or the autoexec.bat. Especially when I am trying to access a device that is continually turning on and off.

It was a bit of a learning curve which I think other new users can be saved if the driver is loaded automatically. How that would have been accomplished in other platforms is to assign the driver to a "dummy" pin. I mention the RX/TX (or just one) because we know they will never be used for anything else. I'm not actually saying use them in the driver. Just trigger driver loading.

Having gone through the frustration of testing and pulling hair to figure out why all of a sudden my device is not accessible I use the "Startup Command" and NOT an autoexec.bat.

So short answer, I think there is one main benefit:
1) More resilient to firmware updates;
- If you are using an autoexec.bat and it gets erase during a firmware update you will still be able to access the device through the AP.

You already have drivers load based on assignment to a pin, so I figured adding the functionality would be simple. Add TuyaMCU to the pull down list and if it is assigned load the driver.

Just a thought.

protectivedad wrote:

I get it. You need other stuff for it to function properly, but without the driver loading you can't get access to the battery device without taking it apart.

That's surely a new information. As far as I tested, I can keep up battery device AP or STA alive longer by pressing pair button many times, but I checked it in BK7231T/BK7231N era, when there was no sign of BK7238. Did something change, can you elaborate?

p.kaczmarek2 wrote:

That's surely a new information. As far as I tested, I can keep up battery device AP or STA alive longer by pressing pair button many times, but I checked it in BK7231T/BK7231N era, when there was no sign of BK7238. Did something change, can you elaborate?

That's interesting. I don't think it has anything to do with the WiFi module, but the TuyaMCU implementation. I have only one type of TuyaMCU device. With my devices if the TuyaMCU has not communicated with the WiFi module (no heartbeat/product id) it will turn off and back on the WiFi module. Pressing the button (I tried it many times) will keep the TuyaMCU on, but the TuyaMCU will still turn the WiFi module on and off. Annoyingly, it leaves it on long enough that the AP looks solid, but the phone/computer will say can't connect. Only after I hooked up a voltmeter to the WiFi module power pins did I find out the TuyaMCU was cycling the power.

When the driver runs it will send a heartbeat or ask for product information and at that point the TuyaMCU will start flashing the device LED and pressing the button will keep it alive. With my device holding it for 5+ seconds cause the TuyaMCU to keep the WiFi module powered for a while, but ONLY if the WiFi module has already sent a heartbeat/product ID request.

I assumed they were all like that, but obviously not. I wonder if that is leading to some frustration on people trying to test the battery operated devices.

So to test stop the driver from loading and see if the device LED flashes on a boot. Mine won't. Allow the driver to start and it will.

Then why not use short startup command? In both cases it will be in two places...

Adding THIRD place that can start TuyaMCU will only confuse people even more.

p.kaczmarek2 wrote:

Then why not use short startup command? In both cases it will be in two places...

1) More elegant.
2) Reduces the learning curve for new users used to Tasmota, like me.
3) TuyaMCU detection and pin assignment can be added to GUI flasher again it is consistent with what the flasher already does.
4) More efficient, reading a pin takes less resources than parsing a command.
5) Documentation, you are documenting in the modules screen the pin is being used by the driver and you get double duty by using that to load the driver.

p.kaczmarek2 wrote:

Adding THIRD place that can start TuyaMCU will only confuse people even more.

It's just a preference people used to looking in the modules page will put it there. People used to the startup will put it there. The idea is to automate the transition from the factory firmware to the use of OBK with as little chance to cause problems.

The GUI flasher reads a device and assigns pins for most devices. The pin assignments cause drivers to automatically load. Why not try to make the TuyaMCU process as close to that as possible.

Anyway, I think it will save people trouble let me know if you'd like me to close the https://github.com/openshwprojects/OpenBK7231T_App/pull/1919

Maybe... I didn't made final decision yet. One of the things I've been thinking about is adding live tuyamcu dpIDs preview to obk main http page.

p.kaczmarek2 wrote:

One of the things I've been thinking about is adding live tuyamcu dpIDs preview to obk main http page.

My use of the devices is to post to a MQTT broker. Anything that slows that down is counter to how I use the devices. I have been optimizing for my device and doing extensive timing testing. By making code optional through obk_config defines and some rearranging I have the TuyaMCU driver loading in 230 ms (initial product information is received in 340 ms), the startup command runs in 400 ms, connect to WiFi i 660 ms, connect to the MQTT broker in 1.4 s and post the pin change in 1.5 s. I think it can be made even faster if I could find an interface callback to run the initial MQTT connect.

That's interesting, what were the original timings? It could make a good separate tutorial - optimizing obk?

p.kaczmarek2 wrote:

That's interesting, what were the original timings?

All tests are done with static IP assignment and IP address for MQTT broker.

Without any flags:
Start Command runs and loads driver 560 ms, first message from TuyaMCU 1.7 s, connect to WiFi in 9.2 s, MQTT connect 9.6 s pin published 10.77 s

With Flag 37:
Start Command runs and load driver 636 ms, first message from TuyaMCU 1.8 s, connect to WiFi in 1.8 s, MQTT connect 2.7 s pin published 3.8 s

With Flag 37 and 51:
Start Command runs and load driver 632 ms, connect to WiFi in 1.1 s, MQTT connect 1.7 s, first message from TuyaMCU 1.8 s pin published 2.8 s

I still think ~3s is too long. That's enough time for someone to remove the batteries and the MQTT broker would have no idea what went on.

For those interested I've post:
https://github.com/openshwprojects/OpenBK7231T_App/pull/1939

I also added tuyaMcu_sendProductInformation to the startup command which gets the TuyaMCU ready for sending information ahead of time.

Times are:
Start Command runs and load driver 632 ms, first message from TuyaMCU 740 ms, connect to WiFi in 1.1 s, MQTT connect 1.7 s, pin published 1.8 s

The PR allows the MQTT broker to connect and then continue and process MQTT message in the same loop. Saving 1 s in the boot sequence.

I saw also you did Allow MQTT connection and processing in one every second iteration change. If it works, then it's a great addition! Hopefully it's stable. I'd love to merge it.

p.kaczmarek2 wrote:

Maybe... I didn't made final decision yet. One of the things I've been thinking about is adding live tuyamcu dpIDs preview to obk main http page.

I just realized how great this might be. I'm like the regular mail I may be slow, but I get there eventually.

I had enough autoexec.bat creation and tuning in the 1980's with DOS. I really don't need to go back to that. You mentioned a good point about the driver if you have to link the dpID to channel in the startup command what's the problem with adding a startdriver? But of course I was stuck in the idea that dpID to channel to MQTT was the way it had to go. It doesn't of course. Channels can be dynamically created from dpID for posting to MQTT. Just like the battery driver posting directly to the website and publishing to MQTT voltage/get and battery/get, the TuyaMCU could do the same with dpID/get. Those who want can name there dpIDs to a channel number or name or whatever. But for those who don't want to create bat files, etc, they don't have to.

Ideas?