SIGNALDuino Empfänger Firmware V 3.3.2r-dev

[Ralf9]

Hallo,

hier ist für den Arduino eine alternative firmware V 3.3.2.1,
die Entwicklung ist inzwischen abgeschlossen, die aus der V 3.3.1-xx bekannten Fehler sind behoben.
Die Firmware läuft bei mir sehr stabil, ich habe mittlerweile eine uptime von 43 Tagen.
Die firmware kann aber trotzdem noch Fehler enthalten.

Die aktuelle Version ist V 3.3.2.1-rc9
https://github.com/Ralf9/SIGNALDuino/releases/tag/3.3.2.1-rc9


firmware:
V 3.3.2.1-rc9

Code Auswählen Erweitern

nano mit cc1101:
set sduino flash https://github.com/Ralf9/SIGNALDuino/releases/download/3.3.2.1-rc9/SIGNALduino_nanoCC1101_3321rc9.hex

nano ohne cc1101 (z.B. mit RXB6);
set sduino flash https://github.com/Ralf9/SIGNALDuino/releases/download/3.3.2.1-rc9/SIGNALduino_nano328_3321rc9.hex

5V promini ohne cc1101 (z.B. mit RXB6):
set sduino flash https://github.com/Ralf9/SIGNALDuino/releases/download/3.3.2.1-rc9/SIGNALduino_promini_3321rc9.hex

miniCUL:
set sduino flash https://github.com/Ralf9/SIGNALDuino/releases/download/3.3.2.1-rc9/SIGNALduino_miniCUL_3321rc9.hex

3.3V promini mit CC1101
set sduino flash https://github.com/Ralf9/SIGNALDuino/releases/download/3.3.2.1-rc9/SIGNALduino_3v3prominiCC1101_3321rc9.hex
3v3prominiCC1101 ist für diejenigen, die mit einem 3.3V promini und der nanocul Verkabelung einen Signalduino gebaut haben.

V 3.3.2.1-rc8

Code Auswählen Erweitern

nano mit cc1101:
set sduino flash https://raw.githubusercontent.com/Ralf9/SIGNALDuino/dev-r332_cc1101/firmware/SIGNALduino_nanoCC1101_3321rc8.hex

nano ohne cc1101:
set sduino flash https://raw.githubusercontent.com/Ralf9/SIGNALDuino/dev-r332_cc1101/firmware/SIGNALduino_nano_3321rc8.hex

radino:
set sduino flash https://raw.githubusercontent.com/Ralf9/SIGNALDuino/dev-r332_cc1101/firmware/SIGNALduino_radinoCC1101_3321rc8.hex

miniCUL:
set sduino flash https://raw.githubusercontent.com/Ralf9/SIGNALDuino/dev-r332_cc1101/firmware/SIGNALduino_miniCUL_3321rc8.hex

3.3V promini mit CC1101
set sduino flash https://raw.githubusercontent.com/Ralf9/SIGNALDuino/dev-r332_cc1101/firmware/SIGNALduino_3v3prominiCC1101_3321rc8.hex

Im "Information menu" kann unter "Last Flashlog" nachgeschaut werden ob das flashen erfolgreich war.

Wenn die alte firmware älter als V 3.3.2.1-rc6 war, dann müssen noch evtl die Daten im EEPROM auf default zurückgesetzt werden:

Code Auswählen Erweitern

get sduino raw eC Damit werden die config Daten im EEPROM auf default zurückgesetzt.
Ein get config ergibt dann folgendes:

Code Auswählen Erweitern

config: MS=1;MU=1;MC=1;Mred=1;Mdebug=1_MScnt=4;MuSplitThresh=8000;MdebFifoLimit=120/140
Wer die Ausgabe der sehr langen MU-Nachrichten testen möchte, der kann dies mit CEO aktivieren:

Code Auswählen Erweitern

get sduino raw CEO
get sduino raw CDR
Die Ausgabe der sehr langen MU-Nachrichten funktioniert z.Zt. bei der stable (SVN) und offiziellen Entwicklerversion dev-r34 nur bei unkomprimierte Nachrichten (Mred=0).
Ein get config ergibt dann folgendes:

Code Auswählen Erweitern

config: MS=1;MU=1;MC=1;Mred=0;MuNoOverflow=1;Mdebug=1_MScnt=4;MuOverflMax=3;MdebFifoLimit=120/140
Für die Versionen mit 3.3V und 8 MHz ist es nicht zu empfehlen, die komprimierung der Nachrichten (Mred=0) abzuschalten, es kann ab und zu zu FIFO Überläufen
https://forum.fhem.de/index.php/topic,82379.msg899489.html#msg899489
Bei meiner Variante der 00_SIGNALduino.pm, funktioniert auch bei komprimierten Nachrichten die Ausgabe der sehr langen MU-Nachrichten
https://github.com/Ralf9/RFFHEM/issues/2


Ich habe die Ausgabe von get config erweitert und es gibt einige neue konfig Befehle.
Gesendet werden sie mit "get sduino raw"

Code Auswählen Erweitern

CED -> Debugausgaben ein
CDD -> Debugausgaben aus
CDL -> Message-LED aus
CEL -> Message-LED ein
CER -> Einschalten der Datenkomprimierung (config: Mred=1)
CDR -> Abschalten der Datenkomprimierung (config: Mred=0)
CEO -> Einschalten der sehr langen MU-Nachrichten (config: MuNoOverflow=1)
CDO -> Abschalten der sehr langen MU-Nachrichten
CSmscnt=[Wert]     -> Wiederholungszähler für den split von MS Nachrichten
CSmuthresh=[Wert]  -> Schwellwert für den split von MU Nachrichten (0=aus)
CSmcmbl=[Wert]     -> minbitlen für MC-Nachrichten
CSfifolimit=[Wert] -> Schwellwert für debug Ausgabe der Pulsanzahl im FIFO Puffer
CSmuoverflmax=[Wert] -> damit wird die Anzahl der ausgegebenen restlichen Daten (ca Wert * 254) nach einem Überlauf begrenzt

?S -  show configSet commands (z.Zt.:  CSfifolimit= CSmcmbl= CSmscnt= CSmuoverflmax= CSmuthresh= )
eC - initEEPROMconfig.  Damit werden die config Daten im EEPROM auf default zurückgesetzt
In den FIFO Empfangspuffer gehen z.Zt. 140 Pulse, dh. eine Ausgabe von MF=140 bedeutet ein Pufferüberlauf


Es wurden recht viele Fehler beseitigt und einiges optimiert. Der ManchesterDecoder wurde komplett überarbeitet. Der Hideki Empfang hat sich deutich verbessert.

Diese Version ist auf Wiederholungen optimiert.

• Die MS-Wiederholungen werden nun auch hochgezählt.
  Wenn die in mscnt definierten Wiederholungen erreicht sind, werden die restlichen Wiederholungen nicht mehr ausgegeben. Seither konnte es vorkommen, daß die unterdrückten überzähligen Wiederholungen z.T. als MU-Nachrichten ausgegeben wurden.
  Da bei den MS-Wiederholungen nun die sync und clock von der 1.Nachricht verwendet werden, müssen sync und clock nicht mehr erneut ermittelt werden.
  
  
• Wenn bei einer erkannten MS-Nachricht die Länge einer Nachricht kürzer wie die minMessageLen ist, dann wird sie als MU-Nachricht ausgegeben.
  Wird benötigt füe ID 79: VTX-BELL_Funkklingel
  https://github.com/RFD-FHEM/SIGNALDuino/issues/84#issuecomment-360206833
  
  
• Ich habe auch eine Erkennung von Wiederholungen bei MU-Nachrichten eingebaut. Dies ist noch experimentell es kann sein, das dies nicht bei allen MU-Nachrichten funktioniert. Ein w am Ende der Nachricht bedeutet, das eine mögliche Wiederholung erkannt wurde.
  Es gibt eine neue Konfigvariable muthresh, damit wird der Schwellwert für den split von MU Nachrichten festgelegt.
  Mit CSmuthresh=8000 werden z.B. die MU Nachrichten nach einer Pause größer 8 ms gesucht und dort die Nachricht abgetrennt.
  
  
• Bei der Ausgabe von Wiederholungen wird nun ein Patternpuffer Überlauf berücksichtigt.
  Wenn Mdebug=1 dann wird bei einem Patternpuffer Überlauf ein "p" am Ende einer Nachricht angehängt.
  Ein Patternpuffer Überlauf kann z.B. bei Störungen oder überlagerung von Signalen entstehen.
  
  
• Beim MC-Decoder wird nun auch geprüft ob der Manchester Code gültig ist, wenn er ungültig ist, wird er evtl als MU-Nachricht ausgegeben. Dies ist erkennbar am i am Ende der Nachricht. 
  Bei den MC-Nachrichten habe ich auch eine Erkennung von Wiederholungen eingebaut.
  
  
• Ich habe die Senderoutine überarbeitet, es werden nun einige Syntaxprüfungen durchgeführt.
  Nun funktionieren auch sehr lange Sendekommandos. In den hex Files ist die Länge momentan auf 350 Zeichen begrenzt.  In der RF_Receiver_332.ino kann die max Länge geändert werden "#define maxCmdString 240"
  
  
