How do we identify doors and other IoT devices?

[th0mas]

We need a way of syncing the edge devices on the network (e.g. Locks) with the main "hub" authentication server. E.g. how will new devices added to the network know if they're an internal door or an external one?

We could:

• Create a startup "handshake" procedure where the "smart locks" contact the hub with a unique ID and get their configuration. We'd need to work out what "Unique ID" to use here.

• Locks stay "dumb" and don't know what type of door they are. They wait for 2FA if told to by the hub. This could make adding a GUI complicated as locks would have no internal "state"

• Hardcode this information. This makes firmware updates harder as each lock type has a different firmware config. Probably configured using environment variables at build time.

• Create a new firmware for each lock type. This works well for internal/external doors but not if we want to add "groups" or door specific access later, as we'd end up with too many firmware images to manage.

The last three options would require a method to pre-register devices with the hub server before they're deployed, while the first method this would be achieved by the initial handshake where a device would be registered if it didn't already exist

It's worth properly thinking about this and doing it right first time as whatever method will take a lot of time and be difficult to change later.

[th0mas]

@nelsonic have you got any thoughts on this?

This is currently a "blocker" as I need to work out how to connect the individual devices to the hub

[th0mas]

As far as unique IDs are concerned - Raspberry Pi's by default use the CPU serial number and is easily accessible within nerves.

Moving forward, Nerves Hub allows us to set device identifiers as well.

[th0mas]

With the handshake method, we could setup a Phoenix channel between lock and hub which could make 2FA easier and allow for monitoring of device health etc.

[nelsonic]

@th0mas right now we only have the concept of internal and external doors but you're right in the near future we will have more types of device (at least two more). For now, given that we will have fewer than 1k devices, I would just have device_type: Int and have regular doors as device_type=1 and higher security doors as device_type=2 We can always refactor/migrate it to a more complex system later. As for using the unique reference of the Raspberry Pi, that seems reasonable. We will only need to associate them to the system once.

[th0mas]

It might be worth making a handshake system now, as we probably need to start with three device types:

• 1 - Internal door
• 2- External door
• 3? - Pairing station

Or at least be able to tell doors to go into a pairing mode - which will require two way communication

[nelsonic]

@th0mas yeah that sounds/looks good. We might be able to re-use one of the internal doors as a pairing station. But given that the cost of having a dedicated pairing station isn't very high, let's make it a separate thing (as you suggest). 👍

[th0mas]

Implemented a Websocket pairing system including a handshake. This fixes all of these problems

[nelsonic]

Great plan! 💡