How PiAware feeders are identified (updated 2017/07/16)

(Updated 2017/07/16 - now applies to all sites)

PiAware feeders are now being identified by a unique feeder ID stored by PiAware, rather than by hardware MAC addresses.

A feeder ID will be assigned when the feeder first connects, and will be stored by PiAware on the sdcard. Subsequent connections will use that feeder ID to identify the site. The main consequence of this is that if you re-image the sdcard or otherwise remove the feeder ID, then subsequently the feeder will look like a brand new feeder and will create a new site.

If you want to retain the same feeder-to-site association when re-imaging, so that the existing site continues to be used, then you can explicitly configure the feeder ID to use. This is a somewhat manual process at the moment:

  • Find the feeder ID that you want to use. You can find this either as the “Site identifier” on the site page at, or from the PiAware logs in /var/log/piaware.log on your existing install. The identifier looks like a series of dash-separated hex digits: 12345678-1234-1234-1234-123456789abc.

  • Configure the feeder ID on the new system: piaware-config feeder-id 12345678-1234-1234-1234-123456789abc

  • Restart piaware: sudo systemctl restart piaware

This also works when replacing hardware (if it is just a Pi replacement, you can just move the existing sdcard over and the feeder ID will be retained)

This now applied to all sites, including sites created before feeder IDs were introduced. Those sites have had a feeder ID assigned retrospectively.

If you are running an older version of PiAware then the description above is not entirely correct (as older versions can’t store a feeder ID, there is a fixed translation of MAC address to feeder ID that happens on the server side now) but the site still has a feeder ID, and you can migrate to new hardware and keep the site so long as you also upgrade PiAware at the same time and configure the feeder ID.


This is certainly a welcome change. Playing MAC roulette has been a pain since I’ve upgraded Pi’s twice over the last two years and I’m about to do it again.

I hope the new identifier is stored in a simple text file on the boot volume so that one can keep it stored on a PC and copy it easily to the SD Card when necessary.

Thanks for all the good work.


It’s not in /boot but it is just a simple text file: /var/cache/piaware/feeder_id
You can set the feeder-id config option in /boot/piaware-config.txt though.

Ah, well this is annoying, had me scraching my head for ages trying to work this out.

I just swapped my SD card to another Pi and got the new identifier ID (used same wifi dongle) noticed it had created new site (new long ID), i was confused so have now put back to my old Pi with wifi dongle and still got new Id. Ive tried deleting the file you mentioned and also forcing back to macaddress but no luck.

I dont want to lose my old stats and i dont want 2x sites as they are the same, is there a way to reconfigure this to keep as one site with or without new ID

Thanks for any ideas.

EDIT: Old Site: 37789. New Site: 39711

You triggered a corner case by swapping hardware and then trying to go back to a MAC-address-based site. I fixed it by hand this time.

(edit: this case should work a bit more smoothly now; migration of an old site to new hardware won’t prevent using the old site on old hardware)

Thanks obj for fixing that for me, very much appreciated for the quick response.

Im going to do some digging in other posts to see how to delete that site ID now its not needed.


Is there a way to move existing sites yet?
I’d like to replace the RasPi on one of my feeders.
If possible, how would one go about it?

The original post has the instructions but here are the exact commands to grab your UUID

You need to get your feeder ID from your piaware.log file.
“cat /var/log/piaware.log | grep -a feeder”

Follow the rest of the instructions.

Configure the feeder ID on the new system: “piaware-config feeder-id 12345678-1234-1234-1234-123456789abc”
Restart piaware: “sudo systemctl restart piaware”

1 Like

Currently you can only move sites that are identified by a feeder id (see David’s instructions above)
If you have an older site that predates the change to using feeder IDs, you can’t currently move it to new hardware and retain the old site ID.

Very happy to see this implemented. To late to help me (just did a swap a couple weeks ago, and hope not to do another for quite awhile). Thanks for continued improvement to FA.

Hi I have just re-added my original feeder-id to my new card.

is there any way I can remove the the other feeder ID from my account. I cannot seem to see any function setup for this.

You have two sites, 39740 (not currently active) and 40150. They have different feeder IDs. Assuming you only have one receiver, which of the two sites do you want to be feeding data to?

I would like to have 40150 as my site and have the 38740 not listed at all. is there a way to do this?

Is this valid for both Piaware image and Piaware package… ?

(I still think they should be named differently…)



(I still think they should be named differently…)

Accident of history…

You’re already feeding 40150 so you don’t need to do anything more to get that part working.
To hide 38740, it’ll disappear on its own after 30 days of inactivity, or after 48 hours there will be a link on the stats page you can click to disable it immediately.

Thanks for the info.

There a time frame for implementation of this feature?

Six days ago (on April 08, 2017) I tested, and found that one can still move the old site registered before March 20, 2017, to a new Pi and retain the old site ID, by spoofing mac address.

I edited file /boot/cmdline.txt. This file has only one line. At the end of this line, I added (without line break) following:

smsc95xx.macaddr=aa:aa:aa:aa:aa:aa (where aa:aa:aa:aa:aa:aa is mac address of old Pi).

I tried it successfully on (1) Piaware 3.5 image, and (2) Jessie Lt image + Piaware 3.5 (add-on package install).

At which point, as far as piaware knows, it’s still the old hardware.

Do it if you want, but at your own risk.