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

[Laser]

@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.

[mickemup]

@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 ;-)

[Laser]

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.

[Laser]

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.

[mickemup]

@Laser
Also ganz streng gesehen sieht man dass um 16:17 ein javascript eine "Debug:info ausgibt.
Ob und und wie dein Alias geschrieben/geändert wurde sieht man hier (ohne viel Hintergrundwissen, dass evtl. @homoran hat ) nicht.

[Laser]

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.

[mickemup]

@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.

[Laser]

Ja, ich habe Alles so angepasst. Auch in Grafana.
Muß beobachten. Kann dauern, nur alle 30 Minuten (etwa) ein Schaltvorgang.

[Homoran]

@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.

[mickemup]

@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....

[Laser]

@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 Problem

Hinzugefügt die Tabelle:

03:23 ist der Wert aber auf 0 gesprungen. Und war 03:28 immer noch 0

[Homoran]

@Laser sagte in InfluxDB schreiben nur Änderungen:

und im Datenpunkt:

lad mal die Seite neu und zeig es dann

[mickemup]

@laser wir kennen dein Script nicht.
Darum nützt uns deine LOG Ausgabe wenig.
Warum verwendest du ein Alias und nicht ein User DP?

[Laser]

@homoran

[Laser]

@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
*/

[Homoran]

@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]

@Homoran
Er loggt gar nicht den DP vom Skript....
Dann wird es natürlich schwierig...

[Homoran]

@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

[Laser]

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!

[mickemup]

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...