HS/FS Logik, Laufzeit und Reihenfolge der Berechnung

[GKap]

Hallo alle!

Eine Frage zur Logik und zur "Sauberkeit" der Programmierung:

Eigentlich eine ganz einfache Aufgabenstellung: Helligkeitswerte aus einer Wetterstation sollen geglättet werden, das geht gut mit dem Baustein "Gleitender Durchschnitt". Leider kommt von der Wetterstation hin und wieder tagsüber der Wert 0, was zu einem Fehlverhalten der Jalousien führen würde. (Das ist ein Fehler der Wetterstation, wurde vom Hersteller bestätigt und ist in Arbeit...) Diesen Fehler möchte ich im HS korrigieren.

Ich möchte daher 0-Werte einfach verwerfen. Das habe ich zuerst so probiert, wie in ""Logik1.gif" zu sehen ist. Manchmal funktioniert das, manchmal nicht. Das ist auch logisch für mich, da bei der Sperre das Telegram möglicherweise schon durchgeleitet wurde, noch bevor der Vergleich die Sperre sperren würde!

Also habe ich es mit "Logik2.gif" probiert. Das funktioniert zwar wie erwartet, aber es kommt mir ziemlich unsauber vor! Vor allem: wie klein könnte ich die Verzögerung machen, damit die Zuverlässigkeit bleibt?

wie löst ihr so etwas?
fragt mit Grüssen
GKap

PS, noch eine Zusatzfrage: Der Baustein "Telegrammverzögerung" liefert lt. Hilfe nur einen 1-Bit Wert am Ausgang. Nach meinen Beobachtungen werden aber alle Telegramme, unabhängig vom Datentyp richtig durchgereicht! Ist das ein Fehler in der Doku?

[MatthiasS]

Ich mache einen Vergleich ungleich Null und setzte bei Ja das Anzeige/Archivobjekt auf den Eingangswert (Setze auf Wert von KO...)

Man müsste mal probieren, ob diese Methode beim KO-Dialog auch den Eingangswert begrenzt:

Min-Wert, Max-Wert
Diese beiden Grössen setzen die Minimal-/Maximalwerte die durch den HS/FS auf den EIB ausgegeben werden (bezüglich des aktuell ausgewählten Objekts).
Dieser Bereich ist unabhängig vom Wert des Aktor/Sensors auf dem EIB.
Hiermit können unter anderem Fehler in der Programmierung global unterdrückt werden, die kleinere/grössere Werte als beabsichtigt auf das Objekt schreiben.

[Tokamak]

lso habe ich es mit "Logik2.gif" probiert. Das funktioniert zwar wie erwartet, aber es kommt mir ziemlich unsauber vor! Vor allem: wie klein könnte ich die Verzögerung machen, damit die Zuverlässigkeit bleibt?

Es ist auch so nicht zuverlässig. Selbst die Verzögerung von 1 Sekunde könnte - theoretisch, praktisch wohl nicht - nicht reichen.

wie löst ihr so etwas?

Um der Unsauberkeit, die ich genauso empfinde, zu umgehen: Eigene Bausteine. Einer meiner Bausteine heißt "Ungleich", der nur dann einen Wert auf dem Ausgang schickt, wenn er ungleich einem zweten Wert ist. In deinem Fall wäre der zweite Eingang 0.

Viel Erfolg
Marcus

[GKap]

Hallo Tokamak!

Um der Unsauberkeit, die ich genauso empfinde, zu umgehen: Eigene Bausteine. Einer meiner Bausteine heißt "Ungleich", der nur dann einen Wert auf dem Ausgang schickt, wenn er ungleich einem zweten Wert ist. In deinem Fall wäre der zweite Eingang 0.

Ja, an einen eigenen Baustein habe ich auch gedacht. Aber nachdem bei mir eine solche Konstellation öfters vorkommt, habe ich angenommen, dass es dazu eine geeignete Methode geben müsste! Ich werde doch nicht der einzige sein, der über eine Bedingung manchmal Aktionen sperren möchte!

meint
GKap

[Tokamak]

Nunja, die geeignete Methode ist eigene Bausteine.

Mir fehlen auch einige Konzepte in der Ereignissteuerung, die man aus prozeduralen Programmiersprachen kennt. Ein echtes "If" fehlt mir am meisten, d.h. ein Möglichkeit, ganze Logiken nur dann auszuführen, wenn bestimmte Bedingungen zutreffen. Ansonsten sollen sie nicht ausgeführt werden.
Das geht in dem HS-Konzept letztlich nur mit eigenen Bausteinen.

[GKap]

Hallo Tokamak!

...
Das geht in dem HS-Konzept letztlich nur mit eigenen Bausteinen.

Richig, und das führt mich gleich weiter zu meiner nächsten Frage, wie macht man sinnvollerweise Folgendes:
Um bei dem Beispiel mit den Helligkeitswerten zu bleiben: Oft ist es notwendig, den letzten Messwert oder den letzten Wert der Berechnung in die neue Berechnung mit einzubeziehen. In konventioneller Programmiertechnik weise ich das einfach einer Variablen "LastValue" zu, die ich dann mit verwende. Beim Homeserver geht das so nicht. denn wenn ich z.B. in ein KO "LastValue" etwas reinschreiben würde, dann würde das sofort wieder ein Neuberechnung auslösen.

Es fehlt mir hier die Möglichkeit eine "atomaren" Abarbeitung einer Logik, wie ich das von anderen Echtzeitsystemen kenne. D.h. eine Logik sollte auch aufgrund eines bestimmten Ereignisses ablaufen können und nicht nur bei jedem Eintreffen eines Telegramms!

Mit eigenen Bausteinen und remanenten Speichervariablen lässt sich das sicher machen. Vielleicht habe ich die Konzepte des Homeservers noch nicht genügend gut verstanden, aber wenn es für solche simplen Aufgabenstellungen standardmässig keine Methoden gibt, dann ist das schon etwas schwach!

meint
GKap

[Tokamak]

Ähnlich wie du habe ich mit der Ereignissteuerung des HS stark gehadert, weil sich damit viele Konzepte, die man aus der Standardprogrammierung kennt, nicht umsetzen lassen. Letztlich sind die Logiken des HS nichts anderes als EIB-Geräte, die GAn empfangen, dann tätig werden und GAn senden.

Um ein wenig besser klarzukommen, haben ich mir neben einigen anderen einen Baustein geschrieben, der alle unären und binären logischen und arithmetischen Operationen anbietet und bei dem gesteuert werden kann, wann er ein Resultat liefert (Eintreffen eines Wertes auf E1, Eintreffen auf E2 oder Eintreffen eines Triggers unabhängig von den Eingängen). So kann ich bestehende Werte erst dann nutzen, wenn ich sie brauche, d.h. eine Änderung eines Wertes triggert - so ich will - die Logik nicht.

Wenn Dacom Ifs und Schleifen anbieten würde, wäre die Welt schon einfacher. Aber die Verbesserungen in den letzten Versionen bezogen sich fast nur auf die GUI, die für mich uninteressant ist.

[swenga]

Aber die Verbesserungen in den letzten Versionen bezogen sich fast nur auf die GUI

Ich habe mir auch schon einiges Mal ob der Logik-Abläufe im HS die Haare gerauft. Aber jetzt stell Dir mal vor, die ändern wirklich was an der Logikengine, plötzlich funktionieren einige hundert Bausteine beim Kunden nicht mehr, das ist eine Zeitbombe sondergleichen!

mfg

[Tokamak]

Um Himmels Willen, die Bausteine können und sollen nicht mehr geändert werden. Man könnte sie höchstens erweitern, etwa, in dam man pro Eingang markieren kann, ob dieser die Berechnung des Bausteins triggert oder nicht.

Aber was spricht dagegen, den Logikeditor um Konstrukte wie "if" und "while" zu erweitern? Nur, wenn die genannte Bedingung erfüllt ist, wird die Logik im Body ausgeführt. Dort können dann die altbekannten Bausteine eingefügt werden.

[swenga]

Gebe ich Dir zu 100% Recht. Diskrete Ausführung sowie Schleifen und klare Bedingungen wären wünschenswert. Die zwangsläufige Abwärtskompatibilität wird hier IMHO aber eine gewisse Hemmschwelle seitens des Herstellers verursachen, leider....

mfg

[MatthiasS]

Schleifen, Bedingungen, innerhalb eines Bausteines doch überhaupt kein Problem. Die Bytecode-Bausteine von Nils (und anderen) nutzen das intensiv.

[Tokamak]

Vermutlich liegt es auch am Marketing. "Männer-Visus" lassen sich besser verkaufen als eine Programmierschnittstelle, die dem Namen gerecht wird.

Mir ist es total zuwider, mit einer Maus a la Turtle bunte Kästchen zu verschieben. Meine Logik für eine externe Steuerung der Wärmepumpe (die keine KNX-Schnittstelle hat) ist derartig komplex, dass sie durch den Experten nicht mehr geprüft werden kann. An ihr habe ich tagelang gesessen, und sie ist immer noch nicht fehlerfrei. Mit einer richtigen Programmiersprache wäre das Thema in wenigen Stunden abgefrühstückt gewesen.

Die meisten haben sich damit abgefunden oder wie Nils einen Workaround gefunden, mit dem Dacom sicher nicht gerechnet hat. Ich selbst habe wegen der grottigen Programmiermöglichkeiten mit dem Gedanken gespielt, den HS wieder zu verkaufen und auf inzwischen vorhandene Alternativen umzuschwenken. Hierzu fehlen mir aber insbesondere Zeit und Muße, alleine schon für die Aus- und Bewertung der Alternativen.

[MatthiasS]

Mit einer richtigen Programmiersprache...

Bezeichnest du Python nicht als eine solche?

[Tokamak]

Schleifen, Bedingungen, innerhalb eines Bausteines doch überhaupt kein Problem. Die Bytecode-Bausteine von Nils (und anderen) nutzen das intensiv.

Und ein Fehler in solch einem Baustein zerrupft im schlimmsten Fall den HS derart, dass man nicht mehr an ihn herankommt.
Hinzu kommt, dass sich dahinter kein Konzept verbirgt. Verschiedene Editoren, verschiedene "Programmiersprachen", ein bisschen hier, ein wenig dort...

Wie gesagt, ich habe für mich eine Lösung gefunden. Meine Bausteine sind weiterhin klein, machen mir aber das Leben leichter, weil sie meiner Art zu programmieren ein wenig mehr entsprechen. Die Logik bleibt im Editor des Experten, nicht im HSL-Editor.

Bezeichnest du Python nicht als eine solche?

Doch, sicher. Aber es ist eine Hintertür. Das hat nichts mit einem stringenten Konzept zu tun. Brächte Dacom Python in den Experten, wäre ich dabei.

[GKap]

Hallo MatthiasS!

Schleifen, Bedingungen, innerhalb eines Bausteines doch überhaupt kein Problem. Die Bytecode-Bausteine von Nils (und anderen) nutzen das intensiv.

Also auf Anhieb verstehe ich das Konzept von Nils nicht vollständig, da müsste ich mich erst mal einarbeiten. Aber offensichtkich kann man in den Homeserver mehr reinbringen, als nur die einzeiligen Python-Befehle bei selbst entwickelten Bausteinen. Das würde sicher die Möglichkeiten stark erweitern. ABER: In einem Posting dazu von Michel ist mir eines aufgefallen:

[WARNUNG]Die Nutzung dieser Möglichkeit kann bei unsachgemäßer Anwendung euren HS/FS komplett lahmlegen!

Ich rate dringend davon ab, das auf produktiven HS/FS einzusetzen und/oder zeitkritische bzw. umfangreiche Aktionen in den Code zu packen!

Die Behandlung dieses Codes weicht vom HS-internen Standard erheblich ab!
[/WARNUNG]

Nach meinem Vertändnis soll doch der Homeserver einem gewissen professionellen Anspruch genügen, daher kämen für mich solche Methoden nur dann in Frage, wenn dies von Gira/Dacom auch so vorgesehen und dokumentiert ist!

Oder wie seht ihr das?
fragt
GKap