Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[Asgothian]

@Homoran

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.

[Homoran]

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

[Asgothian]

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

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

[Homoran]

@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