NEWS

@lansester sagte in Grünlandtemperatursumme und Flux:

Ist das Javascript, so dass ich es direkt als Skript verwenden kann und muss nur den Datenpunkt meines Außentemp-Sensors angeben?

Nein, das ist kein Javascript, sondern Flux, also die Standard-Abfragesprache der InfluxDB 2.x

Mein Ziel:
Einmal pro Tag ein Skript laufen lassen (Blockly oder Javascript), welches aus den vorhandenen Daten in der InfluxDB (Datenpunkt des Temp-Sensors) die aktuelle Gründlandtemperatur berechnet und in einem Objekt/Datenpunkt ablegt.
Das Objekt würde ich dann wiederum mit loggen und zur Darstellung nutzen.

Genau diesem Umweg benötigst du mit meiner Abfrage eben nicht. Die Abfrage setzt einen Datenpunkt mit Außentemperaturen voraus, der mindestens stündlich in die InfluxDB loggen sollte. Diese Abfrage kannst du 1:1 z.B. in Grafana einfügen (Datenpunkt natürlich anpassen) und bist damit fertig.

255fc85e-f7ad-4326-aa30-258f099f4f7e-grafik.png

@marc-berg
Moin, als kurzer Nachtrag: Jetzt läuft alles wieder ohne Probleme. Herzlichen Dank nochmal.
iobrokerbackup.PNG

@bitwicht
Kann es sein, dass da im Zeitraum evtl. keine Daten vorhanden sind?

@crunchip influx CLI ist natürlich auch drauf sonst würde das backup nicht starten, es bricht ja erst nach einer gewissen Zeit ab.

Der Befehl hätte sonst sofort einen fehler gemacht, bei mir ist das ja fast 10 Minuten gelaufen und beim shard 16 kommt dann der Fehler. (Was auch immer ein shard ist)

sudo influx backup ~ $ influx version Influx CLI dev (git: none) build_date: 2023-04-28T14:24:22Z

Ich glaub ich hab was gefunden, mein Speicher ist wie es aussieht voll 😕

$ df -h Filesystem Size Used Avail Use% Mounted on /dev/root 15G 14G 0 100% / devtmpfs 667M 0 667M 0% /dev tmpfs 925M 0 925M 0% /dev/shm tmpfs 370M 1.1M 369M 1% /run tmpfs 5.0M 4.0K 5.0M 1% /run/lock /dev/mmcblk0p1 255M 31M 225M 13% /boot tmpfs 185M 0 185M 0% /run/user/1000 192.168.1.105:/volume1/Share/rpibackups 2.7T 1.7T 1.1T 62% /home/nfs/mybackup

Wie finde ich denn raus wo das zeug liegt, den Ordner /dev/root gibts nicht, irgendwas hab ich mir da zugemüllt, systemctl sagt auch das influx nichtmehr läuft wegen fehlendem Speicher.

Kann mir jemand sagen wie ich den Orddner finde wo das Zeug drin liegt?

@marc-berg
Hat geklappt mit Kopie von influxd.bolt! Super Danke 🙂

@toki1973 InfluxDB 1.x benötigt keinen Token
https://github.com/simatec/ioBroker.backitup/wiki/ioBroker.backitup-Wiki-Deutsch#influxdb-backup

@marc-berg said in Backup Influxdb 2.6.1 funktioniert nicht:

@christianm

Da ist kein Operator-Token drin. Du hast den originalen also gelöscht (oder den User dazu) und die Anleitung zum Erstellen eines neuen nicht korrekt durchgeführt.

Influxdb und ich werden nicht mehr Freunde,
was hat er denn jetzt schon wieder für Probleme?

dd4837cf-63a4-412f-a723-c0337c45a1cf-grafik.png

@christianm klar, aber zwischen splitten und updaten ist halt auch unterschied. 🙂
wie gesagt, ich bin kein datenfreak. nett in grafana was zu virtualisieren. lebensnotwendig ist das für mich nicht.
ich seh live was meine PV macht, die gnädigste wäscht/trocknet nur mehr bei sonnenschein.
geheizt wird bei uns mit infrarot, da sind mir paar W schnurz.
aber wie immer, jedem das seine.

@thomas-braun
Vielen vielen Dank! Jetzt ist es endlich komplett weg.

@rikdrs sagte in InfluxDB 2.0 - welche Measurement löschen vom Scraper:

Jetzt sehe ich gerade noch 'measurement="influxdb*"' - kommen die auch von dem Scraper?

Ja, sowas wie

influxdb_users_total
influxdb_uptime
usw.

kommt auch daher.

@marc-berg
Danke für die Info

Weiss wirklich nicht, von woher die Measurements stammen.
Aber hier ist was Ähnliches beschrieben
https://forum.iobroker.net/topic/66472/influxdb-größe-aufspüren-und-ausmisten/30
Scrapper ist und war bei mir aber trotzdem nie angelegt oder aktiviert.

Ich hab mittlerweile alle Punkte einzeln gelöscht und funktioniert.

ok, danke. Dann muss ich wohl doch tiefer einsteigen. 😞

@martinp sagte in influxDB, sep. Datenreihen für Sichten auf Messwert?:

Wie haltet Ihr es in solchen Fällen?

Ich habe den Fall nicht, aber:

Ob du damit wirklich platz sparst hängt massiv davon ab wie häufig Du die Aktuelle Brennerleistung aktualisierst. Findet das mit jedem Puls statt, dann wirst Du platz sparen. Das macht aber aus meiner Sicht nur Sinn wenn du sowieso wenig verbrauchst. Bei hoher Brennerleistung hast du ggf. mehrere Pulse pro Aktualisierung der Brennerleistung in der Influx DB. Schon wenn es dann nur 2 Pulse sind, ist das mit dem einsparen des Speicherplatzes dahin.

Dazu kommt dann die Flux-Query - die - Immer dann wenn du dir die Daten anschaust Rechenleistung verbrät - und dann im Verhältnis viel, da ja aus der Datenbank die Einzelpulse geholt werden müssen. Ob da ein "Gewinn" übrig bleibt ist eher fraglich.

Der eigentliche Vorteil wäre das du beliebige Queries erstellen kannst und nicht auf deine vorgerechneten Werte angewiesen bist. Und da kommt dann das Thema Query-Sprache und Einarbeitung dazu.

Unterm strich würde ich es nicht machen. Der Vorteil ist zu gering um den Aufwand zu rechtfertigen.

A.

@herrx sagte in Keinen zugriff auf Influx DB:

Muss ich das nach jedem reboot wieder eingeben?

Nein, der Service sollte nun beim booten gestartet werden.

@marc-berg
Ich habe jetzt nochmal meine Festplatte von ganz vorne neu aufgesetzt und jetzt kann ich mit Backitup ein Restore wieder herstellen. Allerdings habe ich es jetzt nur lokal probiert. Über FTP habe ich es noch nicht von meiner Synology geholt. Die Verzeichnisse werden von der NAS angezeigt. Aber das ist erst mal nicht ganz so schlimm.

Mein eigentlicher Fehler war, das ich nicht den richtigen Operator Token benutzt habe. Ich hätte auch per sudo influx auth list --user admin mir den Token anzeigen lassen könnnen. Ich hatte von Dir ja gelesen, das der erste Token ja ganz wichtig ist. Deswegen bin ich nochmal in mich gegangen und hatte überlegt.

Danke für eure Hilfe...

@bitwicht spät aber bin jetzt erst wieder am Rechner.

Abfrage A:

import "date" import "timezone" // import wegen der Berechnung um 02:00:00 option location = timezone.location(name: "Europe/Berlin") from(bucket: "Stromverbrauch") |> range(start: -1y, stop: date.truncate(t: now(), unit: 1mo)) |> filter(fn: (r) => r["_measurement"] == "Stromzaehler") |> aggregateWindow(every: 1mo , fn: last, timeSrc: "_start" ,createEmpty: true ) |> difference()

Abfrage B

import "timezone" // import wegen der Berechnung um 02:00:00 option location = timezone.location(name: "Europe/Berlin") from(bucket: "ioBroker") |> range(start: -1mo, stop: now()) |> filter(fn: (r) => r["_measurement"] == "Vb_Stromzaehler") |> filter(fn: (r) => r["from"] == "system.adapter.javascript.0") |> aggregateWindow(every: 1mo , fn: last, timeSrc: "_start") // ,createEmpty: false ) |> difference()

Der Screenshot dazu:

Screenshot 2024-01-15 183758.png

@haus-automatisierung
Bis jetzt habe ich dafür immer die Funktion spread benutz und bin damit auch ganz zufrieden.
Aber jetzt sind Probleme aufgetaucht wenn ich neue Datenpunkte aufnehme und dann in die Vergangenheit gehe(wo es den Datenpunkt noch nicht gibt) kommt logischerweise ein Fehler im Log. Kann man das irgendwie umgehen ?

@dr-pie Dann weiß ich leider nicht weiter, sorry.

@ftd sagte in Influxdb löschen einzelner Punkte in einer Datenbank:

Danke! Funktioniert.