Suche Rule-Beispiele (Alarm und Szenen) für KNX

[mr.b4]

Hallo zusammen,

ich möchte diverse Funktionen/Szenen in meinem Haus über openHAB realisieren.

-So verfügen die verbauten KNX-Dimmer im Schaltschrank über keinen Szenenspeicher. Darum sollen die passenden Dimmwerte zu einer aktivierten Szene über openHAB gesendet werden.

-bei Abwesenheit sollen das Auslösen der Fensterkontakte und Bewegungsmelder eine Email versenden, bzw eine Sirene schalten.

Leider ist Java nicht mein Steckenpferd. Hab mich bisher eher immer mit C im Bereich Arduino beschäftigt.
Darum bin ich jetzt dringend auf Beispiele angewiesen, die ich nach meinen Bedürfnissen abändern kann.

Viele Grüße,

Markus

[udo1toni]

Du musst dazu kein Java beherrschen

opeHAB ist in Java programmiert. Die Rules DSL wurde mit XTEND programmiert, welches wiederum auf Java aufsetzt. Entsprechend gibt es viele Dinge, die ähnlich wie in Java funktionieren, man kann auch z.B. Funktionen importieren, um sie in Rules zu verwenden. Dennoch läuft die Programmierung anders und hat nicht so viel mit Java zu tun.

Szenen:
Da kommt es sehr darauf an, was Du Dir vorstellst. Integrierte Szenenspeicher lassen sich auf Wunsch mit den aktuellen Einstellungen speichern. Diese Funktion lässt sich aber auch sperren, so dass die Szenen nicht veränderbar sind. Letztere Variante ist weitaus einfacher realisierbar als erstere.

Grundsätzlich: Du brauchst für jeden zu steuernden Kanal ein passendes Item (sei es ein Dimmer, ein Schaltaktor, ein Rollladen...) sowie ein weiteres Item, in welchem Du die Szenennummer verwaltest. Du kannst diese Szenen auch per knx-Taster abrufen, wenn der Taster das Senden von Szenen unterstützt. In diesem Fall muss das Item natürlich mit einem Number Channel verlinkt werden, der als Szenennummer konfguriert ist (DPT17.001).
Aber Du kannst auch genauso gut einen Taster als Taster konfigurieren, der nur ein ON oder nur ein OFF sendet. Die Rule muss dann auf diesen Taster triggern.

Rules:
Die Rules DSL (Domain Specific Language) arbeitet eventbezogen. Deshalb benötigt jede Rule einen oder mehrere Trigger. Jeder Trigger löst die Rule aus (es ist nicht möglich, das Triggern einer Rule an Bedingungen zu knüpfen!!!)
Weiterhin benötigt jede Rule einen Code Block, das ist der Code, der ausgeführt wird. Im Code Block der Rule können beliebige Bedingungen beliebig komplex miteinander verknüpft werden. Das bedeutet: Du kannst zwar nicht verhindern, dass eine Rule getriggert wird, wenn das passende Ereignis eintritt, Du kannst aber die Ausführung des Codes von weiteren Bedingungen abhängig machen.

Nehmen wir an, Du hast zwei Dimmer Items mit den Namen Dimmer_1 und Dimmer_2, sowie ein Switch Item Szene_1, welches Dimmer_1 auf 50% und Dimmer_2 auf 60% dimmen soll. Die einfachste Rule dazu sähe so aus:

Code: Alles auswählen

rule "Szene 1"                         // Name der Rule, muss eindeutig sein (im gesamten System)
when                                   // Beginn der Triggeraufzählung
    Item Szene_1 received command ON   // triggert, wenn das Item Szene_1 das Kommando ON empfängt
then                                   // Ende der Triggeraufzählung, Beginn des Code Blocks
    Dimmer_1.sendCommand(50)           // Sende den Wert 50 an das Item Dimmer_1
    Dimmer_2.sendCommand(60)
end                                    // Ende des Coe Blocks und Ende der Rule

Fertig.

Je nachdem, wie Deine Dimmer programmiert sind, kannst Du damit schon glücklich werden. Falls der Lichtwechsel aber unmittelbar erfolgt, willst Du vielleicht ein allmähliches Dimmen vom ursprünglichen Helligkeitswert zur Zielhelligkeit. Das ist dann leider nicht mehr so einfach, da man keine Dimmzeiten angeben kann. Die Rule muss dann also für die gewünschte Dimmzeit alle Zwischenwerte berechnen und die Dimmer zig-fach ansteuern. Das verursacht im Zweifel auch erheblichen knx Busverkehr, da sollte man also sehr genau schauen, wie flexibel man das haben muss (will)

Alarmmeldungen per eMail: eigentlich sollte es dazu zuhauf Beispiele geben. Man sollte im Hinterkopf behalten, dass eine Alarmanlage zur kritischen Infrastruktur gehört. openHAB ist zwar sehr zuverlässig, aber es ist nicht für kritische Anwendungen konzipiert. Also: sicher besser als nichts, aber im Zweifel wird niemand für entstehende Schäden aufkommen, sei es eine nicht erfolgte Alarmierung im Ernstfall oder eine Anzeige wegen Ruhestörug, weil es ständig zu Fehlalarmen kommt.

[mr.b4]

Danke, das werde ich demnächst testen.
Items sind eh schon alle funktional.
Sieht soweit verständlich aus
Vielleicht sehe ich das falsch, aber mir persönlich liegt es näher bzw. ich finde es zeitgemäßer derartige Funktion über kleine Skripte zu lösen, als teilweise hölzern oder eingeschränkt über das ETS.

Der Nutzen von Alarmanlagen sowohl im Auto als auch im Haus ist leider eh sehr überschaubar.
Besser ist es wenig Feinde und keine teure Münzsammlung (mehr) zu haben.
Als Bewohner eines Neubaugebiets stellt dies zumindest die Ausgangslage dar

[udo1toni]

Zur Ehrenrettung von ETS: Die EngineeringToolSoftware ist - nun ja - ein Werkzeug für Ingenieure. Solche Werkzeuge sind oft eher hölzern zu bedienen. Wobei ETS5 gegenüber ETS1.2 Gold ist. Aber ETS ist nur zur Konfiguration des Busses da. knx als Kommunikationsbus hat nicht die Aufgabe, Dinge zu automatisieren, das tun angeschlossene Geräte. Eine der Spitzen dabei ist der Gira Homeserver, der extrem weitreichende Automation erlaubt. Allerdings auch nicht gerade konfigurationsfreundlich
Ob openHAB hier ein Leuchtfeuer der Nutzerfreundlichkeit ist, da gehen die Meinungen eher auseinander aber letztlich kochen alle Systeme mit Wasser, und ich habe unter den Systemen, die ich mir angeschaut habe, letztlich auch nichts besseres gefunden.