NEWS
RPIMonitor: "No Value found for cpu_frequency"
-
Ich würde das trotzdem noch einmal zur Diskussion stellen:l
- Wenn der Standardweg (cpuinfo_cur_freq) lesbar ist wird er genutzt
- Wenn nicht wird geschaut ob die Alternative geht (scaling_cur_freq)
- Wenn nicht gibt es -1
Es sollte also auch im Standard immer eine Verbesserung geben.
A.
-
Ist das mittlerweile im Standard drin oder nicht?
-
Nein, ist es nicht.
//EDIT:
Irgendwie ist mir bisher auch noch nicht ganz klar geworden, unter welchen Umständen scale_cur_freq nutzbar ist und unter welchen nicht. Hier hab ich zwei raspberries, wo die identisch zu cpu_cur_freq zu sein scheint. Auf meinem Server mit Desktop CPU sind die Werte völlig unterschiedlich und scale_cur_freq irgendwie nicht interpretierbar...Eine mögliche Lösung wäre noch per cron den Wert aus cpu_cur_freq regelmäßig in eine Datei zu schreiben, die der user ioBroker dann lesen kann. Den cron müssten die User dann aber selber einrichten, da der iobroker auch beim installieren von adaptern keine Root-rechte hat. Ist das eine gangbare Lösung?
-
@Asgothian
Anscheinend konnte das Problem mit "No Value found for cpu_frequency " noch nicht gelöst werden?Weil mich genervt hat, daß ich nach jedem Reboot vom Raspi die Dateirechte manuell setzen musste,
habe ich jetzt folgenden Workaround gemacht:In Datei /etc/rc.local folgendes zusätzlich eintragen:
echo "Setze Dateirechte 777 fuer /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq" cd /sys/devices/system/cpu/cpu0/cpufreq sudo chmod 777 cpuinfo_cur_freq cd /home/pi exit 0
Diese Datei wird nach dem Boot des Raspi ausgeführt und setzt die Rechte entspr.
-
@joergeli Nein, mein Änderungsvorschlag wurde abgelehnt. Weswegen das immer noch nicht geht. Das was Du da machst ist durchaus funktional, aber ich bin mir nicht sicher ob das nicht doch zwischendurch noch einmal umgesetzt wird.
A.
-
@Asgothian
Magst du dazu mal einen PR machen? Ich würde das durchaus testen und ggf. übernehmen wollen. -
@Garfonso Klar, mach ich
-
@joergeli sagte in RPIMonitor: "No Value found for cpu_frequency":
chmod 777
Ich würde ja da etwas vorsichtiger rangehen und nicht alles von allen und jedem schreiben, lesen und ausführen lassen.
-
@Garfonso sagte in RPIMonitor: "No Value found for cpu_frequency":
@Asgothian
Magst du dazu mal einen PR machen? Ich würde das durchaus testen und ggf. übernehmen wollen.Das wäre super wenn an dem RPI2 nochmal was gemacht würde!!
wäre dann auch möglich bei anderen Parametern eine bedingte Abfrage zu machen?
bei Armbian-Rechnern liegen die Daten oft in anderen Pfaden oder die Abfrage ist anders.
Da habe ich mir auch immer die io-package.json neu hardcodiert (bis zum nächsten Update)Irgendjemand war cleverer und hat einen OPi-Adapter draus gemacht.
Ich würde dann außerdem gerne mal die geänderte Version auf diversen SBC testen, schließlich steht ja die Aussage noch im Raum, dass der Wert von
scaling_cur_freq
nicxht immer passen soll (siehe Link im früheren Post) -
@Homoran Ich mach einfach meinen Fork wieder aktiv - dann kann da nach Herzenslust getestet werden. In dem Fork wird
- cpuinfo_cur_freq ausgelesen wenn es lesbar ist
- scaling_cur_freq ausgelesen wenn es lesbar ist
- -1000 ausgegeben wenn beide NICHT lesbar sind.
Ich denke damit sind wir hinreichend Sicher.
-
@Homoran sagte in RPIMonitor: "No Value found for cpu_frequency":
bei Armbian-Rechnern liegen die Daten oft in anderen Pfaden oder die Abfrage ist anders.
In gewissen grenzen geht das. Hast du mal ein paar Beispiele für mich was du gepatched hast, dann bau ich das in den Branch gleich mit ein
A.
-
@Asgothian
auf die Schnelle nur das hier:
ist aber schon uralt und ich weiß auch nicht ob da alles drin ist.
Habe rein pragmatisch in den letzten Installationen einfach den Opi-Adapter genutzt.
Vielleicht findest du da ja noch was -
@Homoran
Alles was da drin ist ist so auch im rpi2 drin. Und noch etwas mehr.Am besten testest du mal den adapter von meinem Repo:
https://github.com/asgothian/ioBroker.rpi2
-
-
@Asgothian
Sorry, ich hatte noch keine Zeit. -
@Asgothian
Ja, scheint hier zu gehen. -
@Asgothian
müsste ich mal einen Armbian Rechner neu aufsetzen und testen -
Ok. Dann gebe ich den Pull request jetzt erst einmal durch- In der Hoffnung das es keine Weiteren Probleme gibt.
A.
-
@Asgothian ich habe jetzt mal schnell einen guten alten Cubietruck aufgesetzt.
Da läuft dein Adapter ohne Probleme:
ich glaube aber, dass du die cpu_frequency bei armbian sowieso als user aufrufen kannst.
Habe dann noch ein paar Notizen gefunden, was ich früher mal implementiert hatte:
die Befehle funktionieren noch auf dem Cubie. Ich hatte damals u.a. Eingangsspannung und Leistung überwacht sowie die Ladefunktionen des internen Ladereglers und der angeschlossenen LiPo-Batterie. Die habe ich im Moment nicht dran, aber die Befehle Battery/connected und charger/charging geben immerhin ein 0 heraus.
Auch die Daten der am SATA angeschlossenen HDD/SSD hatte ich abgerufen und so die Temp und die Stunden im View dargestellt:
EDIT:
Mist! Das log ist bei einer neuen Installation standardmäßig nicht sichtbar.
Da stand doch was drin:rpi2.0 2020-09-15 21:03:21.805 error /1024 rpi2.0 2020-09-15 21:03:21.805 error /dev/mmcblk0p1 30431292 1598472 27566624 6% / rpi2.0 2020-09-15 21:03:21.805 error (8577) Cannot evaluate: Filesystem 1K-blocks Used Available Use% Mounted on
Armbian hat eine andere Filestruktur auf der Karte
ich weiß leider nicht mehr wie ich das damals (vor 5 Jahren???) abgefangen hatteEDIT2:
habe es gefunden:
https://forum.iobroker.net/topic/6642/rock64-pine64/202ich habe einfach die Abfragen im Adapter entfernt
-
Ich hatte heute mal etwas Zeit.
das Ganze hatte mir keine Ruhe gelassen, also habe ich nochmals rumgeschraubt.Der "Fehler" mit der Boot-Partition ist anscheinend anders nicht zu lösen, als die Abfrage danach zu löschen.
Unter Armbian kommt man anscheinend von der Root nicht mehr an die Boot-Partition, das sind verschiedene Partitionen schon auf der Karte.Da ich aber noch mehr wollte (auch wenn ich keine Ahnung habe) wollte ich nochmal wie früher unter ccu.io meinen Cubietruck komplett auslesen.
Das chöne am Cubietruck ist ja die Möglichkeit dort einen Akuu anzuschließen und somit eine USV zu besitzen.
Da sind so viele schöne Daten für Batterie und Netz (und noch weitere....).
Ich habe es tatsächlich geschafft die io-package.json so zu manipulieren, dass ich Ergebnisse bekomme:
Leider scheinen die Daten für Voltage und Ampere bei Netzbetrieb und Batterie identisch ausgegeben zu werden, obwohl die Befehle über putty die richtigen Werte ausgeben.
Zur Überprüfung habe ich die Formatierung der Daten absichtlich falsch gesetzt. Dies kommt aber richtig an
Kannst du mir dabei helfen zu verstehen wo der Fehler ist?
und wo muss ich den Typ und die Einheit der States definieren?