Pioreactor Pioreactor 20 mL v1.5

Granice modelu i rewizje

Oficjalny model software dla wcześniejszej wersji 1.1 podaje pojemność 20 mL, średnicę 27 mm i maksymalne napełnienie 18 mL.

Rewizja	Status	Cecha rozpoznawcza i znaczenie
1.0	legacy	najstarsza rodzina mechaniki i HAT; inne przypisania przycisku/czujnika Halla oraz starsza optyka
1.1	starsza	HAT wykorzystujący RP2040/Pico jako ADC/DAC pod adresem I²C 0x2C; tradycyjne fotodiody na przewodach
1.5	bieżąca	moduły Eye-Spy z własnymi 16-bitowymi przetwornikami, mocowane śrubami i podłączane STEMMA QT; baza dla XR

Rewizja 1.5 została ogłoszona 4 listopada 2025 r. Producent wskazuje, że zastąpił 5-milimetrowe fotodiody na długich przewodach modułami Eye-Spy. Eye-Spy ma własny 16-bitowy ADC, większe wzmocnienie, sztywne mocowanie czterema śrubami i złącza STEMMA QT. Źródło: opis zmian Pioreactor v1.5.

Oprogramowanie odczytuje wersję HAT z EEPROM; mechanika naczynia, moduły optyczne i ogrzewanie mogły zostać wymienione zestawem modernizacyjnym. Minimalny materiał identyfikacyjny obejmuje: zdjęcie góry i spodu HAT, nadruki PCB, model Raspberry Pi, oba Eye-Spy, płytkę temperatury, typ naczynia i pokrywy, wersję wybraną w Inventory oraz wynik pio version -v albo eksport informacji systemowej.

Tor procesowy i wyposażenie fizyczne

Bieżący zestaw v1.5 zawiera HAT, płytkę grzania i temperatury, zespół mieszadła, pręt PTFE 3 × 10 mm, dwa moduły optyczne Eye-Spy, szklane naczynie 20 mL, pokrywę ze stalowymi przewodami i żeńskimi zakończeniami luer lock oraz elementy montażowe. Deklarowany zakres grzania to temperatura otoczenia do około 25°C ponad otoczenie.

HAT v1.x korzysta z GPIO2/GPIO3 jako SDA/SCL I²C. GPIO17, 13, 16, 12 i 18 odpowiadają pięciu kanałom PWM, przy czym kanał 5 służy ogrzewaniu. GPIO23 steruje diodą PCB. Funkcje GPIO4, GPIO21, GPIO24 i GPIO25 różnią się między rewizjami: obejmują przycisk, czujnik Halla oraz linie SWD. Oficjalna tabela znajduje się w dokumentacji pinów GPIO.

Dla HAT 1.0 producent dokumentuje ADS1115 pod 0x48, DAC pod 0x49 i czujnik temperatury płytki grzejnej pod 0x4F. HAT 1.1 oraz 1.2 używają RP2040/Pico jako ADC/DAC pod 0x2C i czujnika temperatury pod 0x4F. W modelu 20 mL v1.5 dwa przetworniki optyczne są mapowane jako pd1 0x48 i pd2 0x49. Źródło: oficjalny rejestr adresów I²C.

Komputer, procesor i storage

Jest nakładką na zgodny Raspberry Pi z Wi-Fi i 40-pinowym złączem GPIO. Producent wymienia Raspberry Pi 3 B+, 3 A+, 4 B, 5 oraz Zero 2 z przylutowanym goldpinem; preferuje m.in. 3 B+, 4 B 1 GB i Zero 2.

Producent zaleca nośnik UHS-I/Class 10 o pojemności 16–32 GB; przy zakupie Raspberry Pi w zestawie dodawana jest kompatybilna karta. Karta microSD zawiera system Raspberry Pi OS/Pioreactor, konfigurację, klucze, pakiety, logi i lokalny stan, dlatego jest podstawowym nośnikiem do zabezpieczenia bitowego.

Architektura leader–worker

W większej instalacji leader utrzymuje centralny interfejs, broker MQTT, główną bazę SQLite i rejestr workerów, zaś każdy worker steruje własnym hardware i udostępnia Unit API.

Komunikacja wewnątrz i między urządzeniami opiera się na MQTT.

Leader eksponuje interfejs /api; wszystkie jednostki eksponują /unit_api. Aktualna dokumentacja generowana z kodu wymienia 156 endpointów leadera i 93 endpointy jednostki. Źródła: Leader API i Unit API.

Usługi, protokoły i ustawienia domyślne

Domyślne wdrożenie używa HTTP dla interfejsu webowego; historyczna i bieżąca dokumentacja wskazuje port 80 oraz proto=http. MQTT korzysta standardowo z portu 1883, a WebSocket brokera z 9001. SSH typowo słucha na 22/TCP, zgodnie z systemem Raspberry Pi OS.

Usługa	Typowe ustawienie	Znaczenie
SSH	TCP/22, użytkownik pioreactor	pełna administracja systemem operacyjnym
UI i HTTP API	TCP/80, HTTP	interfejs leadera oraz reverse proxy do funkcji jednostek
MQTT	TCP/1883	komendy, stan, telemetria i komunikacja procesów
MQTT WebSocket	TCP/9001, ws	dostęp UI do strumieni brokera
mDNS/Avahi	nazwy *.local	odnajdywanie leadera i workerów w segmencie lokalnym

Instrukcja instalacji rekomenduje konto pioreactor z hasłem raspberry oraz włączenie logowania SSH hasłem. Broker Mosquitto ma w dokumentacji domyślne poświadczenia pioreactor / raspberry.

Oficjalne zalecenia producenta są jednoznaczne: nie publikować UI w Internecie, użyć kontrolowanej sieci laboratoryjnej lub prywatnej sieci zdalnej, zmienić hasła Linux/MQTT/AP, opcjonalnie dodać uwierzytelnienie UI oraz ograniczyć zarządzanie pluginami. Szczegóły: Security hardening.

Oprogramowanie i aktualizacje

Warstwa aplikacyjna jest rozwijana w otwartym repozytorium Pioreactor/pioreactor na licencji MIT. Wydania aplikacji są publikowane na stronie Releases. Od wersji 26.3.0 producent deklaruje schemat YY.M.N, gdzie N jest licznikiem wydania w miesiącu.

Dane i artefakty śledcze

Bieżąca dokumentacja wymienia między innymi:

• config.ini — konfiguracja wspólna klastra, w tym sieć, MQTT, UI, logowanie i automatyzacje;

• unit_config.ini — konfiguracja właściwa dla jednostki w nowszych wydaniach;

• storage/pioreactor.sqlite — główna baza eksperymentów na leaderze;

• storage/local_persistent_pioreactor_metadata.sqlite — trwały cache i metadane lokalne;

• hardware/ — warstwowe definicje YAML HAT, modelu, sensorów i okablowania;

• experiment_profiles/ — profile YAML harmonogramów eksperymentów;

• plugins/ — kod i zasoby rozszerzeń, w tym definicje UI i eksportowanych datasetów;

• .ssh/ — klucze urządzenia tworzone przy budowie obrazu, używane również do zarządzania workerami.

Pełny rejestr: Important locations on the filesystem.

Źródło: opis magazynów danych.

Funkcję blokuje sentinel DISALLOW_UI_FILE_SYSTEM.

Galeria identyfikacyjna

Bieżący Pioreactor 20 mL z zamontowanym naczyniem, HAT-em i korpusem optycznym. Źródło: oficjalna dokumentacja lub karta produktu Pioreactor.

Tył bieżącego modułu 20 mL; fotografia ułatwia rozpoznanie Raspberry Pi, złączy i rzeczywistego prowadzenia przewodów. Źródło: oficjalna dokumentacja lub karta produktu Pioreactor.

Konfiguracja 20 mL z opcjonalnym wyświetlaczem i kamerą; dodatki zmieniają BOM, usługi i artefakty obrazu. Źródło: oficjalna dokumentacja lub karta produktu Pioreactor.

Zbliżenie opcjonalnej kamery przy naczyniu 20 mL. Źródło: oficjalna dokumentacja lub karta produktu Pioreactor.

Bieżący stos sterowania 26.8.1 — granica zgodności

Kod źródłowy sprawdzony 8 września 2026 r. wskazuje wersję aplikacji 26.8.1 i commit 5d758529ea23aef387a2f18f4a774ff3898db7bc z 19 sierpnia 2026 r. Pioreactor przyjął schemat wersji YY.M.N; numer oprogramowania nie oznacza rewizji mechanicznej. Ten sam release może sterować modelami 20 mL, 40 mL, XR i sprzętem legacy, ale dobiera parametry przez jawny model i wersję workera.

Od wydania 25.11.12 backend, unit API i UI są utrzymywane w jednym repozytorium. Obraz bazowy przeszedł na Debian 13 „Trixie”, wprowadził /etc/pioreactor.env, usługę pioreactor-web.service i katalog /run/pioreactor/.

Od 26.4.0 konfiguracja właściwa dla jednostki jest przechowywana przez worker w unit_config.ini; leader utrzymuje jej obraz i pobiera aktualny stan. Interfejsy nazwane wcześniej /api/config/files* zostały usunięte na rzecz zasobów shared oraz unit-specific. W mieszanym klastrze leader i workery mogą zatem różnić się zarówno buildem aplikacji, jak i własnością konfiguracji.

Web UI — widoki operacyjne

Okno zarządzania konkretnym workerem: etykieta, docelowe RPM, temperatura i odstęp między dawkami. Źródło: oficjalna dokumentacja Pioreactor.

Panel Pioreactors pokazuje stan zadań i ustawień osobno dla każdego workera. Zakładki Activities, Settings, Dosing, LEDs i System odpowiadają różnym klasom komend. Zmiana Target stir RPM wpływa nie tylko na mieszanie, ale także na tor optyczny; zbyt wolne mieszanie może się zatrzymać, a zbyt duży wir zmienić OD. Pole czasu między dawkami może spowodować wcześniejsze zdarzenie dawkowania, dlatego zmiana w UI powinna być korelowana z logiem i wpisem dosing_events.

Overview z wykresami, podsumowaniem dawkowania i tabelą zdarzeń zawierającą czas, worker, źródło oraz komunikat. Źródło: oficjalna dokumentacja Pioreactor.

Overview łączy dane historyczne z SQLite z bieżącym stanem przesyłanym przez MQTT. Tabela zdarzeń odróżnia jednostkę i komponent źródłowy, np. monitor, instalację pluginu albo dodanie workera.

Okno wyboru modelu rozdziela 20/40 mL v1.5 oraz rewizje legacy. Źródło: oficjalna instrukcja instalacji.

Wybór modelu nie jest opisem kosmetycznym. Profile sprzętowe wpływają na geometrię naczynia, objętości, kanały optyczne, adresy I²C, pinout, ustawienia mieszania i dostępne kalibracje. Błędnie wybrany wpis może sprawić, że poprawny fizycznie sensor zostanie zinterpretowany jako inny kanał lub automatyka użyje wartości właściwych dla innej rewizji.

Drugi widok ustawień workera pokazujący, że parametry procesu są edytowane z centralnego web UI. Źródło: oficjalna dokumentacja Pioreactor.

Topologia leader–worker i granice zaufania

Leader serwuje SPA, obsługuje leader API, prowadzi główną bazę SQLite, uruchamia zadania tła przez Huey, pośredniczy w komendach do workerów i zazwyczaj hostuje Mosquitto. Worker wykonuje sterowanie lokalne i od 24.9.19 ma własny web server z unit_api, bez interaktywnego UI.

Warstwa webowa jest serwowana przez lighttpd. Pakiet zawiera osobne konfiguracje aplikacji, CORS i HTTPS, a podstawowa dokumentacja kieruje do http://pioreactor.local. Backend działa jako FastCGI z aplikacją Python, a długie operacje trafiają do kolejki Huey.

MQTT przenosi stan i komendy. Typowy broker nasłuchuje na TCP/1883, a web UI używa MQTT over WebSocket na TCP/9001. Dokumentowany przykład konfiguracji zawiera użytkownika pioreactor, hasło raspberry, use_tls=0 i WebSocket ws; HTTP UI zwykle korzysta z TCP/80, SSH z TCP/22, a mDNS z nazw .local.

Poświadczenia i uwierzytelnienie

Historyczne obrazy i skrypty klastrowe używały konta Linux pioreactor oraz hasła raspberry; to samo hasło występuje w przykładach MQTT. Współczesny proces przygotowania obrazu przez Raspberry Pi Imager prosi operatora o ustawienie nazwy użytkownika i hasła, więc raspberry jest wskaźnikiem do kontroli, a nie gwarantowanym poświadczeniem każdej sztuki.

Producent udostępnia opcjonalny plugin Basic Auth dla UI. Basic Auth bez HTTPS nie zapewnia poufności transportu; osobnymi mechanizmami pozostają konta Linux, klucze SSH leader–worker i poświadczenia MQTT.

