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

[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

[Diginix]

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

• (Apollon77) EN: Make sure disabling "Log changes only" also really do not log the changes anymore
• (Apollon77) DE: Stellen Sie sicher, dass durch Deaktivieren von "Nur Änderungen protokollieren" die Änderungen auch wirklich nicht mehr protokolliert werden

Verstehe nur ich diesen Satz falsch?
Wenn ich nicht nur Änderungen geloggt haben will, dann sollen diese ja aber trotzdem auch noch geloggt werden, aber eben zusätzlich auch Aktualisierungen von Werten, die sich zum vorherigen nicht geändert haben. Wenn aber die Änderungen nicht mehr geloggt werden, würde bis in alle Ewigkeit nur noch der letzte Wert und dessen Aktualisierungen geloggt und eben keinerlei Änderungen mehr.

[apollon77]

@diginix "Nur Änderungen Loggen" bedeutet das der gleiche Wert nicht geloggt wird falls er nochmals kommt. So war das Setting schon immer. Wenn diese Einstellung "aus" ist dann wird genau das geloggt was an Änderungen so reinkommt - egal ob der Wert gleich ist oder anders

Es bestand allerdings ein Bug das wenn man das Setting "gleichen Wert trotzdem loggen"mit einer Zeit angegeben hatte, allerdings "Nur Änderungen Loggen" ausgeschaltet hat (womit diese Option an sich ausgegraut wird), dann wurde der gleiche Wert dennoch im angegebenen Zeitinterval geloggt.

[Diginix]

@apollon77 Das beißt sich doch nun auch wieder. Wenn ich gleich Werte nach x Zeit loggen will, muss doch "nur Änderungen loggen" aus sein. Aber egal. Ich gehe davon aus, dass du das im Code richtig machst und ich nur die Erklärung missverständlich finde ;-)

[apollon77]

@diginix Das beisst sich nicht weil die Einstellung heisst "Gleiche werte Trotzdem loggen nach Zeit X" 8 weil sonst charting blöd wird)

[Marty56]

@apollon77
Hallo,

Ich habe die Kombination influxdb 1.8 mit eingeschaltetem Flux laufen.

Kann es sein, dass die Queries in Javascript, die Flux Queries beinhalten, nur mit influxdb 2.0 funktionieren?

Mein Script

        var query = 'from(bucket:"iobroker")' + 
                        '|> range(start: 2022-05-28T00:00:00Z, stop: 2022-05-28T23:59:59Z)'+
                        '|> filter(fn: (r) => (r._measurement == "mqtt.0.Energie.haus_bezug" and r._field == "value"))' 

        log(query)
        sendTo("influxdb.0", 'query', query
        , function (result) {
                    if (result.error) {
                        console.error(result.error);
                    } else {

                        log('Rows: ' + JSON.stringify(result));
                    }
            });

liefert

influxdb.0
2022-05-29 06:43:33.729	error	query: Error: error parsing query: found FROM, expected SELECT, DELETE, SHOW, CREATE, DROP, EXPLAIN, GRANT, REVOKE, ALTER, SET, KILL at line 1, char 1

javascript.0
2022-05-29 06:43:33.740	error	script.js.common.Energie: Invalid call

Auf der CLI Console von influxdb funktioniert die Abfrage

> from(bucket:"iobroker")|> range(start: 2022-05-28T00:00:00Z, stop: 2022-05-28T23:59:59Z)|> filter(fn: (r) => (r._measurement == "mqtt.0.Energie.haus_bezug" and r._field == "value"))
Result: _result
Table: keys: [_start, _stop, _field, _measurement]
                   _start:time                      _stop:time           _field:string        _measurement:string                      _time:time                  _value:float  
------------------------------  ------------------------------  ----------------------  -------------------------  ------------------------------  ----------------------------  
2022-05-28T00:00:00.000000000Z  2022-05-28T23:59:59.000000000Z                   value  mqtt.0.Energie.haus_bezug  2022-05-28T00:01:22.056000000Z                         130.9  
2022-05-28T00:00:00.000000000Z  2022-05-28T23:59:59.000000000Z                   value  mqtt.0.Energie.haus_bezug  2022-05-28T00:06:37.055000000Z                        130.92 

[apollon77]

@marty56 kurz. Ja. Da flux so spät bei der influxdb 1.x dazu kam nutzt der Adapter das nicht für queries. Wenn du flux willst bitte auf influxdb 2 Updaten.

(So stehts auch in der Readme :-) )

[Palm_Maniac]

Hallo,

in einem anderen Beitrag hier hatte ich mal nachgefragt, ob man die Haltezeit pro Datenpunkt nicht konfigurierbar machen kann, so wie sie im History-Adapter möglich ist. Da ich InfluxDB 2 verwende mußte ich feststellen, dass das dort nur pro Bucket geht und nicht pro Datenpunkt, also entweder ganz oder garnicht. Also habe ich den Tipp hier aus dem Forum aufgegriffen und befülle nun eine weitere Kurzzeitdatenbank mit Hilfe einer 2. Adapter-Instanz. Dort habe ich dann die Haltezeit auf 1 Monat gestellt und alle betroffenen Datenpunkte umgestellt.

Leider bleiben ja die alten Datenpunkte mit den alten Daten in der "Langzeit"-Datenbank erhalten, was der Übersichtlichkeit leider nicht hilft. Also habe ich nach einem Weg gesucht, wie ich diese Datenpunkte aus dem Bucket löschen kann. Das WebUI von Influx selbst bietet leider keine derlei unterstützenden Funktionen. Also habe ich gesucht und bin in einem Forum fündig geworden. Mit folgender Befehlssequenz habe ich meine Datenpunktliste im Bucket von allen alten Einträgen befreien können:

influx delete --bucket "iobroker" --org "Privat" --predicate '_measurement="Ersparnis-Dez-2022"' --start "1970-01-01T00:00:00Z" --stop "2025-12-31T23:59:00Z" --token "Euer InfluxDB Token"

Da man bei dem Befehl Start und Stop, also den zu löchenden Zeitraum, festlegen muß, könnte man nicht doch irgendwie per Skript die Haltezeit pro Datenpunkt (Measurement) realisieren und eventuell eine Art Datenbankbereinigungsfunktion einbauen? Zumindest ist es so manuell per Shell/SSH-Console möglich.

Aber Vorsicht! Solltet ihr die Alias-Funktion im InfluxDB Adapter nutzen, verwendet bei der Benennung "keine" Umlaute. Ich habe den Fehler gemacht, die Datenpunkte werden angelegt und befüllt und nun kann ich sie nicht löschen, da die Konsole keine Umlaute annimmt.

[apollon77]

@palm_maniac hm … also löschen sollte der Adapter können über die Datenpunkt Einstellungen im expertenmodus. Aber hast es ja hinbekommen.

[Palm_Maniac]

@apollon77 Den einzigen Löschbefehl, den ich im Adapter gefunden habe, ist der unter DB Settings. Alle Daten in Datenbank löschen. Eine andere Löschmöglichkeit hab ich nicht gefunden. Der löscht doch nur die komplette Datenbank (Bucket) und das will ich ja nicht.

[apollon77]

@palm_maniac Admin5 - Expertenmodus - gehe auf den Datenpunkt den du willst - gehe auf die Tabelle - dann sollten oben rechts buttons sein

[oFbEQnpoLKKl6mbY5e13]

@apollon77

Bei Influxdb2?

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