Hi,
I'm running OPNsense 26.7.2_2 with Device Monitor v2.1.
I found an issue where multiple historical Hostwatch records for the same MAC address can cause Device Monitor to select an old IP/interface record instead of the current one.
Example
My Windows PC has:
MAC: 7c:83:34:b2:34:7c
Current IP: 192.168.20.111
Interface: igc1 / LAN
Device Monitor initially showed this device incorrectly as:
IP: 192.168.20.146
Interface: IGC1
Offline
I checked the Hostwatch database directly:
sqlite3 /var/db/hostwatch/hosts.db \
"SELECT interface_name, ip_address, ether_address, first_seen, last_seen, organization_name
FROM v_hosts
WHERE ether_address='7c:83:34:b2:34:7c';"
Hostwatch contained three records for the same MAC:
igc1 192.168.20.146 2026-08-15 03:04:46
igc0 192.168.20.146 2026-08-15 11:10:03
igc1 192.168.20.111 2026-08-19 06:06:49
The last record is the current/correct one.
I also confirmed Hostwatch itself was updating correctly. For example, its most recent records included:
7c:83:34:b2:34:7c 192.168.20.111 igc1 2026-08-19 06:08:51
So Hostwatch was not the problem.
Cause
I traced this to:
/usr/local/opnsense/scripts/OPNsense/DeviceMonitor/scan_network.py
The Hostwatch query currently retrieves all matching records:
SELECT
interface_name,
ip_address,
ether_address,
first_seen,
last_seen,
organization_name
FROM v_hosts
WHERE protocol = 'inet'
AND ether_address NOT IN ('ff:ff:ff:ff:ff:ff', '00:00:00:00:00:00')
AND ip_address NOT LIKE '169.254.%'
ORDER BY last_seen DESC
There is no deduplication by ether_address.
Device Monitor's own database uses the MAC address as the key:
mac TEXT PRIMARY KEY
Therefore, when multiple Hostwatch records exist for the same MAC, they are processed sequentially and can overwrite one another. In my case, the historical .146 record ended up being stored instead of the current .111 record.
This also affected the Online/Offline status because Device Monitor was evaluating the stale record's last_seen.
Test fix
I tested a local modification to the SQL query which selects only the newest last_seen record for each MAC address, with the Hostwatch id used as a tie-breaker.
After applying the change and running a full scan, Device Monitor immediately changed the affected PC to:
MAC: 7c:83:34:b2:34:7c
IP: 192.168.20.111
Interface: IGC1
Status: ONLINE
The Device Monitor database then showed:
7c:83:34:b2:34:7c
192.168.20.111
IGC1
2026-08-19 06:18:58
is_active = 1
I subsequently restarted Device Monitor and confirmed the service restarted normally and the Devices page continues to show the correct IP/interface/status.
Suggested fix
I believe the Hostwatch query should deduplicate records by ether_address and select the record with the newest last_seen before passing the results to the Device Monitor database.
This would prevent historical Hostwatch records from overwriting the current record for the same MAC.
The email notification functionality otherwise works correctly for me. I have successfully tested detection of a new MAC address and received the Device Monitor email notification through Postfix.
Thanks — I've attached modified SQL/query if useful.
I'm running OPNsense 26.7.2_2 with Device Monitor v2.1.
I found an issue where multiple historical Hostwatch records for the same MAC address can cause Device Monitor to select an old IP/interface record instead of the current one.
Example
My Windows PC has:
MAC: 7c:83:34:b2:34:7c
Current IP: 192.168.20.111
Interface: igc1 / LAN
Device Monitor initially showed this device incorrectly as:
IP: 192.168.20.146
Interface: IGC1
Offline
I checked the Hostwatch database directly:
sqlite3 /var/db/hostwatch/hosts.db \
"SELECT interface_name, ip_address, ether_address, first_seen, last_seen, organization_name
FROM v_hosts
WHERE ether_address='7c:83:34:b2:34:7c';"
Hostwatch contained three records for the same MAC:
igc1 192.168.20.146 2026-08-15 03:04:46
igc0 192.168.20.146 2026-08-15 11:10:03
igc1 192.168.20.111 2026-08-19 06:06:49
The last record is the current/correct one.
I also confirmed Hostwatch itself was updating correctly. For example, its most recent records included:
7c:83:34:b2:34:7c 192.168.20.111 igc1 2026-08-19 06:08:51
So Hostwatch was not the problem.
Cause
I traced this to:
/usr/local/opnsense/scripts/OPNsense/DeviceMonitor/scan_network.py
The Hostwatch query currently retrieves all matching records:
SELECT
interface_name,
ip_address,
ether_address,
first_seen,
last_seen,
organization_name
FROM v_hosts
WHERE protocol = 'inet'
AND ether_address NOT IN ('ff:ff:ff:ff:ff:ff', '00:00:00:00:00:00')
AND ip_address NOT LIKE '169.254.%'
ORDER BY last_seen DESC
There is no deduplication by ether_address.
Device Monitor's own database uses the MAC address as the key:
mac TEXT PRIMARY KEY
Therefore, when multiple Hostwatch records exist for the same MAC, they are processed sequentially and can overwrite one another. In my case, the historical .146 record ended up being stored instead of the current .111 record.
This also affected the Online/Offline status because Device Monitor was evaluating the stale record's last_seen.
Test fix
I tested a local modification to the SQL query which selects only the newest last_seen record for each MAC address, with the Hostwatch id used as a tie-breaker.
After applying the change and running a full scan, Device Monitor immediately changed the affected PC to:
MAC: 7c:83:34:b2:34:7c
IP: 192.168.20.111
Interface: IGC1
Status: ONLINE
The Device Monitor database then showed:
7c:83:34:b2:34:7c
192.168.20.111
IGC1
2026-08-19 06:18:58
is_active = 1
I subsequently restarted Device Monitor and confirmed the service restarted normally and the Devices page continues to show the correct IP/interface/status.
Suggested fix
I believe the Hostwatch query should deduplicate records by ether_address and select the record with the newest last_seen before passing the results to the Device Monitor database.
This would prevent historical Hostwatch records from overwriting the current record for the same MAC.
The email notification functionality otherwise works correctly for me. I have successfully tested detection of a new MAC address and received the Device Monitor email notification through Postfix.
Thanks — I've attached modified SQL/query if useful.
"