Selbstbau Funkthermometer 433Mhz

[juergs]

Zweckendfremdbare Bodenfeuchte-Platinen, die sich prima zum Sensor eignen, gibt es hier https://forum.fhem.de/index.php/topic,59933.90.html

[bismosa]

PS:
Vom Prinzip habe ich hier einen recht ähnlichen Aufbau in der Schublade auf einem Breadboard. Attiny85, mit 1 Mhz und einen DHT11.
Ich habe vom Prinzip her alles versucht was einem so einfällt. Ich habe sogar den DHT11 und auch das Sendemodul an einen digital Pin gehangen um in an / aus zu schalten.
Wenn Du ihn mit Batterie betreiben willst, dann drücke ich dir die Daumen. Ich hatte da ernsthaft Probleme mit der Haltbarkeit der Batterien.  Daher habe ich auch einige Zeit in ein sehr optimiertes Protokoll gesteckt, denn das Sendemodul verbraucht schon einiges an Energie.

Grüße Sidey

Hallo,

da muss ich mich ja unbedingt wieder einmischen. Habe jetzt auch schon viel probiert, gelesen und getestet. Nun habe ich gerade einen ersten Versuchsaufbau laufen...das sieht bisher schon vielversprechend aus!
Versuchsaufbau (Siehe angehängte Grafik)
- 1x AA Eneloop Akku. Vollgeladen um einen Verbrauch nach einiger Zeit abschätzen zu können.
  (Achtung! Später keine Akkus verwenden, da kein Tiefentladeschutz!)
- Step-Up Wandler 3,3V
- Elko 10µF 25V
- Sender 433MHz FS1000A
- DHT22 mit einem Pullup-Widerstand von 4,7kOhm
- 1kOhm Widerstand zwischen 5V+Reset

Da der Strom sich mit meinen Mitteln (zu langsame Multimeter) kaum messen lässt, habe ich versucht diesen einzeln zu erfassen (ich habe meine Notiz verlegt...daher grob geschätzte Werte):
1.) Deep-Sleep ca. 0,08mA
2.) attiny85 arbeitet ca. 30mA (bei mir derzeit auf 16MHz siehe weiter unten)
3.) Senden (ist ja nur sehr kurz) ca. 80mA

Daraus resultiert, das nur im Deep-Sleep eine einzelne AA-Mignon Batterie (2500mAh) ca. 3 Jahre durchhalten sollte. (Rechner hier: https://oregonembedded.com/batterycalc.htm).
Wenn ich nun einen mittleren Verbrauch von 35mA annehme, wenn gemessen und gesendet wird...könnte die einzelne Batterie 0,54Jahre (196 Tage) durchhalten...denn ich benötige nur ca. 636ms Ausführungszeit (ohne Batteriespannung messen und diesen Wert Senden).

Ich nutze allerdings eine andere Vorlage der recht ähnlichen Software von hier: https://crycode.de/diy-funk-wetterstation-mit-dht22-attiny85-und-radiohead
Diese habe ich aber auch stark abgeändert:
1.) keine 5V sondern 3,3V von einer Batterie mit Step-Up Wandler
2.) keine LEDs
3.) Senden nicht RadioHead, sondern ich nutze hier das "Hideki" Protokoll von hier: https://bitbucket.org/fuzzillogic/433mhzforarduino/overview
Hier kann ich Temperatur und Luftfeuchte mit einem mal senden. Klappte auch auf Anhieb.

Die DHT-Fastlib ist wirklich flott und läuft bei mir (derzeit leider nur bei 16MHz) stabil. Um den Stromverbrauch im Standby zu senken musste ich den Pin vom DHT22 erst auf Low und dann pinMode auf Input setzen, damit der Verbrauch sinkt. Keine Ahnung warum.
Für den Versuch übermittel ich alle 30 Sendevorgänge den Analogwert.

Was hier noch zu erledigen ist:
1.) Code optimieren! Ausführungszeit auf ein minimum beschränken
2.) Den Attiny nur auf 1MHz laufen lassen
3.) AnalogWerte richtig lesen. Derzeit kommt da noch nichts brauchbares raus
4.) Vergleichen wie sich der Stromverbrauch mit 2 Batterien reduziert. Dann gibt es nicht so viele Verluste durch den StepUp.
5.) Den Empfang prüfen. In FHEM kommt nicht jeder Messwert an.

