Gree klíma sűrűn elveszti a WiFi-t

Fórumok

Üdv,

Van 2 db Gree klímám az emeleten - router(mikrotik)(Unifi AP) a földszinten - felcsatlakozok velük a WiFi-re, aztán néhány nap múltán elvesznek ott.
Ugyanitt minden más WiFi-s külyü (tel., lapopok, esp8266, stb.) stabilan megy

Hirtelen azt sem tudom mit írlak le.
Találkozott vki ilyennel?

Köszönöm!

Hozzászólások

Első tipp, 2.4, vagy 5ghz-n csatlakoznak ? Ha 5g-n akkor érdemesebb lenne átrakni őket fix 2.4-re

Ha mikrotik lenne a WiFi is, akkor mondanám kapcsold be, hagy logolja mi is történik a WiFivel. Mivel dobja el. Hány decibel a jel. Eldobás után újra kéne csatlakoznia a kliensnek ... Unifi esetén nem tudom ezt hogy csinálja de ott is mond valamit nem?

Syen klímám van, az is gree. Akkor volt ilyen, amikor a csatorna 12 volt vagy felette.

Szerkesztve: 2022. 08. 12., p – 18:02

Ez sajnos ilyen. Nálunk tucatnyi Gree klíma van, random dobálják el a WiFi-t. Nálam UAP-AC-LR van, esetleg lehet, hogy valamennyire Unifi specifikus lenne a probléma?

Van IPv6? Anno hasonló gondom volt egy laptoppal MikroTik routerrel (ott mondjuk az AP is MT volt). Minden eszközön hibátlanul ment a Wi-Fi, kivéve adott gépen. A megoldás az IPv6 RA packetek intervallumának növelése és szórási gyakoriságának csökkentése volt. Ha használ v6-ot a Gree, esetleg ezt is érdemes lenne megnézni.

TheAdam

A mobiltelefonos app segítségével tudod a klíma firmware-ét frissłteni. A korábbi verziókkal tényleg nagyon sűrűn volt kommunikációs probléma, de a jelenleg aktuális 3.72-vel már szinte stabilnak mondható a kapcsolat :)

http://eVIR.hu
Elektronikus Vállalatirányítási Információs Rendszer

Nálam csak 8 karakteres vagy rövidebb PSK-vel volt hajlandó csatlakozni.

sokféle klímám van/volt. kb mindegyik ugyanavval a fos wifi modullal van ellátva. legalábbis én még nem láttam, csak egyfélét 6 fajta klimában.

mindegyik modul ugyanolyan szar, instabil szarkupac, kb eltörném a kezét aki ezt gyártja és beépíti.

A közelbe kell rakni egy AP-t, ami 2,4-es IPv4-es, és max WPA2-őt használ.

Volt olyan klimám, amit végül egy infra hub-ra tettem inkább, mert infarktusközeli állapotba kerültem tőle

Nekem is Gree klímám van, de azonnal a wifi kikapcsolásával kezdtem, hogy feleslegesen ne fogyassza az áramot.

Mi értelme van engedélyezni?

Amikor arról olvastam, hogy a wifi csatlakozik a kínai kommunista munkáspárt forradalmi felhőjéhez, hogy értesüljenek az elvtársak a beállított hőfokról, inkább kihagytam.

a setuphoz kell az app (bár ha nagyon fáj, talán körbe lehet járni), de utána pl a home assistant integrationja localban basztatja az eszközt (ki is lehet baszni a kommunikációt tűzfalon): https://www.home-assistant.io/integrations/gree

egyébként ezt használja belül: https://github.com/cmroche/greeclimate/tree/master/greeclimate

De egyébként egyrészt értem én, hogy jajj kínai felhő, meg persze, jobb lenne az mqtt vagy a rest direktben, de azért lehet, hogy valakinek mégsem ez az elsődleges szempont a klíma választásánál, szóval lehet, hogy tud együtt élni vele.

A másik meg, hogy kissé siftelsz. Most akkor az a kérdés, hogy minek, vagy szorongol a komcsikon?

Gagyi cuccokat nem szoktam használni.

Nincs kedvem pythonnal warezolni, helyette értelmesebb dolgokkal foglalkozom, megnyomom a wifi off-ot és nem fogyasztja az áramot.

MQTT vagy REST, esetleg HTTP lenne az alap, de ha a usernek a forradalmi felhő kell, akkor használhatja.

Rohadtul irritál, hogy cuccokra ráírják, hogy wifi-s azt noname oldalakkal kommunikál és megpusztul, ha a cég tönkremegy.

A GREE nem támogatja a wifi-t csak valami homályos vackot, ami ha leáll, akkor sorry.

Hát, a warezolas annyiból ált, hogy felraktam a gree plugint a HAba, amibe egyébként is minden ilyesmi bele van kötve, épp azért mert bassza meg az összes smart izé a felhőt, meg a mindenkinek van rgy univerzális megoldását.

De értem, hogy csak puffogni akartál, nem voltál valójában kíváncsi arra, hogy mi értelme van az ilyennek. 

Nem puffogok, csak véleményt írtam a GREE klíma wifi funkcionalitásáról. Annyira elégedett vagyok vele, hogy wifi-s cuccot már nem veszek pont az ilyen faszságok miatt.

Csak okos konnektoraim vannak, átwarezolva Tasmotára.

Norvég fűtőpanelt néztem, szerencsére van még wifi nélküli, olcsóbb is egy 10-essel. Van rajta 3 gomb, azt megnyomod a wifi-t meg lehúzhatják a klotyón. Főleg ha a GREE szintjét produkálják.

Az nem baj, csak én tényleg azt hittem, hogy a minek a klímába egyáltalán wifi a kérdés :)

Egyébként én pont az itt fikkantott szar wifi részét használom (de nekem hálisten nincs vele stabilitás bajom), a felhőt nem, a linkelt plugin egy (gondolom) reverse engineerelt implementáció. Nyilván én is jobban örülnék neki, ha nem ilyen lenne, hanem lenne valami tisztességes protokol benne.

Ilyen ember vagyok. 15 éve vettem egy külső racket, feldugom, a rendszer nem ismeri automatikusan fel, driver kell hozzá, ami csak Win95 alá készült.

USB mass storage helyett fusiban HID eszközként implementálták, azt nem ment driver nélkül. Még aznap ment vissza az eladónak.

Nem bírom, ha a szabványos megoldások helyett ipari hulladékokat készítenek.

Lehet, hogy neked működik HA-val, de supportot kapni a Gree-től nem fogsz, az biztos.

Azt mi van, ha a következő fusi verzió a klímából inkompatibilis lesz a HA-val? Az ipari hulladékok így viselkednek...

Kicsit olyan érzésem van, mintha nem egy mozit néznénk. Mármint próbálsz meggyőzni arról, hogy ez így nem optimális, miközben én egy szóval nem mondtam, hogy az. Persze, hogy nem fogok a greetől supportot. ( Te se fogsz a tasmotára. ) Cserébe ez amíg az eszköz megy, addig fog működni, mert a klíma oldalát biztosan nem fogom lefrissíteni, a HAt pedig meg fogom oldani, ha véletlen elbasznák. De még ha az be is dől, B terv még akkor is van, ha nagyon kellene.

Amikor a klímát vettem, akkor nem volt magasan a prio listán, hogy legyen távvezérelhető (igazából egyáltalán nem volt rajta), de ha már ilyen, akkor használom, attól függetlenül, hogy az architektúra fos.Értem, hogy te inkább kikapcsolod, mert neked nem kell, csak azt nem tudom, miről akarsz meggyőzni? Én elhiszem neked, pusztán próbáltam megváloszolni a kérdésed, hogy minek bekapcsolni.

