# \[APP\]\[Pro\] NetScan - Track devices on your local network using ARP and TCP checks
**URL:** https://community.homey.app/t/app-pro-netscan-track-devices-on-your-local-network-using-arp-and-tcp-checks/47454
**Category:** Apps
**Tags:** app
**Created:** [May 16, 2021, 9:00am UTC](https://community.homey.app/t/app-pro-netscan-track-devices-on-your-local-network-using-arp-and-tcp-checks/47454 "2021-05-16T09:00:48Z")
**Posts on this page:** 18
**Page:** 7
### Author:  [@Sharkys](https://community.homey.app/u/Sharkys)
#### Post date: [July 20, 2026, 2:35pm UTC](https://community.homey.app/t/app-pro-netscan-track-devices-on-your-local-network-using-arp-and-tcp-checks/47454/121 "2026-07-20T14:35:37Z")
Hi everyone,
A new test version of Net Scan is available.
This release contains significant improvements to device detection, reachability presentation, Insights, Advanced Flows, pairing and application stability.
Install the test version here:
> **[Net Scan | Homey](https://homey.app/en-us/app/com.netscan/Net-Scan/test/)**
>
> Watch devices on your local network by scanning for TCP ports
**As this is initially a test release, feedback about device detection, migration and Probe Time measurements is appreciated.**
### Clear network reachability status
Devices now have a dedicated **Network reachability** status:
- Reachable
- Not reachable
This uses a network-specific icon instead of presenting the device as a normal on/off switch.
The reachability status is also available as the device quick action. Although Homey may present it similarly to a toggle, it is a read-only status controlled by Net Scan. Pressing it cannot make a network device online or offline; Net Scan restores the detected state.
### Backwards compatibility
The legacy `onoff` and `alarm_offline` capabilities are retained internally so existing Flows remain compatible.
The legacy on/off status is hidden from the normal device interface where possible and is synchronized with the new reachability status.
You should not need to delete or re-pair existing devices.
For new Flows, use the new reachability status and duration condition instead of the legacy on/off condition.
### ARP device detection
IP devices now support three detection methods:
- **Automatic – ARP, then TCP**
- **ARP only**
- **TCP response – legacy method**
Automatic detection first checks for the device using ARP. If ARP cannot confirm the device, Net Scan falls back to its existing TCP response check.
New IP devices use Automatic detection by default.
Existing IP devices remain configured for the legacy TCP response method after upgrading. This prevents their detection behaviour from changing unexpectedly. Automatic or ARP detection can be enabled manually from the device’s Advanced Settings.
ARP is intended for numeric IPv4 addresses on the same local network as Homey. It may not work across routers, VLANs or other separated networks. Hostnames and non-local targets use the TCP fallback.
ARP confirms that a device is present on the network. It does not confirm that a particular service on that device is operational.
1. **ARP:** Better for detecting local devices without a usable TCP service, but can briefly produce stale online results.
2. **TCP response:** Better when rapid crash detection matters.
3. **TCP port:** Best when the monitored service itself must be operational.
### Probe Time Insights
Net Scan now records the duration of successful device probes in milliseconds.
The new **Probe time** capability:
- Is available in Homey Insights
- Supports both ARP and TCP detection
- Uses a dedicated stopwatch icon
- Updates at most once per minute to avoid unnecessary Insights entries
- Updates immediately when a device recovers
- Is cleared when the device is confirmed offline
**Probe time is not an ICMP ping measurement.** It represents how long the currently selected ARP or TCP detection method took to receive a valid response.
### Improved pairing
The IP and TCP pairing dialogs have been redesigned with clearer fields, validation, feedback and connection testing.
Before adding a device, press **Test connection**.
For an IP device, the test uses the same ARP-first and TCP-fallback process as Automatic detection.
For a TCP device, Net Scan attempts to connect to the specified TCP port.
The result is informational:
- A successful test is displayed in green.
- A timeout, unreachable device, unresolved hostname or closed TCP port is displayed as a warning.
- Devices can still be added after a warning. This allows devices that are currently offline or whose service is stopped to be configured in advance.
- Invalid IP addresses, malformed hostnames and invalid TCP ports are rejected.
- Changing the host or TCP port requires running the test again.
The device name is optional. If it is left empty, Net Scan creates a name from the host or host and TCP port.
### Online/offline duration Flow condition
A new Advanced Flow condition is available for IP and TCP devices:
> Device has been online or offline for at least a specified duration
You can select:
- Online or offline
- Duration
- Seconds or minutes
Net Scan stores the last state transition time, allowing duration tracking to continue across application restarts.
This is a condition, not a delayed trigger. It evaluates the device state when the Flow runs. Use it together with a suitable trigger or periodic Flow.
For upgraded devices without existing duration history, tracking starts when this version first initializes the device.
### Logging changes
The **Send Log** function has been removed, together with its email-related dependencies. Logs can still be viewed, copied and cleared manually from the app settings.
Two logging levels remain:
- **Errors Only:** Only actual errors are recorded.
- **Basic Information:** Includes scanning and Probe Time diagnostics.
When reporting a Probe Time problem, select **Basic Information** before collecting the log.
### Stability and maintenance improvements
This version also includes:
- Improved socket and timer cleanup
- Protection against outdated scan results
- Safer handling of settings changes, app restarts and device removal
- Improved capability migration for existing devices
- Better error handling for Flow triggers and device state updates
- Improved host and TCP-port validation
- Updated Homey SDK and supporting dependencies
- Refreshed device, quick-action and App Store artwork
- Updated English, German and Dutch translations
### Instructions for existing users
1. Install the test version using the link above.
2. If **Network reachability** or **Probe time** is still missing, restart the app once more. Newly added capabilities may require another initialization.
3. Do not delete or re-pair existing devices.
4. Existing IP devices continue using the legacy TCP response method.
5. To test ARP, open the IP device’s Advanced Settings and select **Automatic – ARP, then TCP**.
6. Check Homey Insights for **Network reachability** and **Probe time**.
7. Test your existing Flows after upgrading.
### Reporting problems
When reporting a problem, please change the reporting to Basic, let it run few cycles and then include as many details as possible in the diagnostic report.
Thank you for testing and providing feedback.
---
### Author:  [@Jan-Erik\_Hallkvist](https://community.homey.app/u/Jan-Erik_Hallkvist)
#### Post date: [August 4, 2026, 5:50am UTC](https://community.homey.app/t/app-pro-netscan-track-devices-on-your-local-network-using-arp-and-tcp-checks/47454/122 "2026-08-04T05:50:26Z")
Hi, when testing Quick action button, an error pops up ’ Missing Capability Listener: reachable’.
---
### Author:  [@Sharkys](https://community.homey.app/u/Sharkys)
#### Post date: [August 4, 2026, 6:08am UTC](https://community.homey.app/t/app-pro-netscan-track-devices-on-your-local-network-using-arp-and-tcp-checks/47454/123 "2026-08-04T06:08:35Z")
Hi, it’s dummy button just to indicate device state, however it’s not happening for me. Did you submit diagnostic log, right ?
---
### Author:  [@Jan-Erik\_Hallkvist](https://community.homey.app/u/Jan-Erik_Hallkvist)
#### Post date: [August 4, 2026, 6:24am UTC](https://community.homey.app/t/app-pro-netscan-track-devices-on-your-local-network-using-arp-and-tcp-checks/47454/124 "2026-08-04T06:24:23Z")
539aed0a-4dde-485f-ac57-96c208a77c6c
---
### Author:  [@Sharkys](https://community.homey.app/u/Sharkys)
#### Post date: [August 4, 2026, 9:02am UTC](https://community.homey.app/t/app-pro-netscan-track-devices-on-your-local-network-using-arp-and-tcp-checks/47454/125 "2026-08-04T09:02:57Z")
If you restart the app, the issue shall be gone. In any way, I will publish update, thank you for testing.
---
### Author:  [@Jan-Erik\_Hallkvist](https://community.homey.app/u/Jan-Erik_Hallkvist)
#### Post date: [August 4, 2026, 9:29am UTC](https://community.homey.app/t/app-pro-netscan-track-devices-on-your-local-network-using-arp-and-tcp-checks/47454/126 "2026-08-04T09:29:12Z")
Thanks!
I thought the button is a ’Check now’😁
Wishlist: a then-card ’Check now’.
Best regards Jan
---
### Author:  [@Sharkys](https://community.homey.app/u/Sharkys)
#### Post date: [August 4, 2026, 10:34am UTC](https://community.homey.app/t/app-pro-netscan-track-devices-on-your-local-network-using-arp-and-tcp-checks/47454/127 "2026-08-04T10:34:17Z")
I actually like that idea, please test [Net Scan | Homey](https://homey.app/en-gb/app/com.netscan/Net-Scan/test)
Please note that The Flow action starts the check immediately but does not wait for its result.
---
### Author:  [@Jan-Erik\_Hallkvist](https://community.homey.app/u/Jan-Erik_Hallkvist)
#### Post date: [August 4, 2026, 12:17pm UTC](https://community.homey.app/t/app-pro-netscan-track-devices-on-your-local-network-using-arp-and-tcp-checks/47454/128 "2026-08-04T12:17:49Z")
Tested with good result. Think it could be useful even without the card waitng for result.
The aim is to get a snapshot of the network concerning some ordinary/backup equipment online status..
Thanks.
---
### Author:  [@Drako74](https://community.homey.app/u/Drako74)
#### Post date: [August 5, 2026, 5:28pm UTC](https://community.homey.app/t/app-pro-netscan-track-devices-on-your-local-network-using-arp-and-tcp-checks/47454/129 "2026-08-05T17:28:08Z")
Hi @Sharkys
Absolutely love the new Probe Time property/insight, excellent feature. And the When Flow cards greater/less than will be exceedingly useful.
Can I ask what the reason for changing the minimum check interval to 15 seconds is please? I have a few checks for very important devices that are 10 second intervals, which I can no longer edit, as it says that the check interval is out of bounds. Minor I realise, but a little frustrating nonetheless.
Please keep up the excellent work and improvements, they are greatly appreciated.
---
### Author:  [@Sharkys](https://community.homey.app/u/Sharkys)
#### Post date: [August 5, 2026, 7:46pm UTC](https://community.homey.app/t/app-pro-netscan-track-devices-on-your-local-network-using-arp-and-tcp-checks/47454/130 "2026-08-05T19:46:12Z")
> [@Drako74](#):
>
> Can I ask what the reason for changing the minimum check interval to 15 seconds is please? I have a few checks for very important devices that are 10 second intervals, which I can no longer edit, as it says that the check interval is out of bounds.
I will change this to 5sec minimum, I think default was actually 1sec or so and I was afraid that someone might got overload Homey network stack because of misconfigurations.
---
### Author:  [@Drako74](https://community.homey.app/u/Drako74)
#### Post date: [August 5, 2026, 8:07pm UTC](https://community.homey.app/t/app-pro-netscan-track-devices-on-your-local-network-using-arp-and-tcp-checks/47454/131 "2026-08-05T20:07:22Z")
> [@Sharkys](#):
>
> I will change this to 5sec minimum
Thank you very much, hugely appreciated!
15+s is fine for less critical devices, but I prefer the slightly more frequent 10s for things like my core switch, NAS etc that the rest of my home LAN and smart home rely on.
I totally understand the concern about someone overloading their network stack with silly frequency checks. Especially given Homey Pro’s network bandwidth restrictions going through a USB 2.0 480Mbps adapter (which I personally find utterly NUTS given that RPi 4’s have USB 3 and gigabit network capability… and even the Homey Pro Mini has GbE).
Again, thank you. Your work on this app is greatly appreciated.
---
### Author:  [@Drako74](https://community.homey.app/u/Drako74)
#### Post date: [August 6, 2026, 8:35am UTC](https://community.homey.app/t/app-pro-netscan-track-devices-on-your-local-network-using-arp-and-tcp-checks/47454/132 "2026-08-06T08:35:34Z")
> [@Sharkys](#):
>
> I will change this to 5sec minimum
Sorry for being a nuisance, but now getting similar error for timeout minimum 😬 sorry…
EDIT: a timeout longer than a check interval is a certain way to overwhelm a network stack, oops 🙊
---
### Author:  [@Sharkys](https://community.homey.app/u/Sharkys)
#### Post date: [August 6, 2026, 1:33pm UTC](https://community.homey.app/t/app-pro-netscan-track-devices-on-your-local-network-using-arp-and-tcp-checks/47454/133 "2026-08-06T13:33:01Z")
> **[Net Scan | Homey](https://homey.app/en-cz/app/com.netscan/Net-Scan/test/)**
>
> Track devices on your local network using ARP and TCP checks.
### Version 2.1.5 — Reduced the minimum check timeout to 1 second and clarified the delay-between-checks setting.
😉
> [@Drako74](#):
>
> a timeout longer than a check interval is a certain way to overwhelm a network stack
I renamed that option to understand it better. So for example, a 10-second timeout with a 5-second interval can produce roughly 15 seconds between check starts when the target does not respond. Automatic ARP→TCP detection can take up to roughly 18 seconds because ARP has a separate three-second ceiling before TCP fallback.
---
### Author:  [@Drako74](https://community.homey.app/u/Drako74)
#### Post date: [August 6, 2026, 2:24pm UTC](https://community.homey.app/t/app-pro-netscan-track-devices-on-your-local-network-using-arp-and-tcp-checks/47454/134 "2026-08-06T14:24:24Z")
> [@Sharkys](#):
>
> Reduced the minimum check timeout to 1 second and clarified the delay-between-checks setting
Thank you kind sir, you are a legend. Much appreciated!
I’ll give it a test when I get home tonight.
---
### Author:  [@Borssie](https://community.homey.app/u/Borssie)
#### Post date: [September 10, 2026, 7:09am UTC](https://community.homey.app/t/app-pro-netscan-track-devices-on-your-local-network-using-arp-and-tcp-checks/47454/135 "2026-09-10T07:09:22Z")
Hi all,
I have a question regarding this app. I want to monitor my EV charger (Peblar Business) to check the online status but it keeps stating that the IP adress is not reachable.
Though I can check the status in the Peblar web based app and it has a fixed IP adress in my mesh network. The EV charger _ **IS** _ actually online, but doesn’t reflect in the Netscan app.
Does it only states it is reachable when the EV is physically connected to the EV charger?
---
### Author:  [@Sharkys](https://community.homey.app/u/Sharkys)
#### Post date: [September 10, 2026, 10:56am UTC](https://community.homey.app/t/app-pro-netscan-track-devices-on-your-local-network-using-arp-and-tcp-checks/47454/136 "2026-09-10T10:56:56Z")
Does it responds to PING ? You can try also with TCP/IP - eg. port based check…
---
### Author:  [@Borssie](https://community.homey.app/u/Borssie)
#### Post date: [September 10, 2026, 6:33pm UTC](https://community.homey.app/t/app-pro-netscan-track-devices-on-your-local-network-using-arp-and-tcp-checks/47454/137 "2026-09-10T18:33:30Z")
Thanks @Sharkys
That did it! TCP/IP and port based check passed. You have any idea why the IP adress scan doesn’t work as expected?
---
### Author:  [@Drako74](https://community.homey.app/u/Drako74)
#### Post date: [September 10, 2026, 6:57pm UTC](https://community.homey.app/t/app-pro-netscan-track-devices-on-your-local-network-using-arp-and-tcp-checks/47454/138 "2026-09-10T18:57:31Z")
Some devices/services don’t allow ICMP traffic (which includes ping) for security. There’s an older type of cyber attack called the ping of death, sending malformed ICMP packets as a Denial of Service attack.
Also ping sweeps are a common way of assessing network hosts that are alive and possibly vulnerable. Plus if you don’t need it, why have the overhead of supporting it.
Accessing the actual port a service runs on is a more reliable way of telling if the service is running or not anyway.
[Previous page](https://community.homey.app/t/app-pro-netscan-track-devices-on-your-local-network-using-arp-and-tcp-checks/47454.md?page=6)