Selbstbau Funkthermometer 433Mhz

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

Vorheriges Thema - Nächstes Thema

juergs

#375
Hallo Gisbert,

wenn Du Dir den Code genauer angeschaut hättest: das Senden von "controller_VCC" ist auskommentiert!
LaCrosse.h = controller_VCC;
LaCrosse.sendHumidity();
LaCrosse.sleep(1);

Sollte das "Problem" beheben... ;-)

//LaCrosse.h = bodenfeuchte/1000; //   controller_VCC;   
//LaCrosse.sendHumidity();
//LaCrosse.sleep(1);        /* 1 second, no power-reduction! */


Das hatte damals natürlich auch seinen Grund, da ich am Herumexperimentieren mit der Batterielaufzeit war.

Aber mal ehrlich, sollte man sich nicht dessen bewusst sein, was man so "programmiert" ?
Copy & Paste von vorgefertigten Sachen ist immer einfacher, als sich einem Problem stellen, oder ?
Außerdem macht es wesentlich mehr Spaß das Problem selbst zu lösen ...  ;D
Asche auf mein Haupt.  :(

Weiterhin viel Spaß mit den CUL_TX-Sensoren,

Grüße,
Jürgen

PS:
Zitatautomatisch alles angelegt wird, aber woher kommt dieses Verhalten?
Welches "Verhalten" meinst Du?

ZitatIch dachte, dass auch die Spannung gemessen und übertragen wird, das scheint aber nicht der Fall zu sein, denn es kommt hierzu nichts in Fhem an
Hast Du gesehen, dass im Code auch eine Serielle Ausgabe in Form einer Leitung (=Pin des ATtinys, Schalter: "USE_SOFT_SERIAL_FOR_DEBUG") integriert ist? Nutze die Möglichkeiten zur Analyse!







Gisbert

ZitatBeim Überfliegen des Sketchs ist mir nur das Messen, nicht aber ein send... aufgefallen. Guck Dir mal die loop an.

Hallo Markus,
hast Recht, ist mir natürlich aufgefallen - ich dachte, dass sich jemand erbarmt und einen Vorschlag macht. Getreu dem Motto, man kann sich ja mal dumm stellen - umgekehrt ist schwieriger ;D.
Dann muss ich wohl oder übel selbst nachdenken und auf die Suche gehen.

Viele​ Grüße​ Gisbert​
Aktuelles FHEM | PROXMOX | Fujitsu Futro S740 | Debian 12 | UniFi | Homematic, VCCU, HMUART | ESP8266 | ATtiny85 | Wasser-, Stromzähler | Wlan-Kamera | SIGNALduino, Flamingo Rauchmelder FA21/22RF | RHASSPY

KölnSolar

 ;D ;D ;D
Du weißt doch(und ich zitiere einfach Jürgen):
ZitatAber mal ehrlich, sollte man sich nicht dessen bewusst sein, was man so "programmiert" ?
Die Wertermittlung ist ja bereits drin. Nun must Du Dir nur das send von T u. das Lacrosse-Protokoll ansehen. Eine neue Id vergeben und die send-function kopieren/anpassen u. schon hast Du die Spannung in FHEM.
wobei Jürgen geschrieben hatte
LaCrosse.h = controller_VCC;
LaCrosse.sendHumidity();
LaCrosse.sleep(1);

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

Gisbert

Hallo Jürgen,

meine Antwort an Markus muss dir sicher merkwürdig vorgekommen sein. Ich hatte schlicht auf dem Handy deine Antwort übersehen.
Ich werde mich näher mit deinem Sketch beschäftigen und versuchen ihn nach meinen Bedürnissen anzupassen.

Fhem legt anscheinend per autocreate ein Device an, sowie einen Logfile und einen Plot in 2 neuen Räumen. Das ist ja nicht weiter schlimm, ich kann es ja nach meinem Bedarf ändern.

Viele​ Grüße​ Gisbert​
Aktuelles FHEM | PROXMOX | Fujitsu Futro S740 | Debian 12 | UniFi | Homematic, VCCU, HMUART | ESP8266 | ATtiny85 | Wasser-, Stromzähler | Wlan-Kamera | SIGNALduino, Flamingo Rauchmelder FA21/22RF | RHASSPY

Gisbert

#379
Hallo Jürgen,

vielen Dank nochmals für den Hinweis auf deinen Code in Github.

Im Code auf der Seite https://github.com/juergs/ATtiny85_433MHz_LaCrosse_Temp steht zu Beginn:
OneWire ds(DALLAS_SENSOR_PIN);
OneWire dallas(DALLAS_SENSOR_PIN);
float ReadSingleOneWireSensor(OneWire ds);


Im Loop wird jedoch nur dies benutzt:
float theta = ReadSingleOneWireSensor(dallas);

Wozu wird zu Beginn des Sketches:
OneWire ds(DALLAS_SENSOR_PIN);
float ReadSingleOneWireSensor(OneWire ds);

benutzt - oder kann das weg?

Viele Grüße Gisbert

Edit:
Im Loop steht auch:
float ReadSingleOneWireSensor(OneWire ds)
Bleibt die Frage, warum die ds und dallas definiert wird.
Aktuelles FHEM | PROXMOX | Fujitsu Futro S740 | Debian 12 | UniFi | Homematic, VCCU, HMUART | ESP8266 | ATtiny85 | Wasser-, Stromzähler | Wlan-Kamera | SIGNALduino, Flamingo Rauchmelder FA21/22RF | RHASSPY

juergs

Hallo Gisbert,
ja da ist wohl eine Instanziierung zu viel.
Vermutlich optimiert der Compiler das weg, wenn nicht verwendet.

Für solche Verbesserungen sind die Issues in Github gedacht.
Das wäre dann für alle ein Hinweis und hilfreich  :)

