rocket4321 / nmap_tracker

nmap_tracker component for Home Assistant
4 stars 1 forks source link

nmap_tracker

nmap_tracker component for Home Assistant

Here is the latest feedback from HA Devs: -- Looking for help to implement......

We no longer allow integrations to add or change a platform YAML configuration.

More information on this can be found in Architecture Decision Record:

ADR-0007: https://github.com/home-assistant/architecture/blob/master/adr/0007-integration-config-yaml-structure.md#decision

Please note that this integration connects to a device or service and another Architecture Decision Record applies that disallows the use of YAML configuration in favor of a configuration flow via the UI:

ADR-0010: https://github.com/home-assistant/architecture/blob/master/adr/0010-integration-configuration.md#decision

See our developer documentation on how to get started creating a configuration flow for this integration:

https://developers.home-assistant.io/docs/config_entries_config_flow_handler

As these changes often involve a bit of work and some significant shift in the current code, we will close this PR for now.

We (and our community!) would really appreciate it if you could start on the refactoring of this integration in a new PR.

Thanks already! 👍

Sample configuration.yaml

Use Cases link

device_tracker:
# Minimum Required
  - platform: nmap_tracker
    hosts:
     - 192.168.100.0/24

# Default
  - platform: nmap_tracker
    hosts:
     - 192.168.0.0/24
    consider_home: 180
    # Note 'consider_home' is replacement for 'home_interval', but consider_home value is now in seconds
    exclude_active: true
    timeout: 11   
    include_no_mac: false
    scan_options: "-F --host-timeout 5s"
    local_mac_hostname: "localhost"
    debug_log_level: 2
    # base options of device_tracker
    interval_seconds: 12
    new_device_defaults:
      track_new_devices: true

# Transient Device Use-Case
# Helpful to change parameters for just a few devices, rather than entire subnet
  - platform: nmap_tracker
    hosts:
     - 192.168.0.0/24
    consider_home: 300 
    exclusive_mac:
     - 00:11:22:33:44:55
     - 00:11:22:33:44:56
     - 00:11:22:33:44:57

# Advanced/Experimental
  - platform: nmap_tracker
    hosts:
     - 192.168.0.0/24
    consider_home: 600
    exclude_active: false
    timeout: 20
    interval_seconds: 60
    include_no_mac: true
    scan_options: "--dns-servers 192.168.0.1 --privileged --host-timeout 5s"
    exclude:
     - 192.168.0.69
    local_mac_hostname: "localhostunique"
    exclude_mac:
     - FF:FF:FF:FF:FF:FF
    debug_log_level: 5

# Note: Below config for testing ONLY  
  - platform: nmap_tracker
    hosts:
     - www.google.com
    include_no_mac: true
    interval_seconds: 90
    consider_home: 600
    timeout: 30
    scan_options: "--host-timeout 10s"
    debug_log_level: 5

Breaking Changes (minimal):

Highly Recommended fields:

New OPTIONAL config fields:

Results:

from current HASS nmap_tracker: plot

from improved with exclude_active (set to false): plot

Installation

Recommend to delete known_devices.yaml prior to install. (take a backup first, silly!)

To install, see HASS docs for custom_component install. Essentially, place these files in custom_components subfolder. That HASS config folder structure would then look like:

configuration.yaml
groups.yaml
...
> custom_components
> > nmap_tracker
> > > __init__.py
> > > device_tracker.py
> > > manifest.json 

Component change design note: Due to HASS and nmap design, a scan may take longer than 10 seconds, so an error similar to below will often be displayed. To mitigate this issue, hass is instead provided the previous scan's results on an update request. In practical use, this means nmap data in hass is delayed by at least the time period of 'interval_seconds', so this value should be minimized while balancing host and network resources.

Updating device list from legacy took longer than the scheduled scan interval

Troubleshooting

Recommendations for users with issues:

If you still have issues, create an Issue here and please:

Status

I believe this update resolves the below issues

26553 Nmap tracker keep rediscovering excluded hosts with DHCP #26553

31986 nmap_tracker.device_tracker reports "No MAC address found for" itself #31986

33281 Issue with nmap_tracker since 107.6 #33281

34813 Log spam: "Updating device list from legacy took longer than the scheduled scan interval" #34813

Essentially, you will see this line in your log on every nmap scan: [homeassistant.components.device_tracker] Updating device list from legacy took longer than the scheduled scan interval 0:05:00

Further thoughts:

By default, nmap is doing reverse DNS lookups for devices to get names, so that also could be causing some user's issues and hangs. Further code improvements should incorporate so that this action is not completed every scan, but simply on a startup/interval basis. Some of the examples above control where DNS requests go and/or disable it.

interval_seconds: I really recommend no smaller than the default 300 (5 min). I've seen some posts of sub 60 seconds, so could translate to a heavy network workload for older devices across an entire subnet.

Nmap results return could also be getting stalled by a single host or subnet, so recommending for users to define seperate instances of nmap device tracker for seperate subnets or for sporatic network responsiveness. Each device_tracker instance translates a different nmap process that could be either succeed or fail. It's defined in the user's config how each group is segmented, but multiple host line definitions are combined to a single process call for each nmap device tracker instance.

Other failure causes could simply be resource limitations, such as local computing hardware, network delays/errors, wifi reception... If a nmap scan can't complete in enough time that a device is subsequently marked 'not_home', it then would only to be toggled back to 'home' when the scan completed. All this definitely would imply either a timing or resource bottleneck.

Qs for HASS team:

Is a default MAC address of 'xx:xx:xx:xx:xx:xx' acceptable in known_devices.xml ?

How would a duplicate device_tracker be handled by HASS? Would each update clobber the other? -- this is possible since the user can define any mac address in the config for localhost, so does this need to be blocked at startup?

Latest: