That’s one part of the problem I think. I got a second ESP32C to see if there is any difference. There is not both XIAO boards have the same problem. I also got a second mmwave sensor. I will hook it up tomorrow to see if it makes any difference.
Hmm, wondering if it’s a bad Xiao. I’d delete the project from esphome and start over. That way you’ll start with a clean flash of stock over USB. Then try again.
Well I have hooked up the second mmwave sensor and that one worked fine. Also now with the connection to GPIO6 and GPIO5 the sensor start sending data as soon as the esp board get powerd.
My first mmwave sensor seems to be broken. Also the first XIAO board (both purchased directly form SeeedStudio). There seems to be a shortage on the first XIAO board between the 3.3V and ground.
I changed one thing in the yaml code (not sure if it makes any difference) and that is the board.
I am having the same problem. I got 4 of the mmwave units on Friday. Got one connected to the esp32c3 and it started working immediately. As of yesterday, about 3 days later, the mmwave stopped working. I connected another mmwave to the same esp32c3 and it is working right now. Perhaps I have a bad mmwave?
I’m using the latest yml files with the new connectors. My problem is that I have to reinstall everytime HA or the device restarts. It will not send data after a restart.
This is the screen I see when I look at the logs:
INFO Reading configuration /config/esphome/mmwave.yaml…
INFO Generating C++ source…
INFO Compiling app…
Processing mmwave (board: esp32-c3-devkitm-1; framework: espidf; platform: platformio/espressif32@5.3.0)
HARDWARE: ESP32C3 160MHz, 320KB RAM, 4MB Flash
framework-espidf @ 3.40404.0 (4.4.4)
tool-cmake @ 3.16.4
tool-ninja @ 1.7.1
toolchain-esp32ulp @ 2.35.0-20220830
toolchain-riscv32-esp @ 8.4.0+2021r2-patch5
Reading CMake configuration…
Dependency Graph
|-- noise-c @ 0.1.4
| |-- libsodium @ 1.10018.1
Compiling /data/mmwave/.pioenvs/mmwave/src/main.o
In file included from src/main.cpp:112:
src/R24dvd.h: In member function ‘void UartReadLineSensor::R24_frame_parse_human_information(uint8_t*)’:
src/R24dvd.h:726:66: warning: comparison is always true due to limited range of data type [-Wtype-limits]
if (data[FRAME_DATA_INDEX] < 3 && data[FRAME_DATA_INDEX] >= 0) {
~~~~~~~~~~~~~~~~~~~~~^~
src/R24dvd.h:742:66: warning: comparison is always true due to limited range of data type [-Wtype-limits]
if (data[FRAME_DATA_INDEX] < 9 && data[FRAME_DATA_INDEX] >= 0) {
~~~~~~~~~~~~~~~~~~~~~^~
src/R24dvd.h:749:66: warning: comparison is always true due to limited range of data type [-Wtype-limits]
if (data[FRAME_DATA_INDEX] < 3 && data[FRAME_DATA_INDEX] >= 0) {
~~~~~~~~~~~~~~~~~~~~~^~
src/R24dvd.h:762:66: warning: comparison is always true due to limited range of data type [-Wtype-limits]
if (data[FRAME_DATA_INDEX] < 3 && data[FRAME_DATA_INDEX] >= 0) {
~~~~~~~~~~~~~~~~~~~~~^~
src/R24dvd.h:777:66: warning: comparison is always true due to limited range of data type [-Wtype-limits]
if (data[FRAME_DATA_INDEX] < 9 && data[FRAME_DATA_INDEX] >= 0) {
~~~~~~~~~~~~~~~~~~~~~^~
src/R24dvd.h:784:66: warning: comparison is always true due to limited range of data type [-Wtype-limits]
if (data[FRAME_DATA_INDEX] < 3 && data[FRAME_DATA_INDEX] >= 0) {
~~~~~~~~~~~~~~~~~~~~~^~
src/R24dvd.h: In member function ‘void UartReadLineSensor::R24_frame_parse_open_underlying_information(uint8_t*)’:
src/R24dvd.h:918:66: warning: comparison is always true due to limited range of data type [-Wtype-limits]
if (data[FRAME_DATA_INDEX] < 3 && data[FRAME_DATA_INDEX] >= 0) {
3 of 4 of my MR24HPC1 devices have died. I was following the Seeed Studio guide to integrate it into Home Assistant (HA) and ESPHome, using the XIAO ESP32C3. They all died shortly after I adjusted some settings in HA. There is a FAQ4 entry that talks about the problem, but indicates it should have been fixed as of Jul 30.
I just started setting up the devices yesterday, so I thought I was fine. However, there is a discrepancy in the guide. In step 5, for the second part of the YAML file there is a “Click here to preview the full code” and a “Download the Code” option. The code is different between those 2 options. That is because there were several commits on Aug 21 in the GitHub repo that the “Download the Code” option links to. There appear to be several regressions to an earlier version of the code. I was using the latest GitHub version when 3 of my devices died. I switched to the code in “Click here to preview the full code” later, but I’m scared to try to adjust settings on my last remaining device. Which is the preferred version?
The next issue is that the devices that died will not take a UART firmware re-flash. They just don’t respond to the steps. I know it works because I successfully re-flashed my working device. However it appears it isn’t actually an upgrade. After re-flashing it, the version still says “G24VD1SYV001006”, which is what I had. I noticed it doesn’t say anywhere what version the UART_MR24HPC1-20230302.bin firmware actually is. From a hex dump it looks like it is actually still G24VD1SYV001006. This is rather confusing. As the page says, version 1006 is the first one to support UART flashing, but the provided firmware is the same version. What is the point? If it is to try to fix broken devices, it isn’t working in this case, as they won’t re-flash. It would be helpful if a firmware version was released that didn’t allow the device to be bricked just because a few settings were changed.
I also tried the Arduino sketch in “exclusion 4” and it doesn’t show any output. It is also fairly clear to see just by connecting the device to a USB-Serial adapter, as it just never sends any radar output, while a working device does. And it doesn’t respond to any commands. The only thing it sends, right after startup is “53 59 80 01 00 01 00 2E 54 43” once, then nothing more. That seems to decode to a human presence report indicating absence.
So is there any way to fix my devices now that they are in this state, short of a JLink?
