-
Fototrend
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
-
#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... ?
-
#48800
cigam
titán
///Krisz\\\
#48799
cigam
titán
válasz
///Krisz\\\
#48799
üzenetére
Próbáld meg hozzáadni ezt a sort:
ea support = yes
Indítsd újra a sambat, vagy magát a Pi-t, és próbáld újra. -
#48799
///Krisz\\\
senior tag
///Krisz\\\
senior tag
Még egy dologgal küzdök. A Pi-re csatlakoztatott HDD-ről SMB-n keresztül érem el a fényképeimet. Ez Android TV-n és macOS-en (Finder-ben) hibátlanul működik, viszont iOS-en a Fájlok alkalmazás megnyitja a mappákat, de a benne lévő fényképeknek nincs előnézeti képe valamint a fájlokat már meg se nyitja.
Jelenleg így néz ki az ide vonatkozó SAMBA paraméterezés:
[Fényképek]
comment=Fényképek
path=/mnt/hdd/Fényképek
browseable=Yes
read only=Yes
create mask=0775
directory mask=0775
valid users=horvathkrisztian, @users
force group=users
# Ez a két sor megakadályozza, hogy az OS X rendszer segédfájljai létrejöjjenek ezen a megosztáson
veto files = /._*/.DS_Store/.Trashes/.TemporaryItems/
delete veto files = yes
# Apple-specifikus kiterjesztések (VFS)
vfs objects = catia fruit streams_xattr
fruit:aapl = yes
fruit:metadata = stream
fruit:resource = file
# Ez segít abban, hogy az iOS ne "akadjon ki" a csak olvasható állapoton
fruit:locking = noneItt kellene még valamit módosítani vagy a Fájlok alkalmazás oldalán kellene keresni a hibát?
-
Helios
tag
Ezért is írtam, hogy "Nálam - régebbi rendszeren" (VERSION="12 (bookworm)")
Ott van még ilyen:
[Unit]
Description=/etc/rc.local CompatibilityTehát ebben még kompatibilitási okokból benne van, és nekem ez elégséges megoldás volt.
(Ahogy nézem még a 13-as verzióban is benne hagyták ezt a unitot, csak nincs rc.local fájl, hanem külön kell létrehozni.) -
#48795
cigam
titán
///Krisz\\\
#48788
cigam
titán
válasz
///Krisz\\\
#48788
üzenetére
https://logout.hu/cikk/raspbian/merevlemez_energiatakarekossag.html
Bár a többiek már leírták a lényeget. Az is elképzelhető, hogy az USB fiók vezérlője fixen így működik amire nincs ráhatásod, csak a csere segít.GhostVector
A te feltöltési sebességed a mérvadó, ill. az, hogy a távoli végponton mennyi marad belőle, ami pillanatról pillanatra. A belső hálózaton nem lesz gond.Helios
rc.local? Már régen nem SysV init rendszert használnak, hanem systemd-t. -
Helios
tag
válasz
///Krisz\\\
#48793
üzenetére
Ha parancssorból sem megy, akkor az rc.local sem lesz jó, mert az jelen esetben ugyanaz. Gyaníthatóan az az eset áll fent, hogy a te USB/HDD csatolód az ilyen beállításokat nem támogatja és az ilyen config parancsok nem mennek rajta keresztül.
-
Helios
tag
válasz
///Krisz\\\
#48791
üzenetére
És egyébként parancssorból működik?
Nálam azért került az rc.local-ba a "/usr/sbin/hdparm -B 255 /dev/sda" sor, mert másképp (pl. hdparm.conf-ból kiadva) mindig felülbírálta valami. (Ez a hozzászólás segített.)
-
#48791
///Krisz\\\
senior tag
Helios
#48790
///Krisz\\\
senior tag
válasz
Helios
#48790
üzenetére
Köszi, igen, az apm-et és a spindown-t is már próbáltam babrálni hdparm-ban:
/dev/sda {
apm = 255
spindown_time = 0
}De sajnos ez nem nagyon hatotta meg, ugyanúgy hibernálja a HDD-t 1 perc után. Egyelőre egy touch paranccsal csesztetem 30 másodpercenként, hogy ébren maradjon:
* * * * * mountpoint -q /mnt/ironwolf && touch /mnt/ironwolf/.keepalive >/dev/null 2>&1
* * * * * sleep 30 && mountpoint -q /mnt/ironwolf && touch /mnt/ironwolf/.keepalive >/dev/null 2>&1mert ugyan csak 60 másodperc után állítja le a tányérokat, de már előbb elküldi a fejet parkolni.
Gondoltam rákérdezek, hátha itt valaki kitapasztalt már valami jobb megoldást.
-
Helios
tag
válasz
///Krisz\\\
#48788
üzenetére
Szerintem a hdparm parancsot keresed:
"get/set SATA/IDE device parameters
hdparm [options] [device] .. "neked a -B kapcsoló kell: "Get/set Advanced Power Management feature"
DE nem minden USB-HDD csatoló / disk támogatja
(Nálam - régebbi rendszeren - szerencsére működik és végül a /etc/rc.local fájlba került bele megfelelő paraméterekkel ez a parancs, hogy minden indulásnál lefusson, mert másképp valami mindig bezavart.)
-
#48789
GhostVector
tag
GhostVector
tag
Köszönöm szépen a segítséget mindenkinek.
Itthon ezres optika van, és kezdetnek egy 8TB-os HDD-t gondoltam Hardverapróról, úgyhogy szerintem a sávszélesség nem probléma.
A fő kliens egy TCL C6K TV, azon futna a legtöbbet, aztán van egy Lenovo laptop, 2 Xiaomi telefon, ezek mind hálózaton belül, illetve hálózaton kívül rokonságban van egy Samsung és egy LG TV.Tényleg nem értek hozzá, és úgy tűnik régebben sem fizettem elő semmire, szóval nem volt semmiféle transzkódolás.
Szóval igazából az a célom, hogy szépen lassan építek egy itthoni kis "szervert", amin fut a Plexi szerver, majd később bővíteni szeretném nagyobb HDDvel, akár több darabbal is. A lényeg, hogy itthon menjen róla szépen minden film, sorozat. Általában egyszerre maximum 2-3 aktív kliens lesz.
-
#48788
///Krisz\\\
senior tag
///Krisz\\\
senior tag
Csatlakoztattam a Pi 5-höz USB-n egy HDD-t, de 1 perc tétlenség után elalszik a HDD. Nem tudom, hogy a Pi vagy az USB-SATA átalakító vezérlője altatja el, de van valami szofisztikáltabb megoldás ennek a megszűntetésére mint a touch parancs használata?
-
#48787
cigam
titán
GhostVector
#48784
cigam
titán
válasz
GhostVector
#48784
üzenetére
Pontosan. Arról már nem is beszélve, hogy A Plex transzkódolás funkciója fizetős. Vagy havi ~2300.-Ft, vagy lifetime licence-et kell vásárolni.
A 2-3-4 kliens, csak annyi terhelést jelent, mintha egyszerre 2-3-4-en elkezdenétek lemásolni a fájlt amit néztek. Ha belefér az USB sávszélességbe, nem okoz semmi gondot. Ha mondjuk egy videó 50MBps, 5 kliensek számolva ~250Mbps sebességre van szükség. Ez az USB2 sebességének a fele, a Gbit sebességének a negyede. Semmi extra terhelés nincs benne.
Persze ez csak akkor igaz, ha belső hálózaton használod, és nem távolról, az interneten keresztül próbálod nézni, mert ott beleütközhetsz a két pont közötti sávszélesség korlátba, ami igényelheti a transzkódolást. -
#48786
///Krisz\\\
senior tag
GhostVector
#48784
///Krisz\\\
senior tag
válasz
GhostVector
#48784
üzenetére
A nagy terhelést a transzkódolás és a remux-olás okozná. Transzkódolásnál a CPU fekszik meg, remux-hoz, pedig gyors háttértár kell (mondjuk ezt egy SSD megoldja).
Ha a kliens csont nélkül le tudja játszani a fájlt, akkor nem kell egyik sem és 10% alatti terheléssel megy a Pi.Nem tudom, hogy mennyire ragaszkodsz a Plex-hez vagy milyen klienseken néznéd a tartalmakat.
Nálam az vált be, hogy a kliensekkel VPN-en (Tailscale) csatlakozom és VLC-vel/IINA-val játszom le a tartalmakat SMB-n keresztül. Így nem kell állítgatni semmit, a Pi minimális terhelést kap és mindent "eredeti" minőségben lehet nézni.
Ennek annyi a hátulütője, hogy a feltöltési sebességed limitálni fogja, hogy miket tudsz lejátszani, de ha a tartalmak "beszerzésénél" figyeled a bitrátát és az nem éri el a szabad feltöltési sebességed 75%-át (mert a VPN-nek és az SMB-nek is van egy kis overhead-je), akkor teljesen jól működik. Persze a kliensekre is tudni kell telepíteni a Tailscale + VLC párost, de ez inkább TV-nél lehet szűkkeresztmetszet. -
#48785
Aszpirin
támogató
GhostVector
#48784
válasz
GhostVector
#48784
üzenetére
Igen, jól érted, bár a helyzet egy picit összetettebb lehet, mint itt sokan gondolnák.
A transzkódolást kép esetén erőltetetten ki lehet kapcsolni, itt csak az kell, hogy a kliens le tudja játszani. Hang esetén más ea helyzet, ott ha a kliens nem azt "mondja" a szervernek, hogy elboldogjl vele, akkor a szerver transzkódolni fogja a hangot. Tehát pl. egy Dolby Atmos-ból csinál AAC 2.0-t (Ezt csak egy példa), és ezzel küldi a képet a kliensnek.
Áltslában igaz, hogy ha ismered a klienseket, és tudod, hoygy mit képesek lejátszani, akkor tutod, hogy milyen kép/hangformátummal NE tölts le filmet, és mindenki heppi -
#48784
GhostVector
tag
cigam
#48782
GhostVector
tag
-
#48782
cigam
titán
GhostVector
#48781
cigam
titán
válasz
GhostVector
#48781
üzenetére
Arra még nem gondoltál, hogy olyan formátumba töltsd le, amit újrakódolás nélkül is lejátszanak az eszközeid?
-
GhostVector
tag
válasz
Aszpirin
#48780
üzenetére
Köszönöm szépen, akkor valószínűleg alszok rá még néhányat.
Régebben volt Synology NAS, abból sem a legolcsóbb, RAM is bővítve lett és 3 kliens esetében már ott is rosszalkodott. Lehet jobban járnék egy erősebb mini PCvel. Bár a torrent meg futhatna ezen, ennél csöndesebb, kevesebbet fogyasztó eszköz nem sok van. -
#48780
Aszpirin
támogató
GhostVector
#48777
válasz
GhostVector
#48777
üzenetére
Nálam egy RPi CM5-ös konfigon (8GB RAM, 64GB eMMC a rendszernek és 1TB NVMe SSD a torrentezéshez) fut a PLEX, Directstream-mel és Directplay-jel viszi rendesen a képet, 4K kép-transzkódolás viszont megfekszi a gyomrát, hang-trasnzkódolás egy kliensnek nem probléma 4K direct streammel. Kép trnaszkódolás 1 kliensnek FHD-ben még elmegy.
TLDR: lakáson belüli használatra torrent szerverrel együtt is, jó kliensekkel, kikapcsolt kép-transzkódolással teljesen okés. Én elégedett vagyok vele. Ha ismeretlenek a kliensek, vagy korlátozott a sávszélesség, akkor nem javaslom az RPi-t. -
#48778
AiRLAC
veterán
GhostVector
#48777
válasz
GhostVector
#48777
üzenetére
Plex mi? Szerver vagy kliens?
-
#48777
GhostVector
tag
GhostVector
tag
Üdv.
Plex mennyire tudna futni erről a kis eszközről?
Igazából 4K felesleges, se FHDban menne stream hálózaton belül 2, és távolról 1 eszközön. Azt mennyire bírná? -
válasz
lkristóf
#48775
üzenetére
Igen, a bemásolt képernyőkép 6. sorában látható I/O error alapján eléggé egyértelmű, hogy a microSD kártya (/dev/mmcblk0) - amiről az oprendszert próbálná betölteni - meghibásodott.
Az eredeti kérdésre: van hivatalos RPi microSD kártya előtelepített PiOS-szel, szerintem azt lenne érdemes használni: [link] -
sonar
addikt
válasz
lkristóf
#48771
üzenetére
Csak a saját tapasztalatomat tudom megosztani.
Semmi se örök. Döglött már meg mindenem.
Nálam sd kártyán csak a boot partició van a többi Pendrive-on vagy SSD-n.
Nekem ez bevállt. Teljesítmény szempontjából is úgy érzem, hogy így tudom a maxot kihozni az RPi-ből. Sokkal responzivabb, mintha csak sd kártyáról futna. -
Nem emlékszem pontosan de szerintem 1-2 éve már újra kellett raknom mert meghalt a kártya valami 32-es sandisk lehet benne.
Sajnos nem volt nálam micro hdmi, hogy megnézzem mit mutat, mert headless működik és restart után sem volt elérhető ssh-n, talán ha képernyőre dugom okosabb leszek, de már sd kártyával készülnék.
Ha csak u1-es kártyát vennék bele érezhetően lassabb lenne mint egy u3-as kártyával? Van e esetleg valakinek ezzel tapasztalata.
#48770 azbest Még nem próbáltam ezt, hogy a rendszer külső vinyón legyen, ha olyankor halna meg, akkor tudok egyszerűen egy bootolásra alkalmas sd kártyát készíteni? Utána kéne járnom a dolognak.
-
azbest
félisten
válasz
lkristóf
#48767
üzenetére
léteznek kifejezetten ipari használatra szánt változatok, ami csinál olyan wear levelinget, mint az ssd-k. Nem márkafüggő, hanem konkrét típust kell nézni.
Egyébként tudhat úgy is indulni, hogy a kártyán csak a boot partició van, ami csak frissítéskor változik a rendszer meg a winyón. Vagy eleve kártya nélkül a winyóról is lehet hogy tud. -
Rpi4ben valoszinuleg meghalt az sd kartyam, ja arrol megy 24/7be kulso tapos 2tb vinyoval. Milyen kartya az ajanlott ami nem hal meg hamar vagy mindegy?
-
kbhuinfo
tag
válasz
Aszpirin
#48752
üzenetére
Elszigetelt eset
Nalam pont most jott ugyanez a feladat es a kovetkezo tortent: imager-el pi4 legujabb image (32bit trixie) fel, freerdp3 telepit es labwc autostart elindit. Aztan bekonfigoltam a szunetmentes HAT-et (qups) es mehet is a termelesbe. -
azbest
félisten
válasz
azbest
#48736
üzenetére
hmm, ez a raspberry pi connect ssh ablak nem a legjobb... a karakteres UI felületeknél szétesik teljesen. Tegnap szívtam azzal, hogy nmtui segítségével beállítsak másik wifi ap paramétereket a webkamerának beállítot pin és elvérzett, nem képes megjeleníteni.
A Tailscale is szivatós kicsit. De valsz azért, mert nem sokat használtam. A megosztott gépnél nem alap, hogy az ssh portot is elérje a másik user, azt külön kell engedélyezni. Saját fiókkal meg nem akartam beléni más gépén, ahogy a wifi átállítást próbáltam megcsinálni. Végül korábban beállított teló hotspotra fellépve notival és pi-vel sikerült ssh-val hozzáadni az nmtui-ban az új ap-t.
-
#48761
shadow1901
aktív tag
shadow1901
aktív tag
Pontosan 30mp, ennyit kellett volna TEKERNI, nem feltétlen megnézni. Itt kezdődik. Verziószámot nem tudom.
-
cigam
titán
válasz
Aszpirin
#48758
üzenetére
Kösz! Lehet egy programozásra kihegyezett fizetős jobban/többet tud, de az ingyenes általánosról nincs jó véleményem. MItől kerülnék bajba? Nem vagyok programozó, a saját munkám megkönnyítésére faragok biteket, szórakozásból. Majd akkor kerülök bajba, ha még a hólapátolást is elvégzi helyettem
Inkább Skylake-től vártam volna valami részletes(ebben) indoklást, hogy mitől komolyan vehetetlen. -
Nem tudok jobb szakmai érvet, mint hogy GitHub Copilotot használok már majdnem egy éve, napi szinten, a pénzkereső munkámhoz (Informatikus vagyok, a senior fullstack fajta, egy nagy /értsd: kb 2ezer fős) szoftverfejlesztő cégnél, ipari területetn, leginkább prototipizálással foglalkozom). Kb augusztus óta nem találkoztam hallucinációval. Amiben született ezalatt "kód": C#, Python, Terraform, _gitlab_ci.yml, dockerfile, docker-compose, bash scriptek és MATLAB.
A hobbi dolgokhoz (kb mindenhez, nem csak IT témákban) pedig előfizetéses ChatGPT-t. Jelenleg 5.2-nél tart.
Ha nem tudsz rájönni, hogy mire jó, akkor tényleg nem neked való, de akkor készülj fel rá, hogy NAGYON rövid időn belül nagy bajban leszel, és ezt érdemes nagyon komolyan venni.
Ugyanis tetszik vagy nem tetszik, a prgramozásra ill. IT-s fejlesztésekre kiélezett LLM-ek (ld. GitHub Copilot) teljesen újradefiniálják a szfrverfejlesztési paradigmát, értelmét vesztik a "Java-programozó", "C++-programozó", stb. kategóriák, és előtérbe kerül a prompt engineering. Komolyabb jhelkyeken már a promptok kerülnek a version management rendszerekbe, egyelőre a kód mellé, de hamarosan a kód helyett...
Nekem egyébként hányingerem van az AI-hype-tól, mert nem, az LLM nem intelligencia, csak a jó öreg machine learningre épített nagyon fejlett algoritmus(halmaz), de a hasznosságát és a hatékonyságát nehéz lesz megkerülni a szakmában. Nagyon nehéz lesz. Vagy felülsz a hullámra, vagy elmerülsz. És ez MOST tényleg nem vicc. -
cigam
titán
válasz
Aszpirin
#48754
üzenetére
Majdnem napi szinten próbálok rájönni, hogy mire is jó. Programozásban is. Pl. decemberben megpróbáltam módosítatni vele egy kis scriptet, ami hónapoknak, és azon belül a napoknak készített egy mappát. Sokadik nekifutásra sikerült csak az MI-nek megoldani, hogy a hétvégéket hagyja ki. Az első pár módosítása olyan "jó"ra sikeredett, hogy el sem indult, hibával kilépett, aztán elindult, de nem hozta létre a könyvtárakat....
Persze aki nem ismeri a nyelvet, nem olvas utánna, az a sokadik próbálkozással kikalapálja működőre. Egy délután alatt saját kútfőből is sikerült volna, talán még elegánsabban is mint ahogy végül lekódolta az ő megoldását.
Értem én hogy fejlődnek, de még mindig hiányzik belőlük a valódi intelligencia. Ráadásul kényszert éreznek hogy válaszoljanak, még akkor is, amikor lövésük sincs róla mi a válasz. Nem azt mondják, hogy nem tudják megválaszolni, nem értik a kérdést, hanem valami hallucinációba kezdenek. -
Végülis igazad van, magamnak okoztam a szopást
, de hát az LXDE olyan fapados, 20 évvel ezelőtti feelinget ad, míg a GNOME egy modern, eredeti UI-koncepciójú felület, ami RPi-n is teljesen rendben fut...Az X úgy fut, hpgy az Xrdp egy Xorg-ot RDP-re, majd ezen az XRDP start scriptje (/etc/xrdp/startwm.sh) pedig ebben indítja el a gnome-session-t. Így persze nem az RPi-re esetleg csatolt képernyőn látható kép lesz duplikálva, de egy remote grafikus kliensem lesz, és ez nekem pont tökéletes!
(ehhez persze a megfelelő konfiguráció kell, de ezzel nem untatnám a nagyérdeműt, akit érdekel írja meg privátban)
Íme, az RPi session Gmome-mal egy macOS-ablakban:
Ami az MI-t illeti, amiot írtál az egy "divatos" érv ellenük, de: már leírtam egy Mac-es topikban: csak óvatosan a kijelentésekkel, a félévvel ezelőtti tapasztalat garantáltan nem releváns már. Az AI chatbot-ok és IT-s copilotok programozás- és általában IT-"tudása" félelmetes tempóban fejlődik. Az elmúlt évben rengeteget dolgoztam ilyen. copilotokat hasznélva, ami még május-júniusban széthallucinálta az agyam, az augusztustól NAPI hasznéálatban máig egyetlen egyet sem hallucinélt már. FÉLEMLETESEN jó. Itt az idő ezt a hallucinálásra hivatkozást félretenni, és ez nem vicc, járj magad is utána...
Nálunk már kvázi-kötelező az AI, mindenesetre már mérik, hogy ki mennyit használja a Github-Copilot-ot. Ésn a csapból is az folyik, hogy használd. Nem véletlen, iszonyatosan fel lehet gyorsítani vele a fejlesztést, főleg a prototipizálási fázisban. -
cigam
titán
válasz
Aszpirin
#48752
üzenetére
A Windows-on sem cseréled le az asztali felületet, na ná, hogy működnek a gyári alap beállítások. Ahogy az RaspberryOS esetén is pöc-röf működik a távoli elérés.
Csakhogy Te az LXDE-t lecserélted Gnome-ra. Szóval ezt magadnak okoztad.
Amúgy gratulált a kitartáshoz, és hogy végül sikerült megoldani. Bár azt továbbra sem értem, ha valóban Wayland fut nálad, akkor hogyan fut vele párhuzamosan az X.
Azért az MI-t ne vedd készpénzek, bődületes butaságokat képes hallucinálni.
-
Na, Éjjel 2 óra van, és VÉGRE a probléma megoldva.
Nem is akarom elmondani, mi mindennt csináltam végig, iszonyat frusztráló volt, nem ment.
A tanulságok, hátha valakinek segítenek, direkt beírva a kulcsszavakat, amivel esetleg elő lehet keresni ezt a bejegyzést:
1. Jump Desktop sz RPi-vel NEM KOMPATIBILIS, RPi-re nem fogsz tudni vele RDP-zni. Az ajánlott RDP kliens Mac esetében a Microsoft Windows App nevű progi (App Store-ban fellelhető, ingyenes), Windows esetében a beépített Remote Desktop.
2. a GNOME saját hnome_remot_desktop service-e egyszerűen NEM MŰKÖDIK Raspberry Pi CM5-ön.
3. A megoldás: XRDP-t kell telepíteni és használni. Mivel az XRDP Wayland-en nem működik, úgy kell konfigurálni, hogy saját magának egy Xorg-ot indítson a távoli elérés részére
4. az RPi-n / GNOME-on javasolt beállítani az auto logint valamint a képernyő lockot.
5. a haverom, ChatGPT 5.2, további hasznos magyarázatokat és tanácsokat is adott, lásd:
Ez a történet sikerrel zárult, távoli képernyőn GNOME felületet kapok az RPi-hez, de ismét megerősítette a Linux elleni antipátiámat: egy olyan oprendszerrel, amivel folyamatosan éjszakába nyúló sessionöket kell eltölteni, hogy a máshol teljesen simán és 2-3 perc alatt beállíthatóan működő dolgok menjenek, csak igazi geek-eknek van keresnivalójuk, akik szórakozásból órákon át püfölik a billentyűket a Linux által mindegyre előállított feladványok megoldása érdeképben. Akiknek a géphasználat nem eszköz, hanem maga a cél.
Persze ha az embernek már RPi-je van (főleg CM4/5), akor eléggé geek-nek számít hogy ilyen apróságokon, hogy éjszakázások, ne rinyáljon -
-
Elérem az RPi-t a 3389-es porton a kliens gépről (M2Pro Macbook Pro), nem ezzel van a gond, hanem ezzel ni:
Vagyis az RDP service halott az RPi-n. Na jó, akkor indítsuk újra:
Én ezt nem értem. Milyen credential-ok hiányoznak? Mi az a GKeyFile?
Van ötleted, hogy mit kezdhetek ezzel? -
Visszaállítottam az imént Wayland-re (raspi-config-gal), reboot... és megáll az ész... most nincs a Settings / Sharing alatt Remote desktop... WTF???
(imádom bmeg a linuxot.... mindennel napokat kell szopni, ami más rendszereken kb azonnal megy).
De egyébként volt már waylandon, próbáltam, nem ment. csak most a javaslatodra a tűzfalat csekkolnám... mert azzal lehet gond...Szerk.: megvan, a Settings / System alatt van a Remote Desktop.... bocs, valszeg korábban is onnan lőttem be...
Mindjárt nézem, mi történik.
Szerk2. Van egy olyan fül is itt , hogy Remote Login. Ha azt bekapcsolom, átrakja a Remote Sharing-et 3390-re egy üzenettel, a Remote Login pedig elfoglalja a 3389-et...
Egyelőre így lesz, aztán meglátjuk... -
cigam
titán
válasz
Aszpirin
#48745
üzenetére
Nem csak PiOS létezik, sok disztrónak van Pi-n is futó verziója. Legyen az Ubuntu, Debian, vagy éppen Arch.
A Gnome RDP csak akkor működik, ha már be vagy jelentkezve. Plusz a waylandra épül, szóval X11 alatt nem is fog működni.
Állítsd vissza Wayland-re, jelentkezz be, engedélyezd a távoli elérést, és ezután próbálj belépni.
Van tűzfal? A 3389-es porton eléred onnan, ahonnan elérnéd? pl. nmap -p 3389 a.pi.ip.címe -
X11. Az xrdp nem megy Wayland-on, ezért váltottam vissza X11-re. De Wayland-on sem ment a gnome-remote-desktop (ami az általad említett beépített RDP-megoldás, vagyis természetesen próbáltam)
Hogy érted, hogy melyik disztró? A Trixie-re épülő legújabb 64 bites PiOS, hadd ne mondjak most verziószámot, a legújabb Így értetted? -
Sziasztok! Van valaki, akinél működik RPi-n GNOME-mal a RDP vagy VNC alapú remote dektop?
Amióta GNOME-ra váltottam, már mindent kipróbáltam, de még a RPi ID alapú felhős távoli elérés is megszűnt létezni.
xrdp-t egyszer működésre bírtam, nem Gnome jött be vele, de legalább grafikus felület... és még ezt a félsikert sem sikerült soha többé megismételni.Jump Desktop-ot (fizetős többprotokollos remote desktop kliens) használnék kliensnek Mac-en, Windowsra, másik Mac-re megy vele gond nélkül a bejelentkezés
-
-
azbest
félisten
ja hát a modernebb programok, oprendszer sokkal több erőforrást használnak... a 256MB-os eredeti raspberry kb használhatatlan már. Gpio minimál dologra max. De pl kamera minimál gpu ram igény mellett nem marad már a rendszernek a kernelen kívül ram.
Meg inkább az, hogy az újabb rendszerben nincsen készen sokminden, ami a régin már megvolt. És értem én, hogy szabványosabb api meg minden, de nincs készen
És lehet nem is tesz az alapítvány nagy effortot bele, hanem kivárja a közösséget - de lehet tévedek ebben. -
válasz
azbest
#48736
üzenetére
Én két sima zero W-ből csináltam tavaly megfigyelő kamerát, heteken át kerestem egy image-et, ami képes volt 10 percnél tovább futni anélkül, hogy összehányta volna magát... Végül egy sok éves asszem buster image volt hajlandó csak működni, az is csak tweak-elve, holott a többi - újabb - rendszer is papíron minden hardvert támogatott, aztán meg mégsem...
-
#48737
wassermann
Topikgazda
azbest
#48736
wassermann
Topikgazda
válasz
azbest
#48736
üzenetére
Az a helyzet, hogy a régi Pi-k tényleg kopnak ki.
Az első Pi-met már évekkel ezelőtt odaadtam az egyik kollégámnak, abból akkor terrárium vezérlót csinált a fia.
A Pi2-m a TV-mögött lóg videómagnóként, de nem nagyon használom.
Egy Zero-t pedig kipurcantottunk, mert leesett a földre és valaki véletlenül rálépett, így a kukában végezte szegény... -
#48736
azbest
félisten
wassermann
#48726
azbest
félisten
válasz
wassermann
#48726
üzenetére
múltkor csináltam távolról elérhető webkamerát a pi zero 2w kártyámból
Fú de bosszantó volt, hogy az eredeti v1.3 kamera nem illik a hivatalos házba, mert túl vastag a lecse körüli műanyag szögletes része és beleütközik / kicsit neki a lyuk. Szét is nyomtam kicsit a kamera modulon lévő kis csatlakozót, ami a tényleges kamerát köti a kis nyákra, mert azt hittem csak szorul, úgy kellett visszahajtogatnom az érintkezőket. Végül barbár módon kifaragtam nagyobbra a lyukat.
Egyébként eléggé mostohagyereknek tűnik ez a kameratámogatás az újabb oprendszereknél. Az alap, pythonos eléréses dolgok mennek persze, de valami rendes szoftverből használni barkács helyett nem tűnt jól támogatottnak. Sok leírás még az 5-10 évvel ezelőtti rendszerekről, más megoldásokról szól.
A motioneyeos [link] kész előrekonfigolt rendszer régi, nem támogatott os verziónál maradt és nem fejlesztik. Maga a motioneye az működik újabb renszerekkel, de a legfrisebb "Trixie" oprenszernél a video4linux2 alrendszer nem kezeli még és ilyen kókány wrappeléses útmutatót láttam, ami eszi a cpu-t [link] és nem is mindent mond el, hogy ne csak kézzel indítós legyen, hanem minden szépen megfelelő sorrendben serviceként induljon.
Viszont amit a videónál is használt alapnak, busteres leírást követve már működő és stabil rendszer lett hozzá, amiben a kamera megy, csak annyi hekk van, hogy a libkamerás varázslatukat bele kell írni a servicebe, hogy azzal induljon a program. És persze buster "legacy" lite rendszert kell kiíratni a kártyára [link]Távoli elérésnek néztem a busterre is telepíthető Raspberry pi connect szolgáltatást, de végül a Tailscale-t is feltettem, mert azt pécéről, telóról is egyszerű használni. Amúgy lehet ugyanaz az alapja mindkettőnek, csak az különbözik, hogy ki nyújta a szolgáltatást hozzá. Szóval ezzel a kamera elérhető távoltól is vpn-en át, publikus ip címes kiengedés nélkül. Egyedül arra kell figyelnem, hogy távolról ne nagyon váltogassan a kamera felbontást, mert lehet lefagy néha vagy eldobja a wifit néha miatta, bár nem debubboltam, szóval más probléma is lehet az oka.
A régi v1.3 kamera képminősége eléggé gyenge és zajos a mai telefonokhoz képest. Mivel egész olcsó, rendeltem egy v2-eshez hasonló, szélesebb látószögű, IMX219 -es kameramodult is.
A régi pi2-esekből lehet szintén kamerát csinálok, úgysem használom már másra őket. Eredetileg egyébként növény növekedést figyelő timelaps kamera megoldást kerestem, csak pont kellett egy webcam, hogy távolról a növény lámpákra rá lehessen nézni, hogy megfelelően ki-bekapcsolnak-e. Viszont úgy látom a timelaps-okhoz is inkább python kézi kókányolás a jellemző, nem láttam "kész", széleskörben használsz szoftvert, amit odaadhatok olyannak, aki csak webes felület be akarja állítani és működik.
-
-
vadkörte
addikt
Nem meggyőzni akarlak, de te kérdezted...
Pedig megtetted!
Ha minden jól megy jövő héten megjön a DAC-om, akkor lekerül a Pi2-ről a DAC-HAT és átmegy USB üzemmódba. Adtam egy esélyt a Volumio-nak, még mindig nem tetszik az előfizetéses rendszere de ami nekem kell belőle az pont free... Sokkal többet kajál - működés közben ~80MB a szabad-, ~240MB a felhasznált RAM, a maradék mintha lapozóállomány lenne (RAM-disk??? )
Ez után a kicsike kibújik a plexidobozból és visszaköltözik a régi házába, ekecselek rá egy power-button-t, hogy normálisan le tudjam állítani és a low-cost streamer kész is lesz. A kártyaolvasós mSD miatt aggódtam, igaz onnan használat közben csak olvasás történik, írási művelet minimális, vagy semmi.
Már csak a TV alá kell valami média kliens, de azt a kérdést már a megfelelő helyen fogom feltenni.
ui.:
Minden kedves topiktársnak nagyon boldog új évet kívánok! -
-
vadkörte
addikt
Mert:
A zenéim jelenleg egy a Pi seggébe dugott párszáz Ft-os kártyaolvasóban lévő 128GB-os mSD kártyán vannak.
ésNormálisabb háttértár mégiscsak jobb lenne és a kisfloppy doboz se nagyon illik a képbe.
RPi2=szerettem, de be kell látni, hogy eljárt felette az idő. Gyenge a HW, még akkor is ha csak egy headless streamer a cél. Az rAudio 2026-tal elengedi, frissítés, támogatás nem lesz (nem mintha égetően kellene). A Volumio megint kipróbálom, talán még támogatja de az előfizetős rendszere - számomra a free is pont elég - nagyon nem szimpatikus. A moOdeAudio sem támogatja már nagyon régóta.
Ezzel szemben a Pi4 frissebb időtállóbb a HW, egy GeeekPi, vagy egy DeskPi házban pedig a 2,5"-os SSD is kulturáltan elfér, nem lógnak mindenfelé a kanócok, valamint...az asztali képbe is szépen beleillene...
-
#48724
///Krisz\\\
senior tag
cigam
#48723
///Krisz\\\
senior tag
Értem, köszi.
Így felraktam a Jellyfin-t, de sajnos nekem nem lesz jó. Arra szerettem volna használni, hogy a nagy bitrátájú tartalmakat transzkódolja, mert elég lassú (22 Mbits) a feltöltési sebességem és a jobb minőségű tartalmak már akadnak. De nem bírja a Pi 5 procija, 100%-on pörög és borzalmas 30-40 másodperces beakadások vannak.
-
#48723
cigam
titán
///Krisz\\\
#48722
cigam
titán
válasz
///Krisz\\\
#48722
üzenetére
Passz. Mivel alapból SD kártyán van a rendszer, jó ötlet, hogy az átmeneti, minden lim-lom ideiglenes tárolására szánt könyvtárat a RAM-ba tartsa, és kikapcsoláskor automatikusan kiürül. SSD esetén maradhat kikapcsolva. Nem lesz érdemi difi a mindennapi működésében. Sem a rendszer sebessége, sem az SSD nem sokat vesz ebből észre. Egyrészt elég gyors az SSD írás olvasás, másrészt sokkal fejlettebb cella védelmi eljárásokat háznál, mint a mezei SD.
-
#48721
cigam
titán
///Krisz\\\
#48720
cigam
titán
válasz
///Krisz\\\
#48720
üzenetére
Na és ha nem SD kártyáról fut akkor, akkor mi van? Fogjuk a bejgli kómára, de ha egy percig elgondolkozol rajta ...
A tmpfs nem tudja milyen típusú a háttértárad. Nem is érdekli, nem befolyásolja a működését. Őt egyetlen egy dolog érdekli, hogy mi van a konfigurációs fájljában.
Azt kipróbálhatod, megteheted, hogy telepítés után visszakapcsolod. Valószínű futás közben már nem lesz szüksége ekkora méretű /tmp mappára. -
#48718
cigam
titán
///Krisz\\\
#48717
cigam
titán
válasz
///Krisz\\\
#48717
üzenetére
Insufficient free space for /tmp: 2073472KB found, 2097152KB required
Nincs elég hely a /tmp mappában. Ez egy virtuális, a RAM-ban létrehozott mappa, hogy gyorsítsa a rendszer működését, és kímélje az SD kártyát a sok írástól.
A sudo nano /etc/default/tmpfs paranccsal szerkeszd át a fájlt, és a RAMTMP=yes sort írd át RAMTMP=no -ra. Indítsd újra, és ekkor már a fájlrendszerben lesz a /tmp mappa, és ha van elég hely a kártyán, már le fog futni a telepítő. -
#48717
///Krisz\\\
senior tag
///Krisz\\\
senior tag
Próbálom telepíteni a Jellyfin-t egy Raspberry Pi 5-re, amin Raspberry Pi OS Lite fut, az alábbi paranccsal:
curl https://repo.jellyfin.org/install-debuntu.sh | sudo bash
de ezt dobja:
horvathkrisztian@raspberrypi:~ $ curl https://repo.jellyfin.org/install-debuntu.sh | sudo bash
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 12926 100 12926 0 0 24964 0 --:--:-- --:--:-- --:--:-- 25001
> Determining optimal repository settings.
> Checking for free space and known-problematic filesystem targets.
>> OK: Data directory has 440637MB of available space.
>> OK: Data directory on ext4, this is supported.
Insufficient free space for /tmp: 2073472KB found, 2097152KB requiredPlease increase tmpfs size or free up space and try again.
Ez mi lehet? Milyen tárhely kevés neki?
-
cigam
titán
Bármi ehet belőle
- reklámszűrő: pi-hole
- DLNA sterver (a videókat képeket egy központi helyről tudod megnézni, akár TV-n is)
- Torrent szerver (megmondod mit töltsön le, a többit elintézi maga)
- SMB szerver (NAS, helyi fájlmegosztás, vagy akár a fontos adatok mentése is mehet ide)
- internetes rádió
.... -
DarkByte
addikt
Ha csak ennek akarod szentelni a Pi-t akkor igen. HAOS image-et rá és az majd karbantartja magának.
Ha mást is rá szeretnél bízni, inkább ne, Home Asssitant Docker konténereit kézzel frissítgetni Raspbian-on nem túl szórakoztató. (Évekig így használtam a HA-t egy Pi4-en, de mivel utáltam frissítgetni folyton le voltam maradva rengeteg verzióval.)
Inkább egy Intel N100-as mini PC + Proxmox és a HAOS-t mint VM használni, és akkor az mellé olyan további VM-eket indítasz amilyeneket csak szeretnél. Nagyobb HA upgrade előtt is lehet a Proxmox-on át snapshot-olni, és ha összedönti magát, 2 kattintás és megint üzemel.
-
vadkörte
addikt
Üdv a mélyen tisztelt topiktársaknak (azért van pár ismerős arc
)!
Jóóóó régen nem jártam erre. Leginkább tanácsért fordulnék a kollektív tudathoz. Évek óta porosodott a kis Pi2-m a TV alatt - LibreELEC-kel médiakliens volt egy Dell Optiplex 160-as PC-NAS-ról játszott le filmeket - mivel a NAS OMV-jét lusta voltam/vagyok életre kelteni és más okok miatt, funkció nélkül maradt. Pláne miután egy viharban egy közeli villámcsapás elvitte a tápját. Szerencsére az egész házban csak az pukkant el pedig volt pár fogyasztó. (a feszszabályzó IC égett el benne de úgy, hogy csak a lábai maradtak meg a NYÁK-ban és a NYÁK is átégett, ami mellesleg baromi büdös volt)
2024 közepén barkácsoltam egy erősítő féleséget munka melletti zenehallgatáshoz, ami meghozta az étvágyat.
2025-re lett egy egész jónak mondható D osztályú erősítőm, egy hozzá illő elektroncsöves előerősítővel (nem kell a láncba, de szép kellemes hangja van) - és jó ideig a "PC" - Mac Mini M2 - funkcionált mint forrás és lejátszó. Egy hirtelen ötlettől vezérelve letöltöttem a Pi2-re elérhető utolsó rAudio IMG-t (a Volumio-tól elment a kedvem mióta erőlteti az előfizetést) és telepítettem a Pi2-re. A DAC kártya addig marad a láncban, amíg megjön csájából a kicsit komolyabb USB-s DAC-om.
Némi forrasztás - a Pi-re anno vettem egy FiPi DAC+ v2.0 DAC-ot, az RCA-kat kivezettem a háznak használt 3,5"-os kisfloppy doboz hátuljára és az átkötés valahol megszakadt - után összekötöttem az előfokkal és...
Nem tudom milyen DAC chip van a Mini-ben, de még eszel a vacak DAC-kártyával is simán lezenéli a Pi...
És a hosszúra nyúlt bevezető után a lényeg. A zenéim jelenleg egy a Pi seggébe dugott párszáz Ft-os kártyaolvasóban lévő 128GB-os mSD kártyán vannak. Nem életbiztosítás, de mindegy. Normálisabb háttértár mégiscsak jobb lenne és a kisfloppy doboz se nagyon illik a képbe. A Pi2-vel már nem tervezek hosszú távra, az visszaköltözik szépen a TV alá LibreELEC-kel, a végtelenül gyengusa HW mediaplayer-nek még jó. Bár SSH-n nézve az rAudio fogyasztása is kifejezetten vicces. (az SoC 1-1 magja néha felugrik 10% fölé, de amúgy pár %-ot kaját mindezt ~40MB RAM foglalással)
Streamer célra - csak lejátszó, nem kell kijelző, nem kell RC, sem távirányíthatóság és DAC sem - egy 4GB-os RPi4-nek lenne értelme? A gépet egy 2,5"-os SSD/HDD fogadására alkalmas NAS/desktop házba - DeskPi case - tenném. Így már azért az asztali képbe is szépen beleillene - Streamer-DAC-erősítő-előfok - nézegettem USSF és microPC gépeket is, de azok fogyasztása a Pi-ének a sokszorosa és a teljesítménytöbbletet a büdös életben nem használom ki. -
Igen. Legalább 4GB RAM legyen és legalább 32GB microSD, utóbbi legyen jófjta, ne a legolcsóbb izé.
Nálam RPi 5-ön fut a HA, a 64 bites PiOS-en, dockerben, de persze felrakhatod direktben a HAOS-t is RPi Imager 2.0.0-val (az OS választásánál "Another specific OS" - "Home automation" - "Home Assistant"), ha csak arra akarod használni, úgy jobb is. -
erzol
őstag
Sziasztok!
A tudatlanok nyugalmával szeretnék kérdezni.
Van itthom 33 xiaomi eszközöm xiaomi home alkalmazás alatt.
Próbáltam home assistantba integrálni őket egy qnap ts-431p2 nas-on keresztül, de ennek csak arm32-es architektúrája révén elég régi HA-t képes futtatni, ami csak API alapon integrálná az eszközeimet.
Raspberry pi 5 alkalmas lehet nekem arra, hogy a legújabb HA-t telepítsem rá, ami már képes xiaomi account-al minden eszközömet egyszerre integrálni?
Köszönöm szépen a segítő válaszaitokat! -
cigam
titán
válasz
lanszelot
#48699
üzenetére
Le lehet tiltani a szűrést. A baloldali menüsoron ott van, hogy "Disable Blocking" Itt pár percre, vagy végleg kikapcsolhatod a szűrést.
A "Query Log" oldalon láthatod miket szűrt ki. Itt megkeresed a kiszűrt oldal linkjét. a jobb szélén található "Deny" gombra kattintva hozzáadhatod a kivétel listához, hogy ne szűrje ki. Ezt a kivétel listát a baloldali "Domains" menüpontban kezelheted. -
válasz
lanszelot
#48701
üzenetére
Ugyan ez nem adguard reklám topik, de igen, játékokban is és mindenhol szűr mindent, egyedül youtube-ra kell külön megoldás. 94.140.14.14 és 94.140.15.15 van beállítva a routerben és azóta egy darab reklámot nem látok se telefonon, se gépen, játékokban sem. Telefonon külön be van állítva, hogy mobilneten se lássak reklámot.
-
#48703
Aszpirin
támogató
wassermann
#48702
válasz
wassermann
#48702
üzenetére
Köszi, igen, elég sokat keresgéltem a problémával kapsolatban, a probléma ismert, és eléggé öszetett. Az okozza, hogy a BT-perifériák, ha nincsenek használatban, egy idő után "elalszanak" az akkumulátoridő növelése érdekében. A BT-kommunikáció sajátosságai miatt itt megszakad a kapcsolat, és a felébredéskor szükség lenne agy reconnectre, de ezt a periféria nem tudja kezdeményezni, az RPi pedig nem észleli a "felébredést". Patthelyzet. A megoldások között a legtöbbeknbél egy cron-nal időzített script fut, amelyik folyamatosan polloz, és vagy nem engedi elaludni a perifériát (ez nem jó az ajkkumulátorának), vagy ha a trusted perifériát disconnect állapotban találja, akkor megpróbál reconnectelni, és ezt folyamatosan mondjuk félpercenként ismételgeti. Azt hiszem nem kell magyaráznom, miért nem ideális megoldás ez, de egyelőre jobbat nem találtam. Ezt fogom én is csinálni, de csak a billentyűzettel, mert ha a billentyűzet automatikusan konnektál, annak segítségével már tudok terminált indítani és egyetlen paranccsal újraindítom a BT-alrendszert, amiután konnektelni fog az egér is.
-
#48702
wassermann
Topikgazda
Aszpirin
#48697
wassermann
Topikgazda
válasz
Aszpirin
#48697
üzenetére
Sajnos ilyesmi előfordul máshol is és nem könnyen orvosolható: nekem egy Windows-os PC és egy Linux-os PC is szereti eldobni a rádugott perifériákat hosszabb idejű mellőzöttség esetén, ilyenkor csak a ki-bekapcs segít.
Nyilvánvaló, ha lekapcsolja egy periféria hardvercsatornájáról az áramot, akkor az csak egy újabb hardver szkennelési ciklus után fog látszani (indítás), amikor újra mindent aktívvá tesz.
-
lanszelot
addikt
Észre vettem hogy csak telefonon blokkol olyanokat amit nem kellene.
Beírtam a linket pc-n, és ott meg tudom nyitni.
Telefonon nem.
Telefonon a pi-hole admin felülete is blokkolva van.
Próbáltam több böngészőt is telefonon, de nem.
Pc-n semmi gond.
Hogy lehet hogy telefonon nem engedi megnyitni az oldalakat?
Biztos hogy pi-hole, mert ha fizikálisan kinyomom, akkor meg tudom nyitni telefonon amit addig nem.Köszönöm szépen a választ.
Ad guard nem ingyenes. (Igen van ingyenes része, de az szűr amit szűr)
Ad guard össze se hasonlítható pi-hole -val.
Ad guard csak a böngészőt szűri.
Pi hole mindent. Az alkalmazásokban/játékokban nincs reklám. Tehát mindent szűr.
,) 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
- Automata kávégépek
- Óra topik
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Miért tűntek el a buta tévék?
- TCL LCD és LED TV-k
- Kormányok / autós szimulátorok topikja
- Motorolaj, hajtóműolaj, hűtőfolyadék, adalékok és szűrők topikja
- Folyószámla, bankszámla, bankváltás, külföldi kártyahasználat
- Névteleníti a Panther Lake IGP-jét az Intel, ha nem gyors a memória mellette
- Kerékpárosok, bringások ide!
- További aktív témák...
- Asztali PC , R5 8400F , RTX 3080 , 32GB DDR5 , 1TB NVME
- ASUS CORE I7 8700 GAMER MAX PC 16Gb RAM 512GB NVME SSD ASUS GTX 1660 SUPER 6GB DDR6 1ÉV GAR!
- ASUS CORE I5 8400T GAMER MAX PC 16Gb RAM 512GB SSD ASUS GTX 1660 SUPER 6GB DDR6 1ÉV GAR!
- BeQuiet! GAMER alap! i9-14900K / Z790 / 32GB 6000MHz / 2TB Gen4 / 1000w Gold! BeszámíTOK
- Eladó Asus ROG Nuc15 (2025) - Ultra 9 275HX, RTX 5070 Ti Laptop, 32GB/1TB, hibátlan, magyar garis
- 179 - 180 - 189 - 190 - Lenovo LOQ (15IRX9) - Intel Core i7-13650HX, RTX 4060
- ÁRGARANCIA!Épített KomPhone Ryzen 5 7500F 32/64GB RAM RTX 5070 12GB GAMER PC termékbeszámítással
- Honor 200 Pro - Black - 12/512GB - Új Garanciába cserélt!
- HP 150W töltők (19.5V 7.7A) kis kék, kerek, 4.5x3.0mm
- ÁRGARANCIA! Épített KomPhone Ultra 9 285K 32/64GB RAM RTX 5070 Ti 16GB GAMER PC termékbeszámítással
Á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