SmartHome ohne externen Server/Cloud

Hallo,

ich würde gerne den Einstieg in die SmartHome-Technik machen. Als erste Anwendung denke ich an Steckdosen mit Verbrauchsmessung. Allerdings kommt keine Lösung in Frage , bei der ein externer Server involviert ist und es sollte möglichst alles mit OpenSource-Komponenten realisiert werden. Ich habe mich etwas umgeschaut und bin auf Stichworte wie Tasmota, MQTT und Zigbee2MQTT gestoßen.

Ich denke, dass ich das softwareseitig stemmen kann. Einen kleinen Server auf einem RaspberryPi habe ich schon für andere Anwendungen (NAS, OwnTracks) aufgebaut. Anders ist es bei Hardware/Firmware. Wenn ich das richtig verstanden habe, muss zum Flashen der Tasmota-Software auf Smart-Plugs gelötet werden. Davon will ich auf jeden Fall die Finger lassen. Wenn ich einen Lötkolben in die Hand nehme, kann ich das Gerät auch gleich auf den Recyclinghof bringen.

Daher meine Fragen: Gibt es SmartHome-Lösungen, die ohne externen Server auskommen und wo man die Geräte, speziell die Smart-Plugs, ohne Eingriff in die HW umflashen kann? Gibt es Lösungen, um SmartHome-Geräte, die für den Betrieb mit einem externen Server vorgesehen sind, ohne einen solchen an einem eigenen Server betreiben kann?

Grüße
A.

Hallo,

ein Freund von mir macht das alles mit FHEM:
https://www.fhem.de

Die unterstützen u.a. auch die Steckdosen von AVM:
https://wiki.fhem.de/wiki/Kategorie:Energieverbrauchsmessung

Gruß,
Steve

1 Like

Es geht sogar noch weit einfacher. Neben FHEM gibt es u.a. auch noch openHAB und Home Assistent, die hardware-agnostisch sind und über geeignete Funkmodule direkt mit den Komponenten und ggf. vorhandenen Zentralen diverser Hardware-Hersteller bzw. Funkprotokolle einheitlich umgehen können, ohne dass da irgendetwas umgebaut werden muss.

Ich selbst nutze openHAB als Überbau für Homematic (geht mit der CCU2 und der CCU3 als Zentrale oder der Alternative Homegear auch vollkommen ohne Hersteller-Cloud), Philips HUE, sowie diverse Z-Wave und WLAN-Komponenten, … Dazu setze ich auf einem Raspberry die spezielle Distribution openhabian ein, die OS und openHAB inkl. diverser nützlicher Komponenten, … so mitbringt, dass man die nur auf eine SD-Karte packen muss, die üblichen Vorab-Einstellungen zur Installation eines Raspberry machen muss, und das Ganze dann von selbst läuft. Es gibt aber auch Installationspakete für NAS-Geräte oder sonstige Linux- und Windows-Server. Auf meinem Raspberry steckt ein Razberry-Modul für Z-Wave, es könnte aber auch ein USB-Stick hierfür sein. Für Homematic könnte ich das mitgelieferte Homegear mit einem passenden USB-Stick nutzen, habe mich damals aber für die CCU2 als unabhängige Zentrale entschieden. Für HUE läuft bei mir deren Zentrale auch noch autark.

Im Standard von openhabian nicht vorgesehen ist eine grafische Oberfläche zur Bedienung auf dem Server selbst. Das habe ich bei mir nachgerüstet und setze hierfür ein Gehäuse mit eingebauten Touchscreen ein. Ansonsten läuft die Bedienung über diverse Apps und Oberflächen, die man auf Handy, Tablet, PC, … nutzen kann. Ich habe mir noch einen weiteren Touchclient mit einem Raspberry in ansonsten identischer Installation wie den Server (Gehäuse mit eingebautem Touchscreen) gegönnt. Das ließe sich beliebig erweitern. Von außerhalb des Hauses kann man über den Server der openHAB Foundation sehr einfach auf den eigenen Server zugreifen. Wenn man dies vermeiden möchte, kann man die Geschichte aber auch problemlos anderweitig aufsetzen. Auch hierzu gibt es erprobte Lösungen ohne jegliche Beteiligung Dritter.

