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.
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).
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).
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.
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
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.
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.
@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:
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.
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.
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.