Signalduino Version 3.3.1 / 3.3.2 / 3.3.3-dev

RappaSan · 14 April 2017, 11:13:06

Geht nicht. Sind Sensoren von dem(den) Nachbarn.

Aber jetzt hab ich wenigstens eine Erklärung. Danke Dir.

Der Sduino läuft hier mit longids=0, das hab ich jetzt mal umgestellt.
Und siehe da: Es funken 3 von den Dingern hier herum - bis jetzt.

Gerade gesehen: Die halten sich aber auch nicht an das min-intervall.
Im angelegen Filelog stehen beispielhaft folgende Dinge:

2017-04-14_11:08:10 SD_WS07_TH_3E1 T: 8.5 H: 74
2017-04-14_11:08:10 SD_WS07_TH_3E1 temperature: 8.5
2017-04-14_11:08:10 SD_WS07_TH_3E1 humidity: 74
2017-04-14_11:08:10 SD_WS07_TH_3E1 battery: ok
2017-04-14_11:08:10 SD_WS07_TH_3E1 channel: 1
2017-04-14_11:10:04 SD_WS07_TH_3E1 T: 8.6 H: 74
2017-04-14_11:10:04 SD_WS07_TH_3E1 temperature: 8.6
2017-04-14_11:11:58 SD_WS07_TH_3E1 T: 8.6 H: 73
2017-04-14_11:11:58 SD_WS07_TH_3E1 humidity: 73
2017-04-14_11:13:52 SD_WS07_TH_3E1 battery: ok
2017-04-14_11:13:52 SD_WS07_TH_3E1 channel: 1
2017-04-14_11:14:49 SD_WS07_TH_3E1 T: 8.7 H: 73
2017-04-14_11:14:49 SD_WS07_TH_3E1 temperature: 8.7
2017-04-14_11:17:40 SD_WS07_TH_3E1 T: 8.8 H: 73
2017-04-14_11:17:40 SD_WS07_TH_3E1 temperature: 8.8
2017-04-14_11:17:40 SD_WS07_TH_3E1 humidity: 73
2017-04-14_11:19:34 SD_WS07_TH_3E1 T: 8.8 H: 72
2017-04-14_11:19:34 SD_WS07_TH_3E1 humidity: 72
2017-04-14_11:19:34 SD_WS07_TH_3E1 battery: ok
2017-04-14_11:19:34 SD_WS07_TH_3E1 channel: 1
2017-04-14_11:21:28 SD_WS07_TH_3E1 T: 8.9 H: 72
2017-04-14_11:21:28 SD_WS07_TH_3E1 temperature: 8.9

Da ist von 5 Minuten Mindestabstand keine Spur...

RappaSan · 14 April 2017, 12:12:55

Hab mir gerade noch mal die verschiedenen event-on- Beschreibungen genauer angesehen. Das war dann wohl ein Mißverständnis des Zusammenspiels von min-intervall und change-reading bei mir.
event-on-change: Das event wird bei jeder Änderung ausgeführt, min-intervall spielt dann keine Rolle. Erst wenn im eingestellten min-intervall sich nix geändert hat, schägt das min-intervall zu und löst ein event aus.
event-on-update: Das event wird bei jedem Update des devices ausgelöst, aber es muß min-intervall an Zeit vergangen sein.

Selbst Rudolf scheint da seine Probleme mit zu haben: https://forum.fhem.de/index.php/topic,36522.msg412249.html#msg412249

Da ist es bei uns "normal sterblichen" kein Wunder...

arthur_dent_2015 · 15 April 2017, 18:33:46

Moin zusammen,
ich habe vor ca. 3 Wochen meine Somfy Rollläden von CUL433 auf Signalduino umgestellt. Das hat anfangs auch problemlos funktioniert (wenn man beim restart von fhem das IODev auf sduino setzt). Seit ein paar Tagen (letztes fhem update?) funktioniert das Senden aber nicht mehr richtig. Mal fährt abends ein Rollladen nicht runter, mal bleibt ein Rollladen geschlossen wenn ich die Balkontür öffne. Meist bedarf es mehrerer set Befehle bis ein Rollladen reagiert

Hier mal ein Auszug aus meinem aktuellen Log:

Code Auswählen


