Not sure if there is a way to do this, but figured I would ask here. Does any of the plugin developers or @foosel point me in the direction of a call that would return the connected printers serial number if it exists?
I looked through the reprap gcode page, and could only come up with M115. On my machine it reports a UUID, but on my machine it reports the following: UUID:00000000-0000-0000-0000-000000000000
I'm not sure if that's supposed to be the UUID of the firmware, or of the printer. Not that it's a real UUID anyway. This is not very helpful I'm afraid 
Edit: For clarity, I ran M115 on an MK2S
I'm just curious about your idea/use case 
Here's mine, for what it's worth. I note that my printer's actual serial number is "charming-pascal", its default hostname.
Send: M115
Recv: FIRMWARE_NAME:Marlin 1.1.7-C2 (Github) SOURCE_CODE_URL:https://github.com/Robo3D/Marlin-C2 PROTOCOL_VERSION:C2 MACHINE_TYPE:RoboC2 EXTRUDER_COUNT:1 UUID:cede2a2f-41a2-4748-9b12-c55c62f367ff EMERGENCY_CODES:M108,M112,M410
Google'ing that UUID gives me 208 hits so it can't be unique to my firmware instance. Since the machine type is a Tarantula on the first hit (which is using this identical UUID), I have to assume that Robo 3D didn't re-issue anything when they forked the firmware for their own version.
doh! as marlinfw says:
A suitable unique ID can be generated randomly at uuidgenerator.net. Some host programs and slicers may use this identifier to differentiate between specific machines on your network.
and for data collection, here's M115 from my little MP Mini Delta:
Send: M115
Recv: NAME. Malyan VER: 4.3 MODEL: M300 HW: HG01
Recv: CLK:EXT BUILD: Jan 27 2018 10:40:29
It doesn't respond to M408. Even better, sending M115 P1 or P2 crashes it (kills the serial).
prusa mk3 M115, after adding some manual linebreaks for readability. Again it doesn't respond to M408.
Recv: FIRMWARE_NAME:Prusa-Firmware 3.4.0 based on Marlin
FIRMWARE_URL:https://github.com/prusa3d/Prusa-Firmware
PROTOCOL_VERSION:1.0 MACHINE_TYPE:Prusa i3 MK3
EXTRUDER_COUNT:1 UUID:00000000-0000-0000-0000-000000000000
@tedder42 It's really sad what we accept from these 3D printer manufacturers these days. I had to educate them about OctoPrint's config.yaml UUID code. Before me, they were sending out 2 million printers with all the same UUID in its hotspot mode.
In Marlin, the UUID you get from M115 is hardcoded into the firmware:
It seems to be meant to identify the printer-type, not individual printers.
1 Like
Are you referring to the discovery plugin's setting?
discovery:
publicPort: 80
upnpUuid: b3cf061d-c49a-4af0-81d9-4caece207152
Is that unique for every install?
@jneilliii Yep. Imagine Robo 3D shipping two million printers which all broadcast the same UUID and now imagine a school or public library or makerspace which has more than one. <_<
(The microSD configuration server which I developed for them makes an API call out to the UUID generator.)
Yeah, that's crazy. I don't think that pulls from the UUID of the firmware though, seems like it generates one automatically. Was Robo3D deploying cloned config.yaml files with their deployments on an integrated OctoPrint instance?
They forked the OctoPi image and then basically everyone in support was kind of doing their own thing and the process wasn't fully understood. The main programmer back in software didn't understand and the head of software wasn't a software guy.
I completely read through the docs for that, btw. There is both the UUID for discovery and the API key itself. Nuking both should result in OctoPrint generating one at startup but for better documentation, I did it this way to know what it would be when it landed at the customer's printer.
That's also how the initial version of the "PrusaPrint" image ended up with the same UUID, API key, SSH host key, password salt and cookie hash 
Crap, guess I'll have to generate my own serial numbers then. Looks like I could just use the str(uuid.uuid4()) as a simple fix. Thanks for the warning guys as I could see my future plugin going out and it breaking horribly with these duplicated UUID's all over the place.
Use the MAC address of the Raspi's wi-fi or Ethernet adapter. Probably easier, right?
That might be an option actually. I'm already retrieving that mac address for other parts of the plugin so using that as a serial number isn't a bad idea since they will typically be unique, assuming a hacker isn't using his octoprint and doing mac address spoofing.
It's guaranteed to be unique. You could hash it if you wanted (still unique); this would be more difficult to deduce as a hacker.
There's a clever algorithm lately in the cryptocurrency wallet retrieval space which converts a hex string into an array of words, if you wanted to make the serial number friendlier.
I literally asked Prusa and followed up until they told me the only way to identify a Prusa serial is by a sticker on the unit. If Prusa can't manage, we can't expect China to do more 
So back in the day (well over a decade ago) I worked for a big internet retailer that rhymes with Amazon. We were happy when we had a 'mobile VPN' solution, rather than a hardware VPN that we installed at our houses. Working out of coffeeshops would be a great improvement.
It was basically an embedded linux box that velcroed to the back of a laptop. It had two inputs: USB (for power), and Ethernet. Why ethernet?! You can network via USB.
..the answer is that USB doesn't give any sort of unique identifier. But a hardware MAC does, to a decent extent, so you could satisfy the old idea of three factor auth (something you have, something you know, and, uh, the third) that was helpful for early PCI compliance.
TLDR: this is why I respect the security practices of that big retailer/cloud in the sky more than any subsequent company I've worked at. cc @camerin_hahn for no reason.