Wartung am 15.11. – Forum ab 22:00 Uhr nicht erreichbar

[Spegeli]

@Walkinlarge2010 said in RPIMonitor: "No Value found for cpu_frequency":

@Spegeli bei mir funktioniert das mit der CPU Frequency nicht. Habe den Adapter gelöscht, auf der Katze den link zur Installation eingegeben und danach installiert. Leider weiter der Fehler im Log und keine Frequenz. Was mache ich falsch oder gibt es noch eine alternative Lösung?

Danke!

Walkinlarge2010

Hast du den alten Adapter vorher gelöscht? Oder evtl. Doch nur die Instanz?
Und versucht über Github oder "andere" zu installieren?
Habs selber über "andere" gemacht. Danach evtl. mal iobroker Stop und iobroker Start machen.

[Walkinlarge2010]

Danke. Der User war der Bug. Hatte immer nur die Instanz gelöscht und dann via „andere“ installiert. Nachdem ich auf jedem Slave den Adapter unter Adapter gelöscht und jeweils über den link hinzugefügt hatte ging es.

Problem gelöst, vielen Dank!!

Grüße Walkinlarge2010

[Werde45]

@Spegeli Sorry aber so klappts bei mir nicht. Hab auf Master und Slave die Instanzen und Adapter gelöscht und dann den Fork installiert. Wird dann als Version 1.0.0 statt 1.1.1 angezeigt und bei CPU wird weiterhin nix angezeigt.
Auf dem Master ging es schon mal und nun sind beide "defekt". Keine Idee mehr.

[Asgothian]

@Werde45

• Upload gemacht ?
• Einträge im Log ?

Ich bin heute Abend wahrscheinlich im TS, dann können wir (so du das kannst/willst) auch gemeinsam mal drauf schauen und das Problem beseitigen.

A.

[conectas]

@Asgothian

gab es dazu eine endgültige Lösung?
Nach dem Update von auf raspi Typ: js-controller auf: 2.2.7 das gleiche Problem.

Ich habe jetzt erst einmal in die rc.local

chmod ugo+r /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq reingeschmissen.. kann ja aber nicht die Lösung sein.

CU

[Homoran]

@conectas
Da kann der Adapter nichts für!

Irgendwann hat Linux (und damit Raspbian) beschlossen, dass man an diesen Wert nur als echter Roor ran darf - warum auch immer.
selbst ein sudo hilft da nicht

[Asgothian]

@conectas Die Lösung die ich damals favorisiert hatte funktioniert bei mir immer noch. Allerdings weiss ich nicht ob das bei anderen auch ging.

A.

[Bastelritius]

@Asgothian: Könntest Du noch mal genau beschreiben was Du gemacht hast um die CPU Frequenz wieder anzuzeigen?

[Asgothian]

@Bastelritius
Ich bin von

/sys/devices/system/cpu0/cpufreq/cpuinfo_cur_freq

auf

/sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq

als auszulesender Datei umgestiegen, das hat bei mir auch funktioniert.

Du kannst versuchen meinen Fork von Github zu installieren, er unterscheidet sich vom aktuellen iobroker-community-adapters/ioBroker.rpi2 nur durch diese Änderung.

A,

https://github.com/asgothian/ioBroker.rpi2

[Bastelritius]

@Asgothian: Super, das funktioniert. Vielen Dank dafür.
Kann man das nicht in die Standardversion des Adapters mit einpflegen?

[Homoran]

@Bastelritius sagte in RPIMonitor: "No Value found for cpu_frequency":

Kann man das nicht in die Standardversion des Adapters mit einpflegen?

Nicht wirklich, da dieser Messwert nicht wirklich standardisiert zu sein scheint:

https://forum.iobroker.net/topic/13857/rpimonitor-no-value-found-for-cpu_frequency/21

[Asgothian]

@Homoran

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.

[wendy2702]

Ist das mittlerweile im Standard drin oder nicht?

[Garfonso]

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?

[joergeli]

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

[Asgothian]

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

[Garfonso]

@Asgothian
Magst du dazu mal einen PR machen? Ich würde das durchaus testen und ggf. übernehmen wollen.

[Asgothian]

@Garfonso Klar, mach ich

[Thomas Braun]

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

[Homoran]

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