Signalduino Entwicklung

habeIchVergessen · 04 Juni 2016, 18:54:12

Zitat von: habeIchVergessen am 04 Juni 2016, 12:30:39
das SOMFY-Modul scheint eine Bug zu haben, da bei mir enc_key und rolling_code nicht hochzählen.

wenn miniCUL sendet und sduino gleichzeitig empfängt, dann werden die gesetzten Codes gleich wieder mit dem Empfangenen überschrieben. Ggf. sollte SOMFY erst beim Senden enc_key und rolling_code hochsetzen und nicht schon auf Verdacht nach dem letzen Senden in vorauseilenden Gehorsam.

Sidey · 05 Juni 2016, 23:00:41

Zitat von: habeIchVergessen am 04 Juni 2016, 12:50:03
was mich stört, ist das lange LOW-Signal zu Beginn vom MU. -32001 gibt es im Gesendeten nicht.
Dort werden -30415 am Ende der Nachricht und dann 2560 am Anfang der nächsten Nachricht gesendet.
Woher kommen -32001?

Habe ich jetzt gefunden.
Nach jeder Übertragung eines Kommandos (SM oder SR) setze ich den Sender auf low.
Nach jeder Wiederholung eines SC Kommandos habe ich einen delay eingebaut.

Der Delay ist eher interessant, wenn nur MC gesendet wird. Den hatte ich drinnen um einen Abschluss des Manchester Signals zu generieren.
So auf Anhieb habe ich es mal entfernt, wenn das SC Kommando gesetzt ist. Vermutlich kann man es bei SR Kommandos auch entfernen und braucht es nur bei den SM Kommandos.

Zur Somfy Thematik.
Ich habe jetzt den Überblick verloren, was wann wo wie von welchem Device tatsächlich gesendet wird und wie es der SIGNALduino empfangen müsste.

Grüße Sidey

habeIchVergessen · 06 Juni 2016, 23:07:57

Zitat von: Sidey am 05 Juni 2016, 23:00:41
Nach jeder Übertragung eines Kommandos (SM oder SR) setze ich den Sender auf low.
Nach jeder Wiederholung eines SC Kommandos habe ich einen delay eingebaut.

Habe ich zu Testzwecken beides nach die SC-Schleife gesetzt.
Funktion send_mc sieht bei mir aktuell so aus:

Code Auswählen

void send_mc(const uint8_t startpos,const uint8_t endpos, const uint16_t clock)
{
	uint8_t b;
	char c;
	//digitalHigh(PIN_SEND);
	//delay(1);
	uint8_t bit;

  unsigned long stoptime = micros();

	for (uint8_t i=startpos;i<=endpos;i++ )
	{
  	c = cmdstring.charAt(i);
		//Serial.print(c);

	  b = ((byte)c) - (c <= '9' ? 0x30 : 0x37);

		for (bit=0x8; bit>0; bit>>=1) {
//      send_mc_bit(clock, (b & bit));

      for (byte i=0; i<=1; i++) {
        if ((i==0 ? (b & bit) : !(b & bit))) 
          digitalLow(PIN_SEND);
        else
          digitalHigh(PIN_SEND);
    
        stoptime += clock;
        while (stoptime > micros())
          ;
      }
		}
	}

  // 3 clocks are invalid for manchester and marks the end
  stoptime += clock * (isHigh(PIN_SEND) ? 5 : 4);
  if (isHigh(PIN_SEND))
    digitalLow(PIN_SEND);
  while (stoptime > micros())
      ;

	// Serial.println("");
}

Zitat von: Sidey am 05 Juni 2016, 23:00:41
Ich habe jetzt den Überblick verloren, was wann wo wie von welchem Device tatsächlich gesendet wird und wie es der SIGNALduino empfangen müsste.

ich habe mir nochmal die Zeiten in culfw angesehen und folgendes herausgefunden (Zeiten beim Senden):

Code Auswählen