Ich habe den Versuchsaufbau nun seit 9 Tagen laufen. Ich sende derzeit alle 14 Sekunden neue Messwerte. D.h. im Realbetrieb (ca. 1x pro Minute...mein Wunsch) wären dies bereits 36 Tage Laufzeit. Wenn z.B. nur alle 3 Minuten ein Messwert benötigt wird, sind das schon über 100 Tage! Die Akkuspannung hat nun ca. 0,2V abgenommen. Ich werde die Tage dann mal den Akku ins Ladegerät legen und sehen, wie hoch der Verbrauch in etwa war...dann kann ich auch die Realen Werte und die Theoretischen besser abschätzen.

Gruß
Bismosa

[juergs]

Hallo bismosa,
das deckt sich in etwa auch mit meinen Messungen. 

Du hast den DHT aber über den Pullup-Widerstand ständig auf VCC.
Das ließe sich noch optimieren, wenn Du diese über einen FET schaltbar machst (wenn noch ein Portpin dafür frei wäre ...)
und dem DHT genügend Zeit gibst sich aufzuwärmen, bevor eine oder mehrere Messungen gemacht werden
und dann gesendet werden. Man muss nur die Aufwärmzeit des DHT analysieren und in den Meßzyklus mit einbinden.
Das Gleiche gilt für das Sende-Modul.
Bin mir sicher, daß man da noch etwas herausholen/-quetschen kann.

Das Hideki-Protokoll ist zwar genau für diesen Anwendungszweck auch geeignet, allerdings benutze ich
das CUL_TX-Protokoll für alles Mögliche, das Hideki-Protokoll hatte aber gewisse Einschränkungen,
so dass ich auf das 433-LaCrosse-Protokoll (TX2/3) zurückgegangen bin.

Grüße,
Jürgen

[bismosa]

Hallo,

schön, das Du ähnliche Ergebnisse erzielt hast. Dann liege ich wohl nicht ganz so falsch.
Ich habe auch probiert, den DHT erst für die Messung zu aktivieren. Pin5 und Pin6 sind bei mir ja noch frei. Allerdings verschwendet man wohl zu viel Energie, wenn man 2sek. (schneller ging es bei mir nicht) auf den DHT22 warten muss. Der DHT soll lt. Datenblatt ja nur 0,04mA verbrauchen (bei 3,3V). Das deckt sich fast mit meinen Ergebnissen. Wobei jeder meiner DHT22 hier anders ist!

Durch den 4,7kOhm Widerstand habe ich weitere 0.0007mA. Der Rest wird dann durch den StepUp "verbraten".
Meine Messungen haben gezeigt, das der FS1000A 0,nixMessbares im Standby benötigt.

Das LaCrosse Protokoll und vor allem Deine Bemühungen dies umzusetzen wollte ich nicht schlecht reden! Ich hoffe das ist auch nicht so rüber gekommen. Ich habe nicht weiter probiert/Analysiert ob es nicht sogar schneller ist. Bei Deinem Beispiel wartet der Attiny jedoch 2sek. um den anderen Wert zu senden. Dies ist Laufzeit die Stark auf die Batterie geht. Hier könnte man aber auch eine kurze Deep-Sleep Phase einlegen. Dann wäre das auch gut!

Habe gerade wieder einen Schwung Batterien aus der Weihnachtsbeleuchtung entnommen. Die Batterien sind zwar nicht mehr voll...aber dann für ein Thermometer bestimmt noch einige Wochen gut zu gebrauchen 

Ich muss auch noch unbedingt testen wie es sich mit meinen Fenstersensoren verträgt. Diese senden ebenfalls auf 433MHz. 3x hintereinander ohne Rückkanal. Wäre doof, wenn die dann nicht mehr funktionieren. Dann versuche ich das Ganze lieber auf 868MHz. Hier sind zwar meine MAX Thermostate...aber die merken, wenn die Kommunikation gestört ist.

Gruß
Bismosa

[bismosa]

Hallo,

ich habe frische Messergebnisse 

Mein Versuchsaufbau lief jetzt 22 Tage mit einem Eneloop Akku.
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.

Nur mal so als Zwischenergebnis. Ich werde die Tage mal einen Sensor zusammenbauen, den Code weiter Optimieren und dann das Ganze mit einer Batterie laufen lassen. Es wird dann allerdings lange Dauern bis ich etwas zur tatsächlichen Laufzeit sagen kann 

Für mich ist auch ein halbes Jahr mit einer Batterie eine gute Zeit! Bei einem Messwert jede Minute!

Gruß
Bismosa

[CatWeazle]

Hallo bismosa,

das hört sich aber gut an. Respekt!

Hattest du den Code dazu schon veröffentlicht?

Würde mir gerne das Eine oder Andere abgucken, denn meine Akkulaufzeit ist deutlich, aber so was von deutlich kürzer

Grüße
Mike

[bismosa]

Hallo,

nein, den Code hatte ich noch nicht veröffentlicht. Eigentlich aus 2 Gründen
1.) Alles nur geklaut Naja...auf jeden Fall nur zusammenkopiert.
2.) Nicht aufgeräumt...derzeit ist das noch reiner Spaghetti-Code...

Da ich die Tage nicht dazu kommen werde hier weiter zu machen...und mir denken kann, das es den einen oder anderen interessiert...im Anhang eine ZIP mit dem Projekt.
Kurz noch was dazu:
1.) Überhaupt nicht aufgeräumt
2.) Vorlage von  https://crycode.de/diy-funk-wetterstation-mit-dht22-attiny85-und-radiohead
3.) "Hideki" Protokoll von hier: https://bitbucket.org/fuzzillogic/433mhzforarduino/overview
4.) Analog Read funktioniert noch nicht. Keine Ahnung warum. Hatte vor dem Test keine Zeit mehr das zu ergründen...

Es ist sehr wichtig, das die Ausführungszeit auf ein Minimum beschränkt wird. Nach Möglichkeit keine Sleeps etc. Das bringt wohl am meisten!

Für Tipps und Bugfixes bin ich immer zu haben! Ich hoffe das ich auch bald mal wieder dazu komme!

Gruß
Bismosa

[Deutz]

Hallo, habe versucht, den Code zu kompilieren und erhielt die Fehlermeldung bezüglich der fehlenden SensorTransmitter.h. Habe dann diejenige von https://github.com/RFD-FHEM/ArduinoSensor/blob/master/SensorTransmitter/SensorTransmitter.h verwendet, was zu dem neuen Fehler Attiny85_DHT22_V0.3_FastLib_Bismosa:32: error: 'ThermoHygroTransmitter' does not name a type führt. Habe ich die falsche Library?
Danke im voraus, Deutz

[bismosa]

Hallo,

sorry...ich habe echt kaum Zeit im Moment. Müsste es nicht die Lib von hier sein:
https://bitbucket.org/fuzzillogic/433mhzforarduino/wiki/Home
bzw.
https://bitbucket.org/fuzzillogic/433mhzforarduino/overview

Sonst muss ich mir das nochmal anschauen welche ich habe...das wird aber leider erst nächste Woche...

Gruß
Bismosa

[biggsmann]

Damit baut es zumindest.

Danke.

[Bender78]

Hey, hab grade den Thread gefunden.

Ich hab sowas auch gebaut, also Attiny, 433Mhz Funkchip, Reed/Kupfer Kontakt.

Verbrauch bei geschlossenem Fenster 4 uA, bei offenem Fenster 6uA.
Hatte erst den internen PULL-UP Widerstand verwendet, der verbraucht aber zu viel bei offenem Fenster bei mir.
Interrupt hat bei mir das Aufwachen nicht zuverlässig funktioniert, also wache ich 1x pro Sekunde auf und checke den Status. Bei Änderung wird dann gesendet.
Alles im Intertechno Protokoll, eine CR2032 sollte n paar Jahre reichen nach großben Berechnungen.
Habe im Garten sowas auch als Bewegungsmelder - funzt mittlerweile über ein Jahr ohne Probleme.


Sketch:

Code Auswählen Erweitern

#include <NewRemoteTransmitter.h>
#include <avr/sleep.h>
#include <avr/wdt.h>

