Selbstbau Funkthermometer 433Mhz

Begonnen von matlen67, 28 April 2016, 09:59:57

Vorheriges Thema - Nächstes Thema

KölnSolar

oder so

Aber Obacht, Fehler können den Rpi schrotten.

Grüße Markus
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

juergs

Ein Wrapper/GUI für avrdude auch für RASPI mit Mono: Avrdudess

Groej

Hallo und Danke für Eure Antworten. Aber mit welchen Programm öffnet Ihr die Datei und schiebt sie in den 85 rein? Wie gesagt mach ich die Dateien mit Ardiuno IDE auf und lasse sie prüfen kommen nur Fehlermeldungen.

Danke.
FHEM - RaspPi2 - KNXD - KNX - CUL 868 - FS20 - HMS - WH3080 - Signalduino 433 MHz - Telegram - Anel Elektronik IP Steckdosen - BME280

juergs

#198
Die Standard-Vorgehensweise bei 8Bit-Flash-Atmel-Controllern ist ja immer gleich:

1.) Du hast ein Chip mit vorprogrammierten Bootloader -> Programmierung über USB + AVRdude
2.) Du hast einen Chip ohne Bootloader, dann benötigst Du einen Programmieradapter + avrdude (wenn AVRdude diesen Programmer-Typ auch unterstützt!)

Dann hängt es natürlich auch vom verwendeten Betriebsystem ab, was man, wenn man nicht per Kommandozeile
avrdude parametiert aufrufen möchte.

Ich benutze z.B. einen mySmartUsb Light-Programmer, mit dessen Windows-Programmer-Anwendung zum programmieren.
Eigentlich müsste es auch aus der Arduino-IDE direkt gehen -> Google! 

Hier ist zum ATtiny841 vieles auch beschrieben: Bodenfeuchte-SpinOff-Thread

bismosa

Hallo,

schönes Projekt!
Nachdem ich aufgegeben habe bei den Max-Thermostaten die aktuelle Temperatur auszulesen, bin auch auf der Suche nach einer Möglichkeit in mehren Räumen Temperatur (und Luftfeuchtigkeit) zu Messen.
(Mich ärgert es maßlos, das die Thermostate einen Temperatursensor haben...aber der Wert nur über blöde Umwege preisgeben...aber das gehört hier nicht hin...)

Ich bin Bastler. Daher versuche ich immer erstmal keine fertige Lösung zu nehmen.  Auch wenn derzeit die TFA 30.3121 für schon 10€ (ELV) zu haben sind...bei 5 Räumen sind das aber auch schon wieder 50€...und ein paar mehr Sensoren wären hier ja nicht schlecht. Das ist aber bei der fertigen Lösung schon wieder schwierig, da die IDs sich bei jedem Batteriewechsel verändern...

