Seeed 60GHz mmWave integration using ESPHome

I have quite a few working 24GHz mmWave presence sensors in my home and have made some solutions for others as well but I was very excited when I learned of the 60GHz models from Seeed. So much so that I purchased both the heart/breath MR60BHA1 and fall detection MR60FDA1 variants without a second thought. As is my MO, I had no idea before they arrived, how I was going to make them work :slight_smile:

I played a bit with the example code from Seeed’s GitHub that works with Arduino IDE and even made an HA integration, of sorts, using MQTT thanks to a lot of tips from @mattdm here in the forums. While this works, I wanted to ESPHome and the API based Home Assistant integration framework it provides for more sensor resiliency and also, just because :slight_smile:

I spent a lot of time searching for any hint to even a partially working ESPHome based integration for the Seeed Studio 60GHz line of radar modules and found almost no hint. So I made my own:

The code could be streamlined and made a bit cleaner. For now however, it’s easy to work with and understand. Also adding new sensors is super easy given how I am not using byte defines and cases which is cleaner, smaller code but harder to debug… at least for me.

Hope this helps anyone else who struggled like I did to find a working integration for these cool sensors.

5 Likes

Nice clean code, I like it! I swear I wrote some of that…

Happy someone managed to slog through the datasheet with how many different messages are documented.

Ahh yes, sorry about that. I credited @mattdm for the work I did on making an MQTT version of this but your code snippets from:

here: mmWave human presence for under $20?! - #52 by phillip1

Definitely showed me some hints on how to make this work in ESP! :slight_smile:

Most notably, I used your UART frame parsing and hexmap/hexStr function which was very helpful!

2 Likes

No apologies necessary!

Aren’t you causing an error on the first loop iteration by going out of bounds?
fix: if(bytes.size() > 1 && bytes[bytes.size()-2] == 0x54 && bytes[bytes.size()-1] == 0x43)

Yeah you’d think it wouldn’t work, your original code says while available > 0 and if bytes > 2…

Active code is while available () and if -1?! Odd for sure…

This wasn’t mine or yours I was working with examples from lots of places trying to figure out why I was seeing no frames at all until I realized the uart debug dummy_receiver option seems to disrupt this all together. And once it started seeing frames from the radar and could work with bytes, I never looked back.

Also could be I pasted something older but I’ll check it out, thanks for the catch!

ps, to be honest, I can’t think of a reason to interrogate the frames prior to processing in the first place, it’s not like the radar module sends any mystery frames, all frames start and and end as expected. So simply while available() is probably sufficient.

I shouldn’t have tried to look at this and respond from my phone lol. Upon closer look, I don’t see the issue you’re pointing out. The logic seems clear, if second to last frame == 54 and last frame == 43 then… it does look like this is straight from your code here:

Which you provided as an example of how one might start going about getting the 60GHz radar frames.

However my observation still stands :slight_smile: there isn’t a good reason, that I can think of, to interrogate these frames before processing. Especially given the processing does that anyway and discards any frame that doesn’t match.

You got me ;D I can’t argue against my own code.

The code has an out of bounds error that is thrown and gets silenced by the arduino I’m guessing. It’s a minor nitpick, probably didn’t need to bring it up but bytes[bytes.size()-2] will be checking bytes[-1] the first time loop loops since there’s only one byte in the array.

Edit: man I’m looking at code I’ve written for the other sensors and boy am I missing a lot of bounds checks. Thankfully the arduino doesn’t die/restart if you do silly stuff like being out of bounds (apparently).

Where, when using ESPHome, can you even see Arduino debug messages? I saw them when using Arduino IDE of course but…

@DuncanIdahoCT, you are a godsend. I was searching google and found this post before I realized you had replied to my other messages about this sensor. I had tried to figure out an ESPhome integration, but without any experience, I didn’t get far. I have them set up in the bedroom waiting to have the correct code installed.

I’ll install in the next day or so and let you know how it goes. Let me know if there is a way I can send you a tip! Cheers

Nevermind, got too excited and decided to test it out instead of doing other work…

I am able to get the web server to show me data but the sensors aren’t showing up in HA via ESPhome integration for some reason (despite removing/adding multiple times). Will try rebooting Home Assistant and some other troubleshooting steps.

I have the sensors under some plywood - looks like they are stuck on detecting fairly frequently (my wife is currently in bed) and don’t seem to change to RR/HR data until the sensor is rebooted. Are you able to obtain consistent readings from the sensor?

