Planungsphase: Ist das mit einem Raspberry Pi (bzw. BananaPi) umsetzbar?

[r00t2]

Hallo zusammen,

nachdem ich mir schon einige Tage den Kopf zerbreche und über viele Seiten Dokumentation gelesen habe, kam nun der Entschluss, mich auch hier im Forum anzumelden.

Ich plane mein Heim Stück für Stück an gewissen Stellen zu automatisieren bzw. "smarter" zu machen.
Das Ganze soll keine hochkomplexe und absolut ausfallsichere Profilösung sein, sondern eine stabil laufende Heimwerkerlösung (gerne mit etwas Bastelanteil) zu einem attraktiven Preis.

Um mich nicht gleich von Anfang an zu verrennen, frage ich lieber mal nach, ob mein Vorhaben überhaupt realistisch und mit meiner Hardware umsetzbar ist.

Folgende Hardware ist bereits vorhanden und könnte als Serverhardware genutzt werden:
- 1x Raspberry Pi 2 Model B (unbenutzt)
- 2x Raspberry Pi Model B+ (beide unbenutzt)
- 1x BananaPi (wird mit BanaNAS/OpenMediaVault als NAS betrieben)
- 1x Cubox i4-Pro (wird mit OpenELEC als Mediencenter am TV betrieben)
- 1x WeTek Play (wird mit OpenELEC/Enigma als Mediencenter am TV betrieben)

Favorisieren würde ich als Serverhardware entweder einen RasPi oder den BananaPi. Wenn es mit dem BananaPi laufen würde, hätte das den Charme, dass ich kein weiteres Gerät am Netz benötige.

Folgende Komponenten sollen in Zukunft per FHEM eingebunden werden:
- Rauchmelder (3-5 Stück)
- Heizungsthermostate (3-5 Stück)
- Schaltbare Steckdosen (ca. 5-8 Stück)
- Außenthermometer (ggf. mit Luftfeuchtemessung, 1 Stück)
- TV über die angeschlossenen Mediencenter (zur Visualisierung von Events, Anbindung ggf. über PushBullet/JSON-RPC?)

So weit, so gut. Nun die Frage: Welche Hardware wird (neben den Aktoren/Sensoren) noch benötigt und welches Protokoll soll verwendet werden?

Beim Einlesen in die Materie ist mir aufgefallen, dass es viele Produkte gibt, die per HomeMatic oder Z-Wave vernetzt und in FHEM eingebunden werden können. Daher war meine Idee, auf einen dieser Standards aufzubauen. Mein Favorit wäre momentan HomeMatic. Was denkt Ihr darüber?

Wenn ich auch HomeMatic setzen würde, wäre der COC das Interface meiner Wahl, weil über das CU* Interface viele Protokolle abgedeckt werden können und es sowohl 433 MHz, als auch 868 MHz beherrscht  - aber auf der Seite von busware steht, dass der COC nicht mehr produziert wird. Wäre das SCC Interface ebenso geeignet oder benötige ich hier noch zusätzliche Hardware (z. B. eine externe Antenne oder ein weiteres Zusatzboard)?

Was denkt Ihr über mein Vorhaben - ist das so umsetzbar?

Vielen Dank für ein paar Antworten.

[viegener]

Grundsätzlich finde ich den SCC als device eine gute Wahl und er wird auch auf dem bananapi unterstützt, allerdings ist man weniger flexible als USB (funktioniert an deutlich mehr Geräten) oder gar ein CUN (denn damit ist auch eine flexiblere Platzierung möglich)

Zum BananaPi ist mir nicht klar, wieviel performance noch übrigbleibt wenn ein Betrieb als NAS parallel läuft (Beides sind eher real time anwendungen und können sich deshalb ins gehege kommen)

Bei der Auswahl würde ich versuchen nicht 433 mit 868 gemischt zu betreiben, wenn nötig eher 2 CUxs. Umschaltung ist nur eine Krücke. Allerdings ist es wichtig zu shene, dass bidirektionale Protokolle nicht einfach gemischt werden), also ein Homematic-CUx ist dann auch nur für homematic zu verwenden.

