Open andybak opened 4 years ago
May have to assign 32bit GUIDs with a 'device manager' custom code in RPi. Could you create python code for this? In C# it is this: https://www.c-sharpcorner.com/UploadFile/prasoonk/guids-in-C-Sharp-and-net/ The IDs could have simple aliases or nicknames like OR1, OR2, OR3 etc
Yeah GUIDs are a good solution. The question then becomes "when do we generate a new GUID?"
Is this a good approach?
Only tricky bit is undoing (2) or associating a new device with an old one. How important is this? For the present is 1+2+3 above sufficient?
What about simply using the MAC (Media Access Code) of the Pi. The MAC of the logging device is unique and easy to extract. (In fact there are two - one for WiFi and one for the ethernet port). There is very little risk of this being spoofed. These could be kept on a small database. I have the MAC addresses on stickers on my collection of Pis as it makes them easy to distinguish. It would be easy to have these barcoded/QR coded, scanned and associated to a 'human friendly' form on the server.
MAC ID of RPi sounds like a good unique ID to use. We also need to allow friendly aliases like 'Anaesthesia workstation OR1', OR2 etc Mappings are stored by a 'Device Manager' in RPi and Django. ID is for internal use, while users 'associate' or 'disassociate' their devices with the current anaesthesia chart using user friendly aliases.
A dictionary stored as a config file would be the simplest solution as the config shouldn’t need to be altered very frequently. However if we find that we need more flexible changes at a user level then we might have to write a small script to manage it.
Also, I notice that for the Pi’s that I have, the two MAC addresses (one for WiFi and the other for Ethernet) are identical apart from the leading character so we could easily be agnostic about whether the data arrives by Wired or wireless connection.
The only thing that distinguishes data logged from different devices is the name set on each device.
It's fairly easy for multiple devices to have the same name which could lead to data being mistakenly attributed to the wrong patient.
This issue is for discussion and planning as the solution might involve VsServer, VsCapture or human factors.