Der Vorteil einer solchen Lösung ist, dass man nahezu beliebige Geräte damit unter einem gemeinsamen Hut betreiben kann, solange man die über eines der zahllosen Bindings oder unterstützten Standardprotokolle, wie z.B. MQTT irgendwie an das System dran bekommt. So kannst Du z.B. einen mit EnOcean Energieharvesting arbeitenden HUE-Schalter problemlos nutzen um damit eine Fritz!DECT Steckdose oder ein per Z-Wave angebundenes Gerät zu schalten. Der Nachteil ist allerdings, dass das alles halt open source ist, und nicht immer alles auf Anhieb funktioniert, ggf. mal entscheidende Leute aussteigen und bestimmte Geräteunterstützung dann mal brach liegen kann, … Du hast da keinen Anspruch auf Gewährleistung oder Wartung. Zudem bedeuten die unzähligen Möglichkeiten natürlich auch eine enorme Einarbeitung, wenn man damit etwas mehr machen möchte, und man sollte daher wirklich IT-affin sein und Lust am Basteln haben.

3 Like

Danke @Wiz und @steve_m! Damit habe ich erst mal genug Futter für die nächsten Tage. Ggf. melde ich mich dann noch mal mit weiteren Fragen.

Hallo,

kann zwar nicht mit eigener Erfahrung aufwarten, aber unter folgendem Link wird auf SmartHome aus Datenschutzsicht - und damit auch auf Selfhosting u. ä. - eingegangen. In den Kommentaren stehen auch ein paar interessante Informationen.

Nachdem ich mich etwas umgeschaut habe, möchte ich jetzt zum Einstieg eine minimale Konfiguration bestehend aus einem Raspberry Pi als Controller und einer Steckdose mit Strommeßfunktion. Für die Funkschnittstelle kommt, wenn ich es recht verstanden habe, Z-Wave oder Zigbee in Frage. Für beides gibt es Funkmodule bzw. Sticks für den Raspi, OpenHAB-Unterstützung sowie passende Steckdosen. Die Kosten für Funkmodul und Steckdose liegen in beiden Fällen in einer ähnlichen Größenordnung, wobei ich den Eindruck habe, dass das Angebot an Endgeräten bei Zigbee etwas umfangreicher ist.

Habe ich was übersehen? Welchen Standard würdet ihr empfehlen?

Oder diverse andere. Wenn Du auf openHAB setzen willst, dann kannst Du da so nahezu alles einbinden, was es zu irgendeiner ansatzweisen Marktgeltung gebracht hat. D.h. Du kannst durchaus auch eine WLAN- oder DECT-Steckdose einbinden, oder eine über BT, … solange es hierfür ein passendes Binding gibt. Aufgrund des Stromverbrauchs bin ich allerdings kein so großer Freund von WLAN-Komponenten. Die speziellen, vermaschten IoT-Netzwerke sind da mE immer die bessere Wahl. DECT, wie es z.B. AVM anbietet ist auch eine denkbare Alternative, wenn man ohnehin schon eine Fritz!box im Einsatz hat.

Meine ersten Steckdosen waren Z-Wave Geräte eines inzwischen leider nicht mehr existenten Herstellers, die noch recht klobig, dafür aber sehr einfach in der Einbindung und robust im Betrieb sind. Ich habe dann einige Z-Wave-Komponenten von Fibaro eingesetzt, die mit deutlich besserem Design aufwarten, allerdings zumindest damals recht hakelig in der Einbindung über den Razberry Z-Wave Controller waren. Abgesehen von den Steckdosen leidet jedoch die mechanische Stabilität teilweise unter dem recht zierlichen Design. Da ich ohnehin hier schon einen in openHAB eingebundenen HUE Controller hatte, habe ich zuletzt einige Zigbee-Steckdosen daran gehängt,

Wenn ich neu einsteigen würde und dies ohne vorhandene Controller wie Fritz!box oder HUE-Bridge möglichst kostengünstig gestalten müsste, würde ich auf Zigbee setzen, da Zigbee entscheidend im Matter-Umfeld aktiv ist, und alle namhaften Hersteller von Zigbee-Produkten Matter kurzfristig unterstützen werden.

Materialliste wäre für mich: Raspberry, eine wirklich gute SD-Karte (Raspis sind da gerne etwas wählerisch/zerstören auch mal schlechte Karten, ich nutze aktuell SanDisk Ultra), Gehäuse, ausreichend dimensioniertes Netzteil, Zigbee-Controller nach Wahl und die passende Steckdose dazu. Ich habe zuletzt LEDvance Steckdosen sehr günstig geschossen. Dann openhabian Image mit Edger o.ä. auf die Karte flashen, openHAB 3 auf Raspberry installieren (openHABian) - phenx.de bietet eine recht handliche deutsche Anleitung für die weiteren Schritte.

1 Like

Ich habe mir den Beitrag eben mal durchgelesen, und finde ihn irgendwie eigenartig. Einerseits wird viel gemeckert, andererseits sind alle durchaus vorhandenen Möglichkeiten zur Absicherung „nicht gut genug“, angeblich nicht praktikabel, … Das sehe ich durchaus anders.

Z.B. Homematic IP Komponenten kann man über eine CCU 2 oder CCU 3 problemlos ohne Hersteller-Cloud betreiben und die Inbetriebnahme so einer Lösung ist auch recht trivial, zumal Homematic von Hause aus bestimmte sinnvolle Verknüpfungen von Geräten, wie Heizungsregler mit Fenstersensor, bereits vorsieht. Aber natürlich muss die „Intelligenz“ dann im eigenen Hause sitzen, und insoweit muss man dann natürlich einmalig eine CCU gönnen, deren Kosten sich dann bei mehreren Reglern und ggf. weiteren Komponenten wie Fenstersensoren aber recht schnell relativieren.

Danke für die ausführliche Antwort. Das bestätigt das Ergebnis meiner Überlegungen. Der Raspi war längere Zeit als Mini-Medienserver problemlos im Einsatz. SD-Karte und Netzteil sollten in Ordnung sein.

Übrigens… die Software der CCU3 wurde 1:1 nachgebaut und mit zusätzlichen Features versehen. Das gibt es als alternatives Image für die CCU3, den Raspi und sogar PC. Mit dem richtigen 888MHz-Transceiver läuft das auf allen gleichermaßen. Nennt sich Raspimatic

Oder ist HomeAssistant als Alternative für OpenHAB ne Möglichkeit? Da gibt es das als Plugin.

Für mich ist das durchaus alles nachvollziehbar. Es geht um die tiefgreifende Information selbst, nicht um die Sichtweise des Autors. Wie weit man mit dem Datenschutz geht, muss jeder selber entscheiden, kann das aber nur, wenn er ausreichend informiert ist.

Allerdings hast Du scheinbar meinen Nachsatz nicht so wirklich zur Kenntnis genommen. In den „beiläufigen Informationen“ sind ein paar Alternativen aufgezeigt.

Bei mir kommt „SmartHome“ eh nicht ist Haus. Ich halte das im Heimbereich insgesamt für recht überflüssig, in machen Apekten abseits der Technik sogar für kontraproduktiv.

BTW: Warum hinterlässt Du nicht dort einen Kommenar, wenn Du Möglichkeiten siehst? Der Autor ist im Allgemeinen Recht aufgeschlossen und er hat einen gewissen sportlichen Ehrgeiz, das datenschutzseitig zu erforschen … und ist sich auch nicht zu schade, sich zu korrigieren, falls er dann zu einem anderen Fazit kommt.

Im openhabian Image ist Homegear enthalten. Das ist eine Emulation der CCU2, die man gleich mit auf dem openHAB-Server laufen lassen kann. Die reicht vollkommen aus, wenn man Homematic (IP)-Komponenten ohnehin dann über openHAB steuern will. Wobei tatsächlich einige Homematic Features ganz nett sind, die man dann erst einmal mit etwas Aufwand manuell unter openHAB realisieren muss. Z.B. die Realisierung von mehreren Timerprogrammen für die Heizungen, die man mit einem Klick umstellen kann, als auch die vorkonfigurierten Koppelungen von z.B. Heizung mit Fenstersensor. Allerdings geht das alles auch schon unter der CCU2 und insoweit auch mit Homegear.

