NEWS
InfluxDB schreiben nur Änderungen
-
@mickemup So, jetzt lief das über Nacht ohne Probleme. So sieht es die ganze Zeit aus:
Bild Link)da ich nun 3 (4 mit Grafana) Maßnahmen ergriffen habe, ist nicht klar, was genau nun der Fehler war. Die massenweise Warnungen im Log über Datenformate sind komplett weg.
Als Nächstes werde ich die Einstellungen im influxDB Adapter einzeln zurücknehmen, um zu sehen, ob dort etwas Einfluß hat.@Laser sagte in InfluxDB schreiben nur Änderungen:
da ich nun 3 (4 mit Grafana) Maßnahmen ergriffen habe, ist nicht klar, was genau nun der Fehler war
deswegen geht man systematisch von der Quelle bis zum Ende Schritt für Schritt vor.
Dabei
@Laser sagte in InfluxDB schreiben nur Änderungen:
Die massenweise Warnungen im Log
beachten, lesen und befolgen.
Außerdem hier in vollem Wortlaut zitieren.@Laser sagte in InfluxDB schreiben nur Änderungen:
um zu sehen, ob dort etwas Einfluß hat.
Höchstwahrscheinlich nicht!
Die Ursache wird viel früher in der Kette entstanden sein. Dass der Adapter (nur bei dir) buggy ist, wäre bei so vielen Nutzern höchst unwahrscheinlich.Außerdem immer noch:
sagte in InfluxDB schreiben nur Änderungen:
@Laser warum schreiben script und rpi2 in den DP und warum das Script,
das ich immer noch nicht zu sehen bekommen habe(!), mit ack=false?weder beantwortet, noch etwas geändert!
kein Support per PN! - Fragen im Forum stellen - es gibt fast nichts, was nicht auch für andere interessant ist.
Benutzt das Voting rechts unten im Beitrag wenn er euch geholfen hat.
der Installationsfixer: curl -fsL https://iobroker.net/fix.sh | bash -
-
@homoran Ich verstehe das nicht, was damit gemeint ist!
@Laser warum schreiben script und rpi2 in den DP und warum das Script, das ich immer noch nicht zu sehen bekommen habe(!), mit ack=false?weder beantwortet, noch etwas geändert!
Ich möchte den Zustand des GPIO Protokollieren. Der GPIO soll nach Abschalten des Brenners für 15 Minuten ausgeschaltet bleiben. Das macht meine Steuerung. Warum das so in den Datenpunkt geschrieben wird, wie in der Tabelle dargestellt, kann ich nicht beantworten. Ist das denn falsch? Warum funktioniert der Kram dann fehlerfrei?
-
@homoran Ich verstehe das nicht, was damit gemeint ist!
@Laser warum schreiben script und rpi2 in den DP und warum das Script, das ich immer noch nicht zu sehen bekommen habe(!), mit ack=false?weder beantwortet, noch etwas geändert!
Ich möchte den Zustand des GPIO Protokollieren. Der GPIO soll nach Abschalten des Brenners für 15 Minuten ausgeschaltet bleiben. Das macht meine Steuerung. Warum das so in den Datenpunkt geschrieben wird, wie in der Tabelle dargestellt, kann ich nicht beantworten. Ist das denn falsch? Warum funktioniert der Kram dann fehlerfrei?
@Laser sagte in InfluxDB schreiben nur Änderungen:
Ich verstehe das nicht, was damit gemeint ist!
was denn genau verstehst du nicht?
Bitte erst das kären, und nicht wieder etwas anderes einbringen!
Dann versandet die Klärung eines möglichen Problems wieder über 3 Threads und 100 Posts -
@homoran Ich verstehe das nicht, was damit gemeint ist!
@Laser warum schreiben script und rpi2 in den DP und warum das Script, das ich immer noch nicht zu sehen bekommen habe(!), mit ack=false?weder beantwortet, noch etwas geändert!
Ich möchte den Zustand des GPIO Protokollieren. Der GPIO soll nach Abschalten des Brenners für 15 Minuten ausgeschaltet bleiben. Das macht meine Steuerung. Warum das so in den Datenpunkt geschrieben wird, wie in der Tabelle dargestellt, kann ich nicht beantworten. Ist das denn falsch? Warum funktioniert der Kram dann fehlerfrei?
sagte in InfluxDB schreiben nur Änderungen:
warum schreiben script und rpi2 in den DP und warum das Script, das ich immer noch nicht zu sehen bekommen habe(!), mit ack=false?
Ich verstehe nicht, welches Problem diese beiden Zeilen beschreiben.
-
@mickemup So, jetzt lief das über Nacht ohne Probleme. So sieht es die ganze Zeit aus:
da ich nun 3 (4 mit Grafana) Maßnahmen ergriffen habe, ist nicht klar, was genau nun der Fehler war. Die massenweise Warnungen im Log über Datenformate sind komplett weg.
Als Nächstes werde ich die Einstellungen im influxDB Adapter einzeln zurücknehmen, um zu sehen, ob dort etwas Einfluß hat.@Laser sagte in InfluxDB schreiben nur Änderungen:
@mickemup So, jetzt lief das über Nacht ohne Probleme. So sieht es die ganze Zeit aus:
da ich nun 3 (4 mit Grafana) Maßnahmen ergriffen habe, ist nicht klar, was genau nun der Fehler war. Die massenweise Warnungen im Log über Datenformate sind komplett weg.
Als Nächstes werde ich die Einstellungen im influxDB Adapter einzeln zurücknehmen, um zu sehen, ob dort etwas Einfluß hat.Das sieht nun endlich so aus wie es muss.
Der DP wird von javascript gesteuert und dann folgt das Ack true vom rpi2.0Was willst du denn jetzt schon wieder am Influx-Adapter umstellen?
So wie ich das interpretiere hattest du vorher mehrere Fehler.
-
Einerseits die Entprell- und Blockzeit im Influx-Adapter
-
andererseits sicherlich aus was im Code. Da hast du ja auch geschraubt.
Dein Code ha aber immer noch einiges an Optimierungspotential
Nur als Beispiel: Du hast den User DP "0_userdata.0.Logik.BrennerIstEin"
Immer wenn der wechselt schreibst du den User DP "0_userdata.0.Logik.Brenner_istAus" mit dem gegenteiligen Wert.
Du hast also (zumindest mit dem gezeigten Code) kein Mehrwert durch die zwei DPs
1 DP mit Brenner_Status würde reichen (true=Brenner ein, false=Brenner aus) -
-
@Laser sagte in InfluxDB schreiben nur Änderungen:
@mickemup So, jetzt lief das über Nacht ohne Probleme. So sieht es die ganze Zeit aus:
da ich nun 3 (4 mit Grafana) Maßnahmen ergriffen habe, ist nicht klar, was genau nun der Fehler war. Die massenweise Warnungen im Log über Datenformate sind komplett weg.
Als Nächstes werde ich die Einstellungen im influxDB Adapter einzeln zurücknehmen, um zu sehen, ob dort etwas Einfluß hat.Das sieht nun endlich so aus wie es muss.
Der DP wird von javascript gesteuert und dann folgt das Ack true vom rpi2.0Was willst du denn jetzt schon wieder am Influx-Adapter umstellen?
So wie ich das interpretiere hattest du vorher mehrere Fehler.
-
Einerseits die Entprell- und Blockzeit im Influx-Adapter
-
andererseits sicherlich aus was im Code. Da hast du ja auch geschraubt.
Dein Code ha aber immer noch einiges an Optimierungspotential
Nur als Beispiel: Du hast den User DP "0_userdata.0.Logik.BrennerIstEin"
Immer wenn der wechselt schreibst du den User DP "0_userdata.0.Logik.Brenner_istAus" mit dem gegenteiligen Wert.
Du hast also (zumindest mit dem gezeigten Code) kein Mehrwert durch die zwei DPs
1 DP mit Brenner_Status würde reichen (true=Brenner ein, false=Brenner aus)@mickemup sagte in InfluxDB schreiben nur Änderungen:
Der DP wird von javascript gesteuert und dann folgt das Ack true vom rpi2.0
das ergäbe Sinn!
Ich bin aus den Erklärungen von @laser nicht schlau geworden. Nach meinem Verständnis liest er den GPIO aus, um einen Status zu überwachen.kein Support per PN! - Fragen im Forum stellen - es gibt fast nichts, was nicht auch für andere interessant ist.
Benutzt das Voting rechts unten im Beitrag wenn er euch geholfen hat.
der Installationsfixer: curl -fsL https://iobroker.net/fix.sh | bash -
-
-
@Laser sagte in InfluxDB schreiben nur Änderungen:
da ich nun 3 (4 mit Grafana) Maßnahmen ergriffen habe, ist nicht klar, was genau nun der Fehler war
deswegen geht man systematisch von der Quelle bis zum Ende Schritt für Schritt vor.
Dabei
@Laser sagte in InfluxDB schreiben nur Änderungen:
Die massenweise Warnungen im Log
beachten, lesen und befolgen.
Außerdem hier in vollem Wortlaut zitieren.@Laser sagte in InfluxDB schreiben nur Änderungen:
um zu sehen, ob dort etwas Einfluß hat.
Höchstwahrscheinlich nicht!
Die Ursache wird viel früher in der Kette entstanden sein. Dass der Adapter (nur bei dir) buggy ist, wäre bei so vielen Nutzern höchst unwahrscheinlich.Außerdem immer noch:
sagte in InfluxDB schreiben nur Änderungen:
@Laser warum schreiben script und rpi2 in den DP und warum das Script,
das ich immer noch nicht zu sehen bekommen habe(!), mit ack=false?weder beantwortet, noch etwas geändert!
@Homoran sagte in InfluxDB schreiben nur Änderungen:
@Laser warum schreiben script und rpi2 in den DP und warum das Script, das ich immer noch nicht zu sehen bekommen habe(!), mit ack=false?
weder beantwortet, noch etwas geändert!
Der Verlauf sieht doch jetzt gut aus. Immer ein Steuern und kurz danach das Feedback von rpi2.0
Aber @laser du machst es uns wirklich schwierig zu helfen. Du fragst viel und gleichzeitig (es wirkt zumindest so), scheints du das Feedback nicht/nur widerwillig anzunehmen.
Löse die Teilprobleme einzeln:
Beschreibe den ist Zustand
Beschreibe den gewünschten Sollzustand
Ändere nicht 1000 Sachen gleichzeitig
Setze nicht voraus, dass die Leute dein Projekt kennen und/oder Gedanken lesen können. -
@mickemup Der Datenpunkt soll wieder zurückgesetzt werden. Dafür ist der 2. Trigger.
Es gibt sicher viele Möglichkeiten, eine Logik zu realisieren. So, wie Sie jetzt ist, funktioniert es. Ich könnte jetzt versuchen, weiter zu vereinfachen. Getreu dem Motto "Wenn es dem Esel zu wohl wird, geht er aufs Eis tanzen! Meine Logik vor diesem Zustand war noch viel umfangreicher. Der Istzustand gefällt mir erst mal. Muß ja nicht für immer so bleiben. -
@mickemup sagte in InfluxDB schreiben nur Änderungen:
Der DP wird von javascript gesteuert und dann folgt das Ack true vom rpi2.0
das ergäbe Sinn!
Ich bin aus den Erklärungen von @laser nicht schlau geworden. Nach meinem Verständnis liest er den GPIO aus, um einen Status zu überwachen.@Homoran
Den GPIO liest er nicht aus, sondern schreibt den (ist ein Output)
Im gezeigten Skript überwacht er einen UserDP (Brenner ist ein)
Wie der entsteht wissen wir aber nicht.Edit: Nachtrag: die Logik von der ganzen Steuerung wurde auch nicht gezeigt, aber dazu ist ja auch keine Frage da.
Einfach gesagt überwachen "wir" nur ober der setState Befehl für den GPIO auch ankommt.
Irgendwo (wahrscheinlich in einem anderen Skript wird der GPIO aber auch wieder auf true gesetzt...) -
@mickemup Der Datenpunkt soll wieder zurückgesetzt werden. Dafür ist der 2. Trigger.
Es gibt sicher viele Möglichkeiten, eine Logik zu realisieren. So, wie Sie jetzt ist, funktioniert es. Ich könnte jetzt versuchen, weiter zu vereinfachen. Getreu dem Motto "Wenn es dem Esel zu wohl wird, geht er aufs Eis tanzen! Meine Logik vor diesem Zustand war noch viel umfangreicher. Der Istzustand gefällt mir erst mal. Muß ja nicht für immer so bleiben. -
@Homoran sagte in InfluxDB schreiben nur Änderungen:
@Laser warum schreiben script und rpi2 in den DP und warum das Script, das ich immer noch nicht zu sehen bekommen habe(!), mit ack=false?
weder beantwortet, noch etwas geändert!
Der Verlauf sieht doch jetzt gut aus. Immer ein Steuern und kurz danach das Feedback von rpi2.0
Aber @laser du machst es uns wirklich schwierig zu helfen. Du fragst viel und gleichzeitig (es wirkt zumindest so), scheints du das Feedback nicht/nur widerwillig anzunehmen.
Löse die Teilprobleme einzeln:
Beschreibe den ist Zustand
Beschreibe den gewünschten Sollzustand
Ändere nicht 1000 Sachen gleichzeitig
Setze nicht voraus, dass die Leute dein Projekt kennen und/oder Gedanken lesen können.@homoran @mickemup sagte in InfluxDB schreiben nur Änderungen:
Der Verlauf sieht doch jetzt gut aus. Immer ein Steuern und kurz danach das Feedback von rpi2.0
Aber @laser du machst es uns wirklich schwierig zu helfen. Du fragst viel und gleichzeitig (es wirkt zumindest so), scheints du das Feedback nicht/nur widerwillig anzunehmen.
Ich nehme überhaupt nichts widerwillig an. Von mir aus hätte ich eine Änderung nach der Anderen vorgenommen. Dazwischen 1 Tag abgewartet, wie es läuft. Ich wurde doch gedrängt, endlich die Vorschläge einzuarbeiten. Das habe ich dann getan.
Ich wüßte schon gerne, was die wirkliche Ursache für das teileweise Fehlen des Schreibens in die Datenbank war. Deshalb parametriere ich im Adapter influxDB schrittweise um. Ist keine große Arbeit und kann jederzeit rückgängig gemacht werden. -
@Homoran
Den GPIO liest er nicht aus, sondern schreibt den (ist ein Output)
Im gezeigten Skript überwacht er einen UserDP (Brenner ist ein)
Wie der entsteht wissen wir aber nicht.Edit: Nachtrag: die Logik von der ganzen Steuerung wurde auch nicht gezeigt, aber dazu ist ja auch keine Frage da.
Einfach gesagt überwachen "wir" nur ober der setState Befehl für den GPIO auch ankommt.
Irgendwo (wahrscheinlich in einem anderen Skript wird der GPIO aber auch wieder auf true gesetzt...)@mickemup @homoran sagte in InfluxDB schreiben nur Änderungen:
Im gezeigten Skript überwacht er einen UserDP (Brenner ist ein)
Wie der entsteht wissen wir aber nicht.der Zustand Brenner ist EIN entsteht durch Überwachen der Leistungsaufnahme der Heizung.
Hatte ich weiter oben kurz beschrieben. Wenn das die Frage war? -
@mickemup @homoran sagte in InfluxDB schreiben nur Änderungen:
Im gezeigten Skript überwacht er einen UserDP (Brenner ist ein)
Wie der entsteht wissen wir aber nicht.der Zustand Brenner ist EIN entsteht durch Überwachen der Leistungsaufnahme der Heizung.
Hatte ich weiter oben kurz beschrieben. Wenn das die Frage war? -
@mickemup genau das werde ich versuchen, herauszufinden. Der Zustand steht ja über längere Zeit an. Warum stört da eine Entprell- und Blockzeit?
Übrigens (ist eben ohne seitenlange Romane schwer zu beschreiben) der GPIO ist die Freigabe für den Brenner der Heizung und wird in einem anderen Script nach Ablauf von 15 Minuten am Tag und 25 Minuten in der Nacht (Einstellbar) wieder gesetzt. Damit soll der vorzeitige Verschleiß der Zündelektrode vermieden werden (klappt auch). Die Überwachung des Freigabezustandes und Darstellung in Grafana ist ein hübscher Effekt, mir das Ablesen der Brennerlaufzeit zu erleichtert. Auswirkungen auf die Funktion der Steuerung gibt es nicht. -
Warum willst du den Entrpellen?
Das Blocken könnte das Feedback vom rpi2.0 geblockt haben, da dies ja kurz auf deinen Steuerinput folgt.
Irgendwo habe ich noch im Hinterkopf, das Entprelllen und Blocken gleichzeitig zu Problemen führen könnte...
Es fehlt mir auch gerade kein praktisches Beispiel ein, wo beides gleichzeitig Sinn macht.Nachtrag
Entrpellen: Macht z.B Sinn wenn man einen Taster einliest
Blocken: Macht z.B Sinn, wenn ein Sensor sehr oft Daten liefert und man z.B nicht öfter als jede Sekunde die Daten logen will.
Bei einem Output (den man selber steuert) machen beide Settings 0 Sinn. -
@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 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 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.
Support us
349
Online32.6k
Benutzer82.1k
Themen1.3m
Beiträge