UMFRAGE: Welche Leistungsmerkmale ab V4

[starwarsfan]

Hallo miteinander

Wäre halt auch alles einfacher, wenn Velux nicht solche Sonderlocken bauen würde

ACK!
Ist mir damals beim Bau noch gerade rechtzeitig aufgefallen und daher sind wir jetzt glückliche Roto-Kunden

<off-topic>
Das was Velux da veranstaltet ist unterirdisch! Drüben im KNX-UF gibt's dazu auch viele Diskussionen, immer wieder erstaunlich. Man kann sich echt nur drüber wundern und die Bauherren rechtzeitig genug darauf hinweisen, dass "Smarthome" und "Velux" nicht wirklich sinnvoll zusammen existieren können.
Somfy hatte (oder hat?) auch so eine Tendenz, dort kann man aber zum Glück einfach auf Festverkabelung bestehen und das Thema ist erledigt.
<off-topic-ende>

[StefanW]

Hi Parsley,

Auch mir fehlt bekannter maßen eine "Visu-auf-Knopfdruck". In wie fern wäre die von Elabnet bereits (teilweise?) entwickelte Instant-Visu denn "light" im Vergleich zur CV?
- (Noch) leichter zu erzeugen? (=> gut)

Die damalige Implementierung der Instant Visu, die wir auf der L&B 2018 gezeigt hatten, war extrem einfach zu erzeugen. Nur zwei Angaben (Ort & Typ) zu einem Datenpunkt und er war in der Visu enthalten

- Keine freie Anpassung der Darstellung/Farben/Formen/...? (=> gut. Hauptsache die Darstellung ist massenkompatibel. Bestes (Positiv-)Beispiel einer solchen Visu ist wohl Loxone)

Tja, wenn mir dann mal jemand die Loxone Visu zeigen würde und wie man das so einfach einstellt.

Wir haben zwar eine Loxone Testinstallation hier, aber ich finde keine Zeit mich darin einzuarbeiten. Ich hatte gehofft, dass einer der Loxone Besitzer mir einfach mal eine kurze Führung per Teams gibt....

- Weniger visualisierbare Funktionen? (Beispiel: nur Licht schalten/dimmen und Beschattung auf/ab, aber kein HVAC, RGBW, Diagramme,...? => schlecht Im Bezug auf ein KNX-System ist auch hierfür das beste (Negativ-)Beispiel... *drumroll* Loxone )

Auch das würde mich im Detail interessieren, was die hochgelobte Loxone Visu denn dann nicht kann

Intern habt ihr doch zu diesem Thema bestimmt schon eine tabellarischen Gegeüberstellung von I-V und CV, oder?

Nicht so direkt in einer Weise, die öffentlich darstellbar ist.


lg

Stefan

[tiagra]

Hallo zusammen,

komplett grün und trotzdem Träume

1. Energiemanagement
2. CarCloud
3. Integration ioHomecontrol

Ich kann das Problem mit ioHomecontrol und damit Somf/Velux nur unterschreiben: Somfy ist eigentlich noch viel schlimmer am der Stelle, weil sie einen auf Gedeih und Verderb in ihre Welt zwingen wollen und offenbar aus politischen Gründen die KNX-Welt ignorieren. Ach, ja eigentlich noch schlimmer: Sie werben mit voller KNX-Integration und ihrer Tahoma-Bridge und am Ende stellt sich heraus, dass sie da eigentlich nur einen richtig dicken Mittelfinger für alle nicht-Somfy-User implementiert haben: Sie unterstützen ausschließlich KNX nach Somfy, aber nicht andersrum. Kurz: Alle (und das sind viele) krücken jetzt mit einem KLF200 rum, wofür sie irgendwo wild und un-wart-bar einen PI hindengeln um via iobroker oder Nodered oder HASS ihre Rolläden endlich auf die Glastaster zu mappen. RIESEN Aufriss um die erzwungene Cloud zu vermeiden. Rolladen ohne Internet steuern wollen? Absurd, wer könnte denn soetwas wollen?

