mpk pisze:jeżeli "zniknięcie" USB i jego ponowne połączenie nie propaguje się poprawnie do kontenera, to chyba spróbowałbym to obejść ser2net.

W 95% to działa To może nie działać jeśli zmieni się identyfikator w systemie na inny. Wtedy jest już gorzej...

morf pisze:Przecież mapujesz sobie USB po /dev/serial/by-id z hosta i nic się nie zmienia:)

Ale ok dzięki za feedback

Wszystko zależy jak zmapujesz. Jeśli zmapujesz np.: `/dev/serial/by-id/usb-LeafLabs_Maple-if01` to nie, ale jeśli zmapujesz `/dev/serial/by-id` i upewnisz się dodatkowo, ze są odpowiednie `/dev/ttyS*|ACM*|AMA*` dla wszystkich możliwych wartości jakich oczekujesz... wtedy tak Inaczej nie będzie działać.

Generalnie, docker z urządzeniami które mogą/są hot-plug nie działa trywialnie/powtarzalnie/w każdym przypadku. Jest długo dyskutowany wątek namespace dla udevd. Ale do chwili obecnej nadal nic takiego nie ma.

Ot, np.: https://lwn.net/Articles/656941/, lub https://github.com/eiz/udevfw.

Cosik pisze:

1kamil pisze:...Wynika to z tego, że zdarzenia udev nie są propagowane do kontenterów, i jeśli `/dev/ttyUSB0` zmieni się na USB1 to wtedy trzeba restartować kontener....

Może nie do końca w temacie, ale właśnie z takich powodów w manualu do klippera zalecane jest używanie portów po id urządzenia a nie nazwie portu.

A co do samego octoprint na rpi to moim zdaniem kiepsko z wydajnością. Może lepiej kupić taniego laptopa/PC przy takich kombinacjach ilościowy.

Co do:

1. To przejdzie, ale tylko na głównym systemie, ale nie w kontenerze. Sprawdziłem np. moje dystrybucje, żadna nie ma stockowo `60-persistent-serial.rules`. Jeśli to uruchomisz to faktycznie jest to mocno pomocne. Natomiast nadal nie ma gwarancji, że te zmiany pojawią się w kontenerze, dlatego, że `/dev` nie jest współdzielony. Sprawdziłem to na przykładzie `/dev/bus`, którego w moich kontenerach nie ma, bo nie ma usługi `udevd`.
2. Moje RPI4 daje sobie radę z Octoprintem z dużym zapasem mocy, ledwo zużywajać 1GB z aktywnym timelapse. Zazwyczaj problemem w SBC jest obsługa USB oraz opóźnienia wprowadzane przez przetwarzanie danych. Ja sam nie używam USB. Mój Octoprint łączy się do SKR MINI 2 po dedykowanym UART5 z złącza 40o pinowego. RPI udostępnia kilka UARTów, które mają zdecydowanie duży mniejszy koszt przetwarzania.

Tutaj jest opis wszystkich dostępnych opcji na GPIO Header: https://www.tomshardware.com/reviews/ra ... ,6122.html

Ja miałem, ale zrezygnowałem:
1. Wszystko było OK, ale jak z jakiegoś powodu USB się odłączyło to Octoprint tego nie wykrywał. Wynika to z tego, że zdarzenia udev nie są propagowane do kontenterów, i jeśli `/dev/ttyUSB0` zmieni się na USB1 to wtedy trzeba restartować kontener.
2. Octoprint jako taki nie jest przystosowany dobrze do obsługi pluginów w obrazie dockerowym. Udało mi się to ominąć wymuszają instalację modułów pythonowych w współdzielonym katologu.
3. Wydajnościowo da radę. Bym się tylko martwił o kartę SD oraz czy nie zużyjesz jej cykli
4. Ja używam RPI4

Ostatecznie wróciłem do konfiguracji, która wykorzystuje oddzielnego użytkownika i serwis. Działa, zawsze dobrze