Die Wiederholungen von MS Nachrichten sollen überprüft werden.

`2017.01.27 14:32:27 4: SD433/msg READ: �MS;P7=-32001;D=777777777777777777777777777777777;CP=-1;SP=3;R=6;�
2017.01.27 14:32:27 4: SD433/msg READ: �MS;P7=-32001;D=77777777777777777777777777777777775;CP=-1;SP=3;R=6;�
2017.01.27 14:32:27 4: SD433/msg READ: �MS;P7=-32001;D=77777777777777777777777777777777777;CP=-1;SP=3;R=6;�
2017.01.27 14:32:27 4: SD433/msg READ: �MS;P7=-32001;D=7777777777777777777777777777777777775;CP=-1;SP=3;R=6;�
2017.01.27 14:32:27 4: SD433/msg READ: �MS;P7=-32001;D=7777777777777777777777777777777777777;CP=-1;SP=3;R=6;�
2017.01.27 14:32:27 4: SD433/msg READ: �MS;P7=-32001;D=777777777777777777777777777777777777775;CP=-1;SP=3;R=6;�
2017.01.27 14:32:27 4: SD433/msg READ: �MS;P7=-32001;D=777777777777777777777777777777777777777;CP=-1;SP=3;R=6;�
2017.01.27 14:32:27 4: SD433/msg READ: �MS;P7=-32001;D=77777777777777777777777777777777777777775;CP=-1;SP=3;R=6;�
2017.01.27 14:32:27 4: SD433/msg READ: �MS;P7=-32001;D=77777777777777777777777777777777777777777;CP=-1;SP=3;R=6;�
2017.01.27 14:32:27 4: SD433/msg READ: �MS;P7=-32001;D=7777777777777777777777777777777777777777775;CP=-1;SP=3;R=6;�
2017.01.27 14:32:28 4: SD433/msg READ: �MS;P7=-32001;D=7777777777777777777777777777777777777777777;CP=-1;SP=3;R=6;�
2017.01.27 14:32:28 4: SD433/msg READ: �MS;P7=-32001;D=777777777777777777777777777777777777777777775;CP=-1;SP=3;R=6;�

2017.01.27 14:32:46 4: SD433/msg READ: �MS;P0=-499;P4=-32001;D=0000000000000000000000000000000000000004444444444;CP=-1;SP=3;R=51;�
2017.01.27 14:32:46 4: SD433/msg READ: �MS;P0=-499;P4=-32001;D=000000000000000000000000000000000000000444444444442;CP=-1;SP=3;R=51;�
2017.01.27 14:32:46 4: SD433/msg READ: �MS;P0=-499;P4=-32001;D=000000000000000000000000000000000000000444444444444;CP=-1;SP=3;R=51;�
2017.01.27 14:32:46 4: SD433/msg READ: �MS;P0=-499;P4=-32001;D=00000000000000000000000000000000000000044444444444441;CP=-1;SP=3;R=51;�
`

-> cronjob adds -32001 to fifo
SignalDetectorClass::doDetect should check for different sign, there is a bug

Das Protokoll ist entschlüsselt und es gibt schon Eigenbaulösungen. Siehe hier:
http://www.mikrocontroller.net/topic/242784?goto=3962231#3962231

In Github existiert bereits ein Implementierung (aber nicht für Fhem):
https://github.com/bjwelker/Raspi-Rollo

Das ist auch ein gute Quelle
http://physudo.blogspot.de/2013/08/home-automation-mit-dem-arduino-und-433_17.html
http://physudo.blogspot.de/2013/08/home-automation-mit-dem-arduino-und-433_18.html

Signal sent:
SR;R=6;P0=5000;P1=-1640;P2=320;P3=-800;P4=700;P5=-400;D=0123232345454523232345232323232323232345234545232323454523234523452323234523232345;

Received debug:
Sync: 16025 -> SyncFact: 54.51, Clock: 294, Tol: 150, PattLen: 6 , Pulse: -32001, 136, mStart: 0
Signal: 010102323231010102310101010101010102310232310101023231010231023101010231010102345101. [85]
Pattern: P0: 28_[,-798] P1: 28_[,294] P2: 13_[,682] P3: 13_[,-402] P4: 1_[,4968] P5: 1_[,-1648]
-- chk MC -- 0 1 2 3 4 5 equalcnt: 0 MC equalcnt matched MC neg and pos pattern cnt is equal tstclock: 325 MC LL:0, MC LH:2, MC SL:3, MC SH:1
-- MC found --
mlen: 84 mstart: 0L mlen 1 RES L mlen 2 RES L mlen 2 RES LL mlen 3 RES LL mlen 3 RES L mlen 2 RES L mlen 2 RES L mlen 2 RES LSSL mlen 4 RES LSSL mlen 4 RES SSL mlen 3 RES L mlen 2 RES L mlen 2 RES L mlen 2 RES L mlen 2 RES LLSSL mlen 5 RES LLSSL mlen 5 RES LSSL mlen 4 RES SSL mlen 3 RES L mlen 2 RES L mlen 2 RES L mlen 2 RES L mlen 2 RES L mlen 2 RES L mlen 2 RES L mlen 2 RES L mlen 2 RES L mlen 2 RES L mlen 2 RES L mlen 2 RES L mlen 2 RES L mlen 2 RES L mlen 2 RES LLSSLL mlen 6 RES LLSSLL mlen 6 RES LSSLL mlen 5 RES SSLL mlen 4 RES LL mlen 3 RES LL mlen 3 RES L mlen 2 RES LSSL mlen 4 RES LSSL mlen 4 RES SSL mlen 3 RES L mlen 2 RES L mlen 2 RES L mlen 2 RES L mlen 2 RES LL mlen 3 RES LL mlen 3 RES L mlen 2 RES LSSL mlen 4 RES LSSL mlen 4 RES SSL mlen 3 RES L mlen 2 RES L mlen 2 RES LLSSLLSSL mlen 8 RES LLSSLLSSL mlen 8 RES LSSLLSSL mlen 7 RES SSLLSSL mlen 6 RES LLSSL mlen 5 RES LLSSL mlen 5 RES LSSL mlen 4 RES SSL mlen 3 RES L mlen 2 RES L mlen 2 RES L mlen 2 RES L mlen 2 RES LLSSL mlen 5 RES LLSSL mlen 5 RES LSSL mlen 4 RES SSL mlen 3 RES L mlen 2 RES L mlen 2 RES L mlen 2 RES L mlen 2 RES LL mlen 3 RES LL mlen 3 RES L mlen 2 RES mlen 1 RES L mlen 2 RES mlen: 84 mstart: 81Message truncated�MU;P0=-798;P1=294;P2=682;P3=-402;P4=4968;P5=-1648;D=101;CP=1;�

error is located in ManchesterpatternDecoder::doDecode()
pdec-start is not resetted when a reset occures. This example is a wrong MC detection

Fernbedieung mit LP801B (ist wie PT2262):

Ausgabe mit Debug Detect:

D sync: 188, -5804, TOL: 94, sFACT: -30.87
Sync: -5804 -> SyncFact: -30.87, Clock: 188, Tol: 94, PattLen: 1 , Pulse: 572, -180
MSG: 0. [1]
Pattern: P0:572, -180, Pclock0:3.04, -0.96,
PD sync: 188, -5800, TOL: 94, sFACT: -30.85
PD sync: 200, -5792, TOL: 100, sFACT: -28.96
PD sync: 192, -5788, TOL: 96, sFACT: -30.15

Conrad RSL Protokoll:

SyncBit: 1xHIGH 10xLOW
1: 2xHIGH 1xLOW
0: 1xHIGH 2xLOW
Clock: 650

Für welche Geäte das alles gilt ist mir nicht bekannt.
Quelle: http://www.mikrocontroller.net/topic/252895

Ich habe in der doDetect() einige Verbesserungen vorgenommen. Die gleichen patterrnNr in Folge im message Puffer sind jetzt weg.

Damit waren die meisten gleichen patterrnNr in Folge weg.

Es blieben aber noch einige gleiche patterrnNr in Folge übrig, die schwer zu finden waren.
Damit wurde der last pulse mit dem aktuellen first überschrieben. Der Fehler in der calcHisto Routine konnte sich da auch ausgewirkt haben

			for (uint8_t i = messageLen - 1; i >= 0 && histo[pattern_pos] > 0; --i)
			{
				if (message[i] == pattern_pos) // Finde den letzten Verweis im Array auf den Index der gleich ueberschrieben wird
				{
					i++; // i um eins erhoehen, damit zukuenftigen Berechnungen darauf aufbauen koennen
					bufferMove(i);
					break;
				}

			}

