Helligkeitssensor einbinden

[manes]

Hi,
ich habe einen Helligkeitssensor 2160 REG von Jung.
Wie bindet man sowas in Openhab3 ein? Der hat ja 3 Channels, aber was muß man da eingeben, damit OH3 mit den Werten arbeiten kann? Der liefert ja was zur Helligkeit, auf das OH3 dann reagieren muß. Nur, wie muß man da vorgehen bei der Einrichtung der Channels? Kann mir jemand weiterhelfen?

[manes]

OK,
nach etwas Überlegung und frische Luft schnappen bin ich dann einen Schritt weiter gekommen. Die ersten beiden Werte (morgens hell rauf, abends dunkel runter) werden ja direkt über KNX gesteuert und brauchen von mir erstmal nicht berücksichtigt werden. Der Sonnenschutz wird aber bisher mit einer alten Visualisierungssoftware geregelt, die ich aber abschaffe. Wenn die nun läuft, dann kann man im Gruppenmonitor der ETS sehen, das (wenn der Sonnenschutz greift) 2 Gruppenadressen nacheinander gefeuert werden. Einmal Start und dann direkt danach für Position. Wie kann man sowas über OpenHab3 regeln? Wo muß ich die 2 Adressen hinterlegen und wie?

[udo1toni]

Ah. Ich hab gestern nur kurz über Dein Posting drüber gelesen und bin daraus nicht schlau geworden... Wenn ich es richtig interpretiere, sieht es so aus:
1. Du hast irgendwo am Haus einen Helligkeitssensor.
2. Dieser ist am REG angeschlossen, welches wiederum ein knx Gerät ist.
3. Das REG liefert zu bestimmten Zeitpunkten Steuerdaten an den knx Bus (abhängig von der Helligkeit und vermutlich Uhrzeit).
4. Verschiedene andere angebundene Geräte reagieren auf die Telegramme.

Was ich jetzt nicht verstehe: wo kommt da openHAB ins Spiel? Willst Du lediglich eine Visualisierung der Befehle? Dann binde einfach die gesendeten GA in openHAB ein (passend zum Typ, also Rollershutter, Number, Switch...) und zeige sie an. Oder Willst Du, dass openHAB die Steueraufgaben übernimmt? Dann brauchst Du den Helligkeitssensor höchstens noch, um die Helligkeit zu liefern.

Ich hatte früher eine knx Wetterstation in meiner Installation, die ist aber nach (zu) kurzer Zeit kaputt gegangen, und als ich auf openHAB umgestiegen bin, habe ich darauf verzichtet, sie wieder einzubauen.
Meine Rollläden fahren sonnenstandsgesteuert sowohl morgens auf als auch abends runter, wenn die erwartete Außentemperatur bestimmte Grenzwerte überschreitet fahren die Läden auch in Beschattung. Die Steuerung übernimmt openHAB komplett alleine, die Daten liefern das Astro Binding und eines der Wetter Bindings.
Für die automatische Verschattung gibt es hier im Forum massig Codebeispiele (teilweise recht einfach gehalten, teilweise so komplex, dass ich nur mit Mühe durchsteige), wie gesagt habe ich das bei mir "auf die Schnelle" eingerichtet und nie das Bedürfnis gehabt, da noch groß Änderungen vorzunehmen.

[manes]

Hi,
1-2 stimmt. 3 nur halb. Es wird nur auf Helligkeit reagiert, Uhrzeit nicht. (das kommt später über OH nach)

