Sziasztok!

Valaki használja úgy az Rpi-t, hogy HDD/SSD-ről bootol? Ha igen befolyásolja a torrent sebességét?

Szerintem ha a neted 1 Gbit, akkor azt a HDD is ki tudja szolgálni. SD-hez képest szerintem számít, de ha transmission-t használsz akkor nem sok különbséget fogsz valószínűleg észrevenni.

Sziasztok!

Kérdessel fordulnék hozzátok.
Volumio-ról szertnék érdeklődni.
Tudja azt, ha rákötöm jack-el egy hangcuccra, akkor arra a házban lévő összes eszközről (laptopok, tabletek, android teló, iphone, macbook... ) tudok "küldeni" zenét?
Ez a zene lehet Spotify, Youtube, telón lévő zene, pc-n lévő hangfájl, netrádió?
Ha jól látom, pluginokat kell aktiválni, de ezek jól és megbízhatóan működnek?
Ismerősnek kellene.
Amolyan iEast cucc kellene. Vagy ne szórakozzunk és rögtön iEast?

Köszönöm szépen!

Xiaomi 13 eu dev...

SD-hez képest szerintem számít, de ha transmission-t használsz akkor nem sok különbséget fogsz valószínűleg észrevenni.

Kifejtenéd?
- A program a memóriában fut, teljesen mindegy hogy honnan lett betöltve. Miért befolyásolná a sebességét, az, hogy SD-ről, HDD-ről, vagy SSD-ről tölti be a programot?
- Miért csak transmissionnál nincs difi?

Freeware, és akciós programok egy helyen https://www.facebook.com/freewarenews

"befolyásolja a torrent sebességét" volt a kérdés.
Bár abban egyet értek, mint most is kiderült nem egyértelmű a kérdés. Én a letöltési sebességet, te a program betöltését értetted a kérdés alatt.

Igen, a letöltési sebességre voltam kíváncsi. A netem tényleg 1 Gbit és qbittorrentet fogok használni (eddig is az ment csak más eszközön). Köszönöm a válaszokat!

1Gbit ugyebár 128MB/sec, ennyivel nem fog tudni sd-karira cache-elni a progi (ha csinál ilyet egyébként), de normál írni se.

Ha megvannak a hozzávalók, én kipróbálnám pár tuti gxorsan jövő cuccal, hogy mennyivel jönnek pc-n és mennyivel egy full alap sd-kari pi-n.

[ Szerkesztve ]

30€ Meta store bónusz Quest headset aktiváláshoz, keress priviben :)

Transmission letöltési sebessége olyan 20MB/s körül megáll, ugyan azon a PI4-en, qBittorrent tudja fixen a 60MB/s-et HDD-vel.
Cserébe viszont a qBittorrenthez egy normális remote appot nem találtam még, kezeli több app is úgy ahogy.

Találtam egy érdekes beta-t a raspberry oldalán, de hiába csináltam frissítést, a mappákba nem került bele. Hol kéne keresni?

2020-07-31 Standardize USB port power control accross board revisions - BETATurn off USB port power for 1-second regardless of boot-mode. This appears to resolve an issue on R1.3 and older board revisions where some USB devices would fail upon reboot. On R1.4 USB port power is turned off automatically by the PMIC so this is just held in reset for longer. For earlier board revisions the USB port power is explicitly turned off via XHCI. This can be overriden via USB_MSD_PWR_OFF_TIME in the EEPROM config.Update to the latest Broadcom memsys FW - no significant functional change.

Organic Maps - ingyenes, offline navi iOS-re és Androidra.

Kifutottam az időből, szóval...

Érdekes, hogy találtam ki be kapcsoló gombra alíg egy-két hónapos leírást, scriptel, de ehhez képest a bootloaderes leirasban meg azt olvasom,hogy a gpio3-t gndvel összekötve bekapcsol. És tényleg...

Organic Maps - ingyenes, offline navi iOS-re és Androidra.

Tehát ismét jelentkezem -- eltelt némi idő, és a Raspbian HDMI-kimenetén nem jelenik meg olyan jel, amit a tévé képként értelmezne. "HDMI - nincs jel".

Ezt ugye pár nap/hét után rendszerint eljátssza.

SSH-n elérem, és a tanácsodra kiadott parancs eredménye a következő:

Tuning nincs, a videomemória 256 MB (RPI2).

Köszönettel: MaCS

Fán nem lehet motorozni, motoron viszont lehet fázni!

Próbáltad a config.txt-ben a "hdmi_force_hotplug=1" beállítást?

Illetve a hdmi_group= és hdmi_mode= megadását?

"...találtam ki be kapcsoló gombra alíg egy-két hónapos leírást..."

Ez így szerintem félrevezető: inkább hívnám magyarul program-leállítónak, -elindítónak, mint bekapcsoló gombnak, ugyanis a PI-k kiegészítő hardver nélkül nem tudják kikapcsolni magukat, mint egy PC (nincs ACPI-hez hasonló áramkörük). Olyan keveset fogyasztanak, hogy állandó üzemre vannak tervezve.

Érdekes: visszakerestem és annak idején a ZX Spectrumnak sem volt kapcsolója :-)

Hasonló volt nálam is. Kicseréltem a hdmi csatit (átalakítót) egy minőségibb darabra és "megjavult"

Mindenkit egyforma külső inger ér, de egyén függő, h éljük meg :P

Erre valaki?

Organic Maps - ingyenes, offline navi iOS-re és Androidra.

milyen mappába nem kerül mi?
sudo apt update
sudo apt full-upgrade
sudo rpi-eeprom-update (így nézed meg van e frissebb verzió)
sudo rpi-eeprom-update -a (ez kell az eeprom frissítéshez)

és végül egy reboot

Sziasztok,

egy rpi3-ason 6.1-es PiCorePlayert használok(nék) egy újraindítást követően azonban nem lehet erlérni a hálózaton. Fizikai link van az rpi hálókártyáján, a TV-re kötve, parancssorban nézelődve azonban látszik, hogy nem kapott ip-t, és a setup parancsot pedig nem lehet lefuttatni, hogy újra beállítsam pl a hálózatot.

Tönkremehetett az sd kártya, (nem létezik a pcp mappa a kért útvonalon)?

Csak egy tipp:
Ne vegyetek aliról filléres, kapcsolható USB kábelt...
- Gondoltam, ha már nincs a PI-ken kapcsoló, és néha azért lelőné az ember, jó megoldás lesz egy ilyen: [Kábel]
Hát sajnos nemy nyert, akkora ellenálása van a kapcsolónak, hogy a 60W-os töltő is csak 4.8V max 0,7A -tud átpréselni rajta, szóval hiába van fasza töldőd, kábeled, emiatt már villám ikont dobál a Pi.
Ugyanitt kapcsolós USB kábel eladó

#Raspberry #Orangepi #HassOS #Esp32

Valóban előfordulhat, hogy nagy az ellenállása. Viszont esélyes, hogy az a "60W-os" töltő (5v 12A??) valóban ki akarna adni nagy teljesítményt. Az okos töltők általában valamilyen kézfogással vagy legalább ellenállásokkal megadott terhelés értékek szerint adnak áramot. Szóval hiába van hűdeerős tápod, ha a pi buta tápcsatlakozójával nem tud kommunikálni és ezért 500mA-t ad ki mondjuk, mert az a szabványos usb2-es mód, vagy esetleg 900mA-t ha usb3-as terhelésre céloz.

Ez például pont lehet azért, mert az adatlábak nincsenek bekötve a kapcsolón. Így nem tud kézfogást csinálni és se a Pd se a QC nem tud működni, így visszavált buta és biztonságos, kisteljesítményű módra. A régi pi-khez kifejezetten mondták, hogy buta töltő kell. Az újabbaknál, ahol már chip-ben van a betáp kezelése, nem tudom van-e kézfogás.

A pi4 első szériánál viszont kifejezetten mondták, hogy nem működik a nagyobb teljesítményű typec töltőkkel, mert rosszul implementálták. Szóval az is buta töltővel biztos, okosból meg van amelyik laptop töltővel sem működik. Plusz a pi4-nél pont a butább, nem szabványos type-c kábellel esélyesebb a működés. Neked gondolom korábbi fajta van, nem pi4, mivel a kapcsoló sem type-c.

Sziasztok!

Raspbian van a 3B+-omon. Van rajta Kodi is. Egész jól működik, de ha a Kodi fut és kikapcsolom a TV-t, akkor magátol vissza-vissza kapcsolgatja... Fut még Home assistant is a gépen, amivel tudom kapcsolgatni a tv-t, bemenetet váltogatni, de az mindig fut. Kifejezetten Kodi futása esetén kapcsolódik be véletlenszerűen a TV. Valaki tudja mitől lehet?
Köszi!

Mico végű kapcsolós kábelem van aliról, simán gyorstölti a cuccaimat. Sajna végponti feszmérő kütyüm nincs hozzá, és micro-ra már nem is veszek. Egy c-s végű kábel úton van, esetleg c-n mérő kütyüt nézek valahol.

#38924: noigen, ha nincs meg a stabil 5.0+V/2A páros a valóságban, akkor cseszheti az ember a 40-60-100W-os csudákat. Azok a számok 20V-on értendők.

[ Szerkesztve ]

30€ Meta store bónusz Quest headset aktiváláshoz, keress priviben :)

"... Kodi futása esetén kapcsolódik be véletlenszerűen a TV. Valaki tudja mitől lehet?"

A HDMI kábelen nem csak a video és a hang megy át, hanem egy CEC-nek nevezett protokoll is működik a TV és a PI között (beszélgetnek). Ezt a CEC-et kell a Kodiban és/vagy a config.txt-ben letiltani.

Köszönöm -- logikus, de nálam most nem ez a gond. Volt pár keresztpróba és jelenleg egy pofátlanul drága HDMI-kábellel is szívat.

Holnap jön fa4hu ajánlásának kipróbálása!

Köszönettel: MaCS

Fán nem lehet motorozni, motoron viszont lehet fázni!

Nem lehet, hogy téged is a CEC szivat?
Pl 1. a TV alvásba megy és ezt "közli" a Pi-vel, ami erre kikapcsolja azt a HDMI-kimenetet
Pl 2. Bekapcsol a Pi, megkérdezi a TV-t "mi van veled": erre az, a CEC-en keresztül "ki vagyok kapcsolva" választ adja, erre a PI nem kapcsolja be azt a HDMI kimenetet

[ Szerkesztve ]

Könnyen lehet, bár tudtommal a tévén nincs CEC.

Köszönettel: MaCS

Fán nem lehet motorozni, motoron viszont lehet fázni!

Nem mindig nevezik így, nekem egy kb.15 éves ősrégi Philips TV-m van és már itt is le kellett tiltanom a config.txt-ben a CEC-et mert néha bekavar

Ez kell neked [link]

Lassú a mobilinterneted? 4G/LTE antennák, közvetlenül raktárról ---> http://bit.ly/LTE_Antennak

Üdv !
Hogyan lehet módosítani a Raspbian-nak (vagyis pontosabban most már Rasberry Pi OS-nek) a hálózati idő szinkronizációs beállításait ?
Még jobb lenne, ha valamilyen formában tudnék róla, hogyha módosítás történt a rendszeridőn.
Olyan python programkódot írtam, ami jó pár dolgot a rendszeridőt felhasználva csinál (lekérdezem a time.time()-al, és úgy mérem hogy épp mennyi idő telt el).
És ha futás közben megváltozik a rendszeridő, az adott esetben okozhat kavarodást a működésében.
De teljesen letiltani se akarnám, mert az nem lenne rossz ha induláskor egyszer lekérdezné (ha tudja), ha ez viszonylag gyorsan lefut.

Pontosan mire jó ez a kapcsolós USB kábel? Értem én hogy áramtalanítsa a Pi-t, de attól a tápegysége még a 220-ban marad. Ugyanúgy fogyaszt, adott esetben felgyújtja a házat. Miért nem a 220-as ágat kapcsoljátok le?!

atesss
A script elejére letiltod a szinkronizálást
sudo timedatectl set-ntp false
A végén pedig engedélyezed
sudo timedatectl set-ntp true

[ Szerkesztve ]

Freeware, és akciós programok egy helyen https://www.facebook.com/freewarenews

Hasznalhatod a monotonic funkciojat a time-nak (python), a rendszerido valtoztatasa nincs hatassal a monotonic idore, amelyik meri hogy a bekapcsolas ota mennyi ido telt el [link]
time.monotonic() → float
time.monotonic_ns() → int
Ez eleg preciz. "The clock is not affected by system clock updates."

Viszont ha az ujrainditast kell tulelnie az idobelyegnek akkor alternativakent lehet hasznalni az eltelt idot 1970-ota UTC Epoch
Ez bevett szokas ezt hasznalni hogy log-okban, vagy vezerlesre ezt hasznaljak. Nem hiszem hogy a rendszerido sokat ugralna...

[ Szerkesztve ]

HP ZBook Workstation A3000 - Linux Mint; Raspberry Pi4 - Raspbian

Igen, van olyan része is a kódnak, aminél a pontos idő a fontos.
Jól mondtad, ez a log, a releváns része így néz ki most a programomnak:
import time
from time import localtime, strftime 
...
# MAIN függvény
                TimeStamp_Failure_Left = strftime("%Y-%m-%d %A %H:%M:%S", localtime())
                print("A hiba ideje: ", TimeStamp_Failure_Left)
                with open(LOG_PATH, "a") as logfile:
                    logfile.write(TimeStamp_Failure_Left)
                  logfile.write('  -  Hiba az A motornal (LEFT) \n')

Hát annyi, hogy viszont egyelőre - Pi elindulásakor - a rendszeridő beállításához szükség van a netes szinkronizációra. (Van ugyan RTC modulom, de nem nagyon akarnám használni, csak ha nagyon muszály.)
De később meg ha már fut a Pi, felesleges.
Bár ok, elvileg ekkor nem is kellene már ugrálnia.

[ Szerkesztve ]

Ezt akkor valahogy így kellene a Python scriptembe írnom ?os.system("sudo timedatectl set-ntp false")
Ha kilépek a python scriptből (pl most még a tesztelésnél, Ctrl+C-vel), akkor ez hogyan áll vissza ?
Ha valami ilyesmi van a main ciklusban ?
except KeyboardInterrupt:
    GPIO.cleanup()
    os.system("sudo timedatectl set-ntp true")

Ja és igen, most én is ezt az Epoch-os megoldást használom - a log kivételével mindenhol.
Pl. a legegyszerűbb ezek közül egy a kód működését/futását jelző ledet villogtató függvényem. Bár ugye ez pont nem annyira kritikus dolog, de most önálló példaként ezt tudtam egyszerűen leírni.
SLOW_CYCLE_TIME = 1
slow_time_previous = 0
def run_flasher():
    global run_led_state
    GPIO.output(RUN_LED, run_led_state)
    run_led_state = not run_led_state
...
# MAIN függvény
        slow_time_elapsed = time.time() - slow_time_previous
        if slow_time_elapsed > SLOW_CYCLE_TIME:
            slow_time_previous = time.time()
            run_flasher()    

[ Szerkesztve ]

Mi van a bash scriptből indítod a Python programodat
#!/bin/bash
sudo timedatectl set-ntp false
python3 program.py
sudo timedatectl set-ntp true

Freeware, és akciós programok egy helyen https://www.facebook.com/freewarenews

Hat, megmondom oszinten en pont forditva hasznalnam, time.monotonic-ot preciz vezerlesre mert az soha nem ugral, UTC epoch-ot a log-oknal mert arra soha nincs hatassal a teli-nyari idoszamitas ugralasa.

Magyarazat:
Elvileg, a monotonic ido az minden rendszeren a CPU ora tick-jeit meri, igy az fuggetlen az aktualis idotol.
UTC Epoch pedig jo arra hogy nagyobb idotavlatbol viszonylag pontos osszehasonlitasokat vegezzunk.

[ Szerkesztve ]

HP ZBook Workstation A3000 - Linux Mint; Raspberry Pi4 - Raspbian

