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
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!
