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

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

[Laser]

@mickemup ich möchte aber genau den Zeitpunkt der fallenden Flanke wissen. Nicht nur den Zustand.

[mickemup]

@Laser
Verstehe ich zwar nicht aber egal...
Zeig mal auf was sich der Alias bezieht...

[Laser]

@mickemup das?

für mich ist wichtig zu wissen, ob meine Brennersteuerung (in der Brennwerttherme) tatsächlich ein Signal vom GPIO bekommen hat.

[mickemup]

@Laser

Oben hast du das gesagt:

setState('0_userdata.0.Logik.Brenner_istAus'/Brenner istAus/,true);
daraus ein Alias abgeleitet, um nur 0 und 1 zu bekommen. Für Grafana.

Dies ist aber eine klarer Widerspruch...

[Laser]

@mickemup Das stimmt. Ich habe so viele Varianten durchprobiert. Wegen des Protokoll-Fehlers. Letzter Stand: der GPIO wird benutzt.
für mich ist entscheidend: Nach Brenner ausschalten soll eine Pause eingelegt werden, bevor der Brenner wieder angeht. Deshalb das Ganze. Und damit ich die Laufzeiten und die Pausen besser auswerten kann, diese Protokollierung. Damit ich die Leistung der Öltherme bestimmen kann. Die geht ja nur an und aus. Für die Auslegung der Wärmepumpe. Wenn das einmal in Grafana nicht geht, ist das nicht das große Drama. Aber schön ist es nicht, wenn die Protokollierung nicht zuverlässig arbeitet. Falls man daraus etwas automatisiert ableiten möchte.

[mickemup]

@laser
Ich glaube das Problem liegt nicht an der Influx-DB, sondern an deiner "Herangehensweise"
Niemand hier kann deine Gedanken lesen.
Und dein zu Anfangs beschriebenes Problem (Fehler in Influx-DB Adapter) scheint so nicht zu existieren.
Du musst deine "Probleme" in kleinere Pakete stückeln.
Wenn die Werte nicht richtig geloggt werden, dann musst du noch nicht an Grafana werkeln.
Dein Skript scheint mir kompliziert und wenn du mit dem die "Flanke" erkennen willst (und darstellen), dann musst du auch den "Flanken" DP loggen und nicht ein Alias von einem RPI state.

Die Leute hier sind generell sehr hilfsbereit.
Du musst aber klar sagen wo es klemmt....

[Laser]

@mickemup Das ist wirklich nicht einfach. Nun einen Programmablaufplan erstellen und abfotografieren, ist etwas übertrieben? Oder nicht? Das ich die Tabelle im Datenpunkt aufrufen kann, ist schon mal gut. Das habe ich zwar mal gesehen, aber nicht mehr beachtet. Darin sehe ich, daß sich der Eintrag um 03:22:50 nicht geändert hat. Der GPIO hat aber zu diesem Zeitpunkt umgeschaltet. Hier gibt es ein Problem. Dummerweise habe ich die Protokollierung des GPIO deaktiviert. Die hatte ich vorher parallel zum Alias protokollieren laufen. Abgeschaltet, weil scheinbar Alles in Ordnung war. Vorher kam es ja nach 9 Schaltungen zu einer Fehlprotokollierung. Heute nur 2x am Tag. Ich werde den GPIO-Schaltvorgang wieder protokollieren.
Der jetzige Programm- Zustand ist schon stark vereinfacht. Mein altes Konstrukt war viel aufwendiger (hat aber jahrelang funktioniert.)
Ich werde das Ganze weiter vereinfachen.