Get rid of everything but the mmWave and report back.
You got it. For some reason I didnāt think of that, of all things! Running on just the mmwave sensor now and will check back for any crashes tomorrow morning.
Is there any way that I could tweak the code to display American measurements?
About 12 hours and no reboots! Sorry, I posted in the wrong thread. It is not an mmwave sensor issue. So I still have some troubleshooting to do. My guess is the combination of sensors is consuming too much memory for the ESP32 because I was getting some out of memory errors before each crash. But thatās a topic for another forum.
Thanks for the obvious troubleshooting step that I missed
1 Like
I did have some reboots with the latest code and a D1 mini.
I attribute it to the mini being a bit weak so Iāve removed completely the UART parsing for motion target total number and it seems to be fixed.
I didnāt have the target tracking feature enabled as that did reboot the mini frequently anyhow.
Iāve made the modified code that Iām using for the D1 mini, plus wiring and a sample 3d case available here:
1 Like
Just came back to this thread to ask about the frequent reboots. Iām also using a d1 mini and the detection seems to be pretty reliable (in a small room) but I am getting frequent reboots if I look at the history in HA. I donāt use any of the num_targets information as itās way too unreliable to do anything meaningful with so Iāll try out your stripped down version and hope it solves it!
Edit: Itās been an hour without a reboot so looks like itās going strong!
1 Like
Nice guide. I like the idea of putting it into a smaller package.
Iāve been using an ESP32 devkit v1. I havenāt had any reboots running the sensor alone, but when I add a BLE tracker and PIR sensor it reboots quite often. I havenāt had time yet to troubleshoot what the problem with that might be.
1 Like
wow fantastic, glad to have helped! Mine havenāt rebooted at all over the past couple of days that Iāve got them running continually, so hopefully this version solves this issue. I believe that as the D1 Mini doesnāt have hardware support for UART communication, that reading the UART continually overloads it and it restarts. Iāve disabled these and it appears that it is stable like that.
you could try a few things - firstly you could remove completely the .h file and do all the command sending directly to the UART port from the YAML file. That should remove quite a lot of the code burden on the ESP (but equally will remove the functionality of reading the sensor values for HA to use). You could also try the version of the code above without the target tracking features in it to see if it is more stable for you.
Definitely doesnāt help things. Disabling of the web_server does also help stability; especially multi-sensor deployments.
While the parsing is removed, the mmWave is still configured to send the target data to the ESP. Might want to disable it as well given goals of your build. Command parameters found in the datasheet in the docs linked in the OP.
Might be worth doing a āliteā release for ESP8266ās w/ no target_data/web_server while retaining the configuration options since the latter are very lightweight.
1 Like
But if I disable uart wonāt it stop the code from reading get sensor values , like distance, etc? Iād like to keep these off possible.
Good idea to disable the web server! On it.
Config params are polled by the ESP. Presence/targets are continuous serial output by the sensor during detection. So donāt disable the ESP UART section, you want to configure the sensor to stop spamming the ESP with target data.
Ah gotcha thank you!
Thank you for the pointers! Iāve trimmed down the code and set the sensor to not output presence messages at all to the UART as the IO2 pin is doing the same trick for HA. Also refactored the code to remove the now defunct mmWave radar switch code in the .h file. Finally created a lambda function to flag the radar as on if there is motion detection by the IO2 pin.
Iāve kept the web server as I like having lower level access to the device but may remove it if thereās a need to trim down the code further for stability purposes.
binary_sensor:
- platform: gpio
name: "${device_name_pretty}"
id: mmwave_presence_detection
device_class: motion
pin:
number: ${gpio_pin}
mode: INPUT_PULLDOWN
# when motion is detected, the radar sensor is on so publish radar state to HA
on_press:
then:
lambda: !lambda |-
if (!id(mmwave_sensor).state) {
id(mmwave_sensor).publish_state(true);
}
sensor:
- platform: custom
lambda: |-
auto s = new leapmmw(id(uart_bus));
App.register_component(s);
return {};
sensors:
switch:
- platform: safe_mode
name: use_safe_mode
- platform: template
name: mmwave_sensor
id: mmwave_sensor # do not change
entity_category: config
optimistic: true
turn_on_action:
- uart.write: "setUartOutput 1 0"
- delay: 1s
- uart.write: "saveConfig"
- delay: 4s
- uart.write: "sensorStart"
turn_off_action:
- uart.write: "sensorStop"
- delay: 2s
1 Like
Can you detect if thereās movement in a specific area? So to say cover two areas with only one sensor like with the Aqara FP1 and have different automations for these areas.
Nope, it is a single area detector.
Do you have to use capacitors with the SEN0395 as well?
Nope (Post must be at least 10 characters)
It was actually a soldering issue, you have a solder pad above the rx pin and it was connected which caused the issues
I have two of these setup with the SEN0395 so far. One with a D1 mini and one with an ESP32-POE-ISO and the one with the D1 works fine but the one with the ESP32-POE-ISO works for a bit then stays stuck on detected and wonāt switch back until I restart it. Any ideas?
Iām using these pins:
uart_tx_pin: GPIO4
uart_rx_pin: GPIO36
gpio_pin: GPIO16
