Einstieg in Gebäudeautomation ohne Neubau/Renovierung/großes Strippenziehen

Begonnen von richard-os, 28 April 2019, 14:16:03

Vorheriges Thema - Nächstes Thema

richard-os

Hallo,
ich möchte mit fhem einsteigen und mit dazu einen RPI3 zulegen.
Hauptanwendung wären wohl eine Abwesenheitssimulation und Fernzugriff zum Schalten von Verbrauchern.
Nach tagelangem Lesen habe ich den Eindruck, dass man auch auf dieser Basis viel Geld ausgeben kann. Daher einige Fragen:
zusätzlich zum RPI benötigt man mindestens eine Schnittstelle, um Kontakt zu Sensoren und Aktoren aufnehmen zu können. Gibt es solche Ergänzungsbauteile, die mehrere Protokolle bzw. Kommunikationsstandards beherrschen?
Da ich nur sehr eingeschränkt Kabel nur verlegen kann, wäre eine Funklösung die erste Wahl.
Zumindest für die Sensoren erscheint mir Enocean relativ unauffällig anzubringen zu sein.
An Aktoren bräuchte ich vorwiegend Schalter. Gibt es da eine besonders günstiges, preiswertes oder zuverlässiges Produkt?
Ein wenig Erfahrung habe ich auch mit 1-wire.
Zusätzlich habe ich auch einen Poolcontroller, der per IP ansprechbar ist und den ich vielleicht mit einbinden kann.
Insgesamt möchte ich halt nicht nun etwas anschaffen, was sich in einem halben Jahr als Sackgasse erweist.
Grüße Richard



loescher

Hi!

Das hast du hoffentlich schon gesehen:
https://forum.fhem.de/index.php/topic,89686.0.html
?
Generell kann man schon mal sagen, dass du durch FHEM schon mal keine Sackgasse hast.
Daher meines Erachtens erstmal mit einem "Thema" anfangen und dann später erweitern.
Das Forum und Wiki ist voll von Ideen/Lösungen.
Und auf konkrete (einzelne!) Fragen, kommt sehr schnell eine Antwort.

Zum Thema Funklösung: Neben "preiswert" und "zuverlässig" ist m.E. ein niedriger Standby-Stromverbrauch und Rückkanal wichtig.
Ich habe bisher Homematic und HomematicIP (beides mittels CCU2) und ZigBee im Einsatz. Nicht billig, aber zuverlässig.

LG,
Stephan.

Tedious

Wenn es primär um Steckdosen, Licht und Co geht würde ich in dem Fall auf WLan setzen, da hat man an sich (fast) immer überall im Haus zumindest Empfang. Stichworte sind SonOff und Tasmota, aber auch die Shellys funktionieren einwandfrei innerhalb einer bestehenden Installation. Dafür brauchst Du prinzipiell erst mal kein weiteres Gateway, und viele (nicht alle!) Schalter lassen sich per GPIO aufbohren (Temp, Luftfeuchte, etc...). Stromverbauch lässt sich bei Tasmota stark senken (sleep/DynamicSleep). Wobei der Stromverbrauch realistisch betrachtet vernachlässigbar ist wenn Du nur eine olle häufig benutzte 40/60W Glühbirne oder Halogenlampe durch eine LED ersetzt...

433/866Mhz Funk ist oftmals in der Abdeckung limitiert oder Du brauchst (so überhaupt verfügbar) auch dafür wieder Repeater. Für Beleuchtungsautomatisation bietet sich auch Zigbee (z.B. HUE) an, hier kann jede Lampe als Repeater fungieren. Günstiger wird es denn mit Xiaomi und der Kombination mit günstigen IKEA-Lampen.
FHEM auf Proxmox-VM (Intel NUC) mit 4xMapleCUN (433,3x868) und Jeelink, HUE, MiLight, Max!, SonOff, Zigbee, Alexa, uvm...