• Das Siro müsste nun auch mit mit aktiviertem MC-Dedoder funktionieren und es werden nun auch die Wiederholungen erkannt.
  
  
• Beim Somfy müsste sich nun die Erkennung der Fernbedienung deutlich verbessert haben.
  
  
• Bei get config wird nun auch hinter dem / die FIFO Größe ausgegeben  (MdebFifoLimit=120/140).
  
  
• Nun können auch sehr lange MU-Nachrichten ausgegeben werden. Mit CEO wird es eingeschaltet und mit CDO ausgeschaltet.
  Normalerweise können nur 254 Pulse ausgegeben werden, ein Überlauf ist an einem "O" am Ende der MU-Nachricht erkennbar.
  Bei aktivierten sehr lange MU-Nachrichten, werden die restlichen Daten hinten an die MU-Nachricht angehängt.
  
  
• Es werden nun auch die sehr langen MC-Nachrichten der neuen Oregon V3 Sensoren unterstützt.
  
  
• Bei MS-Nachrichten wird nun geschaut ob nach dem sync innerhalb der nächsten 10 Einträge weitere sync folgen und diese ggf übersprungen. Bei nicht komprimierten MS-Nachrichten wird dann mit "s<anz> die Anzahl ausgegeben.

16.06.19  V 3.3.2.1-rc9
Es werden nun am Anfang von MS-Nachrichten auch mehrere sync in Folge erkannt und übersprungen.
Z.B. ein Temperatursensor der ID 33 hat am Anfang 14 sync.
Bei der Ausgabe werden nun mit "b" die Position des ersten Sync und mit "s" die Anzahl der sync ausgegeben.
Z.B.: "...01010;CP=1;SP=3;R=6;O;b63;s4;m0;" beim GT-WT-02 Temperatursensor

Nachtrag:

Hier sind ältere Versionen und eine History
https://forum.fhem.de/index.php/topic,82379.msg840645.html#msg840645

Dies ist das firmware Verzeichnis auf github:
https://github.com/Ralf9/SIGNALDuino/tree/dev-r332_cc1101/firmware
oder
https://github.com/Ralf9/SIGNALDuino/releases

Hier ist der Quellcode:
https://github.com/Ralf9/SIGNALDuino/tree/dev-r332_cc1101


Kleine Linkliste

sduino Firmware Befehlsübersicht

Signalduino Version 3.3.1 / 3.3.2 / 3.3.3-dev

günstige Wetterstation CTW-600, WS-0101, WS/WH1080 sduino

Wetterstation WH3080 dekodieren für Signalduino 433Mhz

Somfy via SIGNALduino

Neues Modul: 98_Siro.pm (Ansteuerung von motorisierten Innensichtschutzrollos)

Gruß Ralf

[Invers]

Wenn ich mit dem Befehl
get sduino raw CDL
die LED ausschalten möchte, bleibt diese leider an.
Hast du nen Tipp für mich?
Danke im Voraus.

[Ralf9]

Welche LED möchstest Du ausschalten?
Mit CDL wird das kurze Blinken der LED, wenn eine Nachricht empfangen und ausgegeben wurde, abgeschaltet.
Die LED ist beim nanocul an D9.

Gruß Ralf

[Invers]

Schade, dann war das ein Missverständnis. Schade, aber trotzdem danke.

[Ralf9]

Da bis jetzt noch keine Fehler gefunden wurden scheint diese Test V 3.3.2-dev firmware recht gut zu funktionieren.

Hier ist eine Siro Nachricht als Beispiel für eine MU-Nachricht mit Wiederholungen:

Code Auswählen Erweitern


Ich habe diese Nachricht
MU;P0=-8497;P1=4822;P2=-1523;P3=329;P4=-766;P5=679;P6=-415;D=012345634565634565634563434343434563456565634343434563434343434345634563456345634501234563456563456563456343434343456345656563434343456343434343434563456345634563450123456345656345656345634343434345634565656343434345634343434343456345634563456345;CP=5;
damit gesendet
SR;P0=-8497;P1=4822;P2=-1523;P3=329;P4=-766;P5=679;P6=-415;D=012345634565634565634563434343434563456565634343434563434343434345634563456345634501234563456563456563456343434343456345656563434343456343434343434563456345634563450123456345656345656345634343434345634565656343434345634343434343456345634563456345;

Die empfangene Nachricht wurde dann an den Pulsen -8497 getrennt:
MU;P0=-415;P2=-8497;P3=4822;P4=-1523;P5=329;P6=-766;P7=679;D=2345670567070567070567056565656567056707070565656567056565656565670567056705670567;CP=5;w1;i;
MU;P0=-415;P2=-8497;P3=4822;P4=-1523;P5=329;P6=-766;P7=679;D=2345670567070567070567056565656567056707070565656567056565656565670567056705670567;CP=5;w2;i;
MU;P0=-415;P2=-8497;P3=4822;P4=-1523;P5=329;P6=-766;P7=679;D=2345670567070567070567056565656567056707070565656567056565656565670567056705670567;CP=5;i;

