What could be the reason behind flat X/Y coordinates?
Draghmar opened this issue · 17 comments
Thank you for your comment on my recent issue in which you directed me to your history filter here. Perhaps read my latest comment on my issue. If you consider that my issue looks as though it's some sort of EPL hang. Might those flat lines be something similar?
Do both of you have the Bluetooth proxy firmware installed?
Do both of you have the Bluetooth proxy firmware installed?
Well...I don't remember which one I choose when doing first update through the webpage. :) Is there a way to confirm that right now? All I can tell is that I have:
Firmware: 1.0.8 (ESPHome 2024.7.3)
Hardware: 1.0.8
And I have mmWave Bluetooth
toggle available in the configuration.
Edit: I wonder if I didn't get the automatic setup as I have the latest version of EPL and I did have BT enabled during initialization. Maybe that's why I don't remember setup details...
Do both of you have the Bluetooth proxy firmware installed?
I definitely chose firmwares with it disabled for all my EPLs.
Can you go to the device page in home assistant for the Lite, then click the three dots (top left) and download ESPHome diagnostics then attach here?
Here you go:
config_entry-esphome-01J2BGVHE97ZYKR0KNQ986TGVX.json
Here is mine:
config_entry-esphome-01J22E41GN6DNEKZPNFP5KFGKP.json
That issue is still present and I still have no idea what's causing it. Here is the very short period when it happened. You can see that target 1 distance was going down and then stayed for some time at the same value even if the target was actually physically gone. Maybe there's an issue with edge detection? EPL is hanging on the wall, near where entrance is, so someone leaving could make sudden disappearance near the sensor. It's not something that makes too much sense but it's only thing I could think about.
As a side note: I have also Aqara FP1 there (the Occupancy
value) but I think it works on different frequency.
Can you try the latest version of the firmware (1.1.1) and see if this resolves? There was a bug fix related to this which may resolve it
I've seen your fixes and was hoping it would do something about this but at the moment I don't think it did.
I don't know how to reproduce this so I can only monitor regular events as it doesn't happen each time. I had one just before writing this. I forced graph to show only this small fragment that took less than 4min. What's important is that the last value on the bar graph is related to door being opened and closed which triggers lights off automation. MotionSensor03 (PIR) already realized that there's no one there. But EPL needed much more time to achieve that (it has only few second cool down set). Normally I'd say it's because something was moving (water, towels, etc.). But then the line wouldn't be completely flat - movement, even if small, is still movement, right?
All zones were also empty and the first one is defined near where the door is. But the Targets were not, so it looks like T1 was falsely detected as being at that last position (X: 705mm, Y: 413mm) and stayed that until suddenly dropped to 0 after 35s. Looking at coordinates I could guess it's somewhere near where the washbasin is...or towel. But there are no leakage and this towel is heavy so it would stopped moving much sooner. Also those previous occurrences had different positions.
Just for the comparison here's very similar event but this time everything went as it should:
What version are you on here?
Also to add, you said it needs much more time but just to clarify it looks like a 30s period? I know you have a cool down set to a few seconds, however this is really not recommended. I wouldn't advise anything less than 15-30s, it's not really necessary to go lower for the trade-off of false clearing. It also works much differently to a PIR so naturally you do want it to take longer to be sure a target has really disappeared.
The latest I think (those two last screenshot was taken with that version):
Firmware: 1.1.1 (ESPHome 2024.9.2)
Hardware: 1.0.8
Well, I don't agree. :) I said about cool down being low just to let you know that the 35s it needed was way more than what it should be (it was 9s at that moment I think). Also it doesn't matter in this case because the issue is not about getting Occupancy to stay on (which is what cool down helps with) but quite the opposite. Not to mention strange flat behaviour. PIRs actually has the similar thing built-in in 99% of devices I've seen. That's why I choose one from Philips, where cool downs are relatively low (MotionSensor03 is the one). ;)
Cool just checking version.
Uh yeah, I'm of course aware that PIRs have cool downs ;) that's not what I was referring to. PIRs are pretty simple in that they see changes in heat, mmWave sensors use algorithms to target tracking which is a lot more complex. The cooldown on a mmWave comes after the mmWave judges that a target is no longer present based on it's internal algorithm, however they can sometimes "hang on" to a target a little longer, thus delaying the cool down period starting.
The target lingering for 25s (plus 9s of cooldown) isn't really an issue I don't think personally, but the flat coordinates may or may not be depending on if it's the mmWave sensor itself reporting those.
What's your use case for a very short cooldown period?
Yeah, I know the basics. I'm trying to find the best sensor for quite some time. :D
I'm using it to turn on/off lights in the bathroom. Which ideally should happen at the moment of entering/leaving. Any delay is annoying. Especially when I can see light lingering after closing door (I have small apartment - I can see almost everything, everywhere ;)). With FP1 and Philips I was able to get down to about 11-13s after door was closed (Philips cool down). FP1 alone is not enough because both warm up and cool down is really huge (you can check it on my screens as Occupancy). But it's good to preventing lights going out when PIR wasn't able to detect micro movements.
With EPL, at first, I was able to get to 3-5s after closing the door and that was really amazing. But then some anomalies started to happen, like entering bathroom and closing door but not getting in the EPL range and things like that, which forced me to add some failovers in the automation. I have limited places where I can put EPL so it's not in the ideal spot - right beside door, "lookin" inside, when it would be much better looking at the door.
Basically I'm experimenting with settings all the time, both on device and in automations. Those flat lines are really weird for me though. I don't understand why sensor could be detecting something that isn't there. Is this simply some downside of mmWave itself? Or mmWave sensors? Would changing sensor type helped here?
I've been looking more into the "stuck sensor" issues and I've run into the LD2450 itself sending the values (latest version of the firmware for the mmwave sensor but my EPL firmware is a bit custom atm (hence I was able to get debug logs).
[22:27:00][D][uart:833]: p2_x: 1099, p2_y: 2600, p2_speed: 0.000000, p2_distance_resolution: 360, p2_distance: 2822.729248, p2_angle: -22.913403
[22:27:00][D][sensor:094]: 'Target 2 X': Sending state 1099.00000 mm with 0 decimals of accuracy
[22:27:00][D][sensor:094]: 'Target 2 Y': Sending state 2600.00000 mm with 0 decimals of accuracy
[22:27:00][D][sensor:094]: 'Target 2 Speed': Sending state 0.00000 m/s with 2 decimals of accuracy
[22:27:00][D][sensor:094]: 'Target 2 Distance': Sending state 2822.72925 mm with 0 decimals of accuracy
[22:27:00][D][sensor:094]: 'Target 2 Angle': Sending state -22.91340 ° with 0 decimals of accuracy
[22:27:01][D][uart:833]: p2_x: 1164, p2_y: 2584, p2_speed: 0.000000, p2_distance_resolution: 360, p2_distance: 2834.069824, p2_angle: -24.249866
[22:27:01][D][sensor:094]: 'Target 2 X': Sending state 1164.00000 mm with 0 decimals of accuracy
[22:27:01][D][sensor:094]: 'Target 2 Y': Sending state 2584.00000 mm with 0 decimals of accuracy
[22:27:01][D][sensor:094]: 'Target 2 Distance': Sending state 2834.06982 mm with 0 decimals of accuracy
[22:27:01][D][sensor:094]: 'Target 2 Angle': Sending state -24.24987 ° with 0 decimals of accuracy
[22:27:02][D][uart:833]: p2_x: 1168, p2_y: 2583, p2_speed: 0.000000, p2_distance_resolution: 360, p2_distance: 2834.803955, p2_angle: -24.331882
[22:27:02][D][sensor:094]: 'Target 2 X': Sending state 1168.00000 mm with 0 decimals of accuracy
[22:27:02][D][sensor:094]: 'Target 2 Y': Sending state 2583.00000 mm with 0 decimals of accuracy
[22:27:02][D][sensor:094]: 'Target 2 Distance': Sending state 2834.80396 mm with 0 decimals of accuracy
[22:27:02][D][sensor:094]: 'Target 2 Angle': Sending state -24.33188 ° with 0 decimals of accuracy
[22:27:03][D][uart:833]: p2_x: 1168, p2_y: 2583, p2_speed: 0.000000, p2_distance_resolution: 360, p2_distance: 2834.803955, p2_angle: -24.331882
[22:27:04][D][uart:833]: p2_x: 1168, p2_y: 2583, p2_speed: 0.000000, p2_distance_resolution: 360, p2_distance: 2834.803955, p2_angle: -24.331882
[22:27:05][D][uart:833]: p2_x: 1168, p2_y: 2583, p2_speed: 0.000000, p2_distance_resolution: 360, p2_distance: 2834.803955, p2_angle: -24.331882
[22:27:06][D][uart:833]: p2_x: 1168, p2_y: 2583, p2_speed: 0.000000, p2_distance_resolution: 360, p2_distance: 2834.803955, p2_angle: -24.331882
[22:27:07][D][uart:833]: p2_x: 1168, p2_y: 2583, p2_speed: 0.000000, p2_distance_resolution: 360, p2_distance: 2834.803955, p2_angle: -24.331882
[22:27:08][D][uart:833]: p2_x: 1168, p2_y: 2583, p2_speed: 0.000000, p2_distance_resolution: 360, p2_distance: 2834.803955, p2_angle: -24.331882
[22:27:09][D][uart:833]: p2_x: 1168, p2_y: 2583, p2_speed: 0.000000, p2_distance_resolution: 360, p2_distance: 2834.803955, p2_angle: -24.331882
[22:27:11][D][uart:833]: p2_x: 1168, p2_y: 2583, p2_speed: 0.000000, p2_distance_resolution: 360, p2_distance: 2834.803955, p2_angle: -24.331882
[22:27:12][D][uart:833]: p2_x: 1168, p2_y: 2583, p2_speed: 0.000000, p2_distance_resolution: 360, p2_distance: 2834.803955, p2_angle: -24.331882
[22:27:13][D][uart:833]: p2_x: 1168, p2_y: 2583, p2_speed: 0.000000, p2_distance_resolution: 360, p2_distance: 2834.803955, p2_angle: -24.331882
[22:27:14][D][uart:833]: p2_x: 1168, p2_y: 2583, p2_speed: 0.000000, p2_distance_resolution: 360, p2_distance: 2834.803955, p2_angle: -24.331882
[22:27:15][D][uart:833]: p2_x: 1168, p2_y: 2583, p2_speed: 0.000000, p2_distance_resolution: 360, p2_distance: 2834.803955, p2_angle: -24.331882
[22:27:16][D][uart:833]: p2_x: 1168, p2_y: 2583, p2_speed: 0.000000, p2_distance_resolution: 360, p2_distance: 2834.803955, p2_angle: -24.331882
[22:27:17][D][uart:833]: p2_x: 1168, p2_y: 2583, p2_speed: 0.000000, p2_distance_resolution: 360, p2_distance: 2834.803955, p2_angle: -24.331882
[22:27:18][D][uart:833]: p2_x: 1168, p2_y: 2583, p2_speed: 0.000000, p2_distance_resolution: 360, p2_distance: 2834.803955, p2_angle: -24.331882
[22:27:19][D][uart:833]: p2_x: 1168, p2_y: 2583, p2_speed: 0.000000, p2_distance_resolution: 360, p2_distance: 2834.803955, p2_angle: -24.331882
I'm wondering if resetting the x & y values to 0 if they don't change for a while would be a reasonable way to resolve the symptom.
(Code I'm running is here for sanity checking, though it was running with a 1000ms update time when I got the logs above. The code hasn't been battle tested so I don't recommend using it just yet)
I implemented the change I suggested above using the same readings 8 times in a row and did some testing . Whilst I did see some improvements I still had stuck sensors (I'm running a bluetooth proxy so that may factor in).
The change I made did have a (potential) flaw in that if a sensor got stuck with a presence in the room it may report that there was no-one there.