Prosba o dokumentacje + inne sprawy

[Biedronek]

Na samym poczatku chcialbym podziekowac za inicjatywe, super sprawa!

Obecnie jestem na etapie realizowania pol-automatyki domowej, skretka od dawna czeka, kilka ruterow wisi na scianach i teraz czas to wszystko ogarnac. Bardzo zalezy mi na wykorzystaniu istniejacej bazy kodu (zwlaszcza androidowego), przy czym licze sie z tym, ze bede musial ja dopasowac do swoich potrzeb - bym moze zechcecie skorzystac - ale o tym innym razem. Wstepne testy przekaznikow/czujnikow mam za soba, obecnie przymierzam sie do uruchomienia serwera na Raspberry Pi i w tym miejscu pojawilo sie kilka problemow. Na poczatek tak prozaiczny jak adaptacja mojego podejscia: listwy przekaznikow (tak naprawde poprzez plytke z MCP23008 + ULN2003) z podlaczonymi do nich dedykowanymi obwodami (w domu mam niektore gniazdka obok siebie podlaczone "klasycznie" oraz sterowane z przekaznika).

W zwiazku z czym mam nastepujace pytania - z gory przepraszam, jesli zadaje oczywiste oczywistosci, staralem sie zapoznac z forum i repozytoruim ale nie natrafilem na nic co by mi rozjasnilo temat (nie liczac studiowania kodu):
1. czy istnieje jakas dokumentacja dotyczaca systemu (jakies bloczki logiczne itp) - ja wiem, ze pisanie tego jest katorga, ale chodzi mi nawet o nieformalne rysunki itp. jak to wszystko dziala
1a. i jak mozna sie wpiac ze swoim kodem
1b. protokol komunikacji?
2. jaki jest mechanizm przeplywu komend miedzy serwerem a lokalnymi modulami wykonawczymi, czy logika jest wyrzucona do zewnetrznych urzadzen?
3. jesli dobrze rozumiem, to sewer jest obiektem realizujacym komunikacje miedzy klientem (np. telefonem) a modulem? Widzialem pliki gpio.c wiec pewnie moze sterowac - co z podpieciem zewnetrznych bibliotek (np. wiringPi)? Jesli jakies API np. do zastapienia zadan serwera swoimi funkcjami, w tym zewnetrznymi? W moim przypadku chodzi o komunikacje z ekspanderem i2c-gpio (ewentualnie inna lokalna elektronika)

Oraz juz bardziej luzne pytania:
4. planujecie przejsc na CPP (pliki .cpp na repo) czy to przez przypadek?
5. widzialem zdjecie modulu sterujacego gniazdkiem - to jest gdzies do kupienia? Na "popularnych serwisie aukcyjnym" jest tylko modul bramkowy - swoja droga to najpierw jego znalazlem, a dopiero potem strone supla.org. Fajnie byloby moc grzebnac w srodku i dodac cos jeszcze.
6. MySQL to mus, czy SQLite tez dalby rade (wiem, ze typy sa mysqlowe, ale tak z ciekawosci)?

I ostatnie drobne sugestie:
7. dajcie linka do forum gdzies na gorze strony
8. dolaczcie astyle'a do kodu

Tyle z biezacych spraw, jak rozgrzebie temat bardziej to na pewno sie podziele spostrzezeniami. Bylbym wdzieczny za odpowiedzi na ww.

[pzygmunt]

Witam.

1.
W chwili obecnej projekt rozwijany jest przez 3 osoby. Ja jestem odpowiedzialny za kod, Darek za elektronikę, a Mateusz za oprawę graficzną.
Jak widać póki co są to bardzo skromne zasoby osobowe w związku z czym wiele kwestii projektowych zostało pominiętych, a w wielu przypadkach
poszliśmy na skróty po to by nie zwlekać z udostępnieniem pierwszej wersji projektu.Co za tym idzie dokumentacja w chwili obecnej praktycznie nie istnieje. Będziemy starali się za pośrednictwem tego forum jak najlepiej opisywać zagadnienia związane z projektem. Miejmy nadzieję, że w przyszłości z pomocą nowych członków zespołu uda nam się przygotować sensowną dokumentację.

1a.
Uruchomimy osobne forum na potrzeby dyskutowania i rozwoju kodu gdzie będziemy mogli wspólnie go rozwijać.
Osoby, które przyłączą się do zespołu będą mogły publikować do publicznego repozytorium swoje poprawki, dodatkowe funkcjonalności itp.