sduino3/keepalive ok, retry = 0
2017.04.15 17:37:20 4: sduino/keepalive ok, retry = 0
2017.04.15 17:37:32 4: SOMFY_set: Roll2 -> entering with mode :send: cmd :on:  arg1 ::  pos :0: 
2017.04.15 17:37:32 4: SOMFY_set: handled command on --> move :on:  newState :closed: 
2017.04.15 17:37:32 5: SOMFY_set: handled for drive/udpate:  updateState ::  drivet :0: updatet :0: 
2017.04.15 17:37:32 4: SOMFY_sendCommand: Roll2 -> cmd :on: 
2017.04.15 17:37:32 4: sduino/set: sending via SendMsg: SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=640;D=A0ECECECECECCC;F=10AB85550A;
2017.04.15 17:37:32 4: sduino SendFromQueue: msg=SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=640;D=A0ECECECECECCC;F=10AB85550A;
2017.04.15 17:37:33 4: sduino/msg READ: write new ccreg  10AB85550A
2017.04.15 17:37:33 4: sduino/msg READ: Received answer (write new ccreg  10AB85550A) for sendraw does not match ^S(R|C|M);
2017.04.15 17:37:33 4: sduino/msg READ: ccreg write back 10AB853500
2017.04.15 17:37:33 4: sduino/msg READ: Received answer (ccreg write back 10AB853500) for sendraw does not match ^S(R|C|M);
2017.04.15 17:37:33 4: sduino/msg READ: SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=640;D=A0ECECECECECCC;F=10AB85550A;
2017.04.15 17:37:33 4: sduino/read sendraw answer: SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=640;D=A0ECECECECECCC;F=10AB85550A;
2017.04.15 17:37:33 4: sduino/HandleWriteQueue: nothing to send, stopping timer
2017.04.15 17:38:04 4: sduino3/KeepAlive not ok, retry = 1 -> get ping
2017.04.15 17:38:09 4: sduino3/msg READ: OK
2017.04.15 17:38:09 4: sduino3/HandleWriteQueue: nothing to send, stopping timer
2017.04.15 17:38:22 4: sduino/keepalive ok, retry = 0
2017.04.15 17:38:50 4: sduino/set: sending via SendMsg: SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=640;D=A0EEEEEE00EE00;F=10AB85550A;
2017.04.15 17:38:50 4: sduino SendFromQueue: msg=SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=640;D=A0EEEEEE00EE00;F=10AB85550A;
2017.04.15 17:38:50 4: sduino/msg READ: write new ccreg  10AB85550A
2017.04.15 17:38:50 4: sduino/msg READ: Received answer (write new ccreg  10AB85550A) for sendraw does not match ^S(R|C|M);
2017.04.15 17:38:51 4: sduino/msg READ: ccreg write back 10AB853500
2017.04.15 17:38:51 4: sduino/msg READ: Received answer (ccreg write back 10AB853500) for sendraw does not match ^S(R|C|M);
2017.04.15 17:38:51 4: sduino/msg READ: SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=640;D=A0EEEEEE00EE00;F=10AB85550A;
2017.04.15 17:38:51 4: sduino/read sendraw answer: SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=640;D=A0EEEEEE00EE00;F=10AB85550A;
2017.04.15 17:38:51 4: sduino/HandleWriteQueue: nothing to send, stopping timer
2017.04.15 17:39:04 4: sduino3/keepalive ok, retry = 0
2017.04.15 17:39:22 4: sduino/keepalive ok, retry = 0
2017.04.15 17:40:05 4: sduino3/KeepAlive not ok, retry = 1 -> get ping
2017.04.15 17:40:08 4: sduino3/msg READ: OK

und ein list vom sduine device:

Code Auswählen


Internals: 
   CFGFN 
   Clients    :IT:CUL_TCM97001:SIGNALduino_RSL:OREGON:CUL_TX:SD_AS:Hideki:SD_WS07:SD_WS09: :SD_WS:RFXX10REC:Dooya:SOMFY:SD_UT:SD_WS_Maverick:FLAMINGO:CUL_WS:Revolt:SIGNALduino_un:SD_WS_Maverick:FS10:SIGNALduino_un: 
   DEF        /dev/serial/by-path/platform-3f980000.usb-usb-0:1.2.1.4:1.0-port0@57600 
   DMSG       nothing 
   DevState   initialized 
   DeviceName /dev/serial/by-path/platform-3f980000.usb-usb-0:1.2.1.4:1.0-port0@57600 
   FD         45 
   NAME       sduino 
   NR         818 
   PARTIAL 
   STATE      opened 
   TIME       1492272329.82986 
   TYPE       SIGNALduino 
   version    V 3.3.1-dev SIGNALduino cc1101 - compiled at Mar 10 2017 22:54:50 
   Helper: 
     Dblog: 
       State: 
         Fhemlogdb: 
           TIME       1492272363.33962 
           VALUE      opened 
   Matchlist: 
     10:SD_WS07 ^P7#[A-Fa-f0-9]{6}F[A-Fa-f0-9]{2} 
     11:SD_WS09 ^P9#[A-Fa-f0-9]+ 
     12:SD_WS   ^W\d+x{0,1}#.* 
     13:RFXX10REC ^(20|29)[A-Fa-f0-9]+ 
     14:Dooya   ^P16#[A-Fa-f0-9]+ 
     15:SOMFY   ^YsA[0-9A-F]+ 
     16:SD_WS_Maverick ^P47#[A-Fa-f0-9]+ 
     1:IT       ^i...... 
     21:FS10    ^P61#[A-F0-9]+ 
     2:CUL_TCM97001 ^s[A-Fa-f0-9]+ 
     4:OREGON   ^(3[8-9A-F]|[4-6][0-9A-F]|7[0-8]).* 
     5:CUL_TX   ^TX.......... 
     7:Hideki   ^P12#75[A-F0-9]+ 
     X:SIGNALduino_un ^[uP]\d+#.* 
   QUEUE: 
   Readings: 
     2017-04-15 18:11:09   ccconf          freq:433.420MHz bWidth:464KHz rAmpl:42dB sens:4dB  (DataRate:1500.13Baud) 
     2017-04-15 18:25:19   ping            OK 
     2017-04-15 18:06:03   state           opened 
     2017-04-15 18:06:03   version         V 3.3.1-dev SIGNALduino cc1101 - compiled at Mar 10 2017 22:54:50 
   Getcmd: 
   Keepalive: 
     ok         0 
     retry      0 
   mcIdList: 
     43 
   msIdList: 
     17 
     3 
     4 
   muIdList: 
     5 
