RPIMonitor: "No Value found for cpu_frequency"
-
@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 onArmbian 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? -
@Asgothian
Habe mal einfach mit try and Error den wahrscheinlichsten Fall getroffen, dass ich die Bezeichnungen geändert habe, habe dann noch hier und da etwas geändert, sieht im Moment so aus:simulierter Stromausfall mit Batteriebetrieb
und anschließend Stecker wieder rein:
Wenn du mir dann noch helfen könntest wo man diese Datenpunkte definiert, wäre ich dir dankbar.
Variablendefinitionen hatte ich nicht gefunden, daher kam ich auf die Idee, dass die IDs gleichzeitig die Variablen sind.
ich hatte gehofft, dass durch die unterschiedlichen Objekte, die darin enthaltenen States ruhig gleich bezeichnet werden könnten -
Die Definition ist eigentlich ganz einfach, hier mal am Beispiel "raspberry" :
"raspberry": { "cpu_voltage": { "command": "vcgencmd measure_volts core", "regexp": "(\\d+.\\d+)V", "post": "" }, "mem_arm": { "command": "vcgencmd get_mem arm", "regexp": "(\\d+)", "post": "" }, "mem_gpu": { "command": "vcgencmd get_mem gpu", "regexp": "(\\d+)", "post": "" } },das JSON Objekt hinter der Property "raspberry" bezeichnet die 3 Objekte die unter "rpi2.0.raspberry" angelegt werden. Die "ID" der Objekte entspricht dabei den Properties aus der 1. Ebene (also "cpu_voltage", "mem_arm", "mem_gpu". Die Benennung entspricht der "vollständigen id", also z.Bsp. rpi2.0.raspberry.mem_gpu"
Ausgewertet werden diese Properties aber NUR, wenn es auf der obersten Ebene des "common" JSON Objektes den Eintrag "c_raspberry":true gibt. Ohne diesen wird das ganze JSON zu "raspberry" nicht weiter beachtet.
Die "c_..." properties werden auch von der admin Oberfläche aus einstellbar gemacht - müssen also dafuer auch im admin Bereich mit eingetragen werden.
Die eigentliche Benennung der Objekte selber müssen wie eigentlich immer nur in der vollständigen ID eindeutig sein ("rpi2.0.raspberry.mem_gpu")
Was den Typ angeht - aktuell ist der Typ immer "numerisch" oder "mixed", abhängig davon ob es innerhalb eines "verzeichnis" einen oder mehrere Datenpuntkte gibt. Ist es nur einer, ist der Typ mixed, sind es mehrere ist es numerisch.
Da müsste ich die Einträge mal erweitern um "type" und "format". Das kann ich tun wenn Du mir sagst was da gewünscht ist.
Ich hoffe das hilft soweit. Ansonsten können wir uns mal per ts / discord direkt unterhalten.
A.
-
@Asgothian
Danke für die Antworten!@Asgothian sagte in RPIMonitor: "No Value found for cpu_frequency":
Die Definition ist eigentlich ganz einfach, hier mal am Beispiel "raspberry" :
Das hatte ich ja auch früher schon mal geändert um den Adapter an Armbian anzupassen.
Soweit war das kein Problem.@Asgothian sagte in RPIMonitor: "No Value found for cpu_frequency":
Ausgewertet werden diese Properties aber NUR, wenn es auf der obersten Ebene des "common" JSON Objektes den Eintrag "c_raspberry":true gibt.
Das hatte ich mittlerweile auch herausbekommen und entsprechende Einträge hinzugefügt.
Dadurch bekam ich dann die neuen "Gruppen"
@Asgothian sagte in RPIMonitor: "No Value found for cpu_frequency":
Die "c_..." properties werden auch von der admin Oberfläche aus einstellbar gemacht - müssen also dafuer auch im admin Bereich mit eingetragen werden.
Das wäre natürlich noch das Sahnehäubchen - muss ich mir mal ansehen
@Asgothian sagte in RPIMonitor: "No Value found for cpu_frequency":
Die eigentliche Benennung der Objekte selber müssen wie eigentlich immer nur in der vollständigen ID eindeutig sein ("rpi2.0.raspberry.mem_gpu")
Davon war ich auch ausgegangen, aber anscheinend klappt das bei dem Adapter nicht, wenn die States trotz verschiedener Devices den gelichen Namen haben.
Habe mal versucht die main.js nachzuvollziehen. Auch wenn mir da vieles viel zu hoch ist, scheint es da eine funktion parser zu geben, die anscheinend die Werte nicht korrekt zuordnet.@Asgothian sagte in RPIMonitor: "No Value found for cpu_frequency":
Da müsste ich die Einträge mal erweitern um "type" und "format". Das kann ich tun wenn Du mir sagst was da gewünscht ist.
Mein Wunsch ist relativ unwichtig, aber ich denke die Typen sollten schon korrekt sein. Außerdem sollten die units noch mit rein.
Wenn ich eine unmaßgebliche Idee dazu haben sollte, würde ich in der io-package.json noch weitere Punkte entsprechend der Objektbeschreibungen ("unit";"type";"format") hinzufügen, die dann über die parser-Funktion ausgelesen werden müssten.
Hatte zwischenzeitlich manuell das raw angepasst
Mein nächster Schritt wäre noch Daten für die SSD einzubinden, wäre vielleicht auch für andere SBC sinnvoll, da immer mehr eine USB/SATA SSD nutzen.
Damals habe ich die Daten über smartmoncontrol ausgelesen.
Habe ich auch schon installiert, aber noch keine Platte dran@Asgothian sagte in RPIMonitor: "No Value found for cpu_frequency":
Ansonsten können wir uns mal per ts / discord direkt unterhalten.
habe ich leider beides nicht, werde ich auch nicht einrichten.
Nochmals danke für die Hilfe!!!!
-
@Homoran sagte in RPIMonitor: "No Value found for cpu_frequency":
Davon war ich auch ausgegangen, aber anscheinend klappt das bei dem Adapter nicht, wenn die States trotz verschiedener Devices den gelichen Namen haben.
das ist seltsam, ich hatte da keine Probleme. Ich hab mir zum Spass mal 2 Werte erzeugt mit gleichem internen Namen. Das teste ich noch im Detail die Tage, und behebe das gleich wenn ich heraus bekomme wo es klemmt.
@Homoran sagte in RPIMonitor: "No Value found for cpu_frequency":
Mein nächster Schritt wäre noch Daten für die SSD einzubinden, wäre vielleicht auch für andere SBC sinnvoll, da immer mehr eine USB/SATA SSD nutzen.
Damals habe ich die Daten über smartmoncontrol ausgelesen.
Habe ich auch schon installiert, aber noch keine Platte dranHier müssen wir aufpassen. Wenn neue Datenpunkte hinzu gefügt werden müssen wir uns über die Fehlerbehandlung unterhalten.
Es ist halt blöd wenn in der Konfiguration Datenpunkte auswählbar sind die dann Fehlermeldungen im Log oder sogar im Syslog des Systems hinterlassen. Ich denke das man da besser fährt wenn entsprechende Default-Werte hinterlegt werden können.A.
-
@Asgothian sagte in RPIMonitor: "No Value found for cpu_frequency":
Wenn neue Datenpunkte hinzu gefügt werden müssen wir uns über die Fehlerbehandlung unterhalten.
klar - aber erst mal sehn was überhaupt geht
Dauert bei mir eh wieder Wochen
@Asgothian sagte in RPIMonitor: "No Value found for cpu_frequency":
das ist seltsam, ich hatte da keine Probleme.
Die Datenpunkte werden korrekt im Objektbaum angelegt, haben bei gleichem State-Namen bei mir aber identische Werte angezeigt.
Nach änderung der Namen (zuerst bei rpi2.0.battery-stateName_b das _b angehängt) lief alles problemlos