Más is eljutott ám odáig, hogy nem elég warezolni, de a külső netet is meg kell vonni a Gree wifitől a stabil működéshez.

Csak ahelyett, hogy bozótharcba indultam volna a dzsungelbe rituális hókusz-pókuszok közepette, nemes egyszerűséggel lenyomtam a wifi off gombját és elfelejtettem a történetet.

El kell fogadni, hogy vannak emberek, akik a döglött lovat nem kívánják mindenáron életben tartani.

Tényleg nem értem ezt a beszélgetést, kisegít valaki esetleg, hogy hol beszélünk el egymás mellett? 

Én teljesen elfogadom, egészségedre, sose akartalak meggyőzni róla.

(a külső net pedig alapból meg van vonva az összes iot eszközömtől, szóval ez nekem nem probléma) 

Elmagyarázom tömören. Az a gondom, hogy egyes cégek üzleti érdekből a létező és jól működő szabványok helyett fusimunkákat produkálnak.

Ráadásul ráírják, hogy az eszköz Wifi-t támogat. Ilyenkor kellene az Európai Uniónak fellépnie, hogy akkor lehet ráírni egy eszközre, hogy Wifi-t támogat, ha

- szabványos MQTT, vagy REST, vagy HTTP interfésze van (eldönthetik a szakik, hogy melyik)

- tetszőleges felhőhöz tud csatlakozni, nem muszáj pont a gyártóéhoz

Amíg az unió nem lépett fel, az összes telefongyártó az összes telefonjához más töltőt adott, mert nehogy már a Nokiát és az LG-t ugyanazzal az USB kábellel töltsd.

Vegyél minden telefonhoz más töltőt.

Nagyon hiányzik a szabályzás a területen. Könnyebb lenne kompatibilis eszközökből okos otthont építeni, csak ez a gyártóknak rohadtul nem érdeke.

[akit a konkrét gree wifi érdekel, lapozzon nyugodtan, bocsi]

Ezzel én egyet értek, elméletben legalábbis biztosan.

A gyakorlatban kicsit nehéz ügy, most attól tekintsük el, hogy a REST meg a HTTP az eléggé ugyanaz, és a REST nem egy szabvány (ráadásul 100-ból 99 magát RESTnek hazudó API valójában nem az), a nagyobb baj, hogy a terület ennél sokkal bonyolultabb.

Egyrészt van már olyan ezen a területen, ami szabvány, lásd zigbee, (meg tulképp a zwave), és remekül lehet látni a zigbeenél, hogy ugyanúgy szopkovics van, mert mindenféle proprietary extensionök vannak, meg a szabványban (egyébként jogosan) nem kötelező dolgok nincsenek leimplementálva olyan eszközökben sem, ahol egyébként nyugodtan lehetne.

Másrészt azért ez egy erősen turbulens terület, nem annyira jó ötlet bezárni őket valami konkrétumba. A telefontöltő jó példa, nézd meg, hogy mekkora effort most átállni a korábbi micro usbről az usb-c-re, pedig az egy jóval egyszerűbb probléma, jellemzően gyorsabb turn-around timeos eszközökkel.

Harmadrészt hiába mondod azt, hogy legyen pl REST, igazából nem vagy előrébb ezzel, mert azt, hogy ott pontosan mi hol van, mit kell csinálni, azt még mindig nem tudod ebből, és ugyanúgy le kell wrappelni valahol lokálisan. A HA (meg a másik legalább 5 hasonszőrű életképes projekt) mondjuk egészen jó példa arra, hogy sokkal fontosabb volna, hogy legyen az eszközhöz APIjához kötelezően jó doksi, hogy esetleg legyen valamennyi minimális előírt featureset (bár ez már elég nehéz), hogy kötelező legyen olyan APIt adni, amit lehet használni a gyáró külső szarja nélkül (tehát igen, ha secure kulcsokkal bohockódol, akkor le kell írni, hogy hogy tudom helyettesíteni), mintsem az, hogy konkrétan milyen. Mert ha le van írva, akkor lehet jól csinálni, ha van rá igény, ha meg nincs, akkor jönnek az ilyen reverse engineerelt baszások, amik pl ehhez a greehez vannak jobb híján. A reverse engineer a nagyobb baj, nem az, hogy vmi udp felett menő bohóckodás igazából.