Attributes: 
   flashCommand avrdude -c arduino -b 57600 -P [PORT] -p atmega328p -vv -U flash:w:[HEXFILE] 2>[LOGFILE] 
   hardware   nanoCC1101 
   verbose    4 
   whitelist_IDs 3,4,5,17,43

und auch noch eins vom Somfy device:

Code Auswählen


Internals: 
   ADDRESS    200000 
   CFGFN 
   DEF        200000 
   IODev      sduino 
   NAME       Roll2 
   NR         526 
   STATE      closed 
   TYPE       SOMFY 
   move       on 
   Code: 
     1          200000 
   Readings: 
     2017-04-15 18:13:59   enc_key         A2 
     2017-04-15 18:13:59   exact           200 
     2017-04-15 18:13:59   position        200 
     2017-04-15 18:13:59   rolling_code    0002 
     2017-04-15 18:13:59   state           closed 
Attributes: 
   DbLogInclude .* 
   IODev      sduino 
   devStateIcon closed:fts_shutter_100:open open:fts_shutter_10 
   event-on-change-reading state 
   eventMap   on:down off:up 
   group      Rollladen_group 
   room       Somfy 
   verbose    5

nach Ausführung von set Roll2 on, Rolladen ist aber weiterhin offen

Signalsuino und Sofy Modul Version:

Code Auswählen


00_SIGNALduino.pm    10486 2017-04-09 22:00:00Z v3.3.1-dev
10_SOMFY.pm          12918 2016-12-31 10:10:47Z viegener

Wo kann das Problem sein?

Danke & Gruß
Arthur

Ralf9 · 16 April 2017, 18:59:47

@sash.sc
Ich habe ein Attribut rawmsgEvent zugefügt. Damit werden bei RAWMSG events erzeugt.
Ist es so ausreichend?

Gruß Ralf

pejonp · 16 April 2017, 19:23:53

Hallo Sidey,

ich wünsche schöne Ostern.

Ich habe jetzt festgestellt das die Hideki-Nachrichten nicht immer dekodiert werden. Vielleicht kannst du mir da helfen.

Code Auswählen


das ist OK!
2017.04.16 18:59:09 4: sduino/msg READ: MC;LL=-1026;LH=928;SL=-552;SH=429;D=A8EAF45ACFA40AE775AAEEC;C=489;L=90;R=255;
2017.04.16 18:59:09 4: sduino: Found manchester Protocol id 12 clock 489 RSSI -74.5 -> Hideki protocol
2017.04.16 18:59:09 5: sduino: extracted data 01010111000101010000101110100101001100000101101111110101000110001000101001010101000100010011 (bin)
2017.04.16 18:59:09 4: sduino: hideki protocol converted to hex: 752ABACAD0BF3151552201 with 91 bits, messagestart 1
2017.04.16 18:59:09 5: sduino: converted Data to (P12#752ABACAD0BF3151552201)
2017.04.16 18:59:09 5: sduino: dispatch P12#752ABACAD0BF3151552201
2017.04.16 18:59:09 4: Hideki_Parse sduino incomming P12#752ABACAD0BF3151552201
2017.04.16 18:59:09 4: Hideki_Parse SensorTyp = 30 decodedString = 757ece5e70c153f3ff6603
2017.04.16 18:59:09 4: sduino decoded Hideki protocol model=Hideki_30, sensor id=7e, channel=3, bat=ok, temp=17, humidity=53
2017.04.16 18:59:09 4: sduino using longid: 1 model: Hideki_30
2017.04.16 18:59:09 5: deviceCode: Hideki_30_7e.3
2017.04.16 18:59:09 4: sduino/msg READ: MC;LL=-1017;LH=935;SL=-527;SH=445;D=57A2D77D20573BAD5FCE;C=487;L=79;R=0;
2017.04.16 18:59:09 4: sduino: Found manchester Protocol id 12 clock 487 RSSI -74 -> Hideki protocol
2017.04.16 18:59:09 5: sduino: extracted data 10101000010111010010100010000010110111111010100011000100010100101010000000110001 (bin)
2017.04.16 18:59:10 4: sduino/msg READ: MS;P0=-14698;P1=441;P2=-534;P3=935;P4=-1017;D=101212123432121434123434123412121212123432143212121212143434121232141212341212343412343434321412321214121212121;CP=1;SP=0;R=255;
2017.04.16 18:59:11 4: sduino/msg READ: MU;P0=-636;P1=248;P2=176;P3=-105;P4=127;P5=-360;P7=-152;D=012343252323434323232740404323232341134343;CP=4;R=221;
2017.04.16 18:59:14 4: sduino/msg READ: MS;P0=-3905;P1=499;P2=-1943;P3=-9213;D=13121012101212121010101010101212101212121210101210101012101212101210101212;CP=1;SP=3;R=57;O;
2017.04.16 18:59:14 4: sduino/msg READ: MS;P0=-1962;P1=442;P2=-3914;P3=-9184;D=13101210121010101212121212121010121010101012121012121210121010121012121010;CP=1;SP=3;R=60;
2017.04.16 18:59:21 4: sduino/msg READ: MC;LL=-1042;LH=909;SL=-559;SH=418;D=5ACC3E0BC75590FC4;C=487;L=66;R=25;

2 Sensoren werden nicht erkannt:
2017.04.16 18:59:21 4: sduino/msg READ: MC;LL=-1053;LH=906;SL=-553;SH=416;D=39CD16BB0F82F1D5647AD;C=487;L=84;R=25;
2017.04.16 18:59:21 4: sduino: Found manchester Protocol id 12 clock 487 RSSI -61.5 -> Hideki protocol
2017.04.16 18:59:21 5: sduino: extracted data 110001100011001011101001010001001111000001111101000011100010101010011011100001010010 (bin)
2017.04.16 18:59:22 4: sduino/msg READ: MC;LL=-1057;LH=895;SL=-556;SH=418;D=345ADC3E0BC75590714;C=487;L=74;R=25;
2017.04.16 18:59:22 4: sduino: Found manchester Protocol id 12 clock 487 RSSI -61.5 -> Hideki protocol
2017.04.16 18:59:22 5: sduino: extracted data 1100101110100101001000111100000111110100001110001010101001101111100011101011 (bin)

Ich habe es mit einem rtl-sdr (rtl_433) verglichen. Dort werden die Sensor angezeigt. Ich habe die beiden Sensoren in ca. 1,5 m Abstand beim Signalduino zu stehen und diese werden nicht erkannt.
Ich habe in der Signalduino.pm auch schon die clockrange => [420,500] angepaßt (alt 510).
Es wird ja noch etwas bei Hideki geprüft !?

Jetzt habe ich nur Protokoll 12 aktiviert.

Code Auswählen


etwas später, wieder nicht erkannt:
2017.04.16 19:12:06 4: sduino/msg READ: MC;LL=-1037;LH=911;SL=-544;SH=430;D=CD16B30F82F1D5643F1;C=486;L=76;R=25;
2017.04.16 19:12:06 4: sduino: Found manchester Protocol id 12 clock 486 RSSI -61.5 -> Hideki protocol
2017.04.16 19:12:06 5: sduino: extracted data 0011001011101001010011001111000001111101000011100010101010011011110000001110 (bin)
2017.04.16 19:12:07 4: sduino/msg READ: MS;P0=-5200;P1=433;P2=316;P3=-538;P4=-1038;P5=924;D=1023141313531413135314135453131454135454131354135313131413131313531313131454131313531314131354545454135314531314131313545413541;CP=1;SP=0;R=24;
2017.04.16 19:12:07 4: sduino/msg READ: MC;LL=-1039;LH=916;SL=-547;SH=431;D=39A2D6E1F05E3AAC838A;C=488;L=79;R=25;
2017.04.16 19:12:07 4: sduino: Found manchester Protocol id 12 clock 488 RSSI -61.5 -> Hideki protocol
2017.04.16 19:12:07 5: sduino: extracted data 11000110010111010010100100011110000011111010000111000101010100110111110001110101 (bin)
2017.04.16 19:12:10 4: sduino/msg READ: MC;LL=-1049;LH=919;SL=-549;SH=422;D=DD16B2F182F1D571FA1;C=489;L=76;R=22;
2017.04.16 19:12:10 4: sduino: Found manchester Protocol id 12 clock 489 RSSI -63 -> Hideki protocol
2017.04.16 19:12:10 5: sduino: extracted data 0010001011101001010011010000111001111101000011100010101010001110000001011110 (bin)
2017.04.16 19:12:10 4: sduino/msg READ: MC;LL=-1042;LH=914;SL=-554;SH=421;D=E8B5D78C178EAB8DFE8;C=488;L=73;R=22;
2017.04.16 19:12:10 4: sduino: Found manchester Protocol id 12 clock 488 RSSI -63 -> Hideki protocol
2017.04.16 19:12:10 5: sduino: extracted data 0001011101001010001010000111001111101000011100010101010001110010000000010111 (bin)
2017.04.16 19:12:10 4: sduino/msg READ: MC;LL=-1043;LH=904;SL=-554;SH=423;D=E8B5B78C178EAB8ECA8;C=487;L=73;R=21;
2017.04.16 19:12:10 4: sduino: Found manchester Protocol id 12 clock 487 RSSI -63.5 -> Hideki protocol
2017.04.16 19:12:10 5: sduino: extracted data 0001011101001010010010000111001111101000011100010101010001110001001101010111 (bin)
2017.04.16 19:12:14 4: sduino/msg READ: MC;LL=-1022;LH=964;SL=-496;SH=460;D=332D2D32D2B2B4B52CB4B4CAAAB2ACAAB32CCB34;C=490;L=160;R=243;
2017.04.16 19:12:14 4: sduino: Found manchester Protocol id 12 clock 490 RSSI -80.5 -> Hideki protocol
2017.04.16 19:12:14 5: sduino: extracted data 1100110011010010110100101100110100101101010011010100101101001010110100110100101101001011001101010101010101001101010100110101010101001100110100110011010011001011 (bin)
2017.04.16 19:12:14 4: sduino/msg READ: MC;LL=-1123;LH=943;SL=-479;SH=459;D=555555554CCB4B4CB4ACAD2D4B2D2D32AAACAB2AACCB328;C=500;L=185;R=243;

ccconf: freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:4dB (DataRate:5603.79Baud)
version: V 3.3.1-dev SIGNALduino cc1101 - compiled at Mar 10 2017 22:54:50

00_CUL.pm 13833 2017-03-28 15:43:17Z rudolfkoenig
14_CUL_TCM97001.pm 12994 2017-01-07 07:49:53Z bjoernh
14_Hideki.pm 14395 2017-01-25 18:00:00Z v3.3.1-dev
36_JeeLink.pm 12695 2016-12-01 21:38:18Z justme1968
41_OREGON.pm 34476 2016-12-04 13:00:00Z dev
14_SD_WS.pm 33 2017-01-19 18:00:00Z v3.3-dev
00_SIGNALduino.pm 10486 2017-04-09 22:00:00Z v3.3.1-dev

Danke,
Jörg

pejonp · 16 April 2017, 19:48:50

@sidey,@ralf

in der Signalduino.pm ist die ID=62 doppelt. Soll das so sein ? Ich habe es bei mir mal auf ID=63 gesetzt.

Jörg

Code Auswählen


	"62" => ## Clarus_Switch  
		{    #MU;P0=-5893;P4=-634;P5=498;P6=-257;P7=116;D=45656567474747474745656707456747474747456745674567456565674747474747456567074567474747474567456745674565656747474747474565670745674747474745674567456745656567474747474745656707456747474747456745674567456565674747474747456567074567474747474567456745674567;CP=7;O;
			name         => 'Clarus_Switch',
			id           => '62',
			one          => [3,-1],
			zero         => [1,-3],
			start        => [1,-35], # ca 30-40
			clockabs     => 189, 
			preamble     => 'i', # prepend to converted message
			clientmodule => 'IT', 
			#modulematch => '', 
			length_min   => '24',
			length_max   => '24',		
		},
	"63" => ## Warema MU
		{    #MU;P0=-2988;P1=1762;P2=-1781;P3=-902;P4=871;P5=6762;P6=5012;D=0121342434343434352434313434243521342134343436;
			name         => 'Warema',
			id           => '62',
			one          => [1],
			zero         => [0],
			clockabs     => 800, 
			syncabs		 => '6700',# Special field for filterMC function
			preamble     => 'u63', # prepend to converted message
			clientmodule => '', 
			#modulematch => '', 
			length_min   => '24',
			filterfunc   => 'SIGNALduino_filterMC',
		},

Sidey · 16 April 2017, 22:23:56

Hi Jörg,

den Fehler mit der Protokoll ID habe ich beseitigt. Das war ein copy & paste Fehler.

Zitat von: pejonp am 16 April 2017, 19:23:53
Ich habe jetzt festgestellt das die Hideki-Nachrichten nicht immer dekodiert werden. Vielleicht kannst du mir da helfen.

Code Auswählen Erweitern
2 Sensoren werden nicht erkannt: 2017.04.16 18:59:21 4: sduino/msg READ: MC;LL=-1053;LH=906;SL=-553;SH=416;D=39CD16BB0F82F1D5647AD;C=487;L=84;R=25; 2017.04.16 18:59:21 4: sduino: Found manchester Protocol id 12 clock 487 RSSI -61.5 -> Hideki protocol 2017.04.16 18:59:21 5: sduino: extracted data 110001100011001011101001010001001111000001111101000011100010101010011011100001010010 (bin) 2017.04.16 18:59:22 4: sduino/msg READ: MC;LL=-1057;LH=895;SL=-556;SH=418;D=345ADC3E0BC75590714;C=487;L=74;R=25; 2017.04.16 18:59:22 4: sduino: Found manchester Protocol id 12 clock 487 RSSI -61.5 -> Hideki protocol 2017.04.16 18:59:22 5: sduino: extracted data 1100101110100101001000111100000111110100001110001010101001101111100011101011 (bin)

Ich habe es mit einem rtl-sdr (rtl_433) verglichen. Dort werden die Sensor angezeigt. Ich habe die beiden Sensoren in ca. 1,5 m Abstand beim Signalduino zu stehen und diese werden nicht erkannt.

In dem Signal fehlt das 0x75 in umgedrehter Reihenfolge: 10101110

Jetzt stellt sich mir die Frage. Was genau wird im rtl-sdr angezeigt.
Hast Du Sensoren vom gleichen Hersteller oder von verschiedenen? Ich glaube es gibt verschiedene Hersteller die das Protokoll ein klein bisschen abgewandelt haben.
Ich habe die Ausgabe ein wenig erweitert, damit im log auch steht, was nicht geklappt hat.

Grüße Sidey

pejonp · 17 April 2017, 03:29:16

Hi Sidey,

ich habe 2x Bresser (5Ch Temp/Hum) und 1x Hama TC33 (3Ch Temp/Hum). Als Anlage mal die Datei hideki.c und bresser_3ch.c vom rtl-SDR. Vielleicht kannst du daran ja was sehen.
Der Log von FHEM und vom rtl_433 hänge ich auch dran, so wie er ist. Die Zeiten stimmen überein, da auf dem gleichen Gerät mitgelogt.

Jörg

Sidey · 17 April 2017, 10:04:12

Ich hab mal in die besser.c und Hideki.c rein gesehen.

Die besser.c spielt wohl keine Rolle, zumindest habe ich im log von dir dazu nichts gefunden.

In der Hideki.c ist mir aufgefallen, dass dort nicht auf 0x75 geprüft wird. Ich müsste mir das noch mal genauer ansehen, was da alles mit den Daten gemacht wird. Zumindest sieht es so aus, als ob der Sensor das Hideki Protokoll nicht exakt abbildet.

Ich habe mir das jetzt noch etwas näher angesehen. Es scheint sich hierbei tatsächlich nicht um das bereits implementierte Hideki Protokoll zu handeln.
So ganz schlau bin ich aber noch nicht.

Jedes 9. bit ist vermutlich ein Paritätsbit. Wir haben jedes 9. bit einfach ignoriert.
Eine Nachricht wird immer drei mal übertragen, ist aber nicht komplett identisch.
Den Anfang konnte ich noch nicht eindeutig erkennen
Die von uns implementierten hideki Sensoren, werden vom SDR_RTL auch als ts04 erkannt

Grüße Sidey

Gesendet von meinem Nexus 5 mit Tapatalk

Sebastian J · 19 April 2017, 11:37:20

Moin Moin,

betreibe seit kurzer Zeit einen Fhem Server auf einen RPI3 mit angebundenen FTDI und einen SIGNALduino_nanoCC1101.

Konnte erfolgreich die drei Wetterstationen meiner Nachbarn abzapfen und bin in der Lage meine Brennenstuhl Steckdosen über das Intertechno Protokoll zu steuern.
Wollte jetzt einen Schritt weiter gehen und meine Rolläden steuern. Habe fünf über Funk ansteuerbare Rolläden der Firma Acomax. Bei der Fernbedienung handelt es sich um eine CX-465 von Acomax die über 5 Kanäle verfügt.

Diese wollte ich nun im Fhem / Signalduino einlesen und dann die Rolläden steuern. Leider erkennt der Signalduino diese nicht. Die Fernbedienung sendet insgesammt 112 Bit plus den Sync.
Jedes Telegramm pro steuerbefehl wird 4-5mal (je nach Kanal) gesendet. Ich hatte gehofft das das Dooya Modul das Protokoll kennt und es damit klappt aber leider war dies nicht der Fall. Wenn ich es richtig gelesen habe verarbeitet dieses Modul um die 40Bit was in meinem Fall ja zu wenig ist.
Ich verfüge über ausreichende Kenntnisse in der Programmierung und würde von da her gerne mit dem Modul Betreuer in Kontakt treten um dieses ggf. zu erweitern bzw. eine neues anlegen.

Verfüge über sämtliche Telegramme und Timings welche über das Oszilloskope aufgenommen und händisch ausgewertet wurden. Timings etc. sind also vorhanden.

Aus Sichheitsgründen würde ich diese Informationen auch nur dierekt mit dem Betreuer austauschen.

Freue mich auf die Antworten oder Erkentnisse die vielleicht diesbezüglich schon gemacht wurden.

Falls ich hier falsch bin, möchte ich mich schon mal entschuldigen.

davidwohnthier · 19 April 2017, 11:57:50

Zitat von: Ralf9 am 09 April 2017, 19:08:01
Hat zufällig jemand der hier mitliest eine Home Easy Fernbedienung und einen Signalduino?
Falls ja, dann wäre es für uns hilfreich, wenn wir für on und off die dazugehörigen log Einträge mit verbose 4 bekommen könnten.

Hallo Ralf!
Bei der Suche nach den Codes für die HE308EU Fernbedienung bin ich auf einen Thread hier im Forum gestoßen in dem ein anderer User seine Logs zu der "Fernbedienung"/Wandtaster gepostet hat. Der Thread befindet sich hier: https://forum.fhem.de/index.php/topic,65833.msg570670.html#msg570670

Damit wir in diesem Thread weiterkommen zitiere ich mal den Threadersteller. Sollten wir eine Lösung für sein Porblem finden, werde ich ihm noch eine PN schreiben bzw. in seinem Thread antworten. Er nutzt statt einem signalDuino eine nanoCUL, dies sollte jedoch kein Hindernis sein?!

Zitat von: gerdshi am 27 Januar 2017, 13:01:05

Ich habe folgendes Problem:
Wenn ich den Selbstlernmodus an behalte, erkennt mein FHEM (per nanoCUL - a-culfw 1.23 build 05) den Sender nicht wenn ich die ON-Taste(n) drücke - egal wie oft. Weiter unten steht der Log dazu.
Wenn ich aber die OFF-Taste drücke wird sofort ein neues Device angelegt, allerdings fälschlicherweise erkennt FHEM das es sich angeblich um die ON-taste handelt die ich gedrückt habe, was definitiv nicht stimmt.
Das Ergebnis ist, dass FHEM zwar erkennt wenn ich die OFF-Taste drücke, als ON, aber nicht die richtige ON-Taste. Auch wenn ich per Hand über FHEM schalte, reagiert keines des bereits vorher angelernten IT-Steckdosen oder ein HE206 Dimmer.

Jetzt ist meine Frage was läuft da falsch bei der Erkennung und autom. Definition und wie kann ich den Fehler beheben so, dass einerseits FHEM richtig das betätigen der Sender-Tasten erkennt und andererseits man auch per FHEM die vorangelernte Geräte steuern kann? (Ohne das man RAW-Befehle Senden muss)

Hier Auszug aus meine Untersuchungen und Logs (erstmal nur für die eine Wippe - bei der zweiten ist es das gleiche Phänomen nur eben mit anderen IT-Code):

Das ist was FHEM selbst erkannt und zugeordnet hat - fälschlicherweise als Taste ON (in wirklichkeit aber OFF)
Code Auswählen Erweitern
2017.01.25 16:43:25 2: CUL_0 IT: 11000111100101111010101100110100110111010011011100101 not defined (Address: 1100011110010111101010110011010011011101001101 Unit: 1100101 Switch code: 11 GroupCode: 0) 2017.01.25 16:43:25 2: autocreate: define IT_11000111100101111010101100110100110111010011011100101 IT 1100011110010111101010110011010011011101001101 0 1100101 2017.01.25 16:43:25 2: autocreate: define FileLog_IT_11000111100101111010101100110100110111010011011100101 FileLog ./log/IT_11000111100101111010101100110100110111010011011100101-%Y.log IT_11000111100101111010101100110100110111010011011100101 2017.01.25 16:43:30 3: CUL_0 IT: Code 11 not supported by IT_11000111100101111010101100110100110111010011011100101. 2017.01.25 16:43:30 3: CUL_0 IT: Code 11 not supported by IT_11000111100101111010101100110100110111010011011100101.

So sieht es dann im fhem.cfg aus:
Code Auswählen Erweitern
define IT_11000111100101111010101100110100110111010011011100011 IT 1100011110010111101010110011010011011101001101 0 1100011 attr IT_11000111100101111010101100110100110111010011011100011 IODev CUL_0 attr IT_11000111100101111010101100110100110111010011011100011 room IT

Wenn die autom Erkennung aus ist, werden folgende Codes erkannt (wobei die letzten 2-Stellen ändern sich bei jedem Tastendruck):
Code Auswählen Erweitern
2017.01.25 16:13:29 3: CUL_0: Unknown code ihc797ab34dd36b2801d, help me! (Für die Taste OFF) 2017.01.25 16:13:30 3: CUL_0: Unknown code ihc797ab34dd3732801b, help me! (Für die Taste ON)

Wobei der Code für ON wird auch nach der Erkennung genau so weiter gemeldet, da FHEM nicht erkennt das er zu dem autom. angelegte Device gehört. Warum auch immer?

Die Beiden Codes ergeben folgendes Bitmuster, wenn ich mich nicht irre:
Code Auswählen Erweitern
1100011110010111101010110011010011011101001101110011 - c797ab34dd373 1100011110010111101010110011010011011101001101101011 - c797ab34dd36b

Allerdings komme ich mit dem Bitmuster nicht weiter bzw. was kann ich in FHEM ändern, damit der Fehler behoben wird?

Zur Zeit damit die Tasten von FHEM richtig erkannt und dargestellt werden, bediene ich mich der Krücke:
Code Auswählen Erweitern
define SZ_Lampe dummy attr SZ_Lampe icon light_pendant_light_round attr SZ_Lampe room IT attr SZ_Lampe webCmd On:Off define he1_on notify CUL_0:UNKNOWNCODE\sihc797ab34dd373280.* set SZ_Lampe on define he1_off notify CUL_0:UNKNOWNCODE\sihc797ab34dd36b280.* set SZ_Lampe off

Allerdings schaffe ich es ums verrecken nicht selbst den richtigen RAW-Befehl zu senden, damit die vorgelernte Geräte reagieren.

Daher meine Bitte um Hilfe wie kann ich den Sender ordentlich manuell oder automatisch anlegen?
Wenn es nicht möglich ist, wie kann ich bzw. was soll ich genau als RAW-Befehl senden, damit es von eine vorgelernte Steckdose angenommen wird?
Wieso eigentlich hat FHEM ein Device angelegt nach dem Muster 46+1+7? Nirgendwo finde ich in der Doku so eine Definition von Geräten?
Hat es etwas mit dem HE_EU Protokoll zu tun?

Danke Euch vielmals!

andies · 19 April 2017, 15:40:32

Zitat von: Sebastian J am 19 April 2017, 11:37:20
Wollte jetzt einen Schritt weiter gehen und meine Rolläden steuern.

Haben die Rolling Code? Sonst kannst Du, bis das umgesetzt ist, ja mit raw-send ansteuern.

Sebastian J · 19 April 2017, 16:32:34

ZitatHaben die Rolling Code? Sonst kannst Du, bis das umgesetzt ist, ja mit raw-send ansteuern.

Rolling Code haben die denke ich mal nicht, was aber manchmal passiert ist das beim letzten byte 3 verschiedene werte stehen.

BSP: CH1 Runter 7 Telegramme in Folge das letzte Byte variiert:

00011100
00011100
00011100
00100101
00100110
00100110
00100110

Es variiert aber immer gleich.
Denke das die Fernbedienung einfach verschiedene Arten der Checksummenberechnung hat ? ! ?

Das wäre halt mit nem Spezialisten zu klären.

Das vermutete Komando Hoch , Runter, Stop ist in allen Telegrammen Konstant.

Die vermutete Kanalnummer ebenfalls.

Die vermutete ID der Fernbeding ist ebendfalls konstant.

Kann man beim raw-send die Timings und wiederholungen mit angeben ?

andies · 19 April 2017, 16:48:31

Zitat von: Sebastian J am 19 April 2017, 16:32:34
Kann man beim raw-send die Timings und wiederholungen mit angeben ?

Ja, das geht. Details stehen hier https://wiki.fhem.de/wiki/SIGNALduino#Der_Logfile und der nachfolgende Abschnitt https://wiki.fhem.de/wiki/SIGNALduino#Senden_mit_dem_SIGNALduino
und wenn das nicht nachvollziehbar ist, melde Dich mal warum - ich will nämlich (aus eigener Erfahrung) dieser Wikieinträge stärken, damit mehr Leute FHEM nutzen. Das ist so ein wenig stiefmütterlich, weil es eben auch eine Menge Arbeit macht.

Sebastian J · 19 April 2017, 23:29:46

Das Problem ist gelöst.
Durch spielen mit dem P2 knopf an der Fernbedienung auf verschiedenen Kanälen erzeugte das Autocreate Modul zufällig bei CH4 einen Dooya ROOM

Musste kurz verstehen was ich da sehe und habe die übrigen Kanäle dann mit der Hand angelegt.
Klappt fast perfekt. Fast nur weil ich durch ein Missgeschick CH5 gelöscht habe und jetzt das große nicht mehr fährt.

Muss ich wohl morgen neu anlernen.

Rollo 1 scheint auch noch einen abgekriegt zu haben, bewegt sich jetzt wenn ich über Fhem Channel 5 bewege. Obwohl der Channel 5 das Richtige Bitmuster für Channel 5 sendet.
Am Handsender funktioniert CH1 wie gewohnt. (BUG?)

Danke @andies für deine Hinweise!

Bericht fürs Wiki folgt.