Hostwatch features / improvements

[psharkauburn]

Not sure if this is the right place in the forum to put this, so move if needed (and/or i'll take constructive criticism for future posts). Coming from a consumer based router (asus merlin) I definitely appreciate the new addition, I know it has/had some bugs and i'm sure it'll improve. Just saw it today when I noticed an update, wanted to make a couple quick notes for improvements along with some questions:

• Should be a flow from discovery -> static assignment
• Remove IP address requirement from static assignment
• Should be some control over discovery staleness trimming/garbage collection
• Should be some additional fields shown/tracked on discovery + static assignment

Discovery -> Static flow: Nothing crazy here, just expecting a command available on the DiscoveredHosts row detail for 'Create Static Entry' that would pre-fill the static entry form with the values from the DiscoveredHosts row detail. Pretty similar to a normal DHCP flow in DNSMASQ from looking at dynamic lease table and turning a dynamic entry -> create static entry via [add reservation] command.

Remove IP Requirement from Static Mapping -> I know I have plenty of IOT type devices like light bulbs that I don't do static DHCP for, and their OUI org names can be fun to sleuth out (sarcasm). I DO very much want to be able to label them meaningfully (garage exterior light, front porch light, etc...) based just on MAC while keeping them dynamic on IP (maybe playing with setting up VLAN for them, etc...). Occasional use old tablets/phones are in the same boat for me. Plenty of old devices I very occasionally turn on for some reason (or the kids) and love knowing what the device actually is but definitely don't want to waste an IP assignment for it.

Staleness trimming -> My assumption is that the DiscoveredHosts table is meant to serve as a 'devices currently on the network' in some sort of loose interpretation (like recently on the network). I'd expect devices to fall off this list from some concept of last seen versus a staleness threshold (1 min, 10 min, 1 hour, etc...). Just looking for this threshold to be stated / configurable at least on a global level, I can see usefulness in a per host setting also from the static table.

Additional fields/GUI stuff -> On the DiscoveredHosts table a [Last Seen] is VERY useful, especially if we don't know the staleness trimming default. I've had systems that may not trim the discovery table but will change font color/weight/etc... to indicate a stale entry that hasn't been seen in awhile (I think FING does this for example). Bringing static [description] over to DiscoveredHosts seems really natural; if I've gone to the trouble to do the static mapping I want the friendly name showing on the DiscoveredHosts table to show what's currently on the network. Taking this out a step further, may want to consider a distinct field for [FriendlyName] (or [HostName]) on the static table so description can be used for its intended purpose (longer description of something) but a shorter helpful name can be used throughout reporting / firewall stuff / etc... May want to bring the [Last Seen] field to the static table, give an easy way to potentially help folks trim out old entries from their system that may not be used anymore.

Question side - curious about interplay with DNSMASQ DHCP static mappings for example. I was about to go thru the process in DNSMASQ [Hosts] to do most of this mapping between hardware MAC -> friendly device hostname/description. It looks like the [Hosts] table has concepts like tagging so I can add useful logical groups like 'Light Bulbs/Switches/TVs' etc... and doesn't require a fixed IP address assignment. Just wanting to kinda get validation I'm interpreting this right, I haven't moved forward and done the work yet to implement. The next logical question then becomes, what is the best place to do this sort of mapping; DHCP [Hosts] or Neighbor [Static] ? It seems like DHCP [Hosts] does all of what I want and doesn't require any changes, but surfacing that data thru to Neighbor [DiscoveredHosts] would be EXTREMELY beneficial. Just looking for guidance before going down some path trying to map out 100-200 devices in one area and then being told HostWatch is the new/future best practice, and need to redo it.