Stats4Lox - Das Statistik-Plugin

[ChrisR]

Danke für das tolle Plugin. Ich nutze es erst seit ein paar Wochen, aber es ist bereits unersetzlich für mich.

Jetzt möchte ich gerne auch meinen LoxBerry überwachen, da ich seit längerem immer mal wieder Probleme mit Nichterreichbarkeit und Neustarts habe.
Hierzu habe ich Folgendes gefunden:

https://schroederdennis.de/raspberry...hung-influxdb/

Gibts noch eine bessere Möglichkeit, ohne diesem Workaround? Ich hab nix gefunden.

Danke für euer Feedback

[Thomas M.]

imho hat das nun nicht wirklich was mit dem plugin zu tun.



Nicht erreichbar = nicht anpingbar?
Zumindest wäre er während dem neustart nicht anpingbar.

Wenn ja, dann kannst ja von Loxone aus den LB überwachen.


Aaaaber überwachen ist ja keine problemlösung. Irgendwo musst du ja ein problem haben, weil er eben neu startet. Das ist ja wie beim Miniserver auch die letzte Selbstrettung des Systems. So hast du das System nach dem reboot wenigstens wieder zur Verfügung. Zumindest bis zum nächsten reboot, aber besser als tot liegen bleiben.

Ich würde das Problem lösen, dann brauchst nichts überwachen. Gut, eine ping-Überwachung seitens Loxone kannst ja trotzdem machen. Schadet nicht.

Der loxberry hat einen watchdog. (Unter Loxberry dienste), den kannst einschalten, dann hast nach einem Abkacken (auf der SD Karte) Infos was denn schief gelaufen ist. Liegts an der Spannungsversorgung, Temperatur, Speicher, ...

Ich hatte einmal das Thema, dass seit dem ich das Plugin laufen hatte, auf einmal die Stromversorgung das Problem war.
Wie in der Doku zu lesen, ist ein Ladegerät kein Netzteil. Und ich hatte einfach ein Ladegerät aus der Schublade verwendet, war bis zu dem plugin kein Problem. Das ist etwas ressourcen-intensiver.

[ChrisR]

Danke Thomas
Genau aus dem Grund würde ich den Loxberry gern überwachen. Damit ich sehe wo was aus dem Ruder läuft. Mit dem Watchdog komme ich nicht wirklich klar. Sehr viele Daten mit denen ich auf Anhieb nix anfangen kann.

Ich hab mal 3 der letzten Plugin gelöscht und jetzt habe ich das Problem vorerst nicht mehr. Eine wirkliche Lösung ist das aber nicht

[ChrisR]

Oh Mann...läuft bei mir :/

Jetzt startet der Loxberry nach einem Neustart nicht mehr. Mehrmals probiert - kein Erfolg. So wie es aussieht werd ich jetzt mal das Restore des Backups probieren müssen...ich als Linuxvolldepp ://

Kommando zurück!!! Zum Glück war am neuen Router nur keine feste IP eingestellt. Deshalb fand der Neustart mit einer andere IP statt. Puhhhh.... ))

[eisenkarl]

Hallo, ich nutze das Plugin jetzt einen Monat und es funktioniert so weit super, danke dafür.
Allerdings gibt es ein kleines "Schönheitsproblem", ich kann nämlich die Datenpunkte, wenn sie einmal angewählt waren nicht aus dem Stats4Lox dynamic Dashboard löschen (habe auch gelesen, dass das nicht geht) Allerdings habe ich den Datenpunkt unter Loxone and Import entfernt, trotzdem ist das Panel weiter im Dashboard vorhanden.

Gibt es eine Möglichkeit, das zu korrigieren?

Danke

[Christian Fenzl]

eisenkarl Das ist kein "Fehler" sondern ein "Feature". Weil du mit MQTT Live weiterhin Daten an diese Statistik schicken kannst, lösche ich das Panel nicht.

Ich hab das mal als Issue angelegt: https://github.com/mschlenstedt/LoxB...-NG/issues/123

lg, Christian

[eisenkarl]

OK, verstehe...
Kann ich es irgendwo von "Hand" raus nehmen oder soll ich einfach warten bis du das Issue schließt? ;-)

