Komunikacja między urządzeniami

[KaDet]

Poruszałem ten temat już kilkukrotnie, ale ponowię (czyli jak widać rozwiązanie może być przydatne - przynajmniej dla mnie... ).
Najpierw opisze przypadek. Przyszła mi potrzeba zrobienia wyłącznika światła (tak przyjmijmy dla uproszczenia), który były sterowany Suplą jak i pilotem IR. Zrobiłem sobie właściwą płytkę, napisałem soft - działa bez problemu (nawet jest opcja uczenia kolejnych pilotów i takie tam).
I tu pojawia się POMYSŁ, gdyż mam kilka wyłączników ze ściemnianiem z Zamela - może zrobić taki "hub", który przyjmowałby polecenia za pomocą IR i mógł sterować rozmaitymi urządzeniami (w tym wypadku poziomem oświetlenia).
Niestety teraz pojawia się PROBLEM (choć mam nadzieję, że jednak wyzwanie) - jak sterować z jednego urządzenia innym poprzez cloud nie używając "direct link"? Z direct linko biedy radzę sobie jak mam odczytać zdalny termometr, czy tez coś załączyć lub sprawdzić stan - ale sterowanie takie "jakby analogowe'" to już nie bardzo mi się podoba. Takie to nieeleganckie.
A zatem PYTANIE - w jaki sposób mogę podpiąć się, w ramach tego samego konta pod zupełnie inne urządzenie i nim sterować. Jakieś API chyba istnieje bo przecież aplikacje na telefony sterują różnymi urządzeniami. Jak skorzystać z takiego API w ramach oprogramowania urządzenia? Może jest inne, trickowe, obejście?

Ktoś z Was ma podobny POMYSŁ/PROBLEM/PYTANIE i szuka rozwiązania? Może ktoś znalazł? (szukajka forumowa mi nie pomogła, ale zawsze mogłem przeoczyć)

Pozdrawiam

[lesny8]

Urządzenia bez kontaktu z serwerem się nie widzą wzajemnie. Tak po prostu zbudowany jest protokół, urządzenia i klienci(apki) komunikują się poprzez serwer. Urządzenia nie wystawiają API robi to Cloud po autoryzacji. Obecnie jak nie masz internetu, to nie wysterujesz przekaźnika z apki, zadziała tylko fizyczny klawisz na ścianie. Apki nie sterują urządzeniami przez API tylko przy użyciu protokołu SUPLA.
Z tego co wiem, to ta ślepota urządzeń bez internetu, ale w ramach widoczności w jednej sieci LAN/WLAN ma się kiedyś zmienić. Jak dokładnie i kiedy? Nie wiem

[Duch__]

Ja bym niekoniecznie widział komunikację między modułami, ale chętnie bym widział żeby każde urządzenie wystawiało swój stan przez UDP globalnie co parę sekund w formacie json. Tak można by odbierać potrzebne nam informacje do dalszego przetwarzania bez angażowania linków bezpośrednich i zapytań do serwera. U mnie już tak parę urządzeń działa i pluje danymi co 5 sekund. Inne moduły odbierają potrzebne informacje które ich interesują. Pozostałe olewają. Wszystko działa w sieci lokalnej i nie wymaga dostępu do internetu.

[KaDet]

Urządzenia bez kontaktu z serwerem się nie widzą wzajemnie. Tak po prostu zbudowany jest protokół, urządzenia i klienci(apki) komunikują się poprzez serwer. Urządzenia nie wystawiają API robi to Cloud po autoryzacji. Obecnie jak nie masz internetu, to nie wysterujesz przekaźnika z apki, zadziała tylko fizyczny klawisz na ścianie. Apki nie sterują urządzeniami przez API tylko przy użyciu protokołu SUPLA.
Z tego co wiem, to ta ślepota urządzeń bez internetu, ale w ramach widoczności w jednej sieci LAN/WLAN ma się kiedyś zmienić. Jak dokładnie i kiedy? Nie wiem

Mnie nawet by nie przeszkadzało, że musi być internet. Wystarczyłoby jakies API, które z drugiej strony plułoby Supla i robiło to efektywniej niz directlinki (tu mam ciągle kłopot z tym, że urządzenie jest podpięte przez bezpieczne połączenie do clouda i jednocześnie robię wywołania directlink - czasami cos się zupełnie przywiesza, albo - co częściej rozłącza mi połączenie z cloudem)

[KaDet]