1b.
Słowem wstępu. Za obsługę protokołu odpowiadają:
https://github.com/SUPLA/supla-core/blo ... mon/srpc.c
https://github.com/SUPLA/supla-core/blo ... mon/srpc.h
https://github.com/SUPLA/supla-core/blo ... on/proto.c
https://github.com/SUPLA/supla-core/blo ... on/proto.h

gdzie proto.h opisuje struktury danych, a srpc.h opisuje funkcje odpowiedzialne za komunikację pomiędzy
elementami systemu.
Nazwa każdej z funkcji sugeruję przeznaczenie, a dokładniej to w jakiej relacji jest wykorzystywana - wraz z określeniem kierunku.

srpc_dcs_* - Urządzenie/Klient -> Serwer
srpc_sdc_* - Serwer -> Urządzenie/Klient
srpc_ds_* - Urządzenie -> serwer
srpc_sd_* - Serwer -> urządzenie
srpc_cs_* - Klient -> serwer
srpc_sc_* - Serwer -> klient

To samo dotyczy struktur w proto.h

TSDC_* - Serwer -> Urządzenie/Klient
i reszta analogicznie jak w srpc.h

Urządzenie == urządzenie wykonawcze.
Serwer == CLOUD
Klient == aplikacja kliencka np w smartfonie

Szczegóły wymagają szerszej dyskusji.

2.
Z założenia za logikę ma odpowiadać serwer, a rola urządzeń wykonawczych ma się sprowadzać do wykonywania poleceń serwera.
Ten zaś wydaje je na polecenie użytkownika korzystającego z aplikacji klienckiej, lub w wyniku zdarzeń/harmonogramów itp..
Będą jednak wyjątki, które dadzą urządzeniom wykonawczym trochę więcej autonomii. Przykładem może być sterownik kotła, który musi sterować ogrzewaniem nawet jak straci połączenie z serwerem. Czyli od serwera otrzyma wytyczne dot. utrzymania określonych temperatur w określonych godzinach i sterowaniem musi zająć się już sam, pamiętając zestaw najbardziej aktualnych wytycznych.

3.
Sam serwer nie zajmuje się sterowaniem. On wydaje tylko rozkazy dla urządzeń wykonawczych. gpio.c jest w supla-dev
co jest częścią oprogramowania dla urządzenia wykonawczego.
Możemy podłączać dowolne biblioteki do systemu (c/c++) i sukcesywnie będziemy to robili. Docelowo myślę o jakimś
Plugin-API tak aby można było łatwo i w sposób ustandaryzwowany "wpinać" do systemu rozszerzenia na zasadzie wtyczek.
Niemniej jednak w chwili obecnej takiego API nie ma i jest to właśnie jedna z tych rzeczy tzw. "na skróty" o której wcześniej pisałem.
Obsługa i2c-gpio jak najbardziej zostanie dodana.

4.
Podstawowy protokół jest napisany w c po to by można było go jak najprościej przenosić pomiędzy różnymi architekturami.
Pozostała część jest już pisana w c++;

5.
Gniazdko będzie za jakiś czas dostępne w sprzedaży. Również moduł bramowy zbudowany w oparciu o ESP8266.
Środki ze sprzedaży będą przeznaczane w 100% na rozwój projektu.

6.
cloud.supla.org jest oparte o framework Symfony2 i w tym przypadku przepięcie się na SQLLite to żaden problem.
Pozostaje modyfikacja samego serwera (supla-server), ale z tym również nie widzę jakiegoś większego problemu.

7. Słuszna sugestia
8. Rozważę to

[Biedronek]

Super, bardzo dziekuje za odpowiedzi! Wyglada na to, ze te informacje powinny mi dac dobry start. Wieczorem sprobuje sie przegryzc przez kod i wcisnac troche swojego. Jesli mi sie przed urlopem uda to sie pochwale jeszcze w tym tygodniu - na pewno bede celowal w uzycie wiringPi i jego modul do MCP23008 bo to mam "recznie" przetestowane, zobaczymy jak pojdzie integracja z modulem wykonawczym. W razie problemow pozwole sobie pociagnac watek z pytaniami...

[pzygmunt]

Nie ma sprawy. Jak coś to czekam na pytania.

[Biedronek]

