Selbstbau-BMP180-Sensor mit LaCrosse 433 MHz Protokoll

Begonnen von juergs, 14 August 2016, 22:19:23

Vorheriges Thema - Nächstes Thema

juergs

#30
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/
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




kojani

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
BannanaPi+SignalDuino(CC1101,433MHz):WS3080;TFA 30.3125

juergs

#33
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


Grüße,
Jürgen

0x2a

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.