Eigenbau Bodenfeuchte-Sensor-433MHz-LaCrosse-TX2/3 mit ATTiny85 (SpinOff)

Begonnen von juergs, 30 Oktober 2016, 19:57:45

Vorheriges Thema - Nächstes Thema

tante ju

Zitat von: ArduPino am 11 November 2016, 18:52:02
Warum überhaupt Kapazitiv ?

Wenn du nur alle 10 Minuten eine Messung durchführst, sollten doch auch zwei Drähte reichen und dann einfach den Widerstand bestimmen.
Mir ist klar, das z.B. diese fertigen China Dinger nicht lange halten und schon nach kurzer Zeit oxidieren und sich praktisch auflösen, wenn aber die Messung nur in so großen Zeitabständen erfolgt, fließt auch kein Strom und die Oxidation sollt damit sehr langsam verlaufen.
Man könnte ja auch z.B. die Kontakte aus Edelstahl machen.

Oder würde das trotzdem zu Problemen führen ?

Das ist immer eine Frage der Sichtweise. Eine Oxydation findet auch ohne Stromfluß statt. Der galvanische Effekt unter Strom kommt noch dazu. Es bilden sich aber auch an den Leitern Doppelschichten, die die Messung massiv beeinflussen können.

ext23

Zitat von: juergs am 12 November 2016, 14:54:08
Ok, auch eine Einstellung.  :)

Aber es gibt ja 1Wire Busmaster + Bus-Treiber-Bausteine etc. ,  das meinte ich mit Infrastruktur.
Naja das man ein Bus Master hat ist ja klar, sonst macht sich ein 1-Wire Bus ja schlecht ;-) Aber nicht das wir aneinander vorbei reden, ich meine sowas: http://www.tm3d.de/index.php/1-wire-device-mit-avr
Und natürlich sollte man aus Kompatibilitätsgründen einen passenden Baustein nachbilden den es gibt. Ein Zähler macht vielleicht nicht so sehr Sinn in dem Fall. Aber wie gesagt das war nur eine Idee mit dem 1-Wire. Flexibler wäre es eine Spannung auszugeben. Die kann man dann mit verschiedenen Komponenten auslesen und an FHEM schicken. Aber mit einem AVR eine definierte Spannung zu generieren ist auch nicht so einfach.

Btw. so ein Chirp habe ich auch der I2C mit drauf hat, aber ich hab kein I2C hier, nur 1-Wire. Die sind aber auch um einiges teurer die Dinger.
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

juergs

@ext23:

ZitatBtw. so ein Chirp habe ich auch der I2C mit drauf hat, aber ich hab kein I2C hier, nur 1-Wire
Dann brauchst Du eigentlich nur ein I2C-1Wire Gateway?

Mal schauen ob das als "Abfall"-Produkt von dem Luftgütesensor entstehen kann ... :)

Gibt es schon, aber für 29.90 € etwas teuer....
R-Pi i2c 1-Wire OWFS Module

Grüße,
Jürgen

juergs


ext23

Zitat von: ext23 am 10 November 2016, 14:37:35
Ich spiele gerade mit dem Giesomatic rum. Der hat aber eine recht hohe Frequenz (bis 500kHz) was mich ein wenig stört. Ist natürlich auch nicht ganz so einfach auszuwerten als ein 555er der ja mehr oder weniger eine Art PWM ausgibt.
/Daniel

Habe ich doch geschrieben oben ;-) Aber wie gesagt der arbeitet mit einer sehr hohen Frequenz, das finde ich aus EMV Gründen nicht so gut. Ansonsten funktioniert der auch ja. Hab ich auch etliche von rumliegen bzw. mir selber geätzt.

/Daniel
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

juergs

ZitatHabe ich doch geschrieben oben ;-)
Ja, konnte aber mit "Giesomatic" bis dato nichts anfangen  ;D

Der 74HC14 ist ja billiger als der 555 und weniger Bauteile ...
Wenn dieser sauber(er) schwingt ... Muß man mal ausprobieren.
Alles in  SMD würde dann schon sehr klein (;-)

Wegen Deinen EMV-Bedenken, sehe ich bei der gerinsten Leistung eher kein Problem, da ist Dein 230V-Netz
eher eine Problem-Quelle oder die Hochspannungs-Überlandmasten, oder ein Amateur-Funker wohnt genau neben Dir ...  :(

Bei mit tut sich endlich etwas, da ich meinen Blumentopf ja unter Wasser gesetzt und den Sketch noch nicht Energie-optimiert hatte,
sieht man jetzt: Die Batterie geht runter und die Feuchte sinkt (Kapazität steigt), aber nicht proportional zur Batterie-Entladung ....
   
Die Erde fühlt sich in den ersten cm doch sehr trocken an, mit etwas Restfeuchte an den Wurzeln ... also bald nachgießen ...
Nachdem ich den NE555 gegen den ICM555 getauscht hatte muss man noch mal messen...
   

locutus

Hallo Jürgen,

ich erhalte mit der ATTiny Core und einer Taktfrequenz von 8 MHz keinen plausiblen Temperaturwert. Einmalig nach dem Einschalten funkt der Sensor die korrekte Temperatur. Danach werden permanent 12,3°C übermittelt.
Verwendest du tatsächlich den Micronucleus 16,5 MHz Bootloader? t85_default oder t85_aggressive?


juergs

Hallo locutus,

schaue heute Mittag detaillierter nach und melde mich ...

Ich habe den Sensor mit einer CR235A Knopfzelle betrieben.
Und habe ebenfalls (noch) das Erfassungsproblem des 18B20.
Der war aber bei mir in den Hintergrund getreten, da ich sowiso viele Temperatursensoren habe  ;)
Der Wert der ausgeben wird, deutet auch auf einen möglichen Fehler in der  Dallas-Erfassung hin.
Habe das Abschalten des Pullups + 18B20-Sensors via FET 2N7002 noch in der Todo-Liste.
Das spart noch mal extra Strom.

Kommt den wenigstens ein Bodenfeuchte-Wert?

Der Micro-Nucleaus-Bootloader kommt nur in Verbindung mit den DigiSpark (mit USB-Anbindung)
zum Tragen.
Aber wie Du schon richtig bemerkt hast, benutze ich, wegen des Stromverbrauchs keine USB-Variante,
sondern programmiere direkt  über ISP auf einen 8p-DIL ATTiny85.
Standardmäßig, auch wegen Batterie-Lebensdauer, benutze ich eigentlich die "normale" interne 8MHz Einstellung.
Bei den Digispark-Teilen muss man sich wieder Gedanken um den Stromverbrauch der zusätzlichen USB-Pullups machen.
Der Micronucleaus-Bootloader-Variante braucht allerdings die 16,5MHz-Einstellung ....
Die unten angegebene Einstellung ist die für die Digispark-Variante.

Der Sensor an sich funktioniert sehr gut!

Jürgen

locutus

Sollte die Verzögerung nicht min. 750 ms lang dauern?
delay(750); // ms, needed for settling DS18B20

Und warum ...
float celsius = 12.3; ...?

Die Bodenfeuchte lasse ich momentan außer Acht. Für Vergleichsmessungen fehlt mir ein Xiaomi oder Parrot Pflanzensensor.

juergs

ZitatFür Vergleichsmessungen ....
Achtung das ist eine Fehlannahme!
Wie TantaJu schon bemerkte, es sind es relative Messungen!
D.h. die Werte wären wahrscheinlich nicht vergleichbar und bewegen sich immer in einem bestimmten Bereich.
Nehme ich zum Bsp. den Sensor aus dem Blumentopf und stecke ihn wieder rein,
verändern sich die Rahmenbedingungen z.B. Nähe zu Wurzeln/Erdzusammensetzung etc., so daß auf ein Absolutwert zu spekulieren
nicht funktioniert.
Bei meinem Blumentopf weiß ich,  wenn der Wert Richtung 30 wandert, die Blume  Pflanze Wasser braucht.  ;)
Beim Nachgiessen sinkt er dann wieder auf 20.

Zitatfloat celsius = 12.3;
Ist nur die Initialisierung der Variable mit einem Dummywert.

