Is there a possibility to suppress AUTO as port option for printer connect?
Background: there are some other devices connected to the Pi where OctoPrint is running. Not only a 3D printer. With Octoprint / serial rules and system udev rules it is configured, that only the port, the printer is physically attached to, is available as "connect to" destination. All other ports are not shown / available.
Unfortunately the AUTO option is still shown and if one commands "connect and use AUTO -> search the printer, it happens that OctoPrint e.g. send commands to the milling machine, what I'm not amused about.
You should just be able to change it to the printers port, then press 'save connection settings' and it will always use that, not auto.
Alternatively blacklist the ports that AUTO should not consider part of the list of potential printer ports, option for that is in the serial connection settings.
all this I did already.
The fallback to AUTO happens, if the configured port is not active on OctoPrint start, because printer is not switched on yet. If OctoPrint would follow the settings in this case, there is no port at all available.
So what you are saying is, it doesn't follow these settings? Then open a full bug report please.
Thanks for the reply.
I don't think it's a bug! It seems more to be an 'resolve impossible DAU settings-feature'.
To make it clear generally: The developers of specially the OctoPrint kernel earned great respect. It's a great work. Specially the handling of all the plugin stuff.
Sometimes I'm really impressed that the kernel is written so robust that he is not be crashing because of bugs in plugins.
I'm not sure if it isn't a bug As far as I understand you, it is trying to connect to ports explicitly set to not be connected to, when connecting via AUTO. Whether the printer port is available or not in that scenario is not relevant, relevant is that it should only ever even try to connect so such ports that fall into its port patterns and which are NOT on the blacklist. If you are seeing it connecting to ports that you have forbidden explicitly, then it's a bug.
But in any case: thanks for the praise