#ifndef cbi
#define cbi(sfr, bit) (_SFR_BYTE(sfr) &= ~_BV(bit))
#endif
#ifndef sbi
#define sbi(sfr, bit) (_SFR_BYTE(sfr) |= _BV(bit))
#endif

byte REED_PIN=2;     
byte SEND_PIN=3;   

boolean Status=false;

NewRemoteTransmitter transmitter(50630001, SEND_PIN, 290, 2);   // 300us Pulslaenge an PIN 3

void setup() {
  pinMode(REED_PIN, INPUT);
 
  setup_watchdog(6);  // approximately 1 seconds sleep
  cbi(ADCSRA,ADEN);                    // switch Analog to Digitalconverter OFF
  set_sleep_mode(SLEEP_MODE_PWR_DOWN); // sleep mode is set here
}

void loop() {
system_sleep();
}

void system_sleep() {
  sleep_enable();
  sleep_mode();                        // System sleeps here
  sleep_disable();                     // System continues execution here when watchdog timed out
  //sbi(ADCSRA,ADEN);                    // switch Analog to Digitalconverter ON
}

// 0=16ms, 1=32ms,2=64ms,3=128ms,4=250ms,5=500ms
// 6=1 sec,7=2 sec, 8=4 sec, 9= 8sec

void setup_watchdog(int ii) {
  byte bb;
  int ww;
  if (ii > 9 ) ii=9;
  bb=ii & 7;
  if (ii > 7) bb|= (1<<5);
  bb|= (1<<WDCE);
  ww=bb;
  MCUSR &= ~(1<<WDRF);
  // start timed sequence
  WDTCR |= (1<<WDCE) | (1<<WDE);
  // set new watchdog timeout value
  WDTCR = bb;
  WDTCR |= _BV(WDIE);
}

// Watchdog Interrupt Service / is executed when watchdog timed out
ISR(WDT_vect) {
    if (digitalRead(REED_PIN)==LOW && Status==true){
         Status=false;
         transmitter.sendUnit(6, false);
         //pinMode(REED_PIN, INPUT);
    }else if (digitalRead(REED_PIN)==HIGH && Status==false) {
         Status=true;
         //pinMode(REED_PIN, INPUT_PULLUP);
         transmitter.sendUnit(6, true);
    }
}



Hallo zusammen,

sorry erst einmal, dass ich von Seite 11 was "vor" hole.  Ich möchte eigentlich nur meine Fensterkontakte übermachen. Dazu gefällt mir das Beispiel, welches "meggih" aufgeführt hat sehr gut. Zunächst habe ich mir das Ganze auf einem Steckbrett aufgebaut und habe auch einen Digispark verwendet da ich gerade keinen einzelnen Attiny herum liegen habe und auch besser "herumspielen" kann. Wenn das ganze mir gefällt soll alles "Stromsparend" dann mit einem Attiny aufgebaut werde.
Jedoch habe ich nun das Problem, das wenn ich den obigen Code verwende, dieser beim Kompilieren mit einem Fehler abgebrochen wird. Ich bin absoluter "Neuling" was Arduino usw. angeht. Die ganzen Dinge wie LED aus einschalten und PWM ist soweit alles verständlich... aber jetzt will ich doch mal an "Funkübertragung" gehen und dort herum spielen.
Bei mir die Übersetzung mit diesen Fehlern abgebrochen.

Code Auswählen Erweitern

Arduino: 1.8.5 (Windows 7), Board: "Digispark (Default - 16.5mhz)"

Archiving built core (caching) in: C:\Users\PC_Home\AppData\Local\Temp\arduino_cache_451814\core\core_digistump_avr_digispark-tiny_a09920091512088f4cfd8dda5c7f87b8.a
libraries\NewRemoteSwitch\NewRemoteReceiver.cpp.o: In function `NewRemoteReceiver::interruptHandler()':

C:\Program Files (x86)\Arduino\libraries\NewRemoteSwitch/NewRemoteReceiver.cpp:73: multiple definition of `NewRemoteReceiver::interruptHandler()'

sketch\NewRemoteReceiver.cpp.o:sketch/NewRemoteReceiver.cpp:73: first defined here

libraries\NewRemoteSwitch\NewRemoteReceiver.cpp.o: In function `NewRemoteReceiver::interruptHandler()':

C:\Program Files (x86)\Arduino\libraries\NewRemoteSwitch/NewRemoteReceiver.cpp:73: multiple definition of `NewRemoteReceiver::_enabled'