Nachricht			
decrypt	        encrypt	        clock	             -4c      4c      7c      -c                           c                          -49c
A110000112389A	A1B1B1B02A1200	680	SC;R=6;SR;P0=-2720;P1=2720;P2=4760;P3=-680;D=1010101010101023;SM;C=680;D=A1B1B1B02A1200;SR;P0=-33320;D=0;
A210000212389A	A2B2B2B02A1200		SC;R=6;SR;P0=-2720;P1=2720;P2=4760;P3=-680;D=1010101010101023;SM;C=680;D=A2B2B2B02A1200;SR;P0=-33320;D=0;
A210001212389A	A2B3B3A13B0311		SC;R=6;SR;P0=-2720;P1=2720;P2=4760;P3=-680;D=1010101010101023;SM;C=680;D=A2B3B3A13B0311;SR;P0=-33320;D=0;

die oben aufgeführten Nachrichten (SC;...) sollten via sduino versendet die gleichen Ausgaben wie Ys<Nachricht decrypted> (erste Zeile also YsA110000112389A) via miniCUL ergeben. Beim Testen ist mir auch aufgefallen, dass die clock deutlich höher als in culfw sein muss (680 vs. 620), damit MC-Nachrichten empfangen werden können.

Sidey · 07 Juni 2016, 08:24:41

Prima, mit der Tabelle kann ich ja mal die Funktion prüfen.

Dann habe zumindest ich mal einen Stand bis wo hin es funktioniert.

Bezüglich der clock: Welches Device empfängt denn mit der clock von 620 nicht? Ich nehme an der CUL oder?

Sidey

habeIchVergessen · 07 Juni 2016, 08:34:55

Beim Empfang ist immer sduino gemeint (in culfw nicht implementiert). Wenn der sduino mit clock < 675 sendet, dann werden immer MU-Nachrichten empfangen.

sduino müsste die encrypted Nachricht empfangen. Was auch bei der reinen SM;... funktioniert.
Leider werden aktuell die Daten weder encrypted noch encrypted negiert empfangen. Scheint ein Bit-Schiebefehler zu sein.

habe meine Anpassungen hier dokumentiert.

Sidey · 08 Juni 2016, 22:03:15

Zitat von: habeIchVergessen am 07 Juni 2016, 08:34:55
habe meine Anpassungen hier dokumentiert.

Mach doch mal einen Pull Request

bmilos · 08 Juni 2016, 22:59:05

Kann mir vieleicht jeman dhelfen?
Ich bin relativ neu mit dem SignalDuino.

Ich habe mir aus China einen 433MHz Fensterkontakt besorgt, jedoch wird dieser von sDuino nicht erkannt, es werden folgende msg, beim schliessen und öffnen empfangen:

Code Auswählen

016.06.08 22:54:53 4: sduino/msg READ: MS;P0=474;P1=977;P2=-394;P4=-1129;P5=-11112;D=05040412040404120412040404041212120404040412121204;CP=0;SP=5;O;
2016.06.08 22:54:53 4: sduino/msg READ: MS;P0=1121;P1=-387;P2=462;P3=-1121;P4=-11119;D=24232301232323012301232323230101012323232301010123;CP=2;SP=4;O;
2016.06.08 22:54:54 4: sduino/msg READ: MS;P0=-1130;P1=1113;P2=-384;P3=465;P4=-11117;D=34303012303030123012303030301212123030303012121230;CP=3;SP=4;
2016.06.08 22:55:06 4: sduino/msg READ: MS;P1=-389;P2=1111;P3=479;P4=-1126;P5=-11114;D=35343421343434213421343434342121213434343421342134;CP=3;SP=5;O;
2016.06.08 22:55:06 4: sduino/msg READ: MS;P0=-386;P1=471;P2=-1131;P3=1120;P4=-11119;D=14121230121212301230121212123030301212121230123012;CP=1;SP=4;O;
2016.06.08 22:55:07 4: sduino/msg READ: MS;P0=1115;P1=-388;P2=464;P3=-1129;P4=-11130;D=24232301232323012301232323230101012323232301230123;CP=2;SP=4;

Gruss

Sidey · 08 Juni 2016, 23:13:42