Negyedrészt azért elég nehéz ám scopeolni, hogy ki az, akinek meg kell felelni az ilyesminek. Ok, az okos konnektor játszik*, mondjuk az elektromos radiátorszelep is. A klíma, hát az már határeset, de mi van pl a tököm rádiós időjárás állomással, vagy pl az androidos tévémmel? A wifis hangszóróval?

Negyedrészt, bár ez a legkevésbé érdekes, de a HTTP és a REST pont elég fos választás, mivel az ilyen eszközök jellemzően akarnak felfele adatot közölni.

*egyébként minek baszol tasmotaval, ott a shelly, natívan beszél mqtt-t, ha arra játszol, de a saját coap alapú protokoljuk is teljesen jó. Van doksi, by design mennek a saját felhőjük nélkül (hálistennek, mert a facet nézve, azt nem tudnak jót írni), nem értem, miért nem kapcsolod ki a wifit az ipari hulladék okos konnektorodban :)

Mérsékelten akarok ebbe a csodás beszélgetésbe beleugatni, de amúgy a HTTP/REST annyiból jobb választás, hogy sokkal több mindennel integrálható lehet, mint az MQTT. HTTP-t rengeteg minden beszél, mást már sokkal kevesebb. Igen, az IoT rendszerek igen, de nem mindenki akar natív IoT-be integrálni dolgokat, ellenben pl bármilyen chaten ráírok a wifire, hogy "cool fan médium" és ehhez nem biztos, hogy MQTT gatewayekkel akarok szopni, HTTP-t tudó botok meg vannak zsákszámra.

És igen, tudom, hogy a HTTP-nek megvannak a maga limitációi.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Persze, HTTP kérést küldeni beállítani egyszerűbb. Csak minden mást meg nem, szóval kötelező szabványnak nem jó előírni, mert akkor vagy minden nagyon szar lesz, vagy szopkodhatsz a websockettel, ami szintén nem triviális (és nagyon szar lesz). 

Ráadásul a dilemmád egy kicsit hamis dilemma, mert igazából valami hub mindig van. Kb három jellemző setup van:

  • google/homekit/smartthings eszköz direktben
  • random gyártó felhői (opcionálisan, de jellemzően bekötve a fenti háromba is, mert az az integrációs platform)
  • vmi local hub

Ezeknek viszont már mindig van HTTP APIjuk, konfigurálhatsz kedvedre, meg integrálhatsz chatbottal meg google voice assitanttal/sirivel (ráadásul mindegy is neked hogy http vagy galambposta, mert csak kattogtatni kell) orrvérzésig, ettől még a local hálón az eszközöknek jobb vmi, ami tud visszirányba működni, meg valami pubsub/multicast jellegű módon megy.

Értem, hogy a van egy darab eszközöm, és azt akarom kézzel baszni egy kicsit nehezebb, de igazából az egy elég irreális usecase (és igazából nem nehezebb, mert azt úgyis bekötöd a szolgáltató izéjébe, aztán tolhatod)

Persze ettől még jó, ha van HTTP, szokott is lenni, csak ha arról beszélünk, hogy mi legyen a kötelező mindenkinek, akkor plz no.

Alapvetően egyetértek veled (küldtem vissza hőszivattyú wifi modulját, miután megláttam, miként működik és milyen a kapcsolódó adatkezelés, lehet, hogy ugyanarról beszélünk, tekintve mennyire tömegtermék), a gond ott van, hogy a tömeg még nem érett meg az integrált automatizálásra így nincs rá igény. Arra van igény, hogy +1 ikon legyen a telefonján és azt tudja nyomkodni. Akkor lesz rá igény, ha túl sok lesz az egyedi ikon és rájön, hogy akár összehangolni is lehetne dolgokat, de ennek még kell néhány év.

