[lutecki]

Szukam #programista15k do napisania programu na Raspberry Pi. Ktoś coś?

#programowanie #devops #raspberrypi

[Drail]

@lutecki: a co ten program ma robić

[bi-tek]

@lutecki: xD to zeby sterować ledem to juz trzeba programisty15k?

[lutecki]

@Drail: W skrócie odczytywać sygnały z różnych czujników i na tej podstawie w zaprogramowany sposób sterować urządzeniami wykonawczymi w ściśle określony sposób. Zmiana ustawień programu po REST API i udostępnianie danych z czujników w formacie JSON
@bi-tek: Tak, bo to Polska w budowie

[Drail]

@ZabiliMiZolwia luk

[Kryspin013]

@lutecki: Język nie gra roli?

[m.....s]

@lutecki: jak 15k to ja chętnie

[lutecki]

@Kryspin013: Na obecnym etapie wydaje mi się, że nie, chociaż nie jestem w stanie wykluczyć

[Kryspin013]

@lutecki: Dla kogo i za ile?

[maque]

@lutecki: Zmiana ustawień po rest API? IMHO Raczej tak się nie robi, albo masz websocket, ale urządzenie odpytuje serwer gdzie są ustawienia (ale nie robisz z urządzenia serwera i nie autoryzujesz requestow, nie odświeżasz tokenów JWT, nie hardkodujesz hasła). Tu trochę materiałów https://github.com/enableiot , jakby ktoś nie chciał zaczynać od zera.

[lutecki]

@maque: Urządzenie ma być serwerem do którego się będzie można "podłączyć" poprzez WWW lub apki w telefonie i w ten sposób zobaczyć status, bądź coś pozmieniać (włączyć, wyłączyć).

[maque]

@lutecki: czym innym są wymagania (chcę przez telefon kontrolować urządzenie) a czym innym architektura (urządzenie ma być serwerem). To drugie wg mojej skromnej opini jest błędem, które prosi się o kłopoty; trzeba poczynić tyle założeń na potrzeby tej architektury, że musiałbym napisać cały artykuł aby je wszystkie opisać. Skrótowo rzucę tylko: skalowalność, autoryzacja, load balancing, multitenancy itd. Zakładam, że ma być to rozwiązanie produkcyjne oczywiście (a w takim raczej nie używa

[lutecki]

@maque: Ja rozumiem, że na każdy, nawet najdrobniejszy wycinek naszego życia można 100 książek napisać i oczywiście, że chciałbym zrobić wszystko zgodnie z obecnie panującymi trendami, ale na chwilę obecną przy pierwszej wersji produktu nie mogę sobie pozwolić na sztab architektów systemu, oprogramowania, protokołów itd.

[maque]

@lutecki: Dlatego tym bardziej sugeruję architekturę z brokerem. Po prostu część serwerową wydziel i postaw na normalnym serwerze (który jest w stanie obsłużyć ruch) a część sterowania niech pracuje w systemie push/pull na agencie/arduino/raspbery w najprostszym rozwiązaniu (request do serwera z aktualnym stanem, odpowiedź z żadanym stanem). Będzesz mieć wtedy jeden protokół TCP/REST, ale całą autoryzacje/weryfikacje itp. obsłużysz na normalnym serwerze. Urządzenie tylko odpytuje o stan i przekazuje swój - więc

[lutecki]

@maque: Ale my się chyba nie zrozumieliśmy, bo ty piszesz o ruchu setek użytkowników, a ja mam produkt domowy który ktoś będzie "przestawiał i włączał" powiedzmy raz dziennie.

[lutecki]

@maque: Żebyśmy się dobrze zrozumieli - mam dla przykładu mechanicznego kotka. I ten kotek przez całą dobę mruga oczami. Ale możesz z poziomu aplikacji telefonu wystawić jeszcze języczek albo przyspieszyć/zwolnić mruganie oczami ( ͡° ͜ʖ ͡°) No i chciałbym żeby na tym jeszcze postawić (w przyszłości lub od razu) komunikację Homekit i Fibaro.

[maque]

@lutecki: Miałem dawo temu kod, który był zbliżony do tego co potrzebujesz - o dziwno chyba nie jest na publicznym github. Tak czy inaczej wciąż polecam mini-server po drodze; chyba że jesteś pewny stałego IP w domu..no chyba że po domowej sieci to zrobisz. Tu masz sporo kodu, którego w tym celu możesz użyć https://github.com/enableiot/iotkit-lib-c/tree/master/src - przykłady czytania z pinu w raspberyy na pewno też łatwo wygooglać. Wciąż jednak jest to

[lutecki]

@maque: To taki typ urządzenia które się obsługuje z zasady raczej w domu.

[Strzalka]

@lutecki: napisz tutaj albo priw co dokladnie chcesz mieć zrobione, bo narazie nic nie wiem :D

[lutecki]

@Strzalka: ok