Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[Laser]

@mickemup Diese beiden Zeiten standen defaultmäßig drin. Aus reiner Nachlässigkeit habe ich die stehen gelassen. Ich habe die nicht aktiv eingetragen. Diese Zeiten brauche ich bei Sensoren, die immer mal Störimpulse generieren. Hier ist das absolut überflüssig. Trotzdem möchte ich wissen, ob das der Fehler war.

[mickemup]

@Laser
Ok dann probiers aus.
Falls es nicht (nur) das war, dann irgendeine von deinen Code-Anpassungen...

Bei mir ist da nichts defaultmässig drin, aber eventuell übernimmt es einfach die Settings vom letzten Setup eines loggens...

[Laser]

@mickemup im influxDB Adapter kann man "Standardeinstellungen" festlegen. Das habe ich getan. Was von Haus aus drinstand, weiß ich jetzt nicht mehr. Am Code habe ich eigentlich nichts angepaßt. Der war in Ordnung. Nur die Speichervariablen von Zustandstyp "boolean" auf "Zahl" geändert. Was aber scheinbar nicht funktioniert hat. Oder ich habe dabei einen Fehler gemacht. Danach habe ich diese Variablen gelöscht und als "Zahl" neu angelegt. Erst dann waren die vielen Warnungen verschwunden.
Ergänzung: Ich bin erst mal froh, daß die vereinfachte Steuerung den Brennerverschleiß minimiert. Das ist die Hauptaufgabe gewesen. Der Code vorher war zu kompliziert. Er ist schon stark vereinfacht. Auch wenn jetzt noch Feinheiten möglich sind.

[Laser]

@mickemup @homoran Der erste Test mit Veränderungen im influxDB Adapter lief ja erfolgreich durch.
Das war: "nur Änderungen" - Haken nicht gesetzt. Entprellzeit: 200 Blockzeit:500
Jetzt werde ich die beiden Zeiten auf 0 setzen und abwarten.

[mickemup]

@laser
Also sind wir jetzt ernsthaft wieder bei Post 1 angelangt, einfach mit anderen Zeiten?
Und das hat nun funktioniert?

[Laser]

@mickemup Nein, es geht nicht wieder von vorn los. Der Unterschied ist ja schon mal, daß es keine Fehler mehr gibt. Und daß jetzt eine Änderung nach der Anderen (einzeln, nicht Alles zusammen) vorgenommen wird. Die Nächste Änderung (morgen) wird sein, den Haken bei "Nur Änderungen" zu setzen.

[Homoran]

@mickemup

@Laser sagte in InfluxDB schreiben nur Änderungen:

Hatte ich auch schon Alles draußen. Es wird noch ein Fehler im InfluxDB Adapter sein. Speziell bei der Funktion "Nur Änderungen" . Möglicherweise werden Binärzustände nicht so oft gespeichert, so daß das noch nicht aufgefallen ist? Vor Jahren hat das schon mal Jemand bemängelt.

[Laser]

@homoran Es wäre ja erfreulich, wenn der Adapter keinen offensichtliche Fehler hat. Daß es hier ein Problem geben könnte habe nicht ich in die Welt gesetzt, sondern der Thread- Ersteller vor Jahren für möglich (!) gehalten. Ich habe das gelesen und einen ähnlich gearteten Fehler bei mir bemerkt. An diesen Thread habe ich mich angehangen. Meine Ausführungen wurden dann von dort abgespalten und ein neuer Thread aufgemacht.

[mickemup]

@Laser sagte in InfluxDB schreiben nur Änderungen:

@mickemup @homoran Der erste Test mit Veränderungen im influxDB Adapter lief ja erfolgreich durch.
Das war: "nur Änderungen" - Haken nicht gesetzt. Entprellzeit: 200 Blockzeit:500
Jetzt werde ich die beiden Zeiten auf 0 setzen und abwarten.

Das ist doch genau das Setting von Anfang...

Was willst du den nun erreichen mit dem umstellen?

Beschreibe den ist Zustand
Beschreibe den gewünschten Sollzustand

[Laser]

@mickemup ich möchte ausschließen, daß ein Eintrag in diesen Zeiten etwas negatives für meinen Fall bewirkt. Da es absolut keinen Aufwand bedeutet, kann ich das doch machen?
Am Ende soll herauskommen: die Zeiten auf Null, "Nur Änderungen " angehakt.
Das nächste Problem bei "Nur Änderungen" sind die "trotzdem schreiben" Zeit (geringstes Problem) und die "minimale Differenz" bei meinen möglichen Werten von 0 und 1.

