KNX (EIB) per Zigbee ansteuern

[MiGe]

Hallo zusammen,
eine Bemerkung vorneweg: Ich bin ziemlicher Laie auf dem Gebiet, hoffe daher dass mir hier jemand weiterhelfen kann.

Meine Aufgabenstellung ist die folgende:
Die Jalousien in unserer Wohnung werden über einen EIB Instabus angesteuert (von Siemens, vor ca. 23 Jahren installiert)
Dazu gibt es eine 2-Kanal-Schaltuhr, an der ich für 2 Gruppen von Jalousien die Öffnungs-und Schließzeiten einstellen kann, für jeden Wochentag einzeln.

Das ist alles recht schön, da sich aber übers Jahr die Sonnenauf- und -untergangszeiten ändern muss ich regelmäßig diese Schaltzeiten per Hand an der Uhr ändern.
Geht, ist aber unbequem.

Einfachste Abhilfe wäre wohl die Schaltuhr durch eine "astronomische" zu ersetzen die die Auf- und Untergangszeiten automatisch berücksichtigt.

Noch lieber aber wäre mir wenn ich die Zeiten per PC oder App einstellen könnte......

Ich habe ein HUE-Gateway mit dem ich einige Lampen/Steckdosen schalte, und da kann man sehr schön Schaltprogramme anlegen die z. B. als Triggerpunkt "Sonnenaufgang" haben (damit wird aktuell die Adventsillumination gesteuert....)

Jetzt würd ich es super finden wenn ich solche "Schaltimpulse" des HUE-Systems durch ein wie auch immer geartetes Interface an das KNX-System senden und damit die Jalousie steuern könnte.


Was gibt es da für Lösungen / Geräte????


Alles was ich hier im Forum gefunden habe beschreibt immer den umgekehrten Fall, da wollen Leute das HUE-Licht vom KNX aus steuern....


Danke für Tips und Gruß aus Berlin - Michael

[CaptainFuture]

Schlüsselfertig gibt’s da afaik nichts. Du bräuchtest ja als erstes mal im Hue-Kosmos ein virtuelles Gerät. Da bin ich jetzt überfragt, ob es dort soetwas gibt. Den Schaltimpuls kriegt man per Software aus der Hue-Bridge und per Software auch ins KNX. Bleibt die Frage nach dem Aufwand. Software-Systeme wie OpenHAB, HomeAssistant etc. brauchen halt noch einen „Server“ auf dem sie laufen können, die Hue-Geräte können automatisch eingelesen werden. Die KNX-Seite wir etwas mehr Handarbeit, ist aber auch keine Rocket-Science.

tl;dr
geht, aber nur mit ein bisserl Gefummel

[herr2d2]

Vielleicht hast du ja über einen PM oder eine Wetterstation den Helligkeitswert auf dem Bus. Ich bin ein Fan von Uhrzeit und Helligkeit zur Steuerung der Jalousien, z.B. Jalousien, wenn es dunkel ist, runterfahren, aber nicht vor 20 Uhr …

Die Uhrzeit für die Jalousien immer händisch nachzujustieren, wäre mir zu lästig 🤷♂️

[gbglace]

Bei dem Baujahr der KNX-Anlage, sollte man aber auch mal vorsichtig in den Verteiler schauen was da so enthalten. Ist. wenn da noch Aktoren mit Datenschiene drinnen sind muss man schon sehen was man da dann noch in der aktuellen ETS ohne Aufwand bedient bekommt.

Und ich vermute mal da wird nichts zu finden sein was irgendwie einen LAN Schluss hat, also ein KNX-IP Interface oder gar KNX-IP Router. das wären ja so die mindest Gerätschaften am KNX-Bus um irgendwie mit dem Zigbee in Kontakt zu kommen.

Mit ein paar Umwegen wie solchen Opensource Integrationsplattformen kann man sich da bestimmt etwas basteln.

Aber ich würde ggf eher sehen den KNX-Teil zu ertüchtigen und in der Wohnung zu erweitern. man sieht ja dass das schon gut und lange läuft. will ja mal in 20 Jahren sehen welches HUE Birnchen da noch tut bzw. Softwarekompatibel ist.

[MiGe]

Danke für Eure Antworten.

Den Helligkeitswert habe ich leider nicht auf dem Bus, es ist kein entsprechender Sensor installiert.

