NEWS
HowTo: Zusatz-Programme fuer jarvis v3
-
@mcu sagte in HowTo: Zusatz-Programme fuer jarvis v3:
@wolfi913 Passe ich an. Danke.
Super, und nochmal vielen Dank
-
@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 -
@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
-
@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. -
@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?
-
@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.
-
@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.
-
@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ätzlichcount: 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; } }
-
@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
-
@wolfi913 Und jetzt mal ohne count (bzw. null), da war das Problem aufgetaucht.
-
@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
-
@wolfi913 Genau.
Nimm mal bitte count raus:// count: dataLimitValue
-
@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
-
@wolfi913 Ja und das darf laut Programm (main.js iobroker.influxDB) gar nicht passieren.
-
@mcu sagte in HowTo: Zusatz-Programme fuer jarvis v3:
@wolfi913 Ja und das darf laut Programm (main.js iobroker.influxDB) gar nicht passieren.
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. -
@wolfi913 Du könntest nochmal ein Upload für die influxDB versuchen und wieder umstellen auf info, sonst haut es dir das LOG voll.
-
@mcu sagte in HowTo: Zusatz-Programme fuer jarvis v3:
sonst haut es dir das LOG voll.
Hab ich schon umgestellt
-
@mcu
Mir ist gerade zwischendrin im Log noch was aufgefallen. Hatte ich vorher nie gesehen. Denke einwarn
wär mir normalerweise aufgefallenwarn script.js.jarvis.eChartsHistoryGetData: Timeout -> DP 0_userdata.0.PV.SignedBat nicht vorhanden in DB: influxdb.1
Ziemlich sonderbar. Es werden ja scheinbar trotzdem Daten geliefert und der DP ist definitiv in der InfluxDB da.
Ergänzung:
Hab jetzt kurz nochmal auf influx zurückgestellt. Diewarn
ist nicht nochmal aufgetaucht. Trotz mehrmaligem F5.
Möglicherweise tatsächlich nur einmalig vorgekommen. -
@wolfi913 Taucht auch nur als "Hinweis" auf, wenn history-Abfrage einen timeout produziert. Kann auch evtl mit der Anzahl der Werte zusammenhängen?
Hattest du mal ein Upload gemacht um danach nochmal die nur limit für influx zu testen?
iob upload influxdb
-
@mcu
okHattest du mal ein Upload gemacht um danach nochmal die nur limit für influx zu testen?
Mach ich gleich noch, bin nur zwischendrin aufgehalten worden
Upload gemacht und nochmal mitLimit: 5000
ohne Count getestet. Weiterhin nur 502 Werte