Bei Homematic (im Gegensatz zu zwave) stellt man fest, dass eq3 recht lange Erfahrung hat und es eine (momentan noch ?) breitere Basis an Benutzern gibt, allerdings ist bei homematic die Einschränkung auf einen Hersteller gegeben.

Mein Vorschlag:
- Verwende den Raspi - dieser ist wohl am weitesten verbreitet und während der Aufbauphase kannst Du problemlos neustarten und hast auch bei Problemen keinen anderen Dienst beeinflusst.
- Homematic erscheint mir eine gute Wahl, allerdings ist der Markt gerade sehr im fluss und man sollte sich darauf einstellen, dass sich die grossen PLayer für die Zukunft noch nicht herausgestellt haben. Ich bin nicht sicher ob homematic seine starke POsition auch in 5 Jahren noch haben wird.
- Alle von Dir angedachten Geräte sind als homematic-geräte verfügbar
- SCC ist einen gute Wahl, wenn der Preis nicht das entscheidende Merkmal ist, sonst kann man auch einen Selbstbau-CUL andenken ausserdem kann ein CUN die richtige Positionierung vereinfachen. Für Homematic ist eine ganz andere Lösung (Homematic LAN) denkbar (und bei mir trotz vorhandemnem CUL868 im Einsatz)

[r00t2]

Danke für die rasche und ausführliche Antwort!

Ich denke die Verwendung eines RasPi als dedizierter Hardware ist absolut sinnvoll, da hast Du recht. Ein "normaler" RasPi (nicht die Version 2) sollte ausreichend sein, oder?

Benötige ich zum SCC noch Zusatzhardware (Antenne, Befestigungs-Set, etc. ?) oder ist der out of the Box schon fix und fertig einsatzbereit, sobald er auf dem RasPi steckt? Ein USB CUL wäre durchaus flexibler, was den Host angeht, stimmt. Schafft der RasPi ihn mit der bordeigenen Spannungsversorgung zu betreiben oder ist da noch ein externer USB Hub mit eigenem Netzteil zum Anschluss nötig? Und welche Zusatzoptionen sind hier bei der Konfiguration der Hardware sinnvoll (Abschirmung, Gehäuse, große/kleine Antenne, ...) Da bei mir der RasPi relativ zentral im Haus steht wäre ein CUN nicht unbedingt nötig, wird aber im Hinterkopf behalten.

Preislich nehmen sich SCC und CUL ja nicht so viel (wenn man den "nackten" CUL als Basis hat).

Ich dachte mir schon, dass Umschaltbetrieb nicht wirklich zielführend ist. Daher würde ich mich jetzt auf HomeMatic als Protokoll festlegen - erstmal egal, was die nächsten 5 Jahre bringen werden. Die Produkte sind ja scheinbar ausgereift und haben eine recht große Verbreitung. Nachdem ich keine Sonderanforderungen an die Sensoren/Aktoren stelle, sollte das funktionieren - hoffe ich.

[viegener]

Danke für die rasche und ausführliche Antwort!

Ich denke die Verwendung eines RasPi als dedizierter Hardware ist absolut sinnvoll, da hast Du recht. Ein "normaler" RasPi (nicht die Version 2) sollte ausreichend sein, oder?

Benötige ich zum SCC noch Zusatzhardware (Antenne, Befestigungs-Set, etc. ?) oder ist der out of the Box schon fix und fertig einsatzbereit, sobald er auf dem RasPi steckt? Ein USB CUL wäre durchaus flexibler, was den Host angeht, stimmt. Schafft der RasPi ihn mit der bordeigenen Spannungsversorgung zu betreiben oder ist da noch ein externer USB Hub mit eigenem Netzteil zum Anschluss nötig? Und welche Zusatzoptionen sind hier bei der Konfiguration der Hardware sinnvoll (Abschirmung, Gehäuse, große/kleine Antenne, ...) Da bei mir der RasPi relativ zentral im Haus steht wäre ein CUN nicht unbedingt nötig, wird aber im Hinterkopf behalten.

Preislich nehmen sich SCC und CUL ja nicht so viel (wenn man den "nackten" CUL als Basis hat).

