Logikentwurf zur Statusübersicht

[MIT]

Ich bin nun bereits eine Weile am grübeln; finde allerdings keine brauchbare Lösung für eine Problematik bzgl. einer Statusübersicht mit Interaktion:

Kurzum: Ich möchte in meiner Visu gerne eine Seite integrieren, die mir ffg. Funktionen / Übersichten erlaubt:
- Anzahl der (bspw. auf einer Ebene oder komplett im Haus) aktiven Leuchten (also: Wie viele Lampen sind aktuell an?)
- Auflistung der Leuchten, die den Status AN haben (also: Welche Lampen sind an?) Diese Auflistung sollte NUR DIESE zeigen.
- Möglichkeit diese zentral auszuschalten (Alles-AUS) oder Möglichkeit der einzelnen Schaltung der jeweiligen Lampe (somit eine dynamische Darstellung der KOs, die den Wert 1 im Status haben in der Visu; d.h. ich möchte nicht alle Lampen darstellen, die ich im Haus habe und diese über eine Statusanzeige abbilden (das wäre ja kein Problem), sondern ich möchte das gerne dynamisch machen => geht das mit "Bordmitteln" oder wäre das eine Aufgabe für einen LBS?

Mir ist nun nicht klar, wie ich diese Liste im Logikeditor hinbekomme. Einen WENN-DANN-LBS gibt es (noch) nicht, oder?
Habe ich die Möglichkeit die Anzahl der Lampen (und welche Lampe den Status 1 hat) in ein Datenarchiv zu schreiben und dieses zu filtern? So nach dem Motto: WENN Status == 1 DANN schreibe KO in eine Liste (Array? / temporäres Datenarchiv?) - Anschließend dann in der Visu die Darstellung dieser Liste; im Optimalfall dynamisch; wie oben geschildert.

War das verständlich? Gibt es Fragen zu meiner Idee? - DANKE !

EDIT: Ach ja: und ganz analog könnte man so etwas natürlich auch für die Fenster verwenden, die gerade offen stehen ... die gehen nur leider i.d.R. nicht auf Knopfdruck zu ... ;-)

[MrMirror]

Wie wäre es mit Status KOs addieren?

So mache ich das bei der Anzahl meiner offenen Fenster...!

[MIT]

Okay... Danke! Eigentlich ja recht trivial ... :-) .... allerdings: Hast Du auch eine Idee wie man nur die Fenster (bspw.) - dynamisch - anzeigt, die es betrifft?

[gaert]

