I have a device on the network that is a Raspberry PI.
This equipment has a little program in python that sends data to the MQTT server.
I would like to know through my system developed in NODE-RED that this equipment is connected to the network.
Of course I'm only going to use this in case it's not sending data to MQTT, because if it's sending data... I don't need to discover it on the network.
OK, so you are trying to identify the situation where it is on the network, but not connected to the MQTT broker for some reason. I generally use the ping node for that type of scenario.
A NR flow on remote Pies can send a "heartbeat" MQTT message every 10 seconds say.
A flow on the central NR / mosquitto server sends a notificaton if no message arrives for 20 seconds.
But the MQTT node's "close" and "will" offer the same notifications.
If I shutdown the remote Pi, my main server gets the "close" message.
If I just pull the plug, after a timeout period it gets the "will" message.
Somehow it's hard to trust these messages though so I generally use the heartbeat approach.
Perhaps we are indeed suffering from lack of a common language. Apologies if I'm getting confused.
I am not focussed on the MQTT communication, it just happens that MQTT seems to offer what you are seeking.
Here's how it works:
The birth, close and will messages are all sent when the underwater device first connects to the MQTT broker. So these are all safe in the broker up on dry land.
If the connection to the submerged device is lost, either the close or will message (depending on how graceful the disconnect was) is passed on to subscribers.
If Node-red receives a message on (for exampe) topic /diver/birth, it knows that there is some Raspberry Pi online.
If it receives a message on /diver/disconnect or on /diver/broken, it knows that the Raspberry Pi is no longer online.
NB You have to ensure that nmap has an up-to date list including all the MAC address ranges belonging to Raspberry Pi Trading and Raspberry Pi Foundation.
Ping the IP address revealed by (1) ping -c 2 192.168.1.28
PING 192.168.1.28 (192.168.1.28) 56(84) bytes of data.
64 bytes from 192.168.1.28: icmp_seq=1 ttl=64 time=370 ms
64 bytes from 192.168.1.28: icmp_seq=2 ttl=64 time=2.13 ms
--- 192.168.1.28 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 2ms
rtt min/avg/max/mdev = 2.131/186.178/370.225/184.047 ms
Ping the hostname. (Needs Apple Bonjour service on the computer sending ping) ping -c 2 CrucialPi.local
PING CrucialPi.local (192.168.1.12) 56(84) bytes of data.
64 bytes from 192.168.1.12 (192.168.1.12): icmp_seq=1 ttl=64 time=2.38 ms
64 bytes from 192.168.1.12 (192.168.1.12): icmp_seq=2 ttl=64 time=5.03 ms
--- CrucialPi.local ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 2ms
rtt min/avg/max/mdev = 2.380/3.702/5.025/1.323 ms
MQTT birth, disconnect and will messages from python on the remote device.
MQTT birth, disconnect and will messages from Node-red on the remote device (bypassing unreliable python script). The message content could be the IP address to be used for option 2.
Heartbeat messages from Node-red on the remote device.
No doubt there are many other possibilities.
Note that the Raspberry Pi has a hardware watchdog which can be set up to reboot if the network goes down, thereby resetting your python script
Then I think you should revisit your Python code, It is for sure possible to write a Python program that detects network down and then reconnects and continuos when network is back
NMAP is extra software that can be installed at the OS level using apt. I run a BASH shell script on a CRON timer that runs nmap and uses its XML output option to create a temporary file and then I call a node-red http-in endpoint to trigger a flow that reads the temporary file and process it in node-red. I can share the script if needed. I use it to keep track of all of the devices that appear on my network.
The exec node simply runs an OS command. Much as you would at a terminal command line prompt.
Much has been written about using Watchdog on the Pi, there are loads of tutorials.
I have been using your original flow with some success, but I think I read that you have updated it. Any chance of publishing it (I have the nmap script which is also working well already running)