ungeduldiger Neuling mit Verständnisfragen bittet um Hilfe.

[th0ma3]

Hallo zusammen,
ich bin derzeit dabei mich mit OpenHab auseinander zusetzen, lese fleißig und "watcheln" (duckduckgo.com) um Konfigurationsschnipsel zu finden.
ganz dem Motto von https://www.openhab.org/docs/concepts/

<Start slowly and one step at a time>-<Be prepared to learn>-><Remain flexible in how you want to achieve your goal>-<Celebrate all the small successes>

entschieden habe ich mich für eine Konfiguration auf Textfile (xyz.items) Basis, die Vorzüge haben sich sehr früh beim einarbeiten gezeigt.

Wenn ich die Dokumentation richtig verstehe: "Zitat"

The glue between Things and Items are Links. A Link is an association between exactly one Channel and one Item.
If a Channel is linked to an Item, it is "enabled", which means that the capability the Item represents is accessible through that Channel.
Channels may be linked to multiple Items and Items may be linked to multiple Channels.

ist OpenHab eine Poststation welche Telegramme empfängt & versendet (im Übertragenen Sinn)

in meinem Fall:

Etage mit KNX Bus	OpenHab
Aktoren, Taster, Melder, Sensoren	Visualisierung, Rules, Persistense, etc.

Ich bin auf der Suche nach Konfigurationsbeispielen: laut https://www.openhab.org/docs/configu.../packages.html sollten diese Verfügbar sein.

Zitat:"Sample configurations files demo.items, demo.things, demo.sitemap, demo.rules, demo.script, rrd4j.persist, de.map and en.map for use with the MAP transformation

Da wo es interessant wird, scheinen aber die Einträge zu fehlen "demo.things"
Bitte korrigiert mich wenn ich es falsch verstanden habe:

Was ich bisher hinbekommen habe ist die Temperatur aus den MDT Glastastern auszlesen und in OpenHab auszugeben.

Ziele:
im ersten Schritt die grundlegenden Konfigurationen mithilfe der *:things, *.items etc. zum schalten vom Licht (Aktoren), Rolläden auf/ab, FBHeizung steuern
Status der einzelnen Kanäle der Aktoren auszulesen etc.

KNX ETS
druck Glastaster --> Telegramm --> Universalaktor schaltet
aber wie sieht das im OpenHab configfiles aus? xyz.items|xyz.things| xyz.sitemaps

OpenHub
duck lampensymbohl --> Telegramm --> Universalaktor?
xyz.items|xyz.things| xyz.sitemaps

wie sehen weitere Setups für die xyz.sitemap aus, so das die Frames nicht alle nur untereinander stehen usw.
wie sehen weitere Setups für die xyz.things aus, so das die Aktoren auch reagieren sobald die Weboberfläche betätigt wird.

ich wäre euch für die eine oder andere Anlaufstelle sehr Dankbar.
cheers

[xp447]

Ich würde dieses Buch empfehlen - damit habe ich selbst den Einstieg in Openhab perfekt geschafft

https://www.amazon.de/Smart-Home-ope...9900840&sr=8-1

[udo1toni]

Für die Demo-Elemente musst Du openHAB im Demo--Modus installieren (das heißt beim ersten Start DEMO auswählen. Im Nachhinein geht das leider nicht, ohne openHAB neu zu installieren - wobei, Du könntest in der Datei addons.cfg im Zweig services/ den Parameter package = demo setzen. Ich bin mir aber nicht sicher, ob das nach einem Neustart das gewünschte Ergebnis liefert.)

Grobe Konfiguration von knx2:

knx.things:

Bridge knx:ip:bridge "knx IP Gateway" [
    ipAddress="10.1.2.106",
    type="TUNNEL"
    ] {
    Thing device generic "knx Device" @ "knx" [] {
        Type switch : ch1 "Decke 1" [ ga="1/3/10+<1/3/29" ]
    }
}

Es wird ein knx/IP Gateway mit der IP 10.1.2.106 angelegt. Das Gateway muss sich im selben Subnetz wie openHAB befinden. Das Gateway wird im TUNNEL Mode angesprochen. Der Name des Gateways lautet bridge.
Zum Gateway wird ein Thing namens generic angelegt. Im Thing wird ein switch Channel mit dem Namen ch1 angelegt. 1/3/10 ist die Befehls-GA um den Aktor zu steuern, 1/3/29 ist die Rückmelde-GA für den Aktorkanal (diese hat ein gesetztes L-Flag und kann somit ausgelesen werden, was openHAB dann beim Start erledigt - das ist das <)

knx.items:

Switch MeinSwitch "Mein Switch [%s]" { channel="knx:device:bridge:generic:ch1" }

Das Item kann von VSCode automatisiert erstellt werden (VSCode + openHAB Plugin = empfohlener Editor für die Textkonfiguration) - man kann es anschließend den eigenen Vorstellungen anpassen, z.B. Namen und Label ändern - nur der Channel sollte unbedingt unangetastet bleiben...

demo.sitemap:

sitemap demo label="Demo Sitemap" {
    Switch item=MeinSwitch
}

Unter der Voraussetzung, dass Du die entsprechenden Daten (IP und GA) angepasst hast, sollte der Aufruf der Basic UI einen Link zur demo-Sitemap liefern, die wiederum einen einzelnen Switch anzeigt, mit dem Du die Leuchte schalten kannst und den Zustand der Leuchte siehst.

[DiMa]

Ich würde dieses Buch empfehlen - damit habe ich selbst den Einstieg in Openhab perfekt geschafft

Dem würde ich mich anschliessen. KNX kommt da ein bisschen (zu) kurz (bzw. praktisch nicht vor), aber OpenHAB hat man danach verstanden.

[th0ma3]

Hallo zusammen,
vielen Dank für die Antworten, bisher habe ich mir das Buch geholt, und bin ein wenig erschlagen, von den bisher nicht erahnten Möglichkeiten.

[ ga="1/3/10+<1/3/29" ]

Danke funzt, wo es bei mir erst klick machen musste:
a.) die paperUI und Konfig.dateien sind 2 Paar Schuhe
b.) das "Gateway" mit der realen physischen Adresse ließt dann die GA Adressen aus die über den Bus laufen.
unabhängig ob ein weiteres pysisches gerät die adresse hat.

also da ist sie wieder meine initale Frage "Unterschiede" zwischen realen physikalischen Adressen und den GA Adressen.

Wie stucktoriert Ihr eure Dateien, geht ihr nach Gewerken? Funktionen? oder oder?

[udo1toni]

a.) die paperUI und Konfig.dateien sind 2 Paar Schuhe
b.) das "Gateway" mit der realen physischen Adresse ließt dann die GA Adressen aus die über den Bus laufen.
unabhängig ob ein weiteres pysisches gerät die adresse hat.

also da ist sie wieder meine initale Frage "Unterschiede" zwischen realen physikalischen Adressen und den GA Adressen.

Wie stucktoriert Ihr eure Dateien, geht ihr nach Gewerken? Funktionen? oder oder?

Zu a): Ja da stolpert jeder drüber, der erst mit OH2 eingestiegen ist. Es stolpern sogar Einige darüber, die schon OH1 nutzten...

Zu b): Da kann ich Dir jetzt nicht so ganz folgen. openHAB sendet einen Read Request auf einer GA. Eine Regel in knx lautet, dass nur ein KO(!) pro GA das L-Flag gesetzt haben (und damit auf Read Requests antworten) darf.
Die physikalischen Adressen beziehen sich auf die einzelnen Devices und spielen beim korrekten Betreiben der knx Installation nur beim Programmieren der Geräte ein Rolle. Ansonsten sind sie natürlich noch bei der Bustopologie wichtig, aber eben nicht bei Schaltvorgängen. Ich weiß von einer Smarthome Lösung (wenn ich mich richtig erinnere MisterHouse), die tatsächlich die physikalische Adresse mit auswertete, womit man dann unterschiedliches Verhalten beim Senden der selben GA erreichen kann. Das ist nicht regelkonform!
Im openHAB Addon knx2 kann man die physikalische Adresse pro Device (Thing) angeben, in der Praxis spielt das aber keine Rolle. Allenfalls kann man darüber eine Offline Anzeige des Devices erhalten. Die physikalische Adresse des Gateways taucht in der openHAB-Konfiguration nicht auf(!), was in der Konfiguration als localSourceAddr bezeichnet wird, ist die physikalische Adresse von openHAB, nicht vom Gateway. Deshalb muss diese physikalische Adresse auch zwingend eine ungenutzte physikalische Adresse sein. In ETS kann man im Busmonitor die physikalische Adresse nutzen, um die Quelle der Datenpakete zuzuordnen. Dazu muss man dann in ETS ein Dummy Gerät mit dem Namen openHAB und der entsprechenden physikalischen Adresse anlegen (z.B. ein Schalter oder so... spielt keine große Rolle, was für ein Gerät da real nicht vorhanden ist...) Und schon bekommt man im Busmonitor (bzw. auch im Gruppenmonitor) direkt angezeigt, wenn openHAB quasselt.

Ich habe meine GA folgendermaßen strukturiert:

• Erste Zahl: Raum (ich habe weniger als 32 Räume...).
• Zweite Zahl: (grobe) Funktion. Alle Schalter haben eine 0, alle Dimmer eine 1, Heizung/Temperatur eine 2, Rollläden eine 3 usw.
• Dritte Zahl: KO-Nummer oder KO-Nummer + x*10 (x ist der xte gleichartige Kanal im Raum)

Für mich funktioniert dieses GA-Modell hervorragend, alle Aktoren haben damit einen sehr ähnlichen GA-Aufbau, in openHAB musste ich deshalb die Devices nur einmalig anlegen, dann kopieren und nur minimale Änderungen vornehmen.
Letztlich kann man aber die Adressen nach eigenem Gusto organisieren, man sollte sich halt ein System ausdenken, mit dem man selbst gut zurecht kommt.

Die physikalischen Adressen folgen natürlich den Regeln in knx, also alle Geräte einer Buslinie haben an erster und zweiter Stelle identische Zahlen, bis auf Linienkoppler oder gateways darf kein Gerät an letzter Stelle eine 0 haben usw.
Darüber hinaus hat unser Haus insgesamt zwei Stockwerke (also nur Erdgeschoss und Dachgeschoss). Somit war es für mich naheliegend, allen Geräten im zentralen Verteiler eine Adresse unter 100 zu geben, allen Geräten im Dachgeschoss eine Zahl über 199, und denen im Erdgeschoss eine Zahl zwischen 100 und 199 (einschließlich). Aber auch das ist natürlich ein rein willkürliche Festlegung.

Auf openHAB-Seite habe ich Things und Items in Textdateien definiert, wobei ich bei umfangreichen Addons jeweils eine eigene Datei verwende, bei anderen aber eine gemeinsame Datei (für drei Zeilen lohnt keine eigene Datei...)

Ich nutze VSCode zum Bearbeiten der Dateien und nutze entsprechend auch das automatische Erzeugen der Items aus den Channelinformationen. Mit gut organisierten Things Dateien geht das flott von der Hand