Dass ich das vorhandene System (mindestens) mit einem KNX-IP-Interface erweitern muss ist mir schon klar.
Frage ist halt mit welcher Anwendung ich dann die entsprechenden Signale an dieses Interface schicke. Also irgendeine "Haussteuerungs-SW" für die dann ja sicher auch ein Gateway o. ä. benötigt wird.
Ich hatte gehofft wenn ich so ein Ding von HUE schon habe kann ich das dafür hernehmen. Also so dass HUE nicht eine Lampe oder Steckdose "Ein" und "Aus" schaltet sondern diese Signale über das fragliche Interface an das KNX-IP-Interface schickt

[gbglace]

Das Problem ist, HUE kann nur mit sich selbst sprechen also musst Du ein virtuelles Gerät ansprechen oder den HUE Funkverkehr mitschneiden.

Die verfügbaren HUE/KNX Adapter schauen in die HUE API und haben da die Möglichkeit Befehle für ein HUE gerät abzusetzen oder einen Status eines HUE Gerätes zu erhalten. Weil primär ist KNX derjenige Teil der per KNX-Taster eine HUE-Lampe steuert. Die Hersteller sind da nur schwer auf den Gedanken gekommen, das man einen HUE Taster nimmt um einen KNX Aktor zu triggern.

Aber ansonsten sich das ISE HUE GW anschauen ob da so etwas in der Applikation vorgesehen ist.

Anders schaut das bei den OpenSource Lösungen aus. die haben einfach umfangreichere HUE APIs gebaut und haben auch KNX-APIs Dein Problem ist dann dort das Du bei den Dingern für die Verbindung derer sorgen musst. weil nur ganz wenige Systeme da die Möglichkeit haben die Adapterboxen direkt miteinander zu verbinden und automatisch alle notwendigen Konvertierungen vorzunehmen.

Beispiel NodeRed. da habe ich KNX Adapter und Velux-Adapter für deren Rollos. Klar kann ich die einfach mit einer Linie verbinden aber das was da jeweils als payload in der Nachrichtsteckt, damit kann der andere nichts anfangen. der eine will in Worten auf ab der andere erwartet aber absolute Zielpositionen in % also integers 0 bis 100. Da baut sich dann mehr oder weniger jeder selbst eine Konvertierungsnode in den Pfad. Das ist dann bei HA / NR / IOB alles das selbe.

Und weil diese APIs gerade auf der IoT Seite (hier HUE) relativ schnelllebig sind. sind solche GW nichts wo so träge Hersteller wie Siemens, ABB / Gira gerne Gateways bauen. sieht man ja jetzt am ISE Sonos. gibt es nicht mehr wird nciht mehr geartet, wo Sonos die API mal wieder umbaut. An der Stelle sind Open-Source-Adapter einfach viel schneller sowas zu adaptieren und zu aktualisieren. Da sitzen halt einige Leute mit Eigeninteresse. Ist die OpenSourceLösung aber zu klein sind es ggf nur 2 Entwickler und wenn die dann nicht die neuste HW haben sehen die da ggf auch keinen Bedarf zur Aktualisierung.

Von daher versuche ich hier so viel wie möglich im langweiligen alten KNX-TP zu machen weil das auch noch in 20 Jahren alt und langweilig aber einfach funtionierend sein wird. Will man aber später ein Upgrade an Funktionstiefe, dann ja werden ggf neue KNX-Komponenten notwendig.

[Dampf]

Ich kann mich den Ausführungen von gbglace nur anschließen.
Hinzufügend … Wenn du eine Hausatomations-SW, wie HA, iOB und und und, betreiben würdest, bräuchtest du die SonnenAUF/UNTERgangs-Sonnenstandsberechnung von Hue nicht mehr, da diese das genauso beherrschen. Aus der Hue Bridge würdest du es aller Wahrscheinlichkeit nach sowieso nicht rausbekommen, da die API, soweit mit bekannt, nur Geräte und Szenen aber keine solchen Funktionen rausrückt.
Mit so einer Hausautomations-SW wärst du, wie bereits erwähnt, früher oder später gezwungen Updates zu machen und weißt nie was für Überraschungen diese bereithalten(außer du liest alle Release Notes penibel durch).
Ein paar Bespiele aus 1,5 Jahren Home Assistant Produktivbetrieb mit IoT Ware: Durch Änderungen komplette Heizungssteuerung zerschossen, YAML-Befehle für Sprachausgabe(TTS) gänzlich geändert, Probleme mit der Wiedergabe mehrere RTSP Streams(seit kurzem wird immer nur einer Live angezeigt, die anderen währenddessen gestoppt). Da wird einem nie langweilig, besonders nicht Sonntag abends …
Kurz gesagt: Ich bin froh wenn mein KNX endlich steht und ich mich nicht immer wieder mit solchem Mist rumschlagen muss.

