Der neue Monatsrückblick für September 2026 ist online!

[stenmic]

@Bluefox sagte:

Es wäre toll den Script z.B. "Pflanzen.Palme_Diagram_Temperatur" zu haben um zu verstehen, was da gewollte ist

Es ist ein Univertsalskript mit ich dem eine json für meine Diagramme zusammensetze.
Datenquelle ist influxDB2. Davon habe ich ca. 140 Skripte.

Meine Diagramme sind "Materialdesign JSON Chart"
.

Leider zu viele Zeilen fürs Forum, deshalb externer Link

als Blockly (txt)

als konvertiertes Javaskript (txt)

Komisch ist, die Skripte laufen perodisch, oft ohne Fehlermledung.
Im Log von influx gibt es keine (info) Ausgabe.
Kann im Moment auch nix prüfen, da ich zurück auf 4.0.2 gegangen bin.

[Bluefox]

@stenmic Mit InfluxDB 2.x passt das genau zu https://github.com/ioBroker/ioBroker.influxdb/issues/551. Der Adapter hat einen Timeout vom Server als Verbindungsabbruch gewertet und sich neu verbunden. Nur in diesem kurzen Zeitraum schlägt getHistory fehl. Deshalb laufen deine Skripte meistens ohne Fehler und knallen nur ab und zu.

Der Fix ist in influxdb 5.1.7, die schon auf npm bzw. im Latest-Repo ist. Bitte aktualisieren und schauen, ob die Fehler weg sind.

Unabhängig davon würde ich in den Skripten die Antwort trotzdem prüfen, bevor .map aufgerufen wird (siehe mein Beispiel oben). Wenn InfluxDB mal nicht erreichbar ist, kommt sonst immer dieser TypeError statt einer verständlichen Meldung. Wenn du dabei Hilfe brauchst, poste bitte hier direkt die paar Zeilen um Zeile 98 aus dem JavaScript als Code-Block.

[stenmic]

@Bluefox diese Abfrage habe ich mir vor ein paar jahren gebastelt.

	if (ConfigError == 0) {
		return new Promise((resolve, reject) => {
		sendTo('influxdb.0', 'query', settings, function (query) {
			if (query.error) {
				console.error(query.error);
			} else if (Start == Aggregation) {
					Ergebnis = query.result[0][0]._value;
					resolve(Ergebnis);
			} else {
                                        Ergebnis = query.result[0].map(elm => ({
					t: (elm.ts !== null && elm.ts !== undefined) ? elm.ts : null,
					y: (elm._value !== null && elm._value !== undefined) ? elm._value : null
					}));
					resolve(Ergebnis);
			}
        })
		})
	} else if (ConfigError == 1) {
		console.error("Diese Einstellungen sind leider nicht möglich");
        return('Fehler');
	} else if (ConfigError == 2) {
		console.error("Diese Buckets gibt es nicht");
        return('Fehler');
	}

mir ist leider nicht klar, wie ich deinen Vorschlag hier einbauen kann.

so?
if (!query|| query.error || !query.result)

[Bluefox]

@stenmic Ja, genau so. Ich würde aber noch zwei Sachen dazu ändern:

1. Im Fehlerfall wird dein Promise im Moment nie aufgelöst. Das await dahinter wartet dann ewig. Also auch dort resolve (oder reject) aufrufen.
2. Auch wenn kein Fehler kommt, kann query.result[0] leer sein, z. B. wenn es im Zeitraum keine Daten gibt. Das sollte man ebenfalls prüfen.

So etwa:

sendTo('influxdb.0', 'query', settings, function (query) {
    if (!query || query.error || !query.result || !query.result[0]) {
        console.warn(`InfluxDB-Abfrage fehlgeschlagen: ${query && query.error ? query.error : 'keine Daten'}`);
        resolve(Start == Aggregation ? null : []);
        return;
    }
    if (Start == Aggregation) {
        Ergebnis = query.result[0][0] ? query.result[0][0]._value : null;
        resolve(Ergebnis);
    } else {
        Ergebnis = query.result[0].map(elm => ({
            t: (elm.ts !== null && elm.ts !== undefined) ? elm.ts : null,
            y: (elm._value !== null && elm._value !== undefined) ? elm._value : null
        }));
        resolve(Ergebnis);
    }
});

Schau bitte noch, was dein Skript danach mit dem Ergebnis macht. Kann es mit einem leeren Array bzw. null umgehen? Sonst wird das JSON fürs Diagramm nicht geschrieben, und das Diagramm bleibt bis zum nächsten Lauf einfach auf dem alten Stand. Das ist meistens das, was man will.

Wenn du wieder auf influxdb 5.1.7 gehst, sollten die Fehler wegen #551 ohnehin weg sein. Mit der Prüfung siehst du im Log dann aber gleich eine verständliche Meldung, falls InfluxDB mal nicht erreichbar ist.

[stenmic]

@Bluefox mit 5.1.7 und deinen Anpassungen am Script gibt es keine Fehler mehr, ansonsten würde auch ein Fehler bei “Zeitbereich keine Daten“ kommen, DANKE. Für mich zum Verständnis, der Fehler war schon immer da, wurde aber mit der 4er nie angezeigt? Sorry, wenn ich auch ein starker Kritiker bin, ich schätze Eure Arbeit wirklich sehr. Ich hab nur auch viel um die Ohren und verlasse mich auf die stable Versionen. Bin auch aufgeschlossen Sachen zu testen, wenn diese Ersichtlich sind. Das ist leider nicht immer der Fall. Wie gesagt, danke ( und der neue Admin ist gelungen ) jetzt muss nur noch vis2 die Performance von vis1 bekommen 🙈

[cash]

@stenic ja stabile Versionen sind gut und wichtig aber das gilt auch für eigene Scripte. Scripte sollen nicht nur funktionieren sondern auch robust sein und auf fehler vorbereitet sein. Ich habe die letzten Wochen in vielen meiner Scripte genau das also eine Fehlerbehandlung eingebaut, weil ich dort am Anfang sehr schlampig war und nur den Funktionsfall erstellt habe. Wenn man sich nicht mehr intensiv um das Hobby ioBroker kümmern kann weil die Zeit fehlt finde ich es besonders wichtig.

[Bluefox]

@stenmic Schön, dass es jetzt läuft.

Zu deiner Frage: Es waren zwei Dinge.

