Signalduino Entwicklung

Begonnen von thoffma3, 05 Juli 2015, 23:01:00

Vorheriges Thema - Nächstes Thema
Drucken
Nach unten Seiten 1 ... 4 5 6 7 8 ... 146
Benutzer-Aktionen

Ralf9

#75
29 August 2015, 21:50:14
Hallo,

ich möchte mir den Signalduino zusammenbauen.
Ich möchte den etwas besseren Super-heterodyne OOK Wireless Receiver 433 MHz verwenden.
Bei ebay habe ich nur welche aus China gefunden mit einer Lieferzeit: Mo, 14. Sep. und Mi, 21. Okt
Kennt jemand eine Quelle mit einer Lieferzeit bis ca mitte September.
Dies ist das einzigste wo ich gefunden habe, scheint aber etwas schlechter zu sein, -105 dB (der aus China hat 116 dB)
http://www.ebay.de/itm/433Mhz-3400-RF-Superheterody-Transmitter-Receiver-Link-Kit-fur-Arduino-ARM-MCU-/261813743508?hash=item3cf550af94

Gruß Ralf
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

Sidey

#76
29 August 2015, 21:52:48
Hallo Ralf,

ich hab den gleichen Empfänger aus China.
Der ist schon sehr gut. Möglich, dass es bessere gibt, aber aus China verkaufen die eigentlich auch nichts besseres.

Grüße Sidey
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem,zigbee2mqtt

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

Ralf9

#77
29 August 2015, 22:15:17
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

Sidey

#78
29 August 2015, 22:19:11
Hi Ralf,

also die verkaufen alle das gleiche. Wenn da einer ein RXB6 rev 0.8 anbietet, dann kommt der mit Abschirmung.
Die Rev 2.0 scheint wohl ein bisschen besser zu sein. Am Ende musst Du wissen, wie viel Geld zu ausgeben möchtest. Ich denke, beide würden gut funktionieren.

Am Ende machst Du mit dem super-het Empfänger eigentlich nichts falsch. Du kannst auch immer noch eine Antenne anschließen, dann empfängt er noch etwas besser.


Grüße Sidey
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem,zigbee2mqtt

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

Sidey

#79
30 August 2015, 00:45:37
Hallo Jörg,

Zitat von: pejonp am 29 August 2015, 13:25:48
ich habe gedacht der signalduino benutzt auch das tcm97001 oder bringe ich da etwas durcheinander.
Also der SIGNALduino kann vom Prinzip an jedes Modul etwas weiter leiten. tcm97001 ist nur eines von mehreren.

So, ich habe Cresta im SIGNALduino implementiert. Anbei die Ausgabe die daraus resultiert:

Code Auswählen

2015.08.30 00:34:18 4: SIGNALduino/msg READ: MC;LL=-1050;LH=906;SL=-563;SH=412;D=B8465D29BBCFA135501830AE11974A2EF3E84D5400;C=439;
2015.08.30 00:34:18 5: devSduino: Cresta protocol converted to hex: (4875C4BA8AF7BEC85500) with length (80) bytes
2015.08.30 00:34:18 5: converted Data to (4875C4BA8AF7BEC85500)
2015.08.30 00:34:18 5: devSduino dispatch 4875C4BA8AF7BEC85500


Die Vorlage für ein Modul zum Dekodieren kommt die Tage. Bin jetzt leider doch schon zu müde. :(

Ich habe auch mal geschaut, ob wir nicht einfach das TRX_Weather Modul verwenden können. Das scheint mir aber nicht ganz trivial, die übergebenen Daten müssten auf jeden Fall mit 0x520a beginnen, welche Umwandlung der Daten dann noch notwendig ist, erschließt sich mir derzeit nicht.
Testet das doch bitte mal aus, die Ausgaben müssten bei euch ähnlich sein.

Grüße Sidey
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem,zigbee2mqtt

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

hjgode

#80
30 August 2015, 07:30:24
Zitat von: Sidey am 29 August 2015, 10:18:54
Hallo Josef,

ja das hilft. Das Manchester Signal, was im Log als MC auftaucht, ist dass deiner TFA Sensoren.

Weisst Du ob es schon ein Modul in Fhem gibt, welches den TFA Sensor interpretiert, oder würdest dir zutrauen da was zu entwickeln?

Grob formuliert, ist ist eine Fleiß Arbeit. Ich würde im Signalduino das Cresta Protokoll erkennen. Dazu würde ich nach 0x75 suchen, und ab da  beginnend die Daten an ein anderes Modul übergeben.

Das Modul müsste im Prinzip die Funktion encodeThermoHygro realisieren und jedes 9 Bit ignorieren oder einfach verwerfen.

Grüße Sidey

Hallo Sidey

wie willst Du denn nach 0x75 suchen, kommt doch gar nicht vor, oder?

Ich habe noch einmal in der Cresta Doku nachgelesen. Dort wird noch von Encrypt und DeCrypt gesprochen. Daraufhin habe ich Decrypt im PatternDecoder nachgerüstet, um zu sehen ob dann eine zu RemoteSensor Sketch vergleichbare Byte Folge zu erkennen ist. Das war nicht erfolgreich.

Wenn Du das Cresta so dekodierst das die mir bekannten und dokumentierten Bytefolgen rauskommen, würde ich das Perl Modul vielleicht hinkriegen.

Denke mitlerweile aber auch über eine Kombination von RemoteSensor im Stil von signalDuino/fhemDuino, einem fhem Modul für die 'neue' Hardware und einem weiteren fhem Modul zur Interpretation der RemoteSensor Hex-Werte. Die 'neue' Hardware könnte dann Cresta und die PT2262 Schalter.

Gruss

Josef
Debian SID mit aktuellem FHEM, nanoCUL 866, JeeLink EC3000, fhemduino, SIGNALduino,
3 x TFA TH Sensor, 1 x TFA TH Arduino Sender, 3 x EC3000, 4 x Elro Schaltsteckdosen, ESA2000
offline: Wibo Funkthermostat, 2 x ELV Funkthermostat FHT80, 2 FS20 ST4 Funksteckdose

Sidey

#81
30 August 2015, 08:56:36 Letzte Bearbeitung: 30 August 2015, 10:36:22 von Sidey
Hallo Josef,

die aktuelle Version des FHEM Modul gibt es bereits aus (siehe Post von gestern)

Im Beispiel 4875.....
48 ist die Länge und dann beginnt das Protokoll mit 75.
Ich kann die Länge auch wieder heraus nehmen. So kann man aber im logischen Modul via match gleich auf die passende Längen filtern und muss sich auch keinen eigenen Nachrichtentyp überlegen.
Die match regex könnte in etwa folgendes prüfen:
Länge 40-50 75 .*
Bin jetzt nicht der Regex Spezi wie man die Länge am besten via regex prüft. Im Oregon Modul wurde das auch so gemacht.

Neue Hardware / Software auf dem Arduino ist nicht notwendig.

Nachtrag:
Vom Signalduino Modul werden die Daten in der richtigen Bitfolge (MSB first) übergeben. Jedes 9. Bit wird ignoriert. Den Daten wird vorne angestellt ein Längenfeld mit übergeben.
Ob das Telegramm komplett ist, wird nicht geprüft. Alle Werte sind Hexadezimal dargestellt.
Das Modul sollte eventuell noch prüfen, ob ein RSSI Wert mit übergeben wird. Dazu gibt es leider keinen einheitlichen Standard. Manche Receiver hängen es hinten an die Nachricht an, andere fragen es vom IO Device direkt ab.
Der Signalduino übergibt allerdings keinen RSSI Wert!

In einem Cresta Modul wäre die CRC Funktion, das decrypten und anschließen das extrahieren der empfangenen Daten in Readings notwendig.


Grüße Sidey
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem,zigbee2mqtt

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

Sidey

#82
30 August 2015, 22:57:58
Hi,

ich hab mal noch was im Modul ergänzt:

Das Signal der RF20 Funk Rauchmelder könnte  erkannt werden.
TX70DHT könnte zu Protokoll #7 passen, Heidmann HX und TCM Türklingel habe ich nach bestem Wissen auch versucht mit auf zu nehmen.

Wer so ein Gerät hat, kann das vielleicht mal mit verbose 5 testen und hier bestätigen oder eben auch nicht ob das Signal erkannt wird.

Grüße Sidey
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem,zigbee2mqtt

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

hjgode

#83
31 August 2015, 18:51:24
Zitat von: Sidey am 30 August 2015, 08:56:36
Hallo Josef,

die aktuelle Version des FHEM Modul gibt es bereits aus (siehe Post von gestern)

Im Beispiel 4875.....
48 ist die Länge und dann beginnt das Protokoll mit 75.
Ich kann die Länge auch wieder heraus nehmen. So kann man aber im logischen Modul via match gleich auf die passende Längen filtern und muss sich auch keinen eigenen Nachrichtentyp überlegen.
Die match regex könnte in etwa folgendes prüfen:
Länge 40-50 75 .*
Bin jetzt nicht der Regex Spezi wie man die Länge am besten via regex prüft. Im Oregon Modul wurde das auch so gemacht.

Neue Hardware / Software auf dem Arduino ist nicht notwendig.

Nachtrag:
Vom Signalduino Modul werden die Daten in der richtigen Bitfolge (MSB first) übergeben. Jedes 9. Bit wird ignoriert. Den Daten wird vorne angestellt ein Längenfeld mit übergeben.
Ob das Telegramm komplett ist, wird nicht geprüft. Alle Werte sind Hexadezimal dargestellt.
Das Modul sollte eventuell noch prüfen, ob ein RSSI Wert mit übergeben wird. Dazu gibt es leider keinen einheitlichen Standard. Manche Receiver hängen es hinten an die Nachricht an, andere fragen es vom IO Device direkt ab.
Der Signalduino übergibt allerdings keinen RSSI Wert!

In einem Cresta Modul wäre die CRC Funktion, das decrypten und anschließen das extrahieren der empfangenen Daten in Readings notwendig.


Grüße Sidey

Hallo Sidey

die Cresta-Ausgabe habe ich inzwischen gefunden.

Habe auch schon etwas perl code geschrieben, der im Prinzip das RemoteSensor::decodeThermoHygro ersetzt (also nix mit CRC check etc, könnte man aber auch einbauen, gemäß SensorReceiver::decryptAndCheck()).

Wie das dann aber in ein zu schreibendes Cresta Fhem Modul eingebaut wird entzeiht sich meiner Kenntnis.

Vielen Dank soweit für Deine Hilfe

~josef
Debian SID mit aktuellem FHEM, nanoCUL 866, JeeLink EC3000, fhemduino, SIGNALduino,
3 x TFA TH Sensor, 1 x TFA TH Arduino Sender, 3 x EC3000, 4 x Elro Schaltsteckdosen, ESA2000
offline: Wibo Funkthermostat, 2 x ELV Funkthermostat FHT80, 2 FS20 ST4 Funksteckdose

Sidey

#84
31 August 2015, 19:09:04
Ich baue einen dummy, bin eh dabei etwas zur Protokoll Analyse zu entwerfen. Da müsste der code dann rein
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem,zigbee2mqtt

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

Sidey

#85
31 August 2015, 23:02:27
Anbei das Grundgerüst für ein Cresta Modul...

Ich habe zwei-drei Kommentare hinterlassen.

Interessant ist die Funktion cresta_parse. Da drinnen kommen die Daten von SignalDuino an und müssen dekodiert werden.

Grüße Sidey
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem,zigbee2mqtt

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

hjgode

#86
01 September 2015, 16:35:35
Zitat von: Sidey am 31 August 2015, 23:02:27
Anbei das Grundgerüst für ein Cresta Modul...

Ich habe zwei-drei Kommentare hinterlassen.

Interessant ist die Funktion cresta_parse. Da drinnen kommen die Daten von SignalDuino an und müssen dekodiert werden.

Grüße Sidey

Hallo Sidey

Ich weiß leider nicht, wie ich dass in die Cresta.pm integrieren kann. Deshalb hier nur die beiden benötigten Funktionen und das ganze mit einem Testprogramm mit Daten aus SignalDuino (RF_Receiver) und RemoteSensor.

Code Auswählen
# CrestaProtocol.pdf
# Byte 0:  Header byte, always 0x75
# Byte 1:  Device ID
# Byte 2:  Package Length
# Byte 3:  Device type
# Byte 4..n:  The actual device data
# Byte n+1:  Checksum
# Byte n+2:  Second checksum byte

# ID (Byte 1)  Description  Transmitting interval
# 0x20 - 0x3F  Thermo/hygro-sensor at channel 1    43 Seconds
# 0x40 - 0x5F  Thermo/hygro-sensor at channel 2    45 Seconds
# 0x60 - 0x7F  Thermo/hygro-sensor at channel 3    47 Seconds
# 0x80 - 0x9F  Rain sensor, 183
# UV sensor or 300
# anemometer 33 seconds
# 0xA0 - 0xBF  Thermo/hygro-sensor at channel 4    49 Seconds
# 0xC0 - 0xDF  Thermo/hygro-sensor at channel 5    51 Seconds
#

# Package nr.  Raw Data  Decrypted Data
# 1  75,C3,BA,CA,7D,BF,CF,51,EF  75,45,CE,5E,87,C1,51,F3,EF
# 2  75,C3,BA,8A,7D,BF,CF,51,AF  75,45,CE,9E,87,C1,51,F3,AF
# 3  75,C3,BA,4A,7D,BF,CF,51,6F  75,45,CE,DE,87,C1,51,F3,6F
#

# /* Example to decrypt and check a package, 
#    Input: Buffer holds the received raw data.
#    Returns ERROR number, Buffer now holds decrypted data
# */
# 
# #define NO_ERROR     0
# #define ERROR_HEADER 1
# #define ERROR_CS1    2
# #define ERROR_CS2    3
#
# /* Decrypt raw received data byte */
# BYTE DecryptByte(BYTE b)
# {
#   return b ^ (b << 1);
# }
#
# BYTE DecryptAndCheck(BYTE *Buffer)
# {
#   BYTE cs1,cs2,count,i;
# 
#   if (Buffer[0]!=0x75) return ERROR_HEADER;
#   count=(DecryptByte(Buffer[2])>>1) & 0x1f;
#   cs1=0;
#   cs2=0;
#   for(i=1; i<count+2; i++)
#   {
#     cs1^=Buffer[i];
#     cs2 =SecondCheck(Buffer[i]^cs2);
#     Buffer[i]=DecryptByte(Buffer[i]);
#   }
#   if(cs1) return ERROR_CS1;
#   if(cs2!=Buffer[count+2]) return ERROR_CS2;
#   return NO_ERROR;
# }
# 
use strict;
use warnings;

use subs "decryptByte";
use subs "decodeThermoHygro";

print "Cresta ThermoHydro Decoder\n";
my $res=0;
my $c=0;
my $t=0;
my $h=0;

# aus RF_Receiver:
# 58753DBACAEEBEDD55953900
# 58753DBA8AEEBEDD55D50300
# 50753DBA8AEEBEDD55D503
# 58753DBACAEEBEDD55953900
# 5875E2BA8A80BFD1AD915400
# 58753DBA4AEEBEDD55151500
# 5875E2BA4A80BFD1AD514200
# 5875E2BACAD7BFD1AD861000
# 287555500500
# 58753DBA4AEFBEDD55146D00
# 50753DBA8AEFBEDD55D400
my @testdata1 = ("58753DBACAEEBEDD55953900", "58753DBA8AEEBEDD55D50300", "50753DBA8AEEBEDD55D503", "5875E2BA8A80BFD1AD915400", "58753DBA4AEEBEDD55151500", "5875E2BA4A80BFD1AD514200", "5875E2BACAD7BFD1AD861000", "287555500500", "58753DBA4AEFBEDD55146D00", "50753DBA8AEFBEDD55D400", "5075D3BA8ACDBEC851092F");
my @testdata2 = ("0075C3BACA7DBFCF51EF","0075C3BA8A7DBFCF51AF","0075C3BA4A7DBFCF516F");
my @testdata2decrpyted= ("7545CE5E87C151F3EF","7545CE9E87C151F3AF","7545CEDE87C151F36F");

my ($i, $data, @decoded);

print("Cresta ThermoHygro Test\n");

print("Testdata by RF_Receiver:\n");
for($i=0; $i < scalar(@testdata1); $i++){
$data = @testdata1[$i];
@decoded = &decodeThermoHygro($data,$c,$t,$h);
printf ("data: data id: %i, channel: %i, temp: %.1f, humi: %i\n", $i, $decoded[1], ($decoded[2] / 10) + ($decoded[2] % 10), $decoded[3]);
}

print("===========================\nTestdata by RemoteSensor:\n");
for($i=0; $i < scalar(@testdata2); $i++){
$data = @testdata2[$i];
@decoded = &decodeThermoHygro($data,$c,$t,$h);
printf ("data: data id: %i, channel: %i, temp: %.1f, humi: %i\n", $i, $decoded[1], ($decoded[2] / 10) + ($decoded[2] % 10), $decoded[3]);
}


# ===========================================================
sub decryptByte(){
my $byte = shift;
#printf("\ndecryptByte 0x%02x >>",$byte);
my $ret2 = ($byte ^ ($byte << 1) & 0xFF); #gives possible overflow to left so c3->145 instead of 45
#printf(" %02x\n",$ret2);
return $ret2;
}
    sub decodeThermoHygro {
        my $crestahex = shift; # function arg is hey string
        my $channel;
my $temp;
my $humi;
my @crestabytes;#  = map { pack('C', hex($_)) } ($crestahex =~ /(..)/g);
for (my $i=0; $i<(length($crestahex))/2; $i++){
my $hex=hex(substr($crestahex, $i*2, 2));
push (@crestabytes, $hex);
}
# (read and remove first element)
my $len = shift @crestabytes;

printf ("0x%02X ", $crestabytes[0]);
if($crestabytes[0] == 0x75){
my @decrypted;
my $idx=0;
$decrypted[0]=$crestabytes[0];
for($idx=1; $idx<7; ($idx)++) {
$decrypted[$idx]=$crestabytes[$idx];
$crestabytes[$idx]=&decryptByte($decrypted[$idx]);
}

}


if($crestabytes[0] != 0x75){
return (-1, 0, 0, 0)
}

$channel = $crestabytes[1] >> 5;
# //Internally channel 4 is used for the other sensor types (rain, uv, anemo).
# //Therefore, if channel is decoded 5 or 6, the real value set on the device itself is 4 resp 5.
if ($channel >= 5) {
$channel--;
}

$temp = 100 * ($crestabytes[5] & 0x0f) + 10 * ($crestabytes[4] >> 4) + ($crestabytes[4] & 0x0f);
## // temp is negative?
if (!($crestabytes[5] & 0x80)) {
$temp = -$temp;
}

$humi = 10 * ($crestabytes[6] >> 4) + ($crestabytes[6] & 0x0f);

        return (1, $channel, $temp, $humi);
    }
   




Wenn man das laufen läßt erhält man folgende Ausgabe:

Code Auswählen
Cresta ThermoHydro Decoder
Cresta ThermoHygro Test
Testdata by RF_Receiver:
0x75 data: data id: 0, channel: 2, temp: 25.2, humi: 67
0x75 data: data id: 1, channel: 2, temp: 25.2, humi: 67
0x75 data: data id: 2, channel: 2, temp: 25.2, humi: 67
0x75 data: data id: 3, channel: 1, temp: 18.0, humi: 73
0x75 data: data id: 4, channel: 2, temp: 25.2, humi: 67
0x75 data: data id: 5, channel: 1, temp: 18.0, humi: 73
0x75 data: data id: 6, channel: 1, temp: 26.9, humi: 73
0x75 data: data id: 7, channel: 6, temp: 0.0, humi: 0
0x75 data: data id: 8, channel: 2, temp: 24.1, humi: 67
0x75 data: data id: 9, channel: 2, temp: 24.1, humi: 67
0x75 data: data id: 10, channel: 3, temp: 32.7, humi: 58
===========================
Testdata by RemoteSensor:
0x75 data: data id: 0, channel: 2, temp: 25.7, humi: 51
0x75 data: data id: 1, channel: 2, temp: 25.7, humi: 51
0x75 data: data id: 2, channel: 2, temp: 25.7, humi: 51


Ich habe mittlerweile ein fhem in Eclipse Epic mit debug laufen. Weiß ber nicht, wie ich das Modul testen könnte.

~josef
Debian SID mit aktuellem FHEM, nanoCUL 866, JeeLink EC3000, fhemduino, SIGNALduino,
3 x TFA TH Sensor, 1 x TFA TH Arduino Sender, 3 x EC3000, 4 x Elro Schaltsteckdosen, ESA2000
offline: Wibo Funkthermostat, 2 x ELV Funkthermostat FHT80, 2 FS20 ST4 Funksteckdose

Sidey

#87
01 September 2015, 23:28:49
Hallo Josef,

wie Du ein Fhem Modul in Eclipse testen kannst, weiss ich auch nicht.

Ich debugge in einer Fhem Installation.

Ich kann deinen Code in das Cresta Modul von gestern einbauen. Gib mir mal ein paar Tage Zeit.

Die CRC Funktion sollte man vielleicht noch einbauen um feststellen zu können, ob die Nachricht komplett empfangen wurde.
Mit dem Längenfeld gibt es noch einen Fehler im Signalduino. Den muss ich noch korrigieren.

Grüße Sidey
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem,zigbee2mqtt

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

pejonp

#88
02 September 2015, 01:00:42
Zitat von: hjgode am 01 September 2015, 16:35:35
...
Ich weiß leider nicht, wie ich dass in die Cresta.pm integrieren kann. Deshalb hier nur die beiden benötigten Funktionen und das ganze mit einem Testprogramm mit Daten aus SignalDuino (RF_Receiver) und RemoteSensor.

..
~josef

Hallo Josef,

ich habe auch mal etwas rumgespielt.
das ist der String aus dem log:
my text2 = '5875BDBA4AC2BEC855AC0A00';

mit dieser regexp kann man aus dem String die benötigten Stellen erhalten:
$text2 =~  /(75)([\w][\w]{17,17})/;

my @daten= (0xbd,0xba,0x4a,0xc2,0xbe,0xc8,0x55,0xac);

Checksumme errechnen (diese muß  0 ergeben):
my $t2 =  $daten[0]^$daten[1]^$daten[2]^$daten[3]^$daten[4]^$daten[5]^$daten[6]^$daten[7];

dann die Umwandlung der Bytes durchgeführt, wie gesagt ist noch nicht fertig:
my $merk = $daten[0]^($daten[0]<<1);
my $hex = unpack "H2",pack "c", $merk;
print "75";
print ".$hex";
$merk = $daten[1]^($daten[1]<<1) ;
$hex = unpack "H2",pack "c", $merk;
print ".$hex";
$merk = $daten[2]^($daten[2]<<1) ;
$hex = unpack "H2",pack "c", $merk;
print ".$hex";
$merk = $daten[3]^($daten[3]<<1);
$hex = unpack "H2",pack "c", $merk;
print ".$hex";
$merk = $daten[4]^($daten[4]<<1) ;
$hex = unpack "H2",pack "c", $merk;
print ".$hex";
$merk = $daten[5]^($daten[5]<<1);
$hex = unpack "H2",pack "c", $merk;
print ".$hex \n";

Das Ergebnis ist :
# 75.c7.ce.de.46.c2.58
                        \\    \  \\__________ Humidity 58%
                          \\    \_____________ Temp 10 Steller                 2
                           \\_______________ Temp Nachkommastelle    .6
                            \_______________ Temp 1 Stelle                     4
                                                               24.6 °C
Wenn ich den String von oben in dein Skript eingebe erhalten ich folgendes. Aber die Temperatur stimmt nicht. Ansonsten passt es.
0x75 data: data id: 0, channel: 5, temp: 30.6, humi: 58

ich habe dieses hier geändert, dann kommt der richtige Wert raus:
printf ("data: data id: %i, channel: %i, temp: %.1f, humi: %i\n", $i, $decoded[1], ($decoded[2] / 10) + ($decoded[2] % 10), $decoded[3]);

printf ("data: data id: %i, channel: %i, temp: %.1f, humi: %i\n", $i, $decoded[1], ($decoded[2] / 10) , $decoded[3]);


Tschüß Jörg

LaCrossGW 868MHz:WT470+TFA+TX37-IT+EMT7110+W136+WH25A HP1003+WH2621
SignalD(CC1101):Bresser+WS-0101(868MHz WH1080)+Velux KLF200+MAX!+HM-MOD-UART:Smoke HM-SEC-SD+VITOSOLIC 200 RESOL VBUS-LAN+SolarEdge SE5K(Modbus)+Sonnen!eco8(10kWh)+TD3511+DRT710M(Modbus)+ZigBee+Z-Wave+MQTT+vitoconnect

hjgode

#89
02 September 2015, 16:13:37
Hallo pejonp

Vielen Dank für Deinen Support.

Leider ist das alles nicht so ganz stimmig.

Daten aus unterschiedlichen Quellen passen nicht zum CrestaProtocol.pdf

Code Auswählen
# aus RF_Receiver:
# 58753DBACAEEBEDD55953900
# 58753DBA8AEEBEDD55D50300
# 50753DBA8AEEBEDD55D503
# 58753DBACAEEBEDD55953900
# 5875E2BA8A80BFD1AD915400
# 58753DBA4AEEBEDD55151500
# 5875E2BA4A80BFD1AD514200
# 5875E2BACAD7BFD1AD861000
# 287555500500
# 58753DBA4AEFBEDD55146D00
# 50753DBA8AEFBEDD55D400
my @testdata1 = (
"58753DBACAEEBEDD55953900", "58753DBA8AEEBEDD55D50300",
"50753DBA8AEEBEDD55D503",   "5875E2BA8A80BFD1AD915400",
"58753DBA4AEEBEDD55151500", "5875E2BA4A80BFD1AD514200",
"5875E2BACAD7BFD1AD861000", "287555500500",
"58753DBA4AEFBEDD55146D00", "50753DBA8AEFBEDD55D400",
"5075D3BA8ACDBEC851092F", "5875BDBA4AC2BEC855AC0A0"
);
my @testdata2 =
  ( "0075C3BACA7DBFCF51EF", "0075C3BA8A7DBFCF51AF", "0075C3BA4A7DBFCF516F" );

So komme ich zu folgender Darstellung:
Code Auswählen
#       /------------------\-----> package 7 bytes?
#                      /---\-----> not part of useful data
# 75.45.CE.5E.87.C1.51.F3.EF
#                      \__________ comfort level, not used in code
#             \___________________ temp 8.7
#                \________________ 0xC = pos temp
#                 \_______________ temp 10er digit 1X10°C --> 18,7°C
#                   \_____________ humidity = 51%
#        +-----------------------> (0xCE>>1)&0x1f=7
#
#     /--------------\-----------> XOR chksum = 0 (byte1 to count+3)
#  /--------\ -------------------> fixed length 4 bytes
#              /-----\ ----------> package length
    #  0  1  2  3  4  5  6
    # 75.c7.ce.de.46.c2.58 ----------> plus xor chksum = 0: 75.c7.ce.de.46.c2.58.00
    # || || || || || || ||
    # || || || || || || ++------------ 6: BCD: Humidity                               58%
    # || || || || || ||                                         
    # || || || || || ++--------------- 5: BCD: Temp pos(0x4)/neg(0xC) und 10er Stelle 2
    # || || || || ++------------------ 4: BCD: 1 Stelle vor und nach Komma=>           4.6
    # || || || ||                                                                  24.6 °C
    # || || || ++--------------------- 3: device type: 0xCE&0x1F=0x0E (Rain Level?)               
    # || || ++------------------------ 2: package length (0xC7>>1)&0x1F = 3 bytes data
    # || ++--------------------------- 1: ID
    # ++------------------------------ 0: Kennung


Ich wünsche mir, dass 00_SIGNALduino.pm die Cresta Signale als "CRxx75xyz" oder "CR75xz" an das zu schreibende CRESTA fhem Modul 'dispatched'.

Werde noch mehr Daten von meinen 4 Sensoren sammeln und zum Testen meines Perl Codes zum Dekodieren verwenden.

~josef
Debian SID mit aktuellem FHEM, nanoCUL 866, JeeLink EC3000, fhemduino, SIGNALduino,
3 x TFA TH Sensor, 1 x TFA TH Arduino Sender, 3 x EC3000, 4 x Elro Schaltsteckdosen, ESA2000
offline: Wibo Funkthermostat, 2 x ELV Funkthermostat FHT80, 2 FS20 ST4 Funksteckdose
Drucken
Nach oben Seiten 1 ... 4 5 6 7 8 ... 146
Benutzer-Aktionen