Device IDs and their properties

Since this came up recently: Here’s a small summary of how 'device id’s work when using the info-beamer API.

When your initially set up a new SD card, the resulting operating system on the card doesn’t have an identity yet. You first have to insert it into a Pi and boot up the Pi using that card. When the OS first starts it will create a random internal identifier for this installation and persist that on the SD card. This identifier is not relevant for any automation, so it has been removed a while ago from any API calls regarding devices.

The device will then contact the info-beamer backend and show an 8-digit PIN on its display. Entering this PIN creates the connection between the device’s internal identifier and a newly created ‘device id’ on the info-beamer backend and thus registers the device for being used through the dashboard and API. All API calls concerning this device then use this ‘device id’.

A ‘device id’ is stable, aka doesn’t change, while you keep using the SD card in the Pi it has been registered with and can be used to identify this single installation. When you remove the SD card and place it into another Pi, the internal device identifier is invalidated and the SD card will behave as if it were completely new and placed into a new Pi hardware. You then have to follow the steps outlined above to register the device again. Note that this will create a new ‘device id’!

What this means:

  • You cannot move SD cards freely between difference Raspberry Pis: Doing so will invalidate the stored internal hardware identifier on the SD card and you need to register the Pi again to see it in the dashboard. This will create a new ‘device id’.

  • You can have spare SD cards, but only explicitly for individual Raspberry Pis and doing so as follows is not recommended (see next section for a far better alternative):

    • After registering a first info-beamer device, take out its SD card and do !!not!! place it into another Pi.
    • Take a second SD card and register a second info-beamer device.
    • You’ll now have two different info-beamer devices with two 'device id’s showing the same ‘serial number’ on the dashboard. One will be shown as offline (the one laying dormant on the removed SD card) while the second device is online.
    • If the second SD card dies, you can swap it out with the other card.
    • This will then show this first device as online again.
  • A better method of creating spare SD cards is to use the connect-key feature. Doing so allows you to prepare an SD card that, when placed into a Pi, will allow that Pi to self-register as a new info-beamer device in your account. When that happens and a device with the same Pi serial number already exists within an account, the assigned content settings will be transferred over to the new device. This will usually result in the device showing the same content as assigned to its previous SD card.

  • You cannot reuse info-beamer 'device id’s! Once you delete a device from your account, the ‘device id’ is gone and will never be reused. The same happens when you move the SD card from one Pi to another Pi. This will invalidate the indentifier stored on the SD card and thus the corresponding info-beamer device shown in the dashboard will never be online again and can be removed from your account.

In summary: A ‘device id’, as used by info-beamer, identifies a specific OS installation on a single Pi and SD card. Replacing either of them in case the SD card or Pi dies for some reason will require you to register a new Pi/SD combination again as a new info-beamer device with a new ‘device id’. If you need a stable identity on your own backend for billing or similar purposes, it is thus recommended to not directly use the info-beamer ‘device id’ as an identity. Instead only refer to the info-beamer ‘device id’ but allow updating that in case hardware changes have to happen.