Erweiterte Anzeige der Rollladenposition mittels LEDs

[Smylo]

Hallo zusammen,

ich verzweifel gerade an der Programmierung zur Anzeige der Rollladenpostion mittels LEDs und hoffe Ihr könnte mir auf die Sprünge helfen...

Ausgangssituation:
- Positionierung erfolgt über virtuelle Module
- Positionierungsbefehle erfolgen immer über ein Modul, ausgenommen "offen" und "geschlossen", diese Befehle werden immer direkt ans virtuelle Modul geschickt.

Zielsetzung:
Neben der konsolidierten Anzeige der Position möchte ich noch eine Unterteilung in "Süd" und komplettes Haus haben.

Statusse: "aus" (offen), "ein" (geschlossen), "blinken" (Sonnenschutz) und "flackern" (Schlitzstellung).

Erläuterung:
Zwei LEDs des GT6 sollen mir den aktuellen Status der Rollladenposition anzeigen.
LED1=Süd (mit vier oben benannten Statusanzeigen)
LED2=Komplettes Haus (mit den vier oben benannten Statusanzeigen)
LED1 & LED2=Individuell (Rollläden auf der Südseite und/oder Rest des Hauses haben unterschiedliche Positionen)

Beispiele:
- Die Rollläden im Süden stehen auf Sonnenschutz, somit blinkt die LED1 (LED 2 ist aus)
- Alle Rollläden stehen auf Schlitz, somit flackert die LED2 (LED1 ist aus)
- Die Rollläden im Süden sind geschlossen und ein Teil der restlichen Rollläden steht auf Sonnenschutz (=individuell: beide LEDs blinken)

Was habe ich bisher gemacht:
Ich bin mittlerweile soweit, dass ich auf zwei Modulen die gewünschten Statusse für sämtliche Rollläden angezeigt bekomme in eben der gewünschten Form "aus" (offen), "ein" (geschlossen), "blinken" (Sonnenschutz) und "flackern" (Schlitzstellung).
Jetzt wollte ich auf dem einen Modul mittels der Logikfunktion die Südseite berechnen lassen und auf dem anderen Modul die Logikoperationen für das komplette Haus. Sofern man einen eindeutigen Status hat, also kein Rollladen individuell eingestellt ist, funktioniert dies auch wunderbar. Da LEDs aber bekanntermaßen nur vier verschiedenen Statusse einnehmen können, muss für die Position "individuell" wohl ein weitere LED her. Soweit auch kein Problem, nur müsste ich jetzt abermals logische Berechnungen durchführen und dies jeweils fürs komplette Haus und die Südseite. Wenn ich das so umsetzen würde, dann habe ich von insgesamt vier Modulen sämtliche Logikberechnungen belegt, jeweils fast alles LEDs verbraucht und das alles nur um mir den Status anzeigen zu lassen...???

Da muss es doch praktischer Lösungsansätze geben, die nicht soviele Ressourcen verschwenden - nur leider bin ich noch nicht über diese gestolpert bzw. kann mich noch nicht hineindenken und das ist der Punkt wo Ihr ins Spiel kommt

Hat jemand eventuell schon mal etwas ähnliches versucht und oder einen Tipp für mich, wie ich das gewünschte Ziel auf einem leichteren Weg erreichen könnte?

Vielen Dank für Eure Unterstützung.
Dino

[Beleuchtfix]

Hi Dino, das wäre für mich ein akademisches Problem, nur verstehe ich den Sinn der Anzeige nicht so ganz. Aber das Logic-Poblem ist so groß, dass du sehr viel Ressourcen verbrauchen musst. Schreibe das mal in eine Tabelle und sehe, wie viele Abhängigkeiten es gibt, dann wirst du feststellen, dass du sehr viel benötigst. Du könntest das in ein LinHK Makro auslagern, das regelmäßig ausgeführt wird, und damit die Modul-Ressourcen schonen.

Für mich ist es nicht logisch, Anzeigen zu haben, die unterschiedliche Eigenschaften haben, je nach Status einer anderen Anzeige. Da würde ich eine 3 LED zur Gesamtanzeige nehmen.

