Einstieg ins Smarthome

  • Hallo,

    das Thema Smarthome interessiert mich schon eine ganze Weile und ich habe auch immer mal hier und da etwas dazu mitgelesen.
    Dadurch weiß ich schon mal grob was mich erwartet und dass das Thema komplex ist...

    Jetzt hat sich eine konkrete Anforderung ergeben, durch die ich das Thema aufgreifen und einsteigen möchte.

    Die Frage ist nur:
    Wie gehe ich das von Anfang an richtig an?


    1. Anforderung: Smarte Katzenklappe


    Ausgangssituation:
    Aufgrund baulicher Gegebenheiten wurde eine Katzenklappe mit RFID-Öffnung im Außenbereich angebracht.
    Ich müsste jetzt irgendwie signalisiert bekommen, wenn die Klappe passiert wird.
    Und das möglichst nur dann wenn es regnet oder nachts.

    Was ich grundsätzlich möchte:

    • keine "Insellösungen" einzelner Hersteller sondern ein zentrales System mit möglichst einheitlichem Standard
    • eine Lösung die gänzlich ohne Cloudanbindung auskommt
    • eine drahtlose Lösung
    • ein System das ich nach belieben erweitern kann

    Gegeben sind bereits ein Unraid-Server, ein separates Netzwerk für die Smarthome-Geräte, Ubiqiti-WLAN nach Wifi6-Standard.


    Die Überlegung war jetzt, an der Katzenklappe einen Türsensor anzubringen. Hier hatte ich mir bereit Aquara und Sonoff angesehen, da diese über Zigbee angebunden werden, was stromsparender (und günstiger sein dürfte, als z.B. das Wifi-Gegenstück von Shelly.
    Für die Anbindung der Zigbee-Komponenten hätte ich jetzt einen CC2531 USB-Stick an den Unraid-Server angeschlossen und in einen Zigbee2MQTT-Docker durchgereicht.
    Alternativ hatte ich mir das Zigbee-Gateway von Sonoff angesehen. Unter Verwendung von Zigbee2Tasmota auf dem Gerät wäre ich von der Reichweite her vermutlich flexibler als bei der Variante mit dem USB-Stick, da der Aufstellort des Unraid-Servers für eine Funkabdeckung der ganzen Wohnung eher ungünstig sein dürfte.

    Als zentrale Steuerungssoftware würde ich dann gerne ioBroker verwenden. In OpenHab hatte ich vor einiger Zeit schon mal kurz reingeschnuppert. Von der Programmierung her tendiere ich anhand dessen was ich bereits an Einblicke hatte aber eher zu ioBroker.
    Über entsprechende Adapter könnte ich dann Regeln für die Benachrichtigung bauen.

    Weitere Smarthome-Projekte würden folgen.


    Kann bzw. wird das so funktionieren?
    Welche Empfehlungen würdet ihr mir geben?
    Ist die Kombination aus Zigbee-Sensoren, einem entsprechendem Gateway und ioBroker sinnvoll?
    Eher Zigbee-Gateway oder CC2531-Stick?
    Eher Sonoff oder Aquara?
    OpenHab oder ioBroker?....
    Gibt es sonst noch was zu beachten?
    Irgendwelche Tipps von den Experten? :)

  • Ja das kann so funktionieren. Ich kann jetzt nur für NodeRed Sprechen aber da wäre das mit ein paar Blöcken zusammen geklickt.

    Mit dem Aqara Sensor machts du nichts falsch, habe da einigen von im Einsatz. Halten mit ne Batterien ewig und sind zuverlässig.
    Die Sonoff Bridge würde ich nicht nehmen, die war bei mir recht unzuverlässig, nimm lieber den Stick: https://www.berrybase.de/sonoff-zigbee-3.0-usb-dongle-plus

    Welches System du dahinter verwendest ist wohl aus Geschmackssache. Einen MQTT Broker würde ich im Hintergrund immer laufen lassen und mittels Zigbee2MQTT beschicken lassen.

    Ich nutze NodeRed für die Logik und ein bisschen Home Assistant für die GUI, aber GUI brauche ich nicht viel, schließlich ist ein Smart Home nur Smart wenn es möglichst viel selber macht.
    @horschte nutzt sehr Ausgiebig OpenHab, ist so unser Openhab Guru.
    @BigChris nutzt soviel ich weiss IOBroker.

  • Die Überlegung war jetzt, an der Katzenklappe einen Türsensor anzubringen.

    Daran dachte ich auch als erstes als ich es gelesen hab. [ag]

    Kann bzw. wird das so funktionieren?

    Klar.

    Ist die Kombination aus Zigbee-Sensoren, einem entsprechendem Gateway und ioBroker sinnvoll?

    Ja klar, nutzen doch viele so.

    Eher Zigbee-Gateway oder CC2531-Stick?

    Ich würde den Stick nehmen. Bei mir ist der Standort auch nicht ideal aber durch das Mesh-Netzwerk funktioniert es trotzdem gut. Zu beachten ist, dass die Chips mit P-Endung mehr Power haben, also würde ich so einen empfehlen. Zusätzlich würde ich den Stick nicht direkt anschließen sondern ein USB-Verlängerungskabel zwischen hängen (wird auf der zigbee2mqtt-Seite auch so empfohlen).

    Eher Sonoff oder Aquara?

    Warum entscheiden? zigbee2mqtt unterstützt doch beides. Oder geht es jetzt speziell um den Fensterkontakt? Ich nutze hier den vom Lidl und bin zufrieden.

    OpenHab oder ioBroker?....

    Kann ich so nicht beantworten. Ich nutze schon länger openHAB und bin zufrieden. Habe aber auch schon viele Jahre nicht mehr in ioBroker reingeschaut, was sich dort so getan hat. Ich denke mal du wirst in beiden Fällen glücklich werden.

    Gibt es sonst noch was zu beachten?

    Irgendwelche Tipps von den Experten? :)

    Viel Geduld mitbringen. [ag]

  • Super, danke schon mal für den Input.
    Jetzt weiß ich schon mal dass ich nicht auf dem Holzweg bin.
    Und jede Erfahrung die hier eingebracht wird ist hilfreich für mich.
    Mir ist klar, dass ich bei der Thematik viel Zeit mitbringen muss und mich in verschiedene Bereiche einlesen werden muss.
    Aber so tappe ich schon mal nicht komplett im Dunkeln sondern habe eine grobe Richtung in die ich mich orientieren kann.


    Ich würde den Stick nehmen. Bei mir ist der Standort auch nicht ideal aber durch das Mesh-Netzwerk funktioniert es trotzdem gut.

    Wie funktioniert denn das Mesh bei den Zigbee-Geräten?
    Brauche ich da Repeater oder können das alle Teilnehmer im Netzwerk automatisch?
    Hätte ja in der "ersten Ausbaustufe" jetzt nur den USB-Stick am Server und den Sensor. Der USB-Stick wäre auch mit Verlängerung via USB-Kabel von viel Metall umgeben. Reine Luftlinie lägen knapp 20m dazwischen, sowie 2 Außenwände (massiv 30cm Stein) und 2 Innenwände (Gispkarton beidseitig doppelt beplant in Metallständerbauweise).


    Die Sonoff Bridge würde ich nicht nehmen, die war bei mir recht unzuverlässig

    Die Sonoff-Bridge war jetzt nur ein Beispiel. Könnte natürlich auch ein anderer Hersteller sein wenn das Gerät zuverlässiger arbeiten würde.


    Warum entscheiden? zigbee2mqtt unterstützt doch beides. Oder geht es jetzt speziell um den Fensterkontakt? Ich nutze hier den vom Lidl und bin zufrieden.

    Hatte gedacht es gäbe vielleicht Vorteile wenn man hier bei einem Hersteller bleibt.
    Grundsätzlich bin ich da flexibel.
    Wichtig wäre mir halt eine gute Reichweite, Zuverlässigkeit, lange Batterielaufzeit und eine gewisse Wetterfestigkeit wäre speziell für diesen Anwendungsfall hier noch relevant.

    Die Lidl-Teile kämen natürlich auch in Frage. Die und Sonoff funken wohl mit Zigbee 3.0 und die Aquaro "nur" mit 2.0. Ob das einen Unterschied macht bzw. welche Nachteile sich darauf ergeben könnten konnte ich aber bisher noch nicht in Erfahrung bringen.

    Bei Lidl hab ich eben auch die smarten Rauchmelder entdeckt. Das wäre dann eine der nächsten Baustellen :D

  • Vorteile bei einem Hersteller zu bleiben hat man eigentlich nur bei proprietären Systemen, wie bspw. Homematic bzgl. direktverknüpfungena bspw.

    Möchtest du aber immer ein System (Node Red, Home Assistant, openHAB.....) nutzen ist es grundsätzlich egal was von wem. Hier bietet es sich dann nur an bei einem Protokoll zu bleiben. Bedingt durch zigbee und MQTT hast du die eigentlich besten zwei Protokolle für DIY Dinge erwischt.

    NAS: Gehäuse: Jonsbo G3, Mainboard: MSI B460M PRO, CPU: Intel Pentium G6400, OS: OMV 6

    Client: NVIDIA Shield Pro 2019

  • Bedingt durch zigbee und MQTT hast du die eigentlich besten zwei Protokolle für DIY Dinge erwischt.

    Dann bin ich ja auf der richtigen Spur :)
    Ja, soll alles DIY bleiben. Ich möchte mich nicht von Herstellern oder deren Ökosystemen abhängig machen. Außerdem möchte ich selbst die Möglichkeit haben in Vorgänge einzugreifen bzw. nach meinen Vorstellen zu gestalten. Ohne Restriktionen durch Herstellervorgaben.
    Was mir außerdem wichtig ist: Es sollte sichergestellt sein, dass ein eventueller Zugriff der Geräte auf eine Herstellercloud nachhaltig unterbunden werden kann. Also z.B. durch das Flashen einer Tasmota-Firmware oder ähnliches.

    Berührungsängste oder Hemmungen etwas selbst zu machen habe ich eigentlich keine.
    Dafür schätze ich aber den Lerneffekt der entsteht wenn ich etwas eigenständig erreichen konnte. Außerdem reizt mich die Herausforderung dass dann nicht nur iiirgendwie lauffähig zu bekommen sondern so zu beherschen dass es reibungslos und wartungsarm läuft.

  • dann will ich nur aus eigener erfahrung dazu sagen, dass ich gelernt hab, doch immer lieber über die herstellereitigen methoden die geräte anzusprechen.
    genauer gesagt: hab ich homematic, verwend ich ein hmlan, hab ich hue, verwende ich auch das und keine bastellösungen.
    mit der erwähnten software (und auch fhem, dass ich verwende), ists ja kein problem das alles dann zu verbinden.
    macht man hier bastellösungen - währe ja z.b kein problem, so ziemlich jedes protokoll gleichzeitig mit einem raspi zu fahren - kostet einem das gerne mal funkqualität oder sonstige einschränkungen.

    btw - hm direktverbindungen kann man bei fhem (bei anderen weiß ichs ned) auch fhem-intern anlegen. das wäre dann das berühmte peeren, was immer alle mit pairen verwechesln

    aja - wenn mit cloud "kein internet" gemeint ist, wirds auch gern eng.
    eine wettervorhersage oder z.b. auch anrufer rückwärts-suche macht die automatisation auch ein stückerl schöner und informativer.

    ich benutze übrigens fhem und als hw homematic (ohne ip), philips hue, div. ir-sender und alles, was man über div. netze an elektrogeräten im haus einbinden kann (computer, shields, androiden, drucker, 3d-drucker, ...) also quasi alles *g*
    protokolle sind mir scheiß egal, weil das eh fhem für mich zusammen führt.
    ich benutze definitiv nix mit cloud und auch keine sonstigen geräte zum öffnen von türen oder cams und würde das auch niemals empfehlen.

  • protokolle sind mir scheiß egal, weil das eh fhem für mich zusammen führt.

    Das Thema Zuverlässigkeit sollte natürlich auch bei einer DIY-Lösung gegeben sein.
    Aber wenn ich jetzt z.B. die Sonoff-Türkontakte mit einem zugehörigen Gateway nehm, die ja über Zigbee funken, sollte es nach meinen Verständnis für die Zuverlässigkeit keinen Unterschied machen, ob ich die Hersteller-App nutze, oder eine andere App die ebenfalls Zigbee beherscht.
    Was ich aber nicht möchte, ist ein Sammelsurium verschiedener Standards, Protokolle und Schnittstellen für das ich dann verschiedene Bridges, Gateways oder sonstige Empfänger brauch. Daher suche ich bewusst nach einer offenen, allgemeinen Schnittstelle an die ich mit Geräten unterschiedlicher Hersteller bei Bedarf andocken kann.


    aja - wenn mit cloud "kein internet" gemeint ist, wirds auch gern eng.
    eine wettervorhersage oder z.b. auch anrufer rückwärts-suche macht die automatisation auch ein stückerl schöner und informativer.

    Damit meinte ich, dass die Sensoren/Aktoren etc. ohne eine Anbindung ans Internet und insbesondere einer Herstellercloud funktionieren können. Die Kommunikation soll rein lokal (ggfs. über ein erforderliches Gateway) mit der Smarthome-Zentrale (ioBroker/OpenHab/...) funktionieren.
    Hersteller sollen keinen Zugriff auf meine Geräte haben und auch keine Informationen darüber erhalten wann was wie geschaltet wurde. Nicht mal Telemetriedaten.
    ioBroker selbst darf natürlich Wetterinformationen und dergleichen online abrufen.

  • @the ratman
    Daher ja zigbee und MQTT, da ist es egal welchen Hersteller man nimmt, weil auf Protokollebene gesprochen wird. Dabei ist es dann wurscht ob man das Gateway von Xiomi, Lidl, Aqara oder sonst wen nimmt, alle sprechen zigbee.
    Zusätzlich gibt es auch diverse Geräte, welche direkt MQTT sprechen können, somit hat man ein mit den beiden Protokollen zwei Zugangspunkte in System:

    1. Für Zigbee: Gateway (der hier verlinkte Stick)
    2. Für MQTT: WLAN

    Dann nutzt man das angesprochene zigbee2mqtt und hat dann zentral alles unter MQTT ansprechbar, wenn man Geräte mit nativem MQTT nutzen möchte (bspw. Shelly).
    Also primär im Fokus zigbee und alles was damit nicht geht (gibt eigentlich fast nix was es nicht mit zigbee gibt) dann mit MQTT lösen.

    Damit ist man dann, wenn man will, komplett Cloud unabhängig und kann sich optional über sein System (HA, openHAB, ioBroker etc.) Zusatzfunktionen/Features ins System holen, die aber optional sind/sein sollten.

    @psychofaktory
    Was man aber bedenken sollte ist leider, dass man beim Abweichen von den Hersteller Gateways meines Wissens nach keine Firmware-Updates mehr auf die Endgerät kriegt.
    Bspw. bei den Ikea LED-Controllern werden diese über zigbee angesprochen. Nun kann ich sie entweder über den zigbee Stick in mein System einbinden und bedienen, ohne Probleme, oder über das Ikea Gateway mit der App bedienen und auch Updates einspielen und das Gateway in mein Home Assistant einbinden, funktioniert auch.

    Natürlich muss man das Thema "Updates" relativieren. Warum etwas updaten wenn man dafür nichts erhält? Nicht ohne Grund gibt es den Spruch Never Change a running System.
    Liegt eine funktonale Einschränkung oder ein sicherheitsrelevantes Problem vor, klar updaten, ansonsten hat man von nem Update grundsätzlich nix.

    NAS: Gehäuse: Jonsbo G3, Mainboard: MSI B460M PRO, CPU: Intel Pentium G6400, OS: OMV 6

    Client: NVIDIA Shield Pro 2019

  • Was ich aber nicht möchte, ist ein Sammelsurium verschiedener Standards, Protokolle und Schnittstellen für das ich dann verschiedene Bridges, Gateways oder sonstige Empfänger brauch. Daher suche ich bewusst nach einer offenen, allgemeinen Schnittstelle an die ich mit Geräten unterschiedlicher Hersteller bei Bedarf andocken kann.

    blieb mir nix anderes übrig, weil meine automatisation gewachsen ist - anfangs war das nur 1 lightstripe im neu umgebauten schlafzimmer und ist mittlerweile ausgeufert. ich verwende auch keine tools vom hersteller, kann eh alles auch fhem.
    was ich meinte ist, die hardwareseitigen gateways der hersteller zu verwenden, anstelle bastellösungen.

    wenn ich so drüber nachdenke, dann gings auch jetzt nicht, auf nur 1 protokoll zu setzen. bei manchen sensoren ist firma x gut, bei anderen firma y und firma z liefert die besseren/schöneren aktoren.
    an der vielfalt der möglichkeiten sehe ich ja gerade auch den vorteil unserer heimautomatisationen. man ist eben nicht auf einen hersteller und auch auf kein protokoll beschränkt.
    einziges problem, dass ich damit bisher hatte: die hue und das hmlan in ein und denselben schrank zu betreiben war keine gute idee in sachen funk *g* nun sinds getrennt in verschiedenen ecken und alles ist gut.

    wie gesagt, mit protokollen muss man sich bei fhem nicht auseinandersetzen, man muss nur vorher schauen, obs auch ein modul für den hersteller oder das protokoll gibt. und ich gehe davon aus, dass das auch bei anderen systemen kein problem sein wird.

  • Was man aber bedenken sollte ist leider, dass man beim Abweichen von den Hersteller Gateways meines Wissens nach keine Firmware-Updates mehr auf die Endgerät kriegt.

    Das ist ein guter Punkt!
    Was ich herausgefunden habe ist, dass es scheinbar grundsätzlich schon die Möglichkeit gibt Updates über Zigbee2MQTT auszurollen, aber eben nur für bestimmte Geräte:
    https://www.zigbee2mqtt.io/guide/usage/ot…ailable-updates

    Die bisherigen Erkenntnisse werfen folgende Fragen auf:

    • welcher Hersteller wäre für Türkontakte auch hinsichtlich der Updatefähigkeit über Zigbee2MQTT empfehlenswert?
    • welches Zigbee-Gateway wäre empfehlenswert?
    • Macht es in der Praxis einen Unterschied ob Zigbee 2.0 oder 3.0?
    • Wie funktioniert das Zigbee-Mesh bzw. welche Voraussetzungen sind dafür nötig?

    blieb mir nix anderes übrig, weil meine automatisation gewachsen ist

    Deswegen frage ich hier bewusst vor meinem Einstieg in die Smarthome-Welt, um einen unnötigen Wildwuchs bei Hard- und Software zu vermeiden ;)
    Will ja auch administriert und unterhalten werden alles...
    Meine Erfahrung hat mir gezeigt, dass es im Allgemeinen deutlich einfacher wird, wenn es eine einheitliche Basis gibt auf der man dann sauber aufbauen kann.

  • Wie funktioniert denn das Mesh bei den Zigbee-Geräten?

    Brauche ich da Repeater oder können das alle Teilnehmer im Netzwerk automatisch?
    Hätte ja in der "ersten Ausbaustufe" jetzt nur den USB-Stick am Server und den Sensor. Der USB-Stick wäre auch mit Verlängerung via USB-Kabel von viel Metall umgeben. Reine Luftlinie lägen knapp 20m dazwischen, sowie 2 Außenwände (massiv 30cm Stein) und 2 Innenwände (Gispkarton beidseitig doppelt beplant in Metallständerbauweise).

    In der Regel funktionieren alle Geräte, die dauerhaft am Strom hängen (also ohne Batterie) z.B. eine Steckdose oder eine Lampe als Repeater. Ich habe teilweise auch mehrere Wände (auch außen) dazwischen und es klappt. Ich weiß halt nicht ob es bei dir so funktioniert. Ich würde an deiner Stelle es einfach ausprobieren (und auf jedenfall so einen P-Chip nehmen mit höherer Sendeleistung). Wenn es wirklich nicht reicht, kannst du z.B. so eine Steckdose zwischen hängen (die Dinger kann man immer gebrauchen).

    Hatte gedacht es gäbe vielleicht Vorteile wenn man hier bei einem Hersteller bleibt.

    Grundsätzlich bin ich da flexibel.
    Wichtig wäre mir halt eine gute Reichweite, Zuverlässigkeit, lange Batterielaufzeit und eine gewisse Wetterfestigkeit wäre speziell für diesen Anwendungsfall hier noch relevant.

    Prinzipiell ist es scheiß egal wie du kombinierst. Dafür ist ja zigbee2mqtt da, sonst könntest du auch z.B. eine Hue-Bridge oder so nehmen. Du wirst halt irgendwann an einen Punkt kommen, wo du etwas haben willst, was dieser Hersteller nicht anbietet und dann musst du kombinieren. Es gibt auf YouTube teilweise Vergleichsvideos, musst du mal schauen (ich hatte da im Bereich Bewegungsmelder mal geschaut). Im Bereich Festerkontakt hab ich nur selbst Erfahrung mit den Lidl-Dingern und die sind für mich perfekt (wobei könnten kleiner sein). Bzgl. Wetterfestigkeit kann ich dazu gar nichts sagen, da ich die nur innen verbaut habe. Wenn du willst, schaue ich aber mal in der Anleitung nach ob da was steht. Aber ich denke wenn du den Kontakt innen an die Katzenklappe baust, ist das sowieso kein Problem.

    Vorteile bei einem Hersteller zu bleiben hat man eigentlich nur bei proprietären Systemen, wie bspw. Homematic bzgl. direktverknüpfungena bspw.

    Das stimmt aber das Problem ist halt, dass es keinen Hersteller gibt, der alles anbietet und du somit irgendwann an den Punkt kommst, wo eine Direktverknüpfung nicht mehr geht.

    eine wettervorhersage oder z.b. auch anrufer rückwärts-suche macht die automatisation auch ein stückerl schöner und informativer.

    Stimmt, manche Sachen gehen einfach nicht ohne Internet. Da muss man selbst abwägen, ob es Sinn macht oder nicht. Eine Rückwärtssuche (nutze ich auch) ist halt etwas komfort. Wenn das aber mal ausfällt, ist es auch nicht so tragisch. Es ist wichtig, dass Hauptfunktionalität auch ohne Internet funktioniert.

    Was man aber bedenken sollte ist leider, dass man beim Abweichen von den Hersteller Gateways meines Wissens nach keine Firmware-Updates mehr auf die Endgerät kriegt.

    Ja und nein. Teilweise werden OTA Update in zigbee2mqtt unterstützt, die man auch über die GUI oder das Terminal ausführen kann.

    Natürlich muss man das Thema "Updates" relativieren. Warum etwas updaten wenn man dafür nichts erhält? Nicht ohne Grund gibt es den Spruch Never Change a running System.

    Liegt eine funktonale Einschränkung oder ein sicherheitsrelevantes Problem vor, klar updaten, ansonsten hat man von nem Update grundsätzlich nix.

    Das sehe ich auch so!

    wenn ich so drüber nachdenke, dann gings auch jetzt nicht, auf nur 1 protokoll zu setzen. bei manchen sensoren ist firma x gut, bei anderen firma y und firma z liefert die besseren/schöneren aktoren.
    an der vielfalt der möglichkeiten sehe ich ja gerade auch den vorteil unserer heimautomatisationen. man ist eben nicht auf einen hersteller und auch auf kein protokoll beschränkt.

    Richtig, Deshalb gibt es ja auch FHEM, ioBroker, openHAB und co.

  • eines fällt mir halt auch noch ein, das nicht so schön ist, bei unseren lösungen:

    100% ausfallsicherheit würde ich nicht zertifizieren. ist halt bei unsern lösungen wie bei kodi - viel zu viele leute, die viel zu viel basteln *g*
    irgendwann mal findet sich da eine dumme kombination nach einem update. aber zumindest von fhem kann ich sagen, dass die probleme auch sehr schnell aus der welt sind.
    wenn mal ausnahmsweise im forum dort keiner nach 5 minuten auf mein mimimi reagiert, dann spielt man halt schnell mal das automatisch erstellte backup von gestern zurück.

    dies nur, damits nicht untergeht, und irgendjemand glaubt, auf solch freien systemen scheint die sonne 24 stunden lang am tag.

  • @the ratman immerhin kann man selbst eingreifen, den Fehler finden und (ggfs. mit Hilfe einer Community) beheben.
    Das würde ich in jedem Fall vorziehen, anstatt dem Support eines bestimmten Herstellers und dessen Willkür auf Gedeih und Verderb ausgeliefert zu sein und zu hoffen dass Geräte nicht gar noch irgendwann durch den Hersteller unbrauchbar gemacht werden (siehe Sonos Recylingprogramm und andere Beispiele).

  • ist auch meine rede.

    wollts auch nur erwähnt haben, weil ausfallen tut immer alles am besten am 1. tag im urlaub. gut, auch selten ein problem mit 'nem vpn in die heimat, aber man muss sich dem problem halt bewusst sein. man hat keinen, den man schimpfen kann *g*
    wenn ich mir allerdings anschaue, welche probleme man mit div. professionellen hersteller support hat - ich hab da persönliche 'ne vendetta mit dremel und neato - dann ist meine fhem-community echt geilst dagegen.

  • Gut, das sind jetzt natürlich ganz allgemein gültige Aussagen.
    Ich betreibe auch Kodi mit zig Add-Ons auf verschiendenen Endgeräten an verschiedenen Standorten, betreue mehrere NAS-Systeme unterschiedlicher Hersteller sowie Telefonanlagen, Serversysteme, Unraid-Server (inkl. an die 30 Docker), OPNsense-Firewalls (mitunter auch virtuell unter Unraid), Homepages, Smartphones von Freunden und Familien allesamt mit Custom-ROMs und einen eigenen Mail-Server...
    Und das alles läuft sehr zuverlässig und wartungsarm. Selbst nach Updates fange ich da nicht an zu schwitzen.
    Von daher hab ich vor dem Smarthome-Thema jetzt auch nicht unbedingt Angst :)

    Achja, und ich bastel da schon gerne überall dran rum...
    Aber das meinte ich vorhin damit dass ich nicht einfach nur möchte das etwas irgendwie zum laufen gebracht wird, sondern ich möchte mich mit dem System dann auch so weit auseinandersetzen, dass ich verstehen und nachvollziehen kann wie es funktioniert. Nur so kann ich es letzten Endes nicht nur in Betrieb nehmen, sondern eben auch langfristig vernünftig betreuen.

  • jo, ist schön bei fhem - du hast backups aller geänderten files aufgeteilt auf die letzten 3 tage und das machen eines backups von fhem gesamt, kannst du automatisieren, oder per knopfdruck erledigen.
    man muss halt im worst case wenigstens mal telnet oder tools wie winscp bemühen und wissen, wie man files den richtigen user und rechte zu weist. das wars dann aber eh schon ...

    bei fhem hast du eher das problem, dass irgendein modulautor die vorgaben verpennt hat, oder sich halt selber nicht so gut auskennt mit perl.
    da krachts dann halt gerne mit unterstützungsmodulen, die der in seinem modul verwendet. jo mei, shit happens.

    ich update übrigens täglich. grund:
    ich seh immer wieder, dass keiner die fehler meldet und so kann ich den fhem-leuten wenigstens irgendwas zurückgeben ... fehlermeldungen mit allen daten, die sie brauchen.
    weil ansonsten kann ich aufgrund programmier-legastenie und technischer verdummung eh nix zurückgeben *g*

  • ui hier ist es ja schon voll und du hast eigentlich genug kompetente beratung.

    Die Rückmeldungen hier sind wirklich spitze. [ay]
    Danke dafür.

    Daraus resultierend habe ich jetzt den empfohlenen Sonoff ZigBee 3.0 USB Dongle Plus sowie einen Xiaomi Mi Door and Window Sensor 2 (ebenfalls mit Zigbee 3.0) bestellt.
    Sobald das angekommen ist, werde ich alles mal zusammenbasteln und mich an die softwareseitige Einrichtung wagen.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!