Wielki powrót VIRTUINO - oprogramowanie mikrokontrolera

 Wracam do VIRTUINO z dalekiej podróży. Trochę przymuszony sytuacją jaką zgotowali mi twórcy BLINKa likwidując wersję 1.0 i mocno komercjalizując cały projekt. Na szczęście pod ręką jest zapasowy, równie dobry a może i lepszy, system. Niby ten sam jakim go opisywałem trzy lata temu - ale mocno nie taki sam. A że  zmieniło się naprawdę dużo zaczniemy od początku.

Jedyne co nie zmieniło się w Virtuino to koncepcja bez serwerowego systemu sterowania złożonego jedynie z konsoli operatora HMI i mikroprocesorowego modułu wykonawczego. Przy czym i konsoli i modułów może być mnoga ilość. Całość systemu opiera się na założeniu że moduły wykonawcze realizują autonomicznie swe funkcje a konsola służy jedynie do okresowej komunikacji - ustawiania parametrów roboczych i odczytu danych celem kontroli lub sprawdzenia stanu działania systemu. Pozostał więc VIRTUINO systemem mocno rozproszonym z okresową synchronizacją elementów przez konsolę. Czy taki schemat domowej automatyki ma sens w dobie komunikacji i łączenia wszystkiego ze wszystkim?

Z mojego skromnego doświadczenia - jak najbardziej. Mam w domu sporo elementów automatyki ale są one mocno niezależne od siebie. Sterowanie światłami, bramą, piecem, grzałką odbywa się o prawdzie z jednego (lub kilku równolegle działających) miejsca ale każdy z nich działa po swojemu w zasadzie nie ingerując w pozostałe elementy. W obecnym systemie opartym o BLYNKa wspólne dla wszystkich modułów były dwa elementy systemu - serwer załadowany do RPi i konsola/e operatorska w telefonie czy tablecie. Niezawodność całej automatyki określa niezawodność najsłabszego ogniwa - a jest nim serwer BLYNKa. Jego awaria praktycznie wyłącza możliwość pracy większości podsystemów gdyż większość sygnałów sterujących i wykonawczych musi być transmitowana via serwer.

W tym kontekście model działania VIRTUINO wydaje się bardzo atrakcyjny, Uszkodzenie konsoli nie ma (podobnie jak w BLYNKu) praktycznie żadnego wpływu na działanie poszczególnych elementów a brak centralnego serwera wyklucza totalną awarię całości automatyki. A gdyby zachodziła potrzeba połączenia w jakiś sposób dwu lub więcej podsystemów  między sobą? I na to znajdzie się rozwiązanie choć pewnie nie tak proste i eleganckie jak w BLYNKu. 

Zaczynam więc nową podróż w nieznane ze stary ale kompletnie nowym VIRTUINO

I już na wstępie zaskoczenie w miejsce kilku niezależnych aplikacji (VIRTUINO, VIRTUINO SE, VIRTUINO MQTT, VIRTUINO Motbus) na placu pozostały już tylko dwie - powoli schodzący ze sceny VIRTUINO 6 (obecna versja) utrzymywany przy życiu dla zachowania ciągłości z wcześniejszymi wersjami systemu i całkiem nowy - wręcz rewolucyjny w swoim założeniu - VIRTUINO IoT.

Z historii rozwoju VIRTUINO IoT wynika , że to przyszłość projektu autorstwa  Ilias Lamprou

Ale swoją podróż rozpocznę od VIRTUINO 6. To sprawdzony system (ver 6 coś znaczy) i łatwiejszy do ogarnięcia. Potem przejdę do VIRTUINO IoT.

W nowym Virtuino 6 zmieniony został nieco protokół komunikacji. wszystkie dane pomiędzy aplikacją a modułem przesyłane są w formacie String. I chociaż w systemie zachowane zostały deklaracje dotychczasowych (choć nie wszystkich ) typów to jest to pewnikiem podyktowane jedynie koniecznością wstecznej kompatybilności. Tutaj będzie analizowana jedynie ten format zmiennych gdyż znakomicie ułatwia i uelastycznia operowanie zmiennymi w VIRTUINO. Nb. identyczny schemat był zastosowany w BLYNKu co pozwoli mi korzystać z wiedzy tam nabytej do obsługi procedur systemowych. Niestety VIRTUINO 6 to wciąż system klient-serwer gdzie komunikację inicjuje jedynie klient. Tym samym transmisja z aplikacji (klient) do modułu odbywa się natychmiastowo zaś w drugą stronę w interwałach określonych w ustawieniach w aplikacji. Domyślnie jest to 3 sekundy co większości przypadków automatyki nie ma znaczenia ale np. przy zapalaniu światła opóźnienie 3 sekundowe może być już denerwujące. Kwestię tę będę analizował później.

Dalsze rozważanie będą dotyczyć przypadku dla mikrokontrolera ESP8266 lub ESP 32. Analiza zastosowaniem płytek Arduino jest, moim zdaniem, bezsensowna.

Podstawowy kod mikrokontrolera wydaje się dosyć złożony w porównaniu z BLYNKiem.

Wemos - NodeMCU ESP8266 example1: Getting started

 

Jedynie sam trzon komunikacji został wydzielony do osobnej biblioteki VirtuinoCM 

Pozostałe elementy Virtuino zawarte są w kodzie głównym mocno zaciemniając rzeczywistą prostotę i uniwersalność systemu. Toteż pierwszą rzeczą jaką zrobiłem było podzielenie kody na odrębne bloki pozwalające łatwo zapanować na całym programem. Jest to oczywiście moja propozycja ale sprawdzona i przetestowana w boju.

Rozbiłem całość na cztery podstawowe bloki

• blok podstawowy typu .ino zawierający deklaracje bibliotek, funkcje main i setup
• bibliotekę virtuino.h  zawierającą wszystkie niezbędne elementu systemu VIRTUINO. Biblioteka ta w zasadzie powinna pozostać niezmienna we wszystkich moich projektach
• bibliotekę piny.h zawierającą deklaracje pinów zastosowanych w programie i procedur ich obsługi 
• bibliotekę program.h  zawierającą kod mojego programu obsługi danego elementu automatyki

Przykładowe kody tychże bloków zawierają poniższe linki

https://pastebin.com/X3Usbdxu     - blok główny z main()

https://pastebin.com/iQGFVEid     - bibloteka z kodem virtuino

https://pastebin.com/g4BkFGTC     - biblioteka deklaracji pinów i procedur obsługi pinów

https://pastebin.com/VtRZ5w1F      - blok z przykładowym programem

 

Biblioteki te będą sukcesywnie uzupełniane o inne potrzebne mi elementy systemowe np. obsługę transmisji 433 MHz.

Obsługa odbieranych i nadawanych danych pomiędzy modułem a aplikacją VIRTUINO jest bliźniaczo podobna do tej znanej z BLYNKa, Przejście na nowy system zapowiada się i ciekawie i prosto.

Zobaczymy co dalej ....