sketch\NewRemoteReceiver.cpp.o:sketch/NewRemoteReceiver.cpp:73: first defined here

libraries\NewRemoteSwitch\NewRemoteReceiver.cpp.o: In function `NewRemoteReceiver::interruptHandler()':

C:\Program Files (x86)\Arduino\libraries\NewRemoteSwitch/NewRemoteReceiver.cpp:73: multiple definition of `NewRemoteReceiver::_state'

sketch\NewRemoteReceiver.cpp.o:sketch/NewRemoteReceiver.cpp:73: first defined here

libraries\NewRemoteSwitch\NewRemoteReceiver.cpp.o: In function `NewRemoteReceiver::interruptHandler()':

C:\Program Files (x86)\Arduino\libraries\NewRemoteSwitch/NewRemoteReceiver.cpp:73: multiple definition of `NewRemoteReceiver::_minRepeats'

sketch\NewRemoteReceiver.cpp.o:sketch/NewRemoteReceiver.cpp:73: first defined here

libraries\NewRemoteSwitch\NewRemoteReceiver.cpp.o: In function `NewRemoteReceiver::interruptHandler()':

C:\Program Files (x86)\Arduino\libraries\NewRemoteSwitch/NewRemoteReceiver.cpp:73: multiple definition of `NewRemoteReceiver::_inCallback'

sketch\NewRemoteReceiver.cpp.o:sketch/NewRemoteReceiver.cpp:73: first defined here

libraries\NewRemoteSwitch\NewRemoteReceiver.cpp.o: In function `NewRemoteReceiver::interruptHandler()':

C:\Program Files (x86)\Arduino\libraries\NewRemoteSwitch/NewRemoteReceiver.cpp:73: multiple definition of `NewRemoteReceiver::_callback'

sketch\NewRemoteReceiver.cpp.o:sketch/NewRemoteReceiver.cpp:73: first defined here

libraries\NewRemoteSwitch\NewRemoteReceiver.cpp.o: In function `NewRemoteReceiver::interruptHandler()':

C:\Program Files (x86)\Arduino\libraries\NewRemoteSwitch/NewRemoteReceiver.cpp:73: multiple definition of `NewRemoteReceiver::enable()'

sketch\NewRemoteReceiver.cpp.o:sketch/NewRemoteReceiver.cpp:73: first defined here

libraries\NewRemoteSwitch\NewRemoteReceiver.cpp.o: In function `NewRemoteReceiver::interruptHandler()':

C:\Program Files (x86)\Arduino\libraries\NewRemoteSwitch/NewRemoteReceiver.cpp:73: multiple definition of `NewRemoteReceiver::init(signed char, unsigned char, void (*)(NewRemoteCode))'

sketch\NewRemoteReceiver.cpp.o:sketch/NewRemoteReceiver.cpp:73: first defined here

libraries\NewRemoteSwitch\NewRemoteReceiver.cpp.o: In function `NewRemoteReceiver::interruptHandler()':

C:\Program Files (x86)\Arduino\libraries\NewRemoteSwitch/NewRemoteReceiver.cpp:73: multiple definition of `NewRemoteReceiver::_interrupt'

sketch\NewRemoteReceiver.cpp.o:sketch/NewRemoteReceiver.cpp:73: first defined here

libraries\NewRemoteSwitch\NewRemoteReceiver.cpp.o: In function `NewRemoteReceiver::interruptHandler()':

C:\Program Files (x86)\Arduino\libraries\NewRemoteSwitch/NewRemoteReceiver.cpp:73: multiple definition of `NewRemoteReceiver::disable()'

sketch\NewRemoteReceiver.cpp.o:sketch/NewRemoteReceiver.cpp:73: first defined here

libraries\NewRemoteSwitch\NewRemoteReceiver.cpp.o: In function `NewRemoteReceiver::interruptHandler()':

C:\Program Files (x86)\Arduino\libraries\NewRemoteSwitch/NewRemoteReceiver.cpp:73: multiple definition of `NewRemoteReceiver::deinit()'

sketch\NewRemoteReceiver.cpp.o:sketch/NewRemoteReceiver.cpp:73: first defined here

libraries\NewRemoteSwitch\NewRemoteReceiver.cpp.o: In function `NewRemoteReceiver::interruptHandler()':

C:\Program Files (x86)\Arduino\libraries\NewRemoteSwitch/NewRemoteReceiver.cpp:73: multiple definition of `NewRemoteReceiver::isReceiving(int)'

sketch\NewRemoteReceiver.cpp.o:sketch/NewRemoteReceiver.cpp:73: first defined here

libraries\NewRemoteSwitch\NewRemoteTransmitter.cpp.o: In function `NewRemoteTransmitter::NewRemoteTransmitter(unsigned long, unsigned char, unsigned int, unsigned char)':

C:\Program Files (x86)\Arduino\libraries\NewRemoteSwitch/NewRemoteTransmitter.cpp:11: multiple definition of `NewRemoteTransmitter::NewRemoteTransmitter(unsigned long, unsigned char, unsigned int, unsigned char)'

sketch\NewRemoteTransmitter.cpp.o:sketch/NewRemoteTransmitter.cpp:11: first defined here

libraries\NewRemoteSwitch\NewRemoteTransmitter.cpp.o: In function `NewRemoteTransmitter::_sendBit(unsigned char)':

C:\Program Files (x86)\Arduino\libraries\NewRemoteSwitch/NewRemoteTransmitter.cpp:141: multiple definition of `NewRemoteTransmitter::NewRemoteTransmitter(unsigned long, unsigned char, unsigned int, unsigned char)'

sketch\NewRemoteTransmitter.cpp.o:sketch/NewRemoteTransmitter.cpp:141: first defined here

libraries\NewRemoteSwitch\NewRemoteTransmitter.cpp.o: In function `NewRemoteTransmitter::_sendBit(unsigned char)':

C:\Program Files (x86)\Arduino\libraries\NewRemoteSwitch/NewRemoteTransmitter.cpp:141: multiple definition of `NewRemoteTransmitter::_sendStartPulse()'

sketch\NewRemoteTransmitter.cpp.o:sketch/NewRemoteTransmitter.cpp:141: first defined here

libraries\NewRemoteSwitch\NewRemoteTransmitter.cpp.o: In function `NewRemoteTransmitter::_sendBit(unsigned char)':

C:\Program Files (x86)\Arduino\libraries\NewRemoteSwitch/NewRemoteTransmitter.cpp:141: multiple definition of `NewRemoteTransmitter::_sendStopPulse()'

sketch\NewRemoteTransmitter.cpp.o:sketch/NewRemoteTransmitter.cpp:141: first defined here

libraries\NewRemoteSwitch\NewRemoteTransmitter.cpp.o: In function `NewRemoteTransmitter::_sendBit(unsigned char)':

C:\Program Files (x86)\Arduino\libraries\NewRemoteSwitch/NewRemoteTransmitter.cpp:141: multiple definition of `NewRemoteTransmitter::_sendBit(unsigned char)'

sketch\NewRemoteTransmitter.cpp.o:sketch/NewRemoteTransmitter.cpp:141: first defined here

libraries\NewRemoteSwitch\NewRemoteTransmitter.cpp.o: In function `NewRemoteTransmitter::_sendBit(unsigned char)':

C:\Program Files (x86)\Arduino\libraries\NewRemoteSwitch/NewRemoteTransmitter.cpp:141: multiple definition of `NewRemoteTransmitter::_sendAddress()'

sketch\NewRemoteTransmitter.cpp.o:sketch/NewRemoteTransmitter.cpp:141: first defined here

libraries\NewRemoteSwitch\NewRemoteTransmitter.cpp.o: In function `NewRemoteTransmitter::_sendBit(unsigned char)':

C:\Program Files (x86)\Arduino\libraries\NewRemoteSwitch/NewRemoteTransmitter.cpp:141: multiple definition of `NewRemoteTransmitter::_sendUnit(unsigned char)'

sketch\NewRemoteTransmitter.cpp.o:sketch/NewRemoteTransmitter.cpp:141: first defined here

