Selbstbau Funkthermometer 433Mhz

[juergs]

Wenn man verschiedene Version implementiert hat,
muss man doch genauer in die Code-Kommentare schauen:

Bei meiner DHT22-Version habe ich u.A. folgende Fuse-Einstellungen für den ATtiny mit 16MHz Taktrate genommen:
http://www.netz39.de/2014/attiny85-with-16mhz/
https://www.hackster.io/porrey/attiny-16mhz-610d41

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

Das erklärt vielleicht den Unterschied der Timings zwischen Leonardo (16Mhz)  und ATtiny (16MHz oder 8MHz).
D.h. wenn 16MHz vom Timing gefordert waren, ist die 8 MHz-Einstellung natürlich nicht unbbedingt die Richtige (aber *)!
Das richtige Timing ließe sich aber mit einem LA oder Oszi schnell nachprüfen. (siehe LaCrosse-Protokoll)

Die Angaben stehen allerdings auch im Code zum Nachlesen!

(*) Dennoch: die Funktion "delayMicroseconds" sollte eigenlich unabhängig von der Taktrate sein und
somit mit allen möglichen Taktraten-Einstellungen funktionieren.

Grüße,
Jürgen

[juergs]

Da das Projekt für BMP180 + DHT22 + DS18B20 etwas aufwändiger (spezifische ATtiny-I2C-Anbindung) wird,
hier mal in der Zwischenzeit etwas Orientierungshilfe:

1. Arduino Collection: X10 Wireless Temperature Transmitter
http://brohogan.blogspot.de/2009/05/x10-wireless-temperature-transmitter.html
Battery-Life-Time-Calculation
2. The Compleat ATtiny13 LED Flasher: Part 3 - Low Power Mode - Brownsofa
http://brownsofa.org/blog/2011/01/09/the-compleat-attiny13-led-flasher-part-3-low-power-mode/
3. Reduce ATtiny power consumption by sleeping with the Watchdog Timer « insideGadgets
http://www.insidegadgets.com/2011/02/05/reduce-attiny-power-consumption-by-sleeping-with-the-watchdog-timer/
4. Google Code Archive - ATTiny-TWI-Library.
https://code.google.com/archive/p/arduino-tiny/
5. X10 Remote Temp Sch.png (PNG-Grafik, 1350 × 1032 Pixel)
https://dl.dropboxusercontent.com/u/3572198/Blog%20Files/X10%20Remote%20Temp%20Sch.png
6. Alternative I2C-Lib
http://www.eevblog.com/forum/microcontrollers/good-usi-i2c-master-slave-attiny85-library-(optionally-master-arbitration-)/
7. I2C
http://www.instructables.com/id/Mini-weather-station-with-Attiny85/
8. ATtiny85 support
http://highlowtech.org/?p=1695
9. Manchester
http://www.instructables.com/id/Receiving-and-sending-data-between-Attiny85/
http://www.instructables.com/id/Attiny85-RF-Transmitter-to-Arduino-Uno-Receiver-Ma/?utm_source=base&utm_medium=related-instructables&utm_campaign=related_test
http://www.instructables.com/id/Mini-weather-station-with-Attiny85/
http://www.instructables.com/id/Reading-the-BMP180-Pressure-Sensor-With-an-Attiny8/


Anmerkung: Bin selbst überrascht, dass die Portierung Leonardo -> ATtiny sich doch etwas aufwändiger gestaltet.

Anbei der ATtiny85-Vorabsketch mit BMP180 + DHT22 + VCC-Reading für eigene Experimente. 
Fensterkontakt + DS18B20 fehlen noch. Mal schauen, ob dann alles noch ins Flash passt ?

[rippi46]

Habe leider immer noch das Problem, dass z.B. die Batterispannung bei der Temperatur auftaucht, obwohl ich die ID gewechselt habe.

Wird die ID nicht zusammen mit den Temperatur und Luftfeuchtigkeitswerten versendet?

hier mein Sketch mit Fensterkontakt und Interrupt.

Gruß rippi

PS: Leider konnte ich deinen Sketch noch nicht testen. Muss jetzt grillen.

[juergs]

Hi,
habe etwas aufgeräumt.

Als Hinweis: den Code modular aufbauen:

• In Arduino Loop muss die Funktionalität ersichtlich sein und  so wenig Low-Level-Code wie möglich dort unterbringen.
• In Loop immer in Funktionen Ergebnisse holen und in Loop weiter verarbeiten. Entweder wieder in Funktionen oder auch dort, wenn's übersichtlich bleibt.
• Den Interrupt-Code habe ich entsorgt, da ich der Meinung bin: hier nicht erforderlich! Die Wiederholungsrate in loop ist dafür völlig ausreichend. Es sei denn, das Fenster bewegt sich im uS/mS-Takt 

