Hi!!
I have some problem
What specific problem did you encounter?
For me itâs still mmwave lite not talking to the esp32c3.
Tried different pins and also tried flashing the new firmware but it just doesnât want communicate with esp32c3 or usb to uart.
1 Like
Igual problem⌠canto get working on homeassist
Cant receive any data from the sensor on esp32C3
Can you confirm that you have updated the .yaml file and changed the pins to D2/D3 as instructed by the new Wiki?
Which specific step are you having problems with?
You can describe your problem in detail so that we can better solve it for you.
Yaml updated as well as the new pins soldered on. The firmware wonât flash to the mmwave lite using a usb uart.
Same issues here. The sensor doesnât seem to communicate with the Xiao
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:
But when I reinstall it then almost every data is coming to the HA.
I have tried 2 ESP32C and both got the same issue.
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/[email protected])
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) {
My mmwave has been picked up by shipping company to return to Seeed Studio.
Hopefully they will find out whatâs going on.
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?
FYI, I am in the same situation. I have bricked 3 or 4 MR24HPC1 devices trying to get them working in home assistant. In my opinion, they seem extremely fragile when being handled with bare hands. I have never had any issues with MCUâs or other semiconductor devices, as I live in Florida and there is no problems with static electricity. But any handling of the MR24HPC1 Lite board seems to render them useless. I cannot re-flash them with the UART tool as them just stop responding to input. Now to be fair, the data sheet warns you to not touch the boards, and handle them only along the edges, ButâŚ
When it comes to handling, the biggest problem I am encountering is the 6 pin connector for the UART. Itâs using 2.0mm pitch like for GROVE, but there is no GROVE connector for two rows of pins!. And, the spacing between rows is too narrow for two GROVE or standard JST-PH connectors to fit side by side. so getting a good connection is nearly impossible without grabbing the board. If Seeed would only make a 4 or 6 pin connector for that UART side of the board, I wouldnât have to hold the board with my bare hands to try to get breadboard jumpers to attach to it.
I have also noticed that when using the Arduino example MR24HPCB1_rawdata_print.ino on a working board that it stops putting out frames evern second after about 2 hours. A re-boot of the board is needed to get it to output again.
I would like to think that the bricked modules can be salvaged, but for now, Iâm thinking they are trashed, and Iâm being very careful with the few I have remainingâŚ