How does OctoPrint handle choosing the Printer port, and can I re-use this?

stringsonfire · April 6, 2020, 8:41am

OctoPrint lists possible ports for the printer, allows the user to choose one, and remembers this moving forwards,

I'd like to do the same in a plugin, this time to detect ports for sensors, allow the user to select/map sensors, and remember this moving forwards.

Before attempting to re-invent the wheel, it would be helpful to understand how OctoPrint does this, and if there's anything I can safely reuse.

jneilliii · April 6, 2020, 2:32pm

This will be in the printer/comm layer stuff. If you look here is what it's doing for connection logic.

jneilliii · April 6, 2020, 2:38pm

But the real guts of the autodetection is here.

foosel · April 6, 2020, 3:39pm

Don't look to closely at this, these guts will be gutted (ba-dum-tss) for 1.4.1.

In general, I don't think you can really reuse anything there... The only thing that comes to mind is listing serial ports, but that's probably it, and that might find you more than you want due to additional ports defined by the user:

github.com

OctoPrint/OctoPrint/blob/5596daf34668b90fa851ff2b3b0f1730413c7d69/src/octoprint/util/comm.py#L162


  * ``id``: id of the extruder or which the position is reported
  * ``value``: reported position value
"""


regex_firmware_splitter = re.compile(r"\s*([A-Z0-9_]+):\s*")
"""Regex to use for splitting M115 responses."""


regex_resend_linenumber = re.compile(r"(N|N:)?(?P<n>%s)" % regex_int_pattern)
"""Regex to use for request line numbers in resend requests"""


def serialList():
	baselist=[]
	if os.name=="nt":
		try:
			key = winreg.OpenKey(winreg.HKEY_LOCAL_MACHINE,"HARDWARE\\DEVICEMAP\\SERIALCOMM")
			i=0
			while(1):
				baselist+=[winreg.EnumValue(key,i)[1]]
				i+=1
		except Exception:
			pass

Just sticking to globing the files should be the easiest approach really.

jneilliii · April 6, 2020, 7:22pm

LOL, that's funny.

simpat1zq · April 6, 2020, 8:07pm

@foosel, I'm not sure if you are too far along in this rewrite to take suggestions, but would it be possible to have an option to specify the serial port using the "/dev/serial/by-id/ID of Device" path?

The reason I ask this is that I'm running OP on a PC with Hassio, which has a Zwave stick and a Zigbee stick in there. Both those things are accessed by the by-id path in Hass. That makes it so that when the computer reboots, it doesn't matter what ttyACM# gets assigned to each device(which appears to be random). It would be about 10 seconds of extra setup when you first setup OctoPrint, but it will by 100% accurate from then on unless you change printers.

stringsonfire · April 6, 2020, 8:24pm

That's actually why I asked this question, I assumed there would be some sort of smart cross-platform way to remember the correct device between restarts and with other devices added, even if the device is physically moved to a different port - this becomes really important when you have a number of sensors plugged in

foosel · April 7, 2020, 8:13am

Out of scope for the "burn it with fire" fixing of the port auto detection that's scheduled for 1.4.1, but definitely something I can still take into consideration for the general comm layer rewrite (the new connection scheme in there is flexible enough for something like this I think).

stringsonfire · May 2, 2020, 3:54pm

Looking into this at the moment, it would be super helpful if some of this functionality could be extended for use by plugins.

For my use case, I'd like to:

Let the user see all available COM ports in my plugin settings, with extra info to identify what's plugged in, so that they can select one or more for the plugin to connect to
Store the selected device/port, and use it for collecting sensor data
Check that the device is still present after restart, and safely handle when it isn't
Prevent the user from accidentally selecting the Printer COM port
I'm sure I'll think of more edge cases that should be handled...

Looking at get_connection_options(), it looks like the fundamentals I'd need for this are already in place, and I could override them if needed (for example, if I'm dealing with a sensor that only handles a particular baudrate subset, I could just override that) and leave the rest). I won't touch any of this for now, as you said it's going to burn, but for future consideration this would sure be helpful.

For now, I'm just going to use PySerial list_ports to spit out a list, let the user pick one, and hope it's still there later. It feels like building proper handling of serial devices for one plugin is a bit overkill, there must be other plugins that could make good use of this as common functionality.

What do you think? Could be an official "SerialDevicesManager" plugin installed as a dependency by other plugins that use sensors?