Nun haben wir einen TWS, und wieder fangen wir mit ioBroker an, brauchen das KLF200 usw. Ein großer Schritt wäre die native Integration des KLF, was sicherlich eher wenig Budget braucht, denn das ist auf Github x-fach zu finden. Etwas mehr Budget wäre vermutlich die Integration von ioHomecontrol als Protokoll samt Einbindung eines simplen 800Mhz USB-Sticks zur Kommunikation. Für c# findet man so eine Implementierung auf Anhieb, auf dem ise Programmble hat das auch jemand verwendet, aber am Ende... Wer will schon c# und ein device kaufen was so viel kostet wie der TWS aber nur 10% davon kann UND absolut nur für Obernerds überhaupt brauchbar ist. Da Somfy und Velux mittlerweile einen echt großen Teil des Marktes abdecken, wäre die native ioHomecontrol-Variante sicherlich das Optimum - am Ende geht es hier ja nicht nur um (m)ein Problem mit ein paar Rolladen, iohomecontrol ist zu einem Ökosystem erwachsen, welches von Somfy (und anderen) dazu verwendet wird, jedem Eigenheimbesitzer in ihre Cloud zu zwingen. Nicht nett, absolut überflüssig und die ganzen Krücken aus der Misere sind allesamt maximal Nerd-kompatibel.

Ich werde es mir ans Bein binden, aber am Ende ist der TWS für mich der Versuch, ein Haus aus der 'kann nur Papa mit um' - Ecke zu holen. Alle Hacks und Basteleien absägen, potentiell wartbar und kontrollierbar für andere ausser mich selbst. Allein die Tatsache dass ich Somfy im Hausbauvertrag übersehen habe kostet mich Nerven, aber das Gehacke zur Lösung des Problems (Rolladen über KNX steuern), welches 100% gegen o.g. Konzept geht, lässt mich ernsthaft sauer werden. Liest man so die Foren, bin ich absolut keine Ausnahme

Danke für's Zuhören!

[StefanW]

Hallo Tiagra,

herzlich willkommen hier im Forum und willkommen im Rudel und danke für Deinen Beitrag. Wir hören gerne zu, weil dafür ist das Forum da.

Ich kann das Problem mit ioHomecontrol und damit Somf/Velux nur unterschreiben: Somfy ist eigentlich noch viel schlimmer am der Stelle, weil sie einen auf Gedeih und Verderb in ihre Welt zwingen wollen und offenbar aus politischen Gründen die KNX-Welt ignorieren.

Über die Gründe kann man nur spekulieren, leider sehen die Hersteller die jeweilig anderen Kommunikationssysteme als "Konkurrenz" in der irrigen Annahme, mit dem eigenen System könnte man die Herausforderungen eines Smarthomes wirklich abdecken.

Leider verstehen ganz viele Hersteller "Smarthome" auch falsch (oder wollen falsch verstehen) und meinen, wenn sie irgendeine Form von Fernsteuerung (App, Handfernbedienung, Alexa-Integration) mitliefern, dass dies dann smart wäre. Als wenn es wirklich sinnhaft wäre, die zwei Dutzend Rollläden, Raffstore, Rollos usw. mehrmals am Tag über eine App von Hand zu steuern.

Erst die Integration aller Gewerke mit dem Regelwerk des Kunden das zu automatischen Funktionen führt, macht ein Haus smart. Damit wäre Zusammenarbeit angesagt, damit die Kunden das am Besten miteinander verbinden können, als diese abwehrenden Maßnahmen.

Kurz: Alle (und das sind viele) krücken jetzt mit einem KLF200 rum, wofür sie irgendwo wild und un-wart-bar einen PI hindengeln um via iobroker oder Nodered oder HASS ihre Rolläden endlich auf die Glastaster zu mappen. RIESEN Aufriss um die erzwungene Cloud zu vermeiden. Rolladen ohne Internet steuern wollen? Absurd, wer könnte denn soetwas wollen?

Kennst Du Stückzahlen?

