Neue Logikbausteine für den L1/X1: Formelberechnung, Statistik und mehr...

[SirUli]

Feedback wie immer -- nach Lesen der Dokumentation -- hier im Thread.

Hi Horst,

danke für dein Update - wundervolle Neuerungen Die Doku schon alleine ist deutlich umfangreicher geworden - das ist sehr hilfreich! Updates haben schon mal geklappt - sieht gut aus

Da du Feedback wünscht - im Textformatierer findet sich in der Doku ein "gewünchte" statt "gewünschte" Also nichts gravierendes

Viele Grüße,
Uli

[hyman]

Hallo Uli,

das ging ja schnell. Der Schreibfehler wird in der nächsten Version behoben. Wenn Du noch mehr findest, nur immer her damit ...

Obwohl diese Version mit über 96% Testabdeckung die bestgetestete ist, die es je gab, kann immer was sein. Ich schau den Bausteinen auch noch etwas genauer auf die Finger in meiner Anwendung ... bisher aber alles gut.

Grüße von Horst

[Kelvingradcelsius]

Bei mir ist der Textformatierer, die Formelberechnung und der XML/JSON Parser in diversen Logikblättern im Einsatz. Alle ziemlich seit Veröffentlichung. Was soll ich sagen, funktionieren alle tadellos.

Vielen dank für die Bausteine und die Zeit die du investiert hast, die helfen extrem und geben dem X1 aus meiner Sicht einen riesen Mehrwert. Besonders in Verbindung mit einem der HTTP Bausteine. Habe den von dalbuschat in Einsatz. Auch dir vielen Dank an dieser Stelle. Auch ohne “s“ ist im Heimmetz bereits vieles möglich.

[dalbuschat]

Danke Kelvingradcelsius

[martiko]

hyman
Auch von mir nochmal ein großes Dankeschön. Deine Logikbausteine sind alles absolute Spitze und erleichtern die Logik-Erstellung ungemein, nein viel mehr, sie machen Dinge möglich die mit "Bordmitteln" gar nicht gehen würden.

Ich habe die Formelberechnung gerade verwendet um aus zwei Helligkeitswerten den Mittelwert zu erzeugen, das soll mir zu Visualisierung des Dimmers eines Raums mit zwei Lampen dienen.
Ich habe es hinbekommen, bin aber über 1-2 Hürden "gestolpert" und bin jetzt etwas unsicher, ob ich die richtigen Ein- und Ausgangsdatentypen gewählt habe.
Und zwar sind die beiden Eingänge und der Ausgang vom Datentyp 5.001 Prozent (0..100%), ist es da richtig in der Formel Number (also N) zu verwenden und den Ausgang auch als "Number" zu definieren? Ich hatte es erst mit I für Integer probiert, das gab dann aber Fehlermeldungen.

[hyman]

Number ist schon OK für Prozentwerte, mach ich auch immer so.

Integer sollte im Prinzip auch gehen, aber dann wäre der Wertebereich z. B. bei DPT 5.001 nicht mehr 0..100%, sondern 0..255 (einheitenlos) -- eher unhandlich.

Bei den Variablen-Datenpunkten bietet Gira bei Weitem nicht alle DPTs 1:1 an. Daher wird man Prozentwerte fast immer in einen Dezimalwert übernehmen und mit diesem weiter rechnen. Generell müssen die verbundenen Ein- und Ausgänge kompatible Datentypen haben. Eine automatische Umwandlung macht Gira nur in bestimmten Fällen, aber bei weitem nicht in allen.

[martiko]

Hi hyman
noch mal eine kleine Nachfrage, ich bin unsicher ob ich da was falsch mache, ob die Konvertierung ungenau ist oder ob ich einen (kleinen) Bug in der Formelberechnung gefunden habe... Und zwar geht es wieder um Prozentwerte... ich möchte einen Rollladen wie "unten" behandeln, wenn er über 85% geschlossen ist, daher hab ich eine minimale Logik gebaut:
Eingang: Rollladen-Position% (DT 5.001)
Formbelberechnung: "{Position:N} > 85", Ausgangstyp: BOOL
Ausgang: Rollladen-Status-(fast-)Unten: (DT: 1.001)

Und wenn ich jetzt Prozentwerte auf den Eingang schreibe (den Aktor habe ich noch nicht, ich schreibe einfach per ETS-Gruppenmonitor) funktioniert alles gut und wie gewünscht, bis auf genau die Grenze, denn genau bei 85% kommt auf dem Ausgangs-Status schon eine "1" an, bei 84% noch wie erwartet eine "0".
Siehe hier:
fast-unten.png

Witzigerweise - und darum vermute ich wirklich ein Problem bei der Konvertierung der Zahlen - funktioniert es in der Simulation exakt wie erwartet, da kommt auch beim Wert 85 noch eine 0 und erst ab 86 die 1.

Ist für mich überhaupt kein Problem (selbst die 85% sind aktuell geraten), ich dachte nur es wäre spannend (und für die Zukunft hilfreich) die Hintergründe zu verstehen. vielleicht hast Du ja einen Hinweis für mich, wie man das besser machen kann oder solche Probleme umgehen kann.

PS: Auch bei dem Beispiel frage ich mich mal wieder, wie ich das ohne Deinen Baustein gemacht hätte, solche Funktionen sind doch eigentlich essentiell Also bitte auf keinen Fall als Kritik verstehen!

[hyman]

Hallo Martin,

danke für Dein Feedback. Und mach Dir mal keine Sorgen, Kritik kann ich schon von einer Frage unterscheiden. Und berechtigte Kritik vertrag ich auch; ich pflege ja selbst einen sehr direkten Kommunikationsstil.

Zu Deinem Thema: DT 5.001 ist ein 8-Bit-Wert mit einem "rohen" Wertebereich 0..255. Der kann 85,0% gar nicht abbilden. Der Rohwert 216 bedeutet 84,7%, der Rohwert 217 dagegen schon 85,1%. Somit ist es in diesem Fall völlig egal, ob Du "... > 85" oder "... >= 85" hin schreibst.

Ich vermute, der Unterschied zwischen "echtem Leben" mit ETS und "Simulation" mit GPA ist folgender:

• Die ETS schreibt 85% als Rohwert 217 auf den Bus (dritte Zeile in Deinem Screenshot; $D9 ist die hexadezimale Schreibweise dieser Zahl). Das empfängt der X1 als 85,1%, also >85
• In der Simulation schreibst Du 85 auf den Ausgang des Eingangsbausteins. Das gibt der an den Eingang der Forrmelberechnung (vermutlich vom Typ double) unverändert als 85,000% weiter, also nicht >85.

Die einzige Art solche Problem zu umgehen ist, sich über die tatsächliche Auflösung der verwendeten DPT- und Datentypen im Klaren zu sein.

Grüße von Horst

[martiko]

Hallo Horst,
danke für die Erklärung, dann lag ich mit meiner Vermutung dass es an der Konvertierung liegt ja fast richtig, wobei es nicht um GPA selbst sonden logischerweise die Umrechnung von Prozentwert in 255 Bit geht. Irgendwie hatte ich naiv gedacht dass man da die 85 1:1 in binär umrechnet (also 55), dass das nicht stimmt hätte ich natürlich am Gruppenmonitor selbst erkennen können. Wie Du schon geschrieben hast, nutzt der DT 5.001 die volle 8 Bit Auflösung aus, was mehr Genauigkeit bietet, aber dann eben auch zu solchen Abweichungen führt.

Sehr gut, wieder was gelernt!

PS: Ist Gira eigentlich nie mal an Dich herangetreten, dass sie Deine(n) Logikbausteine direkt als "Standard" integrieren wollen? Wie bereits mehrfach erwähnt, wüsste ich an vielen stellen gar nicht, wie ich gewisse Dinge ohne die Bausteine (vor allem eben die Formelberechnung) umsetzen sollte..

[hyman]

255 Bit

Sind nur 8 Bit, Wertebereich 0..255

Ist Gira eigentlich nie mal an Dich herangetreten, dass sie Deine(n) Logikbausteine direkt als "Standard" integrieren wollen?

Nö, wären sie ja auch schön blöd. Die verkaufen doch lieber ihre Erweiterungen. Selbst bei Sachen, die mit nativen Bausteinen leicht gehen, spart man nämlich mit der Formelberechnung gern mal 10 Logikbausteine auf einem Blatt. Und wer soll dann noch mehr als 250 Funktionen brauchen?

Grüße von Horst

[martiko]

PS: Klar 8 Bit, 0...255 Wertebereich, hab mich nur vertippt ;-)

[mmschlosser]

Hallo Horst,

vielen Dank für deine Bausteine und deine zielführenden Hinweise von Ende Dezember (bin leider erst jetzt zur Umsetzung gekommen). Der fehlende Wertgenerator hat das Problem gelöst. Jetzt arbeiten MDT Glastaster, MDT Dali Schnittstelle und OSRAM OTI 4Ch LED Treiber ziemlich gut zusammen. Auf der einen Seite der Glastaster mit HSV Farbsteuerung und auf der anderen Seite der OSRAM (leider nur DT6) RGB Steuerung. Man kann die Farben sowohl am Glastaster als auch am X1 RGBW Steuerelement steuern.

VG Michael Schlosser

[thojoh]

Hallo Horst,

erstmals vielen herzlichen Dank für deine sehr nützlichen Bausteine - diese werten eine VISU mit dem X1 ungemein auf!

Kannst du mir bitte verraten, ob die "Calendar"-Klasse beim Baustein Formelberechnung überhaupt funktioniert oder ich nur bei der Eingabe was falsch mache?

Ich würde gerne die aktuelle Kalenderwoche bestimmen (Typ-Ausgang-Formelberechnung = INTEGER):

CultureInfo.CurrentCulture.Calendar.GetWeekOfYear(DateTime.Now, CalendarWeekRule.FirstDay, DayOfWeek.Monday)

Bekomme folgenden Fehler (in Simulation als auch am X1):
Expression 4: (1,2): error CS0103: The name `CultureInfo' does not exist in the current context

Danke und Grüße,
Johannes

[hyman]

Hallo Johannes,

Du bist in der falschen Namespace-Hierarchie unterwegs, deshalb wird schon CultureInfo nicht gefunden, Außerdem ist Calendar gar nicht unter CultureInfo.CurrentCulture drin, sondern unter System.Globalization ...

Probier mal: System.Globalization.Calendar.GetWeekOfYear(...)

Grüße von Horst

[thojoh]

Hallo Horst,

danke für den Hinweis.

Habe mal die ganzen Namespaces korrigiert - leider ohne Erfolg:

System.Globalization.Calendar.GetWeekOfYear(System.DateTime.Now, System.Globalization.CalendarWeekRule.FirstDay, System.DayOfWeek.Monday

Anbei die Fehlermeldung in der Simulation:
Expression 4: (1,32): error CS0120: An object reference is required to access non-static member `System.Globalization.Calendar.GetWeekOfYear(Syste m.DateTime, System.Globalization.CalendarWeekRule, System.DayOfWeek)'

Fällt dir noch etwas auf?

Grüße
Johannes