Pytanie tylko co i po co chcesz zrobić?
Aktualnie Supla wystawia wszystkie swoje wnętrzności na zewnątrz w ramach MQTT, więc cokolwiek się dzieje wewnątrz, możesz się zintegrować z tym przez MQTT.
Zakładam, że pisać serwera od początku nie chcesz, bo to nie tylko urządzenia wykonawcze są do ogarnięcia, ale też komunikacja z apkami na telefonach.
Co do Arduino IDE, to praktycznie jest to zwykłe programowanie w C++ z paroma ograniczeniami (czasem starszy standard, czasem brak bibliotek std:: ), ale ogólnie czarów tam nie ma. Asemblera też raczej się nie używa ;P
Opis protokołu Supla
W takim razie użyj RetfulAPI lub MQTT. Jeśli bardzo chcesz użyć Suplowego protokołu komunikacyjnego to użyj gotowej biblioteki.jacekl pisze: ↑śr maja 05, 2021 10:24 am Mów mi jeszcze
Nie mam bladego pojęcia o Arduino, nigdy nie widziałem ich IDE, nie jestem elektronikiem ani embedded developerem...
Jestem programistą od strony serwera, chciałbym umieć przyjąć połączenie TCP/IP od urządzenia działającego z firmwarem supli i z nim pogadać.
Czyli bardziej interesuje mnie strona serwera a nie klienta, choć protokół obejmuje obie strony, dlatego pytam o protokół.
Ale mówisz o MQTT w serwerze Supli? Czy w urządzeniach?pzygmunt pisze: ↑śr maja 05, 2021 1:08 pmW takim razie użyj RetfulAPI lub MQTT.jacekl pisze: ↑śr maja 05, 2021 10:24 am Mów mi jeszcze
Nie mam bladego pojęcia o Arduino, nigdy nie widziałem ich IDE, nie jestem elektronikiem ani embedded developerem...
Jestem programistą od strony serwera, chciałbym umieć przyjąć połączenie TCP/IP od urządzenia działającego z firmwarem supli i z nim pogadać.
Czyli bardziej interesuje mnie strona serwera a nie klienta, choć protokół obejmuje obie strony, dlatego pytam o protokół.
Nie, że bardzo tylko w urządzeniach Zamela jest chyba właśnie ten protokół. A czy są inne, bardziej udokumentowane i popularne protokoły, które wspierają także urządzenia Zamela i Sonoffa?Jeśli bardzo chcesz użyć Suplowego protokołu komunikacyjnego to użyj gotowej biblioteki.
Aktualnie jest wsparcie dla mqtt po stronie serwera, ale służy ono tylko do udostępnienia urządzeń Supli na zewnątrz, więc można zintegrować Suplę ze wszystkim co wspiera mqtt.
Mqtt na urządzeniach Zamela jest w planach. Będzie można w konfiguracji je przełączyć i wtedy będzie działać tylko po mqtt bez używania Supli.
Z dyskusji wnioskuję że chciałbyś jakieś urządzenie Supli od Zamela podłączyć do innego systemu bez używania serwera Supli.
A nie wystarczyłoby Tobie postawić prywatny serwer Supli, do tego broker mqtt i dalej działać po mqtt?
Potem jak pojawi się wsparcie dla mqtt po stronie urządzeń, to będziesz mógł serwer wyłączyć.
Mqtt na urządzeniach Zamela jest w planach. Będzie można w konfiguracji je przełączyć i wtedy będzie działać tylko po mqtt bez używania Supli.
Z dyskusji wnioskuję że chciałbyś jakieś urządzenie Supli od Zamela podłączyć do innego systemu bez używania serwera Supli.
A nie wystarczyłoby Tobie postawić prywatny serwer Supli, do tego broker mqtt i dalej działać po mqtt?
Potem jak pojawi się wsparcie dla mqtt po stronie urządzeń, to będziesz mógł serwer wyłączyć.
Widzimy się na Supla Offline Party vol. 2
Czy przez MQTT w Supli jest dostępna pełna funkcjonalność urządzeń i swobodny odczyt ich stanów?
O, to może być ciekawe, wiesz może mniej więcej kiedy to ma być wdrożone? I czy to będzie tylko w nowo nabytych zabawkach czy do starych się będzie dało wrzucić?Mqtt na urządzeniach Zamela jest w planach. Będzie można w konfiguracji je przełączyć i wtedy będzie działać tylko po mqtt bez używania Supli.
Nie wiem jakie taka konfiguracja ma ograniczenia, ale, dobrze odgadujesz, jest potrzeba podpiąć jakieś sterowniki/czujniki do autorskiego systemu i mieć z nimi komunikację.Z dyskusji wnioskuję że chciałbyś jakieś urządzenie Supli od Zamela podłączyć do innego systemu bez używania serwera Supli.
A nie wystarczyłoby Tobie postawić prywatny serwer Supli, do tego broker mqtt i dalej działać po mqtt?
Tak
Liczę, że do lipca wsparcie mqtt dla urządzeń powinno się pojawić. Będą aktualizacje dla istniejących modułów.
Rozwijasz swój system na własne potrzeby czy zamierzasz to komercjalizować?
Bo jeśli typowo własne potrzeby, to może nie ma co przesadzać?
Sam jestem programistą i wiem z doświadczenia, że w okolicy budowy domu, człowiekowi odbija szajba . Wyobraźnia jest bujna i wymyśla się cuda na kiju, które nikomu do niczego nie są potrzebne. Na szczęście budowa domu trochę trwa i moje "marzenia" zostały stemperowane przez odrobinę realizmu i praktyczności.
Do Supli przekonało mnie to, że nie musiałem pisać własnych aplikacji na telefon (akurat to nie moja działka), a na poziomie urządzeń i serwera, jeśli ktoś zna się na programowaniu, to jest w stanie ogarnąć wszystko co sobie zamarzy.
Ostatecznie bramą wjazdową steruję modułem SBW-01, a rolety obsługuje 12 modułów SRW-02m. Mam też trzy układy typu DIY (samoróbki) - jedno Arduino Mega, które monitoruje mi zużycie prądu na 7 obwodach oraz dwa ESP8266 z przekaźnikami, które ogarniają furtkę, temperaturę zewnętrzną i jeszcze kilka innych rzeczy.
Całą automatykę mogę sobie spokojnie i powoli rozbudowywać o kolejne elementy (pewnie następna będzie brama garażowa oraz oświetlenie w domu).
Gdybym miał wszystko samemu robić od podstaw, to raczej by sił zabrakło, a przy trójce dzieciaków jest co robić
Widzimy się na Supla Offline Party vol. 2
Nie swój tylko firmy, w której pracuję. I nie ma to mieć wiele wspólnego ze sterowaniem domem tylko możliwością odczytu danych z tych urządzeń, a do czego to potrzebne to już nie wiem, ja mam zbadać temat możliwości komunikacji.
Jeśli o to chodzi to ja mam kompletnie odrębne przemyślenia, nie mam i nie chcę mieć w domu żadnej automatyki, stawiam na prostotę, puryzm i minimalizm. Im mniej gadżetów tym mniej problemów. A włącznik światła ogarniam manualnie i nigdy mi przez myśl nie przeszło, żeby "się samo włączało"Bo jeśli typowo własne potrzeby, to może nie ma co przesadzać?
Sam jestem programistą i wiem z doświadczenia, że w okolicy budowy domu, człowiekowi odbija szajba . Wyobraźnia jest bujna i wymyśla się cuda na kiju, które nikomu do niczego nie są potrzebne. Na szczęście budowa domu trochę trwa i moje "marzenia" zostały stemperowane przez odrobinę realizmu i praktyczności.
Mam owszem sterowanie automatyczne w ogrzewaniu, ale to jedyna automatyka która wydaje mi się konieczna, reszta to już męskie zabawki
Żeby mój post nie był jałowy to jeszcze spytam o jedną rzecz.Do Supli przekonało mnie to, że nie musiałem pisać własnych aplikacji na telefon (akurat to nie moja działka), a na poziomie urządzeń i serwera, jeśli ktoś zna się na programowaniu, to jest w stanie ogarnąć wszystko co sobie zamarzy.
Ostatecznie bramą wjazdową steruję modułem SBW-01, a rolety obsługuje 12 modułów SRW-02m. Mam też trzy układy typu DIY (samoróbki) - jedno Arduino Mega, które monitoruje mi zużycie prądu na 7 obwodach oraz dwa ESP8266 z przekaźnikami, które ogarniają furtkę, temperaturę zewnętrzną i jeszcze kilka innych rzeczy.
Całą automatykę mogę sobie spokojnie i powoli rozbudowywać o kolejne elementy (pewnie następna będzie brama garażowa oraz oświetlenie w domu).
Gdybym miał wszystko samemu robić od podstaw, to raczej by sił zabrakło, a przy trójce dzieciaków jest co robić
Czy protokół komunikacyjny jest jednokierunkowy? Czyli klient (urządzenie) wysyła request do serwera i serwer odpowiada? Czy może serwer także może (jeśli jest w tej samej sieci) zapytać urządzenie o coś? Innymi słowy czy działa to jak serwer webowy i przeglądarka, że tylko klient inicjuje połączenie?
Tak, tylko klient wywołuje połączenie.
Widzimy się na Supla Offline Party Season 2
Nie, natywny protokół nie działa jak http.
Urządzenia wykonawcze i klienckie zestawiają stałe połączenia TCP z serwerem i tam komunikacja jest dwukierunkowa.
https://fracz.github.io/supla-noc-informatyka-1.1/#/14
https://www.youtube.com/watch?v=5WobKP5 ... Fr%C4%85cz
Urządzenia wykonawcze i klienckie zestawiają stałe połączenia TCP z serwerem i tam komunikacja jest dwukierunkowa.
https://fracz.github.io/supla-noc-informatyka-1.1/#/14
https://www.youtube.com/watch?v=5WobKP5 ... Fr%C4%85cz