[Homoran]

@Laser sagte in InfluxDB schreiben nur Änderungen:

daß ein Eintrag in diesen Zeiten etwas negatives für meinen Fall bewirkt.

Das macht es nur, wenn im Vorfeld dein Konstrukt Blödsinn macht und dadurch das Logging verhindert.

@mickemup sagte in InfluxDB schreiben nur Änderungen:

Das Blocken könnte das Feedback vom rpi2.0 geblockt haben, da dies ja kurz auf deinen Steuerinput folgt.

Und höchstwahrscheinlich noch falsche Typen unterwegs waren, was wir mangels exakter Fehlermeldung nie erfahren werden.

[mickemup]

@Laser sagte in InfluxDB schreiben nur Änderungen:

Das nächste Problem bei "Nur Änderungen" sind die "trotzdem schreiben" Zeit (geringstes Problem) und die "minimale Differenz" bei meinen möglichen Werten von 0 und 1.

Da gibt es kein "Problem", ausser du willlst dir eins kreieren...
Alles leer lassen und Haken setzen (bei nur Aenderungen).

Wieder:
Beschreibe den ist Zustand
Beschreibe den gewünschten Sollzustand?

Nachtrag: Du bist nicht der erste Mensch, der Zahlen (1 und 0 ) in eine DB schreibt.
Du kannst da schon rumdoktern, aber wenn du was dabei lernen willst mach dir einen "Plan" mit einem "Ziel

[Laser]

@Homoran sagte in InfluxDB schreiben nur Änderungen:

Das Blocken könnte das Feedback vom rpi2.0 geblockt haben, da dies ja kurz auf deinen Steuerinput folgt.

Scheinbar wurde das Feedback aber nicht geblockt oder verhindert. Es kam ja.
Und ich möchte mich auch dafür bedanken, daß ich hier auf die Tabelle aufmerksam gemacht wurde. Das wird mir in Zukunft helfen. Ich möchte auch Niemanden etwas "in die Schuhe Schieben". Zu 99 % (100) lag der Fehler bei mir. Ich vermute, die Datentypen haben das Problem gebracht.
Für Binärzustände würde ich eigentlich den Typ "boolean" bevorzugen. Hatte ich im Ursprungszustand auch für alle Merker so gehabt und erst unmittelbar vor dem Datenbank-Schreiben den Alias zur Typenumwandlung angewendet. Dabei kam es zu den Aussetzern bei den Schreibvorgängen. Wie auch immer, es funktioniert jetzt. Auch wenn ich nicht weiß, was nun der Fehler war. Aber wieder von vorn anfangen wird es nicht geben.
Was trage ich denn nun sinnvoll bei "minimale Differenz zum letzten Wert" ein? Null, um die Prüfung zu deaktivieren?

[Homoran]

@Laser sagte in InfluxDB schreiben nur Änderungen:

Was trage ich denn nun sinnvoll bei "minimale Differenz zum letzten Wert" ein? Null, um die Prüfung zu deaktivieren?

das sollte dort stehen!
musst du mal lesen

[Laser]

@homoran Da steht: "null, um die Prüfung zu deaktivieren". Kann ich auf die Prüfung verzichten oder bringt Die mir einen Nutzen? Für analoge Meßwerte ist das ja sinnvoll.

[Homoran]

@Laser sagte in InfluxDB schreiben nur Änderungen:

Da steht: "null, um die Prüfung zu deaktivieren"

wirklich null oder 0??

[Laser]

@homoran Bitte jetzt keine Leseschwäche ins Spiel bringen. Es war ja auch kein Zitat. Nur sinngemaß.
Minimale Differenz zum letzten Wert
0
0 = Abweichungsprüfung deaktivieren

[Homoran]

@Laser sagte in InfluxDB schreiben nur Änderungen:

Bitte jetzt keine Leseschwäche ins Spiel bringen.

das hat damit nichts zu tun!
Das ist ein gewaltiger Unterschied!
null entspricht "kein Wert", während 0 eine Zahl ist.

[Homoran]

@Laser sagte in InfluxDB schreiben nur Änderungen:

Es war ja auch kein Zitat. Nur sinngemaß.

zu diesem ungekennzeichneten EDIT von dir:
Genau das ist immer wieder das Problem! eine sinngemäße Nacherzählung hilft gar nichts

[mickemup]

@Laser

So soll es sein..
Habe ich auch schon erwähnt, aber hast du ignoriert