Beta-User

Zitat von: Tedious am 06 Mai 2019, 10:03:06
[...] würde ich in dem Fall auf WLan setzen, da hat man [...]
Da kann man auch anderer Meinung sein (ich würde z.B. empfehlen, WLAN möglichst zu meinden!), in jedem Fall sollte man aber erwähnen, dass das UNBEDINGT eine entsprechende Basisinfrastruktur voraussetzt, weil häufig vorhandene Consumer-Router etc. nicht geeignet sind, das vernünftig zu managen!

Ansonsten:
HomeMatic habe ich und bin soweit zufrieden, würde das aber heute nicht mehr verbauen - vergleichsweise zu teuer... HM-IP mit dem Zwang zur (optional virtuellen) CCUx käme mir schon gleich gar nicht ins Haus.

Habe zwar erst die ersten Experimente mit ZWave am Laufen, aber das sieht für mich nach einer sehr brauchbaren Alternative aus und bietet mesh (also Vergößerung der Funkreichweite durch netzbetriebene Geräte wie Rollladenaktoren usw.).

Zigbee ist ebenfalls einen Blick wert, die Dresden-Elektronik-Lösungen scheinen da das Maß der Dinge zu sein, was IO angeht (ich selbst nutze grade zigbee2mqtt, das aber noch nicht denselben Funktionsumfang hat und Java benötigt). Liegt leider im selben Frequenzbereich wie WLAN, was ggf. zu Störungen führen kann.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Tedious

Zitat von: Beta-User am 06 Mai 2019, 10:19:42
Da kann man auch anderer Meinung sein (ich würde z.B. empfehlen, WLAN möglichst zu meinden!),

Mag sein dass man da drüber streiten kann, mir erschließt sich nur nicht wieso? Wenns um das Thema Sicherheit geht - die Lücke sitzt IMHO in aller Regel (wenn nicht sauber konfiguriert) eher im FHEM-Rechner als in einem Tasmota-Device ;)
FHEM auf Proxmox-VM (Intel NUC) mit 4xMapleCUN (433,3x868) und Jeelink, HUE, MiLight, Max!, SonOff, Zigbee, Alexa, uvm...

MadMax-FHEM

Zitat von: Tedious am 06 Mai 2019, 10:36:18
Mag sein dass man da drüber streiten kann, mir erschließt sich nur nicht wieso? Wenns um das Thema Sicherheit geht - die Lücke sitzt IMHO in aller Regel (wenn nicht sauber konfiguriert) eher im FHEM-Rechner als in einem Tasmota-Device ;)

Latenzen sind bei WLAN (je nach Installation) höher, weil ja "alles mögliche" drüber läuft: Stream, Musik, Surfen, ...
...als bei einem NUR zu dem Zweck vorhandenes Funksystem.

Und wenn es dann mehr und mehr Geräte werden, dann ist manch ein "HomeRouter" deutlich überfordert...

Und wenn ich dann ein extra Netz aufspanne ist der Vorteil: kein extra IO schon wieder deutlich dahin...

Aber: wenn es funktioniert und man damit zufrieden ist... ;)

Ich würde es aus genannten Gründen nicht (zu viel) nutzen...

EDIT: noch ein Wort zu zuverlässig vs. günstig. Meiner Meinung nach (klar wie so oft gibt es Ausnahmen) geht das nicht zusammen. Heißt nat. umgekehrt nicht, dass teuer immer gut/zuverlässing ist. Eher andersrum: meist ist billig halt unzuverlässig: z.B. oft fehlender Rückkanal... Auch würde ich bei "eierlegenden Wollmilchsäuen" (z.B. CUL) erst mal genau prüfen wozu, also welches Protokoll. Weil nur weil der CUL (fast) alles kann ist es nicht immer die "Waffer der Wahl" (z.B. HomeMatic: finger weg von einem CUL!). Parallelbetrieb von verschiedenen Protokollen (nur weil sie zufällig oder nicht mal das im gleichen Frequenzbereich liegen) würde ich auch tunlichst lassen! Weil der CUL könnte/kann auch das...

