UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[oFbEQnpoLKKl6mbY5e13]

@apollon77

Wird das Editieren von Datenpunkten wie bei Influxdb1 im Admin noch hinzukommen?

[apollon77]

@ofbeqnpolkkl6mby5e13 ... wenn es jemand einbaut ... InfluxDB 2 ist da speziell. leg gern ein Feature Request an dann sieht man das

[oFbEQnpoLKKl6mbY5e13]

@apollon77

Feature Request für den Admin Adapter? Dein Ernst?

[apollon77]

@ofbeqnpolkkl6mby5e13 Nein InfluxDB Adapter. der kann updateState nur für InfluxDB 1 ...

[oFbEQnpoLKKl6mbY5e13]

@apollon77

Heute mal auf Deutsch...

https://github.com/ioBroker/ioBroker.influxdb/issues/262

[Palm_Maniac]

Hallo,

ich hatte ja schon mal geschrieben, dass sich seit einiger Zeit Warnmeldungen bekomme, die mir dann das Log sprengen. Gestern habe mal den Adapter auf Debug gestellt, in der Hoffnung, dass der Fehler wieder auftritt. Er tat es. Anbei ein Ausschnitt des Log, das mittlerweile wieder auf eine Größe von über 2,6GB angewachsen ist. Ein Neustart des Adapter oder des InfluxDB Service behebt das Problem bis zum nächsten Auftreten, meistens irgendwann in der Nacht.

Während des Fehlers findet ein deutlich erhöhter Netzwerktraffic zwischen iobroker und dem Influx Container statt.

influxdb.0
2022-05-21 11:02:42.874	info	Add point that had error for linkeddevices.0.Sensoren.EG.Küche.Küchenmaschine.ENERGIE_Strom to buffer again, error-count=9

