A project change of which I am thinking. Need help on the mechanics of how it is to be done

I'm still kind of torn between full DHCP and static IP addresses on my devices.

This is my list of devices status page.

TWO parts.

1 - WiFi devices
2 - Cable devices (RasPies.)

The Wifi one is fully DHCP - though there is only 1 devices on it. (Sod's law)
The Cable part is older and has 3 permanent devices on it.
That's because they are from the ORIGINAL layout when I was a static person.

So the layout of the Cable part is kind of fixed where devices appear as they have Fixed IP addresses.

When a device connects to my network, it sends an MQTT message (SOL) with it's name and details.
Sorry. No it sends a message saying it's comms are up.
That is detected and an IFF message is sent to which it replies with it's details.

As per:

On the WiFi part, the name is taken and put where the IP address is/was.
(In the example it is GPS - old name and is wrong, but for the sake of showing.)
And it needs to be short, like 3 letters max)
Not a big deal. Just mentioning.

For better clarity this is the message received after the IFF message is sent:

{"topic":"STATUS/WIFIDEVICEID",
"payload":
"{\"WIFI_DEVICE\":\"TelePi\",
\"IP_Address\":\"192.168.17.33\",
\"Sent\":\"2026-04-23 06:51:50\"}"
,"qos":0,"retain":false,"_msgid":"c5fb675e867aa777"}

And yes, WIFI_DEVICE is a misnomer.

So I'm wanting to modify the existing code to allow this to also happen with the Fxied IP address devices.
Be it they are fixed or DHCP.

The PROBLEM if I make them fully DHCP is whey could appear ANYWHERE on the network and not just in the allocated cluster as per now.
There may be a way to force them to a specific IP address. But doesn't that defeat the idea of DHCP?

But when the IFF message reply is received, the IP number is replaced with the device's name.

That in itself isn't that easy as there is a whole subflow which monitors the device's health.
(Another story outside the scope here/now)

(Still with me? Probably not. Sorry.) :wink:

So I am not fully understanding the mechanics of the DHCP vs static part working.
and if I should go from the existing fixed to being fully DHCP controlled IP addresses.

By fixed IP, do you mean that the device itself demands a particular IP address?
For a Pi that would be set up in Network Manager.
Or do you reserve IP addresses in the DHCP server (probably but not necessarily your router)?

If you were to swap SD cards between Pies, the static IP would follow the SD card, while the reserved address stays with the device.

I use reserved addresses for most devices.
Pies have an IP in the range 192.168.1.20 to .29, ESPs 192.168.1.70 to 79, printers 192.168.1.60 to .69, etc.

These IPs are maintained in a single location - the DHCP server and if I burn a fresh SD card for a Pi it automatically gets the same IP it did before, so I know how to connect to it.

Any device without a reserved address is allocated a DHCP IP higher than .100, making it stand out in a network scan.

This works very well for me, I certainly don't have to exchange "IFF" messages to know who is who.

My recommendation is to always set a fixed ip for sensor/controller devices. This is because if your router fails (or other device you are using to deliver DHCP), you may be stuffed for your whole network. Same reason it is best to use IP addresses and not DNS names for them.

I've been caught out like that before.

However, you can use DHCP to supply a fixed IP (by MAC address) and this might be an acceptable alternative - until you have to replace your router and then it goes to pot until you can reconfigure it all again.

I use fixed IP's via DHCP for desktop/laptop/mobile devices with known MAC addresses. But for ESP's and similar embedded devices, I define the fixed address in the device itself.

I have set-aside address ranges for DHCP and for manually fixed addresses. But I also maintain a global context object with a table of all network devices. It is a mix of auto-discovered devices using a CRON-based BASH script with additional descriptions added manually. This lets me check if unknown devices have been on the network at any point and when the network discovered them.

I use MAC addresses as that then stays with the Device. I must admit, I tend to use the Router to define the static IP and have ranges for 'types' of device, my light operating devices being one of them.

I am afraid that my record of MACS and Devices is a spreadsheet!!

Same technique used here. Here's one example of a block of my IPs...

Note: Some routers limit the number of address reservations (mine has a limit of 32).