EDIT2: wie schon angesprochen. Erst einmal damit beschäftigen. Vielleicht auch (ja kostet Geld aber man spart sich letztenendes trotzdem Geld) mal 1, 2, 3 Kandidaten besorgen (mögliche zuverlässige Systeme wurden ja bereits genannt) halt jweils nur mal einen Sensor, Schalter, Aktor und sehen wie man damit zurecht kommt. Je mehr man sich vorher durch Lesen (Forum/Wiki/...) beschäftigt, desto weniger "Prototypen" braucht man... Sich nach Lesen gleich "großzügig" (also quasi gleich alles was man braucht) für ein System zu entscheiden ist mMn falsch... Hätte ich damals MAX! nicht erst mal ausprobiert, sondern gleich (weil klang ganz gut und war/ist günstig) voll umgesetzt: eieieieiei... ;)

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Beta-User

Zitat von: Tedious am 06 Mai 2019, 10:36:18
Mag sein dass man da drüber streiten kann, mir erschließt sich nur nicht wieso? Wenns um das Thema Sicherheit geht - die Lücke sitzt IMHO in aller Regel (wenn nicht sauber konfiguriert) eher im FHEM-Rechner als in einem Tasmota-Device ;)
...das ist genau das Problem, dass alle glauben, dass WLAN doch gar kein Problem sein kann ??? . Schließlich kennt man das ja, nutzt es (in anderen Zusammenhängen) täglich, und das häufig ohne erkennbare (!) Probleme usw..

Das Sicherheitsthema bei den ESP8266-Geräten (im Klartext auslesbare WLAN-Daten im Flash!) scheinen viele schon wieder vergessen zu haben, aber um sowas spezielles geht es gar nicht unbedingt nur. Viel "schlimmer" ist, dass v.a. (manche?) Fritzboxen z.B. dafür geradezu "berühmt" sind, dass ab etwa 20 WLAN-Geräten Probleme auftreten. Beispiel gefällig? Hier:  https://forum.fhem.de/index.php/topic,95688.0.html
Es gibt daher Threads hier im Forum, die sich nur damit beschäftigen, welche Basisinfrastruktur man braucht, um größere WLAN-Installationen stressfrei hinzubekommen - TEs sind in der Regel user, die (bis dahin) - "kein Problem" erkennen konnten, und sich hinterher wundern, warum sie plötzlich besseres WLAN-Gerät anschaffen sollen :P . Oder damit, wie man die HA-Geräte in ein eigenes subnet bekommt...

Aber auch ohne Fritte kann es lustig sein: https://forum.mysensors.org/topic/10199/waf-in-jeopardy-today

Dann: die cloud. Kann man zwar abschalten, oder durch tasmota wegflashen. Aber tasmota ist eine Veränderung des Geräts, so dass evtl. Probleme mit dem Versicherungsschutz bestehen können, wenn die Versicherung das rausfindet, selbst wenn die Bude eventuell doch aus anderen Gründen abgefackelt ist...
(Ganz abgesehen davon, dass man "Spaß" haben dürfte, wenn man mal das WLAN-Passwort ändert...).

Ergo: Ich supporte MQTT2 gern (die meisten "Profiteure" sind tasmota- und Shelly-Nutzer), lasse aber selber möglichst die Finger davon und nehme was anderes, wenn es sich umgehen läßt. Ich habe einfach keinen Bock auf eventuelle Nebenwirkungen, aber letztlich muß das jeder selber wissen.

Wichtig wäre mir nur, dass kein erfahrener User "einfach so" hier gegenüber unbedarften Einsteigern behauptet, WLAN wäre doch eine super Lösung. Kann sein, ist es oft aber eben nicht (ohne weiteres).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors