Try lowercase for the device alias. I know of no other devices which include uppercase characters in them.
Also after rebooting and during troubleshooting, the udev rule should actually create the device tree entry for you: ls -l /dev | grep lrwxrwxrwx
And yet, it's throwing an error to suggest that it can't lock the device.
Quoting myself from the github issue:
Can those of you running into this issue try if it gets solved by this plugin?
https://github.com/OctoPrint/OctoPrint-Remove-ttyS-Ports
It monkey patches the serial list to remove
/dev/ttySentries from the port list again and thus should work around this issue on what seems to be most of the system that so far ran into issues.If this works I'll push it to the repository as a workaround until I have pushed a proper solution with 1.4.1 (hopefully).
Re-installed from scratch and I have my Pi Cam and Touchscreen installed. Everything is up to date. I have PSU Control and Port Lister installed and I no longer have any issues. I've restarted and turned the printer/Raspberry Pi on/off several times and it just works now. No idea why.
Still waiting for feedback here, @5ft24, @kallsop, @kubik256, @Mortimus, would love to get feedback if this fixes it for y'all:
This is working on both my A8 and my Girlfriends Ender 3
Works here too! Thank you 
Machine: Ender3 with SKR E3 mini
Octoprint on Intel NUC / x64 - Ubuntu 19.10 (GNU/Linux 5.3.0-42-generic x86_64)
Update: This plugin also fixed Tasmota autoconnect feature - setup 40-60s delay (for E3 mini) and it works like a charm 
AWESOME 
It works for me, thanks.
Unfortunately it does not solve the problems I have with orange pi zero. Armbian does not create /dev/ttyS ... but there is a virtual serial connected to the USB otg present in the Orange Pi zero /dev/ttyGS0 which probably should also be ignored.
Perhaps it would be the case to create a global pattern exclusion with preset values that the user can however modify in case of need.
If you're a coder and you wanted a quick fix you could fork the work-around plugin and make it do what you need.
Of course I can do it but I could also make Armbian not load the UsbOTG virtual serial driver.
Even more simple I can give up automatic search of the printer port connection and set it by hand on ttyUSB0.
My intent was only to report that the problem is also present with other devices and excluding only ttyS .. it may not be exhaustive.
It would also be possible to take advantage of the "Additional serial ports" field of the settings and exclude from the recognized devices those negated for example
/dev/ttyAMA*
!/dev/ttyS*
!/dev/ttyGS*
Yeah... I did 
your suggestion since it's a good idea.
/dev/ttyG* is not and never was part of the port patterns 
This morning I did a test, I put g_serial in the blacklist so that ttyGS0 is not created.
First the list of tty devices is this :
pi@octopi:~$ ls /dev/tty*
tty tty31 tty55 ttya3 ttybd ttyd7 ttyp1 ttyqb ttys5 ttytf ttyv9 ttyx3 ttyyd
tty0 tty32 tty56 ttya4 ttybe ttyd8 ttyp2 ttyqc ttys6 ttyu0 ttyva ttyx4 ttyye
tty1 tty33 tty57 ttya5 ttybf ttyd9 ttyp3 ttyqd ttys7 ttyu1 ttyvb ttyx5 ttyyf
tty10 tty34 tty58 ttya6 ttyc0 ttyda ttyp4 ttyqe ttys8 ttyu2 ttyvc ttyx6 ttyz0
tty11 tty35 tty59 ttya7 ttyc1 ttydb ttyp5 ttyqf ttys9 ttyu3 ttyvd ttyx7 ttyz1
tty12 tty36 tty6 ttya8 ttyc2 ttydc ttyp6 ttyr0 ttysa ttyu4 ttyve ttyx8 ttyz2
tty13 tty37 tty60 ttya9 ttyc3 ttydd ttyp7 ttyr1 ttysb ttyu5 ttyvf ttyx9 ttyz3
tty14 tty38 tty61 ttyaa ttyc4 ttyde ttyp8 ttyr2 ttysc ttyu6 ttyw0 ttyxa ttyz4
tty15 tty39 tty62 ttyab ttyc5 ttydf ttyp9 ttyr3 ttysd ttyu7 ttyw1 ttyxb ttyz5
tty16 tty4 tty63 ttyac ttyc6 ttye0 ttypa ttyr4 ttyse ttyu8 ttyw2 ttyxc ttyz6
tty17 tty40 tty7 ttyad ttyc7 ttye1 ttypb ttyr5 ttysf ttyu9 ttyw3 ttyxd ttyz7
tty18 tty41 tty8 ttyae ttyc8 ttye2 ttypc ttyr6 ttyt0 ttyua ttyw4 ttyxe ttyz8
tty19 tty42 tty9 ttyaf ttyc9 ttye3 ttypd ttyr7 ttyt1 ttyub ttyw5 ttyxf ttyz9
tty2 tty43 > ttyGS0 ttyb0 ttyca ttye4 ttype ttyr8 ttyt2 ttyuc ttyw6 ttyy0 ttyza
tty20 tty44 ttyS0 ttyb1 ttycb ttye5 ttypf ttyr9 ttyt3 ttyud ttyw7 ttyy1 ttyzb
tty21 tty45 ttyS1 ttyb2 ttycc ttye6 ttyq0 ttyra ttyt4 ttyue ttyw8 ttyy2 ttyzc
tty22 tty46 ttyS2 ttyb3 ttycd ttye7 ttyq1 ttyrb ttyt5 ttyuf ttyw9 ttyy3 ttyzd
tty23 tty47 ttyS3 ttyb4 ttyce ttye8 ttyq2 ttyrc ttyt6 ttyv0 ttywa ttyy4 ttyze
tty24 tty48 ttyS4 ttyb5 ttycf ttye9 ttyq3 ttyrd ttyt7 ttyv1 ttywb ttyy5 ttyzf
tty25 tty49 ttyS5 ttyb6 ttyd0 ttyea ttyq4 ttyre ttyt8 ttyv2 ttywc ttyy6
tty26 tty5 ttyS6 ttyb7 ttyd1 ttyeb ttyq5 ttyrf ttyt9 ttyv3 ttywd ttyy7
tty27 tty50 ttyS7 ttyb8 ttyd2 ttyec ttyq6 ttys0 ttyta ttyv4 ttywe ttyy8
tty28 tty51 > ttyUSB0 ttyb9 ttyd3 ttyed ttyq7 ttys1 ttytb ttyv5 ttywf ttyy9
tty29 tty52 ttya0 ttyba ttyd4 ttyee ttyq8 ttys2 ttytc ttyv6 ttyx0 ttyya
tty3 tty53 ttya1 ttybb ttyd5 ttyef ttyq9 ttys3 ttytd ttyv7 ttyx1 ttyyb
tty30 tty54 ttya2 ttybc ttyd6 ttyp0 ttyqa ttys4 ttyte ttyv8 ttyx2 ttyyc
From here we can see that the only "strange" device is ttyGS0
After blacklisting the result is:
pi@octopi:~$ ls /dev/tty*
/dev/tty /dev/tty41 /dev/ttya0 /dev/ttyc5 /dev/ttyea /dev/ttyqf /dev/ttyt4 /dev/ttyv9 /dev/ttyxe
/dev/tty0 /dev/tty42 /dev/ttya1 /dev/ttyc6 /dev/ttyeb /dev/ttyr0 /dev/ttyt5 /dev/ttyva /dev/ttyxf
/dev/tty1 /dev/tty43 /dev/ttya2 /dev/ttyc7 /dev/ttyec /dev/ttyr1 /dev/ttyt6 /dev/ttyvb /dev/ttyy0
/dev/tty10 /dev/tty44 /dev/ttya3 /dev/ttyc8 /dev/ttyed /dev/ttyr2 /dev/ttyt7 /dev/ttyvc /dev/ttyy1
/dev/tty11 /dev/tty45 /dev/ttya4 /dev/ttyc9 /dev/ttyee /dev/ttyr3 /dev/ttyt8 /dev/ttyvd /dev/ttyy2
/dev/tty12 /dev/tty46 /dev/ttya5 /dev/ttyca /dev/ttyef /dev/ttyr4 /dev/ttyt9 /dev/ttyve /dev/ttyy3
/dev/tty13 /dev/tty47 /dev/ttya6 /dev/ttycb /dev/ttyp0 /dev/ttyr5 /dev/ttyta /dev/ttyvf /dev/ttyy4
/dev/tty14 /dev/tty48 /dev/ttya7 /dev/ttycc /dev/ttyp1 /dev/ttyr6 /dev/ttytb /dev/ttyw0 /dev/ttyy5
/dev/tty15 /dev/tty49 /dev/ttya8 /dev/ttycd /dev/ttyp2 /dev/ttyr7 /dev/ttytc /dev/ttyw1 /dev/ttyy6
/dev/tty16 /dev/tty5 /dev/ttya9 /dev/ttyce /dev/ttyp3 /dev/ttyr8 /dev/ttytd /dev/ttyw2 /dev/ttyy7
/dev/tty17 /dev/tty50 /dev/ttyaa /dev/ttycf /dev/ttyp4 /dev/ttyr9 /dev/ttyte /dev/ttyw3 /dev/ttyy8
/dev/tty18 /dev/tty51 /dev/ttyab /dev/ttyd0 /dev/ttyp5 /dev/ttyra /dev/ttytf /dev/ttyw4 /dev/ttyy9
/dev/tty19 /dev/tty52 /dev/ttyac /dev/ttyd1 /dev/ttyp6 /dev/ttyrb /dev/ttyu0 /dev/ttyw5 /dev/ttyya
/dev/tty2 /dev/tty53 /dev/ttyad /dev/ttyd2 /dev/ttyp7 /dev/ttyrc /dev/ttyu1 /dev/ttyw6 /dev/ttyyb
/dev/tty20 /dev/tty54 /dev/ttyae /dev/ttyd3 /dev/ttyp8 /dev/ttyrd /dev/ttyu2 /dev/ttyw7 /dev/ttyyc
/dev/tty21 /dev/tty55 /dev/ttyaf /dev/ttyd4 /dev/ttyp9 /dev/ttyre /dev/ttyu3 /dev/ttyw8 /dev/ttyyd
/dev/tty22 /dev/tty56 /dev/ttyb0 /dev/ttyd5 /dev/ttypa /dev/ttyrf /dev/ttyu4 /dev/ttyw9 /dev/ttyye
/dev/tty23 /dev/tty57 /dev/ttyb1 /dev/ttyd6 /dev/ttypb /dev/ttys0 /dev/ttyu5 /dev/ttywa /dev/ttyyf
/dev/tty24 /dev/tty58 /dev/ttyb2 /dev/ttyd7 /dev/ttypc /dev/ttys1 /dev/ttyu6 /dev/ttywb /dev/ttyz0
/dev/tty25 /dev/tty59 /dev/ttyb3 /dev/ttyd8 /dev/ttypd /dev/ttys2 /dev/ttyu7 /dev/ttywc /dev/ttyz1
/dev/tty26 /dev/tty6 /dev/ttyb4 /dev/ttyd9 /dev/ttype /dev/ttys3 /dev/ttyu8 /dev/ttywd /dev/ttyz2
/dev/tty27 /dev/tty60 /dev/ttyb5 /dev/ttyda /dev/ttypf /dev/ttys4 /dev/ttyu9 /dev/ttywe /dev/ttyz3
/dev/tty28 /dev/tty61 /dev/ttyb6 /dev/ttydb /dev/ttyq0 /dev/ttys5 /dev/ttyua /dev/ttywf /dev/ttyz4
/dev/tty29 /dev/tty62 /dev/ttyb7 /dev/ttydc /dev/ttyq1 /dev/ttys6 /dev/ttyub /dev/ttyx0 /dev/ttyz5
/dev/tty3 /dev/tty63 /dev/ttyb8 /dev/ttydd /dev/ttyq2 /dev/ttys7 /dev/ttyuc /dev/ttyx1 /dev/ttyz6
/dev/tty30 /dev/tty7 /dev/ttyb9 /dev/ttyde /dev/ttyq3 /dev/ttys8 /dev/ttyud /dev/ttyx2 /dev/ttyz7
/dev/tty31 /dev/tty8 /dev/ttyba /dev/ttydf /dev/ttyq4 /dev/ttys9 /dev/ttyue /dev/ttyx3 /dev/ttyz8
/dev/tty32 /dev/tty9 /dev/ttybb /dev/ttye0 /dev/ttyq5 /dev/ttysa /dev/ttyuf /dev/ttyx4 /dev/ttyz9
/dev/tty33 /dev/ttyS0 /dev/ttybc /dev/ttye1 /dev/ttyq6 /dev/ttysb /dev/ttyv0 /dev/ttyx5 /dev/ttyza
/dev/tty34 /dev/ttyS1 /dev/ttybd /dev/ttye2 /dev/ttyq7 /dev/ttysc /dev/ttyv1 /dev/ttyx6 /dev/ttyzb
/dev/tty35 /dev/ttyS2 /dev/ttybe /dev/ttye3 /dev/ttyq8 /dev/ttysd /dev/ttyv2 /dev/ttyx7 /dev/ttyzc
/dev/tty36 /dev/ttyS3 /dev/ttybf /dev/ttye4 /dev/ttyq9 /dev/ttyse /dev/ttyv3 /dev/ttyx8 /dev/ttyzd
/dev/tty37 /dev/ttyS4 /dev/ttyc0 /dev/ttye5 /dev/ttyqa /dev/ttysf /dev/ttyv4 /dev/ttyx9 /dev/ttyze
/dev/tty38 /dev/ttyS5 /dev/ttyc1 /dev/ttye6 /dev/ttyqb /dev/ttyt0 /dev/ttyv5 /dev/ttyxa /dev/ttyzf
/dev/tty39 /dev/ttyS6 /dev/ttyc2 /dev/ttye7 /dev/ttyqc /dev/ttyt1 /dev/ttyv6 /dev/ttyxb
/dev/tty4 /dev/ttyS7 /dev/ttyc3 /dev/ttye8 /dev/ttyqd /dev/ttyt2 /dev/ttyv7 /dev/ttyxc
/dev/tty40 >/dev/ttyUSB0 /dev/ttyc4 /dev/ttye9 /dev/ttyqe /dev/ttyt3 /dev/ttyv8 /dev/ttyxd
e here
According to the code you posted the only match is ttyUSB0, the problem is that still fails autodetect.
Changing monitoring state from "Offline" to "Detecting serial port"
Serial port list: ['/dev/ttyUSB0', u'/dev/ttyS0', u'/dev/ttyS7', u'/dev/ttyS6', u'/dev/ttyS5', u'/dev/ttyS4', u'/dev/ttyS3', u'/dev/ttyS2', u'/dev/ttyS1']
Trying /dev/ttyUSB0
Could not connect to or enter programming mode on /dev/ttyUSB0, might not be a printer or just not allow programming mode
Trying /dev/ttyS0
Could not connect to or enter programming mode on /dev/ttyS0, might not be a printer or just not allow programming mode
Trying /dev/ttyS7
Could not connect to or enter programming mode on /dev/ttyS7, might not be a printer or just not allow programming mode
Trying /dev/ttyS6
Could not connect to or enter programming mode on /dev/ttyS6, might not be a printer or just not allow programming mode
Trying /dev/ttyS5
Could not connect to or enter programming mode on /dev/ttyS5, might not be a printer or just not allow programming mode
Trying /dev/ttyS4
Could not connect to or enter programming mode on /dev/ttyS4, might not be a printer or just not allow programming mode
Trying /dev/ttyS3
Could not connect to or enter programming mode on /dev/ttyS3, might not be a printer or just not allow programming mode
Trying /dev/ttyS2
Could not connect to or enter programming mode on /dev/ttyS2, might not be a printer or just not allow programming mode
Trying /dev/ttyS1
Could not connect to or enter programming mode on /dev/ttyS1, might not be a printer or just not allow programming mode
Changing monitoring state from "Detecting serial port" to "Error: Failed to autodetect serial port, please set it manually."
Failed to autodetect serial port, please set it manually.
Leaving aside ttySxx, you notice that it does not recognize ttyUSB0 as a valid port.
The usb-serial chip is the classic FT232RL and the device that manages it is always ftdi_sio.
It seems that for some reason something goes wrong in detecting what is connected to the port rather than opening the port
... and ttyS0 through 9. Which it then tries to probe. Which fails and the probing fails with your printer too (since it relies on entering programming mode which doesn't always work and which I want to nuke due to this). If it only finds one port matching the pattern it won't probe but just try its luck with that and that usually works.
I also already explained the general issue with the current implementation and that I'm aware of them here
I had already read it and I'm sorry, I'm probably still asleep and I haven't noticed the ttyS0, ttyS1 present in the long list of tty devices.
Have you confirmed with even a keyboard that the USB port you are trying to use on the pi (with the printer) is still alive?
You might guess by my questions I’m trying to establish if the ports/interface on both halves of the puzzle are working. You’ve said you’ve ruled out the cable.
I did a strange test, I modified
baselist = baselist \
+ glob.glob("/dev/ttyUSB*") \
+ glob.glob("/dev/ttyACM*") \
+ glob.glob("/dev/tty.usb*") \
+ glob.glob("/dev/cu.*") \
+ glob.glob("/dev/cuaU*") \
+ glob.glob("/dev/ttyS*") \
+ glob.glob("/dev/rfcomm*")
turning it into
baselist = baselist \
+ glob.glob("/dev/ttyUSB*") \
+ glob.glob("/dev/ttyACM*") \
+ glob.glob("/dev/tty.usb*") \
+ glob.glob("/dev/cu.*") \
+ glob.glob("/dev/cuaU*") \
+ glob.glob("/dev/ttyZ*") \
+ glob.glob("/dev/rfcomm*")
so I can create links on the fly between ttyZx and other devices
pi@octopi:~$ sudo ln -s /dev/ttyUSB0 /dev/ttyZ0
pi@octopi:~$ ls -la /dev/ttyZ*
lrwxrwxrwx 1 root root 12 Mar 25 16:59 /dev/ttyZ0 -> /dev/ttyUSB0
the result of the auto connection is:
Changing monitoring state from "Offline" to "Detecting serial port"
Serial port list: ['/dev/ttyUSB0', u'/dev/ttyZ0']
Trying /dev/ttyUSB0
Could not connect to or enter programming mode on /dev/ttyUSB0, might not be a printer or just not allow programming mode
Trying /dev/ttyZ0
Could not connect to or enter programming mode on /dev/ttyZ0, might not be a printer or just not allow programming mode
Changing monitoring state from "Detecting serial port" to "Error: Failed to autodetect serial port, please set it manually."
Failed to autodetect serial port, please set it manually.
obviously the manual connection takes place regularly on both devices.
Is not that the problem arises from the fact that there is more than one match in the baselist regardless of the fact that they are ttyS* ?
The problem is that the auto detection probe that tries to put your printer into programming mode doesn't work with your printer. If there's only one port found, that doesn't matter because if there's only one port OctoPrint takes a shortcut and just assumes that to be the printer. If there's more than one port it tries probing. That doesn't work with your printer and it thus finds no printer at all. It doesn't matter how the ports in the list are called or how many there are, if your printer can't be put into programming mode auto detection will fail if there are more than one serial ports found. That's all.
The plugin above solves the issue for many because ttyS* as a port pattern was newly added in 1.4.0 and seems to match on quite a number of machines out there where previously only one port, the printer, was found, causing new issues for them. The auto detect probing was always broken for them, it just becomes visible now. Removing the port pattern again solves it for them until a proper solution can be implemented, removing the bloody probing and replacing it with a different approach.
If you read her previous email, when it finds multiple ports it tries to enter programming mode. If there is only one port, it just tries to open a connection and does not try programming mode