NEWS
HowTo: Zusatz-Programme fuer jarvis v3
-
@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 -
@wolfi913 Problem erkannt. Der Adapter setzt schon selbst count auf 500
https://github.com/ioBroker/ioBroker.influxdb/blob/a7214d819f29556d8f1b3e7cf5b4c1d506a1ff1f/main.js#L1978
und fragt noch ab, ob options.count gesetzt wurde.
https://github.com/ioBroker/ioBroker.influxdb/blob/a7214d819f29556d8f1b3e7cf5b4c1d506a1ff1f/main.js#L1995
Ist es damit aber schon und somit geht er gar nicht in die entscheidende Abfrage.Issue aufgemacht:
https://github.com/ioBroker/ioBroker.influxdb/issues/391 -
@mcu
Dann schauen wir mal ob sich da im Adapter was ändert. Ich bleib ich momentan mal für den Chart auf der historyDB. Wenn sich im influx-Adapter was Neues tut kann ich ja nochmal durchprobieren. -
@mcu Da gibts brlaube ein known issue in influxdb adapter ... kam ich bisher noch nicht dazu final zu fixen ... Bitte mal schauen obs da sgleiche oder was anderes ist
-
@apollon77 Ich hatte den Issue dort eingetragen nachdem ich den Fehler feststellen konnte.
https://github.com/ioBroker/ioBroker.influxdb/issues/391 -
@mcu Cool, auch danke für die Infos und Links. Willst du mal Fix versuchen und PR machen wenn Du die stelle und Vergleich zu History schon hast? Oder soll ich schauen das ich die tage zeit finde?
-
@apollon77 Gibt es igrendwo eine Anleitung dazu, wie man ein PR erstellt?
Gefunden:
https://www.youtube.com/watch?v=l8MZCnrSeQQ