openhabforum.de

Hallo ich habe mal eine vielleicht Anfängerfrage.
Ich habe in meinem Neubau KNX u. ZigBee u. will nun steuern viel OH3.
Auf dem NAS läuft nun im Docker der OH3 Container, ich habe das KNX-Binding installiert u. diverse Netz-Setups des Containers ausprobiert (momentan MacVlan).
In allen Fällen schaffe ich es eine Lampe via SWITCH-Control anzuschalten, aber das ausschalten geht einfach nicht! Gibt es da zum KNX-Interface irgendeine Rückkommunikation oder Broadcast, die bei mir nicht funktioniert?

.... ich probier nun seit ner Woche u. bin ratlos

Typische Fehler in dem Zusammenhang sind:

Falsches Netz für den Container (man sollte dringend den host Mode verwenden, nicht Bridge)
Falsche localIp (das muss die echte von openHAB sein)
Falsches NATing (im host-Mode muss useNAT false gesetzt sein, im Bridge Mode muss useNAT true gesetzt sein. Aber wie vorher erwähnt... lieber host Mode)
Fehlerhaft gesetzte localSourceAddr. Bitte unbedingt auf 0.0.0 stehen lassen, bis eine korrekte Kommunikation sichergestellt ist. Danach diesen Parameter nur ändern, wenn Du auch wirklich verstanden hast, was das bewirkt.

Allgemein: Lass alle Parameter der knx Bridge auf den default Werten. Setze nur die korrekte Betriebsart (ROUTER oder TUNNEL) und die dazu notwendigen Parameter (IP-Adresse des Interface, IP-Adresse von openHAB, im Ausnahmefall Port).

Ansonsten ist es immer hilfreich, hier im Forum direkt die verwendete Konfiguration zu posten. Hinweis dazu: Private IP-Adressen werden nicht durch das Internet geroutet. Sie zu zeigen stellt also kein Risiko dar. knx wird ebenfalls nicht über das Internet geroutet. Auch GA oder andere Parameter zu posten ist kein Sicherheitsrisiko.

Geht es um andere Bindings, in denen z.B. Passworte oder Token einzutragen sind, sieht das natürlich anders aus. aber dort kann man ja problemlos Sternchen hinschreiben oder ein Phantasiepasswort, oder, oder....

Hmmm ... also ich habe KNX angebunden mit folgender Einstellung:
ipAddress ist die vom NAS/LAN-Adapter ... die localIP it die vom MacVLAN zugewiesene.
Hier die Config vom MacVlan, angebunden am Container. Die Kommunikation rein in den KNX-Bus geht ja, also ich kann meine Lampe einschalten nur das ausschalten geht nicht, vermutlich weil der Container einen Broadcast oder Status irgendwie nicht bekommt?

Ja, den HostMode .. wäre wohl vermutlich am einfachsten, wollt ich aber vorerst vermeiden.
Denke ist habe noch irgendein Config-Problem, oder ?

klausVomBau hat geschrieben: ↑19. Okt 2021 20:43 ipAddress ist die vom NAS/LAN-Adapter ... die localIP it die vom MacVLAN zugewiesene.

Nein, das ist verkehrt. ipAddress ist zwingend die IP des knx/IP-Interface localIp ist die des Containers.

Es wäre definitiv besser, den Host-Mode zu verwenden, useNAT auf false zu setzen und entsprechend eine IP aus dem normalen Netz nehmen (eben die, die dann dem Container zugewiesen wird).

.... ich hatte micht gestern vertippt, ich hatte schon richtig die ipAdresse, also die .34 eingetragen für das KNX-LAN-Gateway.
Nun habe ich den Host_Mode in Verwendung und auch hier geht leider das "ausschalten" nicht. Ich habe wie in allen anderen vorherigen Konfigurationsversuchen es ja geschafft im Schaltaktor das "anschalten" zu trigger, nur eben das "ausschalten" nicht.
Ich vermute ich habe noch eine grundsätzliches Konfig/Verständnisproblem

Ich habe doch nur eine Gruppenadresse, einen Status muss ich doch nicht selber proaktiv ziehen, oder?
Hier noch mal mein Konfig!
MDT-Schaltaktor-Switch-Thing: Gateway Ich vermute fast, dass am Gateway (MDT SCN-IP000.02) was falsch ist, oder vielleicht an meinem Managed-Switch was zu konfigurieren ist ..... seltsam.

Nein, entweder die Kommunikation klappt, oder sie klappt nicht. Aber bitte schalte fetch aus und setze unbedingt ! readInterval auf 0.

Wähle als ID bitte möglichst keine ellenlangen_sprechenden_namen_die_nur_unnütz_Platz_verschwenden, das ist Quatsch.