[ewfwd]

Aus der Hue Bridge würdest du es aller Wahrscheinlichkeit nach sowieso nicht rausbekommen, da die API, soweit mit bekannt, nur Geräte und Szenen aber keine solchen Funktionen rausrückt.

Also ich habe eine Hue Fernbedienung und steuere damit Licht und Rolladen in KNX (mittels HA). Das geht schon, einziger Haken dabei ist die HUE Bridge sendet pro Gerät den Status maximal 1mal die Sekunde. Sprich es kann bis zu einer Sekunde Verzögerung kommen.
Würde man die Hue Fernbedienung an eine seperate Zigbee Bridge koppeln fällt das aber weg.

Für Zeitschaltuhren kann man aber auch in KNX bleiben. Bei Rolladen kommt aber schnell mal der Wunsch auf dass auch der Anwender das einfach verstellen kann, da ist man dann in der Regel bei einer Visu wie Gira X1 usw. Wobei ich hier KEINE Kaufempfehlung für den X1 aussprechen möchte da ich ihn überteuert finde und Gira das Produkt auch nicht ordentlich pflegt...

Die Jalousien in unserer Wohnung werden über einen EIB Instabus angesteuert (von Siemens, vor ca. 23 Jahren installiert)
Dazu gibt es eine 2-Kanal-Schaltuhr, an der ich für 2 Gruppen von Jalousien die Öffnungs-und Schließzeiten einstellen kann, für jeden Wochentag einzeln.

Das ist alles recht schön, da sich aber übers Jahr die Sonnenauf- und -untergangszeiten ändern muss ich regelmäßig diese Schaltzeiten per Hand an der Uhr ändern.
Geht, ist aber unbequem.

Einfachste Abhilfe wäre wohl die Schaltuhr durch eine "astronomische" zu ersetzen die die Auf- und Untergangszeiten automatisch berücksichtigt.

Noch lieber aber wäre mir wenn ich die Zeiten per PC oder App einstellen könnte......

Wenn du nur Astro brauchst gibt es von MDT zB eine einfache ZSU. Brauchst aber ETS Kenntnisse und die Software mit Lizenz um das in Betrieb zu nehmen.
Wenn du ne Visu noch on Top brauchst und nicht basteln willst mit Home Assistant usw. sondern etwas nativ in KNX suchst mit App und alles wirste schon bisschen was investieren müssen.

Wobei bei solchen alten Geräten auch die Frage ist ob man da nichtmal das System aktualisiert.

[knxkhx]

Aber ansonsten sich das ISE HUE GW anschauen ob da so etwas in der Applikation vorgesehen ist.

Das ISE HUE GW kann nur HUE-Leuchtmittel/Lampen steuern, ein "Durchreichen" von sonstigen Datenpunkten der HUE-Bridge auf den KNX-Bus ist nicht vorgesehen. Wenn man tatsächlich über die Zeitschaltfunktionen der HUE Werte auf den KNX-Bus bekommen möchte, kann man das folglich nur über "Fake"-Leuchtmittel machen: Eine Automatisierung schaltet bei Sonnenaufgang / Sonnenuntergang ein "Fake"-Leuchtmittel auf einen bestimmten Wert, der dann die Jalousien steuert. Voraussetzung dafür: GW und ETS-Parametrisierung. Kein wirklich sinnvoller Weg mE. Da empfiehlt sich doch eher eine KNX-native Lösung, die zwar auch ETS und Parametrisierung voraussetzt, aber kostengünstiger als das HUE GW ist.

[algo2]

Ungeachtet dessen das sicherlich das Grundsystem mal angeschaut werden soll, hier mal meine Konstellation.

Ich habe einen Eibport und ein AppModule mit der Hue app.
Ich kann also hierrüber alles was Zigbee ist steuern und auslesen!! und somit auch Schalten, Zeitschaltuhren anlegen oder in irgendwelchen Abhängigkeiten hier Schalten.

Was die Rollos betrifft, habe ich hierfür eine MDT Wetterstation, welche mir die Helligkeitswerte liefert. Den Sonnenstand lese ich direkt aus dem Eibport aus. Somit liegen alle Variablen vor, die benötigt werden um Rollo´s in Abhängigkeit von Helligkeit, Temperatur und dem tatsächlichen Sonnenstand!!! zu steuern.
Ich habe seid Jahren keine Zeiten an den Rollo´s eingestellt, da diese komplett autark fahren. Wenn ich zu Hause bin, ist es sogar so gelöst, das dann OHNE irgend einen Tastendruck, die autom. Beschattung deaktiviert wird, da ich ja zu Hause bin und dies selber Regel.