Ich habe die Routine abgeändert. Nun wird zuerst ein compress_pattern versucht, falls kein compress möglich war, entferne ich Zeichen am Anfang des message Puffers:

					uint8_t idx;
					for (uint8_t i = 0; i<messageLen; i++)
					{
						idx = message[i];
						if (histo[idx] == 1)
						{
							pattern[idx] = 0;
							bufferMove(i+1);
							pattern_pos = idx;
							break;
						}
						else
						{
							histo[idx]--;
						}
					}

Diese Routine gefällt mir noch nicht so richtig:
Damit wird processMessage() auch aufgerufen, wenn die mindest messageLen noch nicht erreicht wurde. Wenn beim Aufruf von processMessage() das "m_truncated = false" ist, dann wird in der processMessage() ein reset() durchgeführt!

		// Add pattern
		if (patternLen == maxNumPattern)
		{
			calcHisto();
			if (histo[pattern_pos] > 2)
			{
				processMessage();
				calcHisto();

Beim IT TX3 lacross Signal scheint es keinen Sync zu geben.
Daher kann das Signal vom detector derzeit nicht erkannt werden.

Des weitern wird im doDetect nach[1,-n] oder [n, -1]) gesucht.
Der Low Anteil von ~ 1000 us scheint bei diesem Signal konstant als Trenner zwischen den Bits eingesetzt, die High Pulslängen entsprechen 500 oder 1300. Die Clock könnte ~250 us betragen, das würde zu allen gefunden Pulsen in etwa passen, den daraus reultierenden Clock Faktor habe ich in gerundet angegeben.

Idee

• Eine Erkennung unabhängig vom Sync Signal
• Eine Berechnung der Clock ohne Sync. Dies könnte ähnlich wie bei Manchester aus den Pulslängen geschehen. Größter gemeinsamer Teiler von zwei Pulsen wäre die Clock.

Das Pattern sieht aber grundsätzlich kompatibel aus.
Onebit = 500 us high Puls (fact 2)
zeroBit =1250us high Puls (fact 5)
Dazwischen kommen 1000us low pulse (fact 4)

1252, -1020 --> 0
1264, -1004, --> 0
1252, -1004, --> 0
1260, -1024, --> 0
472, -1020, --> 1
1252, -1024, --> 0
464, -1036, --> 1
1236, -1032, --> 0
1228, -1040, --> 0
1228, -1028, --> 0
1244, -1024, -->0
1236, -1040, -->0
460, -1044, -->1
...
Debug Ausgaben von Jörg, mit leicht abweichender Dauer:
TXA089561562
TimingsIT_TX: 1360 860 1336 876 1320 892 1312 904 564 900 1300 912 548 920 1292 916 1288 920 1284 928
DataBitsIT_TX: 00001010000010001001010101100001010101100010

TXA089561562
TimingsIT_TX: 1372 848 1348 868 1316 896 1316 908 548 904 1304 908 548 916 1292 916 1292 920 1288 924
DataBitsIT_TX: 00001010000010001001010101100001010101100010

TXA089557556
TimingsIT_TX: 1364 856 1340 884 1300 904 1300 916 552 900 1296 924 544 912 1300 908 1284 928 1284 936
DataBitsIT_TX: 00001010000010001001010101010111010101010110

Debug Ausgaben aus dem ITTX Spezialsketch. Eine komplette Nachricht. In Fett die Pulse, welche zum Signal (start bis Ende passen. In Fett noch zwei interessante Pulsdauern. Ggf hängt ein Teil der Nachricht am Anfang. bin mir da nicht ganz sicher.

2015.01.07 22:50:07 4: CUL_TX: TXA082527529
2015.01.07 22:50:07 2: FHEMduino: unknown message -1036, 1216, -1040, 472, -1024, 1236, -1052, 460, -1024, 1232, -1040, 1252, -1008, 480, -1020, 1236, -1032, 468, -1032, 1232, -1040, 1236, -1040, 452,-12264, -3176, -116, -12072, 1276 -996, 1256, -1020, 1244, -1016, 1248, -1024, 480, -1024, 1240, -1028, 472, -1028, 1240, -1012, 1248, -1036, 1232, -1032, 1240, -1024, 1232, -1044, 464, -1020, 1240, -1032, 1236, -1048, 1220, -1036, 1232, -1040, 1228, -1028, 468, -1040, 1228, -1032, 1232, -1040, 460, -1040, 1228, -1044, 464, -1028, 1240, -1020, 1240, -1040, 464, -1036, 1224, -1044, 1232, -1032, 468, -1032, 468, -1020, 484, -1024, 1236, -1032, 476, -1028, 1228, -1040, 468, -1028, 1232, -1044, 1224, -1032, 472, -1028, 1232, -1036, 476, -1028, 1232, -1040, 1224, -1040, 464, ) message length (730)

Weitere Nachrichten:
2015-01-07_23:08:14 FHEMduino UNKNOWNCODE -1252, -2928, -1656, -5588, -1152, -100, -1176, -2644, -2092, -380, -3684, -288, -1356, -2704, -580, -5572, -5864, -5676, -464, -664, -2480, -152, -4284, -2572, -444, -1932, -7996, 244, -1312, -376, 1276, -992, 1256, -1012, 1248, -1024, 1240, -1024, 476, -1020, 1244, -1044, 460, -1028, 1232, -1028, 1240, -1028, 1240, -1032, 1232, -1036, 1232, -1040, 464, -1032, 1240, -1024, 1232, -1048, 1224, -1032, 1236, -1028, 1224, -1040, 468, -1032, 472, -1036, 1220, -1044, 472, -1028, 1236, -1032, 472, -1032, 1228, -1044, 1220, -1040, 468, -1036, 1224, -1044, 1224, -1032, 472, -1032, 476, -1028, 1228, -1044, 1228, -1032, 468, -1020, 1236, -1048, 460, -1032, 1232, -1036, 1232, -1044, 460, -1032, 1232, -1036, 468, -1028, 1240, -1028, 1232, ) message length (737)

2015-01-07_23:11:04 FHEMduino UNKNOWNCODE -1012, -3556, -2364, 152, -108, -1448, -5604, -3944, 188, -3304, -768, -1212, -2156, -568, -636, -460, -704, 100, -496, -1324, -1052, 112, -5852, -1484, -716, -300, -2692, -380, 1264, -1012, 1260, -1004, 1256, -1016, 1240, -1032, 468, -1020, 1252, -1020, 488, -1024, 1232, -1032, 1236, -1020, 1236, -1036, 1236, -1036, 1228, -1040, 460, -1028, 1240, -1036, 1232, -1032, 1228, -1040, 1232, -1044, 1220, -1040, 460, -1032, 472, -1036, 1224, -1040, 464, -1044, 1224, -1036, 468, -1048, 1212, -1040, 1224, -1032, 476, -1036, 1232, -1024, 1236, -1044, 456, -1052, 460, -1036, 1228, -1044, 1220, -1040, 460, -1036, 1240, -1024, 468, -1032, 1248, -1024, 1232, -1028, 476, -1028, 1232, -1032, 476, -1036, 1224, -1048, 1216, -1040, 468, ) message length (729)

2015-01-07_23:12:57 FHEMduino UNKNOWNCODE -1028, 1240, -1032, 460, -1044, 1232, -1028, 1240, -1040, 456, -1048, 1224, -1028, 468, -1032, 1236, -1032, 1236, -1032, 472, -5796, -10296, -1992, -2724, -1320, -820, -3104, 480, 1260, -1016, 1248, -1004, 1248, -1048, 1224, -1024, 480, -1036, 1228, 472, 472, -1024, 1244, -1044, 1228, -1028, 1220, -1040, 1236, -1036, 1224, -1036, -1040, 472, -1032, 1236, -1032, 472, -1024, 1240, -1032, 488, -1016, 1224, -1048, 1220, -1060, 448, -1024, 1232, -1052, 1216, -1040, 464, -1032, 476, -1036, 1224, -1044, 1224, -1036, 460, -1032, 1240, -1040, 468, -1028, 1228, -1048, 1216, -1040, 476, -1020, 1248, -1028, 464, -1028, 1228, -1048, 1224, -1036, 468, 1232, -1036, 464, -1040, 1224, -1036, 464, -1040, 1232, -1036, 1224, -1044, 456, ) message length (728)

Fazit: Scheinbar kein Sync oder <100 mikosekunden

m_truncated wird nicht immer getzt und kann den Status von einem vorhergehenden processMessage() haben

Die Klasse patternDetector sollte auf PatternBasic basieren und umbenannt werden in patternDetectPP , da es auf Puls-Pause Signale ausgelegt ist und andere Signaltypen eher nicht erkennt.