W channel-io.c podpialem naglowki wiringPi dla MCP23008, dodalem komunikacje dla konkretnego pinu na ekspanderze na sztywno i wstepnie wydaje sie to dzialac. Nie jest idealnie bo po zalaczeniu przekaznika zglasza konflikt mi z innymi pinami, plus wymusza sudo no i w ogole widnieje pod gpio ale brak mi jeszcze wiedzy jak to elegancko zintegrowac. W zwiazku z tym pytania pomocnicze: po co w kodzie sa gpio1 i gpio2, jaka jest ich funkcja? Jaki jest optymalny sposob dodania nowego urzadzenia? Jest sens pchac sie w jakis vgpio (virtual gpio) albo exbus-gpio (extension bus gpio) czy latwiej po prostu zdefiniowac urzadzenie i tam cos dokonfigurowac (np. adress i2c, piny, przerwania)? Chcialbym sie zakrecic kolo tego tematu. ale nie chce zmieniac pierwotnej koncepcji systemu...

Przy okazji kilka spraw, ktore mi sie rzucily w oczy odnosnie supla-dev:
1. nie kompiluje sie Release: trzeba w makefile'u dodac '-pthread' - czy ten plik jest rzeczywisce generowany automatycznie? W Debug w makefile jest to linkowane domyslnie
2. jak sie wywali kompilacja to trzeba zrobic 'make clean', inaczej mowi, ze nie ma niczego do zrobienia. To jest nieco klopotliwe na RPiv1. Na szczescie ladnie sie kompliuje -j4 na RPiv2.
3. warto dodac .gitignore dla plikow .o i .d - oczywiscie nie jest to problem samemu zrobic, ale tak byloby wygodniej
4. niepokojace jest 100% zuzycie jednego rdzenia przez supla-dev. Widac, ze architektura jest z zalozenia przygotowana do duzego skalowania, ale gdzies tam musial sie zapodziac busy-loop - nie szukalem juz przyczyny.
5. mysle. z ewarto podpiac w polskiej wersji link do konfiguracji dla clouda (jest w wersji angielskiej)

[pzygmunt]

gpio1 i gpio2 - drugi port gpio wykorzystywany jest w chwili obecnej na potrzeby sterowania roletami.
Jeden port służy do zamykania, drugi do otwierania.

Odnośnie vgpio/exbud-gpio. Generalnie chciałbym utrzymać następujące warstwy:
[SUPLA-CORE]<->[CHANNEL-IO]<->[Wewnętrzny sterownik]<->[Sprzęt]

SUPLA-CORE - komunikacja, obsługa konfiguraci itd czyli wszystko to co pozostaje po wydzieleniu channel-io i sterownika
CHANNEL-IO - warstwa komunikacyjna pośrednicząca pomiędzy channel-io i sterownikiem
Wewnętrzny sterownik - (np. gpio.c) szumnie nazwane, ale chodzi o warstwę najbliżej sprzętu. W tym przypadku to niezła abstrakcja bo w rb pi mamy jeszcze po drodze system i sterownik systemowy, ale chodzi o ideę.

Docelowo z channel-io powinna się wydzielić jeszcze warstwa PLUGIN-API która mogłaby pozwalać na dołączanie dynamiczne sterowników.
Apropos dodania obsługi kolejnego sprzętu. Jeżeli jest gotowy sterownika dla Linux-a który obsługuje np. W1-GPIO (jak w obecnym przypadku) to mija się z celem pisania obsługi tego sprzętu i lepiej tak jak w gpio.c odwołać się bezpośrednio do /sys/class/gpio. Jeżeli są przesłanki aby napisać własną obsługę to można ją wpiąć pomiędzy sprzęt, a channel-io. Dodając kolejny sprzęt trzeba go uwzględnić w pozostałej czeęści infrastruktury czyli
w supla-server, supla-cloud, aplikacji klienckich. Teraz będę dodawał obsługę czujników wilgotności tak więc będzie można podpatrzeć zasadę.

Ogólnie rzecz biorąc obsługę sprzętu trzeba będzie jeszcze raz przemyśleć ponieważ jak będzie dochodzić go coraz więcej to trzeba będzie jakoś
sensownie to usystematyzować aby nie zrobił się bałagan.

Różnice w implementacji będą też pomiędzy sprzętem. Np. dla Arduino jest to rozwiązane trochę inaczej
https://github.com/SUPLA/arduino/blob/m ... Device.cpp

Dla ESP8266 jeszcze inaczej.
https://github.com/SUPLA/supla-core/blo ... _devconn.c

Tak czy owak pewnie po dodaniu kilku dodatkowych czujników sterowników itp. nakreśli się jakiś sensowny kierunek aby to ogarnąć i nie robić bałaganu.

