Every day, I’m discovering the joys of DIY modules—mostly Wi-Fi ones for now—with all the limitations that entails in terms of range. So I’d like to switch to Zigbee, but I’ve run into several issues with my own DIY projects. That’s why I looked for a simpler, more stable solution, and I found ESPHome. I’m now wondering how to use it to connect an ESP32-H2 “mini” board and an AJ-SR04M distance sensor. Has anyone already tested this combination? If not, could you recommend some good tutorials for installing and using ESPHome?
Blockquote As far as I understand, there are basically two ways to use this ultrasonic module: Either the software triggers a transmission pulse and measures the time to reception itself, or the software receives the distance value as a 16-bit number via a serial port.
The modes differ from those of other modules, so it can quickly become confusing.
Here’s how it works with the AJ-SR04M:
Mode 1 (R19 open) = A trigger (0-1-0) of at least 10 µs on “RX/Trig” starts transmission, and when the signal on “TX/Echo” goes high, the echo has been received. The transit time is then the distance (formula)
Mode 2 (R19 set to 300k) = Essentially the same as “Mode 1,” but the trigger pulse must be longer (at least 1 ms) to wake the chip from deep sleep (Low Power Mode).
Mode 3 (R19 set to 120k) = There is no trigger here; instead, the module continuously transmits signals on its own (every 120 ms). The echo returns as a 16-bit serial value (=distance in mm?) on the “TX/Echo” pin, at 9600 baud 8N1.
Mode 4 (R19 connected to 47k) = Same as “Mode 3,” except the module only transmits when a serial data word 0x01 is written to the “RX/Trig” pin, also at 9600 baud 8N1.
Mode 5 (R19 shorted) = Same as “Mode 4”; I didn’t really understand the difference, except that it requires more power.
Of course, the selected mode must match the selected method in ESPHome. Somehow, both—i.e., time-of-flight measurement and serial distance—are probably supported; the question is just how?
Currently, I’ve soldered a 120k resistor to R19 to enable continuous scan mode (Mode 3). The blue LED on the shield is flashing away merrily, and I can hear the sensor “clicking.” I don’t think this makes much sense for production use because it’s constantly transmitting. I’d rather trigger it via HA, using a different signal (light switch, PIR sensor, or whatever).
In the log of my ESP32-C6-Zero, I also see a byte being output—most likely one of the distance bytes—but it’s rejected with the error “checksum failed”:
In other posts, I’ve determined that the sensor always sends 4 bytes in UART mode: a header byte (0xFF), 2 data bytes (distance value), and a checksum byte. The calculation of this checksum apparently varies, which is causing the problem. The selected “model: aj_sr04m” is said to be the cause.
And indeed, when I comment out the “model,” I get values back in the HA, albeit implausible ones.
If I then also omit the “filters” node, the values seem to be correct. The shortest distance is 0.254 m (the datasheet says 20 cm, but never mind), and if the value is 6.016 m, it’s “out of range” (the datasheet lists 8 m here, so everything printed there is just nonsense).
According to the “jsn_sr04t” platform documentation, this platform supports “Mode 1” and “Mode 2” of the JSN-SR04T—that is, only the modes with a serial interface, not those with runtime measurement; the “ultrasonic” platform would be more suitable for that.
It’s just that JSN Mode 1 (47k) means “Continuously measure with serial output,” so it corresponds more closely to AJ Mode 3 (120k).
JSN Mode 2 (120k) corresponds to AJ Mode 4 (47k), except that the JSN expects a 0x55 trigger command while the AJ expects a 0x01. So it’s reasonable to assume that if you set the “model” to “aj_sr04m” on the “jsn_sr04t” platform and select Mode 4 on the AJ, it will then send 0x01 and work.
So what works is “AJ Mode 3” (R19 = 120 kOhm) with the following configuration:
uart:
id: uart_1
tx_pin: GPIO4 # connected to the “RX/Trig” pin on the shield
rx_pin: GPIO5 # connected to the “TX/Echo” pin on the shield
baud_rate: 9600
sensor:
- platform: “jsn_sr04t”
name: “Distance”
uart_id: uart_1
device_class: distance
The “update_interval” setting is not supported in this mode (according to the platform documentation). So I’m not entirely sure where the 1-second interval comes from—probably some default values?
When I set R19 to 47k and thus switch to “Mode 4,” I see the blue LED flash in sync with the “update_interval”—and this happens without any changes to the ESPHome configuration.
# Configuration for AJ-SR04M set to “Mode 4” (R19=47 kOhm)
- platform: “jsn_sr04t”
name: “Distance”
uart_id: uart_1
device_class: distance
update_interval: 10s
Strange: If I enter “model: aj_sr04m” as it should actually be, it no longer works and I get the CRC errors again.
If you go below the minimum distance, you’ll see the following warning in the log:
[W][jsn_sr04t.sensor:051]: Invalid data read from sensor: FF.00.C8.C7
The 0xFF is the header byte and the distance is 0xC8, which corresponds to 200 in decimal, i.e., 200 mm. But it simply indicates that the distance has fallen below the minimum limit. I’ve experienced this with my car, too—when I try to get reeeally close, it starts beeping continuously long before I actually reach the limit. At this distance, the echoes likely overlap, or the transit time is so short that a measurement would require highly precise components.
It’s also important to note that the distance measurement depends heavily on the angle to the target object, as well as its surface area. The transmitter has an “aperture angle” of 75°.