Smart-Home System Eigenentwicklung

C

Cybertronage

Neues Mitglied
0
Hallo zusammen,
ich bin noch relativ neu im Smart-Home Umfeld und möchte mir für mein neues Haus eine neue Lösung aufbauen.
Dafür bin ich auf der Suche nach ein wenig Input von Nutzen, die evtl. bereits etwas ähnliches gemacht haben wie ich.

Ich bin selbst Software-Entwickler, kenne mich also generell mit Programmieren / Netzwerken und Schnittstellen / APIs recht gut aus.
In meinem neuen Haus möchte ich einige verschiedene Geräte von verschiedenen Herstellern einbauen und von einer zentralen Oberfläche steuern.
Die Oberfläche ist eine Webseite auf Basis von Angular, die ich selbst entwickle und die im Heimnetzwerk erreichbar sein soll.
Im Hintergrund kommuniziert diese Oberfläche mit einer Java-Anwendung auf Basis von Spring Boot (auch selbst entwickelt), die auch wiederum eine Datenbank beinhaltet. Dieses Backend soll dann jeweils mit den Smart-Home-Geräten kommunizieren.
Beides soll auf einem Raspberry laufen.

Oberste Prämisse für mein Vorhaben ist, dass ich unabhängig von irgendwelchen Herstellern, Clouds oder Bridges bin. Ich möchte wirklich bis auf die Hardware (und deren Firmware) alles selbst machen.
Bisher habe ich ein paar Nanoleaf-Lichtpanels im Einsatz, die direkt über WLAN an meinem Router hängen und direkt über eine offene API von meinem Backend angesprochen werden. Funktioniert soweit ganz gut, bei der Auswahl der weiteren Hardware tu ich mich allerdings schwer.

Konkret suche ich noch nach Temperatur- und Luftfeuchtigkeits-Sensoren (bzw. eine Kombination aus beiden) und einfachen Schaltern.
Diese sollten sich natürlich in meine Lösung gut einfügen lassen, als nicht ausschließlich über eine App oder Cloud eines Herstellers angesteuert werden können.
Prinzipiell wäre natürlich eine direkte WLAN Anbindung mit entsprechender API (analog zu den Nanoleafs) angenehm.
Ich habe aber auch schon mehrfach gelesen, dass bei Sensoren etc. z.B. ZigBee eher Sinn macht (Stromverbrauch).
Mit Zigbee habe ich jedoch noch nie gearbeitet, würde mir das aber prinzipiell auch anschauen. Soweit ich weiß benötige ich dann für den Raspberry ein zusätzliches Modul?!
Ansonsten ist mir auch MQTT / AMQP als m2m Protokoll geläufig.

Bin über jeden Ansatz und Tipp dankbar und freue mich auf einen Austausch! :)
 
Zuletzt bearbeitet:
Ich würde mir überlegen, ob ich nicht ein neues Haus gleich richtig "smart" mache, anstatt Nachrüst-Geraffel einzuplanen. Ein Raspberry Pi als zentrale Anlaufstelle ist schon arg mutig. Mir wäre das Risiko zu groß, dass die Kiste mal ausfällt und man dann im Dunkeln und in der Kälte hockt. Das wird den WAF ganz stark nach unten ziehen.

Als Erstes braucht man Hardware in einem "smartem" Haus, die auch ohne zentralen Server funktioniert und auch kabelgebunden ist. Alles was per Funk miteinander kommuniziert, kann gestört werden. EnOcean funktioniert bei mir im Haus wesentlich störungsfreier als ZigBee. Bei EnOcean kam es nur alle paar Woche mal vor, dass eine Meldung verschluckt wird und ich bekomme es nur mit, da ich einen Watchdog laufen lasse, der sehr scharf eingestellt ist. Bei Zigbee kommt es häufig vor, dass mal eine Lampe nicht ausgeht oder dass Meldungen von Temperatur und Fensterkontakt-Sensoren verschluckt werden. Zigbee ist ideal wenn man Nachrüsten will, aber ein Nervfaktor, wenn es fehlerhaft in einem neuen Haus werkelt. Zugangskontrollen würde ich komplett autark laufen lassen und nur den Status zur weiteren Auswertung weiterverarbeiten. Ich habe mein Zugang zum Haus bewusst auf Fingerprint, RFID-Chip und Schlüssel begrenzt. Ein Öffnen aus der Ferne oder per Visu ist mir zu riskant. Wenn es klingelt laufe ich lieber zur Tür, als sie per Tablet zu öffnen... ist ja auch höflicher seinen Besuch an der Haustür persönlich zu empfangen ;) . Als Verbinder zwischen den Technologien würde ich nichts Selbstgebasteltes nehmen. Es kommt schneller als man denkt, dass gewisse Vorgänge für andere Mitbewohner anders automatisiert werden müssen und dann ist man bei einer "fertigen" Lösung wesentlich schneller mit der Umprogrammierung. Bei der Visu kann man sich dann frei entfalten und alles selber programmieren, da diese dann doch sehr starr ist. Hier sollte man nur darauf achten, dass diese auch mal schnell ausgetauscht oder durch andere Software ergänzt werden kann und dafür das Übertragungs-Protokoll sehr verbreitet ist --> MQTT.

Mein Setup:

Grundgerüst des Hauses:
- KNX
- EnOcean an einem KNX-Gateway
- ekey (Zugangkontrolle)
- Hikvision NVR

