Double trigger? home, not_home

Configuration Z-Wave
39

ok, for my settings that wont be the case i fear, since the zones are wide apart, and a state not_home will always be in between.

That being said, im still looking for a way to stop especially this automation from triggering after each reconnect. {{trigger.to_state.state != trigger.from_state.state}} doesnt prevent that obviously, and i think it is because of the same reason. The device goes into not_home state and then the template passes…

I think i might use the gps coordinates here. Since they wont change, even in not_home, when on the same location …

{{trigger.to_state.attributes.longitude != trigger.from_state.attributes.longitude and {{trigger.to_state.attributes.latitude != trigger.from_state.attributes.latitude }}

or could I do that in a better way?

this would then be the full conditional section:

condition:
  - condition: template
    value_template: >
      {{ trigger.to_state.state is not none and
         trigger.from_state.state is not none and
         trigger.to_state.state != trigger.from_state.state }}
  - condition: template
    value_template: >
      {{trigger.to_state.attributes.longitude != 
        trigger.from_state.attributes.longitude and 
        trigger.to_state.attributes.latitude != 
        trigger.from_state.attributes.latitude }}
  - condition: template
    value_template: >
      {% set zones = states.zone | map(attribute='entity_id')|list %}
      {{trigger.to_state.state in ['home','not_home'] or
        trigger.from_state.state in ['home','not_home'] or
        trigger.to_state.state in zones or 
        trigger.from_state.state in zones}}
40

What device trackers are you using now? If you’re having a lot of false positives, you should look at adding another tracker in a group or move to one that’s more reliable.

41

yes thx, I do use that in other places.

The thing is, the iOS devices have certain properties that provide options as direction and gps location which make it possible to use the zones.
For that I need to be able to separate those individually, because using a group would forfeit all that. (btw, one of these phones is my spouses, and she switches the network off all the time, so the iCloud connection is all there is :wink: )

unfortunately those devices also have the property to be switching on/off all the time… the only thing remaining the same between not_home and other zones, when in fact staying in the same place, are their gps coordinates…

So it’s not that the iOS devices are unreliable in them selves (though some of the attributes are horribly unsynchronized ), they have certain properties I think I simply need to be able to have this zone notification .

For the non iCloud devices the automation works just fine now (albeit without the zones since they’re only using home and not_home, it’s only this bit that needs finetuning…

42

Understood. I guess my point is that you’re fixing the wrong problem. You should concentrate on making presence more reliable rather than the notification automation. There are a bunch of threads on the forum about various methods to improve the accuracy of presence data.

For example, here’s an automation that I created recently to combine multiple device trackers. I use Google and Life360 for GPS based tracking and I combine that with ping and bluetooth just for at home detection.

device_tracker:
  - platform: mqtt_json
    devices:
      person1_presence: location/person1

automations:
  - alias: Person1 Presence Update from GPS
    trigger:
    - platform: state
      entity_id:
        - device_tracker.person1_google
        - device_tracker.person1_life360
    action:
      - service: mqtt.publish
        data_template:
          topic: "location/person1"
          retain: true
          payload: >-
            {
              "latitude": "{{ trigger.to_state.attributes.latitude }}",
              "longitude": "{{ trigger.to_state.attributes.longitude }}",
              "gps_accuracy": {{ trigger.to_state.attributes.gps_accuracy | int }}
            }

  - alias: Person1 Presence Update from Router or Bluetooth
    trigger:
    - platform: state
      entity_id:
        - device_tracker.person1_ping
        - device_tracker.person1_bt
      to: home
    action:
      - service: mqtt.publish
        data_template:
          topic: "location/person1"
          retain: true
          payload: >-
            {
              "latitude": "{{ states.zone.home.attributes.latitude }}",
              "longitude": "{{ states.zone.home.attributes.longitude }}",
              "gps_accuracy": 0
            }
43

o thats mighty interesting! Creating your own device are you here?

have to digest this. can one build the proximity and directions on this too?

Am I correct in understanding the device_tracker.person1 is the device you can use for all the further automations and notifications?

360 is a dedicated service , but what do you use for the google device_tracker?

aded to that, can I use the own tracks too in the GPS automation? and, which ip address to ping, do you have that set manually?

44

Yes, There is a separate device tracker that’s just managed by the automations.

Yes, that’s the device I’m using for notifications now.

Life360 is a free service. There is a custom component for it at Life360 Device Tracker Platform. For Google, I’m using Google Maps location sharing, but I need to switch over to the official component when I get a chance.

Sure.

I have a DHCP reservation for my phone’s MAC, so I just ping the reserved IP. You can use nmap instead if you prefer that one.

45

This is very cool but I only use one GPS based tracker (Owntracks) a the moment so I don’t think it would actually bring any benefits to me just now (correct?) - but it has been filed away for later!

As for Ping, do you find it reliable? We have two android phones and they both seem to go to sleep and appear as ‘Away’ after a few minutes. I have read that this affects iPhones and can be resolved with consider_home but seen nothing to suggest it affects Android. Once they drop off it seems the only way to make them reappear is to turn the phone on so I am not sure even consider_home would work in this case.

46

Personally, I found owntracks unreliable and I prefer not to expose my Home Assistant to the internet. I’ve noticed that using 2 GPS based trackers bumps up both accuracy and responsiveness of presence.

For Android devices, if the ping tracker says the device is home, it’s guaranteed to be home regardless what GPS says. If ping says its not home, that can’t be trusted with much confidence… Thats why I only use ping for at home detection and ignore not_home.

47

Owntracks - I find it surprisingly reliable and I use an MQTT bridge to CloudMQTT so whilst in theory my location could be seen by others (with nothing to really identify it as me) my HA isn’t exposed to the Internet.

Ping - Yes, I was really just looking for some confirmation that I hadn’t missed something.

Life360 - I’ve been toying with this for a while but am averse to giving my details to yet another ‘cloud’. Given you caution with HA / Internet exposure I imagine you’ve considered this angle too and decided it is ‘ok’? Maybe I’ll give it a go - two GPS trackers will always be better than one!

And thanks for the reply, very helpful all round.

48

I did the same thing for a while and even had it bridged with my local Mosquitto instance. Configuring Owntracks on each device was a hassle.

Yeah, it’s another cloud service, but so is CloudMQTT. In the end, Life360 and Google were both more reliable, so I retired Owntracks.

49

i wouldn’t know why to prefer the one or the other? Using device_tracker ping to reasonable satisfaction. Why would Nmap be ‘better’?

this device_tracker created by mqtt, could be read on another HA instance ? I have been wanting to try and test that architecture for a longer while.
How could I do that please?
I’ve already set up mqtt on the second system to the mosquito broker on the first (on which this newly mqtt device_tracker is created).

50

There isn’t a significant difference between them. Ping is a bit more work to setup because you have to setup a DHCP reservation.

Sure. I actually do that for bluetooth tracking. All you have to do is setup the mqtt_json device tracker on the Home Assistant instance that you want to see the tracker on.

51

With ping it uses the IP address of the device (obviously), and if you’ve not configured a static DHCP lease, for every device you want to track, that’ll fail. Nmap however uses the MAC address, which is fixed, and if the IP of the device changes it still knows what it is.

52

Thanks! Ive never realized that… always used Nmap with up adresses… that really makes a difference indeed.
Rewriting the device trackers per now!
Cool.

hmmm, not sure how… reading https://www.home-assistant.io/components/device_tracker.nmap_tracker/ there’s nothing on mac-addresses.

can I do it like this:

- platform: nmap_tracker
  interval_seconds: 30
  consider_home: 60
  track_new_devices: no
  scan_options: " --privileged -n -sn " #not sure what this is for, but its been there for ages....
  hosts:
    - 192.168.1.1/24
    - mac-address phone 1
    - mac-address phone 2
    - etc
  exclude:
    - 192.168.1.57 # hassio
    - 192.168.1.99 # ikea tradfri
    - 192.168.1.212 # philips hue
53

You give nmap an IP range, and it scans every IP in that range. It doesn’t remember the IP addresses though, just the MAC addresses, as you’ll see in known_devices.yaml.

54

a ok. thx.
for now it only finds the wifi adapter of the router…should one exclude the router itself too? 192.168.1.1 in my case?

also, I think I had issues before with the asuswrt component combined with Nmap. Can Nmap be set only to scan for these phones and excused everything else? Now it is configured the other way round, scan all, with several excludes.

55

No need to exclude that - you did configure nmap to scan 192.168.1.0/24?

And no, you can’t exclude a few, you have to scan a range of IP addresses. You can configure the device tracker component to not track new devices by default.

56

actually i set 192.168.1.1/24 since my router is on that address and starts creating addresses upwards from there.
It didnt find any mac adresses for the phones, or any other device for that matter. Only the 2.5 wifi mac address.
It did start conflicting with Asuswrt again and causing significant lag…

57

If you already have the Asus one working, just use that one instead of nmap.

58

testing this setup, brings back memories… a device switching to on/off frequently, but remaining in position and hence the same gps coordinates.
Since this mqtt_json device_tracker reads those coordinates, I would have hoped the device to show the location of those set zones. Still it doesn’t, and shows Home/Away, when the device it is based on loses connection… Even when the gps coordinates remain steady and fixed on the same location (which they should since the device hasn’t moved, only lost connection and reconnected) And, are reflected in the state of this new device_tracker.

what is pleasantly surprising though is that the only thing that does show the correct position is the Map. So we can be sure that somewhere in the innards of HomeAssistant, these gps coordinates are treated correctly.