-
-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Discussion for further sensor filtering and algorithmic improvements #134
Comments
As per the screenshot in #144 (also below), we see Zoe bouncing back and forth between the kitchen and dining room. Where she was sitting at the time was fairly equidistant between both proxies. However due to the nature of the proxies (they're Shellys in the light switches) they tend to be on one side of a room and not in the centre, so this may become quite a common occurrence. But location accuracy is a subject for another time. To mitigate the bouncy times, I was thinking if we could determine the person is stationary and we are seeing this behaviour, then we could make the proxies a bit 'stickier', as in the area entity would require a higher difference in distance before switching back to the other. I think this could be done by:
The idea being that if swapping is frequent the stickiness goes up and as the frequency decreases, the stickiness average would decrease, kinda an inverse to the time * the average distance to the proxies * a fudge factor. That way stationariness (gee, I didn't know that was a word) is determined by the frequency of swapping and the stickiness attribute auto regulates the swapping without interfering with moving to another proxy (area) nor interfering with actually moving closer to one of the proxies in the stickiness flag. EDIT: |
Hmmm that's an interesting approach. It makes sense that entities that are "flapping" between areas could benefit from some damping to their ability to switch. I've been thinking about this in the back of my mind while doing the filtering stuff, too. I'll give your idea some time to percolate. My current thinking is that a lot of this switching is (probably?) caused by the current proxy receiving occluded signals or missing packets, rather than the usurper proxy actually reading closer (I'll need some more data to confirm that) or at least, not reading much closer than it was previously. I'm thinking it might work to compare the velocities implied by the two proxies (mathematically this might be exactly what you're suggesting, since we're integrating distance over time). If the challenging proxy implies a low "approaching" velocity, then we can assume it's probably stationary and the two proxies are reasonably equidistant or the incumbent proxy is giving poor quality readings right now. However if the usurper proxy is indicating a "high" "approach velocity" (as opposed to the "retreat velocity" that I think this might give more stability but without compromising on responsiveness, based on the plots I've seen while testing. Does that sound like a decent approach to you? I'm leaning somewhat toward trying to model things more... Newtonianly(?!) as my previous area-deciding logic got pretty confusing to debug once I was several levels deep in comparing proxies using more "reasoning-based" approaches. For what it's worth, I think the long-goal of trilateration will inherently assist with this, as it will start to "understand" the relative relation between proxies/areas, rather than treating them as a binary/ternary/(n-ary?) choice. Could you gather some graphs of Suma's "distance to" measurements for the proxy's it tends to switch between, along with the "Area" sensor? So similar to the below, without the final "distance" sensor or any of the "unfiltered" sensors, and at a fine-enough timescale that I can see the per-interval updates during some of the decisions. Here's a beacon I carried to and left on a table, roughly equidistant from kitchen and dining proxies. I left the area, and even with no motion nearby (there was someone a few metres the other side of the lounge proxy) we still get a fair amount of variability. (my rssi figures aren't well-calibrated at the moment, our dining/kitchen is rather significantly less than 100sqm!) Interesting points:
I think that similarly to how we have a At any rate, D is an issue, since it's hard to distinguish between "stationary beacon, gradual noise effects on proxies" versus "beacon circling a proxy" - I think I lean toward the former, for the most part. Multiple proxies in each area really does solidify things though - with two proxies in my studio I basically never get spurious area switches for my watch, even though it is particularly prone to signal variations based on wrist position and orientation. Again, trilateration would also solve a certain amount of this, since it doesn't suffer from having to treat areas as being defined only by proxies "in" that area. I'll be interested to see if my observations here line up with what you're seeing as well. |
Suma is not switching much at all any more. Unless it is leaving there is only one proxy close by (the garage door opener). The next closest is the back garden esp32 (M5Stack) which is a bit temperamental. It seems to only want to communicate to one HA at a time, sometimes my production, sometimes my dev, whereas the Shellys will quite happily communicate to both. I think this screen shows what you're looking for, but it also shows that sometimes the Shelly's reception will have unfiltered distances between 1.26m - 3.16m (left side of the graph) for many hours, and then when the other car leaves (4:42) it will swap to distances between 1.26 and 6.81 (right side of the graph), and when the other car returns it will change again (1.26-5.01m in the case of last night). I'm just mentioning this to give an example of how much things can change with a change in environment, but yet while everything is static (no one in garage and nothing moving) there are still huge variations in the signal. Also note that the M5Stack esp32 is connected via WiFi but it is still monitoring Bluetooth. I believe the default settings in ESPHome (below) mean that every 320ms it will scan for bluetooth signals for only 30ms. This naturally results in many missed packets, hence the gaps in the 'back garden' graph. The Shellys don't seem to suffer from this, likely because they have multiple radios. esp32_ble_tracker:
scan_parameters:
interval: 320ms
window: 30ms Now that Private BLE is connected though, I can also add my watch or phone. In this graph I'm stationary in the office with both the hallway sensor (M5Stack) and Office ceiling light are right next to the office door (same horizontal distance but switch is about 30cm higher up. The bathroom heater switch is in the next room through an interior wall (but about same distance). As the start to a spawning idea, in this case the average between ceiling light and hallway sensor should give a clearer signal. Might be interesting to see. |
Hey, I was wondering if you had to do much work to set up your shelly's, or what settings you are using on them? On the community thread, lazmo88 is seeing a lot of big gaps in packet reception, so I'm wondering if its the script setup on the shelly side that's giving them grief. In particular, looking at |
(oh, also - I'm stoked about the code you pulled together for trilateration and I'm itching to get it integration as soon as I can!) |
That's all I did. Just 10 seconds beyond setting up the Shelly's on the WiFi and accepting the prompt to add the Shelly's inside HA. (Plus about 1-2 hours of investigation on the difference between the Shelly WebUI setting 'Enable Bluetooth gateway' and the HA setting 'Bluetooth scanner mode'). Once I figured it out though, adding a Shelly and setting it up as a "Bluetooth scanner" is just seconds per device. Additionally, they are super reliable and push updates immediately into HA. I have about 13 now and will be adding the new Shelly Mini PM into all power sockets just to monitor whole house power usage. That'll be about another 15 Shellys @ 12 euros each. |
Yep, me too Ashley. Might be starting some new work soon so free time may go down a bit till I get up to speed. All the same, that code just took one late night to pull together. I was surprised how easy it was. |
A continuation of the fruitful chat with @jaymunro in #99 which lead up to the v0.5.0 release today.
I've been finding the elimination of peaks to be pretty promising thus far.
The text was updated successfully, but these errors were encountered: