Anfänger Tag/Nacht schalten

[PhilW]

Tach,

bin seit heute in den Anfängen von openHAB und versuche zu verstehen ;-)
Läuft soweit alles auf meinem Server (Win7) und schalten kann ich auch das was ich will.

Nun hab ich eine Sache die mich schon die ganze Zeit nervt (bzw. es nervt meine bessere Hälfte dir mir dann Feuer macht ;-)) solange ich mir keine anständige Wetterstation (mit DCF/GPS) leisten will/kann.
Ich würde gerne das Orientirungslicht meiner MDT Taster eben bei Nacht an und bei Tag ausschalten. Hab zwar jetzt schon einiges gelesen finde aber den "roten Faden" noch nicht.
Kann (und vor allen Dingen wie) ich openHAB diese Befehle zu bestimmten Uhrzeiten senden lassen? Muss ich dazu ne .rule erstellen??

Ihr sehr, ich bin am Anfang.... Daaanke

Gruss
PhilW

[staehler]

Hi,

ich habe das mit dem astro-Binding gelöst.

Number   Azimuth        "Azimuth [%.2f]"        (gAstro)    {astro="type=AZIMUTH"}
Number   Elevation      "Elevation [%.2f]"        (gAstro)    {astro="type=ELEVATION"}

Switch IsNight      "Nacht" <night>        (gAstro) { knx="0/1/7" }
Switch IsDay        "Tag" <day>            (gAstro) { knx="0/1/6" }
Switch IsTwilight   "Dämmerung" <dawn>        (gAstro) {knx="0/1/11" }

rule "Astro Regeln"
when
    Item Elevation changed or
    System started
then
    if (Elevation.state < -6) {     
        if (IsDay.state==ON || IsDay.state==Uninitialized || IsDay.state==Undefined) {
            logInfo("Astro Regeln", "Sonnenstand < -6 Grad - Es ist Nacht")
              sendCommand(IsTwilight, OFF) 
              sendCommand(IsDay, OFF)
              sendCommand(IsNight, ON)        
          }
    }
    if (Elevation.state >= -6 && Elevation.state <= 0) {
          if (IsDay.state==ON || IsDay.state==Uninitialized || IsDay.state==Undefined) {
              logInfo("Astro Regeln", "-6 Grad <= Sonnenstand <= 0 Grad - Es ist Dämmerung")
              sendCommand(IsTwilight, ON)
              sendCommand(IsDay, OFF)
              sendCommand(IsNight, ON)
         }            
    }
    if (Elevation.state > 0) {
        if (IsDay.state==OFF || IsDay.state==Uninitialized || IsDay.state==Undefined) {
            logInfo("Astro Regeln", "Sonnenstand > 0 Grad - Es ist Tag")
              sendCommand(IsTwilight, OFF)
              sendCommand(IsDay, ON)
              sendCommand(IsNight, OFF)          
        }
    }

end

An die KNX Adresse für IsNight hängt der Nachtmodus meiner Taster-LEDs.
Die Abfragen habe ich nur drin, damit nicht alle 2 Minuten (das ist mein Astro-Intervall in der openhab.cfg) der Status gesendet wird.

That's it und funktioniert prima.

Viele Grüße
Michael

[PhilW]

N'Abend,

äähm ja. Danke, also theoretisch verstehe ich es wie du es machst und klingt auch logisch. Praktisch weiss ich aber grad nicht wie und wo ich die Codes anlege!!!
Klar das astro-binding in den addons-Ordner.
Dann:
- der erste Code ist die .items (mit meinen GA's natürlich)
- der 2. Code ist der für die .rules
richtig??
und dann??
gibts ne Sitemap??

Wie gesagt Anfänger in openHab und muss erstmal die "Wege nach Rom" verstehen.
Kannste mir nochmal für Blöde auf die Sprünge helfen, daaanke.

Gruss
PhilW

p.s.: aaahh ja ersten Weg gefunden, muss natürlich in der config meine Längen-/Breitengrade eintragen, aber weiter bin ich noch nich!
p.p.s.: aaahh 2. Weg Sitemap is klar... hab aber noch keine Azimuth etc. Anzeige
p.p.p.s aaaahh und bin angekommen klappt alles vielen Dank.... ;-)