Da hier der MC-Decoder aktiviert war, ist am "i" am Ende zu erkennen, das die Nachricht im MC-Decoder als ungültiger Manchester Code erkannt wurde.


Die Erkennung und Trennung von Wiederholungen bei MU-Nachrichten ist evtl bei Sensoren und Fernbedienungen interessant die als MU-Nachrichten, die Wiederholungen enthalten und keine Prüfsumme haben, interessant.

Wenn mindestens 2 Wiederholungen empfangen werden, kann das sduino Attribut "doubleMsgCheck_IDs" verwendet werden
(Dieses Attribut erlaubt es, Protokolle anzugeben, die zwei gleiche Nachrichten enthalten müssen, um diese an die Module zu übergeben).
Ich habe es erfolgreich mit den ProtokollIds 0,3,7 getestet.

Damit tauchen dann solche Logeinträge gar nicht mehr oder nur noch sehr selten auf:

Code Auswählen Erweitern

2018.01.18 23:36:56 1: sduinoDo SD_WS07: UNDEFINED sensor SD_WS07_TH_022 detected, code P7#0290B0F2A
2018.01.19 04:14:46 1: sduinoDo SD_WS07: UNDEFINED sensor SD_WS07_TH_2D1 detected, code P7#2D80CBF2E

Gruß Ralf

[Invers]

Nach dem heutigen Update werden die Positionen gespeichert und wiederhergestellt. Vielen Dank.

Ich habe im Log noch eine weitere Meldung gefunden.
Nachts fahre ich ein Rollo runter auf 80 Prozent zu. bei diesem Manöver entstehen die folgenden Meldungen:

Code Auswählen Erweitern


2018.01.23 00:16:37 3: Siro_set: handing over to Siro_Send_Command with following arguments: off 80 0
2018.01.23 00:16:37 3: Siro_sendCommand: execute comand off - sendMsg to HASH(0x44866d8) channel 4 -> P72#1000010000110001010011001101010000010001#R8
2018.01.23 00:16:40 3: Siro_sendCommand: execute comand stop - sendMsg to HASH(0x44866d8) channel 4 -> P72#1000010000110001010011001101010001010101#R8
2018.01.23 00:17:07 3: Siro_set: handing over to Siro_Send_Command with following arguments: position 80 0
2018.01.23 00:17:07 1: PERL WARNING: Use of uninitialized value $command in hex at ./FHEM/98_Siro.pm line 420.
2018.01.23 00:17:07 3: Siro_sendCommand: execute comand position - sendMsg to HASH(0x44866d8) channel 4 -> P72#1000010000110001010011001101010000000000#R8
2018.01.23 00:17:07 3: Siro_sendCommand: execute comand stop - sendMsg to HASH(0x44866d8) channel 4 -> P72#1000010000110001010011001101010001010101#R8


Ich sende den Code zur Sicherheit doppelt, aber mit Verzögerung.
Da die Meldung beim 2. Versand kommt, denke ich , dass es ein Problem mit der Auswertung gibt, wenn die gewünschte Position bereits angefahren ist.
Meine Tests bestätigen den Verdacht.
Kann man da noch etwas machen?

Wunsch:
Da Siro ja keine Rückmeldung liefert, ist der Beatteriestand nicht zu erkennen. Es ist äusserst lästig, wenn plötzlich ein Rollo nicht auf- oder zugeht.
Ich habe daher ermittelt, wie lange eine Ladung reicht. Bei mir sind es 45 Tage, dann muss ich unbedingt laden.
Das ist interessanter Weise bei allen Rollos gleich, egal, wie lang die sind. Merkwürdig, aber egal. Umso besser.
Meine Idee wäre nun, ein Attribut setzen zu können, wo man eine Tageszahl  für den Ladezyklus angeben kann und man wird dann automatisch erinnert, wenn das Rollo einen Tag vorher bedient wird. Das Setzen eines Readings würde schon reichen, kann man ja selber weiter verwerten.
Ladezyklus kann man natürlich auch separat machen (DOIF), aber komfortabler wäre vielleicht eine solche Funktion im Modul.

Sollte die Idee allerdings Blödsinn sein, dann bitte einfach ignorieren.

Danke nochmals für die Fehlerbeseitigung.

[Ralf9]

Nach dem heutigen Update werden die Positionen gespeichert und wiederhergestellt. Vielen Dank.

