NEWS
InfluxDB schreiben nur Änderungen
-
@marc-berg Die Tabelle war zur falschen Zeit, hier richtig:

16:17 war die Problemzeit
Ergänzung: Laut Tabelle hat sich der Wert nicht geändert. Da liegt der Fehler schon vor!
Den Zustand habe ich aber in der Objektdarstellung zum Umschaltzeitpunkt beobachtet. Es hat definitiv gewechselt. Da sehe ich auch an dem Temperaturverhalten.@Laser
Und ja: nur änderungen Tracken, aber keine Enptrell und Blockzeiten einstellen...
Dann sollte es klappen. (Wenn der DP denn auch korrekt geschrieben wird....)Hat denn der Wert zu 100% geändert?
Kannst ja auch mal ein Blockly machen mit Debug Ausgabe von dem DP. Wenn der Wert dort ändert aber nicht in der DB liegt tatsächlich ein "DB Adatper" Fehler vor.
Dies bezweifle ich aber ;-) -
Ergänzung: Laut Tabelle hat sich der Wert nicht geändert. Da liegt der Fehler schon vor!
Den Zustand habe ich aber in der Objektdarstellung zum Umschaltzeitpunkt beobachtet. Es hat definitiv gewechselt. Da sehe ich auch an dem Temperaturverhalten. Das Logging war aber dann dummerweise schon abgeschaltet (16:17 Uhr).
Werde die Einstellungen so ändern. -
Ich habe die ganze Zeit mit "console.log" in JS den Wert beobachtet. Dann aber das Logging abschaltet. Und dann trat der Fehler erst auf. Aber der Wert hat sich geändert . Sehe ich am Temperasturverhalten und im Protokoll am Abschaltbefehl Brenner.
 -
Ich habe die ganze Zeit mit "console.log" in JS den Wert beobachtet. Dann aber das Logging abschaltet. Und dann trat der Fehler erst auf. Aber der Wert hat sich geändert . Sehe ich am Temperasturverhalten und im Protokoll am Abschaltbefehl Brenner.
 -
Heute, 3:22:50 ist das Gleiche passiert.
Der Wert ändert sich, kein Eintrag in die DB. Werde ich aber nochmal in der influxDB suchen!
Der Fehler passiert eben nur selten.@Laser
Hattest du die Settings schon angepasst?Zur Fehler Eingrenzung: Ab jetzt folgende Settings:
-
Nur änderungen nachverfolgen
-
Keine Entprell und Blockzeiten
Falls der Fehler wieder auftritt => Den DB (welchen du auch mit Influx trackst) via Blockly und DEBUG LOG tracken und ausgeben.
Falls dann immer noch ein Widerspruch besteht liegt tatsächlich ein Fehler beim Influx Adapter vor.
Falls nicht ist etwas an deinem Skript/Ailas faul. -
-
@mickemup
ich habe leider auch keinen vollständigen strukturierten Überblick sämtlicher Schritte der Entstehung der zu loggenden Werte bekommen.Ich bin mir ziemlich sicher, dass es auf dieser Strecke vom Ursprung bis zum geloggten DP weitere Pitfalls geben wird.
-
Ja, ich habe Alles so angepasst. Auch in Grafana.
Muß beobachten. Kann dauern, nur alle 30 Minuten (etwa) ein Schaltvorgang.@Laser
OK
Grafana kannst gerne noch weglassen.
Dein Fehler liegt vorher (Du sagst am INFLUX Adapter)
Wenn dem so ist (Unwahrscheinlich), werden wir das erfahren.
Falls nicht klemmts noch weiter vorne, aber auch da kann geholfen werden.
Step by Step.... -
@homoran hier die Aufzeichnung im Log:
und im Datenpunkt:
und in Grafana:
da waren die Änderungen aber nicht gemacht.
Jetzt hinzugefügt die influxDB:

03:23 ist das ProblemHinzugefügt die Tabelle:
03:23 ist der Wert aber auf 0 gesprungen. Und war 03:28 immer noch 0
-
@homoran hier die Aufzeichnung im Log:
und im Datenpunkt:
und in Grafana:
da waren die Änderungen aber nicht gemacht.
Jetzt hinzugefügt die influxDB:

03:23 ist das ProblemHinzugefügt die Tabelle:
03:23 ist der Wert aber auf 0 gesprungen. Und war 03:28 immer noch 0
@Laser sagte in InfluxDB schreiben nur Änderungen:
und im Datenpunkt:
lad mal die Seite neu und zeig es dann
-
@mickemup Das Scrip zur Erkennung der fallenden Flanke:
// Testen auf fallende und steigende Flanke // Bei "Brenner Aus" wird "Brenner _istAus" gesetzt. // Beim Setzen von "Freigabe" wird "Brenner_istEin" zurückgestezt (alt) on({id:'0_userdata.0.Logik.BrennerIstEin'/*BrennerIstEin*/, change: 'lt'}, function (obj) { setState('rpi2.0.gpio.23.state'/*Gpio 23*/,false) ; //true = Freigabe Brenner setState('0_userdata.0.Logik.Freigabe'/*Freigabe*/,0); setState('0_userdata.0.Logik.Brenner_istAus'/*Brenner istAus*/,true); console.log("Brenner schaltet Aus: "); }); on({id:'0_userdata.0.Logik.BrennerIstEin'/*BrennerIstEin*/, change: 'gt'}, function (obj) { setState('0_userdata.0.Logik.Brenner_istAus'/*Brenner istAus*/,false); console.log("Brenner schaltet Ein: "); }); /* change: Wert Erklärung eq Der neue Wert muss gleich dem alten sein ne Der neue Wert muss nicht gleich dem alten sein (Standard) gt Neuer Wert muss größer als der alte Wert sein ge Neuer Wert muss größer oder gleich groß sein lt Neuer Wert muss kleiner als der alte sein le Neuer Wert muss kleiner oder gleich groß sein any Trigger wird immer ausgeführt */ -
@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?
-
@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?
-
@mickemup wie gesagt, solange wir nicht
sagte in InfluxDB schreiben nur Änderungen:
einen vollständigen strukturierten Überblick sämtlicher Schritte der Entstehung der zu loggenden Werte bekommen.
@mickemup sagte in InfluxDB schreiben nur Änderungen:
wird es natürlich schwierig
-
Hier wird ein Datenpunkt geschrieben:
setState('0_userdata.0.Logik.Brenner_istAus'/Brenner istAus/,true);
daraus ein Alias abgeleitet, um nur 0 und 1 zu bekommen. Für Grafana.
Dieser Alias wird dann mit influxDB geloggt.
Fehlen noch weitere Info's. Welche? Werde Sie liefern! -
Wie sieht dein Alias aus?
Wie kann rpi2.0 in den Alias schreiben, wenn sich der alias auf einen User DB bezieht denn du nur in diesem Skript (Annahme) bearbeitest.
Abgesehen davon:
Warum so kompliziert. Du könntest einfach einen User DP machen mit "StatusBrenner" und den auf 0 oder 1 setzen und den dann loggen...
Bild Link)