HowTo: Zusatz-Programme fuer jarvis v3

[MCU]

@wolfi913 Ok auch nicht zu viel? Dann passe ich es so an. Danke.

[wolfi913]

@mcu
Meine jetzt doch noch ein Muster erkannt zu haben. Liegt evtl. an der Anzeige der Nachkommastellen in der y-Achse.
Screenshots mach ich gleich noch
ohne Nachkommastellen

mit Nachkommastellen

[MCU]

@wolfi913 Hab jetzt noch die Nachkommazahlen berücksichtigt.
Neue Version v1.0.3, probiere mal.

[wolfi913]

@mcu sagte in HowTo: Zusatz-Programme fuer jarvis v3:

@wolfi913 Hab jetzt noch die Nachkommazahlen berücksichtigt.
Neue Version v1.0.3, probiere mal.

Hab's bei mir gleich ausprobiert.
Hatte zuerst bei einem Chart noch links einen Cut in der Anzeige.
Nach Änderung auf

	html += '           console.log("gridLeft: "+(10+ (8*'+dataLen+'))); '
	html += '           gridLeft = 10+ (8*'+dataLen+');'

schaut's jetzt so aus:

Würde sagen das passt hervorragend.
Hab's mit Edge, Firefox undunter Windows, im Fully auf dem Tablet und auf dem iPhone gecheckt. Schaut überall gleich gut aus.
Vielen Dank.

[MCU]

@wolfi913 Passe ich an. Danke.

[wolfi913]

@mcu sagte in HowTo: Zusatz-Programme fuer jarvis v3:

@wolfi913 Passe ich an. Danke.

Super, und nochmal vielen Dank

[wolfi913]

@mcu
Hätte in einem früheren Post im Forum zwecks der Einschränkung auf 500 Datensätze bei der influxDB gefunden, falls Du's noch brauchen kannst. Kann aber nicht sagen, ob das noch aktuell ist.
https://forum.iobroker.net/post/568705

[MCU]

@wolfi913 Hab gerade kein InfluxDB integriert. Kannst du es mal testen.

javascript-echartshistorygetdata-v1.0.4

            limit: dataLimitValue,
            //aggregate: 'max', //onchange
            ignoreNull: true,
            count : dataLimitValue

[wolfi913]

@mcu sagte in HowTo: Zusatz-Programme fuer jarvis v3:

@wolfi913 Hab gerade kein InfluxDB integriert. Kannst du es mal testen.

Funktioniert auf Anhieb
Influxdb

History

Ganz passt's bei mir noch nicht. Aber die Werte sind jetzt bei 5000.
Ich probier mal die Abweichung im blauen Bereich durch Hochsetzen vom limit noch zu verbessern.

[MCU]

@wolfi913 Da scheint es ein Problem bei influxDB zu geben? Normalerweise sollten die DB's alle gleiche Werte rückmelden.

Sind die Einstellungen für history und influxDB gleich? Oder loggt influxDB mehr Werte als history?

Vielleicht muss man bei influxDB count nutzen und bei history limit?
Einfach limit ausblenden mit

//  limit: dataLimitValue,

-> history evtl falsch, aber wie sieht es bei influxDB aus?

[wolfi913]

@mcu sagte in HowTo: Zusatz-Programme fuer jarvis v3:

Sind die Einstellungen für history und influxDB gleich? Oder loggt influxDB mehr Werte als history?

Eigentlich nicht, bei history ist zwar eine Entprellzeit von 1000ms drin. Sollte aber nicht's ausmachen da die Werte in der Regel alle 10sec kommen.

[wolfi913]

@mcu sagte in HowTo: Zusatz-Programme fuer jarvis v3:

//  limit: dataLimitValue,

Mach keinen Unterschied. Irgendwie sind in der influxDB mehr Werte drin. Mit 7000 funktionierts.

[MCU]

@wolfi913
Das ist ja nicht zielführend, da, wenn du 2 Tage wählst, wieder nicht alles angezeigt wird?

EDIT: Du kannst mal die influxDB-Instanz auf debug stellen, und dann bei jarvis ein Refresh durchführen.
-> LOG query Aufruf zu DB wird angezeigt.

// Es kommen Einträge mit 
History-Queries to execute:

@apollon77 limit zieht nicht für influxDB? (Bei historyDB ist alles ok)