Grüße
Jürgen

Gisbert

Hallo Jürgen,

vielen Dank für deine Antwort auf Github. Mit dem Sketch werde ich später mal weitermachen.

Hallo Papa Romeo,

was mich im Moment umtreibt, ist die mobile Spannungsversorgung. 2x oder 3x AA wären ideal, aber mein Ziel ist es einige von den 9V-Blocks einzusetzen, die ich mal bei Rauchmeldern mit geliefert bekommen habe. Da diese aber vglw. schwach sind, hatte ich Li-Batterien von Varta dort eingesetzt. Jetzt habe ich etliche von den anderen übrig.

Wie bekomme ich aus 9V-Blocks 3.3 oder 5V zustande (3.3V reicht für den ATtiny85, den FS1000A und Dallas DS18B20 aus), ohne dadurch zuviel vom kostbaren Saft zu verlieren? Bei Aliexpress gibt es dazu kleine Module, aber wie effizient die wirklich sind, kann ich nicht beurteilen.

Hast du einen Vorschlag für mich? Es darf auch eine kleine Schaltung aus Einzelteilen sein, falls dadurch eine effiziente Lösung entsteht.

Viele​ Grüße​ Gisbert​
Aktuelles FHEM | PROXMOX | Fujitsu Futro S740 | Debian 12 | UniFi | Homematic, VCCU, HMUART | ESP8266 | ATtiny85 | Wasser-, Stromzähler | Wlan-Kamera | SIGNALduino, Flamingo Rauchmelder FA21/22RF | RHASSPY


Gisbert

Hallo Jürgen,

ich hab den Stepdown-Wandler aus China bekommen. Äußerlich sehen die Teile völlig identisch zu den Teilen von Reichelt aus und funktionieren bzgl. Spannung sehr gut, d.h. die eingestellte Spannung wird bis zur 3. Nachkommastelle konstant bereit gestellt.

Leider gibt es ein Problem in Zusammenhang mit den vorhandenen 9V-Blöcken (zugegeben nicht die stärksten) und dem Stepdown-Wandler, denn nach 2 Tagen ist ein Block von 9 auf 4 V abgefallen. Bei dieser niedrigen Spannung findet die Regelung auf 3.30V nicht mehr statt.

Ich werde dann mein Glück mit 3x1.5V-Batterien versuchen.

Viele​ Grüße​ Gisbert​
Aktuelles FHEM | PROXMOX | Fujitsu Futro S740 | Debian 12 | UniFi | Homematic, VCCU, HMUART | ESP8266 | ATtiny85 | Wasser-, Stromzähler | Wlan-Kamera | SIGNALduino, Flamingo Rauchmelder FA21/22RF | RHASSPY

Papa Romeo

Zitat von: Gisbert am 13 Februar 2022, 09:41:16
Leider gibt es ein Problem in Zusammenhang mit den vorhandenen 9V-Blöcken (zugegeben nicht die stärksten) und dem Stepdown-Wandler, denn nach 2 Tagen ist ein Block von 9 auf 4 V abgefallen. Bei dieser niedrigen Spannung findet die Regelung auf 3.30V nicht mehr statt.

Hallo Gisbert,

was nutzt du für 9 V Blöcke.

LG
Papa Romeo
...die richtige Lötspitzentemperatur prüft man zwischen Daumen und Zeigefinger.
...überlasse niemals etwas einer Software, das du hardwaremässig erreichen kannst.
...unvorsichtige Elektriker werden schnell zu leitenden Angestellten.
und...never change a running System...no Updates if not necessary

juergs

#385
Ich habe mal überschlägig die die Akkukapazität laut einem Onlinerechner bemüht
Prämisse: 0.1 Watt mal 6000h (ja,  W ist ca 10..100fach zu  hoch ;) ):

