Please check existing posts to see if your feature request already exists.
🐛 If you’ve encountered a bug, please submit a ticket to the Hudu support team to ensure a quick response.
Hudu Radar currently provides no way to exclude specific devices from network scans, which can cause disruption to sensitive hardware. Hudu should allow users to define an exclusion list by IP, MAC address, or hostname that Radar skips during discovery.
When Hudu Radar automatically classifies discovered devices, users have no way to override the assigned device type mapping. Hudu Radar should allow users to manually reclassify devices on a per-device basis, with the override persisting through future scans.
When Hudu Radar discovers a network device (such as a printer, switch, or router), there is currently no way to access that device's HTTPS management interface directly from Hudu. Tools like Domotz support this by proxying the connection through the installed endpoint, allowing technicians to reach a device's web UI even when it isn't directly accessible from their browser. Adding proxied remote access to Hudu Radar would allow users to click through to a device's management page directly from its asset in Hudu, routed through the Radar agent or service on that network. This would significantly reduce the friction of managing devices on remote or segmented networks.
Please add a way for Radar to distinguish between reserved DHCP addresses (which essentially function as static addresses) and normal dynamic DHCP addresses. For users with DHCP reservation pools for critical infrastructure like servers and firewalls, it would be helpful to be able to input those reservations instead of Radar assuming every IP is DHCP.
Currently, Hudu Radar is limited to being installed on Windows. It would be appreciated to have a native Linux install :)
We would like to request that the Hudu Radar code received from the IPAM section within a company be updated so the expiration timer can be customized.
Currently, it seems Hudu Radar requires you to log into the Hudu instance even though it uses a code. This seems counterintuitive to the whole purpose of using an API token if one has to sign in every time. What would resolve this: Making it where Hudu Radar setup does not require signing in and the provided API token is enough.
Currently, Hudu Radar only seems to allow for scanning the currently attached L2 network. It would be of benefit if it was capable of scanning additional L2s accessible via L3, such as VLANs for example. Screenshot attached for reference.
Basically markers putting next to each device showing whether the IP address is alive or dead.
We would like a comprehensive search bar for Hudu Radar, similar to how the CORE of Hudu already is. This would save operators a lot of time.
We use the "Copyable Text" field for all our IP addresses in the asset types but Radar can only sync with "Text" and "Rich Text". Would be nice to also sync with "Copyable Text"
Please add more Hudu Radar Data Points for Wireless Devices. Example Ideas: SSID information Signal strength / RSSI Connection type (2.4 GHz / 5 GHz / 6 GHz) Security type (WPA2, WPA3, etc.) Link speed / negotiated rate Roaming or disconnect history (if available) Associated access point / BSSID
Please add a Data Point for Ram(Memory) so we can see the total amount of memory.
Allow tunneling the web interface from discovered devices like domotz/auvik?
Servers, UPSs, etc. It would be best if we could match discovered devices to any type of configured asset layout.
Het zou fijn zijn om in Hudu de naam van een asset, dat gemaakt werd door Radar, aan te passen zonder dat die telkens overschreven wordt. Als we nu de naam aanpassen in Hudu wordt die bij de eerstvolgende scan overschreven door de oude naam die vaak niet gebruiker-vriendelijk is. We kunnen dat al overkomen door de klant PC over te nemen en in de Hudu Radar app de naam aan te passen maar dan moeten we nog steeds een PC overnemen om een naam aan te passen.
Currently, each child company requires its own Radar license, even when they are configured as departments under a parent company. It would be helpful if a single Radar license for the parent company could also cover its child companies. This would simplify setup and reduce licensing overhead for organizations that use child companies to represent internal departments.
Allow discovered devices to be matched to an existing asset