Hallo Kollegen,
habe o.g. Temp Sensoren hier liegen und diese finde ich wegen der Solarunterstützung ganz praktisch.
Habe dank diesem thread:
https://forum.arduino.cc/index.php?topic=136836.60
über den Sketch Daten geloggt und 4 Tage versucht diese zu "entschlüsseln", ABER leider finde ich keine Daten von den Temp Sensoren drin.
Kann jemand drüberschauen und vielleicht bin ich "blind"?
oder hat jemand diese bereits dekodiert?
Danke im Voraus!
immer 42 bits
Kanal 2
001100001110010011011001101011001000000001 73,6F 43% , C
001100001110010010011001101011001000000111 73,4F 43% , C
001100001110010001011001101011001000001101 73,3F 43% , C
001100001110010001011001101011001000001101 73,3F 45% 22,9C
001100001100011111010101101011001000000110 73,1F 43% , C
001100001110011110010101101011001000001111 73,0F 43% 22,8C
001100001101011001001101100100001100000110 69,3F 52% C
001100001101011010001101100100001100001100 69,4F 52% C
001100001101011011001101100011001100000010 69,5F 51% C
001100001101011101001101100011001100000101 69,7F 51% C
KANAL 1:
001100001110001000010001100100001100010100 70,9 53 21,6C
001100001110001001010001100011001100011010 70,9 51 21,6C
001100001110001001010001100010001100011111 70,9 50 21,6C
001100001110001001010001100011001100011010 70,9 51 21,6C
KANAL 3:
001100001110101001010001100100001100010101 70,9 52 21,6C
001100001110100111010001100100001100010111 70,7 52 21,5C
001100001110101000010001100011001100011011 70,8 51 21,5 21,6
KANAL 3 (NACH Batterie RAUS):
001010100010101101010001100011001100001010 71,2 50 21,8
001010100010101100010001100011001100001100 71,2 51 21,8
KANAL 3 (NACH 2x Batterie RAUS):
001100100110100010010101100010001100001111 71,8 50 22,1
001100100110100001010101100100001100001000 71,7 52 22,0
001100100110100001010101100011001100000000 71,7 51 22,0
001100100110100001010101100010001100000101 71,7 50 22,0
001100100110100001010101100010001100000101 71,7 50 22,0
001100100110100001010101100010001100000101 71,7 50 22,0
001100100110100001010101100001001100001010 71,7 49 22,0
RAW Daten sehen so aus:
für 71,7F 49%
Start Bit L: 7990 H: 460
Data Bits: 42
L: 2024 2028 4080 4072 2040 2108 4072 2048 2044 4140 4076 2044 4076 2112 2044 2044 2044 4144 2048 4072 2048 4140 2044 4076 4076 2112 2044 2044 2044 4140 2044 2048 4076 4140 2044 2044 2048 2116 4076 2048 4080 2156
H: 456 452 452 448 460 456 460 444 460 456 456 456 452 452 456 452 456 452 452 452 456 452 456 456 452 456 452 452 456 452 456 452 452 456 456 456 452 452 448 452 452 448
001100100110100001010101100001001100001010
nach 2 Tagen mit bluefox (vom ioBroker Projekt) haben wir es geschafft!!!!
siehe hier:
http://forum.iobroker.net/viewtopic.php?f=35&t=3818
apropos, FHEM ADAPTER hat er auch schon, also könnt ihr auch VIS nutzen= Visualisierung für alles!
Zitat von: maxtox am 27 September 2016, 16:03:43
nach 2 Tagen mit bluefox (vom ioBroker Projekt) haben wir es geschafft!!!!
siehe hier:
http://forum.iobroker.net/viewtopic.php?f=35&t=3818
apropos, FHEM ADAPTER hat er auch schon, also könnt ihr auch VIS nutzen= Visualisierung für alles!
Zitat von: maxtox am 25 September 2016, 19:37:33
Hallo Kollegen,
habe o.g. Temp Sensoren hier liegen und diese finde ich wegen der Solarunterstützung ganz praktisch.
Habe dank diesem thread:
https://forum.arduino.cc/index.php?topic=136836.60
über den Sketch Daten geloggt und 4 Tage versucht diese zu "entschlüsseln", ABER leider finde ich keine Daten von den Temp Sensoren drin.
Kann jemand drüberschauen und vielleicht bin ich "blind"?
oder hat jemand diese bereits dekodiert?
Danke im Voraus!
immer 42 bits
Kanal 2
001100001110010011011001101011001000000001 73,6F 43% , C
001100001110010010011001101011001000000111 73,4F 43% , C
001100001110010001011001101011001000001101 73,3F 43% , C
001100001110010001011001101011001000001101 73,3F 45% 22,9C
001100001100011111010101101011001000000110 73,1F 43% , C
001100001110011110010101101011001000001111 73,0F 43% 22,8C
001100001101011001001101100100001100000110 69,3F 52% C
001100001101011010001101100100001100001100 69,4F 52% C
001100001101011011001101100011001100000010 69,5F 51% C
001100001101011101001101100011001100000101 69,7F 51% C
KANAL 1:
001100001110001000010001100100001100010100 70,9 53 21,6C
001100001110001001010001100011001100011010 70,9 51 21,6C
001100001110001001010001100010001100011111 70,9 50 21,6C
001100001110001001010001100011001100011010 70,9 51 21,6C
KANAL 3:
001100001110101001010001100100001100010101 70,9 52 21,6C
001100001110100111010001100100001100010111 70,7 52 21,5C
001100001110101000010001100011001100011011 70,8 51 21,5 21,6
KANAL 3 (NACH Batterie RAUS):
001010100010101101010001100011001100001010 71,2 50 21,8
001010100010101100010001100011001100001100 71,2 51 21,8
KANAL 3 (NACH 2x Batterie RAUS):
001100100110100010010101100010001100001111 71,8 50 22,1
001100100110100001010101100100001100001000 71,7 52 22,0
001100100110100001010101100011001100000000 71,7 51 22,0
001100100110100001010101100010001100000101 71,7 50 22,0
001100100110100001010101100010001100000101 71,7 50 22,0
001100100110100001010101100010001100000101 71,7 50 22,0
001100100110100001010101100001001100001010 71,7 49 22,0
RAW Daten sehen so aus:
für 71,7F 49%
Start Bit L: 7990 H: 460
Data Bits: 42
L: 2024 2028 4080 4072 2040 2108 4072 2048 2044 4140 4076 2044 4076 2112 2044 2044 2044 4144 2048 4072 2048 4140 2044 4076 4076 2112 2044 2044 2044 4140 2044 2048 4076 4140 2044 2044 2048 2116 4076 2048 4080 2156
H: 456 452 452 448 460 456 460 444 460 456 456 456 452 452 456 452 456 452 452 452 456 452 456 456 452 456 452 452 456 452 456 452 452 456 456 456 452 452 448 452 452 448
001100100110100001010101100001001100001010
Rein vom timing her müsste der doch schon mit der a-culfw gehen. Hast du dass schon mal probiert?
nee... habe leider keinen CUL
ich kann dir die RAW Daten schicken... willst du probieren?
Hallo bjoernh,
ich habe mir die Dinger auch zugelegt + aculfw aktiv:
Zitat2016-12-24 23:34:57 CUL_TCM97001 Unknown Code: 06C30DA88740
2016-12-24 23:34:58 CUL_TCM97001 Unknown Code: 06C30DA88740
2016-12-24 23:34:58 CUL_TCM97001 Unknown Code: 06C30DA88740
2016-12-24 23:34:58 CUL_TCM97001 Unknown Code: 06C30DA88740
2016-12-24 23:34:58 CUL_TCM97001 Unknown Code: 06C30DA88740
Leider nein.
Auch hier: https://forum.fhem.de/index.php/topic,36104.msg543191.html#msg543191 (https://forum.fhem.de/index.php/topic,36104.msg543191.html#msg543191)
Grüße,
Jürgen
Dann musst du eine Messreihe machen. Sprich Temperatur und Luftfeuchtigkeit aufschreiben + die dazu gehörenden empfangenen Werte.
In die Gefriertruhe sollte er dann für negative Temperaturen auch.
Zusätzlich wird dann noch das Batterienbit sowie Kanalbilts (falls vorhanden) benötigt.
Gesendet von meinem Mobile Device.
https://forum.fhem.de/index.php/topic,36104.msg547174.html#msg547174 (https://forum.fhem.de/index.php/topic,36104.msg547174.html#msg547174)
Signalduino-Issues (https://github.com/RFD-FHEM/RFFHEM/issues/117)
auriol_protocol_v20.pdf (https://github.com/RFD-FHEM/RFFHEM/files/678294/auriol_protocol_v20.pdf)
Arduino-Testcode 42BIT_Protokoll.zip (https://github.com/RFD-FHEM/RFFHEM/files/678599/_Tschibo_42BIT_Protokoll.zip)
Dort das 42 Bit Protokoll. Ist (bis dato, meines Wissens) noch nicht in Fhem implementiert.
Grüße
Jürgen
Moin Moin
und erst mal ein Frohes Neues.
Da ich auch 3 von den Dingern da habe erlaube ich mir mal zu fragen ob man irgendwo helfen kann.
Ich würde die nämlich auch gerne in FHEM einbinden.
Grüße
Dummbatz
Zitat von: Dummbatz am 02 Januar 2017, 14:28:54
Moin Moin
und erst mal ein Frohes Neues.
Da ich auch 3 von den Dingern da habe erlaube ich mir mal zu fragen ob man irgendwo helfen kann.
Ich würde die nämlich auch gerne in FHEM einbinden.
Grüße
Wenn ich Zeit habe kann ich es mir mal anschauen. Es fehlt halt die Interpretation im fhem Modul.
Wenn jemand Lust hat, kann er es gerne mal probieren :)
Dummbatz
ZitatWenn ich Zeit habe kann ich es mir mal anschauen. Es fehlt halt die Interpretation im fhem Modul.
Hallo bjoernh,
habe Testdaten bei Sidey (https://github.com/RFD-FHEM/RFFHEM/issues/117) eingestellt.
Grüße,
Jürgen
Hallo Jürgen,
Kurze Frage:
Kannst Du mir mal bitte erläutern wie Du zu den Daten gekommen bist. Ich bekomme es nicht hin meinen NanoCul zu überreden das Teil überhaupt mal zu empfangen.
Würde gerne mal so eine Testreihe wie Du erarbeitet hast erstellen.
Danke
@bjoernh;
Thx4Info
Hier mit diesem Sketch:
https://github.com/RFD-FHEM/RFFHEM/files/678599/_Tschibo_42BIT_Protokoll.zip (https://github.com/RFD-FHEM/RFFHEM/files/678599/_Tschibo_42BIT_Protokoll.zip)
=> 433-Receiver an D2 (INT0), mehr nicht!
Ist nicht unbedingt Tsch...-Protokoll. Mir ist gerade nichts Besseres dazu eingefallen ;)
Dort ist die Fahrenheit-in-Celsius-Umrechnung dabei.
Überlege mir, ob ich ein Repeater in LaCrosse o.ä. dafür aufsetze:
=> Hier noch in Arbeit: NC7427 Protocol_Repeater_42Bit (https://github.com/juergs/Protocol_Repeater_42Bit)
Grüße,
Jürgen
Danke Dir.
Werde ich mir mal ansehen.
Also doch mal ein wenig Hardware einkaufen 8)
LG
Hallo,
dieser und eineige andere Thementhreads, die sich mit dem 42bit -Protokoll befassen, nehmen zur Dekodierung einen Arduino. Hat denn schon jemand die Daten in FHEM darstellen können? Wenn ja - wie?
Ich habe hier zwei von den NC7415 liegen und empfange die Daten mit einem nanoCUL und a-culfw sauber und regelmäßig. Erkenne aber trotz der vielen Threads nicht, wie ich sie in FHEM darstellen kann.
Sehe ich da etwas falsch oder übersehe ich etwas?
Gruß Eberhard
Hallo FHEm2005,
klingt interessant.
Ich habe hier die aktuelle a-culfw im Einsatz und baue gerade an einem "transponder" für das Protokoll herum.
"autocreate" ist an.
Könntest Du mal Deine Definition des Sensors posten?
Bei mir wird der Sensor nicht erkannt:
Zitat2017-01-22 13:57:49 CUL_TCM97001 Unknown Code: 2FC091888040
2017-01-22 13:57:49 CUL_TCM97001 Unknown Code: 2FC091888040
2017-01-22 13:57:49 CUL_TCM97001 Unknown Code: 2FC091888040
2017-01-22 13:57:49 CUL_TCM97001 Unknown Code: 2FC091888040
2017-01-22 13:57:50 CUL_TCM97001 Unknown Code: 2FC091888040
CUL_TCM97001 passt wohl nicht .... :'(
Könnte unter anderen auch deshalb sein, weil dessen Präambel ein 9ms statt 8ms Impuls enthält (einer bis zwei der 6 Repeats der Protokolle) .
Aber wäre schon weit um das Protokoll Richtung LaCrosse weiterzuleiten (auch zur Reichweiten-Erhöhung nutzbar.)
Soweit wäre ich bis jetzt:
Zitat[1]:
------------------------------------------------------------
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
0 0 1 0 1 1 1 1 1 1 0 0 0 1 0 1 0 0 0 1 0 0 0 1 1 0 0 0 1 0 0 0 1 0 0 0 0 0 1 1 0 0
---------------------------------------------------------------------------------------
LD: 00 |ID: 10111111 |BAT: 00 |CH: 01 |TEMP: 010001000110 |HUM: 00100010 |CRC: 00001100
---------------------------------------------------------------------------------------
[ 2] ID: 1 - 1
[ 3] ID: 1 - 0
[ 4] ID: 3 - 1
[ 5] ID: 7 - 1
[ 6] ID: 15 - 1
[ 7] ID: 31 - 1
[ 8] ID: 63 - 1
[ 9] ID: 127 - 1
------------------------------------------------------------
ld: 0
id: 127
bat: 0
ch: 2
temp: 785
hum: 34
crc: 34
Raw: 1739006387398115328
[2]:
Lead, ID, Bat, Kanal passen schon. Temp + Hum müssen noch aus meinem Bit/Byte-Array ausgelesen werden und in ihtre Werte gewandelt werden.
Die 42 Bit sind in der Tat eine Herausforderung (datentyp 64Bit: unsigned long long) .
Grüße,
Jürgen
Hallo Jürgs,
ich muss da etwas zurückrudern, weil ich mich offensichtlich falsch bzw. unklar ausgedrückt habe und dadurch Erwartungen geweckt habe, die nicht zutreffen. Ich habe KEINE Temperatur und keine Humidity-daten in Klarschrift, sondern genau die Daten, die Du auch empfängst. Es bleibt auch bei mir ein Unkown Code.
Sorry für das Missverständnis.
Gruß Eberhard
ZitatSorry für das Missverständnis.
:) Kein Problem und danke für die Rückmeldung.
Da es die Kombi CUL-Dekodierung und FHEM-Modul für diesen Sensor noch nicht gibt,
habe ich mich für diesen Weg entschieden, der für mich einfacher machbar war.
Da ich mich auch erst in die Thematik Empfangs-seitig einarbeiten musste.
Sogar jetzt auch, zumindest ein bisschen die Arbeit von Sidey und bjoernH noch mehr wertschätzen kann,
die das super machen ...
ZitatLLLL MMMM HHHH HHHH MMMM LLLL
0111 0101 0110 => 0110 0101 0111 => 657 = 0x657 = 1623 - 900 = 723 /10 = 72.3 (F) = 22,38 °C = 22,4 °C in der Anzeige.
Mal schauen, wie weit ich heute komme.
433ProtocolTransponder.ino (https://github.com/juergs/433ProtocolUmsetzer/blob/master/433ProtocolTransponder.ino)
Hardware-Setup (https://bitbucket.org/fuzzillogic/433mhzforarduino/src/0847a6d8a9173abd5abf9cf571a1539f56588c0e/RemoteSensor/docs/hardware%20setup.jpg?at=default&fileviewer=file-view-default)
Dann kann man die Daten des "Billig"-Solar-Sensors als LaCrosse CUL_TX- oder Hideki-Sensor-Daten empfangen.
Vielleicht geht die Firmwareanpassung dann als zweiter Schritt in Signalduino oder aculfw über....
Grüße,
Jürgen
Ich habe mir mal ein excel-Sheet "gebaut" um ein Verständnis der Werte zu bekommen. Dabei arbeite ich grundsätzlich mit einem Array, in welchem in die Zellen immer ein Halbnibbel (2Bit) ausgewertet werden.
Ich habe es mal beigefügt und die hinterlegten Formeln sichtbar gelassen, Vielleicht helfen sie beim Programmieren, was ich in dieser Tiefe nicht kann. Bitte nur in das gelbe Feld den übermittelten Wert eintragen. Im blauen Feld stehen dann die Ergebnisse. Die müssten mit der Anzeige übereinstimmen. Tut es bei mir jedenfalls.
Gruß Eberhard
Ergänzung:
Bei mir wurde ein neues device angelegt mit dem Device CUL_TCM97001. In den Reading steht der empfangene String als state zur Verfügung. Könnte man nicht einfacherweise die Temperatur und die Feuchte als Userreading mit hinterlegter Programmierug ausführen?
Edit: Excel-Datei hatte im Batterie und Kanalnoch Fehler, Deshalb neue Bilder und XLS
Es ist geschafft! Trotz nur rudimentärer Perl-Kenntnisse habe ich den empfangenen Code decodiert und die einzelnen Teile als User Reading dargestellt.
Hier die Definition der UserReadings:
stateBIN {my $s = (ReadingsVal($name,'state',''));
my @worte = split(/\s+/,$s);
$s = @worte[1];
my @chars = split(//,$s);
my $char = "";
my $u = "";
my $t = "";
for (my $i=0; $i <= 11; $i++) {
$char = @chars[$i];
if ($char eq "0") { $t ="0000";}
elsif ($char eq "1"){$t = "0001";}
elsif ($char eq "2"){$t = "0010";}
elsif ($char eq "3"){$t = "0011";}
elsif ($char eq "4"){$t = "0100";}
elsif ($char eq "5"){$t = "0101";}
elsif ($char eq "6"){$t = "0110";}
elsif ($char eq "7"){$t = "0111";}
elsif ($char eq "8"){$t = "1000";}
elsif ($char eq "9"){$t = "1001";}
elsif (($char eq "a")|| ($char eq "A")){$t = "1010";}
elsif (($char eq "b")|| ($char eq "B")){$t = "1011";}
elsif (($char eq "c")|| ($char eq "C")){$t = "1100";}
elsif (($char eq "d")|| ($char eq "D")){$t = "1101";}
elsif (($char eq "e")|| ($char eq "E")){$t = "1110";}
elsif (($char eq "f")|| ($char eq "F")){$t = "1111";}
$u= "$u$t";
}
return($u);},
LD {my $s = (ReadingsVal($name,'stateBIN',''));
my @worte = split(//,$s);
my $t = @worte[0].@worte[1];
return($t);},
ID {my $s = (ReadingsVal($name,'stateBIN',''));
my @worte = split(//,$s);
my $u="";
for (my $i=2; $i <= 9; $i++) {
my $t= @worte[$i];
$u="$u$t";}
$u=oct( "0b$u" );
return($u);},
BAT {my $s = (ReadingsVal($name,'stateBIN',''));
my @worte = split(//,$s);
my $t = @worte[10].@worte[11];
if ($t eq "00"){$t="schwach";}
elsif ($t eq "01"){$t="gut";}
elsif ($t eq "10"){$t="top";}
return($t);},
CH {my $s = (ReadingsVal($name,'stateBIN',''));
my @worte = split(//,$s);
my $t = @worte[12].@worte[13];
if ($t eq "00"){$t="1";}
elsif ($t eq "01"){$t="2";}
elsif ($t eq "10"){$t="3";}
return($t);},
TEMP {my $s = (ReadingsVal($name,'stateBIN',''));
my @worte = split(//,$s);
my $u="";
my $t="";
my $i=0;
for ($i=22; $i <= 25; $i++) {
$t= @worte[$i];
$u="$u$t";}
for ($i=18; $i <= 21; $i++) {
$t= @worte[$i];
$u="$u$t";};
for ($i=14; $i <= 17; $i++) {
$t= @worte[$i];
$u="$u$t";}
$u=oct( "0b$u" );
$u= ((($u-900)/10)-32)*5/9;
$u= int(10 * $u + 0.5) / 10;
return($u);},
HUM {my $s = (ReadingsVal($name,'stateBIN',''));
my @worte = split(//,$s);
my $u="";
my $t="";
my $i=0;
for ($i=30; $i <= 33; $i++) {
$t= @worte[$i];
$u="$u$t";}
for ($i=26; $i <= 29; $i++) {
$t= @worte[$i];
$u="$u$t";};
$u=oct( "0b$u" );
$u= int($u + 0.5);
return($u);},
Dabei ist stateBIN der in Binärzehlen umgewandelte empfangene Code. Die Leading Bits stehen unter LD, der Empfangskanal steht in CH, die Geräte-ID unter ID (wo sonst auch) und TEMP und HUM sind selbsterklärend. Der Zustand der Batterie wird in KLartext dargestellt (top, gut, schwach).
Ich weiß ncht wie sich diese Definition mit zwei Sensoren und nach Batteriewechsel verhält. Das werde ich noch mal austesten. Ich hoffe, dass ein neues Devise anleget wird.
Gruß Eberhard
EDIT: Hinweis: Empfang der Daten mit nanoCUl und a-culfw (V 1.21.00 a-culfw Build: 70)
Du kannst die hex-Werte aus dem state auch relativ simpel in einen Binärwert umrechnen:
sprintf( "%048b", hex( $hexvalue ) );
Das rechnet einen HEX-Wert in einen Binärwert, mit führenden Nullen bis auf 48 Stellen. So wird aus "HEX: 1B0055908040" "BIN: 000110110000000001010101100100001000000001000000".
$hexvalue entsprechend durch Deinen State ersetzen.
Danke mahowi,
habe es eingearbeitet und gleichzeitig einige Readings geändert:
TEMP => temperature
HUM => humidity
BAT => battery
CH => channel
Das hat den Vorteil, dass bei Verwendung von dewpoint zusätzlich die Readings abs Feuchte und dewpoint erscheinen.
stateBIN {my $s = (ReadingsVal($name,'state',''));
my @worte = split(/\s+/,$s);
$s = @worte[1];
my $u=sprintf( "%048b", hex( $s ) );
return($u);},
LD {my $s = (ReadingsVal($name,'stateBIN',''));
my @worte = split(//,$s);
my $t = @worte[0].@worte[1];
return($t);},
ID {my $s = (ReadingsVal($name,'stateBIN',''));
my @worte = split(//,$s);
my $u="";
for (my $i=2; $i <= 9; $i++) {
my $t= @worte[$i];
$u="$u$t";}
$u=oct( "0b$u" );
return($u);},
battery {my $s = (ReadingsVal($name,'stateBIN',''));
my @worte = split(//,$s);
my $t = @worte[10].@worte[11];
if ($t eq "00"){$t="schwach";}
elsif ($t eq "01"){$t="gut";}
elsif ($t eq "10"){$t="top";}
return($t);},
channel {my $s = (ReadingsVal($name,'stateBIN',''));
my @worte = split(//,$s);
my $t = @worte[12].@worte[13];
if ($t eq "00"){$t="1";}
elsif ($t eq "01"){$t="2";}
elsif ($t eq "10"){$t="3";}
return($t);},
temperature {my $s = (ReadingsVal($name,'stateBIN',''));
my @worte = split(//,$s);
my $u="";
my $t="";
my $i=0;
for ($i=22; $i <= 25; $i++) {
$t= @worte[$i];
$u="$u$t";}
for ($i=18; $i <= 21; $i++) {
$t= @worte[$i];
$u="$u$t";};
for ($i=14; $i <= 17; $i++) {
$t= @worte[$i];
$u="$u$t";}
$u=oct( "0b$u" );
$u= ((($u-900)/10)-32)*5/9;
$u= int(10 * $u + 0.5) / 10;
return($u);},
humidity {my $s = (ReadingsVal($name,'stateBIN',''));
my @worte = split(//,$s);
my $u="";
my $t="";
my $i=0;
for ($i=30; $i <= 33; $i++) {
$t= @worte[$i];
$u="$u$t";}
for ($i=26; $i <= 29; $i++) {
$t= @worte[$i];
$u="$u$t";};
$u=oct( "0b$u" );
$u= int($u + 0.5);
return($u);},
Gruß Eberhard
Hallo Zusammen,
schön zu sehen, dass es hier auch vorwärts geht.
Meine Beobachtung war, dass nach einem der letzten Updates von FHEM die ausgegeben Readings
zwischenzeitlich nicht mehr binär zu den übertragenen Daten passten. (Stimmt jetzt aber wieder ... siehe Screenshot)
Zitat[3]:
--------------------------------------------------------------------------------------------
0 1 2 3 4
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
--------------------------------------------------------------------------------------------
0 0 0 0 0 0 0 1 1 1 0 0 0 1 1 1 0 1 0 1 0 0 0 1 1 0 0 0 0 0 0 0 1 0 0 0 1 0 1 1 1 1
----[raw]----------------------------------------------------------------------------------
LD: 00 |ID: 00000111 |BAT: 00 |CH: 01 |TEMP: 110101000110 |HUM: 00000010 |CRC: 00101111
----[swapped]--------------------------------------------------------------------------
LD: 00 |ID: 11100000 |BAT: 00 |CH: 10 |TEMP: 011000101011 |HUM: 01000000 |CRC: 11110100
---------------------------------------------------------------------------------------
ld: 0
id: 7
id_c: 7
bat: 0
ch: 1
tempF: 0x64D (1613-900=713 / 10 = 71.3 °F => °C = (°F-32)/1.8 = 21,83 °C )
tempC: 21.83
hum: 2 <--- dieser Sensor sendet die Feuchte falsch (?! ) zeigt sie aber richtig an. (Batterie? Mein 2ter + 3ter senden richtig)
crc: 47
Habe jetzt Temperatur + Feuchte dekodiert.
Als nächstes kann ich dann das LaCrosse-Protokoll setzen und dann senden.
Da die LaCrosse-MaxId = 127 ist, kappe ich das höchste Bit der ID einfach ab.
Da ich den uint64_t-Datentyp nehme und die Bitdaten in einem Byte-Array speichere, war einges an Bitfummlei erforderlich.
Dann kamen noch Endian-Probleme bei Union/Struct dazu (swappen) ...
Vielleicht gibt es da doch noch eine elegantere Lösung (bitSet-Funktionen usw. gehen nur auf byte-Daten).
TODOS:
- Repetions zwischenpuffern.(Ringpuffer)
- nach dem Protokoll-Durchlauf (nach ca. 865ms ab 1. Protokoll) LaCrosseDaten senden.
- auf CRC-Prüfung verzichte ich.
- Erkennung: "bit 11 is set if manual send button was pressed".
Arduino-Code dafür ist hier (https://github.com/juergs/433ProtocolUmsetzer/blob/master/433ProtocolTransponder.ino) zu finden.
Grüße,
Jürgen
Hallo,
Ich habe jetzt zwei Dinge gemacht:
1. Die Definition der Userreadings gestrafft und in der Art des Moduls angepasst
2. Eine Teil-Errgänzung des Moduls geschrieben. Das soll für Björn lediglich eine Hilfe sein das Gerät dem Hauptmodul hinzuzufügen. Deshalb habe ich nur einen Teil bearbeitet. Wie das Ganze letztendlich im Modul eingebunden wird, weiß ich nicht, weil ich das Modul nicht kenne.
1. Userreadings:
stateHEX {my $s = (ReadingsVal($name,'state',''));
my @a = split(/\s+/,$s);
$s = @a[1];
return($s);},
LD {my $s = (ReadingsVal($name,'stateHEX',''));
my @a = split(//,$s);
my $ld = (hex($a[0])& 0xC);
$ld = sprintf( "%02b", hex( $ld ) );
return($ld);},
ID {my $s = (ReadingsVal($name,'stateHEX',''));
my @a = split("",$s);
my $u="";
$u = (hex($a[0].$a[1].$a[2])& 0x3FC) >> 2;
return($u);},
battery {my $s = (ReadingsVal($name,'stateHEX',''));
my @a = split(//,$s);
my $t = (hex(@a[2]) & 0x3);
if ($t eq "0"){$t="schwach";}
elsif ($t eq "1"){$t="gut";}
elsif ($t eq "2"){$t="top";}
return($t);},
channel {my $s = (ReadingsVal($name,'stateHEX',''));
my @a = split(//,$s);
my $t = (hex(@a[3]) & 0xC) >> 2;
if ($t eq "0"){$t="1";}
elsif ($t eq "1"){$t="2";}
elsif ($t eq "2"){$t="3";}
return($t);},
temperature {my $s = (ReadingsVal($name,'stateHEX',''));
my @a = split("",$s);
my $t= (hex($a[3].$a[4])& 0x3C) >> 2;
$t += ((hex($a[4].$a[5])& 0x3C) >> 2) * 16;
$t += ((hex($a[5].$a[6])& 0x3C) >> 2) * 256;
$t = (($t-900)/10 - 32)*5/9;
$t = int(10 * $t + 0.5) / 10;
return($t);},
humidity {my $s = (ReadingsVal($name,'stateHEX',''));
my @a = split("",$s);
my $t= (hex($a[6].$a[7])& 0x3C) >> 2;
$t += ((hex($a[7].$a[8])& 0x3C) >> 2) * 16;
return($t);},
2. Die Teilergänzung "NC_7427" für das Modul :
[font=courier]if ($readedModel eq "NC_7427" || (hex($a[0]) == 0x5 && $readedModel eq "Unknown")) {
# PEARL NC7427-675,
# /----------------------------------------------------- Leading-Sequence always 00
# / /--------------------------------------------------- ID, changes after every battery change
# / / /------------------------------------------- Battery state 10 == Ok, 01 == not bad, 00 == bad
# / / / /----------------------------------------- Channel 00 == Ch1, 01 == Ch2, 10 == Ch3
# / / / / /--------------------------------------- Temperature
# / / / / / /---------------------------- Humidity
# / / / / / / /------------------- CRC
# / / / / / / /
# 00 01101100 00 01 001101000110 01000010 00010100000000
# Bit 01 23456789 01 23 456789012345 67890123 45678901234567
# 1 2 3 4
# Byte | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 |10 | 11| 12
$temp = (hex($a[3].$a[4])& 0x3C) >> 2;
$temp += ((hex($a[4].$a[5])& 0x3C) >> 2) * 16;
$temp += ((hex($a[5].$a[6])& 0x3C) >> 2) * 256;
$temp = (($t-900)/10 - 32)*5/9;
$temp = int(10 * $t + 0.5) / 10;
$humidity = (hex($a[6].$a[7])& 0x3C) >> 2;
$humidity += ((hex($a[7].$a[8])& 0x3C) >> 2) * 16;
if (checkValues($temp, $humidity)) {
$model="NC_7427";
$channel = (hex(@a[3]) & 0xC) >> 2;;
$batbit = (hex(@a[2]) & 0x3);
$batbit = ~$batbit & 0x1; # Bat bit umdrehen
$mode = (hex($a[3]) & 0x4) >> 2;
if ($deviceCode ne $idType1) # new naming convention
{
if ( $enableLongIDs == TRUE || (($longids != "0") && ($longids eq "1" || $longids eq "ALL" || (",$longids," =~ m/,$model,/))))
{
Log3 $hash,4, "CUL_TCM97001 using longid: $longids model: $model";
} else {
$deviceCode="CUL_TCM97001_" . $model . "_" . $channel;
}
}
$def = $modules{CUL_TCM97001}{defptr}{$deviceCode};
if($def) {
$name = $def->{NAME};
}
if(!$def) {
Log3 $name, 2, "CUL_TCM97001 Unknown device $deviceCode, please define it";
return "UNDEFINED $model" . substr($deviceCode, rindex($deviceCode,"_")) . " CUL_TCM97001 $deviceCode";
}
$hashumidity = TRUE;
$hasbatcheck = TRUE;
$hasmode = FALSE;
$packageOK = TRUE;
$haschannel = TRUE;
$readedModel=$model;
} else {
$name = "Unknown";
}
}[/font]
Ich hoffe, dass Björn (oder jemand anderes) Zeit hat das Modul CUL_TCM97001 um diesen Teil "NC_7427" zu erweitern.
Viele Grüße
Eberhard
Hallo,
weiß Jemand wie das CRC welches zwischen bit34 und bit41 liegt gebildet wird? Wie geht das Modul CUL_TCM97001 mit einem nicht bekannten CRC um?
Gruß Eberhard
Hallo Eberhard,
boolean crcValid(unsigned long value, byte checksum)
// check if received crc is correct for received value
{
byte calculatedChecksum = 0;
for (int i = 0; i < 8; i++) calculatedChecksum += (byte)(value >> (i * 4));
calculatedChecksum &= 0xF;
return calculatedChecksum == checksum;
}
Konnte es aber nicht verifizieren:
unsigned long = 32 Bit = 4 Byte, scheint in diesem Fall nicht zureichen ?!
Jürgen
Hallo Jürgen,
wenn Du den Trailer von "00" nicht berücksichtigen würdest, kämst Du auf genau 32 Bit Nutzdaten:
ID = 8 bit, Batteriecheck=2 bit, KanalNr.=2 bit, Temperatur=12 bit und Feuchte= 8 bit. Ob das aber richtig ist entzieht sich meiner Kenntnis, weil die die Berechnung nicht nachvollziehen kann.
Trotzdem versuche ich es mal. Die Subroutine übergibt einmal die 32-bit-Zahl mit dem Namen value und die vom Sensor gelieferte checksum als Byte. Die calculatedChecksum wird mit checksum verglichen und und das Ergebnis des Vergleiches als True oder False zurückgeliefert. So weit - so gut. Wenn nicht die Schleife wäre >:(.
Die Schleife wird 8-mal durchlaufen. Die 32-bit werden achtmal um je 4 bit nach rechts geschoben. Aber was zu Teufel soll (byte)(value >> (i * 4))? Wie wird denn addiert? Ich könnte doch über einen Wert von 255 kommen und dann reichen die 8 bit nicht mehr aus. Oder? Hinzu kommt, dass das Ergebnis in einem Halbbyte mit 0xF binär addiert wird. Was ist mit dem anderen Nibble? Wohin mit dem Überlauf über die 8bit?
Ich habe ein Bitmuster der Nutzdaten (ohne Trailer) von: 0110 0111 0001 0111 0001 0101 0111 0010 . ID ist "103", BAT ist mit "00" als schlapp gekennzeichnet, Kanal ist "2",Temp ist nach Berechnung "4.6°C" und die rel. Feuchte ist "39%" (berechnet).
Die mitgelieferte CRC lautet: 0010 1101 also 45.
Wie komme ich jetzt auf die berechnete CRC?
Gruß Eberhard
Hallo Eberhard,
ich bin gerade noch am tüfteln wie ich die Dekodierung am performantesten hinbekomme.
Ich habe dabei folgende Probleme:
1. Die Wahl der Bitdekodierung basiert auf "stateless" Messen der Dauer jedes hereinkommenden Low-Impulses in der Interruptroutine.
Dabei darf die Ausführungszeit innerhalb des Interrupts nicht länger als die Low-Impulsphase sein. Mit serieller Ausgabe wird
das dann natürlich nichts. Deshalb hole ich mir die Einzelbits in ein Bytearray mit pro Byte ein Bit-Auflösung.
Das funktioniert schon zuverlässig gut.
2. Das ByteArray wird in die loop-Funktion übergeben und aus dem Array wird eine uint64_t Variable befüllt und soll vorerst in ein Ringpuffer gespeichert werden.
Dann wollte ich die "automatische" Dekodierung mittels Übergabe an Union/Struct erzielen,
hatte aber nicht die Endianness/Bitorder des GCC berücksichtigt. Also musste ich die Byteorder im ByteArray tauschen.
Dann kommt noch die Datenstruktur des Protokolls dazu, wo die High- und Low Nibbels z.B. der Temperatur getauscht werden müssen.
Das Ganze braucht Zeit, die während der Repetitions nicht zur Verfügung steht.
Muss also die weitere Verarbeitung ausserhalb der Erfassung der 6 Repetitions gelegt werden:
-> Ringpuffer + zeitverzögerte Verarbeitung -> in die Pausezeiten legen. (Algorithums dafür ausarbeiten ...)
3. Deshalb muss ich den Ablauf heute noch mal überdenken und versuchen etwas anders zu strukturieren.
Bin also leider noch nicht so weit, um mich um den CRC zu kümmern.
Aber versuchen wir mal aufzudröseln:
(byte)(value >> (i * 4))Die "value" kommt ja mit
uint32_t-Format rein. Das sind effektiv 4 Bytes à 8 Nibble (4Bit = 1 HalbByte).
Es werden jeweils 4 Bit in eine
byte-Variable geschoben ( for i=0; i<8 ...)
(also immer ein Halbbyte). Das AND-en mit 0xf soll sicherstellen, dass die oberen Bits (7..4) wirklich "0" sind.
Das heißt einfach, dass alle Nibble (Bit 0..3) aus "value" in einer einer
Byte-Variablen (uin8_t) aufaddiert werden.
Mehr scheint es nicht zu sein. Aber der Algoritmus muss nicht unbedingt passen (also ohne Gewähr).
Das ließe sich auch auf uint64_t-Format (8 Byte) aufbohren ...
Man müsste also ausprobieren was aufsummiert werden soll, damit es passt ...
Zitat
byte lead : 2;
byte id : 8;
byte bat : 2;
byte chan : 2;
unsigned short temp : 12;
byte hum : 8;
byte crc : 8;
2+8+2+2+12+8+8 = 42 (?), ließe man die Lead-Bits weg, die immer 0 sind, wären es 40 ....
Das ist aber eher untergeordnet, da ich mir aus dem "Bit"-ByteArray ja alle Datentypen auch direkt "konstruieren" kann :D
Zitat//
________________01234567890123456789012345678901 = 32 ohne lead und crc.
uint32_t value = 0b10111111000101000011011000010010; // CRC selbst: 0001.1100
Die trailing "0" hängen nur an der FHEM-Ausgabe dran und sind nicht im Protokoll vorhanden:
Zitat---------------------------------------------------------------------------------------
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
0 0 1 0 1 1 1 1 1 1 0 0 0 1 0 1 0 0 0 0 1 1 0 1 1 0 0 0 0 1 0 0 1 0 0 0 0 1 1 1 0 0
---------------------------------------------------------------------------------------
Aber: "Learning by doing" + "Nobody is perfect" ... ;)
/Edit: die Probleme handle ich mir im Wesentlichen durch die seriellen Debugausgaben ein. (;-((
Grüße,
Jürgen
Ausprobieren kann man das auch online: hier (https://www.tutorialspoint.com/compile_c_online.php) (ggf. auch in Perl hier (https://www.tutorialspoint.com/codingground.htm).)
#include <stdio.h>
#include <stdint.h>
uint8_t checkSumme=0b00011100;
//uint8_t crcValid(uint32_t value, uint8_T checksum);
uint8_t crcValid(uint32_t value, uint8_t checksum)
// check if received crc is correct for received value
{
uint8_t calculatedChecksum = 0;
printf("*** calc: %u\n",value);
int i = 0;
for (i = 0; i < 8; i++)
{
uint8_t nibble = (uint8_t)(value >> (i * 4));
calculatedChecksum += nibble;
printf("*** zwischen: val: %u \t- nibble: %d \t- sum: %d \n",value, nibble, calculatedChecksum);
}
calculatedChecksum &= 0xF;
return calculatedChecksum == checksum;
}
int main()
{
/* Unknown Code: 1CC311848280, 01C8D5808440, 01C8958085C0 */
printf("Hello, World!\n");
//.................01234567890123456789012345678901234567890123456789
//uint32_t value = 0x1CC311848280 ; //TODO: hier noch passend angeben ....
//.................01234567890123456789012345678901 2345678901
uint32_t value = 0b10111111000101000011011000010010; // CRC selbst: 0001.1100
uint8_t ret = crcValid(value, checkSumme);
printf("*** isChecksumOk: %d \n\n", ret);
return 0;
}
Hallo Jürgen,
Zitat2+8+2+2+12+8+8 = 42 (?), ließe man die Lead-Bits weg, die immer 0 sind, wären es 40 ....
Die CRC-Berechnung sollt m.E. nicht die CRC-bits selber einschließen, sondern nur die reinen Nutzdaten zur Berechning heranziehen; und das sind dann 32 bit!. Ich vergaß zu erwähnen, dass die letzten 6 bits auch immer "0" sind.
Ich weiß zwar nicht, was dein Ziel genau ist, ich würde wegen der Zeitprobleme zuerst die CRC prüfen und dann das Byte-Array bei bestandener CRC-Prüfung aus dem Puffer nehmen und die Wiederholungen, da mit identischen CRC, verwerfen. Danach hast Du alle Zeit der Welt das Array aufzubereiten. Deshalb ist es IMHO so wichtig die CRC-Prüfung hinzubekommen.
Deshalb zum Thema CRC ;):
ZitatEs werden jeweils 4 Bit in eine byte-Variable geschoben ( for i=0; i<8 ...)
Das müssten dann die ersten 4 Bit von rechts sein, also "0010" aus meinem Beispiel.
ZitatDas AND-en mit 0xf soll sicherstellen, dass die oberen Bits (7..4) wirklich "0" sind.
Angenommen danach enthält (byte) das Muster "xxxx 0010", dabei ist x beliebig, entweder 1 oder 0. Durch die binäre Addition bleiben die beliebigen "1" auf dem WErt "1", da 1 &1 =1 ergibt . Nur mir einem negierten Halbbyte bekommst du ein definiertes "0". Oder sehe ich das was falsch?.
Zitatin einer einer Byte-Variablen (uin8_t) aufaddiert werden.
Diese Werte werden aber dezimal aufsummiert. Der Überlauf geht dann in die 4 oberen Bits.
Der Code aus Deiner sub crcValid ist doch ein C-Code. Die Schleife wirkt ja nur auf die eine Zeile. Wenn Die fertig ist, addierst Du dem Ergebnis binär die 4 höherwertigen Bits hinzu. ERgebnis: "1" bleibt "1" und "0" bleibt "0". Für die Schreibweise würde ich die Schleife in {} packen, dann ist alles besser lesbar (für mich wenigstes) 8).
Da sind noch viel Fragen für mich offen.
Viele Grüße
Eberhard
Hallo Eberhard,
ZitatRC-Berechnung sollt m.E. nicht die CRC-bits selber einschließen
Zustimmung!
Zitatwegen der Zeitprobleme zuerst die CRC prüfen und dann das Byte-Array bei bestandener CRC-Prüfung aus dem Puffer nehmen und die Wiederholungen, da mit identischen CRC, verwerfen. Danach hast Du alle Zeit der Welt das Array aufzubereiten.
Ja stimmt, allerding kommen meine Daten über alle Repetitions korrekt an, obwohl mein 433MHz-Bereich hier sehr "überfüllt" ist.
Allerdings liegt es wohl daran, dass der Sensor 1m neben der Antenne liegt. ;D
Zitat
//______________01234567890123456789012345678901_____________2345678901
uint32_t value = 0b10111111000101000011011000010010; // CRC selbst: 0001.1100
Nehmen wir dieses Beispiel: "1011.1111.0001.0100.0011.0110.0001.0010"
i=0 shift=0 Nibble = 0010 Nibble & 0xF = 0000.0010 sum = 2 // Anm.: Nibble ist vor dem AND = 0001.0010 (!)
i=1 shift=4 Nibble = 0001 Nibble & 0xF = 0000.0001 sum = 2 + 1 = 3
i=2 shift=8 Nibble = 0110 Nibble & 0xF = 0000.0110 sum = 2 + 1 + 6 = 9
usw.... OK?
ZitatDiese Werte werden aber dezimal aufsummiert. Der Überlauf geht dann in die 4 oberen Bits.
Ja + ja. Aber die Summe steht ja in "calculatedChecksum" und die bleibt vom And unangetatstet.
Der mögliche Überlauf bei > 255 wird verworfen ...
ZitatDie Schleife wirkt ja nur auf die eine Zeile.
So sieht man es besser:
Zitatfor (i = 0; i < 8; i++)
{
uint8_t nibble = (uint8_t)(value >> (i * 4));
calculatedChecksum += nibble;
printf("*** zwischen: val: %u \t- nibble: %d \t- sum: %d \n",value, nibble, calculatedChecksum);
}
Zitat
*** calc: 3205772818
*** zwischen: [0 ] val: 3205772818 chksum: 28 - nibble: 18 - sum: 18
*** zwischen: [1 ] val: 3205772818 chksum: 28 - nibble: 97 - sum: 115
*** zwischen: [2 ] val: 3205772818 chksum: 28 - nibble: 54 - sum: 169
*** zwischen: [3 ] val: 3205772818 chksum: 28 - nibble: 67 - sum: 236
*** zwischen: [4 ] val: 3205772818 chksum: 28 - nibble: 20 - sum: 0
*** zwischen: [5 ] val: 3205772818 chksum: 28 - nibble: 241 - sum: 241
*** zwischen: [6 ] val: 3205772818 chksum: 28 - nibble: 191 - sum: 176
*** zwischen: [7 ] val: 3205772818 chksum: 28 - nibble: 11 - sum: 187
*** checksum == 28 = false // da 187
besser ... ?
Hall Jürgen,
ich sag' nur eines: nicht besser => fantastisch!!!
Jetzt komme ich weiter. Hab' vielen Dank.
Gruß
Eberhard
Hallo,
jetzt passt es auch bei meinem Code mit dem passenden Timing.
Ringpuffer ist auf 16 Elemente definiert. Erlaubt also mindestens 3 Sensoren direkt,
quasi gleichzeitig, einzulesen. Sind es mehr als 3 Sensoren werden die älteren Elemente überschrieben.
Die Wartezeit nach dem Empfang des ersten Protokoll bis zur ersten Ausgabe ist auf 5 s eingestellt.
Was dann letztendlich über LaCrosse wieder weiter versendet wird (Repetitions) werde ich noch klären.
Ebenfalls den CRC. ;)
Zitat
Stored: 0 -> während Erfassung der Repetitions nur 64Bit-"Value" bilden und im Ringpuffer speichern.
Stored: 1
Stored: 2
Stored: 3
Stored: 4
Stored: 5 -> alle 6 Repetitions erfasst!
### Nach der Erfassung (+5s bei 30s Sende-Pause eines Sensors) :
buffer.read: [0 ] ---> nach den Repetitions bleibt Zeit auszuwerten
0001101100100010100101010110000001110011000000000000000000000000
ld: 0
id: 115
id_c: 115
bat: 0
ch: 0
tempF: 0x659
tempC: 22.50
hum: 34
crc: 27
raw: 1955289429710995456
------------------------------------------------------------
buffer.read: [1]
0001101100100010100101010110000001110011000000000000000000000000
ld: 0
id: 115
id_c: 115
bat: 0
ch: 0
tempF: 0x659
tempC: 22.50
hum: 34
crc: 27
raw: 1955289429710995456
------------------------------------------------------------
buffer.read: [2]
0001101100100010100101010110000001110011000000000000000000000000
ld: 0
id: 115
id_c: 115
bat: 0
ch: 0
tempF: 0x659
tempC: 22.50
hum: 34
crc: 27
raw: 1955289429710995456
------------------------------------------------------------
buffer.read: [3]
0001101100100010100101010110000001110011000000000000000000000000
ld: 0
id: 115
id_c: 115
bat: 0
ch: 0
tempF: 0x659
tempC: 22.50
hum: 34
crc: 27
raw: 1955289429710995456
------------------------------------------------------------
buffer.read: [4]
0001101100100010100101010110000001110011000000000000000000000000
ld: 0
id: 115
id_c: 115 --> LaCrosse kann nur IDs < 127
bat: 0
ch: 0
tempF: 0x659
tempC: 22.50
hum: 34
crc: 27
raw: 1955289429710995456
------------------------------------------------------------
buffer.read: [5]
0001101100100010100101010110000001110011000000000000000000000000
ld: 0
id: 115
id_c: 115
bat: 0
ch: 0
tempF: 0x659
tempC: 22.50
hum: 34
crc: 27
raw: 1955289429710995456
------------------------------------------------------------
Dann kann ich morgen das LaCrosse-Protokoll einbauen ... :)
@Eberhard,
könntest Dir mal dieses Thema anschauen:
https://forum.fhem.de/index.php/topic,17196.msg259697.html#msg259697 (https://forum.fhem.de/index.php/topic,17196.msg259697.html#msg259697)
https://github.com/mdorenkamp/fhemduino_modules/blob/master/14_FHEMduino_Env.pm (https://github.com/mdorenkamp/fhemduino_modules/blob/master/14_FHEMduino_Env.pm)
Dort ist die 35-Bit-Variante für Fhemduino behandelt. Vielleicht läßt sich das umbauen?
Jürgen
Transponder: NCS ==> LaCrosse(433Mhz)
Zitat------------------------------------------------------------
buffer.read: [1]
0000110100100010101001000110000011110001000000000000000000000000
ld: 0
id: 241
id_c: 113
bat: 0
ch: 0
tempF: 0x64A
tempC: 21.67
hum: 34
crc: 13
raw: 946499607968350208
------------------------------------------------------------
FUNC ID: 113 [113] T: 21.67 H: 34.00
TX ID: 113 T: 21.67 H: 34.00
------------------------------------------------------------
Zitat2017-01-29 10:27:59 CUL_TCM97001 Unknown Code: 01CA91808040
2017-01-29 10:27:59 CUL_TCM97001 Unknown Code: 01CA91808040
2017-01-29 10:27:59 CUL_TCM97001 Unknown Code: 01CA91808040
2017-01-29 10:28:00 CUL_TCM97001 Unknown Code: 01CA91808040
2017-01-29 10:28:00 CUL_TCM97001 Unknown Code: 01CA91808040
2017-01-29 10:28:05 CUL_TX CUL_TX_7 H: 02.0
2017-01-29 10:28:05 CUL_TX CUL_TX_7 humidity: 02.0
2017-01-29 10:28:06 CUL_TX CUL_TX_7 H: 02.0
2017-01-29 10:28:06 CUL_TX CUL_TX_7 humidity: 02.0
2017-01-29 10:28:06 CUL_TX CUL_TX_7 H: 02.0
2017-01-29 10:28:06 CUL_TX CUL_TX_7 humidity: 02.0
Muss noch die Toleranzen im LaCrosseProtocoll abstimmen, dann sollte es passen. :)
hallo Jürgen,
das sieht ja gut aus! Das sind Daten aus dem Sensor NC-7427? Hast Du denn eine Übereinstimmung mit dem CRC zwischen Deiner Berechnung und dem mitgelieferten CRC? Wie sieht denn der HEX-Code aus? Ist das 01CA91808040?
Mit den beiden Links bin ich noch nicht fertig. Gerade den 2. muss ich mal ausprobieren.
Gruß
Eberhard
Hallo Eberhard,
ZitatDas sind Daten aus dem Sensor NC-7427?
Ja, zurechtgebogen, wenn die ID > 127 ist.
Da bei mir Funk-technisch viel los ist .... muss man eben die Batterie kurz rausnehmen wenn die ID nicht passt. ;)
Zum CRC bin ich noch nicht gekommen.. weil ich dort (https://forum.fhem.de/index.php/topic,59933.msg572030.html#msg572030) auch noch unterwegs war ...
Dennoch scheint es mir doch erforderlich zu sein ...
Aber zwei Projekte gleichzeitig artet etwas in "Streß" aus ;)
Also "One after the other" ...
Zitat2017-01-29 17:46:40 CUL_TCM97001 Unknown Code: 01C8D18481C0
2017-01-29 17:46:40 CUL_TCM97001 Unknown Code: 01C8D18481C0
2017-01-29 17:46:40 CUL_TCM97001 Unknown Code: 01C8D18481C0
2017-01-29 17:46:40 CUL_TCM97001 Unknown Code: 01C8D18481C0
2017-01-29 17:46:40 CUL_TCM97001 Unknown Code: 01C8D18481C0
2017-01-29 17:46:45 CUL_TX CUL_TX_7 H: 18.0
2017-01-29 17:46:45 CUL_TX CUL_TX_7 humidity: 18.0
2017-01-29 17:46:46 CUL_TX CUL_TX_7 H: 18.0
2017-01-29 17:46:46 CUL_TX CUL_TX_7 humidity: 18.0
Man sieht hier, das 5 Sekunden nach dem Empfang des NCS-Protokolls das LaCrosse feuert ... :)
ZitatWie sieht denn der HEX-Code aus? Ist das 01CA91808040?
Sorrry, sind etwas zusammengestückelte Infos, da ich 2 Sensoren habe, ID 7 (TEMP = ok, liefert (noch) HUM falsch) und ID 113 (der eigentlich 241 ist, TEMP+HUM = ok)
Die HW-Signale kommen aber in der Tat so rein, und werden halt 1:1 dekodiert + weitergegeben ...
ZitatStored: 2
buffer.read: [2]
0001001100100010000101000110000011110001000000000000000000000000
ld: 0
id: 241
id_c: 113
bat: 0
ch: 0
tempF: 0x641
tempC: 21.17
hum: 34
crc: 19
raw: 1378686842521518080
------------------------------------------------------------
FUNC ID: 113 [113] T: 21.17 H: 34.00
TX ID: 113 T: 21.17 H: 34.00
------------------------------------------------------------
Außerdem bekomme ich auch noch einige Nachbarsensoren mit dem NCS-Protokoll und ca. 6 eigene LaCrosse-Sensoren und einmal Bodenfeuchte mit 2 Ids rein.
Da diese weiter entfernt sind, kommen weniger Repetitions durch....
Leider kommt gerade bei LaCrosse die Temperatur noch nicht zu FHEM durch, obwohl die Daten dazu gesendet werden. (Siehe Log unten).
(hatte neulich auf aculw umgestellt und dann nicht mehr ausprobiert).
Das ist also auch noch eine Baustelle, evtl. muss ich die Timings dort noch etwas anpassen, da die Feuchte als zweite
Sende-Impulsreihe ausgesendet wird. (Vielleicht stimmt das Pausetiming zwischen TEMP+HUM-Output noch nicht ganz, mal analysieren).
Wenn es zu arg nervt, dann switche ich auf das Hideki-Protokoll um...
Ich hänge mal den aktuellen Stand des Sources (
... as is ..) mal hier an.
Werde dann aber auf Github (https://github.com/juergs) weitermachen.
Hardware:
RX Arduino Pin 2 (INT)
TX Arduino PIN 5 (frei wählbar)
Grüße,
Jürgen
Hi Jürgen,
ich muss nochmal auf den CRC-Check zurückkommen:
ZitatCode: [Auswählen]
(byte)(value >> (i * 4))
Die "value" kommt ja mit uint32_t-Format rein. Das sind effektiv 4 Bytes à 8 Nibble (4Bit = 1 HalbByte).
Es werden jeweils 4 Bit in eine byte-Variable geschoben ( for i=0; i<8 ...) (also immer ein Halbbyte).
Das AND-en mit 0xf soll sicherstellen, dass die oberen Bits (7..4) wirklich "0" sind.
Das heißt einfach, dass alle Nibble (Bit 0..3) aus "value" in einer einer Byte-Variablen (uin8_t) aufaddiert werden.
Mehr scheint es nicht zu sein. Aber der Algoritmus muss nicht unbedingt passen (also ohne Gewähr).
Das ließe sich auch auf uint64_t-Format (8 Byte) aufbohren ...
Man müsste also ausprobieren was aufsummiert werden soll, damit es passt ...
Zitat:
Die "value" kommt ja mit uint32_t-Format rein. Das sind effektiv 4 Bytes à 8 Nibble. Diese Aussage ist soweit falsch, als dass 4Bytes aus insgesamt 8 Nibbles bestehen.
Zitat:
Es werden jeweils 4 Bit in eine byte-Variable geschoben ( for i=0; i<8 ...) (also immer ein Halbbyte). Das AND-en mit 0xf soll sicherstellen, dass die oberen Bits (7..4) wirklich "0" sind. Dann dürften in dem Programmbeispiel die WERte für die einzelnen Nibbles niemals 16 überschreiten. Also gehört dan AND-en mit 0xF in die Schleife hinein.
Die Zeile darf auch nicht:
calculatedChecksum &=0xF ;heißen sondern muß lauten:
nibble&=0xF;Die Schleife lautet dann:
{
uint8_t nibble = (uint8_t)(value >> (i * 4));
nibble &= 0xF;
calculatedChecksum += nibble;
printf("*** zwischen: val: %u \t- nibble: %d \t- sum: %d \n",value, nibble, calculatedChecksum);
}Jetzt bin ich mit Klugscheissen fertig! ;) Dann lautet das Ergebnis:
ZitatHello, World!
*** calc: 3205772818
*** zwischen: val: 3205772818 - nibble: 2 - sum: 2
*** zwischen: val: 3205772818 - nibble: 1 - sum: 3
*** zwischen: val: 3205772818 - nibble: 6 - sum: 9
*** zwischen: val: 3205772818 - nibble: 3 - sum: 12
*** zwischen: val: 3205772818 - nibble: 4 - sum: 16
*** zwischen: val: 3205772818 - nibble: 1 - sum: 17
*** zwischen: val: 3205772818 - nibble: 15 - sum: 32
*** zwischen: val: 3205772818 - nibble: 11 - sum: 43
*** isChecksumOk: 0
Die mitgelieferte war 28 und nicht 43.
Mach ich da einen Denkfehler, oder ist das richtig? Check das bitte erst dann, wenn das andere Projekt fertig ist. Ich habe Zeit.
Gruß Eberhard
Ok, Du hast mich jetzt verwirrt ;)
Vielleicht ist auch der Name der Variablen irreführend.
Das AND wird ja benötigt weil beim 4 BIT rechtsschieben ja 8 Bit von "value" in die Byte-Variable "Nibble" gelangen.
Der nicht erwünschte höherwertige Teil wird mit dem AND 0xF verworfen. Das bei
jedem 4er Bit schieben.
Soweit, denke ich, war mein Beispiel eigentlich ok.
Vielleicht muss man wie bei den anderen Werten auch LOW- und High-Nibble des CRCs tauschen ?
Bin leider gedanklich gerade noch nicht beim CRC, deshalb noch etwas Geduld ...
Github zickt gerade etwas herum, habe das Projekt aber soweit jetzt dort verankern können,
dass ich damit arbeiten kann.
Zitat! [rejected] master -> master (non-fast-forward)
error: failed to push some refs
Hier unter NCS-433-Transponder (https://github.com/juergs/NCS-433-Transponder) ist der aktuelle Source zu finden.
Grüße,
Jürgen
:) :) Die Pause von 1 Sekunde zwischen TEMP und HUM hat geholfen:
Zitat2017-01-29 19:12:32 CUL_TCM97001 Unknown Code: 01C9D1848300
2017-01-29 19:12:32 CUL_TCM97001 Unknown Code: 01C9D1848300
2017-01-29 19:12:32 CUL_TCM97001 Unknown Code: 01C9D1848300
2017-01-29 19:12:32 CUL_TCM97001 Unknown Code: 01C9D1848300
2017-01-29 19:12:32 CUL_TCM97001 Unknown Code: 01C9D1848300
2017-01-29 19:12:38 CUL_TX CUL_TX_7 T: 21.4 H: 18.0
2017-01-29 19:12:38 CUL_TX CUL_TX_7 temperature: 21.4
2017-01-29 19:12:39 CUL_TX CUL_TX_7 T: 21.4 H: 18.0
2017-01-29 19:12:39 CUL_TX CUL_TX_7 humidity: 18.0
2017-01-29 19:12:42 CUL_TX CUL_TX_7 T: 21.4 H: 18.0
Die Anzahl der LaCrosse-Protokolle entspricht der Anzahl der NCS-Repeats .... :D
Hallo juergs,
mal ne ganz doof Frage. Wie bekomm ich denn deinen Github Code als Modul.pm in mein System? ???
Hallo DodiHudori,
ZitatWie bekomm ich denn deinen Github Code als Modul.pm in mein System?
Ist leider ein Mißverständnis.
Der Code ist für einen Arduino gedacht, der die Telegramme des NCS7427 aufnimmt und in LaCrosse Telegramme-übersetzt
und wieder versendet. Die erscheinen dann als CUL_TX-Sensortyp, da FHEM diesen Typ kennt.
Das ist eine "Notlösung" um diese Art von Sensoren einzubinden und hat für mich den Charme,
dass dabei gleich eine Reichweitenerhöhung dabei heraus springt.
Ebenso aus einer gewissen "Ratlosigkeit" wie und von wem neue Module in FHEM eingebunden werden.
Der Aufwand dazu ist nicht unerheblich ... und sidey und bjoernh sind ja gut beschäftigt ;)
Aber Eberhard (FHEm2005) wollte sich dem FHEM-Perl-Code annehmen. Teile hat er dazu ja schon umgesetzt.
Vielleicht kann er Dir mit einer Anleitung weiterhelfen, wie man sein Code in schon existierende Module mit einbindet?
@Eberhard:
Die CRC-Berechnung ist erforderlich, da überlagerte Telegramme zwangsläufig nicht korrekt sind und u. U. Müll fabrizieren.
Also als nächstes die Integration der CRC-Berechnung. (morgen...)
Grüße,
Jürgen
Durch Zufall habe ich eine fast elegantere und einfache Methode entdeckt, das NCS-Protokoll zu erfassen.
Es wird auf Interruptverarbeitung verzichtet und benutzt den Arduino Befehl "pulseIn"
der die PulseDauer in uS zurückgibt und in dieser Zeit aber die Code-Ausführung blockiert.
/*
Liest dieses komische Tchibo-Wetterdingens per 433MhZ aus.
*/
#define telegramLength 42
boolean cnt=false;
int reader=0;
int cnter=0;
char reading[telegramLength];
int decodeTemp(String bitstream);
char decodeTime(int time);
//-------------------------------------------------
void setup()
{
Serial.begin(57600);
Serial.println("*** go! **");
pinMode(2, INPUT);
pinMode(13,OUTPUT);
pinMode(12,OUTPUT);
digitalWrite(12,LOW);
}
//-------------------------------------------------
void loop()
{
//digitalWrite(12,LOW);
int LowVal=pulseIn(2,LOW);
//digitalWrite(12,HIGH);
if (LowVal < 11000)
{
// Kuezer als 1100ms Low ? Koennte unserer Sensor sein
if (decodeTime(LowVal) == 'S')
{
// Startsequenz ?
cnt=true; // Dann go fuer die Sammlung
cnter=0; // BitCounter auf 0
//Serial.println("S*");
}
if ( (cnter<=(telegramLength-1)) && cnt && ((decodeTime(LowVal) == '0') || (decodeTime(LowVal)=='1')))
{
// Stream noch nicht voll und ein Bit erkannt ?
//Serial.print(decodeTime(LowVal));
//Serial.print("LV: ");
//Serial.println(LowVal);
reading[cnter] = decodeTime(LowVal); // Ab ins Array damit
cnter = cnter+1; // Arraycounter fuers naechste Bit inkrementieren
}
}
else
{
cnt=false; // Zurueck auf Anfang - nix fuer uns.
//Serial.print("R*");
}
if ((cnter == telegramLength))
{
// Arrray Voll ?
Serial.print('/');
Serial.print(reading);
Serial.print('/');
Serial.println(decodeTemp(reading));
cnter=0;
cnt=false;
}
}
//-------------------------------------------------
//float decodeTemp(String bitstream)
int decodeTemp(String bitstream)
{ // Versucht aus dem Bitstrom die Temp. zu berechnen
int x=0;
int chk=0;
for (int i=15;i<27;i++)
{
// Extrahiert das Byte zwischen Bit 16 und 24 und packt es als integer in "x"
if (bitstream[i] == '1')
{
bitSet(x,(26-i));
}
}
//for (int i=4;i<15;i++)
for (int i=2;i<10;i++)
{
// Kenner aus den 3 Nibbles zwischen Bit 4 und 15 holen (koennte auch der Kanal sein ?)
if (bitstream[i] == '1')
{
//bitSet(chk,(14-i));
bitSet(chk,(9-i));
}
}
Serial.print("ID: "); Serial.print(chk); Serial.print(" / ");
/*
if (chk != 136)
{ // Kenner = 136 ? Dann ist es unserer Sensor !
return(-999); // Wenn nicht, dann -999 zurueck
}
else
{
*/
return x;
//return ((float)((int)x-900)/10);
//}
}
//-------------------------------------------------
char decodeTime(int time)
{ // Wandelt die Pulse in Bits um.
if (time > 700 && time < 11000)
{
// passendes Signal (zwischen 150ms und 11000ms) ?
if (time < 2200)
{
// kleiner 250ms ? Dann LOW
return '0';
}
if (time < 5000 && time >3900)
{
// Zwischen 500ms und 1000ms dann HIGH
return '1';
}
if (time > 7800)
{
// Groesser 8ms dann Startsequenz !
return 'S';
}
}
else
{
return 'X';
}
}
Zum CRC:
01|2345.6789|01|23|4567.8901.2345|6789.0123|4567.8901 (Bitposition)
00|0100.1110|00|00|0111.0100.0110|0011.0010|0001.1100 ID: 78 (raw)
HEX 4 E 7 4 6 32 CRC: 1 C 4 + E + 7 + 4 + 6 + 3 + 2 = 0x28
00|1110.0100|00|00|0110.0100.0111|0010.0011|11000001 (gedrehte nibble)
HEX E4 6 4 7 23 C 1
0x647 = 1607 dez - 900 dez /10 = 70,7 = 21.5 °C
0x23 = 35 % LF
(4E & 0xF) + (0x746 & 0xF) + (0x32 &x0F) = E + 6 + 2 = 0xD
(E4 & 0xF) + (0x647 & 0xF) + (0x23 &x0F) = 4 + 7 + 3 = 0xE
... Ideen?
Hallo Jürgen,
das Einzige, was mir auffällt ist die Rechnung E + 6 + 2 = 0xD . Das Ergebnis passt nicht, IMHO ist das Ergebnis 16 oder binär 0001 0110 .
Der Datenblock umfasst 8 Nibble, bei Dir sehe ich nur 7. Du hast das Nibble bit 10 bis bit 13 nicht berücksichtigt. Ist zwar 0x0, aber ich weiß nicht, ob es bei der byteweisen Berechnung irgendwie eine Rolle spielt.
Ich komme bei der CRC-Berechnung (ungedreht) auf 48dez bzw. 30HEX. Ich habe Dir mal meine Berechnung angehängt. Darin sind aus der Arduino-Berechnung die Werte der Schleife mal schrittweise aufgedröselt. Die Nibbles werden von hinten gezählt, da ja nach rechts geschoben wird. Ändert aber am Ergebnis nix.
Gruß
Eberhard
Hallo Eberhard,
danke, werde morgen damit weitermachen.
Zwischenzeitlicht habe ich noch mal das hier (http://www.f6fbb.org/domo/sensors/tx3_th.php) gesichtet.
Evtl. ist die dortige CRC-Bildung angepasst verwertbar....
Ohne es genau angeschaut zu haben:
vielleicht ist es so "Checksum: (0 + A + E + 0 + F + 5 + 2 + 0 + 5 + 2) and F = 5" gemeint?
Grüße,
Jürgen
Hallo Jürgen,
so geht es auch nicht.
Mein Beispiel:
Datentelegramm: 19C6CDA08040
Enthaltene Nibble-Werte: ( 6+7+1+11+3+6+8+2) & F = 44 &F= 0010 1100 &F = C . Soll war leider "1". Ergo => So nicht! :(
2. Versuch mit 2er Gruppen: geht aus nicht. >:(
3. Versuch mit negierten Nibbel-Werten: (9+8+14+4+12+9+7+13) & F = 76 & F = 0100 1100 &F = C . So auch nicht :'(
Ich werde Weiters versuchen und hier notfalls ergänzen.
Gruß Eberhard
Ich habe das hier gefunden: http://forum.iobroker.net/viewtopic.php?t=3818
HIER DIE LÖSUNG!
z.B.: 782°F 75%
00 10101000 0 1 10 0010 1001 0110 1011 0100 00010000
aa I______I B B KK TTTT TTTT TTTT HHHH HHHH chksum
aa= Präạmbel
I_I = Sensor ID, ändert sich jedes Mal, wenn man die Batterie wechselt (Stromlos macht)
B = Trend für Temperatur/ Humidity (00=bei dem ersten Wert nach dem Batt. wechsel)
KK= Kanal 1=00, 2=01, 3=10
TTTT=Binär in Dez., Dez als HEX, HEX in Dez umwandeln (z.B. 0010=2Dez, 2Dez=2 Hex) 0010=2 1001=9 0110=6 => 692HEX = 1682Dez = >1+6=7 UND 82 = 782°F
HH=(wie oben)Binär in Dez., Dez als HEX, HEX in Dez umwandeln (z.B. 1011=11Dez, Dez=B Hex / 0100=4Dez=4HEX => (von hinten lesen)4BHEX (von hinten lesen)=75 Dez.)
chksum= Prüfsumme
das war's !!!
Hallo JoWiemann,
hast Du mal 732°F in Celsius umgerechnet? Das sind schlappe 388,9° in Celsius. ;) Nehmen wir mal an, es wären 73,2°F dann liegen wir bei 23,9 ziemlich gut!
Das B ist und bleibt m.E. ein Batteriestatus. Der wechselt nämlich nicht, egal welche Historie die Temperaturen hinter sich haben.
Die Decodierung ist ja schon abgeschlossen. Dass unsere momentane Interpretation stimmt, kann ich bei mir am Schreibtisch ablesen, das stehen zwei Thermometer/Feuchtigkeitsmesser dieses Types rum. Wir hängen momentan "nur" noch noch an der Prüfsumme. Hast Du da weitere Informationen und Tipps bzgl der Prüfsumme?
Gruß
Eberhard
Hallo,
ich glaube wir müssen wieder "back to the roots":
boolean crcValid(unsigned long value, byte checksum)
// check if received crc is correct for received value
{
byte calculatedChecksum = 0;
for (int i = 0 ; i < 8 ; i++)
{
calculatedChecksum +=(byte)(value >> (i*4));
}
calculatedChecksum &= 0xF;
return calculatedChecksum == checksum;
}laut hier wird nur das Ergebnis mit 0x0F ge-AND-det.
Dann kommt es nur auf die Bitwerte an, ob nibble gedreht oder nicht gedreht sind
oder nur auf die Rohdaten ...
Zitatif (bitsCounted>=KW9010_MESSAGELEN) // all bits received
{
if (crcValid(rxBits,crcBits)) fifoWrite(rxBits); // write valid value to FIFO buffer
else fifoWrite(0); // write 0 to FIFO buffer (0 = invalid value received)
rxBits=0;
crcBits=0;
bitsCounted=0;
}
static unsigned long rxBits=0;ist also ein LONG mit 4 Bytes! Nachdem das volle Telegramm eingelesen wurde.
Hier werden die "1" Bits gesetzt und je nach Position in Daten und CRC getrennt:
Zitatelse if (LowVal>KW9010_ONE-KW9010_GLITCH && LowVal<KW9010_ONE+KW9010_GLITCH)
{ // set the one bits
if (bitsCounted<32)
bitSet(rxBits,bitsCounted);
else
bitSet(crcBits,bitsCounted-32);
bitsCounted++;
}
D.h. der CRC wir nur über die Rohdaten gebildet, also ohne Nibble-Tauschen.
Zitat
_________8__2__2___4____4___4_______8 = 32 Bit = LONG
__ 12345678 9 0 12 3456 7890 1234 5678 9012
12 34567890 1 2 34 5678 9012 3456 7890 1234 56789012
00 10101000 0 1 10 0010 1001 0110 1011 0100 00010000
aa I______I B B KK TTTT TTTT TTTT HHHH HHHH chksum
Prämbel bliebe mal außen vor, da sowieso immer 0.
Also wird gebildet:
(ID + Bat mit Kan (nibble oder einzeln? eher nibble) + temp + hum) AND 0xF = CRC
Probiere ich morgen noch aus ...
Grüße,
Jürgen
Hallo Jürgen,
habe (ID + Bat mit Kan (nibble oder einzeln? eher nibble) + temp + hum) AND 0xF = CRC mal in beiden Versionen getestet.
Telegramm: 1C23B96C8300, CRC:12,
Art: Bat und Kanal getrennt(einzeln),
CRC (dez): 4105,
CRC(binär):1 0000 0011 0110,
ge-UND-et: 0110
CRC (ist): 6
Telegramm: 1C23B96C8300, CRC:12,
Art: Bat und Kanal gemeinsam (nibble),
CRC (dez): 4111,
CRC(binär):1000000001111,
ge-UND-et: 1111
CRC (ist): 15
So geht es auch nicht! :( :(
Gruß Eberhard
weitere Versuche mit:
- (Bat mit Kan (nibble) + temp + hum) AND 0xF = CRC Ergebnis: CRC(ist) = 15
- (temp + hum) AND 0xF = CRC Ergebnis: CRC(ist) = 7
waren erfolglos.
Gruß Eberhard
Hallo Eberhard,
Zitat
2017-02-05 10:20:42 CUL_TCM97001 Unknown Code: 31080DA0B140
2017-02-05 10:21:34 CUL_TCM97001 Unknown Code: 31090DA481C0
2017-02-05 10:23:25 CUL_TCM97001 Unknown Code: 310ACDA08180
HEX: 31080DA0B140
00000000010000000002000000000300000000040000000005
12345678901234567890123456789012345678901234567890
1100010000100000001101101000001011000101000000
HEX: 31090DA481C0
00000000010000000002000000000300000000040000000005
12345678901234567890123456789012345678901234567890
1100010000100100001101101001001000000111000000
HEX: 310ACDA08180
00000000010000000002000000000300000000040000000005
12345678901234567890123456789012345678901234567890
1100010000101011001101101000001000000110000000
Zum Vergleich mit Rohdaten:
Zitat
[1]:
------------------------------------------------------------
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
0 0 1 0 1 1 1 1 1 1 0 0 0 1 0 1 0 0 0 1 0 0 0 1 1 0 0 0 1 0 0 0 1 0 0 0 0 0 1 1 0 0
---------------------------------------------------------------------------------------
LD: 00 |ID: 10111111 |BAT: 00 |CH: 01 |TEMP: 010001000110 |HUM: 00100010 |CRC: 00001100
---------------------------------------------------------------------------------------
[ 2] ID: 1 - 1
[ 3] ID: 1 - 0
[ 4] ID: 3 - 1
[ 5] ID: 7 - 1
[ 6] ID: 15 - 1
[ 7] ID: 31 - 1
[ 8] ID: 63 - 1
[ 9] ID: 127 - 1
------------------------------------------------------------
ld: 0
id: 127
bat: 0
ch: 2
temp: 785
hum: 34
crc: 34
Raw: 1739006387398115328
Ein paar empfangene Sensordaten.
Im Moment sehe ich nur, dass der von FHEM gelieferte HEX-Wert nicht zum 42Bit-Protokoll passt.
Hinten hängen ein paar "0" zuviel dran ...
Nehmen wir das als Beispiel:
ZitatHEX: 310ACDA08180
00000000010000000002000000000300000000040000000005
12345678901234567890123456789012345678901234567890
1100010000101011001101101000001000000110000000
und fügen erst mal die Leads hinzu:
123456789012345678901234567890123456789012 > 42 entfällt.
001100010000101011001101101000001000000110 000000
bleibt als Rohdaten:
001100010000101011001101101000001000000110
aufgedröselt:
LL_ID______BB_CC__TEMP______HUM_____CRC
00 11000100 00 10 101100110110 10000010 00000110
ID___ 0xC4=196
CH______________2
TEMP________________ 1011.0011.0110 = 2870 oder 0x0B =11 | 0x03 | 0x06
HUM_____________________________10000010 = 0x82 = 130
______________________________________00000110 = 0x6
1. 196+2+11+3+6+130 == 6? => 344 AND 0x0F = 8
2. 196+2+2870+130 == 6? => 3198 AND 0x0F = 14
Muß dazu sagen, dass bei mir in der Gegend große Sensor-Betriebsamkeit herrscht ...
D.h. es könnten auch "falsche" Protokolle sein, die in die CUL-Erfassung rutschen.
Denkfehler (?) und weiter knobeln ... :o
/edit: Hmmmm, ließe man den Kanal weg: 342 & 0x0F = 6 (!?)
Grüße,
Jürgen
Nach einem FHEM-Update kommen jetzt wieder die Repetitions durch :)
Zitat
2017-02-05 11:12:52 CUL_TCM97001 Unknown Code: 28439D988000
2017-02-05 11:12:52 CUL_TCM97001 Unknown Code: 28439D988000
2017-02-05 11:12:52 CUL_TCM97001 Unknown Code: 28439D988000
2017-02-05 11:12:52 CUL_TCM97001 Unknown Code: 28439D988000
2017-02-05 11:12:52 CUL_TCM97001 Unknown Code: 28439D988000
2017-02-05 11:12:53 CUL_TCM97001 Unknown Code: 310A11A084C0
2017-02-05 11:12:53 CUL_TCM97001 Unknown Code: 310A11A084C0
2017-02-05 11:12:53 CUL_TCM97001 Unknown Code: 310A11A084C0
2017-02-05 11:12:53 CUL_TCM97001 Unknown Code: 310A11A084C0
2017-02-05 11:12:54 CUL_TCM97001 Unknown Code: 310A11A084C0
Gegencheck:
2017-02-05 11:12:52 CUL_TCM97001 Unknown Code: 28439D988000
HEX: 28439D988000
BIN: 1010000100001110011101100110001000000000000000
00000000010000000002000000000300000000040000000005
12345678901234567890123456789012345678901234567890
001010000100001110011101100110001000000000000000
00.10100001.00.00.111001110110.01100010.00000000
ID: 10100001 = 0xA1 = 161
BAT: 0
CH: 0
TEMP: 111001110110 = 0xE76 = 3702
HUM: 0110001 = 0x31 = 49
CRC: 00000000 = 0
161+3702+49 = 3912 & 0x0F = 8 NO!
2017-02-05 11:12:53 CUL_TCM97001 Unknown Code: 310A11A084C0
HEX: 310A11A084C0
BIN: 1100010000101000010001101000001000010011000000
00000000010000000002000000000300000000040000000005
12345678901234567890123456789012345678901234567890
001100010000101000010001101000001000010011000000
1100010000101000010001101000001000010011000000
00.11000100.00.10.100001000110.10000010.00010011
ID: 0xC4 = 196
BAT: 0 = 0
CH: 10 = 2
TEMP: 0x846 = 2118
HUM: 0x82 = 130
CRC: 0x13 = 19
196+2+2118+130 = 2446 & 0x0F = 14
196+2118+130 = 2444 & 0x0F = 12
Dicht daneben ist auch vorbei ...
Am besten noch mal mit empfangen Rohdaten (also ohne FHEM) checken...
Werde auch nochmal versuchen nur den Kanal zu ändern, das sind ja 3 Werte die sich nur in einer Stelle ändern.
Vielleicht zeigt dann die Veränderung des CRCs ein Hinweis....
Hallo Jürgen,
ich weiß zwar nicht ob sich etwas an Deiner Berechnung ändert, aber:
ZitatID: 0xC4 = 196
BAT: 0 = 0
CH: 10 = 2
CH:10 ist zwar 2d aber der Kanal 3! Nicht, dass das irgendwo falsch aufgefasst wird.
Ich habe bemerkt, dass die beiden ersten Bits im CRC ein Trailer für die CRC sein könnten, sie sind bei mir immer "00". Ich versuche mal dafür ein binäres Logging aufzusetzen. Vielleicht sind die letzten sechs Bits auch immer "00 00 00" ? Ich habe darin bisher noch keine "1" gesehen. mal sehen was das Log bis heute abend zeigt.
Gruß Eberhard
ZitatCH:10 ist zwar 2d aber der Kanal 3! Nicht, dass das irgendwo falsch aufgefasst wird.
Ja, korrekt. Hatte zwar auch schon mal das Batterie-Flag gesetzt gesehen, aber im Gut-Zustand auch "00".
Zum Beispiel ist:
28439D988000 = 001010000100001110011101100110001000000000000000
A10E766200 = __1010000100001110011101100110001000000000
Da ja ein AND mit 0x0F gemacht wird, bleiben 4 Bits des CRCs eigentlich immer 0 (?)
Wie wichtig der CRC ist, zeigt mal ein Mitschnitt:
Zitat
*** go! **
/001100010000100111001001100111001000001100*/ID: 196 / 1830
/001100010000100111001001100111001000001100*/ID: 196 / 1830
/001100010000100111001001100111001000001100*/ID: 196 / 1830
/001100010000100111001001100111001000001100*/ID: 196 / 1830
/001100010000100111001001100111001000001100*/ID: 196 / 1830
/001100010000100111001001110111001000001100*/ID: 196 / 1831
/000000000000000000000000000000000000000000*/ID: 0 / 0
/110000000000000000000000000000000000000000*/ID: 0 / 0
/100000000000000000000000000000000000000000*/ID: 0 / 0
/001111011111110011100000000000100000000000*/ID: 247 / 896
/111100010000000000000000000000000000000000*/ID: 196 / 0
/000000000000000000000000000000000000000001*/ID: 0 / 0
/100000000000000000000000000000000000000000*/ID: 0 / 0
/001010000100000111001001101000001000001010*/ID: 161 / 1830
/001010000100000111001001101000001000001010*/ID: 161 / 1830
/001010000100000111001001101000001000001010*/ID: 161 / 1830
/001010000100000111001001101000001000001010*/ID: 161 / 1830
/001010000100000111001001101000001000001010*/ID: 161 / 1830
/001010000100000111001001101000001000001110*/ID: 161 / 1830
/101100000000000000000000000000000000000000*/ID: 192 / 0
/000000000000000000000000000000000000000000*/ID: 0 / 0
/110000000000000000000000000000000000000000*/ID: 0 / 0
/001100010000101000001001100111001000001000*/ID: 196 / 2086
/001100010000101000001001100111001000001000*/ID: 196 / 2086
/001100010000101000001001100111001000001000*/ID: 196 / 2086
/001100010000101000001001100111001000001000*/ID: 196 / 2086
/001100010000101000001001100111001000001000*/ID: 196 / 2086
/000000000000000000000000000000000000000000*/ID: 0 / 0
Die ungültigen Protokolle müssen verworfen werden.
Die Sensoren senden 6 Repetitions, manchmal wird einer überlagert ...
Ohne CRC-Prüfung kommt zu viel Spam durch.
Hallo Jürgen,
Ich habe jetzt endlich das Logging aufsetzen können. Mal sehen was morgen "im Kasten" ist. Ich lasse es mal die Nacht über laufen.
ZitatIch habe bemerkt, dass die beiden ersten Bits im CRC ein Trailer für die CRC sein könnten, sie sind bei mir immer "00".
Nach den bisherigen Aufzeichnungen scheint das der Fall zu sein.
2017-02-05_18:27:34 Unknown2 Logfile: ID: 103, CRC(d): 34, CRC(b): 00|1000100|00000
2017-02-05_18:27:34 Unknown2 Logfile: ID: 103, CRC(d): 34, CRC(b): 00|1000100|00000
2017-02-05_18:27:34 Unknown2 Logfile: ID: 103, CRC(d): 34, CRC(b): 00|1000100|00000
2017-02-05_18:28:22 Unknown2 Logfile: ID: 185, CRC(d): 38, CRC(b): 00|1001100|00000
2017-02-05_18:28:22 Unknown2 Logfile: ID: 185, CRC(d): 38, CRC(b): 00|1001100|00000
2017-02-05_18:28:22 Unknown2 Logfile: ID: 185, CRC(d): 38, CRC(b): 00|1001100|00000
2017-02-05_18:28:22 Unknown2 Logfile: ID: 185, CRC(d): 38, CRC(b): 00|1001100|00000
2017-02-05_18:28:23 Unknown2 Logfile: ID: 185, CRC(d): 38, CRC(b): 00|1001100|00000
2017-02-05_18:28:27 Unknown2 Logfile: ID: 103, CRC(d): 38, CRC(b): 00|1001100|00000
2017-02-05_18:28:27 Unknown2 Logfile: ID: 103, CRC(d): 38, CRC(b): 00|1001100|00000
2017-02-05_18:28:27 Unknown2 Logfile: ID: 103, CRC(d): 38, CRC(b): 00|1001100|00000
2017-02-05_18:28:27 Unknown2 Logfile: ID: 103, CRC(d): 38, CRC(b): 00|1001100|00000
2017-02-05_18:28:27 Unknown2 Logfile: ID: 103, CRC(d): 38, CRC(b): 00|1001100|00000Auch scheinen die letzten 7 Bit einen dauerhaften Zustand "0" zu haben. Mal abwarten bis morgen. Der CRC(d) ist der berechnete Wert nach bisheriger Lesart - in Bit 34 bis Bit 41 ist die CRC enthalten. In CRC(b) sind die 14 Bits des CRC. Die "|" sind nur zur Orientierung gedacht.
Gruß Eberhard
Hallo Jürgen,
ich habe in der letzten Nacht, ca. 10.000 Messwerte von zwei Sensoren erhalten. Ich spare mir diese komplett als Anlage anzuhägen. Alle Werte sehen im Prinzip so aus:
2017-02-05_21:17:10 Unknown2 Logfile: ID: 103, CRC(d): 2, CRC(b): 00|000010|000000
2017-02-05_21:17:10 Unknown2 Logfile: ID: 103, CRC(d): 2, CRC(b): 00|000010|000000
2017-02-05_21:17:10 Unknown2 Logfile: ID: 103, CRC(d): 2, CRC(b): 00|000010|000000
2017-02-05_21:17:10 Unknown2 Logfile: ID: 103, CRC(d): 2, CRC(b): 00|000010|000000
2017-02-05_21:17:11 Unknown2 Logfile: ID: 103, CRC(d): 2, CRC(b): 00|000010|000000
2017-02-05_21:17:32 Unknown2 Logfile: ID: 185, CRC(d): 2, CRC(b): 00|000010|000000
2017-02-05_21:17:32 Unknown2 Logfile: ID: 185, CRC(d): 2, CRC(b): 00|000010|000000
2017-02-05_21:17:33 Unknown2 Logfile: ID: 185, CRC(d): 2, CRC(b): 00|000010|000000
2017-02-05_21:17:33 Unknown2 Logfile: ID: 185, CRC(d): 2, CRC(b): 00|000010|000000
2017-02-05_21:17:33 Unknown2 Logfile: ID: 185, CRC(d): 2, CRC(b): 00|000010|000000
2017-02-05_21:18:03 Unknown2 Logfile: ID: 103, CRC(d): 8, CRC(b): 00|001000|000000
2017-02-05_21:18:03 Unknown2 Logfile: ID: 103, CRC(d): 8, CRC(b): 00|001000|000000
2017-02-05_21:18:03 Unknown2 Logfile: ID: 103, CRC(d): 8, CRC(b): 00|001000|000000
2017-02-05_21:18:03 Unknown2 Logfile: ID: 103, CRC(d): 8, CRC(b): 00|001000|000000
2017-02-05_21:18:04 Unknown2 Logfile: ID: 103, CRC(d): 8, CRC(b): 00|001000|000000
2017-02-05_21:18:22 Unknown2 Logfile: ID: 185, CRC(d): 2, CRC(b): 00|000010|000000
2017-02-05_21:18:22 Unknown2 Logfile: ID: 185, CRC(d): 2, CRC(b): 00|000010|000000
2017-02-05_21:18:23 Unknown2 Logfile: ID: 185, CRC(d): 2, CRC(b): 00|000010|000000
2017-02-05_21:18:23 Unknown2 Logfile: ID: 185, CRC(d): 2, CRC(b): 00|000010|000000
2017-02-05_21:18:23 Unknown2 Logfile: ID: 185, CRC(d): 2, CRC(b): 00|000010|000000
Die Telegramme werden jeweils 5x gesendet. Der Bereich der Prüfsumme reichte von 0d - 47d ( = 0x000000 - 0x101111). Werte über 47d gibt es nicht. Bei beiden Geräten (103 und 185) wurde der komplette Bereich ( 0d - 47d) gefunden
Bisher sind wir davon ausgegangen, dass in 8Bits der CRC-Wert steckt. In Wirklichkeit sind es nur sechs.
Entgegen meiner Vermutung von gestern werden die letzten sechs (nicht fünf) Bits immer auf "0" gesetzt.Leider ändern sich damit nicht die bisherigen CRC-Werte, weil die beiden ersten Bits ohnehin nur "00" sind.
Bisher: CCCCCCCCTTTTTT, jetzt: TTCCCCCCTTTTTT (T = konstante Bits, C=zum CRC-Check gehörend).
Damit sind wir nicht wirklich weiter. Schade.
Gruß Eberhard
Hallo Eberhard,
wieder mal ein Beispiel dafür, das man nicht alles per Copy&Paste übernehmen kann.
Zitat... wie schon gesagt, die CRC Funktion oben passt nicht zum Pearl Sensor.
https://forum.arduino.cc/index.php?topic=425908.15 (https://forum.arduino.cc/index.php?topic=425908.15)
Dort ist das Problem ebenfalls bekannt... (;-)
Dann bin ich auf die Suche gegangen:
ZitatThe CRC mechanisms being used can be reverse engineered using CRC RevEng by just feeding the tool with some recorded samples.
https://fetzerch.github.io/2014/11/15/reveng433/ (https://fetzerch.github.io/2014/11/15/reveng433/)
Ein Tool?
CRC-Explained:
https://barrgroup.com/Embedded-Systems/How-To/CRC-Calculation-C-Code (https://barrgroup.com/Embedded-Systems/How-To/CRC-Calculation-C-Code)
https://barrgroup.com/Embedded-Systems/How-To/CRC-Math-Theory (https://barrgroup.com/Embedded-Systems/How-To/CRC-Math-Theory)
https://barrgroup.com/Embedded-Systems/How-To/Additive-Checksums (https://barrgroup.com/Embedded-Systems/How-To/Additive-Checksums)
CRC8/Maxxim reversed
https://github.com/UlrikHjort/CRC8 (https://github.com/UlrikHjort/CRC8)
https://github.com/zhoulihe/crc8/blob/master/CRC8-16-32-64/CRC16-32-64/crc8.cpp (https://github.com/zhoulihe/crc8/blob/master/CRC8-16-32-64/CRC16-32-64/crc8.cpp)
Helpers
https://github.com/fetzerch/atMETEO/blob/master/lib/utils.h (https://github.com/fetzerch/atMETEO/blob/master/lib/utils.h)
Repeater
http://www.thice.nl/convert-cheap-433mhz-sensors-to-kakucoco-with-an-arduino-convertor/ (http://www.thice.nl/convert-cheap-433mhz-sensors-to-kakucoco-with-an-arduino-convertor/)
Analyzer
http://wiki.nethome.nu/doku.php/analyzer/start (http://wiki.nethome.nu/doku.php/analyzer/start)
http://zorc.breitbandkatze.de/crctester.c (http://zorc.breitbandkatze.de/crctester.c)
https://www.mikrocontroller.net/topic/211884 (https://www.mikrocontroller.net/topic/211884)
http://zorc.breitbandkatze.de/crc.html (http://zorc.breitbandkatze.de/crc.html) mit Links zu weiteren CRCs.
Zitat..Kopfzerbrechen bereitet mir noch die Prüfsumme, in die definitiv
die Telegramm-Nummer (0..2 oder 1..3) eingeht:
http://www.fernando-heitor.de/index.php?topic=3699.0 (http://www.fernando-heitor.de/index.php?topic=3699.0)
Allgemein, interessante Seite mit "Wireless Automation Analyzer":
http://scheidig.de/Deutsch/scheidig_start_WirelessAutomation.htm (http://scheidig.de/Deutsch/scheidig_start_WirelessAutomation.htm)
Last but not least:
https://fetzerch.github.io/2014/11/15/reveng433/
https://sourceforge.net/projects/reveng/ (https://sourceforge.net/projects/reveng/)
Details in der Readme-Datei.
reveng.exe -h | clip
CRC RevEng: arbitrary-precision CRC calculator and algorithm finder
Usage: reveng.exe -cdDesvhu? [-bBfFlLMrStVXyz]
[-a BITS] [-A OBITS] [-i INIT] [-k KPOLY] [-m MODEL]
[-p POLY] [-P RPOLY] [-q QPOLY] [-w WIDTH] [-x XOROUT]
[STRING...]
Options:
-a BITS bits per character (1 to 32)
-A OBITS bits per output character (1 to 32)
-i INIT initial register value
-k KPOLY generator in Koopman notation (implies WIDTH)
-m MODEL preset CRC algorithm
-p POLY generator or search range start polynomial
-P RPOLY reversed generator polynomial (implies WIDTH)
-q QPOLY search range end polynomial
-w WIDTH register size, in bits
-x XOROUT final register XOR value
Modifier switches:
-b big-endian CRC -B big-endian CRC output
-f read files named in STRINGs -F find presets less quickly
-l little-endian CRC -L little-endian CRC output
-M non-augmenting algorithm -r right-justified output
-S print spaces between chars -t left-justified output
-V reverse algorithm only -X print uppercase hex
-y low bytes first in files -z raw binary STRINGs
Mode switches:
-c calculate CRCs -d dump algorithm parameters
-D list preset algorithms -e echo (and reformat) input
-s search for algorithm -v calculate reversed CRCs
-h | -u | -? show this helpGenügend Stoff .... ;)
'This code provided by Weber from osngr.net
crc2calc:
'BASIC code to compute a CCITT-8 CRC checksum for a nibble-based message
crc = 0
crc = crcnibble(crc, sensorid1)
crc = crcnibble(crc, sensorid2)
crc = crcnibble(crc, sensorid3)
crc = crcnibble(crc, sensorid4)
crc = crcnibble(crc, channel)
crc = crcnibble(crc, rollingcode1)
crc = crcnibble(crc, rollingcode2)
crc = crcnibble(crc, battflag)
crc = crcnibble(crc, temp1)
crc = crcnibble(crc, temp2)
crc = crcnibble(crc, temp3)
crc = crcnibble(crc, tempsign)
crc = crcnibble(crc, humidity1)
crc = crcnibble(crc, humidity2)
crc = crcnibble(crc, unknown)
'at the end, need to run 8 zero bits through to finish the calculation
crc = crcnibble(crc, 0)
crc = crcnibble(crc, 0)
crcnib1 = crc And 15
crcnib2 = ShiftRight(crc, 4)
'now, "encode" these two nibbles after your crc1, crc2 checksum nibbles
Return
'this function adds one more nibble to the crc calculation
Function crcnibble(crc As Byte, nibble As Byte) As Byte
For bitno = 0 To 3
If crc.7 = 1 Then 'does this return "1" or "8" ? might need "if crc.7 = 8" instead...
'note: I assume that nibble.3 returns either "0" or "1"
'if it returns "0" or "8" instead then this code is not correct
'and you would need another IF statement here to OR a "1" into
'the left - shifted crc If Bit 3 of nibble is a one
crc = ShiftLeft(crc, 1)
If nibble.3 = 1 Then crc = crc Or 1
If nibble.3 = 0 Then crc = crc Or 0
crc = crc Xor crcpoly
Else
'same comment as above -- depending on what "nibble.3" returns
crc = ShiftLeft(crc, 1)
If nibble.3 = 1 Then crc = crc Or 1
If nibble.3 = 0 Then crc = crc Or 0
Endif
nibble = ShiftLeft(nibble, 1)
Next bitno
crcnibble = crc
End Function
calc_crc1: 'Calculate the first crc, simply the modulo8 sum of all the data variables.
crc1calc = sensorid1 + sensorid2 + sensorid3 + sensorid4 + channel + rollingcode1 + rollingcode2 + battflag
crc1calc = crc1calc + temp1 + temp2 + temp3 + tempsign + humidity1 + humidity2 + unknown
crc1nib1 = crc1calc And 15 'Convert single byte into 2 nibbles.
crc1nib2 = ShiftRight(crc1calc, 4)
Return
Hallo Jürgen,
nachdem ich fast erschlagen wurde von Deinem vorletzten Code und ich einmal durchatmen musste, versuche ich nun den Code des letzten Posts auf Arduino zu portieren. Der soll die Berechnung machen. In welcher Sprache ist der Codeschnipsel eigentlich geschrieben? Ich hänge an dem Ausdruck: If crc.7 = 1, dort genau an dem crc.7 . Kannst Du mir da kurz helfen?
Gruß Eberhard
Hallo Eberhard,
die Codeschnipsel stammen aus einem PIC-Basic-Dialekt.
Aber dessen Methodik sollte einfach in C umsetzbar sein.
Dient aber eher zum Verständnis wie der Gesamt-CRC gebildet wird.
Für mich war die CRC-Bildung interessant, aber ebenso der außer dem Empfang auch der Sendevorgang bzw. Algorithmus.
Die Links waren natürlich eher (un-)eigennützig ... ;)
Damit kann ich mich auf die Suche begeben.
Das Thema ist bei mir gerade etwas durch einen 3D-Drucker-Aufbau interrupted worden.
Verfolge das Thema aber nach einer kleinen Pause gerne weiter.
Grüße,
Jürgen
Hallo Jürgen,
wenn ich mich der Umsetzung fertig bin, bzw. nicht weiterkomme, melde ich mich nochmal. Bei Dir ist es wie bei mir: Tausend Projekte und alle wollen in der ersten Reihe sitzen. 8) 8)
ZitatDie Links waren natürlich eher (un-)eigennützig ...
Ja DARAUF wäre ich ja überhaupt nicht gekommen... ::) ::)
Gruß Eberhard
ZitatBei Dir ist es wie bei mir: Tausend Projekte und alle wollen in der ersten Reihe sitzen.
... das in einem begrenztem Zeitraum, man nennt es auch "Wochenende" .... ;D
Hallo Jürgen,
gibt es eigentlich bei dem Thema CRC irgendwelche Neuigkeiten? Ich habe es nach etlichen Versuchen aufgegeben.
Gruß Eberhard
Hallo Eberhard,
hatte mich in der Zwischenzeit ein paar anderen Projekten zugewandt.
Sidey und Ralf9 haben im Signalduino-Thread einiges an neuen Sensoren implementiert.
Ich werde es noch mal mit einer neuen Signalduino-Version mit dem CC1101 versuchen.
Aber leider hakt es hier nur noch an dem Thema CRC, schade eigentlich.
Vielleicht versuche ich doch noch einen neuen Anlauf ...
Grüße,
Jürgen
Hier vielleicht noch eine weitere CRC Möglichkeit:
https://forum.fhem.de/index.php/topic,28519.msg442814.html#msg442814 (https://forum.fhem.de/index.php/topic,28519.msg442814.html#msg442814)
https://github.com/guillier/433mhz_receiver (https://github.com/guillier/433mhz_receiver)
https://github.com/merbanan/rtl_433 (https://github.com/merbanan/rtl_433)
http://fetzerch.github.io/2014/11/15/reveng433/ (http://fetzerch.github.io/2014/11/15/reveng433/)
Ich habe mich heute auch mal ein bißchen mit der Prüfsumme beschäftigt (ich sage bewußt nicht CRC, weil noch nicht klar ist, ob es sich überhaupt um einen CRC handelt) und bin zu der Erkenntnis gelangt, daß nur die letzten 4 Bit die Prüfsumme darstellen und das vorletzte Nibble noch vollständig Teil der Nutzdaten ist.
Das MSB des vorletzten Nibble ist immer dann 1, wenn der Test-Button gedrückt wurde, das nächste Bit war bei mir bisher immer 0 und die letzten beiden nehmen die Werte 00, 01 und 10 an, ich weiß aber noch nicht, was die bedeuten.
Daß dise beiden Bits nicht zur Prüfsumme gehören schließe ich daraus, daß ich in den Logs der letzten Monate ettliche Fälle gefunden habe, bei denen die ersten 32 Bit identisch waren, die letzten 8 aber nicht. Das läßt sich nach meinem Verständnis nur dadurch erklären, daß die Nutzdaten 36 Bit umfassen und die Prüfsumme 4. Außerdem ändern sich die letzten 4 Bit mehr oder weniger beliebig, während die beiden davor meist über ettliche Messungen hinweg unverändert bleiben.
Basierend auf dieser These habe ich mal verschiedene 4-Bit-CRCs durchprobiert, aber leider hat bisher keiner gepaßt. :(
BTW, der Sensor NC-5849-675 von PEARL hat auch dieses Protokoll.
Mit Unterstützung von Torsten Duwe (Grüße an Rudi) habe ich den CRC geknackt!
Es handelt sich um ein Schieberegister mit 4 Bit.
Die Datenbits werden in der Reihenfolge der Übertragung von rechts nach links hineingeschoben.
Vor dem ersten und zweiten Bit des Registers sitzt jeweils ein XOR dessen zweiter Eingang mit dem Ausgang des vierten Bits verbunden ist.
+---+ +---+ +---+ +---+
| |<-----| |<-----| |<--X--| |<--X-- INPUT
+---+ +---+ +---+ ^ +---+ ^
| | |
+------------->-------------+----->----+
Als C-Code sieht das dann so aus, wenn man annimmt, daß die Daten nicht länger als 64 Bit sind und rechtsbündig in einem 64-Bit Integer vorliegen:
#include <stdint.h>
uint8_t CRC (uint64_t bits)
{
uint8_t crc; int i;
for (i = 0; i < 64; i++) {
crc <<= 1;
if (bits & (1UL<<63)) crc |= 1;
if (crc & 0x10) crc ^= 0x3;
bits <<= 1;
}
return (crc & 0xf);
}
Das kann man sicher noch optimieren, aber so funktioniert es zumindest mal.
Von über 10.000 verschiedenen Datagrammen habe ich damit bei allen außer 4 den CRC korrekt verifizieren könnnen und bei den falschen war ziemlich offensichtlich das letzte Bit von 1 auf 0 gekippt.
Falls Interesse besteht, kann ich bei Gelegenheit nochmal etwas ausführlicher schreiben, wie wir drauf gekommen sind.
Hallo rmax,
das hört sich ja sehr gut an:
ZitatMit Unterstützung von Torsten Duwe (Grüße an Rudi) habe ich den CRC geknackt!
Es handelt sich um ein Schieberegister mit 4 Bit.
Die Datenbits werden in der Reihenfolge der Übertragung von rechts nach links hineingeschoben.
Vor dem ersten und zweiten Bit des Registers sitzt jeweils ein XOR dessen zweiter Eingang mit dem Ausgang des vierten Bits verbunden ist.
Code: [Auswählen]
+---+ +---+ +---+ +---+
| |<-----| |<-----| |<--X--| |<--X-- INPUT
+---+ +---+ +---+ ^ +---+ ^
| | |
+------------->-------------+----->----+
Als C-Code sieht das dann so aus, wenn man annimmt, daß die Daten nicht länger als 64 Bit sind und rechtsbündig in einem 64-Bit Integer vorliegen:
Code: [Auswählen]
#include <stdint.h>
uint8_t CRC (uint64_t bits)
{
uint8_t crc; int i;
for (i = 0; i < 64; i++) {
crc <<= 1;
if (bits & (1UL<<63)) crc |= 1;
if (crc & 0x10) crc ^= 0x3;
bits <<= 1;
}
return (crc & 0xf);
}
Das kann man sicher noch optimieren, aber so funktioniert es zumindest mal.
Von über 10.000 verschiedenen Datagrammen habe ich damit bei allen außer 4 den CRC korrekt verifizieren könnnen und bei den falschen war ziemlich offensichtlich das letzte Bit von 1 auf 0 gekippt.
Falls Interesse besteht, kann ich bei Gelegenheit nochmal etwas ausführlicher schreiben, wie wir drauf gekommen sind.
Chapeau! :D
ZitatFalls Interesse besteht, kann ich bei Gelegenheit nochmal etwas ausführlicher schreiben, wie wir drauf gekommen sind
Na klar doch! Tolle Arbeit!
Ggf. könnte man noch Björn oder Sidey mit informieren, um das mit in die aculfw oder den Signalduino mit einfließen zu lassen. (done: https://github.com/RFD-FHEM/RFFHEM/issues/117 (https://github.com/RFD-FHEM/RFFHEM/issues/117))
Grüße,
Jürgen
Hallo Jürgen,
OK, hier also der "Lösungsweg":
Daß es sich um 36 Nutzdatenbits und 4 Bit Prüfsumme handelt, hatte ich ja in meinem ersten Post schon vermutet.
Auf dieser Annahme, basierten alle weiteren Überlegungen.
Nach ettlichen erfolglosen Versuchen (automatisch und manuell) mit CRC reveng hatte ich schon Zweifel, ob es sich bei den Prüfbits überhaupt um einen CRC handelt. Daß es Prüfbits sein müssen, war ich mir sicher, denn in meinen gesammelten Meßwerten gab es ettliche Doubletten, aber keinen Fall, in dem die ersten 36 Bit identisch und die letzten 4 anders waren.
Torsten brachte mich dann drauf, daß bei einer linearen Prüfsummenfunktion (dazu gehört CRC) ein XOR über zwei Datenfelder samt Prüfbits wieder ein Datenfeld mit der dazu passender Prüfsumme ergibt. Macht man das nun mit Datenfeldern, die sich jeweils nur in einem Bit unterscheiden, sieht man an den Einsen in der resultierenden Prüfsume, welche Prüfbits von diesem Datenbit beeinflußt werden.
Also habe ich meine gut 10.000 unterschiedlichen Datenpakete paarweise miteinander verglichen und das XOR-Ergebnis von solchen ausgegeben, die sich nur in einem Bit unterschieden haben. Heraus kamen gut 8000 Datenfelder mit je einem gesetzten Bit, die erfreulicherweise beim gleichen gesetzten Bit auch immer die gleiche Prüfsumme hatten. Es mußte also etwas CRC-artiges sein. Sortiert und ohne Doubletten ergab sich daraus folgende Tabelle, die angibt, welches Datenbit welche Prüfsummenbits beeinflußt:
000000000000000000000000000000000001 0001
000000000000000000000000000000000010 0010
000000000000000000000000000000001000 1000
000000000000000000000000000000010000 0011
000000000000000000000000000000100000 0110
000000000000000000000000000100000000 0101
000000000000000000000000001000000000 1010
000000000000000000000000010000000000 0111
000000000000000000000000100000000000 1110
000000000000000000000001000000000000 1111
000000000000000000010000000000000000 0010
000000000000000000100000000000000000 0100
000000000000000001000000000000000000 1000
000000000000000010000000000000000000 0011
000000000000000100000000000000000000 0110
000000000000001000000000000000000000 1100
000000000000010000000000000000000000 1011
000000000000100000000000000000000000 0101
000000000001000000000000000000000000 1010
000000000010000000000000000000000000 0111
000000000100000000000000000000000000 1110
000000001000000000000000000000000000 1111
Die Leerzeilen markieren Stellen, an denen die Tabelle unvollständig ist, weil es in meiner Sammlung keine zwei Datensätze gab, die sich nur in diesem einen Bit unterscheiden. Trotz der Lücken kann man erkennen, daß die Abfolge der Prufsummen Regelmäßigkeiten aufweist, z.B. finden sich die Bitmuster aus dem dritten Block am Ende der Tabelle wieder und Teile des ersten und zweiten Blocks kommen am Anfang des vierten wieder vor.
Mit dieser Erkenntnis lassen sich nun einige der Lücken schließen oder zumindest verkleinern.
Der Anfang der Tabelle sieht dann so aus:
000000000000000000000000000000000001 0001
000000000000000000000000000000000010 0010
000000000000000000000000000000000100 0100
000000000000000000000000000000001000 1000
000000000000000000000000000000010000 0011
000000000000000000000000000000100000 0110
000000000000000000000000000001000000 1100
000000000000000000000000000010000000 1011
Nun habe ich mir überlegt, wie ein Schieberegister mit XOR-Rückkopplungen aussehen muß, das ausgehend vom Zustand 0000 nach Einschieben einer Eins gefolgt von der entsprechenden Anzahl Nullen das jeweilige CRC-Muster enthält. Die ersten vier Zeilen sind trivial, da wird ja nur das Eingabemuster durchgeschoben. Weil derweil hinten nur Nullen herausfallen bleiben evtl. vorhandene XOR-Glieder zwischen den FFs wirkungslos. Interessant ist die 5. Zeile, denn hier fällt zum ersten Mal eine 1 links aus dem Register heraus und taucht in den rechten beiden Bits wieder auf. Das läßt sich nur dadurch erklären, daß der Ausgang des MSB per XOR auf die Eingänge der unteren beiden Bits rückwirkt. Weil diese beiden Einsen in den folgenden Zeilen dann auch wieder einfach durch das Register wandern, bevor sich in Zeile 8 dann beim Herausschieben der nächsten Eins wieder die beiden unteren Stellen von 0 auf 1 ändern, war klar, daß es auch keine weiteren Rückkopplungen gibt.
Es folgte eine anschauliche Implementierung in Tcl mit der ich anhand meiner Datensammlung überprüfen konnte, daß ich die richtige Funktion gefunden hatte, und eine effizientere Implementierung in C, die ich dann hier gepostet habe.
Super, danke für den Lösungsweg!
Dann versuche ich mal das Ganze in den Code einzubauen.
Grüße
Jürgen
Erst einmal ein großes Lob für rmax. Da muss man ja erstmal drauf kommen! Chapeau!! (standing ovation! :) :) :) :) )
Ich war jetzt einige Zeit nicht hier und bin mir nicht sicher ob in dem Modul CUL_TCM97001 schon der neune Sensor eingearbeitet ist. Ich fürchte mich nämlich für einem Batteriewechsel und der damit verbundenen neuen ID. Dann muss ich in meine übergangsweise gebastelten Lösung eingreifen.
Also wie sieht es aus? ;)
Einen schönen Sonntag. Bei mir rollt die Tour de France durchs Dorf. 8)
Gruß Eberhard
Hallo Eberhard,
wie der Zufall so will ... ;D :)
Bei so einem miesen Wetter ist das genau das richtige Projekt ...
Grüße,
Jürgen
Big Smilie!! :) :) :) :) :) :) :) :)
Hallo Jürgen,
ich weiß, dass ich nerve, aber es bleibt mir (und den anderen, die auch ein Pearl NC7427 haben) nicht anderes übrig als auf das Update zu warten. Darf ich fragen, wann es voraussichtlich fertig sein wird?
Viele Grüße
Eberhard
Hallo Eberhard,
Bin "leider" auf der grüner Insel bei 17Grad ...
Deshalb musste das Thema etwas warten....
Ich bin aber noch dabei... melde mich wieder ... 8)
Juergen
@Jürgen
ZitatBin "leider" auf der grüner Insel bei 17Grad ...
Unter Sommer stelle ich mir aber etwas anderes vor. Trotzdem gute Erholung.
@rmax
ZitatDaß es sich um 36 Nutzdatenbits und 4 Bit Prüfsumme handelt, hatte ich ja in meinem ersten Post schon vermutet.
Fakt ist, dass das gesamte Datentelegramm aus 48 Bits besteht. Das sind 12 Bytes oder 24 Nibbles. Wir sind bisher immer davon ausgegangen, dass bis zum 34. Bit die Nutzdaten reichen. Die Bits von Nr. 35 bis 46 gehörten unserer bisherigen Lesart nach zur Prüfsumme. Darauf folgen zwei Bits Nr. 47 und 48 die das Ende des Datentelegramms markieren.
Ich habe deshalb zwei Fragen:
1. Wo liegen die 4 Bits zur Prüfsummenberechnung. Sie müssen ja irgendwo zwischen Bit 37 und 46 liegen, da Bit 35, 36 und bit 47,48 bei meinen Messungen immer "00" waren. Das sind aber immer noch 10 Bits, von denen nur 4 benutzt werden.
2. Was könnten Deiner Meinung nach die Bits zwischen Nutz- und Prüfdaten enthalten?
Viele Grüße
Eberhard
EDIT: Die Frage 1 hat sich inzwischen geklärt: Nach der Feuchtigkeitsangabe folgen 4 Bits mit "0" und dann die 4 Bits mit der Prüfziffer. Den Abschluiss bilden noch einmal sechs Nullen. Man möge mich korrigieren wenn ich falsch liege.
Frage 2 ist offen.
Ich versuche gerade die beiden Zeilen
Zitatif (bits & (1UL<<63)) crc |= 1;
if (crc & 0x10) crc ^= 0x3;
zu verstehen und stolpere über die beiden obigen Anweisungen. Warum folgt kein "?" bzw. ein geschweifter Klammerausdruck? Das ist doch C - oder?
Gruß Eberhard
Ja, aber geht beides:
if (bits & (1UL<<63)) crc |= 1;
oder
if (bits & (1UL<<63)) {crc |= 1;}
Grüße Jörg
Hallo Jörg,
vielen Dank für Deine Hilfe - den if Bereich habe ich hoffentlich kapiert. Obwohl es im eigentlichen Sinne nicht hierhin gehört. Ist es richtig wenn ich formuliere:
Wenn die bitweise UND-Verknüpfung von 'bits' maskiert mit '1 gefolgt von 63 Nullen' = wahr (also "1") ergibt, dann bitweises ODER von crc (4bits) mit "1" .
Das würde bedeuten, dass das rechte Bit von crc auf "1" gesetzt wird, wenn der erste (linke Wert) von bits ebenfalls 1 ist. Wie falsch liege ich?
Meine Güte ist das kompliziert. :-[
@rmax
Ich habe die Telegramme meines Sensor mal gelogged:
Hier ein Muster: 2017-07-17_11:36:17 Pearl_1 CRCBIN: 00|10111001|00|00|001001010110|00000100|00|001011|000000[/size
Die wesentlichen Inhalte sind durch ein "|" getrennt.
LD|ID|Bat|Ch|Temp|Hum|00|CRC|unbekannt. Bei meinen Ergebnissen sind die Prüfbits nicht 4 sondern 6 bit breit. Ich bekomme ab und zu Ergebnisse wie dieses:
2017-07-14_23:06:55 Pearl_1 CRCBIN: 00|01100111|00|01|010001010110|00110011|00|101001|000000
2017-07-14_23:07:00 Pearl_1 CRCBIN: 00|10111001|00|00|101101000110|01100011|00|001110|000000
2017-07-14_23:07:49 Pearl_1 CRCBIN: 00|01100111|00|01|010001010110|00110011|00|101001|000000
2017-07-14_23:08:40 Pearl_1 CRCBIN: 00|10111001|00|00|101101000110|01100011|00|001110|000000
2017-07-14_23:09:30 Pearl_1 CRCBIN: 00|10111001|00|00|101101000110|01100011|00|001110|000000
2017-07-14_23:10:20 Pearl_1 CRCBIN: 00|10111001|00|00|101101000110|01100011|00|001110|000000
2017-07-14_23:10:28 Pearl_1 CRCBIN: 00|01100111|00|01|010001010110|00110011|00|101001|000000
2017-07-14_23:11:10 Pearl_1 CRCBIN: 00|10111001|00|00|101101000110|01100011|00|001110|000000
2017-07-14_23:11:20 Pearl_1 CRCBIN: 00|01100111|00|01|010001010110|00110011|00|001011|000000
2017-07-14_23:12:00 Pearl_1 CRCBIN: 00|10111001|00|00|101101000110|01100011|00|001110|000000
2017-07-14_23:12:13 Pearl_1 CRCBIN: 00|01100111|00|01|010001010110|00110011|00|001011|000000
2017-07-14_23:12:50 Pearl_1 CRCBIN: 00|10111001|00|00|101101000110|01100011|00|001110|000000
2017-07-14_23:13:06 Pearl_1 CRCBIN: 00|01100111|00|01|010001010110|00110011|00|001011|000000
2017-07-14_23:13:40 Pearl_1 CRCBIN: 00|10111001|00|00|101101000110|01100011|00|001110|000000
2017-07-14_23:14:00 Pearl_1 CRCBIN: 00|01100111|00|01|010001010110|00110011|00|001011|000000
2017-07-14_23:14:30 Pearl_1 CRCBIN: 00|10111001|00|00|101101000110|01100011|00|001110|000000
2017-07-14_23:15:20 Pearl_1 CRCBIN: 00|10111001|00|00|101101000110|01100011|00|001110|000000
2017-07-14_23:16:10 Pearl_1 CRCBIN: 00|10111001|00|00|101101000110|01100011|00|001110|000000
2017-07-14_23:17:00 Pearl_1 CRCBIN: 00|10111001|00|00|101101000110|01100011|00|001110|000000
2017-07-14_23:17:32 Pearl_1 CRCBIN: 00|01100111|00|01|010001010110|00110011|00|001011|000000
2017-07-14_23:17:50 Pearl_1 CRCBIN: 00|10111001|00|00|101101000110|01100011|00|001110|000000
2017-07-14_23:18:24 Pearl_1 CRCBIN: 00|01100111|00|01|010001010110|00110011|00|001011|000000
2017-07-14_23:18:40 Pearl_1 CRCBIN: 00|10111001|00|00|101101000110|01100011|00|001110|000000
2017-07-14_23:19:30 Pearl_1 CRCBIN: 00|10111001|00|00|101101000110|01100011|00|001110|000000
2017-07-14_23:20:20 Pearl_1 CRCBIN: 00|10111001|00|00|101101000110|01100011|00|001110|000000
2017-07-14_23:21:10 Pearl_1 CRCBIN: 00|10111001|00|00|101101000110|01100011|00|001110|000000
2017-07-14_23:21:57 Pearl_1 CRCBIN: 00|01100111|00|01|001101010110|00110011|00|001010|000000
2017-07-14_23:22:50 Pearl_1 CRCBIN: 00|10111001|00|00|101001000110|01100011|00|001000|000000
2017-07-14_23:23:40 Pearl_1 CRCBIN: 00|10111001|00|00|101001000110|01100011|00|001000|000000
2017-07-14_23:24:30 Pearl_1 CRCBIN: 00|10111001|00|00|101001000110|01100011|00|001000|000000
2017-07-14_23:25:20 Pearl_1 CRCBIN: 00|10111001|00|00|101001000110|01100011|00|001000|000000
2017-07-14_23:25:28 Pearl_1 CRCBIN: 00|01100111|00|01|001101010110|00110011|00|001010|000000
2017-07-14_23:26:10 Pearl_1 CRCBIN: 00|10111001|00|00|101001000110|01100011|00|001000|000000
2017-07-14_23:27:00 Pearl_1 CRCBIN: 00|10111001|00|00|101001000110|01100011|00|001000|000000
2017-07-14_23:27:14 Pearl_1 CRCBIN: 00|01100111|00|01|001101010110|00110011|00|001010|000000
2017-07-14_23:27:50 Pearl_1 CRCBIN: 00|10111001|00|00|101001000110|01100011|00|001000|000000
2017-07-14_23:28:08 Pearl_1 CRCBIN: 00|01100111|00|01|001101010110|00110011|00|001010|000000
2017-07-14_23:28:40 Pearl_1 CRCBIN: 00|10111001|00|00|101001000110|01100011|00|001000|000000
Nicht irritieren lassen: Ich habe zwei Sensoren mit unterschiedlichen ID's im Einsatz. ID 185 und 103
Kannst Du mal überprüfen, ob Dein Algorithmus hier auch passt? Wie sieht an einem Bsp der Inhalt von bits aus?
Gruß Eberhard
Bei C müssen Anweisungsblöcke nur dann in geschwefte Klammern, wenn sie mehr als eine Anweisung enthalten.
Bei Kontrollstrukturen (if, for, while), die nur eine Anweisung enthalten, können die Klammern entfallen.
Die Datenblöcke bestehen aus 42 Bits, die ersten zwei und die letzten sechs Nullen gehören nicht dazu. Mein Empfänger mit eigener Firmware auf einem ATmega32U4 liefert die letzten sechs Nullen gleich gar nicht. Er intepretiert Pausen ab 7ms als End of Frame. Ich nehme an, daß Dein Empfänger die Pause am Ende jedes Frames fälschlich als mehrere Nullen interpretiert.
Die 42 Bits teilen sich nun in 38 Daten- und 4 CRC-Bits. Die beiden Bits vor dem CRC, die Du als Teil des CRC annimmst, gehören definitiv nicht dazu, sondern sind noch Datenbits. Sie verhalten sich bei mir ähnlich wie die beiden, die Du als "Bat" bezeichnet hast. Sie nehmen nur die Werte 00, 01 und 10 an, aber niemals 11. Es wurde ja schon gemutmaßt, es könnte sich bei der ersten Gruppe um die Tendenz der Temperatur handeln, also steigend, fallend oder gleichbleibend. Überprüft habe ich das allerdings noch nicht. Entsprechend könnte die hintere Gruppe die Tendenz der Luftfeuchtigkeit sein. Ich bin mir jedenfalls ziemlich sicher, daß der Batteriestand in keiner der beiden Gruppen enthalten ist, denn dafür zappeln sie zu viel, selbst mit neuen Batterien.
Von den beiden linken Nullen im vorletzten Nibble geht eine auf 1, wenn man die Übertragung mit der Taste (soweit vorhanden) erzwingt. Die andere könnte Low-Bat signalisieren, ein entsprechender Test steht aber noch aus.
Was den Algorithmus angeht, habe ich ihn mit einer 64Bit-Variablen implementiert, weil das als Schnellschuß am einfachsten war, denn da passen die 38 Datenbits auf einen Rutsch rein und dem Algorithmus sind führende Nullen egal. Man könnte stattdessen natürlich auch nacheinander die einzelnen Bytes oder Nibbles hineinschieben, wenn das Ganze auf einem 8-Bitter laufen soll, oder sogar die einzelnen Bits, wenn der CRC bereits während des Empfangs berechnet werden soll.
In jeder Runde werden zuerst im Schieberegister die Bits um eine Position nach links bewegt. Dann wird das nächste Bit der Eingangsdaten als neues unterstes Bit ins Schieberegister kopiert. Jetzt wird noch das gerade aus dem Schieberegister "herausgefallene" Bit mit den unteren beiden XOR-Verknüpft, d.H. wenn es 1 war werden die beiden unteren invertiert, wenn es 0 war bleiben sie wie sie sind. Zuletzt schiebe ich die Eingangsdaten um eine Position nach links, so daß sich in der nächsten Runde das zu verarbeitende Eingangsbit wieder auf Position 63 befindet.
Wenn man das für die 38 Datenbits durchspielt, sollten die 4 Bit im Register mit den letzten 4 Bit der Übertragung übereinstimmen.
Hallo rmax,
danke für die ausführliche Darstellung und Korrektur meiner Sichtweise. Jetzt sind m.E. alle Voraussetzungen vorhanden, um zu dem gleichen Ergebnis zu kommen wie Du. Ich werde berichten, wenn ich es geschafft habe.
Gruß Eberhard
Hallo rmax,
ZitatDie Datenblöcke bestehen aus 42 Bits, die ersten zwei und die letzten sechs Nullen gehören nicht dazu.
Mein Datentelegramm besteht aus 48 bits (12 x 4bits). Wenn ich jetzt rechne: Deine 42 bits und meine 8 Nullen, dann bin ich bei 50 bits. Da beißt sich etwas.
Kann es sein, das die Daten nur 36 bit lang sind?
Meine 2 Nullen +
36 Datenbits +
4 Prüfsequenzbits + Meine 6 Nullen= 48 bits => Passt.
Gruß Eberhard
Ja, stimmt, die beiden "Startbits" gehören doch dazu, um auf meine 42 Bits zu kommen (oder halt weg, dann sind es nur 40, also glatte 10 Nibbles).
Das hatte ich gestern nicht mehr richtig in Erinnerung, war mir dessen aber so sicher, daß ich es auch nicht nochmal nachgeschaut habe.
Sorry.
Solange die Startbits aber immer als 0 empfangen werden, ist es für den hier verwendeten CRC aber egal, ob man sie hinzunimmt oder nicht, denn führende Nullen ignoriert er in beliebiger Anzahl. Die Startbits mit hinzuzunehmen bringt halt zusätzliche Sicherheit, falls mal eines davon fälschlicherweise als 1 ankommt, das kann man andererseits aber auch vorneweg prüfen.
Um herauszufinden, ob die Original-Wetterstation die Startbits beim CRC berücksichtigt oder nicht oder gar Telegramme, die nicht mit 00 anfangen schon vor der CRC-Berechnung verwirft, müßte man mal ein paar entsprechend konstruierte Telegramme an die Wetterstation senden und dabei den Stromverlauf beobachten. Ich habe aber keine solche Station und will mir auch keine kaufen.
Ich habe mal mit meinen rudimentären Kenntnissen versucht den C-Code von rmax in Perl umzusetzen. Vielleicht hilft das bei der Implementierung in das Modul. Ich habe ein UserReading mit dem Namen crc kreiert und kann es dann mit der mitgelieferten Prüfziffer, die in CRC gespeichert wird vergleichen. Das reading state ist der Ausgangspunkt.
Aus dem Reading state wird das Datentelegramm als BIN-String in stateBIN gespeichert:
stateBIN {my $s = (ReadingsVal($name,'state',''));
my @a = split(/\s+/,$s);
$s = $a[1];
my $u=sprintf( "%.48b", hex( $s ) );
return($u);},
Die eigentlichen Nutzdaten werden in dem Reading bits gespeichert
bits {my $s = (ReadingsVal($name,'stateBIN',''));
my @a = split("",$s);
my $u = $a[2].$a[3].$a[4].$a[5].$a[6].$a[7].$a[8].$a[9].$a[10].$a[11].$a[12].$a[13].$a[14].$a[15].$a[16].$a[17].$a[18].$a[19].$a[20].$a[21].$a[22].$a[23].$a[24].$a[25].$a[26].$a[27].$a[28].$a[29].$a[30].$a[31].$a[32].$a[33].$a[34].$a[35].$a[36].$a[37];
return($u);},
Die mitgelieferte Prüfziffer wird in CRC gepeichert:
CRC {my $s = (ReadingsVal($name,'stateHEX',''));
my @a = split("",$s);
my $CRC = (hex($a[9].$a[10]) & 0x3F) >> 2;
return($CRC);},
Und letztendlich wird die berechnete Prüfziffer in crc gespeichert:
crc {my $bits = (ReadingsVal($name,'bits',''));
$bits = oct("0b".$bits);
my $crc = (ReadingsVal($name,'CRCBIN',''));
$crc = 0b00000000;
my $i=0;
for ($i = 0; $i < 64; $i++) {
$crc <<= 1;
my $UL1 = 0b000000000000000000000000000000000000000000000000000000000001;
if ($bits & ($UL1<<63)) {$crc |= 1};
if ($crc & 0x10) {$crc ^= 0x3};
$bits <<= 1;
}
$crc &=0xf;
return ($crc & 0xf);},
Jetzt können CRC und crc miteinander verglichen werden. Bis jetzt stimmen crc und CRC noch überein.
Da ist jede Menge Optimierungspotential enthalten, aber ich kann's nicht besser.
Gruß Eberhard
PS: Ein LogFile zeigt die Schwächen der Programmierung: Während CRC bereits einen neuen Wert besitzt wird der crc noch mit dem bisherigen Wert geloggt. Grundsätzlich scheint es zu funktionieren.
Ich kann auch kein Perl, aber zwei Optimierungsmöglichkeiten sind mir trotzdem spontan ins Auge gesprungen:
1. Du kannst die Zuweisung von UL1 vor die for-Schleife ziehen, dann muß sie nur einmal passieren und nicht bei jedem Durchlauf von neuem.
2. Du kanst UL1 gleich mit dem Wert 1<<63 initialisieren, dann fällt der Teil der Bitschieberei auch noch aus der Schleife raus.
Funktioniert. Zwei Einäugige sehen nun mal besser als einer. Danke.
Schönen Tag
Eberhard
Jetzt ist mir noch was aufgefallen:
Wenn ich das richtig sehe, setzt Du die 64-Bit-Variable zuerst aus den einzelnen Bits zusammen, die in einem Array von Bitwerten vorliegen. Dann nimmst Du den Wert durch Shifting und Maskierung wieder Bit für Bit auseinander. Stattdessen könntest Du in der CRC-Schleife über den Array-Index iterieren und die Bits direkt aus dem Array ins CRC-Register schieben.
Alternativ liegt das Telegramm vielleicht in Deinen Eingabedaten eh schon in einer Form vor, die Du direkt in einen langen Integer wandeln und an die CRC-Schleife übergeben kannst. Die müßte statt über alle 64 bits zu laufen stattdessen nur die Bits herauspicken, über die der CRC berechnet werden soll, was auch wieder einige Schleifendurchläufe einsparen würde.
Hallo rmax,
ZitatWenn ich das richtig sehe, setzt Du die 64-Bit-Variable zuerst aus den einzelnen Bits zusammen, die in einem Array von Bitwerten vorliegen.
Siehst Du - ich verstehe Dich nicht, weil meine Kenntnisse absolut nicht ausreichen. Welche 64-Bit-Variable? Ich habe nur die $UL1 mit 64 bits definiert. $bits ist nur so breit, wie die binären Nutzdaten breit sind, nämlich nur 36 bit.
ZitatAlternativ liegt das Telegramm vielleicht in Deinen Eingabedaten eh schon in einer Form vor, die Du direkt in einen langen Integer wandeln und an die CRC-Schleife übergeben kannst.
Ich habe mal irgendwo gelesen, dass Perl die Variablendeklarierung wie integer, long integer, unsigned integer usw. automatisch machen soll. Ich weiß z.B. nicht wie ich ein 64bit lange binäre Zahl definieren soll/kann. Deshalb habe ich auch zu dem Konstrukt mit $UL1 =0b.... gegriffen.
Am momentanen Punkt bin ich mit meinem Latein am Ende. Du scheinst für mich in C tiefer drin zu stecken als ich.
Gruß Eberhard
OK, dann hier mal wie ich denke, daß es auch (und effizienter) funktionieren müßte, wenn ich Deinen Code (vor allem ReadingsVal() und das drum herum) richtig verstanden habe:
crc {
my $s = (ReadingsVal($name,'state',''));
my @a = split(/\s+/,$s);
my $s = $a[1];
my $bits = ($s>>10);
my $CRC = ($s>>6) & 0b1111;
my UL1=1<<35;
my $crc = 0;
my $i = 0;
for ($i = 0; $i < 36; $i++) {
$crc <<= 1;
if ($bits & $UL1) {$crc |= 1};
if ($crc & 0b0010) {$crc ^= 0b0011};
$bits <<= 1;
}
return ($crc & 0b1111);
}
Es könnte sein, daß bei der Zuweisung von $s noch zusätzlich was passieren muß, damit die Daten in $s dann tatsächlich als binärer Integerwert vorliegen.
Um $bits zu setzen schiebe ich den Datenblock um 12 Bits nach rechts, CRC und Nullbytes am Ende fallen damit raus. Maskieren muß ich an der Stelle nichts, denn es bleiben ja nur die 36 Bits, die ich sehen will.
Um die empfangenen CRC-Bits zu bekommen, schiebe ich die Padding-Bits raus und maskiere die dann letzten vier Bits. Das dient hier aber nur der Illustration, denn der Wert wird in der Routine ja nicht weiter verwendet.
Das gesetzte Bit in UL1 habe ich entsprechend der Datenlänge auf die Position 35 reduziert und auch die Schleife läuft nur noch 36 Mal durch.
Ich kann das allerdings nicht testen, weil ich FHEM selber (noch) nicht einsetze.
Das sieht ja richtig gut aus! Aber leider funktioniert die Prüfung noch nicht einwandfrei. Ich mach mich morgen (Do) oder am Freitag mal auf die Suche, wo der Hase begraben liegt.
Verstanden habe ich die neuen Zeilen, also beste Voraussetzungen den Fehler zu finden.
Gruß
Eberhard
Ich habe mal versucht etwas zu finden:my $s = $a[1];
Danach habe ich in $s den hex-Wert = 2E609580CBC0 oder binär = (00)1011100110000010010101100000001100101111000000. Hier fehlen bereits zwei Nullen vorneweg. Das liegt aber am Umrechnen, da werden die führenden Nullen nicht angezeigt.
Danach: my $bits = ($s>>10);Jetzt sind in $bits alles Einsen ( 111111111111111111111111111111111111111111111111111111) und die Stellenanzahl ist von 46 auf 54 angestiegen. Das lässt vermuten, dass die beiden ersten Stellen doch da waren und weil sie 0 waren, bei meiner Umrechnung nicht berücksichtigt wurden. Sind die Einsen eine Folge von Überlauf? Das shiften >> hat nochmal 8 Stellen hinzugefügt.
Keine Ahnung wieso. Ich bin kurz davor aufzugeben.
Gruß Eberhard
Keine Panik, das kriegen wir schon hin. :)
Das Problem war, daß die Daten in $a[1] noch als String aus Hex-Ziffern vorliegen, wir brauchen sie in $s aber für die Bitschieberei als numerischen Wert, was hex() für uns erledigt. Außerdem fehlte noch ein $ bei der Deklaration von UL1 und ich hatte in der Schleife noch einen Fehler.
Deshalb hier nochmal die komplette Routine:
crc {
my $s = (ReadingsVal($name,'state',''));
my @a = split(/\s+/,$s);
my $s = hex($a[1]);
my $bits = ($s>>10);
my $CRC = ($s>>6) & 0b1111;
my $UL1 = 1<<35;
my $crc = 0;
my $i = 0;
for ($i = 0; $i < 36; $i++) {
$crc <<= 1;
if ($bits & $UL1) {$crc |= 1};
if ($crc & 0b10000) {$crc ^= 0b0011};
$bits <<= 1;
}
return ($crc & 0b1111);
}
Wenn ich da jetzt mangels der restlichen Infrastruktur an Stelle von $a[1] manuell den Hex-String aus Deinem letzten Post einsetze und es damit durchlaufen lasse, bekomme ich den erwarteten CRC-Wert. Mit weiteren Telegrammen habe ich es noch nicht getestet.
Das sieht jetzt sehr gut aus. Beide CRC-WErte (mitgeliefert und berechnet) stimmen jetzt seit Telegrammen mehreren überein. Ich schreibe sie jetzt mal eine Zeit in ein FileLog und melde mich am Wochenende wieder.
Gruß Ebrhard
Hallo rmax,
ich kann das Ergebnis schon vorzeitig bekanntgeben: Ein grßes Lob für den Programmierer!! Ich habe im Log keinen Fehler gefunden. In der Anlage habe ich die WErte der letzten Stunden aufgelistet. Zum Inhalt: Zuerst ist die ID des Thermosensensors zu finden, danach das komplette Telegramm, und am Schluss die zwei CRC-Werte (erster Wert: mitgeliefert, zweiter Wert berechnet). Der gesamte Bereich von 0-15 erscheint im Listing.
Das wird für Jürgen eine gute Grundlage werden, diesen CRC-Check in die 14_CUL_TCM97001 einzubauen. Danke für Deine Hilfe.
Viele Grüße
Eberhard
PS: my $bits = ($s>>10);
my $CRC = ($s>>6) & 0b1111;
my $UL1 = 1<<35; Diese Schreibweise wäre genaugenommen falsch, da Perl vor und hinter den logischen Operatoren Leerzeichen haben will.
Hallo Eberhard + rmax,
bin wieder aus dem Urlaub zurück und arbeite mich nach dem "RESET" erst wieder in das Thema ein.
Wie ich sehen konnte, seid Ihr schon sehr weit gekommen :)
Mein Respekt dafür!
ZitatDas wird für Jürgen eine gute Grundlage werden, diesen CRC-Check in die 14_CUL_TCM97001 einzubauen
Da bin ich leider der falsche Adressat um das in ein Perlmodul von FHEM einzubauen.
Bei mir sträubt sich leider innerlich alles, um in Perl zu programmieren ... will aber keine unnötige Diskussion darüber losbrechen ... ;)
Was mein Ziel war, ist eine Art Zwischeninterface zu programmieren um dieses Protokoll in ein schon von FHEM bearbeitbares wie z.B. "CUL_TX" umzusetzen.
@Eberhard,
Du könntest evtl. mein Einstieg erleichtern, wenn Du Deine Vorgehensweise in ein kurzes Gesamtbild (Code) zusammensetzen könntest.
Das würde mir sehr weiterhelfen, sonst muss ich doch alles aus den Thread-Puzzleteilen zusammensetzen.
Ich muss mir die Hardware + SW leider nach einer leidigen Win10-Neuinstallation erst wieder zusammenbauen.
Ich schaue mal was ich aus den Git-Repositories wieder verwenden kann und melde mich wieder.
Grüße,
Jürgen
Hallo Jürgen,
da war ich (mal wieder) auf dem falschen Dampfer. Ich dachte Du würdest das Modul anpassen können. Wäre es nicht einfacher und eleganter, wenn ich den "Erbauer" des Moduls 14_CUL_TCM97001 anspreche, dass er den neuen Sensor in das Modul einpflegt?
Gruß Eberhard
Hi,
Und das wäre laut
version
"14_CUL_TCM97001.pm 12994 2017-01-07 07:49:53Z bjoernh"
@bjoernh: Hi Björn liest Du hier schon mit?
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Hallo Eberhard,
es spricht ja nichts dagegen zweigleisig zu fahren, primär FHEM, klar.
Bei meiner Infrastruktur ist es leider so, dass die Platzierung der Sender nur
einen mäßigen Empfang ermöglichen.
Die Sensoren sind außerdem sehr gesprächig, will meinen sie senden alle 20 Sek. für 2..3 Sekunden
ihr Telegramm mit 5 Wiederholungen.
Schon bei Verwendung von zwei solcher Sensoren kann es HF-mäßig eng werden und der CRC ist für einen
Einwandfreien Empfang durchaus erforderlich. Je näher sie am CUL positioniert sind desto mehr "buttern" sie
Telegramme von anderen Sensoren zu.
@RaspiLED
danke für die Info des Maintainers: björnh.
Hoffe Björn liest mit und nimmt sich dem Thema an.
Grüße,
Jürgen
Ich habe mal versucht meine Kenntnisse in eine 14_CUL_TCM97001.pm einzubauen. Fehlermeldungen bekomme ich zwar keine mehr, aber einiges läuft schräge. Die bisherigen Nicht-NC-Sensoren werden tadellos gelesen. Ich habe mit den NC7415 noch Probleme. Es wird zwar ein Unknown-Device angezeigt mit dem gesamten richtigen Telegramm, aber Readings werden keine erzeugt.
Dieses habe ich als CRC-Check hinzugefügt:
################################################
#
# CRC-Check for Pearl NC7415(7427)
#
sub checkCRC_NC7415
{
my $msg = shift;
my @a = split("", $msg);
my $dataBin = hex($msg);
my $bin = undef;
# Erzeugung der Binärzahl, über die die Prüfsumme berechnet werden soll
# nämlich Bit0 bis Bit36
my $data = ($dataBin >> 10);
# Berechnung der mitgelieferten CRC-Sequenz
my $CRCCHECKVAL = ($dataBin >> 6) & 0b1111 ;
my $UL1 = 1 << 35;
my $CRC = 0;
my $i = 0;
#Berechnung der CRC-Zahl
for ($i = 0; $i < 36; $i++)
{
$CRC <<= 1;
if ($data & $UL1) {$CRC |= 1};
if ($CRC & 0b10000) {$CRC ^= 0b0011};
$data <<= 1;
}
$CRC &= 0b111;
#Vergleich der mitgelieferten CRC-Zahl ($CRCCHECKVAL) mit der berechneten CRC-Zahl ($CRC)
if ($CRC == $CRCCHECKVAL)
{
return TRUE;
}
return FALSE;
}
sub checkValues
{
my $temp = shift;
my $humidy = shift;
if (!defined($humidy))
{
$humidy = 50;
}
if ($temp <= 60 && $temp >= -30 && $humidy >= 0 && $humidy <= 100)
{
return TRUE;
}
return FALSE;
}
[/b]
Ich weiß nicht, wie ich mir bestimmte Werte zur Fehlereingrenzung anzeigen lassen kann. Gibt des da eine Möglichkeit entweder den gewünschten Wert auf die Konsole oder in das Log zu schreiben?
Hier die Aufbereitung der Daten, wie sie in der 14_CUL_TCM97001.pm eingefügt wurden:
#######################################################################################
# Hinzugefuegt von Fhem2005
# Aufbereitung der Daten von NC 7415 (7427)
#######################################################################################
if (checkCRC_NC7415($msg) == TRUE && ($readedModel eq "NC7415" || $readedModel eq "Type1" || $readedModel eq "Unknown")
|| checkCRC_Type1($msg) == TRUE && ($readedModel eq "Type1" || $readedModel eq "GT_WT_02" || $readedModel eq "Unknown"))
{
$temp = (hex($a[3].$a[4])& 0x3C) >> 2;
$temp += ((hex($a[4].$a[5])& 0x3C) >> 2) * 16;
$temp += ((hex($a[5].$a[6])& 0x3C) >> 2) * 256;
$temp = (($temp-900)/10 - 32)*5/9;
$temp = int(10 * $temp + 0.5) / 10;
$humidity = (hex($a[6].$a[7])& 0x3C) >> 2;
$humidity += ((hex($a[7].$a[8])& 0x3C) >> 2) * 16;
if ($humidity > 100)
{
# HH - Workaround
$humidity = 100;
}
elsif ($humidity < 20)
{
# LL - Workaround
$humidity = 20;
}
if (checkValues($temp, $humidity))
{
$channel = (hex($a[3]) & 0xC) >> 2;
$batbit = (hex($a[2]) & 0x3);
$mode = (hex($a[2]) & 0x4) >> 2;
if (checkCRC_NC7415($msg) == TRUE)
{
$model="NC7415";
}
else
{
$model="Type1";
}
if ($deviceCode ne $idType1) # new naming convention
{
if ( $enableLongIDs == TRUE || (($longids != "0") && ($longids eq "1" || $longids eq "ALL" || (",$longids," =~ m/,$model,/))))
{
Log3 $hash,4, "CUL_TCM97001 using longid: $longids model: $model";
}
else
{
$deviceCode="CUL_TCM97001_" . $model . "_" . $channel;
}
}
$def = $modules{CUL_TCM97001}{defptr}{$deviceCode};
if($def)
{
$name = $def->{NAME};
}
if(!$def)
{
Log3 $name, 2, "CUL_TCM97001 Unknown device $deviceCode, please define it";
return "UNDEFINED $model" . substr($deviceCode, rindex($deviceCode,"_")) . " CUL_TCM97001 $deviceCode";
}
$hashumidity = TRUE;
$hasbatcheck = TRUE;
$haschannel = TRUE;
$hasmode = TRUE;
$packageOK = TRUE;
$readedModel=$model;
}
else
{
$name = "Unknown";
}
}
Soweit der aktuelle Stand bei mir. Wenn ich es schaffe Zwischenwerte auslesen zu können, könnte ich wenigsten den CRC-Check überprüfen, ob dort TRUE oder FALSE zurückgegeben wird.
Die gesamte modifizierte Datei ist als Anlage beigefügt. In der pdf-Datei, sind die Passagen markiert, die gegenüber dem Original verändert wurden.
Gruß Eberhard
Hallo Eberhard,
zum Loggen in FHEM:
https://www.computerhilfen.de/info/fhem-selber-werte-ins-logfile-schreiben.html (https://www.computerhilfen.de/info/fhem-selber-werte-ins-logfile-schreiben.html)
@RaspiLed:
Habe das SVN + Maintainers.txt gefunden: contributors (https://svn.fhem.de/#contributors)
.. und nur so, als Info:
http://www.hjgode.de/wp/2015/11/25/fhem-batteriewarnung-per-email/comment-page-1/ (http://www.hjgode.de/wp/2015/11/25/fhem-batteriewarnung-per-email/comment-page-1/)
Hallo Jürgen,
das ist nicht, dass was ich wollte. Der Links erläutert, wie ein Event geloggt werden kann. Ich möchte aber innerhalb des Pearl-Programmes bestimmte Werte aus der Progranmmierung (z.B. $CRC) in das Log schreiben oder auf die Konsole ausgeben.
Gruß Eberhard
hallo Eberhard,
ja, schade.
Ich würde es so handhaben, ohne die FHEM-Möglichkeiten zu kennen:
https://www.perl.com/pub/2002/09/11/log4perl.html (https://www.perl.com/pub/2002/09/11/log4perl.html)
Lässt sich einfach installieren, konfigurieren und anwenden ...
Jürgen
Hallo Jürgen,
geht ganz einfach:
Log3 $name, 4, "CUL_TCM97001 $name $id3 ($msg) length: $l";
So eine ähnlich ezeile einfach in das Scropt einfügen und schon erscheint die Meldung im Log-File.
Hier mein aktueller Stand:
hatte doch etwas zu kämpfen um auf Stand zu kommen.
Meine Vorgehensweise:
1.) Pulse-Erkennung des Telegramms funktioniert sehr gut.
Die einzelnen bits werden in ein Byte-Array mit Länge 42 als Wert 0 oder 1 gespeichert.
Hier habe ich die Telegrammbits byteweise zur Verfügung, in der Reihenfolge, wie sie reinkommen.
2.) Um die Daten elegant aus einer Struktur bzw. Union lesen zu können, muss ich dann aber einiges "richten":
Hier die Definition, die das Protokoll wiederspiegelt, dafür (Grundlage dafür ist ein 64Bit-Integer):
union proto_union
{
unsigned long long raw;
struct proto_struct
{
unsigned long dummy : 22;
byte lead : 2;
byte id : 8;
byte bat : 2;
byte chan : 2;
unsigned short temp : 12;
byte hum : 8;
byte crc : 8;
} d;
} p;damit die Wertigkeiten dafür passen, muss ich die jeweiligen Wertigkeiten für ID+CH+Temp+Hum+Crc
binär im Byte-Array swappen. Dann steht alles richtig bzw. lesbar in den einzelnen Strukt-Elementen aus der Umwandlung des int64-Wertes.
Dann werden 15 Telegramme in einem Ringpuffer gehalten bzw. zwischengespeichert.
Das Ergebnis daraus, aus dem Seriell-Log des Arduinos:
Zitat------------------------------------------------------------
buffer.read: [4]
0_________10________20________30________40________50________60
0123456789012345678901234567890123456789012345678901234567890123
0000110101100010011110100110000010111101000000000000000000000000
ld: 0
id: 189
id_c: 61
bat: 0
ch: 0
tempF: 0x6A7
tempC: 26.83
hum: 98
crc: 13
raw: 964467826117050368
------------------------------------------------------------
FUNC ID: 61 [61] T: 26.83 H: 98.00
TX ID: 61 T: 26.83 H: 98.00
------------------------------------------------------------
Da LaCrosse nur Ids bis 127 zulässt, subtrahiere ich bei größeren IDs einfach 128 ab,
bzw. setze das 7te Bit der ID auf 0 (id/id_c).
Mein Problem besteht im Moment noch aus:
a.) der falsche HUM-Wert
b.) die "passgenaue" Einbindung der CRC-Unterroutine.
Den int64-Wert für den CRC-Aufruf habe ich, vermute aber, nach der Anpassung mit der Bit-Tauscherei passt das nicht mehr ...
Oder ist nur die Anzahl der Einsen und Nullen relevant, egal in welcher Kombination? (... sah für mich so aus, muss ich noch Testen)
Da ich den Struct und die Union vor den eigentlichen Werten definiert hatte, ist die Bitorder des Telegramms
zu allem Überfluss noch im int64 gedreht, was aber nicht unbedingt stört (aber der Wert der im FHEM-EventMonitor angezeigt wird, passt dann leider nicht zusammen).
Mal schauen, ob das heute noch in Griff zu bekommen ist ...
Grüße,
Jürgen
Zitat------------------------------------------------------------
buffer.read: [1]
0 10 20 30 40 50 60
0123456789012345678901234567890123456789012345678901234567890123
1000001001100010000110100110000010111101000000000000000000000000
ld: 0
id: 189
id_c: 61
bat: 0
ch: 0
tempF: 0x6A1
tempC: 26.50
hum: 98
crc: 130
crc_2: 0
raw: 805166183438352384
------------------------------------------------------------
FUNC ID: 61 [61] T: 26.50 H: 98.00
TX ID: 61 T: 26.50 H: 98.00
------------------------------------------------------------
Ein Versuch die CRC-Routine mit dem Raw-Wert aufzurufen,liefrt immer 0. (CRC Bits sind aber noch dabei und noch nicht ausmaskiert) .
uint_64t musste ich in "unsigned long long" setzen, da der Atmel-Compiler einen 32Bit-Datentyp daraus macht.
//-------------------------------------------------------------
//uint8_t CRC(uint64_t bits)
uint8_t CRC(unsigned long long bits)
{
uint8_t crc; int i;
for (i = 0; i < 64; i++) {
crc <<= 1;
if (bits & (1UL << 63)) crc |= 1;
if (crc & 0x10) crc ^= 0x3;
bits <<= 1;
}
return (crc & 0xf);
}
Zu meinem größten Bedauern funktioniert es nicht so, wie ich es mir vorstelle. Es kommen zwar keine Fehlermeldungen, aber der 7415 wird immer noch als 'Unknown' erkannt. Ein Status wird auch angezeigt, und zwar das richtige 12 Byte lange Datentelegramm, welches ja als UserReading gut verarbeitet werden kann. Mal sehen ob Björn ein Erbarmen mit uns hat und die 14_CUL_TCM97001.pm ergänzt. ....
@Jürgen
obwohl wir hier nicht ein Arduino-Forum sind ;)....
1. Ich finde die Berechnung der Hum in der .ino-Datei nicht
2. Gibt es beim 7415 keinen Kanal 0 (die Bitfolge 00 ist bereits Kanal 1)
3. Ich habe die Hum mal nachgerechnet (ausgehend vom 2F41E9988340in Deinem Bild) komme ich auf "38"
4. Wenn ich 2F41E9988340 in binär umsetze bekomme ich 0010 1111 0100 0001 1110 1001 1001 1000 1000 0011 0100 0000. Das weicht stark von der auf Deinem Zettel enthaltenen Bitfolge ab.
Bei der Größe ist es schwer sich in die Gedankengänge eines anderen Programmierers einzufräsen. Auf welchem Board soll es denn laufen?.
Gruß
Eberhard
Zitat@Jürgen
obwohl wir hier nicht ein Arduino-Forum sind
Ja, werde meinen Teil in die Bastelecke verlegen ... ;)
Wobei man die Telegrammerfassung auf für den "CUL-Hard- und Firmware"-Bereich nutzen kann. (aculfw?) :D
Zitat1. Ich finde die Berechnung der Hum in der .ino-Datei nicht
Durch den Aufbau der Struktur und der Union ist der Speicherbereiche der gleiche.
So dass man einen Wert an den 64bittigen Raw-Wert übergibt, dann enthalten die anderen Struct-Variablen automatich
die Bitweise Zuweisung. Sofern Endianness und Padding stimmen.
Zitat3. Ich habe die Hum mal nachgerechnet (ausgehend vom 2F41E9988340in Deinem Bild) komme ich auf "38"
Stimmt wird bei mir so angezeigt. Habe 2 aktive Sensoren.
Da habe ich noch ein System-/Denkfehler drin, den ich noch finden muss.
ZitatBei der Größe ist es schwer sich in die Gedankengänge eines anderen Programmierers einzufräsen. Auf welchem Board soll es denn laufen?.
Ja. Auf jedem Arduino. Zu berücksichtigen ist nur die INT-Nummer für D2, die bei den Modellen unterschiedlich sein kann.
Die Eigentliche Verarbeitung erfolgt im Interrupt, die Loop-Routine wertet dann nur fertig empfangene Telegramme aus.
Grüße,
Jürgen
Hallo Jürgen,
offensichtlich stimmt das bitpos swapping nicht richtig. Wäre es nicht sinnvoller, das gesamte Telegramm in einem Schritt umzusetzen und dann nur noch auf die umgesetzten Daten zuzugreifen?
Gruß Eberhard
#include <stdio.h>
#include <stdint.h>
uint8_t CRC(unsigned long long bits);
int main()
{
/* # F F 0 0 F 9 5 5 F
# 1111 1111 0000 0000 1111 1001 0101 0101 1111
# A B C D E F G H I
# A+B = Zufällige Code wechelt beim Batteriewechsel
# C Bit 4 Battery, 3 Manual, 2+1 Channel
# D+E+F Temperatur, wenn es negativ wird muss man negieren und dann 1 addieren, wie im ersten Post beschrieben.
# G+H Hum - bit 0-7
# I CRC?
*/
unsigned long long value = 0xFF00F955F ; //0x19C6CDA08040;
printf("CRC:\t%d\n" , CRC(value) );
return 0;
}
//-------------------------------------------------------------
//uint8_t CRC(uint64_t bits)
uint8_t CRC(unsigned long long bits)
{
uint8_t crc; int i;
for (i = 0; i < 64; i++) {
crc <<= 1;
if (bits & (1UL << 63)) crc |= 1;
if (crc & 0x10) crc ^= 0x3;
bits <<= 1;
}
return (crc & 0xf);
}Mit dem Ergebnis:
ZitatCRC: 15
Also muss mit allen Bits (inkl. CRC?) berechnet werden..
Deswegen bin ich noch mal auf das übertragene Protokoll zurückgegangen
und glaube die Problematik zumindest mal darstellen zu können ...
Die 42 Bits des Protokolls ergeben nur 10,5 Nibble (4er Bitfolgen), es müssen also noch 0-Bits bis auf die 64Bit (QWord) aufgefüllt werden.
Gebe ich obiges mit zwei Nullen komplettiertes Beispiel hier, im Simulator (https://www.tutorialspoint.com/compile_c_online.php) ein (mit compile+execute):
#include <stdio.h>
#include <stdint.h>
uint8_t CRC(unsigned long long bits);
int main()
{
unsigned long long value = 0x2F4119A4C3C;
printf("CRC:\t%d\n" , CRC(value) );
return 0;
}
//-------------------------------------------------------------
uint8_t CRC(unsigned long long bits)
{
uint8_t crc; int i;
for (i = 0; i < 64; i++) {
crc <<= 1;
if (bits & (1UL << 63)) crc |= 1;
if (crc & 0x10) crc ^= 0x3;
bits <<= 1;
}
return (crc & 0xf);
}Kommt 15 als CRC heraus. Passt also jetzt (..auch mit anderen Werten).
Muss jetzt also nur noch die Zuordnung + Reihenfolge der empfangenen Bits prüfen.
Die ersten Bits beginnend mit der Id usw. sind entgegen meiner Annahme die höherwertigsten
in der uint64-Zuweisung aus der ich dann die Einzelinfos herausziehen.
Hier muss ich morgen die Zuordnung innerhalb der uint64_t-Variablen noch richtig setzen, dann sollte es passen.
Was ich nicht verstehe, warum FHEM 12 Nibbles liefert:
Zitat2017-07-25 20:20:03 CUL_TCM97001 Unknown Code: 2F4295ACC1C0
Hallo Jürgen,
ZitatWas ich nicht verstehe, warum FHEM 12 Nibbles liefert:
..weil das richtig ist! :)
Vor dem eigentlichen Datenblock liegen noch zwei Bits ( 0 und 1) deren Wert immer Null ist. Danach folgen von Bit 2 bis 33 die eigentlichen Daten. Zwischen den Daten der Hum (26 bis 33) und den 4 Bits der Prüfsumme (38 bis 41) liegen 4 Bits (34 bis 37), deren Bedeutung unklar ist. Am Schluss folgen sechs Bits (42 bis 47) die fast immer Null sind und nicht in die Berechnung einbezogen werden. Das macht zusammen 48 bits = 12 Nibbles.
Deine Betrachtung, dass die Prüfziffer in Bit 34-41 liegt, stimmt nur deshalb, weil die Bits 34-37 Null sind. Der CRC Wert über 33-41 ist also identisch mit dem WErt wenn er über Bit 38 bis 40 gebildet wird. Sie müssen aber nicht immer Null sein, dann passt DEINE Prüfziffernberechnung nicht mehr.
rmax berechnet die Prüfsumme über die Bits 0 bis 37; sie schließt die eigenen Bits (38 bis 41)
nicht mit ein. Macht auch keinen Sinn.
... aus dem o.a. Grund liefert FHEM 12 Nibbles.
Gruß Eberhard
Hallo Eberhard,
Zitatrmax berechnet die Prüfsumme über die Bits 0 bis 37; sie schließt die eigenen Bits (38 bis 41) nicht mit ein...
Danke, das werde ich so implementieren.
Jürgen
Hi,
Gibts denn schon etwas Neues zu dem Thema NC7427?
Gruß Christian
... ich schließe mich den Ausführungen meines Vorredners an. ;D ;D
Dürfen wir uns was wünschen, obwohl Weihnachten vorbei ist? Ich meine wir haben gute Vorarbeit geleistet und wollen nun die Früchte unserer Mühen auch ernten (Teufel, hört sich das gut an!!!) 8) 8) 8)
Viele Grüße
Eberhard
Hallöchen,
war mit dem BME680 - den "four in one" - Sensor doch zu stark beschäftigt, um hier weiterzumachen.
Aber, wenn wirklich Interesse besteht können wir das noch in die Todo-Queue setzen. ;) ;)
Der Sensor sendet alle 10 Sekunden ca. ca Repetitions, verseucht also die 433 MHz-Welt ganz gehörig ....
und der BME680 hat Temp/Hum/Press und Luftgüte ....
Leider hab ich auch noch zwei von den NCS hier rumliegen ....
Grüße,
Jürgen
Ich muss gestehen... der BME680 ist mir persönlich zu teuer... mit 3D-Druckgehäuse etc. ist man ganz schnell bei 40-50€ und das dann pro Raum...
Mehr als 3 NCS würde ich auch nicht empfehlen.
Nur, wenn sonst keine anderen Sensoren im Umfeld sind... ;)
Hallo Jürgen,
ZitatLeider hab ich auch noch zwei von den NCS hier rumliegen ....
Willkommen im Club. Ich habe hier genau 3 mit Übergangslösung in Betrieb.
ZitatAber, wenn wirklich Interesse besteht können wir das noch in die Todo-Queue setzen.
Wenn wir kein Interesse hätten, gäbe es diesen Thread nicht. ;) ;)
ZitatMehr als 3 NCS würde ich auch nicht empfehlen.
Da bin ich absolut bei Dir, und dann aufpassen, dass jeder in einem eigenen Kanal läuft. Wenn ich mich an das letzte Öffnen erinnere, hat der drei einstellbare Kanäle.
Freue mich schon auf die Integration in CUL_TCM97001. Das erspart mir 100 Zeilen in der fhem.cfg ;D ;D
Gruß Eberhard
Darf ich mich als Interessent an der Lösung zu diesem Thema noch einmal in Erinnerung bringen?
Helau, Alaaf und was man/frau sonst noch zu den tollen Tagen ruft.
Eberhard
Hallo Eberhard,
bin bei Dir ... jetzt an Fasching mit Schlafmangel etwas schwieriger ;D
Grüße,
Jürgen
Hallo Jürgen,
das ist verständlich. Denk' mal dran, wenn alle Deine Pegel (Schlaf, Promille und Arbeitslust) wieder im Normalbereich liegen. ;D ;D ;D
Gruß Eberhard
Zitat von: FHEm2005 am 10 Februar 2018, 08:00:28
... wenn alle Deine Pegel (Schlaf, Promille und Arbeitslust) wieder im Normalbereich liegen. ;D ;D ;D
Hoffentlich kommt da nicht eine leere Menge raus ;D ;D ;D
Gruß PeMue
Nee. :D
Aber noch ein "Unimplemented Device" :'(
Zitat2018.02.10 17:10:24 4: CUL_Parse: MAPLE433 s0D425594860009; 432: 8000
2018.02.10 17:10:24 5: MAPLE433: dispatch s0D425594860009; 432: 8000
2018.02.10 17:10:24 4: CUL_TCM97001 Unknown 13 (0D425594860009) length: 14 RSSI: -69.5
2018.02.10 17:10:24 3: CUL_TCM97001 Message length: 14
2018.02.10 17:10:24 4: CUL_TCM97001 Device not implemented yet name Unknown msg 0D425594860009
An
Message length: 14werden wir ansetzen müssen...
Ich sehe eher eine Länge von 12:
Trailer vorne: 2bits
ID: 8 bits
Batterstatus: 2 Bits
Kanal: 2 Bits
temperatur: 12 bits
Feuchtigkeit: 8 Bits
CRC: 8 Bits
Trailer hinten: 6 Bits
Summe:48 bits oder 12 Nibbles
Ich wüsste nicht wie die 14 zustande kommen sollen.
Gruß Eberhard
Hallo Eberhard,
die 14 ist die Summe der Chars der Message mit der das TCM-Modul auf das Device differenziert. ;-)
hallo Jürgen,
Ich nehme das mal so hin, weil ich es nicht verstehe. :) Ich muss nicht alles verstehen. ;D
Ich hatte mal vor einiger Zeit den CRC-Check für das Modul 14_CUL_TCM... gebaut.Vielleicht hilft es Dir. Ich konnte nicht prüfen, ob es funktioniert.
################################################
#
#CRC-Check for Pearl NC7415(7427)
#
sub checkCRC_NC7415
{
my $msg = shift;
Log3 "CUL_TCM97001",3,"msg: $msg";
my @a = split("", $msg);
my $x = undef;
my $dataBin = undef;
foreach $x (@a)
{
my $bin3=sprintf("%04b",hex($x));
$dataBin = $dataBin . $bin3;
}
# my $dataBin = hex($msg);
my $bin = undef;
# Erzeugung der Binärzahl, über die die Prüfsumme berechnet werden soll
# nämlich Bit0 bis Bit36
my $data = ($dataBin >> 10);
Log3 "CUL_TCM97001", 3, "data: $data";
# Berechnung der mitgelieferten CRC-Sequenz
my $CRCCHECKVAL = ($dataBin >> 6) & 0b1111 ;
my $UL1 = 1 << 35;
my $CRC = 0;
my $i = 0;
#Berechnung der CRC-Zahl
for ($i = 0; $i < 36; $i++)
{
$CRC <<= 1;
if ($data & $UL1) {$CRC |= 1};
if ($CRC & 0b10000) {$CRC ^= 0b0011};
$data <<= 1;
}
$CRC &= 0b111;
Log3 "CUL_TCM97001",3,"CRC geliefert: $CRC berechnet: $CRCCHECKVAL ";
if ($CRC == $CRCCHECKVAL)
{
return TRUE;
}
return FALSE;
}
danach hatte ich die eigentliche Brechnung der Daten unter der Rubrik: # Länge $msg == 12 ******************************************************************* eingetragen. Er stand bei mir unter "elseif (length($msg) == 12". alsoeWenn Du jetzt sagst, das Länge $msg ==14 ist, muss ich mich nicht wundern, dass es nie funktioniert hatte.
Diesen Code hatte ich mal hier irgendwann gepostet. Der Einfachheit halber hier noch einmal:
# ######################################################################################
# Hinzugefuegt von Fhem2005
# Aufbereitung der Daten von NC 7415 (7427)
# ######################################################################################
if (checkCRC_NC7415($msg) == TRUE && ($readedModel eq "NC7415" || $readedModel eq "Type1" || $readedModel eq "Unknown")
|| checkCRC_Type1($msg) == TRUE && ($readedModel eq "Type1" || $readedModel eq "GT_WT_02" || $readedModel eq "Unknown"))
{
# 2 E 4 0 A 9 A C 8 3 4 0
# 00|10 1110 01|00| 00|00 1010 1001 10|10 1100 10|00 00|11 01|00 0000
# | ID |B | CH| T | H | | PZ |
#
# bit 0 und 1 sind immer Null
# bit 2 bis 9 enthalten eine ID, die sich bei Batteriewechsel aendert
# bit 10 und 11 enthalten den Batteriestatus [B]
# bit 12 und 13 die Kanalnummer 1-2-3 [CH]
# bit 14 bis 25 die Temperatur [T]
# bit 26 bis 33 die Feuchtigkeit [H]
# bit 34 bis 37 unbekannt
# bit 38 bis 41 die Pruefziffer (0 - 15) [PZ]
# bit 42 bis 47 immer Null
# Es kommen noch zwei weitere Bits an, also insgesamt 14 bytes
#$def = $modules{CUL_TCM97001}{defptr}{$idType3};
$temp = (hex($a[3].$a[4])& 0x3C) >> 2;
$temp += ((hex($a[4].$a[5])& 0x3C) >> 2) * 16;
$temp += ((hex($a[5].$a[6])& 0x3C) >> 2) * 256;
$temp = (($temp-900)/10 - 32)*5/9;
$temp = int(10 * $temp + 0.5) / 10;
Log3 $name , 3, "T: $temp";
$humidity = (hex($a[6].$a[7])& 0x3C) >> 2;
$humidity += ((hex($a[7].$a[8])& 0x3C) >> 2) * 16;
if ($humidity > 100)
{
# HH - Workaround
$humidity = 100;
}
elsif ($humidity < 20)
{
# LL - Workaround
$humidity = 20;
}
if (checkValues($temp, $humidity))
{
$channel = (hex($a[3]) & 0xC) >> 2;
$batbit = (hex($a[2]) & 0x3);
$mode = (hex($a[2]) & 0x4) >> 2;
if (checkCRC_NC7415($msg) == TRUE)
{
$model="NC7415";
}
else
{
$model="Type1";
}
# ************** Ende der Änderungen von FHEM2005
Ich poste extra nicht die ganze Datei, weil diese nicht lauffähig ist. Nicht das Jemand glaubt es wäre eine neue Version. Wenn der obige Code Müll ist, ignoriere ihn einfach. War nur gut gemeint. Ich sehe gerade dass ich damals schon bemerkt hatte, dass 2 Bytes mehr ankommen, wusste aber nichts damit anzufangen (2. Codeblock am Ende der anfänglichen Bemerkungen). Dann beißt sich natürlich der Platz, wo ich meinen Code hingeschrieben hatte. Da ich fast Null Perl kann, bin ich hier dann aus raus.
Gruß Eberhard
Hallo Eberhard,
ZitatIch konnte nicht prüfen, ob es funktioniert.
Genau das ist auch mein Problem!
Ich bin bis jetzt folgendermaßen vorgegangen um unter Windows 10 Perl-Code Debuggen zu können:
1. VSCode (https://code.visualstudio.com/docs/editor/debugging#_launch-configurations) Einstellen (http://zqpythonic.qiniucdn.com/data/20170425091408/index.html) + vscode (https://code.visualstudio.com/)
https://stackoverflow.com/questions/41734738/debugging-perl-with-visual-studio-code (https://stackoverflow.com/questions/41734738/debugging-perl-with-visual-studio-code)
2. Perl-Debug Addin direkt in VSCode hinzugefügt Infos (https://github.com/raix/vscode-perl-debug)
3. In Perl "PadWalker" installiert.
"cpan padwalker" in Konsole ausführen (Strawberry Perl).
4. Die Einstellungen für FHEM in
launch.json aus dem Japanischen (https://translate.google.de/translate?sl=ja&tl=de&js=y&prev=_t&hl=de&ie=UTF-8&u=https%3A%2F%2Fqiita.com%2Ftake_3%2Fitems%2Fe889be9878e8516c89a3&edit-text=) übersetzt, mit nützlichen Tipps.
Hier meine Einstellungen für
launch.json:
{
// Use IntelliSense to learn about possible attributes.
// Hover to view descriptions of existing attributes.
// For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
"version": "0.2.0",
"configurations":
[
{
"type": "perl",
"request": "launch",
"exec": "D:\\Strawberry\\perl\\bin\\perl.exe",
"execArgs": ["-Mfhem::14_CUL_TCM97001", "-MFHEM::SetExtensions"],
"name": "Perl Debug",
"root": "${workspaceRoot}",
//"program": "${workspaceRoot}/${relativeFile}",
"program": "D:\\fhem\\fhem-5.7\\fhem.pl",
"inc": ["D:\\fhem\\fhem-5.7\\FHEM"],
"args": ["fhem.cfg"],
"stopOnEntry": true
}
]
}Um erfahren zu müssen, daß das (visuelle) Debuggen von Perl-Code auf flacher Skript-Ebene sehr gut geht,
aber bei der Einbindung der dynamischen Fhem-Module es doch schwieriger wird als erwartet.
Das hier
"execArgs": ["-Mfhem::14_CUL_TCM97001", "-MFHEM::SetExtensions"],hab ich geraten, scheint teilweise zu funktionieren, aber wiederum auch nicht ...
Das Debuggen der FHEM.pl geht schon mal (immerhin) ...
Da das mit dem "normalen" Debuggen in VSCode jetzt klappt, kann man ja erst mal mit einem einfachen Testcase anfangen. :)
Noch zur dataLength $msg=14:
12345678901234
2018-02-11 13:19:39 CUL_TCM97001 Unknown Code: 0D41919483C00CZitat2018.02.11 13:20:30 4: CUL_TCM97001 Device not implemented yet name Unknown msg 0D41919483C00C
2018.02.11 13:20:30 4: CUL_Parse: MAPLE433 s0D41919483C00C; 432: 7984
2018.02.11 13:20:30 5: MAPLE433: dispatch s0D41919483C00C; 432: 7984
2018.02.11 13:20:30 4: CUL_TCM97001 Unknown 13 (0D41919483C00C) length: 14 RSSI: -68
2018.02.11 13:20:30 3: CUL_TCM97001 Message length: 14
http://perldoc.perl.org/perldebug.html (http://perldoc.perl.org/perldebug.html)
Open Perl IDEhttp://www.lost-sunglasses.de/documentation/user-manual/environment.html (http://www.lost-sunglasses.de/documentation/user-manual/environment.html)
Scheitert wohl an Win10...
Win32 does not define $Win32::VERSION--version check failed at perl5db.pl line 435.
BEGIN failed--compilation aborted.
Compilation failed in require at perl5db.pl line 435.
Muss mich aber wieder etwas in das NCS-Protokoll + CRC-Bildung "einarbeiten" ...
Let's test NCS7415 ...
onException: Integer overflow in hexadecimal numberanbei mal der TestCase:
@Eberhard, ist das die aktuellste Version?
Telegramme kommen nicht immer vollständig rein:
Zitat2018-02-11 19:57:42 CUL_TCM97001 Unknown Code: 0D43D1948300
2018-02-11 19:57:42 CUL_TCM97001 Unknown Code: 0D43D1948300
2018-02-11 19:57:42 CUL_TCM97001 Unknown Code: 0D43D1948300
2018-02-11 19:57:42 CUL_TCM97001 Unknown Code: 0D43D1948300
2018-02-11 19:57:43 CUL_TCM97001 Unknown Code: 0D43D1948300
2018-02-11 19:57:43 CUL_TCM97001 Unknown Code: 5420039380
2018-02-11 19:57:44 CUL_TCM97001 Unknown Code: C501C002C0
Hallo Jürgen,
auch für mich ist das Thema lange her.
Der empfangene Code
0D43D1948300 deutet auf folgende Eigenschaften hin:
LD= 00
ID = 53
Bat = schwach
Kanal = 1
Temp = 21,9 °C bzw. 71,5 °F
rel. Feuchte = 37
CRC =12
Zitat@Eberhard, ist das die aktuellste Version?
Ich habe nur diese Version und die hat bei mir nicht funktioniert. Mit der beschriebenen Vorgehensweise kann ich nichts anfangen, weil ich kein Perl kann.
Den von Dir empfangenen Code habe ich in ein selbst gebasteltes Excel-Sheet eingesetzt und dann das Ergebnis abgelesen. Ich kann Dir wohl sagen, wie das Ergebnis aus dem Datentelegramm erzeugt wird, mit der Implementierung in das Modul kann ich Dir nicht helfen. Ich habe dir erst einmal das Excel-Sheet beigefügt. Die empfangene Sequenz (12byte)nur in Zelle B5 eingeben und das Ergebnis im Bereich D38:L44 ablesen. Jede Änderung in einem anderen Feld kann die gesamte Berechnung zerstören.
Die enthaltenen Tabellen CRC und Tabelle 3 sind Reste meiner Versuche die CRC herauszufinden. Da haben wir ja bereits eine Lösung. Alles das was kürzer als 12 byte ist kannst Du vernachlässigen. Die gehören vermutlich zu anderen empfangenen Sensoren.
Da bei mir die Sensoren über userReadings funktionieren, kann ich Dir noch die dort hinterlegte Berechnung geben - damit bin ich aber schon am Ende.
Gruß Eberhard
HalloJürgen,
Zitat@Eberhard, ist das die aktuellste Version?
Die geposteten Codeschnipsel sind definitiv nicht aus der aktuellen Version, sondern irgendwann habe ich versucht meinen Progarmmtext in das damalige Modul einzuarbeiten. Das war damals diese Version: $Id: 14_CUL_TCM97001.pm 12994 2017-01-07 07:49:53Z bjoernh $
Gruß Eberhard
Hallo Eberhard,
danke für die Info.
Bin gerade ein Influenza-Opfer, dauert also noch ein bisschen, bis ich wieder klar denken kann .. </hust>
Jürgen
Hallo,
gibt es hier noch Aktivitäten?
Gruß
Christian
Hallo Jürgen,
ich hoffe Du hast Deine Erkältung gut überstanden. ;) ;) ;)
Ich bin offensichtlich nicht der Einzige, der sehnsüchtig auf die Einarbeitung meiner damaligen Vorarbeit wartet. Es wird leider nicht einfacher sich jedes Mal erneut in dieses Thema einzuarbeiten.
Es gibt diesen Sensor (Außensensor) immer noch bei Pearl zu einem Preis von 3,40€ (!!) zu haben. Meine beiden Sensoren warten dringen auf die Erweiterung des Moduls.
Vielleicht schaffen wir es doch noch dieses Jahr.
Viele Grüße
Eberhard
Zitat von: FHEm2005 am 14 September 2018, 08:59:33
Hallo Jürgen,
ich hoffe Du hast Deine Erkältung gut überstanden. ;) ;) ;)
Ich bin offensichtlich nicht der Einzige, der sehnsüchtig auf die Einarbeitung meiner damaligen Vorarbeit wartet. Es wird leider nicht einfacher sich jedes Mal erneut in dieses Thema einzuarbeiten.
Es gibt diesen Sensor (Außensensor) immer noch bei Pearl zu einem Preis von 3,40€ (!!) zu haben. Meine beiden Sensoren warten dringen auf die Erweiterung des Moduls.
Vielleicht schaffen wir es doch noch dieses Jahr.
Viele Grüße
Eberhard
Hallo Zusammen,
... ok, ich sehe die Tage Tage werden kürzer...
Dann müssen wir wohl die Prio für diese Projekt wieder nach oben drehen. :D ;)
ZitatEs wird leider nicht einfacher sich jedes Mal erneut in dieses Thema einzuarbeiten.
Wie wahr ....
Grüße,
Jürgen
:) :) :) :) :) (freu, freu) :) :) :) :) :)
VG
...mal vorsichtig nachfragen...
gibt es hier schon Neuigkeiten?
Kann ich irgendwie unterstützen?
Grüße!
Kornelius
Hallo Jürgen,
ich verstehe leider nicht, worin die Schwierigkeit besteht das Gerät in das Modul einzuarbeiten. Die eigentliche Dekodierung ist klar, daran kann es also nicht liegen. Ich kann mich Kornelius nur anschließen: Wie kann ich Dich unterstützen?
Was habe ich?
Ich habe zwei dieser Geräte. Sie haben die (momentane) ID 58 ind 145. In der folgenden Definition werden die ankommenden Daten decodiert und als Readings (ID, temperature, humidity) angezeigt.
Zwei Readings (absFeuchte, dewpoint) werden automatisch zusätzlich hinzugefügt. Danach gehe ich hin und ordne die Daten, abhängig von der ID, den beiden Räumen Gästezimmer (rot) und Gästezimmer (blau) zu uns zeige diese sortierten Daten als Readings an. (siehe Bild). Im Bild sind gerade die Daten für die ID 58 neu angekommen.
Das ist nur eine Übergangslösung, weil eine Definition für zwei Devices zuständig ist. Es macht aber die Funktionsweise klar. Damit sind die Grundlagen für eine Programmierung IMHO auch gelegt. Wir sind also ziemlich weit.
Ziel ist es ja für jedes Gerät, abhängig von der ID, eine eigene Definition zu haben.
defmod Pearl_1 CUL_TCM97001 CUL_TCM97001_Unknown
attr Pearl_1 IODev nanoCUL
attr Pearl_1 group CUL_TCM97001
attr Pearl_1 ignore 0
attr Pearl_1 model Unknown
attr Pearl_1 room Klima
attr Pearl_1 userReadings stateHEX {my $s = (ReadingsVal($name,'state',''));;\
my @a = split(/\s+/,$s);;\
$s = $a[1];;\
return($s);;},\
\
ID {my $s = (ReadingsVal($name,'stateHEX',''));;\
my @a = split("",$s);;\
my $u="";;\
$u = ((hex($a[0].$a[1].$a[2])& 0x3FC) >> 2);;\
return($u);;},\
\
temperature {my $s = (ReadingsVal($name,'stateHEX',''));;\
my @a = split("",$s);;\
my $t= ((hex($a[3].$a[4])& 0x3C) >> 2);;\
$t += ((hex($a[4].$a[5])& 0x3C) >> 2) * 16;;\
$t += ((hex($a[5].$a[6])& 0x3C) >> 2) * 256;;\
$t = (($t-900)/10 - 32)*5/9;;\
$t = int(10 * $t + 0.5) / 10;;\
return($t);;},\
\
humidity {my $s = (ReadingsVal($name,'stateHEX',''));;\
my @a = split("",$s);;\
my $t= (hex($a[6].$a[7])& 0x3C) >> 2;;\
$t += ((hex($a[7].$a[8])& 0x3C) >> 2) * 16;;\
return($t);;},\
\
GzBName {my $n="Bastian (GzB)";;\
return($n);;},\
\
GzBtemperature {my $s = (ReadingsVal($name,'stateHEX',''));;\
my @a = split("",$s);;\
my $u="";;\
$u = (hex($a[0].$a[1].$a[2])& 0x3FC) >> 2;;\
if ($u == 145) {my $t = (ReadingsVal($name,'temperature',''));;\
return($t);;}\
return();;},\
\
GzBhumidity {if ((ReadingsVal($name,'ID','')) == 145) {my $s = (ReadingsVal($name,'stateHEX',''));;\
my @a = split("",$s);;\
my $t= (hex($a[6].$a[7])& 0x3C) >> 2;;\
$t += ((hex($a[7].$a[8])& 0x3C) >> 2) * 16;;\
return($t)};;\
return();;},\
\
GzBdewpoint {if ((ReadingsVal($name,'ID','')) == 145) {my $d = (ReadingsVal($name,'dewpoint',''));;\
return($d)};;\
return();;},\
\
GzBabsFeuchte {if ((ReadingsVal($name,'ID','')) == 145) {my $aF = (ReadingsVal($name,'absFeuchte',''));;\
return($aF)};;\
return();;},\
\
GzBlueften {my $aFMG = ReadingsVal("Prologue_144","absFeuchte","0");;\
my $aFGzB = ReadingsVal($name,"GzBabsFeuchte","0");;\
my $ lue = "";;\
if ($aFMG < $aFGzB){\
$lue = "ja"}\
else\
{$lue = "nein"};;\
return ($lue);;},\
\
GzBtime-stamp {if ((ReadingsVal($name,'ID','')) == 145) {my $t = substr(ReadingsTimestamp($name,'GzBhumidity',''),11,8);;\
return($t)};;\
return();;},\
\
GzRName {my $n="Carolin (GzR)";;\
return($n);;},\
\
GzRtemperature {my $s = (ReadingsVal($name,'stateHEX',''));;\
my @a = split("",$s);;\
my $u="";;\
$u = (hex($a[0].$a[1].$a[2])& 0x3FC) >> 2;;\
if ($u == 58) {my $t = (ReadingsVal($name,'temperature',''));;\
return($t)};;\
return();;},\
\
GzRhumidity {if ((ReadingsVal($name,'ID','')) == 58) {my $s = (ReadingsVal($name,'stateHEX',''));;\
my @a = split("",$s);;\
my $t= (hex($a[6].$a[7])& 0x3C) >> 2;;\
$t += ((hex($a[7].$a[8])& 0x3C) >> 2) * 16;;\
return($t)};;\
return();;},\
\
GzRdewpoint {if ((ReadingsVal($name,'ID','')) == 58) {my $d = (ReadingsVal($name,'dewpoint',''));;\
return($d)};;\
return();;},\
\
GzRabsFeuchte {if ((ReadingsVal($name,'ID','')) == 58) {my $aF = (ReadingsVal($name,'absFeuchte',''));;\
return($aF)};;\
return();;},\
\
GzRtime-stamp {if ((ReadingsVal($name,'ID','')) == 58) {my $t = substr(ReadingsTimestamp($name,'GzRhumidity',''),11,8);;\
return($t)};;\
return();;},\
\
GzRlueften {my $aFMG = ReadingsVal("Prologue_144","absFeuchte","0");;\
my $aFGzR = ReadingsVal($name,"GzRabsFeuchte","0");;\
my $ lue = "";;\
if ($aFMG < $aFGzR){\
$lue = "ja"}\
else\
{$lue = "nein"};;\
return ($lue)}
Damit habe ich hoffentlich eine Grundlage legen können; die Einarbeitung in das Modul überlasse ich Jürgen, weil dazu meine Kenntnisse leider nicht ausreichen.
Gruß Eberhard
@Kornelius
Wenn Du es ausprobieren möchtest, hier der Text den Du unter UserReadings eintragen musst:
stateHEX {my $s = (ReadingsVal($name,'state',''));
my @a = split(/\s+/,$s);
$s = $a[1];
return($s);},
ID {my $s = (ReadingsVal($name,'stateHEX',''));
my @a = split("",$s);
my $u="";
$u = ((hex($a[0].$a[1].$a[2])& 0x3FC) >> 2);
return($u);},
temperature {my $s = (ReadingsVal($name,'stateHEX',''));
my @a = split("",$s);
my $t= ((hex($a[3].$a[4])& 0x3C) >> 2);
$t += ((hex($a[4].$a[5])& 0x3C) >> 2) * 16;
$t += ((hex($a[5].$a[6])& 0x3C) >> 2) * 256;
$t = (($t-900)/10 - 32)*5/9;
$t = int(10 * $t + 0.5) / 10;
return($t);},
humidity {my $s = (ReadingsVal($name,'stateHEX',''));
my @a = split("",$s);
my $t= (hex($a[6].$a[7])& 0x3C) >> 2;
$t += ((hex($a[7].$a[8])& 0x3C) >> 2) * 16;
return($t);},
GzBName {my $n="Bastian (GzB)";
return($n);},
GzBtemperature {my $s = (ReadingsVal($name,'stateHEX',''));
my @a = split("",$s);
my $u="";
$u = (hex($a[0].$a[1].$a[2])& 0x3FC) >> 2;
if ($u == 145) {my $t = (ReadingsVal($name,'temperature',''));
return($t);}
return();},
GzBhumidity {if ((ReadingsVal($name,'ID','')) == 145) {my $s = (ReadingsVal($name,'stateHEX',''));
my @a = split("",$s);
my $t= (hex($a[6].$a[7])& 0x3C) >> 2;
$t += ((hex($a[7].$a[8])& 0x3C) >> 2) * 16;
return($t)};
return();},
GzBdewpoint {if ((ReadingsVal($name,'ID','')) == 145) {my $d = (ReadingsVal($name,'dewpoint',''));
return($d)};
return();},
GzBabsFeuchte {if ((ReadingsVal($name,'ID','')) == 145) {my $aF = (ReadingsVal($name,'absFeuchte',''));
return($aF)};
return();},
GzBlueften {my $aFMG = ReadingsVal("Prologue_144","absFeuchte","0");
my $aFGzB = ReadingsVal($name,"GzBabsFeuchte","0");
my $ lue = "";
if ($aFMG < $aFGzB){
$lue = "ja"}
else
{$lue = "nein"};
return ($lue);},
GzBtime-stamp {if ((ReadingsVal($name,'ID','')) == 145) {my $t = substr(ReadingsTimestamp($name,'GzBhumidity',''),11,8);
return($t)};
return();},
GzRName {my $n="Carolin (GzR)";
return($n);},
GzRtemperature {my $s = (ReadingsVal($name,'stateHEX',''));
my @a = split("",$s);
my $u="";
$u = (hex($a[0].$a[1].$a[2])& 0x3FC) >> 2;
if ($u == 58) {my $t = (ReadingsVal($name,'temperature',''));
return($t)};
return();},
GzRhumidity {if ((ReadingsVal($name,'ID','')) == 58) {my $s = (ReadingsVal($name,'stateHEX',''));
my @a = split("",$s);
my $t= (hex($a[6].$a[7])& 0x3C) >> 2;
$t += ((hex($a[7].$a[8])& 0x3C) >> 2) * 16;
return($t)};
return();},
GzRdewpoint {if ((ReadingsVal($name,'ID','')) == 58) {my $d = (ReadingsVal($name,'dewpoint',''));
return($d)};
return();},
GzRabsFeuchte {if ((ReadingsVal($name,'ID','')) == 58) {my $aF = (ReadingsVal($name,'absFeuchte',''));
return($aF)};
return();},
GzRtime-stamp {if ((ReadingsVal($name,'ID','')) == 58) {my $t = substr(ReadingsTimestamp($name,'GzRhumidity',''),11,8);
return($t)};
return();},
GzRlueften {my $aFMG = ReadingsVal("Prologue_144","absFeuchte","0");
my $aFGzR = ReadingsVal($name,"GzRabsFeuchte","0");
my $ lue = "";
if ($aFMG < $aFGzR){
$lue = "ja"}
else
{$lue = "nein"};
return ($lue)}
Aufpassen die Ziffern 145 und 58 müssen Deinen IDs entsprechen. Die findest Du ja nacheinander unter dem Reading ID.
Edit: Im Reading GzB/GzRlueften kann es einen Fehler geben, weil es auf einen Außenluft-Sensor (Prologue_144) zugreift, der bei Dir nicht vorhanden ist. Entweder anpassen oder Löschen.
Gruß Eberhard
Hallo Eberhard,
Du bist mir zuvorgekommen. ;) :)
Ich wollte ebenfals erst mal wieder den Status Quo beleuchten und mich dann über das lange WoE dranmachen.
Noch unreflektiert sehe ich im Moment noch folgende ToDos:
1.) ich bevorzugte den Einsatz eines Transmitters der die Validierung des Telegramms übernimmt und nur gültige Telegramme in ein CUL_TX-Format wandelt.
Nachteil: die Unknown Messages-Infos tauchen zusätzlich noch im fhem-log auf und man benötigt eine Art "SignalDuino" als zusätzliches Zwischenglied.
2.) Die Lösung von Eberhard in fhem als Perl-Modul.
Also bitte noch etwas Geduld, bis ich wieder alles aufgebaut und mich eingearbeitet habe.
Aber immernoch Zweifel:
Trotz günstigen Preises des Sensors: Ein LaCrosse-Sensor kostet ca. 15€ sendet über die LGW ohne Probleme im 868MHz Band.
Der Sensor "PEARL NC7427" müllt das ISM-Band mit vielen Repetitions und viel zu kurzen Abständen zu.
Bei mehreren Sensoren verschlimmert sich das Ganze noch erheblich, insbesondere wenn man viele 433MHz Sensoren im Einsatz hat....
... und da kommt die Implementierung des CRCs ins Spiel und ist bei meiner Infrastruktur erforderlich, da viele Telegramme sich überlagern.
Nur mal so 'ne Überlegung... ???
Grüße,
Jürgen
Hallo Jürgen,
ich bevorzuge:
Zitat2.) Die Lösung von Eberhard in fhem als Perl-Modul.
;D
Ich verstehe die Problematik bzgl. des Zumüllens des ISM-Bandes. Wenn ich noch zusätzlich einen Signalduino einsetzen muss, der wiederum Geld kostet, sollte ich mich besser mit dem Kauf eines LaCrosse-Sensors anfreunden. Ich glaube wir sollten uns hier auf eine "Quick and Dirty" Lösung einstellen und die Nachteile in allerDeutlichkeit noch einmal herausheben. Ein ganzes Haus mit solchen Sensoren auszustatten ist sicher nicht Sinn der Sache.
ZitatBei mehreren Sensoren verschlimmert sich das Ganze noch erheblich, insbesondere wenn man viele 433MHz Sensoren im Einsatz hat....
... und da kommt die Implementierung des CRCs ins Spiel und ist bei meiner Infrastruktur erforderlich, da viele Telegramme sich überlagern.
Ich habe nicht den ganzen Thread im Kopf, aber irgendwie meine ich wäre das Problem CRC auch gelöst. Ich mach' mich mal auf die Suche...
Gruß Eberhard
Hallo Jürgen,
gesucht - gefunden. In den Beiträgen von #68 bis #85 ist eine Lösung für das Theme CRC vorgestellt. In 85 habe ich die bis dahin vorhandenen Erkenntnisse der CRC/Prüfsummenbildung versucht in einem Pearl-Code abzubilden. Mit Sicherheit ebenfalls eine gute Basis für Deine Arbeit.
Viele Grüße
Eberhard
Zitat von: FHEm2005 am 30 Oktober 2018, 11:08:09
Hallo Jürgen,
gesucht - gefunden. In den Beiträgen von #68 bis #85 ist eine Lösung für das Theme CRC vorgestellt. In 85 habe ich die bis dahin vorhandenen Erkenntnisse der CRC/Prüfsummenbildung versucht in einem Pearl-Code abzubilden. Mit Sicherheit ebenfalls eine gute Basis für Deine Arbeit.
Viele Grüße
Eberhard
Hallo Eberhard,
ja, die meinte ich, mit einer Umsetzung auf C.
Da sind noch ein paar Umsetzungsfragen offen, z.B. welcher Anteil des Telegramms über die CRC-Berechnung gehen muß.
Ich melde mich wieder. 8)
Jürgen
Hallo Jürgen,
Zitatz.B. welcher Anteil des Telegramms über die CRC-Berechnung gehen muß.
Da die Bildung der Prüfsumme bereits als Programm vorliegt, steht darin auch der Bereich:
Speichert man das Reading
state binär in
stateBIN und dann das Ganze in einem Array $a[n], gehen die Nutzdaten von n=2 bis n=37.
Weitere Fragen? :D :D
Gruß Eberhard
@FHEm2005:
Danke, sehr cool!
Ich habe hier (im Büro) gerade nur mein Handy dabei. Dennoch: Nachdem ich Deinen Code (stumpf) per Copy/Paste eingefügt habe (und die ID ersetzt), sehe ich zumindest schon einmal ein paar sehr brauchbare Readings. Ein guter Start!
@juergs:
Toll, dass es weitergeht!
Wenn Du Unterstützung brauchst (z.B. beim Testen, ...) helfe ich gerne!
Grüße in die Runde!
Kornelius
Hallo Jürgen,
Zitatja, die meinte ich, mit einer Umsetzung auf C.
Das verstehe ich nicht: Meine Codeschnipsel bezüglich der CRC/Prüfziffer sind doch in Perl geschrieben und das Modul ebenfalls. Wieso eine Umsetzung in C??
Gruß
Eberhard
Zitat von: FHEm2005 am 30 Oktober 2018, 11:53:30
Hallo Jürgen,
Das verstehe ich nicht: Meine Codeschnipsel bezüglich der CRC/Prüfziffer sind doch in Perl geschrieben und das Modul ebenfalls. Wieso eine Umsetzung in C??
Gruß
Eberhard
Ist ein Mißverständnis. Kann mich erst ab Do. darum kümmern. 8)
Ich habe noch etwas Ähnliches gefunden:
http://s6z.de/cms/index.php/homeautomation-homecontrol/infrastruktur/aktorensensoren/eigenbau/56-tinytx-wireless-sensor-nodes (http://s6z.de/cms/index.php/homeautomation-homecontrol/infrastruktur/aktorensensoren/eigenbau/56-tinytx-wireless-sensor-nodes)
und hier das FHEM-Modul dazu:
https://raw.githubusercontent.com/hexenmeister/MyFHEM/master/FHEM/36_GSD.pm (https://raw.githubusercontent.com/hexenmeister/MyFHEM/master/FHEM/36_GSD.pm)
Vielleicht passt es als Basis?
Jürgen
Hallo Jürgen,
ZitatVielleicht passt es als Basis?
Das kann ich nicht beurteilen. Ich verstehe zu wenig von Perl, um die dort verwendete Logik erfassen zu können. Das ist umso schwerer, je besser die Programmierer sind. Ob ein neues Modul Sinn macht, musst Du entscheiden. Bei der Sache bin ich raus.
Viele Grüße
Eberhard
https://wiki.fhem.de/wiki/DevelopmentModuleIntro (https://wiki.fhem.de/wiki/DevelopmentModuleIntro)
Hallo Jürgen,
ich empfinde das als Kompliment, dass Du mich doch noch zu Programmieren überreden möchtest. :-) Das menschliche Gehirn wird mit steigendem Alter immer träger und somit fällt das Lernen nicht mehr so leicht. So ein Thema neu anzupacken bedingt einen Mentor, der die mannigfaltigen Fragen geduldig erträgt und beantwortet. Ich schaue es mir mal an, mehr kann ich aber nicht versprechen. Danke dir nochmal.
Gruß Eberhard
Hallo Eberhard,
Zitatnoch zu Programmieren überreden möchtest. :-)
nicht so direkt ... und Alter wird sowieso unterschätzt ;).
Das Thema Modulintegration hat mich doch etwas interessiert
und bin bei der LGW-CO2-Luftgütemessung schon etwas damit in Kontakt gekommen.
Mal schauen, ob ich mich (widerstrebend) in den PERL-Tiefen zurecht finden und mit Deinen Vorarbeiten
umsetzen kann.
Habe auch noch nach einer "Auszeit" andere Themen wie z.B. Docker- und MQTT-Einarbeitung in der Pipeline ...
Nächste Woche kommt auch noch .NET Core auf dem Raspberry dazu.
Also viel zu tun ...
Hallo Jürgen,
ZitatMal schauen, ob ich mich (widerstrebend) in den PERL-Tiefen zurecht finden und mit Deinen Vorarbeiten
umsetzen kann.
Ich bin momentan etwas unsicher: Ich dachte immer Du wärst der Maintainer des Moduls. Bist Du das denn nicht???
Gruß Eberhard
Zitat von: FHEm2005 am 01 November 2018, 08:15:33
Hallo Jürgen,
Ich bin momentan etwas unsicher: Ich dachte immer Du wärst der Maintainer des Moduls. Bist Du das denn nicht???
Gruß Eberhard
Nein, ist nicht so. Maintainers (https://fhem.de/MAINTAINER.txt) :(
Und nun? Müssen wir dancer0705/bjoernh fragen, ob die den Sensor einbauen/ergänzen können?
Zitat von: FHEm2005 am 01 November 2018, 11:54:33
Und nun? Müssen wir dancer0705/bjoernh fragen, ob die den Sensor einbauen/ergänzen können?
Meiner Meinung nach ja, evtl. mit deren Unterstützung?
Hallo Björnh,
ich gehe mal davon aus, dass Du die ganze Zeit diesen Thread beobachtet hast und insgesamt gespannt bist, was hier passiert. ;) ;)
Du kennst den aktuellen Stand und (hoffentlich) auch die bereits geleisteten Vorarbeiten. Magst Du Dich mit Jürgen abstimmen, wer was macht. Wenn ich etwas beitragen kann, bin ich gerne dazu bereit.
Mein erster Beitrag zu diesen Temperatursensor ist vom 22.01.2017 (#13). Es nähert sich das Datum, da die Einarbeitung auf den 2. Jahrestag wartet. ::) ::)
Gruß Eberhard
Inzwischen noch eine Meldung von mir:
habe auf meinem raspi-Zero nach dieser Anleitung installiert:
https://blog.heimetli.ch/sdr-rtl_433.html (https://blog.heimetli.ch/sdr-rtl_433.html)
Im Output entdeckt man auch den Pearl-Sensor NC7427:
und zwar als:
2018-11-18 13:59:43 : Kedsum Temperature & Humidity Sensor
Channel: 2
Temperature: 72.30 F
Humidity: 38 %Und hat eindeutig auf Kanalwechsel reagiert:
2018-11-18 13:59:27 : Kedsum Temperature & Humidity Sensor
Channel: 1
Temperature: 72.30 F
Humidity: 38 %und zwar als " Kedsum Temperature & Humidity Sensor"
Hier stehen dazu Einzelheiten:
kedsum.c (https://github.com/merbanan/rtl_433/blob/master/src/devices/kedsum.c)
https://github.com/merbanan/rtl_433 (https://github.com/merbanan/rtl_433)
ZitatLargely based on prologue, esperanza_ews, s3318p
Frame appears to be a differently-endianed version of the esperanza
pi@pi-zero:~/rtl_433 $ sudo rtl_433 -R 57
Registering protocol [57] "Kedsum Temperature & Humidity Sensor"
Registered 1 out of 112 device decoding protocols
Found 1 device(s)
trying device 0: Realtek, RTL2838UHIDIR, SN: 00000001
Detached kernel driver
Found Rafael Micro R820T tuner
Using device 0: Generic RTL2832U OEM
Exact sample rate is: 250000.000414 Hz
[R82XX] PLL not locked!
Sample rate set to 250000 S/s.
Bit detection level set to 0 (Auto).
Tuner gain set to Auto.
Reading samples in async mode...
Tuned to 433.920MHz.
Allocating 15 zero-copy buffers
2018-11-18 14:24:06 : Kedsum Temperature & Humidity Sensor
Channel: 1
Temperature: 72.80 F
Humidity: 38 %Ist zwar noch nicht der Durchbruch Richtung FHEM, aber meine Installationen sind jetzt wieder lauffähig. :D
Falls doch noch allenthalben Interesse an diesem Sensor bestünde:
https://forum.fhem.de/index.php/topic,104534.0.html (https://forum.fhem.de/index.php/topic,104534.0.html)
Wäre mit Signalduino-Firmware in FHEM als CUL_TCM97001-Sensor lesbar.
Hallo Jürgen,
ich dachte das Thema sei bei allen Betroffenen bereits aus dem Focus gekommen. Nach fast einem Jahr wieder ein Beitrag im Thread. Im Januar ist das Problem drei Jahre alt. :'( :'(. Derjenige, der seine 4 Thermometer verhökert, hat wohl die Geduld verloren. Ich habe meine zwei zwar noch in Betrieb, aber immer noch mit dem Workaround aus #137.
Ist zwar noch nicht der Durchbruch Richtung FHEM, ....
Lieb gemeint, aber ich kann ja meine Messergebnisse bereits in FHEM sehen und benutzen, aber nur unter den genannten mangelhalften Randbedingungen (bei Batteriewechsel muss die Def. angepasst werden und für zwei Geräte ist eine Def. zuständig). Bezüglich Batteriewechsel: ist zwar für Akkus mit Solarzelle aber hier und da ist der Akku leer und dann ist leider Arbeit angesagt.
Ich brauche keine Installation auf Linux-Ebene. Ich bin an einer angepassten Definition interessiert. Da ist mein Workaround (abgesehen von den Einschränkungen) bezüglich der Readings einfacher und in FHEM besser zu verarbeiten.
Fazit: Ich bin nach wie vor an einer Lösung interessiert, die den Sensor als einzelnes Gerät erkennt und somit je gefundenes Device eine Definition anlegt.
Die Hoffnung stirbt zuletzt...
Viele Grüße
Eberhard
Hallo Zusammen,
ich habe hier https://forum.fhem.de/index.php/topic,24436.msg1013844.html#msg1013844 (https://forum.fhem.de/index.php/topic,24436.msg1013844.html#msg1013844) in der tsculfw mal den Empfang für NC7427 Sensoren eingebaut und ein TSCUL_NC7427 Modul für FHEM dazu geschrieben (weil ich zwei davon rum liegen hatte und einen Außensenor brauchte).
Die Vorarbeiten und Recherchen hier haben dabei sehr geholfen, vielen Dank!
Die Firmware eleminiert schon die beiden führenden 0 Bits und prüft die Checksumme und liefert nCCSTTTHHcc messages. Das Eleminieren der beider führenden Null Bits entspricht einem zweifachen Bit-Shift nach links (oder Multiplikation mit 4) bezogen auf die hier im Thread beschriebenen Empfangsdaten.
Damit vereinfacht sich das Dekodieren auf Nibble Extraktion in Perl.
Das TSCUL_NC7427 Modul dekodiert dann die Messages. Die Bit Bedeutungen können dem Perl Code des Moduls entnommen werden, falls jemand von der a-culfw gelieferte Daten der Sensoren dekodieren möchte.
Vom Modul werden 3 Sensoren entsprechend der 3 per Schalter wählbaren Kanäle unterstützt (je CUL möglich). Mehr macht wenig Sinn, da sie recht häufig und lange senden und das Sendeintervall vom Kanal abhängig ist. Es macht auch nur Sinn, antennentechnisch wirkliche 433er CULs zum Empfang zu nutzen, da die Sendeleistung der Sensoren recht bescheiden ist.
Die TEST Taste der Sensoren wird in einem Bit kodiert geliefert und die habe ich in meinem Modul als Anlernbedingung integriert. Anlernen geht mit autocreate also nur, wenn die Taste gedrückt wird.
Bei Akkuwechsel kann damit auch die neue zufällige SensorId angelernt werden, ohne den Sensor komplett neu anlernen zu müssen.
Je zwei Bits glaube ich als Temperatur-Trend und Luftfeuchtigkeits-Trend identifiziert zu haben. (Das Display der Basisstation verfügt zumindest über eine Trend Anzeige laut Anleitungsabbildung, kann also Sinn machen)
Gruß, Ansgar.