Was zeigen denn die LEDs an, wenn du nur einen Rollladen im Süden auf Sonnenschutz hast? Genau diese Logik würde ich auch für LED 2 nehmen.
Aber natürlich entscheidet der Kunde, was er will. Ich sehe da nur die Möglichkeit, das in ein Makro auszulagern.

Viel Erfolg
Florian

[Uwe]

Moin Dino,
ohne mir jetzt mal weiter Gedanken zu machen (ich hätte das wohl auch ähnlich parametriert) - aber genau für diese "ausgehenden Ressourcen" hat Niko die VM's 'erfunden'
Die LCN-Module sind halt keine SPS - in der wäre das deutlich einfacher zu programmieren.

Grüße, Uwe - der komplexe Logiken auch gerne mal in Software-Makros/Skripte auslagert

[Niko]

Hallo Dino,

da hast Du Dir ja was vorgenommen...

Da Du ohnehin Deine virtuellen Module zur Positionierung einsetzt, kannst Du diese auch zur "Berechnung" solcher Logiken nutzen. Das Suchstichwort für die vM-Doku lautet "Bedingungen". Dabei kannst Du sogar die Motorposition direkt auswerten (bis LinHK 0.122 wird leider ein "Korrekturfaktor" benötigt, siehe LinHK-Fehlerliste), Du dürftest damit deutlich weniger Ressourcen brauchen. Für die gewünschte LED-Ansteuerung wirst Du sicher noch ein paar zusätzliche Ressourcen benötigen, aber es dürfte klappen. Und notfalls gibt es ja noch den LinHK-Supportbereich :rolleyes:

Die vorgeschlagenen Makros sind für solche Dinge eher ungeeignet, da man in ihnen nicht gerade performant und zuverlässig den Busstatus auswerten kann, sie sind eher für die große weite Welt gedacht, also alles außerhalb des Busses. Die vM hingegen können "live" auf Änderungen im Bus reagieren, wenn man es richtig anstellt.

Schöne Grüße
Niko, der unter den derzeitigen Bedingungen lieber im Garten sitzt B)

[Smylo]

Erstmal vielen Dank für Eure Antworten!

@Niko
Ich könnte mich schwarzärgern, dass ich diesen Punkt damals nur überflogen bin und mich nicht schon längst daran erinnern konnte bzw. den Abschnitt nicht noch mal gelesen habe... -> genau jenes hatte ich schon öfters schmerzlich vermisst!!! Die Option mit den Bedingungen bietet ja schier endlose Möglichkeiten!!! :thumbup:
Da werde ich erst mal meine wilden Konstrukte mittels LED-Logiken entfernen und auf Bedingungen umsteigen, dadurch sollte sich die Buslast extrem reduzieren lassen.

Aber jetzt zurück zum Ausgangspunkt dieses Beitrages. Die angesprochene Problematik mit @@Condition und der Motorpositionierung ist natürlich äußerst ärgerlich. Ich hatte erst gehofft, dass sich er Wertebereich einfach nur verschiebt, also aus 0-200 wird halt 0-100 und "120" wäre dann "60", aber leider ist dem ja nicht so. Steht demnächst ein Update der LinHK an, wo das Problem behoben ist, oder gibt es eventuell einen Workaround, damit ich tatsächlich direkt mit den aktuellen Motorpositionen arbeiten kann? Wäre halt einfach genial, da kommen mir Ideen...

Gruß
Dino

[Niko]

Abgesehen von dem von mir bereits erwähnten leider erforderlichen "Korrekturfaktor" bis LinHK 0.122 sind mir keine Fehler bei der Auswertung der Motorposition bekannt. Daher noch einmal: Falls Du weitere Hilfe benötigst, beschreibe Dein Problem bitte mit Deinen konkreten Parametrierungen und Beobachtungen vollständig in einem neuen Thread im LinHK-Supportbereich, denn dazu ist er da.

Schöne Grüße
Niko, der immer das vollständige Lesen der Doku empfiehlt, da gibt es keinen Workaround

[Smylo]

Ich habe dieses Thema mal ins LinHK-Supportforum verschoben...