Allgemeine Fragen zu OH2 eines Anfängers

[Allodo]

Hallo,

ich probiere mich gerade ein wenig mit OH2 und da kamen mir ein paar Fragen auf, wo ich hoffe, dass ihr mir diese vielleicht beantworten könnt

Installiert habe ich das Ganze auf einem RPi2 (inkl. Homematic HM-MOD-RPI-PCB) mit der aktuellsten Stretchversion. Anschließend habe ich für die Homematic-Komponenten piVCCU installiert und nachdem dies lief, OH2 per Repository.

Was möchte ich nachher alles steuern können?
- Homematic Taster, Dimmer und dgl. (Test mit Dimmer funktioniert)
- Sonoff S20 Steckdosen mit Tasmota (MQTT Binding, kein Connect zum Server)
- MAX! Thermostate und Fensterkontakte (Steuerung per MAX!Cul, nicht MAX!Cube)
- Sprachsteuerung per Alexa

Punkt 1.) Gibt es ein gutes deutschsprachiges Tutorial, wo genau erklärt wird, wofür was genau ist (PaperUI, ClassicUI, Things, Items, Rules usw.)?

Punkt 2.) Die Erstellung von Items per PaperUI ist ja relativ trivial. Jetzt habe ich gelesen, dass ich für die Steuerung per Alexa das Attribut ["Lighting"] dem Item hinzufügen muss. Aber per PaperUI sind die Werte ja in der JSonDB und sollten dort auch nicht editiert werden. Wie bekomme ich dieses Attribut nun zum Item? Beste Vorgehensweise? Warum kann ich die Items nicht im PaperUI entsprechend editieren?

ERLEDIGT Habe einfach auf das Verzeichnis /etc gelinkt statt auf /etc/openhab2
Punkt 3.) Ich habe Samba auf dem Rpi2 installiert und mich mit Windows auf /etc/openhab2/conf verlinkt. Gebe ich diese Verlinkung jetzt im Smart Home Designer als Quelle ein, so erscheint dort keine Struktur (Items, Sitemaps und dgl.). Bei einer Windowsinstallation von OH2 und dessen Conf-Ordner als Quelle erscheint jedoch alles. Ich habe alles nach dieser Installationsanleitung gemacht: https://docs.openhab.org/installation/l ... rk-sharing

ERLEDIGT Habe Mosquitto installiert und es lief
Punkt 4.) Ich habe für die Sonoff S20 das MQTT-Binding installiert und die mqtt.cfg mit Namen und Passwort angepasst. Diese habe ich dann auf dem WebUI des Sonoff eingetragen, sowie die IP des RPi2. Aber ich bekomme im Openhab.log immer "Keine Verbindung zum Server" angezeigt. Muss evtl. noch etwas installiert werden?

Das war es vorerst, bestimmt fallen mir noch einige Fragen ein

Vielen Dank im voraus für die Hilfe

[udo1toni]

Herzlich willkommen!

Zu Punkt 1: Es gibt eine ganze Menge an deutschsprachigen Anleitungen im Netz. Welche davon gut, welche weniger gut sind, will ich nicht beurteilen.
Das große Problem jeder dieser Anleitungen ist, dass sie nicht offiziell sind.
Ob, und wenn, in welcher Form eine Qualitäts- und Aktualitätskontrolle stattfindet, ist bei keiner mir bekannten Anleitung ersichtlich.
Oft sind die Informationen veraltet. openHAB2 wird intensiv weiter entwickelt. Als letzte größere Neuerung sind z.B. Units dazu gekommen (openHAB2.3.0 in einem aktuellen Build rechnet Werte automatisch zwischen US und SI um, ohne dass man einen Finger rühren muss, wenn das Binding dies schon unterstützt.) Such mal eine deutsche Anleitung, die Dir erklärt, wie die Itemdefinition dazu aussieht...

Die erste Anlaufstelle sollte immer die offizielle englische Anleitung sein. Wenn es unüberwindbare Verständnisprobleme gibt, bekommst Du sicher zeitnah Antwort auf entsprechende Fragen.

Zu Punkt 2: Der Punkt in der Itemdefinition über Paper UI müsste eigentlich Category sein.

[udo1toni]

Ach so... vielleicht auf die Schnelle für Punkt 1 (weil es ja eigentlich ganz einfach ist... )

openHAB will Mittler der Welten sein (es gibt auch ein paar andere Systeme, die ähnliches versuchen). Dazu verwendet openHAB mehrere Abstraktionsebenen.

1. Binding/Addon - die Schnittstelle, damit openHAB mit einem bestimmten exterenne System kommunizieren kann. Sofern man über unterschiedliche Schnittstellen kommuniziren kann, ist normalerweise eine Konfiguration nötig (es gibt aber auch Services, welche über Zeroconf mitteilen, dass es sie gibt, dann richtet ein modernes Binding alles fix und fertig ein.)
2. Things/Bridges/Channels - (gehört alles zusammen) openHAB2 Bindings bilden die Hardware virtuell nach.
   1. Die Bridge ist die Schnittstelle zum externen Bus (z.B. eine Homematic CCU).
   2. Zu einer Bridge gehört mindestens ein Thing, oft aber auch mehrere Things. Ein Thing repräsentiert ein einzelnes Gerät, also z.B. einen Aktor oder einen Sensor.
   3. Jedes Thing hat wiederum mindestens einen, oft aber mehrere Channels. Ein Channel ist dabei eine bestimmte Eigenschaft eines Thing, also z.B. der Zustand eines Aktors (ON/OFF), die aktuell abgegebene Leistung, eine Temperatur, die Einschaltdauer usw., je nachdem, um welches Thing es sich handelt, gibt es also unterschiedliche Channels.
3. Items - openHAB arbeitet mit einem internen Bus. Alles, was irgendwie von openHAB gesteuert werden soll, oder was ausgewertet werden soll, um etwas anderes zu steuern, muss auf dem internen Bus auftauchen. Dafür sind die Items da.
   • Es gibt noch eine Menge openHAB1 Bindings, die kein Thing oder Channel kennen. Solche Bindings werden in einer Textdatei direkt mit einem Item verknüpft.
   • Es gibt für verschiedene Eigenschaften verschiedene Itemtypen, also z.B. Switch um einen Schaltzustand zu repräsentieren, Dimmer für einen Dimmer, String für eine beliebige Zeichenkette, Number für numerische Werte usw.
   • Die eine Funktion der Items ist, den aktuellen Status zu speichern. Dabei sollte das Binding z.B. den Status eine Schaltaktors an das Item schicken, welches daraufhin diesen Status annimmt.
   • Die zweite Funktion ist die Gegenrichtung, openHAB schickt also z.B. einen Schaltbefehl an das Item, welches dann den Befehl über das Binding an den Aktor weiter gibt. Entsprechend dem Itemtyp gibt es natürlich unterschiedliche Befehle.
4. Sitemaps - In einer Sitemap wird eine Ansicht festgelegt.
   • Jedes Item, welches über eine UI (Basic/Classic/HabDroid/iOSApp) bedient oder angezeigt werden soll, muss über die Sitemap festgelegt werden. Dazu werden in der Sitemap sogenannte Widgets definiert.
   • Es gibt verschiedene Widgets, z.B. Slider (so ein Schiebedingens), Switch (default ein Schiebeschalter), Text (Nur-Lese-Ansicht), Chart (malt einen Graphen) usw.
   • Achtung! Switch Widget != Switch Item. Man kann ein Switch Item durch ein Switch Widget repräsentieren lassen, man könnte dafür aber auch ein Selection Widget nehmen. Ebenso kann ein Switch Widget z.B. verwendet werden, um einem Number Item einen bestimmten Wert zu geben (über die Option mapping)
   • Eine Sitemap kann beliebig geschachtelt werden, man kann Unterseiten definieren, Blöcke bilden, Items werteabhängig ausblenden, Webseiten einblenden, Bilder anzeigen...
