Beacon monitor remembers values from when it was disabled #3010
Labels
Comments
|
So your saying in HA you disable the sensor completely? Then later on you go on to enable it and the data is restored? That sounds more like HA core holding on to that data. Can you do me a favor and enable debug logging for the mobile app integration and reproduce the issue and grab the logs so we can see what data the app is sending back to HA core when the sensor is being enabled and disabled? |
|
The reason I believe it's the app is because I have my setting to update sensors at 1 minute interval. But I can give that a try later today. |
|
I did a test now where I turned on the beacon had it on for a while, then turned it off, while it was off I unplugged the ESP generating the beacon then turned on the beacon sensor again. This is the logs: Logs |
|
the in app logs actually dont contain the data we are looking for here. We will need to see the debug logs from HA core for the If you run the following service call you can temporarily extend the logger and pull the actual debug logs which contain the state update for the device in question. after the test you can set the logger back to an example of a sensor update will be: |
|
That service call does not exist |
|
I thought the HA logger integration was included by default but i guess not: https://www.home-assistant.io/integrations/logger |
|
Here is a video of the issue. |
|
Thanks for the video, admittedly when I read |
|
I am observing the same problem.
It seems that after turning off the Beacon Monitor sensor, the search remains in some intermediate space, and when it is subsequently activated, it is sent as if it has not been searched (even though it is not) |
|
It seems like a bug for sure. |
|
with the commit #3220, starting and stopping the sensor now works correctly. But unfortunately, working with this issue is a problem.
I use the beacon watch to trigger the door lock, at the moment the opening is triggered immediately upon entering the zone, regardless of finding the beacon, and because of this the automation is degraded, so the lock is triggered for example 100 m from the house. In the log, a state is recorded when an action is triggered when the beacon_monitor sensor is triggered, even if I am no longer (100%) within range of the beacon |
|
I have the same issue and it seems like a real problem with the way the sensor works. On "enable" the sensor should reset itself and definitely not simply broadcast the last state. This is a serious issue |
|
Yes, this issus is very annoying and degrades the feature quite a bit. For now, I've treated this behavior with automation that will "start/stop" the sensor after some time to get it cleaned up and ready for its intended use. |
|
Hey everyone I understand this issue has been a lil frustrating to deal with. I just made an attempt to fix this issue. If you would like to test the fix (which would be appreciated) please download the artifact from: https://github.com/home-assistant/android/actions/runs/3942701963 You'll need to extract the artifact and install the debug app. Notifications will only work with the persistent connection being enabled. |
|
Thanks a lot @dshokouhi, it would be great if it could be released as a beta, I would like to test it in real conditions and scenarios. Not just on a table with a beacon simulator. I understand that the compiled version and its artifact cannot be used with FCM. I.e., real testing is limited. |
you can enable the persistent connection and use the app just like the production version. The debug builds are designed to run side by side. |
|
Ok, so I can normally receive command_beacon_monitor via mobile data outside my home wifi network? |
|
the persistent connection uses the same URLs as the rest of the app so as long as you gave it a valid external address it will continue to work and function outside the home network. There will be some battery drain with the setting so its best to test the issue and then stop using the app. |
|
Okay, I'll try it tomorrow and let you know. |
The issue with this version is unfortunately the same. Attached log, if it helps. |
|
Well that sucks, I was hopeful it would work and in my testing it seemed to work. The attributes for the sensor are generated here In my PR they are being cleared when the monitor stops here Taking a closer look at the library I do see the following issue which actually seems to be the issue we have here. AltBeacon/android-beacon-library#1103 I will try to rethink this approach, thanks for testing. Given the first recommendation is to ignore the first set of values I would say for the time being stick with your workarounds. It seems if you ignore values for the first few seconds it should take care of the issue. If your automation is looking at the sensor to change state to Something like that should provide a good workaround while we try to skip the first set of invalid values. |
|
Here's the new attempt that skips over the first set of values as they are cached. Would appreciate some feedback on this latest APK. https://github.com/home-assistant/android/actions/runs/3952637822 |
|
Hey, I'm sad to say, same behavior 😔 Edit: Edit2: |
|
@Adi146 would you be able to help us here? My attempts at fixing this issue have been unsuccessful thus far. |
|
As far as I remember there is an internal list of beacons and their distance. This bug sounds like we don't clear the list when the sensor gets disabled. I have very limited time at the moment but I hope I can look at it soon. |
|
+1 I was also just bitten by this bug. Same scenario, an automation erroneously triggered the opening of my garage when I was not at home. Fortunately, my wife was at home. Thanks for looking into it. I'm happy to help if I can. |
|
I have a somewhat related but different issue happening. Essentially only one of our phones can connect to the car at a time, so I turned on beacon and monitoring on both devices. However, the first test today showed a big issue. My phone did not remove her phones UUID from the beacon monitor attributes, until about 1.5 hours after she left. I use the Mariah DB addon, so I wrote a SQL query to look at the states and state_attributes tables. (I will put the query I used at the bottom of my comment)
Newer entries are on the top. As you can see the last time my phone picked up my wife's phone was at 7:41AM when she dropped me off at work. However, the attributes were not updated for 1.5 hours until 9:22AM when I picked up my phone to check and see if everything had worked. I have the companion app set to run in the background, but it appears that when my wife's phone became out of range, it does not trigger a state change. The app must have been asleep in the background, and never woke up to report the change to home assistant until I opened the app. I have an android phone, and the companion app has permission to run in the background. I'm wondering if this is the real issue people are seeing. The app must be asleep in the background, and it wakes up to report when it has found a beacon or when monitoring is turned back on, however it doesn't wakeup to report when it has lost a beacon or when monitoring is turned off. Therefore the old attributes are still in HA the next time the beacon monitor is either turned on or detects a new beacon. Here is the SQL query as promised so people can see that I was pulling all the records properly: SELECT
s.entity_id,
s.state,
s.last_updated_ts,
FROM_UNIXTIME(s.last_updated_ts),
sa.*
FROM states s
LEFT JOIN state_attributes sa ON s.attributes_id = sa.attributes_id
WHERE s.entity_id = 'sensor.aron_s_phone_beacon_monitor'
ORDER BY s.last_updated_ts DESC |
|
@dshokouhi I'm not so sure. That issue had to do with device scanning interval. The interval in that issue was between 1min and 10s, vs the 1s foreground interval. Unless you are suggesting that my background scan interval was somehow set to 1.5 hours. I am also not disabling my beacon monitor, it was never turned off. My wife's phone on the other hand, updated that mine was no longer in range minutes after she left (still not as instant as it should have been and probably related to the issue you just linked). However mine took over an hour to notice hers was gone. Her phone was active (receiving text messages) and had High Accuracy location turned on, while mine didn't. I think the High accuracy location notifications kept the background process open enough for her phone to update (even slowly like in the posted issue) that mine was gone. While mine was asleep with nothing to wake it until I did. |
|
I'm suggesting that possibly, the companion app notices the beacons vanish, and updates the sensor on the app, but that it never reports the change to the sensor to the Home Assistant server in the background. When the app "wakes" the sensor gets reported back to the server, however any automations/triggers have possibly already fired with the old sensor data. |
|
@birdwing its still unrelated to this issue as this issue is specifically about values being restored when the monitor is enabled. Please open a new issue and make sure to fill out the issue template so we can do proper troubleshooting. |
|
I opened a Pull Request #3398 to fix this bug |
|
Thanks @Adi146 🙏 It would be great if users who are experiencing this issue can help test and confirm the fix by using the debug APK from this action https://github.com/home-assistant/android/actions/runs/4336169426 |
|
After a quick test, it seems to be really okay with this commit. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Home Assistant Android version:
beta-2762-93844ffe-full
Android version:
11
Phone model:
Motorola G9 play
Home Assistant version:
2022.10.0
Last working Home Assistant release (if known):
Description of problem:
I use the beacon monitor sensor to detect when we get home and open the door.
I also have an automation that detects when my spouse parks her car in the garage about 200 m from home (far from reachable with the beacon).
I heard the announcement that she had parked the car and that also enables the sensor using:
This means her phone now listens for the beacon at home and when her phone sees it another automation will run that will open the door, this automation was triggered at the same time as the previous automation.
I opened the developer tools and had a look at her sensor and managed to get a screenshot of the issue
Here she is at least 200 m away with houses blocking and the sensor reports the state it was in when the sensor was turned off as she left home. Because I turn on and off the sensors since it's not needed and to make sure it does not wrongfully open the door (ironic).
I have managed to replicate the issue that when you enable the sensor and stand close to a beacon, turn it off and move away then turn on again, then the sensor will report the old state for a few seconds before it realizes it's not there.
Because of this bug the sensor and/or the command to turn it on/off is more or less useless.
Traceback (if applicable, to get the logs you may refer to: https://companion.home-assistant.io/docs/troubleshooting/faqs/#android-crash-logs):
Screenshot of problem:
Additional information:
The text was updated successfully, but these errors were encountered: