Tasmota Berry scripting: lokalne skrypty bez Home Assistant

Czym jest Berry w Tasmota i dlaczego działa lokalnie

Berry to lekki język skryptowy wbudowany w firmware Tasmota. Działa bezpośrednio na urządzeniu, najczęściej na module ESP8266 lub ESP32. Nie potrzebujesz do tego brokera MQTT, serwera Home Assistant ani żadnej chmury. Skrypt siedzi w pamięci układu i wykonuje się w miejscu.

To zmienia wszystko w kwestii niezawodności. Gdy internet padnie, automatyzacja dalej działa. Gdy Home Assistant się zawiesi, przekaźnik nadal reaguje na przycisk. Brzmi prosto, tylko że wielu użytkowników o tym zapomina, budując całą logikę w centrum sterowania.

Berry nie jest nowym wynalazkiem. Tasmota korzysta z niego od kilku lat, a sam język powstał jako niezależny projekt wbudowany później w firmware. Składnia przypomina Pythona i JavaScript, więc próg wejścia jest niski. Berry celowo jest okrojony.

Co dokładnie dostajesz w zamian za lokalne wykonywanie kodu?

• Brak zależności od sieci oznacza, że scenariusz działa nawet przy awarii routera.
• Opóźnienia reakcji spadają do milisekund, bo nie ma rundy przez Wi-Fi do serwera.
• Dane z czujników zostają na urządzeniu, co bywa istotne przy prywatności.
• Skrypt uruchamia się automatycznie po restarcie, bez ręcznej inicjalizacji z zewnątrz.
• Możesz reagować na zdarzenia sprzętowe, których chmura zwyczajnie nie widzi.

Moim zdaniem Berry wypada lepiej niż automatyzacje w Home Assistant przy prostych zadaniach, ponieważ nie wymaga utrzymywania serwera i nie zależy od jakości łącza. Przy złożonej logice z wieloma urządzeniami wygrywa jednak centralny system. Wybór zależy od tego, ile chcesz trzymać lokalnie.

Wyobraź sobie sytuację, w której masz Sonoff S26 z Tasmotą sterujący lampą w piwnicy. Chcesz, żeby światło zapalało się o zmierzchu i gasło po dwóch godzinach. Skrypt Berry zrobi to sam, bez pytania nikogo o zgodę. Home Assistant może w tym czasie być wyłączony.

Ta niezależność to główny powód, dla którego Berry wraca do rozmów o lokalnym sterowaniu. To nie czarna magia, tylko inny poziom abstrakcji.

Przygotowanie urządzenia i środowiska do Berry scripting

Berry nie działa na każdym module z Tasmotą. Potrzebujesz ESP32, bo ESP8266 ma za mało pamięci RAM na interpreter. To twarde ograniczenie sprzętowe, nie kwestia konfiguracji. Jeśli masz w szufladzie Sonoff Basic albo S26 na ESP8285, Berry tam nie ruszy.

Zacznij od sprawdzenia wersji firmware. Berry pojawiło się w Tasmocie w wydaniach z gałęzi 12.x i nowszych, ale dopiero wersje 13+ mają sensownie działający interpreter. W konsoli wpisz status 5 i sprawdź linijkę z wersją. Starszą aktualizujesz przez OTA albo klasycznie kablem.

Pliki .be wgrywasz przez menedżer plików w webowym interfejsie albo komendą Upload z konsoli. Trzymaj je w katalogu głównym systemu plików, inaczej interpreter ich nie znajdzie. Włącz autoexec, jeśli chcesz, żeby skrypt startował po restarcie.

Lepiej zacząć od prostego skryptu testowego niż od razu wrzucać rozbudowaną logikę, ponieważ debugowanie na urządzeniu bez podglądu zmiennych jest upierdliwe. Typowy przykład: wgrywasz 200 linii kodu, restartujesz, a w logu widzisz tylko ogólny błąd składni. Wersja z pięcioma linijkami i komendą print pozwala sprawdzić, czy środowisko w ogóle działa, zanim zabierzesz się za właściwą automatyzację.

Pierwszy skrypt Berry: struktura, składnia i wgrywanie na urządzenie

Berry to język skryptowy wbudowany w Tasmotę od wersji 9.1. Działa lokalnie, na samym module, bez udziału brokera MQTT ani Home Assistant. Skrypt zapisany jako plik autoexec.be uruchamia się automatycznie po starcie urządzenia. I tu zaczyna się problem, bo wiele osób wgrywa kod i dziwi się, że nic się nie dzieje.

Składnia Berry przypomina Pythona i Lua, ale jest prostsza. Nie ma klas na start, wystarczy kilka zmiennych i pętla. Każdy skrypt musi mieć punkt wejścia. Bez niego Tasmota nie wie, co ma właściwie wykonać.

Wyobraź sobie sytuację, w której chcesz, żeby moduł sam wysyłał stan przekaźnika co minutę do lokalnego serwera HTTP. Piszesz krótki skrypt, wgrywasz przez konsolę, restartujesz. Efekt? Cisza. Najczęściej winna jest literówka w nazwie funkcji albo brak pliku w odpowiednim katalogu.

Lepiej zacząć od prostego skryptu, który tylko miga diodą, niż od razu pisać rozbudowaną logikę z timerami. Powód jest prosty: Berry na module ma ograniczone zasoby pamięci, a każdy błąd składni blokuje cały plik. Krótki kod łatwiej wyłapać i poprawić niż wielostronicowy monolit.

Wgrywanie sprowadza się do dwóch dróg: przez konsolę szeregową albo przez wbudowany edytor plików w nowszych wersjach Tasmoty. Pierwsza działa zawsze, druga jest wygodniejsza. A co jeśli się okaże, że plik się wgrał, ale system go nie widzi? Wtedy warto sprawdzić, czy nazwa jest dokładnie taka, jakiej oczekuje Tasmota.

Praktyczne zastosowania: automatyzacje, harmonogramy i logika lokalna

Berry daje coś, czego zwykły firmware Sonoff nie oferuje: możliwość uruchomienia własnej logiki bezpośrednio na urządzeniu. Bez brokera MQTT. Bez Home Assistant. Bez chmury. Jeśli Wi-Fi padnie, skrypt nadal działa.

Typowy przykład: masz czujnik ruchu na korytarzu i chcesz, żeby światło zapalało się tylko po zmroku, ale nie reagowało na kota. W Berry piszesz warunek: ruch + brak światła dziennego + brak drugiego wyzwolenia w ciągu 30 sekund. Cała decyzja zapada na ESP8266. Zero opóźnienia sieciowego.

Co realnie można zrobić lokalnie? Sporo.

• Harmonogramy astronomiczne: włącz światło zewnętrzne o zachodzie słońca, wyłącz o wschodzie, bez zewnętrznego serwera czasu.
• Logika progowa: jeśli temperatura z czujnika DS18B20 spadnie poniżej progu, uruchom przekaźnik grzałki na określony czas.
• Licznik impulsów: zliczaj kliknięcia przycisku i wykonuj różne akcje w zależności od liczby (1 klik = światło, 2 kliknięcia = tryb nocny).
• Watchdog lokalny: jeśli przez 5 minut brak komunikacji z brokerem, przełącz urządzenie w tryb autonomiczny z domyślnym harmonogramem.

Berry sprawdza się lepiej niż automatyzacje w chmurze wszędzie tam, gdzie liczy się czas reakcji poniżej sekundy, ponieważ decyzja nie opuszcza urządzenia. Chmura dodaje opóźnienie sieciowe, które w scenariuszach alarmowych bywa problemem. To nie czarna magia, tylko przeniesienie logiki bliżej sprzętu.

Berry nie ma dostępu do wszystkich funkcji, które oferuje pełny Home Assistant. Zaawansowane scenariusze z wieloma warunkami i integracjami lepiej zostawić na serwerze. Ale prostą automatyzację na jednym urządzeniu? Berry załatwia to bez zewnętrznych zależności.

Integracja Berry z MQTT, GPIO i czujnikami bez chmury

Berry daje dostęp do warstwy sprzętowej Tasmoty, ale prawdziwą siłę pokazuje dopiero wtedy, gdy połączysz go z MQTT. Skrypt może odczytać temperaturę z czujnika na GPIO, przeliczyć ją i wysłać wynik jako temat MQTT. Bez chmury, bez pośredników. Urządzenie gada bezpośrednio z brokerem.

Sterowanie przekaźnikami przez Berry to kilka linii kodu. Odczyt stanu pinu, zmiana jego wartości, publikacja potwierdzenia w MQTT. Wszystko lokalnie. GPIO i MQTT działają w Berry równolegle, więc nie musisz wybierać między jednym a drugim. Skrypt może nasłuchiwać komend i jednocześnie raportować stan czujników.

Typowy przykład: masz czujnik DHT22 podpięty do Wolnego pinu. Berry odpytuje go co kilkadziesiąt sekund i publikuje odczyt w temacie dom/salon/temperatura. Home Assistant odbiera dane, ale gdy go zabraknie, skrypt dalej działa i buforuje ostatnie wartości. To nie czarna magia, tylko kilka wywołań funkcji.

Co można podłączyć bez chmury

• Czujniki temperatury i wilgotności na GPIO, z odczytem przez Berry i publikacją w MQTT.
• Przekaźniki sterowane lokalnie, z potwierdzeniem stanu w osobnym temacie MQTT.
• Przyciski fizyczne, które wywołują akcje w skrypcie bez udziału zewnętrznego serwera.
• Wyświetlacze OLED pokazujące dane zebrane przez Berry bezpośrednio z pinów.
• Buzzer lub dioda LED jako lokalny wskaźnik stanu, niezależny od sieci.

Berry sprawdza się lepiej niż reguły Tasmoty w scenariuszach, gdzie potrzebna jest logika warunkowa, ponieważ Tasmota Rules ma ograniczoną składnię i trudno w niej o pętle czy funkcje. Berry to pełny język, więc warunki, tablice i obliczenia są naturalne. Tylko że wymaga więcej pracy na starcie.

Pamiętaj o jednym: jeśli skrypt zapętli się i zablokuje urządzenie, tracisz dostęp do MQTT. Warto dodać watchdog i limit czasu wykonania. Kropla drąży skałę, ale nieskończona pętla w Berry potrafi położyć nawet stabilny moduł.

Najczęściej zadawane pytania (FAQ)

Czy Berry wymaga Home Assistant do działania? Nie. Skrypty Berry uruchamiają się bezpośrednio na module ESP, więc automatyzacja działa nawet przy zerwanej sieci Wi-Fi. To właśnie dlatego wielu użytkowników sięga po to rozwiązanie: logika zostaje na urządzeniu, a nie w chmurze.

Czy muszę znać programowanie? Podstawy wystarczą. Berry przypomina składnią język Python, ale jest znacznie lżejszy. Prosty skrypt sterujący przekaźnikiem po naciśnięciu przycisku zamknie się w kilku linijkach więcej na ten temat znajdziesz w naszym przewodniku: "Sonoff s26 tasmota home assistant".

Szybkie zestawienie wątpliwości

Kiedy Berry, a kiedy Home Assistant?

Berry sprawdza się lepiej niż pełny Home Assistant przy prostych, powtarzalnych zadaniach, ponieważ nie wymaga serwera ani stałego połączenia sieciowego. Home Assistant wygrywa, gdy potrzebujesz rozbudowanych scen, integracji z wieloma ekosystemami i zaawansowanego panelu.

Wyobraź sobie sytuację, w której chcesz, żeby światło w garażu gasło po pięciu minutach niezależnie od tego, czy internet działa. Skrypt Berry załatwia to lokalnie. Home Assistant w tym samym scenariuszu wymaga działającej sieci i serwera.

• Berry wybierz, gdy priorytetem jest niezawodność bez chmury.
• Home Assistant wybierz, gdy budujesz rozbudowany system z wieloma urządzeniami.
• Oba rozwiązania można łączyć w jednej instalacji.
• Zacznij od prostego skryptu, zanim rozbudujesz logikę.
• Zawsze rób kopię konfiguracji przed eksperymentami.

Zanim wgrasz skrypt na wszystkie moduły, przetestuj go na jednym. Jeśli chcesz poznać szerszy kontekst integracji, zajrzyj do artykułu o Sonoff S26 z Tasmotą i Home Assistant.