Dokumentacja hardeningu zaleca niewystawianie interfejsu bezpośrednio do Internetu, odrębną sieć laboratoryjną lub prywatny kanał zdalny, zmianę haseł Linux/MQTT/AP oraz ograniczenie instalowania pluginów. Pliki DISALLOW_UI_INSTALLS i DISALLOW_UI_FILE_SYSTEM blokują wybrane operacje z UI/API, ale nie zastępują kontroli dostępu do SSH ani integralności samego systemu plików.

Dane trwałe i schemat SQLite

Główna baza leadera ~/.pioreactor/storage/pioreactor.sqlite jest źródłem danych historycznych dla UI. Aktualny schemat obejmuje między innymi tabele experiments, workers, przypisania workerów, raw_od_readings, od_readings_filtered, od_readings_fused, growth_rates, temperature_readings, stirring_rates, dosing_events, ustawienia i zdarzenia automatyki dawkowania/LED/temperatury, led_change_events, pwm_dcs, logs, calibrations, od_blanks, historie konfiguracji i uruchomienia profili eksperymentów.

Na węźle występują także SQLite cache: trwały local_persistent_pioreactor_metadata.sqlite oraz bieżący cache metadanych. W gałęzi 26.x cache tymczasowy przeniesiono do /run/pioreactor/, a SQLite może używać WAL/SHM. Kopia wykonana przy aktywnym procesie bez plików -wal i -shm może nie odzwierciedlać najnowszych transakcji. Oficjalne zadanie backupu potrafi kopiować bazę na workery; te repliki są dodatkowymi artefaktami, nie automatycznie niezależnym źródłem integralności.

Od wersji 24.5.22 MQTT w Pioreactorze jest kanałem danych efemerycznych, a trwałe dane procesu są przechowywane w SQLite.

Profile, kalibracje i estymatory

Profile eksperymentów są plikami YAML opisującymi kolejność zadań i nastaw. UI pozwala je tworzyć, edytować i uruchamiać, a backend zapisuje uruchomienia. Kalibracje pomp, OD i mieszania są osobnymi obiektami z nazwą, datą oraz aktywnym wyborem. W XR dochodzą estymatory fuzji kanałów. Kopia samych wykresów bez profilu, aktywnych kalibracji i mapowania modelu jest niewystarczająca do niezależnego odtworzenia wyniku.

Aktualizacje i łańcuch dostaw pluginów

Polecenia pio update i pios update aktualizują aplikację, UI, a zależnie od wydania także komponenty systemowe i skrypty migracyjne. Repozytorium zawiera wersjonowane migracje SQL, pakiety systemowe, zmiany usług i pliki konfiguracyjne. Aktualizacja może więc zmienić nie tylko kod Pythona, ale również lighttpd, bazę, systemd, model konfiguracji i lokalizację artefaktów.

Plugin może dostarczyć joby, automatyzacje, endpointy, elementy UI, definicje sprzętu, tabele SQL i eksportowane datasety. Od 26.4.0 opis możliwości workera jest pobierany dynamicznie, więc plugin obecny tylko na workerze może pojawić się w centralnym UI.

Elektronika, I²C i zależność od Raspberry Pi

Pioreactor HAT nie jest samodzielnym komputerem aplikacyjnym. GPIO, I²C, PWM i pomocniczy mikrokontroler współpracują z Raspberry Pi; obsługiwane modele mają różne SoC Broadcom i ilości RAM, a microSD pozostaje podstawowym nośnikiem.

Profile I²C rozdzielają przetworniki i moduły pomiarowe. Konflikt adresu, niestabilne zasilanie albo uszkodzenie przewodu może dawać przerwy w OD, temperaturze lub sterowaniu, które zdalnie wyglądają podobnie do błędu software. Self-testy pomagają w diagnostyce, lecz nie stanowią kryptograficznego attestation sprzętu.

Źródła podstawowe

• Pioreactor 20 mL — karta bieżącego produktu
• Pioreactor v1.5 — opis zmian sprzętowych
• Software installation
• Security hardening
• API Reference — leader
• API Reference — unit
• GPIO pins used
• I²C addresses
• Data stores
• Filesystem locations
• Back up and restore system files
• Repozytorium i wydania Pioreactor

Stan źródeł i cen sprawdzono 2 września 2026 r.