OpenHAB2 Rule Verbindung von KNX Items (Legacy) mit Astro Thing Definition

[romueba]

Hallo zusammen,

ich steige aktuell von OpenHAB 1.x auf OpenHAB 2 um. Einige der Neuerungen finde ich super und freue mich auf die Entwicklungen der nächsten Monate/Jahre. Vielen Dank dafür schonmal an dieser Stelle!!

Ich habe folgende (sehr einfache) Situation: Ich möchte bei Sonnenuntergang und Sonnenaufgang ein Tag/Nacht-Objekt auf eine bestimmte Adresse des KNX Bus senden.
In Openhab 1 hatte ich das wie folgt gelöst:

${openhab-home}/configuration/items/astro.items:

Switch Sunrise_Event "Sonnenaufgang" {astro="planet=sun, type=rise, property=start"}
Switch Sunset_Event "Sonnenuntergang" {astro="planet=sun, type=set, property=end"}

${openhab-home}/configuration/items/knx.items:

Switch Day_Night "Tag / Nacht" {knx="5/0/0"}

${openhab-home}/configuration/astro.rules:

rule "Send day object on sunrise"
when
    Item Sunrise_Event received update ON
then
    sendCommand(Day_Night, ON)
end

rule "Send night object on sunset"
when
    Item Sunset_Event received update ON
then
    sendCommand(Day_Night, OFF)
end

Nun ist es bei OpenHAB 2 ja so, dass das Astro-Binding bereits als 2.x Version vorhanden ist, entsprechend mit PaperUI und Thing-Definition verfügbar ist.
Meine KNX-Item Definition habe ich so belassen, jetzt ist nur meine Frage wie ich nun eine Verbindung Astro-Binding <-> KNX-Items hinbekomme?
Habe im OpenHAB Forum gelesen, dass man jetzt einen Channel definieren muss mit der entsprechenden ID. Eine Defintion dieser Art in OpenHAB2 funktioniert leider nicht:

${openhab2-home}/conf/items/astro.items:

Switch Sunrise_Event "Sonnenaufgang" {channel="astro:sun:local:rise#start"}
Switch Sunset_Event "Sonnenuntergang" {channel="astro:sun:local:set#end"}

Muss ich diese Channel denn in der Items-Definiton nochmal definieren oder existieren diese bereits in der Datenbank? Wenn ja, wie spreche ich diese in den Rules an?

Vielen Dank und viele Grüße,
Robin

[udo1toni]

Das 2.0 Astro Binding gibt nur Zeitpunkte aus, den Switch kennt das Binding schlicht nicht. Es gibt aber schon entsprechende Rules (schau mal im englischen Forum) um täglich zu abhängig von den Uhrzeiten von Nacht auf Tag bzw. von Tag auf Nacht zu schalten.

[romueba]

Ah, ok, das würde natürlich Sinn machen. Wäre das Vorgehen oben, vorausgesetzt man bekäme tatsächlich ein Signal im Falle eines Events zurück, richtig?

EDIT: Ist es denn notwendig, in der Datei "${openhab2-home}/conf/things/astro.thing" noch das thing zu definieren, wenn dies bereits in der PaperUI passiert ist?

[udo1toni]

Wenn Du über Paper UI ein Thing siehst, musst Du nichts mehr im things-Ordner anlegen. Wenn Signalisierung (so wie im 1.x-Binding vorhanden) mal im 2.x-Binding nachgerüstet wird, funktioniert das auch wieder, bis dahin musst Du eine Rule anlegen. Entweder, Du setzt täglich ein paar Timer, oder Du lässt eine Rule (z.B. einmal pro Minute) nachschauen, ob Deine Wunschzeitpunkte schon vergangen sind.

[freezy]

romueba : Wie hast du das nun mit dem OH2 und Astro-Binding 2.0 gelöst? Ich bin auch gerade dabei, die Tag/Nacht Schaltung via KNX in mein OH2 zu implementieren...

[udo1toni]

In der Zwischenzeit sollte das Problem nicht mehr existieren, da das Astro Binding in der aktuellen Version Events unterstützt. Eine Beschreibung, wie das verwendet wird, ist in der offiziellen Dokumentation (auf englisch) nachzulesen

[freezy]

Hallo udo1toni, naja. Leider hilft mir die Dokumentation auch nicht viel weiter. Habe es bisher geschafft das Licht und die Rolladen mittels openHAB2 zu steuern. Die Temperatur der RTRs kann ich auch mittlerweile anzeigen lassen. Aber da hören meine Programmier-Kenntnisse dann schon auf.

Dachte das mir jemand seine Scripte oder Einstellungen im PaperUI zeigen kann. ;-)

[udo1toni]

Wenn ich mich richtig entsinne, muss man, falls ein offset vom errechneten Zeitpunkt gewünscht ist, das Thing über eine Konfigurationsdatei anlegen (wie in der Doku beschrieben), danach kann man in der rule engine den trigger verwenden:

rule "example trigger rule"
when
    Channel 'astro:sun:home:rise#event' triggered START  
then
    MyItem.sendCommand(ON)
end

bedeutet: "Wenn die Sonne aufgeht, schalte das Item MyItem auf ON."

[freezy]

Vielen Dank. Laut Log Files funktioniert es nun.
Im Paper UI habe ich ja ein Astro Binding eingerichtet. Daraus werden ja schon zwei Things im Paper UI generiert und nun muss man manuell noch eine Konfigurationsdatei im "things" Ordner anlegen und zwei weitere Astro Things einrichten? Verstehe das Konstrukt noch nicht wirklich...

[ArPa]

Verstehe das Konstrukt noch nicht wirklich...

Da bist Du nicht der einzige... Ich weiß manchmal nicht so recht ob das alles für den 0815 Bürger gerade verständlicher oder nur noch komplizierter wird Und ich komme aus dem IT Sektor... Frage mich wie die Lernkurve wohl bei einem "Technik-Normalo" da ist...

[udo1toni]

Es ist ganz einfach

openHAB ist für Nerds. Wenn nun jemand kommt, der nicht ganz so nerdig ist, soll er eine Klicki-Bunti-Oberfläche haben. Deshalb openHAB2. Dort kann man vieles (aber nicht alles!) über Paper UI einrichten. Spätestens, wenn man sehr spezielle Ideen für Automationen hat, kommt man um eine textuelle Konfiguration nicht herum, das kann aber auch schon bei "alltäglichen" Wünschen passieren, einfach, weil es (noch) nicht in Paper UI zur Verfügung steht.

Wer von openHAB1 umsteigt, sollte vorerst Paper UI am besten links liegen lassen und höchstens mal aus Interesse rein lunsen , gleiches gilt für Leute, die alle Möglichkeiten nutzen wollen, zumindest, solange Paper UI (noch) nicht alle Möglichkeiten bietet.

Die Things sind eine zusätzliche Ebene, die eingezogen wurde, um Autokonfiguration zu erlauben. Wenn man nun ein OH2-Binding mit Autokonfig nutzt, kann man Paper UI nutzen, um die Things zu finden und eine Grundeinrichtung vorzunehmen, oder man erstellt eine Konfigurationsdatei, in der man die Things manuell einrichtet. Nur mit dieser Konfigurationsdatei klappt die Definition eines Offset für die Event Channels beim Astro 2.0 Binding (soweit ich weiß). Die Channels als solche kann man vermutlich auch über Paper UI aktivieren (dazu müsste man die ausgeblendeten Channels einblenden und aktivieren).

Einen Channel kann man direkt in Rule-Files als Trigger verwenden, oder man linkt den Channel in einem .items-File auf ein Item (oder erledigt das über Paper UI, aber...), dann kann man statt des Channels auch das Item in einem Rule-File verwenden. Für die Visualisierung muss der channel einem Item zugewiesen sein, wobei speziell die Trigger in der UI sinnfrei sind, da sie (mein Kenntnisstand) nur einen Trigger "Impuls" geben und anschließend wieder den Grundzustand einnehmen. Eine entsprechende Anzeige wäre also praktisch immer "aus". Trotzdem kann es sinnvoll sein, den Channel im .items-File zu verlinken, z.B., wenn man den Sonnenaufgang direkt auf eine anderes Binding durchreichen will (also komplett ohne Rules).

Da ich selbst noch nicht soweit bin, umzusteigen, ist das alles nur mein Kenntnisstand aus meinen letzten Evaluationen in Testumgebungen, also nichts produktives und schon gar nicht mit dem dazugehörigen Aufwand. Aber wenn ich demnächst mal ein paar Wochen Urlaub habe, werde ich vielleicht mal die Zeit finden, testweise komplett umzusteigen (mit der Option, jederzeit meine OH1.8.1-Installation einzusetzen).

[ArPa]

Es ist ganz einfach

openHAB ist für Nerds. Wenn nun jemand kommt, der nicht ganz so nerdig ist, soll er eine Klicki-Bunti-Oberfläche haben. Deshalb openHAB2. Dort kann man vieles (aber nicht alles!) über Paper UI einrichten.

Und genau das halte ich eben für bloße Theorie und unterstelle, dass openHAB 2 für nicht ganz so nerdige Menschen Stand heute deutlich komplizierter ist als openHAB 1... Aber das ist nur mein ganz persönlicher Eindruck nach 2 Wochen komplett Umstieg auf openHAB 2. Vielleicht bin ich auch zu sehr von openHAB 1 infiziert und jemand der noch nie mit openHAB gearbeitet hat, findet das alles ganz schlüssig beim Direkteinstieg auf openHAB 2...

[udo1toni]

Ich denke mal, wenn jemand komplett unbedarft ran geht, und z.B. mit ein paar Leuchten und Rollläden anfängt, kann er mit OH2 sehr schnell ein funktionierendes System bekommen.

• openHAB2 herunter laden,
• installieren,
• starten,
• Webadresse aufrufen,
• in Paper UI passendes Binding auswählen,
• Autokonfiguration,
• fertig.

Wenn man dann feststellt, dass man schon einiges an Technik hat, die mitspielen kann, findet man nach und nach raus, wie das geht.

Wenn man andererseits schon einen ganzen Technikpark ans Laufen bringen möchte, ist es vollkommen egal, welche Software man einsetzt (solange sie alle Komponenten unterstützt), man wird um umfangreiche Konfigurationsarbeiten nicht herum kommen...

[freezy]

Wenn ich mich richtig entsinne, muss man, falls ein offset vom errechneten Zeitpunkt gewünscht ist, das Thing über eine Konfigurationsdatei anlegen (wie in der Doku beschrieben), danach kann man in der rule engine den trigger verwenden:

rule "example trigger rule"
when
Channel 'astro:sun:home:rise#event' triggered START
then
MyItem.sendCommand(ON)
end

bedeutet: "Wenn die Sonne aufgeht, schalte das Item MyItem auf ON."

Das Astro Binding und die Regel scheinen zu funktionieren. Aber beim Aufrufen von "MyItem.sendCommand(ON)" (bei mir Day_Night.sendCommand(ON)) wird nicht die KNX-Gruppenadresse auf den Bus geschickt. Obwohl ich das in der .items Datei hinterlegt habe.

[udo1toni]

funktioniert die Anbindung von knx grundsätzlich? wie sieht die genaue Definition des items Day_Night aus?