Tuya Combustible Gas Alarm DY-RQ400A WB2S Setup, Features, and Data Points - WIP

Here I will document my journey, however long that might be, with a Tuya Combustible Gas Alarm model DY-RQ400A which employs a WB2S (BK7231T) module in tandem with a Runjet RJM8L151F6P6 MCU, (Chinese and machine-translated English datasheet attached).







And inside the Tuya app when paired



A quick Google for the model of this device shows that other teardowns, with nice pictures, are available elsewhere, so I feel the need to investigate everything as if it was a total unknown is somewhat reduced. The datapoint IDs are as follows:





One of the first things I did was connect up to 2TX to check the boot output:



Unexpectedly, the MCU does not get in the way of firmware dump for me on this device, and so I attach the backup file.

A quick gander at the MCU comms in one direction with TuyaMCU Explorer during boot, pairing and then a self-test - which I've highlighted in this pic - dpID9



Before I flash OpenBeken I'd like to do some more TuyaMCU analysis and probably film the device LED behaviour through pairing mode, dormancy and alarm sounding. For now I will park this because I need to fit a new kitchen tap and service the car! 😁

Thank you for your presentation. I am really starting to think that we need a way to support custom enumerations more easily.

So with Tuya firmware, when first plugged in it'll do a little test siren and flash its single tri-colour 5050 SMD LED red, green then blue. When it's in pairing mode it semi-fast flash green.



once paired it'll be a static green if no elevated gas levels are detected



then you can press the button at paired or unpaired state to start a self-test. this can also be done from the app.



Sensor pre-heating indicator LED cycle



Lighter fluid bursts from a lighter didn't seem to set it off but isobutane mix Capingaz certainly did. A single button press clears the alarm state



Added after 1 [hours] 46 [minutes]:

I believe the combustible gas sensor to be a Winsen MP-4

regarding my earlier detection for isobutane, ChatGPT notes the following after analysing the Winsen datasheet



Added after 8 [hours] 57 [minutes]:

I've soldered the device back up to two USB-TTL adaptors to look at the MCU behaviour.

Here is power-up, pre-heating and finally short bursts of lighter fluid into the sensor.



It's fascinating to see dpID5 (Range: 0 to 1000 (LEL - Lower Explosive Limit)) levels change as the gas is suddenly present and then the values drop as it dissipates:



Added after 26 [minutes]:

boot with notes:



lighter fluid emission with notes:

Nice progress. By the way, this dpID:

it's marked as RW (Read/Write) instead of RO (Read Only), does it mean that you can just enable the alarm at any moment from the OBK? So the alarm could be reused as alarm for, I don't know, other sensor?

p.kaczmarek2 wrote:

it's marked as RW (Read/Write) instead of RO (Read Only), does it mean that you can just enable the alarm at any moment from the OBK? So the alarm could be reused as alarm for, I don't know, other sensor?

not sure yet, just started to play.

I've done the basic ro enums and other bits





dpID 12 button doesn't do anything. dpID 9 button makes the LED do a little colour sequence only

Added after 8 [hours] 44 [minutes]:

I thnk I'm going to reflash back to factory to capture more MCU data from actions taken in the Tuya app.

It's shame I can't get a flash of the factory fw into a pairing state on a dev WB3S so I can work on OBK/factory in parallel. I'm guessing the WB3S is waiting for something from the MCU, which isn't there.

Do I remember correctly seeing some post once about faking a series of MCU responses so a factory fw would complete boot? I might be misremembering.

divadiow wrote:

Do I remember correctly seeing some post once about faking a series of MCU responses so a factory fw would complete boot? I might be misremembering.

I've actually made something opposite - faking a series of WiFi module responses:

It seems that you need an opposite thing. Or maybe you can just do that with Realterm?

oh. I don't recall seeing that tool before. I'll have a go at Realterm or just flash between OBK/factory

Added after 48 [seconds]:

p.kaczmarek2 wrote:

I've actually made something opposite - faking a series of WiFi module responses:

