Orange Pi Plus 2e
-
Hoffe, ich habe einen richtigen Thread erwischt.
Ich habe mir auch einen Orange Pi Plus 2e bestellt (dachte ich zumindest).
Nun habe ich ein Problem mit dem Funkmodul und der Anleitung (ReadME im Downloadbereich der Firmware).
Das Funkmodul wollte ich auch nach innen drehen, ein Foto ist ja in der ReadMe dabei.
Allerdings weicht meine Beschaltung des Pi dann mit der vom Foto ab (z. Bsp. Spannungsversorgung, SD-Schacht).
Ich bin nun ein wenig ratlos, kann ich den OPi trotzdem so mit dem Funkmodul bestücken ?
-
Du musst aufpassen ob du einen plus2e
https://homematic-forum.de/forum/viewto … ex#p404285
Oder nur einen plus2
https://homematic-forum.de/forum/viewto … 20#p405503
(???)
Woran machst du fest, dass es bei dir anders ist?
Auf deinem Bild kann man nix erkennen.
Gruß Rainer
-
Allerdings weicht meine Beschaltung des Pi dann mit der vom Foto ab (z. Bsp. Spannungsversorgung, SD-Schacht).
Ich bin nun ein wenig ratlos, kann ich den OPi trotzdem so mit dem Funkmodul bestücken ? `
Das Bild aus der Readme (das untere Bild in der Readme) sieht nicht nach einem Orange Pi Plus 2e aus. Dein Bild sieht nach einem OPi Plus 2e aus. Es sollte also funktionieren. -
OK, Danke.
Dann gehe ich von einem fehlerhaften Bild in der Beschreibung aus und arbeite mich ein.
-
:shock: da hast du wahrscheinlich recht :shock:
Ich war mir sicher nur eigene Fotos im Readme verwendet zu haben.
Das untere scheint jedoch von @deimos zu sein, :oops: sorry
Wenn ich die Beschriftung richtig lese ist es ein Opi One.
Ich werde das Foto schnellstmöglich austauschen.
EDIT:
Habe pragmatisch den Text angepasst
Gruß Rainer
-
Hallo,
ich habe nach dieser (und anderen) Anleitungen mein iobroker System am letzten WE von einem Banana Pi mit SATA SD auf den orange Pi umgezogen.
Ging schneller als erwartet und läuft soweit gut und schnell.
Jetzt hat die Kiste allerdings schon zweimal einen teilweise Neustart hingelegt. Immer spät Abends - Nachts. Im iobroker log steht vor dem "Hänger" nichts und im syslog wird nur der Neustart vermerkt. Allerdings fährt der Orange auch nicht sauber komplett hoch. Ich komme dann auch nicht per ssh drauf und muss erstmal den Stecker ziehen. Dann läuft alles wieder sauber an. Deshalb glaube ich auch nicht an ein Netzteil Problem.
Memory und Temperatur logge ich über den opi Adapter. Sieht auch ok aus.
Hat noch jemand einen Ansatzpunkt für mich?
Gruß
Holger
-
ja, eben das Netzteil tauschen…. Ich hatte auch seltsame Probleme, die Adapter haben ständig die Verbindung verloren, die Kiste schmierte auch des öfteren weg, und ein Neustart dauerte ewigkeiten... Ich habe das Teil mehrmalls neu aufgesetzt, die Speicherkarten getauscht und und und... bis das Netztei getauscht war!
-
ja, eben das Netzteil tauschen…. Ich hatte auch seltsame Probleme, die Adapter haben ständig die Verbindung verloren, die Kiste schmierte auch des öfteren weg, und ein Neustart dauerte ewigkeiten... Ich habe das Teil mehrmalls neu aufgesetzt, die Speicherkarten getauscht und und und... bis das Netztei getauscht war! `
Und was für ein Netzteil nimmst du? Bitte nix zum Löten
Danke und Gruß
Holger
-
und muss erstmal den Stecker ziehen. Dann läuft alles wieder sauber an. Deshalb glaube ich auch nicht an ein Netzteil Problem. `
Dieser Argumentation würde ich nicht so ohne weiteres folgen. Ein Spike in der Versorgung kann eine andere Wirkung haben als ein richtiger Reset.Hinweis Nummer eins in der armbian Hilfe geht in Richtung Stromversorgung.
Wie sieht die bei Dir aus?
Gesendet von meinem ZTE A2017G mit Tapatalk
-
und muss erstmal den Stecker ziehen. Dann läuft alles wieder sauber an. Deshalb glaube ich auch nicht an ein Netzteil Problem. `
Dieser Argumentation würde ich nicht so ohne weiteres folgen. Ein Spike in der Versorgung kann eine andere Wirkung haben als ein richtiger Reset.Hinweis Nummer eins in der armbian Hilfe geht in Richtung Stromversorgung.
Wie sieht die bei Dir aus?
Gesendet von meinem ZTE A2017G mit Tapatalk `
Stecknetzteil 3 Ampere.
Aso, was ich vergessen habe. Der Orange lief vor dem Umzug vom iobroker hier schon ne Woche im "Testbetrieb". Auch schon mit einer iobroker und mysql Installation aber quasi ohne "Last". Und ohne "Hänger"…
Danke
Holger
-
https://www.pollin.de/p/stecker-schaltn … -mm-351836
Damit läuft mein Reserve Opi stabil aber im Leerlauf. Die produktiven sind gelötet.
Gesendet von meinem ZTE A2017G mit Tapatalk
-
Habe jetzt mal meinen Reserve-OPi etwas unter Stress gesetzt:
root@opi2e_reserve:~# sysbench --test=cpu --cpu-max-prime=20000 run --num-threads=$(grep -c '^processor' /proc/cpuinfo) sysbench 0.4.12: multi-threaded system evaluation benchmark Running the test with following options: Number of threads: 4 Doing CPU performance benchmark Threads started! Done. Maximum prime number checked in CPU test: 20000 Test execution summary: total time: 107.1690s total number of events: 10000 total time taken by event execution: 428.6157 per-request statistics: min: 41.97ms avg: 42.86ms max: 62.63ms approx. 95 percentile: 45.35ms Threads fairness: events (avg/stddev): 2500.0000/0.71 execution time (avg/stddev): 107.1539/0.01 root@opi2e_reserve:~# armbianmonitor -m Stop monitoring using [ctrl]-[c] Time CPU load %cpu %sys %usr %nice %io %irq CPU C.St. 18:04:29: 1296MHz 3.68 74% 0% 74% 0% 0% 0% 49.6°C 0/9^C 18:04:34: 1296MHz 3.38 0% 0% 0% 0% 0% 0% 48.5°C 0/9^CBetrieben mit dem o.g. Netzteil und einem provisorischen Inbetriebnahmekühlkörper. Läuft stabil durch.
Jetzt läuft gerade ein zehnmal solanger Test
-
Der längere Test ist jetzt auch durchgelaufen:
root@opi2e_reserve:~# sysbench --test=cpu --cpu-max-prime=200000 run --num-threads=$(grep -c '^processor' /proc/cpuinfo) sysbench 0.4.12: multi-threaded system evaluation benchmark Running the test with following options: Number of threads: 4 Doing CPU performance benchmark Threads started! Done. Maximum prime number checked in CPU test: 200000 Test execution summary: total time: 2998.5967s total number of events: 10000 total time taken by event execution: 11991.7728 per-request statistics: min: 1092.78ms avg: 1199.18ms max: 1327.39ms approx. 95 percentile: 1283.16ms Threads fairness: events (avg/stddev): 2500.0000/1.00 execution time (avg/stddev): 2997.9432/0.38 root@opi2e_reserve:~#Stabil überstanden und läuft noch immer stabil.
-
Hallo,
nachdem ich jetzt mehr logge und auch besser beobachte, tippe ich doch eher auf ein schleichendes Speicherproblem.
Hier mal die Grafik von opi:
Und hier der aktuelle Verbrauch der einzelnen Prozesse:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1188 root 20 0 187576 85664 17332 R 25.2 4.2 134:52.60 iobroker.js-con
817 mysql 20 0 644716 81760 11988 S 0.0 4.0 10:28.31 mysqld
1383 root 20 0 166768 67008 16956 R 3.3 3.2 34:13.80 io.javascript.0
1210 root 20 0 153848 53724 16940 S 0.3 2.6 3:18.22 io.admin.0
1411 root 20 0 147372 48972 17592 S 0.0 2.4 2:48.42 io.telegram.0
1245 root 20 0 147004 48924 17808 S 3.6 2.4 53:51.94 io.sql.0
1263 root 20 0 145324 44772 16984 S 0.3 2.2 7:41.39 io.web.0
1614 root 20 0 134640 44288 17064 S 0.0 2.1 4:22.30 io.opi.0
564 root 20 0 362204 44044 9628 S 0.3 2.1 3:34.16 java
Mal schauen, wie sich das so entwicklet und wann es wieder kracht.
Gruß
Holger
-
Hallo,
kann mir das jemand erklären?
Um 9:10 startetet das Backup vom Backitup Adapter. Wird da ggf der Speicher nicht mehr freigegeben? In der Job Liste sehe ich das aber nicht.
top - 11:22:50 up 1 day, 1:46, 1 user, load average: 0.15, 0.21, 0.21
Tasks: 131 total, 1 running, 83 sleeping, 0 stopped, 0 zombie
%Cpu(s): 3.0 us, 1.2 sy, 0.0 ni, 95.6 id, 0.0 wa, 0.0 hi, 0.2 si, 0.0 st
KiB Mem : 2062388 total, 519056 free, 688624 used, 854708 buff/cache
KiB Swap: 131068 total, 131068 free, 0 used. 1301832 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1188 root 20 0 181016 92212 17332 S 7.3 4.5 149:20.92 iobroker.js-con
817 mysql 20 0 644716 81860 11988 S 0.3 4.0 11:36.41 mysqld
1383 root 20 0 170864 72328 16956 S 2.0 3.5 37:50.45 io.javascript.0
1210 root 20 0 158248 59356 16940 S 0.0 2.9 4:14.57 io.admin.0
1245 root 20 0 147004 49848 17808 S 2.0 2.4 60:40.29 io.sql.0
1411 root 20 0 144300 46224 17592 S 0.0 2.2 3:04.86 io.telegram.0
1614 root 20 0 135664 45004 17064 S 0.0 2.2 4:49.12 io.opi.0
1263 root 20 0 144300 44164 16984 S 0.3 2.1 8:57.64 io.web.0
Danke,
Holger
-
Sorry, kann ich leider nichts dazu sagen. Ich mache mein Backup über ein shellscript, welches ioBroker backup und Rsysnc nutzt. Nur das Aufrufen des shellscripts geschieht mit js script, sozusagen statt cron.
Auf meinem piVCCU-opt mache ich backup mit schellscript über die piVCCU Backup-Funktion, rsync und cron.
Und leider habe ich keine so schönen Charts wie Du.
Du kannst ja mal ein paar Backups provozieren und dann beobachten, aber da bist Du sicher schon dran.
-
mit dem oPI +2e hatte ich , beginnend vor so 6 wochen etwa auch probleme.
sporadische Neustarts, im Abstand von 2-7 Tage, kam aber nach neustart nicht wieder richtig hoch. Das gleiche, was hier auch aufgrtreten ist,
zuerst hatte ich den oPi im verdacht, also den 2. oPI startklar gemacht. restore eingespielt. Nach ein paar Tagen das gleiche Spiel. Also das Netzteil im Verdacht gehabt. Also lief dann der oPI, mit zig Kühlkörpern auf den chips, direk angelötet an einem Labornetzteil mit 5A.Auch hier 2 unkontrolierte Neustarts. Damit schliesse ich Spannungsversorgung nun aus,
Das Tinkerboard startklar mit einem raspberry 5.1V 2.5A Netzteil gemacht, backup eingespielt. seitem rennt das maschinchen durch.
Ich habe da den Opi unter verdacht. Entweder ein HW Komponente oder aber irgendwas mit einem der leztten Softwareupdates..
Seit ca 3 Wochen läuft IObroker bei mir nun auf einem Tinkerboard, mittlerweile samt SUSV.
Gruss, Black
-
Du kannst den backitup-Adapter so wie alle anderen Adapter mit den Systemstates des jeweiligen Adapters monitoren.
Dazu den Wert memRss über den History-Adapter wegschreiben und über die Zeit auswerten. memRss ist der komplette Speicher eines Prozesses im RAM mit Code, Stack und Heap.
-
@stabilostick : Vielen Dank für den Hinweis! Bei mir haben einige Adapter einen Wert namens "output count", der bei allen auf "8 events / 15 seconds" zu stehen scheint. Was hat es damit auf sich?
@blackmike : Interessant! Hatte anfangs des Jahres nach einem armbian Kernel Update Probleme mit history und DB reconnects bis hin zu Neustarts. An Ende lag es daran, daß ich die history Daten auf eine FAT32 formatierte SSD schrieb. Nach Umstellung auf ext4 SSD war das Problem weg; seither schnurrt der OPI wieder wie zuvor. armbian hatte also nach dem Kernel-Update die Fähigkeit verloren mit FAT32 so umzugehen wie in der Zeit zuvor.
Habe mir damals vorgenommen, bei der nächsten größeren Problemwelle auf einen alten Laptop unter Windows zu gehen. Da hätte ich allerdings keine Lösung für den Umgang mit den seit Win 10 nicht mehr steuerbaren Updates.
Habe jetzt seit wenigen Wochen auf einem anderen OPI piVCCU. Das läuft bisher auch stabil, wobei das auch kaum Last generiert.
-
Das mit den 8 Events beim outputCount ist ok. Sie entstehen u.a. durch die zyklischen Abfragen durch den js-Controller um den Status der Adapter auszulesen.