openHAB verwendet das Thing Modell für die Hardware. Das heißt, Du hast im Fall von knx gewöhnlich eine Bridge, über die kommuniziert wird. Hast Du mehrere knx Universen, kann es tatsächlich notwendig sein, eine zweite Bridge einzurichten, gewöhnlich wirst Du aber nur eine haben, deren UID dann am besten bridge ist (ergibt knx:device:bridge: für den vorangestellten Teil der ID aller Things).
Ein Thing sollte reale Hardware abbilden (soweit das möglich ist - z.B. bei astro wird natürlich nicht eine Entsprechung für Sonne und Mond abgebildet, sondern für berechnete Daten dieser beiden Himmelsobjekte) Das heißt bei knx, pro Device ein Thing. z.B. mit der ID hager_TXA606_B_1.
Das wäre dann ein Device, und zwar ein Hager 6-fach Schaltaktor.
Typischerweise enthält z.B. ein REG (Reiheneinbaugerät - die Teile, die im Schaltschrank montiert sind) mehrere identische Kanäle, z.B. 6 Schaltkanäle. Die ID des Channels wäre dann ch1, ch2, ch3, ch4, ch5 und ch6. Das ergibt dann für die kompletten ChannelUIDs knx:device:bridge:hager_TXA606_B_1:ch1 bis knx:device:bridge:hager_TXA606B_1:ch6.
Du siehst, die UIDs sind so hammermäßig sprechend, dass ich direkt an der UID ablesen kann, welches Gerät und welcher Kanal das ist.
Wenn ich nun noch das Label des Channels gescheit setze, z.B. auf "Steckdose Arbeitszimmer Fenster" finde ich den Channel sogar unter diesem Label in der Liste der Channel. Die UID ist aber schön kurz und trotzdem sprechend. Ich habe bei mir das Thing noch etwas kürzer benannt, habe dafür aber die physikalische Adresse in der ID mit drin, also so: hager_sw_1_1_15. Natürlich kann man die IDs nach eigenem Gusto wählen, aber man kann die ID nachträglich nicht ändern, man muss dann das Thing erneut anlegen (es sei denn, man nutzt Textdateien zur Konfiguration...) kurze IDs sparen Platz und erhöhen die Lesbarkeit wenn man mal über die API was nachschauen muss.

Noch mal zurück den GA... Jeder Kanal, den openHAB steuert, hat mindestens zwei GA, dabei ist die erste GA diejenige, an die openHAB den Befehl sendet (also z.B. Licht an/aus), die zweite GA meldet den Zustand zurück. Diese zweite GA ist gewöhnlich lesbar, das heißt, ein Read Request wird vom Aktor mit dem aktuellen Zustand beantwortet.
Ein Dimmer hat als Rückmeldung (in openHAB) nur den Level, nicht den Schaltzustand - der wird höchstens für die Schaltanzeige am Wandtaster benötigt.
Ein Rollladenaktor meldet gewöhnlich die Behanghöhe zurück. Es gibt diverse Modelle, die auch andere Dinge zurückmelden, die Behanghöhe ist aber das Einzige, was in openHAB interessiert. Falls ein Rollladenaktor das nicht kann, ist das kein Beinbruch, man wird aber keine Zustandsmeldung über die Rollläden haben.
Wenn das System korrekt konfiguriert ist, hat man also immer in exakt einem der anzugebenden Parameter des Channels exakt zwei GA in der Form 1/2/3+<4/5/6, in allen anderen Parametern maximal eine GA gesetzt.
Bei ausschließlich lesendem Zugriff (z.B. Raumtemperaturfühler) steht natürlich auch nur eine GA mit vorangestelltem < da, das < bedeutet, dass openHAB beim Systemstart versucht, über die nachfolgende GA den Zustand zu erfragen.

Es gibt ein paar Spezialfälle, in denen man evtl. zusätzliche GA angeben wird oder auch auf den Parameter readInterval > 0 zurückgreift, aber das sind wirklich Spezialfälle, darüber stolpert man allenfalls bei hartnäckigen Problemen.

Faustregel bei knx: nur konfigurieren, was unbedingt konfiguriert werden muss, keinesfalls, was man als "so muss es doch richtig sein" annimmt. Channel bekommen immer nur die GA, die ihnen exklusiv gehören, z.B. Zentral Aus wird keinesfalls in den Aktoren konfiguriert, sondern allenfalls über einen der Taster, die die Funktion steuern, oder alternativ auch als virtueller Channel, der keiner Hardware zugeordnet ist, damit man auch von openHAB aus auf Zentral Aus zugreifen kann. Gleiches gilt für Gruppen, Szenen usw., verfügbar machen: ja, einem Aktor zuweisen: NEIN.

Mir fällt da gerade noch was ein... Hast Du mal den Browser gewechselt? Das Endgerät? (nicht openHAB zwischendurch neu starten)?
es könnte sein, dass Du ein Problem mit der Authentification hast.

Prüfe bitte mal, ob Du in Settings-API Security (bzw. Einstellungen-API Sicherheit) die implizite Benutzerrolle aktiviert hast? Da gab es ein Problem, welches dazu führt, dass der Schaltbefehl nicht registriert wird. In der Folge wird dann beim Zurückschalten kein Befehl gesendet, was zu Deinem Fehlerbild passen würde...

Vielen Dank für Deine Ausführungen, ich richte nun mal die Gruppenadressen ein, das macht Laune bei 36 Geräten auf dem Bus

Ja, ich hatte eine Authentification Problem ... dies

https://github.com/openhab/openhab-webui/issues/731 war die Ursache.

Also .... you are suffering from #699.
Go to settings, API security, show advanced, enable "implicit user role for unauthenticated requests"'. It's probably disabled.

verdammt ... das hat mit viel Zeit gekostet.

Ich glaubte ja nicht wirklich an ein solches Problem, da ja das "Anschalten" via Web-UI ging, nur das "Ausschalten" nicht .... verrückt ...