Hallo an alle,
ich gehe mit meiner Frage einmal Bewusst in den Einsteigerbereich, auch wenn ich meine KNX Powernet Anlage an sich schon mehrere Jahre betreibe und sie an sich bisher gut (aber nicht perfekt) funktioniert hat. Bisher wurde die Anlage über BJ KNX Powernet Busankoppler und ein ComfortPanel samt zugehöriger App gesteuert. Jetzt bekomme ich Probleme mit der App, da der Hersteller Busch-Jaeger diese seit zwei Jahren nicht erneuert hat uns sie zuletzt nach den aktuellen iOS Versionen keine Verbindung zum ComfortPanel aufbauen konnte. Das habe ich nun zum Anlass genommen, openHAB einzubinden und die zugehörige App zum Fernsteuern zu benutzen. Die ersten Schritte waren erfolgreich. Durch Forenbeiträge konnte ich mein ComfortPanel als "Tunnel" für openHAB benutzen und den KNX Bus ansprechen. Ich war ebenfalls in der Lage erste Things zu erstellen und habe mich hierbei auch wieder an Forenbeiträgen orientiert und entschieden, ein Thing einem physikalisch vorhandenen Aktor, bzw. in meinem Fall häufiger einem Steuerbaustein zuzuordnen. Die Kanäle des Things sind dann die physischen Ausgänge der an den Steuerbausteinen angebundenen Aktoren und Dimmer. Items und eine erste Sitemap funktionieren und ich kann die bereits eingebundenen Aktoren schalten. Jetzt habe ich aber drei spezielle Fragen zu zwei konkreten Problemen.
Meine Projektierung hat bisher keine Rückmeldegruppenadressen genutzt. Aus der Erinnerung hat der Elektriker gesagt, dass würde ggfs. zu viele Telegramme auf dem Bus erzeugen. Wenn also eine Taststelle genutzt wird, sendet sie eine GA an den Aktor und auch die Eingänge der LED des Tasters zum Umschalten. Das führt in einem Fall bei einer Treppenhausfunktion natürlich zu einem falschen Status, wenn der Aktor nach Zeitablauf umschaltet, weil ja kein neues Telegramm gesendet wird. Jetzt geht es mir um den Start von openHAB. Meine Anbindung an das ComfortPanel sieht so aus:
und ein Thing als Beispiel so:
Die Adresse 1.1.20 ist die dem Aktor im ETS Projekte zugeordnete Adresse und das Gerät wird in der Paper UI auch als "ONLINE" angezeigt. Schalten des "ausgang_c" funktioniert über die Itemdefinition
Eigentlich dachte ich, über fetch=true könne ich den Status bei Start auslesen und habe in der Basic UI dann die richtige Anzeige stehen. Das klappt aber nicht. Die Frage ist also, ob hierfür zwingend Rückmeldegruppenadressen definiert sein müssten, um beim Auslesen auch einen richtigen Status zu bekommen? So bekomme ich wohl nur einen Status "NULL" für das Item Switch.
Die zweite Frage bezieht sich auf die doppelte Belegung von Gruppenadressen auf die Eingänge von Aktoren und wie man damit im Zusammenhang mit Rückmeldegruppenadressen (und openHAB) richtig umgeht. Ich meine nun verstanden zu haben, dass die Idee von Rückmeldegruppenadressen ist, den Status eines Aktors sauber im Taster bzw. dessen LED abzubilden. Ich sende also eine GA vom Taster an den Aktor, empfängt dieser die GA richtig und schaltet um, sendet er seinerseits eine Rückmeldegruppenadresse und die ist dann der LED des Tasters zugeordnet, die nun umschaltet.
Jetzt habe ich bei mir zwei Sonderfälle, bei denen ich nicht weiss, wie ich richtig mit den Rückmeldegruppenadressen umgehen muss.
Fall 1 sind Deckenleuchten. Wir haben z.B. in einem Raum zwei Deckenleuchten, die jedoch getrennt je einem Aktorausgang zugeordnet sind, damit man sie einzeln schalten könnte. D.h. es gibt je Ausgang eine GA, allerdings gibt es für beide Ausgänge noch eine zusätzliche GA, um beide zusammen zu schalten. Dies ist zur Zeit auch der Zugeordnete Fall bei den Raumtastern. Eigentlich kann ja jedem Ausgang auch nur eine Rückmeldegruppenadresse zugeordnet werden, d.h. im Fall der gemeinsamen GA werden zwei Rückmeldungen gesendet. Was macht man in dem Fall am Taster richtig? Und als Zusatzfrage für openHAB, wie setzt man in den Things diese zusammengeschaltete Gruppenadresse richtig um, denn sie hat ja kein physikalisch vorhandenes Thing.
Fall 2 macht mir mehr Sorgen, geht aber in eine ähnliche Richtung. Ich habe zwei GA definiert, die ich als "Panikfunktion" bezeichnen möchte. Einen für den Innen- und eine für den Aussenbereich. Dazu gibt es natürlich physikalisch vorhandene Taster. Jedem Aktorausgang für Licht ist neben seiner Standardgruppenadresse, auf die er hört, noch zusätzlich eine der beiden Panik-GA zugeordnet. Wenn ich jetzt den Aktoren jeweils noch eine Rückmeldegruppenadresse programmieren würde, dann müsste der Bus doch mit Rückmeldungen geflutet werden, wenn ich Panik-GA sende, richtig?
Daher die Frage: Wie gehen die Fortgeschrittenen und Profis mit den Rückmeldegruppenadressen um, und wie kann ich den aktuellen Status meiner Aktoren in openHAB nach einem Neustart sauber erfahren, so dass ich in der Basic UI den richtigen Status auch sehe. Schalte ich im Moment an den physischen Tastern um, empfängt openHAB auch diese Telegramme und nach je einem Ein- und Ausschaltvorgang stimmt die Anzeige in der Basic UI für die einfachen Fälle. Aber das sollte doch auch anders gehen, oder?
Das war jetzt viel Text, aber ich hoffe das verständlich beschrieben zu haben, denn ich habe kein Problem alle Geräte im Haus nochmal umzuprogrammieren, wenn mir das was bringt. Aber wenn es auch anders geht, bin ich nicht böse drum.
ich gehe mit meiner Frage einmal Bewusst in den Einsteigerbereich, auch wenn ich meine KNX Powernet Anlage an sich schon mehrere Jahre betreibe und sie an sich bisher gut (aber nicht perfekt) funktioniert hat. Bisher wurde die Anlage über BJ KNX Powernet Busankoppler und ein ComfortPanel samt zugehöriger App gesteuert. Jetzt bekomme ich Probleme mit der App, da der Hersteller Busch-Jaeger diese seit zwei Jahren nicht erneuert hat uns sie zuletzt nach den aktuellen iOS Versionen keine Verbindung zum ComfortPanel aufbauen konnte. Das habe ich nun zum Anlass genommen, openHAB einzubinden und die zugehörige App zum Fernsteuern zu benutzen. Die ersten Schritte waren erfolgreich. Durch Forenbeiträge konnte ich mein ComfortPanel als "Tunnel" für openHAB benutzen und den KNX Bus ansprechen. Ich war ebenfalls in der Lage erste Things zu erstellen und habe mich hierbei auch wieder an Forenbeiträgen orientiert und entschieden, ein Thing einem physikalisch vorhandenen Aktor, bzw. in meinem Fall häufiger einem Steuerbaustein zuzuordnen. Die Kanäle des Things sind dann die physischen Ausgänge der an den Steuerbausteinen angebundenen Aktoren und Dimmer. Items und eine erste Sitemap funktionieren und ich kann die bereits eingebundenen Aktoren schalten. Jetzt habe ich aber drei spezielle Fragen zu zwei konkreten Problemen.
Meine Projektierung hat bisher keine Rückmeldegruppenadressen genutzt. Aus der Erinnerung hat der Elektriker gesagt, dass würde ggfs. zu viele Telegramme auf dem Bus erzeugen. Wenn also eine Taststelle genutzt wird, sendet sie eine GA an den Aktor und auch die Eingänge der LED des Tasters zum Umschalten. Das führt in einem Fall bei einer Treppenhausfunktion natürlich zu einem falschen Status, wenn der Aktor nach Zeitablauf umschaltet, weil ja kein neues Telegramm gesendet wird. Jetzt geht es mir um den Start von openHAB. Meine Anbindung an das ComfortPanel sieht so aus:
Code:
Bridge knx:ip:bridge "Busch-Jaeger ComfortPanel 9 8136/09-811 (1.1.255)" [
type="TUNNEL",
ipAddress="192.168.178.10"
]
Code:
Thing device bj_reg_1_1_20_kg "Busch-Jaeger REG 6993-101 (1.1.20)" @ "Kellerflur" [ // Busch-Jaeger KNX Powernet REG 6993-101 Binäraus-/eingang
address="1.1.20",
fetch=true,
pingInterval=300,
readInterval=3600
] {
Type switch : ausgang_c "Wandlampe Kellerflur" [ ga="1/2/1" ]
}
Code:
Switch s_kg_flur_wandlampe "Wandlampe Kellerflur" <light> (gKellerflur) { channel="knx:device:bridge:bj_reg_1_1_20_kg:ausgang_c" }
Die zweite Frage bezieht sich auf die doppelte Belegung von Gruppenadressen auf die Eingänge von Aktoren und wie man damit im Zusammenhang mit Rückmeldegruppenadressen (und openHAB) richtig umgeht. Ich meine nun verstanden zu haben, dass die Idee von Rückmeldegruppenadressen ist, den Status eines Aktors sauber im Taster bzw. dessen LED abzubilden. Ich sende also eine GA vom Taster an den Aktor, empfängt dieser die GA richtig und schaltet um, sendet er seinerseits eine Rückmeldegruppenadresse und die ist dann der LED des Tasters zugeordnet, die nun umschaltet.
Jetzt habe ich bei mir zwei Sonderfälle, bei denen ich nicht weiss, wie ich richtig mit den Rückmeldegruppenadressen umgehen muss.
Fall 1 sind Deckenleuchten. Wir haben z.B. in einem Raum zwei Deckenleuchten, die jedoch getrennt je einem Aktorausgang zugeordnet sind, damit man sie einzeln schalten könnte. D.h. es gibt je Ausgang eine GA, allerdings gibt es für beide Ausgänge noch eine zusätzliche GA, um beide zusammen zu schalten. Dies ist zur Zeit auch der Zugeordnete Fall bei den Raumtastern. Eigentlich kann ja jedem Ausgang auch nur eine Rückmeldegruppenadresse zugeordnet werden, d.h. im Fall der gemeinsamen GA werden zwei Rückmeldungen gesendet. Was macht man in dem Fall am Taster richtig? Und als Zusatzfrage für openHAB, wie setzt man in den Things diese zusammengeschaltete Gruppenadresse richtig um, denn sie hat ja kein physikalisch vorhandenes Thing.
Fall 2 macht mir mehr Sorgen, geht aber in eine ähnliche Richtung. Ich habe zwei GA definiert, die ich als "Panikfunktion" bezeichnen möchte. Einen für den Innen- und eine für den Aussenbereich. Dazu gibt es natürlich physikalisch vorhandene Taster. Jedem Aktorausgang für Licht ist neben seiner Standardgruppenadresse, auf die er hört, noch zusätzlich eine der beiden Panik-GA zugeordnet. Wenn ich jetzt den Aktoren jeweils noch eine Rückmeldegruppenadresse programmieren würde, dann müsste der Bus doch mit Rückmeldungen geflutet werden, wenn ich Panik-GA sende, richtig?
Daher die Frage: Wie gehen die Fortgeschrittenen und Profis mit den Rückmeldegruppenadressen um, und wie kann ich den aktuellen Status meiner Aktoren in openHAB nach einem Neustart sauber erfahren, so dass ich in der Basic UI den richtigen Status auch sehe. Schalte ich im Moment an den physischen Tastern um, empfängt openHAB auch diese Telegramme und nach je einem Ein- und Ausschaltvorgang stimmt die Anzeige in der Basic UI für die einfachen Fälle. Aber das sollte doch auch anders gehen, oder?
Das war jetzt viel Text, aber ich hoffe das verständlich beschrieben zu haben, denn ich habe kein Problem alle Geräte im Haus nochmal umzuprogrammieren, wenn mir das was bringt. Aber wenn es auch anders geht, bin ich nicht böse drum.