@mcu
Das Jahr ist unterschiedlich.
Eingestellt ist 7 Tage Rückwärts; die Abfrage läuft aber START: 2021... STOP 2022
Ja, HistoryGraph geht generell - auch mit nur InfluxDB mit dem :
Hmm, ich teste hier wild rum ...
Spanned ... HGraphen funktionieren mit den Daten von Tado und FritzDect.
Es geht nicht mit den Daten von Shelly und UPNP
Hi,
danke für den WebUntis Adapter!
Anmeldung klappt.
Dann bekomme ich aber :
Was bedeutet die Meldung?
Kann ich das irgendwie lösen?
grüße
Hallo zusammen,
melde mich mit meinem HistoryGraph-Problem zurück.
Symptom:
HistoryGraphen lauf in einen [object][Object] Fehler.
Steps-To-Repro:
Ich habe meine HGraphen inzwischen auf jeweils einen eigenen Tab ausgelagert, um besser testen zu können.
Tabs nacheinander ruhig aufrufen. Die Grafen werden normalerweise beim ersten Aufruf noch sauber erzeugt.
Ein wenig hin und her klicken - ohne große Hektik.
Dann passiert es.
Das spannende ist nun, dass ich das Datum im Fehler beinflussen kann,
indem ich beim InfluxDB Adapter die Vorhaltezeit ändere. (Daher ist das Datum auf den Bildern auch mal 12 und mal 6 Monate zurück.)
Hier die Daten ausm Debug, was mir komisch vorkommt:
# DEBUG-Log von Jarvis & InfluxDB2
2022-01-22 17:35:45.221 - [34mdebug[39m: influxdb.0 (1908) Measurement tado.0.667342.Rooms.4.sensorDataPoints.humidity.percentage is of type Boolean - skipping aggregation options
#
# Hier kommt die Stelle, die verdächtig aussieht.
# Offenbar fragt Jarvis nicht nur die letzten X Tage zurück ab, sondern auch noch den allerersten Datenpunkt vor X Monaten.
# Wenn ich die Vorhaltezeit im Adapter ändere, ändert es sich auch in dieser Fehlermledung.
#
2022-01-22 17:35:45.222 - [34mdebug[39m: influxdb.0 (1908) History-queries to execute:
from(bucket: "iobroker") |> range(start: 2021-07-09T16:35:39.880Z, stop: 2022-01-08T16:35:39.880Z) |> filter(fn: (r) => r["_measurement"] == "tado.0.667342.Rooms.4.sensorDataPoints.humidity.percentage") |> pivot(rowKey:["_time"], columnKey: ["_field"], valueColumn: "_value") |> sort(columns: ["_time"], desc: true) |> group() |> limit(n: 1),
from(bucket: "iobroker") |> range(start: 2022-01-08T16:35:39.880Z, stop: 2022-01-22T16:35:39.880Z) |> filter(fn: (r) => r["_measurement"] == "tado.0.667342.Rooms.4.sensorDataPoints.humidity.percentage") |> pivot(rowKey:["_time"], columnKey: ["_field"], valueColumn: "_value") |> group() |> limit(n: 9999999),
from(bucket: "iobroker") |> range(start: 2022-01-22T16:35:39.880Z) |> filter(fn: (r) => r["_measurement"] == "tado.0.667342.Rooms.4.sensorDataPoints.humidity.percentage") |> pivot(rowKey:["_time"], columnKey: ["_field"], valueColumn: "_value") |> sort(columns: ["_time"], desc: false) |> group() |> limit(n: 1)
# Ausführung Query-Teil I:
2022-01-22 17:35:45.222 - [34mdebug[39m: influxdb.0 (1908) Query to execute:
from(bucket: "iobroker") |> range(start: 2021-07-09T16:35:39.880Z, stop: 2022-01-08T16:35:39.880Z) |> filter(fn: (r) => r["_measurement"] == "tado.0.667342.Rooms.4.sensorDataPoints.humidity.percentage") |> pivot(rowKey:["_time"], columnKey: ["_field"], valueColumn: "_value") |> sort(columns: ["_time"], desc: true) |> group() |> limit(n: 1)
# Fehler bei Ausfürhung Teil I - klar DB existierte ja noch nicht.
2022-01-22 17:35:56.911 - [33mwarn[39m: influxdb.0 (1908) Error in query "
from(bucket: "iobroker") |> range(start: 2021-07-09T16:35:39.880Z, stop: 2022-01-08T16:35:39.880Z) |> filter(fn: (r) => r["_measurement"] == "tado.0.667342.Rooms.4.sensorDataPoints.humidity.percentage") |> pivot(rowKey:["_time"], columnKey: ["_field"], valueColumn: "_value") |> sort(columns: ["_time"], desc: true) |> group() |> limit(n: 1)": RequestTimedOutError: Request timed out
# Ausführung Query-Teil II:
2022-01-22 17:35:56.911 - [34mdebug[39m: influxdb.0 (1908) Query to execute:
from(bucket: "iobroker") |> range(start: 2022-01-08T16:35:39.880Z, stop: 2022-01-22T16:35:39.880Z) |> filter(fn: (r) => r["_measurement"] == "tado.0.667342.Rooms.4.sensorDataPoints.humidity.percentage") |> pivot(rowKey:["_time"], columnKey: ["_field"], valueColumn: "_value") |> group() |> limit(n: 9999999)
# Ausführung Query-Teil III:
2022-01-22 17:35:58.792 - [34mdebug[39m: influxdb.0 (1908) Query to execute: from(bucket: "iobroker") |> range(start: 2022-01-22T16:35:39.880Z) |> filter(fn: (r) => r["_measurement"] == "tado.0.667342.Rooms.4.sensorDataPoints.humidity.percentage") |> pivot(rowKey:["_time"], columnKey: ["_field"], valueColumn: "_value") |> sort(columns: ["_time"], desc: false) |> group() |> limit(n: 1)
2022-01-22 17:36:00.454 - [33mwarn[39m: jarvis.0 (1876) [object Object]
# Daten erhalten von Query-Teil II:
2022-01-22 17:35:59.614 - [34mdebug[39m: influxdb.0 (1908) Parsing retrieved rows:[
[],
[{"result":"_result","table":0,"_start":"2022-01-08T16:35:39.88Z","_stop":"2022-01-22T16:35:39.88Z","_time":"2022-01-08T16:35:50.919Z","_measurement":"tado.0.667342.Rooms.4.sensorDataPoints.humidity.percentage","ack":true,"from":"system.adapter.influxdb.0","q":0,"value":44.5,"time":"2022-01-08T16:35:50.919Z"},
{"result":"_result","table":0,"_start":"2022-01-08T16:35:39.88Z","_stop":"2022-01-22T16:35:39.88Z","_time":"2022-01-08T16:36:50.92Z","_measurement":"tado.0.667342.Rooms.4.sensorDataPoints.humidity.percentage","ack":true,"from":"system.adapter.influxdb.0","q":0,"value":44.5,"time":"2022-01-08T16:36:50.92Z"},
...
{"result":"_result","table":0,"_start":"2022-01-08T16:35:39.88Z","_stop":"2022-01-22T16:35:39.88Z","_time":"2022-01-22T16:29:11.726Z","_measurement":"tado.0.667342.Rooms.4.sensorDataPoints.humidity.percentage","ack":true,"from":"system.adapter.tado.0","q":0,"value":39.7,"time":"2022-01-22T16:29:11.726Z"}],[]]
# Daten Rückmeldung an Jarvis:
2022-01-22 17:35:59.936 - [34mdebug[39m: influxdb.0 (1908) sendTo "getHistory" to system.adapter.jarvis.0 from system.adapter.influxdb.0
.
Hat jemand eine Idee?
grüße
@zefau said in jarvis v3.0.0 - just another remarkable vis:
te die Instanz au
Jarvis-Adapter:Debug + InfluxDB-Adapter:-Info
Jarvis-Adapter: Debug + InfluxDB-Adapter: Debug
Hier könnte das Problm liegen:
{"aggregate":"none","force":true,"review":604800000,"step":3600,"count":9999999,"instance":"influxdb.0"}
604800000 sind laut Epoch Konverter 700 Tage - nicht 7 Tage - 00 zuviel?
@mcu
ok, ich test noch einen Tag und dann öffne ich einen Issue-Report.
Danke für die prompte Reaktion.
@wiki
ok, zu früh gefreut:
Wenn ich die anderen HistoryGraphen für Tado aktiviere, bekomme ich die selben Probleme.
Ist es möglich, dass Jarvis bei vielen Datenpunkt-Abfragen das Jahr falsch setzt?
@mcu
Das Jahr ist unterschiedlich.
Eingestellt ist 7 Tage Rückwärts; die Abfrage läuft aber START: 2021... STOP 2022
Ja, HistoryGraph geht generell - auch mit nur InfluxDB mit dem :
Hmm, ich teste hier wild rum ...
Spanned ... HGraphen funktionieren mit den Daten von Tado und FritzDect.
Es geht nicht mit den Daten von Shelly und UPNP
@mcu
@mcu said in jarvis v3.0.0 - just another remarkable vis:
@wiki Wurden die Einträge zum HistoryGraph von Dir verändert nach dem Upgrade (v2->v3) oder durch den Converter v2-> v3 erstellt?
Die History-Graphen wurden zunächst vom Konverter automatisch angelegt.
Dann ging kein Graph mehr.
Dann habe ich einige History-Widgets und Graphen gelöscht, da ich vermutete, dass ich zuviel Last erzeuge (wg. Timeout).
Auch mit neu angelegten History-Graphen tritt das Problem auf.
Hallo,
hoffe bin richtig hier mit meinem Problemchen.
IObroker, InfluxDB2 - Docker-based bei mir.
Jarvis 3.0.7 installiert (kommende von v2.2)
Im Prinzip läuft alles gut mit Jarvis (Jarvis ist TOP!); leider habe ich Probleme mit dem History-Graphen.
(In v2.2 gabs auch schon Symptome, aber mit v3 wurde es nun ganz schlimm, so daß ich die meisten Graphen nicht mehr nutzen kann)
Die Query für die History scheint nicht eingestellte Werte abzufragen, bekommt dann einen Timeout, und rendert den Graphen dann nicht.
Ggf. mache ich auch was falsch. Wäre für jeden Tipp dankbar.
Herzliche Grüße.