Da bin ich grundsätzlich vollkommen bei Dir. Trotzdem ändert das nichts daran, dass einerseits in dem Beitrag die auf einer Hersteller-Cloud basierenden Lösungen - durchaus zurecht - aufgrund des Datenabflusses schlecht weg kommen. Andererseits aber die durchaus bestehenden Lösungen ohne Hersteller-Cloud auskommen zu können, nicht als sinnvolle Alternative gewürdigt sondern recht salopp aussortiert werden, um dann zu dem Schluss zu kommen, dass es keine praktikablen datenschutzfreundlichen Lösungen für das Thema geben würde.

Ich bin auch kein Freund von Daten in irgendwelchen Hersteller-Clouds und vermeide das bei meiner Heimautomatisation erfolgreich und problemlos ohne irgendwelche windigen Basteleien und instabilen Nerd-Lösungen. Aber wenn der Autor meint, dass man über Lösungen wie Homematic IP mit CCU2/CCU3 gar nicht zu reden braucht, …

So wichtig ist mir das Thema nicht. Er darf dazu auch gerne eine eigene Meinung haben. Ich habe eben eine andere.

Hier ein abschließendes Feedback bzgl. der ersten erfolgreichen Gehversuche.

Hardware:

Software:

  • Raspberry Pi OS Light 32Bit
  • openHAB3
  • deCONZ Steuerungssoftware für die RaspBee

Da es für openHAB kein Binding gibt, mit dem man direkt auf das RaspBee-Gateway zugreifen kann, wird deConz benötigt, Es stellt ein API breit, für welches es ein openHAB-Binding gibt. Außerdem enthält es ein GUI, über das Geräte eingebunden, überwacht und gesteuert werden können.

Ein Versuch mit openHABian war nicht erfolgreich. Es gelang nicht, die Verbindung zwischen openHAB und deCONZ herzustellen. Ob das ein generelles Problem ist oder auf mangelndes Wissen meinerseits zu diesem frühen Zeitpunkt zurückzuführen ist, lässt sich nicht mehr nachvollziehen. Ich habe dann Raspberry Pi OS Lite installiert und darauf openHAB und deConz. Eine kleine Hürde war noch die Java-Laufzeitumgebung. openHAB funktioniert mit OpenJDK nicht sauber und man muss daher Azul Zulu installieren.

Der Raspberry läuft komplett headless. Auf das deConz-GUI greife ich über X Forwarding zu, was erstaunlich flüssig läuft, Das GUI wird aber ohnehin nur in der Installationsphase benötigt.

Nach der Installation aller SW-Komponenten hat die Verbindung zwischen Smart Plug, deConz und openHAB auf Anhieb geklappt. Auch das Steuern und Auslesen hat grundsätzlich funktioniert. Nur die Leistungswerte waren um den Faktor 10 zu hoch. Nach einem Update der Firmware von RaspBee und Smart Plug funktioniert auch das.

Der Upgrade der Firmware des Smart Plugs über das DeConz-GUI war etwas aufwändig und mühsam. Die Übertragung brach systematisch bei < 1% ab. Trotzdem war nach einigen Versuchen die neue Firmware auf dem Plug.

Der Raspberry B+ ist wie zu erwarten etwas knapp dimensioniert. Das macht sich bislang aber nur beim Installieren und Konfigurieren bemerkbar. Beim Systemstart dauert es gut 10 Minuten bist openHAB bereit ist. Aber danach läuft alles reibungslos. Nachdem ich die Preise für aktuelle Raspberrys gesehen habe (und fast vom Hocker gefallen bin) werde ich erst mal damit weiter machen.

Dieses Thema wurde automatisch 30 Tage nach der letzten Antwort geschlossen. Es sind keine neuen Nachrichten mehr erlaubt.