Nun haben wir einen TWS, und wieder fangen wir mit ioBroker an, brauchen das KLF200 usw. Ein großer Schritt wäre die native Integration des KLF, was sicherlich eher wenig Budget braucht, denn das ist auf Github x-fach zu finden.

So einfach ist es nicht. Für die KLF-Ansteuerung habe ich das nicht geprüft, aber das meiste auf Github ist für uns nicht brauchbar (nicht stabil genug, oftmals zu ressourcenintensiv, schlecht dokumentiert). Außerdem liegt der größte Aufwand nicht in der Ausführung eines Protokolls, sondern in der grafischen Benutzeroberfläche und im Support (letzteres ist besonders kritisch).

Etwas mehr Budget wäre vermutlich die Integration von ioHomecontrol als Protokoll samt Einbindung eines simplen 800Mhz USB-Sticks zur Kommunikation.

Unsere Server sind für eine Lebensdauer von 15 Jahren ausgelegt. Da ist gar nichts simpel, schon gar nicht ein Stick für irgendwas, der von dessen Hersteller weder über solche Zeiträume hergestellt nicht supportet wird. Weil wenn es alle paar Jahre einen neuen Stick für xyz gibt, dann erwarten die Nutzer mit größter Selbstverständlichkeit, dass diese dann auch funktionieren. Und schon fangen wir wieder mit Tests usw. an.

Wir sind mit der Unterstützung und direkten Einbindung fremder Hardware schon häufig auf die Nase gefallen. Weil wenn was nicht funktioniert, schlagen die Nutzer bei uns auf. Deshalb müssen wir uns das immer genau ansehen, wie man das auf Dauer finanziert.

Wir sind aber nicht völlig abgeneigt. Derzeit testen wir die Integration von ZigBee und auch hier wird ein Stick verwendet und wir prüfen, wie wir das insgesamt umsetzen und auf Dauer darstellbar halten können.

Da Somfy und Velux mittlerweile einen echt großen Teil des Marktes abdecken, wäre die native ioHomecontrol-Variante sicherlich das Optimum - am Ende geht es hier ja nicht nur um (m)ein Problem mit ein paar Rolladen, iohomecontrol ist zu einem Ökosystem erwachsen, welches von Somfy (und anderen) dazu verwendet wird, jedem Eigenheimbesitzer in ihre Cloud zu zwingen. Nicht nett, absolut überflüssig und die ganzen Krücken aus der Misere sind allesamt maximal Nerd-kompatibel.

Wir werden uns das Thema Somfy & Co. sicherlich noch näher ansehen. Weil wenn es hier große Schmerzen gibt bei den Nutzern, dann wollen wir gerne eine Lösung bieten.

Ich werde es mir ans Bein binden, aber am Ende ist der TWS für mich der Versuch, ein Haus aus der 'kann nur Papa mit um' - Ecke zu holen. Alle Hacks und Basteleien absägen, potentiell wartbar und kontrollierbar für andere ausser mich selbst.

Danke dafür, das ist der Punkt, für den wir den Timberwolf Server eigentlich geschaffen haben und was wir ausbauen wollen. Alles muss einfach sein, dokumentiert, mit einkaufbarem Hersteller-Support.

Danke für's Zuhören!

Bitte gerne, danke für Deinen Beitrag

lg

Stefan

[tiagra]

Hallo Stefan,

Danke für die ausführliche Antwort...

Zahlen zur KLF-Nutzung habe ich natürlich keine und am Ende muss man wohl auch sagen, dass es sich dabei sowieso nur um einen Bruchteil der Nutzer handelt, die sich so weit aus dem Fenster lehnen und dann auf einer offiziell nicht dokumentierten Service-Schnittstelle den Ausbruch aus der Cloud wagen. Stichwort: Nerd-kompatibel.

Weitaus besser greifbar ist an der Stelle sicher allgemein der Marktanteil von devices die sich hinter ioHomecontrol und eigenen Clouds verschanzen, denn das ist mittlerweile beträchtlich mit 100%iger-KNX-Inkompatibilität. Meine Nachfragen bei diversen Spezialisten in der Branche dazu ergab, dass das Thema für den Kunden schlicht ignoriert wird. Man wirft ihm die Somfy Fernbedienung auf dem Tisch, gratuliert zum 25 kEUR Gira-Smarthome und schleicht sich davon. Integration = Null. Frech...

Die Sache mit dem Stick ist vermutlich sogar am Ende der sinnvollere Weg, weil wir es hier zumindest potentiell mit dokumentierte Schnittstelle nach irgendeinem Standard zu tun haben. Gerne versteckt sich dahinter ja nur irgendein Serial device auf welchem man schreiben/lesen kann und alles andere ist eine Ebene drunter in der Protokollimplementierung verwurstet - wenn ihr schon mit Zigbee am Start seid, steckt ihr da ja schon mitten drin

Ich bin gespannt wohin die Reise geht - wir ziehen hoffentlich zum Ende des Sommers ein, bis dahin werde ich das KLF ersteinmal an den Start bringen, dann schauen wir mal wie es bei Euch läuft

Grundsätzlich bin ich ersteinmal höchst erfreut das Produkt und Eure Philosophie gefunden zu haben, denn genau dahin muss die Reise gehen, wir haben schon viel zu viel Wildwuchs und Bastelei in diesem Feld. Das ist im übrigen auch der Grund, warum ich das Energiemanagement gewählt habe: Hier ist der Markt an fertigen Sachen noch sehr überschaubar und auch hier versuchen die Hersteller sich abzukapseln um den Kunden konplett mit eigenen Devices einzuwickeln. Lobenswert ist hier max. die Kooperation von Victron und Fronius, wobei das leider auch nur wenige "Spezialisten" überhaupt anbieten, denn 3 Kisten fix beim Kunden zusammenzustecken und auf den DHCP zu hoffen ist für die allermeisten Solarteure schon das höchste der Gefühle. Energiewende sieht definitiv anders aus - im Moment sehe ich auf dem Markt hauptsächlich Faustkeile bei der Arbeit. Fördermittel irgendwie in Hardware verwandelt und den ganzen Rest, der es eigentlich erst sinnvoll machen könnte, komplett stiefmütterlich abgefackelt: Energiemanagement nämlich.

In diesem Sinn, auf in den Kampf

.martin

[StefanW]

Hallo Martin,

Danke für die ausführliche Antwort...

Gerne, wir wollen ja gute Lösungen finden, dafür müssen wir eben auch miteinander reden

Zahlen zur KLF-Nutzung habe ich natürlich keine und am Ende muss man wohl auch sagen, dass es sich dabei sowieso nur um einen Bruchteil der Nutzer handelt, die sich so weit aus dem Fenster lehnen und dann auf einer offiziell nicht dokumentierten Service-Schnittstelle den Ausbruch aus der Cloud wagen.

Ja, das ist wohl der Punkt. Das Thema lokale Velux-Ansteuerung ist uns zwar lange bekannt (auch früher schon aus dem KNXUF), aber insgesamt ist die Frequenz der Anfragen schon sehr niedrig, sei es hier im Forum, bei Beratungsgesprächen usw.

Eines unserer nächsten Vorhaben ist die (abschaltbare) Anbindung an IFTTT. Über diese Supercloud sind 650+ Hersteller erreichbar und damit wohl auch Somfy. Wie gut das funktioniert und was damit möglich ist, kann ich aus dem Stand nicht sagen. Alle Puristen, die ausschließlich lokal gesteuerte Integrationen akzeptieren, werden hier ohnehin aufschreien. Dafür ist diese Integration einfach. Insgesamt ist das eine frustrierende Entwicklung, weil eigentlich wollen viele von uns so wichtige Dinge wie Beschattung nicht über drei Clouds ansteuern, nur weil die lokale Integration anstrengend ist.

