Signalduino Entwicklung

[mahowi]

Sollte auch so funktionieren. Ich habe so auch mehrere Quellen hinzugefügt.

Gesendet von meinem SM-G900F mit Tapatalk

[waschbaerbauch]

Ok, aber was passiert wenn ich das JETZT ausführe?

Code Auswählen Erweitern

fhem
List of new / modified files since last update:
UPD ./CHANGED
UPD ./fhem.pl
UPD FHEM/00_SIGNALduino.pm
UPD FHEM/10_ZWave.pm
UPD FHEM/14_Hideki.pm
UPD FHEM/14_SD_WS07.pm
UPD FHEM/38_JawboneUp.pm
UPD FHEM/41_OREGON.pm
UPD FHEM/49_SSCam.pm
UPD FHEM/70_MEDIAPORTAL.pm
UPD FHEM/72_FRITZBOX.pm
UPD FHEM/90_SIGNALduino_un.pm
UPD FHEM/98_DOIF.pm
UPD FHEM/firmware/SIGNALduino_nano328.hex
UPD FHEM/firmware/SIGNALduino_promini328.hex
UPD FHEM/firmware/SIGNALduino_uno.hex

New entries in the CHANGED file:
  - feature  49_SSCAM: added function "move" for continuous PTZ action

signalduino
nothing to do...

Dann macht er doch das Update aus dem FHEM repository und überschreibt die dev Variante?!

Edit: Ok dann siehst das Ergebnis so aus

Code Auswählen Erweitern

fhem
List of new / modified files since last update:
UPD FHEM/00_SIGNALduino.pm
UPD FHEM/14_Hideki.pm
UPD FHEM/14_SD_WS07.pm
UPD FHEM/41_OREGON.pm
UPD FHEM/90_SIGNALduino_un.pm
UPD FHEM/firmware/SIGNALduino_nano328.hex
UPD FHEM/firmware/SIGNALduino_promini328.hex
UPD FHEM/firmware/SIGNALduino_uno.hex

signalduino
nothing to do...

[waschbaerbauch]

Im Log tauchen eine Menge Einträge dieser Art auf:

Code Auswählen Erweitern

2016.02.10 01:04:37 4: SIGduino/msg READ: MC;LL=-1051;LH=907;SL=-559;SH=412;D=72389A23441F5107D000000001708080;C=439;
2016.02.10 01:04:37 4: SIGduino: Found manchester Protocol id 10 clock 439 -> OSV2o3
2016.02.10 01:04:37 4: SIGduino: Found manchester Protocol id 12 clock 439 -> Hideki protocol
2016.02.10 01:04:37 4: SIGduino/msg READ: MC;LL=-1005;LH=956;SL=-520;SH=457;D=A8DC765DEBBE0AEF82FFFFFFFFE8E48E;C=470;
2016.02.10 01:04:37 4: SIGduino: Found manchester Protocol id 10 clock 470 -> OSV2o3
2016.02.10 01:04:37 4: SIGduino: Found manchester Protocol id 12 clock 470 -> Hideki protocol
2016.02.10 01:04:37 4: SIGduino: hideki protocol converted to hex: 750F750FFDFFFFFFC52407 with 94 bits, messagestart 34
2016.02.10 01:04:37 4: Hideki_Parse SIGduino incomming P12#750F750FFDFFFFFFC52407
2016.02.10 01:04:37 4: Hideki_Parse SensorTyp = 17 decodedString = 75119f11070101014f6c09
2016.02.10 01:04:37 4: SIGduino crc failed
2016.02.10 01:04:37 4: Hideki_Parse SIGduino incomming P12#750F750FFDFFFFFFC52407
2016.02.10 01:04:37 4: Hideki_Parse SensorTyp = 17 decodedString = 75119f11070101014f6c09
2016.02.10 01:04:37 4: SIGduino crc failed
2016.02.10 01:04:37 4: SIGNALduino_unknown incomming msg: P12#750F750FFDFFFFFFC52407
2016.02.10 01:04:37 4: SIGNALduino_unknown rawData: 750F750FFDFFFFFFC52407
2016.02.10 01:04:37 4: SIGNALduino_unknown Protocol: 12
2016.02.10 01:04:37 4: SIGNALduino_unknown converted to bits: 0111010100001111011101010000111111111101111111111111111111111111110001010010010000000111