Hallo,
wisst Ihr wer an diesem Typ arbeitet?
Seit einem Update erhalte ich nun laufende "Phantasie-Sensoren" die absolut nicht plausibel sind.
Da ich im Forum keinen "Direkten" fand, wer dies unter seinen Fittichen hat, so frage ich erstmal hier an, da ich ja die SIGNALDuino FW nutze.

Aufgefallen ist mir das ganze, da ein Sensor welchen ich schon seit längerem empfange mit plausiblen Werten, das dieser als erstes "Fehlausschläge" brachte an Werten und nun werden diverse Sensoren eben von dem selbigen Typ noch zusätzlich angelegt.

SD_WS_33_TH_1 | T: 15.0555555555556 H: 79 -- | --
2017-08-20_08:46:18 SD_WS_33_TH_1 T: 15.0555555555556 H: 79
2017-08-20_08:46:18 SD_WS_33_TH_1 temperature: 15.0555555555556
2017-08-20_08:46:18 SD_WS_33_TH_1 humidity: 79
2017-08-20_08:46:18 SD_WS_33_TH_1 battery: critical
2017-08-20_08:46:18 SD_WS_33_TH_1 channel: 1
2017-08-20_08:46:18 SD_WS_33_TH_1 DMSG: W33#33A0F57D12C
2017-08-20_08:46:18 SD_WS_33_TH_1 RAWMSG: MS;P1=427;P2=-4100;P3=-2086;P4=-8057;D=14131312121313121212131213131313131212121213121312131212121212131213131312131312131212;CP=1;SP=4;R=210;m=2;
2017-08-20_08:46:18 SD_WS_33_TH_1 RSSI: -97
2017-08-20_08:46:18 SD_WS_33_TH_1 absFeuchte: 10.2
2017-08-20_08:46:18 SD_WS_33_TH_1 dewpoint: 11.4

SD_WS_51_TH_12 | T: 106.9 H: 40 -- | --
2017-08-20_08:51:09 SD_WS_51_TH_12 T: 106.9 H: 40
2017-08-20_08:51:09 SD_WS_51_TH_12 temperature: 106.9
2017-08-20_08:51:09 SD_WS_51_TH_12 humidity: 40
2017-08-20_08:51:09 SD_WS_51_TH_12 battery: ok
2017-08-20_08:51:09 SD_WS_51_TH_12 channel: 12
2017-08-20_08:51:09 SD_WS_51_TH_12 trend: rising
2017-08-20_08:51:09 SD_WS_51_TH_12 DMSG: W51#A980C483AC
2017-08-20_08:51:09 SD_WS_51_TH_12 RSSI: -91
2017-08-20_08:51:09 SD_WS_51_TH_12 RAWMSG: MS;P1=542;P2=-9076;P3=-4097;P4=-2061;P6=136;D=1213141314131414131314141414141414131314141413141413141414141413131314131413136314;CP=1;SP=2;R=222;
2017-08-20_08:51:09 SD_WS_51_TH_12 absFeuchte: 297.3
2017-08-20_08:51:09 SD_WS_51_TH_12 dewpoint: 82.3

SD_WS_51_TH_8 | T: 105.1 H: 60 -- | --
2017-08-20_10:13:38 SD_WS_51_TH_8 T: 105.1 H: 60
2017-08-20_10:13:38 SD_WS_51_TH_8 temperature: 105.1
2017-08-20_10:13:38 SD_WS_51_TH_8 humidity: 60
2017-08-20_10:13:38 SD_WS_51_TH_8 battery: ok
2017-08-20_10:13:38 SD_WS_51_TH_8 channel: 8
2017-08-20_10:13:38 SD_WS_51_TH_8 trend: rising
2017-08-20_10:13:38 SD_WS_51_TH_8 RAWMSG: MS;P0=-740;P1=548;P2=-8895;P3=-4095;P4=-2072;P5=-1488;P7=1428;D=1213141314131414131314141414141414131314141414131413141414141314131314131413152170012;CP=1;SP=2;R=229;
2017-08-20_10:13:38 SD_WS_51_TH_8 RSSI: -87.5
2017-08-20_10:13:38 SD_WS_51_TH_8 DMSG: W51#A980C285A8
2017-08-20_10:13:38 SD_WS_51_TH_8 absFeuchte: 420.9
2017-08-20_10:13:38 SD_WS_51_TH_8 dewpoint: 91.1

SD_WS_WH2_0 | T: 150.8 H: 83 -- | --
2017-08-20_00:57:12 SD_WS_WH2_0 T: 150.8 H: 83
2017-08-20_00:57:12 SD_WS_WH2_0 temperature: 150.8
2017-08-20_00:57:12 SD_WS_WH2_0 humidity: 83
2017-08-20_00:57:12 SD_WS_WH2_0 battery: 0
2017-08-20_00:57:12 SD_WS_WH2_0 channel: 0
2017-08-20_00:57:12 SD_WS_WH2_0 RSSI: -94.5
2017-08-20_00:57:12 SD_WS_WH2_0 RAWMSG: MU;P0=-32001;P1=1382;P2=-1441;P3=258;D=0121212123212123212121212323232323232123212321232323232121232121212321232121232323212323232123212321212;CP=3;R=215;
2017-08-20_00:57:12 SD_WS_WH2_0 DMSG: W64#090FD5E453BA8
2017-08-20_00:57:12 SD_WS_WH2_0 absFeuchte: 2126.6
2017-08-20_00:57:12 SD_WS_WH2_0 dewpoint: 144.1

Die angelegten Sensoren haben im Logfile auch mehrere Werte und werden somit mehrfach "falsch registriert".

MfG

