I have set up the Unifi WAP presence tracker and it is happily detecting my device’s location when I am home/not home.
From the documentation, I read that:
The Unifi controller returns a number of additional attributes that can be used for tracking devices, including signal strength, rx/tx rates, and which AP it is connected to.
I have an outbuilding with its own AP and Sonoff controlled lights. I would absolutely love to be able to create an automation for switching these lights on when my device connects to this specific AP, but I am failing at finding any examples on how to do this. Would anyone be able to point me in the right direction?
I have defined a separate zone for the outbuilding, but not entirely sure if this is the right way to go about things.
So I think router type trackers are either ‘home’ (if connected) or ‘not_home’ (if not connected for a period of time.) If they provide GPS coordinates then they’re just using the coordinates of your HA instance. Which means, I think, when you device connects to the AP in the outbuilding it will ‘home’, just like when it connects to an AP (presumably) in your house.
But if one of the device_tracker attributes can distinguish which AP the device is connected to, then you can use that to trigger an automation to turn on the lights. I don’t have one of these so I’m just guessing here, but you should be able to use something like this, adjusted to the specifics of your scenario:
automation:
- alias: Turn on outbuilding lights
trigger:
platform: template
value_template: >
{{ state_attr('DEV_TRK_ENTITY_ID', 'AP_ATTR') == 'OUT_AP' }}
condition:
condition: template
value_template: >
{{ trigger.from_state is none or
trigger.from_state.attributes.AP_ATTR != 'OUT_AP' }}
action:
# Appropriate service and data to turn on light
Thank you very much @pnbruckner, this worked perfectly.
In addition to the default Unifi WAP configuration, I had to add to the device_tracker section in configuration.yaml:
monitored_conditions:
- ap_mac
And of course, I then found from the Unifi controller the MAC address associated to the outbuilding AP. I didn’t spot any easy AP name attributes I could have used, but getting the MAC was easy enough (00:00:00:00:00:00 in my examples).
In automations.yaml I added your lovely example:
- alias: 'Outbuilding lights'
trigger:
platform: template
value_template: >
{{ state_attr('device_tracker.my_phone', 'ap_mac') == '00:00:00:00:00:00' }}
condition:
condition: template
value_template: >
{{ trigger.from_state is none or
trigger.from_state.attributes.ap_mac != '00:00:00:00:00:00' }}
action:
# Appropriate service and data to turn on light
service: homeassistant.turn_on
entity_id: light.outbuilding_lights
And now when I walk down on a cold night, the lights magically spring into life when I get into range. Glorious thanks very much for your help!
I recently learned more about how template triggers work. Basically, once the template becomes true and the trigger “fires”, it won’t fire again until the template becomes false, and then true again. So that means you shouldn’t need the condition (which was just testing if the previous state would have rendered the template false.)
To make that clear, this should also work:
- alias: 'Outbuilding lights'
trigger:
platform: template
value_template: >
{{ state_attr('device_tracker.my_phone', 'ap_mac') == '00:00:00:00:00:00' }}
action:
# Appropriate service and data to turn on light
service: light.turn_on
entity_id: light.outbuilding_lights
You may also notice I changed homeassistant.turn_on to light.turn_on. When the entity is in the light domain, then the light.turn_on service is more efficient than the homeassisant.turn_on service (because the latter just has to turn around and call the former.)
@pnbruckner@Jagmills
I am trying to achieve the same, but does not work for me, if I manually trigger the script than it work, but then also it is not able to differentiate between different APs, like if my phone get’s connected to the wifi and I trigger manually the automation script then irrespective of what AP it is connected to it fires the light on.
Here is my configuration.yaml:
# Configure a default setup of Home Assistant (frontend, api, etc)
default_config:
# Uncomment this if you are using SSL/TLS, running in Docker container, etc.
# http:
# base_url: example.duckdns.org:8123
# Text to speech
tts:
- platform: google_translate
group: !include groups.yaml
automation: !include automations.yaml
script: !include scripts.yaml
device_tracker:
- platform: unifi
host: 192.168.168.67
port: 8443
username: !secret unifi_user
password: !secret unifi_pw
site_id: default
#verify_ssl: false
interval_seconds: 60
detection_time: 120
#consider_home: 180
new_device_defaults:
track_new_devices: false
hide_if_away: false
monitored_conditions:
- ap_mac
Here is my automation.yaml:
- alias: 'Outbuilding lights'
trigger:
platform: template
value_template: >
{{ state_attr('device_tracker.adams_ipad_2_2', 'ap_mac') == '74:83:c2:2c:fc:99' }}
condition:
condition: template
value_template: >
{{ trigger.from_state is none or
trigger.from_state.attributes.ap_mac != '74:83:c2:2c:fc:99' }}
action:
# Appropriate service and data to turn on light
service: light.turn_on
entity_id: light.nanoleaf_light_panels_55_59_24
I am new to hass.io. Thanks in advance for your help.
First, as mentioned in my last post, you don’t need the condition. So:
- alias: 'Outbuilding lights'
trigger:
platform: template
value_template: >
{{ state_attr('device_tracker.adams_ipad_2_2', 'ap_mac') == '74:83:c2:2c:fc:99' }}
action:
# Appropriate service and data to turn on light
service: light.turn_on
entity_id: light.nanoleaf_light_panels_55_59_24
Next, is the automation turned on?
Lastly, are the values correct? I.e., is that the right entity_id? Does it have an attribute named ap_mac? Is this attribute’s value the MAC address you’re using in the automation when you want it to fire?
I came to know it's not exposing ap_mac anymore,`` today received the hass update as well,`` but I still cannot see the ap_mac of my access point there.`` I am not sure how to go forward with this now.
jumping on the old topic, but this one seems most relevant to what I’m looking for.
My goal here is to use “ap mac” attribute from Unifi to be able to distinguish to which AP which device is connected and then show this on the presence tab in HA. I have few APs inside different buildings around so simple “Home/Not Home” is not enough
Hey, I also have two unifi APs in my flat, so I use the controller in a docker in the server and in mid 2019 it was possible to use RSSI values to try to determine which room AP my phone was connected, but i’m not sure if the integration still expose rssi and to simplify things I moved to connected MAC like this
Please note that it needs two input booleans to track if I’m in a room or not and a input select to choose which location I’m in.
BTW when I start driving I also update this input select to state that I’m driving and when I’m at the office it also updates (all done via Tasker).
I use the unifi integration and thus do not have the device_tracker block for unifi in my configuration.yaml. Is there a way to track ap_mac without the additional?:
Hello, I would like to accomplish a similar scenario: when my iPhone connects to a specific wireless access point, then execute an action. I have the Unifi Network integration installed. Below is what I’ve written into my automations.yaml file (a few personal things redacted, and with a temporary action to test).
- id: '1693390441234'
alias: Notification Test
description: ''
trigger:
- platform: template
value_template: >
{{ state_attr('device_tracker.myiphone', 'ap_mac') == '70:a7:41:bd:12:34' }}
condition: []
action:
- service: notify.mobile_app_myiphone
data:
title: You have a Warning
message: This is a notification from HA
mode: single
Is that sufficient, and is the syntax correct? Is there anything else that needs to be installed or written (anything related to that template)? Needless to say, right now nothing happens when I approach that particular access point
When you post YAML code, please make sure it’s formatted correctly. There’s no way to tell if the indentation is correct, etc., and it’s just difficult to read otherwise.