mmWave Presence Detection - ESPHome style

Thank you. I can share the stl if someone want.
I will print the cover tomorrow. My first try will be in 2mm weight. Hoping that is not an issue. I will see :wink:

Please do!

Un still have to assemble mine after moving and do the “funny” calibration process, but looking forward to give it a try!

Is this the name of the dance that you do in front of the sensor?? /s :stuck_out_tongue:

4 Likes

Hi all

This looks really interesting. My sensor just arrived so I’m getting all the bits I need lined up.

In terms of the wiring.

G and V make sense, i think. tx and rx also make sense (18 and 23). But the code also mentions GPIO22 and I can’t work out what that gets connected to on the sensor.

Anyone help, please?

@andyjacobs are clues an acceptable answer?

Check the wiki which includes a chart of the pinouts of the sensor. Using the process of elimination you have but two left to choose from on the sensor :wink:

As for GPIO22, that’s just the IO that I chose on my particular dev board. You could choose any suitable IO on yours.

Ha ha… I did check that. So we have GPIO1 and GPIO2. Based on “By default, it outputs high when people presence detected, otherwise, output low”, my gut was GPIO2. But that’s only because GPIO1 doesn’t say anything. Reading the bit under the table implies either.

Am I getting warm?

You got it :wink:

1 Like

Nice one. Work call in 12 minutes and then I need to find me a spare D1 Mini (I think I have half a dozen in a box). Quick stab around with the soldering iron, copy and paste. Should be up and running by 4.45 with a bit of luck.

Callipers out and I’ll see if I can Tinkercad me a box to print later.

@crlogic I have another question for you, why are you setting the pin to pull down mode? Didn’t find anything in the DFRobot docs

Hopefully next week I can start with mine myself!

Here is a good read on the topic → https://embeddedartistry.com/blog/2018/06/04/demystifying-microcontroller-gpio-settings/

1 Like

Ok, so luck or talent seems to have run out!

It’s all looking right in HA but the “Diagnostic” always says “Home”. I have it in a drawer on my desk.

Wiring from the sensor to my D1 Mini is:

Tx to D1 (GPIO5)
Rx to D2 (GPIO4)
IO2 to D0 (GPIO16)
G to G
V to 5v

The important bit of YAML after captive_portal: looks like this:

web_server:
  port: 80
  version: 2
  include_internal: true
  auth:
    username: "xxxxx"
    password: "xxxxx"

http_request:
  useragent: esphome/$device_name
  timeout: 2s

switch:
  - platform: safe_mode
    internal: true
    name: use_safe_mode

binary_sensor:
- platform: gpio
  name: mmwave_in_bedroom
  pin:
    number: GPIO16
    mode: INPUT_PULLDOWN

uart:
  id: uart_bus
  tx_pin: GPIO5
  rx_pin: GPIO4
  baud_rate: 115200
  debug:
    direction: BOTH
    dummy_receiver: true
    after:
      delimiter: "\n"
    sequence:
      - lambda: UARTDebug::log_string(direction, bytes);

number:
  - platform: template
    name: distance
    id: distance
    min_value: 0
    max_value: 1350
    initial_value: 315
    optimistic: true
    step: 15
    restore_value: true
    unit_of_measurement: cm
    set_action:
      - uart.write: "sensorStop"
      - delay: 1s
      - uart.write: !lambda
                      int cm = (int)ceil(x / 15.0);
                      std::string cms = "detRangeCfg -1 0 " + to_string(cm);
                      return std::vector<unsigned char>(cms.begin(), cms.end());
      - delay: 1s
      - uart.write: "saveCfg 0x45670123 0xCDEF89AB 0x956128C6 0xDF54AC89"
      - delay: 1s
      - uart.write: "sensorStart"
      
  - platform: template
    name: latency
    id: latency
    min_value: 0
    max_value: 65000
    initial_value: 12500
    optimistic: true
    step: 25
    restore_value: true
    unit_of_measurement: ms
    set_action:
      - uart.write: "sensorStop"
      - delay: 1s
      - uart.write: !lambda
                      int ms = (int)ceil(x / 25.0);
                      std::string mss = "outputLatency -1 0 " + to_string(ms);
                      return std::vector<unsigned char>(mss.begin(), mss.end());
      - delay: 1s
      - uart.write: "saveCfg 0x45670123 0xCDEF89AB 0x956128C6 0xDF54AC89"
      - delay: 1s
      - uart.write: "sensorStart"   

button:
  - platform: restart
    name: Restart $device_name

  - platform: template
    name: "factory_reset_dfrobot"
    id: "factory_reset_dfrobot"
    on_press:
      - uart.write: "sensorStop"
      - delay: 1s
      - uart.write: "factoryReset 0x45670123 0xCDEF89AB 0x956128C6 0xDF54AC89"
      - delay: 3s
      - uart.write: "sensorStart"  

I can read the logs and everything so the D! Mini is obviously working. The red light on the sensor is flashing on and off.

Am I missing something obvious?

Bah! Ignore that. I was looking at the wrong bit. Just seen the sensor bit and it’s working perfectly by the looks of it.

This is brilliant!

I’m intrigued though. I put it on my desk facing the closed door. Step son walks along the landing. Sensor triggers. What’s it detecting? His body through a closed door? Or the vibrations coming through the floorboards? Sitting with it pointing at me, no matter how still I sit, even if I hold my breath, I can’t get it to show “off”. If I sit in my office playing my guitar, my PIR will regularly switch the lights off and I have to wave. In fact, I’ve taken the PIR out of that room for that very reason. This would fix that. And switching lights off with no motion. At the moment, I have to set a delay of 3 to 5 minutes to get over things like if I’m stood chopping veg in the kitchen. With this, you could reduce that delay to seconds.

I think this cost me about £31 for the sensor and a couple of quid for the D1 mini. Ok, it’s “only” presence but that’s cheaper than a Hue sensor. I guess the only downside is that running it off battery is unlikely to be realistic.

Easy enough to test. Using phone to check sensor status, close door, stand still beside door. Wait for sensor to turn off (helps to set a fast off time). Wave hand behind the closed door (to test vibration theory).

Not all doors are created equal after all.

But I would also go as far as to configure the sensor so that the distance of the door is beyond the configured detection distance. While you can measure, please don’t assume the distance is pin-point accurate and test it.

This is the beauty of it :slight_smile:

2 Likes

Here my 3D print is shared for you

Here the result with the cover (no issue)
image

Mmwave see people(s) not moving where Hue sensor see moving only. It works perfectly

2 Likes

The story so far.

This is the smallest i could get it. Luckily, 5v, G, TX and Rx line up with suitable pins on the D1 Mini. I’ve then got a short wire going from IO2 over to D0. Just got to model the top half now and add a sliding bit to good both halves together.

4 Likes

And finally…

Still needs a bit of tweaking but it’s usable

That’s a brilliant idea, bit annoyed I didn’t think of it when I soldered up mine now! It would have halved the size and more importantly… less of my poor soldering. This one is being stuck behind the TV cabinet luckily so not a problem but might be copying your idea for the second…

Whit these chips there’s no need for a hole in the cover, right?

Nice work all of you!

Nah no need for the hole in terms of signal strength, I have got the design with hole and without actually. I was going to see how hot it all ran before deciding if it should keep the hole for heat escape given it’s a sealed box otherwise!

1 Like