es ist folgendes Problem. Vor ca. 15 Jahren wurde das System von einem Bekannten eingerichtet. War damals so mehr oder weniger Resteverwertung. Mir wurde damals mitgeteilt, das der Helligkeitssensor nur direkt mit KNX kommunizieren kann, wenn es darum geht bei aufkommender Helligkeit morgens die Rolladen hochzufahren und bei aufkommender Dunkelheit abends die Rolladen runter zu fahren.
Um KNX aber zu informieren, das die Sonne zu hell ist, oder wieder verschunden ist, hat er mir damals eine Visu installiert, die das gemacht hat. Auch uralt und noch mit serieller Schnittstelle. Jetzt habe ich ein IP gateway und OH3 und möchte die alte Visu ablösen, weil die nicht anzupassen geht und ich auch nicht jedesmal betteln möchte das es einer macht. Außerdem ist OH sicherlich wesentlich flexibler.
Zunächst habe ich mir angeschaut, was die alte Visu macht, wenn die Rolladen auf Position gefahren werden solle, weil die Sonne knallt.
Es werden jedesmal 2 Gruppenadressen an KNX geschickt.
Die erste GA behinhaltet den Helligkeitssensor für den Sonnenschein und die zerte GA beinhaltet alle Jalousieaktoren, die die Rolladen der entsprechenden Südseite Fenster ansprechen.
Das würde ich gerne über OH machen, weil es direkt unter KNX nicht zu klappen scheint. Also eigentlich den Helligkeitssensor einbinden in OH, einen Channel anlegen als Rollershutter. Dort müßten ja dann die 3 Adressen erfasst werden für upDown, Stop und Postion. (so meine Denke) leider weiß ich nicht wie und wo man da die beiden GA angibt, damit entweder der Channel es vom Sensor weiter gibt an KNX oder es weiter gibt, wenn ich den Rollershutter Button auf der GUI klicke.
Ich weiß jetzt nicht ob ich mich verständlich ausgedrückt habe? Hoffe es aber..

PS: Ich habe eigentlich nur das Problem, die DAten vom Helligkeitssensor weiter zu leiten.

in der KNX wird nur eingegeben, wo der Grenzwert ist und das einmal ein EIn (drüber) und einmal ein AUS (drunter) telegram geschickt werden soll. Da ich damit nicht zurecht komme, habe ich auch keine Chane das komplett ohne KNX zu machen und alle einzelnen geräte per OH anzusteuern. (was mir natürlich lieber wäre.)

[udo1toni]

Also, wenn ich in die Doku des 2160 rein schaue, so gibt es zwei mögliche Applikationen für das Modul, entweder Helligkeitssensor mit drei Kanälen oder Helligkeitssensor mit 4 Szenen. Der Unterschied wäre, im ersten Fall kannst Du drei Grenzwerte definieren, die dann jeweils ein Telegramm ON oder OFF senden, pro Kanal. Bei Version 2 hast Du ein zusätzliches Objekt, welches die Helligkeit als Byte ausgibt (also quasi von 0 - 100%, in ~ 0.4% Schritten) und die Schaltausgänge schalten in einer bestimmten Reihenfolge, jeweils wen der entsprechende Grenzwert über/unterschritten wird.
Du kannst die Applikation über ETS frei wählen, sie muss aber natürlich zur programmierten Version passen (oder Du musst das Device halt entsprechend neu programmieren).

So oder so sendet das Gerät auf drei (oder vier) Objekten Daten, die Objekte sind dann jeweils mit einer GA verbunden. Die Visu braucht es vermutlich nur, weil der Sensor halt arg limitiert ist.
Mein Tipp wäre, die zweite Applikation zu laden und dann den Helligkeitswert in openHAB über die programmierte GA zu empfangen. Dann kannst Du diesen Wert frei verwenden, um was auch immer anzustellen.

Natürlich musst Du alle Geräte, die Du steuern möchtest entsprechend in openHAB abbilden.

