Individuall device_tracker.johniosapp is right now showing 13 and device_tracker.sueiosapp is showing 4 but proximity.home is showing 0. Am I referencing something wrong?
Darn, thought you had something but that must have been an extra letter I hit after pasting. Don’t have an “l” in the actual configuration.yaml. Fixed it above.
Ok I’m guessing here because don’t use this integration (might in the future) I think the state you’re referring to indicates the number home which would be zero. I think you have to look at the attribute distance_to_zone to determine the closest (at least that’s the way I read the description. So instead use a value template as in the example below from the online documentation.
automation:
trigger:
platform: numeric_state
entity_id: sensor.temperature
# Optional
value_template: "{{ state.attributes.battery }}"
# At least one of the following required
above: 17
below: 25
# If given, will trigger when condition has been for X time.
for: "01:10:05"
Ok. I put the proximity integration into my system. I needed to define a home zone. Did you define a zone? https://www.home-assistant.io/integrations/zone/ Once you’ve done that a zone entity should appear in the states list. Then your original automation should work I would think. I’m testing it out now.
Ok, final answer. First define a zone as I wrote in the previous note. Second, use person integration as opposed to group integration. With group if any device in the group is home the group is home. Whereas with person if one device is away the person is away. My guess as to why your proximity entity always reported 0 is because one of the devices you linked in your group was at home.
Thanks for the help. So here is what I got and the away works but think it triggers all kinds of errors in the log but return never triggers or if it does is included in all the errors.
configuration.yaml:
proximity:
home:
zone: home
ignored_zones:
- work
- lsp
- Wood
- Costco
devices:
- device_tracker.sueiosapp
- device_tracker.johniosapp
tolerance: 50 #In meters
unit_of_measurement: mi #Used for travel distances
Have a bunch of zones but thinking listing those won’t help but the home one which is the same as the location of HA also in configuration.yaml
everyone:
name: Whole House
entities:
- group.john
- group.sue
john:
name: John
entities:
- device_tracker.johniosapp
- device_tracker.john_s_iphone_unifi
sue:
name: Sue
entities:
- device_tracker.sueiosapp
- device_tracker.sue_s_iphone_unifi
In my automation.yaml I redid some things from what I had before but didn’t change. So the below part sends me a notice but see lots of errors in the logs:
# Turn off ecobee when everyone leaves
- alias: 'Away Mode'
initial_state: 'on'
trigger:
- platform: state
entity_id: group.everyone
to: 'not_home'
action:
- service: notify.ios_johniosapp
data:
message: "No one home"
This part never shows in the logs as triggered or any notices of course for someone on the way home as there are two possible people that could near the home and trigger turning the climate controls back on.
# When no one home and 2 miles away coming back resume preset ecobee
- alias: 'Home Proximity'
initial_state: 'on'
trigger:
- platform: numeric_state
entity_id: proximity.home
below: 2 #in miles
- platform: template
value_template: "{%- if state_attr('proximity.home', 'dir_of_travel') in ['towards', 'arrived'] -%} True {%- else -%} False {%- endif %}"
condition:
- condition: template
value_template: "{%- if state_attr('proximity.home', 'dir_of_travel') in ['towards', 'arrived'] -%} True {%- else -%} Faalse {%- endif %}"
- condition: numeric_state
entity_id: proximity.home
below: 2
action:
- service: notify.ios_johniosapp
data:
message: "someone 2 miles away inbound"
You need to create separate proximity sensors for each device tracker and then list both in the trigger for your automation. How can it show one proximity for two different people if they are in different places?
@micque Yeah I guess you’re right, I just looked at the docs again.
I use separate proximity sensors for me and my wife. Works great. Definitely seems more logical than putting multiple people’s trackers in one to me. I can always tell how far each of us is from home - not just who is closest.
I will say that if he’s trying to debug it then getting it to work with just one tracker and one zone before adding others probably isn’t a bad idea.
Holy crap!!! And yes micque is correct you can have both just shows the closest one as stated. So the holy crap is a couple things:
It triggered as expected this time both directions.
I figured out the problem. On my proximity.home I had device_tracker.johniosapp. Do not ask me why but apparently in HA it was tracker.johniosap with one p. I fixed it to two p’s and now it’s working. Seems with one of the trackers not being valid it didn’t work at all. What a pain.
So the on my way home logic I like better I think than my old one which was more efficiently coded but didn’t take in mind if the phone doesn’t trigger while I’m “toward” home so if I happen to “arrive” then it will still trigger.
Open to any advice on the code logic also but any thoughts on when leaving? Should I be doing something with distance as well as devices not seeing me in the house anymore? Right now when I leave if no phones are on the Wi-Fi and both phones are “not_home” it says I’m away.
And last, now how much of what I did is still needed. The groups, the proximity zone info or ignored_zones info, etc.
Well that was a little odd. So I enabled everything and triggered and worked. Went out today and when the house was empty ecobee was set to away. But oddly when I was at the location, both John and Sue’s proximity showed 4 mi and the home one showed Not Set.
Yet you can see above it seemed to be tracking until 2 miles away which has no relevance on my leaving only my returning but then showed no devices as part of it’s tracking.
In the logs when i got home I saw:
2019-11-16 13:10:40 WARNING (MainThread) [homeassistant.helpers.condition] Value cannot be processed as a number: <state proximity.home=not set; dir_of_travel=not set, nearest=not set, unit_of_measurement=mi, friendly_name=home @ 2019-11-16T13:10:40.341237-06:00> (Offending entity: not set)
Should be noted that at some point it did trigger the return and turned the ecobee back into my standard running mode. Never saw it go not set before while in motion. Only after a reboot.
That said, can you give an example of how my automation should be done with persons based on what I posted above for my current setup? Open to any recommendations.
With regards to your arriving home automations - are you using any other presence detection besides your proximity sensor? I’d probably stick with Bluetooth presence detection for arriving/leaving home events. It’s a more reliable and a heck of a lot faster than waiting for a GPS location update to happen.
Edit: I see you are using WIFI. That works too. I think bluetooth is faster on the draw coming and going though.
The only proximity automation I have triggers the HVAC to home mode when either myself or my wife is almost home and the other person isn’t already home. As I mentioned before I chose to go with a separate proximity sensor for each of us so mine will look a little different than yours.
When you’re setting up a new component you aren’t familiar with start with the basics then build it up from there. Start with one tracker and one simple automation. When you’ve got that working reliably start adding your other trackers and conditions. Makes issues a whole lot easier to diagnose.
Here are my trigger and conditions for my HVAC proximity automation. FWIW it’s been very reliable. I use Google Location for tracking.
Thanks Jason. I’ll take a look at your setup and adjust accordingly. I do add the Wi-Fi in to make sure if home, however as you mentioned with you, using it to control the HVAC so the intent is to make sure people don’t walk into a cold house in the winter. Wi-Fi will just be a last ditch they are home dummy adjust the controls thing. Then of course the family says this stinks just leave it running.
That said, got up this morning and my proximity sensor for just myself said Not Set today. Didn’t leave the house. I saw this multiple times in the log, not sure if related.
2019-11-16 18:43:24 ERROR (MainThread) [homeassistant.components.websocket_api.http.connection.140072827834768] unsupported operand type(s) for &: 'NoneType' and 'int'
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/components/websocket_api/commands.py", line 133, in handle_call_service
connection.context(msg),
File "/usr/src/homeassistant/homeassistant/core.py", line 1236, in async_call
await asyncio.shield(self._execute_service(handler, service_call))
File "/usr/src/homeassistant/homeassistant/core.py", line 1261, in _execute_service
await handler.func(service_call)
File "/usr/src/homeassistant/homeassistant/helpers/entity_component.py", line 213, in handle_service
self._platforms.values(), func, call, service_name, required_features
File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 348, in entity_service_call
future.result() # pop exception if have
File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 363, in _handle_service_platform_call
entity.supported_features & feature_set for feature_set in required_features
File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 363, in <genexpr>
entity.supported_features & feature_set for feature_set in required_features
TypeError: unsupported operand type(s) for &: 'NoneType' and 'int'
When you’re looking at an error in the log the first and/or last line usually tells you what’s going on. In this case yes I think the proximity sensor was saying hey I need an integer to work and you gave me a NoneType (which I think means it get fed a blank value).
It looks like your device tracker is losing it lat / long attributes for some reason. I’m not familiar with the iOS app device tracking. I’d say try using the ignored_zones: parameter of the proximity sensor if you were only dropping out at home but you said it happened when you were out yesterday also.
Long story short - it’s probably your device tracker that has the issue, not your proximity sensor. Try turning your phone right off for a bit and see what your device tracker does. Or try googling iOS device tracking in HA and see if anyone else experiences similar issues with the it.
Edit. I just looked at the automation you posted previously. Is it still the same? Why do you have the same parameters in your condition as your trigger? What are you trying to do there? The condition looks totally redundant, I think you can probably drop it (False is also spelled incorrectly but that shouldn’t impact how it evaluates - it’s really just looking for “true)”. If you have your WIFI set up to turn on your HVAC then you can probably also drop the ‘arriving’ bit in the trigger. I think you’re unnecessarily complicating this. Your WIFI is going to be more reliable for this than your GPS tracker. If you’re looking for redundancy in case the WIFI doesn’t connect I would double up with a bluetooth tracker for that.
I also looked at the error a little closer. “unsupported operand type(s) for &” Something like this usually indicates that you’re trying to add a number and a blank value which means you probably need to pipe the result of an expression somewhere to an integer value. I’m not sure if the proximity sensor throws this error or if you’ve got another unrelated expression somewhere that needs a little fix. Do you have any automations or scripts where you’re adding values together?
No, nothing other than what I shared. The reason for the proximity over the Wi-Fi is I do not want to wait until someone is home before the heat in the winter kicks back up again. Idea is to have the house start warming again when it determines someone is on their way back.
Edit: note was interesting. I was sitting watching TV today and house was getting cold. Noticed it was in away mode somehow and everyone was here.
I’m not suggesting you abandon the proximity trigger for when you’re travelling towards home. Just the arriving home part of it. Having it turn on when you’re on the way home is just plain common sense.
{%- if state_attr('proximity.home', 'dir_of_travel') in ['towards', 'arrived'] -%} True {%- else -%} False {%- endif %}
This way It will still fire when you’re within the specified distance going towards home. But if it doesn’t trigger for some reason when you get home HA can detect the WIFI connection and use that to turn the furnace on. Immediately.
GPS can be unreliable and slow sometimes. You don’t want to have to wait for your GPS to update to turn the furnace on when you arrive home if the proximity didn’t turn it on when you were going towards home for some reason. There is a good chance it won’t turn on when you arrive home either if your GPS isn’t reporting for some reason.
Having them both watching for you to arrive home is redundant except in the very unlikely scenario that your WIFI is down and your GPS is not. Even then I’d be willing to bet you’ll have walked over to the thermostat and turned it on before the proximity/gps tracker ever reports you being home.
Even if you don’t want to use WIFI at all it would just be simpler to check for your device tracker state to be home instead of using the proximity sensor. I can’t think of any reason why you’d want to use the proximity sensor.for your arriving home trigger. You’re just putting an unnecessary layer between what’s going on and what you want to do. More layers = more problems!
This is what that might look like (using WIFI tracker to detect at home state). Just replace the device trackers if you want to use the GPS tracker to detect at home state.
- alias: 'Turn The Furnace On'
initial_state: 'on'
trigger:
- platform: numeric_state
entity_id: proximity.home
below: 2 #in miles
- platform: state
entity_id:
- device_tracker.john_s_iphone_unifi
- device_tracker.sue_s_iphone_unifi
to: 'home'
condition:
- condition: template
value_template: >
{% if trigger.entity_id == 'proximity.home' %}
{{ is_state_attr('proximity.home', 'dir_of_travel', 'towards' ) }}
{% else %}
true
{% endif %}
action:
- # turn your furnace on here
@jriker1 BTW on a related topic, I don’t know if you’ve looked at the Person integration yet. It can combine multiple device trackers into one (in my case Bluetooth, Ping, and GPS) which is great however there is a problem using the person component for the proximity sensor because it drops the lat / long attributes if Bluetooth or WIFI has reported last (why I have no idea but there is probably a reason). As you discovered if the lat / long attributes are missing you get an error.
To make up for that the composite device tracker component by @pnbruckner is very useful in that you can combine all those device trackers into one tracker, but it actually keeps the lat / long of the last GPS report. This means it never loses those attributes so it can be used reliably with the proximity sensor. It also means you are always using ALL the included trackers to determine presence / location so the first one to report changes the state!
I don’t reference any of my other trackers in any of my automations - I only use composite tracker to test for location / presence wherever I need it. It works flawlessly for me.
If you want to check it out here’s the git and you can add the git to HACS as a custom repository if want to use HACS to install it.