influxdb.0
2022-05-21 11:02:42.874	warn	Error on writePoint("{"value":0,"time":"2022-05-21T08:54:22.593Z","from":"system.adapter.linkeddevices.0","q":0,"ack":true}): HttpError: unexpected error writing points to database: timeout / "unexpected error writing points to database: timeout""

influxdb.0
2022-05-21 11:02:42.874	warn	Point could not be written to database: iobroker

influxdb.0
2022-05-21 11:02:42.861	debug	Write Point: linkeddevices.0.Sensoren.OG.Thomas.Fernseher.ENERGIE_Spannung values:{"value":229,"time":"2022-05-21T08:58:52.780Z","from":"system.adapter.linkeddevices.0","q":0,"ack":true} options: null

influxdb.0
2022-05-21 11:02:42.861	info	Add point that had error for linkeddevices.0.Sensoren.OG.Thomas.Fernseher.ENERGIE_Spannung to buffer again, error-count=9

influxdb.0
2022-05-21 11:02:42.861	warn	Error on writePoint("{"value":229,"time":"2022-05-21T08:58:52.780Z","from":"system.adapter.linkeddevices.0","q":0,"ack":true}): HttpError: unexpected error writing points to database: timeout / "unexpected error writing points to database: timeout""

influxdb.0
2022-05-21 11:02:42.861	warn	Point could not be written to database: iobroker

influxdb.0
2022-05-21 11:02:42.860	debug	Write Point: linkeddevices.0.Sensoren.OG.Thomas.PC.ENERGIE_Strom values:{"value":0.733,"time":"2022-05-21T09:00:42.807Z","from":"system.adapter.linkeddevices.0","q":0,"ack":true} options: null

influxdb.0
2022-05-21 11:02:42.860	info	Add point that had error for linkeddevices.0.Sensoren.OG.Thomas.PC.ENERGIE_Strom to buffer again, error-count=8

PS: Ich glaube, ich habe eine Spur gefunden. Die vorausgehenden Kommunikationsfehler treten ab 4Uhr Früh auf und genau da starten Update-Tasks in Proxmox, speziell der von meiner Windows 11 VM, die bei mir als Datei und Multimedia Server läuft. Wieso stört dieser Vorgang die Container von iobroker und InfluxDB? Die laufen doch weiter und genug Resourcen sind im Server auch noch frei und davor hat es immer Problemlos funktioniert?

PPS: Problem gelöst. Es trat auf, nachdem ich eine 6TB HDD in den PVE integriert hatte und alle VMs und CTs dort hin verschoben hatte. Wenn dann nun ein Backup einer VM anspringt, scheint die Last auf der HDD so hoch zu werden, dass es zu starken Verzögerungen zu kommen scheint, die dann diese Kommunikationsfehler mit der InfluxDB auslösen. Ich habe nun die CTs auf ein anderes Laufwerk verschoben und nun klappt es endlich wieder wunderbar, inkl. automatischer Backups. :)

[apollon77]

@palm_maniac Perfekt, genau das wäre auch meine Vermutung gewesen. Der Fehlert liegt bei der InfluxDB. Und die "erhöhle Neutzwerklast" entsteht übrigens das der Adapter bei einem "Massenschreib Fehler" darauf zurückfällt die Daten einzeln zu schreiben

[Marty56]

@apollon77
Ein grundsätzliche Frage. Bei dem History DB Adapter gibt es die Möglichkeit die Retention Policy für jeden Datenpunkt festzulegen. Die "Datenverdichtung" im InfluxDB Jargon, die Continuous Queries, habe ich in meinen Javascripten selber gemacht. Keine Ahnung, ob das der von Dir angedachte Ansatz ist.

Retention Policies habe ich bei dem Influx DB Adapter nicht gefunden.
Kommt das noch zu einem späteren Zeitpunkt, oder muss der Anwender seine Retention Policies und auch die Continuous Queries außerhalb des Adapters in der InfluxDB definieren?

Ich fände es wünschenswert, dass zu mindestens die Retention Polices auch Teil des InfluxDB Adapters werden sollten. Dann wäre die Migration von historyDB nach InfluxDB bzgl. der Scripts einfacher.

Update: Habe gerade nochmal die Doc gelesen. Vermutlich kann man eine kompatible RP nicht realisieren, weil influxDB 2.0 die nur pro Bucket unterstützt und nicht mehr für die einzelnen Messungen. Und dann hat sich auch noch die Query Language geändert, was wiederum einen Effekt hat auf die Javascript. Ok, es bleibt nicht einfach.

Update 2: Ich habe jetzt doch die Retention Policy in den Adapter settings gefunden. Hatte aus "Gewohnheit" bei den Datenpunkten geschaut.
Vergiss die Anfrage.

[Marty56]

Jetzt habe aber doch noch eine Frage.

Die Retention Policies können jetzt ja nur noch für alle Measurements gleich festgelegt werden.
Was ist mit Daten, die ich über längere Zeit archivieren will?

1. Das muss man jetzt wohl in einer separaten Bucket/DB machen.

2. Macht es Sinn eine zweite influxDB Adapter Instanz anzulegen, die auf eine "Langzeit" DB verweist und die dann eine RP von "unendlich" hat?

3. und allgemein ist es sinnvoll, dass man für Werte in dieser Langzeit DB auch wieder zugehörige Datenpunkte in iobroker anlegt?

[ioT4db]

moin @marty56,

ich habe zwar noch den 2.x-Adapter (verwende den sendto bzw. storeState, was wohl aktuell mit dem 3er noch nicht geht), aber so mache ich das schon seit ich die influxV2 eingerichtet habe.

@marty56 sagte in influxdb 3.0.0 verfügbar - eine Zusammenfassung:

Das muss man jetzt wohl in einer separaten Bucket/DB machen.
#ja

Macht es Sinn eine zweite influxDB Adapter Instanz anzulegen, die auf eine "Langzeit" DB verweist und die dann eine RP von "unendlich" hat?
#ich habe je eine Instanz pro DB bzw. Bucket wo nie Daten gelöscht werden, eine mit einer Retention von ein paar Wochen und eine für schnelle Tests (eher ein Mülleimer)

und allgemein ist es sinnvoll, dass man für Werte in dieser Langzeit DB auch wieder zugehörige Datenpunkte in iobroker anlegt?
#in den DPs kann man dann einfach die jeweilige Instanz wählen bzw. man könnte sogar mehrere Instanzen gleichzeitig auswählen (habe ich aber noch nicht probiert)

[apollon77]

@marty56 Ich mag wen sich Fragen schneller selbst beantworten als ich Sie beantworten kann :-)

[apollon77]

@marty56 Also wäre eine Idee das so zu machen. kannst dann auch beide Instanzen für einen Datenounkt konfigurieren ... dann werden ggf auch Daten doppelt geschrieben und hast Sie kurzfristig und langsfristig und kannst dann drauf zugreifen wie Du denkst. Oder was meinst du mit 2.?

[Marty56]

@apollon77 "Oder was meinst du mit 2.?" Typo!

[apollon77]

@marty56 Ja meine Deinen Punkt 3 oben ...

3. und allgemein ist es sinnvoll, dass man für Werte in dieser Langzeit DB auch wieder zugehörige Datenpunkte in iobroker anlegt?

[Marty56]

@apollon77

Ich denke, dass man die Retention und Continous Queries direkt in influxDB also unabhängig von iobroker implementieren könnte.
Und wenn man dann Grafana zur Darstellung dieser Daten benutzt, besteht keine Notwendigkeit mehr für die Langzeitwerte in iobroker Datenpunkte anzulegen.