libraries\NewRemoteSwitch\NewRemoteTransmitter.cpp.o: In function `NewRemoteTransmitter::_sendBit(unsigned char)':

C:\Program Files (x86)\Arduino\libraries\NewRemoteSwitch/NewRemoteTransmitter.cpp:141: multiple definition of `NewRemoteTransmitter::sendGroup(unsigned char)'

sketch\NewRemoteTransmitter.cpp.o:sketch/NewRemoteTransmitter.cpp:141: first defined here

libraries\NewRemoteSwitch\NewRemoteTransmitter.cpp.o: In function `NewRemoteTransmitter::_sendBit(unsigned char)':

C:\Program Files (x86)\Arduino\libraries\NewRemoteSwitch/NewRemoteTransmitter.cpp:141: multiple definition of `NewRemoteTransmitter::sendUnit(unsigned char, unsigned char)'

sketch\NewRemoteTransmitter.cpp.o:sketch/NewRemoteTransmitter.cpp:141: first defined here

libraries\NewRemoteSwitch\NewRemoteTransmitter.cpp.o: In function `NewRemoteTransmitter::_sendBit(unsigned char)':

C:\Program Files (x86)\Arduino\libraries\NewRemoteSwitch/NewRemoteTransmitter.cpp:141: multiple definition of `NewRemoteTransmitter::sendDim(unsigned char, unsigned char)'

sketch\NewRemoteTransmitter.cpp.o:sketch/NewRemoteTransmitter.cpp:141: first defined here

libraries\NewRemoteSwitch\NewRemoteTransmitter.cpp.o: In function `NewRemoteTransmitter::_sendBit(unsigned char)':

C:\Program Files (x86)\Arduino\libraries\NewRemoteSwitch/NewRemoteTransmitter.cpp:141: multiple definition of `NewRemoteTransmitter::sendGroupDim(unsigned char)'

sketch\NewRemoteTransmitter.cpp.o:sketch/NewRemoteTransmitter.cpp:141: first defined here

collect2.exe: error: ld returned 1 exit status

exit status 1
Fehler beim Kompilieren für das Board Digispark (Default - 16.5mhz).

Dieser Bericht wäre detaillierter, wenn die Option
"Ausführliche Ausgabe während der Kompilierung"
in Datei -> Voreinstellungen aktiviert wäre.


Wenn ich auf einen Arduino Uno gehe kommt nur noch die Meldung

Code Auswählen Erweitern

Arduino: 1.8.5 (Windows 7), Board: "Arduino/Genuino Uno"

Build-Optionen wurden verändert, alles wird neu kompiliert
C:\Users\PC_Home\Documents\Arduino\433MHZ_Funk_neu\433MHZ_Funk_neu.ino: In function 'void setup_watchdog(int)':

433MHZ_Funk_neu:51: error: 'WDTCR' was not declared in this scope

   WDTCR |= (1<<WDCE) | (1<<WDE);

   ^

exit status 1
'WDTCR' was not declared in this scope

Dieser Bericht wäre detaillierter, wenn die Option
"Ausführliche Ausgabe während der Kompilierung"
in Datei -> Voreinstellungen aktiviert wäre.


Bin ein wenig überfordert. Vielleicht kann jemand von euch mal einen Blick drauf werfen
Besten Dank!
Steffen

[juergs]

Hallo Bender78,

hast Du in der Arduino-IDE auch die Umgebung für den Digispark ATtiny85 installiert und als Board-Typ im Tools-Menü ausgewählt.
Damit kann die Arduino-IDE die richtigen Anpassungen bei der Ressourcen-Auswahl z.B. " WDTCR" treffen.

Um das aber genauer beurteilen zu können, probier noch mal einen Compile und poste den Text des Ergebnisfensters als Datei in Deine Antwort.
Dann kann man besser beurteilen wo das Problem liegt.

Dein Code läuft bei mir ohne Fehler durch...
Der Output sollte so etwas in der Art enthalten:

Code Auswählen Erweitern

" -mmcu=attiny85 -DF_CPU=16500000L -DARDUINO=10804 -DARDUINO_AVR_DIGISPARK -DARDUINO_ARCH_AVR"

Vielleicht ist es noch in Hinsicht auf FHEM zu erwähnen, daß Du das Hideki-Protokoll gewählt hast.

http://www.max-mg.de/Digispark_ATTiny85_einrichten.pdf