5. rules - das eigentliche Herzstück von openHAB sind sicherlich die Rules. Darüber können Regeln definiert werden, die das home smart werden lassen, also z.B.:
   • Wenn die Außentemperatur über 26°C steigt, lasse die Rollläden der Südseite bis auf 60% ab.
   • Wenn niemand zuhause ist, aber der Bewegungsmelder anspricht, verschicke eine Mail an eine bestimmte Person. Mach zuerst ein Foto über die Webcam und hänge das Bild an die Mail an. Schicke außerdem einen Tweet über das Konto xyz.
   Rules arbeiten mit Triggern, die zur Ausführung der Rule führen. Als Trigger kommen hier Änderungen oder auch nur Updates von Items infrage, aber auch Things oder spezielle Channel können als Ruletrigger verwendet werden. Innerhalb des Execute-Blocks einer Rule wird nur mit Items gearbeitet.
   • Da alles irgendwie in ein Item gequetscht wird, kann also jedes angeschlossene System potenziell jedes andere angeschlossene System steuern, z.B. erscheint auf meinem Fernseher eine Meldung, wenn jemand an der Haustür klingelt (auch wenn der Klingelton stummgeschaltet ist) oder auch wenn jemand anruft (mit Namen und Rufnummer, falls übermittelt und per Rückwärtssuche auffindbar). Dabei können weder der Klingeltaster (Ritto, Twinbus) noch die Telefonanlage (Asterisk) direkt mit meinem Fernseher (yaVDR Receiver) kommunizieren.

[Allodo]

Recht herzlichen Dank für die ausführliche Antwort
Verständigungsprobleme mit der englischen Anleitung habe ich zum Glück nicht, aber teilweise ist es doch sehr theoretischer Natur.

Ich bin derzeit noch generell am tüfteln und am evaluieren mit der Heimautomatisierung.

Habe bis jetzt FHEM rudimentär (Rollladensteuerung, ebus, Alexa per HA-Bridge) am laufen und wollte mal schauen, wie das Ganze mit OH2 läuft

Ich mein irgendwo gelesen zu haben, dass man Sitemaps nicht mit dem PaperUI anlegen kann, nur welchen Bereich müsste ich dafür nehmen?

Was mir später so vorschwebt, ist die generelle Steuerung per Alexa, der einzelnen Aktoren und Steckdosen, Automatisiertes fahren der Rollläden, Anwesenheitserkennung (Bluetooth + WLan) und Benachrichtigung beim Fensterkontakt (Mini-Alarm), ebus und Statusmeldung der Thermostatventile (MAX!)

[udo1toni]

Schau mal hier: https://docs.openhab.org/configuration/ ... comparison In dieser Tabelle kannst Du sehr schön sehen, was mit welcher Konfigurationsart geht.
Grundsätzlich kannst Du die verschiedenen Wege mischen oder kombinieren, man muss sich aber darüber im Klaren sein, dass es dadurch nicht einfacher wird
Da ich aus der openHAB1-Welt komme, bin ich wenig objektiv, trotzdem möchte ich die textliche Konfiguration empfehlen. Bis auf eine Ausnahme ist diese Methode sehr sauber. Die Konfigurationsdateien können jederzeit bearbeitet werden, man kann sie jederzeit sichern und einfach wiederherstellen.

Ich habe geschrieben: Bis auf eine Ausnahme... das bezieht sich darauf, eine Einstellung bzw. einen Parameter über eine *.cfg Datei vorzunehmen. Wenn ich nun diesen Parameter löschen oder auf eine leere Zeichenkette setzen möchte, muss ich zwingend über die karaf Konsole (oder wahlweise auch REST API) eingreifen. Nicht gesetzte Parameter in *.cfg Dateien werden nämlich von openHAB schlicht ignoriert. Das führt dann dazu, dass man z.B. eine Datenquelle angelegt hat, die war aber nur zum Testen. Also löscht man sie, die Daten kommen aber weiterhin ins System rein, obwohl man die Quelle doch schon entfernt hat... das kann ziemlich verwirrend sein.

Ansonsten hat man über die Textkonfiguration volle Kontrolle über alle Parameter. Mit VSCode (und dem openHAB Plugin für VSCode) hat man einen Editor, der sogar live Fehler in der Konfiguration finden kann Dazu wird der Code von der laufenden openHAB-Instanz überprüft - damit ist diese Überprüfung immer auf dem aktuellen Stand. Noch besser wäre höchstens eine direkt in openHAB integrierte Web-Konfigurationsoberfläche (halt vollständig).