-
-
Notifications
You must be signed in to change notification settings - Fork 49
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
[Bug] device_tracker only added when Integration is reloaded #315
Comments
If you have multiple AP on same network, you will get tracker per each, no way going around it as they are different devices and cannot affect each other on HA level. Are you waiting long enough for integration to get data when adding new device? |
I can live with one device_tracker per AP per device as long as that works reliably and doesnt change entity_ids. Well this morning I brought my mobile down to the basement, disable / enabled wifi and let it sit there. I have a rescan intervall of 30 Seconds and devices are considered timeout after 180 seconds. So 10 Minutes should have been plenty of time. I got you a debug logging, just quick and dirty from right now. Tracing started at 14:56 (all times on the full minute) See attached I looked through the log file and noticed two things (not sure if they are relevant):
But after doing some further API Queries it finaly says Hope this helps! |
any news? |
I took the liberty and looked at the code with my limitied coding skills and developed a theory on what goes wrong: The AP reports the Device with its MAC Address.... This MAC Address is allways the same. from device_tracker.py @line 56
Just a theory.. not sure if I am correct. |
ok Scratch that... I added some further Debug Output to the function and I only see it beeing executed on reload. So it seems on a normal refresh that funtion is not even executed!? |
that part of code is there register entities and avoid duplicates. its part of startup process. This is a tough one, specially since we cannot pair devices using debug. We will most likely have to remove masking and redo debugs again. We need to identify the device in wireless registration table and track it down to ping. Specially to make sure IP address is being correctly updated for that device. If you are willing to do that, you can remove IP and MAC related entries inside of TO_REDACT hash in const.py file. That should be first 11 entries. |
I am not sure I am getting what you are suggesting. The repro is dead simple and even works with a single Mikrotik AP:
So in essence new device_trackers are only added when the integration is reloaded while at the same time the device is connected to this specific AP. I think solving the first issue would also solve the second. On the other hand... |
Is there any ETA on this? I could also live with an automated way to reload the integration from HA, but despite many people asking for it, I could not find a way to achive this. |
Describe the issue
When a device, lets say my mobile phone, is connecting to another AP no device_tracker is added.
The existing device_tracker turns to "not_home." When the Integration for that AP is reloaded while the phone is connected to another AP, it turns to "unavailable".
Only when I reload the Integration for the AP the phone is now connected with, a second device_tracker will be added.
When the device reverts back to the first AP, the device_tracker of the second AP will show not_home and the first still "unavailable".
With a second reload of the integration, the first AP then shows the presence of the phone.
But I if reload the intergatrion for the second AP then that one goes to "unavailable".
Is it even neccessary, sensible to create multiple device_trackers for the same device?
How to reproduce the issue
Get two Mikrotik APs that provide the same WLAN and roam between them.
Expected behavior
Devices registering with an AP should get a device_tracker and the device_tracker should get updated, without reloading the Integration.
Screenshots
see above
Software versions
Home Assistant 2023.10.0
Supervisor 2023.10.0
Operating System 10.5
Frontend 20231002.0 - latest
Mikrotik Router integration version: v.2.1.4
RouterOS version: both Routers in this test run v6.49.7 (stable) but I have a 3rd AP running v7.6 that is also affected.
Diagnostics data
Could not find anything in the logs that seems to be related.
Traceback/Error logs
see above
Additional context
This has worked at some point in the past, as I did not have to connect my phone (or other devices) to a certain AP (by switching of the other APs) and then reload the integration in order to get all 3 possible device_trackers into my config, when I originally set up the integration. This must have been prior to v.2.1.3.
However I cannot say, when this stopped working.
Originally the device trackers were showing as device_tracker.name_of_the_device. And the second and third as device_tracker.name_of_the_device_2 and device_tracker.name_of_the_device_3 respectively.
Since the Upgrade of the Mikrotik Integration to Version 2.1.3 device_trackers now show as device_tracker.MAC_Address.
This broke all my automations concerned about device trackers and I had to reconfigure everything with the new entity_ids.
For that it seems I am not the only one: #301
But in my Case its a bunch of Shelly Devices and my Android OS mobile Phone with the Companion App that was affected.
In essence the current state would mean, that I have to bring all possible devices into my network. Switch off 2 of the APs, reload the Integration for the 3rd one, then switch that off and the next one on and repeat the same there.
Generally I am wondering if multiple device_trackers for the same device provided by multiple APs are neccessary.
From a (laymans) logic perspective a single device_tracker per device and than an information in the Attribute which AP reported the Status would be good.
Please let me know if anything is unclear or further information required.
The text was updated successfully, but these errors were encountered: