I’m starting a new project and asking for advice on the most efficient solution.
I have some LD2410 mmWave sensors used with ESPHome. Let’s say I mount two of these on a wall separated by about 2 meters. The sensor will tell me the distance to a person, but not the actual position. With distance, I know only that the person is somewhere along an arc with a radius of X meters and centered on the sensor. But with two sensors, I get two arcs. As the person must be on both arcs at the same time, I know he is where the two arcs intersect.
So with only two $5 sensors, I can track the (x,y) location of a person in a room. I want this because I have a large open floor plan and the lights should be set differently depending on where a person is.
In general, I can use N sensors and have N arcs, and with more than two arcs, they will not all intersect at the same point, so I will have to compute some kind of weighted average.
So my question is how best to combine the sensors. I could use an automation that triggers when any sensor reports a change in distance, then I recompute the (x,y) location, but that is WAY too much math to place in a template. The calculations are complex as there is no direct solution, and I need to make an iterative numerical optimization. I will need to use Python, C++, or something like that.
Maybe what is needed is a custom integration? But I’ve never written one. I assume they can be triggered on value updates? I do have many years of experience as a software engineer, some of it working on air defence radar systems. But I’m a beginner when it comes to the HA server internals. I want a low-latency approach.
My OTHER idea for a sensor is stereo vision. It is similar because I would combine data from multiple sensors, and there is quite a lot more computation than fits in a template.
You’re right, HA isn’t very good at computational acrobatics. I know little about ESPHome, so I can’t speak to doing the calculations in that environment.
My particular hammer (If you only have a hammer, all solutions look like a nail) is c++ running on an Arduino or ESP using the Arduino IDE.
I’d put the sensors on an Arduino Nano and do the calculations there. The “sensors” would be the X and the Y location of the the object. This data would be sent to HA using MySensors.
Note that MySensors is primarily an nRF radio network. But the radio network doesn’t have to be used when the sensors are on the gateway. This gateway is plugged into a USB port, and HA integration MySensors, receives the data. In HA you decide what to do with the location. (The protocol for MySensors is auto discovery)
I’ve never done it, but I believe you can do the same with an ESP device, though I recommend creating an MQTT MySensors gateway on the ESP device. Then the data goes to an MQTT broker (one that is part of HA is fine) which passes it onto HA. This would be WiFi instead of serial.
If you’re using an ESP device, consider Tasmota. That environment allows one to make a custom Tasmota device which in your case would be interfacing the sensors calculating the X,Y and sending the data to HA. Tasmota is is also auto discovery.
How accurate do you need? How many sensors needed to cover the area?
LD2410 has a range of about 5m? For multiple sensors, just calculate the x,y position (simple quadratic) for each pair of sensors (6 for 4 sensors, 10 for 5 sensors, etc ) and then calculate a simple average of x & y values.
Sure, it quickly gets out of hand with many sensors but, given the short range of the sensor, you should be able to prune pairs that don’t overlap.
Figuring out the math is not hard. You suggestion to do the intersection calculation using pairs of sensor makes it easier. Accurcy is likey impossible as the sensor round sthe distance to increments of 75 cm. But if I can track at 1 meter accuacy I’d be happy.
My question was where to do the math. One person suggested doing it in the ESP32 but that means each ESP32 needs to get data from the others. That is too complex. I can wait untill the data is on the server. But then the details are not clear to me. Would that be an abuse of costom integrations? Do integrations run in their own thread or do thay block the server?
You really should be using ESPHome. First off it is easy, really easy. and second it is very effecent. The code that gets flashed is compiled C++ and the protocol from ESP32 to HA allows the ESP32 to directy run services on the server. So I can do a “light.turnon” from the ESP and it is very fast with no layers of encode and data parsing. ESP32 has a built-in radio that does WiFi and some can also do Thread or Zigbee.
So I can build somerthing simple like a remove sensor with just a handfull of lines in a config file and with that not only get the data sent effecently but for free I get a Web server on the ESP32 Device I can use mainly for debugging and moniterring but I get logging to the server and (this is the best part) Over the air flashing of any new formware. So I can make a change to my code, then hit “run” I get my patched code runing on a remote ESP32. And all with a few config file lines in yaml. And the commincations path is securred. with a key.
There is a web-based GUI in the works that will allow you to just click on the chips that you have connected to I/O pins and it does the work for you. You can put snippets of C++ in the yaml if you need it for some math or to access an IO pin.
In the past I have used both C++ and Micro Python on ESP32 and will continue to do that for more complex robotics projects but for Home Assistant related things, there is no need to do that kind of work.
BTW under the hood, ESPHome is using FreeRTOS for some kind of event driven multi-threaed design that we don’t need to know or care about.
Two sensors reporting values to HA entities d1 & d2. In HA, a template to calculate the x,y position. The template will be re-evaluated on every change of d1, d2 (round values to 1dp). Include default values (0) to avoid undefined errors.
Place two sensors in corners on the same wall so there is only 1 (x,y) solution.
x = (d12 - d22 + L2) / 2L where L = distance between sensors.
Here’s an example of a template sensor (of similar complexity as would be needed) used to calculate the apparent temperature. It lives in my templates.yaml file.
- sensor:
- name: temp_apparent_calc
unique_id: 10240082
unit_of_measurement: °C
device_class: temperature
state: >
{% set rh = states('sensor.hp2561ca_pro_v1_9_9_humidity') | float(default=50) %}
{% set Ta = states('sensor.hp2561ca_pro_v1_9_9_outdoor_temperature') | float(default=10) %}
{% set v = states('sensor.hp2561ca_pro_v1_9_9_wind_speed') | float(default=10) %}
{{Ta+(0.33*rh*0.06105*(e**(17.27*Ta/(237.7+Ta))))-(7*v/36)-4.0 | round(1) }}
You might want to take a look at EverythingSmartHome’s github. They have all the ESPHome configs for their various devices and a Zone configurator App/Docker file.
I think I will try your suggestion. At first I was going to compute a global optimum for N sensors, but there is no closed-form solution. It is iterative.
But as you say, with two sensors, the solution is simple. I think I will treat three sensors solution as pairs of two sensors. So for sensors A, B and C I can have templates for point AB, AC and BC and then my final reported position “ABC” will be the vector average ABC = (AB + AC + BC) / 3 and that is good enough. I thing the next step is to get something working and collect real data.
There is an even easier way to hanle N sensors even with large N and complex arc intersections. The sensors have 75cm resolution so divide the room into a grid. Put a counter in each grid cell initialized to zero, Then for each sensor follow the arc and increment the counter for ever cell it crosses. then hunt fore peaks on the grid. But as I said, I need real data first.
These will be Thread devices that can route so that is another reason to put several of them up. Thanks again.
Just be aware that pairs that can produce 2 solutions need to be excluded (ie pairs that are vertically opposite, or nearly so). Only use pairs that are on the same wall.
Maybe 4 sensors would be ‘better’ than 3.
Assume ABC in three corners. AC will be vertically opposite and will have two solutions so can’t use that pair. Leaves AB & BC - 2 positions to average.
Assume ABCD in four corners. AC & BD each will be vertically opposite so eliminate those pairs. Leaves AB, BC, CD, AD - 4 positions to average.
I might set up a simulation to see if it makes a material difference - fun spreadsheet time
I ran 50 simulations each with 2, 3 & 4 sensors. Sensor readings randomised with +/- 0.75m delta.
In summary, with 2 sensors (AB), the calculated position was an average of 0.62m from the actual.
With 3 sensors (AB, BC), the calculated position was 0.5m from actual (15% better)
With 4 sensors (AB, BC, CD, DA), the calculated position was 0.42m from actual (another 15% improvement).
Methodology is pretty rough but gave reasonably consistent results on several 50-sim runs.
If a more accurate result is required, better sensors would be the better solution.
Interesting challenge, not unlike celestial navigation.
Three sensors will give 3 locations (circumference crossings); four will give 6. Which ever you use, averaging the x’s and y’s of each crossing would give a pretty good location. Is this how the location is being determined?
Has is it been considered that each sensor will probably have a consistent error which could be determined empirically? Once known, there could be compensation for the error. My intuition about this type of sensor tells me that the error is of 2nd order (slope plus offset)
That’s. that was so helpful. I had guessed that I could improve on the sensor’s native 0.75M accuracy by using more sensor. But 0.5 M is very good. That could place a peprson on a specific chair. These are literally $6 sensors. I don’t have any in hand now but I have a tracking number. They are on the way.
I suspect the accucy depends on the baseline distance between the sensors and I don’t yet know if running two in the same room will even work. They might see each others radio signals.
Better sensors? I jst read the manual for the LD2450. That unit will track up to three targets ad in x, y and radial velocity. It solves the problem internally with just one unit. They say multiple units are OK, if you place and aim them proberly…
