ROCK64 - Pine64
-
Zur Info:
Mit Win32 DiskImager funktionierte das Image, aber leider ist der Biobroker nicht gestartet. Bei der Status-Abfrage kommt folgende Fehlermeldung:
No connection to states 127.0.0.1:6379[redis] ````Woran kann das liegen? Auch ein Reboot brachte keine Verbesserung. -
:oops: ich habe dich vergessen :oops:
Wenn du ein Backup eingespielt hast, das von einer Installation kommt auf der redis lief (das sind alle aktuellen images) muss auch die Installation auf der das backup "restored" wird mit redis laufen.
Gruß
Rainer
-
:oops: ich habe dich vergessen :oops: ` Alles gut
@Homoran:Wenn du ein Backup eingespielt hast, das von einer Installation kommt auf der redis lief (das sind alle aktuellen images) muss auch die Installation auf der das backup "restored" wird mit redis laufen. ` Wie meinst Du das? Ich habe kein Backup eingespielt sondern nur iobroker status eingegeben nach dem Erststart. Da erschien diese Fehlermeldung.
No connection to states 127.0.0.1:6379[redis]Habe zusätzlich versucht aus dem Image von armbian laut der Anleitung "Pine64 Schnellstart (Jessie)" selbstständig iobroker zu installieren. Funktionierte einigermaßen, nur meine Skripte wollen nicht mehr so richtig. Da muss ich mal forschen. Liegt bestimmt an neuer Controllerversion.
Obwohl Objekt vorhanden, bringt er diese Meldung:
javascript.0 2017-12-29 07:00:00.482 error at Object. (script.js.XSkripte.Backup_Scheduler:38:5) javascript.0 2017-12-29 07:00:00.479 error at ioBroker_Update (script.js.XSkripte.Backup_Scheduler:130:9) javascript.0 2017-12-29 07:00:00.478 error at pushprioTG (script.js.XSkripte.Backup_Scheduler:205:42) javascript.0 2017-12-29 07:00:00.477 error Error in callback: TypeError: Cannot read property 'val' of undefined javascript.0 2017-12-29 07:00:00.474 error script.js.XSkripte.Backup_Scheduler: Cannot use sync getState, use callback instead getState("javascript.0.Nachtruhe", function (err, state){});Naja das bekomme ich schon noch raus. Falls wir uns nicht mehr schreiben, erstmal danke für deine Mühen und guten Rutsch…
vg
Falk
-
Ich bin nun dabei mir einen neuen SBC zu kaufen. Ich habe jetzt schon ne ganze Menge zu den Hardwarevarianten gelesen und schwanke jetzt zwischen dem Rock64 +emmc-Modul oder eben den, auch schon viel beschriebenen, Orange Pi plus 2e.
Von den Daten her wäre ja der Rock erstmal überlegen, vor allem wegen des doppelt so großen RAMs (Frage ist eben auch, ob man den so groß brauch, aber haben ist besser als brauchen
).Der Preis soll erstmal nebensächlich sein. Ein wichtiger Punkt wäre, dass ich mir die Möglichkeit der Nutzung der GPIOs freihalten möchte, sind die denn über den rpi-Adapter schaltbar?
Hat denn noch jemand, außer Rainer (der natürlich gern seine Infos dazugeben kann), Erfahrungen mit beiden Geräten?
Enrico
-
außer Rainer ` :twisted:
-
-
außer Rainer (der natürlich gern seine Infos dazugeben kann), Erfahrungen mit beiden Geräten? ` Tja, Rainer, es wird halt nur Wenige mit Deiner Expertise geben - wenn überhaupt.
Ich kann nur sagen, daß mein Opi bis jetzt unaufgeregt und unauffällig schnurrt.
Das Ruhr 70-Skript sagt ziemlich konstant
ioBroker_Anzahl_Prozesse 16 ioBroker_CPU_Gesamt 26.6% ioBroker_Speicher_gesamt 486 MByte ioBroker_Speicher_prozentual 23.5%Temperatur ist bei ca. 26°C
Habe ja schon recht viel automatisiert. Insofern wird das Wachstum jetzt nicht mehr stürmisch sein. Werde aber immer wieder "Kleinigkeiten" zufügen bis das System an die Grenzen kommt und / oder es den ultimativen ioBroker Rechner gibt, den alle haben unbedingt müssen.
Für mich hat das SD-Karten freie System auf eMMC und die History-Daten auf einer 32GB SSD bewährt. Der Snapsht sieht für mich als Linux-Laien harmlos aus. Kann wahrscheinlich noch ein paar Jahre so weiter gehen.
#free total used free shared buffers cached Mem: 2062612 694324 1368288 41904 3080 160604 -/+ buffers/cache: 530640 1531972 Swap: 131068 0 131068 #free -m total used free shared buffers cached Mem: 2014 701 1312 40 3 155 -/+ buffers/cache: 543 1471 Swap: 127 0 127# df -m Filesystem 1M-blocks Used Available Use% Mounted on /dev/mmcblk0p1 14529 2063 11728 15% / udev 10 0 10 0% /dev tmpfs 403 41 362 11% /run tmpfs 1008 0 1008 0% /dev/shm tmpfs 5 1 5 1% /run/lock tmpfs 1008 0 1008 0% /sys/fs/cgroup /dev/sda2 30062 2393 27670 8% /media/SSD tmpfs 1008 0 1008 0% /tmp tmpfs 202 0 202 0% /run/user/0 -
Tja, Rainer, es wird halt nur Wenige mit Deiner Expertise geben - wenn überhaupt. `
Übertreib mal nicht, trotzdem Danke!Ich habe nur meine eigenen mehr oder weniger dilettantischen Beobachtungen niedergeschrieben - Wissen ist das noch lange nicht.
Trotzdem würde ich nicht sagen, dass
@RappiRN:Von den Daten her wäre ja der Rock erstmal überlegen `
Er hat zwar (bis zu) 4GB RAM, aber bei dem Rest bin ich mir nicht so sicher, ob er wirklich überlegen ist.
Meine Beobachtungen beziehen sich immer auf eine Vergleichsinstallation von ioBroker. Ich selber bin weder in der Lage irgendwelche Benchmarks durchzuführen noch kenne ich einfache Programme dazu.
Andererseits war ich der Meinung, dass ein irgendwie gearteter Benchmark nicht unbedingt die Performance für ioBroker widerspiegelt.
Wie wichtig 4GB RAM sind ist wahrscheinlich diskutierbar. Wichtiger sind IMHO die Geschwindigkeiten der diversen Schnittstellen/Speicher. Die kann ICH nicht objektiv messen, da vertraue ich ganz fest auf T. Kaiser im Armbian Forum und beobachte das dann bei mir.
Das eMMC beim OPi soll sehr schnell sein (beim plus2e schneller als beim plus2) beim Rock64 ist zumindest mein 16GB eMMC ziemlich lahm - sowohl gefühlt, als auch von den Daten, die ich aufgrund des Aufdrucks gegoogelt habe. Zu meinem 32GB eMMC habe ich keine Daten gefunden, habe es aber auch noch nicht selber verwendet.
Ein weiteres Nadelöhr ist der im Armbian-Forum immer wieder thematisierte interne USB 2.0 Hub. Über den laufen teilweise sehr viele interne Schnittstellen, so dass z.B. eine vorhandene SATA-Schnittstelle sich die USB 2.0 Bandbreite mit den USB-Buchsen und vielleicht auch dem Netzwerk und anderen Schnittstellen teilen muss). Der OPi plus2e hat dagegen eine dedizierte eSATA Schnittstelle.
Ich möchte den Rock64 nicht schlecht machen - im Gegenteil, der brummt bei mir problemlos. Da er eine USB 3.0 Schnittstelle besitzt, gehe ich davon aus, dass er nicht die Probleme eines interen Hubs (zumindest kein USB 2.0) hat. Ich habe auch schon den USB 3.0 zu eSATA Adapter nur noch nich die Zeit gehabt diesen z.B. mit einer schnellen SSD zu testen.
Das hier noch gar nicht erwähnte Tinkerboard hat z.B. nicht nur 2GB RAM, wie viele andere, sondern dieses ist auch noch asl Dual-Channel ausgelegt und ist kein DDR2 sondern DDR3 - was zu einer erheblichen Beschleunigung der Rechenvorgänge führt.
Zusammenfassend kann ich wieder nur sagen, dass es so viele verschiedene Gesichtspunkte gibt, dass man sich erst einmal Gedanken machen sollte was für einen wichtig ist. Mit den oben genannten neueren SBC kann man (fast) nichts falsch machen.
Gruß
Rainer
-
Das sind doch mal ein paar Infos!
Habt ihr auch schonmal versucht, die GPIOS vom Orange Pi zu verwenden? Ich brauche das zwar noch nicht zwingend, aber es wäre eben schön zu wissen, ob es funktioniert. Bei meinem jetzigen Banana Pi funktioniert das auf jeden Fall nicht auf Anhieb, der meckert gleich rum, nur wenn die GPIOS im Adapter freigeschaltet werden. Ich weiß ja auch, dass der rpi2.0-Adapter für den Raspi geschrieben wurde, es gab aber auch schon so einige Anpassungen für andere Minicomputer.
Enrico
-
Das hier noch gar nicht erwähnte Tinkerboard hat z.B. nicht nur 2GB RAM, wie viele andere, sondern dieses ist auch noch asl Dual-Channel ausgelegt und ist kein DDR2 sondern DDR3 - was zu einer erheblichen Beschleunigung der Rechenvorgänge führt.
Gibts denn dazu auch emmc Module, dass man das Gerät ohne SD-Karte betreiben kann? Wenn ich das richtig im Kopf habe gibt es diese Möglichkeit noch beim Odroid C2?
Enrico
-
Der OPi plus2e hat dagegen eine dedizierte eSATA Schnittstelle. ` Die ist zumindest nicht nach aussen geführt. Aber er hat wohl alle seine USB2 direkt angeschlossen, ohne Hub. Es gibt wohl einen anderen OPi, der eine extra SATA-Schnittstelle hat, aber eben über einen USB-Hub, was ihn unterm Strich wieder langsamer macht. Deshalb ist T.Kaisers Urteil über den Plus 2e recht positiv.
Meine 32 GB Sata SSD habe ich auch über USB angeschlossen. Das gibt sich bei der kleinen SSD nicht viel. Die ist zwar nicht lahm, aber auch nicht so schnell wie moderne große SSDs. Bei der Anwendung History ist wohl auch nicht die Geschwindigkeit das Problem, sondern die Schreibhäufigkeit. Wenn man die History auf die SD-Karte schreibt, dann gibt es viele Schreibvorgänge, die durch die journaling Dtaeisysteme wie ext2, ext3 noch vermehrt werden. Deshalb habe ich die SSD mit FAT32 formatiert und für History, Backups und solche Dinge reserviert. Ohne Experte zu sein, denke ich, daß für History & Co bereits ein USB-Speicherstick besser ist als die normale SD-Karte. Klar, es gibt auch industrielle SD-Karten, aber die kosten auch entsprechend.
Und zum RAM
@Homoran:Das hier noch gar nicht erwähnte Tinkerboard hat z.B. nicht nur 2GB RAM, wie viele andere, sondern dieses ist auch noch asl Dual-Channel ausgelegt und ist kein DDR2 sondern DDR3 - was zu einer erheblichen Beschleunigung der Rechenvorgänge führt.
Auch der OPI hat DDR3. Au der Beschreibung:
Memory (SDRAM) 2GB DDR3 (shared with GPU) -
Die ist zumindest nicht nach aussen geführt. `
Dann habe ich das bei den ganzen OPi-Varianten durcheinandergewürfelt. (Oder mit dem BananaPi M3 verwechselt)Deshalb ist T.Kaisers Urteil über den Plus 2e recht positiv. `
Es geht ja das Gerücht dass der OPi plus2e in Zusammenarbeit / auf Anforderungen von Armbian entwickelt wurde.Auch der OPI hat DDR3. `
Ja - aber singleChannel.Gibts denn dazu auch emmc Module `
leider Nein!aber wie klassisch schon sagt gibt es auch gute SD-Karten (und auch schlechtes eMMC!)
dass man das Gerät ohne SD-Karte betreiben kann? `
Warum ist das wichtig? Bei mir ist noch nie eine SD-Karte im laufenden Betrieb gestorben - nur wenn ich (während eines Schreibvorgangs) den Stecker gezogen habe. Und dann ist auch nicht die SD-Karte defekt sondern "nur" die Installation. Das passiert aber auch beim eMMC.etwas anders KANN sich das beim RasPi verhalten. Der fängt aufgrund seines geringen RAMs sehr schnell an zu swappen, und wenn ich das richtig verstanden habe ist beim resize der Root Partition auf die Größe der SD-Karte keine Reserve vorgesehen um ggf. defekte Zellen zu kompensieren.
Das Resize beim Armbian berücksichtigt das, wenn ich das richtig verstanden habe.
Gruß
Rainer
-
Warum ist das wichtig? Bei mir ist noch nie eine SD-Karte im laufenden Betrieb gestorben - nur wenn ich (während eines Schreibvorgangs) den Stecker gezogen habe. Und dann ist auch nicht die SD-Karte defekt sondern "nur" die Installation. `
Mir ist schon mindestens eine "durchgebrannt". ne zweite habe ich jetzt noch nicht geprüft, ob sie sich wieder zum Leben erwecken kann. Wir beide hatten dazu schon mal geschrieben, das fing an mit Fehlern beim Update bis zum Totalabsturz, ohne "Steckerziehen"!
Fest verbauter Speicher hat ja auch Nachteile, was z.B. die Datenrettung betrifft, da muss dann wohl die Backuppause verkürzt werden.
Und wie schon geschrieben, ich überlege ja noch, das ist gar nicht so einfach! :?
Enrico
-
Und dann ist auch nicht die SD-Karte defekt sondern "nur" die Installation. ` Und wenn man die History-Daten auf die SD schreibt, dann sind auch die mit weg. Deshalb denke ich, daß das Auslagern der History-Daten auf einen externen Speicher mit FAT32 ein einfacher aber wichtiger großer Schritt ist. Das reduziert die Schreibwahrscheinlichkeit auf die SD, entkopplet System und Daten und vermehrt nicht noch die Schreibzugriffe duch das journaling file system.
Das passiert aber auch beim eMMC. `
Ja, man liest, daß das genauso passieren könnte. Ich habe etliche Kaltstarts getestet und es gab bei meiner Konfiguration bisher keine Problem. Kann natürlich auch Glück sein, oder auch ein Teilergebnis des Auslagerns der History-Daten.
@Homoran:etwas anders KANN sich das beim RasPi verhalten. Der fängt aufgrund seines geringen RAMs sehr schnell an zu swappen, und wenn ich das richtig verstanden habe ist beim resize der Root Partition auf die Größe der SD-Karte keine Reserve vorgesehen um ggf. defekte Zellen zu kompensieren.
Das Resize beim Armbian berücksichtigt das, wenn ich das richtig verstanden habe. `
Experimenteller Befund beim Raspi 1 und 2: Nach einiger Betriebszeit mit Schreiben von CCU.IO "history-Daten" auf die SD-Karte, läßt sich das System z.B. anläßlich eines Updates nicht mehr ordentlich runterfahren / restarten. Es hängt irgendwie. Nach dem Kaltstart kommt es nicht mehr hoch. Und beim anschließenden Versuch, ein neues Image aufzuspielen ist die SD in meinem Notebook heiß geworden und war nicht mehr ansprechbar.Keine Ahnung, ob das ein Kontaktproblem war (solls ja bei den Raspis auch geben) oder ein BS/SW-Problem. Jedenfalls hat es mir so keinen Spass gemacht und wäre mir keine Empfehlung wert. Aber man liest auuch anderes, insbes. Verwendung industrieller SDs.
-
Der OPi plus2e hat dagegen eine dedizierte eSATA Schnittstelle…. Ich habe auch schon den USB 3.0 zu eSATA Adapter nur noch nich die Zeit gehabt diesen z.B. mit einer schnellen SSD zu testen. `
Das ist schade
Wahrscheinlich wird der USB 3.0 zu eSATA Adapter gegenüber der dedizierten eSATA Schnittstelle nicht enttäuschen. USB 3.0 ist jedoch flexibler nutzbar (schneller Memory Stick).
-
Fest verbauter Speicher hat ja auch Nachteile, was z.B. die Datenrettung betrifft, da muss dann wohl die Backuppause verkürzt werden.
`
Ja, wenn der mal richtig korrupt ist, muß ein Ersatgerät her und man kann BGA-Repair üben.Da ich meine Betriebsdaten (= History) auf die externe SSD ausgelagert habe, wäre lediglich die ioBroker Installation weg. Und die backupe ich nach jeder größeren Änderung.
Die History Daten werden alle paar Tage auf ein Zweitsystem kopiert. Wenn was schief geht, sind halt ein paar Daten weg. Schmerzlich, aber wie lange habe ich ohne Datalogging gelebt?
@RappiRN:Und wie schon geschrieben, ich überlege ja noch, das ist gar nicht so einfach! :? ` Denke, Du hast ähnliche Erfahrungen mit dem Raspi gemacht wie ich. Wird also nicht Deine Zielkonfiguration sein. Du kannst aber schon mal den ersten Schritt gehen und die History Daten auslagern. Meiner Meinung nach erhöht das die Überlebenschancen und gibt Dir Zeit, bis Du den für Dich optimalen Rechner gefunden hast.
Ein Kollege, der auch schon SDs beim Raspi verloren hat, macht das auch so. Er startet mit dem Raspi und einer externen SSD. Wenn der Raspi Speicher zu klein für seinen ioBroker wird, wechselt er.
-
I~~@klassisch:~~
der auch schon SDs beim Raspi verloren hat `
irgendwo habe ich mal gelesen, dass der RasPi3 die Karten schneller schrotten würde als der RasPi2 (und der tut es ja auch schon).Leider finde ich diese Stelle nicht mehr und kann nicht suchen woran das liegt.
Aber als der RasPi beim erstellen eines Images bereits swappte, als ich dann noch bei armbian gefunden hatte, dass sie darauf Wert legen, dass deren resize Funktion darauf achtet, dass ein kleiner Teil der Karte nicht partitioniert wird um ein besseres Management von defekten Speicherzellen zu ermöglichen, wundert es mich nicht mehr, dass die RasPis anscheinend öfters die Karten fressen.
Gruß
Rainer
-
Meine History-Daten werden gleich auf ein NAS-Laufwerk gespeichert, die habe ich also immer gleich wieder verfügbar!
Ich habe mir jetzt einfach mal den Orange Pi bestellt, der war grad wieder lieferbar bei banggood.
Enrico
-
Viel Erfolg, ist ein schönes Gerätchen .
Gesendet von meinem ZTE A2016 mit Tapatalk
-
Hallo
Der Rock64 mit 4gb ist bestellt , wie lange dauert der Versand ca?
Gesendet von iPad mit Tapatalk Pro
