Moin zusammen, Ich wollte mal langsam mit Smart Home beginnen. Erstmal will ich nur Temperatur und Luftfeuchtigkeit messen und über Funk an einen Zentralen Punkt senden der alles verwaltet, gegebenenfalls loggt und auch anzeigt. Nachher wahrscheinlich auch Fensterkontaktsensoren, Energiezähler... Da Kauf Varianten recht teuer und für meinen ersten Ansatz übertrieben sind, habe ich mir überlegt die Sensoren erstmal selbst zu bauen. Aufbau Sensor: Temperatur und Feuchte (SHT21), Funk RFM69CW, Mikrocontroller entweder der Atmega328p oder der Attiny85. Aufbau Zentrale: -Arduino Mega (in C über AVR Studio programmiert) -RTC (DS1307) -Loggen auf SD-Karte via Uart (Openlog) -20x4 LCD über I2C -Uart zum debuggen und Kommunikation zum PC Die Hardware wäre komplett vorhanden. Ich hab mich etwas in den Materie eingelesen und bin recht zügig bei FHEM auf Raspberry PI hängen geblieben. Der könnte Natürlich die Komplette Zentrale ersetzen. Was meint ihr? Macht es sinn direkt einen Raspberry zu nehmen oder würdet ihr erstmal mit Arduino anfangen, ein Protokoll zwischen Sensoren und Zentrale nehmen was FHEM auch kann das man die nachträglich noch ersetzen kann? Wenn ja, welches Protokoll wäre dafür am besten geeignet? Oder habt ihr andere Vorschläge? Gruß Peter
Nehm kein FHEM sondern Home Assistant, denn das ist deutlich einfacher zum Einrichten.
Ich würde komplett alles mit dem ESP8266 und Tasmota machen. In der Verbindung dazu ein Raspi mit FHEM und eingebautem MQTT-Server: Der hat den Vorteil, dass er die Tasmota-Software gleich passend einbinden kann. In Tasmota selber kann man beliebig den ESP konfigurieren: An welchem Pin ein Taster, Relais, Sensor oder irgend was anderes sitzt. Käuflich sind auch diverse (WLAN) Steckdosen mit dem ESP8266 verfügbar, welche dann nur noch passend geflasht werden müssten. FHEM ist am Anfang sehr steinig, aber anschließend sehr mächtig... Da muss man auch ein bisschen Zeit mitbringen bis alles läuft.
Ich persönlich würde wohl gleich einen Raspberry Pi nehmen. Folgende Kombination ist mittlerweile ja fast Standard bei nicht kommerziellen Smart-Home-Systemen: - ein Raspberry Pi als Zentrale - ein auf dem Rasperry Pi laufender MQTT-Broker - die Sensoren und Aktoren möglichst primär per MQTT anbinden - als Benutzeroberfläche etc. dann wahlweise fhem, Home Assistant, ioBroker, Node Red, OpenHAB oder so. fhem ist halt das Urgestein und damit vermutlich am ausgereiftesten. Aber andererseits wohl auch ein wenig altbacken und so. Vielleicht täusche ich mich da, aber mein Eindruck ist, dass die meisten Leute die heutzutage beginnen ein Smart Home-System aufzubauen eher zu einer der neueren Lösungen greifen und fhem überwiegend von solchen Leuten genutzt wird, die halt bereits vor Jahren in das Thema eingestiegen sind, als es praktisch nur fhem gab. Hat vermutlich auch damit zu tun, dass fhem halt in Perl geschrieben ist, was heutzutage kaum noch jemand benutzt.
Also was ich vergessen habe zu sagen. Alle Sensoren sollen über Batterie betrieben werden. Deswegen hatte ich den ESP8266 ausgeschlossen, weil dieser einfach zu viel Strom zieht. Der Atmega328p mit dem SHT21 und RFM69CW zieht im Moment des Sendens 52mA (etwa 13,5ms), beim auslesen des SHT21 ca. 1mA (für 2,2ms) und im Sleep 5uA. Damit kommt man mit einer Batterie egal ob CR2032 oder einer Li Ion 14500 mit 800mA schon ziemlich lange. Zusätzlich will ich nicht ewig viele Wlan Teilnehmer hier haben Vom Protokoll her wäre es mir am liebsten, wenn die Zentrale durchgehend lauschen würde wenn z.b. der Temperatursensor und Feuchtesensor oder der Fensterkontakt was senden. Die Sensoren sollen am liebsten gar nicht erst auf eine Antwort warten. das würde auch Strom im Batteriebetrieb sparen. Ja es gibt natürlich echt viele Opensource Projekte für den Raspberry PI. Denke da werde ich nicht rum kommen. Vor allem sind da meistens Loggingfunktionen direkt integriert und müssen nicht mühselig in C Programmiert und getestet werden.
Peter schrieb: > Also was ich vergessen habe zu sagen. Alle Sensoren sollen über Batterie > betrieben werden. Deswegen hatte ich den ESP8266 ausgeschlossen, weil > dieser einfach zu viel Strom zieht. Da haste natürlich völlig Recht, für Batterie-/Akku-Betrieb ist der ESP8266 (bzw. generell alle Geräte mit direkter WLAN-Anbindung) denkbar schlecht geeignet. > Zusätzlich will ich nicht ewig viele Wlan Teilnehmer hier haben Auch ein durchaus nachvollziehbares Argument. > Vom Protokoll her wäre es mir am liebsten, wenn die Zentrale durchgehend > lauschen würde wenn z.b. der Temperatursensor und Feuchtesensor oder der > Fensterkontakt was senden. > Die Sensoren sollen am liebsten gar nicht erst auf eine Antwort warten. > das würde auch Strom im Batteriebetrieb sparen. Dann käme theoretisch auch z.B. die Verwendung des Nachfolgers des ESP8266, des ESP32, in Frage. Der kann zusätzlich zu WLAN auch direkt Bluetooth LE, was ja gezielt für extrem stromsparenden Batterie-/Akku-Betrieb ausgelegt ist. Die von den Sensoren gemessenen Daten könntest Du direkt in den Bluetooth LE-Advertising-Paketen mitschicken - so machen das einige Sensoren mit Bluetooth LE, z.B. die Bluetooth Thermometer/Hygrometer von Xioami. Preislich liegst Du mit einem ESP32 vermutlich unter der Kombination aus Mega328 und RFM69, darüber hinaus ist der ESP32 natürlich um Längen leistungsfähiger. Aber das nur so als Gedankenanregung. Die von Dir angedachte Kombination aus Mega328 und RFM69 ginge natürlich genauso. Egal für welches Funkprotokoll Du Dich letztlich entscheidest für die Kommunikation zwischen den einzelnen Knoten und der Zentrale: Ich würde Dir empfehlen, dann noch eine entsprechende Software zu verwenden/entwickeln, die als Bridge zu MQTT agiert. So dass Deine Sensoren (und später vermutlich auch Aktoren) auf MQTT gemappt werden. So, wie das die beliebte Software "zigbee2mqtt" bspw. für das ZigBee-Protokoll macht. Falls Dir auf Anhieb nicht 100%ig klar ist, was "zigbee2mqtt" macht, dann google am besten einfach mal kurz danach. Wenn Deine Sensoren/Aktoren dann erst einmal auf MQTT gemappt sind, kann so ziemlich jedes beliebige Smart Home-System darauf zugreifen, egal ob Du Dich nun für fhem, Home Assistant, ioBroker, OpenHAB, Node-Red oder was auch immer entscheidest. Du legst Dich dann nicht auf ein bestimmtes Smart Home-System fest, sondern benutzt in Form von MQTT ein universelles Kommunikationsprotokoll, das mit allen nicht-kommerziellen Smart-Home-Systemen kompatibel ist. > Denke da werde ich nicht rum kommen. Vor allem sind da meistens > Loggingfunktionen direkt integriert und müssen nicht mühselig in C > Programmiert und getestet werden. Zum einen das. Zum anderen kommst Du mit einem Arduino Mega als Zentrale natürlich schnell an die Grenzen des Machbaren und Sinnvollen, und würdest dann früher oder später wohl eh auf eine leistungsfähigere Zentrale wie einen Raspberry Pi umsteigen. Von daher würde ich an Deiner Stelle lieber gleich in diese Richtung denken. Mit fhem und den anderen oben genannten Open Source-Smart-Home-Systemen musst Du das Rad nicht erst mühsam neu erfinden, sondern hast gleich eine komfortable und ausgereifte Ausgangsbasis.
Zäum das Pferd von vorne auf: Welche Funktionen brauchst du? Wieviele digtal i/o und analog i/o werden das? Es macht gehörg einen Unterschied ein paar Lampen nach Uhr an oder aus zu machen als eine stetige Raumtemperaurregelung mit präemtiver Störgrössenaufschaltung hinzubekommen. Wenn du nur T und RH im Raum loggen willst, dann nimm einen kleinen lokalen Logger: keine Funkstrecke, keinen Ärger. "Smart" ist daran allerdings nix. Warum soll "debugging" eine Funktion sein? Ein sketch für einen Logger mit Display der akutellen Messwertanzeige auf Arduinobasis bekommst du fertig und 1000fach geprüft. Bevor du jetzt einen µC und Digisensor subotimierst, überlege nocheinmal ganz genau welche Funktionen du brauchst und willst. Protokoll und Zentraleinheit finden sich sehr schnell wenn du weisst was sie denn können sollen.
Da darf ich mich meinen Vorrednern anschließen. Hab vor Jahren mit FHEM angefangen und muss sagen das läuft sehr stabil. Die Einarbeitung dauert ein wenig, aber im Internet gibt es hierzu sehr viele Infos. Vermutlich würde ich heute mit was anderem anfangen da FHEM wirklich etwas altbacken aussieht. Aber wie gesagt läuft sehr stabil und mir gehts mehr um die Funktion als das Aussehen. Ich habe damals mit Temperatur/Feuchtesensor vom Typ LaCrosse TX29 DTH-IT angefangen, die mit einem selbstgebauten CUL-Stick (übrigens Adruino Umbau) kommunizieren der am Rasperrry per USB hängt. Der Vorteil dieser Sensoren ist, dass die Batterien (2xAA) mehr als ein Jahr durchhalten und bereits ein Display für Feuchte und Temperatur enthalten ist (Preis ca. 12-15€). Mittlerweile habe ich auch einige ESP-Module(Wemos-D1 oder Sonoff-Schalter) per MQTT und Tasmota am laufen. Die Andwendungsfälle sind sehr vielfältig und leicht zu integrieren(inkl. Alexa-Ansteuerung).
Ich schließe mich meinem Vorredner an: Die Lösung mit den DTH-Sensoren (TX29 DTH-IT) ist echt schick. Die Dinger kosten nicht viel (15eur) und Batterien/Akkus halten ewig. Ich habe das in 11/2018 in Betrieb genommen mit Eneloop AAA und noch ist kein Akku leer. Weiterhin hat man auf den Sensoren selbst auch ein kleines Display, so dass man im jeweiligen Raum auch ohne Handy (oder was auch immer) sehen kann, wie warm und feucht es ist. Laufen mit 868 MHz und funken bei mir auch aus dem Keller raus, die Reichweite ist also besser als bei WLAN. Die genannte Empfangseinheit ist weitläufig unter dem Namen "Jeelink" bekannt. Üblicherweise sowas wie ein Arduino nano, auf dem ein Funkmodul hängt. Der passende LaCrosse-Sketch ist dann gleich aufgespielt. ZB in openHAB gibt es ein Plugin (Binding) für Jeelink und so kommt man dann direkt an die Werte ran. Unter FHEM läuft das Ganze aber auch. Bei den Jeelinks gibts zwei unterschiedliche Frequenzen (434 und 868 MHz). Ich persönlich setze den hier ein: https://www.smart-home-komponente.de/jeelink/jeelink-868-lacrosse/ Kann man auch selbst bauen, aber ich finde den Preis i.O.
Torsten schrieb: > Die genannte Empfangseinheit ist weitläufig unter dem Namen "Jeelink" > bekannt. Ja stimmt, nicht CUL-Stick sondern Jeelink für die LaCrosse-Sensoren!
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.