Current State of presence detection

I am having the same problem as mentioned above, unreliable presence detection when ‘home’.

  • (2) Apple iOS devices
  • Ubuntu VM with HA
  • 802.11ac wireless network
  • Gigabit Ethernet LAN

I have owntracks setup and it works perfect remote.

The problem is that when I am home owntracks can’t update because I am on the wireless network. So I am falling back on nmap. Because iOS tends to go to sleep I have set what I believe are overly conservative configuration.

- platform: owntracks
  max_gps_accuracy: 200
  waypoints: True
- platform: nmap_tracker
  hosts: 192.168.XXX.100-125
  home_interval: 5
  consider_home: 900
  track_new_devices: no

That should ignore devices 5 minutes after detecting them and consider them home for 15 minutes. My logic here being that the amount of time considered home is irrelevant because once it gets an update from owntracks the last device tracker to update gets priority.

The problem is that nmap is still showing inconsistent ‘home/not home’ results. Is there a debug method for nmap to determine what/why it is considered someone ‘not home’? Or conversely to simply see the device_tracker updates to see if my wifi devices are connecting via LTE and updating owntracks? They shouldn’t because the owntracks is using iBeacons to determine ‘home’.

The home_interval/consider_home logic has kind of confused me.

What I think I want is check as often as you like, but consider it home for 900 seconds from the last successful nmap search for the device.
So assuming a scan every minute.
So minute 1: device is found (I’m Home)
Till minute 10: device still found (I’m Still Home)
Minute 10 : Device not found (but I’m still home because it hasn’t been 900 seconds since last successful attempt.)
Minute 13: Device found (I’m still home)
Minute 19: device found (I’m still home)
Minute 20: device not found( because I physically left home) (but I’m still showing home because it hasn’t been 900 Seconds since last successful scan)
Minute 35: device still not found (it’s been over 900 seconds so now I’m shown as not home).

So here is my config for nmap.

  - platform: nmap_tracker
    hosts: -Pn 192.168.1.1-16  
    home_interval: 1

Using that I never see one of my devices go home/not_home when they shouldn’t in the log book. That, combined with the multiple triggers and conditions I described above has resulted in pretty reliable automations based on home/away status.

1 Like

With the Pn option it doesn’t surprise me.

-Pn: Treat all hosts as online – skip host discovery

It works reliably for me. I have my HA devices locked down to those reserved IPs so I can have nmap survey a narrow range of IPs.

Also helps in locking down what is discovered in HA and eliminates a bunch of noise in the device_trackers as guests connect or I bring home a work computer ect. Track what you want to track, ignore the rest.

I have set up my presence detection using multiple trackers as per https://community.home-assistant.io/t/presence-detection-with-multiple-devices-multiple-trackers/4335 and it works reliably(so far).
I have

  • NMAP to track my phones

  • Bluetooth/BLE tracker running on a different PI3 and reporting back to HA trough appdaemon

  • Owntracks(Misses occasionally)

  • GPS Logger(works great)

  • Locative(Misses occasionally)

All this tied up together with an input boolean

2 Likes

I guess the problem is more with false negatives (away from home when someone is home), than with false positives (thinking someone is home when they aren’t). So do you just compare the responses from each of these and if one of them says you are home, then you’re home??

Wait 5 minutes before setting the state away, set hoe as soon as any tracker is detected.
I found the ble tracker using PI3 and the gpsloger are the most reliable

    - alias: 'Set Anil Away'
  condition:
    condition: and
    conditions:
      - condition: state
        entity_id: input_boolean.anilhome
        state: 'on'
      - condition: state
        entity_id: device_tracker.pixel_bt #bluetooth
        state: 'not_home'
      - condition: state
        entity_id: device_tracker.ac37434ce86a #nmap
        state: 'not_home'
      - condition: or
        conditions:
        - condition: state
          entity_id: device_tracker.anils6_pixel #owntracks
          state: 'not_home'
        - condition: state
          entity_id: device_tracker.anils6_pixel
          state: 'away'
        - condition: state
          entity_id: device_tracker.anils6_pixel
          state: 'Work'

  trigger:
    - platform: state
      entity_id: device_tracker.pixel_bt
      state: 'not_home'
      for:
        minutes: 5
    - platform: state
      entity_id: device_tracker.anils6_pixel
      state: 'not_home'
      for:
        minutes: 5
    - platform: state
      entity_id: device_tracker.anils6_pixel
      state: 'Work'
      for:
        minutes: 5
    - platform: state
      entity_id: device_tracker.ac37434ce86a
      state: 'not_home'
      for:
        minutes: 5
  action:
    - service: homeassistant.turn_off
      entity_id: input_boolean.anilhome

