Das Funkhaus kommt…

Einleitung

Das Erste für den Feind, das Zweite für den Freund und das Dritte für dich“. Der Wahrheitsgehalt dieses Spruchs, es geht übrigens um den Hausbau, wird mir immer wieder klar, wenn man “Veredelungspotential” an seinem Haus entdeckt, welches man im Prinzip auch direkt bei der Planung hätte berücksichtigen können. Mann kann dies auch weniger schmeichelhaft Planungslücken oder -fehler nennen. Man kann eben nicht an alles denken und Erfahrungen müssen auch erstmal gesammelt werden.

 

Zum Thema Automatisierung habe ich mich bereits lange vor der Bauplanung informiert. Ich habe gelesen, getestet und viel auf Vorrat eingeplant bzw. eingebaut. Speziell was das Thema Verkabelung betrifft habe ich selbiges kilometerweise verlegt und zum noch ausreichend Leerrohre einbauen lassen. Trotzdem, man (ich) mag es kaum glauben, fehlen Kabel, so dass ich mich zwangsläufig mit dem Thema Funk beschäftigen muss. Das konkrete Anwendungsszenario ist unser neues Deckensegel in der Küche, welches nur über ein NYM Kabel 3 adrig verfügt und über einen 0815 Wandschalter geschaltet wird. Da ist es dann schwierig ohne Funk mehrer Leuchten im Deckensegel unabhängig voneinander zu schalten.

Lösungsansätze

Nun gibt es im Bereich Funk eine Menge Standards und Hersteller. An vielen Stellen findet man Aufstellungen und Vergleiche der Standards, falls man diese überhaupt vergleichen kann. Ich habe für mich mit Vorsatz eine völlig subjektive Bewertung durchgeführt, welche sich am konkreten Anwendungsszenario, an Lust & Laune sowie an fremden und eigenen Erfahrungen festmacht. Rein technische Gegenüberstellungen finden sich an vielen Stellen im Internet. Hier oder Hier

 

Die folgende Tabelle stellt völlig Subjektiv ohne irgeneinen Anspruch auf Vollständigkeit meine Sicht auf die Dinge dar.

 

TechnologieKommentarPositivNegativEntscheidungskriterien
Z-Wave• International standardisiert
• Weit verbreitet.
• Verfügbarkeit von Open Source Tools (Github hat hier aktuell 299 repos mit dem Tag z-Wave)
• Sehr große Hersteller- und Produktbasis.
• Habe ich jetzt nicht so als die 1a Integration in z.B. KNX gesehen.
Bluetooth - Bluetooth low Energy (BLE)
ZigBee
Scheint mir irgendwie das Protokoll für die Massen zu sein. Siehe Philip Hue, etc.• Nicht geprüft.• Wiederholte schwere SicherheitslückenWer ein Protokoll so fahrlässig implementiert hat direkt am Start verloren. Link
W-LANIst auf den ersten Blick etwas "overdone" und ist in der Implementierung auch recht komplex da Sensoren und Aktoren an die Umgebung angepasst werden müssen.

Bekommt aber unter dem Lichte von Microcontrollern (z.B. ESP8266) eine neue Sichtweise. Dazu später in einem anderen Post aber mehr.
• Offener Standard
• Sicher (noch)
• Hohe Datenrate (Ist aber bei den Sensoren und Aktoren nicht notwendig)
• Wenige fertige Aktoren und Sensoren
• Komplexe Implementierung wg. WLAN Integration.
• Hier gibt es bestimmt auch Lösungen wo man die initiale Konfiguration auch über einen Web-Server machen kann aber trotzdem… Nein.
• Beim Wechsel der WLAN Technik (WPA2 ist irgendwann fällig) müssen die Sensoren und Aktoren angepasst werden.
Ist für mich kein primäres Protokoll. Kann in einigen Bereichen sinnvoll eingesetzt werden.
Dect
Ja, nee. Ist ja jetzt nicht so richtig zeitgemäß.
KNX-RF
Da ich perspektivisch gerne mehr in Richtung KNX gehen werde, wäre es nur konsequent hier KNX-RF einzusetzen.
• Kann mit der ETS konfiguriert werden, also kein Multi-Tools Landschaft.
• Wenige Geräte
• Kein klarer Standard: Hersteller kochen eigenes Süppchen trotz Standard
• Hager RF vs. MDT RF Link

Erstmal on-hold, bis ich hier eine Klarheit beim Standard habe ich auch ausreichend Geräte gibt und dann ggf. einen Piloten starten.
Loxone AirWäre am naheliegendsten, weil ich bereits einen Miniserver mit Extensions etc. habe. • Leichte Integration in Loxone
• Support durch Loxone
• Proprietär: Da laufen dann nur die Loxone Hardware Sensoren und Aktoren.
• Hoher Preis der einzelnen Komponenten
Das proprietäre Protokoll ist für mich ein absolutes no-go. Ein "Vendor login" gilt es auch im Sinne des Investitionsschutzes dringen zu vermeiden.
Enocean• Standardisiert
• Praxiserprobt
• Viele Hersteller und Produkte
• Keine nahtlose Integration in Loxone oder KNX
• Etwas gewöhnungsbedürftige Schalter.
HomeMatic• Gute Verschlüsselung
• Niedrige Kosten
• Propräitärs Protokoll
• Haben online wohl ein paar Probleme Link

Entscheidung

Ich habe mich dann aus den folgenden Gründen für die EnOcean Lösung entschieden:

  • Offener Standard
    • Die Schnittstellen sind offen und gut dokumentiert
    • Es ist, wenn man will, relativ einfach ein Gerät EnOcean fähig zu machen. Die Hardware ist für kleines Geld verfügbar und die Software ist größtenteils kostenlos.
  • Reife Technologie
    • EnOcean gibt es seit über 10 Jahren und die Technologie kann daher als erprobt angesehen werden.
    • Es gibt eine große Community, die bei Problemen schnell Support bieten kann.
  • Viele Hersteller und Geräte
    • Durch viele Hersteller gibt es einen großen Markt mit guten Preisen.
  • Integration
    • Für viele andere Wired Protocols (Loxone, KNX, etc.) gibt es Interfaces, die eine einfache Integration ermöglichen.
      • Loxone Integration – Loxone EnOcean Extension
      • KNX Integration – Weinzierl KNX Gateways oder ABB i-bus KNX/EnOcean Gateway
      • IP Integration – http://enocean-gateway.eu/
      • etc.
  • Verfügbarkeit von Open Source Tools, Application Stacks und Development Kits
    • Github hat hier viele Projekte am Start was eine Akzeptanz ausdrückt, welche in der Konsequenz auf die Offenheit und Integrationsfähigkeit zurückzuführen ist.
    • Nicht zuletzt von EnOcean selbst gibt es viele Application Stacks (Gateway, Linux based middleware, etc.)
  • Unterstützung von Verschlüsselung (bei Nutzung entsprechender Geräte)
    • Das muss ich im Rahmen der kommenden Tests noch etwas genauer untersuchen.
  • Günstige Pilotierung mit Raspberry Pi EnOcean
    • Keine große Investition, um das Ganze mal auszuprobieren.
    • Mit niedrigen Kosten kann ein Proof of Concept durchgeführt werden. Generelle Realisierbarkeit, Schalter Integration, Loxone Integration, KNX Integration, etc. dazu aber mehr in einem weiteren Post.
  • Energy Harvesting
    • Es ist natürlich eine feine Sache, wenn die Schalter nicht mit Strom versorgt werden müssen und einfach irgendwo angeklebt werden können. Interessant ist da die Soft Remote Steuerung  von z.B. nodeon. Link
    • Die Schalter der Hersteller haben meist alle das gleiche EnOcean Modul PTM210 / 215 eingebaut. Das bisschen Plastik drumherum ist dann das Schalterdesign. Die Haptik, gemeint ist hier der Druckpunkt,  ist bei dem Schalter den ich habe (Eltako FT55-WG) jetzt zwar nicht der Brüller, aber es funktioniert. Kann man nicht beschreiben, muss man gedrückt haben. Das hat m.E. auch einen recht geringen WAF (https://de.wikipedia.org/wiki/Woman_acceptance_factor) und wenn ich so ein Ding jeden Tag ein paarmal drücken müsste würde ich auch durchdrehen. Aber irgendwie muss die Bewegungsenergie ja in elektrische Energie umgewandelt werden.

Loxone EnOcean Extension

Wenn bereits ein Loxone Mini-Server im Haus ist, und man aus oben genannten Gründen die Loxone Air Technologie nicht nutzen möchte, liegt die Anschaffung der EnOcean Extension auf der Hand. Die Integration ist nahtlos und man bekommt Herstellersupport. Seit einiger Zeit beobachte ich die Unternehmenspolitik von Loxone aber etwas skeptisch. Loxone ist ursprünglich mit dem Ansatz gestartet, eine offene Plattform anzubieten die sich leicht in andere Standards integrieren lässt. Dies spiegelt sich auch im Portfolio durch die vielen Extensions wie Dali, DMX, One-Wire, Modbus, RS232, RS485 und eben EnOcean wider. Die Implementierungen sind nicht immer vollständig, wie z.B. auch die von Anfang an integrierte KNX Schnittstelle, aber die unique selling proposition (Alleinstellungsmerkmal) war immer die Offenheit.

 

Nun hat Loxone in der Firmengeschichte auch alle Phasen zu durchlaufen, die alle jungen und erfolgreichen Unternehmen durchmachen müssen. Da wird ein neues Produkt mit dem Ziel entwickelt, sich über einen breiten Funktionsumfang, leichte Bedienung (weil am Anfang auch die Privatpersonen als Implementierer mehr im Fokus standen) und einer hohen Integrationsfähigkeit am Markt zu etablieren. Dann ist nach einiger Zeit dieses Ziel erreicht und man muss sich überlegen, wie man diese Marktposition nicht nur weiter durch Produktdiversifikation ausbaut, sondern auch aktiv verteidigt. Also neben der Abteilung Angriff auch die Abteilung Abwehr etabliert. Soweit alles normales Verhalten eines Unternehmens mit Gewinnerzielungsabsicht. Dabei gefällt mir persönlich die Strategie zur Marktverteidigung aber nicht, weil ich den Eindruck habe das dies teilweise auch über eine schleichende Reduzierung des Funktionsumfang (Link) geschieht. Dazu gab es ja eine größere Welle. Zudem ist nicht zu erkennen, dass die Komponenten die das System öffnen (KNX, EnOcean, etc.) aktiv weiterentwickelt werden.  Stattdessen wird über neue propräitäre Standards (Tree, Air) das Portfolio breiter aufgestellt (Diversifikation) und diese eigenen Systeme im Wettbewerb zu den etablierten gestellt. Die Integration von anderen Komponenten wird dann auch gerne mal als “Bastelei” definiert um darzustellen, dass eine homogene Loxone Infrastruktur professionell ist. Wobei professionell im Anbetracht von Link1 und Link2 auch relativ ist.

 

Das kann man als Unternehmen so machen und dies wird m.E. bei den meisten Kunden und Neukunden auch genau so funktionieren, weil dort liegt der Fokus mehr auf dem Thema der einheitlichen Infrastruktur und leichten Integration liegt. Für die, ich sage jetzt mal Enthusiasten, die aber eher den best-of-breed Ansatz wählen und die Infrastruktur als einen Baukasten sehen, ist dieses Modell nichts. Leider sind diese Enthusiasten genau die, die Loxone auch ein Stück weit groß gemacht haben. So jetzt aber Ende mit dem Loxone Bashing.

So geht es im nächsten Post also um die Pilotierung des EnOcean Systems.

Leave a Reply | Anmerkungen