Das Ganze dient der Übersichtlichkeit, weil ich glaube, Du hast den Überblick verloren, wo Du was setzt.
Also habe ich versucht das Ganze etwas aufzuräumen und die Funktionalität an der richtigen Stelle zu bearbeiten. 
Das schont bei zunehmender Komplexität die Nerven...

Das Protokoll sendet ja TEMP und HUM unter der gleichen ID=109.
TEMP ist der DALLAS-18B20-Sensor
HUM ist bei Dir ja der Fensterkontakt mit den zwei Zuständen "0.0" und "100.0".
VCC wird noch als Temperatur mit der ID=111 gesendet.

Ich vermute, daß FHEM die ID/Sensor-Reihenfolge logisch in aufsteigender Reihenfolge erwartet.
Vermutlich machen das die kommerziellen Sensoren auch so.

Das Umbiegen der Bezeichnung machst Du ja dann in FHEM.

Leider hatte ich keine Zeit mehr zu Testen, weil mit meiner IDE-Version der Compile zwar durchgeht,
aber einige Low-Level-Libs noch mit Mehrfach-Deklartionen dazwischenfunken. (Arduino-Version?)

Also für eine endgültige Version noch etwas Geduld.

Grüße,
Jürgen

[rippi46]

Hallo juergs,

ich bin jetzt endlich dazu gekommen deine Version zu testen.
Im Prinzip funktioniert der Temperatursensor mit Fensterkontakt und Batterieanzeige.
Bei der Berechnung wird schon der Wert in mV zurückgegeben, deswegen kann die Berechnung außerhalb der read_vcc weggelassen werden.

Der Wert der Batterieanzeige taucht dann nach dem ersten Aufwachen bei der Temperatur des Temperatursensors auf.
Es sieht so aus, als ob im Puffer noch der Wert der Batterieanzeige steht. Also beim Übertragen der Temperatur steht der aktuelle Wert des Temperatursensors noch nicht zur Verfügung.

Wenn ich mehrfach den Wert des Temperatursensor vor dem Senden der Temperatur auslese, wird der richtige Wert übergeben.

Vielleicht hast du ja noch eine Idee?

Trotzdem Danke für deine Unterstützung.


Gruß rippi

[juergs]

Achtung: Lacrosse erwartet ein Float-Datentyp als Temperatur
und ein Long lässt sich zwar implizit als Float darstellen, aber die max. Stellenanzahl für
das Protokoll wird bei VCC als Millivolt überschritten.
Deshalb die Umrechnung in Volt mit Nachkommastellen!

[rippi46]

Hallo juergs,

habe natürlich den wert noch durch 100 geteilt bevor ich ihn übergeben habe.

Hier mal ein Bild vom ersten Prototyp.

[juergs]

Cool + nicht schlecht!   

Da würde sich die ganze Sache in SMD anbieten:
Sender 433MHZ-STX882 + Sensor DALLAS-DS1620S und ATTiny.

Was für eine Batterie und Gehäuse hast Du ausgewählt?

Grüße,
Jürgen

[rippi46]

Das ganze habe ich auf einer Lochrasterplatine aufgebaut. Als Batterie verwende ich momentan eine AAA 1,5V.
mit einem DC-DC Step Up Boost Module 3v3 versorge ich dann die ganze Schaltung.

Das Gehäuse ist von einem Homematik Fenstersensor (optisch). Dieser passt von der Breite auch in den Rahmen meiner normalen Fenster.
In SMD-Technik würde das Ganze natürlich besser in das Gehäuse passen.
In der endgültigen Version verschwinden nätürlich die Kabel und der Reedkontakt kommt mit ins Gehäuse.

Aber das ist erst einmal der Anfang.

Ich habe die Interruptroutine für den Fensterkontakt momentan noch drin, da an den Fenstern Velux-Rollläden sind und ich mitbekommen will,
wenn meine Kinder gerade das Fenster öffnen.


Gruß rippi

[juergs]

Da bin ich mal auf die Laufzeit gespannt.
1.5Volt + StepUp .... Grübel + Stirnrunzel. 

[rippi46]

Ich auch

[ArduPino]

Habe auch noch immer das Problem mit der Batteriespannung.
Ich habe allerdings nicht den code hier verwendet, sondern hatte das ja schon auf meinem Digispark (Attiny85) am laufen.
Ist aber das gleiche vermute ich mal.

