Ü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!

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.

Ü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.

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?

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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 )

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.

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.

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.

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ó.

Igaz, valóban külön szál, kell közéjük valami.

Hali!
Egymással sehogy. Kell közéjük egy szerver, amire mindkettő bejelentkezik, és ez a szerver "köti" össze a 2 cuccod.

Látom, ti nagy szakértők vagytok Sonoff témában. Nem tudom, jó helyen kérdezem-e de van egy problémám a Sonoff eszközökkel. Nevezetesen Sonoff basic Smart switch és S20 smart switch dugalj.
Android telefonról működtetem, addig nincs is vele probléma, amig van internet. Ha nem vagyok otthon, nyilvánvaló, hogy erre szükség van. De ha otthon vagyok, akkor sem tudom internet nélkül, közvetlen wifi-n át elérni. Másik problémám, hogy néha elég lassú az internet, 10-20 másodpercig is eltart, amíg végrehajtja a parancsot. Ráadásul időnként behoz egy ablakot, hogy azonosítsam magam, és ilyenkor mindig újra kéri a bejelentkezési jelszót, felhasználónevet.

Van egy Shenzhen gyártmányú, WeConn android programmal működő konnektor aljzatom is, ezzel nincs ilyen probléma, ha otthon vagyok, nem kell neki internet. Ráadásul évekkel ezelőtt adtam meg neki a jelszót és felhasználónevet, nem kéri néhány hetenként újra.

Van-e valamilyen program a telefonomra, vagy egyéb megoldás, hogy a Sonoff is elérhető legyen internet nélkül, ha a saját wifim hatótávolságán belül vagyok? Olyasmi is szóba jöhet, amihez saját szerver kell, mert van egy állandóan működő gépem, fix publikus IP-m is, és belül is tudok bármelyik eszköznek fix IP-t adni.

Tudtok erre valami megoldást?

A sonoff cuccok jó eséllyel úgy működnek, hogy a telefonod a jelet elküldi egy internetre csatlakoztatott szervernek, a switch pedig ezt pollozza, és ha van neki szóló utasítás akkor végrehajtja.
Gondolom megoldható helyi (LAN) szerverrel is, de sose foglalkoztam még ilyesmivel, én a gugliba begépelném a "sonoff local server" vagy "sonoff lan server" kifejezést, hátha okosabb leszek.
De ez esetben a távoli kapcsolgatás lehet macerásabb, bár ez se megoldhatatlan.

Bővebben: Link Ha egy programot írsz a szerveredre, lehet menni fog.

Sziasztok. Valamilyen szinten ide is illeszkedőt szeretnék kérdezni. Leendő lakásfelújításomnál Sonoff T1 kapcsolókat használnák fel. Vettem is T1 EU két csatornásból két darabot. Viszont kellene 3 csatornás is. Ebből viszont csak UK vagy US verziót találtam. Az UK ugye méretben és feszültségben is kb. ugyanolyan. Okoz valamilyen problémát ennek villamos beépítése, és működtetése, vagy nem. Első körben (és valószínűleg a másodikban is) semmit sem flashelgetnék rajt, maradna a gyári firmware. Az eWeLink alkalmazáson keresztül való kapcsolhatóság jó lenne, de nem létszükséglet. (A meglévő EU-s kétcsatornás verziónál ez működik, azt próbáltam)

Én most építgetem a saját rendszerem. Eddig jelenlét detektálás, két DHT22, egy Blizwolf dugalj és egy sonoff kapcsoló a tesztalany. Sok-sok kutatás, próbálgatás(zsákutca) után az alábbiakat használom. Saját mini-itx, hangtalan Debian szerver, MQTT bróker, NODE-RED, Domoticz. Próbálgatom a HassIO rendszert is, de az kicsit bonyolult még. A szerver DynDNS szolgáltatással bárhonnan elérhető. Hagyományos gép helyett mehet R-Pi is, az is tervben van. Az vásárolt ESP-s eszközöket újra kell programozni, hogy megszabaduljanak a felhőtől. Saját ESP8266 board = ESPEasy, Sonoff, blitzwolf = Tasmota firmware.
20 éve programozok PHP-ben, de meg sem fordult a fejemben, hogy ehhez alkalmazzam, nem erre való. Talán socket alapon, saját értelmezővel, de minek? Kész van minden, csak össze kell legózni és működik. vottokar! Felújításkor ne felejtsd el behúzni a 0 vezetékeket a kapcsoló aljzatba, mert az is kell neki.

Sziasztok.
Vásároltam Sonoff NSPanel villanykapcsolót:
https://sonoff.tech/product/central-control-panel/nspanel/
Tökéletesen működött, de a gyártó idiotizmusa miatt a kijelző csak levett a fényerőből és nem sötétedett el teljesen ami valljuk be éjszaka nagyon zavaró. Többen jelezték ezt a gyártó felé, de semmi válasz. Így muszáj volt csak ezért nekiállni és flash-elni.
Eljutottam addig, hogy a Pyton telepítve és konfigurálva. Vettem egy FT232-est és PowerShell-alól flash-eltem, majd telepítettem rá a Tasmota-t. Megvan az IP cím, be tudok rá webes felületen jelentkezni. Viszont az MQTT beállításában elakadtam. Tény, hogy nem megy jól az angol, de sehol nem találtam arról infót, hogy hol kell ezt regisztrálni, mit kellene csinálni?
Eszerint a videó szerint dolgoztam, bár a github-os Tasmota-val. (https://tasmota.github.io/install/)
https://www.youtube.com/watch?v=sCrdiCzxMOQ

Sajnálatos, de az MQTT engedélyezés/beállítása nélkül nincs időjárás adatom-ami kellene.
Ebben kérném hozzáértők segítségét.
A mostani "divat" szerint már a Home Assistant (https://www.home-assistant.io/) telepítésével konfigurálják, de a Home Assistant telepítésével is megrekedtem. Fent van Win 10-en a mobaXterm. Rajt az WLS-Ubuntu-22.04. A 'virt-manager' parancsra azonban megnyílik a Virtual Machine Manager de hibaüzenettel. A QEMU/KVM-et kellene helyesen beállítani, ( Username és Hostname)
Gondoltam hátha valaki már küzdött ezzel.....és tud segíteni.