@thomas-braun sagte in Repo für influxdb-client: Einmal aus- und wieder einloggen müsste passen Ja , passt.

@marc-berg Hab mal alles Mögliche ausgeschalten. Intervall jetzt 30s :-) Naja... früher oder später werd ich drüber stolpern. An alle Adapter Entwickler: so ne Debug Meldung bringt niemandem etwas :joy:

@oliverio said in PC stürzt nach Laden hoher Datenmengen ab: @chriswitt in javascript einfach in einer variable den timestamp merken, an dem geschrieben wird. beim nächsten trigger dann prüfen ob letzter timestamp mindestens 30*1000 größer ist. aber dann sind es in 90 tagen immer noch 15 mio werte. wenn dir alle 30 sekunden reicht, dann kannst du ja mal probieren, das influx dir das auch alle 30 sekunden aggregiert und nur diese daten liefert. die abfrage ändert die zugrundeliegenden daten nicht, nur die abfrage liefert das. damit kannst du dann rumspielen ob du evtl noch weiter aggregieren willst. ich kenne jetzt das skript nicht, aber da müsste doch sicherlich eine influx abfrage drin sein, die du nach den folgenden anweisungen apssassen kannst https://docs.influxdata.com/influxdb/cloud/query-data/flux/window-aggregate/ versuche soviel funktionalität in die abfrage von influx zu legen, da diese das um einiges effizienter kann, wie du nachher in javascript auswerten kannst. Ach ich hab halt so gar keine detailllierte Ahnung ;) Das Skript ist prinzipiell dieses hier : https://haus-automatisierung.com/software/2023/05/11/influxdb2-pv-dashboard.html Könnte mir das jemand umbauen auf einen x sek. log ? ;) Geb auch ein Bier aus :)

@balu67 Ich dachte, du wolltest nur bestimmte Daten in der Influx löschen, mit dem command löschst du aber deine ganze influx Installation..

@longbow sagte in Verbindung von influxdb nach Grafana: also ich hatte mal eine Verbindung von Influxdb nach Grafana, als Version 1 noch möglich war. Jetzt verbindet sich die beiden ja nur noch, wenn man die Version 2 nimmt Hast du auch einen kompletten Umzug von v1. X auf v2. X gemacht? Mit "nur auf neue Version upgraden" ist es nicht getan Unabhängig davon läuft v1. X nach wie vor, man muss nicht auf v2. X

@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. [image: 1712241822099-255fc85e-f7ad-4326-aa30-258f099f4f7e-grafik.png]

@marc-berg Moin, als kurzer Nachtrag: Jetzt läuft alles wieder ohne Probleme. Herzlichen Dank nochmal. [image: 1711956264087-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? [image: 1709814892243-dd4837cf-63a4-412f-a723-c0337c45a1cf-grafik-resized.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.