ZitatDie Bodenfeuchte lasse ich momentan außer Acht
Worauf zielst Du dann ab?

Wenn es Dir nur auf die Temperatur ankommt:
https://github.com/juergs/ATtiny85_BMP180_DHT_1820_433]Nur DHT + ATtiny85
https://forum.fhem.de/index.php/topic,52755.0.html

Hideki-Protokoll:
https://bitbucket.org/fuzzillogic/433mhzforarduino/wiki/Home

Ansonsten schaue ich heute Nachmittag noch mal auf den Sketch.

Grüße,
Jürgen

locutus

Zitat von: juergs am 29 Januar 2017, 11:25:10
Achtung das ist eine Fehlannahme!
Wie TantaJu schon bemerkte, es sind es relative Messungen!
D.h. die Werte wären wahrscheinlich nicht vergleichbar und bewegen sich immer in einem bestimmten Bereich.
Das ist mir schon bewusst. Ganz abgesehen davon sind an meinem Sensor noch keine Sonden angeschlossen.
Ich komme nochmals auf mein Anliegen zurück. Was muss ich im Sketch ändern, um korrekte Temperaturwerte vom DS18B20 zu erhalten?

juergs

Ich muss erst mein Testsystem  aufbauen, um die Temperaturerfassung nachstellen zu können.
Melde mich wenn ich Erkenntnisse habe.
Evtl. könnte man die OW-Lib tauschen...

Hier eine funktionierende Dallas-OW--Temperaturerfassung-Variante mit 4 Dallas 18B20 Sensoren:
NANO_DS1820_4Fach.ino

Jürgen

juergs

Hallo locutus,
im NANO-Testsystem bekomme ich den Temperaturwert geliefert:
Zitat===============================================
Sensor-ID (Bodenfeuchte): 100
Bodenfeuchte (int)   = 0
Bodenfeuchte (float) = 0.00
Sensor-ID (Batterie): 101
Temperatur(18B20): 19.62
VCC (int) = 4913
VCC (float) = 4.91
===============================================

Feuchte Sensor ist nicht angeschlossen. Kein Powersave-Modus.

Wenn ich mehr Infos über Dein HW-Setup bekommen könnte,
würde ich das in der passenden Konfiguration  testen ...

Die Digispark Tiny85er habe ich noch zu Verfügung, müsste nur
noch auf- bzw. umbauen.

Nano- und ATTiny-Source hier: BodenfeuchteSensor_Nano
Kompiliert mit Arduino IDE 1.6.12.

Grüße,
Jürgen

digispark-diy-the-smallest-usb-arduino


juergs


juergs

Hallo locutus,

sorry hatte das leider zu schnell überlesen:
ZitatEinmalig nach dem Einschalten funkt der Sensor die korrekte Temperatur. Danach werden permanent 12,3°C übermittelt.
Verwendest du tatsächlich den Micronucleus 16,5 MHz Bootloader? t85_default oder t85_aggressive?

Nein, ich programmiere den ATTiny direkt ohne USB zu verwenden.
Die Standardeinstellung (16.5 MHz) mit dem Micronucleus sollte aber eigentlich problemlos gehen ...

Das Problem war damals, dass ich leider keinen 18B20 mehr zur Verfügung hatte und mir das Verhalten damals
auch aufgefallen ist. Allderdings hatte ich der Temperatur nicht so eine hohe Bedeutung zugemessen.
Allerdings könnte ich mir eine Temperaturkompensation schon vorstellen....  ;)

Damals hatte ich auch kein richtiges DSO, um das Aufwachen aus dem Tiefschlaf und das Protokoll zum Sensor hin zu analysieren.
Mit einem analogen Hameg ging das kaum nachzuvollziehen.

Im letzteren Code hatte ich noch einen Umschalter eingebaut, um zwischen Nano und ATTiny umzuschalten, dort funktioniert die Temperaturerfassung,
aber mit etwas höheren Batterieverbrauchswerten, da dort Narcoleptic nicht aktiv ist.

Möglicherweise beißt sich der Powersave mit Ports auf INPUT während der Schlafphase und der Sensor reagiert nicht mehr.

Gruß,
Jürgen