externe Logik und "Verbinder":
- FHEM
- Harmony zur MultimediaSteuerung
- Zigbee für 4 bunte Lampen und ein paar Sensoren (zB Temperatursensor für den Dachboden)

Visualisierungen:
- HomeAssistant (auch für die Steuerung aus dem Internet raus, Anbindung an die Sprachsteuerung)
- MQTT-Dash auf einem AndroidTablet
- Homekit

Kommunikation:
- MQTT
- XMPP
 
Vielen Dank schon einmal für deinen Input! :)
Für mich ist es bisher eher eine "Spielerei" und als Hobby-Projekt gedacht. Daher beabsichtige ich momentan auch nicht, auf eine Hersteller-Lösung zu setzen und viele Sachen im Haus zu automatisieren.
Sensible Bereiche wie Zugangskontrolle etc. möchte ich ohnehin nicht automatisieren und ganz altmodisch mit Schlüssel bedienen.
Es handelt sich bei dem Haus auch nicht um einen Neubau, wo man so ein System rein strategisch einbauen würde, sondern um einen Altbau.

Ich plane das Ganze also auf einer viel kleineren Ebene, als von dir vorgeschlagen. Konkret schweben mir aktuell folgende Anwendungsfälle vor:
  • Steuerung von Beleuchtung und Nano-Leaf Panels über das Web-Frontend
  • Speicherung und Auswertung von Sensordaten ("Wie warm ist es gerade in Zimmer x", "Wie warm ist es durchschnittlich im Wohnzimmer in der aktuellen Woche", "Wie entwickelt sich die Luftfeuchtigkeit über den Tag") - hier will ich die Messdaten in einem Diagramm darstellen - also erst einmal nur Spielerei und keine "ernsthafte" Steuerung von Lüftung o.ä.
  • Licht an und ausschalten über das Web-Frontend

Daher halte ich einen Raspberry aktuell für ausreichend. Fehlertoleranz ist auch kein Thema, da Datenlücken nicht weh tun werden.
 
Wäre iobroker nicht etwas für dich ? Open Source und du kannst eigene Adapter entwickeln, trägst so mit zur Verbesserung bei
 
ok, also erst einmal nur Datenerfassung und etwas Smartphone-Home.

Bei den Sensoren würde ich dann aber trotzdem schon einen etwas handfesteren Weg gehen. 1-Wire ist ein schönes Bussystem für Sensoren ala Temperatur und Luftfeuchtigkeit. Das dürfte billiger werden als ein Zigbee-Sensoren-Netzwerk und es sollte auch unanfälliger für Firmware-Updates sein.

Man muss auch immer schauen, welche Daten man unbedingt braucht und welche nur einen reinen Infowert haben. Bei mir sind es Luftfeuchtigkeit, CO² und Regenmenge, die nicht zur Automatisierung benötigt werden. Da ich noch ein paar Netatmo-Komponenten aus der alten Wohnung rumliegen hatte und auch nicht unbedingt Geld für neue CO² und Luftfeuchtigkeitssensoren ausgeben wollte, habe ich kurzer Hand mein Netatmo wieder reaktiviert und mit der Visu verbunden. FHEM sammelt jetzt die Daten ein und schreibt sie in eine Datenbank.

Automatisierung fängt immer klein an :) ... Meine ersten Automatisierungen waren teilweise auch selbst in PERL zusammengefrickelt. Damals stellten sich die Philips-Hue automatisch ein, sobald auf der Harmony eine Aktivität lief. Dann wurden es aber zu viele Automatisierungen, so dass ich mich nach fertigen Lösungen umsah. Über openhab bin ich dann bei FHEM gelandet. Heute werkelt neben einem FHEM, auch ein Nodered, ein Mosquitto, ein Ejabber, ein HomeAssistant und sogar eine Homebridge. ... und jedes Stück Software hat seine Daseinsberechtigung. XMPP nutze ich zum Beispiel auch, um mein Android-Tablet zu steuern, dass als Info-Terminal im Büro hängt. MQTT wäre zwar schöner gewesen, aber die MQTT-App auf dem Tablet pennt mir zu fest, wenn das Tablet mal länger nicht benutzt wurde. So nutze ich "Conversation" und Tasker, um das Tablet zeitnah steuern zu können. Die Chat-App schläft nicht so tief, so dass man darüber schneller Reaktionen herbeiführen kann. Ich lasse zum Beispiel beim Betreten des Büros MQTT-Dash auf dem Tablet anzeigen. Per MQTT hat es teilweise 20s gedauert bis sich das Tablet regte und mit XMPP reagiert es quasi sofort.
 
Zur Raumklima-Erfassung finde ich den Netatmo Healthy Home Coach gut. Der ist aber deutlich teurer als ein einfacher Sensor für Feuchtigkeit und Temperatur.
Kann dafür aber auch deutlich mehr und bietet schon eine gute App und Diagramme.

Du kannst bei Netatmo alle Werte per API abrufen. Für Alexa habe ich für den Home Coach selbst einen Skill erstellt. Dort nutze ich dann auch die API.

Wenn es etwa was mehr sein darf kann man auch eine Wetterstation von Netatmo nehmen, diese kann mit einem Indoor-Modul erweitert werden.
 

Ähnliche Themen

YaMu
Antworten
3
Aufrufe
111
swa00
swa00
Justice
Antworten
27
Aufrufe
953
Espressojunkie
Espressojunkie
J
Antworten
55
Aufrufe
2.623
TechnoTueftler
T
Zurück
Oben Unten