Gedanken zum SmartHome, dem Leben und dem Ende desselben ...

Begonnen von M_I_B, 16 Januar 2018, 11:03:22

Vorheriges Thema - Nächstes Thema

M_I_B

Im Zusammenhang mit einem Gespräch unter Kollegen in der Firma kam u.a. auch das Thema auf Hausautomation und der damit zusammenhängenden Technik. Gerade im Zusammenhang mit FHEM ist ja doch ein ordentliches Wissen und "Reinfrickeln" in die Materie unabdingbar. Das aber wiederum bedeutet i.d.R. auch, das in einer Familie lediglich eine Person den Durchblick hat, wie alles zusammenhängt (oder sollte).
In meiner Familie bin ich das halt. Meine Frau hat zu Technik und insbesondere zu FHEM keinerlei Bezug. Sie weiß zwar inzwischen, welche Taste wie lange betätigt was macht und kann nach einem ExKurs auch einen ggf. ausgefallenen PI an der Heizung gegen den daneben liegenden und betriebsbereiten Ersatz-PI tauschen. Aber wenn irgend etwas nicht so funktioniert wie es soll, dann bin grundsätzlich ich gefragt.

Nun kam von einem Kollegen der berechtigte Gedanke auf, was denn passiert, wenn ich z.b. auf der Fahrt zur oder von meiner Arbeitsstätte schlimmstenfalls tödlich verunglücke oder auch auf andere Art und Weise zeitnah das Zeitliche segne; meine Familie wäre nicht in der Lage, das System auf Dauer am Laufen zu halten. Auch ein hinzugerufener "Elektriker" würde i.d.R. da auch wie der Ochs vor'm Berg stehen. Es bliebe dann also nichts weiter übrig, als alle Komponenten gegen klassische Komponenten zu tauschen, also quasi einen kompletten Rückbau zu generieren, um die Infrastruktur des Hauses funktionell zu halten.

Hat sich von Euch dazu schon mal jemand Gedanken gemacht, wie die Hinterbliebenen dann mit dem ganzen Schlunz umgehen sollen? Ich bin sicherlich nicht der Einzige, der bereits mehr als ein halbes Jahrhundert auf dem Buckel hat und in einer Familiengemeinschaft lebt...

marvin78

Es ist im Grunde ganz einfach: Wenn alle kritischen Komponenten auch ohne FHEM funktionieren (und das ist die klare Empfehlung), dann ist das Problem nur sehr klein. Es geht um Hausautomation, nicht um "ersetze alle Lichtschalter und ähnliches durch FHEM".

Ein zweiter Punkt (und in diesem rede ich nur schlau daher): Dokumentation ist alles. Ist alles gut dokumentiert, schafft es jeder halbwegs motivierte Mensch, die Dinge am Laufen zu halten.

CoolTux

Zitat von: marvin78 am 16 Januar 2018, 11:06:54
Ein zweiter Punkt (und in diesem rede ich nur schlau daher): Dokumentation ist alles. Ist alles gut dokumentiert, schafft es jeder halbwegs motivierte Mensch, die Dinge am Laufen zu halten.

Und genau zu diesem Punkt hatten wir unlängst, so vor 1,5 Jahren, mal eine ellenlangen Threaddiskussion.


Grüße
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

visionsurfer

Daher habe ich beim Bau auf ein Bussystem gesetzt. In meinem Fall KNX. Es geht alles auch Offline. Fhem bringt es nur noch smarter und mit viel mehr Logik zusammen.

Aber ich gebe die Recht. Meine Frau bekommt ohne mich fast noch nicht mal KODI live TV an.

ext23

Ich hatte schon exakt dieselben Gedanken wie M_I_B, aber wie so oft verdrängt man das Thema und ist mehr oder weniger Egoistisch veranlagt weil selber hat man das Problem ja dann nicht mehr...

Aber ich sehe es auch so, alles was Licht, Rolladen und und und betrifft muss auch ohne FHEM gehen. Alles andere ist Spielerei womit die Frauen in der regen eh wenig anfangen können. Also bei uns ist das jedenfalls so ;-)

/Daniel
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

M_I_B

Zitat von: ext23 am 16 Januar 2018, 22:14:34... wie so oft verdrängt man das Thema und ist mehr oder weniger Egoistisch veranlagt weil selber hat man das Problem ja dann nicht mehr...
... naja, ich selbst hatte mir vorher tatsächlich keine Gedanken darüber gemacht. Inzwischen denke ich schon darüber nach, allerdings mehr in die Richtung, das Britta im Fall der Fälle nicht noch zusätzliche Probleme erwachsen. Nach fast 26 Jahren möchte man dann doch schon entsprechende Probleme, die in einem solchen Fall auftauchen können, im Vorfeld ausmerzen...