[Christian Fenzl]

Lass mal drin. Ich weiß jetzt nicht auswendig, was nötig ist, dass das Provisioning neu gerechnet wird.

[Heickl]

Hey, danke für tolle das Plugin.

Mir ist ein Bug (oder tatsächlich Feature ;-) aufgefallen, bzw ich kann es mir nicht anders erklären. Hat wahrscheinlich nichts direkt mit dem Plugin zu tun sondern Influx oder Telegram. Bin leider nicht drin in der Materie.

Ich lasse mir von einem anderen Raspberry Daten per MQTT schicken und per MQTT Collector in die Stats4Lox Influx schreiben. Collect strings ist aktiviert.
Im Prinzip ein Topic user/data mit json payload:
"ID", eine Zahl z.B. "12345" und "Description", die aufgeschlüsselte ID z.B. "Michael".
Das wird intern auf dem anderen Raspberry zuegordnet, falls er aber zu einer ID keine Description findet schickt er nochmal die ID in der Description. In Influx stehen aber nur Daten mit gleicher Datenart. Sprich es kommen keine Strings mehr an wenn im ersten Datensatz Zahlen in der Description waren und umgekehrt.
Meine Vermutung ist dass irgendwo eine Zuordnung passiert und die Datenbank dann nur noch gleichartige Daten akzeptiert.
Kann das jemand bestätigen, oder mir sagen welchen Logs ich zu rate ziehen kann um den Weg bzw den Verlust der Daten nachzuvollziehen?

Danke schonmal.
Gruß,
Michael

[Christian Fenzl]

Zeig mal eine json Payload, damit kann ich mehr anfangen 😉

Wer schlüsselt was wie wo auf? 😜

[Christian Fenzl]

Ich glaube, jetzt hab ich verstanden, was du meinst, und das ist die Ursache:
https://docs.influxdata.com/influxdb...-across-shards

Der MQTT Collector identifiziert den ersten Wert als Zahl und sendet diesen dann auch als Zahl. Auch wenn der Collector den nächsten Wert als String identifiziert und sendet, lässt Influx keinen anderen Datentyp mehr zu.

[Heickl]

Sorry, war etwas wirr geschrieben, genau das meinte ich
Payload ist wirklich nur:

{"ID": "12345","description": "Test"} oder eben {"ID": "12345","description": "12345"}

Muss ich mir mal ansehen. Hab schon gesehen ich muss mich etwas in Influx einarbeiten. Oder has du spontan einen Tipp?

Danke schon mal.

[Christian Fenzl]

Du kannst an Influx nichts ändern, und ich müsste viel ändern.
Vielleicht kannst du die Quelldaten modifizieren, damit keine Zahl ankommt.

[simon_hh]

ist es möglich Grafana Plugins dazuzu installieren?

z.B. aus er Weboberfläche fehlen wohl Berechtigungen des loxberry (vermutlich weil keine Verknüpfung zu grafana.com)





Man könnte es aber manuell installieren.
Ginge das? Ist der Pfad korrekt?



Danke fürs Feedback

[smooty1970]

Seit ein paar Tagen habe ich massive LOG Aktivitäten:

Use of uninitialized value $1 in addition (+) at /opt/loxberry/webfrontend/htmlauth/plugins/stats4lox/grabber/../../../../../bin/plugins/stats4lox/libs/Stats4Lox.pm line 102.

WARNING: Stats4Lox corrected 1 duplicate attributes (non-valid Loxone XML):

WARNING: LoxAIRDevice Original: C Type="LoxAIRDevice" Desc="Stromzähler" V="151" U="18b74860-0028-4c4c-ffffc80488007c8f" Title="Zählerinterface IR Air" WF="16384" IP="FE80000000000000524F94FFFE92DDB8" AirType="24" SubType="24" DC="true" UseDimmer="true" UseRGBDimmer="true" PWMFrequency="123" PG="" DType="3" Installation="" SwitchBoard="Schaltschrank" SwitchBoardRow="1" SwitchBoardPos="1" DType="3" PollingCycle="60" Baudrate="9600" Tf="1" NewType="true"