Grüße,
Jürgen

[Bender78]

Hallo Bender78,

hast Du in der Arduino-IDE auch die Umgebung für den Digispark ATtiny85 installiert und als Board-Typ im Tools-Menü ausgewählt.
Damit kann die Arduino-IDE die richtigen Anpassungen bei der Ressourcen-Auswahl z.B. " WDTCR" treffen.

Um das aber genauer beurteilen zu können, probier noch mal einen Compile und poste den Text des Ergebnisfensters als Datei in Deine Antwort.
Dann kann man besser beurteilen wo das Problem liegt.

Dein Code läuft bei mir ohne Fehler durch...
Der Output sollte so etwas in der Art enthalten:

Code Auswählen Erweitern

" -mmcu=attiny85 -DF_CPU=16500000L -DARDUINO=10804 -DARDUINO_AVR_DIGISPARK -DARDUINO_ARCH_AVR"

Vielleicht ist es noch in Hinsicht auf FHEM zu erwähnen, daß Du das Hideki-Protokoll gewählt hast.

http://www.max-mg.de/Digispark_ATTiny85_einrichten.pdf

Grüße,
Jürgen

Hallo Jürgen, vielen Dank für deine Info.
Ich bin jetzt ein Stück weiter gekommen. Den Digispark habe ich in Arduino installiert und hab halt wie immer mein Blinklämpchen übertragen. Das hat auch problemlos funktioniert.
Beim obigen Code läuft die Kompilierung jetzt auch ohne Fehler durch. Ich hatte vermutlich aus verzweiflung und Unwissenheit die Funktion "NewRemoteTransmitter" in den gleichen Ordner kompiert indem der Sketch lag. Dies habe ich jetzt gelöscht und nun läuft es fehlerfrei durch...

Aber natürlich tut sich an meinem FHEM nichts. Mein Cul erkennt nicht das ich den Kontakt zu  Pin 2 öffne und schließe.
Aufgebaut ist es wie folgt VCC, GND sind mit dem Digispark verbunden und Data des STX822 ist mit dem Pin3 des Digispark verbunden. Spannung messe ich.

Oder kann der Nano Cul dieses Protokoll nicht? Ich meine gelesen zu haben das dieser dies ebenfalls via AutoCreate in FHEM anlegt.

[juergs]

Aber natürlich tut sich an meinem FHEM nichts. Mein Cul erkennt nicht das ich den Kontakt zu  Pin 2 öffne und schließe.

Das Protokoll, dafür ist es primär ausgelegt, überträgt ja analoge Daten, wie z.B. Temperaturen oder Drücke.
Unter Umständen sind noch zur Abhandlung von negativen Temperaturen noch ein Offset zum endgültigen Wert addiert.

Man kann aber Tricksen. Durch den Reed-Kontakt kann man ja nur 2 Zustände übertragen.
Je nach Aufbau 0 V oder 5V, wenn Du z.B. Vcc --- 10KOhm-- Abzweig zum ATtiny-Analog-Pin---Reed-Kontakt ---- GND benutzt.
Also sollte der Sensor ca. 2 unterschiedliche Werte liefern. Diese kannst Du im Programm am AD-Wandler Abfragen
und dann in die zwei Zustände z.B. 0 und 100 (innerhalb der Protokoll-Übertragungs-Grenzen) skalieren, entstören (Redd-Kontakte prellen)
und dann übertragen.

In FHEM kannst Du dann mit Abfragen auf die zwei Zustände reagieren.
Wie das gemacht wird steht, glaube ich, hier im Thread oder bemühe einfach die FHEM-Suche nach "Fensterkontakt" 
dann bekommst Du mit Sicherheit einige passende Treffer dazu ...

Fange einfach mal damit an, nur feste Daten zu übertragen um das Device in FHEM wiederzufinden...
Dann kannst Du mit den Werten jonglieren. Denke  daran, nicht das Funknetz mit zu vielen Wiederholungen und keinen Zwischenpausen zu blockieren.
Üblich sind 3..5 Wiederholungen, die gehen aber auf die Batterie-Lebensdauer ... 

Jürgen

[KölnSolar]

oder Du integrierst eine weitere Library, die eher für Schalter geeignet ist.
(Diesen u. Folgeposts.)