0_userdata.0.PV.SignedBat17150970902550.21461031104686312 getHistory message: {"id":"0_userdata.0.PV.SignedBat","options":{"start":1715010686903,"end":1715097086903,"aggregate":"onchange","limit":5000,"ignoreNull":true}}

Es werden bei limit: 5000, nur 502 angzeigt. Setzt man zusätzlich count: 5000, werden auch aus influxDB 5000 geholt, aber wenn mehr vorhanden sind wird die Kurve abgebrochen.
-> limit scheint fest im Adapter definiert zu sein bei influxDB.

Issue aufmachen?

// Hiernach sollte es egal sein, ob limit oder count gesetzt wird 

limit:      parseInt(msg.message.options.limit, 10) || parseInt(msg.message.options.count, 10) || adapter.config.limit || 2000,

// hiernach sollte er bei onchange limit nutzen, wenn count nicht gesetzt

if (!options.count || isNaN(options.count)) {
        if (options.aggregate === 'none' || options.aggregate === 'onchange') {
            options.count = options.limit;
        } else {
            options.count = 500;
        }
    }

[wolfi913]

@mcu sagte in HowTo: Zusatz-Programme fuer jarvis v3:

@wolfi913
Das ist ja nicht zielführend, da, wenn du 2 Tage wählst, wieder nicht alles angezeigt wird?

EDIT: Du kannst mal die influxDB-Instanz auf debug stellen, und dann bei jarvis ein Refresh durchführen.
-> LOG query Aufruf zu DB wird angezeigt.

// Es kommen Einträge mit 
History-Queries to execute:

Ich hab's mal bei 5000 im Script eingestellt. Im Log (Debug) stehen:

Incoming message getHistory from system.adapter.javascript.0
0_userdata.0.PV.SignedBat17150961902120.559960672577708 getHistory message: {"id":"0_userdata.0.PV.SignedBat","options":{"start":1715009786818,"end":1715096186818,"aggregate":"onchange","limit":5000,"ignoreNull":true,"count":5000}}
Query to execute: from(bucket: "iobroker_short") |> range(start: 2024-05-06T15:36:26.818Z, stop: 2024-05-07T15:36:26.818Z) |> filter(fn: (r) => r["_field"] == "value") |> filter(fn: (r) => r["_measurement"] == "0_userdata.0.PV.SignedBat" and contains(value: r._value, set: [true, false])) |> pivot(rowKey:["_time"], columnKey: ["_field"], valueColumn: "_value") |> group()
Query to execute: from(bucket: "iobroker_short") |> range(start: 2024-02-04T15:36:26.818Z, stop: 2024-05-06T15:36:26.817Z) |> filter(fn: (r) => r["_measurement"] == "0_userdata.0.PV.SignedBat") |> last() |> pivot(rowKey:["_time"], columnKey: ["_field"], valueColumn: "_value")
Query to execute: from(bucket: "iobroker_short") |> range(start: 2024-05-06T15:36:26.818Z, stop: 2024-05-07T15:36:26.818Z) |> filter(fn: (r) => r["_measurement"] == "0_userdata.0.PV.SignedBat") |> pivot(rowKey:["_time"], columnKey: ["_field"], valueColumn: "_value") |> group() |> sort(columns:["_time"], desc: false) |> limit(n: 5000)
Query to execute: from(bucket: "iobroker_short") |> range(start: 2024-05-07T15:36:26.819Z) |> filter(fn: (r) => r["_measurement"] == "0_userdata.0.PV.SignedBat") |> first() |> pivot(rowKey:["_time"], columnKey: ["_field"], valueColumn: "_value")
Send: 5002 of: 5001 in: 130ms

[MCU]

@wolfi913 Und jetzt mal ohne count (bzw. null), da war das Problem aufgetaucht.

[wolfi913]

@mcu sagte in HowTo: Zusatz-Programme fuer jarvis v3:

@wolfi913 Und jetzt mal ohne count (bzw. null), da war das Problem aufgetaucht.