Zitat von: habeIchVergessen am 06 Juni 2016, 23:07:57
Habe ich zu Testzwecken beides nach die SC-Schleife gesetzt.
Funktion send_mc sieht bei mir aktuell so aus:

Die habe ich jetzt noch nicht übernommen. Mache ich aber noch.
Aber erst mal eins nach dem Anderen...

Ich habe folgendes mit einem SIGNALduino gesendet:

Code Auswählen


SC;R=6;SR;P0=-2720;P1=2720;P2=4760;P3=-680;D=101010101010102;SM;C=690;D=A1B1B1B02A1200;SR;P0=-31320;D=0;

Der Empfang mit einem SIGNALduino funktioniert auch:

Code Auswählen


MC;LL=-1375;LH=1397;SL=-684;SH=758;D=A1B1B1B02A1200;C=718;L=55

Die Clock wurde halt deutlich höher gemessen. Naja lassen wir das erst mal weg.
Warum geht es mit einer niedrigen Clock nicht.... das ist ein Fehler in der MC Erkennung in Kombination mit der Ersten SR Übertragung.
Das schaue ich mir noch näher an.

Sidey

Sidey · 08 Juni 2016, 23:24:28

Zitat von: bmilos am 08 Juni 2016, 22:59:05
Kann mir vieleicht jeman dhelfen?

Hier ist die Hife:

Code Auswählen


2016.06.08 23:21:25 4: dummyDuino IT: 1527x22870 not defined (Switch code: 1110)
2016.06.08 23:21:25 5: dummyDuino IT: EV1527 housecode = 1527x22870  onoffcode = 1110
2016.06.08 23:21:25 4: dummyDuino IT: msgcode "" (0) bin = 001000101000011100001110
2016.06.08 23:21:25 4: dummyDuino IT: message "i22870E" (7)
2016.06.08 23:21:25 5: dummyDuino dispatch i22870E
2016.06.08 23:21:25 5: dummyDuino: converted Data to (i22870E)
2016.06.08 23:21:25 4: dummyDuino: Decoded MS Protocol id 45 dmsg i22870E length 24
2016.06.08 23:21:25 5: dummyDuino: Starting demodulation at Position 2
2016.06.08 23:21:25 4: dummyDuino: Matched MS Protocol id 45 -> revolt
2016.06.08 23:21:25 4: dummyDuino/msg get raw: MS;P0=1121;P1=-387;P2=462;P3=-1121;P4=-11119;D=24232301232323012301232323230101012323232301010123;CP=2;SP=4;O;

Hast Du eine Idee wie der Name vom Protokoll ist? Ist das Revolt oder vewechsel ich gerade was.

PS: Du musst das FHEM Modul aktualisieren:

Code Auswählen


update all https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r32/controls_signalduino.txt

Grüße Sidey

bmilos · 08 Juni 2016, 23:35:16

Hi,

Vielen Dank.

Hab das Modul aktualisiert, wird nun auch als Revolt angezeigt.
Leider kann ich dir nicht genau sagen, um welches Protokoll es sich genau handelt.

Gruss

habeIchVergessen · 09 Juni 2016, 00:02:44

Zitat von: Sidey am 08 Juni 2016, 23:13:42
SC;R=6;SR;P0=-2720;P1=2720;P2=4760;P3=-680;D=101010101010102;SM;C=690;D=A1B1B1B02A1200;SR;P0=-31320;D=0;

clock für Manchester senden ist 690 (s. SM).

Daraus ergeben sich im ersten SR für
P0=-2760   -4 * clock
P1=2760    4 * clock
P2=4830    7 * clock
P3=-690

und im zweiten SR für P0 -33.810 (-49 * clock).

Das entspricht dem Schema aus der culfw und wird wahrscheinlich auch von den SOMFY-Geräten so erwartet. Ob nun 620, 640 oder 690 ist eher egal.
Was empfängt sduino, wenn ein CUL sendet?

bmilos · 09 Juni 2016, 00:15:24

Zitat von: Sidey am 08 Juni 2016, 23:24:28
Hier ist die Hife:
Code Auswählen Erweitern
2016.06.08 23:21:25 4: dummyDuino IT: 1527x22870 not defined (Switch code: 1110) 2016.06.08 23:21:25 5: dummyDuino IT: EV1527 housecode = 1527x22870 onoffcode = 1110 2016.06.08 23:21:25 4: dummyDuino IT: msgcode "" (0) bin = 001000101000011100001110 2016.06.08 23:21:25 4: dummyDuino IT: message "i22870E" (7) 2016.06.08 23:21:25 5: dummyDuino dispatch i22870E 2016.06.08 23:21:25 5: dummyDuino: converted Data to (i22870E) 2016.06.08 23:21:25 4: dummyDuino: Decoded MS Protocol id 45 dmsg i22870E length 24 2016.06.08 23:21:25 5: dummyDuino: Starting demodulation at Position 2 2016.06.08 23:21:25 4: dummyDuino: Matched MS Protocol id 45 -> revolt 2016.06.08 23:21:25 4: dummyDuino/msg get raw: MS;P0=1121;P1=-387;P2=462;P3=-1121;P4=-11119;D=24232301232323012301232323230101012323232301010123;CP=2;SP=4;O;

Hast Du eine Idee wie der Name vom Protokoll ist? Ist das Revolt oder vewechsel ich gerade was.

PS: Du musst das FHEM Modul aktualisieren:
Code Auswählen Erweitern
update all https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r32/controls_signalduino.txt

Grüße Sidey

Nur noch eine blöde Frage, wie müsste ich dies in der Config definieren?
Sry.

Gruss

Ralf9 · 09 Juni 2016, 08:20:17

Zitat von: bmilos am 09 Juni 2016, 00:15:24
Nur noch eine blöde Frage, wie müsste ich dies in der Config definieren?

Damit müsste der Fensterkontakt automatisch per autocreate angelegt werden:

Code Auswählen

update all https://raw.githubusercontent.com/Ralf9/test/master/controls_signalduino.txt
https://forum.fhem.de/index.php/topic,52827.msg445831.html#msg445831

Gruß Ralf

Ralf9 · 09 Juni 2016, 08:56:07

Hallo Sidey,

spricht was dagegen, in der 14_Hideki.pm
hier

Code Auswählen

if (!Hideki_crc(\@decodedBytes))
	{
		Log3 $iohash, 4, "$name crc failed";
		return undef;
	}

das "return undef;" durch

Code Auswählen

return "";
zu ersetzen?
siehe
https://forum.fhem.de/index.php/topic,53680.msg459931.html#msg459931

Gruß Ralf

bmilos · 09 Juni 2016, 20:31:00

Zitat von: Ralf9 am 09 Juni 2016, 08:20:17
Damit müsste der Fensterkontakt automatisch per autocreate angelegt werden:
Code Auswählen Erweitern
update all https://raw.githubusercontent.com/Ralf9/test/master/controls_signalduino.txt
https://forum.fhem.de/index.php/topic,52827.msg445831.html#msg445831

Gruß Ralf

Wow, vielen Dank. Dein pl funktioniert natürlich auch mit nanoCUL

Leider aber wird bei mir nur ein State erkannt:

2016.06.09 20:26:25 3: nanoCUL IT: IT_1527x22870 on->on
2016.06.09 20:26:26 3: nanoCUL IT: Code 1010 not supported by IT_1527x22870.
2016.06.09 20:26:26 3: nanoCUL IT: Code 1010 not supported by IT_1527x22870.
2016.06.09 20:26:26 3: nanoCUL: Unknown code i22870a, help me!

Könnte man die 10_IT.pm noch ein wenig erweitern, damit es volkommen automatisch generiert wird?

Nochmals Vielen Dank, in meinem Fall habe ich die fhem-config von:

define IT_1527x22870 IT 1527x22870 1110 0000

auf:

define IT_1527x22870 IT 1527x22870 1110 1010

geändert und es funktioniert bestens

Gruss