Ja bym niekoniecznie widział komunikację między modułami, ale chętnie bym widział żeby każde urządzenie wystawiało swój stan przez UDP globalnie co parę sekund w formacie json. Tak można by odbierać potrzebne nam informacje do dalszego przetwarzania bez angażowania linków bezpośrednich i zapytań do serwera. U mnie już tak parę urządzeń działa i pluje danymi co 5 sekund. Inne moduły odbierają potrzebne informacje które ich interesują. Pozostałe olewają. Wszystko działa w sieci lokalnej i nie wymaga dostępu do internetu.

Dla DIY nie ma problemu - zrobię sobie co potrzebuję (i tak robię - mam lokalny serwer restAPI i tam sobie oprogramowuje wszystko, podejście z UDP tez mi sie podoba). Głównie chodzi mi o to, ze mam urządzenia "gotowe" i z nimi to nie pogadam.

[klew]

Dla DIY nie ma problemu - zrobię sobie co potrzebuję (i tak robię - mam lokalny serwer restAPI i tam sobie oprogramowuje wszystko, podejście z UDP tez mi sie podoba). Głównie chodzi mi o to, ze mam urządzenia "gotowe" i z nimi to nie pogadam.

Ogólnie od sterowania urządzeniami są apki na telefonie i one używają supla-client (z repo supla-core).
Ale to nie jest kod przystosowany do pracy na ESP (może ruszy, może nie - nie mam pojęcia - ale raczej rozmiary buforów trzeba by zminiejszyć, bo tam gdzie nie gdzie jest i po 100 kB używane na buforach).

Jest też supla-console-client (też w supla-core) - i to jest gotowa implementacja klienta, którego można sobie z linii poleceń na kompie używać. Ale nie wiem na ile to jest aktualne, ani czy działa .

Tak czy inaczej, ten "client" pozwoli na odczyt i sterowanie wszystkim na Twoim koncie (o ile ma ustawiony dostęp). Ale nie wiem czy to odpalisz na esp.

Sama komunikacja między urządzeniami będzie kiedyś dodana. Z tym że to będzie wymagało aktualizacji softu każdego urządzenia. Dodatkowo najprawdopodobniej implementacja będzie mocno ograniczona do opcji dostępnych w Cloud, choć tutaj szczegółowa koncepcja tego całego mechanizmu jeszcze nie jest zrobiona.
Osobiście rozważam wariant, że urządzenie będzie innemu udostępniać swój stan (odczyt) lub zezwalać też na modyfikację stanu (zapis). Format prawdopobnie będzie taki sam jak na komunikacji z serwerem, bo nie trzeba będzie tego na nowo wymyślać i implementować.
Parowanie urządzeń między sobą będzie realizowane przez Cloud i każdą parę trzeba będzie ręcznie ustawić. Będzie też limit ilości sparowanych urządzeń. Przesyłane dane będą szyfrowane (prawdopodobnie AES 256 z osobnym kluczem dla każdej pary). Możliwe, że parowanie będzie realizowane osobno na każdy kanał, a nie na całe urządznie (np. udostępniamy termometr do innego urządzenia, gdzie działa termostat).

[SOYER]

Dla DIY nie ma problemu - zrobię sobie co potrzebuję (i tak robię - mam lokalny serwer restAPI i tam sobie oprogramowuje wszystko, podejście z UDP tez mi sie podoba). Głównie chodzi mi o to, ze mam urządzenia "gotowe" i z nimi to nie pogadam.

Ogólnie od sterowania urządzeniami są apki na telefonie i one używają supla-client (z repo supla-core).
Ale to nie jest kod przystosowany do pracy na ESP (może ruszy, może nie - nie mam pojęcia - ale raczej rozmiary buforów trzeba by zminiejszyć, bo tam gdzie nie gdzie jest i po 100 kB używane na buforach).

Jest też supla-console-client (też w supla-core) - i to jest gotowa implementacja klienta, którego można sobie z linii poleceń na kompie używać. Ale nie wiem na ile to jest aktualne, ani czy działa .

Tak czy inaczej, ten "client" pozwoli na odczyt i sterowanie wszystkim na Twoim koncie (o ile ma ustawiony dostęp). Ale nie wiem czy to odpalisz na esp.