[Marty56]

@apollon77

Ich bentzte das "sendto ....", um queries auf die influxdb durchzuführen.
Ich habe mir dazu eine async query funktion gebaut, bei der ich 1 Sekunde auf die Ausführung der Query warte, bis ich das Ergebnis zurückgeben.

Ich hoffe dabei, dass alle meine Queries jeweils immer in einer Sekunde abgeschlossen sind.

async function influxDB_energy (db,id,start,sub_start,end) {
    end     =  "'" + end + "'"
    start   = "'" + start + "'" + sub_start
    var query = 'SELECT difference(distinct("value")) FROM "'+ id +'" WHERE time >= '+ start + ' and time <= ' + end +' GROUP BY time(1d) fill(linear)'
    log(query)
    var sum 
    sendTo(db, 'query', 'SELECT difference(distinct("value")) FROM "'+ id +'" WHERE time >= '+ start + ' and time <= ' + end +' GROUP BY time(1d) fill(linear)', function (result) {
        if (result.error) {
            console.error(result.error);
        } else {
            sum = 0
            var res_element = result.result[0]
            for (var i = 0;i< res_element.length;i++) {
                sum = sum + res_element[i].difference
            }
        }
    });
    
    const abfrage = new Promise(function(resolve, error) {
        setTimeout(function () {resolve(true);}, 1000);
    })
    await abfrage;
    return sum; 
};

(async ()  => {
  ...
   var ergebnis = await influxDB_energy (db,id,start,sub_start,end)
// mit "ergebnis" weiterarbeiten
 })(); 

Ich find den Ansatz grundsätzlich eher schlecht und hätte die Frage, ob man die Queries nicht asynchron, also auch mit Promises, bereitstellen könnte.

[apollon77]

@marty56 Hi,
also wenn du im JavaScript Adapter ein "sendToAsync" brauchst dann bitte dort einen Feature Request anlegen (wenn es die Methode wirklich nicht gibt).

Ansonsten kommt der callback immer zurück ... ich glaube im zweifel nach 30 Sekunden ... Die "1s Hoffnung" finde ich persönlich nicht so sinnvoll, aber jeder wie er mag :-)

[Marty56]

@apollon77 danke.
Ich habe es jetzt ein bisschen anders formuliert. Wie Du merkt bin ich kein Promises Profi.

async function influxDB_energy (db,id,start,sub_start,end) {
    end     =  "'" + end + "'"
    start   = "'" + start + "'" + sub_start
    var query = 'SELECT difference(distinct("value")) FROM "'+ id +'" WHERE time >= '+ start + ' and time <= ' + end +' GROUP BY time(1d) fill(linear)'
    log(query)
    var sum

    const abfrage = new Promise(function(resolve, error) {
        sendTo(db, 'query', 'SELECT difference(distinct("value")) FROM "'+ id +'" WHERE time >= '+ start + ' and time <= ' + end +' GROUP BY time(1d) fill(linear)', function (result) {
            if (result.error) {
                console.error(result.error);
            } else {
                sum = 0
                var res_element = result.result[0]
                for (var i = 0;i< res_element.length;i++) {
                    sum = sum + res_element[i].difference
                }
                resolve(true)
            }
        });
    })
    await abfrage;     
    return sum; 
};

Bin mir nicht sicher, ob das ein richtiger Ansatz ist. Grob getestet scheint es zu funktionieren.

[apollon77]

@marty56 Kann man so machen

[apollon77]

Hallo alle zusammen,

mit dem Feedback hier und auf GitHub und noch ein paar Sentry Fehlermeldungen, gibts jetzt hier die 3.1.0 mit noch ein paar Neuerungen:

Die wichtigste Neuerung ist das storeState und auch GetHistory jetzt auch für "unbekannte Objects-IDs" geht. Es fehlen natürlich sämtliche Filteroptionen und alles was man pro Datenpunkt einstellen kann, aber das sollte klar sein :-)

• (Apollon77) Data are not converted to numbers if they are other datatypes on getHistory to respect the saved data formats as defined in the datapoint settings for storage.
• (Apollon77) Fix retention change to lower checkbox in UI
• (Apollon77) Allow storeState again to write to InfluxDB for "unknown state ids" - "rules" usage is not supported in for this and storeState would be silently discarded in this case!
• (Apollon77) Fix several crash cases reported by Sentry
• (Apollon77) Make sure disabling "Log changes only" also really do not log the changes anymore
• (Apollon77) Allow storeState and GetHistory also to be called for "unknown ids"

Das Update sollte im Laufe des Abends im latest Repo aufauchen,

Viel Spass damit.

Ingo