Incoming message getHistory from system.adapter.javascript.0
0_userdata.0.PV.SignedBat17150967602230.6250690538939112 getHistory message: {"id":"0_userdata.0.PV.SignedBat","options":{"start":1715010356877,"end":1715096756877,"aggregate":"onchange","limit":5000,"ignoreNull":true,"count":null}}
Query to execute: from(bucket: "iobroker_short") |> range(start: 2024-05-06T15:45:56.877Z, stop: 2024-05-07T15:45:56.877Z) |> filter(fn: (r) => r["_field"] == "value") |> filter(fn: (r) => r["_measurement"] == "0_userdata.0.PV.SignedBat" and contains(value: r._value, set: [true, false])) |> pivot(rowKey:["_time"], columnKey: ["_field"], valueColumn: "_value") |> group()
Query to execute: from(bucket: "iobroker_short") |> range(start: 2024-02-04T15:45:56.877Z, stop: 2024-05-06T15:45:56.876Z) |> filter(fn: (r) => r["_measurement"] == "0_userdata.0.PV.SignedBat") |> last() |> pivot(rowKey:["_time"], columnKey: ["_field"], valueColumn: "_value")
Query to execute: from(bucket: "iobroker_short") |> range(start: 2024-05-06T15:45:56.877Z, stop: 2024-05-07T15:45:56.877Z) |> filter(fn: (r) => r["_measurement"] == "0_userdata.0.PV.SignedBat") |> pivot(rowKey:["_time"], columnKey: ["_field"], valueColumn: "_value") |> group() |> sort(columns:["_time"], desc: false) |> limit(n: 500)
Query to execute: from(bucket: "iobroker_short") |> range(start: 2024-05-07T15:45:56.878Z) |> filter(fn: (r) => r["_measurement"] == "0_userdata.0.PV.SignedBat") |> first() |> pivot(rowKey:["_time"], columnKey: ["_field"], valueColumn: "_value")
Send: 502 of: 501 in: 70ms

[MCU]

@wolfi913 Genau.

Nimm mal bitte count raus:

// count: dataLimitValue

[wolfi913]

@mcu sagte in HowTo: Zusatz-Programme fuer jarvis v3:

@wolfi913 Genau.

Nimm mal bitte count raus:

// count: dataLimitValue

Send: 502 of: 501 in: 70ms
0_userdata.0.PV.SignedBat17150970902550.21461031104686312 getHistory message: {"id":"0_userdata.0.PV.SignedBat","options":{"start":1715010686903,"end":1715097086903,"aggregate":"onchange","limit":5000,"ignoreNull":true}}
Query to execute: from(bucket: "iobroker_short") |> range(start: 2024-05-06T15:51:26.903Z, stop: 2024-05-07T15:51:26.903Z) |> filter(fn: (r) => r["_field"] == "value") |> filter(fn: (r) => r["_measurement"] == "0_userdata.0.PV.SignedBat" and contains(value: r._value, set: [true, false])) |> pivot(rowKey:["_time"], columnKey: ["_field"], valueColumn: "_value") |> group()
Query to execute: from(bucket: "iobroker_short") |> range(start: 2024-02-04T15:51:26.903Z, stop: 2024-05-06T15:51:26.902Z) |> filter(fn: (r) => r["_measurement"] == "0_userdata.0.PV.SignedBat") |> last() |> pivot(rowKey:["_time"], columnKey: ["_field"], valueColumn: "_value")
Query to execute: from(bucket: "iobroker_short") |> range(start: 2024-05-06T15:51:26.903Z, stop: 2024-05-07T15:51:26.903Z) |> filter(fn: (r) => r["_measurement"] == "0_userdata.0.PV.SignedBat") |> pivot(rowKey:["_time"], columnKey: ["_field"], valueColumn: "_value") |> group() |> sort(columns:["_time"], desc: false) |> limit(n: 500)
Query to execute: from(bucket: "iobroker_short") |> range(start: 2024-05-07T15:51:26.904Z) |> filter(fn: (r) => r["_measurement"] == "0_userdata.0.PV.SignedBat") |> first() |> pivot(rowKey:["_time"], columnKey: ["_field"], valueColumn: "_value")
Send: 502 of: 501 in: 64ms

[MCU]

@wolfi913 Ja und das darf laut Programm (main.js iobroker.influxDB) gar nicht passieren.

https://github.com/ioBroker/ioBroker.influxdb/blob/a7214d819f29556d8f1b3e7cf5b4c1d506a1ff1f/main.js#L1964

[wolfi913]

@mcu sagte in HowTo: Zusatz-Programme fuer jarvis v3:

@wolfi913 Ja und das darf laut Programm (main.js iobroker.influxDB) gar nicht passieren.

https://github.com/ioBroker/ioBroker.influxdb/blob/a7214d819f29556d8f1b3e7cf5b4c1d506a1ff1f/main.js#L1964

Scheint also so, dass der Bug im influx-Adapter liegt? Ich stellt auf alle Fälle bei mir momentan mal den Chart auf history um.