Aber ich fürchte, die meisten werden am Ende nicht bereit sein, den Aufpreis für lokale Integration zu tragen. Worauf ich hinaus will, ist, dass ich befürchte, dass mit der Anbindung an IFTTT und damit auch an Somfy, dieser Weg für 85% der Nutzer (wenn nicht noch mehr) womöglich durchaus akzeptabel ist. Weil sonst wären alle die Anbieter von Cloud integrierten Produkten am Ende nicht so erfolgreich. Denn Cloud bedeutet immer auch "App" und wenn es für etwas eine "App" gibt, dann löst das offenbar ein "haben will" aus bei vielen. Auch wenn es ziemlich fraglich ist, wielange die App am Ende funktionieren wird.... Für mich persönlich wäre es inakzeptabel, dass man erst über fünf Apps rutschen muss, um das Haus bei Sonnenuntergang für die Nachtstunden zu konfigurieren.

Ich kann Dir anbieten, dass ich zu Somfy / KLF bei Gelegenheit eine separate Umfrage mache, dann sehen wir weiter.

Weitaus besser greifbar ist an der Stelle sicher allgemein der Marktanteil von devices die sich hinter ioHomecontrol und eigenen Clouds verschanzen, denn das ist mittlerweile beträchtlich mit 100%iger-KNX-Inkompatibilität.

Meine Nachfragen bei diversen Spezialisten in der Branche dazu ergab, dass das Thema für den Kunden schlicht ignoriert wird. Man wirft ihm die Somfy Fernbedienung auf dem Tisch, gratuliert zum 25 kEUR Gira-Smarthome und schleicht sich davon. Integration = Null. Frech...

Das ist der normative Charakter des Faktischen. Die Unternehmen sind an einer richtigen gleichberechtigten Integration nicht interessiert, sondern wollen Ihr eigenes System durchsetzen. Den Integratoren fehlen damit die Möglichkeiten und für Basteleien fehlt den Integratoren teils das Wissen (wobei es schon sehr fähige gibt) bzw. müssten Sie dann den laufenden Support- und Wartungsaufwand einer RasPi-Lösung selbst tragen, das geht kommerziell nicht.

Die Sache mit dem Stick ist vermutlich sogar am Ende der sinnvollere Weg, weil wir es hier zumindest potentiell mit dokumentierte Schnittstelle nach irgendeinem Standard zu tun haben. Gerne versteckt sich dahinter ja nur irgendein Serial device auf welchem man schreiben/lesen kann und alles andere ist eine Ebene drunter in der Protokollimplementierung verwurstet - wenn ihr schon mit Zigbee am Start seid, steckt ihr da ja schon mitten drin

So einfach ist es dann doch nicht.

Ein Ausflug in die Realität: Manche unserer Kunden nutzen Leseköpfe für ihre smarten Zähler zum Auslesen, manchmal auch für mehrere Zähler. Bei zwei Kunden ging das schief, weil die zweite USB-Schnittstelle wurde nicht erkannt. Kunden machen Tickets bei uns auf und irgendwann landet es dann beim 3rd Level, den Entwicklern. Dort wird dann festgestellt, dass der Hersteller wohl für eine Charge der USB-Seriell-Sticks vergessen hatte, die USB-Daten im Stick zur korrekten Erkennung der Devices bei der Produktion zu flashen und daher wurden diese nicht erkannt und zugeordnet. So ein Service ist für die Kunden zwar toll und daher sieht das alles schmerzlos aus, wenn ElabNET es dann schon irgendwie repariert, aber vom Aufwand her mussten wir anschließend 7 Server verkaufen, um nichts zu verdienen.

Wenn ich mir nun vorstelle, wir sollen fremde Sticks unterstützen, über eine Laufzeit vom 15 Jahren, dann kann ich mir ausrechnen, wie das für uns laufen würde. Folgendes Szenario: Beim Kunden sind - zur Nacht - alle Rollos usw. per Funkkomando runter gefahren und danach geht der Stick kaputt. Das Haus wurde mittlerweile verkauft und Fernbedienungen für eine Handbedienung sind nicht mehr da. Der Käufer meldet sich beim Timberwolf Service mit einer gewissen Erwartungshaltung. Sagen wir nun "der fremde Stick geht uns nichts an", dann bekommen wir schnell einen Shitstorm in einem Forum (nicht wenige Kunden sind mit entsprechenden Drohungen übrigens schnell zur Hand). Aber wie sollen wir das nun lösen? Den Stick gibt es nicht mehr, der neue hat eine andere Firmware mit anderer API. Wer zahlt uns am Ende den Support für eine Hardware, die nicht mal von uns stammt?