- alias: 'Set Anil Home'
  condition:
    condition: state
    entity_id: input_boolean.anilhome
    state: 'off'
  trigger:
    - platform: state
      entity_id: device_tracker.pixel_bt
      state: 'home'
    - platform: state
      entity_id: device_tracker.anils6_pixel
      state: 'home'
    - platform: state
      entity_id: device_tracker.ac37434ce86a
      state: 'home'
    - platform: state
      entity_id: device_tracker.4cd5eae084d35a83
      state: 'home'
      for:
        seconds: 30
      
  action:
     service: homeassistant.turn_on
     entity_id: input_boolean.anilhome

(Thanks Zen for the tip for fromatting)

2 Likes

quote=“anilet, post:34, topic:8347, full:true”(Sorry I have no idea how to properly format the code)
[/quote]

@anilet Slightly OT, but just to address this question - if you use three back ticks ( ` ) on a line by themselves at the top and bottom of your code when you paste it in, it will maintain your formatting, and show up in a code box.

     Like This

I am sure this used to be in a help dialog somewhere, but when I went looking for it to point you in the right direction, I didn’t see it anywhere.

Thanks Zen for the tip, I did search forum before posting.

I use iBeacons for home presence detection and it has been very reliable. I have 4 beacons around the house and use OwnTracks to monitor them with iPhones. I can reliably determine when any combination of my wife and I are home or not home. I also have an iBeacon in my car and use that with GPS to detect when I’m in the car (or garage) or detect presence at work or the gym. The problem with GPS/Owntracks alone was that it sometimes took a while to update and GPS may not work well when you’re in a building. Network-based tracking (nmap, routers, pings, ARP scanning, etc.) didn’t work well because of the iPhone’s quirky behavior related to sleeping and network access.

Anyone ever use 2 nmaps, or 2 subnets? I recent added on to split all the cameras & HA stuff off the main lan (was getting bogged down) and now my nmap is unreliable. I think it is scanning 1 (where the cellphones are) and the the other (where most the devices are) and updating that the phones are away.

I want to track the phones and the devices as both are used in automations.

Currently attempting:

- platform: nmap_tracker
  hosts:
    - 192.168.1.64-253
    - 192.168.2.1-253
  track_new_devices: yes
  interval_seconds: 15
  consider_home: 180

Devices on x.x.2.x are registering but nothing on .x.x.1.x is. And I tried reversing the order but no luck.

is nmap routable?

I’m thinking not. I removed the x.x.2.x and am not seeing anything on x.x.1.x. Previously I had HA on the .1.x subnet and today moved it to the .2.x. I was not seeing any errors so I thought it was connecting to the .1.x router but perhaps not.

Not happy about this

So I ran nmap -F 192.168.1-2.1-254 from the command line of my HASS Pi on the .2.x subnet and got:

Starting Nmap 6.47 ( http://nmap.org ) at 2017-01-02 12:33 CST
Nmap scan report for 192.168.1.64
Host is up (0.024s latency).
Not shown: 99 closed ports
PORT     STATE SERVICE
8080/tcp open  http-proxy

Nmap scan report for 192.168.1.65
Host is up (0.0029s latency).
All 100 scanned ports on 192.168.1.65 are closed

Nmap scan report for 192.168.1.69
Host is up (0.022s latency).
Not shown: 99 closed ports
PORT     STATE SERVICE
8080/tcp open  http-proxy

Nmap scan report for 192.168.1.76
Host is up (0.0054s latency).
Not shown: 98 closed ports
PORT   STATE SERVICE
23/tcp open  telnet
80/tcp open  http

Nmap scan report for 192.168.1.77
Host is up (0.13s latency).
Not shown: 98 closed ports
PORT     STATE SERVICE
80/tcp   open  http
8888/tcp open  sun-answerbook

Nmap scan report for 192.168.1.82
Host is up (0.11s latency).
Not shown: 99 closed ports
PORT     STATE SERVICE
5060/tcp open  sip

Nmap scan report for 192.168.1.83
Host is up (0.0093s latency).
All 100 scanned ports on 192.168.1.83 are closed

Nmap scan report for 192.168.1.84
Host is up (0.053s latency).
Not shown: 93 closed ports
PORT     STATE SERVICE
80/tcp   open  http
139/tcp  open  netbios-ssn
443/tcp  open  https
445/tcp  open  microsoft-ds
631/tcp  open  ipp
8080/tcp open  http-proxy
9100/tcp open  jetdirect

Nmap scan report for 192.168.1.95
Host is up (0.00097s latency).
Not shown: 95 closed ports
PORT     STATE SERVICE
22/tcp   open  ssh
80/tcp   open  http
548/tcp  open  afp
631/tcp  open  ipp
8443/tcp open  https-alt

Nmap scan report for 192.168.1.189
Host is up (0.0037s latency).
Not shown: 98 closed ports
PORT     STATE SERVICE
8008/tcp open  http
8081/tcp open  blackice-icecap

Nmap scan report for 192.168.1.254
Host is up (0.0018s latency).
Not shown: 97 closed ports
PORT      STATE SERVICE
80/tcp    open  http
443/tcp   open  https
49152/tcp open  unknown

Nmap scan report for 192.168.2.1
Host is up (0.00076s latency).
Not shown: 95 closed ports
PORT     STATE SERVICE
53/tcp   open  domain
80/tcp   open  http
548/tcp  open  afp
631/tcp  open  ipp
5000/tcp open  upnp

Nmap scan report for 192.168.2.3
Host is up (0.0024s latency).
All 100 scanned ports on 192.168.2.3 are closed

Nmap scan report for 192.168.2.4
Host is up (0.016s latency).
Not shown: 99 closed ports
PORT    STATE SERVICE
443/tcp open  https

Nmap scan report for 192.168.2.5
Host is up (0.031s latency).
Not shown: 99 closed ports
PORT    STATE SERVICE
443/tcp open  https

Nmap scan report for 192.168.2.6
Host is up (0.052s latency).
All 100 scanned ports on 192.168.2.6 are closed

Nmap scan report for 192.168.2.7
Host is up (0.0095s latency).
Not shown: 92 closed ports
PORT      STATE SERVICE
135/tcp   open  msrpc
139/tcp   open  netbios-ssn
445/tcp   open  microsoft-ds
554/tcp   open  rtsp
5357/tcp  open  wsdapi
49152/tcp open  unknown
49153/tcp open  unknown
49154/tcp open  unknown

Nmap scan report for 192.168.2.8
Host is up (0.00013s latency).
All 100 scanned ports on 192.168.2.8 are closed

Nmap scan report for 192.168.2.9
Host is up (0.0086s latency).
All 100 scanned ports on 192.168.2.9 are closed

Nmap scan report for 192.168.2.100
Host is up (0.00026s latency).
Not shown: 97 closed ports
PORT    STATE SERVICE
22/tcp  open  ssh
139/tcp open  netbios-ssn
445/tcp open  microsoft-ds

Nmap scan report for 192.168.2.105
Host is up (0.0066s latency).
Not shown: 96 closed ports
PORT      STATE SERVICE
23/tcp    open  telnet
554/tcp   open  rtsp
5000/tcp  open  upnp
49152/tcp open  unknown

Nmap scan report for 192.168.2.106
Host is up (0.00071s latency).
All 100 scanned ports on 192.168.2.106 are closed

Nmap scan report for 192.168.2.107
Host is up (0.00069s latency).
All 100 scanned ports on 192.168.2.107 are closed

Nmap done: 508 IP addresses (23 hosts up) scanned in 16.03 seconds

Appears all is well (I am not an expert) but when I used it in device_tracker it still did not work to update the statuses

- platform: nmap_tracker
  hosts: 192.168.1-2.1-254
  track_new_devices: yes
  interval_seconds: 15
  consider_home: 180

Hmm, looked back at the NMAP page and saw that HASS runs nmap -F --host-timeout 5s
When I tried that I got:

pi@HASSpi:~ $ nmap -F --host-timeout 5s 192.168.1-2.1-254

Starting Nmap 6.47 ( http://nmap.org ) at 2017-01-02 12:40 CST
Nmap done: 508 IP addresses (0 hosts up) scanned in 5.23 seconds

So does that mean it sees nothing?

I re-entered in device_tracker as:

- platform: nmap_tracker
  hosts: 192.168.1-2.1-254
  scan_options: " -F "
  track_new_devices: yes
  interval_seconds: 15
  consider_home: 180

But now it only sees the 2.x subnet again.

So reading up on nmap, it is/can screen across multiple subnets but it will not receive the MAC address on subnets other than the computer it is running on.

So I need a workaround. Anyone know how to get HASS to connect to an ARRIS/PACE 5268AC to get the information direct?

OR perhaps run a Master/Slave HASS across the different subnets? hmmm, I wonder if they could then share the information.

Eventstream component can be used to share sensor/state data between multiple ha instances using MQTT messaging.

So I would run 2 Pi, one with full install (Main) on x.x.2.x and the other just running a basic install +MQTT + nmap on x.x.1.x?

mqtt_eventstream:
  publish_topic: MyServerName
  subscribe_topic: OtherHaServerName

Or would I still run Master/Slave? I’m fine with the Master/Slave other than the documentation seems lacking (at least for someone like me).

Yes. 1 full install. 1 basic with only desired component (you probably won’t use frontend)

sensor.nmapx.2 setup in config on full
sensor.nmapx.1 setup in config on basic

sensor.nmapx.1 entity added into group file of full to enable display on frontend

Eventstream will add entity as if it existed natively on pi

1 Like