Hi everyone,
I m not sure, if this is the right way to ask for code explanation.
Could somebody explain the following Code from SIGNALduino?
[code#define portOfPin(P)
(((P)>=0&&(P)<8)?&PORTD:(((P)>7&&(P)<14)?&PORTB:&PORTC))

define ddrOfPin(P)\

(((P)>=0&&(P)<8)?&DDRD:(((P)>7&&(P)<14)?&DDRB:&DDRC))

define pinOfPin(P)\

(((P)>=0&&(P)<8)?&PIND:(((P)>7&&(P)<14)?&PINB:&PINC))

define pinIndex(P)((uint8_t)(P>13?P-14:P&7))

define pinMask(P)((uint8_t)(1<<pinIndex(P)))

define pinAsInput(P) *(ddrOfPin(P))&=~pinMask(P)

define pinAsInputPullUp(P) *(ddrOfPin(P))&=~pinMask(P);digitalHigh(P)

define pinAsOutput(P) *(ddrOfPin(P))|=pinMask(P)

define digitalLow(P) *(portOfPin(P))&=~pinMask(P)

define digitalHigh(P) *(portOfPin(P))|=pinMask(P)

define isHigh(P)((*(pinOfPin(P))& pinMask(P))>0)

define isLow(P)((*(pinOfPin(P))& pinMask(P))==0)

define digitalState(P)((uint8_t)isHigh(P))[/code]

I would like to port that to another device.

Hallo,
kannst du Dir das erklären @sidey79?
Ich bin bei einer Fehlersuche an die Rohdaten gegangen via Putty um erstmal einiges zu kontrollieren.
(FHEM Schnittstelle ist geschlossen)
Dabei fiel mir auf, das ich bei der dev170310 eine klare leserliche Ausgabe erhalte. Bei sämtlichen Versionen danach, bis zur devmc170822 sind die MS und MU Ausgaben mit Steuerzeichen "verstümmelt".

DEV170310

============ PuTTY log 2017.08.25 09:41:40 ============
Reading values fom eeprom
CCVersion=20
CCPartnum=0
CC1101 found
Starting timerjob
receiver enabled
�MS;P1=-4052;P2=487;P3=-9077;P4=-2014;D=23212124212424242124212124212124242421212424242424242424242424242421242421;CP=2;SP=3;R=73;O;�
�MS;P0=474;P1=-2025;P2=-4049;P3=-9074;D=03020201020101010201020201020201010102020101010101010101010101010102010102;CP=0;SP=3;R=71;O;�
�MS;P0=476;P1=-2019;P2=-4061;P3=-9080;D=03020201020101010201020201020201010102020101010101010101010101010102010102;CP=0;SP=3;R=71;�
�MS;P1=-4048;P2=475;P3=-9075;P4=-2021;D=23212124212424242124212124212124242421212424242424242424242424242421242421;CP=2;SP=3;R=71;O;�
�MS;P0=476;P1=-2022;P2=-4062;P3=-9065;D=03020201020101010201020201020201010102020101010101010101010101010102010102;CP=0;SP=3;R=71;O;�
�MS;P0=468;P1=-2022;P2=-4054;P3=-9082;D=03020201020101010201020201020201010102020101010101010101010101010102010102;CP=0;SP=3;R=72;�

DEV170615

============ PuTTY log 2017.08.25 09:36:31 ============
Reading values fom eeprom
CCInit SRES Started
POR Done
CCVersion=20
CCPartnum=0
CC1101 found
Starting timerjob
CC1100_PKTCTRL0=50 vs EEPROM PKTCTRL0=50
C1100_IOCFG2=13 vs EEPROM IOCFG2=13
receiver enabled
�Ms;±Ý�;’Ú�;£ë£;´ë‡;D#!!$!$$$!$!!$!!$$$!!$$$$$$$$$$$$$!$$!;C2;S3;R49;O;m2;�
�Ms;±Ð�;’é�;£ë£;´Ú‡;D#!!$!$$$!$!!$!!$$$!!$$$$$$$$$$$$$!$$!;C2;S3;R49;O;m1;�
�Ms;±Ó�;’Ý�;£í£;´ì‡;D#!!$!$$$!$!!$!!$$$!!$$$$$$$$$$$$$!$$!;C2;S3;R49;O;m0;�
�Ms;±Ø�;’Ü�;£â£;´ä‡;D#!!$!$$$!$!!$!!$$$!!$$$$$$$$$$$$$!$$!;C2;S3;R49;O;�
�Mu;�ß�;±ã‡;²Í�;£ö£;D�����������������������������������������������������������@;C0;R49;�
�Ms;±Õ�;’â�;£þ£;´é‡;D#!!$!$$$!$!!$!!$$$!!$$$$$$$$$$$$$!$$!;C2;S3;R49;O;m2;�
�Ms;±×�;’Ò�;³�£;´ñ‡;D#!!$!$$$!$!!$!!$$$!!$$$$$$$$$$$$$!$$!;C2;S3;R49;O;m1;�
�Ms;±×�;’Ü�;£ö£;´å‡;D#!!$!$$$!$!!$!!$$$!!$$$$$$$$$$$$$!$$!;C2;S3;R49;O;m0;�
�Ms;±Ö�;’ß�;£ó£;´ß‡;D#!!$!$$$!$!!$!!$$$!!$$$$$$$$$$$$$!$$!;C2;S3;R49;O;�
�Mu;�Ò�;±ã‡;²Ú�;£ø£;D�����������������������������������������������������������@;C0;R48;�
�Mu;€’‚;±¿€;’ø€;³À�;„�ý;•­€;d����5��DDDDDDDDDDDDD;C4;R48;�

DEV170822

============ PuTTY log 2017.08.25 10:21:03 ============
Reading values fom eeprom
CCInit SRES Started
POR Done
CCVersion=20
CCPartnum=0
CC1101 found
Starting timerjob
CC1100_PKTCTRL0=50 vs EEPROM PKTCTRL0=50
C1100_IOCFG2=13 vs EEPROM IOCFG2=13
receiver enabled
�Ms;°ñ‡;‘Ö�;£ÿ£;´Ù�;d�1�������A�AA�AA��A���������������A��A;C1;S3;R45;O;m2;�
�Ms;°î‡;‘Ï�;³ƒ£;´Û�;D������������������������������������;C1;S3;R45;O;m1;�
�Ms;°ï‡;‘Ó�;³ƒ£;´á�;D������������������������������������;C1;S3;R45;O;m0;�
�Ms;°î‡;‘Ð�;³�£;´Û�;D������������������������������������;C1;S3;R45;O;�
�Mu;�Ð�;±é‡;²á�;³„£;D�����������������������������������������������������������@;C0;R47;�
�Ms;‘Ù�;²î‡;¤ï£;µÔ�;d!A!!!!!!!Q!QQ!QQ!!Q!!!!!!!!!!!!!!!Q!!Q;C1;S4;R44;O;m2;�
�Ms;‘Î�;²î‡;¤÷£;µç�;D�������������������������������������;C1;S4;R44;O;m1;�
�Ms;‘Ó�;²ï‡;¤û£;µâ�;D�������������������������������������;C1;S4;R44;O;m0;�
�Ms;‘Ñ�;²ó‡;¤ÿ£;µÝ�;D�������������������������������������;C1;S4;R44;O;�
�Mu;�Ô�;±ó‡;²Û�;£è£;D�����������������������������������������������������������@;C0;R45;�

In FHEM werden die Daten aber leserlich angezeigt und ggf. verarbeitet.

Ich habe es mit einem Arduino NANO + CC1101_433 bzw. CC1101_868 getestet.
Einstellungen in Putty wurden nicht geändert bzw. diese wurden auch mehrmals verglichen.
Der einzige Unterschied ist wirklich nur die Firmware. Ältere drauf = lesbar, neuere Drauf, nicht lesbar. Vorfall ist reproduzierbar.

Es wäre schön, wenn wir darauf eine Antwort finden und man die Daten wieder leserlich entnehmen könnte.

MfG

Von FHEM wird ein X00 an den Arduino gesendet.

Dies soll den Empfänger ausschalten.

Hallo,

Hier ist eine neue Version meines test sketches mit den Routinen für den CC1101.
Ich habe inzwischen auch die set- und get Befehle für den CC1101 aus dem 00_cul.pm in die 00_SIGNALduino.pm übernommen.
Wenn es ok ist, werde ich die angepasste 00_SIGNALduino.pm morgen commiten

Gruß Ralf

Example:
MU;P0=214;P1=-492;P2=446;P3=-256;P4=-8255;D=012101010101010321010401010321010101010103210104010103210101010101032101040101032101010101010321010401010321010101010103210104010103210101010101032101040101032101010101010321010401010321010101010103210104010103210101010101032101040101032100;CP=0;O;

04 = 1,-38 not detected as MS

MU;P0=108;P1=-1369;P2=795;P3=-2724;P4=-22182;P5=8157;P6=-900;D=012121212323232321212123212124562123212123212123232121212121232323232121212321212456212321212321212323212121212123232323212121232121245621232121232121232321212121212323232321212123212124;CP=2;�

.MU;P0=-2876;P1=439;P2=-8005;P3=-2101;P4=-4112;D=01212121212121212121212121212121313131313141413141413131313141313141314131313141413131414141313141313131314131314131212131313131314141314141313131314131314131413131314141313141414131314131313131413131413121213131313131414131414131313131413131413141313131;CP=1;O;.

12 is preamble for agc and sync

Provide Support for ethernet shield

Configuration :

ATmega328P Arduino Nano V3 + CC1101 , @see

Hardware:

Switches (YC-4000B) which support InterTechno protocol v1 and that's works like a charm !!!

Now i try to use different switches "Electro Depot 940557", but i cannot create them automatically AND i cannot send Messages. Could you help me ?

I identified the messages (4 per button) for each action.

Fhem code :

define lampeSalonD dummy
define mydoifLampeSalonD DOIF ([sduino:&DMSG] =~ "#B294DD" or [sduino:&DMSG] =~ "#BB00ED" or [sduino:&DMSG] =~ "#B48F6D" or [sduino:&DMSG] =~ "#B0BB5D") (set lampeSalonD on)
DOELSEIF ([sduino:&DMSG] =~ "#B8434D" or [sduino:&DMSG] =~ "#B522CD" or [sduino:&DMSG] =~ "#B176BD" or [sduino:&DMSG] =~ "#BCC78D") (set lampeSalonD off)


Other informations

Association & Desassociation :

• add a button: plug switch into the socket and press "on" during the 30 first seconds (red led flashing)
• remove a button: plug switch into the socket and press "off" during the 30 first seconds (red led flashing)

Switch & Remote:

• vendor brand: Electro Depot
• article code: 940557
• S/N: 022017/1
• imported by: VIVANCO ACCESORIOS S.A.U
• import art. code: 71014
• made in: RPC (China)

Remote:

• remote code print on board: 50074 (i think brand is KANGTAI)
• my remote is more recent, the previous remote (for the same article) has 50027 (i think brand is KANGTAI)

Switch:

Similar to: KANGTAI 55606FRX36 - 2627A-1000

More links :

• http://www.rflink.nl/blog2/changelog

rflink compatible

• https://forum.pimatic.org/topic/1291/new-switch-cotech-from-clas-ohlson/6

layout of the protocol KANGTAI using Rolling code
refer to a instructables.com's tutorial using 50027 remote

• http://www.touteladomotique.com/forum/viewtopic.php?f=48&t=7218&p=127410#p127410

a user give a link to the codes to use in order to setup RFXCOM plugin with theses switches

Apply a watchdog, wich will do a reset, if the microcontroller is not working as expected.

For Sending MC Messages, a method should be provided to send them the same way as they are received.

Die Funktion checkSignal ist um eine Prüfung zu erweitern, mit der Pulse verifiziert wird.

z.B. bestehen viele Signale aus 4 verschiedenen Pulsen, manche aber auch aus 6. Dies soll mit unterschieden werden, damit eine bessere Zuordung zum Protokoll erfolgen kann.

Beispiel: Folgendes Protokoll wird falsch als IT old zugeordnet:
M3;P0=336;P1=-2112;P2=-4116;P3=-9392;D=03010201020101020101010102020101010101010102010202020102010101020201010202;CP=0;SP=3;

Damit sollen vor allem false positives reduziert werden

So wies aussieht ist die Nachrichtenlänge vom BTHR918N mit 96 Bit zu lang.
MC;LL=-1009;LH=947;SL=-534;SH=436;D=AAAAAAAB32CCCB2D555532CD54D4D535554D4D4CB552D2B52A;C=460;
ergibt
505A6D005A102140448339 dies sind nur 88 Bit
dies ist kurz. Richtig wäre:
605a6d005a1021404483394eef

Bei OSV2 hat die Preamble 32 und der Sync 8 Bit
Beim BTHR918N sind es 96 * 2 = 192 Datenbit
Dies ergibt dann 232 Bit

rfduino is already used. we need a better name for this repo

Erweiterung der Musterekennung für Düwi Signal.

Hier scheint es keinen Sync zu geben.
Unklar wie das Signal aufgebaut ist.

U1f5
Timings DUWI: 92 1336 1292 916 1352 864 1332 868 572 892 1312 904
DataBitsDUWI: 000111110101

U1f5
Timings DUWI: 420 924 1192 916 1352 864 1332 868 572 892 1312 904
DataBitsDUWI: 000111110101

Hier soll es um Ideen, Vorschläge und todos für die Firmware dev-r332_cc1101 gehen.

• addData overflow
• Not detected as MS z.B. #38
• MU-Nachrichten werden z.T. als MC erkannt, z.B. Siro
• bei MU-Nachrichten Wiederholungen trennen

@sidey79 kannst Du bitte von der dev-r33_cc1101 einen neuen Branch dev-r332_cc1101 erstellen.
Ich denke es macht Sinn damit zu warten bis die Probleme in der dev-r33_cc1101 die die Abstürze verursachen behoben sind.

Ich sehe momentan nur die Trennung der Wiederholungen als wichtig an.
Der "addData overflow" und "MU-Nachrichten werden z.T. als MC erkannt" dürfte nicht so dringend sein.
Da gibt es z.Zt, noch einge todos mit höherer Priorität.

Ein Ansatz bei MU Nachrichten zu trennen wäre, wenn wir einen low Pegel finden der länger als die anderen ist und vielleicht maximal 3x vorkommt. Dann könnte man diesen verwenden.
Länger wäre dann vermutlich mindestens 2* maximal 10* ?

Evtl ist ein Ansatz, wenn wir eine Variable MuCut einführen, in der die mindestlänge einer Pause als Vielfaches der Clock gespeichert wird. z.B. bedeutet 10: Pause = 10 x clock.
Mit z.B. dem command GSMUCUT kann man es konfigurierbar machen und im EEPROM speichern.
Bei 10 wird dann nach einer Pause von mindestens 10 * clock gesucht

Hallo, da wir ja gelegendlich auf der Suche nach Fehlern sind wieso Protokolle teilweise nach einem Bugfix oder einer Verbesserung schlechter erkannt werden, so machte ich mir mal Gedanken.

Gibt es eine Möglichkeit welche dazu beitragen kann sich der Sache sinnvoll anzunehmen?

Ich hatte die Überlegung 2 Empfänger welche einmal die gute und die "schlechtere" FW haben zu vergleichen. Zusätzlich dient eine Tabelle in FHEM welche mir das letzte Protokoll / DSMG anzeigt und den Empfangszeitpunkt mit Count. So sieht man, wenn Bsp ein Signal mit Wiederholungen von dem einen nur zum Teil erkannt wird. Aus dieser Erkenntnis würde ich im Logfile schauen wie die Daten aussehen welche verarbeitet werden. Wäre das Sinnvoll oder kann neune Erkenntnisse bringen?

Einziges "Problem " was ich sehe, das ggf. in den FW Versionen verschiedene Debugausgaben sind welche man nicht direkt vergleichen kann.

Gibt es diesbezüglich Ideen der herangehensweise?

Im Falle aktuellen Hideki-Protokoll ist es so, das die Nachrichten zu 2/3 schlechter erkannt werden wenn ich die FW @sidey79 SIGNALDuino-dev-r33_cc1101_171103 mit @Ralf9 SIGNALDuino-dev-r33_cc1101_171029_Ralf vergleiche.

Die Variable minBitLength für den MC Decoder soll für Anwender / FHEM konfigurierbar sein

Hallo,

ist es möglich mit SIGNALDuino das X10-Protokoll zu empfangen bzw. zu decodieren.

Wenn ich mir den Empfang des X10-Security-Sensors ansehe, bekomme ich folgende Logs. Ich habe jeweils davor geschrieben, was im Hexcode herauskommen soll.

Kann man damit etwas anfangen?

Das basierende X10-RF Protocol ist her beschrieben:

• http://openmicros.org/media/kunena/attachments/987/X10_RF_Receiver.pdf
  oder
• http://www.authinx.com/manuals/activehome/xtdcode.pdf

"Data is accepted bit by bit as the presence or absence of 120Khz
carrier occurring after the positive or negative mains zero crossing.
The acceptance window begins approximately 250 usecs. and ends
approximately 900 usecs. after a zero crossing. In this window 48 or
more cycle of carrier are accepted as a "1" bit and fewer than 48 as a
"0" bit. Except for the Startcode, each bit of data is sent in its
true and complement form. "

In rtl_433 ist X10 testweise wie folgt codiert:
r_device X10_RF = {
.name = "X10 RF",
.modulation = OOK_PULSE_PPM_RAW,
.short_limit = 1100, // Short gap 500µs, long gap 1680µs
.long_limit = 2800, // Gap after sync is 4.5ms (1125)
.reset_limit = 6000, // Gap seen between messages is ~40ms so let's get them individually
.json_callback = &X10_RF_callback,
.disabled = 0,
.demod_arg = 0,
};

Wie gehe ich am besten vor?

Man muss das Protokoll definieren. Klar.
Also so etwas:
"39" => ## X10 Protocol
{
name => 'X10 Protocol',
id => '39',
one => [1,-2],
zero => [2,-2],
#sync => [1,-8], #
clockabs => 470, #
format => 'twostate', #
preamble => '"', # prepend to converted message
clientmodule => 'RFXX10REC', # not used now
#modulematch => '^TX......', # not used now
length_min => '43',
length_max => '44',
remove_zero => 1, # Removes leading zeros from output

    },    

Aber was kommt bei den einzelnen Werten hin?
Was bedeuten die Angaben bei one, zero, clockabs, ....

Ist format twostate richtig?

Grüße

Willi

DS10A Kontakt geschlossen

Zu demodulierender Hexcode 29454a847bd700

2016.02.15 18:05:02 4: sduino/msg READ: �MU;P0=658;P1=-581;P2=-1720;P4=10748;P5=-2688;D=0101010201020102010102010201020101010102010101020202020102020202010201020202010045010201010102010201020101020102010201010101020101010202020201020202020102010202020100;CP=0;�
2016.02.15 18:05:02 4: sduino: Fingerprint for MU Protocol id 27 -> remote27 matches, trying to demodulate
2016.02.15 18:05:02 4: sduino: Fingerprint for MU Protocol id 28 -> IC Ledspot matches, trying to demodulate
2016.02.15 18:05:02 4: sduino: Fingerprint for MU Protocol id 31 -> pollin isotronic matches, trying to demodulate
2016.02.15 18:05:02 4: sduino: Fingerprint for MU Protocol id 36 -> socket36 matches, trying to demodulate
2016.02.15 18:05:02 4: sduino: Fingerprint for MU Protocol id 8 -> TX3 Protocol matches, trying to demodulate
2016.02.15 18:05:02 4: sduino/msg READ: �MU;P0=656;P1=10710;P2=-2730;P3=-586;P4=-1716;D=01203040303030403040304030304030403040303030304030303040404040304040404030403040404030012030403030304030403040303040304030403030303040303030404040403040404040304030404040300;CP=0;�
2016.02.15 18:05:02 4: sduino: Fingerprint for MU Protocol id 27 -> remote27 matches, trying to demodulate
2016.02.15 18:05:02 4: sduino: Fingerprint for MU Protocol id 28 -> IC Ledspot matches, trying to demodulate
2016.02.15 18:05:02 4: sduino: Fingerprint for MU Protocol id 31 -> pollin isotronic matches, trying to demodulate
2016.02.15 18:05:02 4: sduino: Fingerprint for MU Protocol id 36 -> socket36 matches, trying to demodulate
2016.02.15 18:05:02 4: sduino: Fingerprint for MU Protocol id 8 -> TX3 Protocol matches, trying to demodulate
2016.02.15 18:05:02 4: sduino/msg READ: �MU;P0=-3556;P1=10708;P2=-2720;P3=550;P4=-583;P5=-1711;D=01234353434343534353435343435343534353434343435343434353535353435353535343534353535343;CP=3;�
2016.02.15 18:05:02 4: sduino: Fingerprint for MU Protocol id 16 -> Dooya shutter matches, trying to demodulate
2016.02.15 18:05:02 4: sduino: Fingerprint for MU Protocol id 27 -> remote27 matches, trying to demodulate
2016.02.15 18:05:02 4: sduino: Fingerprint for MU Protocol id 28 -> IC Ledspot matches, trying to demodulate
2016.02.15 18:05:02 4: sduino: Fingerprint for MU Protocol id 30 -> unitec47031 matches, trying to demodulate
2016.02.15 18:05:02 4: sduino: Fingerprint for MU Protocol id 36 -> socket36 matches, trying to demodulate
2016.02.15 18:05:02 4: sduino: Fingerprint for MU Protocol id 8 -> TX3 Protocol matches, trying to demodulate

DS10A Kontakt offen

Zu demodulierender Hexcode 29454a04fbd700

2016.02.15 18:06:35 4: sduino/msg READ: �MS;P0=546;P1=-587;P2=-1721;P3=-15617;P4=10642;P5=-2802;D=03450102010101020102010201010201020101010101010201010202020202010202020201020102020201;CP=0;SP=3;O;�
2016.02.15 18:06:35 4: sduino/msg READ: �MU;P0=-2796;P1=544;P2=-587;P3=-1722;P4=-32001;P5=120;D=01213121212131213121312121312131212121212121312121313131313121313131312131213131312145;CP=1;�
2016.02.15 18:06:35 4: sduino: Fingerprint for MU Protocol id 16 -> Dooya shutter matches, trying to demodulate
2016.02.15 18:06:35 4: sduino: Fingerprint for MU Protocol id 27 -> remote27 matches, trying to demodulate
2016.02.15 18:06:35 4: sduino: Fingerprint for MU Protocol id 28 -> IC Ledspot matches, trying to demodulate
2016.02.15 18:06:35 4: sduino: Fingerprint for MU Protocol id 30 -> unitec47031 matches, trying to demodulate
2016.02.15 18:06:35 4: sduino: Fingerprint for MU Protocol id 36 -> socket36 matches, trying to demodulate
2016.02.15 18:06:35 4: sduino: Fingerprint for MU Protocol id 8 -> TX3 Protocol matches, trying to demodulate
2016.02.15 18:06:35 4: sduino/msg READ: �MU;P0=-1526;P2=10644;P3=-2792;P4=549;P5=-583;D=023454004545454045404540454540454045454545454540454540404040404540404040454045404040454;CP=4;�
2016.02.15 18:06:35 4: sduino: Fingerprint for MU Protocol id 16 -> Dooya shutter matches, trying to demodulate
2016.02.15 18:06:35 4: sduino: Fingerprint for MU Protocol id 27 -> remote27 matches, trying to demodulate
2016.02.15 18:06:35 4: sduino: Fingerprint for MU Protocol id 28 -> IC Ledspot matches, trying to demodulate
2016.02.15 18:06:35 4: sduino: Fingerprint for MU Protocol id 30 -> unitec47031 matches, trying to demodulate
2016.02.15 18:06:35 4: sduino: Fingerprint for MU Protocol id 36 -> socket36 matches, trying to demodulate
2016.02.15 18:06:35 4: sduino: Fingerprint for MU Protocol id 8 -> TX3 Protocol matches, trying to demodulate

Der Sensor THN132N wird von FHEM mit zu 90% mit fehlerhafter Checksumme erkannt.

Mit dem Fhemduino 2.3.1 klappte das wunderbar, mit dem RF Receiver ist das Format falsch.

Hex Ausgabe:
RF Receiver: 40ea4c10c04100a3
Fhemduino 2.3.1 40EA4C10C0410000A3

Da die Anzahl der Bits 0x40 beträgt, wird wohl "0" nicht als 0x00 sonder 0x0 ausgegeben.

Es gibt Funksignale, welche vom Patterndetector derzeit nicht erkannt werden.
Anbei Pulslängen einer TCM Türklingel:

Sync wird vermutlich nicht erkannt, da erst langer Puls und danach der kurze.
Bei doDetect sollte auf1,-n] oder [n, -1]) geprüft werden, was hier passt.

Sync 47584 668 -> Faktor = 71 erst langer Puls, dann kurzer
Onebit = 632 1252
Zerobit = 1328 580

TimingsTCM: 47584 668 632 1252 1328 580 692 1208 1356 556 1368 544 724 1188 1188 1384 528 736 1180 736 1176
DataBitsTCM: 10100101101011100001

Ma5ae1
TimingsTCM: 47580 672 640 1244 1320 584 696 1204 1352 564 1364 544 728 1184 1384 532 752 1160 740 1176
DataBitsTCM: 10100101101011100001

There is to much debug output caused by manchesterPatternDetect, this makes it impossible to debug radio signal.

The output must be shorened to a minimum to help identification of the protocol to allow creating a new decoder.

Gesendet:
SR;R=3;P0=1230;P1=-3120;P2=-400;P3=-900;D=030301010101010202020202020101010102020202010101010202010120202;

Ausgewertet:
Sync: -32001 -> SyncFact: -26.17, Clock: 1223, Tol: 150, PattLen: 6 , Pulse: 348, -13800, mStart: 168
Signal: 01010101010202020201010101020202020101020201010404020202020201010101010102020202010101010202020201010202010104040202020202010101010101020202020101010102020202010102020105. [171]
Pattern: P0: 85_[,1223] P1: 40_[,-385] P2: 40_[,-3300] P3: 0_[] P4: 4_[,-885] P5: 1_[,-32001]

Übergabe:
�MS;P0=1223;P5=-32001;D=052;CP=0;SP=5;�
Error, overflow in message Array

Erweiterung des doDetect um mit unten angegebenem Muster arbeiten zu können.

Vermutlich ist hier nur der Punkt, dass wohl 4 Muster gibt.
Clock scheint so ca. 300 us. Sync wird vermutlich vom doSearch bereits erkannt.

Signalpulse entsprechen Faktor 1 oder 2, Sync beträgt Faktor 16

Timings von Jörg zum HX Signal:

Annahme des Musters, der 2. Puls bestimmt ob 0 oder 1:
312 316 = 0 Bit
640 320 = 0 Bit
636 676 = 1 bit
300 320 = 0 bit
636 676 = 1 bit
...
H2f3
Timings HX: 5032 312 316 640 320 636 676 300 320 636 676 300
DataBitsHX: 001011110011

H2f3
Timings HX: 5024 320 316 640 316 644 672 300 320 636 680 296
DataBitsHX: 001011110011

I recently decoded the signal of a (black) Came garage door opener, see http://www.came.com/de/torantriebe-tuerantriebe-schrankensysteme/zubehoer/funkempfaenger.html (they have a simple MC, no rolling code). Do you think it might be possible to add this protocol to the SIGNALDuino? That would be great.

The protocol is as follows. Came sends on 433.92 MHz, AM OOK and has pulses length of 335 us and 670 us. The first pulse is a 335 us LOW. Then, a sequence of HIGHs and LOWs follows with the following microsecs
335 670 (code will be interpreted as 0)
670 335 (will be interpreted as 1).
The code itself is then a 12-bit sequence of either 0 or 1 (=4096 possibilities as avertised by Came). The sequence closes with a 15018 footer.

So, for example, a valid code would be for example (I added some space for the {01}-code, see below)
335 335 670 670 335 670 335 335 670 670 335 670 335 670 335 335 670 670 335 670 335 670 335 335 670 15018
which would correspond to the code (SyncBit?)011011101110(Footer).

I hope I could make myself clear...

Hallo @sidey79

schöne Pfingsten!
Ich habe aktuell deine DEV Version mal getestet und auf den radino gespielt.
Die Version um den 01.05. herum, was deine letzte Version ist, wurde getestet und verglichen mit der Vorgängerversion um den 10.03. herum.

Die aktuelle Version empfängt 2/3 schlechter als die vorherige. Manche Sensoren empfange ich dadurch sogar gar nicht mehr. Sobald ich diese wieder zurück spiele, so ist der Empfang von den Sensoren abrupt wieder besser und alle Sensoren melden sich

