Nabend
Die habe ich über Google gefunden, weil ich wissen wollte, wie die Pins auf dem ATtiny84 bezeichnet werden.
Die ist aber auch hier (in bunt) zu finden:
Batteriebetriebene Funk Sensoren
Hast du eine andere?
Nabend
Die habe ich über Google gefunden, weil ich wissen wollte, wie die Pins auf dem ATtiny84 bezeichnet werden.
Die ist aber auch hier (in bunt) zu finden:
Batteriebetriebene Funk Sensoren
Hast du eine andere?
Fehlersuche bei Funk-Temperatursensoren? Schau mal ob du hier fündig wirst!
Mich irritiert die Bezeichnung ...
Pins bei ICs werden üblicherweise von links oben nach rechts oben entgegen dem Uhrzeiger-Sinn durchgezählt.
In der von dir weiter oben geposteten Belegung wird aber z.B. Pin Nr. 8 (PA5) als Pin 5 und er physikalische Pin Nr. 2 als Pin 10 angegeben. Das ist eine andere Zählweise (im Uhrzeiger-Sinn) die zudem Vcc und GND nicht mit einschliesst.
Ich frage mich halt, ob und was das jetzt mit dem ATTiny resp. Funkmodul zu tun hat. Möglicherweise müssten andere Pin-Nummern im sketch verwendet werden.
Mal meigrafd fragen ...
cu,
-ds-
Nicht so:
#define rxPin 7 // D7, PA3
#define txPin 3 // D3, PA7. pin der an RXD vom PI geht.
sondern so
#define rxPin 3 // D7, PA3
#define txPin 7 // D3, PA7. pin der an RXD vom PI geht.
und jetzt klappt es!
...Loop...
...Loop...
...Loop...
...Loop...
...Loop...
...Loop...
...Loop...
...Loop...
...Loop...
...Loop...
Baue jetzt erstmal alles wieder zusammen...
Hatten wir das mit den Pins nicht schon mehrfach ( -> hier <- z.B. ) ?
Naja, ... Hauptsache es geht jetzt
bye,
-ds-
..ohne jetzt allles gelesen zu haben:
Wenn man im Sketch eine Nummer angibt, bezieht sich das nicht auf die Pin#:
Was das ist steht auch extra dahinter.
rxPin 7 ist = D7 / PA7 -> pin#6
txPin 3 ist = D3 / PA3 -> pin#10
Die pin# ist die Nummer des Beinchens. Diese Pins beziehen sich generell auf den ATtiny84, wie sie dort eben angeschlossen wurden. Oben links fängts mit 1 an, linke Seite runter bis 7 dann gegenüberliegend rechts #8 und rechts nach oben ans Ende...
Das hat erst mal nichts mit dem PI zu tun, da sind die Nummerierungen freilich anders. Beim PI geht das aber im ZickZack: links oben 1, gegenüber 2, links unter 1 ist dann 3, rechts daneben 4 usw
Wenn du das jetzt verdreht hast, hattest du vorher einfach nur die Kabel falsch am PI angeschlossen...
Moin
Von den unterschiedlichen Bezeichnung der Pins wusste ich noch nichts.
Zumindest was gelernt bei der Aktion
Ich bin aber noch nicht ganz durch mit der Fehlersuche.
Sender:
ATt, DS18B20 und Funkmodul bekommen Strom.
Kein Kurzschluss und alles richtig verschaltet.
Ich habe alles mit dem Multimeter durchgemessen.
Aber ich kann ja gar nicht wissen ob der Sender funktionier,
wenn ich mir beim Empfänger auch nicht sicher bin...
Empfänger:
ATt, Funkmodul und LED bekommen Strom
LED blinkt drei mall wenn ich den Empfänger anschließe,
dann aber nicht mehr...
Verbindungen sind auch alle überprüft und passen.
Sollte die LED auch leuchten, wenn ich auf einer 433Mhz Funkfernbedienung rumdrücke?
Und wenn die LED nicht leuchtet, wird wahrscheinlich auch nicht von minicom empfangen, oder?
Gruß Kolja
Empfänger:LED blinkt drei mall wenn ich den Empfänger anschließe
Wieso 3x? Innerhalb welches Abstands?
Im Sketch ist vorgesehen das er 1x beim Setup für eine Sekunde an und wieder aus geht, also blinkt ein mal.
Wenn etwas empfangen wird was OK ist, blinkt er 2x , mit einem blink-Abstand von 100ms. Wenn aber etwas empfangen wird was nicht OK ist, also BAD CRC, dann blinkt er nur 1x , auch wieder zwischen An/Aus = 1 Sekunde.
So kann man dann halt auch optisch Unterschiede erkennen...
Sollte die LED auch leuchten, wenn ich auf einer 433Mhz Funkfernbedienung rumdrücke?
Nur wenn deine FB genau die selbe Frequenz nutzt, was aber unwahrscheinlich ist da es nicht einfach nur 433 MHz sind sondern der Bereich geht von 433,05 MHz bis 434,79 MHz ...
Und wenn die LED nicht leuchtet, wird wahrscheinlich auch nicht von minicom empfangen, oder?
Minicom hat erst mal nichts mit irgendeinem empfangen zu tun. Ob man über minicom etwas sieht hängt in erster Linie von der korrekten Verkabelung aber auch von der richtigen Baudrate ab, um über UART etwas zu empfangen. Der RFM12B Empfänger empfängt aber unabhängig etwas
Nabend
Also die LED blinkt 1x lang und 2x kurz.
Hab n Video gemacht, finde es jetzt aber nicht mehr bei Youtube...
Danke für die Antworten bzgl. Fernbedinung und minicom
Der ATtiny ist ja in Ordnung, kann es sein, das das Funkmodul defekt ist?
Kolja
edit:
Video wieder gefunden:
Kann ich eigentlich das Sketch auf dem Tiny wieder auslesen?
So, gestern Abend/heute Nacht nochmal von Null angefangen und es funktioniert endlich.
Ich habe nicht die Anleitung aus dem Forum hier benutzt,
aber so wie ich das einschätzen kann, tut sich da nicht viel.
Die Hardware ist exakt gleich.
Es muss irgendwie am Flashen gelegen haben, da mit den "neuen" ATtinys auch die alte Sender und Empfängerplatinen funktionieren.
Hier noch mal der Link zu der o.g. Anleitung:
http://raspberry.tips/hausautomatisi…1-projekt-info/
Vielen Dank für eure Hilfe!
Hier noch mal der Link zu der o.g. Anleitung:
http://raspberry.tips/hausautomatisi…1-projekt-info/
ZitatDie Anleitung basiert auf den Infos von Meingraf und Nathan.
...der kann immer noch nicht meinen Namen richtig schreiben...
So, gestern Abend/heute Nacht nochmal von Null angefangen und es funktioniert endlich.
Ich habe nicht die Anleitung aus dem Forum hier benutzt,
aber so wie ich das einschätzen kann, tut sich da nicht viel.
Die Hardware ist exakt gleich.Es muss irgendwie am Flashen gelegen haben, da mit den "neuen" ATtinys auch die alte Sender und Empfängerplatinen funktionieren.
...
Hi,
ich wärm diesen Thread einfach noch mal auf, um neben falscher Verkabelung und fehlerhafter Programmierung eine weitere Fehlermöglichkeit aufzuzeigen, warum das 'cat /dev/ttyAMA0' nichts anzeigt.
Bei mir war das auch so und als ich auf diesen Thread gestossen bin, hab ich natürlich alle Tips befolgt. Doch es tat sich weiterhin nichts. Dann hab ich schließlich das kurze Progrämmchen aus Beitrag #5 genommen, noch ein LED-Blink mit "delay(500);" eingebaut, geflasht (mit Arduino IDE auf MacOS) - und siehe da: die LED blinkt. Doch am seriellen Port tat sich immer noch nichts.
Alles zum x-ten mal kontrolliert, schien weiterhin ok. Aber dann fiel mir auf, daß die Diode sehr langsam blinkt - statt einer halben Sekunde mindestens zwei! Irgendwie lief wohl alles langsamer ab als programmiert.
Das brachte mich in einem Geistesblitz auf die Idee, daß auch die UART-Baudrate langsamer sein könnte als auf dem Raspi eingestellt. Also mit stty die Baudrate jeweils halbiert und nach ein paar Versuchen ging es mit 'stty 1200 -F /dev/ttyAMA0' tatsächlich: ...Loop... ...Loop... ...!!! :s
Ich hab schon schon einiges gegurgelt und könnte mir vorstellen, daß es an diesen Fuses liegt. Hat jemand von dem hier versammelten geballten Fachwissen eine Idee? Ich bin da wohl in eine böse Anfänger-Falle gelaufen.
Gruß, Jürgen
Puuh,
ich konnte diese Sache doch noch heute lösen, ich hatte schon echte Befürchtungen.
Typischer Anfängerfehler: Flashen des Bootloaders für 8MHz/internal Oscillator vergessen
Bzw. so ganz klar ist mir das noch nicht. Diese Attinys werden wohl mit Fuses für 1MHz ausgeliefert bzw. eventuell auch mit 8 MHz, doch der Takt wird durch 8 geteilt. Doch es sollten wohl trotzdem 9600 Baud möglich sein? Alles sehr merkwürdig, muss wohl doch noch ein wenig Grundlagen durcharbeiten
Jedenfalls läuft die Schleife jetzt mit 9600 Baud, alles im grünen Bereich.
Danke für eure Geduld.
Jürgen
Hallo zusammen,
wenn ich darf, würde ich den Thread auch nochmal gerne aufwärmen mit einem etwas anderen Problem, da dieses hier offenbar gelöst wurde...
Ich habe Empfänger und Sender nach dieser Anleitung gebaut und programmiert.
Die ATTinys sind mit dem RasPi direkt geflasht worden, hat auch alles geklappt, die Testprogramme laufen darauf. Der Sender sendet lediglich eine Testzeichenkette, der Empfänger gibt alles aus, was er empfängt.
Jetzt beginnt das Problem:
Ich bekomme beim Empfänger solche Ausgaben wie diese hier:
BAD-CRC
64
BAD-CRC
0
BAD-CRC
120 0▒▒▒@@▒ 8
pp▒@@`▒p@l▒`@▒x0 ,▒▒▒ ▒@▒
▒pP▒▒x▒ @@`p ▒ ▒p▒▒▒
BAD-CRC
0
BAD-CRC
0
BAD-CRC
24 ▒▒▒p ▒@p▒▒▒
p▒▒▒@▒`@p▒▒<@▒
BAD-CRC
64
BAD-CRC
80 @▒0 ▒@ @`@▒p8 x0
Alles anzeigen
Empfänger hat die NodeID 10, NetworkID 200, der Sender hat die NodeID 21, gleiches Network und Gateway die 10 vom Empfänger...
Die ersten Ziffern, die ausgegeben werden, sind die ID des Senders. Das ist schon verwunderlich, da nie die eigentliche NodeID des Senders ausgeben wird, sondern immer andere. Zwischenzeitlich werden auch Daten empfangen, die nicht vom Sender stammen, vermutlich andere Geräte in der Nähe. Wenn mein Sender aber sendet, erscheint meist die "0" als ID, was ja eigentlich für Broadcast reserviert ist.
Hier auch mal meine Sketches:
Empfänger:
// RFM12B Receiver for RaspberryPI
//
// Basiert zum Teil auf der Arbeit von Nathan Chantrell
//
// modified by meigrafd @ 16.12.2013 - for UART on RaspberryPI
//------------------------------------------------------------------------------
#include <RFM12B.h>
#include <avr/sleep.h>
#include <SoftwareSerial.h>
//------------------------------------------------------------------------------
// You will need to initialize the radio by telling it what ID it has and what network it's on
// The NodeID takes values from 1-127, 0 is reserved for sending broadcast messages (send to all nodes)
// The Network ID takes values from 0-255
// By default the SPI-SS line used is D10 on Atmega328. You can change it by calling .SetCS(pin) where pin can be {8,9,10}
#define NODEID 10 //network ID used for this unit
#define NETWORKID 200 //the network ID we are on
#define ACK_TIME 2000 // # of ms to wait for an ack
#define SERIAL_BAUD 9600
//------------------------------------------------------------------------------
// PIN-Konfiguration
//------------------------------------------------------------------------------
// UART pins
#define rxPin 7 // D7, PA3
#define txPin 3 // pin an den der 433 Mhz Sender angeschlossen ist (D3, PA7)
// LED pin
#define LEDpin 8 // D8, PA2 - set to 0 to disable LED
/*
+-\/-+
VCC 1| |14 GND
(D0) PB0 2| |13 AREF (D10)
(D1) PB1 3| |12 PA1 (D9)
RESET 4| |11 PA2 (D8)
INT0 PWM (D2) PB2 5| |10 PA3 (D7)
PWM (D3) PA7 6| |9 PA4 (D6)
PWM (D4) PA6 7| |8 PA5 (D5) PWM
+----+
*/
//encryption is OPTIONAL
//to enable encryption you will need to:
// - provide a 16-byte encryption KEY (same on all nodes that talk encrypted)
// - to call .Encrypt(KEY) to start en
// - to stop encrypting call .Encrypt(NULL)
//#define KEY "ABCDABCDABCDABCD"
// Initialise UART
SoftwareSerial mySerial(rxPin, txPin);
// Need an instance of the Radio Module
RFM12B radio;
//##############################################################################
static void activityLED (byte mode) {
pinMode(LEDpin, OUTPUT);
digitalWrite(LEDpin, mode);
}
// blink led
static void blink (byte pin, byte n = 3) {
pinMode(pin, OUTPUT);
for (byte i = 0; i < 2 * n; ++i) {
delay(100);
digitalWrite(pin, !digitalRead(pin));
}
}
// init Setup
void setup() {
pinMode(rxPin, INPUT);
pinMode(txPin, OUTPUT);
mySerial.begin(SERIAL_BAUD);
mySerial.println("SETUP RECEIVER");
radio.Initialize(NODEID, RF12_433MHZ, NETWORKID);
// #ifdef KEY
// radio.Encrypt((byte*)KEY); //comment this out to disable encryption
// #endif
if (LEDpin) {
activityLED(1); // LED on
delay(1000);
activityLED(0); // LED off
}
}
// Loop
void loop() {
if (radio.ReceiveComplete()) {
if (radio.CRCPass()) {
//node ID of TX, extracted from RF datapacket. Not transmitted as part of structure
mySerial.print(radio.GetSender(), DEC);
mySerial.print(" ");
int i;
for (byte i = 0; i < *radio.DataLen; i++) //can also use radio.GetDataLen() if you don't like pointers
mySerial.print((char) radio.Data[i]);
if (LEDpin) {
blink(LEDpin, 2);
}
if (radio.ACKRequested()) {
radio.SendACK();
}
} else {
mySerial.println("BAD-CRC");
mySerial.print(radio.GetSender(), DEC);
mySerial.print(" ");
int i;
for (byte i = 0; i < *radio.DataLen; i++) //can also use radio.GetDataLen() if you don't like pointers
mySerial.print((char) radio.Data[i]);
if (LEDpin) {
activityLED(1); // LED on
delay(1000);
activityLED(0); // LED off
}
}
mySerial.println();
}
}
Alles anzeigen
Test-Sender:
// RFM12B Sender for DHT22 Sensor
//
// Basiert zum Teil auf der Arbeit von Nathan Chantrell
//
// modified by meigrafd @ 16.12.2013
//------------------------------------------------------------------------------
#include <RFM12B.h>
#include <avr/sleep.h>
//#include <DHT.h>
//------------------------------------------------------------------------------
// You will need to initialize the radio by telling it what ID it has and what network it's on
// The NodeID takes values from 1-127, 0 is reserved for sending broadcast messages (send to all nodes)
// The Network ID takes values from 0-255
// By default the SPI-SS line used is D10 on Atmega328. You can change it by calling .SetCS(pin) where pin can be {8,9,10}
#define NODEID 21 //network ID used for this unit
#define NETWORKID 200 //the network ID we are on
#define GATEWAYID 10 //the node ID we're sending to
#define ACK_TIME 2000 // # of ms to wait for an ack
#define SENDDELAY 5000 // wait this many ms between sending packets. 300000ms = 5min
#define requestACK false // request ACK? (true/false)
//------------------------------------------------------------------------------
// PIN-Konfiguration
//------------------------------------------------------------------------------
// SENSOR pins
//#define DHT11_PIN 10 // DHT sensor is connected on D10 (ATtiny pin 13)
//#define DHT11_POWER 9 // DHT Power pin is connected on D9 (ATtiny pin 12)
// LED pin
#define LEDpin 8 // D8, PA2 - set to 0 to disable LED
//------------------------------------------------------------------------------
/*
+-\/-+
VCC 1| |14 GND
(D0) PB0 2| |13 AREF (D10)
(D1) PB1 3| |12 PA1 (D9)
RESET 4| |11 PA2 (D8)
INT0 PWM (D2) PB2 5| |10 PA3 (D7)
PWM (D3) PA7 6| |9 PA4 (D6)
PWM (D4) PA6 7| |8 PA5 (D5) PWM
+----+
*/
//encryption is OPTIONAL
//to enable encryption you will need to:
// - provide a 16-byte encryption KEY (same on all nodes that talk encrypted)
// - to call .Encrypt(KEY) to start encrypting
// - to stop encrypting call .Encrypt(NULL)
//#define KEY "ABCDABCDABCDABCD"
// Need an instance of the Radio Module
RFM12B radio;
// Setup the DHT
//DHT myDHT(DHT11_PIN, DHT11);
// Variablen für Temperatur/Luftfeuchtigkeit
//long temp; long humi;
// Temperatur-String zum Versand per 433 Mhz
char msg[26];
//##############################################################################
static void activityLed (byte state, byte time = 0) {
if (LEDpin) {
pinMode(LEDpin, OUTPUT);
if (time == 0) {
digitalWrite(LEDpin, state);
} else {
digitalWrite(LEDpin, state);
delay(time);
digitalWrite(LEDpin, !state);
}
}
}
// blink led
static void blink (byte pin, byte n = 3) {
if (LEDpin) {
pinMode(pin, OUTPUT);
for (byte i = 0; i < 2 * n; ++i) {
delay(100);
digitalWrite(pin, !digitalRead(pin));
}
}
}
// sec since start
static unsigned long now() {
// FIXME 49-day overflow
return millis() / 1000;
}
//--------------------------------------------------------------------------------------------------
// Read current supply voltage (in mV)
//--------------------------------------------------------------------------------------------------
long readVcc() {
bitClear(PRR, PRADC);
ADCSRA |= bit(ADEN); // Enable the ADC
long result;
// Read 1.1V reference against Vcc
#if defined(__AVR_ATtiny84__)
ADMUX = _BV(MUX5) | _BV(MUX0); // For ATtiny84
#else
ADMUX = _BV(REFS0) | _BV(MUX3) | _BV(MUX2) | _BV(MUX1); // For ATmega328
#endif
delay(2); // Wait for Vref to settle
ADCSRA |= _BV(ADSC); // Convert
while (bit_is_set(ADCSRA,ADSC));
result = ADCL;
result |= ADCH<<8;
result = 1126400L / result; // Back-calculate Vcc in mV
ADCSRA &= ~ bit(ADEN);
bitSet(PRR, PRADC); // Disable the ADC to save power
return result;
}
// init Setup
void setup() {
// pinMode(DHT11_POWER, OUTPUT); // set power pin for Sensor to output
// myDHT.begin();
radio.Initialize(NODEID, RF12_433MHZ, NETWORKID);
// #ifdef KEY
// radio.Encrypt((byte*)KEY); //comment this out to disable encryption
// #endif
// configure RFM12B
radio.Control(0xC040); // Adjust low battery voltage to 2.2V
radio.Sleep(); //sleep right away to save power
PRR = bit(PRTIM1); // only keep timer 0 going
analogReference(INTERNAL); // Set the aref to the internal 1.1V reference
ADCSRA &= ~ bit(ADEN); bitSet(PRR, PRADC); // Disable the ADC to save power
activityLed(1,1000); // LED on for 1000ms
}
// Loop
void loop() {
activityLed(1); // LED on
// pinMode(DHT11_POWER, OUTPUT); // set power pin for Sensor to output
// digitalWrite(DHT11_POWER, HIGH); // turn Sensor on
// DHT11_ERROR_t errorCode;
// delay(2500); // Kurzer Delay zur Initialisierung (DHT22 benoetigt mindestens 2 Sekunden fuer Aufwaermphase nach dem Power-On)
// errorCode = myDHT22.readData(); // read data from sensor
// myDHT.read();
// float h = myDHT.readHumidity();
// float t = myDHT.readTemperature();
activityLed(0); // LED off
// if (!isnan(t) && !isnan(h)) { // data is good
// int temp = (myDHT22.getTemperatureC()*100); // Get temperature reading and convert to integer, reversed at receiving end
// int humi = (myDHT22.getHumidity()*100); // Get humidity reading and convert to integer, reversed at receiving end
int vcc = readVcc(); // Get supply voltage
// msg-Variable mit Daten zum Versand fuellen, die spaeter an das WebScript uebergeben werden
//snprintf(msg, 26, "v=%d&t=%d&h=%d", vcc,temp,humi);
strcpy(msg, "1234567890ABCDEFGHIJ12345");
// strcpy(msg,"v=");
// itoa(vcc,&msg[strlen(msg)],10);
// strcat(msg,"&t=");
// itoa(t,&msg[strlen(msg)],10);
// strcat(msg,"&h=");
// itoa(h,&msg[strlen(msg)],10);
radio.Wakeup();
// delay(0);
radio.Send(GATEWAYID, (uint8_t *)msg, strlen(msg), requestACK);
radio.SendWait(2); //wait for RF to finish sending (2=standby mode)
radio.Sleep();
if (LEDpin) {
blink(LEDpin, 2); // blink LED
}
// }
// digitalWrite(DHT11_POWER, LOW); // turn Sensor off to save power
// pinMode(DHT11_POWER, INPUT); // set power pin for Sensor to input before sleeping, saves power
delay(SENDDELAY);
}
Alles anzeigen
Ich verzweifel langsam!:@ Was mache ich falsch??
Gruß, Benny
Hier auch nochmal Fotos von den Schaltungen im Anhang.
Gruß, Benny
necromundo: Hast du dein Problem gelöst? Ich habe auch zwei Sender mit unterschiedlichen NODE ID's und bekomme cryptische Zeichen bei dem DHT22!
Empfänger
#define NODEID 22 //network ID used for this unit
#define NETWORKID 210 //the network ID we are on
DHT22
#define NODEID 1 // network ID used for this unit
#define NETWORKID 210 // the network ID we are on
#define GATEWAYID 22 // the node ID we're sending to[/php]
DS18B20
#define NODEID 2 // RF12 node ID in the range 1-30
#define NETWORKID 210 // RF12 Network group
#define GATEWAYID 22 // the node ID we're sending to
Beide habe ich mit Watchdog Sketch kompiliert! Beide hängen noch an RasPI dran.
necromundo: Hast du dein Problem gelöst? Ich habe auch zwei Sender mit unterschiedlichen NODE ID's und bekomme cryptische Zeichen bei dem DHT22!
Hallo,
nur als Anmerkung: Ich hatte mir vom meigrafd-github
https://github.com/meigrafd/TinyRX4
für meinen DHT22 den Sketch
Send_DHT22_Watchdog.ino
geladen und anfänglich ebenfalls solchen "Müll" erhalten.
Bis ich im Sketch auf Zeile 184 gestoßen bin und diese auskommentiert habe:
radio.Encrypt((byte*)KEY); // comment this out to disable encryption
Vielleicht hilft es....
Tecki-KA: Super :thumbs1: hat funktioniert
Hallo zusammen,
bei mir war das leider nicht der Grund!
Oben in den Sketches sind die entsprechenden Teile vorsorglich komplett auskommentiert, kann also daran nicht liegen! Auch wenn der Datenmüll recht ähnlich aussieht.
Ich bin auch noch nicht weiter bei dem Problem, mir sind die Ideen ausgegangen....
LG, Benny
bei mir war das leider nicht der Grund!
Neben der Verschlüsselung gibt es noch andere Gründe für den Datenmüll:
Baudrate, Anzahl Daten- und Stoppbit sowie Parität. Auch die Spannungspegel der RX- und TX-Signale können durch Jitter solchen Müll erzeugen. Das sind aber Gründe aus der PC-Technik. Bin selbst (noch) zu wenig in der Tiefe der Sketche, um abzuschätzen, wo diese Parameter gesetzt oder auch nicht gesetzt werden. Wenn, dann kann das ja auch eigentlich nur im RasPI eine Falscheinstellung sein.
Siehe Dir dazu mal den Eintrag 52 und 53 in diesem Thema an.
Kurze Anmerkung zur Quelle deiner Bauanleitung:
Der liebe Phillipp S. aus F ist wohl ein recht reproduzierenden Künstler. So stammt meines Erachtens sein gesamter Beitrag "Funksensoren.." im wesentlichen aus diesem Forum "Entwicklung: Temperatur Funk Sensor" von meigrafd. Und da die konsequente Durcharbeitung von inzwischen über 1300 Antwort etwas aufwendig ist, hat sich dort auch der eine oder andere Fehler eingeschlichen.
Das Problem mit dem Datenmüll ist auf Philipps Forum auch zu finden. Die Antworten allerdings eher "dünn".
Dem Forum ist es einfach wichtig, möglichst viele Leute auf seine Seiten zu locken, damit man denen dann möglichst viele Werbe-Cookies um die Ohren hauen kann. Ich empfehle, die Inhalte mit Vorsicht zu genießen.
Meigrafd hat das Thema übrigens auch sehr gut nochmals kondensiert (und fehlerfrei ;))
zusammengestellt:
[Messen, Steuern, Regeln] Batteriebetriebene Funk Sensoren
Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!