yes. probably what I remember

Added after 2 [hours] 10 [minutes]:

on a different note, and to hit the 600 device milestone (oh, too late), this device could be added. The template won't change but the autoexec is obviously a work in progress.

https://github.com/OpenBekenIOT/webapp/pull/129

Added after 11 [hours] 16 [minutes]:

so yes, you can initiate a self-test (auto-detect toggle) but it'll only sound for a fixed short period.



so far:



Added after 4 [minutes]:

and when you toggle dpID9 self-test, the button goes green while in test mode, the checking status value changes to 0 and the alarm state changes to 0. When complete dpID 9 button goes red again



Added after 57 [minutes]:

most readings and functions are in place. the alarm duration (1-180s) selection is not yet sorted. I don't imagine 180 buttons with individual hex sends it the best way to make that available!

So far



with

Maybe TextField button can be used for alarm duration (1-180s)?
I've used it in the past for the timer:
https://github.com/openshwprojects/OpenBK7231T_App/blob/main/docs/autoexecExamples.md
This is how TextField looks like:

p.kaczmarek2 wrote:

it's marked as RW (Read/Write) instead of RO (Read Only), does it mean that you can just enable the alarm at any moment from the OBK? So the alarm could be reused as alarm for, I don't know, other sensor?

ah. specifically, dpID 12 just turns the function of the whole device on/off, not the alarm tone itself. there doesn't appear to be an alarm tone only ability - the closest being the self-test

Added after 10 [hours] 24 [minutes]:

p.kaczmarek2 wrote:

Maybe TextField button can be used for alarm duration (1-180s)?

OK



and I can see from tuyaMcu_sendQueryState that the values I choose in the textfield are set in the MCU

12 seconds:



73 seconds:



I've had to do away with this for now though in autoexec because it means trying to map the same dpID to different OBK channels. I'm looking around to see if there's a way to do write and separately read, so the currently-set value is displayable.



Added after 1 [minutes]:



Added after 32 [seconds]:

also if "channel" can be hidden

Added after 2 [hours] 7 [minutes]:



oh

p.kaczmarek2 wrote:

Thank you for your presentation. I am really starting to think that we need a way to support custom enumerations more easily.

Yes. Not quite sure what that would look like. Something so you could use a command like "linkCustomEnum [tgChannel] [enumVal] [displayVal]".

So, for example, the dpID1 value shown on this gas alarm could just be "Checking" "Success", "Fail" etc instead of 0, 1, 2..

divadiow wrote:

I've had to do away with this for now though in autoexec because it means trying to map the same dpID to different OBK channels. I'm looking around to see if there's a way to do write and separately read, so the currently-set value is displayable.

is it possible to separately show the current state of each channel and to be able to set it elsewhere?

p.kaczmarek2 wrote:

It seems that you need an opposite thing. Or maybe you can just do that with Realterm?

I don't think I ever did try Realterm

BUT it looks like there's an official Tuya tool to emulate an MCU. I attach the TuyaMCU module debugging assistant version 2.2.3.5. This is download for v2.1.3 that updates to 2.2.3.5: https://images.tuyacn.com/smart/solution/deve...urce/aa68e8df-de83-5e2e-b8c1-d189b46168e9.zip

I've not had a chance to try it out, but I've seen it used to respond to a flashed Beken dev board with missing TuyaMCU. This then meant getting the firmware fully booted and into AP/pairing mode.

So now we can flash OBK to converted NodeMCU with BK7231 and let PC simulate TuyaMCU?

It's by default in Chinese, but here you can change language:

yes. Attached is an example function point json to use.



it decodes stuff like TuyaMCU Analyser, to a degree.

I was playing with the Atorch S1 firmware with a view to eventually capturing the 1.0.7 TuyaMCU firmware upgrade that gets offered by the Tuya app once paired. I could not get the firmware to pair though. I guess there's a lot to understand about all the communications that need to occur to make such a thing happen.

Nice and neat - all possible with just this and the PC: