IoT - was wird empfohlen?

L I V E Stammtisch ab 20:30 Uhr im Chat
  • Hallo allerseits,

    mein Thema hat gar nicht wirklich mit Raspberry zu tun, höchstens im zweiten Schritt. Aber ich bin hier wohl doch richtig.

    Ich habe ein Haus, da bin ich aber nicht immer. Dann denke ich "habe ich das Dachfenster verschlossen?" oder die liebste Gattin fragt "ist der Herd aus?" - man kennt das ja.

    Die Sensoren müssten WiFi sein. Ich schaue und falle fast um: Cloud (nein, ich möchte nichts mit Cloud) und Preise jenseits von gut und böse. "Conrad Connect" hat immerhin Technik, aber irgendwie auch Cloud und Tab und Handy. Will ich alles nicht - ich habe im Hausnetz Server und https und ssh und VPN, die Richtung ist also klar.

    Ich fände ja ganz prima, wenn die künftigen Sensoren artig via WLAN an einen Server im Hausnetz die Daten senden. Um die Auswertung (Grafiken usw) kümmere ich mich notfalls selbst.

    Ehe ich mich in völlig falsche Richtungen einarbeite, frage ich lieber die Profis - also euch. Ich fand (ohne mich da einzuarbeiten!) http://nodered.org - da schreckt mich node.js sofort ab. Ich fand auch https://fhem.de - das klingt auf den ersten Blick gut.

    Ehe ich mich verrenne:
    Was ist aus eurer Sicht zukunftsweisend, hält also länger als 5 Jahre? Lufttemperatur, Öffnungsmelder, vielleicht noch IoT-Krempel eines in Deutschland bevorzugten Standards - damit wäre ich schon zufrieden.

    Was ratet ihr mir?

  • Was es in 5 Jahren (oder mehr) im IoT-Bereich (noch) geben wird, kann keiner sagen.
    ICH persönlich verwende FHEM, da es eine große Community hat und ich mich schnell einarbeiten konnte.
    Als Sensoren/Aktoren habe ich haupsächlich Homematic im Einsatz, ein paar Z-wave Produkte und einige Temp/Druck/Feuchte/Licht-Sensoren, sowie die Steuerung meiner Rollo-Gurtwickler mittels ESP8266 selbstgebaut.

    Anfragen ausserhalb des Forums (Mail o.ä.) werden ignoriert!

  • Hallo Mart,

    bei Deinen beiden Beispielen tue ich mich etwas schwer. Eine "Fenster offen"-Erkennung könnte man per Reed-Kontakt realisieren. Wie sieht es aber mit Deiner Bereitwilligkeit aus, Kabel zu ziehen? Oder willst/mußt Du auf Funk setzen? Das kann u.U. größeren Einfluß auf die Art der Realisierung haben, als die Wahl des Automationssystems - fhem, openHAB, Homematic...
    Einen Herd zu kontrollieren ist schon erheblich komplizierter. Da müßte man ggf. Strom messen oder ein Wärmebild erkennen können. Hier wird die Auswahl an Sensoren sicher noch geringer ausfallen. Ich denke, Du solltest zunächst mal alle use cases zusammentragen. Danach kannst Du dann schauen, welche Hardware für Dich in Frage kommt und danach siehst Du dann, welches Automationssystem (oder welche Software) diese Hardware unterstützt.
    Mit den vorliegenden Informationen allein wirst Du Präferenzen aus der Sicht der jeweiligen Leute erhalten. Die können, müssen sich aber nicht mit Deinen Anforderungen decken.

    Schöne Grüße

    schnasseldag

  • Eine "Fenster offen"-Erkennung könnte man per Reed-Kontakt realisieren. Wie sieht es aber mit Deiner Bereitwilligkeit aus, Kabel zu ziehen?

    Ein ESP8266, der immer nur aus dem Deep Sleep aufwacht, wenn der Öffnungszustand des Fensters gewechselt wird, sollte mit einem Satz Ready-to-use Zellen (Eneloop o.ä.) schon ein Jahr auskommen.

    Einen Herd zu kontrollieren ist schon erheblich komplizierter. Da müßte man ggf. Strom messen oder ein Wärmebild erkennen können.

    Am einfachsten wäre dabei, wenn der Versorger zwangsweise einen von diesen neuen elektronischen Zählern in des Haus eingebaut hat. Die haben meistens eine prima Schnittstelle, die einfach anzuzapfen ist.

    Für einen eigenen Server, der die Daten der vielfältigen Sensoren bereitstellt, kann auch mal nach dem Stichwort MQTT gesucht werden. Für den ESP und auch für den RPi gibt es dafür fertige Bibliotheken und Programme.

    Marcus

    Einmal editiert, zuletzt von MarcusFE (29. Mai 2017 um 20:38)

  • Hallo allerseits,

    danke für die interessanten Antworten.

    Leider kann ich nicht mit Kondensatoren, Widerständen und Lötkolben umgehen. Und werde das wohl in diesem Leben auch nicht mehr lernen. Es geht schon um fertig zu kaufende Sensoren, die zudem WLAN können. Aber eben ohne irgendwelchen Cloud-Quatsch.

    Meine Hardware-Künste würden reichen, einen Pi Zero zu kaufen und da einen fertigen Sensor anzustecken. Aber damit ist dann die Grenze meiner Möglichkeiten erreicht.

    digiart
    Kannst Du mir bitte zwei oder drei einfache Sensoren als Produkte (Produktbezeichnung) nennen?

    schnasseldag
    Klar könnte ich use cases zusammentragen ... die dann (Stichwort Herd) doch nicht gehen. Ich möchte den anderen Weg gehen: Etwas wie FHEM zum Laufen bringen, aus Neugier zwei, drei verschiedene Sensoren probieren und spielend lernen.anderen Weg gehen: Etwas wie FHEM zum Laufen bringen, aus Neugier zwei, drei verschiedene Sensoren probieren und spielend lernen.

    Ja, das sollte schon WiFi sein. Wenn ich hier anfange Kabel zu verlegen, dann schlafe ich ab morgen im Schuppen. Aber nicht freiwillig.

    Meldung Fensteröffnung: Da dachte ich nun, dass das das Einfachste sei, dass es solche WiFi-Sensoren von der Stange gäbe. Denn das Problem taucht ja wirklich häufig auf.

    Einmal editiert, zuletzt von Mart (30. Mai 2017 um 01:53)

  • Zitat

    Ja, das sollte schon WiFi sein. Wenn ich hier anfange Kabel zu verlegen, dann schlafe ich ab morgen im Schuppen. Aber nicht freiwillig.
    Meldung Fensteröffnung: Da dachte ich nun, dass das das Einfachste sei, dass es solche WiFi-Sensoren von der Stange gäbe. Denn das Problem taucht ja wirklich häufig auf.

    Hallo mart,

    ja, als (evt. bessere) Spielerei - und als mehr solltest Du das auch nicht sehen - taugt das alles, irgendwie lässt sich vieles zum funktionieren bringen. Mehr oder weniger.

    Allerdings hat es tatsächlich einen Grund, dass Systeme, die nicht von einem cloudy-supderduper-Hipster-Hype-Startup kommen nahezu ausschließlich per Kabel angeschlossen werden und durch den Einsatz von Blei-(Gel)-Akkus auch dann noch funktionieren, wenn der Strom gekappt wird. Abgesehen nämlich vom fehlenden Sabotagealarm oder relativ einfach lahmzulegenden WLAN , gibt es noch nicht einmal eine Garantie, das z.B. der Fenster/Türkontakt tatsächlich funktioniert - der benötigt ja Batterien. Und nach Murphys law sind die genau dann am Ende, wenn das Fenster im Urlaub offen steht und wenn es (überhaupt) einen Batteriealarm gibt, dann entweder bei längerer Abwesenheit oder zwischen ein und halb vier Uhr nachts. WAF adé - doch Schuppen....

    Wenn es denn so gar keine Möglichkeit gibt, Kabel "unsichtbar" zu verlegen (ist der Schuppen eigentlich gemütlich hergerichtet?!? :D ), dann wäre wahrscheinlich eine stromsparendere Funkvariante besser. Ich meine, mit zigbee oder auf Basis 433/866 MHz Technik gibt's bestimmt was fertiges. Aber wie gesagt, für den professionellen Einsatz als Alarmanlage eher unbrauchbar und es kann Dir niemand sagen, ob es das System in Zukunft noch geben oder es unterstützt wird.

    Meine Empfehlung geht auch in die Richtung eines Systems mit breiter Community (fhem, OpenHAB o.ä.), da ist die Chance am größten, das Ganze noch in einigen Jahren nutzen zu können und es gibt im Gegensatz zu den derzeit coolen Klau-Cloud-Lösungen immer Möglichkeiten, genau ohne diese auszukommen. Auf den Webseiten der Systeme findest Du auch immer die unterstützten Sensoren und Aktoren. Danach kannst Du ja aussuchen, was Du Dir einrichtest.

    Gruß, STF

  • Als Fenster-offen Überprüfung habe ich die optischen Tür-/Fensterkontakte von Homematic im Einsatz (https://www.elv.at/homematic-ir-tuer-fensterkontakt.html).
    Zum Testen habe ich hier auch noch einen Z-wave Sensor liegen (http://www.sensative.com/strips.html).
    Steckdosen mit Strommessung habe ich auch hauptsächlich von Homematic, allerdings auch von Fibaro (Z-wave) und Devolo (Z-wave).
    3x S0-Zähler habe ich auch mittels selbstkonstruiertem und -gebautem ESP8266-Modul eingebunden.

    Anfragen ausserhalb des Forums (Mail o.ä.) werden ignoriert!

  • Hallo allerseits,
    danke für die vertiefenden Antworten, das hilft mir bei den Überlegungen vor Beginn sehr.

    STF
    Danke für Deine strategischen Überlegungen. Mir ist durchaus klar, dass ich keine professionelle Alarmanlage bekomme; die Grenzen sind mir klar. Ja, vielleicht meldet mal ein Fenstersensor nicht. Allerdings habe ich derzeit den Zustand, dass gar kein Fenstersensor meldet - ich habe ja keine.

    Die Idee ist eher, das spielerisch auszuprobieren - schon damit ich beim Thema IoT im realen Leben mit klugscheißern kann. Die Idee ist weiterhin, dass ich nach und nach neugierig weitere spannende Module anbinde, anbinden kann.

    Nur mal ein Beispiel: Ich hatte viele Jahre eine semiprofessionelle Wetterstation, die war seriell an einen kleinen Linux-Server angebunden, der las jede Minute alle Werte aus. Und ich hatte mir Scripts für automatisch zu erstellende Grafiken gebaut. Mir schwebt die Vokabel "2300" im Kopf herum. Irgendwann war die Hardware platt. Und meine Hobby-Kraft nicht dafür da. Also mal wieder eine Wetterstation an FHEM-Server-Dingens anbinden - das wäre schon eine Idee.

    Neinneinnein: Ich verlege keine Kabel. Nicht nur, dass ich handwerklich nicht so begabt bin - ich will mein Haus nicht genauer beschreibebnn ... aber Kabel verbieten sich. Leider ist der Schuppen keine Alternative für mich: Da schläft schon ein alter Rasenmäher und die Grillkohle.

    digiart
    Deine speziellen Hinweise helfen mir sehr, ich danke Dir dafür!

    Ich habe gelernt, dass FHEM mit mehreren Protokollen zurechtkommt. Ich habe gelernt, dass ich mit den Protokollnamen als Suchbegriff entsprechende Sensoren bei Anbietern finde. Ich habe nun zwei konkrete Produktnamen, die bei Dir funktionieren: Ich kann also den nächsten Schritt angehen. Du nutzt doch FHEM, ja?

    Grundsatzfrage:
    Benötige ich bei Homematic eine Homematic-Basisstation? Oder nur einen Sensor?

    Ok, grundsätzlich der nächste Schritt, erstmal theoretisch:
    Ich muss nun ja FHEM installieren. Ist es besser, FHEM auf einem EIGENEN Server (ich habe noch einen alten Raspberry PI Mod2 B rumzuliegen) zu installieren? Und falls EIGENER Server für FHEM: Würde ein Raspberry Zero auch reichen? Oder kann man FHEM auf einem EHDA-Server (EHDA: Der ist Eh da) zustätzlich installieren? Wie ist da die grundsätzliche Empfehlung bzgl. Vor- und Nachteilen?

    Einmal editiert, zuletzt von Mart (30. Mai 2017 um 19:37)

  • Ja, bei mir läuft alles über FHEM.

    Für Homematic brauchst du entweder eine Basisstation CCU2 (https://www.elv.at/homematic-zentrale-ccu-2.html), bei der Du die Devices anlernst und dann von FHEM darauf zugreifst, oder du verwendest ein Homematic-Modul für Raspberry (https://www.elv.at/homematic-funk…pi-bausatz.html). Das musst Du aber erst zusammenlöten, ist dafür aber auch wesentlich billiger.
    Für das Modul gibt es im FHEM-Forum auch Anleitungen, wie du damit ein (W)LAN-Homematic Gateway bauen kannst, falls dein Server kein Raspberry ist.

    Als Server kannst Du sicher mit einem RPi 2B anfangen, zum steuern und für's Webinterface reicht die Rechenleistung bei weitem (ausser Du hast eine sehr große Anlage). Ich habe auch so angefangen, mir war aber dann der Aufbau der Diagramme zu langsam, ausserdem läuft bei mir sowieso ein HP Microserver G8 der Web-, Mailserver, Router und Firewall spielt.
    Bei einem Freund habe ich ein FHEM auf einem RPi 2B laufen, der auch eine kleine "Überwachungsanlage" damit betreibt, mit 27 Tür-/Fensterkontakte, 4 Bewegungsmelder und einige Lampen, Schalter und Handsender. Dort werden keine Diagramme benötigt und die Leistung reicht.

    Anfragen ausserhalb des Forums (Mail o.ä.) werden ignoriert!

  • Guten Abend allerseits,

    digiart
    Danke für Deine wieder präzise und gut verständliche Antwort. Ja, CCU2 hatte ich schon gefunden. Mir war lediglich unklar, ob ich das Dingens brauche.

    Ich muss in meinem Verständnis (vor dem Projektstart) noch weiterkommen, da fehlt mir ganz offensichtlich noch so einiges Verständnis:

    Also wer funkt da nun mit wem genau? Offenbar wohl CCU2 mit dem Fensterkontakt. Ist das denn schon WiFi? Greift da FHEM schon in den Funkverkehr ein? Oder ist das noch ein ganz anderer Funk?

    Dann haben wir mein vorhandenes Haus-WLAN (real sind es derzeit zwei, beide Raspberry-basiert), nennen wir das mal SSID=MEINHAUS. An irgend eine Stelle muss ja nun der geplante FHEM-Server:

    * Mit Kabel an das Hausnetz?
    oder
    * geplanter FHEM-Server ist gleichzeitig WLAN-Accesspoint?

    Ich ahne es: Das sind alles dumme Fragen. Seid bitte gnädig zu mir - ich möchte verstehen, auf was ich mich da einlasse.

  • Mart: Ja, CCUI ist wohl das softwaremäßige Gegenstück zu Homematic. Allerdings ist das Projekt eher "tot". Es gib aber einen Nachfolger, genannt "ioBroker". Wir haben hier im Forum auch ein Mitglied, welches zum engeren Kreis der Entwickler von ehemals CCUI und nun ioBroker zählt... Eisbaeer, Zeit für Dich aus dem Winterschlaf zu erwachen und mal ein wenig die Werbetrommel für Euer Projekt zu trommeln... :)
    Ich weis, Vollblutentwickler sind selten Marketingfuzzis - aber ein wenig Werbung hat noch nie geschadet - insbesondere nach der runden Version zum Ende des April!!! Herzlichen Glückwunsch! :bravo2:

    Hier mal ein paar Links zu ioBroker:
    https://de.wikipedia.org/wiki/IoBroker
    http://iobroker.net/
    ...

  • Zitat

    Ja, CCUI ist wohl das softwaremäßige Gegenstück zu Homematic.

    Den Satz habe ich verstanden - die Konsequenz leider nicht.

    Steht CCUI (bzw. IoBroker) alternativ zu FHEM, wird FHEM dadurch ersetzt?

    Oder ist das so gemeint:
    FHEM-Server <-> CCUI/IoBroker <-> Sensor ?

    Einmal editiert, zuletzt von Mart (31. Mai 2017 um 01:55)

  • Ein paar Grundlagen:
    - Homematic verwendet eine kabellose Übertragung mit 868MHz (Vergleich: "Billig"-Steckdosen: 433MHz, WLAN: 2,4MHz bzw. 5MHz).
    - Alle Devices von Homematic kommunizieren mit einer Zentrale. Dies ist entweder eine CCU2 oder ein Computer mit dem Homematic Funkmodul. (Einige Sensoren können auch direkt miteinander kommunizieren, z.B. Tastereinsätze und Schaltaktoren, Fensterkontakte und Heizkörperventile,..).
    - IoBroker ist eine Alternative zu FHEM.

    Anfragen ausserhalb des Forums (Mail o.ä.) werden ignoriert!


  • Mart: Ja, CCUI ist wohl das softwaremäßige Gegenstück zu Homematic. Allerdings ist das Projekt eher "tot". Es gib aber einen Nachfolger, genannt "ioBroker". Wir haben hier im Forum auch ein Mitglied, welches zum engeren Kreis der Entwickler von ehemals CCUI und nun ioBroker zählt... Eisbaeer, Zeit für Dich aus dem Winterschlaf zu erwachen

    Hallo zusammen
    Bei der Hitze kann es keinen Winterschlaf mehr geben ;)
    Das hier angesprochene Projekt CCU.IO war der Vorgänger von iobroker und wird nicht mehr weiterentwickelt. Bei CCU.IO war die CCU ein Bestandteil des Gesamtsystems. CCU.IO lief (bis auf kleine Ausnahmen) nicht ohne CCU.
    Iobroker ist für sich selbst eine eigenständige Server Anwendung, welche Quelloffen, alles anbindet, was anbindbar ist. Der Kern besteht aus einem "broker" und drum herum kann der Anwender verschiedene "Adapter" aktivieren. Diese Adapter nutzen die gleiche Basis (Datenbank) und könenn hierdurch mit allen anderne Adaptern kommunizieren bzw. auf Ereignisse reagieren.
    Nach der Installation wird über eine Weboberfläche definiert, welche Adapter man haben möchte. Diese Adapter werden dann auf der Weboberfläche konfiguriert und gestartet. Ab diesem Moment sind die Daten dann in iobroker verfügbar.
    Adapterliste: http://www.iobroker.net/docu/?page_id=2236&lang=de
    Von KNX/EIB bis Modbus, Miele, Phillips Hue, CUL bis zu Staubsaugerrobotter wie Neatmo, Vorwerk oder Sonos, Sayit, Onkyo, Yamaha, MQTT, node-red, und, und, und....

    Als Frontend (z.B. auf Tablet, Handy, etc) dient eine Weboberfläche, welche Endgerätebasiert, frei konfigurierbar ist. Also eigene Oberflächen generieren und auf die Daten von iobroker zugreifen bzw. auch die Geräte steuern.

    Ich sehe den Vorteil von iobroker darin, dass auch ein Endanwender, welcher keine oder nur geringe Programmierkenntnisse hat, sich sein System einrichten kann. Für denjenigen, der sich damit auseinandersetzt ist das System so offen, dass man sich seine Adapter selbst zusammenstellen kann (z.B. Node-red, Blockly, ScriptUI) oder sogar eigene Adapter bauen kann.
    Es lohnt sich allemal, sich die Software mal anzuschauen und im Forum vorbeizuschauen.
    http://www.iobroker.com
    Grüße Eisbaeeer

  • Den Satz habe ich verstanden - die Konsequenz leider nicht.

    Steht CCUI (bzw. IoBroker) alternativ zu FHEM, wird FHEM dadurch ersetzt?

    Oder ist das so gemeint:
    FHEM-Server <-> CCUI/IoBroker <-> Sensor ?


    Es ist nur ioBroker nötig.

    Sensor<=> CCU<=>ioBroker

    Einmal editiert, zuletzt von Bluefox (31. Mai 2017 um 18:57)

  • Qdigiart

    Zitat

    - Homematic verwendet eine kabellose Übertragung mit 868MHz (Vergleich: "Billig"-Steckdosen: 433MHz, WLAN: 2,4MHz bzw. 5MHz).
    - Alle Devices von Homematic kommunizieren mit einer Zentrale. Dies ist entweder eine CCU2

    Aber mein künftiger FHEM-Server muss nun ja auch mit dem CCU2-Dingens kommunizieren. Welcher Weg ist das denn? Kabel, Wlan oder wie?

    In http://www.meintechblog.de/2016/05/fhem-s…nde-einrichten/ steht allgemein (bezogen auf FHEM-Server) "USB-Ports für den Anschluss von Gateway-Sticks (z.B. für die Unterstützung von FS20, HomeMatic, ZWave, Zigbee)". Das macht mich jetzt nicht schlauer: Benötige ich so einen HomeMatic-Gateway-Stick? Welcher wird denn empfohlen?

    Bluefox

    Zitat

    Sensor<=> CCU<=>ioBroker

    Identische Frage - wie oben.

    Am Rande: Wäre es eine Option, testweise FHEM und ioBroker (abwechselnd) zu betreiben? Ich will ja verstehen, was wie funktioniert.

    Einmal editiert, zuletzt von Mart (31. Mai 2017 um 22:58)

  • Den Homematic USB-Stick gibt's nicht mehr.

    Nochmal:
    Du brauchst bei Homematic eine Zentrale.
    Das ist ENTWEDER eine CCU2 (standalone) ODER ein Raspberry mit Homematic-Modul.

    Du kannst natürlich auch eine CCU2 und einen Raspberry mit FHEM betreiben und die CCU2 mit dem Raspberry ansprechen. Das ist aber so, als wenn du dir ein Motorrad kaufst, dieses aber nur auf einem Anhänger hinter deinem Auto "betreibst".

    Schau' dich auch einmal ein bisschen im FHEM-Forum bzw. im FHEM-Wiki um. Da wird viel beschrieben.

    Anfragen ausserhalb des Forums (Mail o.ä.) werden ignoriert!

    Einmal editiert, zuletzt von digiart (1. Juni 2017 um 08:38)


  • Nochmal:
    Du brauchst bei Homematic eine Zentrale.
    Das ist ENTWEDER eine CCU2 (standalone) ODER ein Raspberry mit Homematic-Modul.

    Ich denke, dass ich da jetzt das Richtige fand. Und dank eurer Hilfe habe ich recht schnell einen groben Überblick gewinnen könnten. Inzwischen habe ich mehrere Bestellungen ausgelöst. Nun habt ihr Ruhe vor mir. ;)

    Ganz herzlichen Dank!

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!