'SensorTyp = 17' ist auffällig oft mit 'SIGduino: hideki protocol converted to hex: 750F750FFDFFFFFFC52407 with 94 bits, messagestart 34' vertreten. Nur selten kommen '95 bits, messagestart 25' und '78 bits, messagestart 34' dazwischen.

[Ralf9]

Im Log tauchen eine Menge Einträge dieser Art auf:

'SensorTyp = 17' ist auffällig oft mit 'SIGduino: hideki protocol converted to hex: 750F750FFDFFFFFFC52407 with 94 bits, messagestart 34' vertreten. Nur selten kommen '95 bits, messagestart 25' und '78 bits, messagestart 34' dazwischen.

Verschwinden diese Meldungen, wenn du im windsensor die Batterien entfernst?

Gruß Ralf

[waschbaerbauch]

Moin!

Der will mich doch verar...en..

Seit 02:11 Uhr keine Spur mehr von 'SensorTyp = 17' 

[Sidey]

Hmm, 95 Bits sind eine krumme Zahl. Die Zahl der Bits sollte sich immer durch 0 teilen lassen.

@Ralf: Wie machen wir das aktuell mit dem CRC Check?
Werten wir vor der CRC Berechnung das Längenbit aus?
Da könnte ja ggf. Der Fehler liegen.

Sidey

[hjgode]

Hmm, 95 Bits sind eine krumme Zahl. Die Zahl der Bits sollte sich immer durch 0 teilen lassen.

@Ralf: Wie machen wir das aktuell mit dem CRC Check?
Werten wir vor der CRC Berechnung das Längenbit aus?
Da könnte ja ggf. Der Fehler liegen.

Sidey

Sollte so sein (dev-r32):

Code Auswählen Erweitern