Dies passt hier nicht so richtig rein, für Siro gibt es ein eigenes Thema.

Gruß Ralf

[MogRuith]

Sorry für Doppelpost, ist hier wahrscheinlich besser aufgehoben...

Hallo beisammen,
ich steuere meine Somfy-Rollläden seit einiger Zeit erfolgreich mit per Signalduino auf einem 433er NanoCUL/CC1101, nur der einwandfreie Empfang will einfach nicht gelingen. Es wird so einiges empfangen, aber trotz autocreate keine neuen devices angelegt oder sonstwas sinnvolles übertragen. Im log kommt nur "sduino: Unknown code YsACBBBA5AAC81668, help me!"...

Dabei habe ich schone einige Firmware- und Modul-Versionen ausprobiert, aber nichts hilft. Auch ist der Abstand zum sduino egal oder ob ich lange oder nur kurz den Sender (Telis 6 Chronis RTS) drücke. Anbei das listing vom sduino und einiges aus dem log mit der Bitte um Hilfe/Unterstützung. Vielen Dank im Voraus.

listing vom sduino

Code Auswählen Erweitern

Internals:
   Clients    :IT:CUL_TCM97001:SD_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: :FS10:CUL_FHTTK:Siro:FHT:FS20:SIGNALduino_un:
   DEF        /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9KFRPLT-if00-port0@57600
   DMSG       YsCB55902CD08003A
   DevState   initialized
   DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9KFRPLT-if00-port0@57600
   FD         10
   LASTDMSG   YsCB55902CD08003A
   MSGCNT     18
   NAME       sduino
   NR         19
   PARTIAL   
   RAWMSG     MC;LL=-1299;LH=1308;SL=-608;SH=657;D=CB55902CD08003A;C=645;L=59;R=117;s3;b0;
   RSSI       -15.5
   STATE      opened
   TIME       1516467896
   TYPE       SIGNALduino
   sendworking 0
   unknownmessages
   version    V 3.3.2-dev SIGNALduino cc1101 - compiled at Jan  7 2018 19:20:14
   DoubleMsgIDs:
   MatchList:
     10:SD_WS07 ^P7#[A-Fa-f0-9]{6}F[A-Fa-f0-9]{2}(#R[A-F0-9][A-F0-9]){0,1}$
     11:SD_WS09 ^P9#F[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   ^Ys[0-9A-F]+
     16:SD_WS_Maverick ^P47#[A-Fa-f0-9]+
     17:SD_UT   ^u30#.*
     18:FLAMINGO ^P13#[A-Fa-f0-9]+
     19:CUL_WS  ^K[A-Fa-f0-9]{5,}
     1:IT       ^i......
     20:Revolt  ^r[A-Fa-f0-9]{22}
     21:FS10    ^P61#[A-F0-9]+
     22:Siro    ^P72#[A-Fa-f0-9]+
     23:FHT     ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
     24:FS20    ^81..(04|0c)..0101a001
     2:CUL_TCM97001 ^s[A-Fa-f0-9]+
     3:SD_RSL   ^P1#[A-Fa-f0-9]{8}
     4:OREGON   ^(3[8-9A-F]|[4-6][0-9A-F]|7[0-8]).*
     5:CUL_TX   ^TX..........
     6:SD_AS    ^P2#[A-Fa-f0-9]{7,8}
     7:Hideki   ^P12#75[A-F0-9]+
     9:CUL_FHTTK ^T[A-F0-9]{8}
     X:SIGNALduino_un ^[u]\d+#.*
   QUEUE:
   READINGS:
     2018-01-20 18:02:34   ccconf          freq:433.420MHz bWidth:325KHz rAmpl:42dB sens:16dB  (DataRate:824.45Baud)
     2018-01-20 04:24:10   ccreg           C3E = 00 C0 00 00 00 00 00 00
     2018-01-20 17:25:54   config          MS=1;MU=1;MC=1;Mred=1;Mdebug=1_MScnt=3;MuSplitThresh=7000;MdebFifoLimit=80
     2018-01-27 12:27:35   ping            OK
     2018-01-20 15:03:02   state           opened
     2018-01-20 15:03:02   version         V 3.3.2-dev SIGNALduino cc1101 - compiled at Jan  7 2018 19:20:14
   getcmd:
   keepalive:
     ok         1
     retry      0
   mcIdList:
     43
   msIdList:
   muIdList:
Attributes:
   event-on-change-reading .*
   flashCommand avrdude -c arduino -b [BAUDRATE] -P [PORT] -p atmega328p -vv -U flash:w:[HEXFILE] 2>[LOGFILE]
   group      Transceiver
   hardware   nanoCC1101
   icon       cul_usb
   room       System
   verbose    3
   whitelist_IDs 43


log bei verbose=4

Code Auswählen Erweitern

2018.01.20 18:04:23 4: sduino/msg READ: MC;LL=-1108;LH=1460;SL=-448;SH=851;D=AAB6B6;C=644;L=23;R=25;s43;b43;w;
2018.01.20 18:04:24 4: sduino/msg READredu: MU;P0=844;P1=-429;P2=1522;P3=-1096;P5=-320;P6=-2294;P7=2701;D=0123012321030125030101010101230121032103232323010123232101010101010101010103230101210676767676767;CP=0;R=26;
2018.01.20 18:04:24 4: sduino/msg READredu: MU;P0=2724;P1=-1013;P2=1539;P3=925;P4=-483;P6=-311;P7=-1532;D=121212121213421342121342134342134212431342431343434343421342431243121212134342134243434363634363636363631362634313637;CP=3;R=26;
2018.01.20 18:04:24 4: sduino/msg READ: MC;LL=-1180;LH=1436;SL=-447;SH=795;D=AAB6B7699FB255D8;C=642;L=61;R=26;s2;b2;
2018.01.20 18:04:24 4: sduino: Found manchester Protocol id 43 clock 642 RSSI -61 -> Somfy RTS
2018.01.20 18:04:24 4: sduino: Somfy bitdata: 1010101010110110101101110110100110011111101100100101010111011000 (61)
2018.01.20 18:04:24 1: sduino: SOMFY_Parse : Somfy RTS message format error (length)! :AAB6B7699FB255D8:
2018.01.20 18:04:24 3: sduino: Unknown code YsAAB6B7699FB255D8, help me!
2018.01.20 18:04:24 4: sduino/msg READredu: MU;P0=2774;P1=-305;P2=1515;P3=-168;P4=938;P5=-470;P6=-972;P7=-2290;D=1234545414141414141414641452645270707070707070;CP=4;R=25;
2018.01.20 18:04:24 4: sduino/msg READredu: MU;P0=791;P1=-308;P2=1517;P3=-983;P5=-486;D=123052325030525030505050505230525032503232323050505250505050505050101010101032105050301;CP=0;R=26;
2018.01.20 18:04:24 4: sduino/msg READredu: MU;P0=-2195;P1=2802;P2=5068;P3=-1096;P4=1517;P5=812;P6=-447;D=0101010101010234343434343564356434356435656435643465356465356565656564356465346534343435656564653;CP=5;R=25;
2018.01.20 18:04:24 4: sduino/msg READ: MC;LL=-1116;LH=1446;SL=-550;SH=835;D=B4CFD8;C=657;L=22;R=23;s17;b17;
2018.01.20 18:04:24 4: sduino/msg READredu: MU;P0=5076;P1=-316;P2=823;P3=-418;P4=-1116;P5=1445;P6=-2257;P7=2731;D=1212323245454215126767676767676045454545454;CP=5;R=26;
2018.01.20 18:04:24 4: sduino/msg READ: MC;LL=-1123;LH=1470;SL=-457;SH=800;D=B5BB4CFD92AD6;C=641;L=52;R=23;s1;b0;
2018.01.20 18:04:32 4: sduino/msg READ: MC;LL=-1114;LH=1453;SL=-525;SH=753;D=ABB7B6;C=640;L=24;R=28;s25;b25;w;
2018.01.20 18:04:32 4: sduino/msg READ: MC;LL=-1131;LH=1452;SL=-464;SH=880;D=ABB7B60;C=654;L=25;R=26;s20;b20;w;
2018.01.20 18:04:32 4: sduino/msg READredu: MU;P0=-1043;P1=859;P2=-432;P3=1476;P6=-302;P7=-593;D=0123032101236101212121712301732103210303030123216121032121212171212121212121210121230;CP=1;R=27;
2018.01.20 18:04:46 4: sduino/msg READ: MC;LL=-1324;LH=1190;SL=-651;SH=640;D=ACBBBA5AAC81668;C=634;L=58;R=111;s1;b1;w;
2018.01.20 18:04:46 4: sduino: Found manchester Protocol id 43 clock 634 RSSI -18.5 -> Somfy RTS
2018.01.20 18:04:46 4: sduino: Somfy bitdata: 101011001011101110111010010110101010110010000001011001101000 (58)
2018.01.20 18:04:46 1: sduino: SOMFY_Parse : Somfy RTS message format error (length)! :ACBBBA5AAC81668:
2018.01.20 18:04:46 3: sduino: Unknown code YsACBBBA5AAC81668, help me!

[Thorsten80]

Ist es möglich ein kompiliertes hex file der aktuellsten Firmware für radino zu bekommen?
Habe bei Github keins gefunden.

Besten Dank!