• Der eigentliche Auslöser war der Fehler in influxdb 5.1.6 (#551). Der Adapter hat einen Timeout vom Server als Verbindungsabbruch gewertet und sich neu verbunden. In diesem kurzen Zeitraum ist deine Abfrage fehlgeschlagen. Mit 4.0.2 ist dieser Fall im Normalbetrieb praktisch nie vorgekommen, deshalb hast du nie etwas gesehen.
• Die fehlende Prüfung im Skript gab es dagegen schon immer. Wäre InfluxDB mit 4.x mal nicht erreichbar gewesen (Neustart, Update, Netzwerk), hättest du denselben TypeError bekommen.

Die Meldung "keine Daten" kommt jetzt einfach, wenn im abgefragten Zeitraum wirklich nichts in der Datenbank steht. Wenn sie dich stört, kannst du sie bei diesem Fall von console.warn auf console.debug ändern.

Danke für das Feedback zum Admin. Wenn du bei vis-2 konkrete Views oder Widgets hast, die deutlich langsamer sind als in vis 1, mach dazu bitte ein eigenes Thema oder ein Issue mit einem Beispiel. Dann können wir uns das gezielt anschauen.

[Asgothian]

@stenmic sagte:

@Bluefox mit 5.1.7 und deinen Anpassungen am Script gibt es keine Fehler mehr, ansonsten würde auch ein Fehler bei “Zeitbereich keine Daten“ kommen, DANKE. Für mich zum Verständnis, der Fehler war schon immer da, wurde aber mit der 4er nie angezeigt? Sorry, wenn ich auch ein starker Kritiker bin, ich schätze Eure Arbeit wirklich sehr. Ich hab nur auch viel um die Ohren und verlasse mich auf die stable Versionen. Bin auch aufgeschlossen Sachen zu testen, wenn diese Ersichtlich sind. Das ist leider nicht immer der Fall. Wie gesagt, danke ( und der neue Admin ist gelungen ) jetzt muss nur noch vis2 die Performance von vis1 bekommen 🙈

Der Punkt den ich auch im anderen Thread gemacht habe ist der folgende:

Jeder Nutzer würde den Entwicklern sehr helfen, wenn er

• immer mal wieder schaut was es im Beta an Adaptern gibt
• wenn bei den Beta Versionen keine breaking changes angemahnt werden versucht die Beta Version zu installieren und für etwas Zeit laufen lässt
• bei Auffälligkeiten diese im Forum oder auf GitHub meldet.
• Nach dem Test wieder die Stable Version installiert (damit das Produktivsystem nicht länger gestört wird).

Oder alternativ ein reduziertes Testsystem nutzt - klar, das verursacht Kosten - aber weniger als man gemeinhin denkt.

Wichtig ist dabei nicht “besondere” Tests durchzuführen, sondern einfach nur zu schauen wie sich der Adapter in Deiner Umgebung verhält.

A.

[stenmic]

@Asgothian man muss aber auch die Chance haben mitzumachen. Beispiel. ich habe nix von Admin, Javascript, influx Entwicklungen mitbekommen, obwohl ich schon viel im Forum unterwegs bin, auf git schau ich nicht, auf einmal kamen die Updates rein, und ich war die letzten 3 Tage beschäftigt. Wie schon geschrieben, ich danke euch allen, die aktiv Adapter unterhalten. Aber in der letzten Zeit sind die Forenbeiträge eher zermürbend.

[stenmic]

@Bluefox sagte:

@stenmic Schön, dass es jetzt läuft.

Zu deiner Frage: Es waren zwei Dinge.

• Der eigentliche Auslöser war der Fehler in influxdb 5.1.6 (#551). Der Adapter hat einen Timeout vom Server als Verbindungsabbruch gewertet und sich neu verbunden. In diesem kurzen Zeitraum ist deine Abfrage fehlgeschlagen. Mit 4.0.2 ist dieser Fall im Normalbetrieb praktisch nie vorgekommen, deshalb hast du nie etwas gesehen.
• Die fehlende Prüfung im Skript gab es dagegen schon immer. Wäre InfluxDB mit 4.x mal nicht erreichbar gewesen (Neustart, Update, Netzwerk), hättest du denselben TypeError bekommen.

Die Meldung "keine Daten" kommt jetzt einfach, wenn im abgefragten Zeitraum wirklich nichts in der Datenbank steht. Wenn sie dich stört, kannst du sie bei diesem Fall von console.warn auf console.debug ändern.

Danke für das Feedback zum Admin. Wenn du bei vis-2 konkrete Views oder Widgets hast, die deutlich langsamer sind als in vis 1, mach dazu bitte ein eigenes Thema oder ein Issue mit einem Beispiel. Dann können wir uns das gezielt anschauen.

ich habe vis2 vor langer Zeit getestet, war positiv eingestellt. Dann hatte ich die üble Performance bei Bindings angesprochen. https://forum.iobroker.net/topic/75324/bindings-extrem-verzögert-in-vis2?_=1792689270032
Da ich damals nur “Negativen“ Feedback bekommen habe, war vis2 für mich gestorben. Zudem möchte ich auf das beste Widget „Material Design“ nicht verzichten, wobei daran ja gearbeitet wird. Ja, vielleicht könnte man es heute mit den sehr vielen Bindings bei mir vielleicht anders lösen, aber muss ich das, wenn’s mit der alten Version perfekt läuft.

[Bluefox]

@stenmic Den Thread habe ich mir angeschaut. Da hat damals leider niemand aus der Entwicklung reingeschaut, und das Thema ist in eine Diskussion abgedriftet statt in eine Analyse. Das ist nicht gut gelaufen.

Wenn vis 1 bei dir gut läuft, musst du natürlich nicht wechseln. Falls du vis-2 irgendwann noch mal eine Chance geben willst: Nimm eine View, bei der die Bindings spürbar verzögert sind, exportiere sie und stell sie zusammen mit der vis-2-Version in ein neues Thema oder ein Issue unter https://github.com/ioBroker/ioBroker.vis-2/issues. Mit einem konkreten Beispiel können wir das nachstellen und gezielt messen. Seit 2.9.32 hat sich in vis-2 einiges getan.

[stenmic]

@Bluefox
Eine Anmerkung zum influx Adapter habe ich noch.

Ich habe viele Datenpunkte, wo ich in den Einstellungen bewusst
"trotzdem gleiche Werte aufzeichnen (Sekunden)“ eingestellt habe.
Hier möchte ich dauerhaft in einem Intervall Daten speichern.
Hier sind viele Datenpunkte dabei, die sich selten ändern.

Dann habe ich Datenpunkte, bei denen ich nur Änderungen aufzeichnen ohne Intervall gesetzt habe.
"Dupletten" bei diesen Datenpunkten, würden bei mir fehlerhafte Ergebnisse bei Berechnungen später in Javaskript erzeugen.

Deshalb habe ich in den Einstellungen vom Adapter „Den letzten Wert erneuert beim Start protokolieren“ deaktiviert.

Bei einem System Neustart, greifen dann aber die gewünschten Intervalle nicht, bei den Datenpunkten wo ich „trotzdem gleiche Werte aufzeichnen (Sekunden)“ eingestellt habe.
Das Intervall beginnt dann erst, wenn der Wert mal aktualisiert oder geändert wird (man muss es also anschupsen)

Ich helfe mir aktuell so, dass ich beim Neustart über Javaskript bei allen Datenpunkten, die ein Intervall haben, den Wert mit sich selbst aktualisiere.

Keine schöne Lösung, aber ich lebe damit. Aber eventuell kann man da was optimieren.

Das “Problem“ gibt es schon sehr lange, hat nix mit der 5er Version zu tun.
Verstehst du, was ich meine?

[Bluefox]

@stenmic sagte:
Das “Problem“ gibt es schon sehr lange, hat nix mit der 5er Version zu tun.
Verstehst du, was ich meine?

Hallo @stenmic,

zu deiner letzten Frage: Das ist tatsächlich ein Fehler im Adapter, danke für den Hinweis.

Das Intervall bei „trotzdem gleiche Werte aufzeichnen (Sekunden)“ läuft bisher erst, nachdem der Adapter einen Wert geschrieben hat. Nach einem Neustart gibt es zwei Fälle:

• „Den letzten Wert erneut beim Start protokollieren“ ist an (in den Instanz-Einstellungen, standardmäßig aktiv): Der aktuelle Wert wird beim Start geschrieben, und das Intervall startet sofort.
• Die Option ist aus: Das Intervall startet erst mit dem ersten Update des Datenpunkts. Bei selten aktualisierten Werten fehlt dann lange nichts geloggt. Dasselbe passiert übrigens, nachdem man die Einstellungen eines Datenpunkts ändert und speichert.

Ab sofort helfen: Schalte in der Instanz die Option „Den letzten Wert erneut beim Start protokollieren“ ein. Dann brauchst du dein Skript nicht mehr, das die Werte beim Start neu schreibt.

Fix: Das Intervall startet künftig direkt beim Start, auch wenn die Option aus ist. Der erste Wert wird dann nach Ablauf des Intervalls geschrieben. Der Fix steckt in https://github.com/ioBroker/ioBroker.influxdb/pull/563 und kommt mit der nächsten Version.

[Bluefox]

Hallo @stenmic,

zu deiner letzten Frage: Das war tatsächlich ein Fehler im Adapter, danke für den Hinweis.

Das Intervall bei „trotzdem gleiche Werte aufzeichnen (Sekunden)“ lief bisher erst, nachdem der Adapter einen Wert geschrieben hatte. Nach einem Neustart hing es deshalb von der Instanz-Einstellung „Den letzten Wert erneut beim Start protokollieren“ ab:

• Option an: Der aktuelle Wert wurde beim Start geschrieben, und das Intervall lief sofort los.
• Option aus: Das Intervall startete erst mit dem ersten Update des Datenpunkts. Bei selten aktualisierten Werten wurde dann lange nichts geloggt. Dasselbe passierte, nachdem man die Einstellungen eines Datenpunkts geändert und gespeichert hatte.

Ab Version 5.1.8 startet das Intervall direkt beim Start, auch wenn die Option aus ist. Der erste Wert wird dann nach Ablauf des Intervalls geschrieben. Die Version ist veröffentlicht und kommt wie üblich zuerst über das Beta/Latest-Repository. Details: https://github.com/ioBroker/ioBroker.influxdb/pull/563

Nach dem Update brauchst du dein Skript, das die Werte beim Start neu schreibt, nicht mehr. Bis dahin hilft es auch, die Option „Den letzten Wert erneut beim Start protokollieren“ einzuschalten.

Falls die Option bei dir schon an war und das Verhalten trotzdem auftritt, ist es ein anderes Problem. Dann schick mir bitte die Einstellungen eines betroffenen Datenpunkts und ein Debug-Log vom Adapterstart.

[stenmic]

@Bluefox
Ich hoffe du (oder deine KI :) hast mich nicht falsch verstanden.

Bis dahin hilft es auch, die Option „Den letzten Wert erneut beim Start protokollieren“ einzuschalten.

„Den letzten Wert erneuert beim Start protokolieren“ habe ich bewust deaktiviert.
Bei mir dürfen auf keinen Fall alle Datenpunkte pauschal beim Start erneuert werden.

Es geht mir nur um die Datenpunkte die ein Interval in den Einstellungen haben > "trotzdem gleiche Werte aufzeichnen (Sekunden)“.
Diese müssen bei mir nach dem Start (leider aktuell manuell) erneuert werden, da viele über längeren Zeit keine Änderungen bekommen.

Aber wenn ich deinen letzten Post richtig gelesen habe, hat die Version 5.1.8 genau dieses Verhalten, oder?
Mir ist nur sehr wichtig, dass nicht pauschal alle Datenpunkte aktualisiert werden.

Gruß Micha

[Bluefox]

@stenmic sagte:

@Bluefox
Ich hoffe du (oder deine KI :) hast mich nicht falsch verstanden.

Bis dahin hilft es auch, die Option „Den letzten Wert erneut beim Start protokollieren“ einzuschalten.

„Den letzten Wert erneuert beim Start protokolieren“ habe ich bewust deaktiviert.
Bei mir dürfen auf keinen Fall alle Datenpunkte pauschal beim Start erneuert werden.

Es geht mir nur um die Datenpunkte die ein Interval in den Einstellungen haben > "trotzdem gleiche Werte aufzeichnen (Sekunden)“.
Diese müssen bei mir nach dem Start (leider aktuell manuell) erneuert werden, da viele über längeren Zeit keine Änderungen bekommen.

Aber wenn ich deinen letzten Post richtig gelesen habe, hat die Version 5.1.8 genau dieses Verhalten, oder?
Mir ist nur sehr wichtig, dass nicht pauschal alle Datenpunkte aktualisiert werden.

Gruß Micha

Doch ICH habe dich so verstanden, dass nach dem Start keine Werte beschrieben wurden (die regelmäßig geschrieben werden müssen). Wo ist der Unterschied, dass du z.B. einen Wert alle 5 Minuten schreibst, und dann einen gleichen Wert nach 2 Minuten und dann wieder nach 5 Minuten erschient (nach dem Start)? Du kannst doch nicht die Instanz genau dann starten, dass deine Intervalle immer 5 Minuten sind.

[stenmic]

@Bluefox sorry… verstehe deine Antwort nicht. wo hab ich was von 5 bzw. 2 min geschrieben. Mir ist nur sehr wichtig, dass nicht pauschal alle Datenpunkte aktualisiert werden. Schönen Abend.

[Bluefox]

@stenmic sagte:

@Bluefox sorry… verstehe deine Antwort nicht. wo hab ich was von 5 bzw. 2 min geschrieben.

Das habe ich als Beispiel benannt. Worum ist für dich einmal Wert ganz am Anfang schreiben - schlecht? Du hast doch sogar selbst über Blockly das gemacht.

[stenmic]

@Bluefox sorry, wie oft soll ich es noch schreiben! weil ich dann falsche berechnungen über Zeiträume bekomme.

[stenmic]

@Bluefox sagte:

@stenmic sagte:

@Bluefox sorry… verstehe deine Antwort nicht. wo hab ich was von 5 bzw. 2 min geschrieben.

Das habe ich als Beispiel benannt. Worum ist für dich einmal Wert ganz am Anfang schreiben - schlecht? Du hast doch sogar selbst über Blockly das gemacht.

ich habe das blockly nur für die Datenpunkte mit Intervall geschrieben. NICHT FÜR ALLE