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

[mickemup]

@Laser sagte in InfluxDB schreiben nur Änderungen:

Was genau möchtest Du mit dem GPIO machen? Ich kann den im Datenpunkt des rpi2 beschreiben oder mit einem Script.

OK, und das machst du ja auch mit deinem Skript.

[mickemup]

@Laser sagte in InfluxDB schreiben nur Änderungen:

ich warte sehnsüchtig auf Aussetzer.

OK und wenn du einen siehst, dann sauber protokollieren:
z.B der DP zeigt 0/False an, im INFLUX log erscheint dies aber nicht.

Denn nur dann ist es wirklich ein Fehler im INFLUX logging.

[Laser]

@mickemup Ja, mache ich. Habe jetzt auch diverse Datenpunkte von boolean auf 0/1 umgeschrieben. (Gefällt mir nicht so richtig.) Nur der GPIO ist noch auf true/false.

[Homoran]

und wann antwortest du auf meine Fragen?
BEVOR du noch weitere Stellschrauben verdrehst?

[Laser]

@homoran "und den Rest übergehst du." War das jetzt eine Aufforderung zum Übergehen oder sollte ich noch etwas beschreiben?

[Homoran]

@Laser sagte in InfluxDB schreiben nur Änderungen:

oder sollte ich noch etwas beschreiben?

Natürlich!

Diese Frage enhielt mehrere Punkte:

sagte in InfluxDB schreiben nur Änderungen:

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!

du bist nur auf den "erledigten" Teil eingegangen, und den Rest übergehst du

[mickemup]

@Laser
Die Frage ist: wer ausser du via script, schreibt noch in den DP?
Konkret geht es um den rp2.0

wer/was schreibt hier...
und ergänzend: mit welchem skript schreibst du direkt in den alias?

[Laser]

@mickemup @homoran Das sehe ich mir jetzt genauer an. Möglicherweise ist da noch ein Fehler drin. Ich habe die ganze Steuerung total überarbeitet. Funktioniert aber. Nur der Zustand in der Datenbank nicht immer.
Direkt in den Alias soll eigentlich kein Script schreiben.

[Homoran]

@Laser sagte in InfluxDB schreiben nur Änderungen:

Funktioniert aber

eben nicht wie gewollt.
Deswegen sollst du ja systematisch von Anfang bis Ende alles nochmal aufrollen.

Ein ständiges (über)springen hilft da nur, noch mehr Verwirrung zu schaffen.

[Laser]

@homoran ich gehe jetzt die Scripte noch mal genau durch. Teilweise habe ich Bezeichnungen geändert, um mehr Klarheit zu schaffen. Dabei Groß/Kleinschreibung mit Fehlermöglichkeit. Datenpunkte von Boolean in 1/ 0 Zahl geändert. Der Steuerungsteil ist eigentlich nichts kompliziertes.
EDIT: in Arbeit (dauert) die Datenpunkte, die ich von "boolean" in "number" ändern wollte, habe ich gelöscht und neu angelegt. Das Umändern hat scheinbar nicht fehlerfrei geklappt.
Die Flüchtigkeitsfehler behoben, jetzt muß ich warten, ob der Fehler wieder auftritt. Werde mich melden...

[mickemup]

Habe nun mal bei mir zum testen im Log nachgeschaut.
Mit folgenden Szenario:
Wert via Javascript steuern (Brighness von Shelly Lampe) im 2 Sekunden Abstand.
Geloggt wurde der Shelly DP sowie ein Alias darauf.

Setting Influx:

Verlaufsdaten:

Eigentlich sollte dein Datenpunkt (der verlinkte von deinem Alias sich ähnlich/gleich verhalten.)
=> Steuerbefehl vom Skript und kurz darauf das Feedback vom Adapter DP
Wenn das bei dir nicht so ist, liegt evtl. bei rp2.0 Instanz ein Fehler.
Oder aber deine Entprell- und Blockzeit verhinderte das loggen...

Any News?

[Laser]

@mickemup ich habe jetzt auch entprell und blockzeit auf Null. "Nur Änderungen" angehakt. Bisher hatte ich immer Warnungen der Art " 0 Signal angekommen, erwartet boolean" und umgekehrt. Habe alle Zwischenspeicherdatenpunkte als "nummer" neu angelegt. Vorher gelöscht. Die Warnungen kommen nicht mehr. Bisher habe ich auch noch keine Abnormalitäten. Das sind nun gleich 3 Änderungen. Die Ursache wird so schwer zu ermitteln sein. Ich beobachte weiter.

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