Wie groß ist denn Dein knx System? Gerade bei älteren Installationen kommt es gerne mal vor, dass die Programmierung nicht wirklich korrekt ausgeführt ist. Für eine saubere Anbindung brauchst Du für jeden Kanal, der gesteuert wird mindestens zwei GA, eine für die exklusive Steuerung, eine zweite für die exklusive Rückmeldung. Bei Dimmern kommt noch ein weiteres Paar für den Helligkeitswert dazu, bei Rollladenaktoren entsprechend für die Behanghöhe, falls die Aktoren das unterstützen. In einer konventionellen knx Installation (ohne vollständige Visu) sind oftmals die Absolutwerte nicht programmiert, lediglich die Befehle INCREASE und DECREASE bzw. UP/DOWN/STOP stehen zur Verfügung, da Wandtaster diese zur Steuerung verwenden. Die Adressstruktur ist oftmals nicht gut durchdacht, was dann zusätzliche Mühe mit sich bringt (fast zwingend ein Blatt mit der vollständigen Liste aller GA und deren Funktion um die Visu zu programmieren).
Es könnte also sein, dass es sich lohnt, die Anlage komplett neu zu programmieren, es kann aber auch sein, dass nur ein paar Dinge nachgepflegt werden müssen.

[manes]

Hi,
erstmal Danke für die Erläuterung.
Wie groß ist mein KNX System? Nun, eigentlich eine handliche Sache. Es befinden sich nur 2 6-fach Rolladenaktoren im System und an den 12 Fenstern jeweils 1 Tasterschnittstelle für analoge Taster und Fensterkontakte. Wie schon erwähnt, es war Resteverwertung und es ging damals nur darum die Rolladen steuern zu können. Was bis vor kurzem eher einer Frickelei entsprach als einer vernünftigen Konstruktion. Es liefen 2 Systeme nebeneinander. Jetzt gibt es nur noch KNX und ich versuche jetzt Schritt für Schritt alles unter einen Hut zu bekommen. Neu zu programmieren hatte ich auch schon im Kopf, aber dann wieder fallen gelassen, weil ich einfach noch zu wenig davon verstehe. (Den Aufbau und die Struktur hatte aber damals schon ein Fachmann gemacht, der das auch professionell macht. Es war halt nur so für mal eben kurz und sollte gar nicht so lange so abstrus laufen) Ich habe jetzt 2 Pis hier, auf denen ich nach und nach ausprobiere, was ich möchte und was geht. Und wenn ich erstmal einigermaßen durchblicke, dann geht es an den richtigen Speck. Jetzt habe ich erstmal alles unter OH3 integriert, aber eben den Helligkeitssensor noch nicht und leider auch noch nicht die Uhrzeitabfrage für Helligkeit am Morgen und Rollade rauf. Das löse ich noch mit einem ganz primitiven Trick anders, der aber so schnell wie möglich ersetzt werden soll. Aber erst wenn alles vom Grund her klappt und meine Beschreibung zum Ablauf und Aufbau steht, für den Überblick.
Ich stecke derzeit überhaupt noch nicht so tief in der Sache, deshalb überrascht mich Deine Aussage mit den 3 Kanälen, bzw. 4 Szenen. Ich habe die/eine Anleitung auch vor mit liegen. Es müßten 10 Seiten sein!? Nur damit wir von derselben Anleitung sprechen.
ich benutze die hier https://downloads.jung.de/public/de/pdf ... reg_td.pdf
Woran kann ich denn erkennen, was aktiv ist?
Auf Seite 5 steht das, was ich in der ETS auch finde. Oder ist das für beide Modis?

[udo1toni]

Ja, ich hatte zwar nur die englische gefunden, passt aber genauso. Schau mal auf Seite 3, da steht ganz oben "ApplikationenSchalten, 3 Grenzwerte 704C01"
und auf Seite 6 "ApplikationenSchalten, Wertgeber, 4 Helligkeitsbereiche 704D01" Das sind die zwei möglichen Applikationen. Du müsstest beide Applikationen in die ETS laden können und das Gerät kannst Du mit beiden Applikationen programmieren. Je nach Applikation stehen dann halt unterschiedliche Funktionen zur Verfügung.
Wie funktioniert die Steuerung über die Taster? Lange drücken hoch bzw. runter, kurz Drücken stop? Oder andersrum, kurz drücken hoch bzw. runter, lang drücken stop? jedenfalls sollten die Tasterschnittstellen jeweils zwei GA parametriert haben, die an den Aktoren jeweils auf Kurz und Lang eines Aktorkanals gehen. Es kann gut sein, dass noch weitere GA in den Kanälen angelgt sind, die wären dann für die Gruppenfahrten (Alle Läden auf/zu).