When you use the sensor reset function, there is an initialization routine that takes maybe 10 seconds or so during which you will likely see data that is invalid, even with no human presence so if it is going pretty quick after to detecting and isn’t then showing anything until reset again, I would surmise that you aren’t getting readings at all. Under plywood? I’m not certain what that means but if you have a sheet of plywood between this and a human it may not work. While the 24GHz radar models are shown to work under a bed “shooting” up and will pass just fine through a box spring and mattress… the 60GHz models aren’t shown in that usage scenario that I have seen. Likely because the higher frequencies have a harder time passing through solid objects. I would test in a room with the unit sitting still and at about 1 meter distance.

A couple of other points to consider that are unrelated to any code you may try out on the MCU… the Seeed specs describe a min /max range and too close or too far outside of this it’s said you won’t get reliable readings or any readings at all. There are perhaps settings that can be changed but as of yet, I haven’t gotten a clear answer from Seeed on what frames to send to the radar to both get and set these settings. Also related to settings but it is documented to an extent; is “real time” mode. Some of the frames from the protocol tables (recently updated in v1.9 on the seeed site) describe only being available when the sensor is placed into real time mode. I’ve sent this setting to my unit but I can’t tell for sure what it does so I don’t include it in the program.

Update: so with a bit further review of some of the sample code:

realtime_mode_frame… 0x53, 0x59, 0x84, 0x0F, 0x00, 0x01, 0x00, 0x40, 0x54, 0x43
sleepstatus_mode_frame… 0x53, 0x59, 0x84, 0x0F, 0x00, 0x01, 0x01, 0x41, 0x54, 0x43

It would seem that realtime mode is already on (sleepstatus mode set to 0x00) when shipped, and that if you want the sleepstatus mode, you set byte 6 to 0x01 with a uart.write which effectively “should” disable realtime mode.

1 Like

Those are helpful insights. That makes sense from the sensor reset data as it was very sporadic and only read for ~30 seconds and then would report “detecting.” I was also looking through documentation and saw they recommend a minimum distance of 2-5mm (3mm ideal) of head space in front of the antenna and non-metallic case/mount with a flat front. I built a rudimentary 3D printed front mount so I can mount it and see if that helps (R60A Case by space_caucus - Thingiverse). I did notice that they recommend 1.2mm maximum in front of sensor so that would make my case too thick (3mm) and prevent anything like wood being in front of it. I will need to reconsider my placement or bore a hole in my plywood bed support haha.

Do you think sleep mode is helpful in any way? I wonder if that is required to get the sleep stats including “deep sleep”, etc. I am primarily using it as a bed presence sensor and sleep tracker so I’ll look into the differences more and see if I can find anything.

I can’t say for sure if the sleep mode is helpful, not having tried it out yet. I’m finding it quite frustrating to work with the heart / breath aspects of the “sleep breathe” radar. For now I’ve shifted focus to the Fall Detection Pro model since it seems more clearly and fully developed but I’ll come back to the other one and see if I can get the sleep monitoring to work with ESPHome.

I’ve recently finished work on the Fall Detection Pro version of this ESP integration:

1 Like

Thanks so much for sharing, Duncan! Are you planning on doing the 24GHz version (MR24BSD1 24GHz mmWave Sensor - Respiratory Sleep Detection Module) ?

I don’t have one of those sensors, if Seed wants to send me one of them, I’d be happy to make an ESPHome integration for it.

Hey @DuncanIdahoCT,
first of all, thank you for your great work. I’ve been testing the library and sensor for two weeks now and everything works great it seems to be doing something.

Did you create this table or is it from some datasheet?

If it is from a datasheet, could you send me a link to it?

Unfortunately I have not been able to find any useful datasheet.

@cobbler.fascism416 when you say “everything works great”, were you able to get the respiratory rate working well ? That thing has given me a headache: sometimes it stays stuck at 0, sometimes it gives nice values but then those values do remain even if I leave the room, and sometimes it remains stuck on “unknown”… How was your setup ?

To be honest, I have exactly the same problems as you. This is a graph of my sleep tonight, and in my opinion the measured data is unusable.

Several times a night the sensor sends no data.

Therefore, I am trying to find some usable datasheet to help me figure out what the problem may be.
In addition, I’m trying to get a second sensor mode working in which it sends sleep data which is more important to me than realtime mode.