Ich dachte mir schon, dass Umschaltbetrieb nicht wirklich zielführend ist. Daher würde ich mich jetzt auf HomeMatic als Protokoll festlegen - erstmal egal, was die nächsten 5 Jahre bringen werden. Die Produkte sind ja scheinbar ausgereift und haben eine recht große Verbreitung. Nachdem ich keine Sonderanforderungen an die Sensoren/Aktoren stelle, sollte das funktionieren - hoffe ich.

Ich habe mit einem Pi1b angefangen, dass funktioniert, allerdings war der performanceanstieg zum pi2 doch recht erheblich. Wenn Du einen Pi2 hast, würde ich damit anfangen, denn Wartezeiten beim reboot oder fhem neustart sind ja doch deutlich kürzer.

Ich habe bei meinen beiden SCCs auch direkt antennen bei busware mitbestellt (einmal mit Kabel und einmal zum direkten anschrauben). Antennen braucht man auf jeden Fall und um das Chaos female/male bei den Antennen zu vermeiden habe ich sie mitbestellt.

Mit einem guten Netzteil ist aus meiner Erfahrung kein zusätzlicher powered hub erforderlich. Ich habe die 2 SCCs, ein fhemduino und einen jeelink direkt am PI2 alles über dasselbe Netzteil (Homematic habe ich komplett per HMlan abgewickelt nachdem ich damals etwas mehr im forum und wiki gelesen hatte).

[r00t2]

Dann schaue ich, dass ich den RPi2 für das Vorhaben reserviere und gleich ein "Komplettpaket" an Starterhardware inklusive Antenne bestelle.

Oh, das heißt Du hast an einem RPi2 insgesamt 2 SCC per GPIO und 2 USB Geräte (FHEMduino und Jeelink) mit nur einem guten Netzteil am laufen - das klingt doch gut! Hast Du dazu in der config.txt den Eintrag max_usb_current=1 gesetzt?

Wenn ich das bei Deinem Setup richtig gelesen habe, kann ich durchaus mit nur einem RPi per FHEM mehrere Protokolle fahren, wenn ich für jedes ein dediziertes Interface habe. Also wenn ich z. B. 433, 868 und Z-Wave mit einem RPi betreiben möchte, dann benötige ich z. B. 2 SCC und einen ZWDongle. Richtig soweit?

[viegener]

Dann schaue ich, dass ich den RPi2 für das Vorhaben reserviere und gleich ein "Komplettpaket" an Starterhardware inklusive Antenne bestelle.

Oh, das heißt Du hast an einem RPi2 insgesamt 2 SCC per GPIO und 2 USB Geräte (FHEMduino und Jeelink) mit nur einem guten Netzteil am laufen - das klingt doch gut! Hast Du dazu in der config.txt den Eintrag max_usb_current=1 gesetzt?

Wenn ich das bei Deinem Setup richtig gelesen habe, kann ich durchaus mit nur einem RPi per FHEM mehrere Protokolle fahren, wenn ich für jedes ein dediziertes Interface habe. Also wenn ich z. B. 433, 868 und Z-Wave mit einem RPi betreiben möchte, dann benötige ich z. B. 2 SCC und einen ZWDongle. Richtig soweit?

Ja mehrere Protokolle  mit verschiedenen Interfaces (Sender/Empfänger) sind kein Problem. In manchen Fällen geht das auch mit einem Interface, allerdings ist meines Wissens nach homematic eine wesentliche Ausnahme, wg. der Notwendigkeit ständig Bestätigungen/Sensordaten zu empfangen. Zum Beispiel mit dem Signalduino ist es möglich sogar sehr viele Protokolle zu empfangen (insbesondere bei Sensoren).

Das mit dem max_usb_current weiss ich jetzt gerade nicht genau, es sollte aber für die CULs eigentlich nicht notwendig sein, denn diese sind fordern meines Wissens eher unter 300mA.

Ob Du gleich beide SCCs brauchst kann ich nicht beurteilen, für Homematic ist es jedenfalls nicht nötig und für einen Temp-Sensor würde ich auch kein eigenes Protokoll hinzufügen.

Also im Prinzip könnte ein HM-Interface (SCC868 oder HMLAN oder ...) und ein Teil für ZWave reichen.

Johannes