1. Tak to już poprawiłem ale cały czas zapominam wrzucić
2. Makefile generowany jest przez Eclipse ale coś postaram się temu zaradzić
3. Racja
4. Generalnie na raspberry zauważyłem szczytowe użycie procesora na poziomie 0.3% i pamięci 1% przy 72 dniach uptime-a. Problem może leżeć w funkcji gpio.cpp: void gpio_wait(TGpioPort *port, int count, int usec, _func_gpio_portvalue on_portvalue) Jeżeli natrafi na jakiś port którego nie ma to może tak być, że się ani na chwilę nie zatrzyma czego efektem może być właśnie 100% użycie. Moszę się temu przyjrzeć
5. Co do clouda to w ogóle przydałby się docelowo jakiś instalator wtedy i instrukcja będzie prostsza. Na razie przygotowałem wirtualną maszynę dla Wirtual Box-a aby było można to łatwo i szybko uruchomić.

[Biedronek]

Co do vgpio/exbud-gpi to przemyslalem sprawe i rzeczywiscie bylby to troche przerost formy nad trescia. Co do abstrakcji tj. nie schodzenia nizej niz potrzeba to rozumiem idee, opcja pojedynczego sterownika jest sensowna. Zobaczymy co mi sie uda zrobic i w razie czego przy pull-request'cie sobie pogadamy

Czyli jesli dobrze rozumiem, to "wewnetrzny sterownik" gpio ma z zalozenia 2 gpio, przy czym nie kazdy musi byc wykorzystany, tak?

Podejrze jak to jest robione z wilgotnosciomierzem i sprobuje zrobic podobnie ze swoim. Zaraz potem sie pojawi pewnie podobny problem z kamerka/aparatem, czujnikiem ruchu, innym termometrem itp.

ad 2 - poprosze
ad 4 - moze to jest kwestie mojej popsutej konfiguracji, ale tak czy inaczej fajnie by bylo widziec te 0.3%
ad 5 - na razie korzystam z srv1 ale przy modyfikacji serwera i tak bede chcial to miec u siebie lokalnie. Jesli mi nie zje to polowy nocy to instalator.sh sie pojawi sam w trakcie uruchamiania go, w razie czego sprobuje na wirtualce.

[pzygmunt]

Przy większości funkcji wykorzystywany jest pojedynczy port gpio1, tylko w przypadku rolet wykorzystywane są dwa porty.
Na wirtualu wskazałem nieistniejące porty i uzyskałem ten sam efekt tj. 95% zjedzonego procka.
gpio_wait używa select-a do monitorowania zmian stanu portu tak więc coś musi tam dziać nie tak jak trzeba, że nie czeka.
W wolnej chwili to przeanalizuję. Być może nie wyrzucam z listy tych portów, które są błędne lub niedostępne.

[rafalski76]

Witam,
gratuluję pomysłu i zaangażowania w projekt. Chętnie zgłaszam swój akces do współpracy. Mam doświadczenie w zakresie elektroniki i programowania (Windows, Android, RPi, Arduino). Na początek mógłbym zmierzyć się z tematami czujników wilgotności i zapisu danych do CSV. Na jakim etapie znajdują się te kwestie? Są jakieś konkretne wytyczne, zasady dot. powyższego?

[pzygmunt]

Temat z CSV jest najprostszy i obejmuje głównie zmianę w cloud.supla.org. (praktycznie jest to drobiazg).
Dodanie czujników też jest dość proste. Mógłbyś zacząć od napisania „sterownika” dla DHT11, DHT22 i YL-69
Później to podepniemy do supla-dev i esp8266.

Możesz się posiłkować implementacją dla DS18B20
https://github.com/SUPLA/supla-core/blo ... _ds18b20.c

Analogicznie można dodać kolejne czujniki.
Jak już pisałem odnośnie dokumentacji, póki co jej nie ma.
Do tej pory był tylko jeden programista czyli ja.

W związku z powyższym nawet kwestia zespołowej pracy nad projektem jest jeszcze do zorganizowania.
Trzeba też uruchomić jakiś system zarządzania projektem tak aby programiści mogli między sobą rozdzielać pracę do wykonania.
(np. Trello/Mantisa itp.)

Do projektu przyłączył się już jeden programista który zgłosił do githuba pierwsze pull requesty.
Jeden został już dołączony do kodu, drugi po lokalnych testach będzie również dołączony.
W związku z powyższym byłyby już (licząc Ciebie i mnie ) 3 osoby pracujące nad kodem.