WARNING: LoxAIRDevice S4LFixed: C Type="LoxAIRDevice" Desc="Stromzähler" V="151" U="18b74860-0028-4c4c-ffffc80488007c8f" Title="Zählerinterface IR Air" WF="16384" IP="FE80000000000000524F94FFFE92DDB8" AirType="24" SubType="24" DC="true" UseDimmer="true" UseRGBDimmer="true" PWMFrequency="123" PG="" DType="3" Installation="" SwitchBoard="Schaltschrank" SwitchBoardRow="1" SwitchBoardPos="1" PollingCycle="60" Baudrate="9600" Tf="1" NewType="true"

WARNING: DNS Lookup error for HAUS: Bad arg length for Socket::inet_ntoa, length is 0, should be 4 at /opt/loxberry/webfrontend/htmlauth/plugins/stats4lox/../../../../bin/plugins/stats4lox/libs/Loxone/ParseXML.pm line 197.

WARNING: --> Could not resolve IP for Miniserver HAUS.

Jede Nacht inder Zeit von 01:30 bis ca. 02:30 zeichnet Stats4Lox keine Daten auf
Ist jetzt zwar nicht dramatisch - aber das muss ja eine Ursache haben...

Danke

[Mandanges]

Ich habe seither ein Problem mit dem MQTT Live Dienst. Nach einem Neustart funktioniert der Abruf genau 1 Mal. Danach werden Änderungen weder registriert, noch in Grafana geplottet.

Hatte immer gehofft, dass ich es noch mehrere mit dem Problem gibt.

Nach einem Neustart funktioniert alles wieder genau 1 mal. Wenn ich das Plugin länger laufen lasse (>2-3 Tage) ist der PI nach einem Neustart oftmals im Netzwerk nicht erreichbar und muss stromlos gemacht werden.

Für mögliche Helfer habe ich Log-Files angehängt.

Besten Dank vorab.

[Christian Fenzl]

Mandanges

Du kannst nochmal den letzten Stand installieren - der Link ist der gleiche wie damals (…/main.zip), ich kann’s am Handy nicht kopieren.
Ich weiß nicht, ob du meine letzten Änderungen schon hast, jedenfalls ist das der Verbindungsfehler zum MQTT Server, und wegen deinem Loglevel weiß ich nicht, ob der Reconnect bei dir schon drin ist.


@smooty1970

Klingt nach Backup oder sowas, wo Telegraf wegen Auslastung in ein Timeout läuft.
Die gelisteten Warnings, da kannst du dich bei Loxone bedanken, die nicht mal ihr zentrales LoxPlan-File XML-valide halten können. Und bei uns, weil wir das, damit wir das XML trotzdem lesen können, am LoxBerry lokal ausbessern. Genau das sagt auch die Meldung, die nur beim Laden des UI kommt. Hat nichts mit dem Abrufen der Werte zu tun.
Das mit dem DNS-Lookup, da stimmt entweder in deiner Loxone Config, oder in der Config von LoxBerry, die IP oder Hostname nicht zusammen (DNS-Auflösung funktioniert nicht).


@Beide: Das error.log brauchen wir bei S4L praktisch nie zur Analyse, weil wir eigentlich für alles eigene Logfiles haben.

[mr-manuel]

Hallo,

ich nutze das Plugin nun schon etwas mehr als ein Monat und finde es echt klasse! In der Zeit sind einige Fragen aufgetaucht, die ich mir leider nicht selbst beantworten konnte und weder in der Doku noch in dem Beitrag gefunden habe.

1) Beim Namen des Logs ist glaube ich ein kleiner Tippfehler unterlaufen?

/opt/loxberry/log/plugins/stats4lox/grabber_logone.log

ich vermute es sollte

grabber_loxone.log

heißen? Nur falls ihr es ausbessern wollt

2) Ich weiß, dass das Speichern der Daten in dasselbe Measurement nicht die standard Konfiguration ist und somit nicht wirklich untersetützt wird. Vielleicht ist es jedoch trotzdem möglich sich das kurz anzuschauen? Wenn nicht, dann kann ich das verstehen.
Für identische Daten (z.B. Tempretatur, Stromverbrauch, Stellantriebe) verwende ich dasselbe Measurement. Da über die GUI dem Measurement automatisch ein Postfix (_n) angehängt wird, habe ich dieses manuell in der

