NEWS
InfluxDB schreiben nur Änderungen
-
@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.
-
@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 -
@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. -
@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.@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 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.@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 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.
@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 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?@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 -
@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.
@Laser sagte in InfluxDB schreiben nur Änderungen:
Da steht: "null, um die Prüfung zu deaktivieren"
wirklich
nulloder0?? -
@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@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!
nullentspricht "kein Wert", während0eine Zahl ist. -
@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@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 -
@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 natürlich! Ich kann ja auch gar nicht "null" eintragen. nur "0" oder einen Zahlenwert auswählen oder manuell eintragen. Das habe ich als bekannt vorausgesetzt.
Ich gebe zu, daß ich ein Problemfall bin. Soll ich in Zukunft durch mehrere Gutachter meine Beiträge auf fachlich und rechtlich sichere Ausdrucksweise prüfen lassen? Manche Dinge in der deutschen Sprache sind selbsterklärend. Beiträge im Bayrischen oder österreichischem Fernsehen sind da wesentlich schwerer zu verstehen. -
@homoran natürlich! Ich kann ja auch gar nicht "null" eintragen. nur "0" oder einen Zahlenwert auswählen oder manuell eintragen. Das habe ich als bekannt vorausgesetzt.
Ich gebe zu, daß ich ein Problemfall bin. Soll ich in Zukunft durch mehrere Gutachter meine Beiträge auf fachlich und rechtlich sichere Ausdrucksweise prüfen lassen? Manche Dinge in der deutschen Sprache sind selbsterklärend. Beiträge im Bayrischen oder österreichischem Fernsehen sind da wesentlich schwerer zu verstehen.@Laser sagte in InfluxDB schreiben nur Änderungen:
Soll ich in Zukunft durch mehrere Gutachter meine Beiträge auf fachlich und rechtlich sichere Ausdrucksweise prüfen lassen?
nein, du sollst einfach nur Fakten in Form von Text in code-tags oder Screenshots liefern und nichts nacherzählen.
Das wurde dir auch schon mehrfach gesagt.
Nachzulesen wie es richtig geht, kannst du es hier
https://forum.iobroker.net/topic/51555/hinweise-für-gute-forenbeiträgeauch dies wurde dir mehrfach angeraten.
Das würde die Hilfe wesentlich vereinfachen und beschleunigen
-
@mickemup morgen trage ich das so ein. Obwohl ich gerne wüßte, was das bei 2 möglichen Zahlen bewirkt.
@Laser
Ist doch selbsterklärend...
Trag bei minimale Differenz eine 2 ein und es wird nichts mehr geloggt...Da deine Differenz (1-0)=1 immer kleiner als 2 ist.
Und immer gleiche Werte, dann schreibt er den Status alle x sekunen, auch wenn nichts ändert...
-
Support us
350
Online32.6k
Benutzer82.1k
Themen1.3m
Beiträge