Getting IP Addresses of devices?

Post-discovery, when a device has successfully running in HA, is there an easy way to get or view their IP addresses?

I have a large block of devices running, and they (often) don’t traditionally do a good job identifying themselves within the router devices list. Even more so, duplicate devices will don’t really identify who they are (e.g. TP Link, HS200, etc). I’d like some way to see what a devices IP address is post-HA discovery. This way I can see their actual devices names and their IP.

1 Like

Hi,

i search the same thing…

Have you find a solution please?

Not really HA integrated but would something like phpIPAM (https://hub.docker.com/r/pierrecdn/phpipam) work for you?

It does have the capacity to keep track of a very large number of devices in different subnets (way more than a regular consumer router can accommodate).

ok thanks but i am on hassio…

Devices with a screen can usually display it.

Devices without screens sometimes have a webpage that displays what it is when you open the IP address.

The rest who don’t:
Copy paste all devices connected to the router and paste in Excel.
Unplug one device and note what device was unplugged.
Update the router and copy paste again.
Repeat untill all devices are known in the router list.

Now comes the fun part.
Work your way through the list and and see which IP is missing on each iteration.
If you are a little skilled in Excel formulas then you can use a vlookup function to easily spot the one that is missing on each iteration.

Make sure to reserve all IPs now.

You could also do this the other way around by plugging in a device on each iteration.
This is better if you are unsure if the router will give a new IP each time.

For those coming here from Google: all device details including their IPs are in ~/.homeassistant/.storage/core.device_registry (assuming your config directory is ~/.homeassistant).

6 Likes

TP-Link doesn’t appear to do that. I checked the whole file and I have no IP addresses

1 Like

What about the Nmap Tracker?

1 Like

In my way too long history of data center dealings… the only reliable way of documenting device IP addresses is; before you install the device, jot down it’s MAC address (it’s on a label somewhere and it doesn’t change). Then, on your router/switch software, the display of devices will always show the MAC address of the device and the IP address the DNS associated it with.

1 Like

Some (maybe all?) appear to be in core.config_entries, but none appear in my core_device.registry.

It would sure be handy if they were accessible directly via the UI.

I make a habbit of creating an named IP reservation on each added device on my routers dhcp
I also use
192.168.101.x for new clients (=dhcp scope)
192.168.102.x for non HA equipment and 192.168.103.x for HA equipment
(netmask 255.255.252.0)

So whenever there is a new device, i just check 101 and move it to 102 or 103 :wink:

4 Likes

That is a good idea!
I have only reserved the IPs to the devices that matter so each time I open the config to find the new device it’s the same problem of finding it.
But that is clever!
Will do that in the next apartment we move to.

Sorry to dig up an old thread, but I have a similar need and was able to figure out a solution.

Recently, the 2011.11 release introduced a configuration_url that a device can self report. This is what powers the visit device functionality.

With this comes a few new functions that can be used in templates:

device_id() and device_attr().

They are covered here.

You can chain them together or just use the ‘helper’ function device_attr() like this:

{% set dev_url = device_attr('fan.bathroom_fan', 'configuration_url') %}

{% if dev_url != None -%}
  url: {{dev_url}}
{%- else -%}
  Check the entity id and confirm that the device the entity belongs to reports its configuration_url properly 
{%- endif %}

The value of dev_url will be a URL, not the IP address … but that’s easy enough to deal with using the existing string manipulation functions in templates.

I hope this helps!

2 Likes

Is there any easy way doing it? I have tried Nmap tracker, it does not show local ip address for devices.

@famous.bulb how do you actually use it with the custom:button-card or the button card? I tried it in both and haven’t been able to make it work, although it works in the HA developper tools template?

{% set ip_address = device_attr('cover.cover_bedroom', 'configuration_url').split("//")[1] %}
{{ ip_address }}

I was neither able to make it work with the custom:button-card, like below:

variables:
  ip_address: "[[[ return device_attr('cover.cover_bedroom', 'configuration_url').split('//')[1] ]]]"

Many thanks!

Do you have a device_tracker setup with your router? It may be easier to use that as those entities will tend to have their IP address in their attributes, and you can use then directly within the card.

See an old thread of mine here: Display an entity's attribute? - #3 by guice

An example device_tracker entity of mine from my Unifi integration:

What I do is assign IP addresses to every smart device, so that the ip address never changes. Then I setup ping sensors (and alerts when needed) to track the device. Which gives me a dashboard like this.

2 Likes

You need the device to report it’s IP address during discovery. Assuming that the device does report this, the code I shared is how you’d access it.

Not sure how you’d use w/ custom cards

I am using many Shelly relays and, unfortunately, not all the parameters are available. Some of them are quite important for the rollers. So it is not possible to open or close a roller using “duration” (only “position” is available) to orient the shades turning them up or down. So to implement this, I use the “command_rest” to send the duration using the device IP. I also need the “last_direction” of the roller, which is not available either, to orient the shades in function of the previous movement, either up or down, using a different number of seconds, which I activate using a button or in an automation. So for all the shades I want to orient, I create a sensor with the “last_direction” and IP attributes. It would be less overdesigned and nicer if it was possible to send a rest command on the fly directly to the device to get the “last_direction” and avoid creating a sensor which takes some time to update its attributes.

FYI: TP-Link have 2 different product lines, Kasa are also TP-link. The Kasa IP address and MAC are stored here.