Oder ein anderes Szenario. Nehmen wir an, wir haben da eine erfolgreiche Implementierung mit ioHomecontrol und hunderte Server mit solchen Sticks sind im Einsatz. Eines Tages nehmen wir ein wichtiges Kernel-Update vor und es knirscht bei der USB Erkennung und nun muss schnell eine Lösung her. Da kämen wir gar nicht aus, das würde selbstverständlich verlangt werden. Auch hier die Frage, wer zahlt uns das?

Oder anderes Szenario: Es gibt neuerdings Funktionsstörungen in einer Anlage, hin und wieder fahren die Rollos nicht. Der Kunde meldet Probleme und meint, der Server wäre "sicher" Schuld, weil da gab es doch erst letztens ein Update (bei uns ist alle vier bis sechs Wochen ein Update verfügbar, das Argument "zieht" also immer). Und schon sind wir wieder dabei. Am Ende handelte es sich um lokale Funkstörungen, weil der Kunde einen neuen Drehsteller verbaut hat im Keller, was sich aus der Ferne alles nur schwer diagnostizieren lässt (das Theme mit dem Drehsteller hatten wir übrigens schon in Verbindung mit leitungsgebundener Technologie). Auch hier, hohe Kosten, bedingt durch fremde Technik, die nicht von uns verkauft wurde.

Dadurch, dass der Timberwolf Server vieles so einfach macht, kann sich der Kunde oft den Integrator für die Einrichtung sparen. Aber damit hat er niemanden für die Fehlersuche und hängt sich deshalb an uns. Das ist nur nicht eingepreist.

Wir müssen daher bei allem was wir weiteres an Technologieunterstützung in den Timberwolf Server implementieren als erstes darauf hin untersuchen, welches negative Potential diese auf den künftigen Supportaufwand hat. Alles was auch nur danach riecht, dass dies zu einem erhöhten Aufkommen führen könnte, das die Rate von mehr als 0,5 Servicefälle pro Tag pro tausend Wölfe steigert, ist nicht machbar.

Ich bin gespannt wohin die Reise geht - wir ziehen hoffentlich zum Ende des Sommers ein, bis dahin werde ich das KLF ersteinmal an den Start bringen, dann schauen wir mal wie es bei Euch läuft

Wir werden uns das Thema sicher ansehen und sehen uns nun erstmal die Erfahrungen mit ZigBee an. Dann sehen wir weiter.

Grundsätzlich bin ich ersteinmal höchst erfreut das Produkt und Eure Philosophie gefunden zu haben, denn genau dahin muss die Reise gehen, wir haben schon viel zu viel Wildwuchs und Bastelei in diesem Feld.

Ja, sehen wir auch so. Danke sehr für die Bestätigung.

Das ist im übrigen auch der Grund, warum ich das Energiemanagement gewählt habe: Hier ist der Markt an fertigen Sachen noch sehr überschaubar und auch hier versuchen die Hersteller sich abzukapseln um den Kunden konplett mit eigenen Devices einzuwickeln.

Ja, haben wir auch so beobachtet. Die Auswahl ist damit immer eingeschränkt.

Lobenswert ist hier max. die Kooperation von Victron und Fronius, wobei das leider auch nur wenige "Spezialisten" überhaupt anbieten, denn 3 Kisten fix beim Kunden zusammenzustecken und auf den DHCP zu hoffen ist für die allermeisten Solarteure schon das höchste der Gefühle.

Nun ja, woher sollen die fortgeschritteneren IT Kenntnisse auch kommen, das kann man so nicht erwarten.

Energiewende sieht definitiv anders aus - im Moment sehe ich auf dem Markt hauptsächlich Faustkeile bei der Arbeit. Fördermittel irgendwie in Hardware verwandelt und den ganzen Rest, der es eigentlich erst sinnvoll machen könnte, komplett stiefmütterlich abgefackelt: Energiemanagement nämlich. In diesem Sinn, auf in den Kampf

Wir bemühen uns


lg

Stefan

[speckenbuettel]

Hallo,

ich bin neu hier im Forum und habe meinen Timberwolf erst seit zwei Wochen. Mangels Erfahrung halten sich auch meine Wünsche in Grenzen, einen hätte ich aber: eine EnOcean-Schnittstelle und eine möglichst nahtlose Integration von EnOcean, idealerweise so wie mit KNX bereits umgesetzt.

Der Hintergrund: ich fange gerade an, unser Haus (mit konventioneller Elektroinstallation) "smart" zu machen. Während ich für Neubauten und größere Umbauten auf jeden Fall auf KNX setzen würde und das auch in unserem Haus überall dort tue, wo der Aufwand (neue Leitungen verlegen) vertretbar ist, sehe gerade bei der Nachrüstung viele Vorteile bei der EnOncean-Funktechnologie. Die Produktpalette ist größer als die für KNX-RF-Produkte und die Idee des "Energy Harvesting" der meisten EnOcean-Sensoren passt besser in unsere Zeit als batteriebetriebene Funksensoren.

Ich habe den TWS vor einigen Wochen als Herzstück (oder besser gesagt als Gehirn) für unser Haus gekauft, vor allem weil ich viele 1-Wire-Sensoren einbinden möchte. Aber leider fehlt eine ausgereifte Schnittstelle zu EnOcean.
Der TWS hat für mich auch nur ganz knapp das Rennen gegen einen Server aus Dortmund (ich weiß nicht ob ich Firma und Modell hier nennen darf) gemacht, der EnOcean schon von Haus aus integriert und ähnlich gut mit KNX verknüpft wie es der TWS mit den schon eingebauten Technologien macht.

Natürlich kann man KNX und EnOcean auch über viele andere Gateways miteinander verknüpfen, aber wirklich robust und zuverlässig wäre das m. E. mit einer eigenen EnOcean-Antenne im TWS und einer entsprechenden softwareseitigen Umsetzung.
Die Antenne sollte dann natürlich extern und mit einigen Metern Leitung geliefert werden damit man sie außerhalb des Verteilerschranks möglichst zentral im Haus platzieren kann.

Von den in der Umfrage genannten Themen habe ich einige ausgewählt die ich wahrscheinlich in Zukunft nutzen würde, aber EnOcean hat aus meiner Sicht ganz klar Priorität Nr. 1.

Vielen Dank und viele Grüße
Falk

[gbglace]

Hi,

willkommen im Forum.

Natürlich kann man KNX und EnOcean auch über viele andere Gateways miteinander verknüpfen, aber wirklich robust und zuverlässig wäre das m. E. mit einer eigenen EnOcean-Antenne im TWS und einer entsprechenden softwareseitigen Umsetzung.
Die Antenne sollte dann natürlich extern und mit einigen Metern Leitung geliefert werden damit man sie außerhalb des Verteilerschranks möglichst zentral im Haus platzieren kann.

Egal wie groß die Antenne da sein wird ein modernes EFH mit Betondecken wirst da maximal auf einer Etage vernünftig mit abdecken können. Die Weinzierl-GW für die UP-Dose am KNX-Bus sind da schon die deutlich stabilere Variante.

Ich glaube mich gar recht zu erinnern, das BAB-Tec die Variante Ihres Servers mit integrierter ENOCEAN-Schnittstelle aus dem Sortiment genommen haben, eben weil der Verteilerschrank kein optimaler Ort ist und auch ein HWR danach nicht weiter. Inwieweit das Signal überhaupt Sinnvoll über CU auf eine externe Antenne transportiert werden kann, kann ich nicht beurteilen.