Parallel kann dies dann auch für die Abwesenheitssimmulation genutzt werden.

[Hightech]

Ja, in diese Richtung (HUE von KNX oder am KNX-Bus hängender Logikengine wie bei Dir Eibport steuern) gibt es für nahezu jede Logikmaschine Anbindungen. Der TE will es aber genau anders herum und da hilft die Richtung KNX -> HUE nicht wirklich.

[ewfwd]

Parallel kann dies dann auch für die Abwesenheitssimmulation genutzt werden.

Du meinst Anwesendheitssimulation. Du willlst ja simulieren dass du da bist obwohl du es nicht bist und nicht simulieren dass du abwesend bist obwohl du zuhause bist. Abwesendheitssimulation braucht man nur wenn die Schwiegermutter vor der Tür steht

Ich habe seid Jahren keine Zeiten an den Rollo´s eingestellt, da diese komplett autark fahren.

In Schlafräumen habe ich es abgekoppelt.Sonst gehen die Rolladen im Sommer schon um 4 hoch. Das ist zumindest nicht für jeden was.

[knxkhx]

Der TE will es aber genau anders herum und da hilft die Richtung KNX -> HUE nicht wirklich.

Das stimmt. Dazu hatte ich ja oben was geschrieben. Der TE geht hier aber von falschen Voraussetzungen aus.

Ich habe ein HUE-Gateway mit dem ich einige Lampen/Steckdosen schalte, und da kann man sehr schön Schaltprogramme anlegen die z. B. als Triggerpunkt "Sonnenaufgang" haben (damit wird aktuell die Adventsillumination gesteuert....)

Jetzt würd ich es super finden wenn ich solche "Schaltimpulse" des HUE-Systems durch ein wie auch immer geartetes Interface an das KNX-System senden und damit die Jalousie steuern könnte.

Die Hue-Bridge kann diese "Schaltimpulse" nicht nach draußen auf "ein wie auch immer geartetes Interface" an den KNX-Bus senden. Die Automatisierungen funktionieren nur innerhalb des HUE-Systems. Wenn man sie über "ein wie auch immer geartetes Interface" an den KNX-Bus senden möchte, dann besteht mit dem ISE HUE GW eine Möglichkeit dazu, wenn man hierzu "Fake"-Leuchtmittel nutzt. Dafür müsste man dann ~ 300 EUR für das GW investieren und damit stellt sich die berechtigte Frage: Warum dazu nicht direkt eine KNX-ZSU nutzen, wenn es allein um die Astrofunktion geht? Dafür bezahlt man z.B. für ein MDT SCN-RTC20.02 ~ 150 EUR und hat eine KNX-Nichtbastellösung für die vom TE beschriebene Aufgabe.

[ewfwd]

Warum dazu nicht direkt eine KNX-ZSU nutzen, wenn es allein um die Astrofunktion geht? Dafür bezahlt man z.B. für ein MDT SCN-RTC20.02 ~ 150 EUR und hat eine KNX-Nichtbastellösung für die vom TE beschriebene Aufgabe.

Wobei du dann wirklich nur eine ZSU mit KNX Schnittstelle bekommst die ausschließlich über die ETS zu Parametrieren ist. Diese Funktion bekommt man bei ner Visu oftmals "gratis" nebenher und kann es dann über die Visu selbst noch bequem einstellen.
Komfortabel würde es sein wenn sie dem Teil ne Netzwerkschnittstelle verpasst hätten und dann zumindest ne simple App/Webinterface.

[knxkhx]

Wobei du dann wirklich nur eine ZSU mit KNX Schnittstelle bekommst die ausschließlich über die ETS zu Parametrieren ist.

Um die ETS kommt man auch beim ISE GW nicht herum.

Diese Funktion bekommt man bei ner Visu oftmals "gratis" nebenher und kann es dann über die Visu selbst noch bequem einstellen.

Klar. Aber wenn es allein um die Astrofunktion geht, dann ist eine Visu mit entsprechendem Server vlt. etwas zu groß geschossen.

Komfortabel würde es sein wenn sie dem Teil ne Netzwerkschnittstelle verpasst hätten und dann zumindest ne simple App/Webinterface.

Klar. Wäre fein, aber dann auch entsprechend teurer. - Unterm Strich bleibt mE: Der Weg von HUE-Automatisierungen zu KNX, wie vom TE angedacht, ist steinig und nicht wirklich sinnvoll umsetzbar.