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

[wolfi913]

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

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

Funktioniert auf Anhieb :blush: :+1:
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.

[MCU]

@wolfi913 Du könntest nochmal ein Upload für die influxDB versuchen und wieder umstellen auf info, sonst haut es dir das LOG voll.

[wolfi913]

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

sonst haut es dir das LOG voll.

Hab ich schon umgestellt

[wolfi913]

@mcu
Mir ist gerade zwischendrin im Log noch was aufgefallen. Hatte ich vorher nie gesehen. Denke ein warn wär mir normalerweise aufgefallen

warn	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. Die warn ist nicht nochmal aufgetaucht. Trotz mehrmaligem F5.
Möglicherweise tatsächlich nur einmalig vorgekommen.

[MCU]

@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

[wolfi913]

@mcu
ok :+1:

Hattest 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 mit Limit: 5000 ohne Count getestet. Weiterhin nur 502 Werte

[MCU]

@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

[wolfi913]

@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.

[apollon77]

@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