tries to solve the issue with zeroconf

[pepelisu]

using here hostnam+".local" does not work all the time
The loop while is not protected against permanently being stuck, without time.sleep(), resources could go to 100% in cpu and maybe block the rpi.

[ggilestro]

I am a bit concerned about that while loop. If the ethoscope reboots in an environment that is without a network what is going to happen? Tracking will not resume until an IP address is detected, right? Can you check before I merge this? Perhaps it gets out of the loop immediately returning 127.0.0.1 ?

[pepelisu]

I thought that it was exactly what was happening until now if not internet or IP assigned. The loop should have a failsave, for example if no IP after 1 or 2 minutes then return with 127.0.0.1.

In my case now, if I disconnect from the network it keeps giving me the last IP (maybe until the lease ends), In a virtual machine I am getting 127.0.0.1 after disconnecting the adapter.

[pepelisu]

Also I have another issue, because zeroconf is registered with an IP address. It happens that when an ethoscopes losses internet and dhcp server gives another IP after reconnecting, then the service is wrong registered and it does not update on the node. The ethoscope appears again offline (when in fact is online and tracking, but under other ip address)

Ethoscope backup needs to be restarted or it will not pick up the changes. I think the next step here is to redesign the network based on separate services from tracking, like you said, and make a more robust zeroconf implementation.

[ggilestro]

Yes - of course. The while loop is my fault :)
I've included your changes in this commit: 4e8e2c2

There is also a failsafe mechanism that leaves the loop after about a minute.