I have two device_trackers pointing to two Mikrotik Access Points located in two different places (for example, Home and Work).
Through Home Assistant I have made sure that both are controlled through the device_tracker component.
I have some automations that are controlled by the presence or absence of a device in the home.
The same automations are however modified even if the device enters the area covered by the Access Point at “Work”
Is it possible to associate the second Access Point to a particular area and prevent it from interfering with the “Home” automation?
I would like a device state with three different state: home, work, not_home
Is it possible?
Thank you
1 Like
So that’s a bit unclear. Let me see if I understand…
You have two device_tracker entities, one associated with an AP at home, and another with an AP at work. I assume they have two different entity_id’s, e.g., device_tracker.me_at_home and device_tracker.me_at work, is that right? Also, the first goes to the ‘home’ state when you’re at home, and the second goes to the ‘home’ state when you’re at work, is that right? Lastly, neither of these device_trackers have gps location information, is that right?
If I understood correctly, then I would suggest creating a template sensor and using that in your automations. Something like:
sensor:
- platform: template
sensors:
my_loc:
value_template: >
{% if is_state('device_tracker.me_at_home', 'home') %}
home
{% elif is_state('device_tracker.me_at_work', 'home') %}
work
{% else %}
not_home
{% endif %}
Sorry pnbruckner, you’re right.
I try to explain myself in other words
This is my actual config:
configuration.yaml
device_tracker:
- platform: mikrotik
host: !secret mikrotik1_ipaddress
username: !secret mikrotik1_username
password: !secret mikrotik1_password
- platform: mikrotik
host: !secret mikrotik2_ipaddress
username: !secret mikrotik2_username
password: !secret mikrotik2_password
known_devices.yaml
mobile_phone:
hide_if_away: false
mac: AA:BB:CC:DD:EE:FF
name: mobile_phone
track: true
I have an automation with a trigger based on the status of the “mobile_phone”.
When the “mobile_phone” connects and disconnects from the “Home” Access Point, everything runs smoothly.
I do not want that when the “mobile_phone” is connected to the “Work” Access Point the status of “mobile_phone” becomes “home”, but remains “not_home” or changes from “not_home” to “work”.
Sorry, I forgot automation.yaml parts:
- id: '123456789' alias: Switch ON trigger: - entity_id: device_tracker.mobile_phone from: home platform: state to: not_home condition: [] action: - data: entity_id: switch.home_switch service: switch.turn_on - id: '987654321' alias: Switch OFF trigger: - entity_id: device_tracker.mobile_phone from: not_home platform: state to: home condition: [] action: - data: entity_id: switch.home_switch service: switch.turn_off
@Kranzkie this might help you out, the template sensor that @pnbruckner mentioned in post #2 for your setup.
The problem is that the recognition of the device is done via Mac address, and therefore it is identical both at Home and at Work. I can not recognize which AP is connected to.
I can not understand how your solution can be integrated into this scenario.
Yes, given your clarifications, my solution won’t work. Honestly, I don’t know a lot about this type of device_tracker (since I don’t use it), but I’m not sure there is a way to tell which AP your device is connected to and have the corresponding device_tracker entity change state accordingly. Maybe someone else that uses this platform will know.
If you were using different device trackers then the scanner attribute could be used to work out which provided the update. Unfortunately using the same tracker at both locations rules that out.
I think it would be enough to include the IP address as an attribute (the two sites have different networks) or the AP hostname, but I have no idea if this is possible.
I created a Feature Request:
1 Like
Having similar problem. Two locations with respective zones and running VPN between (funny fact mikrtoik too). But unfortunately I can’t use device tracker on secondary location since it will automaticall mark discovered device as “home”. In my mind the problem should be solved on device_tracker side. Basically adding attribute “zone” for each entry in device tracking which should be optional and default to “home”
device_tracker:
- platform: platform_name1
host: !secret mikrotik1_ipaddress
username: !secret mikrotik1_username
password: !secret mikrotik1_password
zone: Home
- platform: platform_name2
host: !secret mikrotik2_ipaddress
username: !secret mikrotik2_username
password: !secret mikrotik2_password
zone: Work
4 Likes
I have similar problem with Openwrt. my solution is to put different network layer on two routers so device_tracker attributes return different result. (i have zerotier to connect 2 routers with Ip 192.168.8.11 and 192.168.8.9) Then we can make a binary sensor to identify zone present.
binary_sensor:
- platform: template
sensors:
ongngoai_in_home:
friendly_name: "Ong ngoai o nha"
value_template: >
{{ states.device_tracker.ngoaiong.attributes.host == '192.168.8.11' }}
Gentlemen, any updates/progress on device tracker states?
My config seems to be similar to @bachulator’s one.
For instance I use two Mikrotik routers at two different locations using the same /24 subnet. IE 192.168.0.1 - 100 is addressable by Mikrotik_1 and 192.168.0.101 - 254 is addressable by Mikrotik_2.
Honestly I won’t like to track devices by IP as then I would need them to hard attach via static DHCP which I highly refrain to do.
There might be a good solution attaching different areas to different zones or so and then I would suggest something like tracking devices based on zone recognition.
1 Like
Having a similar problem here.
I have a router (not a Mikrotik BTW) at home location and at another location I’m tracking as a zone (e.g. ‘the_other_place’). GPS works, But I want the router at another location to assist me in assigning the ‘the_other_place’ zone to devices It sees. As I can see from HA code, any device scanner is hardcoded to return HOME/NOT_HOME. Can’t we make device scanners configurable with the zone name as in @ bachulator’s suggestion?
1 Like
I have the same situation/ I have 4 locations and I would like to see not just ‘home’.
Could you please help me with basic settings HA to device_tracker set value home in second place? The problem is that in first place (zone home) device_tracker change value of person to home. device_tracker of second place see phones (i make already 2 device_tracker in second place) but value home is not set. I’m sure that I make mistake in configuration or I need to add addition settings.
I have multiple access points in my unifi controller. They are spread out over multiple sites. It would be great if I could assign a zone to a tracked device based on which access point it was currently connected to.
In my case, because it’s all one big VPN connected network, each site has its own range of IP addresses. So, it would be easy to consult a table of IP address ranges to determine the current zone for a device.
It has already been suggested that each access point be given a zone attribute. That zone attribute can then be used to update the location of a device. This would work well but not with the unifi controller . The unifi controller, in effect, looks like one big access point even though it is many, possibly geographically diverse, access points.
Instead of a zone, a lat/lon attribute could be added to each access point, then the existing zone lookup could use that if the device doesn’t have a more accurate gps location.
Im just getting started with Home Assistant so please forgive my terminology if I’m not getting it right.
Just to let you know: The architecture discussion above has just been closed: “we have been moving to discussions for these architectural discussions”. On discussions, it says: “In case you are not able to implement your proposal (for whatever reason), a feature request on our forum should be raised instead.”
So, here I am closing the loop. 
Sorry to say that, but I am not expecting this problem to be solved.