Ankündigung

Einklappen
Keine Ankündigung bisher.

Anfänger bei KNX Visualisierung mittels Openhab

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

    Anfänger bei KNX Visualisierung mittels Openhab

    Guten Tag zusammen,

    ich bin im Thema Visualisierung mittels openhab blutiger Anfänger und benötige daher dringend eure Hilfe. Ich hoffe das ich auch die richtigen Begriffe benutze um mein Problem zu erklären.

    Ich habe unser Haus mit KNX ausgerüstet und würde dies nun gerne visualisieren.


    Openhab habe ich auf einem Rasberry pi schon zum Laufen gebracht. (Dank den Tutorials im Netz). Das Binding für KNX habe ich auch schon in openhab installiert und ist auch online.

    Leider komm ich bei der eigentlichen Visualisierung nicht weiter. Ich würde diese gerne dies über Habpanel machen. Kann mir jemand helfen wie ich die Item bzw. openitem anlege damit man diese im Habpanel aufrufen kann. Wie kann man mit openhab auf KNX zugreifen?

    Gibt es dazu Tutorials oder Anleitungen?

    Bitte seit gnädig mit euren Kommentaren, da ich mich mit dem Thema Visualisierung mittels openhab noch nicht auskenne.

    Gruß
    Tobias

    #2
    Wie hast Du openHAB denn auf dem Raspberry installiert? Es gibt aktuell zumindest fünf valide Wege, openHAB auf dem Raspberry zu installieren.
    Welches Raspberry Modell nutzt Du?

    Was Tutorials aus dem Internet betrifft, so muss ich sagen, dass die meisten davon zwar sicher gut gemeint, aber deshalb nicht zwingend gut sind. Oftmals sind die Anleitungen hoffnungslos veraltet, oder es werden seltsame Wege beschritten. Deshalb ist nach wie vor die Originaldokumentation der beste Weg, openHAB zu installieren.
    Auf dem Raspberry ist dazu gewöhnlich das openHABian Image der bequemste Weg (vielleicht nicht die alpha1.6...), auch wenn es damit trotz allem unheimlich viele Probleme zu geben scheint.

    Was knx betrifft, gehe ich davon aus, dass Du das knx2 Addon installiert hast. Falls das nicht der Fall sein sollte, rate ich Dir, direkt auf knx2 zu gehen. Der Unterschied: knx2 arbeitet mit dem Things-Modell, während knx1 schon unter openHAB1 zur Verfügung stand, mit openHAB3 aber nicht mehr unterstützt wird. Auch unter openHAB2 gibt es verschiedene Probleme mit knx1, so dass allgemein davon abgeraten wird.

    Ok, also knx2.
    Grob beschrieben musst Du zunächst eine Bridge anlegen. Die Bridge stellt auf openHAB-Seite die Verbindung zwischen dem knx Bus und openHAB dar. knx ist ein Methusalem unter den Automationssystemen, Du darfst hier keine Autokonfiguration erwarten. Um die Bridge zu erstellen, wechselst Du also in Paper UI auf Configuration -> Things und klickst dort auf das große Plus im blauen Kreis (oben links). Evtl. sucht openHAB nun eifrig nach neu hinzugekommener Hardware, aber das nutzt hier nichts, Du klickst also auf "add Thing manually" (oder so ähnlich...) In der Liste wählst Du knx aus, weil es ja darum geht. Nun hast Du die Wahl, eine Bridge oder ein Thing anzulegen, und die Bridge ist das, was Du brauchst.
    Je nach Schnittstelle kommt es jetzt darauf an... Hast Du ein einfaches knx/IP Gateway wie z.B. das Weinzierl 730 knx IP Interface, so wählst Du als Betriebsart TUNNEL aus und trägst die IP-Adresse des Gateways sowie die IP-Adresse des openHAB-Systems ein (die dient der Erkennung, über welches Interface openHAB an dem Netz hängt...) Hast Du gar einen knx/IP Router, kannst Du auch ROUTER als Betriebsart wählen und keine IP-Adresse eintragen (224.0.23.12 sollte die Multicast-Adresse sein, die man besser auch nicht ändert)
    Bitte keine weiteren Angaben vornehmen, insbesondere keine localSourceAddress eintragen, das ist nicht(!) die physikalische Adresse des Gateways.

    Danach sollte das Gateway ONLINE angezeigt werden.

    Nun brauchst Du noch mindestens ein knx Thing, Du kannst aber auch viele Things anlegen (auf dem gleichen Weg, wie Du auch die knx Bridge angelegt hast). Bis auf eine Stelle ist es egal, welchen Weg man geht. Das Thing Modell ist allerdings als virtuelles Pendant zur realen Welt gedacht, die Idee ist also, dass jedes Device am knx Bus als Thing in openHAB repräsentiert wird. Gerade bei knx ist das manchmal etwas verwirrend, da der knx Bus selbst schon eine Abstraktionsschicht bildet und es keinen zwingenden Zusammenhang zwischen Devices und Steuersignalen gibt. Es gibt aber tatsächlich einen Punkt, da ist die Trennung in unterschiedliche Things wichtig, nämlich, wenn man Geräte verwendet, die nicht in der Lage sind, zyklisch oder bei Wertänderung zu senden, sondern immer auf einen Read Request warten. Diesen kann knx2 zyklisch generieren, aber nur pro Thing (weil so eine Funktion eben immer das ganze Device betrifft). Wenn Du also solche Geräte hast, solltest Du mindestens diese als eigenständige Things anlegen.
    Das Thing muss der Bridge zugeordnet werden. Man kann hier die physikalische Adresse des Device eintragen, muss das aber nicht tun. Man sollte keinesfalls eine Fake-Adresse eintragen! Nur wenn eine korrekte Adresse eingetragen ist, sind die beiden Parameter fetch und pingInterval von Bedeutung. openHAB kann versuchen, weitere Informationen über das Device herauszufinden. Manche Devices kommen damit zurecht, andere nicht, bis auf die ONLINE/OFFLINE Anzeige spielt das aber keine Rolle.
    Der Parameter readInterval sollte nicht gesetzt werden oder auf 0 stehen, nur wenn es wirklich unbedingt nötig ist, sollte man von dieser Regel abweichen.

    Unterhalb des Things kannst Du nun beliebig viele Channel definieren. Ein Channel ist z.B. ein Schaltausgang, der dann sinnigerweise vom Typ switch ist (ON oder OFF), oder auch ein Dimmer (Typ dimmer: ON, OFF, INCREASE, DECREASE, 0-100%), oder, oder, oder...
    In jedem Channel musst Du die passenden Gruppenadressen eintragen, und zwar gewöhnlich immer zwei, nämlich für Input und Output.
    Beispiel: Eine Schaltaktor hat die GA 1/1/1, um das Relais schalten zu lassen, und die GA 1/2/1, um die Schaltstellung zu signalisieren. Die GA 1/2/1 ist lesbar. Dann trägt man beide GA gemeinsam so ein: 1/1/1+<1/2/1 Damit weiß openHAB, dass es Schaltbefehle an 1/1/1 sendet, während es beim Start den Status aus 1/2/1 abruft (das < Symbol)

    Jeder Aktor bietet eine aktive Rückmeldung des Status, diese ist enorm wichtig, damit die Visualisierung auch korrekt funktioniert! weiterhin gibt es evtl. Sensoren (Temperatur, Helligkeit, Bewegung...) die in openHAB auflaufen, solche Werte sind oftmals nur lesbar, dann reicht natürlich eine GA aus.
    Ein Dimmer hat dagegen gewöhnlich 5 GA, nämlich Schaltstellung Befehl und Status, Dimmlevel Befehl und Status sowie heller/dunkler, um Ein-Tasten-Bedienung zu ermöglichen. in openHAB benötigt man aber nur drei die GA, nämlich switch(ON/OFF Befehl) und position(Dimmlevel Befehl+<Status). increaseDecrease wird hingegen gewöhnlich nicht benötigt und viele Dimmer funktionieren darüber auch nicht, da openHAB nicht in der Lage ist, Start-Stop-Dimming zu nutzen, dies ist aber die gebräuchliche Art zu Dimmen.

    Nun hast Du eine Bridge, mindestens ein Thing und zum Testen vielleicht ein paar "einfache" Channel.

    Die bisherige Arbeit diente jedoch nur der Abstraktion und der Anbindung der Hardware.

    openHAB verwendet intern einen eigenen Bus, das ist der openHAB Bus. Auf diesem geht es immer um Items. Ein Item hat einen Status und kann Befehle senden. Wichtig ist, zu verstehen, dass dies zwei fundamental unterschiedliche Dinge sind. Beispiel:
    Ein Dimmer kann von openHAB den Befehl bekommen, eingeschaltet zu werden (ON). Der Dimmer ist so konfiguriert, dass das Licht beim Einschalten auf 70% gedimmt wird. Der Dimmer meldet also als Status 70%, woraufhin das Dimmer Item den Status 70 bekommt (ohne das %...) ON ist der Befehl, der Status ist aber 70. Dimme ich den Dimmer auf maximale Helligkeit (nehmen wir mal an, der Dimmer ist nicht begrenzt) so ist der Status anschließend nicht ON, sondern eben 100. Schalte ich den Dimmer aus, so ist der Status nicht OFF, sondern 0.
    Ein Switch kennt die Befehle ON und OFF und liefert als Status entsprechend ON und OFF. Aber auch der Switch kennt zumindest noch einen weiteren Zustand, nämlich NULL, falls openHAB nicht weiß, welchen Zustand der Switch hat.

    Damit Du nun auf die angelegten Channel zugreifen kannst, musst Du für jeden Channel ein Item anlegen. Falls Du Dich fragst: "Warum nicht gleich den Channel verwenden?", so antworte ich: Weil man mehrere Channel mit einem Item verknüpfen kann. Es gibt Konstellationen, wo das sehr sinnvoll ist.
    Gewöhnlich hast Du aber mehr oder weniger eine 1:1 Verknüpfung von Items und Channels. Dem Item ist es dabei vollkommen egal, welches Addon den Channel bereitstellt, und das ist der Knackpunkt von openHAB. Es ist egal, ob es sich um einen knx Dimmer oder eine Hue Lampe oder einen Shelly oder Homematic Dimmer handelt, für openHAB ist das alles gleich anzusteuern, mit ON, OFF, INCREASE, DECREASE und den Zahlen 0-100. Jedes der Geräte liefert über den entsprechenden Channel immer 0-100 als Wert zurück.

    Die passenden Items kannst Du einfacfh erzeugen, indem Du auf den leeren weißen Kreis im blauen Punkt vorne am Channel klickst.
    Es gibt in openHAB den Simple Mode. Ist dieser eingeschaltet, erzeugt openhAB bei diesem Klick direkt ein passendes Item. Leider hast Du keinerlei Einfluss auf dieses Item, Du musst es so nehmen, wie openHAB es anlegt, und ich versichere Dir, das Item ist hässlich
    Ist Simple Mode hingegen ausgeschaltet, so wird eine Liste mit vorhandenen Items geöffnet, die zum Channeltyp passen. In dieser Liste gibt es auch den Punkt + Create new Item..., welcher das dann auch ermöglicht. Der Unterschied zum Simple Mode ist aber, dass Du alle Parameter in diesem Moment selbst wählen kannst.
    Der Name des Items muss im gesamten System eindeutig sein, da er als ID auf dem openHAB Bus dient. Er muss mit einem Buchstaben anfangen und darf nur aus den Zeichen a-z, A-Z, 0-9 sowie _ bestehen. das sind also 63 verschiedene Zeichen. openHAB unterscheidet Groß- und Kleinschreibung, MeinSwitch und meinSwitch sind also zwei unterschiedliche Items! Es ist nicht ratsam, Items anzulegen, die sich nur durch die Groß-/Kleinschreibung unterscheiden, weil man als Anwender schnell durcheinander kommt, aber es wäre problemlos möglich!

    Sobald Du einen Channel mit mindestens einem Item verknüpft hast, kannst Du in Paper UI -> Control den Channel sehen (gruppiert im Thing). Sind von einem Thing keine Channel mit Items verlinkt, so taucht das Thing nicht in Paper UI Control auf. Du kannst z.B. einen Schalter hier auch testweise umschalten und sehen, ob der Schaltaktor dem Befehl folgt.

    Wenn Du diesen Punkt erreicht hast, kannst Du nach HABpanel wechseln, dort ein passendes Widget für das Item heraussuchen, das Erscheinungsbild anpassen, sowie das Item mit dem Widget koppeln.

    Das hört sich vielleicht sehr kompliziert an, aber bitte vergiss nicht, dass openHAB knx "nebenbei" unterstützt, das ist nur eines von mehreren hundert unterstützten Systemen.

    Mittelfristig wirst Du wahrscheinlich mehr als nur Visualisierung mit openHAB machen wollen, spätestens dann wäre es sehr sinnvoll, VSCode zu installieren und das openHAB Plugin einzurichten (das geht direkt aus VSCode heraus). Damit kannst Du fast alles über Textdateien konfigurieren, was ab 2 ähnlichen Channels schneller ist, als das nervige Rumgeklicke in Paper UI Außerdem kannst Du über VSCode Regeln erstellen, mit denen openHAB Dinge automatisch (also smart) erledigen kann.

    Kommentar

    Lädt...
    X