/opt/loxberry/config/plugins/stats4lox/stats.json

Config entfernt. Der Import der Daten (source = import) und Eintrag über MQTT Live (source = mqttlive) funktioniert ohne Probleme, jedoch funktioniert der geplante Import (source = grabber) nur für die erste konfigurierte Statistik.

In den Logs habe ich folgende Einträge:

Erste Statistik die mit dem Measurement "Stellantriebe" angelegt wurde:

18:35:00.220 <INFO> 1.15.20 - Kanal A - 0-10 V -> Interval 60 UUID 133553cd-0031-4b7e-ffffb02f8fc64da0
18:35:00.325 1.15.20 - Kanal A - 0-10 V -> Default: 0
18:36:00.328 <INFO> 1.15.20 - Kanal A - 0-10 V -> Interval 60 UUID 133553cd-0031-4b7e-ffffb02f8fc64da0
18:36:00.338 1.15.20 - Kanal A - 0-10 V -> Default: 0
18:37:00.232 <INFO> 1.15.20 - Kanal A - 0-10 V -> Interval 60 UUID 133553cd-0031-4b7e-ffffb02f8fc64da0
18:37:00.284 1.15.20 - Kanal A - 0-10 V -> Default: 0
18:38:00.246 <INFO> 1.15.20 - Kanal A - 0-10 V -> Interval 60 UUID 133553cd-0031-4b7e-ffffb02f8fc64da0
18:38:00.254 1.15.20 - Kanal A - 0-10 V -> Default: 0
18:39:00.255 <INFO> 1.15.20 - Kanal A - 0-10 V -> Interval 60 UUID 133553cd-0031-4b7e-ffffb02f8fc64da0
18:39:00.262 1.15.20 - Kanal A - 0-10 V -> Default: 0
18:40:00.192 <INFO> 1.15.20 - Kanal A - 0-10 V -> Interval 60 UUID 133553cd-0031-4b7e-ffffb02f8fc64da0
18:40:00.244 1.15.20 - Kanal A - 0-10 V -> Default: 0
18:41:00.411 <INFO> 1.15.20 - Kanal A - 0-10 V -> Interval 60 UUID 133553cd-0031-4b7e-ffffb02f8fc64da0
18:41:00.420 1.15.20 - Kanal A - 0-10 V -> Default: 0
18:42:00.176 <INFO> 1.15.20 - Kanal A - 0-10 V -> Interval 60 UUID 133553cd-0031-4b7e-ffffb02f8fc64da0
18:42:00.265 1.15.20 - Kanal A - 0-10 V -> Default: 0
18:43:00.199 <INFO> 1.15.20 - Kanal A - 0-10 V -> Interval 60 UUID 133553cd-0031-4b7e-ffffb02f8fc64da0
18:43:00.251 1.15.20 - Kanal A - 0-10 V -> Default: 0
18:44:00.201 <INFO> 1.15.20 - Kanal A - 0-10 V -> Interval 60 UUID 133553cd-0031-4b7e-ffffb02f8fc64da0
18:44:00.254 1.15.20 - Kanal A - 0-10 V -> Default: 0
18:45:00.200 <INFO> 1.15.20 - Kanal A - 0-10 V -> Interval 60 UUID 133553cd-0031-4b7e-ffffb02f8fc64da0
18:45:00.250 1.15.20 - Kanal A - 0-10 V -> Default: 0
18:46:00.319 <INFO> 1.15.20 - Kanal A - 0-10 V -> Interval 60 UUID 133553cd-0031-4b7e-ffffb02f8fc64da0
18:46:00.330 1.15.20 - Kanal A - 0-10 V -> Default: 0
18:47:00.186 <INFO> 1.15.20 - Kanal A - 0-10 V -> Interval 60 UUID 133553cd-0031-4b7e-ffffb02f8fc64da0
18:47:00.236 1.15.20 - Kanal A - 0-10 V -> Default: 0
18:48:00.271 <INFO> 1.15.20 - Kanal A - 0-10 V -> Interval 60 UUID 133553cd-0031-4b7e-ffffb02f8fc64da0
18:48:00.279 1.15.20 - Kanal A - 0-10 V -> Default: 0
18:49:00.282 <INFO> 1.15.20 - Kanal A - 0-10 V -> Interval 60 UUID 133553cd-0031-4b7e-ffffb02f8fc64da0
18:49:00.291 1.15.20 - Kanal A - 0-10 V -> Default: 0
18:50:00.196 <INFO> 1.15.20 - Kanal A - 0-10 V -> Interval 60 UUID 133553cd-0031-4b7e-ffffb02f8fc64da0
18:50:00.262 1.15.20 - Kanal A - 0-10 V -> Default: 0