In openHAB solltest Du nur die GA abbilden, welche jeweils genau einen Aktorkanal steuern. Beispiel:

Code: Alles auswählen

UID: knx:device:roll1
label: Rollladen 1
thingTypeUID: knx:device
configuration:
  pingInterval: 600
  readInterval: 0
  fetch: false
bridgeUID: knx:ip:bridge
channels:
  - id: ch1
    channelTypeUID: knx:rollershutter
    label: Kanal 1
    description: ""
    configuration:
      upDown: 1/1/1
      stopMove: 1/1/2
      position: 1/1/3+<1/1/4
  - id: ch2
    channelTypeUID: knx:rollershutter
    label: Kanal 2
    description: null
    configuration:
      upDown: 1/2/1
      stopMove: 1/2/2
      position: 1/2/3+<1/2/4
  - id: ch3
    channelTypeUID: knx:rollershutter
    label: Kanal 3
    description: null
    configuration:
      upDown: 1/3/1
      stopMove: 1/3/2
      position: 1/3/3+<1/3/4
  - id: ch4
    channelTypeUID: knx:rollershutter
    label: Kanal 4
    description: null
    configuration:
      upDown: 1/4/1
      stopMove: 1/4/2
      position: 1/4/3+<1/4/4
  - id: ch5
    channelTypeUID: knx:rollershutter
    label: Kanal 5
    description: null
    configuration:
      upDown: 1/5/1
      stopMove: 1/5/2
      position: 1/5/3+<1/5/4
  - id: ch6
    channelTypeUID: knx:rollershutter
    label: Kanal 6
    description: null
    configuration:
      upDown: 1/6/1
      stopMove: 1/6/2
      position: 1/6/3+<1/6/4

Das wäre ein vollständiger Aktor. Falls Du keine Positionsmeldung hast (kommt ja auf den Aktor an, ob der das unterstützt) lässt Du die GA weg.
In meinem Beispiel ist die GA 1/x/1 für die lange Fahrt zuständig, die GA 1/x/2 ist für die kurze Fahrt (welche hier Stop bedeutet)
Die GA 1/x/3 gibt die gewünschte Position an, die GA 1/x/4 liefert die aktuelle Position. Diese GA ist auch lesbar und openHAB ermittelt beim Start über diese GA die Position.

Nun kannst Du diese Channel mit Items verknüpfen und fortan die Rollläden über diese Items steuern und visualisieren.
Wenn Du die Läden über Sonnenstand und Zeit steuern willst, reicht das Astro Binding vollkommen aus. Du installierst das Astro Binding, und falls Du im System den genauen Standort eingestellt hast (Main UI->Administration->Einstellungen->System Services->Regional Settings->Location), findest Du anschließend in der Inbox zwei Things, das eine heißt Moon, das andere heißt Sun (oder so).
Im Sun Thing kannst Du für das Range Event CivilDusk und CivilDawn Grenzwerte und einen Offset konfigurieren, Offset negativ: x Minuten vor dem eigentlichen Ereignis, Offset positiv: x Minuten nach dem eigentlichen Ereignis. Earliest: frühestens zu diesem Zeitpunkt. Latest: spätestens zu diesem Zeitpunkt.
Leider wird die Konfiguration nicht im Code angezeigt. Deshalb gebe ich hier mal den Code an, so wie er in einer *.things Datei geschrieben wird:

Code: Alles auswählen