Diese Erkenntnis wollte ich mal Preis geben. Eine Verbesserung ist in dem Falle noch nicht erzielt, eher eine "Verschlechterung" was den Empfang angeht. Kann man Dir ggf. Zuarbeit leisten um das Verhalten "einzugrenzen"?

Liebe Grüße

PS: Ist es machbar, das du in das Projekt, die Zeile

#define ARDUINO_AVR_ICT_BOARDS_ICT_BOARDS_AVR_RADINOCC1101

einfügst, da man sonst das Programm nicht kompilieren kann. Wenn ein User nicht daran denkt oder dies weiß, so erscheint erstmal ein Fehler.

//#define CMP_MEMDBG 1
#define CMP_CC1101
#define ARDUINO_AVR_ICT_BOARDS_ICT_BOARDS_AVR_RADINOCC1101
#define PROGNAME "RF_RECEIVER"

In der aktuellen Version mit message kompression kann es unter bestimmten speziellen recht seltenen Umständen zu einem "addData overflow" kommen.
Vielleicht lässt sich mit diesen zusätzlichen Ausgaben der Fehler eingrenzen:
1484b46

siehe auch
#60 (comment)

Because the Arduino has serval digital and analog pins left for usage, it woud be nice to have some generic appoach to access them.

Set command can be like pin1_on , pin1_off .... which will set the pin with number x to high or low.
Get commands can be like get pin1 wich will return state for digital(0-1) or analog pins(0-1023).

Schnittstelle bereitstellen, mit denen erkannte Funksignale des Detectors abgerufen werden können um diese dann z.B. Seriell an FHEM zu übertragen

the library.properties is missing for signalDecoder in the git-repository

Support firmware on radionocc1101

In the Manchester Decoder and subclasses the pattern which is detected with the manchester detector is not used to identify the protocol.

Encancement is to add a check towards the detected pattern in the protocol Decoder.

So there Decoder can check on Signal length, signal pattern and after that in a sync sequence to identify a protocol.

SIGNALduino uses SimpleFIFO as dependency, but the archives of release 3.1 do not contain it.

ich habe versucht nach jeder gesendeten Raw Nachricht den freien FIFO zu senden, aber irgendwas passt nicht. Es funktioniert nicht so wie ich gedacht habe. Der freie FIFO wird nicht nach jeder Raw Nachricht gesendet. Mache ich da einen Denkfehler?

void loop() {
	static int aktVal=0;
	bool state;
	if (command_available) {
		command_available=false;
		HandleCommand();
		if (!command_available) { cmdstring = ""; }
		blinkLED=true;
	}
	while (FiFo.count()>0 ) { //Puffer auslesen und an Dekoder uebergeben
		aktVal=FiFo.dequeue();
		state = musterDec.decode(&aktVal); 
		if (state) {
			if (MdebLevel == 1) {
				MSG_PRINT(F("MD="));
				MSG_PRINTLN(FiFo.count(), DEC);
			}
			blinkLED=true; //LED blinken, wenn Meldung dekodiert
		}
	}
 }

�MU;P0=-3944;P1=6060;P2=-6404;P3=3491;P4=-2368;P5=924;P6=-918;P7=2009;D=45676767012367476767676767676367476767676767676343436767676743;CP=7;R=65;�
�MU;P0=-3956;P1=6056;P2=3506;P3=156;P4=-2378;P5=292;P6=-898;P7=2029;D=23456767676767676767012267476767676767676267476767676767676242426767676742;CP=7;R=65;�
�MS;P1=483;P2=-3934;P3=-985;P4=-1956;D=12131413141413141314131314131313131413141313131414141414141313141314131413;CP=1;SP=2;R=16;O;�
�MS;P0=-981;P1=492;P2=-1972;P3=-3910;D=13101210121210121012101012101010101210121010101212121212121010121012101210;CP=1;SP=3;R=15;O;�
�MS;P0=-1938;P1=500;P2=-977;P3=-3890;D=13121012101012101210121210121212121012101212121010101010101212101210121012;CP=1;SP=3;R=13;O;�
�MU;P0=-959;P1=504;P2=-1938;P3=-3920;P4=264;D=01012101010101210121010101212121212121010121012101210131012101212101210121010121010101012101210101012121212121210101210121012104;CP=1;R=12;�
�MU;P0=-16380;P1=556;P2=-4176;P3=-2188;P4=322;P5=240;P6=-116;P7=184;D=431212131313131313131313131213131212121212567352431213121210;CP=1;R=242;�
�MU;P0=-4156;P1=569;P2=-2105;P4=380;D=01210101210101242121212121212121210121210101;CP=1;R=240;�
�MS;P0=-3914;P1=471;P5=-1960;P7=-990;D=10171517151717171517171517171717171517151717151717151515151717151715151717;CP=1;SP=0;R=23;O;�
�MS;P0=-970;P1=499;P2=-1953;P3=-3902;D=13101210121010101210101210101010101210121010121010121212121010121012121010;CP=1;SP=3;R=23;O;�
�MS;P0=-981;P1=475;P2=-1961;P3=-3911;D=13101210121010101210101210101010101210121010121010121212121010121012121010;CP=1;SP=3;R=23;O;�
�MU;P0=-1962;P1=488;P2=-977;P3=-3904;P4=144;D=01212101212101010101212101210101212131210121012121210121210121212121210121012121012121010101012121012101012124;CP=1;R=23;�
�MU;P0=-29352;P1=2009;P2=-922;P3=-3948;P4=6056;P5=-6396;P6=3476;P7=-2389;D=012121212121212121212121345621712121212121212621712121212121212676762121212176;CP=1;R=65;�
�MU;P0=-918;P1=2013;P2=3477;P3=-2390;D=0101010101010201310101010101010232320101010132;CP=1;R=65;�
�MS;P1=548;P2=-9064;P3=-2099;P4=-4137;D=1213141414131313141313131413131313141313141413131313141314141314141314131314;CP=1;SP=2;R=12;O;�
MD=0
�MS;P0=-2087;P1=549;P2=-4129;P3=-9036;D=1310121212101010121010101210101010121010121210101010121012121012121012101012;CP=1;SP=3;R=10;�
MD=5
�MS;P0=-2087;P1=549;P2=-4129;P3=-9036;D=1310121212101010121010101210101010121010121210101010121012121012121012101012;CP=1;SP=3;R=10;�
MD=17
�MS;P0=-2102;P1=549;P2=-4129;P3=-9036;D=1310121212101010121010101210101010121010121210101010121012121012121012101012;CP=1;SP=3;R=10;�
MD=16
�MS;P0=-2027;P1=549;P2=-4129;P3=-9036;D=1310121212101010121010101210101010121010121210101010121012121012121012101012;CP=1;SP=3;R=10;�
MD=16
�MU;P0=-6928;P1=-919;P2=2013;P3=-3948;P4=6048;P5=3476;P6=-2401;D=1212121212121212340512621212121212121512621212121212121565651212121265;CP=2;R=63;�
�MU;P0=-2378;P1=136;P2=-899;P3=2027;P4=-3944;P5=6044;P6=-6404;P7=3503;D=012323232323456723032323232323232723032323232323232707072323232307;CP=3;R=64;�
�MU;P0=-2093;P1=584;P2=141;P4=-4148;P5=-6944;D=010202010101010101410101414141414101410152;CP=1;R=4;�
MD=1
�MU;P1=-4139;P3=589;P5=-2141;P6=-8592;D=5361313135313531353131313135313531363536;CP=3;R=250;�
�MS;P0=-2085;P1=561;P2=-9218;P3=-4154;D=1210131310131310101010101010101010131010131313131310131013101313131310131013;CP=1;SP=2;R=248;�
�MS;P0=-2308;P1=571;P2=-9080;P3=-4153;D=1210131310131310101010101010101010131010131313131310131013101313131310131013;CP=1;SP=2;R=248;�
�MU;P0=244;P1=-2097;P2=564;P3=-4089;D=012123232323232123212321232323232123212323;CP=2;R=250;�
�MS;P1=494;P2=-3901;P3=-968;P4=-1944;D=12131413141413141314131314131313131413141313131414141414141313141314131413;CP=1;SP=2;R=246;�
�MU;P0=-112;P1=158;P2=-1963;P3=491;P4=-967;P5=360;P6=-3924;P7=-7084;D=0123434323432543234363432343232343234323417;CP=3;R=246;�
�MU;P0=-4228;P1=502;P2=-963;P3=-2014;D=01213121313121312131212131212121213121313;CP=1;R=0;�
�MU;P0=204;P1=-1957;P2=497;P3=-981;P4=-7692;D=01232121232123212323212323232321232123232321212121212123232124;CP=2;R=247;�
�MS;P1=548;P2=-8656;P3=-2082;P4=-4160;D=1213141414131313141313131413131313141313141413131313141314141314141314131314;CP=1;SP=2;R=10;�
�MU;P0=-2374;P1=292;P2=-905;P3=2030;P4=-3936;P5=6064;P6=-6396;P7=3494;D=012323232323232323456723032323232323232723032323232323232707072323232307;CP=3;R=64;�
�MU;P0=3512;P1=534;P2=-2355;P3=-4009;P4=2025;P5=-900;P6=6068;P7=-6388;D=0121313131212121345454545454545454545454367054245454545454545054245454545454545020205454545420;CP=4;R=62;�
MD=0
�MS;P1=558;P2=-2088;P3=-4130;P4=-9053;D=1412131313121212131212121312121212131212131312121212131213131213131213121213;CP=1;SP=4;R=7;�
MD=6
�MS;P1=558;P2=-2088;P3=-4130;P4=-9053;D=1412131313121212131212121312121212131212131312121212131213131213131213121213;CP=1;SP=4;R=7;�
MD=8
�MS;P1=558;P2=-2088;P3=-4130;P4=-9053;D=1412131313121212131212121312121212131212131312121212131213131213131213121213;CP=1;SP=4;R=7;�
MD=7
�MS;P0=664;P1=558;P3=-4130;P4=-9053;D=1410131313101010131010101310101010131010131310101010131013131013131013101013;CP=1;SP=4;R=7;�
MD=8
�MS;P0=597;P3=-4130;P4=-9053;D=0400030303000000030000000300000000030000030300000000030003030003030003000003;CP=0;SP=4;R=7;�
MD=7
�MS;P0=597;P3=-4130;P4=-9053;D=0400030303000000030000000300000000030000030300000000030003030003030003000003;CP=0;SP=4;R=7;�
MD=6
�MS;P0=-1958;P3=-983;P6=489;P7=-3904;D=67636063606363636063636063636363636063606363606363606060606363606360606363;CP=6;SP=7;R=6;O;�
MD=9
�MS;P0=-1958;P3=-977;P6=489;P7=-3904;D=67636063606363636063636063636363636063606363606363606060606363606360606363;CP=6;SP=7;R=6;�
MD=17
�MS;P0=-1949;P3=-974;P6=489;P7=-3907;D=67636063606363636063636063636363636063606363606363606060606363606360606363;CP=6;SP=7;R=9;O;�
MD=7
�MS;P0=-1949;P3=-985;P6=489;P7=-3907;D=67636063606363636063636063636363636063606363606363606060606363606360606363;CP=6;SP=7;R=9;�
MD=14
�MS;P0=-1940;P3=-974;P6=504;P7=-3901;D=67636063606363636063636063636363636063606363606363606060606363606360606363;CP=6;SP=7;R=9;O;�
MD=9
�MS;P0=-1940;P3=-973;P6=504;P7=-3901;D=67636063606363636063636063636363636063606363606363606060606363606360606363;CP=6;SP=7;R=9;�
MD=17
�MU;P0=-1950;P3=-975;P6=493;P7=-3910;D=3606363636363606360636360636360606060636360636060636367636063606363636063636063636363636063606363606363606060606363606360606363;CP=6;R=10;�
�MS;P1=544;P2=-9083;P3=-2116;P4=-4261;D=1213141413141413131313131313131313141313141414141413141314131414141413141314;CP=1;SP=2;R=249;�
�MU;P0=-2102;P1=312;P2=-4183;P3=567;D=01232303030303030303030303230303232323232;CP=3;R=6;�
�MS;P0=-4146;P1=549;P2=-2131;P4=-9054;D=1412101012101012121212121212121212101212101010101012101210121010101012101210;CP=1;SP=4;R=247;�
�MS;P2=-4148;P3=581;P4=-2090;P5=-9077;D=3534323234323234343434343434343434323434323232323234323432343232323234323432;CP=3;SP=5;R=248;�
MD=7
�MU;P0=2025;P1=-3944;P2=6048;P3=-6412;P4=3500;P5=-2369;P6=892;P7=-897;D=6707070123470507070707070707470507070707070707454547070707054;CP=0;R=65;�
�MU;P0=-2367;P1=92;P2=-904;P3=2023;P4=-3936;P5=6048;P6=-6412;P7=3503;D=012323232323456723032323232323232723032323232323232707072323232307;CP=3;R=64;�
�MS;P0=-1945;P1=508;P2=-967;P3=-4348;P4=192;D=1312101210101210121012121012121212101210121212433;CP=1;SP=3;R=246;�
�MS;P0=-4182;P1=497;P2=-962;P3=-1961;P4=-9340;P5=276;D=1012131213131213121312121312121212131213121212131313131313121213121312131214533;CP=1;SP=0;R=245;�
�MU;P0=112;P1=-1988;P2=499;P3=-957;P4=-3944;P5=-6900;D=012324232123212123212321232321232323232123212323232521;CP=2;R=245;�
�MS;P0=-9059;P2=546;P3=-2114;P4=-4143;D=2023242424232323242323232423232323242323242423232323242324242324242324232324;CP=2;SP=0;R=11;O;�
MD=0
�MS;P0=-2089;P1=552;P2=-4123;P3=-9072;D=1310121212101010121010101210101010121010121210101010121012121012121012101012;CP=1;SP=3;R=11;�
MD=0
�MS;P0=-2089;P1=552;P2=-4123;P3=-9072;D=1310121212101010121010101210101010121010121210101010121012121012121012101012;CP=1;SP=3;R=11;�

MS;P0=8142;P1=-894;P2=804;P3=-1391;P4=-2706;P5=-21644;P6=1371;D=2501232323232323232324242424242423242323232323232324225;CP=2;SP=5;

P6 is not included in message and should not be transmitted.

Es handelt sich um diesen Sensor mit der Artikel Nr. 97001 (siehe im Anhang Bild)

Als erstes hatte ich das Protokoll dekodiert.

Die Bits sind wie folgt codiert:
1 = 0,5ms height + 4ms low
0 = 0,5ms height + 2ms low

Wie man bereits sieht steckt die Information in den low-Anteilen der Übertragung.

Ein komplettes Paket sieht dann z.B. so aus:
A B C D E F
25,9° = 1111 0000 0000 0100 0000 1100

Wie komme ich nun auf die 25.9°:
Die ersten zwei Bytes (A+B) sind die Adresse des Sensors, diese wird bei jedem einlegen der Batterie neu generiert.
Die Temperatur steckt in Byte D-F
0100 0000 1100 = 259 dann noch durch 10 und man bekommt die Temperatur

Eine negative Temperatur sieht so aus:
-7,1° = 1111 0000 0011 1110 1110 0101
Die ersten zwei Bytes sind wieder die Adresse
Mit den zwei Bit von Byte C (11) erkennt man dass die Temperatur ins negative gehen muss.

Wenn wir nun wie bei den positiven werten Rechnen, kommen wir leider nicht ans Ziel:
1110 1110 01 = 953 (kann nicht stimmen)
Die Lösung ist allerdings recht simpel:
Wie negieren einfach alle Bits, daraus ergibt sich:
0001 0001 10 = 70
nun noch +1 und /10 dann kommt die -7,1 raus.

In Byte C Bit 3 steck noch die Batteriewarnung, wenn also z.B. ein Paket 0100 kommt, ist die Batterie leer.

Was ich allerdings nicht raus bekommen habe sind die letzen zwei Bits von Byte F. Das letzte wird immer beim manuellen Senden (drücken der TX Taste) gesetzt. Das Bit wird aber auch ab und zu während der normalen Übertragung gesetzt.
Vielleicht sind die letzten Bits auch eine Checksumme, vielleicht hat ja jemand von Euch eine Idee.

Quelle:
http://forum.fhem.de/index.php/topic,28519.msg214031.html#msg214031

Firmware Dateien sollen nicht mehr über den normale FHEM Update Prozess verteilt werden.

Daher würde ich gerne die Update Prozedur so ändern, dass eine Firmware aus dem Repo des uC geladen wird, wenn der Update Prozess gestartet wird.

Gesendet von meinem Motorola XT1650 mit FastHub

Sync of a protocol with sync fact of 8 is not detected

Provide a generic interface to send radio signals.

Send instruction coul'd be something like this:

P0=-1058;P1=289;P2=-248;P4=-2568;D=1412101210101210121012121012101012101210121012121012101210101210121012101210121012101210121012121010121210120;

This woul'd provide a option to send any signal without modification of the arduino code.