Mikor megrendelted a terméket sehol nem írták le, hogy integrálni fogod tudni, csak azt, hogy Wifi-n elérhető. És ez végülis igaz. Ez olyan, mikor veszel egy autót és rájössz, hogy ez és az nincs benne, pedig annyira alapnak tűnik.

Egyébként a visszaküldött wifi modulomnak utána néztem, szinte biztosan innen vagy ilyet vettek: http://www.fschico.com/?cid-221_id-178_productinfo.html. Ennek a cégnek egy másik alkalmazása kapcsán az adatkezelési tájékoztató: https://sites.google.com/view/chico-privacy-policy, "We want to inform users of this Service that these third parties have access to your Personal Information. The reason is to perform the tasks assigned to them on our behalf. However, they are obligated not to disclose or use the information for any other purpose.". Az, hogy kik ezek, mégis milyen adatok - semmi részletezés. Nyilván lehet mondani, hogy egy hőszivattyúnál nincs különösebb kritikus adat, de engem ez akkor sem nyugtat meg.

Hasonló a napelem: tervezek venni, az inverterek is elérhetők "Wifin", de például korántsem tűnik általánosnak a külső adatkinyerés. Talán SolarEdge-nél van valami API, amivel a portáljukon keresztül eléred az adatokat, de áramszünet esetén ezt nem biztos, hogy eléred, holott akkor lenne leginkább szükség rá (lekapcsolod, ami annyira nem fontos/később is ráér). Elvileg van modbus/TCP, de számomra az jött át, hogy az nem szempont, hogy közvetlenül az inverterből kinyerhesd a saját adataidat.

Ez viszoont nem a konnektor hibaja, hanem a radugott keszuleke. Az a keszulek, ami folyamatos uzemeltetesu, es egy aramszunet utan nem kepes magatol elindulni, az nem alkalmas folyamatos uzemeltetesre.

"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

subs.  pont tegnap szerteltek be (gree gtech), be is lottem a wifit es az appjukat telefonra, unifi uap-ac-lr van tole par meterre de 13-as csatornan (minden mas full foglalt), kivancsi leszek, remelem nem fog szakadozni.

Nálam 2 Gree Comfort X működik több, mint egy éve full unifi-s hálózaton (U6-Lite AP-ken). Az ajánlott 1,6,11 csatornákat használom. Atomstabil a kapcsolat. A klímák kb. 4-5 méterre vannak az AP-któl.

Unifi használóknak: 2.4GHz-en csak ezek vannak aktiválva:

Proxy ARP - Enabled

BSS Transition - Enabled

802.11 DTIM Period - 3

Minimum Data Rate Control - Auto

Security Protocol - WPA2

ARP-nél IP -> MAC address feloldáshoz a kérdező a teljes subnet-nek küld egy broadcast üzenetet és akihez tartozik az IP az válaszol neki a MAC cimével. Ez wifi-n rohadt pazarló, ezért ha bekapcsolod ezt a kapcsolót, akkor az AP, ha ismeri a kérdéses MAC/IP párost, akkor egyrészt nem küldi ki minden kliens felé a broadcast kérést (lebutitva minden kliens sebességére B/G/N/AC/AX) sőt a kliens nevében válaszol is a kérdezőnek, ezáltal nem lassitva be hülyességgel az egész csatornát.

Tehát az AP proxy-ként eljár a kliensek nevében ARP kérésekben, innen a név.