Zitat von: visionsurfer am 16 Januar 2018, 22:00:36... ein Bussystem gesetzt. In meinem Fall KNX.
Darüber hatte ich auch nachgedacht. Aber der Aufwand hätte in keinem Verhältnis zum Nutzen gestanden bei einem "gebrauchtem" Haus. Wenn wir neu gebaut hätten, dann hätte ich ganz sicher auf KNX o.ä. gebaut. So aber ...

Allgemein scheint das aber Allgemeingültigkeit zu haben, dass die vermeintlich bessern Hälften eher die Doktrin "das muss funktionieren" als "wie funktioniert das?" vertreten.
Daher werde ich mal mehr darauf achten, das nach und nach alles auch notfalls ohne Server funktioniert; schaden kann's nicht.

Beta-User

Wichtiges Thema!
Zitat von: M_I_B am 17 Januar 2018, 16:16:17
Daher werde ich mal mehr darauf achten, das nach und nach alles auch notfalls ohne Server funktioniert; schaden kann's nicht.
Finde ich einen guten Ansatz.

Weitere Gedanken dazu noch:

Problematisch empfinde ich auch Konstruktionen, die weitere Infrastruktur erfordern, damit etwas aus FHEM heraus funktioniert. Dann ist nämlich nicht nur der Server ein Problem, sondern eben auch diese darunter liegende weitere Infrastruktur. Das ist ein Grund, warum ich WLAN meide, wo es geht (keine ESP8266), nur ungern über LAN verbinde und GW's nach Möglichkeit seriell (an USB) einbinde. Derzeit läuft das Projekt, was geht auf RS485 umzustellen. Aus diesem Grund käme mir auch eine CCU2 nicht in's Haus, jedenfalls nicht als separate Hardware.
Speziell noch zu WLAN/ESP8266: Jedenfalls früher war es so, dass man die ESP's neu flashen mußte, wenn man mal das WLAN-Passwort ändern will. Von einem Router-Tausch mit komplett neuen Zugangsdaten will ich daher gar nicht reden, mal abgesehen von eventuellen Änderungen der libraries, die man mal in grauer Vorvergangenheit genutzt hat.

Ich habe auch noch ein paar Arduinos, die zwar mit FHEM kommunizieren, aber auch in der Lage sind, "autonome" Entscheidungen zu treffen (Zirkulationspumpe für's warme Brauchwasser an/aus und so). Was (noch) fehlt, ist die saubere Beschriftung und ein "Backup" für den einfachen Austausch im Fehlerfall.

Aber wie man die Dinge auch löst, einen Tod muß man sterben, wenn man überhaupt automatisieren will - womit wir wieder beim Thema wären ;D .

Gruß, Beta-User
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

zap

Die Sache ist eigentlich relativ entspannt, wenn man ein paar Regeln berücksichtigt:

- Bei Ausfall der zentralen Steuerung (egal ob FHEM, OpenHab oder ...) darf lediglich die Automatisierung wegfallen.
- Eine manuelle Steuerung muss jederzeit möglich sein
- Bei wichtigen Steckdosen (z.B. Zirkulationspumpe) keine UP-Aktoren verbauen. Dann kann man einfach den Zwischenstecker entfernen und das Gerät funktioniert.

Rollladen sind manuell bedienbar. Homematic Heizungsthermostate arbeiten auch ohne CCU/FHEM und im Worst Case hat man sie in 2 Minuten durch ein manuelles ersetzt.

Viel mehr Probleme sehe ich da bei der Steuerung von Multimedia (TV, SAT usw). Der ganze Mist ist auch nach Jahrzehnten Entwicklung bei der Steuerung immer noch nicht zueinander kompatible, oft nicht mal dann, wenn die KOmponenten vom gleichen Hersteller sind. Wenn meine Logitech Harmony ausfällt, kann meine Frau vermutlich nicht mehr Fernsehen, weil sie nicht weiß, welche Fernebdienung wofür ist, an welchem Eingang des TV welches Gerät hängt usw.
2xCCU3, Fenster, Rollläden, Themostate, Stromzähler, Steckdosen ...)
Entwicklung: FHEM auf AMD NUC (Ubuntu)
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: FULLY, Meteohub, HMCCU, AndroidDB

ext23

