Random MAC addresses break add-ons

[webmeister]

Describe the issue you are experiencing

HAOS 15 updated Docker to v28. Docker v28 uses a new random MAC address every time a container is restarted. This breaks the assumption of add-ons such as Congatudo to always run with the same MAC address. Can Home Assistant continue to provide static MAC addresses to add-ons to avoid such issues?

What operating system image do you use?

generic-x86-64 (Generic UEFI capable x86-64 systems)

What version of Home Assistant Operating System is installed?

15

Did the problem occur after upgrading the Operating System?

Yes

Hardware details

n/a

Steps to reproduce the issue

1. Set up Congatudo 2024.04 add-on on HAOS 14.
2. Observe that it adds a new vacuum entity to Home Assistant.
3. Restart the add-on.
4. Observe that the same vacuum entity is still present in Home Assistant and can be used to control the device.
5. Upgrade to HAOS 15.
6. Observe that suddenly a new vacuum entity is present in Home Assistant and the old one cannot be used anymore to control the device.
7. Restart the add-on.
8. Observe that yet another vacuum entity got added to Home Assistant.

Anything in the Supervisor logs that might be useful for us?

n/a

Anything in the Host logs that might be useful for us?

n/a

System information

No response

Additional information

No response

[sairon]

@webmeister I have moved this issue to Supervisor, as it's where this should be discussed and eventually handled, even though the regression started with an OS update (and as Supervised installs are affected too if the Docker version is 28.0+).

In my opinion this is something that should be fixed on the add-on side anyway. Even though the MAC was more stable in older Docker versions, it was never guaranteed the same add-on would get the same IP/MAC address, because it depended on the start-up order of add-ons. Since it can change over time as well, relying purely on the MAC address to generate device IDs is broken by design.

On the other hand, it might be possible to ensure that add-ons get stable MAC addresses in HAOS/Supervised - Supervisor could e.g. use container name as seed for a hashing function that would be used to derive the MAC address but even then we need to avoid collisions, and so on. So I'm not sure if it's worth the effort, as we could still run into edge-cases when trying to address the issue you are encountering 🤔

[github-actions[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

[agners]

In my opinion this is something that should be fixed on the add-on side anyway. Even though the MAC was more stable in older Docker versions, it was never guaranteed the same add-on would get the same IP/MAC address, because it depended on the start-up order of add-ons. Since it can change over time as well, relying purely on the MAC address to generate device IDs is broken by design.

Yeah I agree with this assessment. If you need a stable identifier, you can create a UUID and store it in the add-on specific data folder. This allows to track a particular installation of the add-on across reboots and backup restores.

If you need something which is machine specific, then the machine ID is typically the way to identify a certain system. We don't expose that information currently in add-ons, but I've just created #5953 which exposes that information on the Supervisor API, so it would be available for add-ons as well.