Umso interessanter dieser Beitrag. Da ich noch drei digispark (die billigen rev.3), einen DHT22 und ein 433MHZ Sender (FS1000A) hier rumfliegen habe, habe ich mich gleich mal daran versucht.
Ich finde den Digispark echt klasse. Auch ohne programmer leicht zu programmieren. Zum testen hat man dann auch gleich die Stromversorgung von USB. Hier könnte man den Sender und Sensor direkt anlöten(ohne weitere Platine)..und sehr günstig ist er auch noch...
Hier meine theoretische Einkausliste:
Zitat
Digispark: 10x 8,94€ (https://de.aliexpress.com/item/Free-shipping-10pcs-CJMCU-Digispark-kickstarter-miniature-for-Arduino-ATTINY85-usb-development-board/32540165258.html?spm=a2g0s.13010208.99999999.270.u954ZO)
DHT22: 10x 22,30€ (https://de.aliexpress.com/item/Free-shipping-DHT22-digital-temperature-and-humidity-sensor-Temperature-and-humidity-module-AM2302-replace-SHT11-SHT15/632552670.html?spm=a2g0x.search0104.3.1.KkWOr8&ws_ab_test=searchweb0_0,searchweb201602_4_10152_10065_10151_10068_10344_10345_10547_10342_10343_10340_10341_10548_10193_10194_10541_10304_10307_5670020_10060_10302_10155_10154_10056_10055_10539_10537_10536_10059_10534_10533_100031_10103_10102_10107_10142_10320_10321_10322_10562_10084_10083_10561_10177_5650020_10180_10312_10313_10314_10184_5660020_10319_10550_10073_10551_10552_10553_10554_10186_10557-10552,searchweb201603_30,ppcSwitch_5&btsid=4d5b6118-c3b5-47fe-8a24-829edfa72f1a&algo_expid=85639189-872a-48cc-910c-1c3eae6fe51f-0&algo_pvid=85639189-872a-48cc-910c-1c3eae6fe51f)
XY-MK-5V-XY-FST-433Mhz-Rf-Transmitter-and-Receiver: 10x 11,10€ (https://de.aliexpress.com/item/XY-MK-5V-XY-FST-433Mhz-Rf-Transmitter-and-Receiver-Link-Kit-for-Arduino-Arm-McU/32732438014.html?spm=a2g0s.13010208.99999999.263.u954ZO)
Batteriehalter 2xAA: 10x ca. 10€
Gehäuse: ca. 10€ (hab noch nichts passendes herausgesucht)
Summe ca. 65€...für 10 Stück. Also nur noch 6,50€/Stück. Macht die Sache doch schon echt interessant.
Wobei hier noch ggf. ein Step-UP mit eingeplant werden sollte...


Leider habe ich es nicht geschafft, die DHT (Sparkfun Lib) zu verwenden. Ich hatte auch auf dieser Seite einen Artikel zum DHT22 gelesen:
http://www.instructables.com/id/Mini-weather-station-with-Attiny85/
Hier wird die DHT Lib von Rob Tillaart verwendet. (https://github.com/RobTillaart/Arduino/tree/master/libraries/DHTlib)
Diese lief bei mir fast auf Anhieb.

Dann habe ich die LaCrosse Lib eingebunden und versuche nun die Daten zu senden. Gesendet wird auch irgendwas. Ich kann das mittels SDR# sehen.
In FHEM wird aber rein gar nichts empfangen.  In FHEM wird kein Gerät angelegt. (Autocreate ist eingeschaltet)
Daher habe ich auch noch probiert mit der 433MHz (Intertechno) Lib zu senden. (https://bitbucket.org/fuzzillogic/433mhzforarduino/wiki/Home)
Auch hier wird etwas gesendet, aber ich weiß leider nicht, wie ich das prüfen kann.

Wenn ich das bisher richtig verstanden habe, sollten doch beide Protokolle von meinem Selbstbau CUL (433MHz / SlowRF) erkannt werden? Intertechno Fenstersensoren empfange ich auch problemlos...

Ich gehe mal davon aus, das entweder auf das Timing nicht stimmt (Ich habe sowohl die Standardeinstellung als auch 8MHz probiert) oder der FS1000A nicht ganz auf der richtigen Frequenz sendet. Das lässt sich ja leider nicht beeinflussen.

Hat das schon jemand mit einem Digispark am laufen? Mit welchen Einstellungen?

Mich würde auch noch generell die Batterielaufzeiten bei euch interessieren. Bei welchem Intervall mit welcher Batterie/Akku habt ihr welche Laufzeiten? Hat auch jemand eine Variante mit einem Step-UP umgesetzt? Dann könnte man die Batterien auch bis zum Ende ausreizen...

Gruß
Bismosa
1x nanoCUL 433MHz (SlowRF Intertechno) für Fenstersensoren
1x nanoCUL 868Mhz für MAX (9x HT 1xWT)
1x ZigBee CUL
Weiteres: Squeezebox server, Kindle Display, ESP8266, Löterfahrung, ...

juergs

#200
Schau Dich mal hier bei mir auf Github um.
Dort sind auch einige Projekte auf ATtiny-Basis. (85 + 841)
Hier steht drin, was zu tun ist...

Die Verwendung von USB-ATtiny-Typen im Batterie-Betrieb rate ich, wegen dem Verlust an Batterie-Kapazität, allemal ab (Milli- zu Mikro-Ampere  + Batterielaufzeit ;)).
Es sei denn, man kann die Pullups abschalten....

Der Code sollte eigentlich einfach laufen, wenn man alles in einen Ordner kopiert und über die Arduino-Ide die Ino-Datei aufruft.

Beim Timing der Bit-Zeiten hat sich etwas geändert, diese LaCrosse.cpp hier ist der aktuelle Code
mit den geänderten Pulse-Zeiten dafür zu finden. Die funktionieren bei mir ebenfalls 100%ig.

//--- Duration of pulses and delays
//--- geändertes Timing
int iLongPulse = 1200;  // 975;
int iShortPulse = 400;  // 250;
int iDelay = 900;         // 1450;


Vielleicht sind die CPU-Freq-Fuses bei Dir nicht richtig gesetzt?

bismosa

#201
Hallo,

danke für die Antwort!
Ich habe jetzt mit der aktuellen LaCrosse Lib probiert. Aber auch hier kein Erfolg. Wenn ich das richtig sehe (auf einer Aufnahme mit SDR# analysiert mit Audacity), scheinen aber die Timings bei mir halbwegs zu stimmen. Außer ich bin ne 10er Potenz daneben...ich komme da gerne mal durcheinander...
Dann habe ich meinen CUL zum SIGNALduino umgeflasht. Nun bekomme ich auch Temperatursensoren von den Nachbarn rein. Aber meiner wird immer noch nicht erkannt.

Also liegt es entweder am Sender selbst (Der auch auf dem ganzen Frequenzband sehr streut) oder an den Timings.
Ich denke, da das Ganze wohl eh keinen Erfolg haben wird (Batterielaufzeit), gebe ich die Versuche mit dem Digispark auf. Eigentlich schade...
Vielleicht probiere ich am Wochenende mal einen Digispark mit einen Arduino umzuflashen. Müsste eigentlich möglich sein. Dann muss ich nicht zum Testen neue Attinys bestellen. Dann könnte ich auch sehen, ob es nicht wirklich am Sender liegt.

Wie lange hält denn nun bei euch eine Batterie durch?

Gruß
Bismosa

[edit]
Ich habe es jetzt direkt mal probiert. Aber ich müsste die Fuses wohl erst zurücksetzen mit einem High-Voltage Programmer. Kann man sich wohl auch selbst bauen...

Ich werde wohl jetzt erst einmal neue Hardware bestellen (Attiny; Sender; DHT22 und zum testen ein Step-up). Das wird dann also wieder ein paar Wochen dauern. Ich weiß nur noch nicht genau welchen Sender ich jetzt kaufen sollte? Ist der FS1000A ok? Oder gibt es da bessere Module?
[/edit]
1x nanoCUL 433MHz (SlowRF Intertechno) für Fenstersensoren
1x nanoCUL 868Mhz für MAX (9x HT 1xWT)
1x ZigBee CUL
Weiteres: Squeezebox server, Kindle Display, ESP8266, Löterfahrung, ...

bismosa

Hallo nochmal,

ich konnte es jetzt doch nicht lassen. Ich habe mir den HV Programmer nachgebaut (http://www.instructables.com/id/How-to-unlock-Digispark-ATtiny85-and-convert-it-to/)
Nun habe ich einen "normalen" Attiny85 nur bereits aufgelötet :)

Nun habe ich mit der Arduino IDE den Sketch vom 4.Januar (https://github.com/juergs/_ATtiny85_DHT22_BMP180_433) geflasht. Eingestellt habe ich auf "internal 8MHz" und habe den Booloader und den Sketch erfolgreich hochgeladen.
In FHEM wird immer noch nichts erkannt.
Dann habe ich mittels SDR# gesehen, das mein FS1000A (ich glaube immer noch das der ne Macke hat) nicht auf 433,92MHz sendet sondern auf ca. 433,73MHz. Daher habe ich den SIGNALduino mal umgestellt. Jetzt wird wenigstens mal etwas erkannt. Aber das sieht nicht so ganz richtig aus:

2017.11.10 18:48:31 4 : SIGNALduino/msg READ: MU;P0=-32001;P1=364;P2=-21832;P3=1000;P4=-1509;P5=244;D=01234343454545454343454543434543454543454545434543434543454543454345454523434343454345434343434345454545434345454343454345454345454543454343454345454345434545452343434345434543434343434545454543434545434345434545434545454345434345434545434543454545234343;CP=5;R=24;O;
2017.11.10 18:48:31 4 : SIGNALduino: Fingerprint for MU Protocol id 50 -> optus_XT300 matches, trying to demodulate
2017.11.10 18:48:32 4 : SIGNALduino/msg READ: MU;P0=-1517;P1=990;P2=248;P3=-21988;D=01020102010101010102020202010102020101020102020102020201020101020102020102010202023101010102010201010101010202020201010202010102010202010202020102010102010202010201020202;CP=2;R=24;
2017.11.10 18:48:32 4 : SIGNALduino: Fingerprint for MU Protocol id 50 -> optus_XT300 matches, trying to demodulate
2017.11.10 18:48:33 4 : SIGNALduino/msg READ: MU;P0=-32001;P1=978;P2=-1542;P3=234;P5=-21972;D=01212121232123212323232123232323212123232323212323232123232321232323212323232123232123235121212123212321232323212323232321212323232321232323212323232123232321232323212323212323512121212321232123232321232323232121232323232123232321232323212323232123232321;CP=3;R=21;O;
2017.11.10 18:48:33 4 : SIGNALduino/msg READ: MU;P0=-1526;P1=240;P2=995;P3=-21990;D=010102010132020202010201020101010201010101020201010101020101010201010102010101020101010201010201013202020201020102010101020101010102020101010102010101020101010201010102010101020101020101;CP=1;R=22;


Ich denke das ich entweder die Fuses nicht richtig habe (wobei ich das in der Arduino IDE wohl nicht weiter beeinflussen kann) oder stimmen die 8MHz nicht?

Gruß
Bismosa
1x nanoCUL 433MHz (SlowRF Intertechno) für Fenstersensoren
1x nanoCUL 868Mhz für MAX (9x HT 1xWT)
1x ZigBee CUL
Weiteres: Squeezebox server, Kindle Display, ESP8266, Löterfahrung, ...


bismosa

Hallo,

danke für den Wink mit dem Zaunpfahl  :)

Ich habe jetzt mit avrdude (unter Windows) die Fuses ausgelesen. (Sorry...für mich ist das alles neuland)
avrdude.exe -c stk500v1 -p attiny85 -P com4 -U lfuse:r:-:i -v -b 19200
Dabei kam heraus:
(E:FF, H:DF, L:62)

Dann habe ich mit dem fusecalc http://www.engbedded.com/fusecalc gesehen, das bei mir wirklich der "Divide clock by 8" gesetzt war. Hier sind ja die richtigen Einstellungen auch schon beschrieben (https://forum.fhem.de/index.php/topic,52755.msg517158.html#msg517158)

Also habe ich diese jetzt neu gesetzt mit
avrdude.exe -c stk500v1 -p attiny85 -P com4 -U lfuse:w:0xe2:m -U hfuse:w:0xdf:m -U efuse:w:0xff:m -v -b 19200

Und die Abfrage bestätigt: (E:FF, H:DF, L:E2)

In FHEM kommt leider immer noch nichts richtiges an...

Also habe ich nochmal die LaCrosse geprüft. Natürlich hatte ich hier wieder die falsche Version. Grmpf. Also ausgetauscht und PIN_SEND auf 4. Jetzt kommt wohl endlich mal etwas an.

Internals:
   CODE       121
   DEF        121
   LASTInputDev SIGNALduino
   MSGCNT     11
   NAME       CUL_TX_121
   NR         299
   SIGNALduino_DMSG TXA0F32DD2D6
   SIGNALduino_MSGCNT 11
   SIGNALduino_RAWMSG MU;P0=-21493;P1=393;P2=-10356;P3=-940;P4=252;P5=1217;D=01213435353535353131313135353131353531353131353131313531353531353131353135313131053535353135313535353535313131313535313135353135313135313131353135353135313135313531313105353535313531353535353531313131353531313535313531313531313135313535313531313531353131;CP=1;R=41;O;
   SIGNALduino_RSSI -53.5
   SIGNALduino_TIME 2017-11-11 10:22:05
   STATE      T: -48.0
   TYPE       CUL_TX
   corr       0
   lastH      1510392118.01914
   lastT      1510392125.91591
   minsecs    0
   READINGS:
     2017-11-11 10:22:05   state           T: -48.0
     2017-11-11 10:22:05   temperature     -48.0
Attributes:
   room       CUL_TX


Aber es wird immer die Temperatur -48° und manchmal -50° angezeigt? Auch wenn ich den Sensor ganz entferne wird nichts anderes angezeigt?

Also irgendwas mache ich wohl immer noch falsch...oder ich habe noch mehr übersehen....

Gruß
Bismsoa
1x nanoCUL 433MHz (SlowRF Intertechno) für Fenstersensoren
1x nanoCUL 868Mhz für MAX (9x HT 1xWT)
1x ZigBee CUL
Weiteres: Squeezebox server, Kindle Display, ESP8266, Löterfahrung, ...

juergs

#205
Hallo bismosa,

Zitat(Sorry...für mich ist das alles Neuland)
... hast Du den Hinweis auf "avrdudess" gesehen? Das erleichtert das Ganze.
Außerdem gilt: Learing by doing ..  ;)

Die -50 Grad deuten eher darauf hin, dass evtl. die Pins mit den Zugriffen auf die Sensoren nicht richtig gesetzt sind.

Versuche doch einfach mal mit einem Basis-Sketch der Sensoren (einfach die Werte auf die serielle Schnittstelle ausgeben) zu überprüfen, ob die Hardware der Sensoren richtig funktioniert.
Sind deren Pins richtig gesetzt?

Hast Du den "Trick" gesehen, wie man die Serielle des ATtiny nur mit einem Pin betreiben  kann (Also nur TX, um Zwischenergebnisse zu sehen, wenn zu wenig Pins zur Verfügungs stehen?

Die I2C Pins könnten für NANO und ATTiny unterschiedlich sein...

Hast du die Readme.txt dazu gelesen?

ZitatBeta-Vorversion für ATtiny85 mit spezifischen I2C.
Angefangen, aber nicht fertig.

Wenn Du das LaCrosse-Senden hinbekommen hast, sollte der Rest nur ein Klacks sein ;)

Wie sieht Dein HW- Aufbau aus? Pullups für I2C?

Hier noch eine Möglichkeit, die Dir evtl. weiterhelfen könnte (möglicher Unterschied 3V3 und 5V beachten!) :
https://forum.fhem.de/index.php/topic,24651.msg419419.html#msg419419

bismosa

#206
Hallo,

danke für die ausführliche Hilfe! Es hat mich zwar wieder ein Stück weiter gebracht...aber funktionieren tut es leider immer noch nicht. Langsam fange ich an zu zweifeln...
Zitat von: juergs am 11 November 2017, 10:41:45
... hast Du den Hinweis auf "avrdudess" gesehen? Das erleichtert das Ganze.
Natürlich nicht. Wäre ja auch zu einfach gewesen. Aber ich habe es ja nach längerer Zeit endlich geschafft  :)

Zitat von: juergs am 11 November 2017, 10:41:45
Hast du die Readme.txt dazu gelesen?
Ähm...welche jetzt? Wo hast Du das Zitat gefunden? Gehört das noch zum "Trick" zur Seriellen Schnittstelle?


Also. Ich teste jetzt erstmal den DHT22. Dafür habe ich jetzt erstmal SoftwareSerial aktiviert:

#include <SoftwareSerial.h>
SoftwareSerial mySerial(0, 3);
...
void setup()
{
...
mySerial.begin(9600);
}

Und lasse mir über meinen FTDI1232 Adapter Serielle Ausgaben ausgeben.
Klappt soweit.

Den DHT22 habe ich an Pin4. Error ist 3 also DHT_ERROR_ACK_TOO_LONG
Wenn ich den Sensor entferne bekomme ich DHT_ERROR_NOT_PRESENT
Sieht ja gar nicht so verkehrt aus.
Pullup ist drin, Spannungsversorgung (3,3V) ok...alles mehrfach geprüft. Auch andere Pins probiert...jeweils der gleich Erfolg.

Dann habe ich (wie mit dem Digispark) die DHT lib von Rob Tillaart  ausprobiert. Beim ersten Versuch bekomme ich auch gleich die Werte. Allerdings nur direkt nach dem Einschalten.
Nach dem Schlafen erhalte ich auch hier den Fehler "DHTLIB_ERROR_CONNECT". [edit]Ich denke da muss noch irgendwas wieder geweckt werden. Habe ich jetzt aber noch nicht nachgeschaut.
Ich hatte noch den Sender auf dem gleichen pin im Programm. Der wurde natürlich durch "LaCrosse.setTxPinMode(OUTPUT);" falsch gesetzt. Also geht das mit der lib.[/edit]
Also ist der Sensor und die Verkabelung wohl ok.

Ich würde eigentlich lieber die hier verwendete lib von Ben Adams benutzen. Da habt ihr ja schon Erfahrungen...aber was mache ich hier wohl falsch?
Nutzt du (ihr) denn jetzt den Nano oder einen Attiny85?

Gruß
Bismosa
1x nanoCUL 433MHz (SlowRF Intertechno) für Fenstersensoren
1x nanoCUL 868Mhz für MAX (9x HT 1xWT)
1x ZigBee CUL
Weiteres: Squeezebox server, Kindle Display, ESP8266, Löterfahrung, ...

juergs

#207
ZitatNutzt du (ihr) denn jetzt den Nano oder einen Attiny85?
Zum Testen nehme ich den Nano oder Leonardo, dann portiere ich auf den ATtiny.

Ich komme leider mit Deinen Aussagen nicht ganz klar.
Du schilderst nicht genau genug, was Du eigentlich machst.

Wenn Du Dein Code in ein Zip packst und hier anhängst, wäre es möglicherweise einfacher nachzuvollziehen.  ;D

Hast DU das Projekt  mal genauer angeschaut?
Dort habe ich auch einen Schalter zwischen Leonardo und ATtiny eingebaut ..  :D

... und die DHT-Fehler-Quellen und Diagnose-Output:
case DHT_ERROR_NONE:
    //---Get Data
    dht_temp = myDHT22.getTemperatureC();
    dht_hum  = myDHT22.getHumidity();
    break;
  case DHT_ERROR_CHECKSUM:
    //--- send erraneous data as err indicator
    dht_temp = -99.99;
    dht_hum = -99.99;
    break;
  case DHT_BUS_HUNG:
    dht_temp = -88.88;
    dht_hum = -88.88;
    break;
  case DHT_ERROR_NOT_PRESENT:
    dht_temp = -77.77;
    dht_hum = -77.77;
    break;
  case DHT_ERROR_ACK_TOO_LONG:
    dht_temp = -66.66;
    dht_hum = -66.66;
    break;
  case DHT_ERROR_SYNC_TIMEOUT:
    dht_temp = -55.55;
    dht_hum = -55.55;
    break;
  case DHT_ERROR_DATA_TIMEOUT:
    dht_temp = -44.44;
    dht_hum = -44.44;
    break;
  case DHT_ERROR_TOOQUICK:
    dht_temp = -33.33;
    dht_hum = -33.33;
    break;
  default:
    dht_temp = -22.22;
dht_hum = -22.22;


Dort ist eigentlich alles realisiert ... und es funktioniert (auch mit sleep).  ;)

Schau auch mal in die Infos im Header!


bismosa

Hallo,

Zitat von: juergs am 12 November 2017, 19:00:48
Du schilderst nicht genau genug, was Du eigentlich machst.
Sorry. Ich werde versuchen mich zu bessern.

1.) Ich habe meinen Digispark mit einem HV-Programmer zurückgesetzt. Jetzt ist es kein Digispark mehr, sondern nur noch ein normaler Attiny85, der sich auf der Platine befindet.
2.) Nachdem ich nun die Fuses richtig gesetzt habe, klappt das Senden. (Wenn auch auff 433,7MHz...aber das ist kein Problem.)
3.) Hardwareaufbau:
https://forum.fhem.de/index.php?action=dlattach;topic=52755.0;attach=53190;image
Statt dem DS1820 nutze ich den DHT22.
3.) Ich programmiere rein mit der Arduino Software. Nun benutze ich den Code aus deinem GitHub (unverändert) https://github.com/juergs/_ATtiny85_DHT22_BMP180_433/blob/master/_ATtiny85_DHT22_BMP180_433.ino

Hiermit schaffe ich es nicht, den DHT22 auszulesen. (DHT_ERROR_ACK_TOO_LONG)

Nutze ich jedoch die DHT lib von Rob Tillaart (https://github.com/RobTillaart/Arduino/tree/master/libraries/DHTlib) funktioniert der DHT22 wie gewünscht.

Zitat von: juergs am 12 November 2017, 19:00:48
Hast DU das Projekt  mal genauer angeschaut?
Ja...aber erst jetzt. Soweit ich das sehen konnte, ist das Handling mit dem DHT22 aber gleich. Ich werde das heute Abend aber nochmal ausprobieren.

Vielen Dank für die Hilfe!

Gruß
Bismosa
1x nanoCUL 433MHz (SlowRF Intertechno) für Fenstersensoren
1x nanoCUL 868Mhz für MAX (9x HT 1xWT)
1x ZigBee CUL
Weiteres: Squeezebox server, Kindle Display, ESP8266, Löterfahrung, ...

juergs

ZitatFuse-Einstellungen beim ATtiny85 für interne 20 MHz:
   ====================================================
   LF = 0xF1 ( PLL-Clock, not internal 8 MHz)
   HF = 0xDF
   EF = 0xFF
   LB = 0x03