Zitat von: zap am 20 Januar 2018, 11:21:40
Viel mehr Probleme sehe ich da bei der Steuerung von Multimedia (TV, SAT usw). Der ganze Mist ist auch nach Jahrzehnten Entwicklung bei der Steuerung immer noch nicht zueinander kompatible, oft nicht mal dann, wenn die KOmponenten vom gleichen Hersteller sind. Wenn meine Logitech Harmony ausfällt, kann meine Frau vermutlich nicht mehr Fernsehen, weil sie nicht weiß, welche Fernebdienung wofür ist, an welchem Eingang des TV welches Gerät hängt usw.

Exakt, ist bei uns auch so. Aber ganz ehrlich, das ist das geringste Übel, das wird sie auch lernen. Fernbedienungen liegen alle noch im Schrank für den Notfall. Und HDMI Matrix ausbauen etc. das kann dann auch der liebe Nachbar. Da sehe ich gar nicht all zu große Probleme.

Und wenn ich mal auf Dienstreise bin und es geht mal wieder nichts weil FHEM abgeschmiert ist etc. dann wird die Lampe angemacht und ein Buch gelesen ;-) Schadet in der heutigen Zeit bei den laufenden TV Formaten zumindest nicht der persönlichen Bildung^^
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

drhirn

Zitat von: zap am 20 Januar 2018, 11:21:40
Die Sache ist eigentlich relativ entspannt, wenn man ein paar Regeln berücksichtigt:
- Bei Ausfall der zentralen Steuerung (egal ob FHEM, OpenHab oder ...) darf lediglich die Automatisierung wegfallen.
- Eine manuelle Steuerung muss jederzeit möglich sein

Und ich stelle mir schon lange die Frage, wie ich das beim Thema Beleuchtung realisieren kann. Bin mir sicher, ihr könnt da Licht in mein Dunkel bringen.
Ich wohne in einer Mietwohnung und habe da Lampenanschlüsse, wo ich eigentlich keine brauche. Und eine komplett verkorkste Elektrik (Lichtschalter schaltet Wandsteckdosen, ...). Deshalb habe ich irgendwann angefangen, LED Streifen an die Decke zu montieren und ein paar HUE/Osram-Birnen eingeschraubt. Die LED Streifen sind mittels Komponenten von Dresden-Elektronik an die HUEBridge angebunden. Zum Ein-/Ausschalten verwende ich EnOcean-Schalter (PTM215). Gesteuert wird alles via FHEM.
Jetzt ist es halt so, dass die Wohnung bei einem FHEM-/Router-/HUEBridge-Ausfall dunkel bleibt. Und das ist eher unpraktisch.
Wonach müsste ich also suchen, wenn ich gerne Lichtschalter (noch besser: Drehdimmer) hätte, die die LED-Strips immer an/aus schalten können und zusätzlich den Status an FHEM senden bzw. über FHEM gesteuert werden können?
Oder wie löse ich das überhaupt wenn ich, sagen wir mal, EnOcean als Protokoll weiterverwenden möchte?

Danke!
Stefan

connormcl

#10
Der alternative Weg muss halt entweder vom Gerät unterstützt werden oder man muss einen Zweiten Schaltweg einbauen...oder man kauft ein anderes...

Hier haben die "Billig"-Aktoren zusätzlich zum Preis ausnahmsweise mal die Nase etwas vorn, denn eine Notwendige Zentrale für Funk-Funktionalität schränkt im Fehlerfall zu sehr sein.

Bspw. Intertechno-Steckdosen:
a) Die Steckdose wird direkt über die Fernbedienung angelernt. Den gleichen Code benutzt FHEM -> Steckdose kann über beide geschaltet werden.

b) Alternative: Die Fernbedienung benutzt einen anderen Code wie FHEM. Die Steckdose kann aber auf mehrere Codes angelernt werden -> Steckdose kann über beide geschaltet werden.

Bspw. UP-Aktoren für Rolladen und Lichtschalter:
Hier habe ich darauf geachtet, dass alles den vorhandenen Lichtschalter weiterverwendet und noch über diesen zusätzlich geschaltet werden kann und Conrad RSL sowie auch Intertechno kompatibles verwendet. Zusätzlich gibts hier auch Handfernbedienungen -> Man hat drei Wege um zu schalten.

Bspw. RGB-Strip-WLAN-Schalter UFO:
Vorausgesetzt WLAN läuft, ist schalten ist möglich über FHEM-Modul oder über eine Handy-App -> Alternativer Weg verfügbar

Da bei vielen Leuten ein Raspberry-PI den FHEM beherbegt: die SD-Karte ist der größte Schwachpunkt und geht gerne im laufenden Betrieb hops. Hab bei mir mittlerweile alle Dateisysteme auf Read-Only laufen und genügen Images gezogen, so dass die SD-Karte schnell ersetzt ist.