Zweite und alle weiteren Statistiken die ich ins Measurement "Stellantriebe" schreibe:

18:35:00.326 <INFO> 1.15.22 - Kanal B - 0-10 V -> Interval 60 UUID 133553e2-03a6-27a5-ffffb02f8fc64da0
18:35:00.326 <INFO> 1.15.22 - Kanal B - 0-10 V -> Interval not reached - skipping this time
18:36:00.340 <INFO> 1.15.22 - Kanal B - 0-10 V -> Interval 60 UUID 133553e2-03a6-27a5-ffffb02f8fc64da0
18:36:00.340 <INFO> 1.15.22 - Kanal B - 0-10 V -> Interval not reached - skipping this time
18:37:00.285 <INFO> 1.15.22 - Kanal B - 0-10 V -> Interval 60 UUID 133553e2-03a6-27a5-ffffb02f8fc64da0
18:37:00.285 <INFO> 1.15.22 - Kanal B - 0-10 V -> Interval not reached - skipping this time
18:38:00.255 <INFO> 1.15.22 - Kanal B - 0-10 V -> Interval 60 UUID 133553e2-03a6-27a5-ffffb02f8fc64da0
18:38:00.255 <INFO> 1.15.22 - Kanal B - 0-10 V -> Interval not reached - skipping this time
18:39:00.263 <INFO> 1.15.22 - Kanal B - 0-10 V -> Interval 60 UUID 133553e2-03a6-27a5-ffffb02f8fc64da0
18:39:00.263 <INFO> 1.15.22 - Kanal B - 0-10 V -> Interval not reached - skipping this time
18:40:00.246 <INFO> 1.15.22 - Kanal B - 0-10 V -> Interval 60 UUID 133553e2-03a6-27a5-ffffb02f8fc64da0
18:40:00.246 <INFO> 1.15.22 - Kanal B - 0-10 V -> Interval not reached - skipping this time
18:41:00.422 <INFO> 1.15.22 - Kanal B - 0-10 V -> Interval 60 UUID 133553e2-03a6-27a5-ffffb02f8fc64da0
18:41:00.422 <INFO> 1.15.22 - Kanal B - 0-10 V -> Interval not reached - skipping this time
18:42:00.266 <INFO> 1.15.22 - Kanal B - 0-10 V -> Interval 60 UUID 133553e2-03a6-27a5-ffffb02f8fc64da0
18:42:00.266 <INFO> 1.15.22 - Kanal B - 0-10 V -> Interval not reached - skipping this time
18:43:00.252 <INFO> 1.15.22 - Kanal B - 0-10 V -> Interval 60 UUID 133553e2-03a6-27a5-ffffb02f8fc64da0
18:43:00.252 <INFO> 1.15.22 - Kanal B - 0-10 V -> Interval not reached - skipping this time
18:44:00.255 <INFO> 1.15.22 - Kanal B - 0-10 V -> Interval 60 UUID 133553e2-03a6-27a5-ffffb02f8fc64da0
18:44:00.255 <INFO> 1.15.22 - Kanal B - 0-10 V -> Interval not reached - skipping this time
18:45:00.252 <INFO> 1.15.22 - Kanal B - 0-10 V -> Interval 60 UUID 133553e2-03a6-27a5-ffffb02f8fc64da0
18:45:00.252 <INFO> 1.15.22 - Kanal B - 0-10 V -> Interval not reached - skipping this time
18:46:00.331 <INFO> 1.15.22 - Kanal B - 0-10 V -> Interval 60 UUID 133553e2-03a6-27a5-ffffb02f8fc64da0
18:46:00.331 <INFO> 1.15.22 - Kanal B - 0-10 V -> Interval not reached - skipping this time
18:47:00.237 <INFO> 1.15.22 - Kanal B - 0-10 V -> Interval 60 UUID 133553e2-03a6-27a5-ffffb02f8fc64da0
18:47:00.238 <INFO> 1.15.22 - Kanal B - 0-10 V -> Interval not reached - skipping this time
18:48:00.280 <INFO> 1.15.22 - Kanal B - 0-10 V -> Interval 60 UUID 133553e2-03a6-27a5-ffffb02f8fc64da0
18:48:00.280 <INFO> 1.15.22 - Kanal B - 0-10 V -> Interval not reached - skipping this time
18:49:00.292 <INFO> 1.15.22 - Kanal B - 0-10 V -> Interval 60 UUID 133553e2-03a6-27a5-ffffb02f8fc64da0
18:49:00.292 <INFO> 1.15.22 - Kanal B - 0-10 V -> Interval not reached - skipping this time
18:50:00.262 <INFO> 1.15.22 - Kanal B - 0-10 V -> Interval 60 UUID 133553e2-03a6-27a5-ffffb02f8fc64da0
18:50:00.262 <INFO> 1.15.22 - Kanal B - 0-10 V -> Interval not reached - skipping this time

Wenn ich das Measurement testweise auf Stellantriebe_2 umstelle und alle anderen fortlaufend (_3, _4 usw.) dann funktioniert es ohne Probleme. Das komische ist eben, dass nur der geplante Import nicht mit demselben Measurement zurechtkommt und sagt, dass das Interval nicht erreicht ist. Ist das ein Sicherheitsmechanismus? Wenn ja, kann ich den irgendwie deaktivieren?

Würde es klasse finden, wenn es in einer nächsten Version irgendwo eine "Profi" Checkbox gibt, die man einmalig anhaken kann und dies die Prüfung selber Measurements bei verschiedenen Statistiken deaktiviert.

LoxBerry Version: 2.2.1.2
Stats4Lox Version: 0.9.6 (Log-Level: Debug)
Systemauslastung: 0.16 0.13 0.10

Vielen Dank!

[mr-manuel]

Ich habe nun im Script "/opt/loxberry/webfrontend/htmlauth/plugins/stats4lox/grabber/grabber_loxone.cgi" in Zeile 99 folgendes hinzugefügt:

LOGINF "$results->{name} -> Interval not reached - skipping this time - (now: $now) (nextrun: $mem->{$tag}->{nextrun})";

20:09:00.267 <INFO> 1.15.22 - Kanal B - 0-10 V -> Interval not reached - skipping this time - (now: 1646593740) (nextrun: 1646593800)
20:10:00.336 <INFO> 1.15.22 - Kanal B - 0-10 V -> Interval 60 UUID 133553e2-03a6-27a5-ffffb02f8fc64da0
20:10:00.336 <INFO> 1.15.22 - Kanal B - 0-10 V -> Interval not reached - skipping this time - (now: 1646593800) (nextrun: 1646593860)
20:11:00.326 <INFO> 1.15.22 - Kanal B - 0-10 V -> Interval 60 UUID 133553e2-03a6-27a5-ffffb02f8fc64da0
20:11:00.326 <INFO> 1.15.22 - Kanal B - 0-10 V -> Interval not reached - skipping this time - (now: 1646593860) (nextrun: 1646593920)
20:12:00.260 <INFO> 1.15.22 - Kanal B - 0-10 V -> Interval 60 UUID 133553e2-03a6-27a5-ffffb02f8fc64da0
20:12:00.260 <INFO> 1.15.22 - Kanal B - 0-10 V -> Interval not reached - skipping this time - (now: 1646593920) (nextrun: 1646593980)
20:13:00.303 <INFO> 1.15.22 - Kanal B - 0-10 V -> Interval 60 UUID 133553e2-03a6-27a5-ffffb02f8fc64da0
20:13:00.303 <INFO> 1.15.22 - Kanal B - 0-10 V -> Interval not reached - skipping this time - (now: 1646593980) (nextrun: 1646594280)
20:14:00.309 <INFO> 1.15.22 - Kanal B - 0-10 V -> Interval 60 UUID 133553e2-03a6-27a5-ffffb02f8fc64da0
20:14:00.309 <INFO> 1.15.22 - Kanal B - 0-10 V -> Interval not reached - skipping this time - (now: 1646594040) (nextrun: 1646594100)
20:15:00.261 <INFO> 1.15.22 - Kanal B - 0-10 V -> Interval 60 UUID 133553e2-03a6-27a5-ffffb02f8fc64da0
20:15:00.261 <INFO> 1.15.22 - Kanal B - 0-10 V -> Interval not reached - skipping this time - (now: 1646594100) (nextrun: 1646594160)
20:16:00.314 <INFO> 1.15.22 - Kanal B - 0-10 V -> Interval 60 UUID 133553e2-03a6-27a5-ffffb02f8fc64da0
20:16:00.314 <INFO> 1.15.22 - Kanal B - 0-10 V -> Interval not reached - skipping this time - (now: 1646594160) (nextrun: 1646594220)

Es schaut so aus, als würde er den Task so vor sich herschieben, aber nie abarbeiten. Wenn ich das umgehe funktioniert es einwandfrei. Nur wird dann jede Minute alles importiert. Leider kenne ich CGI so gut wie garnicht :/

[mr-manuel]

Habe nun selbst die Lösung gefunden und poste diese hier, falls jemand auch mehrere Statistiken in einem Measurement haben möchte.

ACHTUNG: Diese Lösung wird offiziell NICHT unterstützt und gilt auf eigene Gefahr.

Es genügt in der Datei

/opt/loxberry/webfrontend/htmlauth/plugins/stats4lox/grabber/grabber_loxone.cgi

in Zeile 69 und 94 die Variable "measurementname" durch "uuid" zu ersetzten. Dadurch werden die Statistiken nicht mehr nach Measurement sondern nach UUID abgearbeitet. Die Timestamps mit der Info, wann die Statistik das nächste Mal abgearbeitet wird, wird alle 60 Sekunden neu in die Datei

/dev/shm/stats4lox_mem_loxonegrabber.json

geschrieben. Da diese Datei im Stats4Lox Projekt sonst nirgends verwendet wird sollte diese Änderung keine Probleme mit sich bringen.
Ich werde es nun einige Wochen testen und wenn jemand Interesse hat, kann ich gerne eine Rückmeldung geben.

[Prof.Mobilux]

mr-manuel Danke für den Typo :-)

Das editieren oder anpassen des Measurements unterstützen wir nicht. Ich weiß nicht, was da alles passiert. Es hat einige Zeit gedauert, bis wir das für uns passende Speicherkonzept entwickelt haben. So ist es für die meisten Nutzer am einfachsten "seine" Daten in der Datenbank wiederzufinden. Zudem halten wir uns (nach unserer Meinung) einigermaßen an das von Influx vorgegebene Konzept.

Kurz gesagt: Wir werden das nicht anpassen und auch keine Funktion einbauen, damit man das als "Profi" selbst anpassen kann. Sorry.

[mr-manuel]

Alles klar. Danke für die Rückmeldung.

[mr-manuel]

Nur der Vollständigkeit halber:

Habe herausgefunden, wieso das so ist. Die Imports werden nach den Measurements abgearbeitet und nicht nach UUID. Das bring mit sich, dass der Wert "nextrun" nach dem ersten Abarbeiten angepasst wird und alle folgenden Statistiken mit demselben Measurement nicht mehr abgearbeitet werden, da "nextrun" bereits um den Intervall erhöht wurde. Auch wären unterschiedliche Import Intervalle somit nicht möglich, da das Measurement nicht mehr einzigartig ist. In dem Fall ist das Thema "Ein Measurement für mehrere Statistiken verwenden" abgehakt.

Solltet ihr die Routine irgendwann mal überarbeiten, könnte das abarbeiten nach UUID statt Measurement vielleicht eine Alternative sein