FHEM Forum

hier die Beta-Version mit Arduino Leonardo.
Der BMP180 ist über I2C-Standardbelegung am Leonardo angeschlossen. Der 433MHz-Sender an Port D7.
Er sendet Temperatur und Luftdruck über ID=120. Hex-File ist im Zip enthalten.
Die ATtiny-Version folgt noch.
Da der Luftdruck das LaCrosse-Protokoll etwas überfordert, ziehe ich 1000 mBar vom angezeigten Wert ab.
Die Korrektur zurück, kann in der GPlot-Definition erstellt werden.
https://forum.fhem.de/index.php?topic=24985.0 (https://forum.fhem.de/index.php?topic=24985.0)

Aktuelle Implementierung:
http://www.f6fbb.org/domo/sensors/tx3_th.php (http://www.f6fbb.org/domo/sensors/tx3_th.php)

Angestrebt:
http://f6fbb.org/domo/sensors/ws7000_20.php (http://f6fbb.org/domo/sensors/ws7000_20.php)

Neueste und aktuelle SW-Version (https://forum.fhem.de/index.php?action=dlattach;topic=56660.0;attach=56699)

Zur Verwendung mit 433MHz-CUL.

Siehe auch hier diese Version mit dem Dallas 18B20:
Selbstbau Funkthermometer (https://forum.fhem.de/index.php/topic,52755.msg446298.html#msg446298)

Eine mögliche Platine, zum "umfunktionieren":
Bodenfeuchte mit 433-Sender (https://forum.fhem.de/index.php/topic,59933.msg599637.html#msg599637)

Jürgen

Der heutige Plot, ohne Korrektur:

habe mal nach "ReadingsVal" gesucht:
https://forum.fhem.de/index.php/topic,16036.msg104196.html#msg104196 (https://forum.fhem.de/index.php/topic,16036.msg104196.html#msg104196)

Zitatdefine Temp_AZ dummy
define n_Temp_AZ notify Heiz_AZ_ClimRT_tr:measured-temp.* { fhem("set Temp_AZ ".(ReadingsVal('Heiz_AZ_ClimRT_tr','measured-temp', '10') - 2) ) }

Aber komme auf keinen grünen Zweig. Sorry, bin kein PERL-Ab-Taucher  :-[

Zitatdefine CUL_TX_120 CUL_TX 120
attr CUL_TX_120 room CUL_TX,Plots_OK
define FileLog_CUL_TX_120 FileLog ./log/CUL_TX_120-%Y.log CUL_TX_120
attr FileLog_CUL_TX_120 logtype temp4hum4:Temp/Hum,text
attr FileLog_CUL_TX_120 room CUL_TX
#attr CUL_TX_120 userReadings CUL_TX_120.humidity {ReadingsVal("CUL_TX_120.humidity","Luftdruck", 0)+1000}
define SVG_CUL_TX_120 SVG FileLog_CUL_TX_120:SVG_CUL_TX_120:CURRENT
attr SVG_CUL_TX_120 label "CUL_TX_120 [BMP180] Min $data{min1}, Max $data{max1}, Last $data{currval1}"
attr SVG_CUL_TX_120 room Plots,Plots_OK

Hier das gplot:
# Created by FHEM/98_SVG.pm, 2016-08-15 21:05:29
set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set title '<L1>'
set ytics nomirror
set y2tics
set grid y2tics
set ylabel "Luftdruck"
set y2label "Temperatur in C"

#FileLog_CUL_TX_120 4:CUL_TX_120.temperature\x3a:10:
#FileLog_CUL_TX_120 4:CUL_TX_120.humidity\x3a:50:

plot "<IN>" using 1:2 axes x1y2 title 'Temperatur' ls l0 lw 1.5 with lines,\
     "<IN>" using 1:2 axes x1y1 title 'Luftdruck' ls l2 lw 1.5 with lines

Hat jemand eine hilfreiche Idee?

probier's mal damit:
attr CUL_TX_120 userReadings CUL_TX_120.humidity { ReadingsVal("CUL_TX_120.humidity","Luftdruck", 0)+1000[b];;[/b] }

Gruß PeMue

Danke, Peter,

jetzt ist mir der Weg klar.

"CUL_TX_120.humidity" steht jetzt auf dem Wert 1000.

Probiere mal "humidity" als Eingangswert ....

Zitatattr CUL_TX_120 userReadings CUL_TX_120.humidity { ReadingsVal("CUL_TX_120.humidity","Luftdruck", 0)+1000;;}

dann:

Zitatattr CUL_TX_120 userReadings CUL_TX_120.humidity { ReadingsVal("humidity","Luftdruck", 0)+1000;;}

dann:

Zitatattr CUL_TX_120 userReadings humidity { ReadingsVal("humidity","Luftdruck", 0)+1000;;}

Die 1000 kommen jetzt ohne Perl-Fehler, müssten aber 1003.0 sein. Irgendwie fehlt der der Eingangswert bei der Addition.

Momentan reicht mir aber die Tendenz ohne Absolutwerte schon aus, probiere morgen weiter.

https://forum.fhem.de/index.php?topic=19619.0 (https://forum.fhem.de/index.php?topic=19619.0)

Hier die Definition von ReadingsVal (nach langem Suchen gefunden):
#ReadingsVal (http://www.fhemwiki.de/wiki/DevelopmentModuleAPI#ReadingsVal)

Daten abfragen/auslesen:
***********
ReadingsVal
***********
   
$value = ReadingsVal($name, $reading, $default)

Die Funktion ReadingsVal() gibt den inhaltlichen Wert des Readings $reading der Definition $name zurück. Sollte das gewünschte Reading nicht existieren, wird $default zurückgegeben.

Parameter:
==========
$name     (mandatory) Der Definitions-Namen aus dem das gewünschte Reading ausgelesen werden soll.
$reading  (mandatory) Der Name des Readings welcher ausgelesen werden soll.
$default  (mandatory) Der Standardwert der zurückgegeben werden soll, sofern das Reading nicht existiert. (can be undef)


Rückgabewert:
=============
Rückgabe Bedeutung
$value Inhalt des gewünschten Readings oder $default, wenn es nicht existiert.

Ich bin zwar selbst blutiger Anfänger, aber probier mal folgendes (ungetestet)

attr CUL_TX_120 userReadings humidity_corr[s].*[/s] { ReadingsVal("CUL_TX_120","humidity", 0)+1000.0;;}

Edit: das ".*" Brauchst du, glaub ich, nicht.

Hallo Lucky2K12,

war nicht @home, deshalb kann ich erst jetzt weiterprobieren:
1.Versuch:
CUL_TX_120.humidity { ReadingsVal("Luftdruck","humidity", 0)+1000;}
CUL_TX_120.humidity 1000 2016-08-17 21:21:50
CUL_TX_120.press  1000 2016-08-16 21:44:47
humidity 00.9 2016-08-17 19:08:29
state T: 23.6 H: 00.9 2016-08-17 21:21:50
temperature 23.6 2016-08-17 21:21:50

Unglücklicherweise dümpelt der Luftdruck gerade bei 1000 hPa herum.  :(

Den 2. Versuch, wenn wir wieder mit einen Integer über 1000 hPa sind ... :

Zitatattr CUL_TX_120 userReadings humidity_corr.* { ReadingsVal("CUL_TX_120","humidity", 0)+1000.0;;}

Mein eigentlicher Fehler war die Interpretation der ReadingsVal-Parameter, genau falsch herum ...
Vielleicht liegt es auch daran, keine virtuelle Meßstelle sondern eine Reale zu überschreiben ?

Die Definition dafür war aber auch etwas, sagen wir mal "schwer" zu finden...

Die Aussagen zu den Anfragen mit "ReadingsVal" immer recht kurz u. knapp gehalten. (Perl eben ... )
Anmerkung: Nein, will nicht lästern ....  ;D

Jürgen

Hier zum 1.Versuch, nach "shutdown restart".
Ich warte die Ergebnisse morgen ab.... und hoffe, dass es nicht bei 1000 bleibt.
Es soll ja ein Tiefdruckgebiet in Anmarsch sein ...  ;)

Hast du in deinen Plots das neue userreading humidity_corr dargestellt oder eins von deinen vorher angelegten?
Die oben angegebenen Definitionen laufen ins leere, denn die Devices humidity und CUL...humidity gibt's nicht.
Dann wird (vermutlich) der Defaultwert, den du mit 0 angegeben hast genommen und 1000 draufgezählt. 0+1000 bleibt 1000, egal wie der Luftdruck sich entwickelt.
Übrigens apropos Tief: Falls er dann mal unter 1000 fällt, müsste dein Reading negativ werden. Geht schlecht bei einem unsigned int  :o

Die userreadings sind in der commandref schon ein bisschen versteckt, da muss ich dir Recht geben.  :P

userReadings
... Jede Definition hat folgendes Format:  <reading>[:<trigger>] [<modifier>] { <perl code> }
...
Beispiele:  attr myEnergyMeter userReadings energy { ReadingsVal("myEnergyMeter","counters.A",0)/1250.0;; }

also
attr Devicename userReadings
  neuesReading {ReadingsVal("Devicename","altesReading",Defaultwert)+Offsetwert;;}

Das wird dann bei jedem Event aktualisiert, wenn man keinen Trigger angibt. Der Trigger könnte bei dir dann auch :humidity.* lauten, dann würde es nur bei einer Änderung des readings humidity neu berechnet, soweit ich das verstanden habe.

Hallo Lucky2K12,

ZitatGeht schlecht bei einem unsigned int 

worauf bezog sich das?
Habe deshalb auch nochmal nachgeprüft:

ZitatTemp.: 23.6 Druck: 998.86

Oho! Liefert leider:

ZitatSTATE T: 23.6 H: 00.7

Da muss ich mir noch mal  Source + Protokoll anschauen.
Evtl. ist es besser auf  dieses Protokoll zu gehen: "Protocol of the Lacrosse WS7000-20 meteo sensor".
Die machen da den Trick, dass sie noch 200 hPa dazudaddieren um in jedem Fall positiv zu bleiben....
Mit offset von + offset 200 hPa:
[temp] 25.5 deg - [hygro] 49.6 % - [press] 794 hPa (+ offset 200 hPa)

Also nur 800 hPA statt 1000 hPa subtrahieren, dann bleibt das Ergebnis positiv.

Wenn die Werte richtig durchkommen, schaue ich wieder auf die readings.

Danke für den Hinweis + Grüße
Jürgen

Hier noch das jetzt endlich funktionierende ReadingsVal:
:) :) :)

attr CUL_TX_120 userReadings CUL_TX_120.press { ReadingsVal("CUL_TX_120","humidity", 0)+800;;}

mit:

CUL_TX_120.press	=	neue "virtuelle" Messtelle
CUL_TX_120	=	das Device
humidity	=	reale Meßstelle (Besonderheit: steht im Log, nicht in der Definition)

hier die richtige Stelle im Wiki: #ReadingsVal (http://www.fhemwiki.de/wiki/DevelopmentModuleAPI#ReadingsVal)
oder Creating_Plots (http://www.fhemwiki.de/wiki/Creating_Plots)

Mit dieser Defintion:

define CUL_TX_120 CUL_TX 120
attr CUL_TX_120 room CUL_TX,Plots_OK
define FileLog_CUL_TX_120 FileLog ./log/CUL_TX_120-%Y.log CUL_TX_120
attr FileLog_CUL_TX_120 logtype temp4hum4:Temp/Hum,text
attr FileLog_CUL_TX_120 room CUL_TX

temperature und humidity stehen im Logfile und werden wohl von der FHEM-LaCrosse-Verarbeitung so geliefert.
Für diese Messung, Rohwerte über die serielle Schnittstelle (ohne Subtraktion von 800 hPA für Sende-Protokoll):

Temp.: 23.6 Druck: 998.99

Sorry, es stimmt also das Sende-Protokoll noch nicht für Werte unter 1000 hPa. Checke das nochmal durch,
nachdem mir das Wetter den Gefallen des falldenden Luftdruckes getan hat (;-))

Vielleicht wäre es auch sinnvoller, dann gleich dieses Protokoll zu implementieren ...
http://f6fbb.org/domo/sensors/ws7000_20.php (http://f6fbb.org/domo/sensors/ws7000_20.php) und die Luftfeuchte gleich noch mitzuliefern (DHT).
Beispiel:

Zitat[temp] 25.5 deg - [hygro] 49.6 % - [press] 794 hPa (+ offset 200 hPa)

Super, dass sieht doch schon viel besser aus  8)
Jetzt muss nur noch das "pressure" reading übermittelt werden, dann musst du den Luftdruck nicht mehr aus der Feuchtigkeit berechnen ;D

Danke! So sieht's aus.  8)  für ein schnelles Sonntags-Spät-Abends-Projekt ...
... und draußen regnet es ...

rtl_433 (https://github.com/merbanan/rtl_433/tree/master/src/devices)
TX29 (http://fredboboss.free.fr/articles/tx29.php/)
Decodage-capteur-thermo-hygro-TFA (http://www.jacquet80.eu/blog/post/2011/10/Decodage-capteur-thermo-hygro-TFA)
Dekodieren (http://bertrik.sikken.nl/433mhz/index.html)

Zitat von: juergs am 18 August 2016, 19:32:48
worauf bezog sich das?

Hallo Jürgen,
das mit dem unsigned int bezog sich auf eine potenzielle Fehlermöglichkeit, (da fehlt ein z.B.). Ist wohl eine Berufskrankheit, immer Fehlermöglichkeiten im Hinterkopf zu haben  ;D

In deinem Code verwendest du ja float, aber in den diversen Codeschnipseln wird auch viel int verwendet, ich hab mich da nicht im einzelnen durchgewühlt...

Aber die Idee war gar nicht so schlecht.

Das Protokoll sendet ja Tem + HUM in separaten Telegrammen in fünf BCD-Digits verklausuliert.
Wovon 3 davon der informative Anteil sind und die restlichen 2 Digits eine Wiederholung der ersten 2 sind.
Also sollten 3 BCD-Digits zur Übertragung zur Verfügung stehen. Nur Negative Werte müssen vermieden werden.
Interessanterweise werden zur Temperatur 50 Grad hinzuaddiert, um positiv zu bleiben.  ;)

http://forum.arduino.cc/index.php?topic=155483.0 (http://forum.arduino.cc/index.php?topic=155483.0)

Das TX3-Protokoll kann nur 2-Stellige Werte + 1 Nachkomma-Stelle übermitteln.
bei Offset 800:
H=199.9600219726 TENS=19 ONES=9 TENTHS=9
nible1=0 nible2=1010 nible3=1110 nible4=1111 nible5=0
tens     = 19 10011
ONES     = 9
TENTHS   = 9
CheckSum = 8

bei Offset 1000:

Temp.: 24.4 Druck: 1000.44 Druck[corr]: 0.44
h=0.4400024414
nible1=0 nible2=1010 nible3=0 nible4=1111 nible5=1
tens     = 7 111
ONES     = 4
TENTHS   = 4
CheckSum = 4


Momentan kenne ich nur die LaCrosse-Gerätetypen 0x00 = Temperatur und 0xEF für Luftfeuchte.

Eine Methode ist:
Eine BCD-Stelle nach rechts schieben: 800 subtrahieren und durch 10 teilen.

Beispiel:
Sensor-seitig: 998.5 hPa => (998.5 - 800)/10 = 19.85 ==> FHEM-seitig: (19.85 *10)+800 = 998,5

CUL_TX_120.press { ReadingsVal("CUL_TX_120","humidity", 0)*10+800;}

Minimalwert wäre dann 800 hPa. Doch besser mit 700er Offset...

FHEM-userReadings-Attribut:
CUL_TX_120.press { ReadingsVal("CUL_TX_120","humidity", 0)*10+700;}

ZitatTemp.: 24.6 Druck: 1000.48 Druck[corr]: 30.05

Anbei der Code V2 mit 700 als Offset und ergänzter LaCrosse-Instanz mit LaCrosseClass::CalcPress() .

Statt 5 Telegramm-Wiederholungen sind jetzt 3 eingestellt. Das sollte reichen.

Temp.: 24.6 Druck: 1000.61 Druck[corr]: 30.06
h=30.0609989166
nible1=0 nible2=1010 nible3=0 nible4=1111 nible5=1
tens     = 7 111
ONES     = 4
TENTHS   = 6
CheckSum = 6
h=30.0609989166
nible1=0 nible2=1010 nible3=0 nible4=1111 nible5=1
tens     = 7 111
ONES     = 4
TENTHS   = 6
CheckSum = 6
h=30.0609989166
nible1=0 nible2=1010 nible3=0 nible4=1111 nible5=1
tens     = 7 111
ONES     = 4
TENTHS   = 6
CheckSum = 6
CalcPress::H=30.0609989166 CalcPress::TENS=3 CalcPress::ONES=0 CalcPress::TENTHS=0
h=30.0609989166
nible1=0 nible2=1010 nible3=1110 nible4=1111 nible5=1
tens     = 3 11
ONES     = 0
TENTHS   = 0
CheckSum = 14
h=30.0609989166
nible1=0 nible2=1010 nible3=1110 nible4=1111 nible5=1
tens     = 3 11
ONES     = 0
TENTHS   = 0
CheckSum = 14
h=30.0609989166
nible1=0 nible2=1010 nible3=1110 nible4=1111 nible5=1
tens     = 3 11
ONES     = 0
TENTHS   = 0
CheckSum = 14


Dann schauen wir morgen wieder auf das Ergebnis.

Das heutige Ergebnis. Leider keine großen Luftdruckveränderungen ...

Weitere Denkanstöße:

https://forum.fhem.de/index.php/topic,20620.0.html (https://forum.fhem.de/index.php/topic,20620.0.html)
FHEM-Universalsensor (http://www.fhemwiki.de/wiki/Universalsensor)
using-attiny-chips-for-arduino-like-projects (http://provideyourown.com/2014/using-attiny-chips-for-arduino-like-projects/)
arduino-voltmeter-measure-battery-voltage (http://provideyourown.com/2012/secret-arduino-voltmeter-measure-battery-voltage/)
Batteriehalter (http://www.reichelt.de/Batteriehalter-fuer-sonstige-Zellen/2/index.html?&ACTION=2&LA=3&GROUPID=6538)
18650-Li-Ion-3400mAh (https://www.amazon.de/Panasonic-NCR18650B_1-18650-Li-Ion-3400mAh/dp/B00AO79JQU/ref=sr_1_6?s=ce-de&ie=UTF8&qid=1471702116&sr=1-6&keywords=18650)
Charger (https://www.amazon.de/Demarkt-Lithium-Akku-Batterie-Charger-Ladeger%C3%A4t/dp/B00QI6TR54/ref=pd_sim_107_4?ie=UTF8&psc=1&refRID=S676E3JFGT8M9SBRJ7VT)

PIR-Sensor mit ATtiny85 (http://www.borngeek.net/Projects/attiny85-pir-sensor)
433Mhz-Antenne für CUL (2.5 dBi) (http://www.ebay.com/itm/Antenna-433MHZ-2-5dBi-GPRS-GSM-SMA-male-plug-SMD-SMT-for-Ham-Radio/271733423418?_trksid=p2047675.c100623.m-1&_trkparms=aid%3D222007%26algo%3DSIC.MBE%26ao%3D1%26asc%3D38618%26meid%3D8e9f7d2b41094b48a134d62666bb502f%26pid%3D100623%26rk%3D5%26rkt%3D6%26sd%3D330935792243)
Antenne (3 dBi) (http://www.ebay.com/itm/330915811011?ssPageName=STRK:MEWNX:IT&_trksid=p3984.m1439.l2649)

Hier der zweite Prototyp mit ATtiny85:
Mit 18650-Lipo-Akku + BMP180 + DHT220 sollte ausreichend sein.
Der Lipo-Accu mit 4,1..3,6V sollte auch dem DHT genügen.
Batterievergleich (http://www.kaayee.com/wp-content/uploads/2016/04/18650-vs-AA-battery-2.jpg)

ZitatNominal capacity: 3350 mAh
Nominal voltage: 3.6 V
Discharge end voltage: 2.5 V
Charging voltage: 4.20 +/- 0.03 V

Das BMP180-Breakoutboard hat ein LDO-Regler + Vorwiderstände.
Warte noch auf den Lipo-Charger zum komplettieren.
Evtl. auch extern mit 3mm Klinken-Buchse.

passendes Gehäuse (http://www.tme.eu/ch/details/box-sens-white/gehaeuse-fur-alarmanlagen-und-sensoren/supertronic/)
Gehäuse, größere Baufrom (http://www.tme.eu/ch/details/pp73bl/gehaeuse-fur-alarmanlagen-und-sensoren/supertronic/)

Alternativen (?):
Silabs - EFM32 (http://community.silabs.com/t5/Projects/EFM32-microAmp-Weather-Station/td-p/100107)
Überblick (http://www.silabs.com/products/mcu/32-bit/Pages/manage-the-iot-on-an-energy-budget.aspx)

Noch ein paar Infos zu CR2032-Batterien:
The impact of high pulse drain on CR2032 coin-cell battery capacity (http://www.eetimes.com/document.asp?doc_id=1279311)
High pulse drain impact on CR2032 coin cell battery capacity(pdf) (http://m.eet.com/media/1121454/c0924post.pdf)
Leaks-and-Drains (http://www.embedded.com/electronics-blogs/break-points/)

Sieht doch ganz gut aus ....  :)
Temperaturabfall, weil Fenster geöffnet .... "tropische Nacht"

Luftdrucktrend unter "Charts"
Karlsruhe (http://www.wetter.net/1210/Karlsruhe)
Luftdruck-Trend (http://www.wetter.net/cgi-bin/wetter-net3/wetter-stadt-graph.pl?IDM=4&ID=1210&ALIAS=Karlsruhe&ID2=0&REGIO=0)

Hallo zusammen,

bitte um Mithilfe, bekomm es nicht hin. Kommt nix an in FHEM.
Muß ich den LACROSSE CUL STICK in Pairing setzten, so das er die Werte erhält ??

Der BMP180 ist über I2C-Standardbelegung am Leonardo angeschlossen. GND , VCC, 2, 3 -> BMP wird erkannt und liefert Werte.
BMP180 Temperatur und Luftdruck auslesen.
Temp.: 23.0 Druck: 1012.00 Druck[corr]: 31.20
h=31.2000007629
nible1=0   nible2=1010   nible3=0   nible4=1111   nible5=1
tens     = 7   111
ONES     = 3
TENTHS   = 0
CheckSum = 14
h=31.2000007629
nible1=0   nible2=1010   nible3=0   nible4=1111   nible5=1
tens     = 7   111
ONES     = 3
TENTHS   = 0
CheckSum = 14
h=31.2000007629
nible1=0   nible2=1010   nible3=0   nible4=1111   nible5=1
tens     = 7   111
ONES     = 3
TENTHS   = 0
CheckSum = 14
CalcPress::H=31.2000007629 CalcPress::TENS=3 CalcPress::ONES=1 CalcPress::TENTHS=2
h=31.2000007629
nible1=0   nible2=1010   nible3=1110   nible4=1111   nible5=1
tens     = 3   11
ONES     = 1
TENTHS   = 2
CheckSum = 2
h=31.2000007629
nible1=0   nible2=1010   nible3=1110   nible4=1111   nible5=1
tens     = 3   11
ONES     = 1
TENTHS   = 2
CheckSum = 2
h=31.2000007629
nible1=0   nible2=1010   nible3=1110   nible4=1111   nible5=1
tens     = 3   11
ONES     = 1
TENTHS   = 2
CheckSum = 2

Bis hier denke ich, ist alles OK. Nun DATEN senden an FHEM ,mh?????

433MHz-Sender an Port D7. --> Superheterodyne 433 Mhz RF sender : http://www.ebay.de/itm/Superheterodyne-Sender-Empfaenger-433-Mhz-aehnlich-3400-RF-Raspberry-Pi-Arduino-/252256558833 .............so einen hab ich , kommt nix an.
RFM69CW oder RFM69HCW ???

In FHEM sieht die Define auch komisch aus.

CUL_TX_120 Defined
CODE 120
DEF  120
NAME CUL_TX_120
NR 510
STATE Defined
TYPE CUL_TX
corr 0
lastH 0
lastT 0
minsecs 0


Was mache ich falsch, das keine DATEN in FHEM ankommen, falscher Sender ? wird erkannt als AliRF_22A286.

Bitte um Hilfe, DANK Voarb....:=)

Hallo toensi,
Sieht ja schon ganz gut aus. Die Werte werden geliefert.

Zu klären wäre:

Ich benutze einen nanoCul mit 433MHz Version.

"LaCrosse" bezieht sich auf das Protokoll und nicht die
Hardware. Deshalb benötig man auch kein Pairing etc.


Der Sensor wird mit "autocreate" normalerweise richtig
erkannt und ohne weiteres Zutun als cul_tx-Device angelegt.
Meine cul_tx120-Definitionen sind schon im Thread angegeben.

Wenn Dein Sender unter 433.92 MHz sendet, sollte er von Fhem erkannt werden


Könntest Du schildern was Du zum Empfang benutzt?
Jürgen

Hallo Jürgen,

zum Empfang benutze ich:  JeeLink 1 als Epfänger für PIR 433 MHZ :PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110:KeyValueProtocol

JeeLink 2 für  Temperatursensoren
:PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110:KeyValueProtocol
[LaCrosseITPlusReader.10.1h (RFM69CW) @AutoToggle 30 Seconds / 868280 kHz]

Cul 868 für Homematic

Denke es liegt am Sender, werde mir jetzt so einen Bestellen und weiter testen. Oder fehlt der Empänger ? sollte doch mit Jeelink1 gehen oder ??
http://www.ebay.de/itm/433Mhz-RF-Sender-Empfaenger-transmitter-receiver-modul-Arduino-wireless-funk-kit-/171650960632

Besten Dank und Gruß aus Münster.................:)

Hallo toensi,

...sorry, jetzt ist es klar.

Es liegt nicht am Sender.
Diese Art von Sender ist nicht (direkt) kompatibel zu Deinen Jeelink-Empfängern.  (Hauptsächlich 868 MHz!)
Die Sender, die ich benutze, verwendet die "Modulationsart" OOK welche der Cc1101 im Cul kann.

Die Jeelinks mit den RFM chips können das mit Tricks auch... empfangen aber normalerweise nur FSK.
Aber dann müsstest Du ein Empfänger opfern, der dann nur dieses spezielle Protokoll empfangen kann.

Tut mir Leid, wenn das nicht so deutlich erkennbar war.

Aber vielleicht gibt es ja Hoffnung für eine andere Lösung?

Jürgen

Je nach dem welche FW konfiguratiom Dei cul868 hat könntest Du
Probieren, den cul auf 433 MHZ umzuschalten

Mit set culname freq 433.920 sollte es möglich sein, den 868er umzuschalten.
Dann kannst Du die Sensoren möglichweise empfangen.
Aber ob das mit Deiner Infrastruktur harmoniert ....

Dieser Thread ist ja aus  diesem hier (https://forum.fhem.de/index.php/topic,52755.0.html) mit dem Dallas-DS18B20
abgeleitet.

Mann müßte prüfen, ob für Dich diese Variante in Frage kommt:
http://johan.kanflo.com/the-aaduino/ (http://johan.kanflo.com/the-aaduino/)
Die ist mit einem RFM69 realisiert.... und könnte auf Deine Jeelinks passen.

Die Umschalterei mit den Homematic-CUl war schon öfter hier im Forum ein Thema.
Es geht wurde aber davon abgeraten und eher ein 433-CUL oder FHEMDUINO/Signalduino  zusätzlich empfohlen.

Hier noch der Hinweis auf RFM - OOK:
http://jeelabs.net/projects/cafe/wiki/Receiving_OOKASK_with_a_modified_RFM12B (http://jeelabs.net/projects/cafe/wiki/Receiving_OOKASK_with_a_modified_RFM12B)
Ein anderes Protokoll (http://www.mike-stirling.com/2013/02/implementing-the-elv-fht-protocol-with-an-rfm23/)
controlling-433mhz-rf-power-sockets-with-a-rfm12b-module (https://harizanov.com/2012/04/controlling-433mhz-rf-power-sockets-with-a-rfm12b-module/)
433-92mhz-askook-transmitter-modules-compared/ (http://goughlui.com/2016/05/01/shootout-four-433-92mhz-askook-transmitter-modules-compared/)

Hallo Jürgen!

Danke für die schnelle Rückantwort und Hilfe.

So hab jetzt nen CUL433 an FHEM angesteckt und ist Initialized.

Clients :FS20:FHT.*:KS300:USF1000:BS:HMS: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX:Revolt:IT:UNIRoll:SOMFY: :STACKABLE_CC:CUL_RFR::CUL_TCM97001:CUL_REDIRECT:

V 1.21.00 a-culfw Build: private build (unknown) CUL433 (F-Band: 433MHz)

FHEM: autocreate ist active also disable 0.

Bekomme im LOG File und im Event Monitor nix rein....
Empfänger CUL 433 ist ca 3 m entfernt

Danke Vorab :=)

Ah,

ich benutze diese Version:
NANOCUL version => V 1.63 CUL433 Benennung "Nanocul" täuscht, da ich ein 32U4 in der CUL-Konfiguration benutze, ist leider noch ein Relikt ...
evtl. mit "set <culname> raw e"  den CUL + dessen EEPROM-Inhalt resetten.
in dieser Konfiguration:
Clients:   
:FS20:FHT.*:KS300:USF1000:BS:HMS: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX:Revolt:IT:UNIRoll:SOMFY: :STACKABLE_CC:CUL_RFR::CUL_TCM97001:CUL_REDIRECT:

Da es bei mir auf Anhieb geklappt hat, kam ich nicht in die Versuchung das Feature suchen zu müssen (Glück gehabt ...).
Ich vermute, dass es sich um dieses Feature handeln könnte: CUL_TX:Revolt, welches Du aber auch eingeschalten hast.

1.) Könntest Du mir mal bitte den Output von CCCONF des CULs senden?  Steht er auf 433.92 MHz? Fehlerhaftes Device wieder gelöscht?
2.) Der Data-Pin des 433-TX-Moduls sollte am Leonardo-Pin D7 angeschlossen sein. Liegen 5V  und Masse auch am Sendemodul an?
3.) Wenn die "L" Led  am Leonardo angeht, sollte man am Data-Pin des TX-Moduls mit einem Multimeter deutlich aber kurzfristig eine Spannungsschwankung/Pulsieren
beim Senden der On-Off-Signale bemerken können (0V=Idle, 5V=Senden) dann sollte das Modul eigentlich auch senden... (Modul kaputt?)
4.) Steht im FHEM-Log noch irgendwas außerordenliches zu den Zeitpunkten wo die Sendung erfolgte?
5.) Hast Du auch ein 17,4 cm lange Antenne an das Modul angeschlossen? Schau mal hier auf howto/funkdaten-mitloggen-und-simulieren/ (http://www.david-pauli.de/howto/funkdaten-mitloggen-und-simulieren/)
6.) Dann wird es eng ... Ist das Modul wirklich 433MHz und nicht 325MHz?
7.) Könnte ich Dir mein Hex-File des CULs zur Verfügung stellen.
8.) Waren beim Kompilieren des Sources, irgenwelche Fehlermeldungen in der Arduino-IDE zu sehen? Waren alle Sourcen mit eingebunden(siehe Bild)?
     Oder hast Du das enthaltene HEX-File geflasht?
8.) Müsste evtl. noch mal auf die CUL-Software schauen, wenn ich etwas mehr Zeit habe, um das Feature zu identifizieren, welches erforderlich sein muss ....    ;)
9.) siehst Du das CUL_TX-Device mit der ID=120?

Schade, bei mir ging's auf Anhieb .... (Auch mit den DHT + DS18B20-Sensoren)

Jürgen

Hier noch die autocreate Einstellung:
define autocreate autocreate
attr global autoload_undefined_devices 1


http://www.instructables.com/id/Mini-weather-station-with-Attiny85/ (http://www.instructables.com/id/Mini-weather-station-with-Attiny85/)

passende Antenne (https://www.elektor.nl/Uploads/Forum/Posts/How-to-make-a-Air-Cooled-433MHz-antenna.pdf)

Weiterere Sensoren:
http://arduinolearning.com/code/htu21d-bmp180-bh1750fvi-sensor-example.php (http://arduinolearning.com/code/htu21d-bmp180-bh1750fvi-sensor-example.php)
http://www.ebay.de/itm/HTU21D-BMP180-BH1750FVI-Temperature-Humidity-Pressure-Light-Sensor-Module-/371728971698?hash=item568cc5f7b2 (http://www.ebay.de/itm/HTU21D-BMP180-BH1750FVI-Temperature-Humidity-Pressure-Light-Sensor-Module-/371728971698?hash=item568cc5f7b2)

Hallo,

ich sende, mit der Lacrosse-Libary von juergs (danke, daß du die Sourcen zu Verfügung stellst), Sensordaten von einem Arduino mit FS1000A an einen Signalduino.

Dabei hatte ich das Problem, daß die Daten vom Signalduino nicht erkannt wurden.
Ein TFA 30.3125 (verwendet auch das Lacrosse-Protokoll) funktioniert allerdings problemlos.

Falls jemand das gleiche Problem haben sollte, hier die Lösung:

Pulslängen und Verzögerung ändern:
int iLongPulse = 1200;
int iShortPulse = 400;
int iDelay = 900;

Daraufhin wurden die Daten von Signalduino einwandfrei erkannt.

Die Werte hab ich übrigens von dieser Seite:
https://github.com/letscontrolit/NodoClassic/blob/master/RFLinkNRF/Plugins/Plugin_043.c

Gruß kojani

Hallo kojani,
danke fürs Herausfinden:
Es waren ja ursprünglich folgende Angaben:
//--- Duration of pulses and delays
int iLongPulse  = 975;
int iShortPulse = 250;
int iDelay = 1450;

Die unterscheiden sich dann ja schon erheblich.

Deine Einstellungen werde ich gerne mal ausprobieren.
Hatte kein Orginal zu Vergleich ... und der Signalduino
passt sein Timingfenster für die Erkennung in einer bestimmten Größe an.
Wenn der Sender Frequenz-technisch etwas daneben liegt ...
Die  FS1000A sind nicht unbedingt die Besten  ;)

Im Moment hänge ich noch an einem ähnlichen Problem:
LaCrosse-Transponder (https://forum.fhem.de/index.php/topic,58110.105.html)


Grüße,
Jürgen

Wäre es möglich die Lib auf github oder etwas ähnlichem hoch zu laden? man könnte so Änderungen leichter verfolgen und sich besser einbringen.

https://github.com/juergs/_ATtiny85_DHT22_BMP180_433 (https://github.com/juergs/_ATtiny85_DHT22_BMP180_433)