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.
Und genau das kannst du abfangen. Ich habe das sogar versuchsweise in eine externe Logik umgesetzt. Dann sollte es auch in der Brücke machbar sein. Du musst doch nur die Unterscheidung zwischen hoch und runter ignorieren und es als ein Tap interpretieren.
Nach deiner Logik müsste die Brücke, wenn während dem Öffnen ein Schließbefehl kommt, das Rollo stoppen. Das mag bei deinem Anwendungsfall so stimmen, aber was wenn jemand während dem Öffnen das Rollo schließen möchte (zB weil eine HomeKit-Szene ausgeführt wird)? Dann würde das Rollo stoppen und nicht schließen – das wäre dann ein Fehlverhalten.
Die korrekte Lösung wäre, dass die Home-App per Option das Rollo während der Fahrt stoppen kann und nicht die Fahrtrichtung ändert. Da es aber eine App von Apple ist, würde ich da wenig Hoffnung darin setzen, dass so ein Option jemals Einzug findet.
Könntest du mit bitte deine Konfiguration und die Ausgaben des Busmonitors zukommen lassen?
(Entweder hier posten, auf GitHub ein Issue erstellen, oder ein E-Mail schreiben.)
Das wird mit einem Aktor z.B. bei MDT mit aktivem SOC nie gehen können. In Szenen verwendet man doch Positionsangaben und dann ist es egal. Man müsste ja nur in der Pflegemaske ein weiteres Öffnen/Stop/Schließen GA haben. Die keine SOC nutzen, nutzen es wie bisher. Aber das SOC ist ja jetzt kein speziell Fall. Also bei uns verwenden alle das SOC, da es keine JAL-Tasten mit Stopptaste gibt. Und der Umweg per Long/Shortpress finde ich unintuitiv. Die Diskussion das ist in KNX nicht üblich möchte ich jetzt aber auch nicht los treten. Das ist so eine KNX Filter-Blase die man bei anderen Hersteller so nicht kennt. Wie gesagt auch der Hörmann Torantrieb arbeitet defaultmäßig damit.
Der Aktor ermöglicht eine komfortable Handbedienung. Ein kurzer Tastendruck auf den Rollladentaster lässt den Rollladen des bedienten Fensters fahren oder wenn er fährt, anhalten. Mit einem langen Tastendruck fahren z.B. alle Rollläden im Raum. Mit normalen Aktoren anderer Hersteller ist diese Funktion nicht möglich. Erreicht wird die Funktion durch eine Ansteuerung mit nur einem Objekt (kurzer Tastendruck) für Auf/Ab/Stopp (Single Object Control). Das Objekt für langen Tastendruck (empfohlen 1-1,5s) steuert dann alle Rollläden im Raum als Gruppe an."
Hast du schonmal auf dem KNX Bus nachgesehen, ob alle Werte auf den KNX Bus gesendet werden?
Hier könnte das Problem an den unterschiedlichsten Stellen liegen.
Daher würde ich mal beginnen nachzusehen, ob alle Werte beim Ausführen der Szenen an den KNX Bus gesendet werden.
Das Problem ist nicht so einfach zu reproduzieren, da es eben nur manchmal auftritt. Der Fehler betrifft insbesondere das korrekte Dimmen. Ich bleibe dran.
Türklingeln als eigenständiges Gerät werden von HomeKit nicht unterstützt. Was unterstützt wird ist eine Videokamera in Verbindung mit einer Haustürklingel - als eine Video-Türsprechanlage.
Ich habe eine Türklingel über die node-red-contrib-homekit-bridge eingebunden: Beim Druck auf die Klingel bekomme ich jetzt eine HomeKit-native Nachricht. Eine gewisse Unterstützung gibt es offensichtlich schon.
Das sehe ich nicht als Aufgabe einer HomeKit Brücke. Für Rasensprenger gibt es nicht ohne Grund eine Systeme, da es hier unzählige Varianten, Optionen und Einstellungen geben kann. Hier würde ich ein Skript einsetzen und die ganze Bewässerungslogik dort abbilden. Damit könnte man komplexe Logiken in allen möglichen Varianten realisieren und auch externe Services wie Wetter und Kalendar integrieren.
Klar, für die Logiken ist die Brücke nicht gedacht. Aber um manuell einen Sprenger zu starten sehr wohl. Genau das vermisse ich. Ich habe jetzt mühsam jeden Sprenger über KNX-Ultimate und o.g. Homekit-NodeRed-Brücke eingebunden. Kein Spaß!
Das Problem ist mir neu. Könntest du bitte das im Detail nochmal erklären, wie du die Alarmanlage konfiguriert hast?
Wenn die Alarmanlage über die Brücke scharfgestellt werden soll, dann geht sie bei Homekit in den Target-State und wartet auf die positive Rückmeldung, dass die Alarmanlage scharf ist. Wenn aber die Scharfstellung fehlschlägt sehe ich keine Möglichkeit, den Target-Modus über ein KNX-KO zu beenden, das geht nur, indem man sie manuell wieder ausstellt.
Welche Erleichterung würde das in deinem Fall bringen?
Man könnte ein Gerät duplizieren, die Bezeichnung und Raumzuordnung und Datentypen wären bereits richtig, man müsste nur noch die Gruppenadressen ändern (und in der Regel nur eine einzige Ziffer davon, wenn man das in der ETS systematisch aufgebaut hat).
Ein Backup von einer App von Apple ist nicht möglich. Aus Datenschutzgründen kann man nicht auf die Daten zugreifen, geschweige den wiederherstellen.
Ich dachte es gäbe eine App, die genau das kann?! Wie auch immer: schade, ich möchte niemals knapp 150 Geräte neu anlegen müssen. Apropos: Die Raumzuordnung kann ja mit Deiner App rekonstruiert werden; es wäre schön, wenn man auch die Einstellung für „Status“ und „Favoriten“ rekonstruieren könnte.
Richtig, es lässt sich nur das Umsetzen, was auch von HomeKit und der Home-App unterstützt wird.
Klare Sache. Und z.B. ein Stopp eines Garagentors ist m.W. bei Homekit nicht vorgesehen.
Ich habe eine Türklingel über die node-red-contrib-homekit-bridge eingebunden: Beim Druck auf die Klingel bekomme ich jetzt eine HomeKit-native Nachricht. Eine gewisse Unterstützung gibt es offensichtlich schon.
Klar, für die Logiken ist die Brücke nicht gedacht. Aber um manuell einen Sprenger zu starten sehr wohl. Genau das vermisse ich. Ich habe jetzt mühsam jeden Sprenger über KNX-Ultimate und o.g. Homekit-NodeRed-Brücke eingebunden. Kein Spaß!
Was spricht dagegen einen Taster für die Sprenger in hkknx anzulegen?
Man könnte auch einen Taster für mehrere Sprenger benutzen, wenn es dazu eine Gruppenadresse gibt.
Wenn die Alarmanlage über die Brücke scharfgestellt werden soll, dann geht sie bei Homekit in den Target-State und wartet auf die positive Rückmeldung, dass die Alarmanlage scharf ist. Wenn aber die Scharfstellung fehlschlägt sehe ich keine Möglichkeit, den Target-Modus über ein KNX-KO zu beenden, das geht nur, indem man sie manuell wieder ausstellt.
Wenn die Scharfstellung fehlschlägt, dann müsste man das der Brücke auch mitteilen.
Man könnte ein Gerät duplizieren, die Bezeichnung und Raumzuordnung und Datentypen wären bereits richtig, man müsste nur noch die Gruppenadressen ändern (und in der Regel nur eine einzige Ziffer davon, wenn man das in der ETS systematisch aufgebaut hat).
Interessante Idee. Dazu habe ich mal ein Issue erstellt. → #117
Wie auch immer: schade, ich möchte niemals knapp 150 Geräte neu anlegen müssen.
Musst du auch nicht. Wenn du die Brücke mal aus HomeKit entfernst und wieder hinzufügst, werden alle Geräte wieder in HomeKit sichtbar. Nur die Raumzuordnung stimmt dann nicht mehr. Die Raumzuordnung kann man aber wieder mit der Konfigurator-App wiederherstellen.
Die Raumzuordnung kann ja mit Deiner App rekonstruiert werden; es wäre schön, wenn man auch die Einstellung für „Status“ und „Favoriten“ rekonstruieren könnte.
Die Raumzuordnung wird zentral in der HomeKit-Datenbank gespeichert. Daher haben auch Drittanbieter-App darauf Zugriff.
Ob ein Gerät in der Apple Home-App als Favorit angezeigt wird oder nicht, wird in der App selbst gespeichert und nicht in der HomeKit-Datenbank.
Deshalb hat nur die Apple Home-App Zugriff darauf.
Tja der Status könnte irritieren. Andererseits funktioniert es bereits einfach gut. Ich würde es mit entsprechendem Hinweis als „alpha“ einbinden.
Was spricht dagegen einen Taster für die Sprenger in hkknx anzulegen?
Man könnte auch einen Taster für mehrere Sprenger benutzen, wenn es dazu eine Gruppenadresse gibt.
Was spricht denn so gegen die Implementierung? Irrigation-Systeme bestehen aus verschiedenen Sprengern und lassen sich für Bereiche des Gartens erstellen. Jeder Sprenger bekommt in HomeKit zudem eine Rückmeldung, so dass visualisiert wird, ob nur das Ventil offen ist oder tatsächlich Wasser läuft. Das alles ist doch schon deutlich mehr, als ein Schalter kann.
Wenn die Scharfstellung fehlschlägt, dann müsste man das der Brücke auch mitteilen.
Und damit kriegt man ein Alarm-System vom Target-Mode wieder auf Aus gestellt? Muss ich mir nochmal genau angucken, wenn ich wieder aus dem Urlaub zurück bin.
Was spricht denn so gegen die Implementierung? Irrigation-Systeme bestehen aus verschiedenen Sprengern und lassen sich für Bereiche des Gartens erstellen. Jeder Sprenger bekommt in HomeKit zudem eine Rückmeldung, so dass visualisiert wird, ob nur das Ventil offen ist oder tatsächlich Wasser läuft. Das alles ist doch schon deutlich mehr, als ein Schalter kann.
Dagegen spricht, dass ein Bewässerungssystem an sich nichts mit KNX zu tun hat. Es würde sich dabei um ein eigenes "System" handeln und die Logik, wann welcher Sprenger eingeschaltet wird und für wie lange, muss von der Brücke ausgeführt werden. Bei allen anderen Geräten läuft das nicht so – wird eine Lampe in KNX eingeschaltet, so leitet die Brücke das lediglich an HomeKit weiter und umgekehrt auch.
Weiters würde ein Bewässerungssystem wieder eine Unmengen an Sonderfällen mit sich bringen. Manchen wollen nur zeitgesteuert die Sprenger regeln, andere wieder mit speziellen Regeln (zB wann niemand zu Hause ist, wenn die Bodenfeuchte unter einem Schwellwert liegt) und Integrationen mit anderen System (zB Kalendar, Wetter) erfordern. Nicht ohne Grund gibt es dafür eigene in sich abgeschloßene System – zb opensprinkler
Zum aktuellen Stand hat ein eigenes Bewässerungssystem keine hohe Priorität, da es
1. kein generelles Feature von KNX ist
2. zu viele Sonderfälle gibt und es daher enorm viel Aufwand bedeutet
3. der Bedarf für mich nicht einschätzbar ist (für nur ein paar User ist der Kosten-Nutzen-Faktor zu gering).
Genau für solche Fälle wurden Skripte eingeführt. Damit kann man mit wenigen Zeilen Code bereits anständige Automationen realisieren. Außerdem kann man mit Skripte auf Wetterdaten zugreifen, Kalender für eine HTTP API einbinden, ein eigenes Webinterface zur Verfügung stellen, KNX Sensorwerte (zB Bodenfeuchte) abfragen einbinden. Eine einfache Form einer Gartenbewässerung wird im Beispiel Gartenbewässerung gezeigt.
Dagegen spricht, dass ein Bewässerungssystem an sich nichts mit KNX zu tun hat. Es würde sich dabei um ein eigenes "System" handeln und die Logik, wann welcher Sprenger eingeschaltet wird und für wie lange, muss von der Brücke ausgeführt werden. Bei allen anderen Geräten läuft das nicht so – wird eine Lampe in KNX eingeschaltet, so leitet die Brücke das lediglich an HomeKit weiter und umgekehrt auch.
Warum hat Bewässerung nichts mit KNX zu tun? Meine Bewässerung ist komplett mit KNX-Aktoren realisiert. Und genau das, was Du oben in Deinem letzten Satz schreibst, würde ich erwarten:
a) Sprinkler an- und ausstellen sowie b) den Status visualisieren (Ventil zu, offen, Wasser läuft). Und genau das unterstützt Homekit. Und genau das ließe sich mit zwei bis drei KNX-Gruppenadressen (Ventil-Aktor und -Rückmeldung, ggf. Rückmeldung Pumpe/Strömungsmesser) realisieren. Also einfache Weiterleitung von Homekit zu KNX und zurück.
Wenn man es perfektionieren wollte, dann noch Parent-Service und Linked-Service für Sprinkler umsetzen, damit die Visualisierung übersichtlich bleibt.
Eine Logik oder Zeitsteuerung würde ich von einer „Brücke“ überhaupt nicht erwarten - weder für Sprinkler, noch für sonstige Gerätschaften; und damit wären wir wieder beim ursprünglichen Thema…
Aber eines ist klar: Das ist Dein Projekt und Du entscheidest, was implementiert wird, ich bin nur ein Kunde und soweit sehr zufriedener Anwender!
Und genau das, was Du oben in Deinem letzten Satz schreibst, würde ich erwarten:
a) Sprinkler an- und ausstellen sowie b) den Status visualisieren (Ventil zu, offen, Wasser läuft).
Wo sitzt bei dir die Logik, wann welches Ventil eingeschaltet wird und für wie lange?
Logiken (nicht nur für Bewässerung) laufen bei mir über Node Red. Homekit benutze ich zur Visualisierung und zur manuellen Bedienung.
Tja, genau da liegt das Problem. Irgendwer muss die Logik dafür übernehmen – ich kann ja nicht voraussetzen, dass jeder Node-Red oder ein anderes System am Laufen hat. hkknx sollte unabhängig von anderen System sein.
Das unterscheidet die Bewässerung nicht von der Lichtsteuerung oder anderen Gerätschaften: die Logik ist eben nicht Aufgabe der Brücke! Es geht primär um Visualisierung und manuelle Bedienung. Insofern würde eine Implementierung in hkknx auch ohne Logik sehr hilfreich sein.
Hi, also ich habe auch eine Bewässerungsanlage mit 2 Ventilen bei mir verbaut.
Ich öffne und schließe die Ventile über je einen Aktorausgang ( schalten ein/aus). Hinter diesen Ausgängen sind dann je 1 24V Netzteil verbaut die die Ventile öffnen und schließen. Diese 2 habe ich in HKKnx mit 2 Schaltern realisiert, die je ein Ventil steuern.
Somit habe ich die Möglichkeit beide getrennt anzusteuern und den Status zu sehen.
Ich habe weiterhin in Homekit eine Automation laufen, wo ich beide Ventile einschalten lasse um 19:00 Uhr und diese dann automatisch 1 Stunde später wieder schließen lasse.
Ich plane noch weiteres einzubauen, was aber im Moment noch geplant ist aber soweit schon vorbereitet ist:
(Wenn es regnet oder geregnet hat lasse ich bei mir über den Regensensor von MDT messen, der mir dann eine "1" oder eine "0" sendet, je nachdem ob es geregnet hat oder nicht, so das die Bewässerung eben nicht angeht um 19 Uhr bei mir.)
So habe ich für mich die Bewässerung geregelt.
Vielleicht hilft ja diese Info
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