Generally I just use ddns, avahi, bonjour, mdns (depending on operating system/device) - eg sudo apt install avahi-utils on Pi. So then I can just use hostname_of_thing.local to find any device by name, no need for reservations, having to remember ip numbers, etc.

Hi folks.

Ok, to reply.
(As best I can)

Oh, I use PiHole as my DHCP.

@jbudd
No, I assign the IP address by their MAC address.

@TotallyInformation
That is what I am doing now.
But am not sure it is...... Yeah, that's where it gets confusing.

(------ now to just a general reply to all --------)

A bit more on what I'm doing and why.
(These IFF messages)

When a machine (originally) connects the MQTT message (SOL - Start Of Life. Was SOM, but anyway)

That broadcasts that THAT machine is connected to the network.
Used to identify if the network goes down. Me being anal. It shouldn't happen, but WAY BACK, I was just playing with the idea and it kinda became part of the system.

Given each machine had/s a FIXED IP address, the indicator starts to show me the device is seen.
Every 20 seconds that machine transmits health information back to MQTT and it is displayed.
CPU load, and Temperature.

These messages arriving confirm the machine is working.
If those messages aren't received for a certain time, the machine is marked as HUNG.
It can still be PINGed but isn't talking to anyone. (NR may have only hung, but...... I can only do so much. Anyway.)

IFF is something I introduced to get the IP address of the GPS when it connects to the WiFi network.
The reply sends the device's name and IP address.
Leaving things as they are (fixed IP) I would receive that message and replace the IP number with the 3 letter device name on the dashboard.

When a new MQTT device connects and a SOL message is received, an IFF message is sent out.

As is, the existing UI has 8 positions for such devices (RasPies)
But they also have ASSIGNED IP NUMBERS.

If I do to dynamic (though of course once assigned; they should be kept) I have 128 addresses on the network.
(/25, not /24)

So it is a bit hit and miss getting it to show the relevant 8 for the devices.

I kind of get/appreciate I am probably going to have to rewrite the entire front end if I want to use the existing 8 with DYNAMIC IP ADDRESSES.

Thoughts:
Originally I would PING each of the addresses to detect them.
But it became painful if/when I added new devices. I would have to append the addresses being pinged, then search for the specific addresses to indicate the device's status.

nmap is a lot cleaner and it doesn't need the ip address list being edited every time I add a new device.
Yes, I still need to switch the replies. But that is only ONE point to edit, rather than TWO.

But the existing switch is based on the IP address.

I guess I should/could use the device name.
Then it doesn't matter what the IP address is.

This way I am limiting the range with the name.
Then it could be any of the available and not fixed to any 8 fixed numbers.

PiHole.
Yes, I have had some quirks with things - I'm not the brightest.
But I guess I do need to keep the PiHole machine's IP address fixed - of course.

Similar to what @dynamicdave showed I have groups in the addresses set aside for certain types of devices.

But others (external) swear by DHCP name assignments and talk to the machine via it's name rather than IP address.

Does that/this help with the confusion I am seeing and what I'm trying to do?

This is what I'm doing, happy to share the script. The script needs to run as root so it runs using CRON. However, the end of the script sends the data back to Node-RED via a web call in the script. It is easy to set up. The data is merged into the master in Node-RED and I have a web page that shows the data. But the master data has additional fields that let me record a description against the entry as well. Noting that some devices may have multiple entries, having multiple network connections (such as a Pi with both Wi-Fi and wired connections).

For embedded devices, I would send the IP and device name to MQTT on startup as a retained message and then just a timestamp thereafter which makes it easier to see if/when the device stopped sending (I used to have regular crashes on ESP8266 devices running Tasmota or ESPEasy which is why I switched to ESPHome which seems a lot more reliable). This way, you have all the info in MQTT.

Dave's use of bonjour, etc might also work but if the service fails for any reason, you will struggle to find the IP addresses of your devices - ask me how I know!

Thanks.

The IFF is only sent by the RasPi devices and Arduinos that can handle the message.

Any other device is not really possible as I can't get into the MQTT to send the desired message.