Grüße

Thorsten

[Ralf9]

Ist es möglich ein kompiliertes hex file der aktuellsten Firmware für radino zu bekommen?

Ja, ist geplant, kann aber noch etwas dauern. Ich bin z.Zt. dabei an der Firmware noch einiges zu optimieren und zu erweitern.

Gruß Ralf

[Ralf9]

Ich habe in der Firmware noch einiges optimiert und erweitert:


Wenn bei einer erkannten MS-Nachricht die Länge einer Nachricht kürzer wie die minMessageLen ist, dann wird sie als MU-Nachricht ausgegeben.
Wird benötigt füe ID 79: VTX-BELL_Funkklingel
https://github.com/RFD-FHEM/SIGNALDuino/issues/84#issuecomment-360206833


Die MS-Wiederholungen werden nun auch hochgezählt.
Wenn die in mscnt definierten Wiederholungen erreicht sind, werden die restlichen Wiederholungen nicht mehr ausgegeben. Seither konnte es vorkommen, daß die unterdrückten überzähligen Wiederholungen z.T. als MU-Nachrichten ausgegeben wurden.
Da bei den MS-Wiederholungen nun die sync und clock von der 1.Nachricht verwendet werden, müssen sync und clock nicht mehr erneut ermittelt werden.


Bei der Ausgabe von Wiederholungen wird nun ein Patternpuffer Überlauf berücksichtigt.
Wenn Mdebug=1 dann wird bei einem Patternpuffer Überlauf ein "p" am Ende einer Nachricht angehängt.
Ein Patternpuffer Überlauf kann z.B. bei Störungen oder überlagerung von Signalen entstehen.


Es gibt nun zwei neue Kommandos:

Code Auswählen Erweitern

?S -  show configSet commands (z.Zt.:  fifolimit mcmbl mscnt muthresh)

eC - initEEPROMconfig
     Damit werden die config Daten im EEPROM auf default zurückgesetzt


Außerdem habe ich noch die configSet Kommandos in Arrays gelegt:

Code Auswählen Erweitern

#define CSetAnz 4
const char *CSetCmd[] = {"fifolimit", "mcmbl", "mscnt", "muthresh", "L"};
const uint8_t CSetAddr[] = {  0xf0,     0xf1,    0xf2,     0xf3,   0xf4};
const uint8_t CSetDef[] =  {    80,       0,       4,     0x1f,   0x40};

Belegt das "char *CSetCmd" so nur im Programmspeicher Platz oder belegt es auch Platz im RAM?

Gruß Ralf

[Ralf9]

const char *CSetCmd[] = {"fifolimit", "mcmbl", "mscnt", "muthresh", "L"};

Belegt das "char *CSetCmd" so nur im Programmspeicher Platz oder belegt es auch Platz im RAM?

Momentan spielt es keine Rolle ob es Platz im RAM belegt, da noch genügend RAM frei ist.
Aber falls noch mehr set-Befehle dazu kommen, ist es besser, wenn das char *CSetCmd keinen Platz im RAM belegt.
Da bis jetzt noch keiner was dazu geschrieben hat.  Kann ich davon ausgehen, daß es so passt und durch das const keinen Platz im RAM belegt?


Ich habe seither mit der Arduino IDE 1.6.5 compiliert. Nun habe ich auch mal mit der Arduino IDE 1.8.5 compiliert.
Dabei ist mir aufgefallen, daß der Code mit der DE 1.8.5 zwar deutlich kleiner ist, aber das mit "get sduino R" angezeigte freeram ist deutlich weniger.
Ist dies normal?

Bei der IDE 1.6.5 bekomme ich mit "get sduino R"  600
Nach dem compilieren (ohne cc1101) bekomme ich:
Der Sketch verwendet 30.212 Bytes (98%) des Programmspeicherplatzes. Das Maximum sind 30.720 Bytes.
Globale Variablen verwenden 1.075 Bytes (52%) des dynamischen Speichers, 973 Bytes für lokale Variablen verbleiben. Das Maximum sind 2.048 Bytes.

IDE 1.8.5 bekomme ich mit "get sduino R"  541
Nach dem compilieren (ohne cc1101) bekomme ich:
Der Sketch verwendet 23550 Bytes (76%) des Programmspeicherplatzes. Das Maximum sind 30720 Bytes.
Globale Variablen verwenden 1000 Bytes (48%) des dynamischen Speichers, 1048 Bytes für lokale Variablen verbleiben. Das Maximum sind 2048 Bytes.

Hier ist der Code von freeram:

Code Auswählen Erweitern

  extern int __heap_start, *__brkval;
  int v;
  return (int) &v - (__brkval == 0 ? (int) &__heap_start : (int) __brkval);

Gruß Ralf

[Ralf9]

Belegt das "char *CSetCmd" so nur im Programmspeicher Platz oder belegt es auch Platz im RAM?

Hier habe ich was dazu gefunden:
https://www.arduino.cc/reference/en/language/variables/utilities/progmem/

Demnach muss ich dies

Code Auswählen Erweitern

const char *CSetCmd[] = {"fifolimit", "mcmbl", "mscnt", "muthresh"};

durch das hier ersetzen. Ist dies so ok?

Code Auswählen Erweitern

#define CSetAnz 4
const char string_0[] PROGMEM = "fifolimit";
const char string_1[] PROGMEM = "mcmbl";
const char string_2[] PROGMEM = "mscnt";
const char string_3[] PROGMEM = "muthresh";

const char* const CSetCmd_table[] PROGMEM = {string_0, string_1, string_2, string_3};

// Funktion
char * CSetCmd(uint8_t n)
{
   char buffer[10];
   strcpy_P(buffer, (char*)pgm_read_word(&(CSetCmd_table[n])));
   return buffer;
}

Nachtrag:
Das CSetCmd() wird u.a. hier verwendet:

Code Auswählen Erweitern

  if (cmdstring.charAt(0) == cmd_ping){
getPing();
  }  // ?: Kommandos anzeigen
  else if (cmdstring.charAt(0) == cmd_help) {
    if (cmdstring.charAt(1) == 'S') {
for (uint8_t i = 0; i < CSetAnz; i++) {
    MSG_PRINT(CSetCmd[i]);
    MSG_PRINT(" ");
        }
MSG_PRINTLN("");
    } else {

Code Auswählen Erweitern

inline void configSET()
{
uint8_t i = cmdstring.indexOf("=",4);
uint8_t n = 0;
uint8_t val;
while (n < CSetAnz) {
if (cmdstring.substring(2, i) == CSetCmd[n]) {
MSG_PRINT(CSetCmd[n]);
MSG_PRINT("=");
...
break;
}
n++;
}
...


Gruß Ralf

[Ralf9]

Ist es möglich ein kompiliertes hex file der aktuellsten Firmware für radino zu bekommen?

Hier ist ein aktuelles kompiliertes hex file (SIGNALduino_radinoCC1101_332r.hex). Da ich keine radino habe, konnte ich nicht testen ob ich es richtig kompiliert habe
https://github.com/Ralf9/SIGNALDuino/tree/dev-r332_cc1101/firmware

Bitte schau mal ob diese kurze Anleitung fürs flashen ausreichend ist:
https://forum.fhem.de/index.php/topic,58397.msg762083.html#msg762083

Gruß Ralf

[Ralf9]

Hier sind die Hexfile für die neue Testversion V 3.3.2b-dev
https://github.com/Ralf9/SIGNALDuino/tree/dev-r332_cc1101/firmware

Bitte mal schauen ob diese kurze Anleitung fürs flashen ausreichend ist:
https://forum.fhem.de/index.php/topic,58397.msg762083.html#msg762083

Ich habe die folgenden Protokoll IDs getestet:
0
3  (ITv1)
7
9 (Wetterstation WH3080)
12  (Hideki), die ID 12.1 wird nun nicht mehr benötigt.
18  (OSV1)
61 (FS10)


Bei Somfy (43) ist der Empfang nun deutlich zuverlässiger
https://forum.fhem.de/index.php/topic,53319.msg764241.html

Es wäre schön, wenn ich zu den folgenden Protokollen Rückmeldungen bekommen würde:

Bei Siro werden nun noch mehr Wiederholungen erkannt. Der MC-Decoder muß nun nicht mehr deaktiviert werden.

Bei FS20 und FHT80 muß der MC-Decoder nun nicht mehr deaktiviert werden.

Das Maverick Funk Grillthermometer (ET 732/733) muß noch getestet werden.

Bei OSV3 müssten alle Sensoren funktionieren.

Bei OSV2 benötige ich noch log Auszüge mit verbose 4
Der THN132N sollte funktionieren
Bei den anderen wie z.B. THGR228N, kann es sein, daß sie noch nicht funktionieren.

Edit: 15.02. 2018
Ich habe in der ersten Nachricht die Beschreibung aktualisiert.

Edit: 22.02.2018
OSV3 mit dem THGR810 getestet.
OSV2 auch mit THGR228N getestet.
Ob die 3  folgenden BTHR sauber erkannt werden, kann ich nicht abschätzen, da sich niemand gemeldet hat der die BTHR hat.
Evtl sind für die BTHR noch Anpassungen in der Firmware notwendig.
BTHR918 oder BTHR918N oder  BTHR968

Gruß Ralf