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.

[DerFrickler]

Kennt jemand eine quelle für ähnliche Gehäuse in unterschiedlichen Größen?
http://www.ebay.de/itm/Waterproof-IP66-Electronic-Junction-Project-Box-Enclosure-Case-200x120x75mm-MDV-/132227734197?hash=item1ec9631ab5:g:hcwAAOSwEzxYS7cm. Der UV-Sensor benötigt immerhin einen transparenten Deckel und einigermaßen wasserdicht sollte das Gehäuse auch sein, da es ja im Freien montiert wird.

Wie handhabt Ihr das mit der Montage? Arduino nano als Basis mit Stiftleisten an den Anschlüssen und oben drauf eine Lochrasterplatine mit Buchsenleisten und einer Lochrasterplatine zur Montage des Funkmoduls und des Sensors?

Bei der Spannungsversorgung scheint der Arduino ja recht flexibel zu sein... bei 6-20 V sollten die 12V direkt vom Solarregler sicherlich kein Problem sein? Oder habt Ihr da andere Erfahrungen?

Gruß und Danke!

[Ranseyer]

Gehäuse bitte hier weiter: https://forum.fhem.de/index.php/topic,75022.0.html
(Das passt für alle Systeme)

[Beta-User]

Der UV-Sensor benötigt immerhin einen transparenten Deckel und einigermaßen wasserdicht sollte das Gehäuse auch sein, da es ja im Freien montiert wird.

Was willst Du für einen Sensor einsetzen? Für den VEML6075 sollte laut diesem Beitrag im MySensors-Forum ein UV-transparentes Gehäuse verwendet werden: https://forum.mysensors.org/topic/6952/veml6070-and-veml6075-uv-sensors/9#
Und irgendwo meine ich gelesen zu haben, dass der eigentlich mit 45° montiert werden sollte.
Die Diskussion zu diesem Sensor (oder einem anderen) sollte man ggf. abtrennen, ist nicht nur im Rahmen von MySensors interessant...

Wie handhabt Ihr das mit der Montage? Arduino nano als Basis mit Stiftleisten an den Anschlüssen und oben drauf eine Lochrasterplatine mit Buchsenleisten und einer Lochrasterplatine zur Montage des Funkmoduls und des Sensors?

Wenn ich genug Platz habe, versuche ich den Arduino immer steckbar zu machen (mit Stiftleisten), dann kann ich einfach tauschen, wenn ich eine neue Sketch-Version testen möchte. Für Funkmodule (nRF) kann ich die Steckmodule mit integrierten Kondensatoren empfehlen, ob es für die RFM69 was ähnliches braucht: keine Ahnung. Bei den nRF's ist man jedenfalls gut bedient, wenn man die einfach tauschen kann, es wurde hinsichtlich der Funkleistung schon von großen Serienstreuungen berichtet.

Bei der Spannungsversorgung scheint der Arduino ja recht flexibel zu sein... bei 6-20 V sollten die 12V direkt vom Solarregler sicherlich kein Problem sein? Oder habt Ihr da andere Erfahrungen?

Gruß und Danke!

Dazu kann ich leider wenig sagen, an 12V geht es jedenfalls, aber verträgt der Spannungswandler mehr wie 18V?
Was Solarversorgung angeht, gab es im MySensors-Forum irgendwo auch einen Beitrag, wo jemand statt Solarzellen Supercaps verwendet hat. Wäre evtl. auch eine interessante Variante.

[DerFrickler]

Was willst Du für einen Sensor einsetzen? Für den VEML6075 sollte laut diesem Beitrag im MySensors-Forum ein UV-transparentes Gehäuse verwendet

Gut das wir darüber gesprochen haben, da hätte ich fast eine falsche Bestellung ausgelöst bzw. hätte mich über die geringen UV Werte gewundert.

[DerFrickler]

Ich kämpfe hier gerade mit meinem Arduino Nano... und bekomme leider nur folgenden Output:

Code Auswählen Erweitern

avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0x2e


bei folgendem Board:

Code Auswählen Erweitern

Mini USB Nano V3.0 ATmega328 5V 16M Micro-controller CH340G board für Arduino

Welche benutzt Ihr, die dann hoffentlich OutOfTheBox funktionieren? Den CH340G Treiber habe ich in der aktuellsten Version installiert.

Gruß!

[gloob]

Wie sehen denn deine Arduino IDE Einstellungen aus für den Upload. Eigentlich sind die Arduino Nanos auch mit CH340 sehr einfach zu flashen.

[Beta-User]

Wie sehen denn deine Arduino IDE Einstellungen aus für den Upload. Eigentlich sind die Arduino Nanos auch mit CH340 sehr einfach zu flashen.

Die Erfahrung kann ich bestätigen.
Evtl. haben die Arduinos aber noch keinen Bootloader bzw. es ist (in der IDE) der falsche eingestellt. Wenn Du einen Programmieradapter hast, kannst Du versuchen, darüber den Standard-Bootloader draufzumachen. Manchmal hatte ich auch ähnliche Probleme bei Arduinos ohne USB-Seriell-Wandler. Wenn sowas war, hat bei vielem Probieren manchmal geholfen, den Reset-Taster kurz vor dem flash-Beginn zu drücken. Klappt aber leider nicht immer...

Ein flashbarer Uno oder Nano hilft btw auch, da gibt es einen Sketch (im Standard der IDE enthalten), um den zum Programmer zu machen.

[DerFrickler]

Wie sehen denn deine Arduino IDE Einstellungen aus für den Upload. Eigentlich sind die Arduino Nanos auch mit CH340 sehr einfach zu flashen.

Ich benutze die Arduino 1.8.3 IDE mit folgenden Einstellungen:

Board: Arduino Nano
Prozessor: ATmega328
Port: Com7 (habe ich über den Gerätemanager verifiziert)
Programmer: AVRISP mkii

Ich nutze das einfache "Hochladen", nicht "Hochladen mit Programmer".

[Beta-User]

Bin kein "Redmonder", aber m.E. sieht das ok aus.

Das mit dem "Programmer" brauchst Du nur, wenn Du entweder einen anderen Bootloader drauf machen willst oder die SW direkt flaschen (ohne Bootloader). Aber dazu bräuchtes Du dann extra Hardware.

[DerFrickler]

Code Auswählen Erweitern

Produkt Details:

Auf dem Board ist bereits ein Bootloader für 16 MHz Geschwindigkeit installiert.

Es ist anfängergerecht direkt per Arduino IDE programmierbar.

Sie können den Microcontroller entweder per USB mit Spannung versorgen oder ein beliebiges Netzteil benutzen, dass zwischen 5-12 Volt liefert.

Tipp: Verwenden Sie beim Anschließen des Boards unbedingt einen USB-Hub um Ihren Computer vor Kurzschlüssen zu schützen.

Atmel Atmega328P-AU MCU

USB-Controllerboard: CH340G (ersetzt FT232RL)

Betriebsspannung? 5V-12V (per USB oder über Netzteil dank Spannungsregulator)

8 Analoge Schnittstellen:A0 ~ A7

14 Digitale Schnittstellen:TX,RX,D2 ~ D13

6 PWM Schnittstellen:D3, D5, D6, D9, D10, D11

1x  TTL level serial IO Schnittstelle für RX / TX


Kann es auch am USB Kabel liegen?

[gloob]

Setz doch bitte mal den Programmer auf "Arduino as ISP"

Bitte ignorieren. Hab in der falschen IDE geschaut.

[DerFrickler]

Es liegt am Arduino selbst. Ich habe gerade einen anderen ausgepackt, den angeschlossen und es funktioniert. Entweder war der von Beginn an defekt oder hat beim auflöten der Steckerleiste etwas abbekommen. Leider musste ich feststellen dass meine Sehstärke seit 1992 (Abschluss meiner Ausbildung zum Elektroniker) etwas nachgelassen hat. Ich werde die Steckleisten beim zweiten Arduino (bei dem ich den Sketch hochladen konnte) anlöten.

[Beta-User]

Dann kannst Du den funktionierenden zum ISP machen und versuchen, den ersten damit wiederzubeleben . Also den ISP-Sketch drauf, den anderen nach Anleitung anschließen (habe leider grad keinen link, steht aber evtl. auch im Sketch), dann den Bootloader draufbrennen mit der Einstellung Arduino as ISP. Vielleicht klappt das ja.

[DerFrickler]

werde ich ausprobieren, danke. Für die Sende- / Empfangsmodule nutzt Ihr (abgesehen vom ESP8266) den level converter zum anschliessen?

[gloob]

Was für ein Sende-/Empfangsmodule möchtest du denn einsetzen?

NRF24L01
RFM69

[DerFrickler]

Ich habe aktuell NRF24L01+ PA LNA im Einsatz, werde später auch noch RFM69 (433 MHz) testen, die 868Mhz sind noch auf dem Weg. Diejenigen, mit denen ich dann am besten auskommen werde, werden dann auch final in allen Sensoren verbaut.

[Beta-User]

Für die nRF habe ich gute Erfahrungen mit den in der Bucht erhältlichen Adapter-Boards gemacht, da sind auch Kondensatoren mit drauf. PA+LNA direkt am 3.3V-PIN ist eher nicht zu empfehlen.

Mit den anderen Bausteine habe ich keine Erfahrung.

[DerFrickler]

auf mysensors.org werden explizit der Pro Mini und der Nano genannt, wenn ich jetzt aus dem Uno ein Gateway machen möchte benötige ich keinen adapter und kann den nrf24 direkt an 3,3 V anschliessen?

[Beta-User]

Hat der Uno einen anderen Spannungswandler drauf?

Du kannst Du es ja versuchen, ggf. mit einer Änderung auf PA_LOW oder MIN. Gerade für die PA+LNA-Module sollte aber eine stabile Spannungsversorgung hohe Prio haben. Also: wenn's nicht klappt, nicht wundern und nachbessern, Du weißt ja wo suchen...

[DerFrickler]

Den Uno habe ich mit dem Adapter getestet, leider habe ich ein Problem mit dem Ethernet Shield (https://forum.fhem.de/index.php?topic=75253.0). Um weiter zu kommen, habe ich den Raspberry GW ans Laufen gebracht (auch mit Adapter). Als Sensor habe ich den UV-Sensor gebaut. Da die Sonne aber eher selten im Arbeitszimmer scheint und es aktuell regnet dürfte für das Senden aktuell eher die 5-Minuten Regel greifen, doch sie tut es nicht...

Code Auswählen Erweitern

unsigned long lastSend =0;
...
    unsigned long currentTime = millis();
...
    //Send value to gateway if changed, or at least every 5 minutes
    if ((uvIndex != lastUV)||(currentTime-lastSend >= 5UL*60UL*1000UL)) {
        lastSend=currentTime;
        send(uvMsg.set(uvIndex,2));
        lastUV = uvIndex;
    }

Ich habe mir das ganze mal auf der Konsole ausgeben lassen, mit folgendem Ergebnis:

1. Zyklus:
currentTime: 2191
lastSend: 0

Differenz: 2191
Der Vergleichswert beträgt: 300000

2. Zyklus:
currentTime: 2213
lastSend: 2191

Differenz: 22
Der Vergleichswert beträgt: 300000

Irgendwie werde ich das Gefühl nicht los dass currentTime gar nicht in Millisekunden gemessen wird, trotz der Angabe millis()??

Ich hoffe von Euch kann mir da jemand weiterhelfen.

Danke!

[Beta-User]

Das mit currentTime sollte an sich schon passen, aber insgesamt kommt es mir so vor, als wäre die Logik nicht ganz optimal:

- Du mißt bei jedem loop()-Durchlauf? Warum? Jede Minute (oder sogar länger) sollte doch reichen. Ich würde erst mal hart alle 20 Sek. senden und erweiterte Logik an der Stelle später einfügen.
- Da lastSend einen update bekommt, müßte auch was gesendet worden sein. Da wäre eher die Frage, warum das GW das nicht mitbekommt. Ich würde auf ein Problem mit dem GW tippen.

Was spuckt #MY_DEBUG an der Konsole des Sensors aus? Was passiert, wenn Du ein "Ack" anforderst? (Ohne Gewähr:
"send(uvMsg.set(uvIndex,2), true)")

Es kommt mir so vor, als wolltest Du zu viel auf einmal...

Gruß, Beta-User

[Beta-User]

Ergänzung noch:

- Die Node ist bereits angelegt?
- Hast Du mal versucht, erst mal den Arduino als GW zu nutzen (nur GW-Feature aktivieren, das reicht schon...). Das mit dem PI ist für Fortgeschrittene
- Du nutzt doch hoffentlich 2.2.0-beta; ohne das geht es vermutlich gar nicht 

Wenn Dir die Arduinos ausgehen: Sag per pm Bescheid, notfalls kann ich Dir ein, zwei in einen Umschlag stecken.

[DerFrickler]

Das mit currentTime sollte an sich schon passen, aber insgesamt kommt es mir so vor, als wäre die Logik nicht ganz optimal:

- Du mißt bei jedem loop()-Durchlauf? Warum? Jede Minute (oder sogar länger) sollte doch reichen. Ich würde erst mal hart alle 20 Sek. senden und erweiterte Logik an der Stelle später einfügen.
- Da lastSend einen update bekommt, müßte auch was gesendet worden sein. Da wäre eher die Frage, warum das GW das nicht mitbekommt. Ich würde auf ein Problem mit dem GW tippen.

Was spuckt #MY_DEBUG an der Konsole des Sensors aus? Was passiert, wenn Du ein "Ack" anforderst? (Ohne Gewähr:
"send(uvMsg.set(uvIndex,2), true)")

Es kommt mir so vor, als wolltest Du zu viel auf einmal...

Gruß, Beta-User

Es handelt sich bei dem Sketch um das Beispiel von mysensors. Nehme ich die if-Abfrage raus, dann wird alle 30 Sekunden eine Message versendet. Funktioniert alles wunderbar, veränderte UV-Werte werde ich dann nach dem Dauerregen testen. Die 30 Sekunden kommen von dem sleep(SLEEP_TIME).

Das einzige Problem ist folgende Zeile:

    if ((uvIndex != lastUV)||(currentTime-lastSend >= 5UL*60UL*1000UL)) {

wenn sich der UV-Index nicht ändert. Das mit den 5-Minuten haut nicht hin, da bei mir currentTime sowie lastSend nicht in Millisekunden gemessen wird, sondern was ganz anderes.

[DerFrickler]

Ergänzung noch:

- Die Node ist bereits angelegt?
PI-GW läuft sauber und UV-Sensor ist aktiv.

- Hast Du mal versucht, erst mal den Arduino als GW zu nutzen (nur GW-Feature aktivieren, das reicht schon...). Das mit dem PI ist für Fortgeschrittene
Der Arduino GW macht Probleme, da es allem Anschein nach 2 Widerstände im Ethernet Shield einzulösen gilt.

- Du nutzt doch hoffentlich 2.2.0-beta; ohne das geht es vermutlich gar nicht 
Du sprichst hier von der mysensors Version?

Wenn Dir die Arduinos ausgehen: Sag per pm Bescheid, notfalls kann ich Dir ein, zwei in einen Umschlag stecken.
Das dürfte in naher Zukunft nicht passieren

[Beta-User]

OK, die Kommunikation zwischen GW und node passt also, dann dürfte dei MySensors-lib-Version auch 2.2.0-beta sein.

Das mit dem Ethernet-Shield verstehe ich (nicht), es gibt auch ein ganz ordinäres serielles GW, anzuschließen via USB. Das meinte ich (ist aber egal, da GW und Node miteinander sprechen).

Dein Problem dürfte folgendes sein: Du machst ein sleep(). Das setzt nach meiner Kenntnis millis() zurück...

Meine Arduinos behalte ich auch gerne, sonst muß ich nur nachbestellen und Chinesen verhauen, wenn sie mir fake TFDI's unterschieben wollen .

[DerFrickler]

OK, die Kommunikation zwischen GW und node passt also, dann dürfte dei MySensors-lib-Version auch 2.2.0-beta sein.
Laut Bibliotheksverwalter ist die Version 2.1.1 installiert, die Möglichkeit eine Beta-Version zu installieren kann ich im Verwalter nicht finden. Muss ich dazu spezielle Einstellungen vornehmen?
Das mit dem Ethernet-Shield verstehe ich (nicht), es gibt auch ein ganz ordinäres serielles GW, anzuschließen via USB. Das meinte ich (ist aber egal, da GW und Node miteinander sprechen).
Möglicherweise führt ja auch ein Update der lib-Version zum Erfolg, deshalb auch meine Frage im anderen Beitrag.... bevor ich das Shield unnötig zerstöre.
Dein Problem dürfte folgendes sein: Du machst ein sleep(). Das setzt nach meiner Kenntnis millis() zurück...
Das sollte doch sicherlich auch anderen Foren Mitgliedern aufgefallen sein, insbesondere da es ja original Beispiel-Sketch ist.
Meine Arduinos behalte ich auch gerne, sonst muß ich nur nachbestellen und Chinesen verhauen, wenn sie mir fake TFDI's unterschieben wollen .

[Beta-User]

Was den Sketch angeht: Welchen genau hast Du verwendet? Bitte einen Link oder den code direkt.
Ich habe mal hier nachgesehen, da wird nur sleep() verwendet, nicht noch parallel millis(). Was bei Dir Probleme zu machen scheint, ist die Kombination beider Methoden.

Die Beta-Version habe ich über git installiert.
Dazu reicht es, in dem Ordner, in dem die Arduino-libraries liegen ein git clone ... auf das MySensors-Github-repo zu machen, dann kann man auch die Versionen wechseln (git checkout...). Evtl. liege ich auch falsch, ich bin irgendwie davon ausgegangen, dass es um RFM69-Module geht, und da war 2.2.0-beta als Empfehlung für ein PI-GW auf der offiziellen Seite genannt (bei build, meine ich).

Was das Serielle GW angeht: Ich kann hier nirgendwo einen Netzwerkshield erkennen: https://www.mysensors.org/build/serial_gateway. Wir sprechen also über unterschiedliche Dinge. Ich nur über einen Arduino, der nicht mal ein Funkmodul braucht, geschweige denn Netzwerk.
Und wenn der Netzwerkshield mit den falschen Widerständen ausgestattet ist, helfen m.E. neue libs tendenziell eher nichts, zumal es eher Ausnahmen zu sein scheinen, bei denen falsche Widerstände verwendet wurden.

[DerFrickler]

Was den Sketch angeht: Welchen genau hast Du verwendet? Bitte einen Link oder den code direkt.
Ich habe mal hier nachgesehen, da wird nur sleep() verwendet, nicht noch parallel millis(). Was bei Dir Probleme zu machen scheint, ist die Kombination beider Methoden.

https://www.mysensors.org/build/uv

[Beta-User]

Asche auf mein Haupt, ich hatte nur nach dem VEML gesucht, weil ich irgendwie der Ansicht war, das sei der Sensor, den Du nutzt .

Aber @sundberg84 sagt in der Diskussion zu dem Beispiel weiter unten auch in einem Nebensatz:

Also, do you run this on batteries and sleep the node the 5 min delay wont work and you have to remove it.

Also nochmal: sleep() und millis() vertragen sich nicht, das wird so nicht funktionieren.
Quellen: https://arduino.stackexchange.com/questions/30077/how-to-keep-accurate-millis-while-using-adc-sleep-mode
https://forum.mysensors.org/topic/7263/remainder-sleep-time-upon-an-interrupt/5

Ergo: entweder aus dem sleep() ein wait() machen (dann aber kein Batteriebetrieb), oder einen Rundenzähler einführen, und dann nur alle 10 Runden senden und den Zähler zurücksetzen.

[DerFrickler]

Asche auf mein Haupt, ich hatte nur nach dem VEML gesucht, weil ich irgendwie der Ansicht war, das sei der Sensor, den Du nutzt .

Aber @sundberg84 sagt in der Diskussion zu dem Beispiel weiter unten auch in einem Nebensatz:
Also nochmal: sleep() und millis() vertragen sich nicht, das wird so nicht funktionieren.
Quellen: https://arduino.stackexchange.com/questions/30077/how-to-keep-accurate-millis-while-using-adc-sleep-mode
https://forum.mysensors.org/topic/7263/remainder-sleep-time-upon-an-interrupt/5

Ergo: entweder aus dem sleep() ein wait() machen (dann aber kein Batteriebetrieb), oder einen Rundenzähler einführen, und dann nur alle 10 Runden senden und den Zähler zurücksetzen.

Na jetzt mal locker bleiben, Du hast mir den Einstieg schon sehr erleichtert. Immerhin habe ich jetzt den Gateway (Pi + Ethernet) sowie einen UV-Sensor und einen Staubsensor im Einsatz, weitere folgen. Das Problem mit dem sleep und den millis werde ich schon noch irgendwie gelöst bekommen.
Beim UV-Sensor wird ohne Wertänderung alle 5-Minuten trotzdem gesendet (so der Plan).
Beim Staubsensor nur bei Wertänderung.
Die Variante mit den 5-Minuten gefällt mir und ich werde mal sehen wie sich das Problem lösen lässt. Immerhin gibt mit currentTime ja einen Wert zurück, mal sehen was sich damit machen lässt. Die Beispiele sind gut, meistens sogar ausreichend... können aber auch angepasst werden.

[Beta-User]

Danke für die Rückmeldung.

Kurze Anmerkungen noch:

Immerhin gibt mit currentTime ja einen Wert zurück, mal sehen was sich damit machen lässt.

Das wird m.E. nicht klappen, da currentTime mittels millis() befüllt wird. Besser einen Zähler nehmen, der jeden Durchlauf der loop() (wg. sleep() alle 30 Sekunden) um eins hochgezählt wird. Ist der das 10. Mal durch, sind 5 Min. um und es wird gesendet, unabhängig von einer Änderung.

Wenn Du den VEML nutzt: Den kann man extra schlafen legen und dann nur zum Messen wieder aufwecken. Allerdings muß man dann kurz warten, bis er wieder einsatzfähig ist (500ms oder so), erst dann messen.
Die Infos dazu finden sich in dem bereits zitierten MySensors-Thread, eine modifizierte lib habe ich auch auf github, ebenso wie einen ungetesteten MySensors-Sketch mit sleep.

[DerFrickler]

macht Sinn, nach jedem Senden wird der Zähler dann zurückgesetzt.

[DerFrickler]

Die Spannungsversorgung:

Laut Verkäufer kann der nano mit einer Eingangsspannung von 3,8 bis 12V betrieben werden. Anzubieten hätte ich die 12V Ausgangsspannung eines Ladereglers in meiner Gartenhütte. Laut Datenblatt kann bei >50% Ladung die Ausgangsspannung 12,6V betragen. Ich würde hierzu einen DC/DC Wandler vorschlagen http://www.ebay.de/itm/3x-LM2596-DC-Step-Down-Spannungswandler-Arduino-Modul-Regler-LM2596S-/252785167788?hash=item3adb2b8dac:g:9dkAAOSwTuJYr~hm
Gibt es hier Eurerseits Erfahrungen? Was wäre eine optimale Betriebsspannung für den nano?

Die Reichweite:

Aktuell arbeite ich mit dem
- NRF24L01+ PA LNA SMA (mit externer Antenne) http://www.ebay.de/itm/NRF24L01-PA-LNA-SMA-mit-Antenne-Long-Range-Funk-Modul-Raspberry-Arduino-/252713945935?hash=item3ad6eccb4f:g:3FIAAOSw4DJYl1I0
- NRF24L01+ PCB Adapter http://www.ebay.de/itm/NRF24L01-PCB-Adapter-Breakout-Board-Breadboard-Pinout-Funk-Modul/252715007048?ssPageName=STRK%3AMEBIDX%3AIT&_trksid=p2060353.m2749.l2649
- NRF24L01 2.4GHz Funkmodul (ohne externe Antenne) http://www.ebay.de/itm/NRF24L01-2-4GHz-Funkmodul-Raspberry-Pi-Arduino-Nano-Modul-Nano-FHEM-NRF24L01/252715004274?ssPageName=STRK%3AMEBIDX%3AIT&_trksid=p2060353.m2749.l2649

Probleme hierbei....
ich würde wegen der Größe der externen Antenne doch lieber auf die Funkmodule ohne externe Antenne ausweichen. Leider sind dann die Empfangseigenschaften so schlecht, dass ich mich im gleichen Raum befinden muss damit die Verbindung nicht abreisst. Mit externer Antenne (GW und Sensor) schaffe ich zumindest schon mal eine Etage. Anmerkung: Bei mir daheim ist so viel Stahl verbaut worden, dass WLN auch keine 2 Etagen schafft. Der Gateway soll im Keller stehen, die Sensoren an der Gartenhütte montiert werden. D.h., wir sprechen hier von einer Mauer in Leichtbauweise, einer Aussenwand und dann noch ca. 10 m freie Fläche. Mein HMLAN-GW schafft das problemlos mit einem durchschnittlichen RSSI von -71,88 dBm. Kann man sich über die serielle Konsole auch RSSI Werte ausgeben lassen?

Das Verbauen in ein Gehäuse:

Ein weiterer Nachteil den ich bei den Modulen mit externer Antenne sehe ist die Tatsache dass es sicherlich sinn macht die Antenne ausserhalb des Gehäuses zu montieren. Dass führt 1. dazu, dass man ein Loch in das Gehäuse bohren muss und 2. dass die Gefahr besteht dass Feuchtigkeit eindringen kann. Gibt es hier Adapter die man relativ Feuchtigkeitsdicht am Gehäuse verschrauben kann? Und falls ja, wie nennt man diese Adapter?

Dann die Ausmasse des PCB Adapters zusammen mit dem Funkmodul... Wie zum Henker befestigt ihr beide Module später wenn Ihr alles in ein Gehäuse verbaut? Insbesondere die Tatsache dass alle Kontakte nach oben hin verbaut sind gibt einem nicht wirklich die Möglichkeit den Adapter auf einer Hauptplatine zu verbauen.

[Beta-User]

Seit dem WE habe ich eine Node am laufen, die mit 12 V versorgt wird, parallel zur internen Versorgung über raw habe ich auch so ein Modul angeschlossen (auf 5V eingestellt). Das funktioniert soweit bis jetzt, da kann aber sicher jemand mehr dazu sagen, der etwas mehr Ahnung hat. Wenn Du die vor raw setzt, sollten ab 6V anliegen; ich würde zur Versorgung über raw mal mit 7V ins Rennen gehen.

Was die Reichweitenthematik angeht, gibt es sehr unterschiedliche Erfahrungen mit den nRF. Nach meinen Erfahrungen ist es ähnlich wie bei WLAN@2,4GHz (oh Wunder...)
Dass es aber grade mal im selben Raum klappt, ist m.E. nicht repräsentativ. 5m+ eine dickere Wand sollten schon gehen, auch mit den "kleinen" Modulen; hier hatte jemand aber auch schon von großen Serienstreuungen aus derselben Grundplatine berichtet.

Grundsätzlich würde ich überlegen, auf RFM69 zu setzen (können auch RSSI-Werte ausgeben, wenn ich das richtig im Kopf habe, nRF kann das nicht). Kosten zwar mehr, sollten dafür aber auch bessere Funkleistungen aufweisen. Notfalls Repeater für nRF definieren, GW+Repeater in PA+NLA-Version (mit PA_PAX). Die Antennenausrichtung sollte parallel sein, wenn ich das richtig verstanden habe.

In der Garage habe ich eine handelsübliche Aufputz-Dose (10x10) genommen, und die Antenne durch eines der vorgesehenen Löcher nach außen geführt, also die Antennenbuchse durchgesteckt und die Antenne von außen verschraubt. Ist zwar nicht wasserdicht, aber ohne weitere so hinzubekommen, dass selbst kleine Spritzer kein Problem sein sollten. Da paßt dann alles rein, das Adapter-Modul liegt bei entsprechender Position des Funkmoduls fast auf der Gehäuseseite an und man kann "bequem" stecken (bzw. bei anderen Nodes habe ich die Kabel dann unten an den Adapter gelötet, das hat sich aber m.E. nicht so bewährt). Die Stecker der Adapterplatinen durch eine Lochraster-Platine zu stecken sollte auch gehen (u.U. ohne +/gnd), dann bekommt das auch eine gewisse Stabilität.

[Ranseyer]

Genau. Die Polarisation der Antennen sollte immer gleich sein.
https://de.m.wikipedia.org/wiki/Polarisation_(Antennen)

Abweichungen können extrem Auswirkungen haben (25dB hab ich gerade gegoogelt)

PS: Der beschriebene Fall hört sich für mich eher nach gefangen NRF Chips an...

[DerFrickler]

Habt Ihr eine bevorzugte Software zur Leiterplatten-Entwicklung? Ich hatte zwar vor Lochrasterplatinen zu verwenden, nur wollte ich auch darauf Leiterbahnen ziehen.

Gruß und Danke!

[Beta-User]

Habt Ihr eine bevorzugte Software zur Leiterplatten-Entwicklung?

Bin bisher ohne ausgekommen...
Btw.: es gibt auf openhardware.io auch einige Grundplatinen, wenn man "Platzprobleme" vermeiden möchte bzw. da werden die für die diversen Transport-Schnittstellen erforderlichen PINs auch gleich mit "sortiert" und es gibt definierte Plätze für das "Hühnerfutter".

@Ranseyer:
1. Wenn ich es richtig sehe (?), wird bei Deinen RS485-Platinen PIN3 für 1-wire verwendet. Halte ich für suboptimal, PIN 3 ist der einzige freie (PIN2 wird für RS485 benötigt) PIN mit eindeutigem interrupt. Ist der frei, ist es sehr viel einfacher, wenigstens einen Zähler, Bewegungsmelder etc. mit zu "vermultisketchen".
2. Vorschlag: wir könnten einen "Platinen-Sticky-Thread" aufmachen, zum Sammeln von (Basis-) Platinen dort. Mich hat bislang immer abgeschreckt, dass ich keinen Plan habe, was dort (und anderswo) gut ist und funktioniert, und was eben nicht..

Beispiele für Links bzw. sowas gibt's (natürlich...) auch auf MySensors.org:
https://www.mysensors.org/hardware/newbie-pcb
https://forum.mysensors.org/topic/214/a-compendium-of-hardware-boards-to-support-mysensor-nodes

[Ranseyer]

Die Leute hier im Forum nutzen Target3001 oder auch den Cirquit Maker von Altimeter.

Das meistgenutze ist leider EAGLE. Das dürfte die älteste Software sein. Es gibt aber auch ganz viele Libyen mit Bauteilen die direkt Nutzbarkeit sind.

Ich habe mit Kincade ein größeres Projekt gemacht. Wenn du keins der Programme kennst würde ich dir Target3001 oder besser KICAD empfehlen. KICAD ist auf den ersten Blick nur eine Sammlung von Modulen. Der Workflow ist aber absolut sinnvoll und logisch. Die Einarbeitung in KICAD dürfte gleich sein wie bei EAGLE. Dafür hast du dann aber ein unbegrenzt kostenloses Programm.

Zu den PCs. Ich starte dazu gelegentlich einen neuen Thread. Meine Anforderungen zu MySensors PC sind haben sich auch geändert...

[Ranseyer]

Die Leute hier im Forum nutzen Target3001 oder auch den Cirquit Maker von Altium.

Das meistgenutze ist leider EAGLE. Das dürfte die älteste Software sein. Es gibt aber auch ganz viele Libs mit Bauteilen die direkt nutzbar sind.

Ich habe mit KiCAD ein größeres Projekt gemacht. Wenn du keins der Programme kennst würde ich dir Target3001 oder besser KICAD empfehlen. KICAD ist auf den ersten Blick nur eine Sammlung von Modulen. Der Workflow ist aber absolut sinnvoll und logisch. Die Einarbeitung in KICAD dürfte gleich sein wie bei EAGLE. Dafür hast du dann aber ein unbegrenzt kostenloses Programm.

Zu den PCBs. Ich starte dazu gelegentlich einen neuen Thread. Meine Anforderungen zu MySensors PCB haben sich auch geändert...

Ed: Fehler durch Autokorrektur weitgehend behoben

[DerFrickler]

benötigt man für die RFM69 am Nano auch Adapter? Oder funktionieren die auch direkt an 3.3V?

Gruß und Danke!

[SabineT]

benötigt man für die RFM69 am Nano auch Adapter? Oder funktionieren die auch direkt an 3.3V?

Gruß und Danke!

Der RFM69CW ist für 3.3V ausgelegt (sh. Datenblatt: http://www.hoperf.com/upload/rf/RFM69CW-V1.1.pdf).

[DerFrickler]

Der RFM69CW ist für 3.3V ausgelegt (sh. Datenblatt: http://www.hoperf.com/upload/rf/RFM69CW-V1.1.pdf).

Stelle ich die Frage mal etwas konkreter... reicht die Leistung eines 3,3V Anschlusses eines Nano aus oder müsste man ähnlich wie beim nRF den 5V Anschluss nutzen und die Spannung auf 3,3V runter transformieren? Und wo wir schon mal dabei sind... welche Art Antenne nutzt Ihr? Reicht ein 13mm Kupferdraht wie in http://www.ebay.de/itm/10pcs-Copper-868MHz-50Ω-Spring-Antenna-for-Wireless-Communication-System-13mm/302038280721?ssPageName=STRK%3AMEBIDX%3AIT&_trksid=p2060353.m2749.l2649 oder sollte es schon etwas mehr sein?

Gruß und Danke!

[gloob]

Ich hab mal eine Stabantenne geöffnet. Da ist nix anderes drinne als so eine Drahtwindung.
Kannst du also ohne Probleme nutzen

[SabineT]

Stelle ich die Frage mal etwas konkreter... reicht die Leistung eines 3,3V Anschlusses eines Nano aus oder müsste man ähnlich wie beim nRF den 5V Anschluss nutzen und die Spannung auf 3,3V runter transformieren? Und wo wir schon mal dabei sind... welche Art Antenne nutzt Ihr? Reicht ein 13mm Kupferdraht wie in http://www.ebay.de/itm/10pcs-Copper-868MHz-50Ω-Spring-Antenna-for-Wireless-Communication-System-13mm/302038280721?ssPageName=STRK%3AMEBIDX%3AIT&_trksid=p2060353.m2749.l2649 oder sollte es schon etwas mehr sein?

Gruß und Danke!

Stromaufnahme vom RFM69CW ist max. 45 mA bei max. Leistung (+13 dBm). Die Frage ist nur, ob man bei einem Sensor nicht ohnehin besser die 3,3V-Variante vom Nano nimmt und mit 2x AAA oder 1x CR2032 versorgt.
Zur Antenne: normal wird beim RFM69 für 868MHz einfach ein 82mm langer Draht verwendet, allerdings wird da die Anpassung eh nur Pi x Daumen sein...

[gloob]

Stromaufnahme vom RFM69CW ist max. 45 mA bei max. Leistung (+13 dBm). Die Frage ist nur, ob man bei einem Sensor nicht ohnehin besser die 3,3V-Variante vom Nano nimmt und mit 2x AAA oder 1x CR2032 versorgt.
Zur Antenne: normal wird beim RFM69 für 868MHz einfach ein 82mm langer Draht verwendet, allerdings wird da die Anpassung eh nur Pi x Daumen sein...

Dann würde ich keinen Arduino Nano mehr nehmen sondern einen Pro mini. Spannungswandler runter gelötet und die LED entfernt, kann man ihn wirklich mit Batterien betreiben.

[DerFrickler]

Stromaufnahme vom RFM69CW ist max. 45 mA bei max. Leistung (+13 dBm). Die Frage ist nur, ob man bei einem Sensor nicht ohnehin besser die 3,3V-Variante vom Nano nimmt und mit 2x AAA oder 1x CR2032 versorgt.
Zur Antenne: normal wird beim RFM69 für 868MHz einfach ein 82mm langer Draht verwendet, allerdings wird da die Anpassung eh nur Pi x Daumen sein...

Ich habe hier einen RFM69 für 433 MHz (ähnlich dem hier für 868 MHz). Eine standardmässige (Steckbrettfreundlich) Stiftleiste kann man da aber nicht anlöten. Wie bekommt Ihr die montiert?

[SabineT]

Die lötet man direkt auf den Print. Schau dir mal den TinyTX3 https://nathan.chantrell.net/tinytx-wireless-sensor/ an. Dann siehst du, was ich meine.

[DerFrickler]

Das habe ich befürchtet. Gibt es Prints die nur den RFM69 auf Stiftleiste erweitern? Ich würde die Module gerne erst einmal bezüglich ihrer Reichweite testen.

[gloob]

https://www.openhardware.io/view/392/Minimalist-RFM69HW-Shield-for-Wemos-D1-Mini

Die boards könntest du nutzen.

[SabineT]

https://www.openhardware.io/view/392/Minimalist-RFM69HW-Shield-for-Wemos-D1-Mini

Die boards könntest du nutzen.

ACHTUNG: RFM69HW hat eine andere Pin-Belegung!
Also nicht wundern, wenn die Beschriftung auf dem Print nicht mit dem RFM69CW übereinstimmt

Aber einfacher ist es, den RFM einfach mit ein paar Drahtstücken "schwebend" auf ein Stück Lochrasterplatte zu montieren, wenns erst mal nur zum Testen sein soll.

[Beta-User]

Ist die HW-Variante in D erlaubt? Irgendwie hatte ich abgespeichert: nein....

[gloob]

Man kann auch einfach die RFM69W Variante nehmen, wenn man "bedenken" mit der HW hat.

[DerFrickler]

womit wir beim nächsten Problem angekommen sind, welche RFM69 Varianten gibt es und welche sind in Deutschland erlaubt / nicht erlaubt?

So ganz nebenbei wäre eine Zusammenfassung einiger Details an zentraler Stelle sicherlich hilfreich.

[gloob]

Ich nutze den RFM69W als LaCrosseGateway und als MySensors Gateway.
Auch wird er bei eigentlich allen MySensors Projekten (https://www.openhardware.io) genutzt, wenn ein RFM69 zum Einsatz kommt.

[DerFrickler]

Man kann auch einfach die RFM69W Variante nehmen, wenn man "bedenken" mit der HW hat.

Hallo zusammen, ich möchte diesen Punkt noch mal etwas ausführlicher betrachten. Aktuell habe ich testweise einen Sensor im Garten montiert der ein RFM59W Modul enthält, wie auch der Gateway. Testweise lasse ich mir die RSSI Werte am Gateway anzeigen, die zwischen -96 bis -104 schwanken. Soweit noch ganz o.k., da darf dann aber nicht mehr viel anderes dazwischen funken. Im Keller (da soll der GW final installiert werden) ist dann Schicht; hier scheint irgendetwas massiv zu stören bzw. abzuschirmen.

Ich werde am Samstag mal eine Sensor-Platine mit einem HW Modul und RSSI Implementierung testen... mal sehen was dabei herauskommt.

Aber jetzt mal grundsätzlich.... sind die RFM69HW Module in Deutschland erlaubt oder nicht?

Gruß!

[DerFrickler]

Ich möchte dann an dieser Stelle noch mal meine Ergebnisse zum Thema RFM69W oder RFM69HW zusammenfassen.

Es stellt sich hier nicht die Frage ob RFM69W oder RFM69HW, sondern welche Sendeleistung. Erlaubt ist im Frequenzbereich um 868Mhz 25mW was in etwas 14dBm entspricht. Der RFM69W schafft 13 dBm, der RFM69HW 20 dBm. D.h., ohne Modifikation ist der RFM69HW nicht einsetzbar und beim RFM69W, der mit 13dBm sendet, würde man 1 dBm verschenken.

Lösung: Man nutzt den RFM69HW und reduziert die Sendeleistung auf 14dBm was 25mW entspricht.

Das erreicht man indem man folgendes Makro nutzt:

#define MY_RFM69_MAX_POWER_LEVEL_DBM

Wie der Syntax dazu genau aussieht, das kann ich augenblicklich noch nicht sagen.