...
# check crc for incoming message
# in: hex string with encrypted, raw data, starting with 75
# out: 1 for OK, 0 for failed
# sample "75BDBA4AC2BEC855AC0A00"
sub Hideki_crc{
#my $Hidekihex=shift;
#my @Hidekibytes=shift;

my @Hidekibytes = @{$_[0]};
#push @Hidekibytes,0x75; #first byte always 75 and will not be included in decrypt/encrypt!
#convert to array except for first hex
#for (my $i=1; $i<(length($Hidekihex))/2; $i++){
    # my $hex=Hideki_decryptByte(hex(substr($Hidekihex, $i*2, 2)));
# push (@Hidekibytes, $hex);
#}

my $cs1=0; #will be zero for xor over all (bytes>>1)&0x1F except first byte (always 0x75)
#my $rawData=shift;
#todo add the crc check here

my $count=($Hidekibytes[2]>>1) & 0x1f;
my $b;
#iterate over data only, first byte is 0x75 always
for (my $i=1; $i<$count+2 && $i<scalar @Hidekibytes; $i++) {
$b =  $Hidekibytes[$i];
$cs1 = $cs1 ^ $b; # calc first chksum
}
...


[Sidey]

Hmm, ich sehr zwar, dass in $count die Länge steht, aber wo $count verwendet wird, sehe ich gerade nicht.

Grüße Sidey

[Ralf9]

Man könnte auch vor dem Aufruf von Hideki_crc das Längenbyte auswerten und
bei zu kurzer Nachricht eine log Meldung machen, daß die Nachricht zu kurz ist und die soll- und ist Länge mit ausgeben

Gruß Ralf

[hjgode]

Hmm, ich sehr zwar, dass in $count die Länge steht, aber wo $count verwendet wird, sehe ich gerade nicht.

Grüße Sidey

Na, bei der Berechnung des CRC1:

Code Auswählen Erweitern

for (my $i=1; $i<$count+2 && $i<scalar @Hidekibytes; $i++)

[hjgode]

Man könnte auch vor dem Aufruf von Hideki_crc das Längenbyte auswerten und
bei zu kurzer Nachricht eine log Meldung machen, daß die Nachricht zu kurz ist und die soll- und ist Länge mit ausgeben

Gruß Ralf

Dann müsste man auch den Typ vorher auswerten nachdem entschlüsselt wurde, da die Länge der Nachricht vom Typ abhängig ist:

T/H insgesamt 9 Bytes
Anemometer insgesamt 12 Bytes
UV index = 9 Bytes
Rain = 8 Bytes

~josef

[Sidey]

Dann müsste man auch den Typ vorher auswerten nachdem entschlüsselt wurde, da die Länge der Nachricht vom Typ abhängig ist:

T/H insgesamt 9 Bytes
Anemometer insgesamt 12 Bytes
UV index = 9 Bytes
Rain = 8 Bytes

~josef

Lasst es uns sich einfach machen und einfach prüfen ob $count <= scalar @hidekibytes ist.. Solange es nicht zu kurz ist, ist alles gut. Wie große die Abweichungen ist spielt doch keine Rolle.

Grüße Sidey

[Ralf9]

Dann müsste man auch den Typ vorher auswerten nachdem entschlüsselt wurde, da die Länge der Nachricht vom Typ abhängig ist:

In Byte 2 steckt Länge der Nachricht

Code Auswählen Erweitern

Bits number 5..1 hold of bytes the to package read from length. byte n1 = to (b byte ≫ 11) n.
So & 0x1F after.reading Where b byte is byte 2, we 2, still andneed n is the to read n-2 bytes before we reach the checksum.
Bits 7 and 6 always seem to be "1", bit 0 always seems to be "0". These bits may however have some meaning which I am unaware of.

Ich würde es so machen

Code Auswählen Erweitern

my $packageLen = (($decodedBytes[2]>>1) & 0x1f) + 2;
my $decodedLen = length($decodedString);
if ($decodedLen < $packageLen) {        # zu kurz

Wenn die Nachricht zu kurz ist  kann mit return abgebrochen werden

Gruß Ralf

[Sidey]

Code Auswählen Erweitern

my $packageLen = (($decodedBytes[2]>>1) & 0x1f) + 2;
my $decodedLen = length($decodedString);
if ($decodedLen < $packageLen) {        # zu kurz

Ginge das nicht noch einfacher? Nachdem ich noch mal die Protokollbeschreibung gelesen habe, müsste $count+2 auch falsch sein, da in $count ja die Anzahl an Bytes steht und wir zusätzlich noch den übertragenen crc Wert auswerten müssen.

Code Auswählen Erweitern


my $count=($Hidekibytes[2]>>1) & 0x1f;
        log3 $name, 5, "$name: Message is to short" && return 0 if (scalar @Hidekibytes < $count);

my $b;

#iterate over data only, first byte is 0x75 always n+1 must also be checked
for (my $i=1; $i<$count+1; $i++) {



Grüße Sidey

[hjgode]

Ginge das nicht noch einfacher? Nachdem ich noch mal die Protokollbeschreibung gelesen habe, müsste $count+2 auch falsch sein, da in $count ja die Anzahl an Bytes steht und wir zusätzlich noch den übertragenen crc Wert auswerten müssen.

Code Auswählen Erweitern


my $count=($Hidekibytes[2]>>1) & 0x1f;
        log3 $name, 5, "$name: Message is to short" && return 0 if (scalar @Hidekibytes < $count);

my $b;

#iterate over data only, first byte is 0x75 always n+1 must also be checked
for (my $i=1; $i<$count+1; $i++) {



Grüße Sidey

Zitat:

Code Auswählen Erweitern

Byte n+1: The checksum byte makes sure that the outcome of an exclusive or of bytes 1..n+1 is 0.

Also muss die checksumme bis n+1 gezählt werden.

Code Auswählen Erweitern

for(my $i=1; $i < $count+2...

zählt bis count+1 (oder wie in der Doku bis n+1); die Zählung in perl beginnt wie in der Doku bei 0; das 1. Byte wird bei der checksumme ausgespart. Man hätte auch

Code Auswählen Erweitern


for(my $i=1; $i =< $count+1...

schreiben können, Dann verwirrt es nicht so. Liest sich dann einfach: 'Für Byte 1 bis n+1'

Fazit: Die checksummen-Berechnung is OK so.

~Josef