Hát, akkor ez is tisztességes, mert pont ezt írja ő is, csak használja a frame szót. De szerintem nem ezt jelenti, mármint nem tudom minek ide belekeverni a unicastod, a proxy arp alapvetően azt jelenti, hogy amikor egy broadcast tartományban valójában nem érhető el mindenki, mert van valamilyen gateway jellegű eszköz, akkor az fog válaszolni az arp kérésre. Ennek klasszikus példája, mikor egy subneten belül van egy tűzfal, a kliensek azt hiszik, direktben tudnak egymással beszélni, de igazából a router válaszol helyettük, kapja meg a csomagot, majd routeol.

De amit Imo mond, lényegében az is majdnem ugyanez, bár az inkább cachenek hangzik igazából, mintsem arp proxynak (hiszen nem hazudja az AP a saját MACjét). De azt továbbra se értem, hogy a magyarázatba minek a broadcast, meg a unicast (mmint sejtem, hogy milyen relációban gondolják ezzel az egésszel), szóval asszem leginkább helpet írni nem tudnak, de azért a nevezéktan is ejnyebejnye egy kicsit.

bluetooth eszközök vannak mellette? Azok meg tudják akasztani a 2.4-es wifit, főleg hangátvitel.

Az nem hinném, hogy zavarna. Hang esetén talapsztaltam már problémákat a bt wifi ütközéssel 2.4-en.

Esetleg fogj egy okostelefont, állj a klíma wifis rész emellé és nézd meg milyen hálózatokat lát a telefon. 
Például https://play.google.com/store/apps/details?id=com.farproc.wifi.analyzer

Ha a te wifiddel egyező csatornán van szomszéd vagy több szomszéd és közelebb van a klímához, akár el is nyomhatja a te jeledet. Érdemes megnézni van-e csatorna, ami kevélbé zavart a szomszédok által a klímánál és azt választani. Arra is figyelve, hogy lehet 13as csatornát nem szereti minden eszköz.

Nekem mind2 Gree klímám atomstabilan lóg non-stop a Unifi wifi-n, illetve tesómnál is 3db. Régi firmware okozhat gondot (tavaly talán nálam is előfordult szakadozás), illetve ha a Unifi-n be van kapcsolva, hogy próbálja 5GHz-re kényszeríteni a klienseket (amit szerencsétlen klíma nem tud). Legtisztább a csak 2,4-en szórt IoT SSID.

"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"

Nálam december óta vannak gree klimák, egy régi unifi ap-re vannak felcsatlakozva, különösebb bajom nincs velük. Homeassistant-ba vannak integrálva, app-ot nem használok.

Szerkesztve: 2022. 08. 28., v – 21:55

Nekem az ilyen "szar a wifi" megoldásra két dolog szokott gyógyírt adni:

- Leválasztom a 2.4-es és 5G-s wifit külön SSID-ra, és a problémás eszközt kizárólag a 2.4-esre engedem fel. Hiába csak 2.4-et tud, néhány eszköznek problémás, ha van 5G is, nem biztos, hogy értek annyira hozzá, hogy tudjam miért.
- Meg kell nézni a jelenlegi környezet zajszintjét. Nagyon sokszor az van, hogy sokan vesznek olyan eszközt, aminek a default csatornakiosztása egybeesik a te aktuális csatornáddal, és hiába mérted be mondjuk másfél évvel ezelőtt a wifi környezetet, az ma már nem releváns. Újra fel kell mérni a csatornák "foglaltságát", és szükség esetén át kell bökni másik csatornára a dolgokat. (Az emberek nagy része csak bedugja a wifi routert, mint a kenyérpirítót, pedig azt illene rendesen beüzemelni). 

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

MT RB4011 - saját konfig faragással. +UAP LC LR kb. 10 méterre, 1 plafon
Ez egy családi ház, utca végén, két szomszádos AP-t látok van (vélhetően tényleg olyanok, hogy bedugom oszt jónapot...)
2.4 GHz-en vannak a klímák, telókkal mellette min. 70% a jelerősség.

Szerkesztve: 2022. 08. 29., h – 16:15

Beacon interval-t probald kisebbre venni, hatha... De amugy ugyanaz az SSID az osszes ap-nek?