Ansonsten ja bei Nachrüstungen / Sanierungen kann dann ENOCEAN eine interessante Ergänzung sein. Allerdings fehlt es da auch noch an Auswahl bei Heizungsthermostaten. Taster und Fenster/Türkontakte sind da erstmal die wesentlichen Anwendungen, weil das da mit dem Energy-Harvesting gut funktioniert. Wobei ich letztlich auch mal was von so kleinen Piezoelementen gesehen habe, die aus T-Differenzen an Oberflächen elektrische Energie bereitstellen.

[speckenbuettel]

Hallo,

vielen Dank!

In einem modernen EFH hat man ja sinnvollerweise KNX gleich von Anfang an verbaut und muss nicht mit Funklösungen nachrüsten

In meiner alten Hütte (Bj. 1936) funktioniert EnOcean sehr gut, ich habe schon seit Jahren hier und da ein paar Taster und Aktoren nachgerüstet. Auch über Stockwerke (Holz- oder Gipskartondecken) hinweg.
Viele Komponenten können ja auch als Repeater fungieren.

Vor ein paar Wochen, als ich vor der Entscheidung Timberwolf oder Eibport stand, hatte BAB-Tec den Server noch mit EnOcean im Programm, mit externer Antenne.

Bei den Weinzierl-Gateways sehe ich als Hauptnachteil deren Limitierung auf maximal 32 Kanäle. Wenn man viel mit EnOcean nachrüsten möchte dann braucht man schnell mehrere davon. Der Eibport kann unbegrenzt EnOcean-Telegramme empfangen und auf 125 Kanälen senden. Das sollte für ein normales EFH reichen.

Es gibt auch Heizkörperthermostate mit Energy Harvesting, z. B. von Micropelt. Die habe ich für unser Haus eingeplant - sobald ich die optimale Verknüpfung für KNX/EnOcean gefunden habe
Außerdem sehe ich großes Potenzial bei UP-Aktoren. Da gibt es deutlich mehr Auswahl (sogar Aktoren mit Strommessung) als für KNX RF.

Viele Grüße
Falk

[StefanW]

Hallo Falk,

wir haben - vor Jahren - das Thema EnOcean evaluiert, weil ein Konzern Interesse an einer Zusammenarbeit bekundet hatte.

Herausforderungen:

- Senden aus dem Schaltschrank kann eine Schwierigkeit darstellen, zumal diese sich oft an "ungünstigen" Orten (Technikkeller) befinden.

- Für große Gebäude (z.B. Hotels oder Büros) bräuchte man per IP abgesetzte Tranceiver-Module, die man in Dosen bzw. abgehängten Decken usw. installieren könnte.

- Der Konzern konnte sich damals nicht durchringen, Entwicklungskosten zu übernehmen, weil der Timberwolf Server gefällt zwar, aber man hätte halt gerne eine Lösung die nur einen Bruchteil kostet und eine einfache APP dazu und außerdem sieht man sich nicht in der Lage, dem eigenen Vertrieb die Fähigkeiten des TWS nahezubringen sowie dem eigenen Support die Unterstützung dafür.

Das ist auch, warum die meisten Hersteller auf eine cloudbasierte APP-Lösung für alles und jedes setzen, das mit nichts anderes Verbindung hat. Weil die damit mögliche Vereinfachung lässt sich gerade noch verkaufen und supporten.

Bei den Weinzierl-Gateways sehe ich als Hauptnachteil deren Limitierung auf maximal 32 Kanäle.

Dann nimm halt mehrere davon? Was spricht dagegen?

Außerdem sehe ich großes Potenzial bei UP-Aktoren. Da gibt es deutlich mehr Auswahl (sogar Aktoren mit Strommessung) als für KNX RF.

Ja, gibt es aber auch mit Zigbee und WLAN, mit erheblich größerer Verbreitung als EnOcean.


==> Grundsätzlich haben wir EnOcean auf unserer Roadmap für die nächsten Jahre. Aber es wird auch darauf ankommen, wie groß das Budget ist, dass uns die Kunden für Upgrades zur Verfügung stellen werden. Hierzu demnächst mehr Info.


lg


Stefan