logo elektroda
logo elektroda
X
logo elektroda

Tuya JSON specification - how to get smart device IO template automatically?

p.kaczmarek2 
Sample Tuya configuration JSON with various parameters.
Automatic Tuya JSON extraction allows you to automatically configure the GPIO template of your smart device. Unlike in Tasmota, where all GPIO probing has to be done manually, OpenBeken flasher BK7231GUIFlashTool is able to extract the Tuya GPIO roles, so it can automatically tell which pin is used for relay, which pins are used for PWMs, which baud is used for TuyaMCU, etc.
The usage of this feature has been presented already in our video:



Today I am going to show you few more details about the Tuya JSON inner working.
Let's start by considering a sample JSON:
Code: JSON
Log in, to see the code

This is a description of a simple 6014HA device, featuring a single relay, WiFi LED and a button.
The most important keys here start with "rl1_", "netled_", and "bt1_".
The "rlX_" prefix stands for relay. There can be multiple relays, so X stands for the relay number.
There are multiple keys for relays:
Code: C / C++
Log in, to see the code

The "lv" key stands for active level. Value 1 means that relay is active-high, so relay is closed when the given GPIO has high level.
This is a standard for all Tuya products so we are not even parsing that.
The more important key is rl1_pin, which is a GPIO index of Relay pin. 14 there means that relay is on P14 (not on the 14th pin of QFN case).
The same logic applies to buttons. There can be also multiple buttons, for example, bt1_pin is a GPIO of a first button, and bt2_pin is a GPIO of second button. Futhermore, there can be also LEDs following relay states, so led1_pin, led2_pin, etc is possible.
Of course, most of IO roles are not numbered, for example, status_led_pin. Here is more detailed list of Tuya JSON keys:
- status_led_pin - this is a WiFi pairing LED
- bz_pin_pin - buzzer pin
- samp_sw_pin - battery ADC sampling enable pin
- samp_pin - battery ADC sampling pin used to measure battery voltage
- i2c_scl_pin and i2c_sda_pin - I2C bus pins
- alt_pin_pin - ALERT pin (interrupt from temperature/humidity sensor)
- one_wire_pin - OneWire bus for DS18B20, etc
- backlit_io_pin - backlight pin
- max_V and min_V - battery voltages for battery measurement
- rl_on1_pin and rl_off1_pin - this is used for bridge (bistable) relay
- k1pin_pin (etc) - alias for button pin
- door1_magt_pin - door sensor pin for non-TuyaMCU device
- onoff1, onoff2, etc - this is used to connect old-style bistable switch on relay modules
- basic_pin_pin - this is a PIR sensor for motion detectors
- netled_pin - WiFi LED (again), also may be used as netled1_pin
- ele_pin - BL0937 energy metering pin ELE
- vi_pin - BL0937 energy metering pin VI (Voltage/Current)
- sel_pin_pin- BL0937 energy metering sel pin
- sel_pin_lv - BL0937 sel pin level (usually 1, active-high)
- r_pin, g_pin, b_pin, c_pin, w_pin - R G B C W PWMs for lamps and LEDs
- micpin, also sometimes mic - microphone input for music-based effects
- ctrl_pin - it seems it may be a LED strip controller button
- mosi - SPI MOSI, always 16 on Beken, used for example to drive WS2812B
- buzzer_io - again, buzzer pin
- buzzer_PWM - buzzer PWM frequency
- irpin or infrr - IR input (receiver)
- infre - IR output (sending)
- reset_pin - reset/pair button
- wfst_pin - WiFi state LED, again, pairing LED
- pwmhz - PWM frequency (for LED?)
- pirsense_pin - PIR sensitivity adjustment (probably via PWM)
- pirlduty - PIR adjust duty (min)
- pirfreq - PIR adjust frequency
- pirmduty - PIR adjust duty (max)
- pirin_pin - PIR input (read this value to detect PIR state, 1 or 0)
- total_bt_pin - again, reset/pair button
There are also some twowire (I2C-like) LED controllers, like SM2253, BP5758. They are using keys:
- iicscl - I2C (not really I2C, because adressation is missing) Clock
- iicsda - I2C (as above) Data
I haven't investigated it fully, but it seems that LED drivers have separate RGB and CW (or separately, C and W) current limits.
- ehccur, wampere, iicccur - SM2135 current levels (color mode?)
- dccur - BP5758D current level (color mode?)
- dwcur - BP5758D current level (cool/warm mode?)
- cjwcur - BP1658CJ current level (cool/warm mode?)
- cjccur - BP1658CJ current level (color mode?)
- _2235ccur - SM2235 current level (color mode?)
- _2335ccur - SM2335 current level (color mode?)
- kp58wcur - KP18058 current level (cool/warm mode?)
- kp58ccur - KP18058 current level (color mode?)
- iicr, iicg, iicb, iicc, iicw - color indexes for I2C-like RGBCW drivers (they are not standarized)
Futhermore, there is BL0942 and TuyaMCU related keyword:
- baud - TuyaMCU/BL0942 communication baud rate
And there is a generic information keyword:
- module - name of the WiFi module, like CBU, CB3S, etc

The list above is not comprehensive and more information will be added there over time.

To extract Tuya Config JSON from a live device or from 2MB flash backup, use our flasher:
https://github.com/openshwprojects/BK7231GUIFlashTool
To decode Tuya JSON, you can use our online utility:
https://openbekeniot.github.io/webapp/templateImporter.html
For some sample Tuya flash dumps, check out flash dumps library:
https://github.com/openshwprojects/FlashDumps

As you can see, Tuya JSON decoding can make "cloudless" conversion of your Tuya device much faster and easy than it was in case of ESP8266/Tasmota devices. Most of the related GPIO roles are included in JSON, so you don't have to guess anymore. Futhermore, OpenBeken can automatically convert Tuya JSON to a template, so all you have to do is just to copy and paste the extracted text.

About Author
p.kaczmarek2
p.kaczmarek2 wrote 11960 posts with rating 9995 , helped 572 times. Been with us since 2014 year.

Comments

divadiow 15 Jul 2024 19:54

very interesting. I fed ChatGPT all the cloudcutter json files and it came back with this deduped list. alarm_pin alt_pin_pin b_pin backlit_io_pin basic_pin_pin bt1_pin bt2_pin bt3_pin ... [Read more]

p.kaczmarek2 16 Jul 2024 08:33

They don't have all pins, for example, "micpin" seems to be missing. [Read more]

divadiow 16 Jul 2024 08:47

true. those are included in the jsons but my GPT request wasn't good enough. anyway, it's a snapshot of the variety used, as you say in the first post. [Read more]

p.kaczmarek2 16 Jul 2024 08:48

Btw those key names doesn't seem standarized, as I have seen both "micpin" and "mic" [Read more]

divadiow 16 Jul 2024 08:56

it'd be a bit of task to have Easy Flasher cater for them all I guess [Read more]

divadiow 20 Feb 2025 09:32

netled_reuse also indicates if an LED is shared - I guess for wifi then for on/off purposes once wifi established. This could be used to assign a new dual-purpose pin assignment that changes the LED behaviour... [Read more]

p.kaczmarek2 20 Feb 2025 09:42

So you'd like to have a separate LED pin role? I don't know, LED_State? StateLED? [Read more]

divadiow 20 Feb 2025 09:58

An idea perhaps. I think I saw this floated before somewhere. Even if netled_reuse is wrong (I don't think it is), a single assignment to change the behaviour of LED depending on wifi connection would... [Read more]

insmod 20 Feb 2025 10:18

My idea is to make keep WifiLED, but allow assigning channel to it. So, as soon as wifi is connected, it would act like a led for assigned channel. But, if channel is 0, then keep original behavior. [Read more]

p.kaczmarek2 20 Feb 2025 10:55

Good idea but not perfect - channel 0 is often used for relays, so it's a normal channel, not a special value. We can't do -1 as well, because channel indexes are stored as unsigned byte.... Maybe we... [Read more]

%}