A while ago I replaced my ADS-B computer and my receiver. The new equipment is Rpi 4 + AIrspy R2. I kept the unique identifier. The new set-up worked fine, so I did not care that the local IP address showed on my FA web page was wrong. However, I soon found that MLAT was red on the web page, but working fine according to my logs. So I started looking into this and found that the local IP address was in use by another computer and also that the MAC address was that of the other computer. And it was not the MAC or IP address of the computer I had used for ADS-B reception before! It was another RPi which has always been used for weather data. Still everything seemed to work except for MLAT.
To solv this I included “force-macaddress xx:xx:xx:xx:xx:xx” in piaware-config.txt and restarted my RPi 4. For a while everything seemed correct (FA had the right MAC address and local IP address and MLAT was green), but soon the IP address of my weather computer turned up again and MLAT was red. Sometimes it changed back, but later even the MAC address changed to that of the weather computer. (I have restarted the computer and for the moment the MAC address is correct.)
I am surprised that anything is working at all when the MAC address is that of another computer. How can this be corrected?
Do you have a DHCP reservation based on the mac address in your router perhaps ? That would explain why it reverts to the weather Pi ?
If so, maybe adapt it to the new mac address in order to fix this ?
mac address hasn’t been used for piaware feeder identification for a long time. We still send it (mostly to help out in situations exactly like this one!) but the feeder ID is the primary way we distinguish piaware instances.
You have two Pis configured with the same feeder ID:
wxpi is running piaware and reading its feeder ID from /var/cache/piaware piaware1 is also running piaware and has been manually configured with the same feeder ID via piaware-config.
When you have a situation like this, with two feeders with the same ID, you will see confusing results on the stats page because it will reflect whichever one last sent a health update.
Don’t do that - ensure that you’re only running piaware where you expect to be running it (I guess wxpi is not meant to be running it) and ensure that each piaware has a unique feeder ID.
(The only way I can think of for wxpi to have that cached feeder ID is if that sdcard was originally running your old feeder, or if you took a copy of that sdcard as a starting point for a new install. note that if you move a sdcard between hardware without reimaging, the feeder ID effectively follows the sdcard, not the hardware)
Thank you! This explains everything except how it occured!
I have now removed /var/cache/piaware from wxpi and everything seems fine. But what created that catalog on wxpi? It has never been used for piaware, only for wx data. I also checked the Pi I used before for piaware. Luckily, no trace of /var/cache/piaware.
well, wxpi is running piaware, merely deleting the feeder ID cache doesn’t change that, you will want to also stop or install piaware itself.
I don’t know how it ended up on there, but given that the feeder ID matches your long-lived site ID, the most likely explanation is that when you set up wxpi you re-used the old sdcard that already had piaware installed & configured without reimaging.
Well, I ruled that out, so I didn’t check… But you were right! I have now removed the software from wxpi. This must have happened way back in 2019. Unfortunately my memory of that is a bit foggy. I suppose this means that I have had problems for a long time without knowing.