Ich lasse zuerst Temp. und Hum. senden.
Warte 200 Millisekunden, gebe dann t=0.0 einen Festwert (nur zum testen) lasse den senden und dann gebe ich t=Spannung.
t=0.0 ist zur Fenster Erkennung. Das habe ich mit einem Poti mal schnell getestet. 0 = Fenster zu, 50 = gekippt, 100 = auf. Läuft !
Nur die Spannungsmessung funktioniert nur ein mal.
Ich erhalte z.B. 4.1V (keine Ahnung warum das am USB Port so niedrig ist), das wird auch so in FHEM angezeigt. Danach bleibt der Wert auf 1.0
Setze ich das fest t=4.875 wird mir in FHEM schön 4.8 angezeigt und zwar immer.

Also muss da irgend was mit der Spannungsmessung nicht funktionieren. Habe schon mehrere delay eingebaut um das ganze etwas zu verlangsamen.
Am senden kann es nicht liegen, sonst wäre der feste Wert auch falsch und den habe ich extra mal mit 3 Nachkommastellen getestet.
Die Spannungsausgabe laut Serial.Print ist nur zweistellig nach dem Komma.

Weiß echt nicht was da falsch sein könnte.

Code Auswählen Erweitern


delay(200);
 
  int t2 = analogRead(analogpin);   // Widerstand / Fensterkontakt an Sensor xxx+1
  //t2 = map(t2, 0, 1023, 0, 100);
  t_old = t;  // alte Temperatur speichern um falsche Werte zu vermeiden
  t=0.0;  // zum testen Fenster zu
 
  SENSORID = SENSORID_A;    //übergeben der neuen Sensor ID 112
  sendTemperature();
  delay(500);
 
  // Spannung an Sensor xxx+2
  SENSORID = SENSORID_B;   //übergeben der neuen Sensor ID 113
  t=decimalVcc; //4.88 ;
  sendTemperature();

  t = t_old;       // alter Wert zurück, um Fehlanzeigen zu vermeiden
  SENSORID = SENSORID_ID;   //übergeben der haupt Sensor ID 111


Vermute mal das da irgend was mit den Variablen nicht funktioniert. Die Spannung verwendet double t und t_old float
Werde das mal gleich setzen, mal sehen was dann passiert.

EDIT: War ja klar, kaum den Beitrag geschrieben, schon den Fehler gefunden...war ja vorher nur Stunden da dran 
In der system_sleep() routine habe ich die Analog-Digital Converter aus geschaltet. Das geht anscheinend, solange keine Spannungen gemessen werden 

sbi(ADCSRA,ADEN);

schaltet diese wieder ein. Dann funktioniert das auch !

[ArduPino]

Hier mal ein Bild vom ersten Prototyp.

Das Batteriesymbol habe ich auch, ein dummy angelegt, Icons mit devStateIcon gesetzt für low und high und dann ein DOIF angelegt mit

Code Auswählen Erweitern

define di_Batterie1 DOIF ([CUL_TX_113:temperature] <3.0) (set Batterie1 low) DOELSE (set Batterie1 high)


Ok so ? Funktioniert auf jeden Fall
Aber wie bekommt man denn mehrere Werte in eine Zeile ? Habe jetzt alles getrennt.
Wobei das für das Webinterface eigentlich nicht soooo wichtig ist. Auf jeden Fall möchte ich dieses TabletUI verwenden und dann auch ein Tablet an die Wand hängen...schön alles auf einen Blick, mit Wetter, Unwetterwarnung, Fenster auf/zu, Temp. /Hum / Batterie , Müllkalender...und ein oder zwei Funksteckdosen...falls mal eine nicht so schaltet wie FHEM (oder ich) das will...also eigentlich ganz einfach
Was bedeutet denn die -85 ? Luftfeuchtigkeit ?

[rippi46]

Hallo ArduPino,

habe das ganze mit readingsGroup gemacht.

Die -85 kommt von Empfangsqualität RSSI. Das sind ca. 13m durch 3 geschlossene Türen.
Da der Tranceiver nur mit 3,3V betrieben wird finde ich das eigentlich ganz ok.

Ich sende nicht 3,3 über die Temperatur sondern eine 10er Potenz höher, und mache die Umwandlung dann in fhem.

Gruß rippi

[KölnSolar]

Hallo Jürgen,
hast Dich ja seit Mai mächtig ins Zeug gelegt. Ich hab nun auch meinen ersten 85er flashen können  Das war schon extrem nervenaufreibend:
https://forum.fhem.de/index.php/topic,58746.0.html
Leider hab ich aber noch kein Funkmodul. Welches nutzt Du eigentlich ? RFM12B ? Ich wird es vielleicht mal mit einem Hideki-Sender aus einem Wettersensor probieren. Kann es gar nicht erwarten meinen stromsparenden, selbstgebauten "Post-ist-da-Taster" mit Deinem (dann endgültigen ?) Sketch fertigzustellen. Ahh noch ne Frage: wenn im Sketch die Pins angegeben werden, so ist das immer die PBX-Nr. oder ? Ich würd dann 3 und 4 nehmen.
Grüße Markus