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

[mickemup]

Wie sehen denn nun die Verlaufsdaten aus?

[Homoran]

@Laser sagte in InfluxDB schreiben nur Änderungen:

hatte ich immer Warnungen der Art " 0 Signal angekommen, erwartet boolean"

der exakte Wortlaut wäre hier sehr wichtig gewesen!

@Laser sagte in InfluxDB schreiben nur Änderungen:

Die Ursache wird so schwer zu ermitteln sein

jetzt wahrscheinlich ja, leider!

[mickemup]

@Laser
Habe mir das Skript mit deiner Aussage:
ich möchte aber genau den Zeitpunkt der fallenden Flanke wissen. Nicht nur den Zustand.

Nochmal angeschaut. Dein User DP ist ja ein boolean, hat also nur zwei Zustände
Das ginge eleganter mit nur einem Trigger auf Aenderung (ne) von deinem User DP (0_userdata.0.Logik.BrennerIstEin)
Dann ist ja jede Auslösung entweder eine steigende Flanke (Dann ist der Wert TRUE oder sonst eine fallende Flanke)

Pseudo Code:
Trigger auf Aenderung:
Falls "True" => Code für steigende Flanke
Sonst => Code für fallende Flanke

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: ");
 });

[Laser]

@mickemup Mit ne habe ich auch zuerst getestet, mich dann für lt entschieden.

[mickemup]

@Laser
Also dein Entscheid war zwei Trigger auf den gleichen DP zu setzen. Anstatt mit nur einem Trigger zu arbeiten?
Macht wahrscheinlich nicht die Welt aus, aber die "Effizienz"-Experten @paul53 denken wohl das ein Trigger effizienter/besser ist...

[Laser]

Zuverlässigkeit war mir wichtiger als Effizienz.

[mickemup]

@Laser Es ändert genau 0 an der Zuverlässigkeit...

[Laser]

Ja, aber so war ich offen für verschiedene Schreibhandlungen. Bei steigender und fallender Flanke. Für Irgendetwas muß man sich entscheiden.

[mickemup]

@Laser Eben nicht...lies doch mal in Ruhe nochmals meinen Text.

Damit kannst du steigende und fallende Flanke unterscheiden.
Da ist nix mit entscheiden...

on({ id: '0_userdata.0.Dummy_Bool' /* Dummy Bool */, change: 'ne' }, async (obj) => {
  let value = obj.state.val;
  let oldValue = obj.oldState.val;
  if ((obj.state ? obj.state.val : '')) {
    // Code für steigende Flanke
  } else {
    // Code für fallende Flanke
  }
});

[Laser]

Ich sehe mir das Morgen noch mal an. Ob es besser grht als mit der jetzigen Lösung.

[mickemup]

@Laser Es "geht" nicht besser oder schlechter. Du "sparst" dir einfach einen Trigger

[mickemup]

Wie siehts nun mit den Verlaufsdaten aus? immer noch "Fehler"

[Laser]

@mickemup bisher kein Fehler. Werde abwarten. Zuletzt waren es nur 2 Fehler am Tag.

[mickemup]

@Laser zeig doch trotzdem mal einen Verlauf.
nur um zu sehen ob auf jedes ack false ein true duch den rp2.0 folgt.

[Laser]

Mache ich. Habe hier nur das Handy. Würde das gerne morgen machen.

[Laser]

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

[Homoran]

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

[Laser]

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

@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

[Laser]

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.