SOMFY Rolladen und Handsender Status bzw. Position abgleichen mit SIGNALduino

Begonnen von timtom, 20 Mai 2017, 14:35:24

Vorheriges Thema - Nächstes Thema

nagelreo

@Ralf9

ja, ein Beispiel habe ich am 15 März 2020, 18:46:56 gepostet.
Zitat2020.03.15 07:13:21 4: CUL1: Parse_MC, Found manchester Protocol id 43 clock 643 RSSI -37.5 -> Somfy RTS
2020.03.15 07:13:21 4: CUL1: Somfy bitdata: 01010110010111001101111110110100110100011110010101000100 (56)
2020.03.15 07:13:21 4: CUL1: Somfy RTS preprocessing check: A enc: 565CDFB4D1E544 dec: 560A836B6534A1
2020.03.15 07:13:21 1: SOMFY Unknown device A13465 (56 836B), please define it
2020.03.15 07:13:21 4: CUL1: Read, msg: MC;LL=-1271;LH=1298;SL=-635;SH=655;D=565CDFB4D1E544;C=643;L=56;R=72;
dec fhem:  56 0A 836B 6534A1      cks ist korrekt, Adresse ist falsch
berechnetes cks: A
Bit 1 entfernt und Bit "0" angehängt
_10101100101110011011111101101001101000111100101010001000
dec Excel: AC 15 06D6 4269CA       cks und Adresse sind korrekt
berechnetes cks: 5
Bit 1 entfernt und Bit "1" angehängt
_10101100101110011011111101101001101000111100101010001001
dec Excel: AC 15 06D6 4369CA      cks und Adresse sind falsch
berechnetes cks: 4

@Kawaci,
in deinem Signalesp ist das sens mit 8 dB definert, default ist 4. Hast Du das "optimiert"?

Gruß
Rolf

Kawaci


Ralf9

Zitat@Ralf9
ja, ein Beispiel habe ich am 15 März 2020, 18:46:56 gepostet.
War dies mit der Firmware von mir oder mit der offiziellen von Sidey?
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

nagelreo

ZitatWar dies mit der Firmware von mir oder mit der offiziellen von Sidey?
Ich benutzte ab dem 5.03.2020 die FW SIGNALduino_nanoCC1101_3321rc9.hex.


Kawaci

Ich nutze die von sidey wäre das besser deine zu nehmen ralf? Geht die mit nem wemos?

nagelreo

Hallo Ralf,

mein Maplemini war fleißig und hat in den letzten 7 Tagen ca. 13000 Somfy-Signale gesammelt.

gesamt              12733
sun-sensor         12433  (ca. 80 Signale pro Stunde)
nicht erkannt          201  1.6 % (please define it)
davon sun-sensor    157  1.3 %
davon Handsender      8   2.7 %
Nachbar ?                 32  0.3 % (bit-Länge und cks ok, sehr schwaches Signal, RSSI < -90)

Bei fast allen nicht erkannten Signale (sun-sensor und Handsender) fehlte das erste bzw. die ersten beiden bits. Nach dem Ergänzen war die Adresse und cks ok.
Checksum error oder fehlende bist am Ende waren in den 7 Tagen nicht aufgetreten. Diese sind seit Umstellung auf den Maplemini und oder der aktuellen FW selten.

Was mich wundert, dass die Angabe der Signal-Länge bei bitdata (Anzahl in Klammer) nicht mit der Anzahl der bit-Folge übereinstimmt. Bei allen 3 Beispielen ist zähle ich in der bit-Folge 56 bits.
2020.08.09 18:44:52 4: MapleSduino1: Read, msg: MC;LL=-1268;LH=1273;SL=-647;SH=640;D=8115151672FC88;C=637;L=54;R=0;s1;b1;w;
2020.08.09 18:44:52 4: MapleSduino1: Parse_MC, Found manchester protocol id 43 clock 637 RSSI -74 -> Somfy RTS
2020.08.09 18:44:52 4: MapleSduino1: SomfyRTS, bitdata: 10000001000101010001010100010110011100101111110010001000 (54)
2020.08.09 18:44:52 4: MapleSduino1: Somfy RTS preprocessing check: 4 enc: 8115151672FC88 dec: 81940003648E74
2020.08.09 18:44:52 1: SOMFY Unknown device 748E64 (81 0003), please define it

2020.08.10 09:42:45 4: MapleSduino1: Read, msg: MC;LL=-1275;LH=1286;SL=-635;SH=638;D=408A8A8B397E44;C=638;L=55;R=248;s1;b1;
2020.08.10 09:42:45 4: MapleSduino1: Parse_MC, Found manchester protocol id 43 clock 638 RSSI -78 -> Somfy RTS
2020.08.10 09:42:45 4: MapleSduino1: SomfyRTS, bitdata: 01000000100010101000101010001011001110010111111001000100 (55)
2020.08.10 09:42:45 4: MapleSduino1: Somfy RTS preprocessing check: A enc: 408A8A8B397E44 dec: 40CA0001B2473A
2020.08.10 09:42:45 1: SOMFY Unknown device 3A47B2 (40 0001), please define it

2020.08.10 13:50:35 4: MapleSduino1: Read, msg: MC;LL=-1267;LH=1282;SL=-627;SH=663;D=A2A2CE5F910;C=639;L=41;R=240;s1;b1;
2020.08.10 13:50:35 4: MapleSduino1: Read, msg: MC;LL=-1283;LH=1267;SL=-647;SH=594;D=A04545459CBF22;C=631;L=56;R=240;s3;b3;
2020.08.10 13:50:35 4: MapleSduino1: Parse_MC, Found manchester protocol id 43 clock 631 RSSI -82 -> Somfy RTS
2020.08.10 13:50:35 4: MapleSduino1: SomfyRTS, bitdata: 10100000010001010100010101000101100111001011111100100010 (56)
2020.08.10 13:50:35 4: MapleSduino1: Somfy RTS preprocessing check: 5 enc: A04545459CBF22 dec: A0E50000D9239D


Daher bin ich mir nicht sicher, wie valide meine Aussage zu Deiner Frage ist.
Zitat@nagelreo
kommt es bei Dir auch ab und zu vor, daß bei einer korrekten Länge von 56 am Anfang ein Bit zuviel ist und am Ende ein Bit fehlt?

Gruß
Rolf

Ralf9

Ich habe hier
https://forum.fhem.de/index.php/topic,72173.msg1075881.html#msg1075881
die Nachrichten anpassungen überarbeitet.

Zitatsun-sensor 
sendet der auch Somfy Nachrichten, werden diese vom Somfy Modul erkannt?
56 oder 80 Bit?
Fangen die auch immer mit A an?

ZitatWas mich wundert, dass die Angabe der Signal-Länge bei bitdata (Anzahl in Klammer) nicht mit der Anzahl der bit-Folge übereinstimmt. Bei allen 3 Beispielen ist zähle ich in der bit-Folge 56 bits.
Bei einer Hex Nachricht sind die bitfolgen immer durch 4 teilbar, die Bitanzahl wird extra mit übergeben
z.B.
AA8 = 1010 1010 1000

Nachtrag
in den Logs von Kawaci lässt sich erkennen, warum mit der firmware von Sidey die Somfy Nachrichten nicht so gut erkannt werden, nur bei wenigen Nachrichten passen die Bits am Anfang
und es gibt auch Nachrichten wo die Länge und Checksum ok ist aber der Anfang nicht passt

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

nagelreo

Hallo Ralf,

Zitata:) Länge <= 60
- wenn die ersten 4 Bit "1010" (A) sind, dann ok
- bei einer Länge von 56 oder 57 wird geprüft ob die ersten 5 Bit "01010" sind, falls ja, dann wird das erste Bit entfernt, bei einer Länge von 56 wird am Ende eine 0 ergänzt
Bei der Anpassung verstehe ich nicht warum bei 56 bits
- das erste bit entfernt werden soll, "1010" = doch "A"
- am Ende eine 0 ergänzt werden soll, das Ziel sind doch 56 korrekte bits, oder?

Zitatsendet der auch Somfy Nachrichten, werden diese vom Somfy Modul erkannt?
56 oder 80 Bit?
Fangen die auch immer mit A an?
Sorry, habe vergessen zu erwähnen, dass der sun-sensor der "Somfy Soliris Sensor RTS" ist, 56 bit sendet. Die korrekte Signale beginnen mit "A" und werden von der Somfy Markise erkannt. Die 3 Beispiele zur bit Länge sind Signale vom sun-sensor.

ZitatBei einer Hex Nachricht sind die bitfolgen immer durch 4 teilbar, die Bitanzahl wird extra mit übergeben
z.B. AA8 = 1010 1010 1000
Das habe ich schon verstanden. Mein Punkt ist aber, dass die beiden Angaben (bit-folge und bit Länge in Klammer) im log nur im Beispiel 3 übereinstimmen.
bitdata: 10000001000101010001010100010110011100101111110010001000 (54) , gezählt 56
bitdata: 01000000100010101000101010001011001110010111111001000100 (55),  gezählt 56
bitdata: 10100000010001010100010101000101100111001011111100100010 (56),  gezählt 56

Gruß
Rolf

Elektrolurch

Hallo,

ich habe auch die Probleme mit dem Empfang, bzw. das immer wieder neue Handssender per autocreate angelegt werden.
Ich habe folgende Version auf dem Stick:
   version    V 3.3.2.1-rc9 SIGNALduino cc1101 - compiled at Jun 16 2019 20:18:01

Gibt es eine neuere Version und wie flashe ich die auf den Stick?

Danke.

Elektrolurch

configDB und Windows befreite Zone!

Heiner

Hi, ich glaube ich hab ein aehnliches Problem.

Ich habe im ganzen 

3 Fernbedienungen vom Typ Telis 4 RTS Pure
jede hat 5 Kanaele,davon sind 2 auf jeweis 1 Device geschaltet und ein Kanal je FB steuert 2 Devices parallel.

zum senden nehme ich ein signalduino mit CC1101, zum emfangen von den remotes ein Signalduino "normal".

Eine FB mit 2 Rollos funktioniert dahzu komplett so wie es sollte, 2 andere eher weniger.

Damit meine ich nicht immer wird der status in fhem angepasst, oft gibts fehlermeldungen im log und ab und zu werden neue devices angelegt.

Gern post ich hier mal details, sagt mir nur was genau damits nicht zuviel und zu durcheinander wird.

Vieleicht mit dem besser funktionierenden anfangen?

definition der 3 remote kanaele, die beiden devices sowie logs mit komentar welcher Taste an der remote gedrueckt wurde?
Oder warte ich besser bis Ihr eine Loesung habt, und teste dann weiter?

Viele Gruesse
Heiner
--------------------------------
fhem auf Pi3+
CUL 868MHz, Signalduino 434MHz, HM-CFG-USB
HM, THZ, Kostal, Somfy, Conbee, Pytonbinding, FritzBox, FTUI, MQTT2

Ralf9

ZitatBei der Anpassung verstehe ich nicht warum bei 56 bits
- das erste bit entfernt werden soll, "1010" = doch "A"
- am Ende eine 0 ergänzt werden soll, das Ziel sind doch 56 korrekte bits, oder?
Es wird nur das erste Bit entfernt, wenn am Anfang eine 5 steht, dies kommt bei der Firmware von Sidey recht oft vor.

ZitatDas habe ich schon verstanden. Mein Punkt ist aber, dass die beiden Angaben (bit-folge und bit Länge in Klammer) im log nur im Beispiel 3 übereinstimmen.
Es werden die Bits aus der Hex Nachricht ausgegeben, in Klammer steht dann die tatsächliche Bitanzahl.


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

Kawaci


Ralf9

meine aktuelle firmware V 3.3.2.1-rc9 gibt es nicht für den SignalESP,

@nagelreo
Da Du den MapleSduino verwendest, gehe ich davon aus, daß Du auch meine angepasstes 00_SIGNALduino.pm Modul verwendest.

Ich habe die hier beschriebenen
https://forum.fhem.de/index.php/topic,72173.msg1075881.html#msg1075881
Nachrichten fixe in mein 00_SIGNALduino.pm Modul eingebaut. Ich habe es noch nicht komplett getestet, es kann wahrscheinlich noch optimiert werden
Zum Testen muß in meiner angepassten 00_SIGNALduino.pm die "sub SIGNALduino_SomfyRTS" ersetzt werden:
sub SIGNALduino_SomfyRTS
{
my ($name, $bitData,$id,$mcbitnum) = @_;

my $flag = 0;
if (defined($mcbitnum)) {
Log3 $name, 4, "$name: Somfy bitdata: $bitData ($mcbitnum)";
if ($mcbitnum <= 60) {
if (substr($bitData, 0, 4) eq '1010') {
$flag = 1; # ok
}
elsif (($mcbitnum == 56 || $mcbitnum == 57) && substr($bitData, 0, 5) eq '01010') {
$bitData = substr($bitData, 1, $mcbitnum - 1);
if ($mcbitnum == 56) {
$bitData .= '0';
}
Log3 $name, 4, "$name: Somfy bitdata: _$bitData (" . length($bitData) . "). Bit am Anfang entfernt";
$flag = 1; # ok
}
elsif ($mcbitnum >= 52 && $mcbitnum <= 55) {
$bitData = substr($bitData, $mcbitnum - 52, 52);
$bitData = '1010' . $bitData;
Log3 $name, 4, "$name: Somfy bitdata: _$bitData (" . length($bitData) . "). 1010 am Anfang zugefuegt";
$flag = 1; # ok
}
}
else { # 80 Bit Nachrichten
if (substr($bitData, 0, 4) eq '1010' || substr($bitData, 0, 4) eq '1000') {
$flag = 1; # ok
}
elsif (($mcbitnum == 80 || $mcbitnum == 81) && (substr($bitData, 0, 5) eq '01010' || substr($bitData, 0, 5) eq '01000')) {
$bitData = substr($bitData, 1, $mcbitnum - 1);
if ($mcbitnum == 80) {
$bitData .= '0';
}
Log3 $name, 4, "$name: Somfy bitdata: _$bitData (" . length($bitData) . "). Bit am Anfang entfernt";
$flag = 1; # ok
}
elsif ($mcbitnum == 78 || $mcbitnum == 79) {
$bitData = substr($bitData, $mcbitnum - 78, 78);
$bitData = '10' . $bitData;
Log3 $name, 4, "$name: Somfy bitdata: _$bitData (" . length($bitData) . "). 10 am Anfang zugefuegt";
$flag = 1; # ok
}
}
}
return (-1,"Somfy check error!") if ($flag == 0);

my $encData = SIGNALduino_b2h($bitData);

#Log3 $name, 4, "$name: Somfy RTS protocol enc: $encData";
return (1, $encData);
}


Nachtrag:
Dieser Somfy Nachrichten fix, sollte eigentlich auch mit dem offiziellen 00_SIGNALduino.pm von Sidey bis zur Version v3.4.4 funktionieren.
Evtl muss dazu am Anfang der Sub ein "()" ergänzt werden:
sub SIGNALduino_SomfyRTS()

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

Elektrolurch

Hallo Ralf,

jetzt habe ich wie oben von Dir angegeben, die Routine ausgetauscht, aber jetzt werden gar keine Handsender mehr erkannt.
Stimmt das mit dem 00_SIGNALduiono.pm Model?


# $Id: 00_SIGNALduino.pm v3.4.4 2020-04-07 21:20:33Z Sidey $
#
# v3.4.3 - https://github.com/RFD-FHEM/RFFHEM/tree/dev-r34


Elektrolurch
configDB und Windows befreite Zone!

Ralf9

Diese sub SIGNALduino_SomfyRTS funktioniert nicht bei der 00_SIGNALduino.pm von Sidey.

Dies ist eine Vorabversion zum Testen für @nagelreo
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