Eigene Sensoren -> Grundlegende Hardware

[DerFrickler]

Hallo zusammen,

ich würde gerne mal damit beginnen mir eigene Sensoren zu bauen und befinde mich aktuell im Stadium der "Qual der Wahl".

Als Basis könnte ich mir einen Arduino Uno vorstellen. Dazu dann einen UV Sensor: https://learn.adafruit.com/adafruit-si1145-breakout-board-uv-ir-visible-sensor

Das sollte soweit klappen, immerhin bietet Adafruit ja ein wunderbares Schritt für Schritt Tutorial dazu an.

Nur muss ich jetzt noch meine Daten rüber zu FHEM bekommen. Kann man das Problem mit einem RFM69HCW lösen, den man "HomeMatic" sprechen lässt? Oder ist dieses Modul eher ungeeignet?

Vielen Dank!

[Bennemannc]

Hallo,

für eigene Sensoren würde ich mir mal ESP Easy ansehen. Da kann man so einiges einfach aufbauen und mit dem Modul direkt in FHEM einbinden.

Gruß Christoph

[medikopter]

Hi,

wie schön geschrieben wurde könntest du es mit espeasy (wemos/nodemcu) oder mit mysensors.org machen.

Ich persönlich stehe auf mysensors. Baue dafür auch gerade einen Blog auf und mache Anleitungen bei YouTube. Da das aber noch nicht offiziell ist, dauert es noch ein wenig

Aber mittels mysensors, kann man schon einiges machen Schau dich einfach mal auf der offiziellen Seite um.

Liebe Grüße

[DerFrickler]

Ich werde mal offen für beide Varianten bleiben. Lass es uns doch mal Wissen wenn das erste Tutorial fertig ist. Das es mein erster Sensor in Eigenbauweise ist, habe ich aktuell absolut keinen Plan wie ich die gemessenen Daten vom Sensor aus zu FHEM übertragen soll. Gibt es dazu Tutorials, welche auch für Neulinge auf diesem Gebiet zu gebrauchen sind?

[Bennemannc]

Hallo,

deswegen ja ESP Easy. Da gibt es für viele Sensoren schon Plugins die einfach über das WebIF des ESP eingestellt werden können. Mit dem ESPEASY Modul werden diese dann in fhem angezeigt.

Gruß Christoph

[Beta-User]

Sofern Dich Christoph nicht schon bekehrt hat, mal von meiner Seite der Versuch der Ehrenrettung für MySensors und die angesprochenen Stichworte zu sortieren:

Vorab: MySensors dürfte (evtl. neben ESPEasy und dem keyValueProtokol) mit die einfachste Variante sein, mit der Du zum Erfolg kommen kannst, und ESPEasy hat nicht nur Vorteile:

1. ESPEAsy ist nett und vermutlich auch einfach zu handhaben, hat aber den grundlegenden Nachteil, dass der Übertragungsweg WLAN heißt. Man kann zwar argumentierendass man das überwiegend sowieso hat, aber man setzt eben für das Funktionieren dieses Teils der Hausautomatisierung eine bestimmte Infrastruktur voraus. Nimmt man serielle GW's (also nicht das weit verbreitete GW von hexenmeister, sondern einfach nur einen Arduino Nano/Uno+Transceiver), hat man eine parallele Infrastruktur. Ob ESPEasy einfach zu handhaben ist, wenn man mal die SSID oder das Passwort ändert, weiß ich nicht, bei MySensors ist sowas egal.

Der m.E. einzige Nachteil von MySensors ist, dass theoretisch jedermann mithören kann, wenn man kein signing (oder RS485=Kabel) nutzt.

2. Mit dem Arduino+RFM kann man auch ein Homematic-Device bauen (Stichwort asksin(++)).
Experten mögen mich eines besseren belehren, aber die Frage, wie man den Arduino einstellen muß, damit er was für FHEM brauchbares liefert (bzw. dann die Empfangsseite in FHEM mit xml-files (?) versorgen), finde jedenfalls ich nicht besonders selbsterklärend.

3. Bei MySensors sind die wesentlichen Software-Bausteine vorhanden, man braucht keine plugins oder so und eigentlich ist das Zusammenwirken der Elemente auch nicht besonders schwer zu verstehen.
Kein Tutorial, aber als Anleitung: Versuch' doch erst mal, aus dem Uno ein serielles GW zu bauen und daran einen lokalen Motion-Sensor zu definieren (kann ein einfacher Taster sein; es sollte reichen, den Motion-Sensor-Sketch zu nehmen, den Transport-Layer erst mal zu deaktivieren und die paar GW-Zeilen aus der GatewaySerial.ino reinzubasteln). Dann siehst Du, wie das grundlegend funktioniert.
Danach dann den den RFM-Transport-Layer definieren und vorab mal testen, ob Dein Modul sauber angesprochen wird.
Parallel kannst Du ja weitere Nanos/pro Micros und RFM-Module bestellen und Dir überlegen, welche Daten und wie Du aus dem Sensor-Modul an FHEM senden möchtest. Das kannst Du ja auch auf Deinem Noch-GW alles erst mal testen.

Evtl. findest Du auch im Starter-Guide (Wiki) weitere Infos.

Gruß, Beta-User

[DerFrickler]

Sofern Dich Christoph nicht schon bekehrt hat, mal von meiner Seite der Versuch der Ehrenrettung für MySensors und die angesprochenen Stichworte zu sortieren:

Vorab: MySensors dürfte (evtl. neben ESPEasy und dem keyValueProtokol) mit die einfachste Variante sein, mit der Du zum Erfolg kommen kannst, und ESPEasy hat nicht nur Vorteile:

1. ESPEAsy ist nett und vermutlich auch einfach zu handhaben, hat aber den grundlegenden Nachteil, dass der Übertragungsweg WLAN heißt. Man kann zwar argumentierendass man das überwiegend sowieso hat, aber man setzt eben für das Funktionieren dieses Teils der Hausautomatisierung eine bestimmte Infrastruktur voraus. Nimmt man serielle GW's (also nicht das weit verbreitete GW von hexenmeister, sondern einfach nur einen Arduino Nano/Uno+Transceiver), hat man eine parallele Infrastruktur. Ob ESPEasy einfach zu handhaben ist, wenn man mal die SSID oder das Passwort ändert, weiß ich nicht, bei MySensors ist sowas egal.

WLAN sehe ich auch als Nachteil... denn irgendwo müssen ja die WLAN Verbindungsdaten hinterlegt werden. Ich gehe mal davon aus dass man diese aus dem Sensor auslesen kann. Da es sich beim ersten Sensor um einen UV-Sensor handeln soll wird dieser natürlich im Freien montiert und kann auch relativ einfach demontiert werden.

Der m.E. einzige Nachteil von MySensors ist, dass theoretisch jedermann mithören kann, wenn man kein signing (oder RS485=Kabel) nutzt.

Bei UV-Daten wäre das sogar wünschenswert und könnte möglicherweise die Rate der Hautkrebserkrankungen reduzieren.

2. Mit dem Arduino+RFM kann man auch ein Homematic-Device bauen (Stichwort asksin(++)).
Experten mögen mich eines besseren belehren, aber die Frage, wie man den Arduino einstellen muß, damit er was für FHEM brauchbares liefert (bzw. dann die Empfangsseite in FHEM mit xml-files (?) versorgen), finde jedenfalls ich nicht besonders selbsterklärend.

Das gilt es dann noch herauszufinden. Davon ausgehend dass ich diesen Sommer eh nicht fertig werde setzte ich mir als Zieltermin den Sommeranfang 2018. Ich kann ja diesen Beitrag als Status Bericht nutzen, möglicherweise ein Ansatzpunkt für das ein oder andere Tutorial.

3. Bei MySensors sind die wesentlichen Software-Bausteine vorhanden, man braucht keine plugins oder so und eigentlich ist das Zusammenwirken der Elemente auch nicht besonders schwer zu verstehen.
Kein Tutorial, aber als Anleitung: Versuch' doch erst mal, aus dem Uno ein serielles GW zu bauen und daran einen lokalen Motion-Sensor zu definieren (kann ein einfacher Taster sein; es sollte reichen, den Motion-Sensor-Sketch zu nehmen, den Transport-Layer erst mal zu deaktivieren und die paar GW-Zeilen aus der GatewaySerial.ino reinzubasteln). Dann siehst Du, wie das grundlegend funktioniert.
Danach dann den den RFM-Transport-Layer definieren und vorab mal testen, ob Dein Modul sauber angesprochen wird.
Parallel kannst Du ja weitere Nanos/pro Micros und RFM-Module bestellen und Dir überlegen, welche Daten und wie Du aus dem Sensor-Modul an FHEM senden möchtest. Das kannst Du ja auch auf Deinem Noch-GW alles erst mal testen.

Evtl. findest Du auch im Starter-Guide (Wiki) weitere Infos.

Gruß, Beta-User

Die HW ist noch auf dem Lieferweg, ein paar Tage Urlaub fallen dann noch dazwischen... aber dann werde ich mich mal mit ein paar Versuchsreihen ans Werk machen.

Danke!

[Beta-User]

Das gilt es dann noch herauszufinden. Davon ausgehend dass ich diesen Sommer eh nicht fertig werde setzte ich mir als Zieltermin den Sommeranfang 2018. Ich kann ja diesen Beitrag als Status Bericht nutzen, möglicherweise ein Ansatzpunkt für das ein oder andere Tutorial.

Willkommen im Club! Übrigens: Als ich die ersten Arduinos gekauft habe, dachte ich auch erst mal, dass das lange dauern wird, bis da was brauchbares rauskommt, schließlich hatte ich weder von Elektronik (-löterein) noch von C-Programmierung einen Plan. ABER: Binnen kurzer Frist (wenige Wochen) hatte ich die ersten Erfolge mit selbergestrickten Multi-Sensor-Nodes!

Die HW ist noch auf dem Lieferweg, ein paar Tage Urlaub fallen dann noch dazwischen... aber dann werde ich mich mal mit ein paar Versuchsreihen ans Werk machen.

Wenn Du die paar Kröten auch in den Sand setzen kannst, würde ich empfehlen, interessante Sensor-HW und einige China-Pro-Minis (zzgl. 1-2 USB-Seriell-Wandler) bzw. Nanos sowie die Funkchips einfach mal auf Vorrat zu kaufen (Achtung bei den Funkchips gibt es auch eine Weitstreckenvariante, die in D nicht zugelassen ist, 2 FTDI-Nanos wären eigentlich auch sinnvoll, hier bekommt man aber gelegentlich Fakes). Es erleichtert später die Fehlersuche, wenn man den MC einfach mal tauschen kann.

Ich kann ja diesen Beitrag als Status Bericht nutzen, möglicherweise ein Ansatzpunkt für das ein oder andere Tutorial.

Gerne! Du kannst Dir auch gerne Schreibrechte in's Wiki geben lassen; der RFM-Weg ist bislang mangels Erfahrung nicht dokumentiert .

Was das mit dem "öffentlichen" Senden angeht, ist das m.E. etwas kurz gedacht: Solange es nur um Sensorik geht, ist das kein großes Problem, wenn andere mitlesen, aber: Man kann damit steuern und man könnte theoretisch auch weitere Node mit derselben ID falsche Infos an FHEM geben lassen...
Aber für einen einfachen UV/Temperatur/Licht.... Sensor ist das m.E. wirklich nicht dramatisch, das öffentliche Senden passiert im 433MHz-Bereich ja woanders auch zuhauf.

Gruß und viel Erfolg,
Beta-User

[Ranseyer]

Als Basis könnte ich mir einen Arduino Uno vorstellen. Dazu dann einen UV Sensor: https://learn.adafruit.com/adafruit-si1145-breakout-board-uv-ir-visible-sensor

-Wenn du schon einen Uno hast kannst Du damit anfangen.
-Billiger + besser dokumentiert ist die HW auf der MySensors Seite: https://www.mysensors.org/store/buying_guide
-Wenn es Funk sein soll ist der bisherige Standard die NRF2401, die anderen = 868MHz Module haben aufgrund der tieferen Frequenz vermutlich bessere Reichweite.

Wenn du 1-2 ProMini +NRF Module rasch willst könnte ich aushelfen. (RS485 Platinen inkl. Max487 auch)

PS: Ich nutze eigenen Platinen, habe mir aber auch mal einen Satz von ein paar verschiedenen NModule Platinen machen lassen: https://www.openhardware.io/view/364/NModule (ungetestet)

[DerFrickler]

Einen Arduino Uno habe ich, dazu habe ich auch noch einen Raspberry Pi 3 der aktuell keine Verwendung findet. Ich werde mal:
1. die Lieferung der Funkmodule und des UV-Sensors abwarten (ein paar andere adafruit Sensoren habe ich hier auch noch zum Testen rumliegen)
2. den Gateway aufbauen und in Betrieb nehmen (hier mit Raspberry Pi); ist diese Anleitung ausreichend? Oder muss für die spätere Anbindung an FHEM noch was spezielles beachtet werden?
3. mit dem Uno und dem UV-Sensor eine Sensoreinheit aufbauen.

Zur Beschreibung von MYSENSORS in der commandef hätte ich da mal eine Frage:
"A single MYSENSORS device can serve multiple MYSENSORS_DEVICE clients." Ist hier mit MYSENSORS device der Gateway gemeint?

Worüber gibt der state in einem MYSENSORS Device Auskunft? Geht es hierbei um den Status des Gateways oder der daran (über Funk) verbundenen Sensoren? Hintergrund: Ich hatte mal einen Gateway ohne Funkmodul nach der Anleitung oben aufgesetzt und in FHEM eingebunden; dieser zeigt mir disconnected an.

Des Weiteren... auch wenn es nicht zu MySensors passt... Da ich eh bisher ausschliesslich HomeMatic nutze, interessier mich natürlich auch die Variante von Beta-User bezüglich "2. Mit dem Arduino+RFM kann man auch ein Homematic-Device bauen (Stichwort asksin(++))." Hat hierzu von Euch schon jemand Erfahrungen?

Gruß und Danke!

[Ranseyer]

Mit dem Arduino+RFM kann man auch ein Homematic-Device bauen (Stichwort asksin(++))." Hat hierzu von Euch schon jemand Erfahrungen?

Ich habe mir ein paar H***-4 fach Relais gebaut. Zumindest mir ist das Thema schon mit fertiger Firmware kompliziert genug: Bootloader, dann OTA die Firmware flashen...

Es gibt ja auf GitHub eine Menge fertiger Devices: HomeBrew Devices genannt weil nicht von E3Q:
Beispiel: https://github.com/pa-pa/AskSinPP/tree/master/examples Wenn dir davon ein Device zusagt sollte sich das ganze mit gewissen Aufwands und Verständniss machen lassen...

Mehr zu Homematic bitte in anderen Boards...

[Beta-User]

Vorab: Ich habe es bislang noch nie erlebt, dass eine auf der MySensors-Seite "vorne" gepostete Anleitung gar nicht funktioniert hätte, allenfalls muß man  aufpassen, wenn Sketche Abhängigkeiten zu externen libs haben. Die brauchen manchmal eine spezielle Version der lib (habe ich mit DS18B20 schon erlebt). Sketche aus dem Forum sind da natürlich mehr mit Vorsicht zu genießen, aber in der Regel auch brauchbar, wenn  die SW-Versionen zueinander passen.

Einen PI als GW zu nutzen habe ich bislang nicht gemacht. Wenn nicht nötig, würde ich auch davon abraten, das erhöht m.E. nur die Komplexität, vor allem, wenn der Controller dann nicht auch darauf läuft. Aber wenn Du keine andere HW hast, sollte es notfalls auch damit gehen, und irgendwer wollte ja schon immer eine Doku dazu ins Wiki stellen...

Besser ist es m.E. wie bereits vorgeschlagen, zunächst das GW gleichzeitig als Sensor-Node zu nutzen, dann kann man schon mal testen.

"A single MYSENSORS device can serve multiple MYSENSORS_DEVICE clients." Ist hier mit MYSENSORS device der Gateway gemeint?

Nein, eigentlich eine Node (wobei das GW eben gleichzeitig auch eine Node ist). Den Starter-Guide hast Du gelesen, ich dachte, das da halbwegs nachvollziehbar dargestellt zu haben? Verbesserungsvorschläge sind willkommen.

state bei Nodes (=MYSENSORS_DEVICES) sagt gar nichts (sind bei mir durchgängig drei , auch bei der Node0=GW-Sensordaten), das GW (=MYSENSORS) sollte auf startup complete oder opened stehen. Alle echten Sensordaten stehen dann in den readings, die angelegt werden (sobald Daten von der Node kommen, nicht vorher!).

Am besten mal testen, dann wird das schneller klar.

[DerFrickler]

Vorab: Ich habe es bislang noch nie erlebt, dass eine auf der MySensors-Seite "vorne" gepostete Anleitung gar nicht funktioniert hätte, allenfalls muß man  aufpassen, wenn Sketche Abhängigkeiten zu externen libs haben. Die brauchen manchmal eine spezielle Version der lib (habe ich mit DS18B20 schon erlebt). Sketche aus dem Forum sind da natürlich mehr mit Vorsicht zu genießen, aber in der Regel auch brauchbar, wenn  die SW-Versionen zueinander passen.

Einen PI als GW zu nutzen habe ich bislang nicht gemacht. Wenn nicht nötig, würde ich auch davon abraten, das erhöht m.E. nur die Komplexität, vor allem, wenn der Controller dann nicht auch darauf läuft. Aber wenn Du keine andere HW hast, sollte es notfalls auch damit gehen, und irgendwer wollte ja schon immer eine Doku dazu ins Wiki stellen...

Den PI hatte ich im Regal neben dem Schreibtisch stehen / rumliegen und habe ihn halt mal ausprobiert... allerdings ohne angeschlossenes Funkmodul. Sobald ich das dann habe, werde ich die Einrichtung des Raspberry noch mal vornehmen. Der PI hat halt den Charme, das man ihn wegen des vorhandenen LAN Anschlusses direkt als Ethernet GW benutzen kann. Ich melde mich diesbezüglich noch mal wenn die gesamte HW vorhanden ist. Aber Deiner Antwort entnehme ich dass dieses Tutorial 1:1 umgesetzt werden kann und keine FHEM spezifischen Änderungen vorzunehmen sind?

Den Uno inkl. Steckboard hätte ich dann zum Ausprobieren von Sensor Nodes nutzen können.

Besser ist es m.E. wie bereits vorgeschlagen, zunächst das GW gleichzeitig als Sensor-Node zu nutzen, dann kann man schon mal testen.
Nein, eigentlich eine Node (wobei das GW eben gleichzeitig auch eine Node ist). Den Starter-Guide hast Du gelesen, ich dachte, das da halbwegs nachvollziehbar dargestellt zu haben? Verbesserungsvorschläge sind willkommen.

Den habe ich mittlerweile gelesen und es ist soweit klar. Alleine die Beschreibung in der Commandref fand ich aber eher verwirrend.

state bei Nodes (=MYSENSORS_DEVICES) sagt gar nichts (sind bei mir durchgängig drei , auch bei der Node0=GW-Sensordaten), das GW (=MYSENSORS) sollte auf startup complete oder opened stehen. Alle echten Sensordaten stehen dann in den readings, die angelegt werden (sobald Daten von der Node kommen, nicht vorher!).

Am besten mal testen, dann wird das schneller klar.

Mir ging es hier um den GW, da ich aktuell wegen fehlender HW nichts weiter realisieren kann. Wie oben schon angemerkt werde ich es in den nächsten Tagen mit vollständiger HW erneut testen.

[Beta-User]

Aber Deiner Antwort entnehme ich dass dieses Tutorial 1:1 umgesetzt werden kann und keine FHEM spezifischen Änderungen vorzunehmen sind?

Die Frage hatte ich eigentlich bereits etwas anders beantwortet:

Einen PI als GW zu nutzen habe ich bislang nicht gemacht.

Ergo: Keine Ahnung, nur das Urvertrauen, dass es grundsätzlich irgendwie klappen müßte . Aber nochmal: m.E. keine gute Option für den Start, da zu komplex! Aber jeder, wie er mag...

Der PI hat halt den Charme, das man ihn wegen des vorhandenen LAN Anschlusses direkt als Ethernet GW benutzen kann.

Da Du sowieso Funk planst, besteht m.E. eigentlich kein Grund, Abhängigkeiten von weiteren Infrastrukturkomponenten (hier LAN) zu schaffen. Ist zwar besser als WLAN, aber eben eine weitere Abhängigkeit. Sofern das funktechnisch überhaupt notwendig ist (hast Du so ein großes Grundstück?!?), würde ich lieber an geeigneter Stelle eine Node als Repeater-Node definieren (das kann auch eine normale Sensor-Node sein, sie braucht halt immer Strom..).

[DerFrickler]

Die Frage hatte ich eigentlich bereits etwas anders beantwortet:Ergo: Keine Ahnung, nur das Urvertrauen, dass es grundsätzlich irgendwie klappen müßte . Aber nochmal: m.E. keine gute Option für den Start, da zu komplex! Aber jeder, wie er mag...
Da Du sowieso Funk planst, besteht m.E. eigentlich kein Grund, Abhängigkeiten von weiteren Infrastrukturkomponenten (hier LAN) zu schaffen. Ist zwar besser als WLAN, aber eben eine weitere Abhängigkeit. Sofern das funktechnisch überhaupt notwendig ist (hast Du so ein großes Grundstück?!?), würde ich lieber an geeigneter Stelle eine Node als Repeater-Node definieren (das kann auch eine normale Sensor-Node sein, sie braucht halt immer Strom..).

Es ist auch kein Problem einen Arduino zum GW auszubauen. War halt ein Versuch mit vorhandener HW. Ansonsten benötige ich aber einen Ethernet GW, da mein FHEM auf einer VM läuft. Ich melde mich zurück wenn ich die ersten Ergebnisse habe.