Igen, ez jogos.
De a #38936-ben írt kódomban [link] az
strftime("%Y-%m-%d %A %H:%M:%S", localtime())
nem az Epoch-ot használja alapként ?
Azzal a különbséggel, hogy az oprendszer localisation -jét is beleszámolja, azaz - ha be van állítva a Magyarország - akkor mindig a megfelelő időzónában van, és állítja az időszámítást is. Így mindig a pontos helyi időt kapom.
"nagyobb idotavlatbol viszonylag pontos osszehasonlitasokat vegezzunk."
Nekem első körben arra kellhet a log, hogy tudjam mikor történt a hiba, össze tudjam hasonlítani a kamerák képével (ezt másodperc pontosan), tudjak beszélni az épp akkor dolgozó kollégával, stb. És ugye ő is a saját óráján ezt az időt "használja".
Második körben meg statisztikára (milyen gyakran fordult elő hiba összesen, pl. egy hónap alatt, illetve volt-e olyan hogy egy óra alatt nagyon sokszor).

Az időszámítás miatti ugrálás viszont bizonyos esetekben tényleg gond lehetne...
Viszont az átállás ideje, az éjjel 3 óra az én esetemben abszolút üzemidőn kívül van, úgyhogy ez nem lesz gond most nekem.
Mondjuk máshol a LOG-ba lehet be kéne írni azt is, hogy egy óra-átállítás történt.

time.monotonic() → float
time.monotonic_ns() → int
A felsőt én az eddigi time.time()-omhoz hasonlóan tudnám használni ?
Annyi, hogy jóval kisebb értékekről van szó. De a rendszerindítás után egy 15-20 sec úgyis biztosan el fog telni, mire elindul a python scriptem.
Mondjuk ezt akkor át kell gondolnom, mert asszem van ahol úgy adtam meg egy kezdeti értéknek (a program-induláskor) a time.time() visszatérési értékét, hogy az "Úgyis jó nagy lesz", és így - amíg nincs külön esemény, ami módosítaná ezt a változót - addig a "Jó nagy" miatt biztosan nem lesz igaz az egyik if szerkezetem.

[ Szerkesztve ]

"az Epoch-os megoldást használom - a log kivételével mindenhol."
Csak erre reagaltam hogy logra teljesen jo a localtime(), ha az eszkoz mindig 1 beazonosithato helyen marad. Nalunk a cegnel a termekek naploinal mindig UTC idot hasznalunk, igy barmely foldreszen nezik meg a naplot, nincs kavaras es atszamolas (termek USA-ban naplozott valamit, szerver svedeknel van + nyari/teli)

time.monotonic() erteket ugyanugy tudod a time.time()-hoz hasonloan osszehasonlitani elozo ertekkel. En biztonsagosabbnak erzem, kivedhet par megmagyarazhatatlan esemenyt.. hacsak letiltod az ora szinkronizalast, ahogy cigam javasolta.

[ Szerkesztve ]

HP ZBook Workstation A3000 - Linux Mint; Raspberry Pi4 - Raspbian

Gondolom manapság is a fake hardware clock csomagot használják az idő kezelésére. Az úgy működik, hogy kikapcsoláskor elmenti az utolsó ismert időt és újraindításkor alapból azzal indul a rendszer elvileg. Utána, a netről beszinkronizálja frissre.
A lényeg, hogy sosem jár visszafelé az óra, mindig csak előre halad így.

Másrészt óraátállítások is vannak és ha jól csináltad, akkot utc idővel dolgozol, nem pedig helyi idővel, ami évente kétszer urál és egyszer még visszafelé is megy.
Érdemes lenne átgondolnod, hogy jól kezeled-e az időt a programodban, mert gyanús, hogy nem. Bár rákeresve a python leírásban, lehet utc-t használ az a függvény is.

A másik lehetőség, hogy szimplán veszel valami filléres hardver órát és bekötöd a pi-re egy gombelem társaságában.

szerk: tovább olvasva lehet nem is az a probléma, amire vissza szeretnéd vezetni. Csak egy tipp, de lehet rosszul fogod Nem a rendszerórára kellene alapozni a feladatodat, hanem megszakításkezelés vagy a broadcom pwm-re vagy valami más, a célra való megoldásra és nem újra feltalálni a spanyolviaszt. Nameg nem végtelen ciklussal vagy rekurzióval kellene

Amúgy igen, látom, hogy a bemutatkozó példákban sokszor sleep meg hasonló nagyon egyszerűen érthető megoldásokat használnak, de komolyabb feladatokra túl kell lépni ezeken.

[ Szerkesztve ]

"hogy kikapcsoláskor elmenti az utolsó ismert időt és újraindításkor alapból azzal indul a rendszer elvileg"

Az én gyakorlati tapasztalataim alapján így működik a Raspberry.
"Másrészt óraátállítások is vannak és ha jól csináltad, akkot utc idővel dolgozol, nem pedig helyi idővel, ami évente kétszer urál és egyszer még visszafelé is megy."
Igen, ez tényleg okozhat bizonyos esetekben problémát. Sőt, igazából a programozási esetek döntő többségében tényleg jobb az UTC, ez jogos.
De most nálam, ha gyakorlatban a #38941-ben írt felhasználása van a log-nak, akkor én úgy érzem hogy pont hogy jobb ha nem UTC időt használom. És így rögtön a szemem előtt az az időpont szerepel, amivel a többi dolgot össze tudom hasonlítani.

Vagy - ha valamiért lényeges a helyi idő is - ti hogyan szoktátok azt fejben tartani ? Vagy egyszerűen kiszámolni ?
Mentsem le a fő logban mindkét időt ?
Vagy egy ilyen esetben ez hogyan lenne célszerű ?

"A másik lehetőség, hogy szimplán veszel valami filléres hardver órát és bekötöd a pi-re egy gombelem társaságában."
Hát, igazából van is. Konkrétan több darab ilyenem van: [link]
Sőt, - ehhez a projekthez - a nyákon meg is van már neki a hely, és a modulon át is forrasztottam a tüskéket derékszögűre, így be is dugható.
De ez most igazából egy teszt lenne, hogy mennyire kell a HW-es RTC. A későbbiekben lesz remélhetőleg több olyan projektem is, ahol nem lesz nyák az RPI-hez, így a HW-es óra körülményesebb és drágább. Nem lenne a GPIO-ra csatlakozó nyák, meg még egy - amúgy jó drága - HAT RTC modul se nagyon férhet el egy standard RPI házban, stb.
És most jelen esetben elég megbízható netkapcsolata lesz az eszköznek. Nem is egy otthoni/kisvállalati, hanem egy bérelt vonali kapcsolatról kapja az RPI a netet, fixen kábelen.

MOD:
"A lényeg, hogy sosem jár visszafelé az óra, mindig csak előre halad így."
Igen, ezt én is így sejtettem.
De ez is okozhat problémát.
Pl. van egy folyamatom, aminek megadok egy kívánt időtartamot. Legyen ez mondjuk 4 perc (240 sec). Ha a folyamat indítása előtt nem sokkal történt pl. egy rövid áramszünet (esetleg véletlen áram-lekapcsolás, stb.), akkor lehet hogy a rendszeridő már a folyamat futása közben frissül (növekszik). Így a végén a 240 sec-ből lesz aztán valami sokkal kevesebb.

[ Szerkesztve ]

műveletvégzéshez utc, de nem a leírt dátumra gondolok, hanem timestampre vagy más olyan reprezentációra amit használni lehet. A megjelenítés vagy kiírás pedig, ha oda helyi idő kell, akkor arra szokott lenni függvény, ami kiadja magából olyan, emberi fogyasztásra alkalmas formában.

De úgy általában, azt javaslom, hogy amikor a feladat megoldását akarod kitalálni, akkor ne a végétől állj neki, hogy a kakukkos órából kiszámolsz valami pici időkülönbséget. Hanem úgy a végcélből indulj ki és tedd fel a kérdést (akár a google keresőnek), hogy pythonban és raspi hardveren milyen létező megvalósításokat használhatnál fel rá.

Például, ha neked 1 másodpercenként kell csinálni valamit, akkor nem a kakukkos órát kell nézegetni gyakran, hanem konkrétan egy másodpercenként kellene történni valaminek. Nem foglalkoztam sokat pythonnal, de google kidobta, hogy van valami interrupt kezelés benne, ami callback függvényt hív meg, amikor esemény van.

Szóval nem azt mondod, hogy végeten ciklusban nézegeted az órát, hanem megmondod neki, hogy 1 másodpercenként történjen a végrehajtás és adott függvény végezze akkor el. Csak valami véletlen találat példának [link]
Ne tévesszen meg, hogy belül megint meghívja magát. Ott valójában azt mondja, hogy x idő után melyik függvény fusson le. Csak mivel egy következő esetet kezel, így ezért a függvény álítja be a következő időpontra. De lehet van interval vagy hasonló nevű megoldás is (mint javasciptben), ahol nem egyetlen, hanem leállításig minden egyes x idő elteltében való futtatást lehet beállítani.

Az áramszünetre: az már egy teljesen más probléma és gondolom most sem tudod lekezelni. Oda már valami nyilvántartás kell (adatbázis), hogy mi történt meg és ha késik, akkor megtörténjen -e és ha igen, akkor mikor. Az a másik véglet, ha mindenre is jó megoldást akarsz, annak sem szokott lenni jó vége

Egyébként újraindulásnál érdemes azt is megnézned, hogy mikor történik az óra netes szinkronizációja. Hogy előtte elindul-e a szolgáltatásod. Egyébként systemd óta úgy emlékszem külön érdemes megadni a raspbianon, hogy várja meg a szolgáltatások indításával a netkapcsolatot. Mert anélkül ész nélkül elindít minden szolgáltatást és például hálózati meghajtók felcsatolásával is problémák vannak. Még a raspi-config utilba is tettek erre beállítást azt hiszem, szal elég lehet ott beállítani, hogy várja meg a netet.

A saját szolgáltatásodnak meg lehet függősége egy másik, példál olyasmi, ami az óra szinkronizációt elvégzi. Amíg az nem végzett, addig a tiedet nem indítja.

[ Szerkesztve ]

Nekem valamikor 12V-os tápról megy a cucc és a 12->5v konverter 5V-ját alkalmasint másra is tervezem használni.

30€ Meta store bónusz Quest headset aktiváláshoz, keress priviben :)

Lejárt a szerk idő:
De 230V-os rendszerben is el tudok hasonlót képzelni, egy combosabb többágú mobiltöltő, ami egy rakat egyéb cucc mellé van dugva az elosztóba, etethet még egy telefont is, pláne ha a pi ki van kapcsolva. És ha van egy kapcsoló akkor nagyon egyszerű az újraindítás.

Elgondolkoztam, hogy vajon az extra hosszú, pl 3m-es kábeleken mennyi feszültség eshet?

30€ Meta store bónusz Quest headset aktiváláshoz, keress priviben :)

"A megjelenítés vagy kiírás pedig, ha oda helyi idő kell, akkor arra szokott lenni függvény, ami kiadja magából olyan, emberi fogyasztásra alkalmas formában."
Akkor ezzel a függvénnyel az alapból UTC-ben kiolvasott TimeStamp-ot alakítsam át ?
Most a konkrét esetben amúgy nem végeznék semmilyen műveletet vele, csak kiírnám a log-ba a már részletezett célokra.
De amúgy arra jó lehet az UTC használata, hogy akkor ezt a megoldást szokom meg már most. És így írom meg a kezelő-függvényeimet, amit akkor később - amikor már tényleg kell is az UTC - egyszerűbben újra tudok hasznosítani/ ismét fel tudok használni.

"Szóval nem azt mondod, hogy végeten ciklusban nézegeted az órát, hanem megmondod neki, hogy 1 másodpercenként történjen a végrehajtás és adott függvény végezze akkor el. "
Igen, ez teljesen jogos.
Annó Atmega-n használtam Timer Interruptokat. És nem a - HW-es működést elég komolyan elfedő - mostanában nagyon népszerű Arduino alatt, hanem a gyári IDE-vel (akkoriban még AVR Studio-nak hívták), közvetlen a regiszterek bitjeit címezve. Sőt, asszem még AVR-assembly alatt is használtam timereket.
Viszont mivel úgy tudom hogy a Raspberry Pi ilyen szempontból elég gyenge ehhez képest, így első körben nem erőltettem a Timer Interruptot.
(Lehet kivétel ha valami RealTime OS-t rakok fel rá, de ahogy sejtem az RTC hiánya miatt még az alatt sem lesz teljes értékű.)
De persze nem lenne rossz, csak kérdés mennyire bonyolult használni. Illetve ezekre a feladatokra még oké lesz, ledet villogtatni, meg ADC-t átlagolni.
De kicsit valamiért úgy érzem, hogy - bizonyos szempontból - hiába tanulnám meg. Mivel amit te írtál, hogy:
", de komolyabb feladatokra túl kell lépni ezeken."
Az a sejtésem, hogy bizonyos komolyabb feladatokra, ahol pontosabb időzítés kell, oda meg mégsem lesz elég ez sem.

"Az áramszünetre: az már egy teljesen más probléma és gondolom most sem tudod lekezelni. Oda már valami nyilvántartás kell (adatbázis), hogy mi történt meg és ha késik, akkor megtörténjen -e és ha igen, akkor mikor."
Jó igen, ha olyan a feladat, hogy ez fontos, akkor ilyen eseteket tényleg csak így lehetne profin. De most erről azért nincs szó.
Itt nem arról van szó, hogy az áramszünet befolyásolt-e valamit. Hanem szimplán csak arról, hogy az áramszünet okán a Raspberry órája kicsit elállítódott. És ha pont akkor áll vissza a pontos idő, amikor a scipten belül fut valamilyen, a rendszeridőt kalkulációnak használó függvény, akkor ezt a függvényt az óra-átállítás "eltérítheti".

"Egyébként újraindulásnál érdemes azt is megnézned, hogy mikor történik az óra netes szinkronizációja. Hogy előtte elindul-e a szolgáltatásod."
Igen, már a téma-indító hsz-emben is feltettem ezt a kérdést. Hogy hogyan lenne arról információm, hogy egy netes idő-szinkronizáció történt.
cigam ötlete közvetlenül ezt nem oldja meg, mert azzal csak letiltani tudnám meg engedélyezni a funkciót. De arról nem lenne információm, hogy egy rendszerindulás után megtörtént-e a "kezdeti" szinkronizáció.

"Egyébként systemd óta úgy emlékszem külön érdemes megadni a raspbianon, hogy várja meg a szolgáltatások indításával a netkapcsolatot."
Egyrészt: az internet-csatlakozás, és a hálózati idő-szinkronizáció megtörténte nem feltétlenül esik egybe.
Másrészt: azért ha esetleg nincsen net, attól még nem lenne rossz ha elindulna a scriptem.
Vagyis akkor be kéne rakni ide egy plusz timeout-ot is, hogy ha nincs netkapcsolat x idő után sem, akkor viszont indítsa el a scriptet, ne várjon a végtelenségig.

[ Szerkesztve ]

Akkor viszont ha az 5V-os oldalon akarsz kapcsolni, akkor itt a feszültségesés miatt valami normálisabb kapcsoló kell. Abba a kínai kapcsolós kábelbe minden bizonnyal az elérhető leggagyibb kapcsolót rakták bele...
Nekem is volt ilyesmi kábeles kapcsolóm. Egyik fele 5,5/2,1-es DC aljzat másik fele dugó, közte a kapcsolóval. Használhatatlan volt, már 12V-on is olyan feszültségesést produkált némelyik infrás analóg CCTV kamerával, hogy szakadozott a képe.

A 3m-es kábelnél már tényleg nagyon nem mindegy milyen minőségű. Mennyire vastag benne a réz.
Én mértem be annó microUSB kábeleket. Direkt pont Raspberry-vel való használatra. Volt egy olyan - minőségi, márkás, nagyobb magyar informatikai boltból beszerzett - 3m-es kábelem, amin a hosszához képest abszolút nem volt nagy a feszültségesés. Jobb volt mint némelyik ránézésre is gagyi 50-70cm-es...

Közben rájöttem hogy az én függvényem ezt az időkonvertálást már nagyjából így is csinálja.
# Time in RFC 2822 Internet email standard: strftime("%a, %d %b %Y %H:%M:%S +0000", gmtime())
# Magyar formátum szerinti: strftime("%Y-%m-%d %A %H:%M:%S", localtime())
Vagyis akkor jól gondolom hogy az alsó sor függvénye is az UTC időt számolja alapból, csak a végén csinál egy formázást, és a localtime-os formátumban írja ki (időzóna, időszámítás-t beleszámolja) ?