Wenn dies dein erster Besuch hier ist, lies bitte zuerst die Hilfe - Häufig gestellte Fragen durch. Du musst dich vermutlich registrieren, bevor du Beiträge verfassen kannst. Klicke oben auf 'Registrieren', um den Registrierungsprozess zu starten. Du kannst auch jetzt schon Beiträge lesen. Suche dir einfach das Forum aus, das dich am meisten interessiert.
Du kannst die Taster natürlich auch mit konfigurieren, aber wenn Du keine GA exklusiv auf einem Taster hast (z.B. um über openHAB die Lautstärke von Sonos zu steuern), würde ich dort die Channel nicht konfigurieren. Dann kann man trotzdem sehen, ob ein Device offline ist (wenn man das Feature nutzen möchte).
openHAB interessiert sich eigentlich nur für Aktoren und Sensoren (im Sinne von Messwerten also z.B. Temperatur), Schaltzustände fragt man nicht am Taster ab, sondern am Aktor.
Den reinen Taster würde ich auch nicht als Aktor, sondern als Sensor einordnen (wie gesagt, es sei denn, er wird auch ausgelöst, um etwas " zu tun", also LED schalten o.ä.). Ich wollte erst auch die Adresse meiner Taster erfahren, bis ich verstanden habe, dass die keine haben, sondern ich Leeradressen auf Vorrat anlegen und auf die Taster legen lassen muss, die ich dann später am eigentlichen Aktor oder in einer Logik auswerten muss.
Synology DS216j, OpenHAB2 2.1.0.008-DSM6 Snapshot (conf verlinkt nach /volume1/public/openhab2/conf)
Ein Taster ist im eigentlichen Sinn ja kein Sensor, sondern nur eine Fernsteuerung. Man könnte natürlich argumentieren, dass der Tastendruck erfasst wird, aber der Tastendruck wird ja dann weitergeleitet und im Aktor gespeichert (in Form des Aktorzustands). Auch hat man oft mehrere Taster, die die selben Aktoren steuern, der Status des Tasters ändert sich also in Abhängigkeit anderer Taster. das wäre bei einem Sensor normalerweise nicht der Fall.
Andererseits gibt es oft genug Taster mit echten Sensoren (z.B. Raumtemperatur), die möchte man ja auf jeden Fall einsammeln. Bei RTR kommt dann auch noch die Solltemperatur dazu, die im Taster gespeichert wird, somit ist der Taster auch der Chef für diese Information.
LED in Tastern sind meist an den Status des Tasters gebunden, es gibt leider nur selten die Möglichkeit, die LED unabhängig zu steuern.
habe heute meine Installation upgedated und auf das KNX 2.0 binding umgestellt. Habe knapp 450 GA. War bissel arbeit alle Things und Channels anzulegen und die Items umzuschreiben, aber es funktioniert nun super und vor allem kein Echo mehr am BUS. Perfekt.
Vielen Dank Kai für die viele arbeit !
Mal ne' andere Frage, das neue Binding wäre ja ein Klasse Anlass endlich mal mit openHAB zu spielen. Meine Frau macht mir sowieso schon Druck wann sie endlich das Licht mit dem Amazon Echo schalten kann . Mit der 1er Version konnte ich ja nach meinem Verständnis keine Verbindung in meinen BUS via meines Homeservers herstellen. Hat sich hier was geändert?
Alternativ müsste ich wohl zum Testen den Homeserver von der USB-Schnittstelle trennen und mit dem Rasbpi eine Serial-Verbindung aufbauen, korrekt? Und wenns klappt dann ein IP Gateway wie das Weinzierl IP Interface 731 anschaffen...
Der Homeserver stellt vermutlich keine KNXnet/IP Tunnel zur Verfügung, oder? Wenn eine knx Schnittstelle mit IP verwendet werden soll, muss dieses Protokoll verwendet werden (ob im Tunnel oder im Router Mode).
Alternativ kann openHAB aber auch mit seriellen (FT1.2?) Schnittstellen umgehen - inwieweit das auf USB-Schnittstellen zutrifft, weiß ich nicht. Notfalls kann man auf einem Rechner, an dem die Schnittstelle hängt, knxd laufen lassen, das stellt dann Tunnel oder Router Mode zur Verfügung.
Alternativ müsste ich wohl zum Testen den Homeserver von der USB-Schnittstelle trennen und mit dem Rasbpi eine Serial-Verbindung aufbauen, korrekt?
Über den HS kann man mittels EIBLIB/IP auf den Bus zugreifen. Das Protokoll wird aber von den Konnex nicht mehr unterstützt, Alternartiv den Raspi mit USB an den KNX und dort eibd / knxd laufen lassen. Dann kann der HS darüber auf den Bus zugreifen.
Leider ändert der Switch der Kommode nicht den Status wenn das Deckenlicht eingeschaltet wird somit muss in der Visu immer 2 mal der Taster betätigt um das Licht wieder auszuschalten.
Kann mir bitte jemand erklären wo ich da einen Fehler mache?
Wenn das in diesem Thread falsch ist, bitte verschieben aber die meisten Anderen beziehen sich noch nicht auf das neue Binding.
Über den HS kann man mittels EIBLIB/IP auf den Bus zugreifen. Das Protokoll wird aber von den Konnex nicht mehr unterstützt, Alternartiv den Raspi mit USB an den KNX und dort eibd / knxd laufen lassen. Dann kann der HS darüber auf den Bus zugreifen.
Servus vento, das klingt doch sehr interessant! Habe ich denn relevante Nachteile (z.B. Anzahl der möglichen TUNNEL) zu befürchten, wenn ich das so (also Raspi mittels knxd über USB Serial angeschlossen) mache, anstatt dass ich mir ein IP-Interface anschaffe? Will halt nicht x Stunden investieren, um am Ende doch 200 EUR in ein IP-Interface zu stecken.... :-)
Ich habe ein Item, dessen Status von OH kontrolliert wird. Es gibt hier also kein KNX Device welches auf lese requests antwortet.
Daher habe ich einen switch-control channel angelegt. Wenn ich in der ETS auf die konfigurierte GA einen lese request absende, wird von OH nicht darauf geantwortet. Ändere ich in oh den Wert in der sitemap, dann sehe ich den Wert aber im Gruppenmonitor. Was mache ich falsch?
Wir verarbeiten personenbezogene Daten über die Nutzer unserer Website mithilfe von Cookies und anderen Technologien, um unsere Dienste bereitzustellen. Weitere Informationen findest Du in unserer Datenschutzerklärung.
Indem Du unten auf "ICH stimme zu" klickst, stimmst Du unserer Datenschutzerklärung und unseren persönlichen Datenverarbeitungs- und Cookie-Praktiken zu, wie darin beschrieben. Du erkennst außerdem an, dass dieses Forum möglicherweise außerhalb Deines Landes gehostet wird und bist damit einverstanden, dass Deine Daten in dem Land, in dem dieses Forum gehostet wird, gesammelt, gespeichert und verarbeitet werden.
Kommentar