Aktuell gibt es nur eingeschränkte Möglichkeiten:
- Meldungsarchiv: immer wenn ein Status geändert wird das Archiv komplett leeren, dann nacheinander die Stati eintragen
- oder entsprechende Visuelemente erstellen und diese ein-/ausblenden (bzw. verschieben - dann wird's kompliziert...)
- denkbar wäre auch eine Logik, die ein KO mit Text füllt: "Lampe1<br>Lampe2<br>..." - nur gibt's aktuell noch keinen LBS, der Strings zusammenführt (könnte ich ja glatt mal erstellen...)

[wintermute]

nur gibt's aktuell noch keinen LBS, der Strings zusammenführt (könnte ich ja glatt mal erstellen...)

wohl: https://service.knx-user-forum.de/?c...ad&id=19000154

[gaert]

Ah... Na wunderbar - besten Dank

Ich habe auch gerade einen LBS gebastelt - allerdings ohne Trigger (den wollte ich optional anbieten). Ich werde dann eine Kombination aus Deinem und meinem LBS demnächst als System-LBS einfügen (18000001).

[wintermute]

Ich hatte den Trigger auch eigentlich nur zum "Durchreichen" dabei - um Bausteine zu Kaskadieren wenn die Eingaenge nicht reichen sollten...

[gaert]

Der Trigger macht in manchen Situationen schon Sinn (also der Eingang "Trigger"): Sonst würde bei jeder Änderung an einem der String-Eingänge ein neuer String berechnet - und das kann manchmal doof sein, z.B. wenn man einen "Gesamtstring" archivieren möchte und die Telegramme nach und nach eintrudeln. Daher habe ich in meinem LBS zwei Modi zur Wahl gestellt: Bei jeder Änderung berechnen oder erst beim einem Trigger berechnen:

###[DEF]###
[name        =Strings verbinden 10-fach        ]

[e#1        =String 1     ]
[e#2        =String 2     ]
[e#3        =String 3     ]
[e#4        =String 4     ]
[e#5        =String 5     ]
[e#6        =String 6     ]
[e#7        =String 7     ]
[e#8        =String 8     ]
[e#9        =String 9     ]
[e#10        =String 10     ]
[e#11        =Trigger ≠0 #init=0            ]
[e#12        =Modus 0/1 #init=0                ]

[a#1        =String        ]
[a#2        =Trigger    ]
###[/DEF]###


###[HELP]###
Dieser Baustein fügt die Eingangswerte zu einem String zusammen.

Die Verknüpfung zu einem String wird entweder bei jedem neuen Telegramm ≠[leer] an einem Eingang E1..10 berechnet (Modus E12=0), oder die Verknüpfung erfolgt erst bei einem Telegramm ≠0 an E11 (Modus E12=1).

E1..E10: Wert ≠[leer]
E11: Trigger ≠0
E12: Modus: 0=bei jedem Telegramm an E1..10 einen String an A1 ausgeben, 1=String erst an A1 ausgeben wenn an E11 ein Telegramm ≠0 anliegt
A1: Ergebnis als String
A2: Trigger: wird auf 1 gesetzt sobald A1 auf einen neuen String gesetzt wurde (z.B. zur Kaskadierung)
###[/HELP]###


###[LBS]###
<?
function LB_LBSID($id) {
    if ($E=getLogicEingangDataAll($id)) {
    
        $trigger=false;
        if ($E[12]['value']==0) {
            for ($t=1;$t<=10;$t++) {
                if (!isEmpty($E[$t]['value']) && $E[$t]['refresh']==1) {
                    $trigger=true;
                    break;
                }
            }
        } else if ($E[11]['value']!=0 && $E[11]['refresh']==1) {
            $trigger=true;
        }
        
        if ($trigger) {
            $n='';
            for ($t=1;$t<=10;$t++) {
                $n.=$E[$t]['value'];
            }
            setLogicLinkAusgang($id,1,$n);
            setLogicLinkAusgang($id,2,1);
        }
        
    }
}
?>
###[/LBS]###


###[EXEC]###
<?

?>
###[/EXEC]###

[MIT]

Cool ... :-) ... DANKE!
IHR seit SPITZE!!!

[gaert]

Ich werde demnächst mal ein "Listen-Visuelement" basteln, dass aus einem KO-Wert eine Liste erstellt. Das KO muss dann als "CSV"-String aufgebaut werden, also z.B. "Eintrag1,Eintrag2,..." - wobei der Separator (Komma) frei wählbar sein wird.

[coliflower]

Ich werde demnächst mal ein "Listen-Visuelement" basteln, dass aus einem KO-Wert eine Liste erstellt. Das KO muss dann als "CSV"-String aufgebaut werden, also z.B. "Eintrag1,Eintrag2,..." - wobei der Separator (Komma) frei wählbar sein wird.

Vielleicht bringt mich das dann auch mit meiner Liste (VISU) mit Playlist-Namen weiter ...

[wintermute]

Schande ueber mich, ich habe das kommende Update nicht erwartet und jetzt kommt das zu spaet

setLogicLinkAusgang($id,2,1); 

IMHO macht es Sinn, den Trigger so wie er ist weiter zu reichen, also eher ein:

setLogicLinkAusgang($id,2,$E[x]['value']); 

einfach weil ein Trigger vllt nicht nur 0/1 sein kann, sondern auch ein String. Und wenn man den weiter verwenden will, dann geht an der Stelle Information verloren...

[gaert]

Richtig, aber der Trigger (z.b. KO) liegt doch eh vor - warum diesen also durchreichen?

[wintermute]

Richtig, aber der Trigger (z.b. KO) liegt doch eh vor - warum diesen also durchreichen?

Weil der Trigger zB auch ein String sein koennte, den man in einem "spaeteren" Baustein noch auswerten moechte. Ich hab grad kein konkretes Szenario vor Augen, aber bei meinen Squeeze-Sachen koennte das zB ein Kommando sein, also sowas wie "play" zB und nicht nur 0/1...
Mir geht es erstmal nur um den Informationsverlust, wie bei den Physikern und den Schwarzen Loechern, ma sagen

[gaert]

Ich verstehe was Du meinst - und wir reden geschmeidig aneinander vorbei

Folgendes Szenario: Trigger ist ein String und ist z.B. ein KO (oder auch ein LBS-Ausgang). Warum dann diesen "Trigger" (also das Objekt quasi) nicht einfach nochmal an dem erforderlichen Baustein anlegen? Er wird den String-LBS doch ohnehin triggern, falls er !=0 ist - also kann genau dieses "Objekt" doch auch jeden beliebigen anderen (geeigneten) LBS triggern... Oder meinst Du quasi die "Verkettung", d.h. der LBS triggert erst den nächsten LBS, wenn er fertig ist?

Ich bevorzuge bei LBS ja 0/1-Ausgänge - macht die Sache für Anfänger i.d.R. einfacher zu verstehen (siehe Ausgangsbox - die meisten Leute sind wohl verwirrt wegen !=0 und !=leer).

Aber wenn Du gesteigerten Wert darauf legst, füge ich gerne noch einen A3 hinzu (der dann den Trigger-Wert erhält). Soll A3 denn nur dann gesetzt werden, wenn der LBS per E11 getriggert wurde - oder auch, wenn der "Modus"=0 ist (der LBS also durch E1..10 getriggert wurde)?