Information zum Kontoabgleich und zur Namensänderung

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

[Laser]

@mickemup @homoran Die Tabelle ist das was in den influxDB Baustein reinkommt oder was in die DB geschrieben wird?

[Homoran]

@Laser sagte in InfluxDB schreiben nur Änderungen:

was in den influxDB Baustein reinkommt oder was in die DB geschrieben wird?!

wenn es nach neu laden noch drin steht ist es in die DB geschrieben worden.

Du hast diese Frage
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!

So macht helfen keinen Spaß!

[Laser]

@homoran Das script, welches die Auswertung macht und in die Datenpunkte schreibt, habe ich doch hier gezeigt! #49. Mehr ist da nicht.

[Homoran]

@Laser sagte in InfluxDB schreiben nur Änderungen:

habe ich doch hier gezeigt!

nachdem ich das damals schrieb (wahrscheinlich zeitgleich)
deswegen durchgestrichen!
und den Rest übergehst du.

[Laser]

@homoran Der Kuddelmuddel mit true/false und 1/0 kommt eigentlich nur davon, daß Grafana nicht true/false darstellen kann. Zumindest nach Beschreibung. Es wird aber trotzdem dargestellt. Und Die influxDB meckert ein True/false auch an. Verarbeitet es aber scheinbar doch.

[Thomas Braun]

@Laser

Intern wird true mit 1 behandelt, false mit 0.

[Homoran]

@Laser

sagte in InfluxDB schreiben nur Änderungen:

und den Rest übergehst du.

[mickemup]

@Laser
Also
Dann log doch mal mit Influx dein Alias und den GPIO.

dann sehen wir ob da ein Unterschied ensteht.
Sollte aber nicht, da der Alias ja das gleiche "sieht" wie dein GPIO DP

Also:

• Beide mit Influx loggen

• Settings: nur änderungen, keine Entprell- und Blockzeiten

Dann Bescheid geben, ob immer noch nicht korrekt geloggt wird. OK?

[Laser]

@mickemup mache ich. Dann muß ich auf den Fehlerzustand warten. Kann dauern.