Fórum témák

» Több friss téma
Fórum » Sonoff kapcsolók informatikai háttere (rendszer topológia)
Lapozás: OK   1 / 1
(#) superuser hozzászólása Nov 5, 2018 /
 
Üdv!

Az lenne a kérdésem a hozzáértőkhöz, hogy milyen rendszer topológiával valósíthatják meg pl. a Sonoff, vagy más hasonló internet alapú kapcsoló eszközök folyamatos online elérését?

Kicsit bővebben: A Sonoff egy olyan hálózatban van, ahonnan csak kifele lát, kívülről nem érhető el.
A mobiltelefonom szintén olyan hálózatban van ahonnan kilát, de visszafele nem érhető el.
A mobilon futó alkalmazás viszont bármikor megtalálja a Sonoffot és kommunikálni tud vele.
Engem ez a része érdekelne.

- Hogyan tudok felépíteni egy ilyen szolgáltatást anélkül, hogy egy saját szervert üzemeltetnék?
- Létezik-e pl. olyan szerver szolgáltatás, ami mondjuk lehetővé teszi két TCP kliens közötti
adatátvitelt?

Köszönöm a válaszokat előre is!
(#) Johnycorp válasza superuser hozzászólására (») Nov 5, 2018 / 1
 
Szia.

A nagyságrendi elv hasonló, mint például a Skype kliensek esetében is, vagy a mai legtöbb videórögzítőnél és azok mobilos klienseiknél.

A Sonoff feljelentkezik egy szerverre a saját azonosítójával. Elküld adatokat (pl: a kimenetének az állapota) és megnézi, hogy van-e kiadott parancs kimenet kapcsolására.
A kliens program is erre a szerverre kapcsolódik és a szervertől megkapja a Sonoff által küldött adatokat valamilyen formában. Meg értelemszerűen ő küldi a szerver felé a kimenet kapcsolásának a parancsát.

Így nem kell látniuk egymást közvetlen, a szerver pedig mindig ugyanott, ugyanazon Ip címen van az interneten.

Saját szerver nélkül nehézkes ezt megcsinálni, helyi hálózaton vannak rá lehetőségek (saját maga az eszköz a "minimalista" szerver és ahhoz kapcsolódsz mobillal).
Egyéb esetben saját szerver kell, megfelelő konfigurációval, adatbázissal, API-val.

A kezdetekben én is csináltam az ESP8266-ra közvetlen elérést. A legutóbbi megoldás pedig a Sonfoff-hoz hasonlóan megy. Főleg mivel nekem is különböző helyeken vannak az eszközök és még máshonnan nézem én és vezérlem azokat.
(#) b10up válasza superuser hozzászólására (») Nov 5, 2018 /
 
Üdv,

Szedjük ketté, ugye van az, hogy nem látsz bele kívülről egy hálózatba, mert NAT mögött vagy. Vagy saját router, vagy szolgáltató miatt, ez nem is lényeges.

És van a másik, hogy adott egy szerver, amit ezek a szolgáltatáshoz tartozó eszközök ismernek és indítanak oda egy (vagy több) kapcsolati szálat. Ez NAT mögül is megy. Ha már a szál nyitott és aktív,akkor ezen kétirányú az adatáramlás. A kliens tesz róla, hogy ez a szál mindig aktív legyen, a szerver pedig fogadja ezeket.

Szóval mondjuk vegyünk egy Spotify klienst, be vagy lépve telefonon mobilnetről és gépen is. Ott úgy irányítod az egyikből a másikat, hogy a szerveren keresztül, ami azt hiszem legkorábban a svédeknél van. Szóval a szervernek megy az egyik kliensről kérés, hogy mi történjen, és az parancsol ki a másiknak.

Itt meg ugye nem kell nyitott port a klienseknél, mert a szálat ők indítják a központi szerver felé.

És hogy válaszoljak sorban:
-P2P-vel lehetne kísérletezni, de a megbízhatósága és a NAT miatti problémák miatt érdemes szerverezni.
-Attól függ, milyet szeretnél. Felhős VPN-ek is vannak, de ha konkrét célod van, arra lehet, hogy konkrét appot kell/érdemesebb írni.
(#) superuser hozzászólása Nov 5, 2018 /
 
Ok, kell szerver. A hangsúly elsősorban a 'nem sajáton' volt.
Nyilván az egyik kézenfekvő megoldás amikor megírja az ember a szervert és beállítja egy szolgáltatóhoz. Lehetőleg nem ezzel szeretnék kezdeni.

Másik megoldás, ha pl. PHP alkalmas lenne a feladatra, hogy a bérelt web tárhelyemen fut az alkalmazás és sok teendőm nincsen vele.

Harmadik megoldás - indulásnak ez lenne a legtisztább - ha valahol létezik ilyen szolgáltatás alapból és csak a használatáért kell fizetni, adat alapon, vagy a kliensek száma szerint.

Szóval a kérdés továbbra is az, hogy milyen módon lehetne hatékonyan összekötni egymással a klienseket.

@Johnycorp: nálad milyen szerver futott?
(#) b10up válasza superuser hozzászólására (») Nov 5, 2018 /
 
Nem írtad, hogy mit szeretnél pontosan, de bizonyos feladatokra még a PHP-t is el tudom képzelni, hogy használható.
Bár nem tartom szerencsésnek, de PHP fájlokkal is lehet kétirányú átvitelt csinálni a longpolling nevű technikával. Ilyen alapú pl nagyon sok webes chatprogram.
(#) superuser válasza b10up hozzászólására (») Nov 5, 2018 /
 
Technikailag ugyanazt ami pár Sonof kapcsolóhoz szükséges.
Példaként vegyünk épületautomatizálási rendszereket. Vannak egymástól független végpontok, routerek mögött. Vannak végfelhasználók, akik mobilalkalmazásból akarják elérni a végpontjaikat. Elsőre maximalizáljuk 100 darabban a végpontokat és egy ennél alacsonyabb számban a usereket.
Minden végpontnak van egy pár bájtos státusz információja. Visszafele a végpontok (szintén pár bájtos) vezérlő parancsokkal kontrollálhatóak.
A mobilalkalmazásokban legyenek folyamatosan online státuszúak a végpontok.
Ha változik a végpont státusza, az automatikusan érkezzen be az alkalmazásba.
Ha a user vezérlő parancsot ad ki a végpontnak, az hajtódjon végre.
1 másodpercnél sokkal többet ne kelljen várni a felhasználónak.
Dióhéjban ennyi.
(#) Johnycorp válasza superuser hozzászólására (») Nov 5, 2018 /
 
Nekem jelenleg is kétféle megoldás fut, kétféle helyen.
A régebbi hely egy saját Banana PI, melyen Apache, MySQL, PHP (LAMP) fut.
Ezen egyszerű, PHP-ban írt program teszi a dolgát (bejelentkezés, adatbázis kezelés, adatok fogadása GET módszerrel [valami.php?id=12345>>>>>>>>>>>>>>&data1=123>>>>>>>>>&data2=456 formátumban>] ).
Ez a diplomamunkám része volt egyebekkel együtt.

Ez a PHP alkalmazás van most átrakva egy bérelt VPS szerverre. Pár eszköz (saját) még használja.
De az újabb már teljesen átdolgozott és most is az alatt van.
Egy komplett példány már fut belőle 30+ klienssel egy internettől elszigetelt hálózaton (igen, direkt), fizikai szerveren Ubuntu Server + LAMP kompozícióval, adatgyűjtés céllal.
Ez már megérne egy bemutatót itt, mint érdekes home-made projekt.
(#) b10up válasza superuser hozzászólására (») Nov 5, 2018 /
 
Folyamatban van nálam egy komolyabb épületautomatizálási rendszer kivitelezése. Egyelőre csak tervezőasztalon létezik, és még súlyok hónapok, mire prezentálható állapotba kerül. De ott az lesz a koncepció, hogy a vezérlő egységek RS485 buszon fognak lógni, ezeket egy IP alapú buszvezérlő fogja összefogni, majd ezek bejelentkeztethetőek lesznek egy saját felhős rendszerbe.
Felhasználó felé android app/sima reszponzív weblap lesz, jogosultságokat rendesen elkülönítve.
A kliensek pedig a felhő felé mindig nyitva tartanak egy TCP kapcsolatot.
Attól függ, mennyire gondolkozol komoly eszközökben és funkciókban, ez lehet mérsékelten egyszerű és nagyon bonyolult projekt is.
(#) superuser hozzászólása Nov 5, 2018 /
 
Hát igen, átfutott az én fejemen is, hogy indulásként mehetne egy Raspberry pi + DynDns egy bármilyen hálózatra ráültetve, még az is lehet, hogy ezen a vonalon fogok elindulni.
(#) b10up válasza superuser hozzászólására (») Nov 6, 2018 /
 
Kísérletezéshez mindenképpen tudom ajánlani a Raspberryt. Szerintem a legérdemesebb úgy elindulni, hogy írni rá egy programot, ami konkrétan a végrehajtó eszközökkel kommunikál, ezt a programot pedig valami PHP+javascript alapú weblappal tenni elérhetővé a felhasználóknak. Aztán ha nem lenne elég az RPi, simán lehet költöztetni nagyobb gépre.

Ha nagyon muszáj, még a bérelt tárhelyen is meg lehet oldani pusztán web alapon, bár annak a válaszideje és hatékonysága nem feltétlenül a legjobb.
A hozzászólás módosítva: Nov 6, 2018
(#) proba válasza b10up hozzászólására (») Nov 6, 2018 / 1
 
Nem tudom, egy HTML alapú kérés meddig él. Ha sokáig akkor egy sima szolgáltatóval is meg lehetne csinálni, eszköz adott időnként megkérdezi a szervert van e parancs számára, a szerver viszont csak akkor válaszolna, ha szükséges. Így úgy gondolom szinte valós idejű lenne a folyamat. Azt vettem észre, ha a php szervert valami hosszú folyamatra kényszerítem, a kliens áll le időtúllépés miatt. Tehát ha a klienst rábeszélem, sokáig várjon a válaszra, akár kevés lekérdezés is elég lehet. Ami még eszembe jutott, rádiót lehet hallgatni reggeltől estig, tehát valami erre alapuló protokollal is lehetne egyszerű szolgáltatói oldalon keresztül kommunikálni.
(#) b10up válasza proba hozzászólására (») Nov 6, 2018 /
 
Egy kérés kb 20-60 másodperc, mire timeout a vége. Ez úgy általánosságban. Aztán ha ez letelik, úgy szokták, hogy javascript egyből indítja a következő kérést, így végülis van egy folyamatos szál a kliens felé.
Folyamatosan nyitva tartott megoldás kell, így akár egy másodperc alá is szorítható a kapcsolási idő.
Egyébként nem is kell az időtúllépésen módosítani, jó így, ha mindig új kérést küld a kliens, ha túllépi az időt.
A rádió az jópár elven működhet, ott szélesebb a szórás.
(#) superuser válasza proba hozzászólására (») Nov 6, 2018 / 1
 
A HTTP rerequest elnyújtása egy érdekes gondolat, csak a két kliens összekötéséhez kell egy összekötő kapocs. Gondolom ez tipikusan egy adatbázis lenne. Ebben az esetben viszont a két kliens másodpercenként olvasná a táblát, hogy a másik írt-e bele valamit, ami nem igazán szerencsés megoldás.
(#) b10up válasza superuser hozzászólására (») Nov 6, 2018 /
 
Ezért nem szerencsés tisztán webesen megcsinálni.
Viszont hogy ne gyilkolja a hardvert, egy olyat lehet csinálni, hogy a php fájl önmagában egy átjáró legyen.
Kliens eszközön betölt egy keret, háttérben pedig csak ezt a php fájlt hívogatja meg, amiben csak pár bájt adat van, ha szükséges, ha nincs változás, akkor pedig semmi.

A php fájlban csak annyi lenne, hogy kapcsolódik localhoston egy saját készítésű szerver apphoz, ha az küld adatokat, akkor azt simán átnyomja a böngésző felé xml vagy hasonló formátumban, egyébként csendben figyel. Ezt azt hiszem aszinkron kóddal meg lehet írni, tehát a php csak akkor használ CPU időt, amikor forgalom van, vagy amikor időtúllépés miatt záródik az előző szál.

A szerver háttér, amihez a php kapcsolódik ott pedig csak RAM-ban lennének tárolva a várakozó parancsok X másodpercig vagy darabszámig, ami ki lett küldve, az onnan mehet is ki. Egyrészt így nem használja el az SD kártyát vagy egyéb háttértárat, kellően gyors is, és ha valami egyéb trükköt is alkalmazol, hogy ne kelljen a teljes várósort lekérdezni, hanem triggerelve legyenek ilyesmi átvitelek, akkor így már egy elég hatékony rendszert lehet alkotni - szerintem.

Legalábbis ez kompatibilis mindenfajta plugin nélkül. Persze ha nem saját eszközök és mindent te felügyelsz, célszerű lehet a klienset is megírni a projekt bonyolultságától függően.
A hozzászólás módosítva: Nov 6, 2018
(#) proba válasza superuser hozzászólására (») Nov 6, 2018 /
 
Nem adatbázisra gondoltam, Az macerás, és nem valós idejű. Egy weblapot megjelenítő PHP rutin szerintem elég. Az addig nem küld választ a HTML kérésre amíg nincs új információ. A vevő csak várakozik, míg a PHP rutin nem válaszol, vagy idő túllépés ideje előtt valamit küld, hogy egyáltalán van e kapcsolat. A mobil feljelentkezésekor a php érzékeli ezt, és a vevő megkapja a megfelelő választ azonnal. A vevőnek csak 20-30 s-ként kell csak kérnie. Változáskor a válasz azonnal jön. ( a 20-30s időtúllépést a böngésző adja szerintem, azt esetleg ki is lehetne tolni )
(#) superuser válasza proba hozzászólására (») Nov 6, 2018 / 1
 
Nem vagyok otthon a php-ben, de azt gondolnám, hogy a két kliens az két külön PHP szálat indít (?session?), abban az esetben is, ha azonos URL-re hivatkoznak. Feltételezem a session-ok nem látják egymás változóit, nem tudnak egymásra hivatkozni. Ezért írtam, hogy kell egy összekötő kapocs a két kliens között.
(#) tbarath válasza proba hozzászólására (») Nov 6, 2018 /
 
Szerintem nem érdemes állandó kapcsolatot kiépíteni a szerver felé, legalábbis hosszú távon ez eléggé overkill. Sok szálat kell nyitva tartni, azok mind erőforrást esznek, és teszik ezt fölöslegesen.

Én valahogy úgy csinálnám, hogy az eszköz felcsatlakozna a szerverre mondjuk 5 percenként, ez rendes https-en, autentikációval, stb. Ha itt van valamilyen parancs akkor ezt természetesen végrehajtja, de kap mellé pl. 30 http linket is, valami ilyesmit:
http kettőspont perper server.tld/eng5eiMFei9eet8yaighiD8uw1Yu8a
És ezeket 10 másodpercenként sorban meghívja, amire az adott szerver csak egy response kóddal válaszol, ami lehet "rendes" http status code is, de akár 0 és 1 is. Az egyik jelentése annyi, hogy az eszköznek nincs tennivalója, a másiké pedig az, hogy van. Ha van, akkor https-en autentikál, lekérdezi, stb. Ezáltal a server felé is meglenne a heartbeat, a kliens is viszonylag gyorsan reagálna (a 10 sec csak példa, lehet kevesebb is), és a server terhelése se lenne akkora.
(#) 77blsoft válasza superuser hozzászólására (») Nov 7, 2018 / 1
 
A sonoff-ban ESP8286 IC van. Létezik olyan firmware, amelyiket te tudsz konfigurálni és belső hálózaton keresztül tudsz kapcsolódni rá, de ha beállítod akkor a külvilág felől is tudsz kapcsolódni a belső hálózatodra kapcsolódni.
Persze a router-edben érdemes FIX IP-t fenntartani a SONOFF-nak.

Pl. belső hálózatról:
Relé on:
http://192.168.1.82/control?cmd=GPIO,12,1
Relé off:
http://192.168.1.82/control?cmd=GPIO,12,0
Bekapcsolás 2000 ms időre:
http://192.168.1.82/control?cmd=Pulse,12,1,2000

A nyomógomb a GPIO,0

Külső hálózatról tudsz használni szervert, ami az dinamikus IP címet azonosítja.
- Egyszer regisztrálsz a szerverre.
- A routeredet beállítod, hogy közölje a szerverrel, hogy ha új IP-t kaptál, valamint a portot engedélyezed.
- Már tudud is vezérelni, amit akarsz. Pl. http://Nagymate.dyndns.com/control?cmd=GPIO,12,1

Youtube link a FW update-ről és a SONOFF beállításáról:

Csatoltam az EASY FW leírását is.

Lehet, hogy nem túl biztonságos, de működik ez is.
(#) superuser válasza 77blsoft hozzászólására (») Hé, 18:08 /
 
Köszönöm, de a kérdés elsősorban arra vonatkozott, hogy két"router mögötti" eszköz hogyan épít fel egymással kapcsolatot. Általánosan működő megoldás szükséges, port forward + dyndns nem járható.
(#) proba válasza superuser hozzászólására (») Hé, 19:40 /
 
Igaz, valóban külön szál, kell közéjük valami.
(#) pipi válasza superuser hozzászólására (») Hé, 19:42 /
 
Hali!
Egymással sehogy. Kell közéjük egy szerver, amire mindkettő bejelentkezik, és ez a szerver "köti" össze a 2 cuccod.
Következő: »»   1 / 1
Bejelentkezés

Belépés

Hirdetés
Lapoda.hu     XDT.hu     HEStore.hu