Reliably track robot identity across renames

[SyntaxColoring]

Overview

The robot discovery system currently listens for robots on the network and keeps track of them by their IP addresses and human-readable names.

This is problematic because both of those things are transient. IP addresses can change as DHCP leases expire, and users can rename robots.

So, for example, the Opentrons App has no reliable way to distinguish between:

• A robot's name changing from A to B.
• The A robot going offline, and then a different B robot appearing for the first time.

Which can cause the UI to present things in a confusing way.

In certain cases, the Opentrons App might be able to handle this heuristically. For example, if it is the thing that triggered the rename from A to B in the first place, it can know that the "new" robot called A is really the same thing as the B robot that just disappeared. But this can't hold up in the general case because robots can change their names under command from other clients, or even on their own (to automatically deconflict with other devices on the network). And it would be prone to timing-related fragility.

So, the Opentrons App needs a way of tracking robot identity that's independent from names and IP addresses.

Acceptance criteria

• The Opentrons App (or the discovery client?) can distinguish between a robot's name changing from A to B versus the A robot going offline and then a different B robot appearing for the first time.
  • For example, it should not leave behind a duplicate entry in the Devices list for the old robot.
  • This should hold even when the robot's name changed on its own, without explicit action from the user.
• The Opentrons App can (or the discovery client?) can distinguish between two physically different robots that happen to have the same name.

Implementation options

We can have the Opentrons App and discovery client use some new form of robot ID. Options:

• The robot's serial number, which is already accessible over HTTP.
• The mDNS host (<hostname>.local). With the way the robot software is currently set up, <hostname> is the robot's serial number, when everything is working correctly. So this should be functionally equivalent to that.
• Some new opaque identifier string—call it machineId for the sake of discussion—that we would expose over HTTP.
  • We have several good options for this on the robot side, including MAC addresses or the systemd machine-id.

[mcous]

I like machine-id for this. A problem is that we want a local dev server to be relatively transparently available in the app, but that seems relatively solvable to fake with the dev server (e.g. by dropping something in ~/.opentrons)

[SyntaxColoring]

Another question is exactly how we should expose this ID.

• Reading it by HTTP polls. I think we need this in order to support the case where mDNS isn't involved in robot discovery at all, and the discovery client is just polling a static list of IP addresses.
• Reading it as part of receiving an mDNS advertisement. I'm not sure exactly how necessary this is, but it could help keep track of a robot's identity when the robot's robot-server and update-server are unreachable. mDNS and Avahi do let us tack a small amount of arbitrary data onto the robot's advertisements (as a TXT record), but I'm not sure if our client-side mDNS library supports parsing it out.

[mcous]

Ideally, we'd have this bit of information present in all three sources. Less ideally, I think it's workable if it's missing from mDNS

[SyntaxColoring]

Migrated to RSS-489.