- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
- Újabb hét, újabb Galaxy S26 képek
- Android szakmai topik
- Samsung Galaxy Watch7 - kötelező kör
- Amazfit Active 2 NFC - jó kör
- iPhone topik
- Telekom mobilszolgáltatások
- Samsung Galaxy A52s 5G - jó S-tehetség
- Milyen okostelefont vegyek?
- Honor Magic6 Pro - kör közepén számok
-
Mobilarena
Amit érdemes tudni a Raspberry Pi-kről:
A legelső változat 2012-ben jelent meg. Pici, olcsó és nagyon alacsony fogyasztású, hobby-célú kártyagép. Felépítése ARM alapú, nem PC-architektúra, hanem kb. egy régi mobilhoz hasonló. Nagyon sok mindenre használható! A Linux-nak és a magas eladási mennyiségnek köszönhetően jelentős fejlesztőtáborral rendelkezik.
Új hozzászólás Aktív témák
-
-
#48848
Aryes
nagyúr
cinemazealot
#48846
válasz
cinemazealot
#48846
üzenetére
Ez egy statisztikai alapon működő nagy nyelvi modell, aminak fingja nincs a nyelvtani szabályokról, csak úgy pakolja egymás után a szavakat
Pontosan így működik az emberi agy is, hiszen az LLM is neurális hálót használ ami az emberi agy működését utánozza. Egy másfél éves gyerek pont így tanul beszélni: statisztikai alapon rakja egymás után a megtanult szavakat, úgy, hogy fingja nincs néhány szó jelentéséről, sem a nyelvtani szabályokról, azokat majd 10 év múlva az általános iskolában fogja megtanulni hozzá (és akkor sem aszerint fog beszélni).
-
válasz
vadkörte
#48844
üzenetére
Az LLM-ekkel kapcsolatban az az általános tévhit, hogy egyfajta "intelligens keresők", azaz az intrnetről nézik ki a választ. Ez azonban nem így van, mert igen veszélyes lenne az internet teljes tartalmával tanítani egyrészt, másrészt maga a tanítási folyamat is igen hosszadalmas tud lenni. Az LLM a saját betanításakori információkat "ismeri", ami nem feltétlenül naprakész. Ezért naprakész információkat számonkérni tőlük nem jó elképzelés.
Amikor ragaszkodik egy információhoz, az nem hallucináció, hanem az esetleges rossz vagy elavult információkkal való betanításáé, és a "ragaszkodik a hallucinációjához" nem is értelmezhető - legalábbis a hallucináció fogalmának LLM-kontextusban való értelmezése alapján.
De én a téves elvárásokat nem nevezném user error-nak, hiszen a hype akkora körülöttük, hogy az olyan jogosnak vélt hallgatólagos elvárásokat generál, amiket az LLM ma (még) nem tud teljesíteni. Az, hogy mindenre (is), bármilyen rosszul feltett kérdés legyen, azonnal vágja a helyes választ, mára már a Kano-modell szerinti "dissastisfier" kategóriájú követelménnyé vált, és mivel nem teljesítik az LLM-ek, ezért jól láthatóak már mindenfelé a lelkesedés korszakát követő alapos kiábrándultság jelei (amikor olyanokat mondanak egy LLM-ről, hogy "buta mint a föld, állandóan hallucinál, és ragaszkodik a hallucinációjához", mert egy-egy XY által ismert információt nem helyesen közli, akkor XY elfelejti, hogy mindezek mellett az LLM tudásbázisa egy-egy emberének, így XY tudásának is többezerszerese; azt pedig a legtöbben (még) nem is tudják, hogy eme óriási tudásbázis kiaknázására ill. a válaszok tényszerűségének (factuality) növelésére és a hallucinációk számának csökkentésére külön tudományág van kialakulóban, az ún. "prompt engineering", ami komoly kutatásokon alapul, és amiben nap mint nap újabb és újabb tudományos publikációk születnek.
Én örülök ennek a kiábrándultságnak, mert kijózanítja az elvárásokat, és segít megtalálni az LLM-ekben azt az elképesztően hasznos eszközt, ami. De egy bonyolult eszköz, és mint minden bonyolult eszközt (pl. egy repülőgépet) ezt sem lehet felkészültség nélkül használni, bármennyire is próbálják elhitetni velünk.
Egy új kor hajnalán vagyunk, amiben ha úgy tetszik, a prompt engineering a programozás új paradigmája.
-
#48846
cinemazealot
addikt
Kicsirics77
#48843
cinemazealot
addikt
válasz
Kicsirics77
#48843
üzenetére
Nem vagy vele egyedül. De fontos hangsúlyozni, hogy téves a hétköznapi nyelvben megragadt megnevezése, ez ugyanis nem intelligencia. Ez egy statisztikai alapon működő nagy nyelvi modell, aminak fingja nincs a nyelvtani szabályokról, csak úgy pakolja egymás után a szavakat a kérdésre adott válaszhoz, ahogy a tudásbázisa valószínűségeiből jónak látja. És minél több ilyen "valószínű" választ generál, annál több hülyeség lát majd napvilágot.
-
#48845
///Krisz\\\
senior tag
vadkörte
#48844
-
#48844
vadkörte
addikt
///Krisz\\\
#48842
vadkörte
addikt
válasz
///Krisz\\\
#48842
üzenetére
Ugyanazt a kérdést feltettük egy ismert és széles körben használt LLM-nek, egyikünk szóban diktálással, én írásban. A kérdés rendkívül összetett és bonyolult volt.
Ki a katolikus egyház vezetője jelenleg, vagyis 2026-ban és mióta.
Az írásban feltett kérdésre tökéletes választ kaptam, a szóban feltettre akkora ordas baromságot válaszolt, hogy a röhögéstől majdnem lenyelem a nyelvem.
Amikor felhívtuk a figyelmét, hogy téved, átment hisztis pi***ba és visszaszúrt, hogy nem, ő nem téved, bizonyára a mi információnk a hibás.
Eszközök - HW, SBC, DAC, AMP, (elektroncső
,) stb... - technikai paraméterek alapján történő összehasonlítására, kódalapok, látványtervek, illusztrációk* generálására használom. Ha normálisan, részletesen van megírva a prompt, korrekt választ kapok. Szóbeli promptolást meg sem próbálok.
*:
Épp folyamatban van egy munkám, amihez baromi kevés illusztrációt kaptam, AI-jal viszont egész hatékonyan tudok generálni hozzá illusztrációnak használható tartalmakat.
(helyszínelési fotók, látleletek, kamu jegyzőkönyvek, stb...) -
#48843
Kicsirics77
veterán
///Krisz\\\
#48842
Kicsirics77
veterán
válasz
///Krisz\\\
#48842
üzenetére
Hát nemtudom, lehet én öregszem, de nekem egyáltalán nem fekszik az AI
-
#48842
///Krisz\\\
senior tag
Kicsirics77
#48839
///Krisz\\\
senior tag
válasz
Kicsirics77
#48839
üzenetére
Nem gondolnám. Ez is csak ugyanolyan mint a többi termék: a bevezetésekor tele van hibával és idővel egyre jobb lesz. Jelentse ez akár azt is, hogy megmarad a hallucináció, de mondjuk figyelmeztetni fog, hogy amit most leírt arra nem talált konkrét bizonyítékot, hogy létezik, csak ő gondolja így.
Nem tudom mások hogy használják. Én mindig akkor használom ha valami olyat akarok megismerni, amivel kapcsolatban még nincs tapasztalatom. Mert hát lássuk be, nem jöhetek ide a fórumba azzal, hogy: "Sziasztok, Semmit nem tudok XY dologról, kérlek világosítsatok fel". Ki fog így segíteni nekem? Kinek van erre ideje/idegrendszere, hogy elmagyarázza nulláról? Az AI-al meg nyugodtan elbeszélgethetek órákon keresztül, ráér és nem fogy el a türelme.
Néha persze becsúszik egy ilyen baki, de 95%-ban jókat mond. Nekem ez így belefér, 5%-ban meg majd tartom a hátam és égek a baromságai miatt.
-
#48841
PhoenixK
őstag
Kicsirics77
#48839
válasz
Kicsirics77
#48839
üzenetére
Szerintem igen. Már most látok olyan épelméjünek hitt embereket, akik az AI terjedése elött kreatívak voltak, tudtak, de mióta az AI széles körben elterjedt, azóta sajnos MINDENRE is használják.
A kedvencem a nyelvtann@ci, aki az AI óta bizonytalan levelet írni, és mindent azzal irat.
Én meg import személyként ülök a szemben levö asztalnál, és maximum egy nyelvtani ellenörzésre tolok egy deepl-t - ha bizonytalan vagyok -
#48840
HantekDSO
aktív tag
Kicsirics77
#48839
HantekDSO
aktív tag
válasz
Kicsirics77
#48839
üzenetére
-
#48839
Kicsirics77
veterán
///Krisz\\\
#48838
Kicsirics77
veterán
válasz
///Krisz\\\
#48838
üzenetére
Amúgy minden hátsó szándék nélkül kérdezem: ezek az AI szarok fogják egyszer ezt a világot bedönteni?
Olyan iszonyat mennyiségű f@szságot talál ki,hogy a hajam égnek áll, plussz ugye lassan ha valaki valamit nemtud egybol ezeket a szarokat kérdezi és feltétel nélkül elhiszi amit mond. -
#48838
///Krisz\\\
senior tag
azbest
#48836
///Krisz\\\
senior tag
válasz
azbest
#48836
üzenetére
Kicsit faggattam még a Gemini-t, kiderült, hogy csak kitalálta a POWER_OFF_ON_REBOOT-ot, szóval az nem létező kapcsoló. Gondolom amikor teszteltem, a papírt átszúrhatták a GPIO tüskék végei és megint kapott tápot. Szóval azt benéztem.
Lényeg a lényeg, hogy most már kap áramot a pogo pin-eken keresztül a HAT és végre normálisan újraindul. -
vadkörte
addikt
Üdv!
Én messze nem űzöm ezt a hobbit olyan szinten mint Ti, az eszközök képességeinek talán 1-5%-t ha kihasználom. Talán.
A tanácsotokra - különösen cigam tanácsára - az RPi2-t tartósan streamer szerepkörbe száműztem, egy régebbi moOde-dal egy SMSL PS200Pro DAC-kal szolgáltatja a muzikot. Vettem mellé egy gyári tápot, mivel a 10W-os gagyi mobiltöltő a Pi-t és a DAC-ot már nem tudta üzembiztosan vinni. 600MHz-en járnak a magok, több óra zenehallgatás után is 1-15% közötti kihasználtsággal ketyegnek, alig 150MB RAM foglalással. Amíg meg nem döglik, elleszek vele.
A Pi-vel kiesett a mediaplayer-em, tettem egy próbát a dedikált Android-os lejátszók háza táján, de egyik sem győzött meg (túl sokat tudtak, vagy preneolitikumi HW-rel árulták arany áron)
Végül a HA-n nézelődve jött szembe egy RockChip-es SBC. Egy 2GB RAM/32GBonboard eMMC-vel szerelt Radxa RockPi4B+-t.
Mindig fáztam az RK SoC-któl, de ez valahogy érdekesnek tűnt. Utánaolvasva rá kellett jönnöm, hogy ez az RK, már nem az az RK. Némi FoxPost-os szívatás után megérkezett a kütyü. Nos, háát nem RPi...
A Pi-t beüzemelni gyerekjáték, ezzel azért molyoltam pár napig.
Érdekes a konfig, mert 2GB RAM-mal nem szerelték 32GB eMMC-vel, csak 16-tal. Kiderült, hogy ezek Wi-Fi router-ek voltak, amikkel mellesleg Helimum-ot bányásztak. Háát nálam már nem bányászik. Sikerült kialakítani a számomra ideális dualOS kombót. Az mSD-ről LibreELEC boot-ol mediaplayer lesz, az eMMC-ről meg egy Debian12-vel lehet használni. Ahhoz képest, hogy csak egy ARM SBC nyúlfarknyi 2GB RAM-mal, gyors és gördülékeny. A repók gyárilag kínaiakra vannak állítva, ezeket tervezem áttenni valami európaira. Szükséggépnek, vagy ágybandöglősnezetősnek tökéletes. -
#48836
azbest
félisten
///Krisz\\\
#48833
azbest
félisten
válasz
///Krisz\\\
#48833
üzenetére
köszi, hogy amoda is leírtad. A másik amit ott írtál, hogy létezik ilyen eeprom bootloader kapcsoló is
"POWER_OFF_ON_REBOOT=1 "
Ezt valsz sokan keresték, akik az évek során valamilyen okból szívtak az ssd-kkelNa ezt nem is láttam még. Kezd a pi is egyre követhetetlenebb lenni. Sokszor a régi rendszerek és pik leírásai jönnek fel kereséskor és valahogy egyre nehezebb megatalálni szerintem az aktuális információkat úgy, hogy ne kelljen adatbányászni hozzá.
De ez a kapcsoló tényleg létezik vagy csak kicserélted a POWER_OFF_ON_HALT -ot arra? Nem találok dokumentációt hozzá
-
#48835
Aszpirin
támogató
///Krisz\\\
#48833
válasz
///Krisz\\\
#48833
üzenetére
-
#48834
azbest
félisten
///Krisz\\\
#48833
azbest
félisten
válasz
///Krisz\\\
#48833
üzenetére
aaah
nem gondoltam volna hogy ilyen tünetet kontakthiba is okozhat.Érdemes lehet a hivatalos raspberry fórumon is leírni a megoldást, hogy ha más rátalál a kérdésedre, ezt a lehetőséget is megnézze
-
#48833
///Krisz\\\
senior tag
azbest
#48826
///Krisz\\\
senior tag
válasz
azbest
#48826
üzenetére
+ #48828 cigam
Nem rátok gondoltam, itt mindig normálisan álltak hozzám.Meglett a hiba, de tök véletlenül jöttem rá. Kipróbáltam már mindent, de mindig elakadt. Kínomban már szétszedtem a Pi-t és a HAT-et is és akkor vettem észre, hogy a Pi hátoldalán az egyik GPIO tüske végén ott hagyták a gyártás során a flux-ot. Pont azon, amivel a HAT egyik pogo pin-je érintkezett. Izopropil-alkohollal és egy csipesszel letakarítottam róla, összeraktam és többet nem akadt el az újraindítás.
Szerintem az lehetett, hogy mivel 3.9W az NV3-as SSD max fogyasztása és a Pi a PCIe csatlakozón 5W-ot tud max leadni, működés közben sosem okozott gondot, hogy a pogo pin-eken keresztül nem kap plusz tápot.
Illetve gondolom, hogy a Trixie az újraindítás közben szórakozik vagy el is veszi a tápot a PCIe csatlakozóról, így a pogo pin-ek hiányában leállt az SSD és nem tudott felébredni a boot-ra. Bookworm alatt viszont lehet, hogy nem szórakoztak a PCIe csatlakozó tápellátásával.
-
-
azbest
félisten
Áh bocs, félreolvastam Jeff írását. A 3.3v-ot kapcsolja le és az zavarhatja meg valamelyik HAT-ot, hogy az 5v mellől kiesik.
Apparently some HATs have trouble if the 3v3 power rail is off, but 5v is still active—which would be the case if you completely power off the SoC, but still have your 5V power supply plugged in. [link]
Mivel csak egy paraméterről van szó, a legegyszerűbb kipróbálni, hogy van-e hatása
Valaki írta, Jeff alá kommentnek, hogy újabb rendszeren lehet alapértelmezetten be is van kapcsolva.Máshol azt írják talán, hogy a cmdline.txt -ben kernel opciónak reboot=pci vagy reboot=cold vagy reboot=warm vagy reboot=force -t is lehet próbálni. Bár ez lehet csak ai halucináció mert összekutyul pécés és raspberrys témákat.
-
cigam
titán
válasz
azbest
#48829
üzenetére
Köszi, gondoltam rákérdezek, mert nem előszőr fordulna elő, hogy valamit félre értek. Köszi a kiigazítást!
A halt egy fura dolog, mert van a shutdown halt parancs, hlt utasítás is. Mindkettőnek más a hatása. De egyik sem áramtalanítja a PCIe buszt. A Raspberry Pi architektúrája miatt a PMIC alapértelmezésben nem kapcsolja le az 5V-os bemeneti feszültséget a GPIO tüskékről és a PCIe csatlakozóról. (Mivel fizikai kapcsolat van köztük ezt nem tudja befolyásolni)
A PCIe HAT-ok többsége közvetlenül erről az 5V-ról kapja a tápellátást. A legtöbb PCIe HAT-on (pl. egy NVMe SSD bővítőn) saját feszültségszabályozók vannak, amik az 5V-ból csinálnak 3.3V-ot az SSD-nek.
Ugye ez általánosság, nem tudjuk biztosan az ő esetében pontosan hogyan működik a HAT/tápellátás. -
azbest
félisten
A hivatalos raspi fórumra gondolt.
A haltot ő is úgy gondolja. De ezt nem garantálnám, pláne nem a raspberry pi esetén. Ez nem oprendszer szinten van, hanem hogy a soc átszóljon a tápáramkör mikrokontrollerének, hogy csináljon tápelvételt.
És kifejezetten illik a tünet arra, amit nvme és más hatek kapcsán erre az opcióra írtak. Ha valahol dokumentálva van, vagy valahol ki lehet nyerni logokból, mit csinál máshogy a mostani kernel, változott e az alapértelmezett restart mód, az segíthetne biztosan rájönni. A reboot_type is one of bios, acpi, kbd, triple, efi, or pci opciók közül is változhatott, hogy mi az alapértelmezett és az esetleg másképp reseteli a pit. De akár a pi5 specifikus implementációba is kerülhetett más, ha a pécés opciók itt nem validak.
DA9091 is the product of a multi-year co-development effort. Working closely with the Renesas team in Edinburgh allowed us to produce a PMIC which is precisely tuned for our needs. And we were able to squeeze in two frequently requested features: a real-time clock (RTC), which can be powered by an external supercapacitor or a rechargeable lithium-manganese cell; and a PC-style power button, supporting hard and soft power-off and power-on events. [link]
-
#48828
cigam
titán
///Krisz\\\
#48827
cigam
titán
válasz
///Krisz\\\
#48827
üzenetére
///Krisz\\\
Akkor ebben nem fogunk egyetérteni, szerintem totál hülyeségeket kérdeztek.
Ezt kifejtenéd? Nem akarok neked esni egy félreértés miatt, de jól értem? Úgy gondolod, hogy az itteni segíteni szándékozók írtak hülyeségeket neked?Amúgy a halt a kikapcsolásnál van, mert onnan nem megy tovább, a reboot nem ad ki halt parancsot. Abban viszont lehet igazság, hogy leállításkor lecsatolja a fájlrendszert, és kikapcsolja, energiatakarékos módba teszi a vezérlőt, és az SSD-t. Ebből az alvó módból lassan vagy hibásan ébredhet fel, szemben az áramtalanítással, ami nulláról indít mindent.
-
#48826
azbest
félisten
///Krisz\\\
#48824
azbest
félisten
válasz
///Krisz\\\
#48824
üzenetére
pedig jókat kérdeztek, csak nem írták le, hogy hol és hogyan tudod megnézni. A POWER_OFF_ON_HALT pedig ahogy írtam azért lényeges, mert ha rebootkor is van halt állapot, lehet elveszi az 5vot, míg 3.3v-ot kapja az nvme HAT-ról és attól meghülyülhet. A bookworm valsz máshogy adta ki a rebootot és ott nem volt halt közben. Egy próbát megér átállítani.
-
#48824
///Krisz\\\
senior tag
azbest
#48822
///Krisz\\\
senior tag
válasz
azbest
#48822
üzenetére
Bookworm alatt normálisan működött a reboot (sudo reboot - piros LED világít - zöld LED világít - összes LED elalszik (be van állítva config.txt-ben, hogy kapcsoljon ki az összes)). Trixie-től kezdve: sudo reboot - piros LED világít - zöld LED világít és itt megáll, mert a képernyőképen is látható módon nem éri el az SSD-t és ismételgeti a boot sorrendet.
Mivel ha kikapcsolom és utána bekapcsolom, akkor mindig gond nélkül boot-ol, csak reboot-nál van probléma, arra gondolok, hogy valami parancs kimarad a reboot elején, ami jelzi az SSD-nek, hogy újraindulás lesz. Nyilván ez a parancs kikapcsolásnál más illetve kikapcsoláskor elveszi az áramot, tehát nulláról indul a hardware bekapcsolásnál.
Nem tudom mik azok az UART logok, csak megemlítette az egyikük, hogy annak hiányában kell még kérdezgetnie.
Félelmetesen hülyék vannak abban a topikban. Már beszélgettem Github-on az OS-ért felelős fejlesztőkkel, akik tök segítőkészek voltak és normális utasításokkal vezettek, hogy hogyan oldjuk meg a problémát. De ezek annyira fogalmatlanok, hogy én nem akartam elhinni, hogy ezek fejlesztők.
Az első két dolgot javasolt: frissítsek a legújabb bootloader-re, amikor a képen látszik, hogy a legújabb van a Pi-n, a másik javaslata, pedig az volt, hogy beszélgessek más felhasználókkal. A második csóka felhozta a POWER_OFF_ON_HALT-ot, aminek semmi köze az újraindításhoz, az a kikapcsolás után veszi el a tápot a perifériákról illetve az SD kártyáról akart bootoltatni, amikor az NVMe eszközt nem éri el a bootloader. A harmadik emberbe szorult valami ész, mert rászolt a másodikra, hogy milyen hülyeséget ír. A végére, pedig megérkezett bolygókapitánya, aki úgy érezte, hogy megsértettem őket a kérdéseimmel, de egyszerűen már kezdtem elveszíteni a türelmem, hogy milyen hülyeségekkel fárasztanak.
-
azbest
félisten
válasz
azbest
#48822
üzenetére
eh de eltört ez a másolás innen
reboot=pci esetleg?reboot= [KNL]
Format (x86 or x86_64):
[w[arm] | c[old] | h[ard] | s[oft] | g[pio]] \
[[,]s[mp]#### \
[[,]b[ios] | a[cpi] | k[bd] | t[riple] | e[fi] | p[ci]] \
[[,]f[orce]
Where reboot_mode is one of warm (soft) or cold (hard) or gpio
(prefix with 'panic_' to set mode for panic
reboot only),
reboot_type is one of bios, acpi, kbd, triple, efi, or pci,
reboot_force is either force or not specified,
reboot_cpu is s[mp]#### with #### being the processor
to be used for rebooting.Ezen kívült még [link] [link] ennek a hangolása
nvme_core.default_ps_max_latency_us=0
talán valami bealvásos problémát megoldhat -
#48822
azbest
félisten
///Krisz\\\
#48821
azbest
félisten
válasz
///Krisz\\\
#48821
üzenetére
mondjuk ahogy itt és a raspi fórumon írtad, ezek szerint máshogy csinálja a rebootot a két oprendszer? A bookwornnál is volt az, hogy lekapcsol majd visszakapcsol vagy ott a ledek máshogy viselkedtek?
Lehet a gyors ki-be kapcsolás miatt az ssd még valami instabil állapotban van. Nem tudom van -e kernel kapcsoló, hogy hasonlóan viselkedjen a rebootkor az áram, mint a bookwormon.
Azt meg azért mondhatták, hogy a POWER_OFF_ON_HALT gondot okozhat, mert úgy olvasom, vannak HAT-ek amit összezavar hogy részben kap áramot, részben nem. [link]
Ha power offot csinál restart előtt az új os, míg a bookworm máshogy rebootolt, lehet köze hozzá. Annak a halt-nak meg kikapcsolt pi fogyasztására kéne legyen hatása, nem a futó pire. Ha mindig fut, akkor nem nyersz vele gondolom.
Az UART logot említették még, amit a bootloadernél be lehet kapcsolni és akkor valsz a pi valamelyik pinjeire kötött usb soros átalakítóval és terminállal lehet látni debug infókat a bootloaderből, hogy miért nem sikerül.
Kernel opciónak esetleg próbálhatsz, most hirtelen nem tudom a pi5 esetén cmdline.txt van -e még vagy hol lehet ezeket megadni. De van reboot=valami opció a kernelhez. Talán nem ugyanaz az alapértelmezett beállítás a két oprendszeren vagy valami bug miatt meg kéne adni valamit helyette:
reboot= [KNL] Format (x86 or x86_64): [w[arm] | c[old] | h[ard] | s[oft] | g[pio]] \ [[,]s[mp]#### \ [[,]b[ios] | a[cpi] | k[bd] | t[riple] | e[fi] | p[ci]] \ [[,]f[orce] Where reboot_mode is one of warm (soft) or cold (hard) or gpio (prefix with 'panic_' to set mode for panic reboot only), reboot_type is one of bios, acpi, kbd, triple, efi, or pci, reboot_force is either force or not specified, reboot_cpu is s[mp]#### with #### being the processor to be used for rebooting. -
#48821
///Krisz\\\
senior tag
cigam
#48820
///Krisz\\\
senior tag
Megnéztem, a HAT-nek nincs firmware-e, a Kingston, pedig még nem adott ki frissítést az NV3-akhoz.
Az ASPM-et már próbáltam, de nem változott semmi. A sebességet viszont nem szeretném felezni, így is elég takarékon megy a cucc. Lehet, hogy inkább ezt elengedem, oldják meg a fejlesztők, addig meg a havi egyszeri frissítéskor nem reboot-al indítom újra, hanem shutdown-al és kézzel bekapcsolom, ez belefér.
Köszi a segítséget.
-
#48820
cigam
titán
///Krisz\\\
#48819
cigam
titán
válasz
///Krisz\\\
#48819
üzenetére
Van egy "ébredési" idő, amit a vezérlő látszólag a vártnál később végez el. Lehet pont a soft reset miatt.
Bizonyos SSD-k (Micron, Samsung 2230, WD SN530 stb.) érzékenyek a Pi 5 PCIe resetjére. Próbáld meg frissíteni az HAT fw-t, ill. az SSD-ét.
Az is segíthet, ha késlelteted a PCIe busz inicializálását, ill. kisebb sebességre állítod.
PCIE_ASPM=0
PCIE_SPEED=1
Az első kikapcsolja a PCIe energiatakarékosságát, ami növelheti a stabilitást, a második pedig beállítja az x1 linket. Így 5Gbps helyett csak 2.5Gbps lesz a kapcsolat sebessége. -
#48819
///Krisz\\\
senior tag
cigam
#48818
///Krisz\\\
senior tag
Megcsináltam mindkettőt, de ugyanúgy elakad.
Az a furcsa, hogy van egy szögre ugyanilyen setup-om, csak egy dologban különbözik, azon egy 2TB-os NV3 SSD van és az nem csinálja ezt. Megnéztem, ezen az 1TB-os NV3 SSD-n (ami elakad) TenaFe a vezérlő, a 2TB-oson, pedig Silicon Motion. Létezik, hogy a TenaFe bealszik az újraindítás során és azért nem válaszol?
Mert ha jól tudom az újraindítás és a ki-be kapcsolás között az is különbség, hogy újraindításnál nem veszi el a tápot. -
#48818
cigam
titán
///Krisz\\\
#48817
cigam
titán
válasz
///Krisz\\\
#48817
üzenetére
Frissítsd a bootloadert:
sudo apt update
sudo apt full-upgrade
sudo rpi-eeprom-update -a
sudo reboot
Ha még mindég problémás, engedélyezd a PCIE_PROBE opciót. A PCIE_PROBE egy Raspberry Pi‑specifikus bootloader opció, ami azt szabályozza, hogyan és mikor próbálja a Pi 5 inicializálni a PCIe buszt – vagyis azt a részt, amin az NVMe SSD is lóg.
sudo rpi-eeprom-config --edit
PCIE_PROBE=1
BOOT_ORDER=0xf416 -
#48817
///Krisz\\\
senior tag
///Krisz\\\
senior tag
Egy Pi 5-öt használok SSD-vel (HAT + SSD). Az a problémám, hogy ha kikapcsolom a Pi-t majd be, akkor minden gond nélkül bekapcsol, viszont ha sudo reboot-al indítom újra, elakad a bootlolásnál, csatolok egy képet, hogy mit ír ki (OS Lite):
Ezt azóta csinálja, hogy felkerült rá a Trixie, előtte ilyen nem volt. Találkozott esetleg valaki már ilyennel?
-
Köszi, ez hasznos
Amúgy mit reklamáljak? Hogy érted, hogy miért nem vár az eszköz az internetre?
Az egyik egy Volvo V60 autó, a másik egy Viessmann Vitodens 100W kazán.
A Volvónak és a Viessmann-nak is saját IoT megoldásuk van, és a lokális API-t nem adják ki (a Volvo esetében főleg security, a Viessmann esetében főleg safety okokból teljesen érthető, hogy a lokális API-ra csatlakozást saját kézben tartják, nem adják ki 3rd partynak).
Az Edge nélküli IoT megoldásoknál (mindekttő tipikusan ilyen) a szenzoradatok "betáplálása" és azok kliens általi lekérése külön folyamaton megy, elkülönített interfészeken ("Southbound" ill. "Northbound", ha foglalkoztál már IoT-val), aszinkron módon. Ha lekérsz egy szenzoradatot, jobb esetben megkapod annak timestampjét is, ami azt mutatja, hogy az adat nagyon friss. Rosszabb esetben (ha leszakadt a kütyü /autó, kazán/ az internetről/, akkor régebbi adatot kapsz.
Mindkét gyártó publikálja a Northbound API-ját, és elérhetővé teszi az autentikált userek számára, hogy kliens applikációjuk számára (jelen esetben a HA) authentication key-t generáljanak, aminek használatával egyszrei user-autentikáció után az applikáció hozzáfér a user kütyüje szenzoradataihoz illetve eseményeket is tud kiváltani /pl triggerelni tudja az autó indítását, szellőztetés indítását, ilyenek/).
Alighanem ezeket tudtad, szóval bocs, hogy leírtam, inkább a többieknek, akik esetleg nem láttak még IoT architektúrákat.
Szóval az interneten a két gyártó Northbound interfésze ott van, ők nem "szakadnak le", és a HA-nak ezekre van szüksége. Az auto mint "eszköz" egyébként a saját SIM-kártyáján keresztül "lóg" az interneten, ő ée sem szakad. A kazán igen, de mint láttuk,, nem közvetlenül tőle lesz lekérdezve az adat.
A probléma inkább azzal van, hogy a HA-na zok az integrációk, amelyek internetet igényelnek, nem várják meg az indulással az internet meglétét, és belehalnak abba, hogy nem tudnak be-autentikálni a gyártói IoT-interfészekre.
A többi már ebből következik.
Fura, mert pl. a Homey-nál nincs ilyen probléma. Erre maga a HA is vigyázhatna egy (re)boot utáni integráció-indításokkor, mert az, hogy egy integráció igényel internetet, egyértelműen ott van a manifestben (az integráció IoI-class-a "cloud_polling"):{
"domain": "vicare",
"name": "Viessmann ViCare",
"codeowners": ["@CFenner"],
"config_flow": true,
"dhcp": [
{
"macaddress": "B87424*"
}
],
"documentation": "https://www.home-assistant.io/integrations/vicare",
"integration_type": "hub",
"iot_class": "cloud_polling",
"loggers": ["PyViCare"],
"requirements": ["PyViCare==2.55.0"],
"version": "1.0.99"
}
(mellesleg van okosotthon-topik, ahol intenzíven foglalkoznak a HA-val (főleg azzal), és nem is ide szántam a kérdést, csak véletlenül pakoltam ide be. A sors fintora, hogy Te adtál a legprofibb választ rá, szóval a HA-szakértőknél jobb vagy(Amúgy meg nem használok docker-compose-t és ha a HA-t dockerbe rakod fel, ő sem pakol fel compose file-t /bár ebben nem vagyok biztos!/. Portainer-t használok, ahol egy Stack lényegében ugyanazt jelenti, mint egy docker-compose file, de még nem készítettem el neki. Ideje már...)
-
cigam
titán
válasz
Aszpirin
#48805
üzenetére
Persze paranoia kérdése is, de miért kell kimennie az internetre? Miért nem vár az eszköz ha nincs internet. Szerintem nem a gyártóhoz kell igazodni, hanem annak hozzád. Pl az eszköz gyártójánál megreklamáltad?
A HA service fájlját kicsit módosítod:
After=network-online.target
Wants=network-online.targetAztán engedélyezed a figyelő szervizt:
sudo systemctl enable NetworkManager-wait-online.service
sudo systemctl start NetworkManager-wait-online.serviceDocker használatával a compose fájlt kell kicsit módosítani:
healthcheck:
test: ["CMD", "ping", "-c", "1", "1.1.1.1"]
interval: 10s
timeout: 3s
retries: 5Ugyanakkor a HA-n belül is létezik interntefigyelés:
binary_sensor:
- platform:
ping host: 1.1.1.1
name: Internet elérhető
count: 2
scan_interval: 10Ezzel már elérheted, hogy az Internethez kötött szolgáltatásokat csak akkor indítsa, ha van internet kapcsolat. PL. a Volvo fájljába beteszed ezt:
condition:
- condition:
state entity_id: binary_sensor.internet_elérhető
state: "on"Így működik a HA minden szolgáltatása, kivéve amikhez internet szükséges. Ezt a HA topikban biztos tovább tudják finomítani. pl. a HA indulásakor vár az internetre.
internetre.automation:
- alias: "HA startup – várj internetre"
trigger:
- platform: homeassistant
event: start
wait_for_trigger:
- platform: state
entity_id: binary_sensor.internet_elérhető
to: "on"
timeout: "00:05:00"
continue_on_timeout: false
action:
- service: homeassistant.reload_config_entry
target:
device_id: <volvo_device_id> -
Az a gond, hogy ha nem jön meg az internet, nem indul el.
Olyan volt már nálam is, hogy visszajött az áram, és volt WLAN meg Ethernet LAN is, de az internetre várnolm kellett másnapig, amíg megoldották nekem távolról a telekomos műszakiak...
Ha leblokkolom a HAOS vagy docker esetében akár a host OS bootolását az internet hiányában, akkor egy halom automatizálást blokkolok, miközben a túlnyomó többségük nem igényel internetet. -
válasz
Aszpirin
#48809
üzenetére
Most látom, hogy elírtam ugyan, de értetted, amit írtam
Miért, mi a gond az oprendszer blokkolásával, míg megjön az internet?
Ugyanaz lesz a végeredmény, mintha a docker konténert blokkolnád.Azt nem tudom amúgy, hogy FTTH net esetén marad-e online a router, ha UPS-en van. 🤔
-
Köszi a Tippet.
Az oprendszert azt biztos nem blokkoltatnám internet hiányában, szerintem az nem annyira jó ötlet.
Viszont a HA docker konténerben van, annak jó lenne csak akkor indulnia, ha van internet, ha nincs, várjon. Függetlenül attól, miért és hogyan lett leállítva és újraindítva. -
Sziasztok!
Van egy általános jellegű problémám, talán Ti is találkoztatok már vele.
A probléma két olyan HA-integrációval van, amelyek internetet igényelnek a működéshez (nekem csak ez a kettő ilyen van, de lehet, hogy mindegyik internetes autentikációt igénylő integrációra kiterjed a probléma). A gond, hogy ha áramszünet van, a HA gyorsabban feláll, mint az internet kapcsolat, elindulnak az integrációk, autentikálni akarnak a felhőikkel az API-kulcsot és a korábbi autentikációs tokennel, de mivel nincs internet, ez nem megy, és itt behal az integráció. A két eset nálam: Viessmann és Volvo. A viessmann egy sima Reconfigure-val ment, a Volvo viszont sehogy sem akart autentikálni, újra kellett generálnom az API kulcsot a Volvo felületén, újra kellett indítanom a HA-t, majd a Volvo integráción Reconfigure, újraautentikálás, új API key megadása, és innentől újra fut.
Ez a Viessmann esetében csak vgvagy 3 klikk, de a Volvo esetében is pár kliekkel beoldható, nem ez a fő probléma. Hanem hogy Elhalnak az automatizációik, és lehet, hogy észre sem veszem, mindez egy esetleges áramszünet miatt, ami akár pillanatnyi is lehet, nálunk sajnos ez eléggé gyakori. Márpedig az egész főleg az automatizációk miatt van... (Nálam Homey Pró-n futnak az automatizációk, a HA "csak" az integrációk miatt van speciális esetekre (jelenleg három Device-ot veszek át a Homey-ba a HA-ból: az Ecowitt WS90 időjárás-állomást, a Viesmann Vitodenss '00W kazánt, és a Volvo autómat. Mindegyiknek meg van az alapos oka, hogy miért nem a natív Homey-integrációt használom).
Szóval, Ti talékoztatok-e ezzel a problémával és ha igen, miként oldottázok meg, vagy miként oldanátok meg? Tul. képpen csak annyi kellene, hogy a Viessmann és Volvo integrációk késleltetve induljanak el egy HA-újrindítás esetén, én már belőném, hogy kb mennyi idő múlva van már internet. Nem sok ez az idő, de tuti nincs még, amikor elindulnak.
Köszi szépen a segítséget (és vegyétek figyelembe, hogy HA-ban viszonylag kezdő vagyok, szóval elnézést előre is, ha túl banális a kérdés).
-
PistiSan
addikt
válasz
azbest
#48739
üzenetére
Nem írnám le az eszközt, nekem pont egy ilyen elsőgenerációs raspberry pi 1 (256MB ram) van használatában a legújabb raspberry pi os fut rajta.
GPIO-n hőmérő szenzor van rákötve, egy wifi usb stickkel (ezen még nincs beépített wifi) és python scriptek futnak rajta, amiből szivattyú vezérlést indít, állít meg, csomó paramétert alapján. A fontosabb dolgokról pedig gotify-on keresztül még üzenetet is küld lanon, így ha nincs net, akkor is működik. A logok ramdisken
vannak, hogy ne egye meg az SD-t.
Nyílván egyre kevesebb dologra jó már egy öreg pi, de anno mekkora erőgépnek tűnt az akkori Asus WL-500GP V2 routeremhez képest. -
#48802
///Krisz\\\
senior tag
cigam
#48800
///Krisz\\\
senior tag
Kipróbáltam, de sajnos nem változott tőle.
#48801 wassermann
Lehet, de azt nem nagyon szeretném, hogy teleszemetelje a mappákat.Mivel minden máson tökéletesen működik, inkább az iPhone-on lecseréltem a Fájlok alkalmazást az Owlfiles-ra, amivel tökéletesen meg tudom nyitni a képeket, sőt az összes videót is lejátsza, szóval még a VLC-t is kiváltottam vele.
Köszönöm azért a segítségeteket.
-
#48801
wassermann
Topikgazda
///Krisz\\\
#48799
wassermann
Topikgazda
válasz
///Krisz\\\
#48799
üzenetére
Nincs ilyenem, de nem épp pont azok az OS X segédfájlok kellenének, amiknek a létrejötte le van tiltva... ?
,) stb... - technikai paraméterek alapján történő összehasonlítására, kódalapok, látványtervek, illusztrációk* generálására használom. Ha normálisan, részletesen van megírva a prompt, korrekt választ kapok. Szóbeli promptolást meg sem próbálok.
A Pi-t beüzemelni gyerekjáték, ezzel azért molyoltam pár napig.
Ugyanaz lesz a végeredmény, mintha a docker konténert blokkolnád.
vannak, hogy ne egye meg az SD-t.
Új hozzászólás Aktív témák
wassermann- NIOH 3
- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
- Degeneratív kapcsolóval készül a Firefox
- Újabb hét, újabb Galaxy S26 képek
- Android szakmai topik
- Samsung Galaxy Watch7 - kötelező kör
- BMW topik
- Autós topik
- A fociról könnyedén, egy baráti társaságban
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- További aktív témák...
- Bontatlan Intel Core ULTRA 9 285K (24mag!) + hűtött VRM-es Z890 alaplap! GAR/SZÁMLA (a Te nevedre)!
- AMD RYZEN 3700X MSI RTX 3700Ti 32GB DDR4 3600MHz 250GB M.2 SSD 1.5TB SSD
- I7-4790K, 16Gb Ram, Sapphire RX550 2Gb Videókártya, 480Gb SSD, Komplett Számitógép
- ÚJ CORE I5 12400 GAMER OPTIMUM PC 16-32GB RAM 512GB NVME SSD ASUS GTX 1660 S 6GB DDR6 VGA 2ÉV GAR!
- ÚJ ASUS B760 CORE I5 14400F GAMER ERŐMŰ PC 32GB DDR5 1.0TB SSD ÚJ ASUS RTX 5070 12GB DDR7 2ÉV GAR!
- Bomba ár! Lenovo IdeaPad 3: i3-10GEN I 8GB I 256SSD I 14" FHD I Cam I W11 I Garancia!
- ÁRGARANCIA!Épített KomPhone Ryzen 7 7800X3D 32/64GB RAM RTX 5070Ti 16GB GAMER PC termékbeszámítással
- Telefon felvásárlás!! iPhone 11/iPhone 11 Pro/iPhone 11 Pro Max
- 242 - Lenovo ThinkBook 16p (G6 IAX) - Intel Core U9 275HX, RTX 5060
- Eladó használt Huawei P30 Lite 4/128GB / 12 hónap jótállás
Állásajánlatok
Cég: Central PC számítógép és laptop szerviz - Pécs
Város: Pécs
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest