In diesem Beitrag beschreibe ich, wie man mit recht einfachen Mitteln und wenigen Bauteilen selbst eine kleine Funk-Wetterstation mit Temperatur und Luftfeuchtigkeit bauen kann.
Als Grundlage verwenden wir:
- Einen Temperatur- und Luftfeuchtigkeitssensor vom Typ DHT22
- Einen Mikrocontroller vom Typ ATtiny85
- Ein 433 MHz Funkmodul (Sender)
- Einen 5V DC-Boost-Konverter
- Ein bis vier Mignon-Batterien (AA, LR6)
Der ATtiny85 Mikrocontroller befindet sich die meiste Zeit im Tiefschlaf-Modus und wacht in regelmäßigen Zeitabständen durch den integrierten Watchdog kurz auf, um den DHT22 Sensor auszulesen und die Daten per Funk zu übermitteln.
Der DC-Boost-Konverter dient als Step-Up Wandler und macht aus 0,6 bis 4,7V von den Batterien eine stabile 5V Versorgungsspannung für die anderen Bauteile.
Softwareseitig verwenden wir zur Programmierung des ATtiny85 die ArduinoIDE und zur Funkübertragung die Open Source paketbasierte Funkmodul-Bibliothek RadioHead.
Aufbau der Hardware
Der Aufbau der Hardware erfolgt nach folgendem Schema:

Wichtig sind hier der 4,7 kOhm Widerstand vom Data-Pin des DHT22 gegen +5V, sowie der 10 kOhm Widerstand vom Reset-Pin des ATtiny85 gegen ebenfalls +5V.
Die beiden Leuchtdioden sind optional und dienen lediglich der Anzeige einer Aktivität des Mikrocontrollers. Es sollten am besten Low-Current LEDs (2mA) mit 1,5 kOhm Vorwiderständen verwendet werden, um möglichst stromsparend zu arbeiten.
Die grüne LED blinkt bei jeder Funkübertragung kurz auf und die rote LED zeigt, vom Mikrocontroller gesteuert, den Status an (einmal blinken = Ok, mehrfach blinken = Fehler).
Die direkte Verbindung vom Pluspol der Batterien zum Pin 7 (ADC1) des ATtiny85 dient der Spannungsüberwachung der Batterien.
Je nach Qualität des DC-Boost-Konverters kann es erforderlich sein, zwischen GND und +5V einen zusätzlichen kleinen Kondensator (~20µF) zu schalten.
Das Ganze platzsparend auf eine kleine Leiterplatte gebracht und in ein Gehäuse gesteckt könnte dann so aussehen:



Software
Die Software wird mit der ArduinoIDE auf den ATtiny85 Mikrocontroller geflasht. Wie dies grundlegend funktioniert, habe ich bereits im Beitrag ATtiny Mikrocontroller mit Arduino IDE programmieren beschrieben.
Die gesamte Software ist im GitHub Repository verfügbar.
Es wird bewusst nicht die aktuelle DHT22-Library von Adafruit eingesetzt, da diese für den ATtiny85 Mikrocontroller zu viel Speicher benötigt. Stattdessen wird die Fast DHT22 Library von Sergey Denisov benutzt.
Mit dieser Software schläft der ATtiny85 die meiste Zeit im Power Down Modus und benötigt dadurch extrem wenig Strom (< 10 µA für die gesamte Schaltung).
Der Watchdog weckt den Mikrocontroller alle 8 Sekunden auf, woraufhin dieser einen Zähler hoch zählt und sich wieder schlafen legt.
Bei jedem siebenten Aufwachen, also alle 56 Sekunden, werden die Temperatur und die Luftfeuchtigkeit vom Sensor abgerufen und per Funk übertragen.
Möchte man genau alle 60 Sekunden einen Messwert haben, so kann im Arduino Sketch im oberen Config-Bereich #define WATCHDOG_TIME 1
und #define WATCHDOG_WAKEUPS_TARGET 60
gesetzt werden. Dies führt jedoch zu einem etwas höheren Energieverbrauch, da der Mikrocontroller dann 8 mal häufiger aufwacht.
Bei jedem 30. Messvorgang wird zudem der Batteriestatus über den Analog-Digial-Konverter (ADC) abgerufen und per Funk übertragen. Dies ist über #define BAT_CHECK_INTERVAL 30
einstellbar.
Der Batteriestatus wird in zwei Formaten übertragen. Dies ist zum Einen der reine ADC-Messwert im Bereich von 0 bis 255, was 0V bis 5V entspricht und zum Anderen eine berechnete Prozentangabe. Diese Prozentangabe wird mit Hilfe der beiden Optionen #define BAT_ADC_MIN 40
(~0,78V) und #define BAT_ADC_MAX 225
(~4,41V) ermittelt.
Board-Auswahl in der ArduinoIDE
Die folgenden Board-Einstellungen müssen vor dem Kompilieren in der ArduinoIDE vorgenommen werden:
Board: ATtiny25/45/85
Prozessor: ATtiny85
Clock: Internal 8 MHz
Mögliche Probleme und Lösungen
Fehler beim Kompilieren
Abhängig von den verwendeten Versionen der ArduinoIDE und der RadioHead Bibliothek kann es beim Kompilieren zu Fehlermeldung wie beispielsweise ‘Serial’ was not declared in this scope
kommen. Grund hierfür ist, dass beim kompilieren einzelne Module von RadioHead mit kompiliert werden, die jedoch gar nicht benötigt werden.
Die einfachste Lösung ist hier das Löschen oder Umbenennen der folgenden .cpp
und .h
Dateien der RadioHead Bibliothek: RH_CC110
, RH_E32
, RH_MRF89
, RH_NRF24
, RH_NRF905
, RH_RF22
, RH_RF24
, RH_RF69
, RH_RF95
, RHHardwareSPI
, RHNRFSPIDriver
, RHSPIDriver
Daten werden nicht empfangen
Anhand der blinkenden LEDs ist erkennbar, dass der Sensor arbeitet, aber ein Empfänger bekommt keine Daten. Die häufigste Ursache dafür ist, dass die Fuse-Bits des ATtiny85 falsch gesetzt sind und er dadurch mit einem Takt von 1 MHz anstatt den erwarteten 8 MHz arbeitet.
Für den richtigen Takt sollte das Byte lfuse
auf 0xE2
gesetzt sein. Dies wird am einfachsten erreicht, indem man über die ArduinoIDE über das Menü Werkzeuge -> Bootloader berennen den Bootloader sowie die passenden Fuse-Bits in den ATtiny85 schreibt. Anschließend muss der Sketch des Wettersensors nochmals neu auf den Controller hochgeladen werden.
Übertragene RadioHead Datenpakete
Es werden vier verschiedene Arten von Datenpaketen übertragen. Das jeweils erste Byte eines Datenpakets kennzeichnet dabei die Art.
0x00 Startmeldung
Dieses Datenpaket wird einmalig beim Start des Mikrocontrollers übertragen.
Es besteht aus nur einem Byte mit dem Wert 0x00
.
0x01 Temperatur und Luftfeuchtigkeit
Dieses Datenpaket wird nach jeder Messung der Temperatur und Luftfeuchtigkeit übertragen.
Es besteht aus 9 Byte: 0x01
, gefolgt von 4 Byte Temperatur und 4 Byte Luftfeuchtigkeit, jeweils als Float Zahl im Little-Endian Format.
0x01 t t t t h h h h
z.B. 0x01 0xcd 0xcc 0xd0 0x41 0xcd 0xcc 0x4e 0x42
, was 26,1°C und 51,7% Luftfeuchtigkeit entspricht
0x02 Batteriestatus
Dieses Datenpaket besteht aus 3 Byte, beginnend mit dem Code 0x02
, gefolgt vom Batteriestatus in Prozent (0 bis 100) und dem reinen ADC-Wert (0 bis 255).
z.B. 0x02 0x64 0xe7
, was 100% und einem ADC-Wert von 231 entspricht
0xEE Fehlermeldung
Dieses Datenpaket mit einem Byte 0xEE
wird gesendet, wenn es bei der Messung der Temperatur/Luftfeuchtigkeit einen Fehler gab.
Batterielebensdauer
Mit dieser Hard- und Software zeigt sich nun schon über mehrere Monate, dass circa 1% pro Monat von den Batterien verbraucht wird.
Damit sollte die Funk-Wetterstation also mehrere Jahre problemlos mit den drei Mignon-Batterien arbeiten können.
Beispiel-Sketch für einen Empfänger
Hier ist ein Beispiel-Sketch für einen Empfänger zu finden, welcher unter anderem auf einem Arduino Nano oder Uno verwendet werden kann.
Die empfangenen Nachrichten werden anhand des Typs der Nachricht unterschiedlich verarbeitet. Die empfangenen Daten werden über die serielle Schnittstelle (USB-Anschluss eines Arduinos) ausgegeben.
Das Beispiel geht davon aus, dass alle empfangenen Nachrichten von einem Wettersensor stammen. Im produktiven Einsatz sollte beispielsweise anhand der Absenderadresse geprüft werden, ob die Nachricht von einem Wettersensor stammt.
Anwendungsbeispiele
Ein Beispiel für die Anwendung dieser Mini-Wetterstation ist Überwachung und Protokollierung der Temperatur und Luftfeuchtigkeit im Gewächshaus unseres Gartens.

Die Wetterstation sendet im Minutentakt die aktuellen Daten an die Heimautomatisierung ioBroker. Hier nimmt der ebenfalls von mir entwickelte Adapter ioBroker.radiohead die Daten entgegen. Als Hardware wird auf der Empfängerseite (ioBroker) lediglich ein Arduino Nano mit 433 MHz Funkempfänger benötigt, der als Funk-Seriell-Gateway dient.
Zweites Beispiel wäre ein Arduino mit 433 MHz Funkempfänger und einem LCD-Display, welcher die gemessenen Daten entgegen nimmt und auf dem Display darstellt.
Weiterhin kann über das Node.js Modul radiohead-serial ein solcher Wettersensor in jedes Node.js Programm eingebunden werden. Damit sind die Möglichkeiten nahezu unendlich 😉
Lizenz
Lizenziert unter GPL Version 2
Copyright (c) 2017-2023 Peter Müller
17. Nov. 2017 um 10:33
Hallo,
danke für die Dokumentation des Projekts, welches ich für die Temperatur- und Luftfeuchtemessung in meinem Haus verwenden möchte.
Ich habe noch vier Fragen dazu:
1. Wie sieht es mit der Reichweite der 433 MHz Sender mit Antenne aus? Ich habe gelesen, dass die Reichweite mit der Versorgungsspannung skaliert. Durch den StepUp-Wandler werden diese mit 5V versorgt. Es können aber bis zu 12V verwendet werden. Ist die Reichweite für die Überwachung eines Hauses (durch Mauern) bei 5V ausreichend? (Einschätzung genügt).
2. Auf der Lochstreifenplatine ist neben dem Elko (der vermutlich als Glättung der Spannung vom StepUp-Wandler fungiert) noch ein weiterer, kleiner blauer Kondensator zu sehen. Welche Funktion hat dieser und wie wird er im Layout verbaut?
3. Warum wurden gerade 4 AAA Batterien verwendet? Da diese mit 4.5V am nächsten an den 5V liegen? Theoretisch würden auch 2 AA gehen, die zusammen ca. 3 V erzeugen, durch den StepUp-Wandler aber wiederum zu 5V gemacht werden. Da die Leistung die gleiche bleibt, würden dann die Batterien sozusagen “einfach” nur schneller leer werden, richtig?
4. ATTINY85: Welche Version des Bausteins wird genau verwendet?
Ich sage schon mal vielen Dank für die Beantwortung der Fragen und freue mich, bald selbst loslegen zu können 🙂
18. Nov. 2017 um 16:57
Hallo Norman,
freut mich zu lesen, dass du das Projekt verwenden möchtest.
Zu deinen Fragen:
1) Nach meinen Erfahrungen bringen die Sendemodule auch bei 5V schon eine durchaus gute Sendeleistung. Entscheidend für die Reichweite ist mehr ein entsprechend guter Empfänger mit einer guten Antenne. Ich habe bei mir die in meinem Beitrag DIY 433 MHz Dipol-Antenne beschriebene Antenne im Einsatz. In der Kombination (5V und 17cm Antenne am Sender, Dipol-Antenne am Empfänger) sind bei mir Entfernungen von über 50m, durch mehrere Wände hindurch problemlos möglich.
2) Der große Elko (20µF) stabilisiert die Spannung vom StepUp-Wandler, da dieser bei den geringen Strömen teilweise etwas zu träge reagiert. Der kleine blaue Kondensator (100nF) ist zwischen den AREF-Pin und Masse geschaltet und dient der Stabilisierung der internen Referenzspannung des ADCs vom ATtiny.
3) Die vier AA Batterien habe ich verwendet, weil ich für dieses den Batteriehalter noch da hatte und anfangs auch keine Erfahrungen hatte, wie lange die Batterien halten werden. Es können problemlos auch ein, zwei oder drei Batterien vom Typ AA oder AAA verwendet werden. Diese sind dann eben nur schneller leer. Akkus würde ich nicht empfehlen, da diese durch den StepUp-Wandler tiefenentladen werden würden. Mein Sensor läuft mit vier AA-Batterien nun schon rund 5 Monate und die Batterien sind immer noch zu rund 92% voll.
Bei einer anderen Anzahl an Batterien muss im Code nur die Zeile
#define BAT_ADC_MAX 225
für den ADC-Wert bei 100% angepasst werden, wobei 255 5V und 0 0V entspricht.4) Ich habe den ATtiny85-20PU im PDIP-8 Gehäuse verwendet. Andere Bauformen sollten jedoch genauso funktionieren.
Viel Erfolg 😉
2. Jan. 2018 um 17:26
Hallo Peter,
vielen Dank für die Veröffentlichung sowie die guten Erklärungen.
Ich versuche die Anleitung bestens zu verfolgen, stosse aber auf Problemen anhand der gewählten lib zum Senden. Bei RadioHead warnen sie das der Platz auf dem ATTiny85 sehr begrenzt ist. Ich habe leider die Grenze überschritten.
Mein Setup:
Digispark ATTiny85 USB
DHT22
433Mhz Sendemodul
(Optional: 5V Umwandler)
Alles zusammenzubauen macht erst Sinn wenn ich das Programme hochladen kann. Wahrscheinlich liegt mein Problem daran dass ich über USB es kompilieren will. Beim Bau ist mein Problem SPI dass für ATTiny85 nicht geht. Als Aternative habe ich tinySPI genommen (https://github.com/jscrane/SPI) was leider nicht funktioniert hat.
In platformio (mit den nötigen Änderungen), bin ich weiter damit gekommen aber mit RadioHead ist es einfach zu gross, glaube ich. Z.B.:
$ pio run –target upload
Processing digispark-tiny (platform: atmelavr; board: digispark-tiny; framework: arduino)
Library Dependency Graph ( http://bit.ly/configure-pio-ldf )
|–
| |– v1.0.1
|–
Linking .pioenvs/digispark-tiny/firmware.elf
Checking program size
text data bss dec hex filename
6250 78 286 6614 19d6 .pioenvs/digispark-tiny/firmware.elf
Error: The program size (6328 bytes) is greater than maximum allowed (6012 bytes)
Es ist ja lustig finde ich mit so wenig Speicher zu arbeiten. Ich werde es versuchen mit Manchester zu machen und werde den Code anpassen. Hast Du Vorschläge wo man aufpassen sollte?
Vielen Dank im Voraus für die Hilfe!
Gruss
Brian
2. Jan. 2018 um 19:20
Hallo Brian,
soweit ich das sehe, ist das Problem bei dir, dass bei dem Digispark ATtiny85 durch den integrierten Bootloader nur noch 6k von den eigentlichen 8k des Flash zur Verfügung stehen. Damit reicht der Speicher bei einem Upload über USB nicht aus.
Es sollte aber trotzdem möglich sein, den Controller über das SPI bzw. ISP Interface zu programmieren, wobei die vollen 8k genutzt werden können. Dabei würdest du dann den Bootloader überschreiben, sodass erstmal kein weiteres Programmieren über USB möglich ist.
Als ISP-Programmer kannst du zum Beispiel einen Arduino Nano verweden, wie ich hier beschrieben habe.
Die entsprechenden Anschlüsse zum Programmieren an deinem Digispark ATtiny85 wären dann wie folgt:
Um Speicherplatz zu sparen könnte man wahrscheinlich noch auf die Nutzung von
rh_manager
(RHDatagram
) verzichten und stattdessen die Nachrichten per Hand zusammenbauen und dann mitrh_driver
(RH_ASK
) senden.Das wäre jedoch mit etwas mehr Programmieraufwand verbunden.
4. Jan. 2018 um 11:28
Hallo Peter,
vielen Dank für die tolle Beschreibung! Da ich auch gerade etwas sehr ähnliches umsetze (mit 3,3V StepUp und zum Senden das LaCrosse Protokoll) habe ich zunächst mal den Stromverbrauch gemessen.
Im Sleep-Modus habe ich ca. 0,03mA. Damit bin ich auch zufrieden.
Meine Sketch benötigt derzeit noch über 3sek. um den Sensor auszulesen und die Daten zu senden. Dabei fließt geschätzt ein Strom von 15mA (beim Senden kurzzeitig mehr, dafür ohne Senden etwas weniger…dafür ist mein Messgerät zu träge).
Dadurch habe ich eine berechnete Batterielaufzeit mit 2xAA (2500mAh) von 114 Tagen. Das ist noch nicht so richtig gut.
Wie lange benötigt Deine Sketch (geschätzt) um den Sensor auszulesen und zu senden? Hast Du den Verbrauch während dessen mal gemessen?
Danke.
Gruß
Bismosa
4. Jan. 2018 um 17:57
Hallo Bismosa,
deine 0,03mA (30µA) erscheinen mir bei 3,3V im Sleep-Modus noch recht viel. Verwendest du den
SLEEP_MODE_PWR_DOWN
und hast du den ADC sowie den Analog Comperator deaktiviert?Rund 15mA im Wach-Zustand hatte ich auch.
Das gesamte Aufwachen, Messen und Senden dauert bei mir etwa 0,4 Sekunden. Das Senden macht dabei nur wenige Millisekunden aus, wodurch auch eine Strommessung währenddessen schwierig wird.
5. Jan. 2018 um 8:53
Hallo Peter,
vielen Dank für die schnelle Antwort. Ich habe gestern Abend noch weiter testen können.
Ich habe nun Deinen Sketch als Vorlage genommen und nur das Senden nicht mit RadioHead sondern mit LaCrosse umgesetzt. Die Geschwindigkeit ist enorm.
Wie hast Du die 0,4 Sekunden ermittelt?
Ich hatte allerdings einige Startschwierigkeiten. Der DHT22 wollte absolut keine Daten liefern….bis ich dann herausgefunden habe, das der Attiny85 auf 16MHz laufen muss.
Ich habe dann immer noch keine Humidity-Werte bekommen. Daher habe ich den Sensor getauscht…der erste hat wohl einen Defekt.
Der 2. Sensor hat nun einen noch höheren Standby-Verbrauch. Nach meinem Schätzeisen 0,12mA. Der Attiny ist nicht schuld. Der Strom bleibt gleich, wenn ich den Attiny zum Programmieren umstecke.
Ich habe auch zusätzlich das Problem, das beim ersten Messvorgang (direkt nach dem Einschalten) ein Fehler beim auslesen des DHT22 zurückgegeben wird. Dies konnte ich nun erfolgreich durch ein
delay(2000);
im Setup umgehen. Ab dem 2.Durchlauf wird das nicht mehr benötigt.
Wie viel Strom mein Versuchsaufbau nun wirklich benötigt, kann ich so nicht mehr feststellen. Bis mein Multimeter etwas anzeigt ist der Sendevorgang schon abgeschlossen. Das werde ich dann durch einen Langzeitversuch ermitteln müssen.
Witzig ist auch, das bei einer Temperatur von 21,3°C und Luftfeuchtigkeit von 55% meine Weihnachtsbeleuchtung (an billigen Funksteckdosen) einfach ausgeht…
Danke!
Gruß
Bismosa
5. Jan. 2018 um 10:11
Die 0,4 Sekunden habe ich ganz einfach mit Hilfe meiner verbauten LED, einer Stoppuhr und mehreren Messungen ermittelt.
Ich habe den ATtiny85 mit 8MHz laufen.
Den Stromverbrauch des DHT22 im Leerlauf hatte ich auch versucht zu messen. Der war aber so gering, dass ich ihn nicht mehr messen konnte. Du könntest hier mal einen höheren Widerstand (z.B. 10kOhm) zwischen +3,3V und dem Data-Pin des DHT22 versuchen.
Zum Messen des Stroms bei aktivem Controller kannst du
sleep_mode();
in der FunktionenterSleep
einfach mal auskommentieren. Dadurch würde er nicht mehr in den Sleep-Modus gehen, sondern permanent den Sensor abfragen und die Daten Senden.7. Jan. 2018 um 15:32
Hallo,
keine Ahnung warum…aber erst nachdem ich
digitalWrite(DHTPIN, LOW);
pinMode(DHTPIN, INPUT);
vor dem deepSleep hinzugefügt habe, wurde der Stromverbrauch meines DHT geringer.
Da sich durch messen der Stromverbrauch nicht wirklich ermitteln lässt, habe ich jetzt einen vollen (frisch geladenen) Akku genommen und schicke alle 14 Sekunden einen neuen Messwert raus. Das lasse ich jetzt mal ein paar Tage laufen und werde dann hoffentlich besser abschätzen können, wie hoch der mittlere Verbrauch wirklich ist.
Ich nutze mittlerweile zum Senden das “Hideki” Protokoll von hier: https://bitbucket.org/fuzzillogic/433mhzforarduino/wiki/Home
Klappt mit FHEM super. Ich habe dann mal die Zeit vom Attiny messen lassen und mir dies auf einem anderen Kanal gesendet. Somit weiß ich jetzt genau, dass ich derzeit ohne Optimierungen (mein Code sieht noch sehr Wild aus!) inkl. Senden (ohne Analogwert) bei 636ms Ausführungszeit bin.
Ich bin mal gespannt!
Gruß
Bismosa
13. Jan. 2018 um 19:51
Schön, dass du voran kommst 🙂
Die Konfiguration des Pins übernimmt eigentlich die DHT22 Library beim
dht_init
sowie jedemdht_read
.27. Jan. 2018 um 12:36
Hallo,
kurze Rückmeldung nochmal. Ich habe jetzt 22 Tage meinen Versuchsaufbau mit einem Eneloop Akku laufen lassen.
Geladen habe ich ca. 1450mAh. Bei einem Messwert alle 14 Sekunden!
Wenn ich nur jede Minute einen Messwert senden würde und statt des Akkus eine Batterie (2500mAh) verwenden würde, müsste ich auf ein Laufzeit von ca. 150 Tagen kommen…
Bevor ich den Akku geladen habe, hatte ich noch eine Akkuspannung von 1,23V. Insgesamt ist die Akkuspannung ja geringer. Somit könnte sich die Laufzeit erhöhen, da eine Batterie anfangs eine höhere Spannung hat und somit die Verluste über den StepUp geringer ausfallen sollten.
Optimaler wäre sicherlich 2 Batterien zu verwenden. Dann sind die Verluste noch geringer und eine Laufzeit von einem Jahr vermutlich problemlos möglich.
Alles weitere werde ich dann hier Schreiben:
https://forum.fhem.de/index.php/topic,52755.255.html
Vielen Dank für Deinen Beitrag und die Tipps!
Gruß
Bismosa
1. Feb. 2018 um 20:37
Hallo.
Vorab erstmal: sehr detailliert Anleitung. Kompliment und vielen Dank. Jetzt zu meinem Problem: Ich nutze das Digisparc USB Developer Board (Ja, ich weiß, wahrscheinlich wird der Sketch nicht passen. So weit bin ich aber noch nicht.) Ich scheitere gerade an folgender Fehlermeldung:
Dokumente/Arduino/libraries/RadioHead/RH_E32.h:266:23: error: ‘Serial’ was not declared in this scope
RH_E32(Stream *s=&Serial, uint8_t m0_pin = 4, uint8_t m1_pin = 5, uint8_t aux_pin = 8);
Hatte jemand schon eine ähnliche Meldung und weiß wie ich diese abschalte? – Danke vorab!
2. Feb. 2018 um 18:34
Hallo Stephan,
die Fehlermeldung deutet darauf hin, dass du in der ArduinoIDE ein Board ausgewählt hast, das über keine serielle Schnittstelle verfügt.
Mit der Auswahl des richtigen Boards sollte diese Fehlermeldung verschwinden.
2. Feb. 2018 um 19:47
Ich habe dasselbe Problem.
Welches Board muss genau ausgewählt werden?
Ich habe folgendes ausgewählt:
— ATtiny25/45/85
— ATtiny85
— Internal 8Mhz
— Arduino as ISP
Ich nutze dabei einen Attiny85-20 PU (DIP).
Und als Programmer einen Arduino Nano V3 und den Aufbau aus der Anleitung.
6. Feb. 2018 um 15:23
Das sieht soweit gut aus.
Ich habe es eben selbst noch mal probiert und kam zu dem selben Fehler. Scheinbar versucht die ArduinoIDE alle Module der RadioHead Bibliothek zu kompilieren und es kommt dann bei Teilen, die für die Wetterstation nicht benötigt werden, zu diesem Fehler.
Die einfachste (wenn auch vielleicht nicht schönste) Lösung ist es, die folgenden Dateien aus dem Verzeichnis
Dokumente/Arduino/libraries/RadioHead/
zu löschen:RH_E32.cpp
,RH_E32.h
,RH_RF24.cpp
undRH_RF24.h
9. Feb. 2018 um 6:22
Hallo Peter.
Vielen Dank für deine Unterstützung. Ich habe jetzt in RF22 und RF24 die letzten Serial aaskommentiert und RH_E32 umbenannt. Dadurch hat sich die Fehlermeldung wie folgt geändert:
Ich nutze auch die ATTiny25/45/85, ATTiny85, Internal 8Mhz Board Einstellung.
Zusätzlich noch Digisparc Default 16.5MHz, das macht aber bei der Fehlermeldung keinen Unterschied.
10. Feb. 2018 um 10:34
Hallo Stephan,
das scheint irgendwie mit der Arduino-Version zusammenzuhängen. Auf meinem einen System mit Ubuntu und ArduinoIDE v1.6.9 kompiliert der Sketch nach der ersten Änderung problemlos. Unter Windows 10 mit v1.8.5 erhalte ich jedoch die von dir beschriebene Fehlermeldung.
Einfachste Lösung ist auch hier wieder die nicht benötigten Dateien von der Bibliothek zu löschen oder umzubenennen. Jeweils die `.cpp` und `.h` Datei von `RH_CC110`, `RH_MRF89`, `RH_NRF24`, `RH_NRF905`, `RH_RF69`, `RH_RF95`, `RHHardwareSPI`, `RHNRFSPIDriver` und `RHSPIDriver`.
11. Feb. 2018 um 8:40
Hi Peter.
So, nach jeder Menge Dateien umbenennen:
Build-Optionen wurden verändert, alles wird neu kompiliert
Der Sketch verwendet 6506 Bytes (79%) des Programmspeicherplatzes. Das Maximum sind 8192 Bytes.
Globale Variablen verwenden 371 Bytes (72%) des dynamischen Speichers, 141 Bytes für lokale Variablen verbleiben. Das Maximum sind 512 Bytes.
Jetzt besorge ich mir noch einen ISP Programmierer und dann bin ich echt gespannt.
Danke für deine Hilfe!
25. Feb. 2018 um 0:08
Hallo Peter,
endlich geht’s bei mir auch mal weiter – lang lang ist’s her.
Ich stelle mich anscheinend zu doof an, den Attiny85-20PU mit deinen Sourcen programmiert zu bekommen. Bzw. scheitert es schon am kompilieren.
Ich verwende die Arduino IDE 1.8.5 und habe mir die RadioHead Library runtergeladen und entsprechend eingebunden.
Weiter oben in den Kommentaren wurde ja auch schon darüber gesprochen, dass der Attiny wohl kein SPI hat. Leider hängt hier bei mir das Problem. Ich füge ein kleines Bruchstück der Fehlermeldung des Kompilers ein:
Habe ich eine falsche Library oder woran könnte es noch liegen, dass es bei dir funktioniert, bei mir aber nicht?
Danke nochmal für deine Hilfe!
Grüße,
Norman
25. Feb. 2018 um 10:06
Hallo Norman,
hast du, wie in den anderen Kommentaren schon beschrieben, die Dateien aus der RadioHead Bibliothek entfernt?
Betroffen sind jeweils die `.cpp` und `.h` Datei von `RH_CC110`, `RH_E32`, `RH_MRF89`, `RH_NRF24`, `RH_NRF905`, `RH_RF24`, `RH_RF69`, `RH_RF95`, `RHHardwareSPI`, `RHNRFSPIDriver` und `RHSPIDriver`.
Sollte das nocht nicht helfen, kannst du noch `RHGenericSPI` und `RHSoftwareSPI` entfernen.
25. Feb. 2018 um 13:35
Hallo Peter,
Support sogar am Sonntag 🙂 Danke!
Zunächst: Ich habe wohl irgendeinen Fork erwischt gehabt, dort waren einige der Dateien, die man löschen sollte, gar nicht vorhanden. Ich habe nun die RH-Library 1.83 von hier http://www.airspayce.com/mikem/arduino/RadioHead/RadioHead-1.83.zip genommen und die von dir angegebenen Dateien gelöscht.
Jetzt – und das ist völlig klar – meckert der Compiler natürlich, dass diese Dateien fehlen (sorry, ich kenne die Tags nicht, mit denen man den Source-Code so schön einbetten kann):
Kann man den Arduino Compiler irgendwie anweisen, sowas zu überspringen?
In der Arbeit mache ich ausschließlich VHDL 😉
Danke dir nochmal!
Grüße,
Norman
25. Feb. 2018 um 16:13
Kein Problem, ich helfe gerne und die Formatierung kann ich auch leicht anpassen.
Oh, da hatte ich wohl die `RH_RF22` in meiner Auflistung vergessen. Die also auch noch löschen 😉
Bis auf `RadioHead`, `RH_ASK`, `RHCRC`, `RHDatagram`, `RHGenericDriver`, `RHReliableDatagram` können für dieses Projekt eigentlich alle anderen Dateien der RadioHead Bibliothek weg.
Ich habe leider bisher noch keinen Weg gefunden, dem Arduino Compiler zu sagen, dass er nur die Teile kompilieren soll, die auch wirklich eingesetzt werden.
25. Feb. 2018 um 18:26
Hallo Peter,
ich nochmal 🙁
Jetzt passt es mit dem SPI-“Problem”.
Ich denke aber, dass die IDE ein Problem mit den Datentypen uint8_t char hat.
Ich benutze Version 1.8.5. Auch wenn ich explizit eine Variable vom Typ uint8_t beispielsweise uint8_t abc=1; und “abc” dann in die dht_init-Funktion gebe, funktioniert es nicht.
Der zweite Fehler ist vermutlich eine Folge des ersten.
Ich habe die Bibliothek mehrmals über verschiedene Wege installiert. Mal über den Bibliotheksmanager, mal direkt in den library-Ordner kopiert. Leider fruchtet beides bisher nicht.
Hattest du das Problem auch? Hast du da auch eine Idee? Wenn ich die Parts auskommentiere, die in der Fehlermeldung genannt sind, kompiliert es auch. Allerdings bringt das halt nichts :-).
Also der Linker schlägt fehl, weil die IDE den definierten Pin als char ansieht… aber wie gesagt, auch wenn ich ein uint8_t übergebe, wird es als char interpretiert :(.
Ich danke dir nochmals für deine Hilfe – ich hoffe, ich benötige sie bald nicht mehr 😉
Grüße,
Norman
25. Feb. 2018 um 21:44
Hallo Peter,
ich antworte hier mal selber.
Also ich habe jetzt die IDE neu installiert und es auch zusätzlich auf meinem Laptop probiert. Immer das selbe, wie bereits oben beschrieben.
Wenn ich die funktionen aus der Datei “dht22.cpp” rauskopiere und als Funktionen in deinen Sourcecode einfüge (+ defines, etc.) kann ich kompilieren…
Ich weiß, dass das jetzt eigentlich nichts mehr mit deinem Projekt hier zu tun hat.
Hast du evtl. trotzdem eine Ahnung, was da schief sein könnte?
Danke und Grüße,
Norman
26. Feb. 2018 um 19:32
Also deiner Fehlermeldung nach scheint er den Code den Dateien `dht22.cpp` und `dht22.h` beim Kompilieren nicht zu berücksichtigen. Werden dir in der ArduinoIDE die beiden Dateien als Tabs mit angezeigt?
Ich denke mit dem Datentyp `uint8_t` an sich hat das eher wenig zu tun. Eigentlich sind `uint8_t` und `char` auch von der Sache her das gleiche.
26. Feb. 2018 um 19:42
Hallo Peter,
nein, es werden keine Tabs angezeigt. Sollte das der Fall sein?
Die Zeile
dht22 dht;
funktioniert. Wenn er die h-Datei nicht finden würde, würde das doch auch fehlschlagen, weil der Compiler ja dann nichts vom struct weiß.
Naja, danke dir! 🙂
26. Feb. 2018 um 19:57
Ja, eigentlich sollte es so aussehen:
Die beiden dht22-Dateien müssen im selben Verzeichnis liegen, wie die ino-Datei.
27. Feb. 2018 um 9:02
Servus!
Danke, funktioniert jetzt mit den Dateien. Ich dachte eigentlich, dass ich das aus dem Library-Ordner einbinden kann. Aber falsch gedacht. 🙂
Wenn ich mehrere dieser Sensorboxen an einem Server betreiben möchte, reicht es dann wenn ich:
// the own RadioHead address
#define RH_OWN_ADDR 0xca // 202
die Adresse ändere oder sind noch weitere Anpassungen notwendig?
Bevor ich das ganze mit Pimatic versuche, möchte ich es von den Attiny Clients an einen Arduino RH-Server ausprobieren.
Dazu braucht man dann einen ask datagram Server, richtig? Da muss ich mich noch einlesen.
Wirklich nochmal vielen Dank für deinen Input! 😉
27. Feb. 2018 um 9:24
Genau, es reicht wenn du jedem Sensor eine eigene Adresse gibst. Alles andere kann so bleiben.
Für den Server benötigst du den `RH_ASK` Treiber und als Manager kannst du `RHDatagram` oder `RHReliableDatagram` verwenden.
7. Mrz. 2018 um 21:16
Hallo Peter,
ich habe jetzt alles in Betrieb – mit deiner Hilfe :).
Server läuft und empfängt Daten. Hierzu verwende ich einen originalen Arduino Uno. Manchmal reagiert der Arduino aber nicht auf empfangene Pakete. Dass sie richtig ankommen habe ich mit einem Oszi und einem Logic-Analyzer geprüft. Also am Pin vom empfangenden Arduino passen die Signale.
Hattest du das Problem auch mal, dass die Pakete dann nicht verarbeitet werden?
Ich verwende einen RXB6-Empfänger und habe diesen ohne weitere PullUp/Down Widerstände an den Arduino angeschlossen.
Ich dachte erst, dass der Standardpin 11 nicht geeignet ist und habe auf den interrupt-fähigen Pin 2 gewechselt, doch leider keine Änderung.
Hast du noch Tips oder führt das jetzt zu weit?
Danke und Grüße,
Norman
18. Mrz. 2018 um 15:56
Hello,
I have installed RadioHead Library by I have a compilation issue not met with Arduino but with the Attiny85 . I used the same attend core .
Could you please help me to fix this issue.
thanks
In file included from /Users/manu/Documents/Arduino/libraries/RadioHead/RH_E32.cpp:6:0:
/Users/manu.marcon/Documents/Arduino/libraries/RadioHead/RH_E32.h:282:23: error: ‘Serial’ was not declared in this scope
RH_E32(Stream *s=&Serial, uint8_t m0_pin = 4, uint8_t m1_pin = 5, uint8_t aux_pin = 8);
18. Mrz. 2018 um 17:16
Hi Manu95,
that’s because of an issue with ArduinoIDE, RadioHead and the ATtiny85 controller. You have to delete (or rename) the following `.cpp` and `.h` files from the RadioHead library: `RH_CC110`, `RH_E32`, `RH_MRF89`, `RH_NRF24`, `RH_NRF905`, `RH_RF22`, `RH_RF24`, `RH_RF69`, `RH_RF95`, `RHHardwareSPI`, `RHNRFSPIDriver`, `RHSPIDriver`
Then it should compile without an error. 🙂
19. Mrz. 2018 um 9:04
Thanks Pete I would like to configure an arduino Uno as the receiver is it a feasible implémentation. Can you provide sketch example that has to be configure on the Uno side that run with your attiny85 tx settings. Kind regards
22. Mrz. 2018 um 9:49
Hi Manu,
I have created an example sketch for you: https://git.cryhost.de/crycode/attiny85-radiohead-dht22-weather-sensor/snippets/19
22. Mrz. 2018 um 19:07
Hi Peter tx for your help. Sketch are ok.
First question on the attiny85 tx side Yellow LED and red are blinking one time simustaneously when data are ? Is it normal behavior ?
Even i receive a signal on my rc arduino with the sketch you set i did not receive any data from the attiny85. But on the same receiver i am able to receive data from another tx with radiohead library but s’ender is another arduino. Something wrong beetween attiny85 and arduino uno ? Oscilloscope shows data receive from attiny85 at thé rugit time, is it something to do with pin assignment on the Uno side. Rgds
22. Mrz. 2018 um 19:09
Hi Peter on the receiver manager. Available always return_url false. I am Stil investigating’ do you have an advise to debug ? Rgds MAnu
23. Mrz. 2018 um 8:38
I fixed multiple issue : bootloader reste with right attiny core, all works perfectly thanks for the arduino sketch. Big thanks Peter
23. Mrz. 2018 um 16:57
That’s great 🙂
I’ll add some information in the article above.
4. Apr. 2018 um 13:57
Hi Peter
I have configured receiver part on a arduino uno équipped with alocal sensor with value saved on a local SD card. This sketch were running perfectly but when I have gaffe radiohead part to receive signal confirmé from attiny85 I receive value température and humidity but I am notre able to save data on local SD. Command SD. Open(file) hangs now. What is the dépendancy beetween SD library and radiohead receiver uno sketch you sent ?
Would appreciate your kind advise. Thx
5. Apr. 2018 um 19:59
I haven’t used the SD library so far. Maybe there are some timer conflicts or the interrupts from RadioHead interfere with the SD methods.
You can try to add `#define RH_ASK_ARDUINO_USE_TIMER2` to your sketch before `#include `.
You also may disable interrupts globally while accessing your sd card using noInterrupts() and interrupts(). Be careful, while interrupts are disabled, you cannot receive RadioHead messages.
23. Apr. 2018 um 14:24
Hallo!
Ein sehr interessantes Projekt – ich habe gerade etwas sehr ähnliches auf Basis eines abgespeckten Pro Mini entwickelt. Allerdings haut das mit dem Stromverbrauch bei mir noch nicht so ganz hin.
Der beste 5V-DC Booster, den ich gefunden habe, hat 235uA gezogen (während der Rest der Schaltung nur 12uA benötigt). Daher bin ich jetzt bei einem Set-Down-Wandler, muss nun aber einen 9V-Block nutzen was mir nicht so gefällt.
Welchen Wandler hat Du genau benutzt, wo kann man ihn beziehen?
Dan
23. Apr. 2018 um 16:18
Hallo Nils,
ich verwende einen StepUp dieser Art von ebay. Um Strom zu sparen habe ich noch von dem Modul die LED abgelötet.
23. Apr. 2018 um 17:44
Super, vielen Dank für die schnelle Antwort!
2. Jun. 2018 um 15:10
Hallo Peter, ich habe einen ATiny85 mit USB besorgt, sieht also ein wenig anders aus =).
Nun möchte ich das Sketch flashen aber ich habe nur 6012 Bytes Platz…
Das Sketch hat aber 7072 Bytes (117%)
Hast du da möglicherweise eine Lösung?
lg Philipp
Bibliothek RadioHead im Ordner: C:…ArduinolibrariesRadioHead (legacy) wird verwendet
Der Sketch verwendet 7072 Bytes (117%) des Programmspeicherplatzes. Das Maximum sind 6012 Bytes.
Globale Variablen verwenden 425 Bytes des dynamischen Speichers.
Der Sketch ist zu groß; unter http://www.arduino.cc/en/Guide/Troubleshooting#size finden sich Hinweise, um die Größe zu verringern.
Fehler beim Kompilieren für das Board Digispark (Default – 16.5mhz).
2. Jun. 2018 um 17:36
Hallo Philipp,
das Problem bei dem Digispark Board ist, dass der Bootloader bereits rund 2 Kb von den verfügbaren 8 Kb Speicher belegt und somit nur rund 6 Kb für das Programm bleiben.
Das gleiche Problem hatte ich bereits hier, zusammen mit zwei Lösungsideen, beschrieben.
6. Jun. 2018 um 17:19
Direkt über den Arduino ging es dann anscheinend.
Jetzt habe ich derzeit leider keine LEDs zur hand anhand ich überprüfen könnte ob ein Signal ausgegeben wird.
Kann ich anders Prüfen ob der ATiny85 seine Arbeit verrichtet?
8. Jun. 2018 um 9:11
Du kannst z.B. einen Empfänger verwenden, der die gesendeten Datenpakete empfängt und an einen Rechner weitergibt.
Am Anschluss für die Status-LED solltest du außerdem mit einem Messgerät kurzzeitig (<1 Sekunde) eine Spannung messen können, wenn der Controller arbeitet.
6. Jun. 2018 um 17:51
Hi,
ich versuche das gerade nachzubauen aber der 5V DC-Boost-Konverter. Was ist das für ein Bauteil. Ich kann das nirgends finden.
Bin dankbar für eine Info.
Sven
8. Jun. 2018 um 9:16
Hallo Sven,
diese Boost-Konverter (oder auch StepUp genannt) gibt es zum Beispiel bei ebay zu kaufen. Ich habe diesen Typ verwendet und dabei noch die kleine LED von dem Board abgelötet, da diese deutlich mehr Strom verbrauchte als meine gesamte Schaltung.
8. Dez. 2018 um 14:26
Hi,
ich bastel gerade deine Version nach, als Empfänger dient ein Arduino Uno.
Ich werde aber Attiny 44 Chips verwenden da die hier gerade rumliegen. Oder setzt das große code Veränderungen voraus?
Ich möchte das System dann versuchen umzubauen ein LoRa Funkmodul einsetzen (Beispielprojekt hier: http://www.iot-lab.org/blog/209/).
Hättest Du an sowas vielleicht auch Interesse?
8. Dez. 2018 um 14:32
Ein Nachtrag: Sowohl bei den Codebeispielen als auch in der textarea wo ich gerade tippe macht die Seite machnmal zicken. Bei den Codebeispielen verschwindet der inhalt wenn man reinclickt (alles wei). In diesem Kommentarfeld verschwindet manchmal der Textinhalt wenn man in die Textarea mit der Mouse clickt. Dann kann man nix mehr schreiben. Aktueller firefox mit letztem Update.
6. Feb. 2019 um 16:43
Guten Tag,
Einleitend: Ihre Wetterstation ist ein sehr interessantes Projekt und trifft im Wesentlichen meine Vorstellungen
Mit meinem Arduino Nano und der Arduino IDE konnte ich die Sketche aus dem attiny85-radiohead-dht22-weather-sensor-master in den ATtiny85 laden. Eine Fehlermeldung gab es nicht. Auch bei mir kam der Hinweis dass der Speicher (7188 bytes of flash written, 437 Bytes dynamischer Speicher), fast voll ist obwohl ich die Kürzungen im Radiohead Ordner vorgenommen habe.
Nach dem Laboraufbau mit einem Steckbrett habe ich folgende Signale der LED‘s bekommen:
LED 1 (grün) kurz Pause kurz kurz, LED 2 kurz kurz kurz lang. Nach einiger Zeit ca. 1 Minute gibt zuerst die LED 2 ein weiteres kurzes Zeichen, die LED 1 leuchtet danach kurz. Da ich den Empfänger noch nicht fertig habe, vermute ich zunächst dass alles richtig funktioniert. Zum Test habe ich meinen 820T2 verwendet und jeweils mit den LED‘s auch deutliche Anzeichen einer Sendung auf 433 MHz erhalten und mit SDRsharp aufgezeichnet.
Nun aber meine eigentliche Frage. Da ich mehr als ein Sendemodul einsetzen möchte, drei habe ich vorbereitet, stelle ich mir die Frage was ist im Sketch wo und wie zu ändern damit die gesendeten Daten zusätzlich die Nr. oder ein anderes Kennzeichen des Sensors enthalten. Meine Programmierkenntnisse sind eigentlich nur rudimentär so das ich dafür Hilfe brauche.
Mein nächster Schritt soll dann eine Verbindung zu meinem RPI3 oder evtl. OPI PC plus sein. Dort möchte ich die Daten in eine Langzeitdatei auf uSD oder USB speichern. Mit Pimatik und sonstiger Netzwerkanbindung möchte ich mich derzeit nicht befassen.
Könnten sie zum Aufbau des Empfängerteils etwas sagen? Mein Arduino UNO ist gerade angekommen und ich könnte jetzt weiter machen. Wo der Empfänger angeschlossen werden soll habe ich aus einer Fritzingdarstellung mit Steckbord entnehmen können. Was muss ich nun in den UNO laden? Versuche mit der ArduinoIDE gehen mit dem Empfängersketch noch schief. In der IDE habe statt der zuvor bespielten Attiny‘s als Bord nun Arduino UNO eingestellt. Welche Vorbereitung sind für den UNO noch nötig?
4. Mrz. 2019 um 13:11
Guten Tag Herr Müller,
Jetzt habe ich pimatic installiert. Eingerichtet habe ich es so wie sie es erläutert haben. Zuerst ihr Plugin radiohead 1.3.1 geladen und aktiviert. Dann rh-serial-1 installiert und die Device eingerichtet 1:1 nach ihrer Anleitung. Dann die Device rhw-serial 1 auch 1:1 aus ihrer Anleitung übernommen. Der erste Sensor funktioniert wie vorgesehen. Jedenfalls kann ich mit dem USB Stick DVB Receiver 820T2, ein Signal immer wenn die LED kurz leuchten aufnehmen. Mit audacity kann ich das Signal auch zerlegen.
Bisher ist es mir aber nicht gelungen das Signal in pimatic zu empfangen. Die Software „pimatic“ habe ich auf meinem Orangepi PC Plus, der mit ARMBIAN 5.73 stable Debian GNU/Linux 9 (stretch) 4.19.20-sunxi läuft, installiert.
Ich verwende einen Arduino nano der mit ihrem Empfängersketch ohne Fehlerhinweise über die ArduinoIDE 1.8.8 geladen ist.
Der Datenpin vom Sender ist am nano auf D2 gesteckt. Vss und Gnd wird vom nano abgenommen. Der Arduino wird auch mit lsusb im OPI angezeigt:
root@orangepipcplus:~# lsusb
Bus 008 Device 002: ID 1a86:7523 QinHeng Electronics HL-340 USB-Serial adapter
Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 009 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
wenn ich dann in pimatic Events öffne finde ich dort diese Anzeige:
04.03.2019 11:44:52
rhw-serial-1 (rhw-serial-1)
Battery
100 %
04.03.2019 11:44:52
rhw-serial-1 (rhw-serial-1)
Humidity
0 %
04.03.2019 11:44:52
rhw-serial-1 (rhw-serial-1)
Temperature
0 °C
04.03.2019 11:44:52
rh-serial-1 (rh-serial-1)
RetransmissionsCount
0
04.03.2019 11:44:52
rh-serial-1 (rh-serial-1)
ReceivedCount
0
04.03.2019 11:44:52
rh-serial-1 (rh-serial-1)
SentErrorCount
0
04.03.2019 11:44:52
rh-serial-1 (rh-serial-1)
SentOkCount
0
11:44 ist der Start des OPI‘s der automatisch pimatic startet.
Egal wie lange der Sender arbeitet (der letzte Versuch dauerte 35 min.)
bleibt die Anzeige so stehen.
Meine Vermutung ist, dass entweder der nano das Signal nicht weiter gibt, oder im Sketch eine Einstellung verlangt ist, die ich nicht zutreffend vorgenommen habe.
Ich würde mich sehr freuen wenn sie mir weiter helfen könnten. Ggf. im direkten Mailaustausch. Mit freundlichen Grüßen
Hans-J. Grigoleit
4. Mai. 2019 um 15:44
Hallo Herr Grigoleit,
sorry für die etwas verspätete Antwort 🙁
Das sieht aus, als würden gar keine Daten empfangen werden.
Was für Funkmodule und Antennen verwenden Sie? Gerade die billigen Empfängermodule vom Typ XY-MK-5V sind oftmals nur für wenige Zentimeter Funkstrecke zu gebrauchen.
28. Apr. 2019 um 15:06
Ich habe das „Projekt“ seit November 2018 am laufen und alles läuft wunderbar. Inzwischen habe ich allerdings die Stromversorgung von NiMh Akkus/Batterien auf einen Lithium Ionen Akku + Solarzelle (5V/500mA) umgestellt.
Sehr nützlich ist dazu das WeMos Battery Shield (https://wiki.wemos.cc/products:d1_mini_shields:battery_shield). Das Breakout sorgt für die Laderegelung des Akkus und bietet direkt auch die benötigten 5 V Betriebsspannung. Ein Stepup-Konverter ist deshalb nicht mehr notwendig.
Ob das auf Dauer gut funktioniert weiß ich nicht, aber momentan klappt das Ganze sehr gut.
4. Mai. 2019 um 15:37
Freut mich, das zu lesen 🙂
Bei meinem Bewässerungssystem habe ich es ähnlich gelöst und ebenfalls Li-Ion Akkus und eine kleine Solarzelle verwendet. Das System liefe im letzten Jahr wunderbar und ist seit kurzem auch dieses Jahr wieder im Einsatz.
22. Mai. 2019 um 21:28
Ich musste leider feststellen, dass das mit dem WeMos Charger Shield doch nicht so gut klappt. Wenn die Spannung der Solarzelle unter einen bestimmten Wert sinkt, liefert das Board nur noch 0,8 V bis es entweder so dunkel ist, dass von der Solarzelle gar nichts mehr kommt oder sie abgeklemmt wird. Erst dann wird auf die Batterie umgeschaltet. Dass bedeutet, dass auch die Sensorschaltung nicht mehr funktioniert. Mann bräuchte also noch eine Zwischenschaltung, welche die Solarzelle automatisch komplett abknippst, wenn die Spannung unter einen bestimmten Wert fällt.
23. Mai. 2019 um 20:26
Als Alternative kann ich die kleinen TP4056 Boards empfehlen. Die laufen problemlos auch mit einer Solarzelle zusammen und gewährleisten eine stabile Ausgangsspannung. 🙂
19. Jun. 2019 um 22:00
Hallo Peter,
ich habe jetzt solch ein TP4056 Board im Einsatz. Dafür brauche ich zwar immer noch den StepUp Regler, aber dafür funktioniert es einwandfrei.
Weil mir das Projekt so gut gefallen hat, habe ich das Ganze inzwischen auch als PCB: https://pekaru.de/bilder/21-1PCB-Wettersensor.jpg
Gruß Kai
2. Mai. 2019 um 22:25
Hallo,
vielen Dank für das tolle Projekt.
Ich habe es gerade aufgebaut, es funktioniert prinzipiell.
Nur die Ausgabe der Messwerte stimmt nicht
0x01 DHT data
588.80°C – 486.40%
Haben Sie eine Idee was ich falsch gemacht habe ?
Danke und viele Grüße
4. Mai. 2019 um 15:32
Sieht aus, als würde das Auslesen des Sensors nicht richtig funktionieren.
Ähnliche seltsame Messwerte konnte ich mal beobachten, als ich einen falschen PullUp-Widerstand für die Datenleitung des DHT22 verwendet hatte.
23. Mai. 2019 um 16:00
Danke für den Hinweis, die Messwerte des DHT22 sind jetzt richtig (der PullUp-Widerstand war zu groß).
Ich möchte 2 Sensoren verwenden, weiß aber nicht wie ich den RHDatagram Server einstellen soll.
Ausgabe des seriellen Monitor:
got message from : 0xCB
0x01 DHT data
23.00°C – 51.30%
23
got message from : 0xCA
0x01 DHT data
23.20°C – 53.60%
23
Können Sie mir etwas helfen ?
Danke
23. Mai. 2019 um 19:51
Hier hilft eine einfache Unterscheidung nach der `from` Adresse.
Ich habe mal einen zweiten Beispiel-Sketch erstellt, der bei den Adresse 0xCA und 0xCB die Temperatur und Luftfeuchtigkeit zusätzlich in die Variablen `tCA` und `hCA` bzw. `tCB` und `hCB` speichert. Diese können dann wiederum verwendet werden, um eine entsprechende Ausgabe zu realisieren.
23. Mai. 2019 um 16:14
Ergänzung:
Ich möchte die beiden Temperaturwerte auf einer LED-Matrix ausgeben, aber es wird nur ein Temperaturwert angezeigt. Wie kann ich mit dem RHDatagram Server die Daten der Sensoren getrennt voneinander speichern ( z.b als t und t1)
Danke
12. Jun. 2019 um 17:28
Hallo Peter,
tolles Projekt was du da erstellt hast. Wollte dies nachbauen und in FHEM einbinden.
Leider klappt das kompilieren absolut gar nicht weder mit MAC noch mit Windows.
Die Lib’s hab ich soweit du beschrieben hast gelöscht bzw. in den jeweiligen Ordner geschoben, dennoch bekomme ich immer Fehlermeldungen z.b:
Hast du dazu eine Idee?
Kannst du mir vielleicht auch sagen, ob ich dann überhaupt die Daten mit FHEM empfangen kann bzw. verarbeiten kann? 433MHZ bzw. 833 CUL hab ich natürlich.
12. Jun. 2019 um 19:15
Hallo Lars,
der Fehlermeldung
undefined reference to `dht_init(dht22*, unsigned char)'
nach fehlen bei dir die Dateien `dht22.cpp` und/oder `dht22.h` in deinem Projektverzeichnis. Diese beiden Dateien müssen zusammen mit der ino-Datei im gleichen Verzeichnis liegen.Mit FHEM habe ich selbst noch nicht gearbeitet. Ich denke hier wäre ein entsprechendes Modul erforderlich, dass das RadioHead-Protokoll umsetzt.
12. Jun. 2019 um 20:24
Danke für deine schnelle Antwort 🙂
Aber die Dateien liegen im selben Verzeichnis. Deshalb sind sie auch als TAB im IDE drin. Ich bin schon am verzweifeln..
12. Jun. 2019 um 22:37
So, Peter, hab jetzt alles nochmal alles gelöscht und von Github runtergelassen, nachdem ich nochmal einen neuen Ordner angelegt habe hat es nun geklappt.
Super. Jetzt nur noch FHEM Integration und dann bin ich happy.
VG,LArs
13. Jun. 2019 um 12:29
Freut mich, dass es geklappt hat 🙂
Wie bereits erwähnt kann ich dir bei FHEM nicht groß weiterhelfen.
Den Code meiner Umsetzung des RadioHead-Protokolls für Node.js findest du bei Bedarf hier: https://git.cryhost.de/crycode/node-radiohead-serial
12. Nov. 2019 um 14:03
Hallo Peter,
danke das du dieses tolle Projekt veröffentlicht hast. Das ist so ziemlich genau das was ich für mein aktuelles vorhaben benötige. Ich möchte in meinen Bienenvölkern die Temperatur und Luftfeuchtigkeit erfassen. Die Daten sollen per Funk an eine Empfängerstation gesendet und von dort in eine Datenbank geschrieben werden.
Die Sende-Einheiten habe ich nach deinem Vorbild mit einem BME280 auf einem ATTINY85 zum Laufen gebracht. Aktuell empfange ich die Daten an einem Arduino. Allerdings möchte den Datenempfang über einen RaspberryPI Zero W bewerkstelligen. Hast du diesbezüglich schon Erfahrungen gesammelt bzw. vielleicht einen Tip welche Bibliotheken auf Raspberry-Seite sinnvoll eingesetzt werden können um die Daten zu decodieren?
Viele Grüße
Christian
12. Nov. 2019 um 15:37
Hallo Christian,
das Einfachste wäre denke ich das ganze über einen Arduino als Radio-Serial-Gateway zu realisieren. So habe ich bei mir auch den RadioHead Funk an meinen HomePi angebunden. Der Arduino setzt dabei das Funksignal auf eine serielle Schnittstelle (USB) um. Einen Beispielsketch für den Arduino findest du hier.
Wenn du das ganze möglichst klein halten möchtest, dann kannst du auch einen einzelnen ATMega328P mit dem Sketch Programmieren und die RXD/TXD Leitungen direkt mit denen des RasPi verbinden. Der ATMega muss dann mit +3,3 V Betriebsspannung laufen, oder du musst die Pegel auf den beiden Leitungen entsprechend anpassen (einfacher Spannungsteiler / Levelshifter / …).
Für die Auswertung der Daten auf dem Raspberry Pi kann ich dir dann mein Node.js Modul radiohead-serial empfehlen. Mit diesem bekommst du leicht die Datenpakete und kannst sie dann entsprechend weiter verarbeiten.
Das Auslesen der Temperatur und Luftfeuchtigkeit auf dem empfangenen Buffer würde dann beispielsweise so aussehen.
12. Nov. 2019 um 17:45
Hallo Peter,
super Danke für deine Rückmeldung. Denke ich werde das so machen wie du es auch gemacht hast und den Arduino per USB an den Raspberry koppeln.
Aufgrund deiner super Vorarbeit sollte das recht schnell umgesetzt sein. Danke auch für dein Code-Beispiel für die Extraktion der Daten aus dem Buffer.
Ganz herzliches Merci und Grüße
Christian
4. Jan. 2020 um 15:43
Hallo Peter
Ich versuche, ein Potentiometersensorprojekt, das Ihrem Wetterstationsprojekt ähnelt, auf Attiny85 zu migrieren. Es funktioniert gut auf einem Atmega328 mit Radiohead. Ich habe meine Skizze auf einem Attiny85 ausprobiert, kann sie aber nicht übertragen. Ich folge Ihrem Tutorial zur Programmierung des Attiny85 mit Aduino. Kannst du mir ein paar Hinweise geben, was ich tue?
5. Jan. 2020 um 18:18
Hallo Bernard,
werden irgendwelche Fehlermeldungen ausgegeben?
Der ATtiny hat recht wenig Flash-Speicher und RAM. Ich vermute, dass das Problem damit zusammenhängt.
5. Jan. 2020 um 19:30
Hallo Peter
Zunächst wünsche ich Ihnen und Ihnen alles Gute für 2020. Entschuldigung!
Sketch belegt 6382 Bytes (77%) des Programmspeicherplatzes. Maximal sind 8192 Bytes möglich.
Globale Variablen belegen 374 Byte (73%) des dynamischen Speichers, während lokale Variablen 138 Byte belassen. Maximal sind 512 Bytes möglich. Ich habe keine Fehler bekommen. Aber wenn ich Ihren Code kompiliere, erhalte ich folgende Fehlermeldung:> C: Programme (x86) Arduino arduino-builder hat 2 zurückgegeben
Fehler beim Kompilieren der Karte ATtiny25 / 45/85.
Können Sie sich meine Skizze ansehen?
1. Feb. 2020 um 18:39
Hi Peter,
Super Projekt , hab leider nur folgendes Problem.
Wenn ich in Andruino IDE als Board ein Andruino Nano eingeben läuft alles durch, sobald ich aber auf attiny85 stelle bekomme ich nur Fehler.
Hast du eine Idee woran das liegt bzw. was ich machen kann?
Viele Grüße
Tom
2. Feb. 2020 um 16:27
Hallo Tom,
was für Fehler kommen denn?
Hast du wie oben in den anderen Kommentaren beschrieben die folgenden Dateien von der RadioHead Bibliothek entfernt oder umbenannt?
`RH_CC110`, `RH_E32`, `RH_MRF89`, `RH_NRF24`, `RH_NRF905`, `RH_RF22`, `RH_RF24`, `RH_RF69`, `RH_RF95`, `RHHardwareSPI`, `RHNRFSPIDriver`, `RHSPIDriver`
2. Feb. 2020 um 19:27
Hi Peter,
ja die Dateien hab ich entsprechend entfernt.
Es erscheint folgender Fehler: (zwei Beispiele)
RHGenericDriver.h:84:37: error: ‘uint8_t’ has not been declared
virtual bool recv(uint8_t* buf, uint8_t* len) = 0
RHGenericDriver.h:165:40: error: ‘uint8_t’ has not been declared
virtual void setHeaderTo(uint8_t to);
Es ist immer der Fehler “uint8_t
2. Feb. 2020 um 20:05
Huch… da kennt er den Variablentyp `uint8_t` nicht.
Füg mal bei dem Arduino Sketch ganz am Anfang `#include <arduino.h>` ein. Dann sollte es funktionieren. 🙂
25. Apr. 2020 um 21:48
Hallo Peter,
danke auch für die schöne Doku.
Leider bekomme auch ich den Fehler.
Was genau muss an den Anfang eingefügt werden?
Bei dem #include fehlt noch was?
Viele Grüße
26. Apr. 2020 um 10:46
Huch… da hatte ein Update doch glatt die Formatierung kaputt gemacht.
Das sollte `#include <arduino.h>` heißen. 🙂
29. Apr. 2020 um 18:14
Hi Peter,
ein echt super Projekt und echt gut erklärt!
Konnte dadurch problemlos meinen ersten ATtiny programmieren 😉
Leider bekomme ich trotzdem zwei Fehlermeldungen.
ccbZEVw8.ltrans0.ltrans.o: In function `setup’:
sketch_apr29a.ino:182: undefined reference to `dht_init(dht22*, unsigned char)’
und im loop:
undefined reference to `dht_read_data(dht22*, float*, float*)’
LG Mais
30. Apr. 2020 um 6:51
Da scheinen die Dateien `dht22.cpp` und/oder `dht22.h` im Projektverzeichnis (da wo die .ino-Datei liegt) zu fehlen. Diese werden benötigt, um den DHT-Sensor auszulesen.
30. Apr. 2020 um 17:48
Danke, jetz hats geklappt. Musste seltsamerweise die library umbenennen. 🙂
5. Jul. 2020 um 17:29
Hallo guten Tag Peter,
auch mit hat es sehr viel Spaß gemacht Dein Projekt nach zu bauen. Nachdem alle Stolpersteine beiseite geräumt waren funktioniert mein WD-Sender sehr gut. Die von Dir genannten Komponenten benutze ich auch 1 zu 1. Der Aufbau ist fest auf einem kleinen PCB. Ich hatte jedoch mit einer noch geringeren Stromaufnahme gerechnet. Meine Messwerte liegen bei Spannungsversorgung 5,0 Volt; 0,811 mA im Ruhe und ca. 0,87 mA beim Mess- und Sendevorgang. Ich hatte angenommen dass der Sleep-Modus den Stromverbrauch noch weiter senkt. Entsprechen die Werte dem Machbaren oder habe ich noch eine Fehler zu suchen.
LG Bodo
5. Jul. 2020 um 19:33
Hallo Peter,
folgende Korrektur zu meiner Aussage!
Meine Messwerte liegen bei Spannungsversorgung 5,0 Volt; 0,811 mA im Ruhe und ca. 13,769 mA beim Mess- und Sendevorgang.
LG Bodo
6. Jul. 2020 um 10:48
Hallo Bodo,
im Sleepmodus sollten eigentlich weniger als 10 µA (0,01 mA) fließen. Deine 0,811 mA sind definitiv etwas hoch. Ist der Strom gleichbleibend oder eher pulsierend? Eventuell wacht der Controller wegen irgendwas vorzeitig immer mal wieder auf.
Beim Messen und Senden sind etwa 14 mA im Normalbereich.
6. Jul. 2020 um 18:27
Hallo Peter,
vielen Dank für die schnelle Antwort. Habe mich gleich noch einmal auf die Suche gemacht und festgestellt, dass ich das Pinout des FS1000A nicht richtig verstanden hatte. Statt DTA | VCC | GND hatte ich VCC | DTA | GND verwendet. Nach dem ich die Anschlüsse geändert habe, benötigt mein Modul nur noch 12,0 – 14,0 µA.
Vielen Dank für das Tolle Projekt.
LG Bodo
13. Jul. 2020 um 18:37
Hallo guten Tag Peter,
nachdem mein Wetterdatensender gut funktioniert versuche ich die Spannung zu messen. Obwohl es viele Beschreibungen gibt leider ohne Erfolg. Würdest Du bitte einen Blick auf meinen Code werfen wo ich evtl. einen Fehler mache.
LG Bodo
16. Jul. 2020 um 15:55
Was mir spontan auffällt:
Du hast einige Sachen, wie z.B. das Setup des ADCs, in der Funktion drin, die nicht jedes Mal ausgeführt werden müssen.
Du deaktivierst den ADC und aktivierst ihn gleich wieder. Das macht recht wenig Sinn.
Bei dem 15x Lesen und Addieren des ADC-Wertes kommt es wahrscheinlich zu einem Überlauf der 16Bit Variable `sensorValue`. Wozu 15x lesen? 1x sollte eigentlich reichen.
Als Referenzspannung hast du die internen 1,1 V verwendet. Damit kannst du dann auch nur Spannungen bis 1,1 V messen. Alles darüber führt zwangsläufig zum Maximalmesswert.
24. Aug. 2020 um 11:42
Hallo guten Tag Peter,
bekomme den Sketch nicht zum laufen.
Es wurde alles so wie beschrieben installiert.
Habe dann nur die beiden Dioden angeschlossen und //sleep_mode(); auskommentiert. Programm wird korrekt übertragen, doch Pin 2 und 3 gehen zu keinem Zeitpunkt auf High.
verifying lfuse memory against 0xE2:
Hast Du eventuell eine Idee?
LG Herbert
24. Aug. 2020 um 12:29
Hallo Herbert,
also nach meinem Beispiel oben wäre die LED am Hardware Pin 3 (PB4, Arduino D4) und sollte bei Aktivität auf High gesetzt werden. Hardware Pin 2 (PB3, Arduino D3) ist TX vom Funk, wo sehr kurze Impulse erzeugt werden, die ggf. mit einem einfachen Messgerät nicht korrekt erfasst werden.
Wenn du `sleep_mode();` auskommentierst, dann würde er quasi permanent ohne Pause messen und senden.
24. Aug. 2020 um 15:50
Danke für die Info, es wurde alles so verwendet wie angegeben.
Da ja bei mir nichts funktioniert (Attiny85) habe ich ja komplett zurückgebaut bis auf die 2 LED’s.
Zusätzlich habe ich Versuchshalber Attiny85(Pin5 – #define LED 0) in Deinem Sketch definiert, im Setup pinMode(LED, OUTPUT) und im Loop
digitalWrite(LED, HIGH); delay(1000); digitalWrite(LED, LOW);
als erstes eingefügt.
Selbst hier bleibt Pin5 (Attiny85) ständig low.
Wenn ich das in einem seperaten Scetch hochlade blinkt es.
Mit deinem Sketch geht gar nichts.
Ich weis leider nicht mehr weiter.
Gruß
28. Aug. 2020 um 13:39
Dann scheint er schon irgendwo in der `setup`-Funktion hängen zu bleiben.
Vielleicht da mal Stück für Stück ein kurzes Blinken der LED einbauen und schauen, wo er hängen bleibt.
22. Okt. 2020 um 9:49
Hallo Herr Müller,
vielen Dank zunächst für das tolle Tutorial. Ich versuche dieses als Anleitung für eine selbst gebaute Wetterstation zu nutzen. Um zunächst die Funktionalität grob zu testen (ob hardwareseitig alles in Ordnung ist), habe ich auf meinen ATtiny85 zunächst den Bootloader über den Arduino als ISP (nach einer Ihrer Anleitungen) geschrieben und anschließend das Programm geschrieben. Die gute Nachricht: die LEDs blinken in regelmäßigen Abständen ;-).
Auf der Empfängerseite setze ich einen Arduino Nano ein. Der 433MHz-Empfänger ist neben der Spannungsversorgung mit dem PIN “D5” des Arduino Nano verbunden. Ich habe Ihr im Tutorial aufgeführtes Beispielsketch auf den Arduino Nano geschrieben.
Auf der Konsole der Empfängerseite bekomme ich allerdings lediglich das zu erwartende “init done” angezeigt. Eventuell empfangene Daten erscheinen nicht.
Um zu kontrollieren, ob der Empfänger überhaupt Daten empfängt, habe ich parallel zum Eingang “D5” am Arduino nano eine LED über einen 470 Ohm Vorwiederstand geschaltet. Die LED zeigt tatsächlich immer wenn die Sende LED des Senders leuchtet auf der EMpfängerseite durch leuchten den Empfang von Daten an. Den Inhalt zeigt sie leider nicht an ;-).
Nun bin ich leider mit meinem Latein am Ende und hoffe, dass Sie mir helfen können.
Viele Grüße
Michael
26. Okt. 2020 um 16:20
Hallo Michael,
wichtig ist, dass die Adressen zueinander passen (z.B. der ATtiny an die 0x01 sendet und der Empfänger die 0x01 als Adresse hat) und das `RH_SPEED` bei beiden gleich gesetzt ist.
Passt das Blinken der LEDs am Sender zu den eingestellten Zeiten? In dem Beispiel oben müsste die LED etwa alle 56 Sekunden aufblinken.
Falls die LED zu schnell oder zu langsam blinkt, bitte ein mal die Fuse-Bits des ATtiny85 über den ISP-Programmer prüfen. Standardmäßig ist hier z.B das Bit `CKDIV8` gesetzt, wodurch der interne 8 MHz Takt noch mal durch 8 geteilt wird und der Controller somit nur mit 1 MHz läuft.
15. Dez. 2020 um 22:37
Hello Peter,
I would like to configure an ESP 32 as the receiver ,and i use your example receiver sketch,but now I have a compilation issue.
In file included from F:ArduinolibrariesRadioHead/RHGenericDriver.h:9:0,
from F:ArduinolibrariesRadioHead/RHDatagram.h:9,
from C:UsershaseeDesktopJIESHOUreceiver.ino:9:
F:ArduinolibrariesRadioHead/RadioHead.h:618:27: fatal error: util/atomic.h: No such file or directory
compilation terminated.
exit status 1
Error compiling for board ESP32 Dev Module.
Could you please help me to fix this issue?
Thanks.
18. Dez. 2020 um 10:23
Hi, which version of the RadioHead library did you use?
I’ve checked the current v1.113 and this should not include `util/atomic.h` on ESP8266 platform because this is Arduino specific.
Maybe you could try the latest version.
20. Dez. 2020 um 0:16
Thanks,I used the old version of Radiohead library before.But now the serial monitor does not display data after the program runs normally, even “init failed” or “init done” are not displayed.
20. Dez. 2020 um 0:17
Thanks,I used the old version of Radiohead library before.But now the serial monitor does not display data after the program runs normally, even “init failed” or “init done” are not displayed.
7. Feb. 2021 um 17:01
Hello Peter,
I wanted to thank you very much for this project.
It took me several days to get it working with the Attiny85.
With Arduino Uno it worked fine from the beginning.
In the end the solution was to keep the wires to the sensor and transmitter as short as possible and to keep the Attiny running at 8MHz. 1MHz did not work for me.
Further I ensured to only use _delay_ms/us from instead of delay() from Arduino.
From the radiohead library i used only the RH_ASK; RHCRC; RHDatagram; RHGenericDriver and RHReliableDatagram files.
Im now trying to implement it on Attiny1614/Attiny1616, however the watchdog will not work as with the Attiny85 and I have to use other timers for sleep.
Also I have issues to get the Radiohead library running due to a missmatch of F_CPU definition. If someone has a solution please let me know.
All the best from Bavaria,
Peter
22. Sep. 2021 um 14:47
Könnte Sinn ergeben den Sender und den DHT noch von der Spannungsversorgung zu trennen, wenn der Tiny schläft. Da PB0 noch frei ist, könnte man darüber zwei BS170 nKanal MOSFETs steuern, die dann GND für die Peripherie schalten. Das sollte den Standby Stromverbrauch noch ganz gut senken.
22. Sep. 2021 um 15:08
Was sicher auch interessant wäre ist den freien PB0 für einen PCINT zu nutzen und den Tiny gesteuert von der Wetterstation aufwachen zu lassen. Dann hat man den ganzen Sync-Kram aus dem Sender hier raus, wenn die Station auch im Schlafmodus ist.
Der NRF24L01 als 2.4GHz Transceiver hat einen IRQ Trigger Ausgang…
Nur eine Idee 🙂
17. Nov. 2023 um 11:56
Hallo
sehr gutes Projekt
habe das mal umgesetzt aber einen BME280 genommen der kann mehr.
Funktioniert sehr gut.
Aber da die Übertragungsreichweite nicht so der brüller ist spiele ich mit dem Gednken das ganze mit einem Lora Modul und nen Attiny84 zu machen.
Gibt es da schon von deiner Seite irgendwelche Ansätze oder Projekte.
Gruß Torsten
18. Nov. 2023 um 17:48
Hi, ja der BME280 ist zudem auch zuverlässiger als der DHT22.
Mit der Reichweite ist in der Tat oftmals ein Problem. Mit Lora hatte auch mal geliebäugelt, aber bislang nichts gemacht.
Ich bin inzwischen auf kleine (fertige) Geräte mit Zigbee umgestiegen, da diese zuverlässig funktionieren und preislich ok sind.