UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[paul53]

@Sprite01:

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.

[Sprite01]

OK, Danke.

Dann gehe ich von einem fehlerhaften Bild in der Beschreibung aus und arbeite mich ein.

[Homoran]

@paul53

: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

[holgerwolf]

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

[knopers1]

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!

[holgerwolf]

@knopers1:

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

[klassisch]

@holgerwolf:

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

[holgerwolf]

@klassisch:

@holgerwolf:

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

[klassisch]

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

[klassisch]

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^C

Betrieben mit dem o.g. Netzteil und einem provisorischen Inbetriebnahmekühlkörper. Läuft stabil durch.

Jetzt läuft gerade ein zehnmal solanger Test

[klassisch]

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.

[holgerwolf]

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

[holgerwolf]

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

[klassisch]

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.

[Blackmike]

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

[Stabilostick]

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.

[klassisch]

@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.

[Stabilostick]

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.

[holgerwolf]

Ich kämpfe immer noch mit dem Memeory Verbrauch. Irgendwie scheint der nicht mehr freigegeben zu werden.

Hier eine "top" Anzeige:

top - 10:15:42 up 1 day,  1:37,  1 user,  load average: 0.73, 0.48, 0.32
Tasks: 130 total,   1 running,  82 sleeping,   0 stopped,   0 zombie
%Cpu(s):  2.1 us,  0.8 sy,  0.0 ni, 97.1 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem :  2062388 total,   441772 free,   703456 used,   917160 buff/cache
KiB Swap:   131068 total,   131068 free,        0 used.  1288416 avail Mem 

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                            
 1077 root      20   0  203308 100752  17336 S   4.3  4.9 140:28.20 iobroker.js-con                                    
  883 mysql     20   0  635896  79548  12084 S   0.3  3.9  12:41.71 mysqld                                             
 1676 root      20   0  169228  70908  17028 S   1.6  3.4  36:55.28 io.javascript.0                                    
 1668 root      20   0  158620  59456  17900 S   1.3  2.9  58:40.35 io.sql.0                                           
13767 root      20   0  158320  57260  17092 S   0.0  2.8   3:38.90 io.admin.0                                         
 1738 root      20   0  149744  48028  17128 S   0.3  2.3  16:08.35 io.web.0                                           
 1557 root      20   0  138652  47320  16924 S   0.0  2.3   5:08.57 io.opi.0                                           
  623 root      20   0  362680  44612   9560 S   0.0  2.2   4:08.81 java                                               
 1545 root      20   0  140492  43080  19700 S   0.0  2.1   1:32.66 io.ham.0                                           
 1371 root      20   0  141900  42416  17524 S   0.3  2.1   3:57.63 io.telegram.0                                      
 1551 root      20   0  142824  41496  28228 S   0.0  2.0   1:52.60 io.amazon-dash.                                    
 1662 root      20   0  137004  39092  17160 S   0.0  1.9   4:13.78 io.hm-rega.0                                       
10494 root      20   0  128464  38504  17136 S   0.0  1.9   3:23.15 io.hm-rpc.2                                        
 1656 root      20   0  128492  38176  17168 S   0.0  1.9   7:21.93 io.hm-rpc.0                                        
 1395 root      20   0  124016  33272  17076 S   0.3  1.6   1:15.48 io.socketio.0                                      
 1497 root      20   0  122484  32308  17112 S   0.3  1.6   5:02.23 io.hm-rpc.1                                        
 1569 root      20   0  126172  32224  17644 S   0.0  1.6   1:16.53 io.alexa.0      

Hier sieht man schön, dass der Memeory immer schön abnimmt. Der Knick gegen 9:10 ist ein Backup (backup Adapter). Bald knallt es dann wieder.

Gruß

Holger

[klassisch]

Sorry, hatte eine recht volle Woche und Abends leider kaum Zeit. Habe am 19.7. mal meinen OPi Adapter aktiviert.

So sieht es bei mir aus. Keine so großen bleibenden Sprünge, dafür recht lebhaft. Zeitskala deckt aber einige Tage ab. Man koennte eine Tendenz hineininterpretieren. Würde ich aber noch nicht tun. Ich lassen den Monitor noch etwas laufen.

Den Backitup Adapter habe ich nicht. Habe das alles "zu Fuß" über shell, rsync etc eingerichtet. Sicher alles suboptimal, da ich kein Linux-Spezi bin, aber es scheint hinreichend zu laufen.