A Tuya thermo-hygrometer without cloud, with OpenBeken

This page was translated automatically from Italian. Read the original

WiFi thermo-hygrometers costing only a few euros have a readable screen, a good probe, and one flaw: to function, they pass through the manufacturer’s cloud and an app. If the internet goes down, or if the service closes one day, the measurement stays on the display and no longer reaches anyone. Many of these sensors contain a Beken chip, and on that chip runs OpenBeken, a free firmware that speaks MQTT directly with the home network. This guide explains how we did it on an Emylo H&T S09 to use it as a room probe in ORFHAn, but the procedure applies to other similar models.

Before buying: what chip is inside

“Tuya” is a platform, not a chip. Inside the sensors, there are different WiFi modules: older ones with ESP8266, many recent ones with a Beken (BK7231T, BK7231N, BK7238), and others with chips from different manufacturers. OpenBeken supports Beken and some others; the updated list is in its documentation. The safest way to find out is to search for the model along with “OpenBeken” or look at photos of the interior: the model name is printed on the module.

The S09 has a BK7238. And like almost all Tuya thermo-hygrometers, it does not read the probe with the WiFi chip: there is a second microcontroller, the TuyaMCU, which reads the probe, controls the display, and passes the values to the WiFi module via serial, in the form of numbered datapoints (DP). On the S09, DP 101 is the temperature in tenths of a degree and 102 is the humidity in percent. This is an important detail: after OpenBeken, the WiFi module must know which DPs to listen to.

What you need

1. Writing OpenBeken

Open the sensor and locate the WiFi module, with the TX, RX, and CEN pads. This is how it worked for us:

  1. the sensor remains powered by its USB plug;
  2. only TX and RX from the adapter are connected, crossed with those of the Beken module: the module’s TX to the adapter’s RX and vice versa;
  3. when the flashing software requests a chip reset, briefly touch the module’s CEN pin (on the S09 it is pin 3) to the adapter’s ground.

If the sensor and the adapter are not connected to the same computer, it is advisable to connect the two grounds together as well. And if the software allows it, first make a copy of the original firmware: it is the only way to go back.

Once the firmware is written, the sensor restarts with OpenBeken and opens its own WiFi network for the first configuration. Connect with your phone, provide the name and password of your home network, and from then on, its page will open at the address assigned to it by the router.

2. The startup script: telling OpenBeken where the measurements are

As soon as it is flashed, OpenBeken does not know what the object it is running on is. You tell it via the startup script, in its page: Config, then Startup command. For the S09, it is only a few lines:

startDriver TuyaMCU
startDriver NTP

// temperature: DP 101, in tenths of a degree, in channel 1
setChannelType 1 temperature_div10
linkTuyaMCUOutputToChannel 101 val 1

// humidity: DP 102, in channel 2
setChannelType 2 Humidity
linkTuyaMCUOutputToChannel 102 val 2

The first line initiates the dialogue with the TuyaMCU. The others connect each DP to an OpenBeken channel and specify what it contains and in which unit: temperature_div10 means “temperature, to be divided by ten”. After the reboot, the sensor page shows temperature and humidity.

With another model the DP numbers may be different. A practical way to find them: turn on only the TuyaMCU driver, check the sensor log, and warm the probe with your fingers. The DP that changes is the temperature; from the value, you can tell if it is in tenths or hundredths, and choose temperature, temperature_div10 or temperature_div100.

3. MQTT measurements

In the Config → MQTT page, you enter the home broker address, the username, and the password. From that moment on, OpenBeken publishes its channels to the broker, and according to its documentation, it can also announce them to Home Assistant via automatic discovery. We have not tested this part manually: we let the ORFHAn board handle it.

In ORFHAn, the sensor is assigned to a room from the Devices page of the relay board, just like a Shelly or an ESPHome node. The board reads the sensor’s startup script to understand which channel contains the temperature and humidity, writes the broker to it and reads it back to verify, adds a piece of script delimited by two comment lines to its autoexec.bat file, and restarts it. That piece of script publishes the temperature to sensors/<stanza>/temperature and the humidity to sensors/<stanza>/humidity: on every change and anyway once a minute, so the board knows the sensor is alive even when the temperature is steady. In short:

alias orfhan_t publishFloat sensors/soggiorno/temperature $CH1*0.1 1 1
addEventHandler OnChannelChange 1 orfhan_t
addRepeatingEvent 60 -1 orfhan_t

The actual script also waits for the first real value before publishing: at startup, the channels are zero, and zero degrees in a living room is not a measurement but a sensor that hasn’t read the probe yet. This is a useful trick for anyone writing their own scripts: a fake value at startup is enough to trigger a wrong automation.

What you gain, and what you don’t

What is proven

The script for the S09 and the complete procedure are in the ORFHAn repository.