Zitat0.1 Watt / 3V3 Volt = 0.03 Ampere
0.03 Ampere * 6000 Stunden = 180 Ah Kapazität
180 Ah * 1.7 Puffer = 306 Ah empfohlene Kapazität (bei 3V3 Volt)

ZitatAA-Primär-Mignonzellen haben meist eine Nennspannung von 1,5 V und eine typische Kapazität von 1200 bis 2300 mAh,
wiederaufladbare Mignon AA Akkus hingegen eine Nennspannung von 1,2 V und eine Kapazität von 1000 bis 2500 mAh.

Also 2,5 Ah im Gegensatz zu den benötigten 306Ah/100.

Um eine lange Batterielebensdauert zu erreichen muss man wirklich an allen "Stellschrauben" drehen.
Stepdown wäre da schon mal am wenigsten dafür geeignet.  :-\ 

Hast Du mal den Stromverbrauch Deiner Schaltung gemessen und gemittelt?
https://forum.fhem.de/index.php/topic,104466.0.html
https://github.com/pemue-git/uAmp_meter

Jürgen

PS: Meine Sensoren werden mit einem 18650 betrieben und halten dann ca. 1/2 Jahr.
Verbesserungspotential ist wohl aber auch nicht zu 100% ausgeschöpft.
Und der verwendete Sensor trägt naturgemäß auch zum Stromverbrauch bei!
Siehe auch mal hier:
Einige Code-Korrekturen und Stomverbrauch im Deep_Sleep-Modus wieder unter 10 MikroAmpere (WDTCSR-Register):
https://forum.fhem.de/index.php/topic,59933.msg611880.html#msg611880

Papa Romeo

Zitat von: juergs am 13 Februar 2022, 12:16:13
Stepdown wäre da schon mal am wenigsten dafür geeignet.  :-\ 

... deswegen eigentlich meine Frage.

LG
Papa Romeo
...die richtige Lötspitzentemperatur prüft man zwischen Daumen und Zeigefinger.
...überlasse niemals etwas einer Software, das du hardwaremässig erreichen kannst.
...unvorsichtige Elektriker werden schnell zu leitenden Angestellten.
und...never change a running System...no Updates if not necessary

Gisbert

Hallo Jürgen und Papa Romeo,

ich hatte nur den Stepdown-Wandler am 9V-Block dran, nicht den ATtiny85.

Der 9V-Block ist zugegebenermaßen Schrott (Zhongyin (Ningbo) Battery Co., Ltd., PAIRDEER Super Heavy Duty). Er kam mit Flamingo Rauchmeldern mit. Ich hab dann bei den Rauchmeldern Varta Li-Batterien eingesetzt, so dass ich noch etliche unbenutzte, in Folie eingepackte Batterien übrig hatte.

Viele Grüße​ Gisbert​
Aktuelles FHEM | PROXMOX | Fujitsu Futro S740 | Debian 12 | UniFi | Homematic, VCCU, HMUART | ESP8266 | ATtiny85 | Wasser-, Stromzähler | Wlan-Kamera | SIGNALduino, Flamingo Rauchmelder FA21/22RF | RHASSPY

DerD

#388
Hallo, bin ich mit Frage zur aktuellen Software hier auch richtig?

Zuerst hierzu:

void calc_checksum(){
  //                n0   n1   n2   n3   n4   n5   n6   n7   n8
  //                1    5    4    14   8    0    0    4    8
  // 154E800480  = 0001 0101 0100 1110 1000 0000 0000 0100 1000
  // reverse all = 1000 1010 0010 0111 0001 0000 0000 0010 0001


Was hat es denn mit der 154E800480 auf sich, oder ist das nur ein Beispiel?
Was ist denn das für ein reverse? Sollte "1" nicht eigentlich "E" werden, wenn "5" => "A"?

Eigentlicher Grund für mich den Code zu studieren war die Beschreibung des W044 Protokolls hier https://github.com/merbanan/rtl_433/blob/master/src/devices/alecto.c, bei dem ich nicht klar kam wie er gebildet wird. Laut Code hier ist es aber einfach (0xf - n0 - n1 - n2 - n3 - n4 - n5 - n6 - n7) & 0xF.

Zum Thema Energiesparen gibt es übrigens auch tatsächlich eine Norm: ISO/IEC DIS 14543-3-10 (Wireless Short-Packet protocol optimized for energy harvesting). Ich kenne deren Inhalt zwar nicht, bin aber im Rahmen meiner Suche zum Thema Prüfsummen darauf gestoßen, weil im EnOcean protokoll verwendet.
Gruß,
Dieter

Ralf9

Bei reverse wird die Reihenfolge der Bits umgedreht
z.B.
aus
3210
1000
wird
0123
0001

Das W044/W155 Protokoll ist bereits im 14_CUL_TCM97001.pm eingebaut
https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/14_CUL_TCM97001.pm#L982
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7