Bspw. Solarlampen im Garten:
Können über Homematic geschaltet werden, haben ihm Fehlerfall noch einen Bewegungssensor verfügbar, der dann aber erst spät schaltet, wenn man in die Nähe kommt.

Da bei vielen Leuten ein Raspberry-PI den FHEM beherbegt: die SD-Karte ist der größte Schwachpunkt und geht gerne im laufenden Betrieb hops. Hab bei mir mittlerweile alle Dateisysteme auf Read-Only laufen und genügen Images gezogen, so dass die SD-Karte schnell ersetzt ist.

Beta-User

Zitat von: connormcl am 10 April 2018, 12:12:30
Hier haben die "Billig"-Aktoren zusätzlich zum Preis ausnahmsweise mal die Nase etwas vorn, denn eine Notwendige Zentrale für Funk-Funktionalität schränkt im Fehlerfall zu sehr sein.
Das ist m.E. etwas pauschal bis irreführend formuliert:

Es ist ausreichend, wenn die Funktionalität in Hardware abgebildet ist - deswegen funktioniert auch der HM-Bewegungsmelder wie von  dir geschildert, nur eben mit dem Vorteil, dass der tatsächliche Schaltzustand bekannt ist und nicht wie bei IT oder RSL "geraten" werden muß.
Soweit mir bekannt is, kennen praktisch alle "besseren" Gerätefamilien eine Art "peering" (HM-Sprech), also insbesondere auch Z-Wave, enocean oder zigbee, das heißt halt jeweils anders. Damit könnte drhirn also auch einfach eine Fernbedienung oder einen Schalter aus dem HUE-kompatiblen Sortiment nehmen und den jeweils anlernen (kann sein, dass man dann die Bridge trotzdem braucht, aber "wenigstens" nicht mehr FHEM und ein funktionierendes Netzwerk). Oder eben enOcean-Aktoren, wenn die Schalter bleiben sollen.

Kritische Kommentare zum Thema WLAN hatte ich ja schon genug geäußert - für eine "alternative und sichere" Schaltoption kommt mir das jedenfalls nicht ins Haus...

Just my2ct.

Beta-User
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Wuppi68

Ich habe es mir "einfach" gemacht :-)

Alle Zugänge sind entsprechend dokumentiert. Fast alles läuft auch ohne FHEM. Und der Hinweis, dass es hier im Forum genug Spezialisten gibt, die ggfls. unterstützen können ;-)

KNX ist ohne die Projektdatei auch nicht der Hit um es an einen fremden Elektriker weiter zu geben
Jetzt auf nem I3 und primär Homematic - kein Support für cfg Editierer

Support heißt nicht wenn die Frau zu Ihrem Mann sagt: Geh mal bitte zum Frauenarzt, ich habe Bauchschmerzen

svenson08

Zitatt, wenn ich z.b. auf der Fahrt zur oder von meiner Arbeitsstätte schlimmstenfalls tödlich verunglücke
Genua dieses Szenario habe ich erlebt. Begabter Bastler stirbt plötzlich. Die Frau ist hoffnungslos überfordert. Selbst ich schaffe es bis heute nicht alles durchblicken was der Verstorbene gebaut hat. Und die Doku von Ihm ist Weltklasse - aber nicht aktuell gewesen. In dem Fall geht es nicht mal um FHEM und ein SmartHome, sondern um banalere Dinge......

Vor gut 1,5 Jahren hab ich mir eine Ähnliche Frage gestellt. Was ist wenn ich urplötzlich unter der Erde liege. Und meine Antwort im Bezug auf SmartHome und deren Gimmicks war, das auch meine Familie nicht auf SmartHome verzichten soll. Wenn ich nicht mehr bin nehm ich den gewonnen Komfort mit ins Grab? Hautpsache das Minimum geht? Das entspricht nicht meiner Vorstellung wie ich etwas hinterlassen wollte und habe (bin noch dabei) auf KNX gesetzt. Damit kommen regionale Elektriker klar - hab ich vorher abgeklärt. Projektdatei samt Lizenz ist mein. Ist eine Investition in ein Hobby.

Prof. Dr. Peter Henning

Ich denke, hier muss ein "Digitales Testament" her: Was kann man tun, wenn derjenige, der das System aufgesetzt hat, eben nicht mehr da ist ?

Das wird nicht nur wegen des Themas "Hausautomatisierung" immer wichtiger. Passwörter, Accounts etc. müssen auch geklärt werden - und man sollte sich nicht erst nach dem  Tod des lieben Angehörigen darum kümmern, wie man dessen digitales Erbe löscht, archiviert oder konserviert.

LG

pah