Skript um alle Rolladen auf einmal zu öffnen

[Tschosie]

ich weiß nicht, ob es jemand gebrauchen kann, ich bin neu in der Homematic-Skriptsprache. Ich hatte versehentlich mein altes WebUI-Programm gelöscht, dass mir morgens alle Rolladen im Erdgeschoss geöffnet hat. Da ich nicht jeden Rolladen wieder einzeln in die WebUI klicken wollte, dachte ich mir ich schreibe ein kleines Skript. Nach 3 Nächten hab ichs dann auch geschafft Also wesentlich schneller als WebUI, gell?

1. Ich habe ein Gewerk "RolladenEG" angelegt und alle entsprechenden Rolläden zugeordnet
2. Wenn ich morgens auf eine bestimmten Funkschalter drücke, wird das u.g. Skript ausgelöst

Code: Alles auswählen

! Hole alle Aktoren des Gewerks "RolladenEG"
var objIDs = dom.GetObject("RolladenEG").EnumUsedIDs();
string id; 
var dp;

! Alle Datenpunkte durchlaufen
foreach(id, objIDs){
 ! Einzelnen Aktor holen
 var object = dom.GetObject(id);
 ! Hole den Datenpunkt "LEVEL" des entsprechenden Aktors
 dp = object.DPByHssDP("LEVEL");
 ! Überschreibe den Datenpunkt "Level" mit 1.00 (=offen)
 dp.State(1.00);
}

Normalerweise gehen die Rollläden bei uns ja zeit gesteuert hoch, aber in den Ferien nicht, da mache ich sie von "Hand" auf.
Vielleicht kann das Skript ja noch jemand gebrauchen?

Schönen Urlaub!
Tschosie

[Ondas[tm]]

Also ich habe das mit einer Virtuellen Taste und Direktverknüpfungen realisiert... Jeder, wie er es mag.

[dtp]

In dem Fall bräuchtest du aber gar kein Skript; nicht mal ein Programm, wenn Taster und Aktoren aus der gleichen Serie (HM bzw. HMIP) stammen. Dann geht das nämlich auch sehr einfach mit Direktverknüpfungen.

[Xel66]

Ein schönes Beispiel mehr, die den beobachtbaren Thend belegen, simpelste Steuerungsaufgaben (in diesm Falle Direktverknüpfungen) auf die denkbar komplizierteste Weise umgesetzt werden. Vorzugsweise durch Scriptlösungen. Ich will niemanden angreifen, aber das ist nun mal der Trend, die vom Hersteller vorgesehenen und im System implementierten Funktionen verden mit maximaler Nicht(be)achtung bestraft. Und warum? Weil Handbücher ja nur für andere geschrieben sind. Man weiß ja schließlich wie es geht.

Gruß Xel66

[dtp]

Nun ja, der Einsatz von Skripten ist ja durchaus auch vom Hersteller vorgesehen.

[Xel66]

...durchaus auch vom Hersteller vorgesehen.

Nicht ganz! So pauschalt stimmt die Aussage nicht. Es ist ausschließlich im Rahmen der dokumentierten Befehle für den Endanwender vorgesehen (auch wenn in diesem Beispiel auf den ersten Blick nur solche Dinge genutzt werde). Wäre es so global vorgesehen, würde/müsste der Hersteller es auch supporten. Das tut er aber mit gutem Grund nicht. Würde er es supporten, wären in dem Falle auch nur dokumentierte Funktionen zulässig. Trotzdem ist diese Lösung, die komplizierteste Art, mit Bordmitteln eine Direktverknüpfung zu ersetzen.

Die Funk-Problematik dürfte ähnlich der zu einer gleichzeitigen ("sofort") Ansteuerung per Programm sein. Kollisionen von Fahrbefehlen, Quittierungen und Statusübermittlungen sind vorprogrammiert. Bei letzteren kann man die Gleichzeitigkeit nicht unbedingt verhindern. Gerade bei geschwätzigen Rollladenaktoren ist mit Kommunikationsstörungen zu rechnen. Und als Abhilfe wird dann die Anzahl der möglichen Funkbefehle in den Geräteeinstellungen erhöht und sich anschließend über den "hohen" Duty Cycle des Systems beschwert. Wenn man hier im Forum viel mitliest, dann macht man ständig die gleichen Beobachtungen.

Gruß Xel66

[mazta]

Ein schönes Beispiel mehr, die den beobachtbaren Thend belegen, simpelste Steuerungsaufgaben (in diesm Falle Direktverknüpfungen) auf die denkbar komplizierteste Weise umgesetzt werden. Vorzugsweise durch Scriptlösungen. Ich will niemanden angreifen, aber das ist nun mal der Trend, die vom Hersteller vorgesehenen und im System implementierten Funktionen verden mit maximaler Nicht(be)achtung bestraft. Und warum? Weil Handbücher ja nur für andere geschrieben sind. Man weiß ja schließlich wie es geht.

Gruß Xel66

Diese Direktverknüpfungen sind aber in der WebUI auch sehr kompliziert und nicht besonders intuitiv dargestellt.

Ich würde aber auch nicht alle Rollladen gleichzeitig durch ein Script ansteuern. Bei mir gab es ohne zeitliche Verzögerungen immer Kommunikationsprobleme.

[Xel66]

...Direktverknüpfungen sind aber in der WebUI auch sehr kompliziert und nicht besonders intuitiv dargestellt.

Das mag sein, ist aber nur ein Anfangsproblem. Und mit einem Klick auf die Spaltenköpfe rechts und links kann man das in eine übersichtlichere Art bringen. Dann sieht man, wer mit wem verknüpft ist. Die Voreinstellung der Sortierung an Hand der Benennung ist "unvorteilhaft". Auch gibt es sonst noch etwas Optimierungspotenzial. Aber intuitiver als eine Scripterstellung ist es allemal.

Gruß Xel66

[dtp]

Aber intuitiver als eine Scripterstellung ist es allemal.

Kommt drauf an. Wenn man regelmäßig HM-Skripte schreibt, dann ist das auch nicht komplizierter, als die Steuererklärung.

Und zum Thema gleichzeitiges Auslösen. Absolut gleichzeitig kann die CCU ja nichts auslösen, da sie immer sequentiell arbeitet. Aber ich nutze ja selbst ein Skript zum Steuern meiner Rollläden und kann damit problemlos alle acht (die restlichen vier habe ich noch nicht auf Motorantrieb umgerüstet) nahezu gleichzeitig hoch- und runterfahren (optisch nicht unterscheidbar), ohne dass es zu Kommunikationsstörungen oder dergleichen kommt. Ich mache das nun seit einiger Zeit täglich mehrere Male und finde es einfach schöner, wenn sich die Rollläden einer Hausseite schön synchron bewegen.

[Xel66]

ist das auch nicht komplizierter, als die Steuererklärung.

Mag sein, aber aufwändiger als das Anlegen einer Direktverknüpfung ist es allemal. Und das Fehlerpotenzial ist um Dimensionen höher. Wohlgemerkt, es geht lediglich um eine identische Funktionalität und nicht das Scripting als solches. Scripting hat durchaus seine Berechtigung, wenn Berechnungen durchgeführt, Vergleiche angestellt und mit Strings Operationen durchgeführt werden müssen, die mit den Mitteln der WebUI nicht möglich sind. Aber um vorhandene und dokumentierte Funktionen der WebUI zu ersetzen (wie in diesem Topic), ist es eben weit über das Ziel hinausgeschossen.

Es geht nicht darum, dass man sowas nicht als Fingerübung machen kann. Aber Einsteiger, die sowas finden und lesen halten dieses dann eben für den einzig möglichen und üblichen Weg, eine "gleichzeitige" Ansteuerung zu erreichen und lassen dann eben die Möglichkeiten des WebUI auch links liegen. Mir ist immer noch dieses Heizungsdingens im Kopf, auf das viele Einsteiger geflogen sind, weil es vermeintlich ihre Bedürfnisse abgedeckt hat. Dabei entstand das in einer Zeit, in der die Möglichkeiten der alten (Wand-)Thermostate-Serie noch recht eingeschränkt war und hat dessen Schwächen ausgebügelt. Außerdem war für diese eine zentrale Steuerung ausdrücklich vorgesehen (Cent-Modus). Die erweiterten Möglichkeiten der aktuellen Hardware (Porfilsteuerung etc.) wurde dann wegen diese omnipräsenten Scripts überhaupt nicht wahrgenommen, obwohl die Profile 99,9% der gestellten Anforderungen abdeckt. Großer Nachteil dieses Lösungsansatzes, es musste auf der vergleichsweise schlecht performanten Hardware der CCU2 ein Monsterscript zyklisch ausgeführt werden. Ist zwar alles hier in diesem Topic nicht der Fall, aber solche Missverständnisse durch Einsteiger prägen und generieren einen völlig überflüssigen Supportbedarf (daher auch die Omnipräsenz der Lösung - die zum Glück derzeit in den Tiefen des Forums ruht, weil sie überflüssig geworden ist), denn nicht jeder Eisteiger weiß, wie solche Lösungen zu handhaben sind.

Gruß Xel66