// Astro
Thing astro:sun:local "Sonne" @ "zuhause" [geolocation="49.91,8.66,130", interval=300] {
    Channels:
        Type rangeEvent : civilDawn#event  [
            offset=10,
            earliest="06:00",
            latest="08:00"
        ]
        Type rangeEvent : civilDusk#event  [
            offset=15,
            earliest="16:00",
            latest="22:00"
        ]
}

Dieser Code bedeutet, dass zehn Minuten nach der bürgerlichen Morgendämmerung, aber nicht vor 6 Uhr und nicht nach 8 Uhr der Trigger civilDawn ausgelöst wird. Weiterhin wird fünfzehn Minuten nach der bürgerlichen Abenddämmerung, jedoch frühstens 16 Uhr und spätestens 22 Uhr der Trigger civilDusk ausgelöst.

Nun reichen zwei Rules, eine für Öffnen und eine für Schließen, die jeweils auf den passenden Trigger konfiguriert sind:

Code: Alles auswählen

rule "frueh"
 when
    Channel 'astro:sun:local:civilDawn#event' triggered START
 then
    gShutters.members.forEach[ m | m.sendCommand(UP) ]
end

rule "spaet"
 when
    Channel 'astro:sun:local:civilDusk#event' triggered START
 then
    gShutters.members.forEach[ m | m.sendCommand(DOWN) ]
end

um alle Rollläden (die sind in der Gruppe gShutters zusammengefasst) zu öffnen, bzw. zu schließen.

Natürlich kannst Du auch die GA der verschiedenen Schwellwerte Deines Helligkeitssensors verwenden, die musst Du halt ebenfalls als Switch (Contact ist Quatsch...) angeben, dann kannst Du diese auch als Trigger verwenden (aber das Astro Modell funktioniert meiner Erfahrung nach besser als ein Helligkeitssensor).

Die Verschattung ist, wie gesagt, ein anderes Thema, lässt sich aber ebenfalls recht einfach abbilden. Natürlich braucht es auch dafür entweder Sensorwerte oder eine Berechnung, ob (und wann) eine Verschattung stattfinden soll. Meist möchte man diese dann nur partiell durchführen, also morgens die Ostseite, mittags den Süden und Abends den Westen, wobei die anderen Seiten dann auch wieder öffnen sollen. Das ist aber alles recht einfach zu bewerksteligen. Über Astro bekommst Du auch Elevation und Azimuth, womit Du einfach die verschiedenen Bereiche abgrenzen kannst (soweit Du die Lage Deines Hauses genau genug kennst). Eine entsprechende Rule muss dann bei Änderung der Werte triggern - die werden sich jedes Mal gleichzeitig ändern, je nach Einstellung, z.B. in obigem Code alle 6 Minuten (interval=300), dann triggert eine Rule, die die beiden Werte in Bezug auf verschiedene Grenzwerte prüft und entsprechend die Läden in bestimmte Positionen fährt. Da kommt es sehr drauf an, was die Aktoren können (Positionsfahrten, Szenen usw.). Man kann die Rule zusätzlich abhängig von der Außentemperatur machen oder auch den Helligkeitssensor mit verwenden (dafür böte es sich aber an, die Applikation 704D01 zu laden, damit Du direkt den Messwert verwenden kannst).

[manes]

erstmal vielen Dank für die Mühe. Ich schaue mir das morgen mal in Ruhe an.

[manes]

hm,
ich habe mal gesucht. Ich glaube der Helligkeitssensor ist zu alt. Ich habe nur was für die ETS2-3 gefunden. Derzeit ist nur 1 Applikation im System vorhanden.

[udo1toni]

Die Applikation läuft auch unter ETS5, die ETS kommt grundsätzlich mit allen alten Formaten klar. Aber notfalls geht es ja auch ohne die andere Applikation, dann bist Du halt darauf angewiesen, dass die Schwellwerte im Sensor (bzw. in der Busankopplung, das ist das REG) hinterlegt werden. Du musst dann natürlich neue (unbenutzte) GA anlegen, damit die Rollläden nicht mehr direkt auf den Sensor reagieren.