Sama komunikacja między urządzeniami będzie kiedyś dodana. Z tym że to będzie wymagało aktualizacji softu każdego urządzenia. Dodatkowo najprawdopodobniej implementacja będzie mocno ograniczona do opcji dostępnych w Cloud, choć tutaj szczegółowa koncepcja tego całego mechanizmu jeszcze nie jest zrobiona.
Osobiście rozważam wariant, że urządzenie będzie innemu udostępniać swój stan (odczyt) lub zezwalać też na modyfikację stanu (zapis). Format prawdopobnie będzie taki sam jak na komunikacji z serwerem, bo nie trzeba będzie tego na nowo wymyślać i implementować.
Parowanie urządzeń między sobą będzie realizowane przez Cloud i każdą parę trzeba będzie ręcznie ustawić. Będzie też limit ilości sparowanych urządzeń. Przesyłane dane będą szyfrowane (prawdopodobnie AES 256 z osobnym kluczem dla każdej pary). Możliwe, że parowanie będzie realizowane osobno na każdy kanał, a nie na całe urządznie (np. udostępniamy termometr do innego urządzenia, gdzie działa termostat).

Brawo, czekamy:)

[KaDet]

Sama komunikacja między urządzeniami będzie kiedyś dodana. Z tym że to będzie wymagało aktualizacji softu każdego urządzenia. Dodatkowo najprawdopodobniej implementacja będzie mocno ograniczona do opcji dostępnych w Cloud, choć tutaj szczegółowa koncepcja tego całego mechanizmu jeszcze nie jest zrobiona.
Osobiście rozważam wariant, że urządzenie będzie innemu udostępniać swój stan (odczyt) lub zezwalać też na modyfikację stanu (zapis). Format prawdopobnie będzie taki sam jak na komunikacji z serwerem, bo nie trzeba będzie tego na nowo wymyślać i implementować.
Parowanie urządzeń między sobą będzie realizowane przez Cloud i każdą parę trzeba będzie ręcznie ustawić. Będzie też limit ilości sparowanych urządzeń. Przesyłane dane będą szyfrowane (prawdopodobnie AES 256 z osobnym kluczem dla każdej pary). Możliwe, że parowanie będzie realizowane osobno na każdy kanał, a nie na całe urządznie (np. udostępniamy termometr do innego urządzenia, gdzie działa termostat).

Jak dla mnie brzmi bardzo rozsądnie. Jak już ktoś napisał - czekamy

Co do tego, czy to aplikacja na telefonie ma służyć do sterowania urządzeniami - to już jest dyskusyjne. Jestem (z jednego z moich zawodów) automatykiem i to w większości urządzenia sterują urządzeniami lub przy najmniej odczytują ich stan. Podam przykład (który sobie jakoś tam załatwiłem i w sumie podałeś wyżej) - mam termostat, ale termometr nie może/nie jest przypięty do niego fizycznie, jak i czujnik/i otwarcia okna tez nie są. Powinienem móc zrobić z nich infrastrukturę, gdzie oczywiście elementem kontrolującym jest termostat, ale to czujniki wskazują na rodzaj działania. I w tym wypadku czujniki w ogóle mi w apce nie sa potrzebne. Rozwiązałem to używając direclinków i mojego serwera, ale jak to już parę razy pisałem - nieelegancko. Nie chcę tym wpisem wywoływać dyskusji, ze można to było zrobić jeszcze inaczej, lecz bardziej wskazać na potrzebę, którą jak widzę Supla, jako zespół, jest w stanie zaadresować. Czekamy więc.


No i czekam na KTOP

Pozdrawiam serdecznie.

[Duch__]

Ja też mam moduł który odpowiada tylko za pomiary z DSów. Wysyła poprzez UDP globalnie dane do innych urządzeń które jak chcą to sobie je obrabiają. Wsród nich jest termostat który na podstawie otrzymanych pomiarów ocenia konieczność grzania w danym pomieszczeniu. Ma przekaźnik od pieca, a sam wysyła też poprzez UDP informacje do siłowników o konieczności otwarcia ich. Żadnych ceregieli, szyfrowań, tylko prosta suma kontrolna. Wszystko jest przesyłane jako Word, jako wartość dodatnia. Np. temperatura -21.2 to mnoże ją przez 100 czyli mam -2120 i do tego dodaje 10000. Mam wartośc 7880.

[klew]

To inaczej to sformułuję: w Supli to supla-client ma podgląd do stanu wszystkich urządzeń i może sterować. Między innymi aplikacje na telefonie używają tego komponentu;)

U nas te czujniki będą raportowane do serwera, bo z Clouda się to konfiguruje (przypisanie termometru, czy czujnika otwarcie do termostatu)