ElabNET Technik Forum

Robert_Mini hat geschrieben: ↑Di Sep 17, 2019 7:32 am Willst du auch den Fall erkennen, dass der „teildefekte“ Sensor falsche Werte weiterschickt?

Ja, da habe ich mir einen Statsitic Baustein mit Min Max Vergleich gedacht, das funktioniert ja recht einfach mit §VAR<>-Variablen und den Baustein brauche ich eh für die Mittelwertbildung.

Robert_Mini hat geschrieben: ↑Di Sep 17, 2019 7:32 am Ansonsten Sensoren alle 10min zyklisch Senden und mit pegelgetriggerten Timer kombinieren. Dabei am Eingang ein “in Bereich” => macht die float => bool Umwandlung und zusätzliche Plausibilisierung!

Genau das, habe ich mir auch als Alternative gedacht, Ich fände es aber schöner, wenn man das direkt in einem RTR-Baustein löst. Aber da es dort recht kompliziert wird (wegen $VAR-Eingang) sollte man es vermutlich KIS (keep it simple) machen.

sollte man es vermutlich KIS (keep it simple) machen.

Ja, und ich finde es ist keine Schande, komplexe Geschichten auf mehrere Logiken aufzuteilen. Im Gegenteil, macht es m.E. übersichtlicher und wartbarer.

(Bezugnehmend auf deinen anderen Beitrag zum Thema „goto“: Durch die Aufteilung kannst du ggf. auch Eine Art „goto“ auslösen. Also abhängig vom Ergebnis von Teillogik A (true/false) entweder Logik B oder Logik C triggern.)

Hallo Sven,

wir diskutieren das zur Zeit, wie wir das erkennen, das gilt auch für fehlerhafte / abgesteckt KNX Sensoren. Also es geht generell um

1. Reaktion auf das Ausbleiben von Telegrammen

2. Reaktion auf sich "nicht mehr verändernde" Werte trotz Telegrammeingang (irgendas "hängt" und sendet immer das gleiche, z.b. die ewige wiederholte Sendung eines persistenten Wertens, der jedoch keine Änderung mehr erfährt).

lg

Stefan

Matze76 hat geschrieben: ↑Di Sep 17, 2019 8:55 am Ja, und ich finde es ist keine Schande, komplexe Geschichten auf mehrere Logiken aufzuteilen. Im Gegenteil, macht es m.E. übersichtlicher und wartbarer.

(Bezugnehmend auf deinen anderen Beitrag zum Thema „goto“: Durch die Aufteilung kannst du ggf. auch Eine Art „goto“ auslösen. Also abhängig vom Ergebnis von Teillogik A (true/false) entweder Logik B oder Logik C triggern.)

Jo, werde es denke ich auch genau so machen. Insbesondere nach Stefan's Rückmeldung in Beitrag#13 macht es Sinn die Sensor-Ausfallerkennung stand-alone zu relaisieren. Denn spätere eine custom-logik zu verändern ist denke ich nicht so genial. Bei Änderungen der Abschnitte Levels, Input und Output muss man glaube ich dann eine neue Logik anlegen und diese komplett neu verschalten. Dann wäre es blöd, wenn ich meine RTR Logik schon 22 mal im Einsatz habe.

StefanW hat geschrieben: ↑Di Sep 17, 2019 11:17 am 1. Reaktion auf das Ausbleiben von Telegrammen

2. Reaktion auf sich "nicht mehr verändernde" Werte trotz Telegrammeingang (irgendas "hängt" und sendet immer das gleiche, z.b. die ewige wiederholte Sendung eines persistenten Wertens, der jedoch keine Änderung mehr erfährt).