ElabNET Technik Forum

Ich stehe gerade auf dem Schlauch. Ich brauche eine Logik (die ich in eine Custom einbinde) die dafür sorgt, dass nur der letzte empfangene Wert von 6 Binäreingängen zählt.

Bei And, Or, Break werden ja immer alle Eingänge ausgewertet...Irgendwie stehe ich auf dem Schlauch. Falls es keine Lösung gibt, die ich im Moment einfach nur übersehe, würde ich daraus einen FR machen wollen. Aus meiner Sicht wäre ein eigener Baustein "Last" interessant oder aber das wäre eine Unterfunktion in den beiden Statstik-Bausteinen.

Ich hab das als custom logic versprochen, bin aber noch nicht dazu gekommen.

FR schadet aber trotzdem nicht, dann reden wir sicher vom gleichen.

Lg
Robert

Ich werde mal einen 8-Fach LAST IN Baustein vorbereiten. Vielleicht fällt mir noch was ein, wie ich das mit VAR abdecken kann (für bool dämmert es schon ).

Robert

Das wäre cool, es reicht ja ein 3-fach, dann kann ich mir den selber weiter stricken. Mir fehlt nur die Idee und ich habe keine richtige Lust extra in der ETS zwei neue KNX-Objekte anzulegen und den dann alles hochzuladen usw.... der Workaround, der ja in der anderen Diskussion oben benannt wird, war mir schon klar. Aber den finde ich echt irgendwie doof.

Wenn Latch umgebaut wird, so dass es nicht nur einzelne Werte sondern ein Array annimmt als Eingang, wäre das eine sehr kompakte Lösung: Allerdings müssten existierende Custom Logiken wohl umgestellt werden von Außer es ist / wird beides zulässig - z.B. auch für Break - Array wird erwartet, wenn keines geliefert wird, wird dieser Wert einfach zu Array mit einem Element konvertiert - Quick and Dirty:
$input = (array) $input;

Dante hat geschrieben: ↑Fr Jan 24, 2020 4:25 pm Wenn Latch umgebaut wird, so dass es nicht nur einzelne Werte sondern ein Array annimmt als Eingang, wäre das eine sehr kompakte Lösung:

Code: Alles auswählen

["Latch",["$Eingang1","$Eingang2","$Eingang3"],"$Ausgang","$Wahr",0]
// dynamischer
["Latch",["$VAR<Inhibit?>"],"$Ausgang","$Wahr",0]

Allerdings müssten existierende Custom Logiken wohl umgestellt werden von

Code: Alles auswählen

["Latch","$Eingang","$Ausgang","$Wahr",0]
// auf
["Latch",["$Eingang"],"$Ausgang","$Wahr",0]

Außer es ist / wird beides zulässig - z.B. auch für Break - Array wird erwartet, wenn keines geliefert wird, wird dieser Wert einfach zu Array mit einem Element konvertiert - Quick and Dirty:
$input = (array) $input;

Die Idee mit Latch finde ich gut, aber aus zwei Gründen tendiere ich immer mehr zu einem neuen Modul / einer neuen Basislogik z.B.: ["Last",["$VAR<Eingang!>"],"$Ausgang"]. Begründung:

1. Es ist die einfachste Lösung, auch weil so niemand alte Logiken ändern muss oder die Kompatibilität nicht getestet werden muss. Das war ein wie ich finde sehr gutes Argument von Dir und spricht auch gegen meine Ideen es in die bestehenden Statistik-Bausteine einzubauen. Auch wenn ich finde, dass es von der Sache perfekt in den "Statistik-Baustein" passt, quasi nach dem Motto "wo mean, max und min ist, da muss auch last sein".
2. Ich persönlich hätte in Latch jetzt nicht gesucht und den Baustein gibt es dazu ja auch nicht als Standardbaustein. Ausserdem passen dann der 4te und 5te Parameter dort nicht mehr so rochtig rein oder müssen für den Sonderfall umdefiniert werden und der Baustein wirkt dann irgendwie vergewaltigt.
3. einfach wegen keep it simple.

Hallo zusammen!

Wenn euch das wichtig ist und der Umweg über ein KNX-Objekt als nicht zumutbar gesehen wird (was ich nicht so sehe), dann bitte als FR posten und voten.
Ich hab mich gestern damit länger beschäftigt und bin zur Erkenntnis gekommen, dass das derzeit nicht als Custom Logik umsetzbar ist.

Warum: Dazu muss man wissen, welcher Eingang getriggert wurde. Dies kann man mit der Einschränkung erkennen, wenn ein Eingang nie mit dem gleichen Wert getriggert wird. Wenn man annehmen muss (und davon gehe ich aus), dass jeder Eingang auch mit "a" verwendbar sein soll, dann geht das derzeit nicht und wird auch für ElabNet schwer umsetzbar, da es entgegen dem Konzept Trigger/Sendeoptionen an der Schnittstelle und Auswertung in der Zelle läuft.

Dazu gibt es einen FR (viewtopic.php?f=77&t=1856), der dieses Problem lösen würde und das LAST_IN als Custom ermöglichen würde.

lg
Robert

Alles klar, Robert, danke für die Rückmeldung.

Ich kann die Funktion tatsächlich gut gebrauchen und werde sie nun erst einmal mit KNX umsetzen. Meines Erachtens wäre diese Funktion aber wünschenswert und die Umsetzung über KNX ist nur ein unschöner Workaround. Ich mache dann mal einen FR auf.

Nur für mich zum Verständnis,
Wenn ich im DOS ein neues Objekt -ohne ETS erzeugen könnte- und alle relevanten Binäreingänge als Eingang von diesem TWS-Objekt zuordnen würde, hätte das Objekt doch stets den Status des letzten Binäreingang-Input.
Dieses TWS-Objekt könnte dann als Eingang in einer beliebigen Logik verwendet werden.

Dieses Ansatz wäre also quasi ein Teil von dem FR
Reverse Workflow - oder von hinten durch den Server in die ETS - der ETS Teil wäre in diesem Fall dann halt obsolet...

Also wenn diese Eingänge eh alle irgendwo aus dem KNX kommen, sehe ich keinen wirklichen Grund das in einer Logik zu bauen. Dazu Gibt es dann ein KNX KO mit dem Namen Logik123 Eingang AB und an dieses KO werden alle relevanten GA verbunden und fertig. Ganz nativ KNX. Man muss dem TWS ja nicht nur KO anlegen die immer 1:1 einer im sonstigen Projekt genutzten GA entsprechen. Man kann das auch so machen wie an jedem KNX-Logikmodul usw.