tomaae / homeassistant-mikrotik_router

Mikrotik router integration for Home Assistant
Apache License 2.0
302 stars 51 forks source link

[Question] Device (iOS) tracker inaccurate in comparison with other custom integration + possibility to choose which device should be tracked #324

Closed ronnieSVK closed 9 months ago

ronnieSVK commented 10 months ago

Dear Developer !

First of all, let me thank for this fantastic custom component ! As a long and heavy MikroTik user im really glad to have such complex informations, sensor, KidControl in HA ! I would like to kindly ask you to take a look to my questions and issues related to "device_tracker" :

QUESTION 1 : device tracker & Apple devices = My first issue is with iOS devices. Even after loooooooooong researching and "playing" with RouterOS settings, im unable to correctly track some of our iOS devices. We have in our apartment 6 WiFi connected iOS devices. 4 older ones are tracked correctly, the remaining two (iPhone 13 + 15) are sometimes considered as "Away", even if the device is at home. This happens mostly during night (devices unused, considered away for hours!), but the mentioned status appears sometime also during day for couple of minutes (2minutes away, then home etc..). My opinion is, that this issue is something related to Apples "deep sleep - batterry saving" state. "Anger" between MikroTik + Apple is well known, but without "device_tracker" would be those states not visible for us as consumers. I can play with RouterOS WiFi settings and your component settings, but i never get 100% result. This causes issues during presence automation, since you cannot relay on their function. Two interesting findings: Android based (Samsung Galaxy) phone works with ROS WiFi default advanced settings absolutely great and stable without any hesitation ; Yesterday found custom component "iphonedetect" https://github.com/mudape/iphonedetect seems to be working with mentioned two devices ! Since iphonedetect was tested only 24h, i would like to wait some time to say "it is working" , but it looks really good. I would like to kindly ask you, if you have such issue-bug-question reported so far, if you have some sort of solution for this, and if is possible to somehow compare the "device_tracker" option/solution/method used in your _Mikrotik customcomponent and _iphonedetect customcomponent

QUESTION 2 : possibility to choose which device should be tracked and listed in HA as entity The second question is also related to "device_tracker". Im familiar with HA integrated device tracker component, track_new_devices, know_devices options. But since all this configurations are nicely and easily done in your custom component with a click to "Track Network Devices" im unable to filter them and have HA flooded with all my network devices (cca 70 entities from which i would like to track maybe 10). Even if i remove the devices from your integration, the appear again after restart. They are also visible even if the are disabled (maybe this will sort the "Visible tab" in HA) during automations writing, device-state options and entities list. Also if i try to cover those devices and disable them somehow from "HA", every newly connected device appears again in this list. It would be great (if its already not possible) to somehow select only the desired tracked devices, and have only them reported to HA as entities. So the opposite solution as its now used : instead of reporting/creating entity to every actual+new device automatically -> making this only for selected devices without chaging/touching this selection even if new on network appears.

Thank you very much for your work, time for reading this and feedback !

Best wishes Ronnie

tomaae commented 10 months ago

Best would be to check if mikrotik is actually reacting correctly to device. check if it disappears from wireless list in mikrotik itself. if it does not, we can have a look what the issue is.

you can disable entities that do not require tracking in HA. from integration side, there is no easy way to pick and choose.

github-actions[bot] commented 9 months ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

github-actions[bot] commented 9 months ago

This issue was closed because it has been stalled for 5 days with no activity.