[udo1toni]

und dann??

Mehr isses nicht (vorausgesetzt, Du hast die richtigen knx-Adresse bei der Switch-Definition hinterlegt.)

[PhilW]

Jep, geht allet, danke...

[PascalTurbo]

@staehler: Was ich bei deiner Lösung nicht verstehe: Warum nutzt du nicht das Sunrise- und Sunset-Event des Astro-Bindings? Das vereinfacht den Code doch massiv.

[staehler]

@staehler: Was ich bei deiner Lösung nicht verstehe: Warum nutzt du nicht das Sunrise- und Sunset-Event des Astro-Bindings? Das vereinfacht den Code doch massiv.

Da hast Du recht, allerdings benötige ich diese Status für weitere Abfragen. Ich lege mit diesen "Tageszeiten" auch andere Aktionen fest, wie z.B. sollen meine Rollos erst hochfahren, wenn es Tag ist (IsDay.state==ON) und Bettruhe.state==OFF (Bewegung detektiert oder ähnliche) uvm.

Deine Lösung ist für viele Anwendungen völlig ausreichend. Für meine hat es nicht gereicht, daher die etwas aufgeblähtere Version.
Aber es führen ja bekanntlich immer mehrere Wege nach Rom ;-)

[teichsta]

welche verschiedene Zeiten Du direkt aus dem Astro-Binding beziehen kannst, liest Du am besten auf der zugehörigen Wiki-Seite nach.

Gruß,

Thomas E.-E.

[lo4dro]

Hallo,

ich habe die RULE von Michael auf openhab 2.x umgesetzt.
Die If Abfragen müssen hier etwas anders definiert werden.
Auf den KNX Bus sende ich bei jedem "SunElevation" Trigger den Status (TAG = ON oder Nacht = OFF)

rule "Astro Regeln Tag Nacht Umschaltung"
when
Item SunElevation changed or System started
then
if (SunElevation.state < -6) {
sendCommand(KNX_TAG_NACHT_DG, ON)
if (es_ist_TAG.state==ON || es_ist_TAG.state==NULL) {
logInfo("Astro Regeln", "Sonnenstand < -6 Grad - Nacht")
sendCommand(es_ist_DAEMMRIG, OFF)
sendCommand(es_ist_TAG, OFF)
sendCommand(es_ist_NACHT, ON)
}
}
if (SunElevation.state >= -6 &&  SunElevation.state <= 0) {
sendCommand(KNX_TAG_NACHT_DG, ON)
if (es_ist_TAG.state==ON || es_ist_TAG.state==NULL) {
logInfo("Astro Regeln", "-6 Grad <= Sonnenstand <= 0 Grad - Dämmerung")
sendCommand(es_ist_DAEMMRIG, ON)
sendCommand(es_ist_TAG, OFF)
sendCommand(es_ist_NACHT, ON)

}
}
if (SunElevation.state > 0) {
sendCommand(KNX_TAG_NACHT_DG, OFF)
if (es_ist_TAG.state==OFF || es_ist_TAG.state==NULL) {
logInfo("Astro Regeln", "Sonnenstand > 0 Grad - Tag")
sendCommand(es_ist_DAEMMRIG, OFF)
sendCommand(es_ist_TAG, ON)
sendCommand(es_ist_NACHT, OFF)
}
}
end 

Meine ITEMS

Number      SunElevation        "Sonnenhöhe [%.1f °]"                               <sun>       (Astro) { channel="astro:sun:kork:position#elevation" }
Switch es_ist_TAG  "TAG [%s]"
Switch es_ist_NACHT "NACHT [%s]"
Switch es_ist_DAEMMRIG "DÄMMERUNG [%s]"
Switch KNX_TAG_NACHT_DG "Tag=1 Nacht=0 Umschaltung" {knx="2/0/3+"}

Danke Michael für das gute Beispiel.

[FlyingEaglE]

lo4dro könntest du die unterschiede OH1 vs OH2 if mal ein wenig ausarbeiten bitte? bin zwar noch auf OH1.8.3, möchte aber demnächst mal OH2 in angriff nehmen. :-) merci

[udo1toni]

Es gibt massig Unterschiede zwischen OH1 und OH2. Für den Umstieg empfiehlt es sich, die englische Dokumentation zu studieren, insbesondere http://docs.openhab.org/tutorials/migration.html
Dort ist eigentlich ganz gut erklärt, wo die Knackpunkte sind.
Die wichtigsten Unterschiede sind

• Logging
• Konsole
• Thing-Modell
• Auto discovery
• API
• UI

Das Logging funktioniert komplett anders, wobei es für den Anwender erstmal keinen Unterschied gibt, aber wenn Du spezielle Änderungen am Logging vorgenommen hast, musst Du lernen, wie Du das gleiche unter OH2 erreichst (z.B. einzelne Bindings im DEBUG-Mode laufen lassen)
Die Konsole ist wesentlich mächtiger als früher, und sie ist wesentlich wichtiger als früher, weil man bestimmte Sachen über die Konsole wesentlich einfacher herausfinden kann (das Logging ist auch ein Teil davon)
Things sollen Geräte repräsentieren, also z.B. eine Leuchte. Die Leuchte hat dann z.B. einen Schalter zum Ein- und Ausschalten. Sie kann aber auch noch einen Dimmer haben, also eine Helligkeit. Vielleicht kann man gar noch die Farbtemperatur oder die Farbe im RGB-Raum einstellen, oder den Verbrauch ablesen. All dies sind dann Channel eines Things. Diese Channel werden dann auf Items gelinkt. Vorteil ist eine weitere Abstraktion der Hardware von der Software.
Wenn es ein Gateway gibt, über das mehrere Things mit openHAB kommunizieren, heißt das dann Bridge, ein besonderes Thing. Das wäre dann z.B. der USB-Stick, der die Kommunikation mit homematic übernimmt.
Das Autodiscovery ermöglicht es openHAB, solche Geräte selbständig zu finden, wenn grundlegende Voraussetzungen getroffen wurden. Wenn z.B. ein Gateway per Avahi (oder Zeroconf) erreichbar ist, kann das passende Binding dieses Gateway finden. Wenn das Gateway Informationen zur angebundenen Hardware hat, kann es im Anschluss openHAB davon berichten -> alle Leuchten tauchen "einfach so" in openHAB auf, im Idealfall, ohne einen Finger zu rühren.
Der Nachteil ist, wenn man das alles gerne haben möchte, muss man sich mit geänderten Konfigurationsmethoden auseinandersetzen.
Wenn Du OH1-Bindings verwenden willst (teilweise gibt es gar nichts anderes), musst Du die Konfiguration dazu in separate Dateien packen, für jedes Binding eine Datei (statt openhab.cfg) - dafür entfällt die Zuordnung zum Binding, die ist ja schon durch den Dateinamen gegeben.

Wenn Du die aktuelle nightly Version OH2.2.0 nimmst (nur dann kommst Du in den Genuss aller Neuerungen), gibt es in der Rule Engine die Möglichkeit, Channel als Trigger zu verwenden. Beim Astro Binding gibt es z.B. Start- und End- Trigger für die verschiedenen Sonnenauf- und Untergänge, diese Punkte kann man auch noch zeitlich verschieben, dann gibt es also die Möglichkeit einfach eine Rule zu schreiben:

Fahre 10 Minuten vor der nautischen Dämmerung die Rolläden zu (heißt 10 Minuten bevor die Sonne unter -12° sinkt)

In den Regeln oben wird solch ein Punkt alle paar Minuten berechnet (das Astro Binding muss dazu natürlich alle paar Minuten neue Werte liefern), aber dazu muss die Rule alle paar Minuten ausgeführt werden, nur um einmal am Tag tatsächlich etwas zu tun. Mit den Triggern in OH2.2 wird die Rule nur einmal am Tag aufgerufen.

API und UI kannst Du am einfachsten selbst anschauen, Du wirst feststellen, dass es mehr Auswahl und mehr Möglichkeiten gibt, falls Du aber schon bisher von außen Werte nach openHAB "geschrieben" hast, wirst Du vielleicht mehr anpassen müssen, da sich die Aufrufe hier doch sehr unterscheiden, möglich ist das aber trotzdem noch.

[FlyingEaglE]

Vielen Dank für die sehr ausführlichen Infos.

ich habe die RULE von Michael auf openhab 2.x umgesetzt.
Die If Abfragen müssen hier etwas anders definiert werden.

Ich bezog mich mehr darauf, dachte das es da syntaktisch Änderungen gibt.

[udo1toni]

Ahso...

Nein, grundsätzlich gibt es keine (oder zumindest kaum) Unterschiede in der Rule Engine.

1. Alle imports, die Standardfunktionen von openHAB betreffen, sowie die imports für joda, sind automatisch aktiv, entsprechende imports sollten in den rule-Files auskommentiert werden.
2. imports mit Platzhalter sind nicht statthaft, also z.B. kein import lang.java.org.* (rein theoretischer import, ich bin grade faul)
3. Es gibt Thing Trigger, wenn ein Thing seinen Status ändert, man kann also z.B. darauf reagieren, wenn eine HUE vom Strom getrennt wurde oder wieder mit Strom versorgt wird.
4. Es gibt (im aktuellen nightly, also "seit OH2.2.0") zusätzliche Trigger, man kann also eine Rule so schreiben:

rule "test"
when
    Channel 'astro:sun:home:rise#event' triggered START  //die 'einfachen' Anführungszeichen werden gebraucht, da Channel- und auch Thingnamen Doppelpunkte enthalten
then
...
end

[FlyingEaglE]

Ah, verstehe, also primär nur eine Erweiterung und keine komplette Änderung.
Dann dürften ja die meisten simplen Rules weiterhin gehen ...
(Ich mag Rules generell lieber als Bedingungen in der Sitemap oder bei den Items. So steht alles primär an einer Stelle und nicht an möglichen mehreren.)

Nur das mit dem Astrobinding habe ich hier im Thread noch nicht ganz kapiert, insbesondere das mit dem Rechnen. Ist es am Ende nicht egal wer rechnet, das Binding (und dadurch der Channel) oder Openhab in der Rule?

[udo1toni]

Es gibt schon in OH1.8 im Astro Binding die Möglichkeit, eine Rule auf Sonnenaufgang/Untergang/Dämmerung usw. triggern zu lassen. Das hat einige Zeit in OH2 nicht funktioniert, weil der zugrundeliegende Mechanismus sich geändert hat.
Mit der Möglichkeit, auf Channel zu triggern, ist quasi der alte Zustand wiederhergestellt.

Der Unterschied in der Berechnung mag marginal sein, grundsätzlich läuft aber sowieso ein Thread für Astro, warum also noch einen weiteren Thread laufen lassen, der 99% der Zeit nur kurz aufgerufen wird, um dann (nach Berechnung) ohne irgendeine sinnvolle Funktion wieder schlafen zu gehen. Es ist wesentlich effizienter, das durch das Binding selbst erledigen zu lassen (wenn das möglich ist).
Natürlich gibt es auch gute Gründe, Berechnungen in kurzen Abständen durchzuführen, z.B. die Steuerung einer aktiven Sonnenstandsnachführung wäre so etwas (auch wenn man das vielleicht besser einer dedizierten Hardware überlassen würde - z.B. einem Arduino).
Im einfachen Fall einer dämmerungsabhängigen Rollladensteuerung ohne Dämmerungssensor ist die Triggervariante einfach besser und recourcenschonender.