I also only send the IFF if/when a new device connects and sends MQTT messages.
(Via the SOL message)
I don't know if I could cheat and include the IP address in that too, which could/may make my life a bit easier.

None of my devices are both wired and wifi on the same network.
(Well, not officially. If the WAP RasPi locks up and can't connect to the WAP, I plug in the network cable and re-establish the wifi connection. Beats rebooting. :wink:

[quote="TotallyInformation, post:8, topic:100821"]
For embedded devices, I would send the IP and device name to MQTT on startup as a retained message and then just a timestamp thereafter which makes it easier to see if/when the device stopped sending (I used to have regular crashes on ESP8266 devices running Tasmota or ESPEasy which is why I switched to ESPHome which seems a lot more reliable). This way, you have all the info in MQTT.
[/quote]

Interesting.

That would be another huge rewrite of how things work.
Not saying it is bad.
But that is a big thing to do.

I'd prefer to not start using/introducing other broadcast systems (bonjour, etc) unless really needed.
The last bit... I'm guessing you have been down that rabbit hole.

nmap should work.
I've made a subflow that maps my vlans and spits out the results to different outputs for each vlan. Kinda helps with parsing. (I think. But it may not, as a switch node would do most of what is in the subflow anyway) :wink:

This is one of the parts of the output for one specific device:

{"delay":20000,
"topic":"192.168.17.23",
"_event":"node:6437aa0c.5cca1c",
"payload":"On-line",
"rc":{"code":0},
"parts":{"id":"2ac2d82e69a55e6e",
"type":"string",
"ch":"\n",
"index":11,
"count":21},
"_msgid":"5d92eeec79106189"}

I seem to remember if I do a sudo on it, I also get the names.

I am just wanting to get a better understanding of the work needed to redesign the code so after an IFF message is sent and the reply received: the IP number on the dashboard is changed to the name.

Ah, I assumed you were using custom firmware on other devices. One of the nice things about ESPHome is how you can set up configuration fragments using YAML files that you then include into your device config. It means that you can easily standardise nearly everything even if the device is quite a different beast.

But if you can't customise the firmware then nmap remains a good option. I forgot to say that I created a custom MAC address lookup table which helps identify the make of devices connected to the network. The first few digits of the MAC are assigned to specific manufacturers. So generally not hard to identify, for example, anything based off an ESP device.

My home server is wired via a switch to the router and is incredibly reliable. But my separate Wi-FI AP is not so reliable. I now have a Wi-Fi controlled plug on the power for the AP and Node-RED resets the power if the AP goes offline for more than a few seconds. It used to be annoying to reset since the AP is power-over-ethernet so it was hard for the rest of the family to know how to reset it. I've also had the AP go offline when we were on holiday. Meaning that I couldn't monitor things at home which I don't like. Now, if I loose connectivity to my ESP sensors for more than 5 minutes or so, I know there is a bigger problem.

I similarly have occasional issues with our outdoor camera and have the same arrangement there, the wi-fi plug is controlled by Node-RED and resets the camera automatically.

Well, it shouldn't be that hard. But of course, I don't know your flows.

Assuming that your dashboard is driven by a source context variable in the form of, lets say, an array of objects, it is simply a matter of feeding the IFF name into that array. I'd do that in a function node. Read the entire array, filter to the IP address then update the name. Write back the array.

I would also make sure that the array uses the IP address as the name by default. That way, you only need to display the name in your Dashboard. You get the IP if no actual name is available but the name if one has been received. No front-end processing needed.

Alas, I hadn't thought of doing it that way.

The existing is like...... (How long have I been here?) 10 years old.

I made/wrote the structure way back then and it is not done the way you described.

I may look at that idea a bit more and how to do it that way.

ESPHome is soon going to be used, but just now.... Not.
Not sure if that is making life hard for myself or not just now.

The WAP is fairly good now. Had all sorts of problems at the beginning.
But after some painful things, it is pretty good.
Though the fall back is being left there Just in case.
At worst, I lose the display (8 RGB Led strip).

I have a Tasmota powerpoint which is used/needed daily. (Plant waterer)
But it sems to find itself most of the time.
Yes, the default name/s would be the IP addresses and overwritten on reception of an IFF message.

Thanks.