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-rc9https://github.com/Ralf9/SIGNALDuino/releases
Da nun bei den MU-Nachrichten das CP=x und R=xx vor den Daten ausgegeben wird, funktioniert diese Version erst mit einer 00_SIGNALduino.pm aus dem normalen fhem update ab 2019-02-20 21:46:10Z
oder der Entwicklerversion.
update all https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r34/controls_signalduino.txthttps://wiki.fhem.de/wiki/SIGNALduino#FHEM-Modul_laden
firmware:V 3.3.2.1-rc9
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
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:
get sduino raw eC Damit werden die config Daten im EEPROM auf default zurückgesetzt.
Ein get config ergibt dann folgendes:
config: MS=1;MU=1;MC=1;Mred=1;Mdebug=1_MScnt=4;MuSplitThresh=8000;MdebFifoLimit=120/140Wer die Ausgabe der sehr langen MU-Nachrichten testen möchte, der kann dies mit CEO aktivieren:
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:
config: MS=1;MU=1;MC=1;Mred=0;MuNoOverflow=1;Mdebug=1_MScnt=4;MuOverflMax=3;MdebFifoLimit=120/140Fü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"
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ückgesetztIn 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-rc9Es 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 Linklistesduino Firmware Befehlsübersicht (https://forum.fhem.de/index.php/topic,58396.msg497921.html#msg497921)
Signalduino Version 3.3.1 / 3.3.2 / 3.3.3-dev (https://forum.fhem.de/index.php/topic,58397.0.html)
günstige Wetterstation CTW-600, WS-0101, WS/WH1080 sduino (https://forum.fhem.de/index.php/topic,39451.0.html)
Wetterstation WH3080 dekodieren für Signalduino 433Mhz (https://forum.fhem.de/index.php/topic,67587.0.html)
Somfy via SIGNALduino (https://wiki.fhem.de/wiki/Somfy_via_SIGNALduino)
Neues Modul: 98_Siro.pm (Ansteuerung von motorisierten Innensichtschutzrollos) (https://forum.fhem.de/index.php/topic,77167.0.html)
Gruß Ralf
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.
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
Schade, dann war das ein Missverständnis. Schade, aber trotzdem danke.
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:
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:
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
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:
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.
ZitatNach 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
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
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
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!
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
ZitatIst 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
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:
?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:
#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
ZitatZitatconst 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:
extern int __heap_start, *__brkval;
int v;
return (int) &v - (__brkval == 0 ? (int) &__heap_start : (int) __brkval);Gruß Ralf
ZitatBelegt 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
const char *CSetCmd[] = {"fifolimit", "mcmbl", "mscnt", "muthresh"};durch das hier ersetzen. Ist dies so ok?
#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:
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 {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
Zitat von: Thorsten80 am 27 Januar 2018, 21:27:21
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
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
Zitat von: Ralf9 am 15 Februar 2018, 00:04:39
Bei Siro werden nun noch mehr Wiederholungen erkannt. Der MC-Decoder muß nun nicht mehr deaktiviert werden.
Hi Ralf,
ich werde wohl erst am Wochenende dazu kommen, gebe dir dann aber bescheid.
gruss Byte09
Zitat von: KölnSolar am 23 Februar 2018, 12:49:45
Ab und zu hab ich u20er unterschiedlicher Länge, wo ich mir keinen Reim drauf machen kann. Manchmal u61er, die vom nicht immer erkannten IT-PIR1000 stammen.
Ich vermisse regelmäßige Meldungen meiner FA21RFFA20RF(u13). Testauslösung ist mir zu laut ;D
Wenn ich etwas testen soll, melde Dich.
Hallo Markus,
Mich interessieren die raw-Nachrichten (MS oder MU) vom IT-PIR1000.
Ebenso sind auch die raw-Nachrichten vom FA20RF interessant.
Die raw-Nachrichten bekommst Du mit
attr sduino verbose 4Eine andere Möglichkeit ist das
attr sduino rawmsgEvent 1damit werden dann die raw-Nachrichten als event ausgegeben.
Gruß Ralf
Hallo Ralph,
Danke für die neue Version. Sehr gerne werde ich das Maverick 732 Grillthermometer testen. Wird aber voraussichtlich etwas dauern, da ich mir den Signalduino erst wieder zusammen bauen muss.
VG,
Dirk
Hi Ralf,
attr sduino rawmsgEvent 1
find ich klasse
PIR100 ist dabei. Aber bestimmt auch Revolts2018-02-23 21:36:19 SIGNALduino Sduino RAWMSG MS;P0=-9498;P1=234;P2=-2586;P3=-296;P4=-1081;D=0121314131413141413141313141413141313141314131414131314131414131314131414131314131413141314141313141413131413141413141313141314141310;CP=1;SP=2;R=15;O;m=0;
2018-02-23 21:36:19 IT IT_V3_d892149 on
2018-02-23 21:36:19 SIGNALduino Sduino RAWMSG MS;P1=246;P2=-2587;P3=-298;P4=-1097;P6=-9464;D=121314131413141413141313141413141313141314131414131314131414131314131414131314131413141314141313141413131413141413141313141314141316;CP=1;SP=2;R=15;O;m=1;
2018-02-23 21:36:19 SIGNALduino Sduino RAWMSG MS;P0=-9484;P1=223;P2=-2583;P3=-317;P4=-1111;P7=-268;D=121314131413141413141313141413141317141314131414131314131414131314131414131314131413141314141313141413131413141413141313141314141310;CP=1;SP=2;R=15;O;m=2;
2018-02-23 21:36:19 SIGNALduino Sduino RAWMSG MS;P0=-9458;P1=244;P2=-2576;P3=-287;P4=-1068;D=0121314131413141413141313141413141313141314131414131314131414131314131414131314131413141314141313141413131413141413141313141314141310;CP=1;SP=2;R=5;O;m=0;
2018-02-23 21:36:19 SIGNALduino Sduino RAWMSG MS;P1=244;P2=-2576;P3=-287;P4=-1088;D=12131413141314141314131314141314131314131413141413131413141413131413141413131413141314131414131314141313141314141314131314;CP=1;SP=2;R=5;e;m=1;
2018-02-23 21:36:19 SIGNALduino Sduino UNKNOWNCODE i569A5659655996900
2018-02-23 21:36:19 SIGNALduino Sduino RAWMSG MU;P0=-231;P1=138;P2=255;P3=99;D=010101010201010101020201010201010201020101010102010201020202010202030102020201010203010101010101010101010101020101010102020101020101020102010101010201020102020201020203010;CP=1;R=48;e;
2018-02-23 21:36:20 SIGNALduino Sduino RAWMSG MS;P0=-299;P1=245;P2=-1081;P6=-9466;P7=-2550;D=171012101210121210121010121210121010121012101212101012101212101012101212101012101210121012121010121210101210121210121010121012121016;CP=1;SP=7;R=14;O;m=0;
2018-02-23 21:36:20 IT IT_V3_d892149 on
2018-02-23 21:36:20 SIGNALduino Sduino RAWMSG MS;P0=-9472;P1=249;P2=-2584;P3=-291;P4=-1077;D=0121314131413141413141313141413141313141314131414131314131414131314131414131314131413141314141313141413131413141413141313141314141310;CP=1;SP=2;R=8;O;m=0;
2018-02-23 21:36:20 SIGNALduino Sduino RAWMSG MS;P1=246;P2=-2570;P3=-290;P4=-1089;P6=-9468;D=121314131413141413141313141413141313141314131414131314131414131314131414131314131413141314141313141413131413141413141313141314141316;CP=1;SP=2;R=8;O;m=1;
2018-02-23 21:36:20 SIGNALduino Sduino RAWMSG MS;P0=-9464;P1=256;P2=-2571;P3=-278;P4=-1082;P7=-257;D=121314131413141413141313141413141317141714171414131314131414131314131414131314131413141314141313141413131413141413141313141314141310;CP=1;SP=2;R=8;O;m=2;
2018-02-23 21:36:20 SIGNALduino Sduino RAWMSG MS;P0=-9466;P1=257;P2=-2562;P3=-273;P4=-1076;D=0121314131413141413141313141413141313141314131414131314131414131314131414131314131413141314141313141413131413141413141313141314141310;CP=1;SP=2;R=10;O;m=0;
2018-02-23 21:36:20 SIGNALduino Sduino RAWMSG MS;P1=248;P2=-2575;P3=-287;P4=-1078;P5=-9484;D=121314131413141413141313141413141313141314131414131314131414131314131414131314131413141314141313141413131413141413141313141314141315;CP=1;SP=2;R=10;O;m=1;
2018-02-23 21:36:20 SIGNALduino Sduino RAWMSG MS;P1=256;P2=-2561;P3=-283;P4=-1090;P6=-9448;D=121314131413141413141313141413141313141314131414131314131414131314131414131314131413141314141313141413131413141413141313141314141316;CP=1;SP=2;R=10;O;m=2;
2018-02-23 21:36:20 SIGNALduino Sduino RAWMSG MS;P1=244;P2=-2561;P3=-283;P4=-1090;P7=-270;D=121314131413141413141317141413141317141714131414131314131414131314131414131314131413141314141313141413131413141413141313141;CP=1;SP=2;R=10;e;m=3;
2018-02-23 21:36:20 SIGNALduino Sduino RAWMSG MS;P1=231;P2=-1101;P4=-288;P6=-2588;D=516141214121412121412141412121412141412141214121214141214121214141214121214141214121412141212141412121414121412121412141412141212141;CP=1;SP=6;R=12;e;
2018-02-23 21:36:22 SIGNALduino Sduino RAWMSG MU;P0=-231;P1=127;P3=92;P4=255;D=01010101010101010101010101010101030101040401010401010101010101010101010101040101010104040101040101040104010101010401040104040401040401010404010401040101010401040;CP=1;R=51;e;
2018-02-23 21:36:23 SIGNALduino Sduino RAWMSG MU;P0=-9472;P1=-2592;P2=-298;P3=-3712;P4=257;P5=-1077;D=45424245424542454542424542454542424542454542424542454245424545424245454242454245424545424245424545424041424542454245454245424245454245424245424542454542424542454542424542454542424542454245424545424245454242454245424545424245424545424;CP=4;R=10;p;
2018-02-23 21:36:23 SIGNALduino Sduino RAWMSG MU;P0=-2580;P1=-329;P2=248;P3=-156;P4=332;P5=-204;P6=-1081;P7=-9472;D=3452626212126212621262621212621262621272021262126212626212621212626212621;CP=2;R=14;p;
2018-02-23 21:36:23 SIGNALduino Sduino RAWMSG MS;P0=-295;P1=241;P2=-1080;P3=-9496;P4=-2580;D=3141012101210121210121010121210121010121012101212101012101212101012101212101012101210121012121010121210101210121012121010121012121013;CP=1;SP=4;R=15;O;m=0;
2018-02-23 21:36:23 IT IT_V3_d892149 off
2018-02-23 21:36:24 SIGNALduino Sduino RAWMSG MS;P0=-283;P1=253;P2=-1093;P4=-2574;P6=-268;P7=-9488;D=141012101210121210121010121210121016121012101212101012101212101012101212101012101210121012121010121210101210121012121010121012121017;CP=1;SP=4;R=13;O;m=1;
2018-02-23 21:36:24 SIGNALduino Sduino RAWMSG MU;P0=-2582;P1=232;P2=-304;P3=-1106;P4=-9492;D=0121312131213131213121213131213121213121312131312121312131312121312131312121312131213121313121213131212131213121313121213121313121410121312131213131213121213131213121213121312131312121312131312121312131312121312131213121313121213131212131213121313121213;CP=1;R=14;O;
2018-02-23 21:36:24 SIGNALduino Sduino RAWMSG MU;P0=-295;P1=229;P2=-1107;P4=-9468;P5=-2592;D=0101012121010121012101212101210101212101210101210121012121010121012121010121012121010121012101210121210101212101012101210121210101210121210141510121012101212101210101212101210101210121012121010121012121010121012121010121012101210121210101212101012101210;CP=1;R=13;O;
2018-02-23 21:36:24 SIGNALduino Sduino RAWMSG MS;P0=-1099;P1=233;P2=-308;P3=-9480;P4=-2582;D=3141210121012101012101212101012101212101210121010121210121010121210121010121210121012101210101212101012121012101210101212101210101213;CP=1;SP=4;R=13;O;m=0;
2018-02-23 21:36:24 SIGNALduino Sduino RAWMSG MS;P0=-1104;P1=239;P2=-291;P4=-2587;P6=-9480;D=141210121012101012101212101012101212101210121010121210121010121210121010121210121012101210101212101012121012101210101212101210101216;CP=1;SP=4;R=13;O;m=1;
2018-02-23 21:36:24 SIGNALduino Sduino RAWMSG MU;P0=-2586;P1=227;P2=-318;P3=-1106;P4=-9476;D=0121312131213131213121213131213121213121312131312121312131312121312131312121312131213121313121213131212131213121313121213121313121410121312131213131213121213131213121213121312131312121312131312121312131312121312131213121313121213131212131213121313121213;CP=1;R=14;O;
2018-02-23 21:36:24 SIGNALduino Sduino RAWMSG MU;P0=-286;P1=233;P2=-1112;P3=-9492;P4=-2568;D=0101012121010121012101212101210101212101210101210121012121010121012121010121012121010121012101210121210101212101012101210121210101210121210131410121012101212101210101212101210101210121012121010121012121010121012121010121012101210121210101212101012101210;CP=1;R=13;O;
2018-02-23 21:36:24 SIGNALduino Sduino RAWMSG MS;P0=-1098;P1=234;P2=-317;P3=-9496;P4=-2576;D=3141210121012101012101212101012101212101210121010121210121010121210121010121210121012101210101212101012121012101210101212101210101213;CP=1;SP=4;R=13;O;m=0;
2018-02-23 21:36:24 SIGNALduino Sduino RAWMSG MS;P0=-1109;P1=237;P2=-296;P4=-2576;P6=-9492;D=141210121012101012101212101012101212101210121010121210121010121210121010121210121012101210101212101012121012101210101212101210101216;CP=1;SP=4;R=13;O;m=1;
2018-02-23 21:36:25 SIGNALduino Sduino RAWMSG MS;P0=-1111;P1=236;P2=-295;P4=-2576;P7=-9484;D=141210121012101012101212101012101212101210121010121210121010121210121010121210121012101210101212101012121012101210101212101210101217;CP=1;SP=4;R=13;O;m=2;
2018-02-23 21:36:25 SIGNALduino Sduino RAWMSG MS;P0=-1095;P1=242;P2=-282;P4=-2576;D=14121012101210101210121210101210121210121012101012121012101012121012101012121012101210121010121210101212101210121010121210121010121;CP=1;SP=4;R=13;e;m=3;
2018-02-23 21:36:26 SIGNALduino Sduino RAWMSG MU;P0=-207;P1=92;P2=147;P3=274;D=0101010101020202030302020302020202020202020202020202030202020203030202030202030203020202020302030203030302030302020303020302030202020302030;CP=2;R=51;e;
2018-02-23 21:36:27 SIGNALduino Sduino RAWMSG MU;P0=32001;P1=-356;P2=142;P3=-216;P4=268;D=012343434343434323434343432343234343434323234323432323232323232323232323232323232323234343232343232323232323232323232323232323232323232323232323234343434343232323432323234323234323232323432343432323434343234340;CP=2;R=6;e;
2018-02-23 21:36:30 SIGNALduino Sduino RAWMSG MU;P0=-223;P1=261;P2=147;D=01010201020101010202010201020202020202020202020202020202020202010102020102020202020202020202020202010202020201010202010202010201020202020102010201010102010102020101020101010202020101020;CP=2;R=52;e;
2018-02-23 21:36:30 SIGNALduino Sduino RAWMSG MU;P0=-217;P1=149;P2=260;P5=-20556;D=0101020201010201010101010101010101010101010101010101010101010101020202020201010102010101020101020101010102010202010102020201020250;CP=1;R=4;e;
2018-02-23 21:36:31 SIGNALduino Sduino RAWMSG MU;P0=-10552;P1=688;P2=32001;P3=-5368;P4=991;P5=-969;P6=-481;P7=469;D=2345454545454545454545454545467576467576454675454576467576454675764675454545454545457646754576467545454545454545454545764546754545457645467545454545454576467545764545467545454545764546754576454546754545764675764675764545401545454545454545454545454545454;CP=4;R=31;O;
2018-02-23 21:36:31 SIGNALduino Sduino RAWMSG MU;P0=1010;P1=-465;P2=479;P3=-959;D=01232101232103012303032101232103012321012303030303030303210123032101230303030303030303030321030123030303210301230303030303032101230321030301230303030321030123032103030123030321012321012321030300;CP=0;R=29;e;
2018-02-23 21:36:33 SIGNALduino Sduino RAWMSG MU;P0=-224;P1=257;P2=124;P3=92;D=010202010201030303020102010201010102010102020101020102010202020101020;CP=2;R=243;e;
2018-02-23 21:36:33 SIGNALduino Sduino RAWMSG MU;P0=-219;P1=137;P2=259;P4=-25132;P5=92;P6=-2208;D=010101010101010202010102010101010101010101010101010101010101010101010101010202020202010101020101010201010201010101020102020101020202010202456;CP=1;R=4;e;
2018-02-23 21:36:36 SIGNALduino Sduino RAWMSG MU;P0=-210;P1=150;P3=271;D=0101010101010101030101010103030101030101030103010101010301030103030301030301010303010303030101010303010;CP=1;R=245;e;
2018-02-23 21:36:37 SIGNALduino Sduino RAWMSG MU;P0=32001;P1=-1260;P2=9984;P3=-352;P4=143;P5=-219;P6=262;D=01234565656565656545656565654565456565656545456545654545454545454545454545454545454545456565454565454545454545454545454545454545454545454545454545456565656565454545654545456545456545454545654565654545656565456560;CP=4;R=6;e;
Muss morgen mal alle Revolts rausnehmen, dann sollte es stiller werden.
Grüße Markus
Edit: gerade gesehen dass ich 2 "falsche" devices vom PIR1000 habe. Beim RFXTRX u. aculfw hab ich das nicht.
IT_V3_d890949
i569A56595659969600
MS;P0=-9488;P1=248;P2=-1090;P4=-286;P7=-2577;D=171412141214121214121414121214121414121412141212141412141212141412141214121412121414121412121414121214141214121214121414121412121410;CP=1;SP=7;R=15;O;m=1;
IT_V3_d89214a
i569A56596559969900
MS;P0=-1078;P1=254;P2=-285;P3=-9476;P6=-2568;D=131612101210121010121012121010121012121012101210101212101210101212101210101212101210121012101012121010121210121010121012121010121210;CP=1;SP=3;R=24;O;m=3;
korrekt:
IT_V3_d892149
i569A56596559959600
MS;P0=-284;P1=247;P2=-1080;P3=-9486;P4=-2568;D=3141012101210121210121010121210121010121012101212101012101212101012101212101012101210121012121010121210101210121012121010121012121013;CP=1;SP=4;R=6;O;m=0;
Edit2: HÖLLE, hab jetzt mal alle Revolts u. FA20RF außer Betrieb genommen. Es dürften nur noch die OREGON's funken und für die hab ich MC disabled. Aber da kommen immer noch höllisch viele Telegramme. Wenn ich das R richtig als Repetition interpretiere, dann machen mir folgende raw's mit R um die 250 sicherlich das Leben schwer(Überlagerungen). Ich hab mal die CP immer drüber gesetzt:
P2=946
2018-02-24 09:32:39 SIGNALduino Sduino RAWMSG MU;P0=418;P1=-1058;P2=946;P3=-512;P5=-4588;D=012121212121212121212121230103230103212301212103230103212121230121212121210323012121032301032301210323012103230121212121210323012121212121212121212103212123012121032301212121210321212123010321230121210323012103212301032;CP=2;R=251;e;
P1=925
2018-02-24 09:32:39 SIGNALduino Sduino RAWMSG MU;P0=-200;P1=925;P2=-1056;P3=-509;P4=428;P5=112;P6=-8688;D=012121212121212121212121212134243134243121342121243134243121212134212121212124313421212431342431342124313421243134243134212121243134212121212121212121212431212134212124313421212121243121213424312121342124313421243134243134212560;CP=1;R=251;e;
P3=908
2018-02-24 09:33:16 SIGNALduino Sduino RAWMSG MU;P0=-180;P1=160;P2=-3156;P3=908;P4=-1063;P5=-552;P6=398;D=012343434356465356465343564343465356465343434356434343434346535643434653564653564346535643465356434346534343564343434343434343434343465343435643434653564343434346535646534356465343564343434343434653435640;CP=3;R=251;e;
P1=920
2018-02-24 09:33:16 SIGNALduino Sduino RAWMSG MU;P0=-555;P1=920;P2=-1037;P4=390;P5=-9460;D=0121212121212121212121042401042401210421212401042401212121042121212121240104212124010424010421240104212401042401042401212104212121212121212121212124012121042121240104212121212401042401042401212104212401210424012121212150;CP=1;R=253;e;
P4=422
2018-02-24 09:33:36 SIGNALduino Sduino RAWMSG MU;P0=-1444;P1=950;P2=-1077;P3=-512;P4=422;P5=-140;D=0121212121212121212134243134243121342121243134243121342431342121212121212124313421243134243150;CP=4;R=251;e;
P4=900
2018-02-24 09:33:37 SIGNALduino Sduino RAWMSG MU;P0=-308;P1=429;P2=-1060;P3=-526;P4=900;P5=116;P6=-2132;D=012134312424242424242134312424213431242424242424242424242421343124242134312424242424242134243121343124213424243121343124242560;CP=4;R=248;e;
P2=866
2018-02-24 09:33:37 SIGNALduino Sduino RAWMSG MU;P0=1628;P1=-1107;P2=866;P3=-583;P4=403;P5=102;P6=-9164;P7=160;D=012121212121212121212121212121212341432341432123412121432341432123414323412121212121212143234121432341432341432341212121212121432341212143234121212121212121212121214323412121432341212121212121432123414323412143212123414323412121565370;CP=2;R=252;e;
P5=916
2018-02-24 09:33:53 SIGNALduino Sduino RAWMSG MU;P0=-292;P1=136;P2=-180;P3=1180;P4=-1076;P5=916;P6=-543;P7=381;D=01234545454545454545454545454545454567476567476545674545476567476545454567454545454547656745454765674765674547656745476567454547654545674545454545454545454545476545456745454765674545454547656747654567476545674545454545454765456740;CP=5;R=252;e;
P5=945
2018-02-24 09:33:53 SIGNALduino Sduino RAWMSG MU;P0=379;P1=-12760;P2=-156;P3=92;P4=-92;P5=945;P6=-1019;P7=-550;D=234565656565656565656565656565656565706075706075657065656075706075656565706565656565607570656560757060757065607570656075706075706075656570656565656565656565656560756565706565607570656565656075706075706075656570656075657060756565656510;CP=5;R=252;e;
P2=905
2018-02-24 09:34:20 SIGNALduino Sduino RAWMSG MU;P0=200;P1=-1057;P2=905;P3=-508;P4=414;P5=136;P6=-8976;D=01212121212123414323414321234121214323414321234143234121212121212121432341214323414323414323412121212121214323412121432341212121212121212121212143234121214323412121212121214321234143234121432121234143234121215;CP=2;R=251;e;
P3=912
2018-02-24 09:34:20 SIGNALduino Sduino RAWMSG MU;P0=-204;P1=212;P2=-132;P3=912;P4=-1059;P5=-497;P6=437;P7=-640;D=012103434343434343434343434343434343435646535646534356434346535646534356465356434343434343434653564346535646535646535643434343434346535643434653564343434343434343434343465356434370;CP=3;R=251;e;
P1=441
2018-02-24 09:34:20 SIGNALduino Sduino RAWMSG MU;P0=-320;P1=441;P2=-505;P3=904;P4=-1067;P5=92;P6=-5288;D=0123214343434343434123432141232143412343432141232143434560;CP=1;R=243;e;
P1=1007
2018-02-24 09:34:30 SIGNALduino Sduino RAWMSG MU;P0=-432;P1=1007;P2=-973;P3=495;P5=152;P6=-5916;D=0121212121212123012103212123010321212121230121212121210321212121230103230103212560;CP=1;R=253;e;
P3=951
2018-02-24 09:34:30 SIGNALduino Sduino RAWMSG MU;P0=-996;P1=272;P2=-14034;P3=951;P5=-511;P6=453;P7=-92;D=01230303030303030303030303030303030356065356065303560303065356065303030356030303030306535603030653560653560306535603065356065356065303035603030303030303030303030653030356030306535603030303065356065356065303035603065303560653030303032670;CP=3;R=252;e;
P1=913
2018-02-24 09:35:02 SIGNALduino Sduino RAWMSG MU;P0=-5692;P1=913;P2=-1066;P3=-501;P4=429;D=012121212121212121212121342431342431213421212431342431213424313421212121212121243134212431342431342431342121212121212431342121243134212121212121212121212124313421212431342130;CP=1;R=250;e;
P1=895
2018-02-24 09:35:03 SIGNALduino Sduino RAWMSG MU;P0=-525;P1=895;P2=-1081;P3=418;P4=112;P5=-7184;D=01212121212301210323010321230121210323010321212450;CP=1;R=250;e;
P2=862
2018-02-24 09:35:03 SIGNALduino Sduino RAWMSG MU;P0=-396;P1=-1096;P2=862;P3=-566;P4=404;P5=92;P6=-13636;P7=124;D=121212121212121212121212121212123414323414321234121214323414321234143234121212121212121432341214323414323414323412121212121214323412121432341212121212121212121212143234121214323412121212121214321234143234121432121234143234121215673700;CP=2;R=251;p;
P2=942
2018-02-24 09:35:07 SIGNALduino Sduino RAWMSG MU;P0=417;P1=-1048;P2=942;P3=-522;P5=116;P6=-11436;D=01212121230103230103212301212103230103212121230121212121210323012121032301032301210323012103230121210321212301212121212121212121212103212123012121032301212121210323010321230103212301212121212121032123015;CP=2;R=253;e;
P2=921
2018-02-24 09:35:07 SIGNALduino Sduino RAWMSG MU;P0=-204;P1=92;P2=921;P3=-1021;P4=-558;P5=390;P6=-15488;D=010232323232323232323232323232323232453542453542324532323542453542323232453232323232354245323235424535424532354245323542453542453542323245323232323232323232323235423232453232354245323232323542453542453542323245323542324535423232323260;CP=2;R=252;e;
Dazu gibt es noch diese raw-Nachrichten mit geringerer Wiederholrate:
2018-02-24 09:32:26 SIGNALduino Sduino RAWMSG MU;P0=732;P1=-19072;P2=1003;P3=-1001;P4=-458;P5=472;P6=116;P7=-10376;D=1232323232323245354245354232453232354245354232453542453232323232323542453232323235424535423245323235424535424532354232323245354245323232323232323542324532323542453232323235423232323232453232323235424535424532367032323232323232323232323232323232453542453;CP=2;R=20;O;
2018-02-24 09:32:27 SIGNALduino Sduino RAWMSG MU;P0=-469;P1=980;P2=-997;P3=485;P4=112;D=01210321212301032301210323010321212121212123010321212121230103230121032121230103230103212301212121032301032121212121212123012103212123010321212121230121212121210321212121230103230103212;CP=1;R=15;e;
2018-02-24 09:32:28 SIGNALduino Sduino RAWMSG MU;P0=676;P1=-28852;P2=977;P3=-1014;P4=-477;P5=470;P6=108;P7=-10428;D=1232453542453542324532323542453542324535424532323232323232354245323542453232323232323232323232323542453232354232453232323232323232323542323245323232323542453542453542323245323542324535423232453236703232323232323232323232323232323245354245354232453232354;CP=2;R=35;O;
2018-02-24 09:32:30 SIGNALduino Sduino RAWMSG MU;P0=-484;P1=463;P2=-987;P3=976;P4=128;D=01210323012103012323232323232321030123210301232323232323232323232323210301232321032301232323232323232323210323230123232323210301210301210323230123210323012103232301232;CP=3;R=35;e;
2018-02-24 09:33:07 SIGNALduino Sduino RAWMSG MU;P0=708;P1=-5256;P2=987;P3=-964;P4=-477;P5=469;P6=112;P7=-10384;D=1232323232323232323232323232453542453542324532323542453542324535424532323232323235424532323232354245354232453232354245354245323542323232453542453232323232323235423245323235424532323232354232323232324532323232354245354245323670323232323232323232323232323;CP=2;R=16;O;
2018-02-24 09:33:08 SIGNALduino Sduino RAWMSG MU;P0=-999;P1=972;P2=-465;P3=484;P4=140;D=0101230321230321012301010321230321012303212301010101010103212301010101032123032101230101032123032123010321010101230321230101010101010103210123010103212301010101032101010101012301010101032123032123010;CP=3;R=13;e;
2018-02-24 09:33:10 SIGNALduino Sduino RAWMSG MU;P0=-10428;P1=700;P3=100;P4=465;P5=-976;P6=997;P7=-474;D=4565656565656745476745476567456565476745476567454767456565656565656547674565476745656565656565656565656565476745656547656745656565656565656565476565674565656565476745476745476565674565476567454765656745653015656565656565656565656565656565674547674547656;CP=6;R=27;O;
2018-02-24 09:33:11 SIGNALduino Sduino RAWMSG MU;P0=474;P1=-992;P2=977;P3=-469;P4=132;D=0121210323010321230103230121212121212121032301210323012121212121212121212121210323012121032123012121212121212121210321212301212121210323010323010321212301210321230103212123012140;CP=2;R=27;e;
2018-02-24 09:33:48 SIGNALduino Sduino RAWMSG MU;P0=-32001;P1=460;P2=-478;P3=984;P4=-989;P5=132;P6=-10372;P7=724;D=0123432143434123214123432141232143434343434341232143434343412321412343214343412321412321434123434343214123214343434343434341234321434341232143434343412343434343432143434343412321412321434567434343434343434343434343434343432141232141234321434341232141234;CP=3;R=14;O;
2018-02-24 09:33:49 SIGNALduino Sduino RAWMSG MU;P0=-483;P1=467;P2=-1026;P3=941;P4=116;D=0121030123232323232321030123232323210301210323012323210301210301232103232323012103012323232323232321032301232321030123232323210323232323230123232323210301210301232;CP=3;R=13;e;
2018-02-24 09:33:53 SIGNALduino Sduino RAWMSG MU;P0=-10500;P1=-19088;P2=1000;P3=-2984;P4=-973;P5=-476;P6=467;P7=108;D=1232424242425646525646524256424246525646524256465256424242424242424652564246525642424242424242424246525642465256424246524256424242424242424242465242425642424242465242425646524242564246525646524256465256424702424242424242424242424242424242425646525646524;CP=2;R=26;O;
2018-02-24 09:33:54 SIGNALduino Sduino RAWMSG MU;P0=-478;P1=466;P2=-1001;P3=966;P4=112;D=01232321030121032301210301232323232323232103012321030123232323232323232321030123210301232321032301232323232323232323210323230123232323210323230121032323012321030121032301210301232;CP=3;R=26;e;
2018-02-24 09:34:29 SIGNALduino Sduino RAWMSG MU;P0=32001;P1=-942;P2=1007;P3=-489;P4=458;P5=112;P6=-10384;P7=700;D=0121212121212121212121212121212123414323414321234121214323414321234143234121212121212143234121212121432341432123412121432341432341214321212123414323412121212121212143212341212143234121212121432121212121234121212121432341432341215671212121212121212121212;CP=2;R=16;O;
2018-02-24 09:34:30 SIGNALduino Sduino RAWMSG MU;P0=995;P1=-986;P2=-439;P3=497;P5=-712;D=010101010231320231320102310101320231320102313202310101010101013202310;CP=3;R=12;e;
2018-02-24 09:34:30 SIGNALduino Sduino RAWMSG MU;P0=-244;P1=1033;P2=-964;P3=485;P4=-449;D=0121212341432341214321212341432341432123412121214323414340;CP=3;R=12;e;
2018-02-24 09:34:36 SIGNALduino Sduino RAWMSG MU;P0=1652;P1=-19004;P2=1000;P3=-997;P4=-469;P5=472;P6=136;P7=-10484;D=0123232323232324535424535423245323235424535423245354245323232323232323542453235424532323232323232323235424532354245323235423245323232323232323232354232324532323232354232324535423232453235424535423245354245323672323232323232323232323232323232324535424535;CP=2;R=27;O;
2018-02-24 09:34:37 SIGNALduino Sduino RAWMSG MU;P0=986;P1=-1000;P2=-463;P3=479;P4=112;D=0102310101320231320102313202310101010101010132023101320231010101010101010101320231013202310101320102310101010101010101013201010231010101013201010231320101023101320231320102313202310140;CP=0;R=27;e;
2018-02-24 09:35:10 SIGNALduino Sduino RAWMSG MU;P0=22768;P1=-967;P2=978;P3=-452;P4=480;P5=132;P6=-10352;P7=744;D=0121212121212121212121212121212123414323414321234121214323414321234143234121212121212143234121212121432341432123412121432341432341214321212123414323412121212121212143212341212143234121212121432121212121234121212121432341432341215671212121212121212121212;CP=2;R=13;O;
2018-02-24 09:35:11 SIGNALduino Sduino RAWMSG MU;P0=964;P1=-1004;P2=-476;P3=478;P4=136;D=01010101023132023132010231010132023132010231320231010101010101320231010101013202313201023101013202313202310132010101023132023101010101010101320102310101320231010101013201010101010231010101013202313202310140;CP=3;R=15;e;
Ne Idee, was das sein könnte ? Wenn ich das nicht eliminiert bekomme sind Tests(interpretierbare Testdaten) so gut wie unmöglich. :'(
Edit3: Hier hab ich Batterien in den FA20RF eingelegt und dann 2* Testbutton(UNKNOWNCODE) gedrückt.
2018-02-24 10:10:01 SIGNALduino Sduino RAWMSG MU;P0=204;P1=-979;P2=977;P3=-462;P4=477;P5=-10572;P6=648;D=0121212121212121212121212121234143234143212341212143234143212341432341212121212121432341212121214323414321234121214323414321212341432121234143234121212121212121432123412121432341212121214323414321212123412121214321234143212125612121212121212121212121212;CP=2;R=8;O;
2018-02-24 10:10:02 SIGNALduino Sduino RAWMSG MU;P0=1007;P1=-920;P2=-467;P3=477;P4=-26272;P5=92;D=01010231320231320102310101320231320102313202310101010101013202310101010132023132010231010132023132010102313201010231320231010101010101013201023101013202310101010132023132010101023101010132010231320101045;CP=3;R=5;e;
2018-02-24 10:10:09 SIGNALduino Sduino RAWMSG MU;P0=-528;P1=909;P2=-1053;P3=406;P5=-720;D=0121212123010321230103230103230103212121212150;CP=3;R=249;e;
2018-02-24 10:10:10 SIGNALduino Sduino RAWMSG MU;P0=-732;P1=910;P2=-1093;P3=420;P4=-549;D=01212121212123414321212341432121212123414340;CP=1;R=248;e;
2018-02-24 10:10:10 SIGNALduino Sduino RAWMSG MU;P0=1492;P1=-1071;P2=881;P3=-514;P4=428;P7=-272;D=012121212121212121212121212121212341432341432123412121432341432123414323412121212121212143234121432341432341432341212121212143212341212143234121212121212121212121214;CP=2;R=249;e;
2018-02-24 10:10:11 SIGNALduino Sduino RAWMSG MU;P0=-522;P1=872;P2=-1075;P3=419;P5=132;P6=-6240;D=012301032121212123010323012103230103212301032121212121212560;CP=1;R=246;e;
2018-02-24 10:10:15 SIGNALduino Sduino RAWMSG MU;P0=32001;P1=-1057;P2=946;P3=-491;P4=422;P5=-776;D=0121212121212121212121212121212123414323414321234121214323414321212123412121212121432341212143234;CP=2;R=248;e;
2018-02-24 10:10:16 SIGNALduino Sduino RAWMSG MU;P0=-260;P1=396;P2=-566;P3=927;P4=-1063;D=012321434123214341232143434341234321434343434343434343434343412320;CP=3;R=248;e;
2018-02-24 10:10:16 SIGNALduino Sduino RAWMSG MU;P0=-216;P1=991;P2=-1048;P3=-516;P4=413;P5=92;P6=-9088;D=01212121212134243134243121342121243134243121212134212121212124313421212431342431342124313421243134243134212431213421212121212121212121212124312134212124313421212121243121342121243121342124312134243121342431342560;CP=4;R=250;e;
2018-02-24 10:10:26 SIGNALduino Sduino RAWMSG MU;P0=-10512;P1=-27104;P2=469;P3=-1002;P4=952;P5=-474;P7=116;D=1234345232545232543452343432545232543452325452343434343434343254523432545234343434343434343434325452343254523432543452343434343434343434325434345234343434325434523254523254345234325452325452343434343704343434343434343434343434343434345232545232543452343;CP=4;R=38;O;
2018-02-24 10:10:27 SIGNALduino Sduino RAWMSG MU;P0=-1010;P1=466;P2=-474;P3=951;P4=112;D=01232101230321012321030303030303030123210301232103030303030303030303012321030123210301230321030303030303030303012303032103030303012303210123210123032103012321012321030303030;CP=3;R=36;e;
2018-02-24 10:10:41 SIGNALduino Sduino RAWMSG MS;P0=-1447;P1=727;P2=-2811;P3=-14890;P4=8059;P5=-992;D=01345121210121210121212121010121210121010101012121010;CP=1;SP=3;R=30;O;m=0;
2018-02-24 10:10:41 SIGNALduino Sduino UNKNOWNCODE P13#2432F3
2018-02-24 10:10:41 SIGNALduino Sduino RAWMSG MS;P0=-1450;P1=741;P2=-2801;P3=-15005;P4=8057;P5=-970;D=1345121210121210121212121010121210121010101012121010;CP=1;SP=3;R=30;O;m=1;
2018-02-24 10:10:41 SIGNALduino Sduino RAWMSG MS;P0=-1490;P1=716;P2=-2813;P3=-14762;P4=8062;P5=-983;D=1345121210121210121212121010121210121010101012121010;CP=1;SP=3;R=30;O;m=2;
2018-02-24 10:10:41 SIGNALduino Sduino RAWMSG MS;P0=-1458;P1=738;P2=-2813;P3=-14659;P4=8057;P5=-985;D=1345121210121210121212121010121210121010101012121010;CP=1;SP=3;R=30;O;m=3;
2018-02-24 10:10:41 SIGNALduino Sduino RAWMSG MU;P0=-14464;P1=8044;P2=-1004;P3=724;P4=-2822;P5=-1457;P6=2552;P7=-112;D=01234343534343534343434353534343534353535353434353530670;CP=3;R=247;e;
2018-02-24 10:10:42 SIGNALduino Sduino RAWMSG MU;P0=1748;P1=-1024;P2=733;P3=-2818;P4=-1433;D=0123232423232423232323242423232423242424242323242420;CP=2;R=247;e;
2018-02-24 10:10:42 SIGNALduino Sduino RAWMSG MU;P0=18600;P1=-971;P2=993;P3=-463;P4=476;P5=-10556;P6=648;D=0121212121212121212121212121212123414323414321234121214323414321234143234121212121212143234121212121432341432123412121432341432121234143212123414323412121212121212143212341212143234121212121432341432121212341212121432123414321212561212121212121212121212;CP=2;R=3;O;
2018-02-24 10:10:43 SIGNALduino Sduino RAWMSG MU;P0=1009;P1=-961;P2=-479;P3=480;D=01010101023132023132010231010132023132010231320231010101010101320231010101013202313201023101013202313201010231320101023132023101010101010101320102310101320231010101013202313201010102310101013201023132010100;CP=3;R=4;e;
2018-02-24 10:10:50 SIGNALduino Sduino RAWMSG MS;P1=-2819;P2=727;P3=-1455;P4=-14764;P5=8055;P6=-1006;D=2456212123212123212121212323212123212323232321212323;CP=2;SP=4;R=46;O;m=0;
2018-02-24 10:10:50 SIGNALduino Sduino UNKNOWNCODE P13#2432F3
2018-02-24 10:10:50 SIGNALduino Sduino RAWMSG MS;P1=-2806;P2=738;P3=-1458;P4=-14636;P5=8071;P6=-991;D=2456212123212123212121212323212123212323232321212323;CP=2;SP=4;R=46;O;m=1;
2018-02-24 10:10:50 SIGNALduino Sduino RAWMSG MS;P1=-2807;P2=740;P3=-1422;P4=-14636;P5=8071;P6=-991;D=2456212123212123212121212323212123212323232321212323;CP=2;SP=4;R=46;e;m=2;
2018-02-24 10:10:50 SIGNALduino Sduino RAWMSG MS;P1=-2807;P2=740;P3=-1422;P4=-14636;P5=8071;P6=-991;D=2456212123212123212121212323212123212323232321212323;CP=2;SP=4;R=46;e;m=3;
2018-02-24 10:10:50 SIGNALduino Sduino RAWMSG MS;P0=-1436;P1=732;P2=-2811;P3=-14737;P4=8062;P5=-997;D=01345121210121210121212121010121210121010101012121010;CP=1;SP=3;R=38;e;m=0;
2018-02-24 10:10:51 SIGNALduino Sduino RAWMSG MS;P0=-1436;P1=732;P2=-2811;P3=-14737;P4=8062;P5=-997;D=1345121210121210121212121010121210121010101012121010;CP=1;SP=3;R=38;e;m=1;
2018-02-24 10:10:51 SIGNALduino Sduino RAWMSG MS;P0=-1436;P1=732;P2=-2811;P3=-14737;P4=8062;P5=-997;D=13451212101212101212121210101212101210101010121210101;CP=1;SP=3;R=38;e;m=2;
2018-02-24 10:10:53 SIGNALduino Sduino RAWMSG MU;P0=1537;P1=-495;P2=-164;P3=425;P5=962;P6=-1046;P7=-368;D=01023151023101510231010101010101565651363151363156513700;CP=0;R=253;p;
2018-02-24 10:10:53 SIGNALduino Sduino RAWMSG MU;P0=930;P1=-1003;P3=-170;P4=1292;P5=1844;P6=496;P7=-520;D=0103434353010101530353510101670761530101535301015301535303515301670;CP=0;R=250;p;
2018-02-24 10:10:53 SIGNALduino Sduino RAWMSG MU;P0=391;P1=-1075;P2=872;P3=-549;P4=92;P5=-9024;P6=156;P7=-292;D=01212121210323010321230103230121032301212121212121456;CP=2;R=243;e;
Edit4:Nachdem ich das FLAMINGO-Modul kopiert habe, wird er einwandfrei erkannt. Folgende Testauslösung bringt:
2018-02-24 10:36:39 SIGNALduino Sduino RAWMSG MS;P1=734;P2=-2802;P3=-1437;P4=-14892;P5=8062;P6=-984;D=31456121213121213121212121313121213121313131312121313;CP=1;SP=4;R=51;e;m=0;
2018-02-24 10:36:39 Global global UNDEFINED FLAMINGO_2432F3 FLAMINGO 2432F3
2018-02-24 10:36:39 SIGNALduino Sduino RAWMSG MS;P1=734;P2=-2802;P3=-1437;P4=-14892;P5=8062;P6=-984;D=14561212131212131212121213131212131213131313121213131;CP=1;SP=4;R=51;e;m=1;
2018-02-24 10:36:40 SIGNALduino Sduino RAWMSG MU;P0=-10596;P1=636;P2=-7496;P3=474;P4=-977;P5=981;P6=-477;D=2345454545454545454545456343656343654563454543656343654563436563454545454545436563454545454365634365456345454365634543654563436545456343656345454545454545436545634545436563454545454545436545454563454543656343654545454501454545454545454545454545454545456;CP=5;R=9;O;
2018-02-24 10:36:41 SIGNALduino Sduino RAWMSG MU;P0=-964;P1=477;P2=-475;P3=994;P5=-656;P6=-116;P7=144;D=01232101230321030301232101230321012321030303030303012321030303030123210123032103030123210301230323516;CP=1;R=6;p;
2018-02-24 10:36:41 SIGNALduino Sduino RAWMSG MU;P0=-542;P1=871;P2=-112;P3=196;P4=-1072;P6=394;P7=112;D=01234301064601064601064141414141460141064141460106414141414141414141414146010641414601064141414146010646014106460106414601064141414141414;CP=1;R=251;p;
2018-02-24 10:36:42 SIGNALduino Sduino RAWMSG MU;P0=1984;P1=-1097;P2=858;P3=-549;P4=372;D=01212121212121212121212121212121234143234143212341212143234143212341432341212121212121214323412143234143234143234121212121214321234121214323412121212121212121212121432341212143234121212121432341432123414323412143234121212121212;CP=2;R=251;e;
2018-02-24 10:36:44 SIGNALduino Sduino RAWMSG MS;P1=738;P2=-2804;P3=-1432;P4=-14450;P5=8060;P6=-972;D=31456121213121213121212121313121213121313131312121313;CP=1;SP=4;R=51;e;m=0;
2018-02-24 10:36:44 Global global UNDEFINED FLAMINGO_2432F3 FLAMINGO 2432F3
2018-02-24 10:36:44 Global global DEFINED FLAMINGO_2432F3
2018-02-24 10:36:44 SIGNALduino Sduino RAWMSG MS;P1=738;P2=-2804;P3=-1432;P4=-14450;P5=8060;P6=-972;D=14561212131212131212121213131212131213131313121213131;CP=1;SP=4;R=51;e;m=1;
2018-02-24 10:36:44 SIGNALduino Sduino RAWMSG MS;P1=-976;P2=739;P3=-2803;P4=-1426;P5=-14458;P6=8070;D=2561232324232324232323232424232324232424242423232424;CP=2;SP=5;R=46;e;m=0;
2018-02-24 10:36:44 SIGNALduino Sduino RAWMSG MS;P1=-976;P2=739;P3=-2803;P4=-1426;P5=-14458;P6=8070;D=25612323242323242323232324242323242324242424232324242;CP=2;SP=5;R=46;e;m=1;
2018-02-24 10:36:46 SIGNALduino Sduino RAWMSG MU;P0=-1064;P1=970;P2=432;P3=-486;P4=-128;D=01010231320231010101320101010101023132010102313202313240;CP=2;R=249;e;
2018-02-24 10:36:47 SIGNALduino Sduino RAWMSG MU;P0=-1056;P1=972;P2=415;P3=-503;P4=112;P5=-5672;D=010231320102313201010101023132023132010101010101010101010102313201010231320101010102310101320231320231320102310132023101320231320450;CP=2;R=249;e;
2018-02-24 10:36:47 SIGNALduino Sduino RAWMSG MU;P0=-736;P1=961;P2=-1024;P3=-512;P4=438;P5=-132;D=01212121212121212121212121342431342431213450;CP=1;R=249;e;
2018-02-24 10:36:47 SIGNALduino Sduino RAWMSG MU;P0=-1060;P1=897;P2=443;P3=-502;P4=-684;P5=116;P6=-216;P7=-320;D=0101023132023101456101320101010101023132010170;CP=1;R=250;e;
2018-02-24 10:36:47 SIGNALduino Sduino RAWMSG MU;P0=-224;P1=427;P2=-1034;P3=947;P4=-505;P5=-7716;D=0123232143412143412323232323232323232323214341232321434123232323214323232323412143412323232323232321432350;CP=3;R=249;e;
2018-02-24 10:37:40 SIGNALduino Sduino RAWMSG MS;P0=-13252;P2=731;P3=-2802;P4=-1413;P6=8048;P7=-1012;D=2067232324232324232323232424232324232424242423232424;CP=2;SP=0;R=49;p;m=0;
2018-02-24 10:37:42 FLAMINGO FLAMINGO_2432F3 Alarm
2018-02-24 10:37:42 FLAMINGO FLAMINGO_2432F3 no alarm
2018-02-24 10:37:42 SIGNALduino Sduino RAWMSG MU;P0=200;P4=747;P5=-2793;P6=-1420;P7=-8548;D=4545464545464545454546464545464546464646454546464700;CP=4;R=51;e;
2018-02-24 10:37:42 SIGNALduino Sduino RAWMSG MU;P0=-12308;P1=-2786;P2=863;P3=-1044;P4=-700;P5=8068;P7=-1424;D=12324532121272121272121212127272121272127272727212127272023230;CP=2;R=50;p;
2018-02-24 10:37:42 SIGNALduino Sduino RAWMSG MU;P0=477;P1=-477;P2=970;P3=-997;P4=116;D=012103012321030121032323232323232301210323012103232323232323232323012321032301210323012321032323232323232323230123232103232323230121030123210301232103230123210323012103232340;CP=2;R=35;e;
2018-02-24 10:37:43 SIGNALduino Sduino RAWMSG MS;P1=730;P2=-2806;P3=-1448;P4=-14673;P5=8069;P6=-989;D=31456121213121213121212121313121213121313131312121313;CP=1;SP=4;R=53;O;m=0;
2018-02-24 10:37:43 FLAMINGO FLAMINGO_2432F3 Alarm
2018-02-24 10:37:43 FLAMINGO FLAMINGO_2432F3 no alarm
2018-02-24 10:37:43 SIGNALduino Sduino RAWMSG MS;P1=735;P2=-2809;P3=-1432;P4=-14673;P5=8069;P6=-989;D=1456121213121213121212121313121213121313131312121313;CP=1;SP=4;R=53;e;m=1;
2018-02-24 10:37:43 SIGNALduino Sduino RAWMSG MS;P1=735;P2=-2809;P3=-1432;P4=-14673;P5=8069;P6=-989;D=1456121213121213121212121313121213121313131312121313;CP=1;SP=4;R=53;e;m=2;
2018-02-24 10:37:43 SIGNALduino Sduino RAWMSG MS;P1=735;P2=-2809;P3=-1432;P4=-14673;P5=8069;P6=-989;D=1456121213121213121212121313121213121313131312121313;CP=1;SP=4;R=53;e;m=3;
2018-02-24 10:37:43 SIGNALduino Sduino RAWMSG MS;P0=-960;P3=-2818;P4=731;P5=-1433;P6=-15072;P7=8088;D=546704343454343454343434345454343454345454545434345454;CP=4;SP=6;R=46;e;
ZitatEs dürften nur noch die OREGON's funken und für die hab ich MC disabled.
Wenn Du die MC disabled, dann werden sie als MU-Nachrichten empfangen.
Das R ist die RSSI.
Gruß Ralf
Ahh, dann bin ich beruhigt. Dass die MU's die ORGEONs sind, hatte ich schon spekuliert.
Bringt es Dir etwas, wenn ich alle meine FA20RF teste und Dir das raw zur Verfügung stelle ?
Und um mit ein paar Unklarheiten an der Stelle zu FA20RF aufzuräumen:
- Es ist nicht etwa so wie die Bedienungsanleitung suggeriert, dass es einen "echten" Master-/Slave-Betrieb gäbe. Beim Pairing wird lediglich der device-code auf einen anderen Rauchmelder kopiert und bei einer Auslösung wird der eigene device-code ausgesendet, was die RM's mit demselben device-code ebenfalls zur Auslösung veranlasst.
- stromfrei machen der RM's führt NICHT dazu, dass der device-code evtl. verloren ginge(die Befürchtung hatte ich immer)
- die FA20RF senden nicht permanent etwas aus (https://forum.fhem.de/index.php/topic,72822.msg644160.html#msg644160)(zumindest meine nicht), was man zur Batterieüberwachung einsetzen könnte
Grüße Markus
So wie ich das sehe wird Dein FA20RF sauber als MS-Nachricht erkannt, wenn das so bei allen ist, dann brauche ich keine weitere raw Nachrichten.
Wenn sie sauber empfangen wird, dann hat sie 3 Wiederholungen (m=1-3)
MS;P1=730;P2=-2806;P3=-1448;P4=-14673;P5=8069;P6=-989;D=31456121213121213121212121313121213121313131312121313;CP=1;SP=4;R=53;O;m=0;
MS;P1=735;P2=-2809;P3=-1432;P4=-14673;P5=8069;P6=-989;D =1456121213121213121212121313121213121313131312121313;CP=1;SP=4;R=53;e;m=1;
MS;P1=735;P2=-2809;P3=-1432;P4=-14673;P5=8069;P6=-989;D =1456121213121213121212121313121213121313131312121313;CP=1;SP=4;R=53;e;m=2;
MS;P1=735;P2=-2809;P3=-1432;P4=-14673;P5=8069;P6=-989;D =1456121213121213121212121313121213121313131312121313;CP=1;SP=4;R=53;e;m=3;ZitatEdit: gerade gesehen dass ich 2 "falsche" devices vom PIR1000 habe. Beim RFXTRX u. aculfw hab ich das nicht.
Anscheinend ist in der Firmware noch ein kleiner Bug, den ich jetzt erst mal finden muß.
Gruß Ralf
ZitatEdit: gerade gesehen dass ich 2 "falsche" devices vom PIR1000 habe. Beim RFXTRX u. aculfw hab ich das nicht.
IT_V3_d890949
i569A56595659969600
IT_V3_d89214a
i569A56596559969900
korrekt:
IT_V3_d892149
i569A56596559959600
Irgendwas passt da nicht.
Ich habe mal bei Deinen 3 Beispielen die DEF zugefügt:
i569A56596559969900
IT_V3_d89214a DEF 00011011000100100100001010 0 1010
i569A56596559959600
IT_V3_d892149 DEF 00011011000100100100001010 0 1001
i569A56595659969600
IT_V3_d890949 DEF 00011011000100100001001010 0 1001Wie viele PIR1000 hast Du und was für einen Hexcode und DEF haben sie?
Werden damit die PIR1000 besser erkannt?
attr sduino doubleMsgCheck_IDs 17Gruß Ralf
Hab nur den einen :-[
doubleMsgCheck_IDs hab ich eingestellt u. beobachte.
Edit: Hat nichts gebracht :( Sind jetzt über Nacht noch mehr devices geworden. Und ich hatte extra die Revolts raus gelassen, damit die nicht u.U. verfälschen Die SDWS37/FS10 Meldungen kommen mir auch spanisch vor. Kommen permanent.
2018.02.24 20:43:43 0: ERROR: Cannot autoload FS10
2018.02.24 20:43:43 3: Sduino: Unknown code P61#5F7E13CEBD, help me!
2018.02.24 20:43:44 3: Sduino: SD_WS37 ERROR - checksum 62 != 66
2018.02.24 20:43:44 0: ERROR: Cannot autoload FS10
2018.02.24 20:43:44 3: Sduino: Unknown code P61#BEFC279D7A, help me!
2018.02.24 20:43:44 0: ERROR: Cannot autoload FS10
2018.02.24 20:43:44 3: Sduino: Unknown code P61#5F7E13CEBD, help me!
2018.02.24 20:52:04 3: Sduino: SD_WS37 ERROR - checksum 62 != 66
2018.02.24 20:52:04 0: ERROR: Cannot autoload FS10
2018.02.24 20:52:04 3: Sduino: Unknown code P61#5F7E13CEBD, help me!
2018.02.24 20:52:04 3: Sduino: SD_WS37 ERROR - checksum 62 != 66
2018.02.24 20:52:04 0: ERROR: Cannot autoload FS10
2018.02.24 20:52:04 3: Sduino: Unknown code P61#5F7E13CEBD, help me!
2018.02.24 20:53:44 0: ERROR: Cannot autoload FS10
2018.02.24 20:53:44 3: Sduino: Unknown code P61#5F7E13CEBD, help me!
2018.02.24 20:54:54 3: Sduino: Unknown code U65#4ACB2CAB32D2C, help me!
2018.02.24 20:54:54 3: Sduino: Unknown code U65#9A565965599696, help me!
2018.02.24 20:54:54 3: Sduino: Unknown code U65#B4D2B2CB2ACCB4B0, help me!
2018.02.24 20:54:54 3: Sduino IT: IT_V3_d892149 off->on
2018.02.24 20:54:59 3: Sduino: Unknown code U65#569A565965599596, help me!
2018.02.24 20:54:59 3: Sduino IT: IT_V3_d892149 on->off
2018.02.24 20:56:03 1: PERL WARNING: substr outside of string at ./FHEM/10_IT.pm line 1019.
2018.02.24 20:56:03 2: Sduino IT: IT_V3_2 (10D0D11D1D1D111DD10D1DDDDDD) not defined (Address: 10D0D11D1D1D111DD10D1DDDDD Group: D Unit: Switch code: )
2018.02.24 20:56:03 4: autocreate: received 1 event(s) for 'IT 10D0D11D1D1D111DD10D1DDDDD D ' during the last 30 seconds
2018.02.24 20:56:03 4: autocreate: ignoring event for 'IT 10D0D11D1D1D111DD10D1DDDDD D ': at least 2 needed
2018.02.24 20:56:04 3: Sduino IT: IT_V3_d892149 off->on
2018.02.24 20:56:20 3: Sduino: Unknown code U65#569A565965599596, help me!
2018.02.24 20:56:21 3: Sduino IT: IT_V3_d892149 on->off
2018.02.24 20:56:24 3: Sduino: Unknown code U65#569A565965599696, help me!
2018.02.24 20:56:24 3: Sduino IT: IT_V3_d892149 off->on
2018.02.24 20:56:29 3: Sduino: Unknown code U65#569A565965599596, help me!
2018.02.24 20:56:29 3: Sduino IT: IT_V3_d892149 on->off
2018.02.24 20:56:34 3: Sduino IT: IT_V3_d892149 off->on
2018.02.24 20:56:38 3: Sduino: Unknown code U65#569A565965599596, help me!
.
.
2018.02.24 21:01:58 3: Sduino IT: message "i5A5966695AA9946A5600" (21) too short!
2018.02.24 21:01:58 3: Sduino IT: message "i5A5966695AA9946A5600" (21) too short!
2018.02.24 21:01:58 3: Sduino: Unknown code i5A5966695AA9946A5600, help me!
.
.
2018.02.24 23:46:35 3: Sduino: Unknown code U65#569A565965599696, help me!
2018.02.24 23:46:36 3: Sduino: Unknown code U65#32D4D2B2CB2ACCB4B0, help me!
2018.02.24 23:46:36 3: Sduino IT: IT_V3_d892149 off->on
2018.02.24 23:46:40 3: Sduino: Unknown code U65#569A565965599596, help me!
2018.02.24 23:46:40 3: Sduino: Unknown code U65#32B4D2B2CB2ACCACB0, help me!
2018.02.24 23:46:40 3: Sduino IT: IT_V3_d892149 on->off
.
.
2018.02.25 02:18:56 3: Sduino: Unknown code P61#569A56596559, help me!
2018.02.25 02:18:56 3: Sduino: Unknown code U65#ACCAD34ACB2CAB32D2C, help me!
2018.02.25 02:18:56 3: Sduino IT: IT_V3_d892149 off->on
2018.02.25 02:18:56 2: Sduino IT: IT_V3_6c490a5 (000110110001001001000010100101D) not defined (Address: 00011011000100100100001010 Group: 0 Unit: 101D Switch code: 1)
2018.02.25 02:18:56 4: autocreate: received 1 event(s) for 'IT 00011011000100100100001010 0 101D' during the last 30 seconds
2018.02.25 02:18:56 4: autocreate: ignoring event for 'IT 00011011000100100100001010 0 101D': at least 2 needed
2018.02.25 02:18:56 3: Sduino IT: IT_V3_d892149 on->on
.
.
2018.02.25 02:20:47 3: Sduino: Unknown code P61#569A56596558, help me!
2018.02.25 02:20:47 3: Sduino IT: IT_V3_d892149 off->on
2018.02.25 02:20:51 3: Sduino: Unknown code U65#569A565965599596, help me!
2018.02.25 02:20:51 3: Sduino: Unknown code U65#32B0D2B2CB2ACCACB0, help me!
2018.02.25 02:20:52 3: Sduino: Unknown code U65#5995A69596595665658, help me!
2018.02.25 02:20:52 0: ERROR: Cannot autoload FS10
2018.02.25 02:20:52 3: Sduino: Unknown code P61#569A5659655, help me!
2018.02.25 02:20:52 3: Sduino: Unknown code U65#2ACCAD34ACB2CAB32B2C, help me!
2018.02.25 02:20:52 3: Sduino IT: IT_V3_d892149 on->off
2018.02.25 02:20:52 2: Sduino IT: IT_V3_6c490a5 (000110110001001001000010100101D) not defined (Address: 00011011000100100100001010 Group: 0 Unit: 101D Switch code: 0)
2018.02.25 02:20:52 4: autocreate: received 1 event(s) for 'IT 00011011000100100100001010 0 101D' during the last 30 seconds
2018.02.25 02:20:52 4: autocreate: ignoring event for 'IT 00011011000100100100001010 0 101D': at least 2 needed
2018.02.25 02:20:52 3: Sduino IT: IT_V3_d892149 off->off
2018.02.25 02:20:52 2: Sduino IT: IT_V3_6c490a5 (000110110001001001000010100101D) not defined (Address: 00011011000100100100001010 Group: 0 Unit: 101D Switch code: 0)
2018.02.25 02:20:52 4: autocreate: received 2 event(s) for 'IT 00011011000100100100001010 0 101D' during the last 30 seconds
2018.02.25 02:20:52 2: autocreate: define IT_V3_6c490a5 IT 00011011000100100100001010 0 101D
2018.02.25 02:20:52 1: define IT_V3_6c490a5 IT 00011011000100100100001010 0 101D: Define IT_V3_6c490a5: wrong Unit format: specify 4 digits 0/1
2018.02.25 02:20:52 1: ERROR: Define IT_V3_6c490a5: wrong Unit format: specify 4 digits 0/1
2018.02.25 02:20:52 2: Sduino IT: IT_V3_d89214b (0001101100010010010000101001011) not defined (Address: 00011011000100100100001010 Group: 0 Unit: 1011 Switch code: 0)
2018.02.25 02:20:52 4: autocreate: received 1 event(s) for 'IT 00011011000100100100001010 0 1011' during the last 30 seconds
2018.02.25 02:20:52 4: autocreate: ignoring event for 'IT 00011011000100100100001010 0 1011': at least 2 needed
2018.02.25 02:20:53 3: Sduino IT: IT_V3_d892149 off->off
2018.02.25 02:28:51 3: Sduino: Unknown code U65#569A565965599696, help me!
2018.02.25 02:28:51 3: Sduino: Unknown code U65#32D2D2B2CB2ACCB4B0, help me!
2018.02.25 02:28:51 3: Sduino: Unknown code U65#5996A69596595665A58, help me!
2018.02.25 02:28:52 0: ERROR: Cannot autoload FS10
2018.02.25 02:28:52 3: Sduino: Unknown code P61#569A5659655, help me!
2018.02.25 02:28:52 3: Sduino: Unknown code U65#2ACCAD34ACB2CAB32D2C, help me!
2018.02.25 02:28:52 3: Sduino IT: IT_V3_d892149 off->on
2018.02.25 02:28:52 2: Sduino IT: IT_V3_d89214a (0001101100010010010000101001010) not defined (Address: 00011011000100100100001010 Group: 0 Unit: 1010 Switch code: 1)
2018.02.25 02:28:52 4: autocreate: received 1 event(s) for 'IT 00011011000100100100001010 0 1010' during the last 30 seconds
2018.02.25 02:28:52 4: autocreate: ignoring event for 'IT 00011011000100100100001010 0 1010': at least 2 needed
2018.02.25 02:28:52 3: Sduino IT: IT_V3_d892149 on->on
2018.02.25 02:28:52 2: Sduino IT: IT_V3_6c490a5 (000110110001001001000010100101D) not defined (Address: 00011011000100100100001010 Group: 0 Unit: 101D Switch code: 1)
2018.02.25 02:28:52 4: autocreate: received 1 event(s) for 'IT 00011011000100100100001010 0 101D' during the last 30 seconds
2018.02.25 02:28:52 4: autocreate: ignoring event for 'IT 00011011000100100100001010 0 101D': at least 2 needed
2018.02.25 02:28:52 3: Sduino IT: IT_V3_d892149 on->on
2018.02.25 02:29:20 3: Sduino: Unknown code U65#569A565965599596, help me!
2018.02.25 02:29:20 3: Sduino: Unknown code U65#32B2D2B2CB2ACCACB0, help me!
2018.02.25 02:29:21 3: Sduino: Unknown code U65#5995A69596595665658, help me!
2018.02.25 02:29:21 0: ERROR: Cannot autoload FS10
2018.02.25 02:29:21 3: Sduino: Unknown code P61#569A5659655, help me!
2018.02.25 02:29:21 3: Sduino: Unknown code U65#2ACCAD34ACB2CAB32B2C, help me!
2018.02.25 02:29:21 3: Sduino IT: IT_V3_d892149 on->off
2018.02.25 02:29:21 2: Sduino IT: IT_V3_d89a149 (0001101100010011010000101001001) not defined (Address: 00011011000100110100001010 Group: 0 Unit: 1001 Switch code: 0)
2018.02.25 02:29:21 4: autocreate: received 1 event(s) for 'IT 00011011000100110100001010 0 1001' during the last 30 seconds
2018.02.25 02:29:21 4: autocreate: ignoring event for 'IT 00011011000100110100001010 0 1001': at least 2 needed
2018.02.25 02:29:21 3: Sduino IT: IT_V3_d892149 off->off
.
.
2018.02.25 02:34:11 3: Sduino: Unknown code U65#569A565965599696, help me!
2018.02.25 02:34:11 3: Sduino: Unknown code U65#32D2D2B2CB2ACCB4B0, help me!
2018.02.25 02:34:11 3: Sduino: Unknown code U65#5996A69596595665A58, help me!
2018.02.25 02:34:11 0: ERROR: Cannot autoload FS10
2018.02.25 02:34:11 3: Sduino: Unknown code P61#569A5659655, help me!
2018.02.25 02:34:11 3: Sduino: Unknown code U65#2ACCAD34ACB2CAB32D2C, help me!
2018.02.25 02:34:12 3: Sduino IT: IT_V3_d892149 off->on
2018.02.25 02:34:12 2: Sduino IT: IT_V3_d89214a (0001101100010010010000101001010) not defined (Address: 00011011000100100100001010 Group: 0 Unit: 1010 Switch code: 1)
2018.02.25 02:34:12 4: autocreate: received 1 event(s) for 'IT 00011011000100100100001010 0 1010' during the last 30 seconds
2018.02.25 02:34:12 4: autocreate: ignoring event for 'IT 00011011000100100100001010 0 1010': at least 2 needed
2018.02.25 02:34:12 3: Sduino IT: IT_V3_d892149 on->on
2018.02.25 02:34:35 0: ERROR: Cannot autoload FS10
2018.02.25 02:34:35 3: Sduino: Unknown code P61#569A5659655, help me!
2018.02.25 02:34:35 3: Sduino IT: IT_V3_d892149 on->off
2018.02.25 02:52:12 2: LuftdatenInfo (air) - error while request: 192.168.178.58: Connection refused
.
.
2018.02.25 03:06:44 3: Sduino IT: IT_V3_d892149 off->on
2018.02.25 03:06:44 2: Sduino IT: IT_V3_d89a149 (0001101100010011010000101001001) not defined (Address: 00011011000100110100001010 Group: 0 Unit: 1001 Switch code: 1)
2018.02.25 03:06:44 4: autocreate: received 1 event(s) for 'IT 00011011000100110100001010 0 1001' during the last 30 seconds
2018.02.25 03:06:44 4: autocreate: ignoring event for 'IT 00011011000100110100001010 0 1001': at least 2 needed
2018.02.25 03:06:44 3: Sduino IT: IT_V3_d892149 on->on
2018.02.25 03:06:44 2: Sduino IT: IT_V3_d89214a (0001101100010010010000101001010) not defined (Address: 00011011000100100100001010 Group: 0 Unit: 1010 Switch code: 1)
2018.02.25 03:06:44 4: autocreate: received 1 event(s) for 'IT 00011011000100100100001010 0 1010' during the last 30 seconds
2018.02.25 03:06:44 4: autocreate: ignoring event for 'IT 00011011000100100100001010 0 1010': at least 2 needed
2018.02.25 03:06:44 3: Sduino IT: IT_V3_d892149 on->on
2018.02.25 03:06:44 2: Sduino IT: IT_V3_d892949 (0001101100010010010100101001001) not defined (Address: 00011011000100100101001010 Group: 0 Unit: 1001 Switch code: 1)
2018.02.25 03:06:44 4: autocreate: received 1 event(s) for 'IT 00011011000100100101001010 0 1001' during the last 30 seconds
2018.02.25 03:06:44 4: autocreate: ignoring event for 'IT 00011011000100100101001010 0 1001': at least 2 needed
2018.02.25 03:06:51 3: Sduino IT: IT_V3_d892149 on->off
2018.02.25 03:06:51 1: PERL WARNING: Integer overflow in hexadecimal number at ./FHEM/10_IT.pm line 953.
2018.02.25 03:06:51 1: PERL WARNING: Hexadecimal number > 0xffffffff non-portable at ./FHEM/10_IT.pm line 953.
2018.02.25 03:06:51 3: Sduino: Unknown code i569A565965599599800, help me!
2018.02.25 03:06:51 3: Sduino IT: IT_V3_d892149 off->off
2018.02.25 03:06:51 2: Sduino IT: IT_V3_d89214a (0001101100010010010000101001010) not defined (Address: 00011011000100100100001010 Group: 0 Unit: 1010 Switch code: 0)
2018.02.25 03:06:51 4: autocreate: received 2 event(s) for 'IT 00011011000100100100001010 0 1010' during the last 30 seconds
2018.02.25 03:06:51 2: autocreate: define IT_V3_d89214a IT 00011011000100100100001010 0 1010
2018.02.25 03:06:53 3: Sduino IT: IT_V3_d892149 off->off
2018.02.25 03:06:53 1: FreezeMon: freezedetect possible freeze starting at 03:06:52, delay is 1.365 by
2018.02.25 03:06:53 3: Sduino IT: IT_V3_d89214a ???->off
2018.02.25 03:06:53 2: Sduino IT: IT_V3_6c490a5 (000110110001001001000010100101D) not defined (Address: 00011011000100100100001010 Group: 0 Unit: 101D Switch code: 0)
2018.02.25 03:06:53 4: autocreate: received 1 event(s) for 'IT 00011011000100100100001010 0 101D' during the last 30 seconds
2018.02.25 03:06:53 4: autocreate: ignoring event for 'IT 00011011000100100100001010 0 101D': at least 2 needed
2018.02.25 03:06:53 3: Sduino IT: IT_V3_d892149 off->off
2018.02.25 03:06:53 2: Sduino IT: IT_V3_d89214 (000110110001001001000010100D001) not defined (Address: 00011011000100100100001010 Group: 0 Unit: D001 Switch code: 0)
2018.02.25 03:06:53 4: autocreate: received 1 event(s) for 'IT 00011011000100100100001010 0 D001' during the last 30 seconds
2018.02.25 03:06:53 4: autocreate: ignoring event for 'IT 00011011000100100100001010 0 D001': at least 2 needed
2018.02.25 03:06:53 2: Sduino IT: IT_V3_6c490a5 (000110110001001001000010100101D) not defined (Address: 00011011000100100100001010 Group: 0 Unit: 101D Switch code: 0)
2018.02.25 03:06:53 4: autocreate: received 2 event(s) for 'IT 00011011000100100100001010 0 101D' during the last 30 seconds
2018.02.25 03:06:53 2: autocreate: define IT_V3_6c490a5 IT 00011011000100100100001010 0 101D
2018.02.25 03:06:53 1: define IT_V3_6c490a5 IT 00011011000100100100001010 0 101D: Define IT_V3_6c490a5: wrong Unit format: specify 4 digits 0/1
2018.02.25 03:06:53 1: ERROR: Define IT_V3_6c490a5: wrong Unit format: specify 4 digits 0/1
2018.02.25 03:06:53 3: Sduino IT: IT_V3_d892149 off->off
2018.02.25 03:06:53 2: Sduino IT: IT_V3_6c490a5 (000110110001001001000010100101D) not defined (Address: 00011011000100100100001010 Group: 0 Unit: 101D Switch code: 0)
2018.02.25 03:06:53 4: autocreate: received 1 event(s) for 'IT 00011011000100100100001010 0 101D' during the last 30 seconds
2018.02.25 03:06:53 4: autocreate: ignoring event for 'IT 00011011000100100100001010 0 101D': at least 2 needed
.
.
ZitatDie SDWS37/FS10 Meldungen kommen mir auch spanisch vor. Kommen permanent.
SDWS37 ist der Bresser 7009994. Hat evtl einer Deiner Nachbarn den Bresser oder einen FS10 Sender.
Es kann auch sein, daß eines der Signale Deiner Sensoren eine Ähnichkeit mit diesen hat und deshalb fälschlicherweise erkannt wird.
U65# ist Homeeasy, es ist im Signalduino noch nicht fertig eingebaut. Die empfangenen Daten müssen wahrscheinlich für das IT-Modul noch gewandelt werden.
Kann es sein, daß der PIR1000 in 2 Formaten sendet, ITv3 und homeeasy?
Wird vom cul das homeeasy auch erkannt?
Mit dem "attr doubleMsgCheck_IDs 17" hatte ich einen Denkfehler. Da die IDs 4 und 17 ähnlich sind, werden beim PIR1000 beide erkannt.
Mit dem doubleMsgCheck_IDs 17 müssen bei der ID 17 zwei gleiche Nachrichten empfangen werden, damit ein dispatch erfolgt.
Bei cul ist es glaube ich ähnlich.
Damit das mit dem doubleMsgCheck_IDs 17 funktionieren kann, mußt Du entweder die Whitelist verwenden und dort alle verwendeten Protokolle eintragen,
oder das "attr blacklist_IDs 4" verwenden.
Kann es sein, daß die Reichweite des PIR1000 nicht sehr groß ist und daß die Signalzeiten schwanken.
In der 3.3.2-dev war bei der Ausgabe von Wiederholungen ein kleiner Bug, der sich bei Sensoren mit schwankenden Signalzeiten ausgewirkt hat.
Es gibt für den nano und für den 3,3V promini neue hex-Files
Gruß Ralf
ZitatKann es sein, daß der PIR1000 in 2 Formaten sendet, ITv3 und homeeasy
Kann ich mir nicht vorstellen, da
ZitatWird vom cul das homeeasy auch erkannt
negativ zu beantworten ist.
ZitatKann es sein, daß die Reichweite des PIR1000 nicht sehr groß ist und daß die Signalzeiten schwanken
Glaub ich nicht. Steht im selben Raum 3m entfernt zum S'duino. RSSI -67. Pulslängen guck ich mir mal in den raw messages an.
doubleMsgCheck_IDs hab ich jetzt verstanden. Ich versuch damit dann auch mal die Flut der falschen Revolt-devices einzudämmen.
ZitatSDWS37 ist der Bresser 7009994. Hat evtl einer Deiner Nachbarn den Bresser oder einen FS10 Sender.
Der SDWS37 kann nicht wirklich ein SDWS37 sein. Liefert ja ständig Checksummenfehler und wurde nun auch angelegt mit Temp=-41,4° So kalt ist es nun auch wieder nicht ;D
Ich flash dann mal neu und beobachte nach einem restart.
Grüße Markus
Hi Ralf,
ich hab jetzt mal mit der Version vom 25.2. durchlaufen lassen. blacklist_IDs=4, doubleMsgCheck_IDs=17,45.
Revolt-Falscheinträge hab ich keinen Einzigen mehr. Logischerweise ist die Aktualisierungsrate aber gesunken. Für meinen PIR1000 gibt es nur noch einen Falscheintrag. Die SD_WS37er sind deutlich seltener geworden. FS10-Meldungen überhaupt nicht mehr im Log(könnte aber daran liegen, dass ich das FS10-Modul kopiert habe und shutdown/restart gemacht hatte).
Ein paar Logauszüge: Anlage des falschen PIR1000(danach lt. timestamp scheinbar keine weitere falsche Erkennung)
2018.02.27 17:52:13 3: Sduino: Unknown code U65#34ACB2CAB32B2C, help me!
2018.02.27 17:52:13 3: Sduino: Unknown code U65#95A69596595665658, help me!
2018.02.27 17:52:13 3: Sduino: Unknown code U65#CCACB4ACB2CAB32B2C, help me!
2018.02.27 17:52:13 3: Sduino: Unknown code U65#566565A565965599596, help me!
2018.02.27 17:52:14 3: Sduino: Unknown code U65#CAB32B4D2B2CB2ACCACB0, help me!
2018.02.27 17:52:35 3: Sduino IT: IT_V3_d892149 off->off
2018.02.27 17:52:36 3: Sduino IT: IT_V3_d892149 off->off
2018.02.27 17:52:47 3: Sduino: Unknown code U65#996969596595665A58, help me!
2018.02.27 17:52:47 3: Sduino: Unknown code U65#ACCB434ACB2CAB32D2C, help me!
2018.02.27 17:52:48 3: Sduino: Unknown code U65#95665A9A565965599696, help me!
2018.02.27 17:52:48 2: Sduino IT: IT_V3_d89214a (0001101100010010010000101001010) not defined (Address: 00011011000100100100001010 Group: 0 Unit: 1010 Switch code: 1)
2018.02.27 17:52:48 4: autocreate: received 1 event(s) for 'IT 00011011000100100100001010 0 1010' during the last 30 seconds
2018.02.27 17:52:48 4: autocreate: ignoring event for 'IT 00011011000100100100001010 0 1010': at least 2 needed
2018.02.27 17:52:49 3: Sduino: Unknown code u20#0000A08000000000000AA8088800888228A, help me!
2018.02.27 17:52:52 3: Sduino: Unknown code U65#569A565965599596, help me!
2018.02.27 17:52:52 3: Sduino: Unknown code U65#32B2D2B2CB2ACCACB0, help me!
2018.02.27 17:52:53 3: Sduino: Unknown code U65#5995969596595665658, help me!
2018.02.27 17:52:53 3: Sduino: Unknown code U65#2ACCAD34ACB2CAB32B2C, help me!
2018.02.27 17:52:53 3: Sduino: Unknown code U65#59566569A565965599596, help me!
2018.02.27 17:52:54 2: Sduino IT: IT_V3_d89214a (0001101100010010010000101001010) not defined (Address: 00011011000100100100001010 Group: 0 Unit: 1010 Switch code: 0)
2018.02.27 17:52:54 4: autocreate: received 2 event(s) for 'IT 00011011000100100100001010 0 1010' during the last 30 seconds
2018.02.27 17:52:54 2: autocreate: define IT_V3_d89214a IT 00011011000100100100001010 0 1010
2018.02.27 17:52:57 3: Sduino IT: IT_V3_d89214a ???->on
Bei eigentlich richtiger Erkennung immer wieder U65er dazwischen
2018.02.27 19:25:51 3: Sduino IT: IT_V3_d892149 off->on
2018.02.27 19:25:56 3: Sduino IT: IT_V3_d892149 on->off
2018.02.27 19:26:11 3: Sduino: Unknown code U65#569A565965599696, help me!
2018.02.27 19:26:11 3: Sduino IT: IT_V3_d892149 off->on
2018.02.27 19:26:12 3: Sduino: Unknown code U65#AD34ACB2CAB32D2C, help me!
2018.02.27 19:26:12 3: Sduino IT: IT_V3_d892149 on->on
2018.02.27 19:26:16 3: Sduino: Unknown code U65#569A565965599596, help me!
2018.02.27 19:26:16 3: Sduino IT: IT_V3_d892149 on->off
2018.02.27 19:26:27 3: Sduino: Unknown code U65#569A565965599696, help me!
2018.02.27 19:26:27 3: Sduino IT: IT_V3_d892149 off->on
2018.02.27 19:26:32 3: Sduino: Unknown code U65#69A565965599596, help me!
2018.02.27 19:26:32 3: Sduino IT: IT_V3_d892149 on->off
2018.02.27 19:27:02 3: Sduino IT: IT_V3_d892149 off->on
2018.02.27 19:27:12 3: Sduino IT: IT_V3_d892149 on->off
2018.02.27 19:29:57 3: Sduino: Unknown code U65#569A565965599696, help me!
2018.02.27 19:29:57 3: Sduino IT: IT_V3_d892149 off->on
2018.02.27 19:30:17 3: Sduino IT: IT_V3_d892149 on->off
2018.02.27 19:30:17 3: Sduino IT: IT_V3_d892149 off->off
2018.02.27 19:30:24 3: Sduino IT: IT_0000FFFF0F off->on
Die Nacht. Ich vermute, dass sich die falschen U20er aus Überlagerungen Revolt/Oregon ergeben oder ein Nachbardevice. Oder aber es hängt mit Systemhängern zusammen ? Es ist nämlich auffällig, dass die u20er fast immer mit einem freeze(freezemon) einhergehen(hab ich aus den Logs rausgeschnitten)Keine U65er, kein SD_WS37.
2018.02.28 03:29:48 3: Sduino: Unknown code u20#555F5D555555D57D75DD577D75DD75F5FC, help me!
2018.02.28 03:44:54 3: Sduino: Unknown code u20#555555D57C, help me!
2018.02.28 03:51:56 3: Sduino: Unknown code u20#F77F5FD555555557D7555555755F5D7755DF5D775D7D7F, help me!
2018.02.28 03:54:14 3: Sduino: Unknown code u20#555F5D555555D57D75DD577D75DD75F5FC, help me!
2018.02.28 04:01:23 3: Sduino: Unknown code u20#7DF77F5FD555555557D7555555755F5D7755DF5D775D7D7F, help me!
2018.02.28 04:01:51 3: Sduino: Unknown code u20#555F5D555555D57D75DD577D75DD75F5FC, help me!
2018.02.28 04:27:00 3: Sduino: Unknown code u20#7555F7DDFD7F555555555F5D555555D77D75DD577D75DD77777C, help me!
2018.02.28 04:28:20 3: Sduino: Unknown code u20#57DF77F5FD555555557D7555555755F5D7755DF5D775D7D7F, help me!
2018.02.28 04:29:58 3: Sduino: Unknown code u20#7555F7DDFD7D555555555F5D555555D57D75DD577D75DD5FF5DE, help me!
2018.02.28 04:30:11 3: Sduino: Unknown code u20#555F, help me!
2018.02.28 04:37:59 3: Sduino: Unknown code u20#7555F7DDFD7F555555555F5D555555D57D75DD577D75DD75F5FC, help me!
2018.02.28 04:38:04 3: Sduino: Unknown code u20#555F, help me!
2018.02.28 04:38:15 3: Sduino: Unknown code u20#7555F7DDFD7F555555555F5D555555D57D75DD577D75DD75F5FC, help me!
2018.02.28 04:38:19 3: Sduino: Unknown code u20#555F5D555555D57D75DD577D75DD75F5FC, help me!
2018.02.28 04:38:50 3: Sduino: Unknown code u20#DFD7F555555555F5D555555D57D75DD577D75DD75F5FC, help me!
2018.02.28 04:39:53 3: Sduino: Unknown code u20#DFD7D555555555F5D555555D57D75DD577D75DD5FF5DC, help me!
2018.02.28 04:40:02 3: Sduino: Unknown code u20#ABEFBBFAFEAAAAAAAABEBAAAAAABAAFAEBBAAEFAEBBAEBEBF8, help me!
2018.02.28 04:41:33 3: Sduino: Unknown code u20#7555F7DDFD7F555555555F5D555555D57D75DD577D75DD75F5FC, help me!
2018.02.28 04:42:05 3: Sduino: Unknown code u20#7555F7DDFD7F555555555F5D555555D57D75DD577D75DD75F5FC, help me!
2018.02.28 04:42:39 3: Sduino: Unknown code u20#5555555F5D555555D5DFD7F555555555F5D555555D57D75DD577D75DD75F5FC, help me!
2018.02.28 04:43:11 3: Sduino: Unknown code u20#77DDFD7D555555555F5D555555D57D75DD577D75DD5FF5DC, help me!
2018.02.28 04:44:05 3: Sduino: Unknown code u20#5555557D7555555755F5D77555555557D7555555755F5D7755DF5D775D7D7F, help me!
2018.02.28 04:45:07 3: Sduino: Unknown code u20#7555F7DDFD7F555555555F5D555555D57D75DD577D75DD75F5FC, help me!
2018.02.28 04:45:14 3: Sduino: Unknown code u20#555F5D555555D57D75DD577D75DD75F5FC, help me!
2018.02.28 04:49:02 3: Sduino: Unknown code u20#5555F7DDFD7F555555555F5D555555D57D75DD577D75DD75F5FC, help me!
2018.02.28 04:52:58 3: Sduino: Unknown code u20#7555F7DDFD7F555555555F5D555555D57D75DD577D75DD75F5FC, help me!
2018.02.28 04:53:30 3: Sduino: Unknown code u20#75DD577D75DD5DD77D5557F7D75DD577D75DD5DD778, help me!
2018.02.28 05:02:38 3: Sduino: Unknown code u20#7555F7DDFD7F555555555F5D555555D57D75DD577D75DD75F5FC, help me!
2018.02.28 05:02:50 3: Sduino: Unknown code u20#555F5D555555D57D75DD577D75DD75F5FC, help me!
2018.02.28 05:08:32 3: Sduino: Unknown code u20#D7555555755F5D777D75DD75F5FD55555755F5D777D75DD75F5FC, help me!
2018.02.28 05:12:25 3: Sduino: Unknown code u20#555F5D555555D57D75DD577D75DD5FF5DC, help me!
2018.02.28 05:16:30 3: Sduino: Unknown code u20#7555F7DDFD7F555555555F5D555555D57D75DD577D75DD75F5FD, help me!
2018.02.28 05:17:36 3: Sduino: Unknown code u20#555F5D555555D57D75DD577D75DD75F5FC, help me!
2018.02.28 05:23:31 3: Sduino: Unknown code u20#FD55555555555F5D5555557F7D75DD577D75DD5DF5DC, help me!
2018.02.28 05:28:56 3: Sduino: Unknown code u20#DFD775, help me!
2018.02.28 05:29:19 3: Sduino: Unknown code u20#7555F7DDFD7D555555555F5D555555D57D75DD577D75DD5FF5DE, help me!
2018.02.28 05:31:24 3: Sduino: Unknown code u20#7555F7DDFD77555555555F5D555555D57D75DD577D75DD5DF5F6, help me!
2018.02.28 05:34:41 3: Sduino: Unknown code u20#AEFAEBBABFEBBC, help me!
2018.02.28 05:35:41 3: Sduino: Unknown code u20#5D555555D57D75DD55555555F5D555555D57D75DD0, help me!
2018.02.28 05:36:03 3: Sduino: Unknown code u20#7555F7DDFD77555555555F5D555555D57D75DD577D75DD5DF5F6, help me!
2018.02.28 05:40:17 3: Sduino: Unknown code u20#7555F7DDFD7D555555555F5D555555D57D75DD577D75DD5FF5DF, help me!
2018.02.28 05:41:24 3: Sduino: Unknown code u20#FD7D555555555F5D555555D57D75DD577D75DD5FF5DC, help me!
2018.02.28 05:56:59 3: Sduino: Unknown code u20#7555F7DDFD7D555555555F5D555555D57D75DD577D75DD5FF5DE, help me!
2018.02.28 05:58:43 3: Sduino: Unknown code u20#555557F7D75DD577DF5DFF5D5555557F7D75DD577DF5DE, help me!
2018.02.28 06:05:22 3: Sduino: Unknown code u20#7DF77F5D5555555557D7555555755F5D7755DF5D7755FD77, help me!
2018.02.28 06:09:01 3: Sduino: Unknown code u20#7555F7DDFD75555555555F5D555555D57D75DD577D75DD57F5DC, help me!
2018.02.28 06:17:27 3: Sduino: Unknown code u20#7555F7DDFD75555555555F5D555555D57D75DD577D75DD57F5DC, help me!
2018.02.28 06:18:04 3: Sduino: Unknown code u20#7555F7DDFD75555555555F5D555555D57D75DD577D75DD57F5DC, help me!
2018.02.28 06:25:59 3: Sduino: Unknown code u20#7555F7DDFD75555555555F5D555555D57D75DD577D75DD57F5DC, help me!
2018.02.28 06:28:23 3: Sduino: Unknown code u20#DFD75555555555F5D5555557F7D75DD577D75DD55F5DC, help me!
2018.02.28 06:30:01 3: Sduino: Unknown code u20#7555F7DDFD75555555555F5D555555D57D75DD577D75DD57F5DC, help me!
2018.02.28 06:30:49 3: Sduino: Unknown code u20#7555F7DDFD75555555555F5D555555D57D75DD577D75DD57F5DC, help me!
2018.02.28 06:36:09 3: Sduino: Unknown code u20#777F5D5555555557D7555555755F5D7755DF5D7755FD77, help me!
2018.02.28 06:36:26 3: Sduino: Unknown code u20#7555F7DDFD75555555555F5D555555D57D75DD577D75DD57F5DC, help me!
2018.02.28 06:36:52 3: Sduino: Unknown code u20#5F5D7755DF5D7755FD77, help me!
2018.02.28 06:41:21 3: Sduino: Unknown code u20#7555F7DDFD77555555555F5D555555D57D75DD577D75DD5DF5F6, help me!
2018.02.28 06:46:36 3: Sduino: Unknown code u20#557D7555555755F5D7755DF5D7755FD77, help me!
Sobald der Bewegungsmelder aktiv wird, kommen wieder U65er u. IT-Fehlinterpretationen(u20er u. freezes raus editiert)
2018.02.28 07:32:37 3: Sduino IT: IT_V3_d892149 off->on
2018.02.28 07:32:38 3: Sduino IT: IT_V3_d892149 on->on
2018.02.28 07:32:42 3: Sduino IT: IT_V3_d892149 on->off
2018.02.28 07:32:42 1: PERL WARNING: Illegal binary digit 'D' ignored at ./FHEM/10_IT.pm line 1127.
2018.02.28 07:32:42 2: Sduino IT: IT_V3_6c490a5 (000110110001001001000010100101D) not defined (Address: 00011011000100100100001010 Group: 0 Unit: 101D Switch code: 0)
2018.02.28 07:32:42 4: autocreate: received 1 event(s) for 'IT 00011011000100100100001010 0 101D' during the last 30 seconds
2018.02.28 07:32:42 4: autocreate: ignoring event for 'IT 00011011000100100100001010 0 101D': at least 2 needed
2018.02.28 07:32:42 3: Sduino IT: IT_V3_d892149 off->off
2018.02.28 07:32:45 3: Sduino IT: IT_V3_d892149 off->on
2018.02.28 07:33:12 3: Sduino: Unknown code U65#569A565965599596, help me!
2018.02.28 07:33:13 3: Sduino: Unknown code U65#32B2D2B2CB2ACCACB0, help me!
2018.02.28 07:33:13 3: Sduino: Unknown code U65#5995869596595665658, help me!
2018.02.28 07:33:13 3: Sduino: Unknown code U65#2ACCAD34ACB2CAB32B2C, help me!
2018.02.28 07:33:13 3: Sduino IT: IT_V3_d892149 on->off
2018.02.28 07:33:14 2: Sduino IT: IT_V3_6c490a5 (000110110001001001000010100101D) not defined (Address: 00011011000100100100001010 Group: 0 Unit: 101D Switch code: 0)
2018.02.28 07:33:14 4: autocreate: received 1 event(s) for 'IT 00011011000100100100001010 0 101D' during the last 30 seconds
2018.02.28 07:33:14 4: autocreate: ignoring event for 'IT 00011011000100100100001010 0 101D': at least 2 needed
2018.02.28 07:33:25 3: Sduino IT: IT_V3_d892149 off->on
2018.02.28 07:33:30 3: Sduino: Unknown code U65#569A565965599596, help me!
2018.02.28 07:33:30 3: Sduino: Unknown code U65#32B2D2B2CB2ACCACB0, help me!
2018.02.28 07:33:30 3: Sduino: Unknown code U65#5995A69596595665658, help me!
2018.02.28 07:33:31 3: Sduino: Unknown code U65#2ACCAD34ACB2CAB32B2C, help me!
2018.02.28 07:33:31 3: Sduino IT: IT_V3_d892149 on->off
2018.02.28 07:34:18 3: Sduino: Unknown code U65#569A565965599696, help me!
2018.02.28 07:34:19 3: Sduino: Unknown code U65#32D2D2B2CB2ACCB4B0, help me!
2018.02.28 07:34:19 3: Sduino: Unknown code U65#5996A69596595665A58, help me!
2018.02.28 07:34:19 3: Sduino: Unknown code U65#2ACCAD34ACB2CAB32D2C, help me!
2018.02.28 07:34:19 3: Sduino IT: IT_V3_d892149 off->on
2018.02.28 07:34:23 3: Sduino IT: IT_V3_d892149 on->off
2018.02.28 07:34:37 3: Sduino IT: IT_V3_d892149 off->off
2018.02.28 07:34:40 3: Sduino IT: IT_V3_d892149 off->on
2018.02.28 07:34:45 3: Sduino: Unknown code U65#2B2D2B2CB2ACCACB0, help me!
2018.02.28 07:35:21 3: Sduino IT: IT_V3_d892149 on->on
2018.02.28 07:35:23 3: Sduino: Unknown code U65#6969596595665A58, help me!
2018.02.28 07:35:27 3: Sduino IT: IT_V3_d892149 on->off
2018.02.28 07:36:44 3: Sduino: Unknown code U65#569A565965599696, help me!
2018.02.28 07:36:53 3: Sduino IT: IT_V3_d892149 off->off
2018.02.28 07:37:21 3: Sduino IT: IT_V3_d892149 off->off
2018.02.28 07:37:41 3: Sduino IT: IT_V3_d892149 off->on
2018.02.28 07:37:42 3: Sduino IT: IT_V3_d892149 on->off
2018.02.28 07:37:49 3: Sduino IT: IT_V3_d892149 off->on
2018.02.28 07:38:37 3: Sduino IT: IT_V3_d892149 on->on
2018.02.28 07:39:12 3: Sduino: Unknown code U65#569A565965599596, help me!
2018.02.28 07:39:12 3: Sduino: Unknown code U65#32B2D2B2CB2ACCACB0, help me!
2018.02.28 07:39:12 3: Sduino: Unknown code U65#5995969596595665658, help me!
2018.02.28 07:39:12 3: Sduino: Unknown code U65#2ACCACB4ACB2CAB32B2C, help me!
2018.02.28 07:39:13 3: Sduino: Unknown code U65#59566569A565965599596, help me!
2018.02.28 07:39:13 3: Sduino: Unknown code U65#B2CAB32B4D2B2CB2ACCACB0, help me!
2018.02.28 07:39:17 3: Sduino IT: IT_V3_d892149 on->on
2018.02.28 07:39:42 3: Sduino: Unknown code U65#569A565965599596, help me!
2018.02.28 07:39:42 3: Sduino IT: IT_V3_d892149 on->off
2018.02.28 07:39:47 3: Sduino IT: IT_V3_d892149 off->off
2018.02.28 07:39:49 3: Sduino IT: IT_V3_d892149 off->on
2018.02.28 07:39:57 3: Sduino IT: IT_V3_d892149 on->off
2018.02.28 07:40:05 3: Sduino: Unknown code U65#569A565965599696, help me!
2018.02.28 07:40:05 3: Sduino IT: IT_V3_d892149 off->on
2018.02.28 07:40:13 3: Sduino: Unknown code U65#569A565965599596, help me!
2018.02.28 07:40:13 3: Sduino IT: IT_V3_d892149 on->off
2018.02.28 07:41:56 3: Sduino: Unknown code U65#69A565965599696, help me!
2018.02.28 07:41:56 3: Sduino IT: IT_V3_d892149 off->on
2018.02.28 07:42:03 3: Sduino IT: IT_V3_d892149 on->off
2018.02.28 07:43:32 3: Sduino IT: IT_V3_d892149 off->on
2018.02.28 07:43:40 3: Sduino IT: IT_V3_d892149 on->off
2018.02.28 07:44:36 3: Sduino: Unknown code U65#34ACB2CAB32D2C, help me!
2018.02.28 07:44:36 3: Sduino: Unknown code U65#69A565965599696, help me!
2018.02.28 07:44:36 3: Sduino IT: IT_V3_d892149 off->on
2018.02.28 07:44:47 3: Sduino: Unknown code U65#569A565965599596, help me!
2018.02.28 07:44:48 3: Sduino IT: IT_V3_d892149 on->off
2018.02.28 07:45:13 3: Sduino IT: IT_V3_d892149 off->on
2018.02.28 07:45:24 3: Sduino IT: IT_V3_d892149 on->off
2018.02.28 07:45:45 3: Sduino IT: IT_V3_d892149 off->on
2018.02.28 07:45:55 3: Sduino: Unknown code U65#569A565965599596, help me!
2018.02.28 07:45:55 3: Sduino IT: IT_V3_d892149 on->off
2018.02.28 07:46:22 3: Sduino: Unknown code U65#569A565965599696, help me!
2018.02.28 07:46:22 3: Sduino IT: IT_V3_d892149 off->on
2018.02.28 07:46:42 3: Sduino IT: IT_V3_d892149 on->off
2018.02.28 07:47:29 3: Sduino IT: IT_V3_d892149 off->on
2018.02.28 07:47:38 3: Sduino: Unknown code U65#569A565965599596, help me!
2018.02.28 07:47:38 3: Sduino IT: IT_V3_d892149 on->off
2018.02.28 07:47:39 3: Sduino IT: IT_V3_d892149 off->off
2018.02.28 07:48:17 3: Sduino IT: IT_V3_d892149 off->on
2018.02.28 07:48:26 3: Sduino IT: IT_V3_d892149 on->off
2018.02.28 07:49:14 3: Sduino IT: IT_V3_d892149 off->on
2018.02.28 07:49:15 3: Sduino: Unknown code U65#569A565965599596, help me!
2018.02.28 07:49:16 3: Sduino IT: IT_V3_d892149 on->off
2018.02.28 07:49:25 3: Sduino: Unknown code U65#569A565965599696, help me!
2018.02.28 07:49:25 3: Sduino IT: IT_V3_d892149 off->on
2018.02.28 07:49:39 3: Sduino: Unknown code u20#028200028A0808AA2AA0228A822000A80, help me!
2018.02.28 07:49:40 3: Sduino: Unknown code U65#569A565965599596, help me!
2018.02.28 07:49:40 3: Sduino IT: IT_V3_d892149 on->off
2018.02.28 07:49:49 3: Sduino IT: IT_V3_d892149 off->on
2018.02.28 07:50:04 3: Sduino IT: IT_V3_d892149 on->off
2018.02.28 07:51:16 3: Sduino: SD_WS37 ERROR - checksum 2 != 253
2018.02.28 07:59:38 3: Sduino: Unknown code U65#D34ACB2CAB32D2C, help me!
2018.02.28 07:59:38 3: Sduino IT: IT_V3_d892149 off->on
2018.02.28 07:59:50 3: Sduino IT: IT_V3_d892149 on->off
2018.02.28 08:00:19 3: Sduino IT: IT_V3_d892149 off->on
2018.02.28 08:00:25 3: Sduino: SD_WS37 ERROR - checksum 3 != 30
2018.02.28 08:00:25 3: Sduino: SD_WS37 ERROR - checksum 3 != 30
2018.02.28 08:00:34 3: Sduino: Unknown code U65#569A565965599596, help me!
2018.02.28 08:00:34 3: Sduino IT: IT_V3_d892149 on->off
2018.02.28 08:00:39 3: Sduino IT: IT_V3_d892149 off->on
2018.02.28 08:01:00 3: Sduino IT: IT_V3_d892149 on->off
2018.02.28 08:01:04 3: Sduino IT: IT_V3_d892149 off->on
2018.02.28 08:01:15 3: Sduino IT: IT_V3_d892149 on->off
2018.02.28 08:01:16 3: Sduino IT: IT_V3_d892149 off->off
2018.02.28 08:10:36 3: Sduino IT: IT_V3_d892149 off->on
2018.02.28 08:10:41 3: Sduino: Unknown code U65#5A69596595665658, help me!
2018.02.28 08:10:41 3: Sduino IT: IT_V3_d892149 on->off
2018.02.28 08:14:28 3: Sduino IT: IT_0F00F0000F ???->on
2018.02.28 08:14:28 4: autocreate: received 1 event(s) for 'IT 0F0000000F FF F0' during the last 30 seconds
2018.02.28 08:14:28 4: autocreate: ignoring event for 'IT 0F0000000F FF F0': at least 2 needed
2018.02.28 08:14:32 4: autocreate: received 2 event(s) for 'IT 0F0000000F FF F0' during the last 30 seconds
2018.02.28 08:14:32 2: autocreate: define IT_0F0000000F IT 0F0000000F FF F0
2018.02.28 08:15:05 3: Sduino IT: IT_V3_d892149 off->on
2018.02.28 08:15:14 3: Sduino IT: IT_V3_d892149 on->off
2018.02.28 08:15:56 3: Sduino IT: IT_V3_d892149 off->on
2018.02.28 08:16:01 3: Sduino IT: IT_V3_d892149 on->off
2018.02.28 08:16:19 3: Sduino: Unknown code U65#569A565965599696, help me!
2018.02.28 08:16:20 3: Sduino IT: IT_V3_d892149 off->on
2018.02.28 08:16:20 3: Sduino: Unknown code U65#AD34ACB2CAB32D2C, help me!
2018.02.28 08:16:20 3: Sduino IT: IT_V3_d892149 on->on
2018.02.28 08:16:32 3: Sduino IT: IT_V3_d892149 on->off
2018.02.28 08:16:42 3: Sduino IT: IT_V3_d892149 off->on
2018.02.28 08:16:43 3: Sduino IT: IT_V3_d892149 on->on
2018.02.28 08:16:56 3: Sduino: Unknown code U65#D34ACB2CAB32B2C, help me!
2018.02.28 08:16:56 3: Sduino IT: IT_V3_d892149 on->off
2018.02.28 08:19:30 3: Sduino IT: IT_V3_d892149 off->on
2018.02.28 08:19:38 3: Sduino IT: IT_V3_d892149 on->off
2018.02.28 08:20:33 3: Sduino IT: IT_V3_d892149 off->on
2018.02.28 08:20:59 3: Sduino IT: IT_V3_d892149 on->off
2018.02.28 08:21:06 3: Sduino IT: IT_V3_d892149 off->on
2018.02.28 08:21:07 3: Sduino: Unknown code U65#AD34ACB2CAB32D2C, help me!
2018.02.28 08:21:07 3: Sduino IT: IT_V3_d892149 on->on
2018.02.28 08:21:31 3: Sduino IT: IT_V3_d892149 on->off
2018.02.28 08:21:34 3: Sduino: Unknown code U65#569A565965599696, help me!
2018.02.28 08:21:34 3: Sduino IT: IT_V3_d892149 off->on
2018.02.28 08:21:54 3: Sduino: Unknown code U65#569A565965599596, help me!
2018.02.28 08:21:55 3: Sduino IT: IT_V3_d892149 on->off
2018.02.28 08:24:15 3: Sduino: Unknown code U65#569A565965599696, help me!
2018.02.28 08:24:15 3: Sduino IT: IT_V3_d892149 off->on
2018.02.28 08:24:23 3: Sduino: Unknown code U65#569A565965599596, help me!
2018.02.28 08:24:23 3: Sduino IT: IT_V3_d892149 on->off
2018.02.28 08:32:45 3: Sduino: Unknown code U65#569A565965599696, help me!
2018.02.28 08:32:45 3: Sduino IT: IT_V3_d892149 off->on
2018.02.28 08:32:50 3: Sduino: Unknown code U65#569A565965599596, help me!
2018.02.28 08:32:50 3: Sduino IT: IT_V3_d892149 on->off
2018.02.28 08:33:14 3: Sduino IT: IT_V3_d892149 off->on
2018.02.28 08:33:15 3: Sduino IT: IT_V3_d892149 on->on
2018.02.28 08:33:19 3: Sduino IT: IT_V3_d892149 on->off
2018.02.28 08:35:43 3: Sduino IT: IT_V3_d892149 off->on
2018.02.28 08:35:55 3: Sduino IT: IT_V3_d892149 on->off
2018.02.28 08:36:03 3: Sduino IT: IT_V3_d892149 off->on
2018.02.28 08:36:18 3: Sduino IT: IT_V3_d892149 on->off
2018.02.28 08:46:31 3: Sduino IT: IT_V3_d892149 off->on
2018.02.28 08:46:36 3: Sduino IT: IT_V3_d892149 on->off
2018.02.28 08:50:15 3: Sduino: Unknown code U65#569A565965599696, help me!
2018.02.28 08:50:16 3: Sduino IT: IT_V3_d892149 off->on
2018.02.28 08:50:21 3: Sduino IT: IT_V3_d892149 on->off
2018.02.28 08:50:22 3: Sduino IT: IT_V3_d892149 off->off
2018.02.28 08:52:11 3: Sduino: Unknown code U65#569A565965599696, help me!
2018.02.28 08:52:11 3: Sduino IT: IT_V3_d892149 off->on
2018.02.28 08:52:15 3: Sduino IT: IT_V3_d892149 on->off
2018.02.28 09:00:03 3: Sduino: Unknown code U65#569A565965599696, help me!
2018.02.28 09:00:03 3: Sduino IT: IT_V3_d892149 off->on
2018.02.28 09:00:07 3: Sduino: Unknown code U65#569A565965599596, help me!
2018.02.28 09:00:08 3: Sduino IT: IT_V3_d892149 on->off
2018.02.28 09:00:09 3: Sduino IT: IT_V3_d892149 off->off
2018.02.28 09:00:09 3: Sduino IT: IT_V3_d892149 off->off
2018.02.28 09:08:54 3: Sduino: Unknown code U65#569A565965599696, help me!
2018.02.28 09:08:54 3: Sduino IT: IT_V3_d892149 off->on
2018.02.28 09:08:58 3: Sduino: Unknown code U65#569A565965599596, help me!
2018.02.28 09:08:58 3: Sduino IT: IT_V3_d892149 on->off
2018.02.28 09:11:15 3: Sduino: SD_WS37 ERROR - checksum 36 != 206
2018.02.28 09:11:15 3: Sduino: SD_WS37 ERROR - checksum 36 != 206
2018.02.28 09:11:16 3: Sduino: SD_WS37 ERROR - checksum 36 != 206
Und nur um Missverständnisse zu vermeiden: für mich musst Du da nicht tiefer einsteigen und Zeit vergeuden. Mein Produktivsystem werde ich nach wie vor mit dem RFXTRX betreiben und den S'duino nur zu Analysezwecken einsetzen.
Grüße Markus
ZitatBei eigentlich richtiger Erkennung immer wieder U65er dazwischen
Solange das Homeeasy nicht vollständig im Signalduino eingebaut ist, kann maximal vermutet werden, daß erkannte U65er Homeeasy sein könnten.
Da die Protokolle 4,17 und 65 recht ähnlich sind, können die U65er auch fehlerhaft empfangene ITv3 Signale Deiner PIR1000 sein.
Nochmals Danke fürs testen.
Gruß Ralf
Schade, daß ich außer von @KölnSolar noch keine Rückmeldungen von der V 3.3.2-dev erhalten habe.
Interessant wären dabei besonders:
- Intertechno V3
- Siro mit aktivierem MC-Decoder.
- FS20 und FHT80
- das Maverick Funk Grillthermometer (ET 732/733)
Ich habe jetzt erstmal keine Lust und Motivatiion an der V 3.3.2-dev weiterzumachen. Ich werde jetzt erst mal abwarten ob weitere Rückmeldungen kommen.
Besteht überhaupt interesse an meiner V 3.3.2-dev.
Gruß Ralf
Hallo Ralf,
Ich habe weiterhin vor das Maverick zu testen, wird leider wegen wenig Freizeit und abgebauten SDuino etwas dauern. Und aufgrund der Kälte ist der Grill gerade eher selten an ;)
VG,
Dirk
Hallo Ralf,
was möchtest du beim FS20 geprüft haben.Ich habe noch FS20 Steckdosen (868,35 MHz).
Wenn ich den Signalduino auf 868 Stelle empfängt er dieses hier:
2018.03.02 15:04:26 5: SIG868 Dispatch: u57#0A8AA22500908428A7, test ungleich: disabled
2018.03.02 15:04:26 5: SIG868 Dispatch: u57#0A8AA22500908428A7, -46.5 dB, dispatch
2018.03.02 15:04:26 5: SIG868: dispatch u57#0A8AA22500908428A7
2018.03.02 15:04:26 4: SIGNALduino_unknown incomming msg: u57#0A8AA22500908428A7
2018.03.02 15:04:26 4: SIGNALduino_unknown rawData: 0A8AA22500908428A7
2018.03.02 15:04:26 4: SIGNALduino_unknown Protocol: 57
2018.03.02 15:04:26 4: SIGNALduino_unknown converted to bits: 000010101000101010100010001001010000000010010000100001000010100010100111
2018.03.02 15:04:26 4: Unknown, please report
2018.03.02 15:04:26 3: SIG868: Unknown code u57#0A8AA22500908428A7, help me!
pejonp
Mir reichen die raw Nachrichten beim Drücken einer Taste des FS20 Senders
Es müssten MU-Nachrichten sein die als ID 74 erkannt werden.
In dieser Art:
2018.03.02 15:54:07.575 4 : sduinoD/msg get raw: MU;P1=373;P2=-412;P3=590;P4=-610;D=0121212121212121212121212123412343412123434121234121234341212341212121212121212121212121234121212341212121234123434123415121212121212121212121212341234341212343412123412123434121234121212121212121212121212123412121234121212123412343412341512121212121212;CP=1;R=12;
2018.03.02 15:54:07.578 4 : sduinoD: Fingerprint for MU Protocol id 74 -> FS20 matches, trying to demodulate
2018.03.02 15:54:07.578 5 : sduinoD: applying postDemodulation, value before: 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 1 0 0 1 1 0 0 1 0 0 1 1 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 1 0 0 0 0 1 0 1 1 0 1
2018.03.02 15:54:07.578 4 : sduinoD: FS20 - remote control post demodulation 6699000011 length 45
2018.03.02 15:54:07.578 5 : sduinoD: rcode=1, modified value after postDemodulation: 0 1 1 0 0 1 1 0 1 0 0 1 1 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 1
2018.03.02 15:54:07.578 4 : sduinoD: decoded matched MU Protocol id 74 dmsg 810b04f70101a0016699000011 length 40 RSSI = -68
2018.03.02 15:54:07.578 5 : sduinoD: dispatch 810b04f70101a0016699000011
Gruß Ralf
Bei mir ist noch ein Hideki(vermutlich aus der Nachbarschaft) aufgetaucht
Sduino_DMSG P12#751F06751DC0B15C
Sduino_RAWMSG MC;LL=-1037;LH=918;SL=-551;SH=422;D=5183E7EA347FE5CB8A;C=487;L=71;R=250;s1;b1;
Wenn Du über pejonp's FS20 hinaus noch weitere Daten benötigst, könnte ich den 433 auch mal auf 868 umstellen.
Maverick u. Siro hab ich nicht :'(
Ich hab dann mal eine IT_V3_Dose mit FHEM getestet. Verhält sich arg komisch:
ein: funktioniert
aus: Dose schaltet nicht;Signal wird aber vom produktiven RFXTRX erkannt
Und ich kenn schon Deine Antwort: Das kann nicht sein ist ja nur das doofe on/off-Bit unterschiedlich
Aber mein IT-V3-Dimmer hat genau das selbe Verhalten....
Grüße Markus
Die Hideki werden bei mir auch sauber erkannt. Seitdem im Hideki Modul auch die second checksum geprüft wird, werden die Hideki Sensoren zuverlässig empfangen:
https://forum.fhem.de/index.php/topic,58397.msg723382.html#msg723382
ZitatIch hab dann mal eine IT_V3_Dose mit FHEM getestet. Verhält sich arg komisch
Dies ist dann ein blöder sehr schwer zu findender Fehler, da ich dies bei mir nicht nachvollziehen kann.
Ich tappe da noch komplett im dunkeln.
Das seltsame dabei ist, daß die anderen Protokolle problemlos empfangen werden.
Bei mir sind dies:
0 (CUL_TCM97001)
3 (ITv1)
7 (SD_WS07)
9 (Wetterstation WH3080)
12 (Hideki)
18 (OSV1)
61 (FS10)
Für mich wären die raw Nachrichten beim ein- und ausschalten hilfreich.
Gruß Ralf
Du meinst, wenn ich mit dem RFXTRX schalte ?
on: MS;P0=261;P1=-251;P3=-2549;P4=-1275;P5=-9992;D=030104010404010401010401040401010401040401010404010104040104010104010401040401040104010401040101040401010401040401010401040104040105;CP=0;SP=3;R=56;O;m=1;
off: MS;P0=255;P1=-250;P2=-1280;P3=-9988;P4=-2558;D=040102010202010201010201020201010201020201010202010102020102010102010201020201020102010201020101020201010201020102010201020102020103;CP=0;SP=4;R=56;O;m=0;
device IT_V3_192b1f41
Das erkennt der S'duino ja :-\ Und raw beim Senden geht doch nicht, oder ?
Edit: Vielleicht war das oben missverständlich: Das komische Verhalten ist beim send mit S'duino.
Ja, daß dies das send vom sduino betrifft ist mir nun auch klar geworden.
Da einzige, was mir auffällt, ist daß beim off beim sendmsg recht viele Nullen in Folge enthalten sind.
Es gibt irgendwo ein Thema wo es bei bestimmten unit codes Probleme gibt.
Ich habe das Gefühl, daß wir den ITv3 Code noch nicht 100% verstanden haben. Evtl gibt es auch beim Timing noch was zu beachten.
2018.03.02 22:54:12.409 3 : sduinoRXB IT_set: IT_V3_192b1f41 on
2018.03.02 22:54:12.414 5 : sduinoRXB: sendmsg msg=P17#00110010010101100011111010010001#R6
2018.03.02 22:54:12.414 5 : sduinoRXB: sendmsg Preparing rawsend command for protocol=17, repeats=6, clock=250 bits=00110010010101100011111010010001
2018.03.02 22:54:12.515 5 : sduinoRXB SR;R=6;P0=250;P1=-2500;P2=-1250;P3=-250;D=0103020302020302030302030202030302030202030302020303020203020303020302030202030203020302030203030202030302030202030302030203020203;
2018.03.02 22:54:13.680 3 : sduinoRXB IT_set: IT_V3_192b1f41 off
2018.03.02 22:54:13.683 5 : sduinoRXB: sendmsg msg=P17#00110010010101100011111010000001#R6
2018.03.02 22:54:13.683 5 : sduinoRXB: sendmsg Preparing rawsend command for protocol=17, repeats=6, clock=250 bits=00110010010101100011111010000001
2018.03.02 22:54:13.783 5 : sduinoRXB SR;R=6;P0=250;P1=-2500;P2=-1250;P3=-250;D=0103020302020302030302030202030302030202030302020303020203020303020302030202030203020302030203030202030302030203020302030203020203;
Du kannst auch raw senden. Z.B. das hier:
off: MS;P0=255;P1=-250;P2=-1280;P3=-9988;P4=-2558;D=040102010202010201010201020201010201020201010202010102020102010102010201020201020102010201020101020201010201020102010201020102020103;CP=0;SP=4;R=56;O;m=0;
kann so wieder gesendet werden:
get sduino raw SR;P0=255;P1=-250;P2=-1280;P3=-9988;P4=-2558;D=040102010202010201010201020201010201020201010202010102020102010102010201020201020102010201020101020201010201020102010201020102020103;
Gruß Ralf
Du kannst auch mal testen ob mit dem sduino das senden von "aus" funktioniert, wenn Du als unitcode 1001 oder 0010 verwendest.
Gruß Ralf
Ich habe dazu was gefunden:
https://forum.fhem.de/index.php/topic,79019.msg710073.html
https://forum.fhem.de/index.php?topic=58468
Gruß Ralf
Hallo Ralf,
ich habe den Signalduino auf whitelist_IDs=74 und verbose=5 gestellt.
Firmeware: version: V 3.3.1-dev SIGNALduino cc1101 - compiled at Mar 10 2017 22:54:50
00_SIGNALduino.pm 10488 2018-02-14 14:32:00Z v3.3.3-dev
Das kommt beim drücken der FS20 S8 Fernbedienung Tasten 1-4 Ein im log an. Wenn ich alle Protokolle freigebe wird u57# erkannt, wie einige Beiträge weiter vorne. Protokoll 74 wird nicht erkannt.
2018.03.03 01:29:26 4: SIG868/msg READ: MS;P1=376;P2=-415;P3=574;P4=-618;P5=-9354;D=151212121212121212121212121234343412123434343412123412123412343412121212121212121212121212341212123412121234341212123434;CP=1;SP=5;R=75;O;
2018.03.03 01:29:27 4: SIG868/msg READ: MC;LL=-621;LH=574;SL=-418;SH=369;D=FFF5776BFFF7BD7A8;C=330;L=65;R=73;
2018.03.03 01:29:30 4: SIG868/msg READ: MS;P1=376;P2=-413;P3=563;P4=-623;P5=-9340;D=1512121212121212121212121234343412123434343412123412123412343412121212121212121212121212341212123412121234341212123434;CP=1;SP=5;R=72;O;
2018.03.03 01:29:30 4: SIG868/msg READ: MC;LL=-634;LH=556;SL=-440;SH=357;D=FFD5DDAFFFDEF5EA;C=331;L=63;R=70;
2018.03.03 01:29:32 4: SIG868/msg READ: MS;P1=359;P2=-431;P4=569;P5=-619;P6=-9346;D=1612121212121212121212121245454512124545454512124512124512454512121212121212124545121212451212124512121245451212451245;CP=1;SP=6;R=71;O;
2018.03.03 01:29:33 4: SIG868/msg READ: MC;LL=-619;LH=565;SL=-433;SH=365;D=FD7ABBB5FF5EF7AED;C=330;L=68;R=69;
2018.03.03 01:29:35 4: SIG868/msg READ: MS;P1=361;P2=-418;P3=559;P4=-635;P5=-9342;D=1512121212121212121212121234343412123434343412123412123412343412121212121212341234121212341212123412121234341212343412;CP=1;SP=5;R=70;O;
2018.03.03 01:29:35 4: SIG868/msg READ: MC;LL=-623;LH=571;SL=-424;SH=370;D=EF7B5FEDEF7AEB;C=331;L=56;R=68;
2018.03.03 01:29:36 4: SIG868/msg READ: MU;P0=248;P1=-1035;P2=1471;P3=493;D=0121312121313121213131212131212131213121212121212131212121212121313121212121212121212121212121212121212121212121312121212131312121312;CP=2;R=236;
2018.03.03 01:29:36 4: SIG868/msg READ: MS;P1=555;P2=-632;P3=374;P4=-422;P5=-9342;D=3534343434343434343434343412121234341212121234341234341234121234341234123434343434343434123434341234123434343434341234;CP=3;SP=5;R=70;O;
2018.03.03 01:29:37 4: SIG868/msg READ: MU;P0=-477;P1=570;P3=351;D=01030103030303030301030301030303030303030301030303010301030303030303010303;CP=3;R=68;
Jörg
ZitatFirmeware: version: V 3.3.1-dev SIGNALduino cc1101 - compiled at Mar 10 2017 22:54:50
Daß es bei der Firmware V 3.3.1 Probleme mit FS20 gibt, ist bekannt.
Hier geht es um die Firmware V 3.3.2
@KölnSolar
Ich habe eine Vermutung, demnach funktioniert das Senden von ITv3 nur wenn der unitcode nicht mit 1 endet.
Gruß Ralf
Ich denke ich kann Deine Vermutung bestätigen. Eine Dose m. unit code 0000 funktioniert.
das vom RFXTRX empfangene off raw mit get Sduino raw senden klappt auch nicht bei unit code 0001.
Mal mit aculfw testen u. vergleichen? Da ich auf meiner Betty die aculfw hab u. mit ihr das schalten vom Dimmer(unit code 0111)klappt, scheint die aculfw "richtiger" zu sein. Blöd, dass der S'duino rein gar nichts von der Betty empfängt. :( Ich vermute, dass das am Basispuls liegt. Wie kann ich den verändern ?
Grüße Markus
@ralf
ccconf: freq:868.300MHz bWidth:325KHz rAmpl:42dB sens:4dB (DataRate:5603.79Baud)
version: V 3.3.2b-dev SIGNALduino cc1101 - compiled at Mar 3 2018 11:24:00
00_SIGNALduino.pm 10488 2018-02-14 14:32:00Z v3.3.3-dev
FS20 Commandos gedrückt, wird nichts erkannt nur diese Einträge im Log.
Wenn whitelist_ID nicht gesetzt ist, wird kein protokoll (auch nicht mal u57#) erkannt.
2018.03.03 11:33:33 4: SIG868: Calling Getting Attr sub with args: set whitelist_IDs = 74
2018.03.03 11:33:33 3: SIG868 Attr: whitelist_IDs
2018.03.03 11:33:33 3: SIG868 sduinoIdList: whitelistIds=74
2018.03.03 11:33:33 3: SIG868 sduinoIdList: blacklistIds=
2018.03.03 11:33:33 3: SIG868 sduinoIdList: development=
2018.03.03 11:33:33 3: SIG868: ID=74 skiped (developId=y)
2018.03.03 11:33:33 3: SIG868: IDlist MS
2018.03.03 11:33:33 3: SIG868: IDlist MU
2018.03.03 11:33:33 3: SIG868: IDlist MC
2018.03.03 11:33:46 4: SIG868/msg READredu: MU;P0=-1037;P1=1463;P2=503;P3=-188;P4=320;D=01010201020202010102010101010202010102010101010201023;CP=2;R=2;
2018.03.03 11:33:48 4: SIG868/msg READredu: MU;P0=-26232;P1=570;P2=-5236;P3=371;P4=-425;P5=-620;P6=-9346;D=01234343434343415151534341515151534341534341534151534343434343434341515343434153434341534343415153434153415;CP=3;R=60;w=0;
2018.03.03 11:33:48 4: SIG868/msg READredu: MU;P1=582;P3=369;P4=-413;P5=-616;P6=-9346;D=634343434343434343434343415151534341515151534341534341534151534343434343434341515343434153434341534343415153434153415;CP=3;R=60;w=1;
2018.03.03 11:33:48 4: SIG868/msg READredu: MU;P1=582;P3=369;P4=-413;P5=-616;P6=-9346;D=634343434343434343434343415151534341515151534341534341534151534343434343434341515343434153434341534343415153434153415;CP=3;R=60;
2018.03.03 11:33:50 4: SIG868/msg READredu: MU;P0=-422;P1=363;P2=571;P3=-625;P4=-9360;D=0101010101023232310102323232310102310102310232310101010101010231023101010231010102310101023231010232310;CP=1;R=58;w=0;
2018.03.03 11:33:50 4: SIG868/msg READredu: MU;P0=-418;P1=373;P2=570;P3=-619;P4=-9360;D=410101010101010101010101023232310102323232310102310102310232310101010101010231023101010231010102310101023231010232310;CP=1;R=58;w=1;
2018.03.03 11:33:50 4: SIG868/msg READredu: MU;P0=-418;P1=373;P2=570;P3=-619;P4=-9360;D=410101010101010101010101023232310102323232310102310102310232310101010101010231023101010231010102310101023231010232310;CP=1;R=58;
2018.03.03 11:33:51 4: SIG868/msg READredu: MU;P0=-32001;P1=379;P2=-416;P3=289;P4=561;P5=-634;P6=-9356;D=01232323232323212121212121245454512124545454512124512124512454512124512451212121212121212451212124512451212121212124512;CP=1;R=56;w=0;
2018.03.03 11:33:51 4: SIG868/msg READredu: MU;P1=362;P2=-423;P4=556;P5=-638;P6=-9356;D=612121212121212121212121245454512124545454512124512124512454512124512451212121212121212451212124512451212121212124512;CP=1;R=56;w=1;
2018.03.03 11:33:51 4: SIG868/msg READredu: MU;P1=362;P2=-423;P4=556;P5=-638;P6=-9356;D=612121212121212121212121245454512124545454512124512124512454512124512451212121212121212451212124512451212121212124512;CP=1;R=56;
2018.03.03 11:33:51 4: SIG868/keepalive ok, retry = 0
2018.03.03 11:33:52 4: SIG868/msg READredu: MU;P0=-32001;P1=376;P2=-411;P3=551;P4=-640;P5=-9356;D=012121212121212121212121234343412123434343412123412123412343412123412341212121212121212121212121212123434341212121234;CP=1;R=57;w=0;
2018.03.03 11:33:52 4: SIG868/msg READredu: MU;P1=371;P2=-421;P3=570;P4=-624;P5=-9356;D=512121212121212121212121234343412123434343412123412123412343412123412341212121212121212121212121212123434341212121234;CP=1;R=57;w=1;
2018.03.03 11:33:52 4: SIG868/msg READredu: MU;P1=371;P2=-421;P3=570;P4=-624;P5=-9356;D=512121212121212121212121234343412123434343412123412123412343412123412341212121212121212121212121212123434341212121234;CP=1;R=57;
2018.03.03 11:33:53 4: SIG868/msg READredu: MS;P1=579;P2=-9610;P4=370;P5=-611;P7=-425;D=74247474747474747474747474715151547471515151547471547471547151547474747474747154715474747474747474747474715474747154747;CP=4;SP=2;R=56;m=0;
2018.03.03 11:33:53 4: SIG868/msg READredu: MS;P1=581;P2=-9610;P4=382;P5=-610;P7=-412;D=42474747474747474747474747151515474715151515474715474715471515474747474747471547154747474747474747474747154747471547474;CP=4;SP=2;R=56;m=1;
2018.03.03 11:33:54 4: SIG868/msg READredu: MU;P0=-9350;P1=370;P2=-418;P3=225;P5=154;P6=567;P7=-628;D=123232323252521212121212126767671212676767671212671212671267671212121212121212676712121212121212121212126712121212671210;CP=1;R=60;w=0;
2018.03.03 11:33:54 4: SIG868/msg READredu: MU;P0=-9350;P1=366;P2=-430;P6=556;P7=-638;D=012121212121212121212121267676712126767676712126712126712676712121212121212126767121212121212121212121267121212126712;CP=1;R=60;w=1;
2018.03.03 11:33:54 4: SIG868/msg READredu: MU;P0=-9350;P1=366;P2=-430;P6=556;P7=-638;D=012121212121212121212121267676712126767676712126712126712676712121212121212126767121212121212121212121267121212126712;CP=1;R=60;
2018.03.03 11:33:55 4: SIG868/msg READredu: MS;P1=550;P2=-428;P3=336;P5=-9354;D=3532323232323232323232323212121232321212121232321232321232121232323232323232323232323232323232323232323212323232323212;CP=3;SP=5;R=58;m=0;
2018.03.03 11:33:55 4: SIG868/msg READredu: MS;P0=-639;P1=549;P2=-449;P3=348;P5=-9354;P6=240;P7=184;D=35326262626262723232323232101010323210101010323210323210321010323232323232323232323232323232323232323232103232323232103;CP=3;SP=5;R=58;m=1;
2018.03.03 11:34:10 5: SIG868: command for gets: C0DnF
2018.03.03 11:34:10 5: AddSendQueue: SIG868: C0DnF (1)
2018.03.03 11:34:10 5: SIG868 SW: C0DnF
2018.03.03 11:34:10 4: SIG868/msg READ: C0Dn11=21656A57C43023B900070018146C070090
2018.03.03 11:34:10 5: SIG868/noMsg Parse: C0Dn11=21656A57C43023B900070018146C070090
2018.03.03 11:34:10 5: SIG868/msg READ: regexp=C0Dn11.* cmd=ccconf msg=C0Dn11=21656A57C43023B900070018146C070090
2018.03.03 11:34:10 4: SIG868/HandleWriteQueue: nothing to send, stopping timer
2018.03.03 11:34:15 5: SIG868: command for gets: V
2018.03.03 11:34:15 5: AddSendQueue: SIG868: V (1)
2018.03.03 11:34:16 5: SIG868 SW: V
2018.03.03 11:34:16 4: SIG868/msg READ: V 3.3.2b-dev SIGNALduino cc1101 - compiled at Mar 3 2018 11:24:00
2018.03.03 11:34:16 5: SIG868/noMsg Parse: V 3.3.2b-dev SIGNALduino cc1101 - compiled at Mar 3 2018 11:24:00
2018.03.03 11:34:16 5: SIG868/msg READ: regexp=V\s.*SIGNAL(duino|ESP).* cmd=version msg=V 3.3.2b-dev SIGNALduino cc1101 - compiled at Mar 3 2018 11:24:00
2018.03.03 11:34:16 4: SIG868/HandleWriteQueue: nothing to send, stopping timer
2018.03.03 11:34:21 4: SIG868/msg READredu: MU;P0=-132;P1=204;P2=-1030;P3=491;P4=1477;D=0123232323242424232324242424242423242424232324242324242424242423242424242424232324242424242424242424242424242424242424242424232324232423242423232;CP=4;R=235;
2018.03.03 11:34:26 5: SIG868: command for gets: V
2018.03.03 11:34:26 5: AddSendQueue: SIG868: V (1)
2018.03.03 11:34:26 5: SIG868 SW: V
2018.03.03 11:34:26 4: SIG868/msg READ: V 3.3.2b-dev SIGNALduino cc1101 - compiled at Mar 3 2018 11:24:00
2018.03.03 11:34:26 5: SIG868/noMsg Parse: V 3.3.2b-dev SIGNALduino cc1101 - compiled at Mar 3 2018 11:24:00
2018.03.03 11:34:26 5: SIG868/msg READ: regexp=V\s.*SIGNAL(duino|ESP).* cmd=version msg=V 3.3.2b-dev SIGNALduino cc1101 - compiled at Mar 3 2018 11:24:00
pejonp
ZitatFS20 Commandos gedrückt, wird nichts erkannt nur diese Einträge im Log.
Zitat2018.03.03 11:33:33 3: SIG868: ID=74 skiped (developId=y)
Mit dem Attribut development=y müsste es funktionieren.
Die raw Nachrichten im Log sehen gut aus.
Damit es auch vom FS20 Modul verarbeitet wird fehlt noch eine Kleinigkeit:
https://forum.fhem.de/index.php/topic,84699.0.html
Gruß Ralf
Zitat von: KölnSolar am 03 März 2018, 11:30:53
Ich denke ich kann Deine Vermutung bestätigen. Eine Dose m. unit code 0000 funktioniert.
das vom RFXTRX empfangene off raw mit get Sduino raw senden klappt auch nicht bei unit code 0001.
Funktioniert es mit einem Repeat=6 (R=6)?
get sduino raw SR;R=6;P0=255;P1=-250;P2=-1280;P3=-9988;P4=-2558;D=040102010202010201010201020201010201020201010202010102020102010102010201020201020102010201020101020201010201020102010201020102020103;Beim RFXTRX fällt auf, daß dort "03 (255, -9988) am Ende gesendet wird.
Kannst Du bitte mal bei der aculfw schauen ob dort auch 255, -9988 am Ende gesendet wird?
Gruß Ralf
wenn ich es richtig abgelesen hab, wird in der aculfw so gesendet: repetition * ( 235 -10000 275 -2650 32/36(dim)bits)
Zitatwenn ich es richtig abgelesen hab, wird in der aculfw so gesendet: repetition * ( 235 -10000 275 -2650
Du kannst mal dieses testen:
get sduino raw SR;P0=255;P1=-250;P2=-1280;P3=-9988;P4=-2558;D=030401020102020102010102010202010102010202010102020101020201020101020102010202010201020102010201010202010102010201020102010201020201;Interessant wäre noch wie es der RFXTRX sendet? Die (255 -9988) am Anfang oder am Ende?
Gruß Ralf
@ralf
so sieht es im Log aus wenn FS20.pm angepaßt wurde.
FS20 werden erkannt und auch der Zustand in FHEM ändert sich.
Senden ?
2018.03.03 16:57:20 4: SIG868: Calling Getting Attr sub with args: set development = y
2018.03.03 16:57:20 3: SIG868 Attr: development
2018.03.03 16:57:20 3: SIG868 sduinoIdList: whitelistIds=74
2018.03.03 16:57:20 3: SIG868 sduinoIdList: blacklistIds=
2018.03.03 16:57:20 3: SIG868 sduinoIdList: development=y
2018.03.03 16:57:20 3: SIG868: IDlist MS
2018.03.03 16:57:20 3: SIG868: IDlist MU 74
2018.03.03 16:57:20 3: SIG868: IDlist MC
2018.03.03 16:57:27 4: SIG868/msg READredu: MU;P0=-4632;P1=372;P2=-418;P3=558;P4=-629;P5=-9340;D=01212121212121212121212121234343412123434343412123412123412343412121212121212121212121212341212123412121234341212123434;CP=1;R=74;w=0;
2018.03.03 16:57:27 4: SIG868: Fingerprint for MU Protocol id 74 -> FS20 matches, trying to demodulate
2018.03.03 16:57:27 5: SIG868: Starting demodulation at Position 1
2018.03.03 16:57:27 5: SIG868: applying postDemodulation
2018.03.03 16:57:27 4: SIG868: FS20 - remote control post demodulation CF4B000011 length 45
2018.03.03 16:57:27 5: SIG868: modified value after postDemodulation:40
2018.03.03 16:57:27 5: SIG868: dispatching bits: 1 1 0 0 1 1 1 1 0 1 0 0 1 0 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 1
2018.03.03 16:57:27 4: SIG868: decoded matched MU Protocol id 74 dmsg 810b04f70101a001CF4B000011 length 40 RSSI = -37
2018.03.03 16:57:27 5: SIG868 Dispatch: 810b04f70101a001CF4B000011, test ungleich: disabled
2018.03.03 16:57:27 5: SIG868 Dispatch: 810b04f70101a001CF4B000011, -37 dB, dispatch
2018.03.03 16:57:27 5: SIG868: dispatch 810b04f70101a001CF4B000011
2018.03.03 16:57:27 4: SIG868/msg READredu: MU;P1=367;P2=-424;P3=573;P4=-621;P5=-9340;D=512121212121212121212121234343412123434343412123412123412343412121212121212121212121212341212123412121234341212123434;CP=1;R=74;w=1;
2018.03.03 16:57:27 4: SIG868: Fingerprint for MU Protocol id 74 -> FS20 matches, trying to demodulate
2018.03.03 16:57:27 5: SIG868: Starting demodulation at Position 1
2018.03.03 16:57:27 5: SIG868: applying postDemodulation
2018.03.03 16:57:27 4: SIG868: FS20 - remote control post demodulation CF4B000011 length 45
2018.03.03 16:57:27 5: SIG868: modified value after postDemodulation:40
2018.03.03 16:57:27 5: SIG868: dispatching bits: 1 1 0 0 1 1 1 1 0 1 0 0 1 0 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 1
2018.03.03 16:57:27 4: SIG868: decoded matched MU Protocol id 74 dmsg 810b04f70101a001CF4B000011 length 40 RSSI = -37
2018.03.03 16:57:27 5: SIG868 Dispatch: 810b04f70101a001CF4B000011, test gleich
2018.03.03 16:57:27 4: SIG868 Dispatch: 810b04f70101a001CF4B000011, Dropped due to short time or equal msg
2018.03.03 16:57:27 4: SIG868/msg READredu: MU;P1=367;P2=-424;P3=573;P4=-621;P5=-9340;D=512121212121212121212121234343412123434343412123412123412343412121212121212121212121212341212123412121234341212123434;CP=1;R=74;
2018.03.03 16:57:27 4: SIG868: Fingerprint for MU Protocol id 74 -> FS20 matches, trying to demodulate
2018.03.03 16:57:27 5: SIG868: Starting demodulation at Position 1
2018.03.03 16:57:27 5: SIG868: applying postDemodulation
2018.03.03 16:57:27 4: SIG868: FS20 - remote control post demodulation CF4B000011 length 45
2018.03.03 16:57:27 5: SIG868: modified value after postDemodulation:40
2018.03.03 16:57:27 5: SIG868: dispatching bits: 1 1 0 0 1 1 1 1 0 1 0 0 1 0 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 1
2018.03.03 16:57:27 4: SIG868: decoded matched MU Protocol id 74 dmsg 810b04f70101a001CF4B000011 length 40 RSSI = -37
2018.03.03 16:57:27 5: SIG868 Dispatch: 810b04f70101a001CF4B000011, test gleich
2018.03.03 16:57:27 4: SIG868 Dispatch: 810b04f70101a001CF4B000011, Dropped due to short time or equal msg
2018.03.03 16:57:30 4: SIG868/msg READredu: MU;P0=-4552;P1=361;P2=-442;P3=560;P4=-626;P5=-9342;D=0121212121234343412123434343412123412123412343412121212121212121212121212121212121212121234121212121234;CP=1;R=71;w=0;
2018.03.03 16:57:30 4: SIG868: Fingerprint for MU Protocol id 74 -> FS20 matches, trying to demodulate
2018.03.03 16:57:30 5: SIG868: Starting demodulation at Position 1
2018.03.03 16:57:30 5: SIG868: applying postDemodulation
2018.03.03 16:57:30 4: SIG868: FS20 - remote control post demodulation CF4B000000 length 45
2018.03.03 16:57:30 5: SIG868: modified value after postDemodulation:40
2018.03.03 16:57:30 5: SIG868: dispatching bits: 1 1 0 0 1 1 1 1 0 1 0 0 1 0 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
2018.03.03 16:57:30 4: SIG868: decoded matched MU Protocol id 74 dmsg 810b04f70101a001CF4B000000 length 40 RSSI = -38.5
2018.03.03 16:57:30 5: SIG868 Dispatch: 810b04f70101a001CF4B000000, test ungleich: disabled
2018.03.03 16:57:30 5: SIG868 Dispatch: 810b04f70101a001CF4B000000, -38.5 dB, dispatch
2018.03.03 16:57:30 5: SIG868: dispatch 810b04f70101a001CF4B000000
2018.03.03 16:57:30 4: SIG868/msg READredu: MU;P1=357;P2=-433;P3=570;P4=-625;P5=-9342;D=512121212121212121212121234343412123434343412123412123412343412121212121212121212121212121212121212121234121212121234;CP=1;R=71;w=1;
2018.03.03 16:57:30 4: SIG868: Fingerprint for MU Protocol id 74 -> FS20 matches, trying to demodulate
2018.03.03 16:57:30 5: SIG868: Starting demodulation at Position 1
2018.03.03 16:57:30 5: SIG868: applying postDemodulation
2018.03.03 16:57:30 4: SIG868: FS20 - remote control post demodulation CF4B000000 length 45
2018.03.03 16:57:30 5: SIG868: modified value after postDemodulation:40
2018.03.03 16:57:30 5: SIG868: dispatching bits: 1 1 0 0 1 1 1 1 0 1 0 0 1 0 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
2018.03.03 16:57:30 4: SIG868: decoded matched MU Protocol id 74 dmsg 810b04f70101a001CF4B000000 length 40 RSSI = -38.5
2018.03.03 16:57:30 5: SIG868 Dispatch: 810b04f70101a001CF4B000000, test gleich
2018.03.03 16:57:30 4: SIG868 Dispatch: 810b04f70101a001CF4B000000, Dropped due to short time or equal msg
2018.03.03 16:57:30 4: SIG868/msg READredu: MU;P1=357;P2=-433;P3=570;P4=-625;P5=-9342;D=512121212121212121212121234343412123434343412123412123412343412121212121212121212121212121212121212121234121212121234;CP=1;R=71;
2018.03.03 16:57:30 4: SIG868: Fingerprint for MU Protocol id 74 -> FS20 matches, trying to demodulate
2018.03.03 16:57:30 5: SIG868: Starting demodulation at Position 1
2018.03.03 16:57:30 5: SIG868: applying postDemodulation
2018.03.03 16:57:30 4: SIG868: FS20 - remote control post demodulation CF4B000000 length 45
2018.03.03 16:57:30 5: SIG868: modified value after postDemodulation:40
2018.03.03 16:57:30 5: SIG868: dispatching bits: 1 1 0 0 1 1 1 1 0 1 0 0 1 0 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
2018.03.03 16:57:30 4: SIG868: decoded matched MU Protocol id 74 dmsg 810b04f70101a001CF4B000000 length 40 RSSI = -38.5
2018.03.03 16:57:30 5: SIG868 Dispatch: 810b04f70101a001CF4B000000, test gleich
2018.03.03 16:57:30 4: SIG868 Dispatch: 810b04f70101a001CF4B000000, Dropped due to short time or equal msg
2018.03.03 16:57:31 4: SIG868/msg READredu: MU;P0=-112;P1=644;P2=-1032;P3=1475;P4=489;D=0123232323232323232324232323232423232324232;CP=3;R=236;
2018.03.03 16:57:32 4: SIG868/msg READredu: MU;P0=-32001;P1=372;P2=-426;P3=569;P4=-620;P5=-9340;D=012121212121212121212121234343412123434343412123412123412343412121212121212123434121212121212121212121234121212123412;CP=1;R=72;w=0;
2018.03.03 16:57:32 4: SIG868: Fingerprint for MU Protocol id 74 -> FS20 matches, trying to demodulate
2018.03.03 16:57:32 5: SIG868: Starting demodulation at Position 1
2018.03.03 16:57:32 5: SIG868: applying postDemodulation
2018.03.03 16:57:32 4: SIG868: FS20 - remote control post demodulation CF4B010000 length 45
2018.03.03 16:57:32 5: SIG868: modified value after postDemodulation:40
2018.03.03 16:57:32 5: SIG868: dispatching bits: 1 1 0 0 1 1 1 1 0 1 0 0 1 0 1 1 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
2018.03.03 16:57:32 4: SIG868: decoded matched MU Protocol id 74 dmsg 810b04f70101a001CF4B010000 length 40 RSSI = -38
2018.03.03 16:57:32 5: SIG868 Dispatch: 810b04f70101a001CF4B010000, test ungleich: disabled
2018.03.03 16:57:32 5: SIG868 Dispatch: 810b04f70101a001CF4B010000, -38 dB, dispatch
2018.03.03 16:57:32 5: SIG868: dispatch 810b04f70101a001CF4B010000
2018.03.03 16:57:32 4: SIG868/msg READredu: MU;P1=364;P2=-423;P3=555;P4=-633;P5=-9340;D=512121212121212121212121234343412123434343412123412123412343412121212121212123434121212121212121212121234121212123412;CP=1;R=72;w=1;
2018.03.03 16:57:32 4: SIG868: Fingerprint for MU Protocol id 74 -> FS20 matches, trying to demodulate
2018.03.03 16:57:32 5: SIG868: Starting demodulation at Position 1
2018.03.03 16:57:32 5: SIG868: applying postDemodulation
2018.03.03 16:57:32 4: SIG868: FS20 - remote control post demodulation CF4B010000 length 45
2018.03.03 16:57:32 5: SIG868: modified value after postDemodulation:40
2018.03.03 16:57:32 5: SIG868: dispatching bits: 1 1 0 0 1 1 1 1 0 1 0 0 1 0 1 1 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
2018.03.03 16:57:32 4: SIG868: decoded matched MU Protocol id 74 dmsg 810b04f70101a001CF4B010000 length 40 RSSI = -38
2018.03.03 16:57:32 5: SIG868 Dispatch: 810b04f70101a001CF4B010000, test gleich
2018.03.03 16:57:32 4: SIG868 Dispatch: 810b04f70101a001CF4B010000, Dropped due to short time or equal msg
2018.03.03 16:57:32 4: SIG868/msg READredu: MU;P1=364;P2=-423;P3=555;P4=-633;P5=-9340;D=512121212121212121212121234343412123434343412123412123412343412121212121212123434121212121212121212121234121212123412;CP=1;R=72;
2018.03.03 16:57:32 4: SIG868: Fingerprint for MU Protocol id 74 -> FS20 matches, trying to demodulate
2018.03.03 16:57:32 5: SIG868: Starting demodulation at Position 1
2018.03.03 16:57:32 5: SIG868: applying postDemodulation
2018.03.03 16:57:32 4: SIG868: FS20 - remote control post demodulation CF4B010000 length 45
2018.03.03 16:57:32 5: SIG868: modified value after postDemodulation:40
2018.03.03 16:57:32 5: SIG868: dispatching bits: 1 1 0 0 1 1 1 1 0 1 0 0 1 0 1 1 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
2018.03.03 16:57:32 4: SIG868: decoded matched MU Protocol id 74 dmsg 810b04f70101a001CF4B010000 length 40 RSSI = -38
2018.03.03 16:57:32 5: SIG868 Dispatch: 810b04f70101a001CF4B010000, test gleich
2018.03.03 16:57:32 4: SIG868 Dispatch: 810b04f70101a001CF4B010000, Dropped due to short time or equal msg
2018.03.03 16:57:33 4: SIG868/msg READredu: MU;P0=-32001;P1=362;P2=-435;P3=554;P4=-633;P5=-9334;D=012121212121212121212121234343412123434343412123412123412343412121212121212341234121212121212121212121234121212341212;CP=1;R=71;w=0;
2018.03.03 16:57:33 4: SIG868: Fingerprint for MU Protocol id 74 -> FS20 matches, trying to demodulate
2018.03.03 16:57:33 5: SIG868: Starting demodulation at Position 1
2018.03.03 16:57:33 5: SIG868: applying postDemodulation
2018.03.03 16:57:33 4: SIG868: FS20 - remote control post demodulation CF4B020000 length 45
2018.03.03 16:57:33 5: SIG868: modified value after postDemodulation:40
2018.03.03 16:57:33 5: SIG868: dispatching bits: 1 1 0 0 1 1 1 1 0 1 0 0 1 0 1 1 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
2018.03.03 16:57:33 4: SIG868: decoded matched MU Protocol id 74 dmsg 810b04f70101a001CF4B020000 length 40 RSSI = -38.5
2018.03.03 16:57:33 5: SIG868 Dispatch: 810b04f70101a001CF4B020000, test ungleich: disabled
2018.03.03 16:57:33 5: SIG868 Dispatch: 810b04f70101a001CF4B020000, -38.5 dB, dispatch
2018.03.03 16:57:33 5: SIG868: dispatch 810b04f70101a001CF4B020000
2018.03.03 16:57:33 4: SIG868/msg READredu: MU;P1=351;P2=-442;P3=558;P4=-631;P5=-9334;D=512121212121212121212121234343412123434343412123412123412343412121212121212341234121212121212121212121234121212341212;CP=1;R=71;w=1;
2018.03.03 16:57:33 4: SIG868: Fingerprint for MU Protocol id 74 -> FS20 matches, trying to demodulate
2018.03.03 16:57:33 5: SIG868: Starting demodulation at Position 1
2018.03.03 16:57:33 5: SIG868: applying postDemodulation
2018.03.03 16:57:33 4: SIG868: FS20 - remote control post demodulation CF4B020000 length 45
2018.03.03 16:57:33 5: SIG868: modified value after postDemodulation:40
2018.03.03 16:57:33 5: SIG868: dispatching bits: 1 1 0 0 1 1 1 1 0 1 0 0 1 0 1 1 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
2018.03.03 16:57:33 4: SIG868: decoded matched MU Protocol id 74 dmsg 810b04f70101a001CF4B020000 length 40 RSSI = -38.5
2018.03.03 16:57:33 5: SIG868 Dispatch: 810b04f70101a001CF4B020000, test gleich
2018.03.03 16:57:33 4: SIG868 Dispatch: 810b04f70101a001CF4B020000, Dropped due to short time or equal msg
2018.03.03 16:57:33 4: SIG868/msg READredu: MU;P1=351;P2=-442;P3=558;P4=-631;P5=-9334;D=512121212121212121212121234343412123434343412123412123412343412121212121212341234121212121212121212121234121212341212;CP=1;R=71;
2018.03.03 16:57:33 4: SIG868: Fingerprint for MU Protocol id 74 -> FS20 matches, trying to demodulate
2018.03.03 16:57:33 5: SIG868: Starting demodulation at Position 1
2018.03.03 16:57:33 5: SIG868: applying postDemodulation
2018.03.03 16:57:33 4: SIG868: FS20 - remote control post demodulation CF4B020000 length 45
2018.03.03 16:57:33 5: SIG868: modified value after postDemodulation:40
2018.03.03 16:57:33 5: SIG868: dispatching bits: 1 1 0 0 1 1 1 1 0 1 0 0 1 0 1 1 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
2018.03.03 16:57:33 4: SIG868: decoded matched MU Protocol id 74 dmsg 810b04f70101a001CF4B020000 length 40 RSSI = -38.5
2018.03.03 16:57:33 5: SIG868 Dispatch: 810b04f70101a001CF4B020000, test gleich
2018.03.03 16:57:33 4: SIG868 Dispatch: 810b04f70101a001CF4B020000, Dropped due to short time or equal msg
2018.03.03 16:57:38 4: SIG868/keepalive ok, retry = 0
2018.03.03 16:57:44 4: SIG868: Calling Getting Attr sub with args: del whitelist_IDs =
2018.03.03 16:57:44 3: SIG868 Attr: whitelist_IDs
2018.03.03 16:57:44 3: SIG868 sduinoIdList: whitelistIds=
2018.03.03 16:57:44 3: SIG868 sduinoIdList: blacklistIds=
2018.03.03 16:57:44 3: SIG868 sduinoIdList: development=y
2018.03.03 16:57:44 3: SIG868: ID=p76 skiped (developId=p)
2018.03.03 16:57:44 3: SIG868: ID=p76.1 skiped (developId=p)
2018.03.03 16:57:44 3: SIG868: IDlist MS 0 1 13 14 15 17 2 22 23 25 3 3.1 32 33 35 38 4 41 51 55 6 68 7 72.1
2018.03.03 16:57:44 3: SIG868: IDlist MU 13.1 16 20 21 24 26 27 28 29 30 31 36 37 39 40 44 44.1 45 46 48 49 5 50 56 59 60 61 62 63 64 65 66 67 69 70 71 72 73 74 75 77 78 8 9
2018.03.03 16:57:44 3: SIG868: IDlist MC 10 11 12 12.1 18 43 47 52 57 58
Jörg
Sieht recht gut aus.
Dir ist sicher auch aufgefallen, daß die emfangenen Nachrichten, ab und zu als MS-Nachrichten erkannt werden.
Macht es Sinn den Aufwand zu treiben, daß diese MS-Nachrichten auch dekodiert und dem FS20 Modul übergeben werden,
oder können diese vernachlässigt werden, da ausreichend viele MU-Nachrichten empfangen werden?
Das Senden ist bei @HomeAuto_User und @elektron-bbs in Arbeit,
https://forum.fhem.de/index.php/topic,84699.msg771120.html#msg771120
Gruß Ralf
@ralf
Mir reicht es so, da FHEM meine FS20 Steckdosen richtig schaltet. Der Test war nur wegen deiner Anfrage.
Wenn das sendet geht kann sich ja einer melden, ob ich was testen kann/soll.
Jörg
der raw-Befehl hat nicht funktioniert. Den hat auch der RFXTRX nicht erkannt :(
Beim RFXTRX kann ich leider nicht gucken, da die firmware nicht offen, also eine black box ist. Ich kann halt lediglich dessen Aussendung mit S'duino oder CUL aufzeichnen.
Ich verstehe worüber Du nachdenkst. Ich stolpere auch immer wieder drüber, ob Header oder Footer. pilight (https://manual.pilight.org/protocols/433.92/dimmer/intertechno.html) dokumentiert den 3./4. Puls als Header. Den 1./2. als Trennung/Footer zwischen den Wiederholungen. Logisch betrachtet scheint mir das richtiger.
Hi,
ich habe eben recht schnell versucht das Maverick 732 Grillthermometer zu vertesten. Bin mir daher nicht ganz sicher, ob ich alles korrekt durchgeführt habe.
Die Erkennung und Anlage eines SD_WS_Maverick geschah sofort nach Einschalten des Grillthermometers.
Temp1 am Thermometer zeigt 23°C, Temp2 sind 22°C. Im SD_WS_Maverick werden Temp1=-363 und Temp2=-106 angezeigt.
Im Anhang das Log mit verbose=5 am sduino.
Ich hoffe es hilft. Wenn ich etwas noch nicht richtig installiert habe bitte um Entschuldigung. Muss mir dann mehr Zeit nehmen.
VG,
Dirk
Zitatich habe eben recht schnell versucht das Maverick 732 Grillthermometer zu vertesten. Bin mir daher nicht ganz sicher, ob ich alles korrekt durchgeführt habe.
Danke fürs Testen, ich schaue es mir mal an.
Gruß Ralf
Zitatder raw-Befehl hat nicht funktioniert.
Ohne Wiederholungen scheint es gar nicht zu funktionieren.
Evtl funktioniert damit das ausschalten:
SR;R=6;P0=250;P1=-2500;P2=-1250;P3=-250;P4=-10000;D=010302030202030203030203020203030203020203030202030302020302030302030203020203020302030203020303020203030203020302030203020302020304;Gruß Ralf
der funktioniert ;D Dose u. Empfang m. RFXTRX.
Zitat von: Wuehler am 03 März 2018, 21:35:25
ich habe eben recht schnell versucht das Maverick 732 Grillthermometer zu vertesten. Bin mir daher nicht ganz sicher, ob ich alles korrekt durchgeführt habe.
Die Erkennung und Anlage eines SD_WS_Maverick geschah sofort nach Einschalten des Grillthermometers.
Temp1 am Thermometer zeigt 23°C, Temp2 sind 22°C. Im SD_WS_Maverick werden Temp1=-363 und Temp2=-106 angezeigt.
Ich habe den Fehler gefunden. Hier ist eine neue Version des 14_SD_WS_Maverick.pm Moduls:
https://raw.githubusercontent.com/Ralf9/RFFHEM/master/FHEM/14_SD_WS_Maverick.pm
Gruß Ralf
Zitat von: KölnSolar am 04 März 2018, 08:06:39
der funktioniert ;D Dose u. Empfang m. RFXTRX.
Dann ist der Bug, wie ich schon vermutet habe nicht in der Firmware sondern in der 00_SIGNALduino.pm.
Nun muss ich nur noch in der 00_SIGNALduino.pm eine kleinigkeit anpassen.
Gruß Ralf
Gerade heimgekommen und Nachricht zum Post bekommen. Test durchgeführt: SIEHT GUT AUS :)
Heute Abend gibts Pizza vom Grill, da teste ich dann etwas länger.
DANKE
Veeschwindet dann auch die "Fehlerkennung" ? Dann würd ich mit ner neuen Version einen Neustart(keine devices, nur neu per autocreate) machen.
Grüße Markus
Veeschwindet dann auch die "Fehlerkennung" ?
Nein, dies bezieht sich nur aufs senden.
Hier ist der patch und die neue 00_SIGNALduino.pm für das Senden von itv3:
https://github.com/Ralf9/RFFHEM/commit/b8b3168962eaea9d1122e0ad3b223dffcecf37ea
https://raw.githubusercontent.com/Ralf9/RFFHEM/master/FHEM/00_SIGNALduino.pm
nun sieht das senden so aus:
alt:
IT_set: IT_V3_192b1f41 off
sendmsg msg=P17#00110010010101100011111010000001#R6
sendmsg Preparing rawsend command for protocol=17, repeats=6, clock=250 bits=00110010010101100011111010000001
SR;R=6;P0=250;P1=-2500;P2=-1250;P3=-250;D=0103020302020302030302030202030302030202030302020303020203020303020302030202030203020302030203030202030302030203020302030203020203;
neu:
IT_set: IT_V3_192b1f41 off
sendmsg msg=P17#00110010010101100011111010000001#R6
sendmsg Preparing rawsend command for protocol=17, repeats=6, clock=250 bits=00110010010101100011111010000001
SR;R=6;P0=250;P1=-2500;P2=-1250;P3=-250;P4=-10000;D=010302030202030203030203020203030203020203030202030302020302030302030203020203020302030203020303020203030203020302030203020302020304;
Gruß Ralf
Sorry, ich bin erst jetzt zum Testen meines Maverick-Grillthermometers gekommen:
2018.03.04 19:51:41 4 : sduino/msg READ: MC;LL=-470;LH=528;SL=-221;SH=276;D=AA999559959A695996A65A9566;C=249;L=104;s13;b13;O;w;
2018.03.04 19:51:41 4 : sduino: Found manchester Protocol id 47 clock 249 -> Maverick protocol
2018.03.04 19:51:41 4 : sduino/msg READ: MC;LL=-482;LH=511;SL=-230;SH=264;D=AA999559959A695996A65A9566;C=247;L=104;s17;b17;O;w;
2018.03.04 19:51:41 4 : sduino: Found manchester Protocol id 47 clock 247 -> Maverick protocol
2018.03.04 19:51:41 4 : sduino/msg READ: MC;LL=-487;LH=507;SL=-229;SH=261;D=AA999559959A695996A65A9566;C=247;L=104;s17;b17;O;w;
2018.03.04 19:51:41 4 : sduino: Found manchester Protocol id 47 clock 247 -> Maverick protocol
2018.03.04 19:51:42 4 : sduino/msg READ: MC;LL=-488;LH=502;SL=-241;SH=256;D=AA999559959A695996A65A9566;C=247;L=104;s17;b17;
2018.03.04 19:51:42 4 : sduino: Found manchester Protocol id 47 clock 247 -> Maverick protocol
2018.03.04 19:51:50 4 : sduino/msg READredu: MU;P0=-21980;P1=866;P2=-1037;P3=-623;P4=356;D=01212134342434313421243434343134243431243121213434243434343121243434343434343431243121342431243124313424343;CP=4;
2018.03.04 19:51:50 4 : sduino/msg READ: MC;LL=-1072;LH=869;SL=-580;SH=427;D=A8E5F3B52F5FF69D5B;C=491;L=72;s3;b3;
2018.03.04 19:51:55 4 : sduino/keepalive ok, retry = 0
2018.03.04 19:51:55 4 : sduino/msg READredu: MU;P0=-2224;P1=280;P2=-6352;P3=473;P4=-1070;P5=1440;P6=-25752;D=012343434343434343454343434545434543454543454545454543454345434543454545454545454545454545454545454343434345454545454343454543434;CP=3;w=0;
Das sehe mit Verbose=4, aber es wird kein Device automatisch angelegt?
Vielen Dank für deine Mühe und Arbeit.
Gruß
Thomas
Hast Du einen anderen Maverick als @Wuehler. Die Datenqualität bei Dir ist viel besser als bei @Wuehler.
Wenn ich es mit Deinen Nachrichten simuliere, sieht es sehr gut aus.
Hast Du die neue Version des 14_SD_WS_Maverick.pm Moduls eingespielt?
2018.03.04 20:17:49.061 4 : sduinoD/msg get raw: MC;LL=-487;LH=507;SL=-229;SH=261;D=AA999559959A695996A65A9566;C=247;L=104;
2018.03.04 20:17:49.061 4 : sduinoD: Found manchester Protocol id 47 clock 247 -> Maverick protocol
2018.03.04 20:17:49.061 5 : sduinoD: extracted data 10101010100110011001010101011001100101011001101001101001010110011001011010100110010110101001010101100110 (bin)
2018.03.04 20:17:49.061 4 : sduinoD: Maverick protocol detected: header_pos = 24
2018.03.04 20:17:49.062 5 : sduinoD: dispatch P47#59959A695996A65A9566
2018.03.04 20:17:49.062 4 : SD_WS_Maverick_Parse SD_WS_Maverick (P47#59959A695996A65A9566) length: 20
2018.03.04 20:17:49.062 4 : SD_WS_Maverick decoded protocolid: 47 sensor startup=59, temp1=959A6, temp2=95996, unknown=A65A9566
2018.03.04 20:17:49.062 4 : SD_WS_Maverick decoded protocolid: temp1=25, temp2=21;
2018.03.04 20:17:49.062 1 : SD_WS_Maverick: UNDEFINED sensor SD_WS_Maverick
2018.03.04 20:17:49.063 2 : autocreate: define SD_WS_Maverick SD_WS_Maverick SD_WS_Maverick
Gruß Ralf
ZitatHast Du einen anderen Maverick als @Wuehler
Ich habe den Maverick ET733, welchen hat Wuehler?
ZitatHast Du die neue Version des 14_SD_WS_Maverick.pm Moduls eingespielt?
Ja, habe ich und deine Firmware:
V 3.3.2b-dev SIGNALduino - compiled at Feb 25 2018 17:57:16Ist es denn richtig, dass kein Device automatisch erstellt wird?
Gruß
Thomas
ZitatIst es denn richtig, dass kein Device automatisch erstellt wird?
Er sollte normalerweise automatisch angelegt werden.
Gruß Ralf
Habe das Maverick 732. An meinem sduino sind aber auch nur selbstgebastelte Antennen aus nem Stück Kupferdraht. Wobei das Maverick direkt daneben lag.
Edit: und zwei Nachbarn müssen im letzten Jahr eine Wetterstation in den Garten gestellt haben. Habe jetzt auch die Außentemperatur in meinem fhem. Vielleicht sind das die schlechten signale.
ZitatWobei das Maverick direkt daneben lag.
Der Empfänger kann auch übersteuern, wenn die Entfernung zu kurz ist.
Gruß Ralf
Hallo,
mit der neuen Firmware und der aktualisierten 14_SD_WS_Maverick.pm, wurde jetzt auch bei mir das ET-732 automatisch angelegt. Vorher hatte das nicht geklappt, es könnte aber auch an etwas anderem gelegen haben: Wenn syncedMS und unsyncedMU an sind, werden die Nachrichten nicht erkannt (es steht aber etwas im Log, was ich als Versuch der Deutung der Nachrichten interpretiere). Wenn nur manchesterMC an ist, scheint es bei mir zu laufen.
Ansonsten noch vielen Dank die Arbeit.
Viele Grüße,
Florian
get sduino config bei mir:
config: MS=1;MU=1;MC=1;Mred=1;Mdebug=1_MScnt=4;MuSplitThresh=8000;MdebFifoLimit=80
Was soll ich ändern?
Versuch mal diese 00_SIGNALduino.pm, dann ein fhem restart
https://raw.githubusercontent.com/Ralf9/RFFHEM/master/FHEM/00_SIGNALduino.pm
Gruß Ralf
Nein, leider keine Änderung.
Wie sieht das log mit sduino verbose 5 aus?
Alles gut! Ich habe noch ein altes Maverick-Device gefunden, gelöscht und danach wurde ein Neues auch angelegt:
Internals:
CFGFN
CHANGED
CODE SD_WS_Maverick
DEF SD_WS_Maverick
LASTInputDev sduino
MSGCNT 77
NAME SD_WS_Maverick
NR 603
STATE T1: 22 T2: 20 S: 59
TYPE SD_WS_Maverick
lastMSG 5995999959959599A659
lastReceive 1520272116.50695
sduino_DMSG P47#5995999959959599A659
sduino_MSGCNT 77
sduino_RAWMSG MC;LL=-476;LH=518;SL=-226;SH=266;D=AA99955995999959959599A659;C=247;L=104;s18;b18;O;w;
sduino_TIME 2018-03-05 18:48:36
Helper:
DBLOG:
T1:
myDbLog:
TIME 1520271960.52663
VALUE 22 T2: 20 S: 59
messageType:
myDbLog:
TIME 1520271960.52663
VALUE 59
temp1:
myDbLog:
TIME 1520271960.52663
VALUE 22
temp2:
myDbLog:
TIME 1520271960.52663
VALUE 20
READINGS:
2018-03-05 18:48:36 messageType 59
2018-03-05 18:48:36 state T1: 22 T2: 20 S: 59
2018-03-05 18:48:36 temp1 22
2018-03-05 18:48:36 temp2 20
Attributes:
alias ET733
event-min-interval .*:300
event-on-change-reading .*
room BBQ,SD_WS_Maveric
Das sieht jetzt sehr gut aus! Die Grillsaisson kann kommen.
Kannst du den Entwicklungsstand irgendwie festschreiben?
Danke & Gruß
Thomas
Das SD_WS_Maverick Modul ist momentan nur recht einfach programmiert.
Die checksum wird nicht überprüft und es findet keine Plausibilitätsprüfung statt.
Eine einfache Plausibilitätsprüfung wäre z.B. ob die Temperaturen plausiblel sind.
In welchem Bereich sind beim Maverick die Temperaturen plausilbel?
Reicht euch das recht einfache Maverick Modul so?
Wenn jemand von Euch in Perl programmieren kann und bereit wäre bei der Modulverbesserung mitzuhelfen, würde ich Euch dabei unterstützen.
Gruß Ralf
Aus dem Produktdatenblatt vom ET733:
ZitatDer Messbereich des Barbecue- und Grill-Thermometers liegt zwischen 0 ºC (32 ºF) und 300 ºC (572 ºF)
Bin leider selber kein Programmierer. :-[
Hallo Ralph,
Momentan reicht mir der Stand. Danke. Aber der Appetit kommt ja beim essen ;)
Da ich mit perl mittlerweile warm geworden bin und Mitmaintainer beim Unifi-Modul bin welches evtl. irgendwann in ein zweistufiges Modul umgebaut werden muss kann ich Mitarbeit anbieten (um daran auch zu lernen).
Ist das Modul nur für das Grillthermometer?
Was hältst du von einem eigenen Thread zum Modul? Wenn ich es (unterwegs mit dem Handy) richtig sehe gibt es noch keinen eigenen Thread dazu.
VG,
Dirk
https://forum.fhem.de/index.php/topic,18606.msg425454.html#msg425454
https://forum.fhem.de/index.php/topic,22977.0.html
das hier dürfte am Besten passen:
https://forum.fhem.de/index.php/topic,49548.0.html
Ich werde dann die wichtigsten Infos von hier dort nochmals posten.
Ich werde dort dann auch eine kleine Todo Liste aufschreiben, dann kann wer Lust und Zeit hat dies einbauen.
Gruß Ralf
Danke für das Testen.
An den Nachrichten vom UV- und Helligkeitssensor der WH3080 und an den FS20 Nachrichten lässt sich erkennen, daß die Trennung der MU-Nachrichten recht gut funktioniert.
Jetzt fehlt nur noch ein Test von Siro mit mit aktiviertem MC-Dedoder.
Ich habe in dieser Übersicht noch die allgemeinen Befehle ergänzt:
https://forum.fhem.de/index.php/topic,58396.msg497921.html#msg497921
Gruß Ralf
Eine Frage zur 3.3.2. Ich habe bei 3.3.1 ein raw-signal gesendet, um mein Gartentor zu öffnen:
set sduino raw SR;;R=7;;P0=335;;P1=-665;;P2=-335;;P3=665;;P4=-15018;;D=01010232310101023101010234;;
Das bewegt sich mit 3.3.2 aber nicht mehr. Gab es da eine Änderung der Befehle?
Fehler von mir. Alles ok.
Bei mir hat sich heute morgen (zumindest ohne mein bewusstes Zutun) die Frequenz von 433.92 verstellt, siehe Screenshot vom iPhone. Hat das schon mal jemand gehabt?
Das hatten wir doch schon oft, zumindest, wenn meine Annahme richtig ist, dass es sich um einen SelbstbauCUL handelt, also Arduino mit CC1101. Ursachen waren dann kalte Lötstellen, fehlende Verbindungen, Spannungsprobleme.....
Zitat von: KölnSolar am 02 Mai 2018, 11:03:36
wenn meine Annahme richtig ist, dass es sich um einen SelbstbauCUL handelt, also Arduino mit CC1101. Ursachen waren dann kalte Lötstellen, fehlende Verbindungen, Spannungsprobleme.....
Ist ein Selbstbau, korrekt. Allerdings lief der ein Jahr fehlerfrei und erst seit der neuen dev hatte ich das Problem. Wenn es nochmal auftritt, schaue ich mal in diese Richtung.
Ich habe erneut eine Frequenzänderung beobachtet. Bevor ich die Lötstellen prüfe (ich muss dazu das Ding ausbauen), würde ich gern schauen, ob es ein Muster bei der Umwandlung gibt; bei 3.3.1 hatte ich diese Probleme nämlich nicht. Dazu würde ich gern die Frequenz selbst beobachten und einen Logeintrag generieren, wenn die Frequenz wechselt.
Gibt es einen einfachen Weg, die Frequenz abzufragen? Ich hole sie sonst mit
get sduino freq
allerdings weiß ich nicht, wie ich daraus einen Perlcode machen kann. Geht denn so etwas wie
$freq=fhem("get sduino freq")
Ist die Frequenzänderung nur ein Anzeigeproblem oder funktioniert dann der Empfang nicht mehr?
Die Frequenz kannst Du mit "get sduino ccconf" abfragen.
Wenn Du
attr sduino noMsgVerbose 3
setzt, dann steht auch bei verbose 3 im log folgendes:
2018.05.06 19:51:00.705 3 : sduino/noMsg Parse: C0Dn11=10B07117C43023B900070018146C070090
10B071 ist 433.920MHz
Du kannst mit
get sduino raw C0Dn1
auch die Frequenz Register direkt auslesen.
2018.05.06 19:10:44.184 3 : sduino/noMsg Parse: C0Dn03=10B071
Wenn sich die Frequenz geändert hat, dann ist auch der Inhalt vom EEPROM und die uptime interessant:
get sduino raw r0Fn
2018.05.06 19:11:49.662 3 : sduino/noMsg Parse: EEPROM 0F : 10 B0 71 17 C4 30 23 B9 00 07 00 18 14 6C 07 00
Gruß Ralf
Danke, damit komme ich (hoffentlich) weiter. Ich kann dann nicht mehr senden, weil ich mehrere 433MHz-Geräte habe. (Bzw ich müsste es so umprogrammieren, dass vor jedem Senden oder gar regelmäßig die Frequenz geändert wird.) Ich beobachte mal und melde mich dann wieder.
So, jetzt habe ich zum ersten Mal eine Situation, in der die Frequenz geändert wird. Ich habe folgender Logeinträge
2018.05.07 15:03:12 3: sduino/noMsg Parse: SR;R=7;P0=335;P1=-665;P2=-335;P3=665;P4=-15018;D=01010102310101023101023104;
2018.05.07 15:03:12 3: sduino/noMsg Parse: C0Dn11=10B071550A3023B900070018146C070090
... keine weiteren sduino-Eintrage ...
2018.05.07 16:47:36 3: sduino/noMsg Parse: C0Dn11=FFB071550A3023B900070018146C070090
2018.05.07 16:50:00 3: sduino: Setting FREQ2..0 (0D,0E,0F) to 10 b0 71 = 433.920 MHz
2018.05.07 16:50:00 3: sduino/noMsg Parse: W0F10
2018.05.07 16:50:01 3: sduino/noMsg Parse: W10B0
2018.05.07 16:50:01 3: sduino/noMsg Parse: W1171
2018.05.07 16:50:01 3: sduino/noMsg Parse: cmdStrobeReg 36 chipStatus 1 delay1 0
2018.05.07 16:50:02 3: sduino/noMsg Parse: cmdStrobeReg 34 chipStatus 0 delay1 1
und dazwischen ist es ja passiert. Ich würde mir gern mehr Einträge anzeigen lassen, kriege das aber nicht richtig hin: https://forum.fhem.de/index.php?topic=87579.msg800235#msg800235
Ist es möglich, dass ich das Problem selbst auslöse? Ich habe folgende Einträge im Logfile, die mE einen Wechsel der Frequenz anzeigen:
2018.05.07 21:07:01 3: sduino/noMsg Parse: C0Dn11=10B071550A3023B900070018146C070090
2018.05.07 21:07:25 3: motion_switch_off return value:
2018.05.07 21:07:50 3: sduino/noMsg Parse: SR;R=7;P0=335;P1=-665;P2=-335;P3=665;P4=-15018;D=01010102310101023101023104;
2018.05.07 21:07:50 3: sduino/noMsg Parse: C0Dn11=10B071550A3023B900070018146C070090
2018.05.07 21:08:59 3: sduino IT_set: Garagentor on
2018.05.07 21:08:59 3: sduino/noMsg Parse: SR;R=3;P0=1100;P1=-743;P2=425;P3=-1401;P4=630;P5=-7010;D=012301010123230123230123232323232323230123230123232301232323232345;
2018.05.07 21:08:59 3: sduino/noMsg Parse: C0Dn11=FFB071550A3023B900070018146C070090
2018.05.07 21:09:00 3: sduino/noMsg Parse: SR;R=6;P0=290;P1=-8990;P2=870;P3=-290;P4=-870;D=01040404230423040404040423042304040423042304040423;
2018.05.07 21:09:10 3: sduino IT_set: Garagentor off
2018.05.07 21:09:11 3: sduino/noMsg Parse: SR;R=3;P0=1100;P1=-743;P2=425;P3=-1401;P4=630;P5=-7010;D=012301010123230123230123232323232323230123230123232301232323232345;
2018.05.07 21:09:11 3: sduino/noMsg Parse: C0Dn11=10B071550A3023B900070018146C070090
2018.05.07 21:09:11 3: sduino/noMsg Parse: SR;R=6;P0=290;P1=-8990;P2=870;P3=-290;P4=-870;D=01040404230423040404040423042304040423042304230404;
2018.05.07 21:09:25 3: sduino IT_set: Garagentor on
2018.05.07 21:09:25 3: sduino/noMsg Parse: SR;R=3;P0=1100;P1=-743;P2=425;P3=-1401;P4=630;P5=-7010;D=012301010123230123230123232323232323230123230123232301232323232345;
2018.05.07 21:09:25 3: sduino/noMsg Parse: C0Dn11=10B071550A3023B900070018146C070090
2018.05.07 21:09:26 3: sduino/noMsg Parse: SR;R=6;P0=290;P1=-8990;P2=870;P3=-290;P4=-870;D=01040404230423040404040423042304040423042304040423;
2018.05.07 21:10:00 3: sduino IT_set: Garagentor on
2018.05.07 21:10:01 3: sduino/noMsg Parse: SR;R=3;P0=1100;P1=-743;P2=425;P3=-1401;P4=630;P5=-7010;D=012301010123230123230123232323232323230123230123232301232323232345;
2018.05.07 21:10:01 3: sduino/noMsg Parse: C0Dn11=FFB071550A3023B900070018146C070090
2018.05.07 21:10:01 3: sduino/noMsg Parse: SR;R=6;P0=290;P1=-8990;P2=870;P3=-290;P4=-870;D=01040404230423040404040423042304040423042304040423;
2018.05.07 21:10:07 3: sduino IT_set: Garagentor on
2018.05.07 21:10:07 3: sduino/noMsg Parse: SR;R=3;P0=1100;P1=-743;P2=425;P3=-1401;P4=630;P5=-7010;D=012301010123230123230123232323232323230123230123232301232323232345;
2018.05.07 21:10:07 3: sduino/noMsg Parse: C0Dn11=FFB071550A3023B900070018146C070090
2018.05.07 21:10:08 3: sduino/noMsg Parse: SR;R=6;P0=290;P1=-8990;P2=870;P3=-290;P4=-870;D=01040404230423040404040423042304040423042304040423;
2018.05.07 21:10:24 3: sduino IT_set: Garagentor on
2018.05.07 21:10:25 3: sduino/noMsg Parse: SR;R=3;P0=1100;P1=-743;P2=425;P3=-1401;P4=630;P5=-7010;D=012301010123230123230123232323232323230123230123232301232323232345;
2018.05.07 21:10:25 3: sduino/noMsg Parse: C0Dn11=FFB071550A3023B900070018146C070090
2018.05.07 21:10:25 3: sduino/noMsg Parse: SR;R=6;P0=290;P1=-8990;P2=870;P3=-290;P4=-870;D=01040404230423040404040423042304040423042304040423;
2018.05.07 21:10:37 3: sduino IT_set: Garagentor on
2018.05.07 21:10:38 3: sduino/noMsg Parse: SR;R=3;P0=1100;P1=-743;P2=425;P3=-1401;P4=630;P5=-7010;D=012301010123230123230123232323232323230123230123232301232323232345;
2018.05.07 21:10:38 3: sduino/noMsg Parse: C0Dn11=10B071550A3023B900070018146C070090
2018.05.07 21:10:38 3: sduino/noMsg Parse: SR;R=6;P0=290;P1=-8990;P2=870;P3=-290;P4=-870;D=01040404230423040404040423042304040423042304040423;
2018.05.07 21:11:00 3: sduino/noMsg Parse: C0Dn11=10B071550A3023B900070018146C070090
2018.05.07 21:11:22 3: sduino IT_set: Garagentor off
2018.05.07 21:11:22 3: sduino/noMsg Parse: SR;R=3;P0=1100;P1=-743;P2=425;P3=-1401;P4=630;P5=-7010;D=012301010123230123230123232323232323230123230123232301232323232345;
2018.05.07 21:11:22 3: sduino/noMsg Parse: C0Dn11=10B071550A3023B900070018146C070090
2018.05.07 21:11:22 3: sduino/noMsg Parse: SR;R=6;P0=290;P1=-8990;P2=870;P3=-290;P4=-870;D=01040404230423040404040423042304040423042304230404;
2018.05.07 21:11:28 3: sduino IT_set: Garagentor on
2018.05.07 21:11:29 3: sduino/noMsg Parse: SR;R=3;P0=1100;P1=-743;P2=425;P3=-1401;P4=630;P5=-7010;D=012301010123230123230123232323232323230123230123232301232323232345;
2018.05.07 21:11:29 3: sduino/noMsg Parse: C0Dn11=FFB071550A3023B900070018146C070090
2018.05.07 21:11:29 3: sduino/noMsg Parse: SR;R=6;P0=290;P1=-8990;P2=870;P3=-290;P4=-870;D=01040404230423040404040423042304040423042304040423;
2018.05.07 21:11:48 3: sduino IT_set: Garagentor on
2018.05.07 21:11:49 3: sduino/noMsg Parse: SR;R=3;P0=1100;P1=-743;P2=425;P3=-1401;P4=630;P5=-7010;D=012301010123230123230123232323232323230123230123232301232323232345;
2018.05.07 21:11:49 3: sduino/noMsg Parse: C0Dn11=10B071550A3023B900070018146C070090
2018.05.07 21:11:49 3: sduino/noMsg Parse: SR;R=6;P0=290;P1=-8990;P2=870;P3=-290;P4=-870;D=01040404230423040404040423042304040423042304040423;
2018.05.07 21:11:53 3: sduino IT_set: Garagentor off
2018.05.07 21:11:54 3: sduino/noMsg Parse: SR;R=3;P0=1100;P1=-743;P2=425;P3=-1401;P4=630;P5=-7010;D=012301010123230123230123232323232323230123230123232301232323232345;
2018.05.07 21:11:54 3: sduino/noMsg Parse: C0Dn11=10B071550A3023B900070018146C070090
2018.05.07 21:11:54 3: sduino/noMsg Parse: SR;R=6;P0=290;P1=-8990;P2=870;P3=-290;P4=-870;D=01040404230423040404040423042304040423042304230404;
Besagtes Garagentor ist wie folgt definiert, das sind jetzt mehrere Schritte, leider:
Internals:
00 f0
DEF 0FF00FF0FF 0F F0
IODev sduino
NAME Garagentor
NR 102
STATE  
TYPE IT
XMIT 0ff00ff0ff
XMITdimdown 00
XMITdimup 00
XMITon 0f
CODE:
1 0ff00ff0ff
READINGS:
2017-10-31 20:30:17 protocol V1
2018-05-07 21:11:53 state off
Attributes:
IODev sduino
ITclock 290
devStateIcon .*:noIcon:noFhemwebLink
eventMap off:Zu on:Auf
group Tore
room Schalter
und zugleich
defmod Garagentor_Lampe notify Garagentor:.* set LampeGarage on-for-timer 180
wobei
defmod LampeGarage dummy
attr LampeGarage setList on off
attr LampeGarage useSetExtensions 1
attr LampeGarage webCmd on:off
und
defmod Lampe_Garage_Ein notify LampeGarage:on {fhem("set sduino raw SR;;;;R=3;;;;P0=1100;;;;P1=-743;;;;P2=425;;;;P3=-1401;;;;P4=630;;;;P5=-7010;;;;D=012301010123230123230123232323232323230123230123232301232323232345;;;;")}
und analog ein Befehl fuer Lampe aus.
Evtl kommt es ab und zu vor, daß das Register am Anfang falsch ausgelesen wird.
Anstatt 10 wird FF ausgelesen.
C0Dn11=10B071550A3023B900070018146C070090
C0Dn11=FFB071550A3023B900070018146C070090
Wenn die Frequenz falsch angezeigt wird und Du dann noch ein paarmal ein "get sduino ccconf" machst, ist dann auch die richtige Frequenz dabei?
Gruß Ralf
Habe es gerade mal getestet. Es war die falsche Frequenz drin und nach zweimaligem lesen der ccconf (get sduino ccconf) erschien wieder 433.92.
Das verstehe ich aber nicht. Wieso ändert sich die eingestellte Frequenz, wenn ich sie lese? Ist das ein Hardware-Problem?
Gesendet von iPhone mit Tapatalk Pro
so wies aussieht, ändert sich die eingestellte Frequenz nicht, sie wird nur ab und zu fehlerhaft ausgelesen.
Was für ein CC1101 Modul verwendest Du?
Gruß Ralf
Ich nutze das hier
Du kannst mal testen ob die fehlerhaft ausgelesene Frequenz auch bei der 3.3.1 dev und 3.3.1 RC5/RC6 auftritt.
Gruß Ralf
Test läuft, gerade mit
V 3.3.1-dev SIGNALduino cc1101 - compiled at Mar 10 2017 22:54:50
geflasht. Hätte ich auch selber draufkommen können...
So, ich habe jetzt getestet. Innerhalb von 24 Stunden (7.5 14:00 bis 8.5 14:00) gab es ca 400 Aufrufe durch den Signalduino (entspricht ca 16 pro Stunde). Die veränderte Frequenz habe ich aber nur am 7.5 zwischen 15:01 und 23:20 beobachtet, und das genau 13 Mal (ca 1,6 mal pro Stunde, Eintrag C0Dn11=FFB07 im Logfile). Nachdem ich am 8.5 mittags den sduino neu geflasht habe, ist bis jetzt kein einziges Mal eine falsche Frequenz erkannt worden.
Die falsche Frequenz müsste bis jetzt (19:00) etwa 10 mal aufgetreten sein. Die Wahrscheinlichkeit, dass das nicht passiert (also wie beobachtet) ist mit 0,006% so gering, dass ich eigentlich einen Hardwarefehler ausschließen kann. Das muss mE ein Softwareproblem der Version 3.3.2-dev sein.
Ich konnte den Fehler bei mir nachstellen. Es ist ein sehr spezieller Fehler der nur unter bestimmten Umständen auftritt.
Ich verwende einen pro mini.
Wenn ich den pro mini mit einem CP2102 an USB anschließe, triit der Fehler nicht auf.
Wenn ich den pro mini an einen Wemos D1 mini anschließe, wird ab und zu eine falsche Frequenz ausgelesen.
Ich habe einen Verdacht was die Ursache sein könnte.
Demnach müsste der Fehler auch bei den 3.3.1 RC Versionen von Sidey auftreten.
Gruß Ralf
Wie kann ich helfen?
Ich habe
V 3.3.1-rc3 SIGNALESP cc1101 - compiled at Jan 24 2018 21:48:34
bin ich aktuell?
LG
/robin
Zitat von: fh168 am 08 Mai 2018, 21:07:29
bin ich aktuell?
nein, siehe hier
https://forum.fhem.de/index.php/topic,83273.msg789328.html#msg789328
Gruß Ralf
Zitat von: andies am 08 Mai 2018, 20:46:56
Wie kann ich helfen?
Es gibt eine neue Version
https://raw.githubusercontent.com/Ralf9/SIGNALDuino/dev-r332_cc1101/SIGNALduino_nanoCC1101_332rc1.hex
Du kannst mal testen ob damit der Fehler mit der falschen Frequenz weg ist.
Gruß Ralf
Ich habe den ersten Beitrag (Nachtrag) aktualisiert.
Gruß Ralf
Danke, war lange weg und kann das erst diese Tage machen!
Problem (anscheinend) gelöst; Danke!
Gesendet von iPad mit Tapatalk Pro
Zitat ccconf freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:4dB (DataRate:5603.79Baud)
Hat sich denn am raw-send-Befehl irgendwas geändert?
Hallo Ralf9, ich habe die Ursache meines Problems gefunden. Die Frequenz verstellt sich. Ich habe "normalerweise" als Frequenz 433.9 MHz eingestellt und betreibe zwei Somfy-Rolläden. In einigen Fällen (wann genau, kann ich nicht sagen) verstellt sich die Frequenz auf den Somfy-Wert und bleibt dann so. Das raw-Senden der 433.9-Toröffnung geht dann natürlich nicht.
Die einfachste Lösung besteht für mich jetzt darin, dass ich einfach
vor jedem raw-Senden die Frequenz des Gartentorempfängers nochmal auf 433.9 einstelle. Ist das eine vernünftige Lösung, eine, die Ihr empfehlen würdet? Oder ist das ein Problem? Macht man so etwas nicht? Gibt es was besseres? Ist das überhaupt ein Fehler des Moduls?
Das genau ist mein workaround
fhem("set sduino cc1101_freq 433.9;
set sduino raw SR;;R=7;;P0=335;;P1=-665;;P2=-335;;P3=665;;P4=-15018;;D=01010101010101023101023104;;")
Funktioniert.
ZitatDie Frequenz verstellt sich. Ich habe "normalerweise" als Frequenz 433.9 MHz eingestellt und betreibe zwei Somfy-Rolläden. In einigen Fällen (wann genau, kann ich nicht sagen) verstellt sich die Frequenz auf den Somfy-Wert und bleibt dann so. Das raw-Senden der 433.9-Toröffnung geht dann natürlich nicht.
Danke für das nähere Eingrenzen, so wies aussieht passt in der Firmware was nicht ganz.
Nun weiß ich wo ich suchen muss.
Es gibt demnächst eine neue Firmware.
Gruß Ralf
Zitat von: andies am 27 Mai 2018, 15:09:40
Die Frequenz verstellt sich. Ich habe "normalerweise" als Frequenz 433.9 MHz eingestellt und betreibe zwei Somfy-Rolläden. In einigen Fällen (wann genau, kann ich nicht sagen) verstellt sich die Frequenz auf den Somfy-Wert und bleibt dann so. Das raw-Senden der 433.9-Toröffnung geht dann natürlich nicht.
Es gibt für den cc1101 eine neue Version 332rc2, bitte teste mal ob es damit funktioniert
set sduino flash https://raw.githubusercontent.com/Ralf9/SIGNALDuino/dev-r332_cc1101/firmware/SIGNALduino_nanoCC1101_332rc2.hexBeim Senden von Somfy müsste es ungefähr so aussehen:
2018.06.02 00:24:43 3: sduino/noMsg Parse: SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=645;D=AEE9E9C75D6577;F=10AB85550A;ccreg write back 10B07127C4F=10AB85550A ist 433.42MHz
write back 10B07127C4 ist 433.92MHz
Gruß Ralf
Zitat von: Ralf9 am 02 Juni 2018, 10:33:27
Es gibt für den cc1101 eine neue Version 332rc2, bitte teste mal ob es damit funktioniert
Danke für die Hilfe, ich habe das jetzt hochgeladen und einfach mal eine Jalousie bedient (sowie irgendeinen Sensor empfangen):
2018.06.02 11:44:43 4: sduino/msg READredu: MU;P0=-32001;P1=1984;P2=-1889;P3=3892;P4=-3911;D=01212341414141212121414121214121414121414121412121412121214141214121214121212141414121214141214121214121214121414121414141212141214141212141214121412;CP=1;R=17;
2018.06.02 11:44:43 5: sduino: applying filterfunc SIGNALduino_filterSign
2018.06.02 11:44:43 5: sduino: applying filterfunc SIGNALduino_compPattern
2018.06.02 11:44:43 4: sduino: Fingerprint for MU Protocol id 44 -> BresserTemeo matches, trying to demodulate
2018.06.02 11:44:43 5: sduino: Starting demodulation at Position 7
2018.06.02 11:44:43 5: sduino: dispatching bits: 1 1 1 0 0 0 1 1 0 0 1 0 1 1 0 1 1 0 1 0 0 1 0 0 0 1 1 0 1 0 0 1 0 0 0 1 1 1 0 0 1 1 0 1 0 0 1 0 0 1 0 1 1 0 1 1 1 0 0 1 0 1 1 0 0 1 0 1 0 1 0 0
2018.06.02 11:44:43 4: sduino: decoded matched MU Protocol id 44 dmsg W44#E32DA4691CD25B9654 length 72 RSSI = -65.5
2018.06.02 11:44:43 5: sduino Dispatch: W44#E32DA4691CD25B9654, test gleich
2018.06.02 11:44:43 5: sduino Dispatch: W44#E32DA4691CD25B9654, -65.5 dB, dispatch
2018.06.02 11:44:43 5: sduino: dispatch W44#E32DA4691CD25B9654
2018.06.02 11:44:43 4: SD_WS_Parse: Protocol: 44, rawData: E32DA4691CD25B9654
2018.06.02 11:44:43 4: SD_WS_Parse BresserTemeo: Humidity <= 79 Flag
2018.06.02 11:44:43 4: SD_WS_Parse BresserTemeo: new bin 0111000110010110110100100011010010001110011010010010110111001011001010100
2018.06.02 11:44:43 4: sduino SD_WS_Parse: model=BresserTemeo, temp=23.4, hum=71, channel=1, id=6D, bat=ok
2018.06.02 11:44:43 4: sduino: Fingerprint for MU Protocol id 44.1 -> BresserTemeo matches, trying to demodulate
2018.06.02 11:44:43 5: sduino: start pattern for MU Protocol id 44.1 -> BresserTemeo mismatches, aborting
2018.06.02 11:44:45 5: sduino/write: sending via Set sendMsg P43#A78584D3DDDDDD#R6
2018.06.02 11:44:45 5: sduino: sendmsg msg=P43#A78584D3DDDDDD#R6
2018.06.02 11:44:45 5: sduino: sendmsg Preparing manchester protocol=43, repeats=0, clock=645 data=A78584D3DDDDDD
2018.06.02 11:44:45 5: AddSendQueue: sduino: SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=645;D=A78584D3DDDDDD;F=10AB85550A; (1)
2018.06.02 11:44:45 4: sduino/set: sending via SendMsg: SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=645;D=A78584D3DDDDDD;F=10AB85550A;
2018.06.02 11:44:45 5: sduino SW: SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=645;D=A78584D3DDDDDD;F=10AB85550A;
2018.06.02 11:44:45 4: sduino SendrawFromQueue: msg=SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=645;D=A78584D3DDDDDD;F=10AB85550A;
2018.06.02 11:44:45 4: sduino/msg READ: SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=645;D=A78584D3DDDDDD;F=10AB85550A;ccreg write back 10B03F15C4
2018.06.02 11:44:45 5: sduino/noMsg Parse: SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=645;D=A78584D3DDDDDD;F=10AB85550A;ccreg write back 10B03F15C4
2018.06.02 11:44:45 5: sduino/msg READ: regexp=^S(R|C|M); cmd=sendraw msg=SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=645;D=A78584D3DDDDDD;F=10AB85550A;ccreg write back 10B03F15C4
2018.06.02 11:44:45 4: sduino/read sendraw answer: SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=645;D=A78584D3DDDDDD;F=10AB85550A;ccreg write back 10B03F15C4
2018.06.02 11:44:45 4: sduino/HandleWriteQueue: nothing to send, stopping timer
2018.06.02 11:44:50 4: sduino/keepalive ok, retry = 0
2018.06.02 11:45:11 4: sduino: Calling Getting Attr sub with args: del verbose =
2018.06.02 11:45:11 3: sduino: setting Verbose to:
2018.06.02 11:45:11 1: PERL WARNING: Argument "" isn't numeric in numeric lt (<) at ./FHEM/00_SIGNALduino.pm line 2689.Sieht gut aus, oder?
ccreg write back 10B03F15C4
Die eingestellte Frequenz passt nicht ganz genau, bitte mach mal ein Factoryreset
set sduino raw e
Gruß Ralf
Habe ich. Danach wieder ein Gerät eingelesen sowie einmal Somfy (der hat ja nicht 433.92) ausgelöst:
2018.06.02 15:30:52 4: sduino/msg READredu: MU;P0=-24432;P1=791;P2=-915;P3=213;P4=-664;P5=546;P6=-305;P7=-492;D=0121212123456563434565634343456565634343456343437;CP=3;R=218;
2018.06.02 15:30:52 4: sduino: Fingerprint for MU Protocol id 16 -> Dooya shutter matches, trying to demodulate
2018.06.02 15:30:52 5: sduino: start pattern for MU Protocol id 16 -> Dooya shutter mismatches, aborting
2018.06.02 15:30:52 5: sduino: applying filterfunc SIGNALduino_filterSign
2018.06.02 15:30:52 4: sduino: Fingerprint for MU Protocol id 20 -> livolo matches, trying to demodulate
2018.06.02 15:30:52 5: sduino: Starting demodulation at Position 12
2018.06.02 15:30:52 4: sduino: Fingerprint for MU Protocol id 24 -> visivon remote matches, trying to demodulate
2018.06.02 15:30:52 5: sduino: start pattern for MU Protocol id 24 -> visivon remote mismatches, aborting
2018.06.02 15:30:52 4: sduino: Fingerprint for MU Protocol id 27 -> remote27 matches, trying to demodulate
2018.06.02 15:30:52 5: sduino: start pattern for MU Protocol id 27 -> remote27 mismatches, aborting
2018.06.02 15:30:52 4: sduino: Fingerprint for MU Protocol id 28 -> IC Ledspot matches, trying to demodulate
2018.06.02 15:30:52 5: sduino: start pattern for MU Protocol id 28 -> IC Ledspot mismatches, aborting
2018.06.02 15:30:52 4: sduino: Fingerprint for MU Protocol id 29 -> HT12e remote matches, trying to demodulate
2018.06.02 15:30:52 5: sduino: start pattern for MU Protocol id 29 -> HT12e remote mismatches, aborting
2018.06.02 15:30:52 4: sduino: Fingerprint for MU Protocol id 30 -> unitec47031 matches, trying to demodulate
2018.06.02 15:30:52 5: sduino: start pattern for MU Protocol id 30 -> unitec47031 mismatches, aborting
2018.06.02 15:30:52 4: sduino: Fingerprint for MU Protocol id 31 -> pollin isotronic matches, trying to demodulate
2018.06.02 15:30:52 5: sduino: Starting demodulation at Position 1
2018.06.02 15:30:52 4: sduino: Fingerprint for MU Protocol id 37 -> Bresser 7009994 matches, trying to demodulate
2018.06.02 15:30:52 5: sduino: Starting demodulation at Position 4
2018.06.02 15:30:52 5: sduino: applying filterfunc SIGNALduino_compPattern
2018.06.02 15:30:52 4: sduino: Fingerprint for MU Protocol id 49 -> quigg_gt9000 matches, trying to demodulate
2018.06.02 15:30:52 5: sduino: start pattern for MU Protocol id 49 -> quigg_gt9000 mismatches, aborting
2018.06.02 15:30:52 4: sduino: Fingerprint for MU Protocol id 56 -> Celexon matches, trying to demodulate
2018.06.02 15:30:52 5: sduino: start pattern for MU Protocol id 56 -> Celexon mismatches, aborting
2018.06.02 15:30:52 4: sduino: Fingerprint for MU Protocol id 61 -> FS10 matches, trying to demodulate
2018.06.02 15:30:52 5: sduino: Starting demodulation at Position 9
2018.06.02 15:30:52 4: sduino: Fingerprint for MU Protocol id 62 -> Clarus_Switch matches, trying to demodulate
2018.06.02 15:30:52 5: sduino: start pattern for MU Protocol id 62 -> Clarus_Switch mismatches, aborting
2018.06.02 15:30:52 4: sduino: Fingerprint for MU Protocol id 69 -> Hoermann matches, trying to demodulate
2018.06.02 15:30:52 5: sduino: start pattern for MU Protocol id 69 -> Hoermann mismatches, aborting
2018.06.02 15:30:52 4: sduino: Fingerprint for MU Protocol id 70 -> FHT80TF matches, trying to demodulate
2018.06.02 15:30:52 5: sduino: Starting demodulation at Position 11
2018.06.02 15:30:52 4: sduino: Fingerprint for MU Protocol id 72 -> Siro shutter matches, trying to demodulate
2018.06.02 15:30:52 5: sduino: start pattern for MU Protocol id 72 -> Siro shutter mismatches, aborting
2018.06.02 15:30:52 4: sduino: Fingerprint for MU Protocol id 79 -> VTX-BELL_Funkklingel matches, trying to demodulate
2018.06.02 15:30:52 5: sduino: start pattern for MU Protocol id 79 -> VTX-BELL_Funkklingel mismatches, aborting
2018.06.02 15:30:52 4: sduino: Fingerprint for MU Protocol id 8 -> TX3 Protocol matches, trying to demodulate
2018.06.02 15:30:52 5: sduino: Starting demodulation at Position 1
2018.06.02 15:30:52 4: sduino/msg READredu: MU;P0=195;P1=811;P2=-899;P4=-664;P5=558;P6=-307;P7=-30168;D=121212120456560404565604040456565604040456040404040404560404040456560404040456045604565607;CP=0;R=220;w=0;
2018.06.02 15:30:52 4: sduino: Fingerprint for MU Protocol id 16 -> Dooya shutter matches, trying to demodulate
2018.06.02 15:30:52 5: sduino: start pattern for MU Protocol id 16 -> Dooya shutter mismatches, aborting
2018.06.02 15:30:52 5: sduino: applying filterfunc SIGNALduino_filterSign
2018.06.02 15:30:52 4: sduino: Fingerprint for MU Protocol id 20 -> livolo matches, trying to demodulate
2018.06.02 15:30:52 5: sduino: Starting demodulation at Position 11
2018.06.02 15:30:52 4: sduino: Fingerprint for MU Protocol id 24 -> visivon remote matches, trying to demodulate
2018.06.02 15:30:52 5: sduino: start pattern for MU Protocol id 24 -> visivon remote mismatches, aborting
2018.06.02 15:30:52 4: sduino: Fingerprint for MU Protocol id 27 -> remote27 matches, trying to demodulate
2018.06.02 15:30:52 5: sduino: start pattern for MU Protocol id 27 -> remote27 mismatches, aborting
2018.06.02 15:30:52 4: sduino: Fingerprint for MU Protocol id 28 -> IC Ledspot matches, trying to demodulate
2018.06.02 15:30:52 5: sduino: start pattern for MU Protocol id 28 -> IC Ledspot mismatches, aborting
2018.06.02 15:30:52 4: sduino: Fingerprint for MU Protocol id 29 -> HT12e remote matches, trying to demodulate
2018.06.02 15:30:52 5: sduino: start pattern for MU Protocol id 29 -> HT12e remote mismatches, aborting
2018.06.02 15:30:52 4: sduino: Fingerprint for MU Protocol id 30 -> unitec47031 matches, trying to demodulate
2018.06.02 15:30:52 5: sduino: start pattern for MU Protocol id 30 -> unitec47031 mismatches, aborting
2018.06.02 15:30:52 4: sduino: Fingerprint for MU Protocol id 31 -> pollin isotronic matches, trying to demodulate
2018.06.02 15:30:52 5: sduino: Starting demodulation at Position 1
2018.06.02 15:30:52 4: sduino: Fingerprint for MU Protocol id 37 -> Bresser 7009994 matches, trying to demodulate
2018.06.02 15:30:52 5: sduino: Starting demodulation at Position 8
2018.06.02 15:30:52 5: sduino: dispatching bits: 0 1 1 0 0 1 1 0 0 0 1 1 1 0 0 0 1 0 0 0 0 0 0 1 0 0 0 0 1 1 0 0 0 0 1 0 1 0 1 1
2018.06.02 15:30:52 4: sduino: decoded matched MU Protocol id 37 dmsg W37#6638810C2B length 40 RSSI = -92
2018.06.02 15:30:52 5: sduino Dispatch: W37#6638810C2B, test ungleich: disabled
2018.06.02 15:30:52 5: sduino Dispatch: W37#6638810C2B, -92 dB, dispatch
2018.06.02 15:30:52 5: sduino: dispatch W37#6638810C2B
2018.06.02 15:30:52 4: SD_WS_Parse: Protocol: 37, rawData: 6638810C2B
2018.06.02 15:30:52 4: sduino: SD_WS37 checksum ok 43 = 43
2018.06.02 15:30:52 4: sduino: SD_WS37 tempraw = 2177, temp = 127.7 F, temp = 53.2 C, Hum = 12
2018.06.02 15:30:52 4: sduino: SD_WS37 decoded protocol = 37 (Bresser 7009994), sensor id = 66, channel = 3
2018.06.02 15:30:52 1: SD_WS: UNDEFINED sensor SD_WS37_TH detected, code SD_WS37_TH_3
2018.06.02 15:30:52 5: sduino: applying filterfunc SIGNALduino_compPattern
2018.06.02 15:30:52 4: sduino: Fingerprint for MU Protocol id 49 -> quigg_gt9000 matches, trying to demodulate
2018.06.02 15:30:52 5: sduino: start pattern for MU Protocol id 49 -> quigg_gt9000 mismatches, aborting
2018.06.02 15:30:52 4: sduino: Fingerprint for MU Protocol id 56 -> Celexon matches, trying to demodulate
2018.06.02 15:30:52 5: sduino: start pattern for MU Protocol id 56 -> Celexon mismatches, aborting
2018.06.02 15:30:52 4: sduino: Fingerprint for MU Protocol id 61 -> FS10 matches, trying to demodulate
2018.06.02 15:30:52 5: sduino: Starting demodulation at Position 8
2018.06.02 15:30:52 5: sduino: dispatching bits: 1 0 0 1 1 0 0 1 1 1 0 0 0 1 1 1 0 1 1 1 1 1 1 0 1 1 1 1 0 0 1 1 1 1 0 1 0 1 0 0
2018.06.02 15:30:52 4: sduino: decoded matched MU Protocol id 61 dmsg P61#99C77EF3D4 length 40 RSSI = -92
2018.06.02 15:30:52 5: sduino Dispatch: P61#99C77EF3D4, test ungleich: disabled
2018.06.02 15:30:52 5: sduino Dispatch: P61#99C77EF3D4, -92 dB, dispatch
2018.06.02 15:30:52 5: sduino: dispatch P61#99C77EF3D4
2018.06.02 15:30:52 4: sduino FS10_Parse: Protocol: 61, rawData: 99C77EF3D4
2018.06.02 15:30:52 4: sduino FS10_Parse: rawBitData: 1001100111000111011111101111001111010100 (40)
2018.06.02 15:30:52 4: sduino: Fingerprint for MU Protocol id 62 -> Clarus_Switch matches, trying to demodulate
2018.06.02 15:30:52 5: sduino: start pattern for MU Protocol id 62 -> Clarus_Switch mismatches, aborting
2018.06.02 15:30:52 4: sduino: Fingerprint for MU Protocol id 69 -> Hoermann matches, trying to demodulate
2018.06.02 15:30:52 5: sduino: start pattern for MU Protocol id 69 -> Hoermann mismatches, aborting
2018.06.02 15:30:52 4: sduino: Fingerprint for MU Protocol id 70 -> FHT80TF matches, trying to demodulate
2018.06.02 15:30:52 5: sduino: Starting demodulation at Position 10
2018.06.02 15:30:52 4: sduino: Fingerprint for MU Protocol id 72 -> Siro shutter matches, trying to demodulate
2018.06.02 15:30:52 5: sduino: start pattern for MU Protocol id 72 -> Siro shutter mismatches, aborting
2018.06.02 15:30:52 4: sduino: Fingerprint for MU Protocol id 79 -> VTX-BELL_Funkklingel matches, trying to demodulate
2018.06.02 15:30:52 5: sduino: start pattern for MU Protocol id 79 -> VTX-BELL_Funkklingel mismatches, aborting
2018.06.02 15:30:52 4: sduino: Fingerprint for MU Protocol id 8 -> TX3 Protocol matches, trying to demodulate
2018.06.02 15:30:52 5: sduino: Starting demodulation at Position 0
2018.06.02 15:30:52 4: sduino/msg READredu: MU;P0=195;P1=811;P2=-899;P4=-664;P5=558;P6=-307;P7=-30168;D=71212121204565604045656040404565656040404560;CP=0;R=220;
2018.06.02 15:30:52 4: sduino: Fingerprint for MU Protocol id 16 -> Dooya shutter matches, trying to demodulate
2018.06.02 15:30:52 5: sduino: start pattern for MU Protocol id 16 -> Dooya shutter mismatches, aborting
2018.06.02 15:30:52 5: sduino: applying filterfunc SIGNALduino_filterSign
2018.06.02 15:30:52 4: sduino: Fingerprint for MU Protocol id 20 -> livolo matches, trying to demodulate
2018.06.02 15:30:52 5: sduino: Starting demodulation at Position 12
2018.06.02 15:30:52 4: sduino: Fingerprint for MU Protocol id 24 -> visivon remote matches, trying to demodulate
2018.06.02 15:30:52 5: sduino: start pattern for MU Protocol id 24 -> visivon remote mismatches, aborting
2018.06.02 15:30:52 4: sduino: Fingerprint for MU Protocol id 27 -> remote27 matches, trying to demodulate
2018.06.02 15:30:52 5: sduino: start pattern for MU Protocol id 27 -> remote27 mismatches, aborting
2018.06.02 15:30:52 4: sduino: Fingerprint for MU Protocol id 28 -> IC Ledspot matches, trying to demodulate
2018.06.02 15:30:52 5: sduino: start pattern for MU Protocol id 28 -> IC Ledspot mismatches, aborting
2018.06.02 15:30:52 4: sduino: Fingerprint for MU Protocol id 29 -> HT12e remote matches, trying to demodulate
2018.06.02 15:30:52 5: sduino: start pattern for MU Protocol id 29 -> HT12e remote mismatches, aborting
2018.06.02 15:30:52 4: sduino: Fingerprint for MU Protocol id 30 -> unitec47031 matches, trying to demodulate
2018.06.02 15:30:52 5: sduino: start pattern for MU Protocol id 30 -> unitec47031 mismatches, aborting
2018.06.02 15:30:52 4: sduino: Fingerprint for MU Protocol id 31 -> pollin isotronic matches, trying to demodulate
2018.06.02 15:30:52 5: sduino: Starting demodulation at Position 1
2018.06.02 15:30:52 4: sduino: Fingerprint for MU Protocol id 37 -> Bresser 7009994 matches, trying to demodulate
2018.06.02 15:30:52 5: sduino: Starting demodulation at Position 9
2018.06.02 15:30:52 5: sduino: applying filterfunc SIGNALduino_compPattern
2018.06.02 15:30:52 4: sduino: Fingerprint for MU Protocol id 49 -> quigg_gt9000 matches, trying to demodulate
2018.06.02 15:30:52 5: sduino: start pattern for MU Protocol id 49 -> quigg_gt9000 mismatches, aborting
2018.06.02 15:30:52 4: sduino: Fingerprint for MU Protocol id 56 -> Celexon matches, trying to demodulate
2018.06.02 15:30:52 5: sduino: start pattern for MU Protocol id 56 -> Celexon mismatches, aborting
2018.06.02 15:30:52 4: sduino: Fingerprint for MU Protocol id 61 -> FS10 matches, trying to demodulate
2018.06.02 15:30:52 5: sduino: Starting demodulation at Position 9
2018.06.02 15:30:52 4: sduino: Fingerprint for MU Protocol id 62 -> Clarus_Switch matches, trying to demodulate
2018.06.02 15:30:52 5: sduino: start pattern for MU Protocol id 62 -> Clarus_Switch mismatches, aborting
2018.06.02 15:30:52 4: sduino: Fingerprint for MU Protocol id 69 -> Hoermann matches, trying to demodulate
2018.06.02 15:30:52 5: sduino: start pattern for MU Protocol id 69 -> Hoermann mismatches, aborting
2018.06.02 15:30:52 4: sduino: Fingerprint for MU Protocol id 70 -> FHT80TF matches, trying to demodulate
2018.06.02 15:30:52 5: sduino: Starting demodulation at Position 11
2018.06.02 15:30:52 4: sduino: Fingerprint for MU Protocol id 72 -> Siro shutter matches, trying to demodulate
2018.06.02 15:30:52 5: sduino: start pattern for MU Protocol id 72 -> Siro shutter mismatches, aborting
2018.06.02 15:30:52 4: sduino: Fingerprint for MU Protocol id 79 -> VTX-BELL_Funkklingel matches, trying to demodulate
2018.06.02 15:30:52 5: sduino: start pattern for MU Protocol id 79 -> VTX-BELL_Funkklingel mismatches, aborting
2018.06.02 15:30:52 4: sduino: Fingerprint for MU Protocol id 8 -> TX3 Protocol matches, trying to demodulate
2018.06.02 15:30:52 5: sduino: Starting demodulation at Position 1
2018.06.02 15:30:59 5: sduino/write: sending via Set sendMsg P43#AB8988D3DDDDDD#R6
2018.06.02 15:30:59 5: sduino: sendmsg msg=P43#AB8988D3DDDDDD#R6
2018.06.02 15:30:59 5: sduino: sendmsg Preparing manchester protocol=43, repeats=0, clock=645 data=AB8988D3DDDDDD
2018.06.02 15:30:59 5: AddSendQueue: sduino: SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=645;D=AB8988D3DDDDDD;F=10AB85550A; (1)
2018.06.02 15:30:59 4: sduino/set: sending via SendMsg: SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=645;D=AB8988D3DDDDDD;F=10AB85550A;
2018.06.02 15:30:59 5: sduino SW: SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=645;D=AB8988D3DDDDDD;F=10AB85550A;
2018.06.02 15:30:59 4: sduino SendrawFromQueue: msg=SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=645;D=AB8988D3DDDDDD;F=10AB85550A;
2018.06.02 15:31:00 4: sduino/msg READ: SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=645;D=AB8988D3DDDDDD;F=10AB85550A;ccreg write back 10B07157C4
2018.06.02 15:31:00 5: sduino/noMsg Parse: SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=645;D=AB8988D3DDDDDD;F=10AB85550A;ccreg write back 10B07157C4
2018.06.02 15:31:00 5: sduino/msg READ: regexp=^S(R|C|M); cmd=sendraw msg=SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=645;D=AB8988D3DDDDDD;F=10AB85550A;ccreg write back 10B07157C4
2018.06.02 15:31:00 4: sduino/read sendraw answer: SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=645;D=AB8988D3DDDDDD;F=10AB85550A;ccreg write back 10B07157C4
2018.06.02 15:31:00 4: sduino/HandleWriteQueue: nothing to send, stopping timer
Wie kann ich diese Einträge vermeiden:
018.06.02 21:40:57 3: sduino: SD_WS37 ERROR - checksum 195 != 43
2018.06.02 21:41:54 3: sduino: SD_WS37 ERROR - checksum 195 != 43
2018.06.02 21:42:50 3: sduino: SD_WS37 ERROR - checksum 195 != 43
2018.06.02 21:44:44 3: sduino: SD_WS37 ERROR - checksum 195 != 43
2018.06.02 21:45:42 3: sduino: SD_WS37 ERROR - checksum 195 != 43
2018.06.02 21:46:39 3: sduino: SD_WS37 ERROR - checksum 195 != 43
2018.06.02 21:46:39 3: sduino: SD_WS37 ERROR - checksum 195 != 43
2018.06.02 21:49:29 3: sduino: SD_WS37 ERROR - checksum 195 != 43
2018.06.02 21:50:26 3: sduino: SD_WS37 ERROR - checksum 196 != 73
2018.06.02 21:51:23 3: sduino: SD_WS37 ERROR - checksum 195 != 43
2018.06.02 21:51:48 3: sduino: SD_WS37 ERROR - checksum 7 != 131
2018.06.02 21:52:21 3: sduino: SD_WS37 ERROR - checksum 195 != 43
2018.06.02 21:54:15 3: sduino: SD_WS37 ERROR - checksum 194 != 141
Gesendet von iPad mit Tapatalk Pro
2018.06.02 15:30:52 5: sduino Dispatch: W37#6638810C2B, -92 dB, dispatch
-92 dB sind grenzwertig.
Ist der SD_WS37 etwas weiter vom sduino weg?
Gruß Ralf
Der ist nicht bei mir, den hat der Nachbar (vermutlich). Ist das mit der Frequenz geklärt?
(Ich habe jetzt 37 auf die Blacklist gesetzt und die Meldung kommt nicht mehr.)
Das mit der Frequenz sieht im log gut aus. Hast Du damit noch Probleme?
Als Alternative zur Blacklist wäre, Sidey zu bitten den loglevel der checksum Fehlermeldung von 3 auf 4 zu erhöhen.
14_SD_WS.pm Zeile 253
Log3 $name, 3, "$name: SD_WS37 ERROR - checksum $checksum != ".SD_WS_binaryToNumber($bitData,32,39);
Gruß Ralf
Bisher läuft alles bestens. Ich habe verbose auf 0 und brauche diese anderen Geräte nicht, ich habe ja nur drei hier. Vielen Dank für die Reparatur!
Zitat"get sduino uptime" Fehler behoben (nun funktioniert auch größer 49 Tage).
Hier ist meine aktuelle uptime:
uptime 53 18:55:36ZitatIch 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.
Beim analysieren von unbekannten Protokollen kann es sinnvoll sein die Erkennung von Wiederholungen bei MU-Nachrichten abzuschalten:
get sduino raw CSmuthresh=0Gruß Ralf
Wenn mit einem https link z.B. von https://raw.githubusercontent.com/ geflasht wird, dann wird beim flashen kein flash log ausgegeben.
z.B. bei
set sduinoRXB flash https://raw.githubusercontent.com/Ralf9/SIGNALDuino/dev-r332_cc1101/firmware/SIGNALduino_nano_332rc1.hex
steht in etwa folgendes im fhem log:
2018.07.25 21:15:58.028 3 : url https://raw.githubusercontent.com/Ralf9/SIGNALDuino/dev-r332_cc1101/firmware/SIGNALduino_nano_332rc1.hex returned: 85276 bytes Data
2018.07.25 21:15:58.028 3 : sduinoRXB: Downloaded SIGNALduino_nano_332rc1.hex firmware from raw.githubusercontent.com
2018.07.25 21:15:58.029 5 : sduinoRXB: Header = HTTP/1.1 200 OK Content-Security-Policy: default-src 'none'; style-src 'unsafe-inline'; sandbox Strict-Transport-Security: max-age=31536000 X-Content-Type-Options: nosniff X-Frame-Options: deny X-XSS-Protection: 1; mode=block ETag: "8aae23ec6b263230a24c342cf5ba29ee9a5ce314" Content-Type: text/plain; charset=utf-8 Cache-Control: max-age=300 X-Geo-Block-List: X-GitHub-Request-Id: E798:1891:A168F3:AB1F70:5B58CC6D Content-Length: 85276 Accept-Ranges: bytes Date: Wed, 25 Jul 2018 19:15:57 GMT Via: 1.1 varnish Connection: close X-Served-By: cache-hhn1538-HHN X-Cache: MISS X-Cache-Hits: 0 X-Timer: S1532546158.845393,VS0,VE140 Vary: Authorization,Accept-Encoding Access-Control-Allow-Origin: * X-Fastly-Request-ID: f0cd834df3f45e9c28ed2a1206c7bf591ea6770a Expires: Wed, 25 Jul 2018 19:20:57 GMT Source-Age: 0
2018.07.25 21:15:58.029 3 : calling set flash FHEM/firmware/SIGNALduino_nano_332rc1.hex
2018.07.25 21:15:58.030 3 : sduinoRXB: filename FHEM/firmware/SIGNALduino_nano_332rc1.hex provided, trying to flash
Der flash log steht in der Datei "SIGNALduino-Flash.log" im log Verzeichnis.
z.B.:
avrdude: Version 6.3, (openSUSE Buildservice)
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2014 Joerg Wunsch
System wide configuration file is "/etc/avrdude.conf"
User configuration file is "/home/ralf/.avrduderc"
User configuration file does not exist or is not a regular file, skipping
Using Port : /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9GFBXLP-if00-port0
Using Programmer : arduino
Overriding Baud Rate : 57600
AVR Part : ATmega328P
Chip Erase delay : 9000 us
PAGEL : PD7
BS2 : PC2
RESET disposition : dedicated
RETRY pulse : SCK
serial program mode : yes
parallel program mode : yes
Timeout : 200
StabDelay : 100
CmdexeDelay : 25
SyncLoops : 32
ByteDelay : 0
PollIndex : 3
PollValue : 0x53
Memory Detail :
Block Poll Page Polled
Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
eeprom 65 20 4 0 no 1024 4 0 3600 3600 0xff 0xff
flash 65 6 128 0 yes 32768 128 256 4500 4500 0xff 0xff
lfuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
hfuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
efuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
lock 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
calibration 0 0 0 0 no 1 0 0 0 0 0x00 0x00
signature 0 0 0 0 no 3 0 0 0 0 0x00 0x00
Programmer Type : Arduino
Description : Arduino
Hardware Version: 2
Firmware Version: 1.16
Vtarget : 0.0 V
Varef : 0.0 V
Oscillator : Off
SCK period : 0.1 us
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.00s
avrdude: Device signature = 0x1e950f (probably m328p)
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "FHEM/firmware/SIGNALduino_nano_332rc1.hex"
avrdude: input file FHEM/firmware/SIGNALduino_nano_332rc1.hex auto detected as Intel Hex
avrdude: writing flash (30314 bytes):
Writing | ################################################## | 100% 8.30s
avrdude: 30314 bytes of flash written
avrdude: verifying flash memory against FHEM/firmware/SIGNALduino_nano_332rc1.hex:
avrdude: load data flash data from input file FHEM/firmware/SIGNALduino_nano_332rc1.hex:
avrdude: input file FHEM/firmware/SIGNALduino_nano_332rc1.hex auto detected as Intel Hex
avrdude: input file FHEM/firmware/SIGNALduino_nano_332rc1.hex contains 30314 bytes
avrdude: reading on-chip flash data:
Reading | ################################################## | 100% 6.16s
avrdude: verifying ...
avrdude: 30314 bytes of flash verified
avrdude done. Thank you.
Gruß Ralf
Zitat von: Ralf9 am 14 Februar 2018, 12:06:33
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
hallo Ralf
ich habe folgenden Stick bei mir im Einsatz:
https://shop.in-circuit.de/product_info.php?products_id=253 (https://shop.in-circuit.de/product_info.php?products_id=253)
mit diesem versuche ich folgende Wetterstation abzugreifen:
https://www.lidl.de/de/auriol-funk-wetterstation/p256157
Anleitung (Seite 8 für technische Infos):
https://www.lidl-service.com/static/1414890947/283582_PL.pdf (https://www.lidl-service.com/static/1414890947/283582_PL.pdf)
FHEM erkennt den sduino nur leider kann er mit den empfangenen Signalen nicht umgehen:
Logauszug:
2018.08.08 17:24:29 3: sduino: Unknown code u40#4E024870, help me!
2018.08.08 17:24:29 3: sduino: Unknown code u40#4824E024870, help me!
2018.08.08 17:24:29 3: sduino: Unknown code u40#4924E024870, help me!
2018.08.08 17:25:30 3: sduino: Unknown code u40#4904E024870, help me!
2018.08.08 17:25:30 3: sduino: Unknown code u40#4824E024870, help me!
2018.08.08 17:25:30 3: sduino: Unknown code u40#4924E024870, help me!
2018.08.08 17:25:31 3: sduino: Unknown code u40#4824E024870, help me!
2018.08.08 17:25:31 3: sduino: Unknown code u40#4924E024870, help me!
2018.08.08 17:26:01 3: sduino: Unknown code u40#09380921C, help me!
2018.08.08 17:26:01 3: sduino: Unknown code u40#490E6024870, help me!
2018.08.08 17:26:01 3: sduino: Unknown code u40#4E024870, help me!
2018.08.08 17:26:02 3: sduino: Unknown code u40#490E6024870, help me!
2018.08.08 17:27:03 3: sduino: Unknown code u40#4924E024870, help me!
2018.08.08 17:27:03 3: sduino: Unknown code u40#490E6024870, help me!
2018.08.08 17:29:07 3: sduino: Unknown code u40#4924E024A10, help me!
2018.08.08 17:29:07 3: sduino: Unknown code u40#4824E024A10, help me!
2018.08.08 17:29:08 3: sduino: Unknown code u40#4924E024A10, help me!
2018.08.08 17:29:08 3: sduino: Unknown code u40#4824E024A10, help me!
2018.08.08 17:30:09 3: sduino: Unknown code u40#127012508, help me!
2018.08.08 17:30:09 3: sduino: Unknown code u40#4824E024A10, help me!
2018.08.08 17:30:10 3: sduino: Unknown code u40#093809284, help me!
2018.08.08 17:30:10 3: sduino: Unknown code u40#4824E024A10, help me!
2018.08.08 17:30:10 3: sduino: Unknown code u40#093809284, help me!
2018.08.08 17:30:40 3: sduino: Unknown code u40#4924E024A10, help me!
2018.08.08 17:30:40 3: sduino: Unknown code u40#49420, help me!
2018.08.08 17:30:40 3: sduino: Unknown code u40#024A10, help me!
2018.08.08 17:30:40 3: sduino: Unknown code u40#49420, help me!
2018.08.08 17:30:40 3: sduino: Unknown code u40#024A10, help me!
2018.08.08 17:30:41 3: sduino: Unknown code u40#49420, help me!
2018.08.08 17:30:41 3: sduino: Unknown code u40#024A10, help me!
2018.08.08 17:30:41 3: sduino: Unknown code u40#49420, help me!
2018.08.08 17:30:41 3: sduino: Unknown code u40#024A10, help me!
2018.08.08 17:30:41 3: sduino: Unknown code u40#4924E024A10, help me!
2018.08.08 17:31:42 3: sduino: Unknown code u40#4940, help me!
2018.08.08 17:31:42 3: sduino: Unknown code u40#7012508, help me!
2018.08.08 17:31:42 3: sduino: Unknown code u40#4924E024A10, help me!
2018.08.08 17:31:43 3: sduino: Unknown code u40#4944E024A10, help me!
2018.08.08 17:31:43 3: sduino: Unknown code u40#4940, help me!
2018.08.08 17:31:43 3: sduino: Unknown code u40#7012508, help me!
2018.08.08 17:31:43 3: sduino: Unknown code u40#4940, help me!
2018.08.08 17:31:43 3: sduino: Unknown code u40#7012508, help me!List vom sduino:
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/ttyACM0
DMSG nothing
DevState disconnected
DeviceName /dev/ttyACM0@57600
LASTDMSG nothing
NAME sduino
NR 248
PARTIAL
STATE disconnected
TIME 1533803065.09469
TYPE SIGNALduino
versionmodul v3.3.3-dev_20.04.
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+#.*
READINGS:
2018-08-08 17:56:56 ccconf freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:8dB (DataRate:5603.79Baud)
2018-08-06 16:17:32 config MS=1;MU=1;MC=1
2018-08-08 12:26:41 ping OK
2018-08-09 10:24:25 state disconnected
2018-08-08 17:57:04 version V 3.3.1-dev SIGNALduino cc1101 (433Mhz )- compiled at Mar 10 2017 23:27:29
mcIdList:
10
11
12
18
43
47
52
57
58
msIdList:
0
1
2
3
3.1
4
6
7
13
13.2
14
15
17
22
23
25
32
33
35
38
41
51
55
65
68
72.1
muIdList:
5
8
9
13.1
16
20
21
24
26
27
28
29
30
31
36
37
39
40
44
44.1
45
46
48
49
50
56
59
60
61
62
64
66
67
69
70
71
72
75
79
Attributes:
flashCommand avrdude -c arduino -b [BAUDRATE] -P [PORT] -p atmega328p -vv -U flash:w:[HEXFILE] 2>[LOGFILE]
hardware nanoCC1101
room I/Oich habe jetzt versucht die Beta-Firmware 332 zu flashen.
Den Befehl habe ich direkt auf der Raspberry pi ausgeführt.
Leider erfolglos:
avrdude -v -p atmega32u4 -c avr109 -P /dev/ttyACM0 -b57600 -D -V -U flash:w:SIGNALduino_radinoCC1101_332r.hex:i
avrdude: Version 6.3-20171130
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2014 Joerg Wunsch
System wide configuration file is "/etc/avrdude.conf"
User configuration file is "/home/pi/.avrduderc"
User configuration file does not exist or is not a regular file, skipping
Using Port : /dev/ttyACM0
Using Programmer : avr109
Overriding Baud Rate : 57600
AVR Part : ATmega32U4
Chip Erase delay : 9000 us
PAGEL : PD7
BS2 : PA0
RESET disposition : dedicated
RETRY pulse : SCK
serial program mode : yes
parallel program mode : yes
Timeout : 200
StabDelay : 100
CmdexeDelay : 25
SyncLoops : 32
ByteDelay : 0
PollIndex : 3
PollValue : 0x53
Memory Detail :
Block Poll Page Polled
Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
eeprom 65 20 4 0 no 1024 4 0 9000 9000 0x00 0x00
flash 65 6 128 0 yes 32768 128 256 4500 4500 0x00 0x00
lfuse 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00
hfuse 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00
efuse 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00
lock 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00
calibration 0 0 0 0 no 1 0 0 0 0 0x00 0x00
signature 0 0 0 0 no 3 0 0 0 0 0x00 0x00
Programmer Type : butterfly
Description : Atmel AppNote AVR109 Boot Loader
Connecting to programmer: .
Found programmer: Id = "CATERIN"; type = S
Software Version = 1.0; No Hardware Version given.
Programmer supports auto addr increment.
Programmer supports buffered memory access with buffersize=128 bytes.
Programmer supports the following devices:
Device code: 0x44
avrdude: devcode selected: 0x44
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.00s
avrdude: Device signature = 0x1e9587 (probably m32u4)
avrdude: safemode: lfuse reads as FF
avrdude: safemode: hfuse reads as D8
avrdude: safemode: efuse reads as CB
avrdude: reading input file "SIGNALduino_radinoCC1101_332r.hex"
avrdude: ERROR: No valid record found in Intel Hex file "SIGNALduino_radinoCC1101_332r.hex"
avrdude: read from file 'SIGNALduino_radinoCC1101_332r.hex' failed
avrdude: safemode: lfuse reads as FF
avrdude: safemode: hfuse reads as D8
avrdude: safemode: efuse reads as CB
avrdude: safemode: Fuses OK (E:CB, H:D8, L:FF)
avrdude done. Thank you.den radinoCC1101 konnte ich problemlos flashen:
avrdude -v -p atmega32u4 -c avr109 -P /dev/ttyACM0 -b57600 -D -V -U flash:w:SIGNALDuino_radinoCC1101.hex:i
avrdude: Version 6.3-20171130
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2014 Joerg Wunsch
System wide configuration file is "/etc/avrdude.conf"
User configuration file is "/home/pi/.avrduderc"
User configuration file does not exist or is not a regular file, skipping
Using Port : /dev/ttyACM0
Using Programmer : avr109
Overriding Baud Rate : 57600
AVR Part : ATmega32U4
Chip Erase delay : 9000 us
PAGEL : PD7
BS2 : PA0
RESET disposition : dedicated
RETRY pulse : SCK
serial program mode : yes
parallel program mode : yes
Timeout : 200
StabDelay : 100
CmdexeDelay : 25
SyncLoops : 32
ByteDelay : 0
PollIndex : 3
PollValue : 0x53
Memory Detail :
Block Poll Page Polled
Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
eeprom 65 20 4 0 no 1024 4 0 9000 9000 0x00 0x00
flash 65 6 128 0 yes 32768 128 256 4500 4500 0x00 0x00
lfuse 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00
hfuse 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00
efuse 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00
lock 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00
calibration 0 0 0 0 no 1 0 0 0 0 0x00 0x00
signature 0 0 0 0 no 3 0 0 0 0 0x00 0x00
Programmer Type : butterfly
Description : Atmel AppNote AVR109 Boot Loader
Connecting to programmer: .
Found programmer: Id = "CATERIN"; type = S
Software Version = 1.0; No Hardware Version given.
Programmer supports auto addr increment.
Programmer supports buffered memory access with buffersize=128 bytes.
Programmer supports the following devices:
Device code: 0x44
avrdude: devcode selected: 0x44
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.00s
avrdude: Device signature = 0x1e9587 (probably m32u4)
avrdude: safemode: lfuse reads as FF
avrdude: safemode: hfuse reads as D8
avrdude: safemode: efuse reads as CB
avrdude: reading input file "SIGNALDuino_radinoCC1101.hex"
avrdude: writing flash (23080 bytes):
Writing | ################################################## | 100% 3.02s
avrdude: 23080 bytes of flash written
avrdude: safemode: lfuse reads as FF
avrdude: safemode: hfuse reads as D8
avrdude: safemode: efuse reads as CB
avrdude: safemode: Fuses OK (E:CB, H:D8, L:FF)
avrdude done. Thank you.
Ich hoffe die Logauszüge sind hilfreich. Wenn du noch mehr Infos benötigst, dann melde dich bitte.
Vielen Dank schonmal
Gruß Michael
Bitte versuche mal folgendes:
set sduino flash https://raw.githubusercontent.com/Ralf9/SIGNALDuino/dev-r332_cc1101/firmware/SIGNALduino_radinoCC1101_332r.hexZitatFHEM erkennt den sduino nur leider kann er mit den empfangenen Signalen nicht umgehen:
evtl ist mit den raw Nachrichten mehr zu erkennen (sduino verbose 4)
Gruß Ralf
hi,
hatte ich auch mal getestet, leider aber nicht mit Verbose 4.
Aktuell habe ich meinen Signauduino durch die ganze flasherei wohl zerschossen. Er wird weder bei Windows noch Linux erkannt ....
Sobald ich den wieder hinbekommen haben sollte, werde ich den gewünschten Test durchführen.
Gruß Michael
hi,
so läuft wieder. Hier die Logs:
Flashlog:
avrdude: Version 6.3-20171130
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2014 Joerg Wunsch
System wide configuration file is "/etc/avrdude.conf"
Using Port : /dev/ttyACM0
Using Programmer : arduino
Overriding Baud Rate : 57600
ioctl("TIOCMSET"): Broken pipe
ioctl("TIOCMSET"): Broken pipe
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x3f
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x3f
avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0x3f
avrdude: stk500_getsync() attempt 4 of 10: not in sync: resp=0x3f
avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0x3f
avrdude: stk500_getsync() attempt 6 of 10: not in sync: resp=0x3f
avrdude: stk500_getsync() attempt 7 of 10: not in sync: resp=0x3f
avrdude: stk500_getsync() attempt 8 of 10: not in sync: resp=0x3f
avrdude: stk500_getsync() attempt 9 of 10: not in sync: resp=0x3f
avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0x3f
und das FHEM-Log mit Verbose 4:
2018.08.10 10:28:24 3: sduino: setting Verbose to: 4
2018.08.10 10:28:44 1: /dev/ttyACM0 disconnected, waiting to reappear (sduino)
2018.08.10 10:28:47 3: Setting sduino serial parameters to 57600,8,N,1
2018.08.10 10:28:47 1: sduino/define: /dev/ttyACM0
2018.08.10 10:28:47 1: sduino/init: /dev/ttyACM0
2018.08.10 10:28:47 1: /dev/ttyACM0 reappeared (sduino)
2018.08.10 10:28:49 3: sduino/init: disable receiver (XQ)
2018.08.10 10:28:49 3: url https://raw.githubusercontent.com/Ralf9/SIGNALDuino/dev-r332_cc1101/firmware/SIGNALduino_radinoCC1101_332r.hex returned: 79663 bytes Data
2018.08.10 10:28:49 3: sduino: Downloaded SIGNALduino_radinoCC1101_332r.hex firmware from raw.githubusercontent.com
2018.08.10 10:28:49 3: sduino: filename FHEM/firmware/SIGNALduino_radinoCC1101_332r.hex provided, trying to flash
2018.08.10 10:28:51 3: Opening sduino device /dev/ttyACM0
2018.08.10 10:28:51 3: Setting sduino serial parameters to 57600,8,N,1
2018.08.10 10:28:51 1: sduino/define: /dev/ttyACM0
2018.08.10 10:28:51 1: sduino/init: /dev/ttyACM0
2018.08.10 10:28:51 3: sduino device opened
2018.08.10 10:28:52 3: sduino/init: disable receiver (XQ)
2018.08.10 10:28:53 3: sduino/init: get version, retry = 0
2018.08.10 10:28:53 1: /dev/ttyACM0 disconnected, waiting to reappear (sduino)
2018.08.10 10:28:58 3: Setting sduino serial parameters to 57600,8,N,1
2018.08.10 10:28:58 1: sduino/define: /dev/ttyACM0
2018.08.10 10:28:58 1: sduino/init: /dev/ttyACM0
2018.08.10 10:28:58 1: /dev/ttyACM0 reappeared (sduino)
2018.08.10 10:28:58 4: sduino/msg READ: Reading values fom eeprom
2018.08.10 10:28:58 4: sduino/msg READ: Received answer (Reading values fom eeprom) for version does not match V\s.*SIGNAL(duino|ESP).*
2018.08.10 10:28:58 4: sduino/msg READ: CCVersion=20
2018.08.10 10:28:58 4: sduino/msg READ: Received answer (CCVersion=20) for version does not match V\s.*SIGNAL(duino|ESP).*
2018.08.10 10:28:58 4: sduino/msg READ: CCPartnum=0
2018.08.10 10:28:58 4: sduino/msg READ: Received answer (CCPartnum=0) for version does not match V\s.*SIGNAL(duino|ESP).*
2018.08.10 10:28:58 4: sduino/msg READ: CC1101 found
2018.08.10 10:28:58 4: sduino/msg READ: Received answer (CC1101 found) for version does not match V\s.*SIGNAL(duino|ESP).*
2018.08.10 10:28:58 4: sduino/msg READ: Starting timerjob
2018.08.10 10:28:58 4: sduino/msg READ: Received answer (Starting timerjob) for version does not match V\s.*SIGNAL(duino|ESP).*
2018.08.10 10:28:58 4: sduino/msg READ: receiver enabled
2018.08.10 10:28:58 4: sduino/msg READ: Received answer (receiver enabled) for version does not match V\s.*SIGNAL(duino|ESP).*
2018.08.10 10:28:59 3: sduino/init: disable receiver (XQ)
2018.08.10 10:29:00 3: sduino/init: get version, retry = 0
2018.08.10 10:29:00 4: sduino/msg READ: V 3.3.1-dev SIGNALduino cc1101 (433Mhz )- compiled at Mar 10 2017 23:27:29
2018.08.10 10:29:00 2: sduino: initialized. v3.3.2
2018.08.10 10:29:00 3: sduino/init: enable receiver (XE)
ich hoffe das hilft weiter.
P.S.: Auf meinem Haupt-Fhem hatte ich gestern Abend gesehen, dass die Wetterstation wohl doch empfangen wurde und auch ein DEVICE angelegt hat. Somit komme ich wahrscheinlich auch mit der alten Firmware zurecht. Ich werde das heute nochmals testen.
Gruß Michael
Zitat2018.08.10 10:28:49 3: sduino: filename FHEM/firmware/SIGNALduino_radinoCC1101_332r.hex provided, trying to flash
2018.08.10 10:29:00 4: sduino/msg READ: V 3.3.1-dev SIGNALduino cc1101 (433Mhz )- compiled at Mar 10 2017 23:27:29
ZitatP.S.: Auf meinem Haupt-Fhem hatte ich gestern Abend gesehen, dass die Wetterstation wohl doch empfangen wurde und auch ein DEVICE angelegt hat. Somit komme ich wahrscheinlich auch mit der alten Firmware zurecht. Ich werde das heute nochmals testen.
Es sieht so aus als hätte das flashen der SIGNALduino_radinoCC1101_332r.hex nicht funktioniert, mit get version wird die alte firmware "V 3.3.1-dev SIGNALduino cc1101 (433Mhz )- compiled at Mar 10 2017" angezeigt.
Die Wetterstation sollte aber auch von der alten Firmware erkannt werden.
Evtl ist in fhem ein update auf die dev-r33 notwendig
update all https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r33/controls_signalduino.txtGruß Ralf
ja genauso ist es!
die Frage ist warum, das nicht funktioniert hat?!
Gruß Michael
Da kann ich leider auch nicht weiterhelfen, da ich keinen radino zum Testen habe.
Evtl bist Du der erste der dies mit einem radino versucht hat.
Gruß Ralf
ok, alles klar.
ich komm ja erstmal zurecht.
Vielen Dank schon mal und ein schönes Wochenende!
Gruß Michael
ich frage hier auch mal, denn ich habe einen Thread (https://forum.fhem.de/index.php/topic,90101.msg827022.html#msg827022) eröffnet und dort meine Probleme geschildert.
Kann sein das mir evtl. eine Aktualisierung der Firmware weiterhilft..? Oder eben nicht dann hat sich da hier erledigt. Sduino habe ich erst vor einer Woche bei ebay gekauft.
dies kannst Du nur durch testen mit der Firmware rausfinden.
Gruß Ralf
Hier ist ein Ausblick auf die nächste Version V 3.3.2.1-rc0 (ist rc0 ok, oder ist es besser, wenn ich mit rc3 weiter zähle?
Momentan können mit einer MU-Nachricht maximal 255 Pulse übertagen werden. Ein Überlauf wird mit einem O am Ende gekennzeichnet.
In der 3.2.2 habe ich zwar eine Erkennung von Wiederholungen bei MU-Nachrichten eingebaut, diese funktioniert aber nicht bei allen MU-Nachrichten.
Nun werden bei einem Überlauf die restlichen Daten in MO-Nachrichten übertragen.
Die Nachrichten müssen dann in der 00_SIGNALduino.pm wieder zusammengesetzt werden.
Das CP=xx und R=xx wird nun vor den Daten ausgegeben.
MU;P0=-500;P1=503;P2=-1057;P3=1425;P4=-25402;CP=1;D=012121212121232121212121212121212121232323232321232123212321232323232323232323232323232323232323232323232323232321212121232141212121212121212321212121212121212121212323232323212321232123212323232323232323232323232323232323232323232323232323212121212321;O0;
MO;D=41212121212121212321212121212121212121212323232323212321232123212323232323232323232323232323232323232323232323232323212121212321;e;
Damit die MU-Nachrichten nun noch verarbeitet werden können, ist in der "SIGNALduino_Parse" eine Anpassung notwendig. Es muß in der folgenden Abfrage das CP=\d; entfernt werden:
elsif (@{$hash->{muIdList}} && $rmsg=~ m/^MU;(P\d=-?\d+;){3,8}D=\d+;CP=\d;/)
Damit auch die MO-Nachrichten verarbeitet werden können sind noch weitere Anpassungen in der 00_SIGNALduino.pm notwendig.
Gruß Ralf
Ich habe in der Firmware noch einen Bug gefunden, der für mich sehr schwierig zu finden war.
Wenn die Bedingung "if (message == pattern_pos)" nie erfüllt ist, dann ergibt das folgende "for" eine Endlosschleife.
Mir ist nicht klar warum durch das "i >= 0" die for Schleife nicht bei 0 endet. Sie macht weiter mit 255.
Mit "i>0" endet die Scheife bei 1
if (messageLen > 0) {
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);
calcHisto();
break;
}
}
}
Ich habe es ein wenig umgeschrieben, dies sollte eigentlich das gleiche machen.
if (messageLen > 0 && histo[pattern_pos] == 0) {
for (uint8_t i = messageLen; i > 0; --i)
{
if (message[i-1] == pattern_pos) // Finde den letzten Verweis im Array auf den Index der gleich ueberschrieben wird
{
bufferMove(i); // i um eins erhoehen, damit zukuenftigen Berechnungen darauf aufbauen koennen
calcHisto();
break;
}
}
}
Gruß Ralf
Mit i >= 0 ist 0 ebenso wahr wie alle zahlen > 0.
uint8_t heißt doch bestimmt unsigned Integer 8 Bit, oder? Dann kann der Wert nur zwischen 0 und 255 liegen und nicht negativ werden.
ZitatDann kann der Wert nur zwischen 0 und 255 liegen und nicht negativ werden.
Danke, nun ist mir auch klar geworden, daß die Abfrage i >= 0 nur funktionieren kann, wenn i auch negativ werden kann.
Gruß Ralf
ZitatHier ist ein Ausblick auf die nächste Version V 3.3.2.1
Momentan können mit einer MU-Nachricht maximal 255 Pulse übertagen werden. Ein Überlauf wird mit einem O am Ende gekennzeichnet.
In der 3.2.2 habe ich zwar eine Erkennung von Wiederholungen bei MU-Nachrichten eingebaut, diese funktioniert aber nicht bei allen MU-Nachrichten.
Nun werden bei einem Überlauf die restlichen Daten in MO-Nachrichten übertragen.
Die Nachrichten müssen dann in der 00_SIGNALduino.pm wieder zusammengesetzt werden.
Die neue Option, daß bei einem Überlauf die restlichen Daten in MO-Nachrichten übertragen werden, ist default mässig abgeschaltet.
ein: (bei get config steht dann: MuNoOverflow=1
get sduino raw CEOaus:get sduino raw CDODa bei MU-Nachrichten die Wiederholungen nun in der 00_SIGNALduino.pm verarbeitet werden können, kann in der Firmware die Erkennung und spliten von Wiederholungen abgeschaltet werden:
get sduino raw CSmuthresh=0Da dies noch im beta Stadium ist und das zusammensetzen der Nachrichten noch nicht in der offiziellen 00_SIGNALduino.pm ist, ist zum Testen eine angepasste 00_SIGNALduino.pm notwendig:
https://github.com/Ralf9/RFFHEM/blob/master/FHEM/00_SIGNALduino.pm
und hier als raw für den download:
https://raw.githubusercontent.com/Ralf9/RFFHEM/master/FHEM/00_SIGNALduino.pm
Gruß Ralf
History:11.05.18 V 3.3.2-rc1- FIFO_LENGTH von 100 auf 120 erhöht
- Bei getSync() das syncLenMax von 100 auf 120 erhöht. Dies ist zum Empfangen von Homeeasy HE_EU notwendig
- "get sduino uptime" Fehler behoben (nun funktioniert auch größer 49 Tage).
11.06.18 es gibt für den cc1101 eine neue Version 3.3.2-rc2- Bei send raw mit dem Parameter "F=..." (Frequenz) konnte es Probleme geben.
15.09.18 V 3.3.2.1-rc3-Da nun bei den MU-Nachrichten das CP=x und R=xx vor den Daten ausgegeben wird, funktioniert diese Version nicht mehr mit der 00_SIGNALduino.pm aus dem normalen fhem update. Es wird die Entwicklerversion dev-r33 benötigt.
- Ich habe den FIFO Empfangspuffer auf 130 erhöht
- Die max Länge der Sendekommandos habe ich beim nano mit cc1101 auf 350 und beim nano ohne cc1101 auf 400 erhöht.
29.09.18 V 3.3.2.1-rc4- Es waren bei der Übertragung von komprimierten (bei get config steht Mred=1) Nachrichten 2 Fehler:
Bei komprimierten MS-Nachrichten konnte am Anfang ein Bit zuviel sein.
Bei komprimierten MU-Nachrichten war am Ende ein Bit zuwenig oder ein Bit zuviel.
Z.B. bei der ID 34 (QUIGG GT-7000 Funk-Steckdosendimmer) hat dadurch am Ende ein Bit gefehlt.
-
Es gibt eine neue Option mit der bei einem Überlauf die restlichen Daten in MO-Nachrichten übertragen werden. Wurde in der V 3.3.2.1-rc6 anders gelöst.
03.11.18 V 3.3.2.1-rc5- mit "set sduino raw CDL" wird nun auch beim Senden die Message-LED ausgeschaltet.
- Ich habe die Syntaxprüfung beim Senden erweitert, wenn beim Sendebefehl der Datenteil fehlt, wird "send failed" ausgegeben.
- Zum kompilieren habe ich nun die z.Zt. aktuelle Arduino IDE 1.8.7 verwendet.
miniCUL:
set sduino flash https://raw.githubusercontent.com/Ralf9/SIGNALDuino/dev-r332_cc1101/firmware/SIGNALduino_miniCUL_3321rc5.hex02.12.18 V 3.3.2.1-rc6- Bei get config wird nun auch hinter dem / die FIFO Größe ausgegeben (MdebFifoLimit=120/140).
- Ich habe den FIFO auf 140 erhöht.
- Ich habe die Ausgabe von sehr langen MU-Nachrichten überarbeitet. Bei einem Überlauf werden die restlichen Daten nicht mehr in MO-Nachrichten übertragen.
Nach einem Überlauf bei einer MU-Nachricht werden die restlichen Daten an die MU-Nachricht angehängt.
Die Ausgabe der sehr langen MU-Nachrichten funktioniert z.T. bei der offiziellen Entwicklerversion dev-r33 nur bei unkomprimierte Nachrichten (Mred=0).
Bei komprimierten Nachrichten ist noch eine Anpassung in der 00_signalduino.pm erforderlich
https://github.com/RFD-FHEM/RFFHEM/commit/7cd526edcf43684d27b631243262a59a9a374f85
https://github.com/Ralf9/RFFHEM/issues/2
nano mit cc1101:
set sduino flash https://raw.githubusercontent.com/Ralf9/SIGNALDuino/dev-r332_cc1101/firmware/SIGNALduino_nanoCC1101_3321rc6.hex3.3V promini mit CC1101
set sduino flash https://raw.githubusercontent.com/Ralf9/SIGNALDuino/dev-r332_cc1101/firmware/SIGNALduino_3v3prominiCC1101_3321rc6.hexDiese Version ist für diejenigen, die mit einem 3.3V promini und der nanocul Verkabelung einen Signalduino gebaut haben.
nano ohne cc1101:
set sduino flash https://raw.githubusercontent.com/Ralf9/SIGNALDuino/dev-r332_cc1101/firmware/SIGNALduino_nano_3321rc6.hexradino:
set sduino flash https://raw.githubusercontent.com/Ralf9/SIGNALDuino/dev-r332_cc1101/firmware/SIGNALduino_radinoCC1101_3321rc6.hex9.12.18 V 3.3.2.1-rc7- Optimierungen damit weniger RAM belegt wird.
12.01.19 V 3.3.2.1-rc8- Es werden nun auch die sehr langen MC-Nachrichten der neuen Oregon V3 Sensoren unterstützt.
- der Windmesser W132 von der Wetterstation Ventus W155 wird nun auch sauber empfangen
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-rc9Es 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
Gruß Ralf
Zitat von: Ralf9 am 29 September 2018, 10:13:36
Diese Version funktioniert nicht mehr mit der 00_SIGNALduino.pm aus dem normalen fhem update. Es wird die Entwicklerversion dev-r33 benötigt.
Bei der 00_SIGNALduino.pm aus dem normalen fhem update ist eine kleine Anpassung notwendig, bei Bedarf kann ich diese hier posten.
Hallo Ralf,
wann kann man denn damit rechnen, das die geänderte 00_SIGNALDUINO.pm ins "normale" fhem update übernommen wird.
Hintergrund ist das ich zwei SignalESPs an FHEM habe, einen 433 für IT der produktiv eingestzt wird und soweit funktioniert und einen 868 der für Testzwecke missbraucht wird. Würde gerne beide parallel betreiben. Gibt's da eine Möglichkeit das zu trennen damit ich den 868 auf RC4 laufen lassen kann?
Der 433er läuft zur Zeit mit Firmware Version V 3.3.1-dev SIGNALESP cc1101 433MHz - compiled at Nov 2 2017 ausschliesslich für IT Sachen.
Viele Grüße
Markus
Hallo Markus,
die geänderte 00_SIGNALDUINO.pm wird nur für die Firmware Version V 3.3.2.1 benötigt.
Für die SignalESPs ist die geänderte 00_SIGNALDUINO.pm nicht nowendig, da es von meiner V 3.3.2.x keine firmware für die SignalESPs gibt.
Gruß Ralf
Alles ein wenig verwirrend!
[emoji33][emoji6]
Gesendet von meinem E6653 mit Tapatalk
Hallo Ralf,
ich habe mich auch nicht richtig ausgedrückt....sorry.... ;-)
Also ich habe einen SignalESP 433Mhz und einen Signalduino 868 MHZ (natürlich seriell)
Beide verwenden ja die selbe Signalduino.pm
Wie kann ich das denn handhaben in Bezug auf Tests mit dem seriellen Signalduino und deiner Firmware?
Gruß
Markus
ZitatWie kann ich das denn handhaben in Bezug auf Tests mit dem seriellen Signalduino und deiner Firmware?
Wenn Du die V 3.3.2.1-rc4 und die 00_SIGNALDUINO vom normalen fhem update benutzen möchstest, dann mußt Du in der 00_SIGNALDUINO die folgende Zeile ändern.
In der sub SIGNALduino_Parse($$$$@) die Zeile 3802
elsif (@{$hash->{muIdList}} && $rmsg=~ m/^MU;(P\d=-?\d+;){3,8}D=\d+;CP=\d;/)abändern in
elsif (@{$hash->{muIdList}} && $rmsg=~ m/^MU;(P\d=-?\d+;){3,8}((CP|R)=\d+;){0,2}D=\d+;/)danach fhem neustarten
oder ein
reload 00_SIGNALduino.pm
Gruß Ralf
okay danke dir :-)
werde es mal so testen...
Gruß
Markus
Hallo Ralf,
in Antwort #129 ist mit miniCUL der miniCUL von locutus gemeint?
Zitatist mit miniCUL der miniCUL von locutus gemeint?
ja, der ist gemeint.
Gruß Ralf
Hallo Ralf,
ich habe versucht, meinen SignalDuino nach Deiner Anleitung zu flashen.
set sduino_nano_c1101 flash https://raw.githubusercontent.com/Ralf9/SIGNALDuino/dev-r332_cc1101/firmware/SIGNALduino_nanoCC1101_332rc2.hex
(Die Datei wurde auch in das FHEM-Firmwareverzeichnis kopiert)
Leider wird die Änerung nicht übernommen (es gibt auch keine Fehlermeldung)
Es wird weiterhin die ursprüngliche Version (version: V 3.3.1-dev SIGNALduino cc1101 - compiled at Mar 10 2017 22:54:50)
von FHEM genutzt.
Das sind die beiden Zeilen zu meinem sduino aus der FHEM fhem-Config:
define sduino_nano_c1101 SIGNALduino /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9I5XRZ7-if00-port0@57600
attr sduino_nano_c1101 flashCommand avrdude -c arduino -b [BAUDRATE] -P [PORT] -p atmega328p -vv -U flash:w:[HEXFILE] 2>[LOGFILE]
Muss ich bei [HEXFILE] Deine neue Datei eintragen?
Achim
Es gibt ein flash log wo Du nachsehen kannst, was nicht geklappt hat.
Der flash log steht in der Datei "SIGNALduino-Flash.log" im log Verzeichnis.
https://forum.fhem.de/index.php/topic,82379.msg821636.html#msg821636
Du kannst auch mit
set sduino_nano_c1101 flash FHEM/firmware/SIGNALduino_nanoCC1101_332rc2.hex
nochmals versuchen zu flashen
Gruß Ralf
Mich würde mal interessieren wie stabil die V 3.3.2 rc oder 3.3.2.1 rc bei Euch läuft, insbesondere wenn viel gesendet wird.
Ich verwende produktiv einen promini mit der "V 3.3.2-rc2 SIGNALduino cc1101" und habe mittlerweile eine uptime von fast 144 Tagen. Ich sende nur sehr wenig.
Da ich gegenüber der V 3.3.1 die Senderoutinen überarbeitet habe, müsste die firmware auch bei sehr langen Sendebefehlen sehr stabil laufen.
Interessant ist auch ob durch vieles senden das freeram deutlich weniger wird.
Gruß Ralf
Hallo Ralf,
ich schätze deine Bemühungen sehr, nur leider ändert sich bei mir nichts. Inzwischen habe ich die Befürchtung, dass durch das häufige flashen irgendwann der sduino ganz aussteigt...
Wie dem auch sei...eben auf Version 3.3.2.1-rc4 aktualisiert und Zeile 3802 in der 00_SIGNALDUINO gemäß #134 geändert:
2018.10.26 10:51:12 1: sduino: SOMFY_Parse : Somfy RTS message format error (length)! :A18D8FD22409EE84001D:
2018.10.26 10:51:12 3: sduino: Unknown code YsA18D8FD22409EE84001D, help me!
Dabei hatte ich schon so gefreut... :-\
LG
was ergibt
get sduino version
get sduino config
get sduino ccconf
nähere Infos wären hilfreich.
funktioniert gar nichts?
Funktioniert SOMFY nur teilweise oder gar nicht?
Gruß Ralf
Hallo zusammen,
ich bin nun durch Arnd ebenfalls im Besitz eines Signalduino mit cc1101-Chip um meinen Busware CUL abzulösen und die Somfy Rollos nebst IT Komponenten Schalten zu können.
Nach dem Konfigurieren und ersten Test mit dem Signalduino ist mir aufgefallen, dass er bei scheinbar jedem (auch get version) Kommando auf den Status Disconnectet wechselt und dann sofort wieder open wird.
Aus dem Log mal ein Mitschnitt, wo ich eben ein Rollo runter, gestopped und hochgefahren habe. Der Befehl zum Runterfahren wurde sofort ausgelöst, der nach wenigen Sekunden gesendete Stop-Befehl gar nicht und erst wieder nach mehrmaligem Versuch der Hoch-Befehl.
Versuche ich das ganze mit meinem CUL läuft es Problemlos.
2018.10.27 12:17:04 1: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_003A9QUY-if00-port0 disconnected, waiting to reappear (SIGNAL_CUL)
2018.10.27 12:17:04 3: Setting SIGNAL_CUL serial parameters to 57600,8,N,1
2018.10.27 12:17:04 1: SIGNAL_CUL/define: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_003A9QUY-if00-port0@57600
2018.10.27 12:17:04 1: SIGNAL_CUL/init: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_003A9QUY-if00-port0@57600
2018.10.27 12:17:04 1: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_003A9QUY-if00-port0 reappeared (SIGNAL_CUL)
2018.10.27 12:17:04 5: SIGNAL_CUL/write: adding to queue sendMsg P43#ACB7BD11888888#R6
2018.10.27 12:17:05 3: SIGNAL_CUL/init: disable receiver (XQ)
2018.10.27 12:17:05 5: SIGNAL_CUL SW: XQ
2018.10.27 12:17:05 5: SIGNAL_CUL/write: adding to queue sendMsg P43#ADB6BC11888888#R6
2018.10.27 12:17:06 3: SIGNAL_CUL/init: get version, retry = 0
2018.10.27 12:17:06 5: SIGNAL_CUL SW: V
2018.10.27 12:17:06 4: SIGNAL_CUL/msg READ: V 3.3.1-RC8 SIGNALduino cc1101 - compiled at Oct 4 2018 21:44:45
2018.10.27 12:17:06 5: SIGNAL_CUL/noMsg Parse: V 3.3.1-RC8 SIGNALduino cc1101 - compiled at Oct 4 2018 21:44:45
2018.10.27 12:17:06 5: SIGNAL_CUL/msg READ: regexp=V\s.*SIGNAL(duino|ESP).* cmd=version msg=V 3.3.1-RC8 SIGNALduino cc1101 - compiled at Oct 4 2018 21:44:45
2018.10.27 12:17:06 2: SIGNAL_CUL: initialized. v3.3.2
2018.10.27 12:17:06 5: SIGNAL_CUL SW: XE
2018.10.27 12:17:06 3: SIGNAL_CUL/init: enable receiver (XE)
2018.10.27 12:17:09 5: SIGNAL_CUL/write: adding to queue sendMsg P43#AEB5BF11888888#R6
2018.10.27 12:17:09 5: SIGNAL_CUL: sendmsg msg=P43#AEB5BF11888888#R6
2018.10.27 12:17:09 5: SIGNAL_CUL: sendmsg Preparing manchester protocol=43, repeats=0, clock=645 data=AEB5BF11888888
2018.10.27 12:17:09 5: AddSendQueue: SIGNAL_CUL: SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=645;D=AEB5BF11888888;F=10AB85550A; (1)
2018.10.27 12:17:09 4: SIGNAL_CUL/set: sending via SendMsg: SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=645;D=AEB5BF11888888;F=10AB85550A;
2018.10.27 12:17:09 5: SIGNAL_CUL SW: SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=645;D=AEB5BF11888888;F=10AB85550A;
2018.10.27 12:17:09 4: SIGNAL_CUL SendrawFromQueue: msg=SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=645;D=AEB5BF11888888;F=10AB85550A;
2018.10.27 12:17:11 4: SIGNAL_CUL/HandleWriteQueue: sendraw no answer (timeout)
2018.10.27 12:17:11 4: SIGNAL_CUL/HandleWriteQueue: nothing to send, stopping timer
2018.10.27 12:17:37 5: SIGNAL_CUL/write: adding to queue sendMsg P43#AF878D22BBBBBB#R6
2018.10.27 12:17:37 5: SIGNAL_CUL: sendmsg msg=P43#AF878D22BBBBBB#R6
2018.10.27 12:17:37 5: SIGNAL_CUL: sendmsg Preparing manchester protocol=43, repeats=0, clock=645 data=AF878D22BBBBBB
2018.10.27 12:17:37 5: AddSendQueue: SIGNAL_CUL: SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=645;D=AF878D22BBBBBB;F=10AB85550A; (1)
2018.10.27 12:17:37 4: SIGNAL_CUL/set: sending via SendMsg: SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=645;D=AF878D22BBBBBB;F=10AB85550A;
2018.10.27 12:17:37 5: SIGNAL_CUL SW: SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=645;D=AF878D22BBBBBB;F=10AB85550A;
2018.10.27 12:17:37 4: SIGNAL_CUL SendrawFromQueue: msg=SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=645;D=AF878D22BBBBBB;F=10AB85550A;
2018.10.27 12:17:37 1: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_003A9QUY-if00-port0 disconnected, waiting to reappear (SIGNAL_CUL)
2018.10.27 12:17:37 3: Setting SIGNAL_CUL serial parameters to 57600,8,N,1
2018.10.27 12:17:37 1: SIGNAL_CUL/define: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_003A9QUY-if00-port0@57600
2018.10.27 12:17:37 1: SIGNAL_CUL/init: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_003A9QUY-if00-port0@57600
2018.10.27 12:17:37 1: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_003A9QUY-if00-port0 reappeared (SIGNAL_CUL)
2018.10.27 12:17:38 4: SIGNAL_CUL/msg READ: 10B0715700SC;R=62560;P1=2640;D=101M;C=645;D2BBBBBB;F50A;
2018.10.27 12:17:38 5: SIGNAL_CUL/noMsg Parse: 10B0715700SC;R=62560;P1=2640;D=101M;C=645;D2BBBBBB;F50A;
2018.10.27 12:17:38 4: SIGNAL_CUL/msg READ: Received answer (10B0715700SC;R=62560;P1=2640;D=101M;C=645;D2BBBBBB;F50A;) for sendraw does not match ^S(R|C|M);
2018.10.27 12:17:39 3: SIGNAL_CUL/init: disable receiver (XQ)
2018.10.27 12:17:39 5: SIGNAL_CUL SW: XQ
2018.10.27 12:17:39 3: SIGNAL_CUL/init: get version, retry = 0
2018.10.27 12:17:39 5: SIGNAL_CUL SW: V
2018.10.27 12:17:39 4: SIGNAL_CUL/msg READ: V 3.3.1-RC8 SIGNALduino cc1101 - compiled at Oct 4 2018 21:44:45
2018.10.27 12:17:39 5: SIGNAL_CUL/noMsg Parse: V 3.3.1-RC8 SIGNALduino cc1101 - compiled at Oct 4 2018 21:44:45
2018.10.27 12:17:39 5: SIGNAL_CUL/msg READ: regexp=V\s.*SIGNAL(duino|ESP).* cmd=version msg=V 3.3.1-RC8 SIGNALduino cc1101 - compiled at Oct 4 2018 21:44:45
2018.10.27 12:17:39 2: SIGNAL_CUL: initialized. v3.3.2
2018.10.27 12:17:39 5: SIGNAL_CUL SW: XE
2018.10.27 12:17:39 3: SIGNAL_CUL/init: enable receiver (XE)
Anbei auch das list:
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_003A9QUY-if00-port0@57600
DMSG W51#E25055D721
DevState initialized
DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_003A9QUY-if00-port0@57600
FD 62
ITClock 250
LASTDMSG W51#E25055D721
MSGCNT 11
NAME SIGNAL_CUL
NR 749
PARTIAL
RAWMSG MS;P1=-1827;P2=615;P3=-4049;P4=-16004;P5=1040;P6=-991;P7=-7852;D=27232323212121232121232123212121212123212321232123232321232123232321212321212121232456565656;CP=2;SP=7;R=242;O;m=2;
RSSI -81
STATE opened
TIME 1540590227.02006
TYPE SIGNALduino
sendworking 0
unknownmessages
version V 3.3.1-RC8 SIGNALduino cc1101 - compiled at Oct 4 2018 21:44:45
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-10-26 20:05:34 ccconf freq:433.420MHz bWidth:325KHz rAmpl:42dB sens:4dB (DataRate:5603.79Baud)
2018-10-27 12:15:14 config MS=1;MU=1;MC=1;Mred=1
2018-10-27 12:21:48 ping OK
2018-10-27 12:14:35 raw done
2018-10-27 12:20:48 state opened
2018-10-27 12:20:48 version V 3.3.1-RC8 SIGNALduino cc1101 - compiled at Oct 4 2018 21:44:45
getcmd:
keepalive:
ok 1
retry 0
mcIdList:
10
11
12
18
43
47
52
57
58
msIdList:
0
1
13
14
15
17
2
22
23
25
3
3.1
32
33
35
38
4
41
51
55
6
68
7
72.1
muIdList:
13.1
16
20
21
24
26
27
28
29
30
31
36
37
39
40
44
44.1
45
46
48
49
5
50
56
59
60
61
62
64
65
66
67
69
70
71
72
75
8
9
Attributes:
devStateIcon opened:10px-kreis-gruen
flashCommand avrdude -c arduino -b [BAUDRATE] -P [PORT] -p atmega328p -vv -U flash:w:[HEXFILE] 2>[LOGFILE]
hardware nanoCC1101
verbose 5
Obwohl die Frequenz laut list auf freq:433.420MHz habe ich diese wieder umgesetzt auf: 433.920 MHz. Das Reading wurde seit gestern nicht mehr aktualisiert.
2018.10.27 12:27:59 3: SIGNAL_CUL: Setting FREQ2..0 (0D,0E,0F) to 10 b0 71 = 433.920 MHz
2018.10.27 12:27:59 5: AddSendQueue: SIGNAL_CUL: W0F10 (1)
2018.10.27 12:27:59 5: AddSendQueue: SIGNAL_CUL: W10b0 (2)
2018.10.27 12:27:59 5: AddSendQueue: SIGNAL_CUL: W1171 (3)
2018.10.27 12:27:59 5: AddSendQueue: SIGNAL_CUL: WS36 (4)
2018.10.27 12:27:59 5: AddSendQueue: SIGNAL_CUL: WS34 (5)
2018.10.27 12:27:59 5: SIGNAL_CUL SW: W0F10
2018.10.27 12:27:59 1: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_003A9QUY-if00-port0 disconnected, waiting to reappear (SIGNAL_CUL)
2018.10.27 12:28:00 3: Setting SIGNAL_CUL serial parameters to 57600,8,N,1
2018.10.27 12:28:00 1: SIGNAL_CUL/define: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_003A9QUY-if00-port0@57600
2018.10.27 12:28:00 1: SIGNAL_CUL/init: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_003A9QUY-if00-port0@57600
2018.10.27 12:28:00 1: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_003A9QUY-if00-port0 reappeared (SIGNAL_CUL)
2018.10.27 12:28:01 3: SIGNAL_CUL/init: disable receiver (XQ)
2018.10.27 12:28:01 5: SIGNAL_CUL SW: XQ
2018.10.27 12:28:02 3: SIGNAL_CUL/init: get version, retry = 0
2018.10.27 12:28:02 5: SIGNAL_CUL SW: V
2018.10.27 12:28:02 4: SIGNAL_CUL/msg READ: V 3.3.1-RC8 SIGNALduino cc1101 - compiled at Oct 4 2018 21:44:45
2018.10.27 12:28:02 5: SIGNAL_CUL/noMsg Parse: V 3.3.1-RC8 SIGNALduino cc1101 - compiled at Oct 4 2018 21:44:45
2018.10.27 12:28:02 5: SIGNAL_CUL/msg READ: regexp=V\s.*SIGNAL(duino|ESP).* cmd=version msg=V 3.3.1-RC8 SIGNALduino cc1101 - compiled at Oct 4 2018 21:44:45
2018.10.27 12:28:02 2: SIGNAL_CUL: initialized. v3.3.2
2018.10.27 12:28:02 5: SIGNAL_CUL SW: XE
2018.10.27 12:28:02 3: SIGNAL_CUL/init: enable receiver (XE)
Im obigen Logauszug sieht man auch, dass der disconnect erfolgt:
2018.10.27 12:27:59 1: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_003A9QUY-if00-port0 disconnected, waiting to reappear (SIGNAL_CUL)
Firmware habe ich jetzt wieder die aktuelle: V 3.3.1-RC8. Ich hatte gestern aber auch andere Version aus dem Git geflashed mit dem gleichen Ergebnis.
Ein weiteres Problem: Das Senden von Kommandos an IT Geräte klappt nicht bei allen Geräten. Der alte CUL schaltet sofort alle Geräte, der Signalduiono ist da sehr wählerisch.
Vielleicht hat von euch jemand eine Idee, was ich noch testen kann?
Grüße,
Dirk
Mit welchen Firmware Versionen hast du es getestet?
Mit welchen funktioniert es und mit welchen nicht?
Gruß Ralf
Hallo Ralf,
ich hab das Problem auch bei: https://github.com/RFD-FHEM/SIGNALDuino/releases/download/3.3.1-RC7/SIGNALDuino_nanocc1101.hex
sowie bei Test mit: https://github.com/RFD-FHEM/SIGNALDuino/releases/download/3.3.1-RC4/SIGNALDuino_nanocc1101.hex
Weitere habe ich bisher nicht ausprobiert.
Anbei noch mal ein Logauszug, wo ich gerade versucht habe das IT Gerät (Intertechno Funk Einbauschalter CMR-1000 ) zu schalten:
2018.10.27 14:42:02 3: SIGNAL_CUL IT_set: Dach.Decke.LED on
2018.10.27 14:42:02 5: SIGNAL_CUL IT_set: Type=SIGNALduino Protocol=V1
2018.10.27 14:42:02 4: SIGNAL_CUL IT_set: sendMsg=P3#is0F0F000F0FFF#R6
2018.10.27 14:42:02 5: SIGNAL_CUL/write: adding to queue sendMsg P3#is0F0F000F0FFF#R6
2018.10.27 14:42:02 5: SIGNAL_CUL: sendmsg msg=P3#is0F0F000F0FFF#R6
2018.10.27 14:42:02 5: SIGNAL_CUL: sendmsg IT V1 convertet tristate to bits=000100010000000100010101
2018.10.27 14:42:02 5: SIGNAL_CUL: sendmsg Preparing rawsend command for protocol=3, repeats=6, clock=250 bits=000100010000000100010101
2018.10.27 14:42:02 5: AddSendQueue: SIGNAL_CUL: SR;R=6;P0=250;P1=-7750;P2=750;P3=-250;P4=-750;D=01040404230404042304040404040404230404042304230423; (1)
2018.10.27 14:42:02 4: SIGNAL_CUL/set: sending via SendMsg: SR;R=6;P0=250;P1=-7750;P2=750;P3=-250;P4=-750;D=01040404230404042304040404040404230404042304230423;
2018.10.27 14:42:02 5: SIGNAL_CUL SW: SR;R=6;P0=250;P1=-7750;P2=750;P3=-250;P4=-750;D=01040404230404042304040404040404230404042304230423;
2018.10.27 14:42:02 4: SIGNAL_CUL SendrawFromQueue: msg=SR;R=6;P0=250;P1=-7750;P2=750;P3=-250;P4=-750;D=01040404230404042304040404040404230404042304230423;
2018.10.27 14:42:03 4: SIGNAL_CUL/msg READ: SR;R=6;P0=250;P1=-7750;P2=750;P3=-250;P4=-750;D=01040404230404042304040404040404230404042304230423;
2018.10.27 14:42:03 5: SIGNAL_CUL/noMsg Parse: SR;R=6;P0=250;P1=-7750;P2=750;P3=-250;P4=-750;D=01040404230404042304040404040404230404042304230423;
2018.10.27 14:42:03 5: SIGNAL_CUL/msg READ: regexp=^S(R|C|M); cmd=sendraw msg=SR;R=6;P0=250;P1=-7750;P2=750;P3=-250;P4=-750;D=01040404230404042304040404040404230404042304230423;
2018.10.27 14:42:03 4: SIGNAL_CUL/read sendraw answer: SR;R=6;P0=250;P1=-7750;P2=750;P3=-250;P4=-750;D=01040404230404042304040404040404230404042304230423;
2018.10.27 14:42:03 4: SIGNAL_CUL/HandleWriteQueue: nothing to send, stopping timer
Mir scheint eher, mein Problem liegt nicht an der Firmware....
Grüße,
Dirk
Mit den V 3.3.1-RC Firmware Versionen lässt sich nicht sicher sagen ob es ein Problem mit der Hardware ist. Dies sind Entwicklerversionen.
Es gibt anscheinend bestimmte Hardware mit den die V 3.3.1-RC Probleme hat. Dies könnte z.B. an Hardwareversionen des cc1101, Toleranzen oder einem nicht sauberen Hardwareaufbau liegen.
In die V 3.3.2 rc2 habe dafür einen Workaround eingebaut und auch die Senderoutinen überarbeitet. Dies ist zwar auch eine Entwicklerversion, dürfte aber einer stable Version schon recht nahe kommen.
set sduino flash https://raw.githubusercontent.com/Ralf9/SIGNALDuino/dev-r332_cc1101/firmware/SIGNALduino_nanoCC1101_332rc2.hex
Wenn es mit der V 3.3.2 rc2 auch nicht funktioniert, kannst Du es auch mal mit der 3.3.1-dev vom normalen fhem update probieren.
Dies ist eine Version von Anfang 2017.
Du kann diese flashen mit
set SIGNAL_CUL flash
Gruß Ralf
Hi,
da es ja ein Wemos Clone ist, würde ich auch dringend über das Netzteil nachdenken. Hast Du da mal etwas anderes verwendet? Welches setzt Du ein? Wie verhält sich die Spannung beim senden?
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Für mich sieht es nach einer nanocul Hardware aus
Zitatich hab das Problem auch bei: https://github.com/RFD-FHEM/SIGNALDuino/releases/download/3.3.1-RC7/SIGNALDuino_nanocc1101.hex
sowie bei Test mit: https://github.com/RFD-FHEM/SIGNALDuino/releases/download/3.3.1-RC4/SIGNALDuino_nanocc1101.hex
Gruß Ralf
Naja, eigentlich ist die Hardware ja von mir, aber hier gingen verschiedene Testaufbauten von mir in den letzten Tagen raus. Daher logisch, bei der Firmware ein nanocul (wahrscheinlich auf Boardplatine V3.1) mit SMD-cc1101.
Vielleicht wäre eine Bild hilfreich w/ genauem cc1101 Typ?
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Hi,
auch das Flashen der anderen Firmware hat keine Besserung gebracht. Der signalduino bekommt immer wieder sein disconnect.
version: V 3.3.2-rc2 SIGNALduino cc1101 - compiled at Jun 1 2018 23:56:2:56:22
2018.10.27 18:54:52 4: SIGNAL_CUL/KeepAlive not ok, retry = 1 -> get ping
2018.10.27 18:54:52 5: AddSendQueue: SIGNAL_CUL: P (1)
2018.10.27 18:54:52 5: SIGNAL_CUL SW: P
2018.10.27 18:54:52 1: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_003A9QUY-if00-port0 disconnected, waiting to reappear (SIGNAL_CUL)
2018.10.27 18:54:52 3: Setting SIGNAL_CUL serial parameters to 57600,8,N,1
2018.10.27 18:54:52 1: SIGNAL_CUL/define: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_003A9QUY-if00-port0@57600
2018.10.27 18:54:52 1: SIGNAL_CUL/init: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_003A9QUY-if00-port0@57600
2018.10.27 18:54:52 1: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_003A9QUY-if00-port0 reappeared (SIGNAL_CUL)
2018.10.27 18:54:54 3: SIGNAL_CUL/init: disable receiver (XQ)
2018.10.27 18:54:54 5: SIGNAL_CUL SW: XQ
2018.10.27 18:54:54 3: SIGNAL_CUL/init: get version, retry = 0
2018.10.27 18:54:54 5: SIGNAL_CUL SW: V
2018.10.27 18:54:54 4: SIGNAL_CUL/msg READ: V 3.3.2-rc2 SIGNALduino cc1101 - compiled at Jun 1 2018 23:56:22
2018.10.27 18:54:54 5: SIGNAL_CUL/noMsg Parse: V 3.3.2-rc2 SIGNALduino cc1101 - compiled at Jun 1 2018 23:56:22
2018.10.27 18:54:54 5: SIGNAL_CUL/msg READ: regexp=V\s.*SIGNAL(duino|ESP).* cmd=version msg=V 3.3.2-rc2 SIGNALduino cc1101 - compiled at Jun 1 2018 23:56:22
2018.10.27 18:54:54 2: SIGNAL_CUL: initialized. v3.3.2
2018.10.27 18:54:54 5: SIGNAL_CUL SW: XE
2018.10.27 18:54:54 3: SIGNAL_CUL/init: enable receiver (XE)
2018.10.27 18:54:56 4: SIGNAL_CUL/msg READ: M▒;▒̄;▒▒▒;▒ܞ;▒▒▒;▒▒▒;D!!!#CSSScccScSScSccSccScScSccccSSc ;C3;REE;e;
Ich habe jetzt auch mal den MapleCUL abgezogen (wegen Stromverbrauchstest). Auch hier keine Besserung.
Ich verwende das Original 2,5A Netzteil für meinen Rpi.
2018.10.27 19:09:38 4: SIGNAL_CUL/msg READ: ▒;▒▒▒;▒▒;▒▒▒;▒▒▒QQQaaaQaQaQaQaaaaQaaaQ;CO;m0;
2018.10.27 19:09:38 5: SIGNAL_CUL/noMsg Parse: ▒;▒▒▒;▒▒;▒▒▒;▒▒▒QQQaaaQaQaQaQaaaaQaaaQ;CO;m0;
2018.10.27 19:09:38 4: SIGNAL_CUL/msg READ: ▒▒;▒̃;▒▒;▒▒▒;D;C1;S1;
2018.10.27 19:09:38 5: SIGNAL_CUL/noMsg Parse: ▒▒;▒̃;▒▒;▒▒▒;D;C1;S1;
2018.10.27 19:09:39 4: SIGNAL_CUL/msg READ: ▒;▒▒▒;▒;▒▒▒;▒▒;;O;m2;
2018.10.27 19:09:39 5: SIGNAL_CUL/noMsg Parse: ▒;▒▒▒;▒;▒▒▒;▒▒;;O;m2;
2018.10.27 19:09:39 1: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_003A9QUY-if00-port0 disconnected, waiting to reappear (SIGNAL_CUL)
2018.10.27 19:09:39 3: Setting SIGNAL_CUL serial parameters to 57600,8,N,1
2018.10.27 19:09:39 1: SIGNAL_CUL/define: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_003A9QUY-if00-port0@57600
2018.10.27 19:09:39 1: SIGNAL_CUL/init: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_003A9QUY-if00-port0@57600
2018.10.27 19:09:39 1: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_003A9QUY-if00-port0 reappeared (SIGNAL_CUL)
2018.10.27 19:09:41 3: SIGNAL_CUL/init: disable receiver (XQ)
2018.10.27 19:09:41 5: SIGNAL_CUL SW: XQ
2018.10.27 19:09:41 3: SIGNAL_CUL/init: get version, retry = 0
2018.10.27 19:09:41 5: SIGNAL_CUL SW: V
2018.10.27 19:09:41 4: SIGNAL_CUL/msg READ: V 3.3.2-rc2 SIGNALduino cc1101 - compiled at Jun 1 2018 23:56:22
2018.10.27 19:09:41 5: SIGNAL_CUL/noMsg Parse: V 3.3.2-rc2 SIGNALduino cc1101 - compiled at Jun 1 2018 23:56:22
2018.10.27 19:09:41 5: SIGNAL_CUL/msg READ: regexp=V\s.*SIGNAL(duino|ESP).* cmd=version msg=V 3.3.2-rc2 SIGNALduino cc1101 - compiled at Jun 1 2018 23:56:22
2018.10.27 19:09:41 2: SIGNAL_CUL: initialized. v3.3.2
2018.10.27 19:09:41 5: SIGNAL_CUL SW: XE
2018.10.27 19:09:41 3: SIGNAL_CUL/init: enable receiver (XE)
Die Firmware, die von fhem aus verteilt wird liegt auf meinem System nicht im Filesystem. MIt der 3.3.1 RC4 hatte ich aber bereits schon mal getestet.
Was hat es mit dem Eintrag: 2018.10.27 18:54:52 4: SIGNAL_CUL/KeepAlive not ok, retry = 1 -> get ping auf sich?
@Arnd: Was soll ich genau ablichten vom Chip?
Danke vorerst für eure Mühe!
Dirk
wenn es mit der V 3.3.2-rc2 auch nicht funktioniert sieht es eher nach einem Hardware oder Stromversorgungs Problem aus.
Zitat
SIGNAL_CUL/KeepAlive not ok, retry = 1 -> get ping
Wenn innerhalb von 1 Minute nichts empfangen wird, dann sendet das fhem signalduino Modul ein Ping, wenn als Antwort nichts empfangen wird, wird ein weiterer Ping gesendet. Nach 3 Ping wird ein Reset versucht.
Ein Bild vom cc11001 hilft hier nicht weiter.
Gruß Ralf
Wie lang ist das USB Kabel am SIGNAL_CUL? Ich habe einen nano der nur mit einem kurzen (<50cm) USB Kabel funktioniert.
4: SIGNAL_CUL/msg READ: M▒;▒̄;▒▒▒;▒ܞ;▒▒▒;▒▒▒;D!!!#CSSScccScSScSccSccScScSccccSSc ;C3;REE;e;
Das hier ist auch seltsam, diese Nachricht wird nicht als komprimierte Nachricht erkannt.
Es müsste ungefähr so aussehen
4: sduino/msg READredu: MU;P0=...
Du kannst mal versuchen die Komprimierung abzuschalten:
get SIGNAL_CUL raw CDR
Gruß Ralf
Hallo Ralf,
ich glaube der Tipp mit dem USB Kabel scheint zu funktionieren.
Im folgenden Log Auszug habe ich den Singalduino mit dem USB Adapter von Arnd direkt am USB POrt vom Rpi angeschlossen.
Ich bekomme keine Disconnects mehr, auch nicht bei Abfrage von version oder cccf.
2018.10.28 17:31:48 3: Opening SIGNAL_CUL device /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_003A9QUY-if00-port0
2018.10.28 17:31:48 3: Setting SIGNAL_CUL serial parameters to 57600,8,N,1
2018.10.28 17:31:48 1: SIGNAL_CUL/define: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_003A9QUY-if00-port0@57600
2018.10.28 17:31:48 1: SIGNAL_CUL/init: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_003A9QUY-if00-port0@57600
2018.10.28 17:31:48 3: SIGNAL_CUL device opened
2018.10.28 17:31:49 3: SIGNAL_CUL sduinoIdList: whitelistIds=
2018.10.28 17:31:49 3: SIGNAL_CUL sduinoIdList: blacklistIds=
2018.10.28 17:31:49 3: SIGNAL_CUL sduinoIdList: development=
2018.10.28 17:31:49 3: SIGNAL_CUL: ID=73 skiped (developId=y)
2018.10.28 17:31:49 3: SIGNAL_CUL: ID=63 skiped (developId=y)
2018.10.28 17:31:49 3: SIGNAL_CUL: ID=p76 skiped (developId=p)
2018.10.28 17:31:49 3: SIGNAL_CUL: ID=74 skiped (developId=y)
2018.10.28 17:31:49 3: SIGNAL_CUL: ID=p76.1 skiped (developId=p)
2018.10.28 17:31:49 3: SIGNAL_CUL: IDlist MS 0 1 13 14 15 17 2 22 23 25 3 3.1 32 33 35 38 4 41 51 55 6 68 7 72.1
2018.10.28 17:31:49 3: SIGNAL_CUL: IDlist MU 13.1 16 20 21 24 26 27 28 29 30 31 36 37 39 40 44 44.1 45 46 48 49 5 50 56 59 60 61 62 64 65 66 67 69 70 71 72 75 8 9
2018.10.28 17:31:49 3: SIGNAL_CUL: IDlist MC 10 11 12 18 43 47 52 57 58
2018.10.28 17:31:50 3: SIGNAL_CUL/init: disable receiver (XQ)
2018.10.28 17:31:50 3: SIGNAL_CUL/init: get version, retry = 0
2018.10.28 17:31:50 2: SIGNAL_CUL: initialized. v3.3.2
2018.10.28 17:31:50 3: SIGNAL_CUL/init: enable receiver (XE)
2018.10.28 17:32:00 3: SIGNAL_CUL: Setting patable 433 7_dBm xC8
2018.10.28 17:32:16 3: SIGNAL_CUL: setting Verbose to: 5
2018.10.28 17:32:50 4: SIGNAL_CUL/KeepAlive not ok, retry = 1 -> get ping
2018.10.28 17:32:50 5: AddSendQueue: SIGNAL_CUL: P (1)
2018.10.28 17:32:50 5: SIGNAL_CUL SW: P
2018.10.28 17:32:50 4: SIGNAL_CUL/msg READ: OK
2018.10.28 17:32:50 5: SIGNAL_CUL/noMsg Parse: OK
2018.10.28 17:32:50 5: SIGNAL_CUL/msg READ: regexp=^OK$ cmd=ping msg=OK
2018.10.28 17:32:51 4: SIGNAL_CUL/HandleWriteQueue: nothing to send, stopping timer
2018.10.28 17:33:08 5: SIGNAL_CUL: command for gets: C0DnF
2018.10.28 17:33:08 5: AddSendQueue: SIGNAL_CUL: C0DnF (1)
2018.10.28 17:33:08 5: SIGNAL_CUL SW: C0DnF
2018.10.28 17:33:08 4: SIGNAL_CUL/msg READ: C0Dn11=10B07157C43023B900070018146C070090
2018.10.28 17:33:08 5: SIGNAL_CUL/noMsg Parse: C0Dn11=10B07157C43023B900070018146C070090
2018.10.28 17:33:08 5: SIGNAL_CUL/msg READ: regexp=C0Dn11.* cmd=ccconf msg=C0Dn11=10B07157C43023B900070018146C070090
2018.10.28 17:33:08 4: SIGNAL_CUL/HandleWriteQueue: nothing to send, stopping timer
2018.10.28 17:33:23 5: SIGNAL_CUL: command for gets: V
2018.10.28 17:33:23 5: AddSendQueue: SIGNAL_CUL: V (1)
2018.10.28 17:33:23 5: SIGNAL_CUL SW: V
2018.10.28 17:33:23 4: SIGNAL_CUL/msg READ: V 3.3.1-RC8 SIGNALduino cc1101 - compiled at Oct 4 2018 21:44:45
2018.10.28 17:33:23 5: SIGNAL_CUL/noMsg Parse: V 3.3.1-RC8 SIGNALduino cc1101 - compiled at Oct 4 2018 21:44:45
2018.10.28 17:33:23 5: SIGNAL_CUL/msg READ: regexp=V\s.*SIGNAL(duino|ESP).* cmd=version msg=V 3.3.1-RC8 SIGNALduino cc1101 - compiled at Oct 4 2018 21:44:45
2018.10.28 17:33:23 4: SIGNAL_CUL/HandleWriteQueue: nothing to send, stopping timer
2018.10.28 17:33:26 5: SIGNAL_CUL: command for gets: t
2018.10.28 17:33:26 5: AddSendQueue: SIGNAL_CUL: t (1)
2018.10.28 17:33:26 5: SIGNAL_CUL SW: t
2018.10.28 17:33:26 4: SIGNAL_CUL/msg READ: 96
2018.10.28 17:33:26 5: SIGNAL_CUL/noMsg Parse: 96
2018.10.28 17:33:26 5: SIGNAL_CUL/msg READ: regexp=^[0-9]+ cmd=uptime msg=96
2018.10.28 17:33:27 4: SIGNAL_CUL/HandleWriteQueue: nothing to send, stopping timer
2018.10.28 17:33:30 5: SIGNAL_CUL: command for gets: CG
2018.10.28 17:33:30 5: AddSendQueue: SIGNAL_CUL: CG (1)
2018.10.28 17:33:30 5: SIGNAL_CUL SW: CG
2018.10.28 17:33:30 4: SIGNAL_CUL/msg READ: MS=1;MU=1;MC=1;Mred=1
2018.10.28 17:33:30 5: SIGNAL_CUL/noMsg Parse: MS=1;MU=1;MC=1;Mred=1
2018.10.28 17:33:30 5: SIGNAL_CUL/msg READ: regexp=^MS.*MU.*MC.* cmd=config msg=MS=1;MU=1;MC=1;Mred=1
2018.10.28 17:33:30 4: SIGNAL_CUL/HandleWriteQueue: nothing to send, stopping timer
2018.10.28 17:33:49 5: SIGNAL_CUL/write: adding to queue sendMsg P3#is0F0F000F0FFF#R6
2018.10.28 17:33:49 5: SIGNAL_CUL: sendmsg msg=P3#is0F0F000F0FFF#R6
2018.10.28 17:33:49 5: SIGNAL_CUL: sendmsg IT V1 convertet tristate to bits=000100010000000100010101
2018.10.28 17:33:49 5: SIGNAL_CUL: sendmsg Preparing rawsend command for protocol=3, repeats=6, clock=250 bits=000100010000000100010101
2018.10.28 17:33:49 5: AddSendQueue: SIGNAL_CUL: SR;R=6;P0=250;P1=-7750;P2=750;P3=-250;P4=-750;D=01040404230404042304040404040404230404042304230423; (1)
2018.10.28 17:33:49 4: SIGNAL_CUL/set: sending via SendMsg: SR;R=6;P0=250;P1=-7750;P2=750;P3=-250;P4=-750;D=01040404230404042304040404040404230404042304230423;
2018.10.28 17:33:49 5: SIGNAL_CUL SW: SR;R=6;P0=250;P1=-7750;P2=750;P3=-250;P4=-750;D=01040404230404042304040404040404230404042304230423;
2018.10.28 17:33:49 4: SIGNAL_CUL SendrawFromQueue: msg=SR;R=6;P0=250;P1=-7750;P2=750;P3=-250;P4=-750;D=01040404230404042304040404040404230404042304230423;
2018.10.28 17:33:49 4: SIGNAL_CUL/msg READ: SR;R=6;P0=250;P1=-7750;P2=750;P3=-250;P4=-750;D=01040404230404042304040404040404230404042304230423;
2018.10.28 17:33:49 5: SIGNAL_CUL/noMsg Parse: SR;R=6;P0=250;P1=-7750;P2=750;P3=-250;P4=-750;D=01040404230404042304040404040404230404042304230423;
2018.10.28 17:33:49 5: SIGNAL_CUL/msg READ: regexp=^S(R|C|M); cmd=sendraw msg=SR;R=6;P0=250;P1=-7750;P2=750;P3=-250;P4=-750;D=01040404230404042304040404040404230404042304230423;
2018.10.28 17:33:49 4: SIGNAL_CUL/read sendraw answer: SR;R=6;P0=250;P1=-7750;P2=750;P3=-250;P4=-750;D=01040404230404042304040404040404230404042304230423;
2018.10.28 17:33:49 4: SIGNAL_CUL/HandleWriteQueue: nothing to send, stopping timer
2018.10.28 17:33:50 4: SIGNAL_CUL/keepalive ok, retry = 0
Hier habe ich ihn wieder per 15cm USB Kabel angeschlossen. Ergebnis sind disconnects
2018.10.28 17:41:25 4: SIGNAL_CUL/msg READ: Received answer ([LaCrosseITPlusReader.10.1q (RFM69 f:868300 t:30~3)]) for version does not match V\s.*SIGNAL(duino|ESP).*
2018.10.28 17:41:34 4: SIGNAL_CUL/msg READ: OK 9 106
2018.10.28 17:41:34 5: SIGNAL_CUL/noMsg Parse: OK 9 106
2018.10.28 17:41:34 4: SIGNAL_CUL/msg READ: Received answer (OK 9 106) for version does not match V\s.*SIGNAL(duino|ESP).*
2018.10.28 17:41:35 4: SIGNAL_CUL/msg READ: OK 9 42 129 4 191 46
2018.10.28 17:41:35 5: SIGNAL_CUL/noMsg Parse: OK 9 42 129 4 191 46
2018.10.28 17:41:35 4: SIGNAL_CUL/msg READ: Received answer (OK 9 42 129 4 191 46) for version does not match V\s.*SIGNAL(duino|ESP).*
2018.10.28 17:41:39 3: SIGNAL_CUL/init: get version, retry = 2
2018.10.28 17:41:39 5: SIGNAL_CUL SW: V
2018.10.28 17:41:39 4: SIGNAL_CUL/msg READ:
2018.10.28 17:41:39 4: SIGNAL_CUL/msg READ: [LaCrosseITPlusReader.10.1q (RFM69 f:868300 t:30~3)]
2018.10.28 17:41:39 5: SIGNAL_CUL/noMsg Parse: [LaCrosseITPlusReader.10.1q (RFM69 f:868300 t:30~3)]
2018.10.28 17:41:39 4: SIGNAL_CUL/msg READ: Received answer ([LaCrosseITPlusReader.10.1q (RFM69 f:868300 t:30~3)]) for version does not match V\s.*SIGNAL(duino|ESP).*
2018.10.28 17:41:39 4: SIGNAL_CUL/msg READ: 9 42 1246
2018.10.28 17:41:39 5: SIGNAL_CUL/noMsg Parse: 9 42 1246
2018.10.28 17:41:39 4: SIGNAL_CUL/msg READ: Received answer ( 9 42 1246) for version does not match V\s.*SIGNAL(duino|ESP).*
2018.10.28 17:41:40 1: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AI04NS4X-if00-port0 disconnected, waiting to reappear (SIGNAL_CUL)
2018.10.28 17:41:40 3: Setting SIGNAL_CUL serial parameters to 57600,8,N,1
2018.10.28 17:41:40 1: SIGNAL_CUL/define: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AI04NS4X-if00-port0@57600
2018.10.28 17:41:40 1: SIGNAL_CUL/init: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AI04NS4X-if00-port0@57600
2018.10.28 17:41:40 1: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AI04NS4X-if00-port0 reappeared (SIGNAL_CUL)
2018.10.28 17:41:41 1: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AI04NS4X-if00-port0 disconnected, waiting to reappear (SIGNAL_CUL)
2018.10.28 17:41:41 3: Setting SIGNAL_CUL serial parameters to 57600,8,N,1
2018.10.28 17:41:41 1: SIGNAL_CUL/define: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AI04NS4X-if00-port0@57600
2018.10.28 17:41:41 1: SIGNAL_CUL/init: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AI04NS4X-if00-port0@57600
2018.10.28 17:41:41 1: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AI04NS4X-if00-port0 reappeared (SIGNAL_CUL)
2018.10.28 17:41:41 4: SIGNAL_CUL/msg READ: OK 9 39 44
2018.10.28 17:41:41 5: SIGNAL_CUL/noMsg Parse: OK 9 39 44
2018.10.28 17:41:41 4: SIGNAL_CUL/msg READ: Received answer (OK 9 39 44) for version does not match V\s.*SIGNAL(duino|ESP).
Was allerdings mit dem Anschluss per USB Adpater auch nicht funktionert hat, war das Schalten der IT Geräte. Wechsel ich das IODev auf den MapleCUL, klappt es sofort.
Ich versuche das aber noch mal mit einer anderen Firmware.
Ich werde dazu vermutlich erst am kommenden Wochenenden kommen.
Schönen Restsonntag und schon mal Danke!
Dirk
@Devender
Hast du einen JeeLink am System und aber dem Signalduino den richtigen Port zugewiesen ? In der letten Zeile sendest du was für den SignalDuino und JeeLink kann es nicht verstehen ?!
Du müstest 2 Devices anlegen:
SignalDuino:
defmod SIG868 SIGNALduino /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_003A9QUY-if00-port0@57600
JeeLink:
defmod J1 JeeLink /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AI04NS4X-if00-port0@57600
2018.10.28 17:41:35 4: SIGNAL_CUL/msg READ: Received answer (OK 9 42 129 4 191 46) for version does not match V\s.*SIGNAL(duino|ESP).*
2018.10.28 17:41:39 3: SIGNAL_CUL/init: get version, retry = 2
2018.10.28 17:41:39 5: SIGNAL_CUL SW: V
2018.10.28 17:41:39 4: SIGNAL_CUL/msg READ:
2018.10.28 17:41:39 4: SIGNAL_CUL/msg READ: [LaCrosseITPlusReader.10.1q (RFM69 f:868300 t:30~3)]
2018.10.28 17:41:39 5: SIGNAL_CUL/noMsg Parse: [LaCrosseITPlusReader.10.1q (RFM69 f:868300 t:30~3)]
2018.10.28 17:41:39 4: SIGNAL_CUL/msg READ: Received answer ([LaCrosseITPlusReader.10.1q (RFM69 f:868300 t:30~3)]) for version does not match V\s.*SIGNAL(duino|ESP).*
pejonp
Habe gerade die Version 3.3.2-rc2 auf meinen SIGNALDuino geflasht. Der Hideki-Empfang hat sich erheblich verbessert. Vielen Dank an Ralf für die super Arbeit!
Zitat von: Invers am 08 Januar 2018, 11:07:07
Wenn ich mit dem Befehl
get sduino raw CDL
die LED ausschalten möchte, bleibt diese leider an.
Mit der neuen Version V 3.3.2.1-rc5 wird nun auch beim Senden die message LED ausgeschaltet
https://forum.fhem.de/index.php/topic,82379.msg840645.html#msg840645
Gruß Ralf
Es gibt eine neue Version V 3.3.2.1-rc6
https://forum.fhem.de/index.php/topic,82379.msg840645.html#msg840645
Gruß Ralf
Hallo Ralf9,
ist die Firmware V 3.3.2.1-rc6 auch für ein Signalduino von der Firma In-Circuit mit einem Raduino Funkmodul geeignet?
Danke!
Gruß,
Datenleck
Was ist ein Signalduino von der Firma In-Circuit? ::)
Von dem Radino gibt es mehrere Varianten, es ist nur die mit einem ATmega32U4 geeignet.
Es gibt dafür aber noch keine fertige firmware, die müsste ich bei Bedarf aber erst noch Kompielieren
Gruß Ralf
dieser müsste geeignet sein
https://shop.in-circuit.de/product_info.php?products_id=253
Hallo Ralf,
danke für die schnelle Antwort.
Ja, genau diesen Stick habe ich.
Könntest du mir den neuesten RC für diesen Stick zur Verfügung stellen?
Gruß,
Datenleck
set sduino flash https://raw.githubusercontent.com/Ralf9/SIGNALDuino/dev-r332_cc1101/firmware/SIGNALduino_radinoCC1101_3321rc6.hex
Ist aber noch ungetestet, da ich keinen radiino habe.
Der ATmega32U4 hat mehr RAM aber weniger verfügbarer flash
Reicht gerade noch:
Der Sketch verwendet 28446 Bytes (99%) des Programmspeicherplatzes. Das Maximum sind 28672 Bytes.
Gruß Ralf
Hallo nochmal,
hab jetzt eben neu geflasht. Das Logfile sieht wie folgt aus:
2018.12.21 16:58:49 3: url https://raw.githubusercontent.com/Ralf9/SIGNALDuino/dev-r332_cc1101/firmware/SIGNALduino_radinoCC1101_3321rc6.hex returned: 80032 bytes Data
2018.12.21 16:58:49 3: Signalduino: Downloaded SIGNALduino_radinoCC1101_3321rc6.hex firmware from raw.githubusercontent.com
2018.12.21 16:58:49 3: Signalduino: filename FHEM/firmware/SIGNALduino_radinoCC1101_3321rc6.hex provided, trying to flash
2018.12.21 16:58:49 3: SIGNALduino Signalduino: flashCommand is manual defined! avrdude -c arduino -b [BAUDRATE] -P [PORT] -p atmega328p -vv -U flash:w:[HEXFILE] 2>[LOGFILE]
2018.12.21 16:59:41 3: Opening Signalduino device /dev/ttyACM0
2018.12.21 16:59:41 3: Setting Signalduino serial parameters to 57600,8,N,1
2018.12.21 16:59:41 1: Signalduino/define: /dev/ttyACM0
2018.12.21 16:59:41 1: Signalduino/init: /dev/ttyACM0
2018.12.21 16:59:41 3: Signalduino device opened
2018.12.21 16:59:41 3: Signalduino: Firmware update was succesfull
Wenn ich mir jetzt aber die Eigenschaften von meinem Signalduino anschaue, sehe ich bei "Version" jedoch immer noch die "3.3.1-dev".
Ist beim Flashen irgendwas schiefgegangen?
Internals:
Clients :IT:CUL_TCM97001:SD_RSL:OREGON:CUL_TX:SD_AS:Hideki:SD_WS07:SD_WS09: :SD_WS:RFXX10REC:Dooya:SOMFY:SD_BELL:SD_UT:SD_WS_Maverick:FLAMINGO:CUL_WS:Revolt: :FS10:CUL_FHTTK:Siro:FHT:FS20:CUL_EM:Fernotron:SIGNALduino_un:
DEF /dev/ttyACM0
DMSG YsA2E8EBCE4FEBAA
DevState initialized
DeviceName /dev/ttyACM0@57600
FD 11
LASTDMSG YsA2E8EBCE4FEBAA
MSGCNT 1
NAME Signalduino
NR 41
PARTIAL
RAWMSG MC;LL=-1277;LH=1289;SL=-637;SH=642;D=A2E8EBCE4FEBAA;C=640;L=55;R=49;
RSSI -49.5
STATE opened
TIME 1545408323
TYPE SIGNALduino
sendworking 0
version V 3.3.1-dev SIGNALduino cc1101 (433Mhz )- compiled at Mar 10 2017 23:27:29
versionmodul v3.3.3-dev_24.11.
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 ^P(?:29|30|34|69|81|83|86)#.*
18:FLAMINGO ^P13\.?1?#[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
25:CUL_EM ^E0.................
26:Fernotron ^P82#.*
27:SD_BELL ^P(?:14|15|32|41|42|57|79)#.*
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-12-03 21:48:15 ccconf freq:433.420MHz bWidth:464KHz rAmpl:42dB sens:16dB (DataRate:5603.79Baud)
2018-12-01 18:15:35 ccpatable C3E = 00 C0 00 00 00 00 00 00 => 10_dBm
2018-09-22 15:45:33 ccreg C3E = 00 C0 00 00 00 00 00 00
2018-12-01 18:17:58 cmds V R t X F S P C r W x e
2018-12-01 18:17:44 config MS=1;MU=1;MC=1
2018-12-21 17:03:53 ping OK
2018-12-21 17:02:53 state opened
2018-12-21 17:02:53 version V 3.3.1-dev SIGNALduino cc1101 (433Mhz )- compiled at Mar 10 2017 23:27:29
getcmd:
keepalive:
ok 0
retry 0
mcIdList:
43
msIdList:
muIdList:
Attributes:
flashCommand avrdude -c arduino -b [BAUDRATE] -P [PORT] -p atmega328p -vv -U flash:w:[HEXFILE] 2>[LOGFILE]
hardware radinoCC1101
whitelist_IDs 43
hast Du vor dem flashen den Bootloader Modus aktiviert?
ZitatTo reprogramm the SIGNALDuino Stick it has to be set to bootloader mode by pressing the reset button twice. (bootloader mode is indicated by fading status LED)
versionmodul v3.3.3-dev_24.11Evtl ist auch die dev-r33 zu alt
die aktuelle Version ist
versionmodul "v3.3.3-dev_17.12."
Oben links gibt es das "Information menu" dort kann mit " Last Flashlog" das flashlog angeschaut werden.
Gruß Ralf
Hat das flashen des Signalduino von der Firma In-Circuit inzwischen funktioniert?
Es ist dafür eine einigermaßen aktuelles dev-r33 fhem Modul notwendig.
Es kann sein, daß das flashen vom radinoCC1101 nur funktioniert, wenn zuvor das Attribut flashCommand gelöscht wurde.
Gruß Ralf
Hallo Ralf,
sorry für die späte Antwort, ich war über die Feiertage verreist und konnte es daher erst jetzt nochmal ausprobieren.
Das Flashen war sehr kompliziert und hat aus fhem heraus nicht funktioniert, da ich nie den richtigen Zeitpunkt erwischt habe um die Reset-Taste am Signalduino zwei Mal für den Flash-Modus zu drücken.
Ich habe dann den Signalduino direkt am PC erfolgreich geflasht.
Leider empfängt fhem auch nach dem Flashen der neuen Firmware nicht zuverlässig die Tastendrücke meiner Somfy Fernbedienungen.
Ich möchte derzeit den Signalduino ausschließlich mit dem Somfy Protokoll betreiben.
Gibt es eventuell die Möglichkeit die Zuverlässigkeit des Somfy Protokolls zu erhöhen, indem man nicht benötigte Protokolle komplett aus der Firmware entfernt? Ich habe bereits die whitelist_ID 43 gesetzt, aber hat scheinbar auch keinen Einfluss.
Welche Einstellungen wären für Somfy optimal?
Derzeit ist der Stick so konfiguriert:
ccconf: freq:433.420MHz bWidth:464KHz rAmpl:42dB sens:16dB (DataRate:5603.79Baud)
Gruß,
datenleck
Daß Somfy Fernbedienungen nicht sauber empfangen werden, kann mehrere Ursachen haben.
z.B. zu schwaches Empfangssignal oder Störungen in der Nähe des Signalduinos.
Du kannst auch mal ein sens von 4 oder 8 versuchen.
Interessant wären MU-Nachrichten, dazu musst Du den MS- und MC-Decoder deakivieren.
Bitte schau mal hier:
https://forum.fhem.de/index.php/topic,53319.msg762696.html#msg762696
Gruß Ralf
Ein zu schwaches Signal kann ich ausschließen, da ich eine fette Antenne an dem Signalduino habe und ich nur wenige Meter daneben stehe.
Im Event Monitor kann ich sehen, dass ca. jeder 10 Tastendruck zwar empfangen aber nicht richtig dekodiert wird.
Kann ich eigentlich irgendwo den Unterschied zwischen MU-, MS- und MC-Nachrichten nachlesen? Ich bin noch ziemlich neu in fhem.
Ich kann das leider erst in den nächsten Tagen ausprobieren, da ich wieder unterwegs bin.
Wenn die Fernbedienung zu dicht am sduino ist kann der Empfänger auch übersteuern
ZitatKann ich eigentlich irgendwo den Unterschied zwischen MU-, MS- und MC-Nachrichten nachlesen?
hier z.B.
https://wiki.fhem.de/wiki/SIGNALduino#Das_Logfile
Evtl kann ich was erkennen, wenn ich mir die von der Fernbedienung empfangenen MU-Nachrichten anschaue.
Du kannst diese auch nach "10_SOMFY.pm - Somfy RTS (und kompatible)" posten oder dafür ein eigenes Thema aufmachen.
Gruß Ralf
Es gibt eine neue Version V 3.3.2.1-rc8
Es wird in fhem die Entwicklerversion dev-r33 benötigt.
- Es werden nun auch die sehr langen MC-Nachrichten der neuen Oregon V3 Sensoren unterstützt.
- der Windmesser W132 von der Wetterstation Ventus W155 wird nun auch sauber empfangen
- Optimierungen damit weniger RAM belegt wird.
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
Gruß Ralf
Nachtrag:
Ich habe den ersten Beitrag überarbeitet, da steht jetzt alles drin.
Liest hier jemand mit der eine der folgenden Fernbedienungen oder Sensoren hat?
ID 74 - FS20
ID 48 - Joker Dostmann TFA 30.3055.01
ID 85 - Funk Wetterstation TFA 35.1140.01 mit Temperatur-/Feuchte- und Windsensor TFA 30.3222.02
Normalerweise kann der Datenteil einer MU-Nachricht maximal 254 Werte enthalten, der Rest wird abgeschnitten, dies ist an einem O am Ende erkennbar.
Bei FS20 und Joker Dostmann TFA 30.3055.01 ist dadurch die dritte Nachricht nur zur Hälfte in der MU-Nachricht enthalten.
Bei der ID 85 ist dadurch in der MU-Nachricht nur eine Nachricht enthalten.
Mich interessiert wie diese MU-Nachrichten komplett mit allen Wiederholungen aussehen.
Mit der V 3.3.2.1-rc8 kann die Ausgabe der sehr langen MU-Nachrichten aktiviert werden, dies funktioniert z.Zt. bei der offiziellen Entwicklerversion dev-r33 nur bei unkomprimierten Nachrichten (Mred=0).
get sduino raw CEO
get sduino raw CDR
Ein get config ergibt dann folgendes:
config: MS=1;MU=1;MC=1;Mred=0;MuNoOverflow=1;....
Beim nano funktioniert es normalerweise auch mit unkomprimierten Nachrichten.
Beim radino und 8 MHz promini kann es bei unkomprimierten Nachrichten zu einem Überlauf des FIFO kommen, dies ist erkennbar, wenn MF=140 empfangen wird.
Gruß Ralf
Hallo,
Ich habe den FS20 Wandschalter gedrückt und es kam was an:
2019.01.16 21:55:48 4 : sduino868/msg READredu: MU;P0=364;P1=-428;P2=559;P3=-631;P4=-7460;CP=0;D=010101010101010101010101012301012301230101010101230101230123230101010101010101232301010123010123010123010101232301012304;e;
2019.01.16 21:55:48 4 : sduino868/msg READredu: MU;P0=-424;P1=560;P3=366;P4=-629;CP=3;D=0103030303030303030303030143030143014303030303014303014301414303030303030303014143030301430301430301430303014143030143;e;
Es ist ein Nano mit normalem Empfänger.
Horst
Ich habe eigentlich sowas erwartet (alle 3 Nachrichten in einer MU-Nachricht)
MU;P0=-7460;P1=-92;P2=398;P3=-417;P5=596;P6=-592;CP=2;D=123232323232323232323232356232323565623232323235623235623232323232323232323232323232323562323232356235656562356562356202323232323232323232323235623232356562323232323562323562323232323232323232323232323232356232323235623565656235656235620232323232323232323232323562323235656232323232356232356232323232323232323232323232323235623232323562356565623565623562;Zitat2019.01.16 21:55:48 4 : sduino868/msg READredu:
Bei Dir ist die komprimierung noch eingeschaltet (Mred=1), die muss ausgeschaltet sein:
config: ...;Mred=0;MuNoOverflow=1;...Kann es evtl sein daß der FS20 Wandschalter jede Wiederholung einzeln sendet?
Das kann ich jetzt auch. Und da CUL und Sduino868 beide die Togglebefehle hören weiss ich jetzt auch, warum die Lampe nur kurz angeht.
Teil eins: alle Meldungen des ersten drücken
Teil zwei: jeweils erste Meldung der weiteren Tastendrücke.
2019-01-17 00:35:28 FS20 Schalter4OL toggle
2019.01.17 00:35:28 4 : sduino868/msg READ: MU;P0=-96;P1=96;P2=-428;P3=364;P4=560;P5=-629;P6=-7908;CP=3;D=0123232323232323232323232324532324532453232323232453232453245453232323232323232454532323245323245323245323232454532324536;e;
2019.01.17 00:35:28 4 : sduino868/msg READ: MU;P0=-631;P1=364;P2=-427;P3=559;P4=-7520;CP=1;D=01212121212121212121212123012123012301212121212301212301230301212121212121212303012121230121230121230121212303012123014;e;
2019.01.17 00:35:29 4 : sduino868/msg READ: MU;P0=-629;P1=364;P2=-428;P3=561;P4=-8280;CP=1;D=01212121212121212121212123012123012301212121212301212301230301212121212121212303012121230121230121230121212303012123014;e;
2019.01.17 00:35:29 4 : sduino868/msg READ: MU;P0=496;P1=-957;P2=1008;P3=-348;P4=377;P5=-5648;CP=4;D=01232323412341232341234141234123232341414141414145;e;i;
2019.01.17 00:35:29 4 : sduino868/msg READ: MU;P0=-120;P1=552;P2=-954;P3=1008;P4=-344;P5=378;P6=-5940;CP=5;D=012343434523452343452345252345234343452525252525256;e;i;
2019.01.17 00:35:29 4 : sduino868/msg READ: MU;P0=-323;P1=362;P2=-973;P3=1029;P5=-7044;CP=1;D=012303030123012303012301212301230303012121212301215;e;
2019.01.17 00:35:29 4 : sduino868/msg READ: MU;P0=-974;P1=363;P2=1025;P3=-328;CP=1;D=01023232310231023231023101023102323231010101023101;e;
2019.01.17 00:35:29 4 : sduino868/msg READ: MU;P0=-156;P1=484;P2=-961;P3=1029;P4=-327;P5=353;P6=-6768;P7=2352;CP=5;D=01234343452345234345234525234523434345252525234567;e;i;
2019.01.17 00:35:33 4 : sduino868/msg READ: MU;P0=-228;P1=559;P2=-430;P3=363;P4=-629;CP=3;D=012323232323232323232323232143232143214323232323214323214321414323232323232323232323232321432321432321432323214321414323;e;
2019.01.17 00:35:35 4 : sduino868/msg READ: MU;P0=366;P1=-428;P2=561;P3=-629;P4=-7432;CP=0;D=0101010101010101010101012301012301230101010101230101230123230101010101010101010101010123010123010123010101230123230104;e;
2019.01.17 00:35:36 4 : sduino868/msg READ: MU;P0=-196;P1=363;P2=-429;P3=562;P4=-629;P5=-7716;CP=1;D=01212121212121212121212123412123412341212121212341212341234341212121212121212121212121234121234121234121212341234341215;e;
Danke.
Demnach gibt es auch FS20 Sender, die jede Nachricht einzeln senden.
Mich interessieren Handsender bei denen alle 3 Nachrichten in einer sehr langen MU-Nachricht empfangen werden.
Gruß Ralf
Liest hier niemand mit der einen FS20 Handsender und einen Signalduino hat?
Gruß Ralf
Zitat von: Ralf9 am 23 Januar 2019, 21:42:01
Liest hier niemand mit der einen FS20 Handsender und einen Signalduino hat?
Gruß Ralf
Hallo Ralf,
Ich habe so einen fs20 handelnder dieser sendet aber auf 868,3 MHz. Ich kann ja mal morgen etwas mitloggen. Muss ich was besonderes einstellen ?
version: V 3.3.2.1-rc8 SIGNALduino cc1101 - compiled at Jan 10 2019 20:13:56
Jörg
ZitatMuss ich was besonderes einstellen ?
Ja, siehe hier
Zitat von: Ralf9 am 16 Januar 2019, 18:33:22
Mich interessiert wie diese MU-Nachrichten komplett mit allen Wiederholungen aussehen.
Mit der V 3.3.2.1-rc8 kann die Ausgabe der sehr langen MU-Nachrichten aktiviert werden, dies funktioniert z.Zt. bei der offiziellen Entwicklerversion dev-r33 nur bei unkomprimierten Nachrichten (Mred=0).
get sduino raw CEO
get sduino raw CDR
Ein get config ergibt dann folgendes:
config: MS=1;MU=1;MC=1;Mred=0;MuNoOverflow=1;....
Gruß Ralf
Zitat von: Ralf9 am 07 Januar 2018, 21:37:44
...
hier ist für den Arduino eine alternative firmware V 3.3.2.1, sie ist noch in Entwicklung und kann noch Fehler enthalten.
...
dezente frage: was sind die unterschiede zur "original firmware" ? und was war die hauptmotivation für die "alternative" ?
ich will mir evtl. den "SIGNALduino Stick Atmega 32U4 + CC1101 868MHz" als einstieg zulegen.
ist die mitgelieferte FW sehr schlechte, gemäss eurer erfahrung? (falls vorhanden).
"In-Circuit" sieht ja erstmal sehr professionell aus von der aufmachung/webpage her...
ich hoffe "allgemeine fragen" sind hier auch erlaubt :)
danke im voraus!
lou
wie ich hier schon geschrieben habe, habe ich in meiner alternativer Version gegenüber der V 3.3.1 einige Erweiterungen und Optimierungen eingebaut.
https://forum.fhem.de/index.php/topic,82379.msg744554.html#msg744554
Die mir bekannten Fehler der V 3.3.1 müssten eigentlich behoben sein.
Diese Version läuft bei mir sehr stabil, mir sind keine Fehler bekannt, es können aber trotzdem noch Fehler enthalten sein.
Welche 868MHz Sensoren möchstet Du damit emfangen oder senden?
Gruß Ralf
Zitat von: Ralf9 am 27 Januar 2019, 11:14:44
wie ich hier schon geschrieben habe, habe ich in meiner alternativer Version gegenüber der V 3.3.1 einige Erweiterungen und Optimierungen eingebaut.
https://forum.fhem.de/index.php/topic,82379.msg744554.html#msg744554
Die mir bekannten Fehler der V 3.3.1 müssten eigentlich behoben sein.
Diese Version läuft bei mir sehr stabil, mir sind keine Fehler bekannt, es können aber trotzdem noch Fehler enthalten sein.
Welche 868MHz Sensoren möchstet Du damit emfangen oder senden?
Gruß Ralf
thanks Ralf. ich schätze du beziehst dich auf den abschnitt "einige neue konfig Befehle". den hab ich tatsächlich übersehen - sorry.
primär interessieren mich erstmal fenster + temp-sensoren, evtl. ein paar simple fernbedienungen.
also devices für die eine WLAN lösung wg. "battery only" unpassend wäre.
z.b. die MAX!-fenstersensoren (BC-SC-Rd-WM-2).
die rs232-protokoll-treiber möchte ich auf jeden fall selbst schreiben wg. robustheit. (win server/c#/cpp).
dabei soll dann z.b. eine "CC1101-COM-MQTT bridge" o.ä. herauskommen.
mit RF-firmware oder RF-hardware will ich mich weniger beschäftigen, daher die idee mit dem "komplett-stick" von in-circuit.
thanks again,
lou
Zitatprimär interessieren mich erstmal fenster + temp-sensoren, evtl. ein paar simple fernbedienungen.
Da hast Du bei 433 MHz eine größere Auswahl.
Zitatdie MAX!-fenstersensoren (BC-SC-Rd-WM-2)
Die MAX!-fenstersensoren können vom Signalduino nicht empfangen werden, da sind beim cc1101 andere Einstellungen wie z.B. eine höhere Datenrate notwendig.
Es gibt z.B. auch diese fenstersensoren
https://forum.fhem.de/index.php/topic,95346.msg881807.html#msg881807
Zitatdie rs232-protokoll-treiber möchte ich auf jeden fall selbst schreiben wg. robustheit. (win server/c#/cpp).
dabei soll dann z.b. eine "CC1101-COM-MQTT bridge" o.ä. herauskommen.
Dafür ist der Signalduino wahrscheinlich nicht geeignet. Beim Signalduino werden die empfangenen Rohnachrichten zum 00_SIGNALduino.pm Modul übertragen und dort verarbeitet.
Gruß Ralf
Zitat von: pejonp am 23 Januar 2019, 22:16:07
...
Ich habe so einen fs20 handelnder dieser sendet aber auf 868,3 MHz. Ich kann ja mal morgen etwas mitloggen. Muss ich was besonderes einstellen ?
version: V 3.3.2.1-rc8 SIGNALduino cc1101 - compiled at Jan 10 2019 20:13:56
Hallo Ralf,
bin jetzt erst dazu gekommen. Hänge mal das Log an. Ich hoffe du kannst damit etwas anfangen. Es wurden die Tasten 1-2 auf der rechten Seite nacheinander durchgedrückt und dann von 2-1 zurück auf der linken Seite. Es ist eine FS20 S8 Fernbedienung 868.3 MHz(https://files.elv.com/service/manuals/FS20S8/73632_FS20S82_UM.pdf). Ich nutzte sie nur zum Ein/Ausschalten von FS20 Steckdosen. Bei längerem Tastendruck ist auch ein Dimmen möglich. Im System ist auch noch ein BusWare CUL, der auf SlowRF läuft.
Kennst du diese Seite (http://fhz4linux.info/tiki-index.php?page=FS20%20Protocol) dort wird das FS20-Protokoll dargestellt.
Jörg
Kann es sein, daß FS20 ab und zu als MS-Nachricht erkannt wird?
Kannst Du mal den MS-Decoder abschalten?
Hallo Ralf,
BusWare CUL abgezogen.
MS=0
Internals:
BTN 00
DEF cf4b 00
IODev CUL_0
LASTInputDev SIG868
MSGCNT 1
NAME FS20_cf4b00
NR 298
SIG868_DMSG 810b04f70101a001CF4B000011
SIG868_MSGCNT 1
SIG868_RAWMSG MU;P0=-26372;P1=365;P2=-5388;P3=-433;P4=564;P5=-628;P6=-9336;CP=1;R=46;D=01213131313134545451313454545451313451313451345451313131313131313131313131345131313451313134545131313454516131313131313131313131313454545131345454545131345131345134545131313131313131313131313134513131345131313454513131345451613131313131313131313131345454513134545454513134513134513454513131313131313131313131313451313134;e;
SIG868_RSSI -51
SIG868_TIME 2019-01-29 23:07:48
STATE on
TYPE FS20
XMIT cf4b
CODE:
1 cf4b 00
READINGS:
2019-01-29 23:07:48 state on
Attributes:
IODev CUL_0
room FS20
verbose 5
Internals:
BTN 01
DEF cf4b 01
IODev CUL_0
LASTInputDev SIG868
MSGCNT 1
NAME FS20_cf4b01
NR 296
SIG868_DMSG 810b04f70101a001CF4B010011
SIG868_MSGCNT 1
SIG868_RAWMSG MU;P0=-32001;P1=371;P2=-15324;P3=-617;P4=578;P5=252;P6=-420;P7=-9346;CP=1;R=63;D=01213434343561643161643164343161616161616161643431616164316161643161616434316164316431716161616161616161616161643434316164343434316164316164316434316161616161616164343161616431616164316161643431616431643171616161616161616161616164343431616434343431616431616431643431616161616161616434316161643161616431616164;e;
SIG868_RSSI -42.5
SIG868_TIME 2019-01-29 23:09:13
STATE on
TYPE FS20
XMIT cf4b
CODE:
1 cf4b 01
READINGS:
2019-01-29 23:09:13 state on
Attributes:
IODev CUL_0
room FS20
verbose 5
Jörg
Zitat von: Ralf9 am 28 Januar 2019, 18:27:15
..
Dafür ist der Signalduino wahrscheinlich nicht geeignet. Beim Signalduino werden die empfangenen Rohnachrichten zum 00_SIGNALduino.pm Modul übertragen und dort verarbeitet.
...
danke für die Tipps, Ralf.
pearl oder anderes scripting etc will ich vermeiden und mindestens den com-protokolltreiber selbst schreiben (s.o.) .
mein technischer verständnis geht derzeit soweit daß ich den C1101 als mini-SDR sehe.
dahinter typischerweise ein AVR+FW (der oft an der leistungesgrenze ist - siehe FW threads github etc).
vielleicht wäre sogar eine paarung ESP+c1101 (ohne AVR) optimal für die zukunft. somit wäre ein bottleneck eliminiert. (~10x mehr cpu leistung)
was ist die hauptchallenge bei der AVR-firmware? speed? ram? die ganzen C1101 settings?
sorry für OT.
@: lou
Ich habe dafür ein neues Thema aufgemacht
https://forum.fhem.de/index.php/topic,96813.0.html
Hallo Jörg,
Danke für die logs von Deinem FS20 Handsender.
Ich habe darin gefunden was ich gesucht habe.
Mir ist dabei aufgefallen, daß Du anscheinend keine optimalen Empfangsbedingungen hast, bei der dritten Nachricht haben immer ein paar Werte gefehlt.
Gruß Ralf
Zitat von: Ralf9 am 01 Februar 2019, 23:21:33
Hallo Jörg,
Danke für die logs von Deinem FS20 Handsender.
Ich habe darin gefunden was ich gesucht habe.
Mir ist dabei aufgefallen, daß Du anscheinend keine optimalen Empfangsbedingungen hast, bei der dritten Nachricht haben immer ein paar Werte gefehlt.
Gruß Ralf
Hallo Ralf,
Ja das kann so sein bzw. ist so. Der Sender ist schon etwas alt und sendet nicht immer zuverlässig. Und der cc1101 ist eigentlich für 434MHz ausgelegt. Habe ihn nur zum Test auf 868.3MHz umgestellt. Aber schön das ich dir helfen könnte.
Gruss Jörg
ich habe im ersten Beitrag eine Version für den miniCUL ergänzt.
Es wäre schön, wenn ich für den radino und miniCUL Rückmeldungen bekommen könnte ob sie funktionieren, da ich sie nicht testen konnte.
Nachtrag:
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 kommen.
Wenn das Attribut noMsgVerbose auf 3 gesetzt wird, bekommt man dann auch bei verbose 3 log Ausgaben wenn der FIFO fast voll ist oder überlaüft
z.B.
fast voll
... 3: sduino/noMsg Parse: MF=138
oder überlauf
... 3: sduino/noMsg Parse: MF=140
Gruß Ralf
Moin Ralf,
könntest Du auch noch nen Build für den ProMini328 mit anhängen?
Hallo SusisStrolch,
was für eine Hardware verwendest Du?
Ein 5V 16 MHz ProMini und ein RXB6 Empfänger?
Gruß Ralf
Den miniCUL von locutus
https://forum.fhem.de/index.php/topic,42998.0.html:
Ich meine das wäre ne 8MHz Version.
Edit: mit cc1101
Für den miniCUL gibt es bereits eine Firmware:
set sduino flash https://raw.githubusercontent.com/Ralf9/SIGNALDuino/dev-r332_cc1101/firmware/SIGNALduino_miniCUL_3321rc8.hex
Argh...
Hatte den falschen Beitrag referenziert....
https://forum.fhem.de/index.php/topic,55705.0.html
Sorry
Zitat von: Ralf9 am 10 Februar 2019, 15:05:38
Für den miniCUL gibt es bereits eine Firmware:
set sduino flash https://raw.githubusercontent.com/Ralf9/SIGNALDuino/dev-r332_cc1101/firmware/SIGNALduino_miniCUL_3321rc8.hex
Mit der herrscht Funkstille. Hatte vorher Sideys Mega-Version drauf, da wurden meine 433er Devices erkannt. Mit deinem Mega Compilat kommt nix an.
Der cc1101 wird erkannt, Configuration und paTable werden sauber ausgelesen..
was ergibt ein
get ccconf
und
get config
Hier die raw definition nach dem get...
defmod SDuino.AZ SIGNALduino 192.168.254.64:85
attr SDuino.AZ cc1101_frequency 433.92
attr SDuino.AZ comment freq: 433.940MHz, bWidth: 325kHz\
(bei 433.92: T1: -35,7kHz, T2: +42,3kHz, T3: +60,8kHz)\
attr miniCUL433 event-on-change-reading .*
attr SDuino.AZ debug 1
attr SDuino.AZ flashCommand avrdude -c arduino -b [BAUDRATE] -P [PORT] -p atmega328p -vv -U flash:w:[HEXFILE] 2>[LOGFILE]
attr SDuino.AZ hardware miniculCC1101
attr SDuino.AZ room Arbeitszimmer,CUL
attr SDuino.AZ verbose 5
attr SDuino.AZ whitelist_IDs 0,0.1,0.2,0.3,0.4,1,3,3.1,4,7,17,17.1,18,23,32,45,57,60,79
setstate SDuino.AZ opened
setstate SDuino.AZ 2019-02-10 16:21:06 ccconf freq:433.940MHz bWidth:325KHz rAmpl:42dB sens:4dB (DataRate:5603.79Baud)
setstate SDuino.AZ 2019-02-10 10:30:44 ccpatable C3E = 00 84 00 00 00 00 00 00 => 5_dBm
setstate SDuino.AZ 2019-02-06 23:32:13 cmds V R t X S P C r W x e
setstate SDuino.AZ 2019-02-10 16:20:00 config MS=1;;MU=1;;MC=1;;Mred=1;;Mdebug=1_MScnt=4;;MuSplitThresh=8000;;MdebFifoLimit=120/140
setstate SDuino.AZ 2019-02-10 16:19:19 ping OK
setstate SDuino.AZ 2019-02-10 15:44:44 state opened
setstate SDuino.AZ 2019-02-10 16:21:29 version V 3.3.2.1-rc8 SIGNALduino cc1101 - compiled at Jan 10 2019 20:10:21
Und hier das Log... (verbose 5)
2019.02.10 16:19:17.273 5: AddSendQueue: SDuino.AZ: P (1)
2019.02.10 16:19:18.299 5: SDuino.AZ SW: P
2019.02.10 16:19:19.299 4: SDuino.AZ/HandleWriteQueue: nothing to send, stopping timer
2019.02.10 16:19:19.306 5: SDuino.AZ/RAW READ: /OK
2019.02.10 16:19:19.308 4: SDuino.AZ/msg READ: OK
2019.02.10 16:19:19.310 5: SDuino.AZ/noMsg Parse: OK
2019.02.10 16:19:19.310 5: SDuino.AZ/msg READ: regexp=^OK$ cmd=ping msg=OK
2019.02.10 16:19:58.087 5: SDuino.AZ: command for gets: CG
2019.02.10 16:19:58.090 5: AddSendQueue: SDuino.AZ: CG (1)
2019.02.10 16:19:59.020 5: SDuino.AZ SW: CG
2019.02.10 16:20:00.073 4: SDuino.AZ/HandleWriteQueue: nothing to send, stopping timer
2019.02.10 16:20:00.121 5: SDuino.AZ/RAW READ: /MS=1;MU=1;MC=1;Mred=1;Mdebug=1_MScnt=4;MuSplitThresh=8000;MdebFifoLimit=120/140
2019.02.10 16:20:00.122 4: SDuino.AZ/msg READ: MS=1;MU=1;MC=1;Mred=1;Mdebug=1_MScnt=4;MuSplitThresh=8000;MdebFifoLimit=120/140
2019.02.10 16:20:00.122 5: SDuino.AZ/noMsg Parse: MS=1;MU=1;MC=1;Mred=1;Mdebug=1_MScnt=4;MuSplitThresh=8000;MdebFifoLimit=120/140
2019.02.10 16:20:00.123 5: SDuino.AZ/msg READ: regexp=^MS.*MU.*MC.* cmd=config msg=MS=1;MU=1;MC=1;Mred=1;Mdebug=1_MScnt=4;MuSplitThresh=8000;MdebFifoLimit=120/140
2019.02.10 16:20:18.148 4: SDuino.AZ/keepalive ok, retry = 0
2019.02.10 16:21:04.877 5: SDuino.AZ: command for gets: C0DnF
2019.02.10 16:21:04.878 5: AddSendQueue: SDuino.AZ: C0DnF (1)
2019.02.10 16:21:05.887 5: SDuino.AZ SW: C0DnF
2019.02.10 16:21:06.917 4: SDuino.AZ/HandleWriteQueue: nothing to send, stopping timer
2019.02.10 16:21:06.962 5: SDuino.AZ/RAW READ: /C0Dn11=10B0A357C43023B900070018146C070090
2019.02.10 16:21:06.963 4: SDuino.AZ/msg READ: C0Dn11=10B0A357C43023B900070018146C070090
2019.02.10 16:21:06.963 5: SDuino.AZ/noMsg Parse: C0Dn11=10B0A357C43023B900070018146C070090
2019.02.10 16:21:06.964 5: SDuino.AZ/msg READ: regexp=C0Dn11.* cmd=ccconf msg=C0Dn11=10B0A357C43023B900070018146C070090
2019.02.10 16:21:18.872 4: SDuino.AZ/keepalive ok, retry = 0
2019.02.10 16:21:24.497 5: SDuino.AZ: command for gets: V
2019.02.10 16:21:24.499 5: AddSendQueue: SDuino.AZ: V (1)
2019.02.10 16:21:28.520 5: SDuino.AZ SW: V
2019.02.10 16:21:29.692 4: SDuino.AZ/HandleWriteQueue: nothing to send, stopping timer
2019.02.10 16:21:29.704 5: SDuino.AZ/RAW READ: /V 3.3.2.1-rc8 SIGNALduino cc1101 - compiled at Jan 10 2019 20:10:21
2019.02.10 16:21:29.705 4: SDuino.AZ/msg READ: V 3.3.2.1-rc8 SIGNALduino cc1101 - compiled at Jan 10 2019 20:10:21
2019.02.10 16:21:29.706 5: SDuino.AZ/noMsg Parse: V 3.3.2.1-rc8 SIGNALduino cc1101 - compiled at Jan 10 2019 20:10:21
2019.02.10 16:21:29.707 5: SDuino.AZ/msg READ: regexp=V\s.*SIGNAL(duino|ESP).* cmd=version msg=V 3.3.2.1-rc8 SIGNALduino cc1101 - compiled at Jan 10 2019 20:10:21
2019.02.10 16:22:20.011 4: SDuino.AZ/keepalive ok, retry = 0
2019.02.10 16:23:20.629 4: SDuino.AZ/KeepAlive not ok, retry = 1 -> get ping
2019.02.10 16:23:20.631 5: AddSendQueue: SDuino.AZ: P (1)
2019.02.10 16:23:21.547 5: SDuino.AZ SW: P
2019.02.10 16:23:22.591 4: SDuino.AZ/HandleWriteQueue: nothing to send, stopping timer
2019.02.10 16:23:22.627 5: SDuino.AZ/RAW READ: /OK
2019.02.10 16:23:22.628 4: SDuino.AZ/msg READ: OK
2019.02.10 16:23:22.629 5: SDuino.AZ/noMsg Parse: OK
2019.02.10 16:23:22.629 5: SDuino.AZ/msg READ: regexp=^OK$ cmd=ping msg=OK
2019.02.10 16:24:21.347 4: SDuino.AZ/keepalive ok, retry = 0
Edit: code-tags korrigiert
Und das ist das alte Setting mit Sideys Version (läuft auf dem LCGW im Wohnzimmer):
defmod SDuino.WZ SIGNALduino 192.168.254.63:85
attr SDuino.WZ DbLogExclude .*
attr SDuino.WZ cc1101_frequency 433.92
attr SDuino.WZ debug 0
attr SDuino.WZ flashCommand avrdude -c arduino -b [BAUDRATE] -P [PORT] -p atmega328p -vv -U flash:w:[HEXFILE] 2>[LOGFILE]
attr SDuino.WZ hardware promini328
attr SDuino.WZ room CUL,Wohnzimmer
attr SDuino.WZ verbose 4
setstate SDuino.WZ opened
setstate SDuino.WZ 2019-02-10 16:27:03 ccconf freq:433.920MHz bWidth:232KHz rAmpl:42dB sens:12dB (DataRate:5603.79Baud)
setstate SDuino.WZ 2019-02-10 10:32:37 ccpatable C3E = 00 84 00 00 00 00 00 00 => 5_dBm
setstate SDuino.WZ 2019-02-10 16:27:32 config MS=1;;MU=1;;MC=1;;Mred=1;;Mdebug=1_MScnt=4;;MuSplitThresh=8000;;MdebFifoLimit=120
setstate SDuino.WZ 2019-02-07 22:22:18 ping OK
setstate SDuino.WZ 2019-02-10 10:11:48 state opened
setstate SDuino.WZ 2019-02-10 16:29:33 version V 3.3.2.1-rc4 SIGNALduino cc1101 (433Mhz )- compiled at Sep 29 2018 00:15:51
Zitatversion V 3.3.2.1-rc8 SIGNALduino cc1101 - compiled at Jan 10 2019 20:10:21
Du hast die SIGNALduino_3v3prominiCC1101_3321rc8.hex geflasht, diese Version ist für diejenigen, die mit einem 3.3V promini und der nanocul Verkabelung einen Signalduino gebaut haben.
Bei der SIGNALduino_miniCUL_3321rc8.hex ergibt ein get config:
version: V 3.3.2.1-rc8 SIGNALduino cc1101 (433Mhz )- compiled at Feb 2 2019 10:25:03Beim minicul ist gegenüber der nanocul Verkabelung Senden und Empfangen vertauscht.
Argh...
Danke!
Lööpt - da hatte ich mich doch durch das "pro" in der alten Version irritieren lassen...
Hallo,
ich würde gerne Temperatur/Feuchte Werte (die von anderen Sensoren kommen) im Oregon V1 oder V2 Format an meine Wetterstation senden. Der Original Außenfühler ist nun nach 10 Jahren leider kaputt. Funktioniert das schon so ohne weiteres über den sendMsg Befehl ?
Danke
Marc
Zitatich würde gerne Temperatur/Feuchte Werte (die von anderen Sensoren kommen) im Oregon V1 oder V2 Format an meine Wetterstation senden
Funktioniert das schon so ohne weiteres über den sendMsg Befehl ?
Das funktioniert ist aber nicht so einfach. Du musst dazu die Temperatur und Luftfeuchtigkeit mit einer Perlroutine in das Protokoll umrechnen, das Deine Wetterstation verwendet. Evtl musst Du auch noch die passende Prüfsumme berechnen.
Siehe auch
https://forum.fhem.de/index.php/topic,93684.0.html
Gruß Ralf
Aus meiner Sicht wäre das eine schöne Erweiterung (ja, ich helfe, ja es ist Aufwand), wenn einige/viele der Module echtes Senden bekommen. Ich habe schon drüber siniert, aber noch kein Konzept.
Das Modul für Oregon bräuchte eine Funktion "send" mit Parametern (immer andere, in diesem Fall alle Nutzdaten). Sie würde dann die sendMsg zusammenstellen, je nachdem, welches Interface es verwendet (Signalduino/CUL/...) incl. Checksum.
Horst
Eine Möglichkeit wäre einige der Module um ein "set send" zu erweitern, z.B.
set send T: 16.5 H: 47
Du kannst ja dafür ein neues Thema unter "Sonstige Systeme" oder "Wunschliste" aufmachen.
Gruß Ralf
Zitat von: Ralf9 am 14 Februar 2019, 19:12:49
Das funktioniert ist aber nicht so einfach. Du musst dazu die Temperatur und Luftfeuchtigkeit mit einer Perlroutine in das Protokoll umrechnen, das Deine Wetterstation verwendet. Evtl musst Du auch noch die passende Prüfsumme berechnen.
Siehe auch
https://forum.fhem.de/index.php/topic,93684.0.html
Danke schön, schaue ich mir an.
Zitat von: Ralf9 am 14 Februar 2019, 23:52:50
Eine Möglichkeit wäre einige der Module um ein "set send" zu erweitern, z.B.
set send T: 16.5 H: 47
Das wäre natürlich noch besser :-)
Danke
Marc
Hallo zusammen, in der Sufu find ich keine Hilfe, deshalb probier ich es hier:
Ich hab eine Steuerung für mein Dachfenster im Bad aufgebaut und einen SIGNALDUINO mit CC1101 um Temperatur und Luftfeuchtigkeit im Raum zu messen.
Nun stelle ich aber fest, dass unter Umständen die Feuchtigkeit schnell steigt (Beim Duschen zum Beispiel).
Dann bekomm ich von meinem Signalduino die Meldung:
"ERROR - Hum diff too large (old 59, new 63, diff 4.0)"
Somit erkenne ich den zu hohen Wert der Feuchtigkeit nicht mehr...
Kann ich den Differenzwert ab dem ein Messwert als Fehler verworfen wird einstellen?
Ich habNichts gefunden...
Vielen Dank
Friedrich
Gibt es bei Dir die Attribute "max-deviation-temp" und "max-deviation-hum" die sind per Default auf 1
Gruß Ralf
Nein, sind nicht definiert.
Soll ich?
Ja, wenn es diese beiden Attribute in der Liste gibt und bei Dir der Defaultwert von 1 nicht passt, muß Du sie mit einem höheren Wert definieren.
OK, danke
Hallo Forum, ich benötige nochmal Hilfe. Ich habe die neue Firmware aufgespielt und nun reagiert der sduino gar nicht mehr >:(
Ich weiß nicht, was ich falsch gemacht habe. Neustart, auf "Werkeinstellung" zurückgesetzt, es gibt einfach keinen Signaleingang. Selbst rawmessages werden nicht angezeigt (keine events über mehrere Minuten, obwohl hier Thermometer und Regenmesser stehen):
Internals:
Clients :IT:CUL_TCM97001:SD_RSL:OREGON:CUL_TX:SD_AS:Hideki:SD_WS07:SD_WS09: :SD_WS:RFXX10REC:Dooya:SOMFY:SD_BELL:SD_UT:SD_WS_Maverick:FLAMINGO:CUL_WS:Revolt: :FS10:CUL_FHTTK:Siro:FHT:FS20:CUL_EM:Fernotron:SD_Keeloq:SIGNALduino_un:
DEF /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A104WS3F-if00-port0
DMSG nothing
DevState initialized
DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A104WS3F-if00-port0@57600
FD 10
FUUID 5c782b53-f33f-1115-5537-1acd607a016042cf
IDsNoDispatch 2,72.1,82
LASTDMSG nothing
NAME sduino
NR 21
PARTIAL
STATE opened
TIME 1552893658
TYPE SIGNALduino
sendworking 0
unknownmessages
version V 3.3.2.1-rc8 SIGNALduino cc1101 - compiled at Jan 10 2019 20:13:56
versionProtocols 1.01
versionmodul v3.4.0_dev_16.03
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 ^P(?:14|29|30|34|46|69|76|81|83|86|90|91|91.1|92)#.*
18:FLAMINGO ^P13\.?1?#[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
25:CUL_EM ^E0.................
26:Fernotron ^P82#.*
27:SD_BELL ^P(?:15|32|41|42|57|79)#.*
28:SD_Keeloq ^P(?:87|88)#.*
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:
2017-06-26 16:33:12 ITParms Unsupported command
2019-03-18 08:56:23 ccconf freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:4dB (DataRate:43.78Baud)
2019-03-18 08:56:30 ccpatable C3E = 00 C0 00 00 00 00 00 00 => 10_dBm
2019-03-16 22:09:03 ccreg C3E = 00 C0 00 00 00 00 00 00
2019-03-18 08:56:07 config MS=1;MU=1;MC=1;Mred=1;Mdebug=1_MScnt=4;MuSplitThresh=8000;MdebFifoLimit=120/140
2018-05-27 15:09:14 freeram 450
2018-05-08 21:22:16 logEntry freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:4dB (DataRate:3173.83Baud)
2019-03-18 09:06:13 ping OK
2019-03-18 08:55:49 raw Init eeprom to defaults
2019-03-18 08:21:12 state opened
2018-05-27 15:09:00 uptime 0 00:07:35
2019-03-18 08:21:12 version V 3.3.2.1-rc8 SIGNALduino cc1101 - compiled at Jan 10 2019 20:13:56
getcmd:
keepalive:
ok 1
retry 0
mcIdList:
10
11
12
18
43
47
52
57
58
msIdList:
0
0.1
0.2
0.3
0.4
1
3
3.1
4
6
7
13
13.2
14
15
17
23
25
33
35
51
55
65
87
88
90
91.1
93
muIdList:
8
9
13.1
16
17.1
19
21
22
24
26
27
28
29
30
31
32
34
36
39
42
44
44.1
45
46
48
49
50
56
59
60
61
62
64
66
67
69
70
71
72
73
74
76
79
80
81
83
84
85
86
89
91
92
Attributes:
blacklist_IDs 41,40,37,38,68
debug 0
devStateIcon Initialized:cul_usb@green:Open Open:cul_usb@red:Initialized
development u86
flashCommand avrdude -c arduino -b 57600 -P [PORT] -p atmega328p -vv -U flash:w:[HEXFILE] 2>[LOGFILE]
group intern
hardware nanoCC1101
updateChannelFW testing
Habe ich mir den zerschossen? Ich habe doch bestimmt was übersehen, nur was?
Hier noch der Flashlog
avrdude: Version 6.1, compiled on Jul 7 2015 at 10:29:47
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2014 Joerg Wunsch
System wide configuration file is "/etc/avrdude.conf"
Using Port : /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A104WS3F-if00-port0
Using Programmer : arduino
Overriding Baud Rate : 57600
AVR Part : ATmega328P
Chip Erase delay : 9000 us
PAGEL : PD7
BS2 : PC2
RESET disposition : dedicated
RETRY pulse : SCK
serial program mode : yes
parallel program mode : yes
Timeout : 200
StabDelay : 100
CmdexeDelay : 25
SyncLoops : 32
ByteDelay : 0
PollIndex : 3
PollValue : 0x53
Memory Detail :
Block Poll Page Polled
Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
eeprom 65 20 4 0 no 1024 4 0 3600 3600 0xff 0xff
flash 65 6 128 0 yes 32768 128 256 4500 4500 0xff 0xff
lfuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
hfuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
efuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
lock 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
calibration 0 0 0 0 no 1 0 0 0 0 0x00 0x00
signature 0 0 0 0 no 3 0 0 0 0 0x00 0x00
Programmer Type : Arduino
Description : Arduino
Hardware Version: 2
Firmware Version: 1.16
Vtarget : 0.0 V
Varef : 0.0 V
Oscillator : Off
SCK period : 0.1 us
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.01s
avrdude: Device signature = 0x1e950f
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "FHEM/firmware/SIGNALduino_nanoCC1101_3321rc8.hex"
avrdude: input file FHEM/firmware/SIGNALduino_nanoCC1101_3321rc8.hex auto detected as Intel Hex
avrdude: writing flash (24824 bytes):
Writing | ################################################## | 100% 9.83s
avrdude: 24824 bytes of flash written
avrdude: verifying flash memory against FHEM/firmware/SIGNALduino_nanoCC1101_3321rc8.hex:
avrdude: load data flash data from input file FHEM/firmware/SIGNALduino_nanoCC1101_3321rc8.hex:
avrdude: input file FHEM/firmware/SIGNALduino_nanoCC1101_3321rc8.hex auto detected as Intel Hex
avrdude: input file FHEM/firmware/SIGNALduino_nanoCC1101_3321rc8.hex contains 24824 bytes
avrdude: reading on-chip flash data:
Reading | ################################################## | 100% 10.54s
avrdude: verifying ...
avrdude: 24824 bytes of flash verified
avrdude done. Thank you.
Und das Modul ist
00_SIGNALduino.pm 10488 2019-03-08 12:00:00Z v3.4.0-dev
# $Id: 90_SIGNALduino_un.pm 15479 2018-01-24 20:00:00 dev-r34 $
<edit>
ccregAll:
ccreg 00: 0D 2E 2D 07 D3 91 3D 04 32 00 00 06 00 10 B0 71
ccreg 10: 50 C4 30 23 B9 00 07 00 18 14 6C 07 00 90 87 6B
ccreg 20: F8 56 11 EF 2B 17 1F 41 00 59 7F 3F 88 31 0B
Du kannst mal folgendes versuchen:
get raw e
get raw eC
"get raw eC" macht ein initEEPROMconfig. Damit werden die config Daten im EEPROM auf default zurückgesetzt
Den sduino ziehen und stecken.
get ccconf
get config
Gruß Ralf
Hat geklappt (bin erst jetzt nach Hause gekommen zum Steckerziehen), läuft alles, danke!
Ich habe noch einen TFA Dostmann 30.3211.02 Temperatursensor, der lief früher unter Bresser_Temeo. Ich sehe, dass beim Batterieeinlegen sich das folgende Gerät einrichtet
Internals:
CFGFN
CODE CUL_TCM97001_Unknown
DEF CUL_TCM97001_Unknown
FUUID 5c8f7c67-f33f-1115-ec53-88b338576106bb3a
LASTInputDev sduino
MSGCNT 119
NAME Unknown
NR 289
STATE Code: ACC03B1268
TYPE CUL_TCM97001
lastH 0
lastT 1552932118.1508
sduino_DMSG sACC03B126800
sduino_MSGCNT 119
sduino_RAWMSG MS;P1=-4223;P2=555;P3=-2074;P4=-9062;D=24212321232121232321212323232323232323212121232121232323212323212323212123212323;CP=2;SP=4;R=219;s=22;e;m0;
sduino_RSSI -92.5
sduino_TIME 2019-03-18 19:01:58
READINGS:
2019-03-18 19:01:58 state Code: ACC03B1268
Attributes:
model Unknown
room CUL_TCM97001
und vermute, dass das der Sensor ist. Aber ich weiß nicht, welches Modell ich da nehmen soll. Hast Du einen Tipp? Sonst probiere ich mal alles herum.
ZitatIch habe noch einen TFA Dostmann 30.3211.02 Temperatursensor, der lief früher unter Bresser_Temeo. Ich sehe, dass beim Batterieeinlegen sich das folgende Gerät einrichtet
Ich habe mal gesucht, konnte beim Signalduino oder CUL_TCM97001 nichts über den TFA Dostmann 30.3211.02 finden, ich konnte auch keine Protokollbeschreibung finden.
Bitte mache dazu bei Bedarf ein neues Thema auf.
Zitat von: Ralf9 am 19 März 2019, 23:38:57
Bitte mache dazu bei Bedarf ein neues Thema auf.
Hat sich erledigt - nach einem Neustart wurde das Gerät komplett eingerichtet.
@andies: Bitte schick mir doch ein Bild und die sonstigen Daten, damit ich das Gerät in das Wiki eintragen kann. Du kannst auch gerne selbst eintragen.
Horst
https://wiki.fhem.de/wiki/Geprüfte_Geräte (https://wiki.fhem.de/wiki/Gepr%C3%BCfte_Ger%C3%A4te)
Mache ich, dauert etwas.
Hi,
ich habe 2 signalduino. einen mit CC1101 und einen ohne. Der mit ist auf die somfy Frequenz eingestellt und nur somfy ist in der whitelist angegeben.
Ich habe seit einger Zeit viele Fehlermeldungen und fragte mich wo die wohl herkommen. Gestern hatte ich dann die Idee das dies von meinem autoschluessel mit keylessGo koemmen koennte. Heute morgen habe ich dann auch noch 3 Mal die Taste von meinem alten Autoschluessel (nur funk ZV) gedrueckt und dann mal ins LogFile geschaut:
[/2019.04.01 18:41:07 1: SignalDuino: SOMFY_Parse : Somfy RTS message format error (length)! :A0404040762ECC940058: 2019.04.01 18:41:07 3: SignalDuino: Unknown code YsA0404040762ECC940058, help me!
2019.04.01 18:41:08 1: SignalDuino: SOMFY_Parse : Somfy RTS message format error (length)! :A0404040762ECC84001D:
2019.04.01 18:41:08 3: SignalDuino: Unknown code YsA0404040762ECC84001D, help me!
2019.04.01 18:41:08 1: SignalDuino: SOMFY_Parse : Somfy RTS message format error (length)! :A0404040762ECC880022:
2019.04.01 18:41:08 3: SignalDuino: Unknown code YsA0404040762ECC880022, help me!
2019.04.01 18:41:08 1: SignalDuino: SOMFY_Parse : Somfy RTS message format error (length)! :A0404040762ECC8C0037:
2019.04.01 18:41:08 3: SignalDuino: Unknown code YsA0404040762ECC8C0037, help me!
2019.04.01 18:41:08 1: SignalDuino: SOMFY_Parse : Somfy RTS message format error (length)! :A0404040762ECC90004D:
2019.04.01 18:41:08 3: SignalDuino: Unknown code YsA0404040762ECC90004D, help me!
2019.04.01 18:41:08 1: SignalDuino: SOMFY_Parse : Somfy RTS message format error (length)! :502020203B17664A002C:
2019.04.01 18:41:08 3: SignalDuino: Unknown code Ys502020203B17664A002C, help me!
2019.04.01 18:57:31 1: SignalDuino: SOMFY_Parse : Somfy RTS message format error (length)! :A0404040762ECC8C00370: 2019.04.01 18:57:31 3: SignalDuino: Unknown code YsA0404040762ECC8C00370, help me!
2019.04.01 18:57:31 1: SignalDuino: SOMFY_Parse : Somfy RTS message format error (length)! :A0404040762ECC90004D:
2019.04.01 18:57:31 3: SignalDuino: Unknown code YsA0404040762ECC90004D, help me!
2019.04.01 18:57:32 1: SignalDuino: SOMFY_Parse : Somfy RTS message format error (length)! :A0404040762ECC940058:
2019.04.01 18:57:32 3: SignalDuino: Unknown code YsA0404040762ECC940058, help me!
2019.04.01 18:57:36 1: SignalDuino: SOMFY_Parse : Somfy RTS message format error (length)! :A0404040762ECC8C0037:
2019.04.01 18:57:36 3: SignalDuino: Unknown code YsA0404040762ECC8C0037, help me!
2019.04.01 18:57:36 1: SignalDuino: SOMFY_Parse : Somfy RTS message format error (length)! :A0404040762ECC90004D:
2019.04.01 18:57:36 3: SignalDuino: Unknown code YsA0404040762ECC90004D, help me!
2019.04.01 18:57:36 1: SignalDuino: SOMFY_Parse : Somfy RTS message format error (length)! :A0404040762ECC940058:
2019.04.01 18:57:36 3: SignalDuino: Unknown code YsA0404040762ECC940058, help me!
2019.04.02 07:30:35 1: SignalDuino: SOMFY_Parse : Somfy RTS checksum error! :504142111928B3:
2019.04.02 07:30:35 1: SignalDuino: SOMFY_Parse : Somfy RTS checksum error! :504142111928B3:
2019.04.02 07:30:35 3: SignalDuino: Unknown code Ys504142111928B3, help me!
code]
Kann es sein das ich hier wirklich meine Autoschluessel sehe? Kann ich die irgendwie so einbinden das ich was damit machen kann?
Danke fuer Eure Hilfe
ZitatIch habe seit einger Zeit viele Fehlermeldungen und fragte mich wo die wohl herkommen.
siehe hier
https://forum.fhem.de/index.php/topic,53319.0.html
Gruß Ralf
Hi Ralf, eine Frage. Zuerst zum Hintergrund: Ich betreibe den Signalduino zum Senden (Somfy und ziemlich robuste 433 MHz-Steckdosen) sowie zum Empfang einer Wetterstation (BresserTemeo). Damit der Empfang gut ist, habe ich RPi+Signalduino in einem Rolladenkasten verbaut, was manchmal nervig ist, wenn der RPi ausfällt. Ich würde gern zwei Dinge tun:
- Den RPi aus dem Rolladenkasten holen und im Haus dann per LAN anschließen
- ohne aber auf das Senden und Empfangen von 433 MHz zu verzichten (Somfy muss und will ich nicht empfangen, nur die robusten Anwendungen).
Jetzt dachte ich, dass ich einen SignalESP entsprechend einbinde, d.h. das Modul ist via WLAN und eben nicht USB an FHEM gebunden. Dann könnte ich den SignalESP im Rolladenkasten lassen und den RPi endlich rausholen.
Ich habe gelesen, dass gerade bei Somfy hier Probleme auftreten können. Würdest Du empfehlen das zu probieren oder soll ich das besser lassen und weiter auf USB-Anbindung setzen? WLAN-Abdeckung ist sehr gut.
Mit dem SignalESP habe ich keine Erfahrung, da ich keinen habe.
Dem ESP8255 muß durch regelmässigen aufruf von Yield Zeit gegeben werden, damit er sich um Dinge wie z.B. wlan und dem tcp-Stack kümmern kann.
Es ist denkbar, daß es Protokolle gibt die auf dem ESP8255 nicht so gut laufen.
Weiß zufällig jemand, wieviel Zeit der Yield Befehl normalerweise benötigt?
Du kannst auch einen promini oder nano mit einem ESP (z.B. wemos d1 mini), auf dem ESP-Link läuft, verbinden
https://forum.fhem.de/index.php/topic,69042.msg605241.html#msg605241
Denkst Du noch an die rawmsg vom TFA Dostmann 30.3211.02?
Gruß Ralf
Zitat von: Ralf9 am 14 April 2019, 19:07:37
Denkst Du noch an die rawmsg vom TFA Dostmann 30.3211.02?
Sorry, hatte ich vergessen: Auf einmal hatte ich ein Gerät BresserTemeo und das war genau mein Messgerät. Daher habe ich mich nicht mehr gemeldet. Also das läuft.
OK, dann lese ich mal. Vielleicht probiere ich das einfach aus mit dem SignalESP und baue erst zurück, wenn alles läuft.
Zitat von: Ralf9 am 14 April 2019, 19:07:37
Du kannst auch einen promini oder nano mit einem ESP (z.B. wemos d1 mini), auf dem ESP-Link läuft, verbinden
https://forum.fhem.de/index.php/topic,69042.msg605241.html#msg605241
Ich hatte das mehrfach gelesen aber immer nur die Hälfte verstanden. Sehe ich das richtig, dass das so läuft:
Arduino wird über SPI (MOSI, MISO usw.) mit dem CC1101 verbunden.
Arduino wird weiter über seriell (Tx, Rx) mit Wemos verbunden. Dann flashe ich den C1101 mit Signalduino V 3.3.2r-dev (?) und welche Firmware/Software kriegt der arduino?
ZitatArduino wird über SPI (MOSI, MISO usw.) mit dem CC1101 verbunden.
Arduino wird weiter über seriell (Tx, Rx) mit Wemos verbunden.
Ja
Die sduino Firmware kommt auf den Arduino.
Die ESP-Link SW kommt auf den Wemos
Gruß Ralf
Hallo,
ich bräuchte für meine Rolladensteuerung einen Signalduino, fertig kostet das Teil ja 50 Euro, ist das https://www.ebay.de/itm/nanoCUL-Bausatz-3D-Druck-Gehause-868-433-MHz-CUL-CC1101-FHEM-openHAB/272946835329?hash=item3f8ce62f81:m:mvu8rY2MKdkAQ8X4c5FKfeA (https://www.ebay.de/itm/nanoCUL-Bausatz-3D-Druck-Gehause-868-433-MHz-CUL-CC1101-FHEM-openHAB/272946835329?hash=item3f8ce62f81:m:mvu8rY2MKdkAQ8X4c5FKfeA) nicht das gleiche ? Kann ich das als identische HW betrachten auf der die FM hier läuft ?
Sollte problemlos funktionieren. aculfw ist vorgeflashed und Du musst S'duino-firmware selber flashen. (Und natürlich löten ;D)
Zitat von: KölnSolar am 17 April 2019, 11:46:12
Sollte problemlos funktionieren. aculfw ist vorgeflashed und Du musst S'duino-firmware selber flashen. (Und natürlich löten ;D)
Solltest du nicht löten können [emoji6] so kannst auch den Geldbeutel hiermit https://shop.in-circuit.de/product_info.php?products_id=253 strapazieren oder einfach löten lassen :) Alle Wege sind Dir offen.
Gesendet von iPhone mit Tapatalk Pro
Löten sollte ich hinbekommen, wenn nicht hätte ich hier jemanden. Die Sigduino FW macht er mir sogar schon mit drauf. Ganz nett der Verkäufer, super beraten. So hab ich jetzt zwei Sticks zum Preis von einem und die horrenden Versandkosten auch noch gespart.
Grüße,
ZitatLöten sollte ich hinbekommen,
Es muß auch ein SMD IC (Levelshifter) gelötet werden.
Ich habe es mir mal angeschaut, hier sind beide Seiten der Adapterplatine abgebildet:
https://www.ebay.de/itm/nanoCUL-Adapter-Board-Platine-fuer-CC1101-CUL-DIY-Kit-FHEM-openHAB-/273427912476
Als Levelshifter wird 74HC4050D verwendet. Die Signalduino die mir bekannt sind verwenden Widerstände als Levelshifter. Meine V 3.3.2.1-rcx firmware sollte damit auch funktionieren.
Liest hier jemand mit, der einen Signalduino mit Levelshifter IC Inbetrieb hat?
Gruß Ralf
Zitat von: Ralf9 am 17 April 2019, 22:26:41
Liest hier jemand mit, der einen Signalduino mit Levelshifter IC Inbetrieb hat?
;) Wie lautet deine Frage?
ZitatWie lautet deine Frage?
Was für ein Levelshifter, ein bidirektionaler oder 74HC4050?
Läuft er stabil? Ich habe Mittlerweile eine Uptime von 97 Tagen.
Wenn Du sehr häufig ein "get ccconf" machst, bekommst Du dann immer die richtigen Werte?
Gruß Ralf
Ich verwende die BiDirektional Variante und es läuft alles einwandfrei. Einschränkungen habe ich bisher keine festgestellt.
- Stabil, ja ohne Probleme.
- get Werte, keine Fehler festgestellt.
- Uptime, wurde zurückgesetzt wegen Neustarts FHEM. Betrieb in der Bauvariante über nen halbes Jahr mindestens.
Bsp:
https://www.amazon.de/level-shifter-33v-5v/s?k=level+shifter+33v+5v
Grüße
Zitat von: Ralf9_User am 17 April 2019, 22:48:17
Es muß auch ein SMD IC (Levelshifter) gelötet werden.
Ist der nicht dabei, oder eben ein anderer ? Irgendwas von einem SMD hat er gesprochen am Telefon, den man auflöten müsste. Ich bin mir aber nicht mehr sicher.
Deine Aussage hat mich jetzt etwas verwirrt, heißt das ich muss noch so ein Teil nachkaufen, sonst funktioniert es nicht ? Ist der Bausatz dann nicht komplett, so wie man es für deine FW braucht ?
Der SMD IC 74HC4050 ist dabei, er ist auf den ersten beiden Bildern vom ebay Angebot abgebildet.
So ich wollte mal Fragen, ob das soweit richtig aussieht, geflashed wurde der nanoCUL vom Händler, damit habe ich jetzt nur, in FHEM das Signalduino Modul installiert und den Stick definiert. Nun steht er dort mit Status opened, passt das so ? Müsste da nicht initialized stehen ?
Bei get version kommt folgendes, das sollte so passen..
version: V 3.3.2.1-rc8 SIGNALduino cc1101 - compiled at Jan 10 2019 20:13:56
Wenn get version funktioniert sollte es passen.
Status opened passt.
Was noch fehlt ist das Internal
DevState initialized
Was ergibt ein
get config
get ccconf
Gruß Ralf
Ich hatte noch mal auf den JarolifCUL geklickt, nachdem sah die Seite so aus, auch das
DevState initialized
ist jetzt vorhanden. Glaube so sieht es gut aus. Oregon und SW kann man weg lassen, sind das Temp Sensoren vom NanoCUL ?
Oder was ist das Links oben in der Liste alles ?
Vermutlich sind das Sensoren in der Nachbarschaft, die er gleich mit erkennt.
Wow ok, dann hat das kleine Kerlchen ne ganz schöne Reichweite, was den Empfang angeht.
Also kann ich eigentlich alles löschen, bis auf das Keeloq, das brauche ich für meine Rollos.
Wird hier eigentlich ein Modul mit installiert ? Ich wollte dieses Jarolif Modul per FTP in FHEM schieben, dann stand dort, ist schon vorhanden. Zeit könnte mit dem installieren des SignalDuino Moduls passen.
Das 14_SD_Keeloq Modul ist in der dev-r34 mit enthalten
https://github.com/RFD-FHEM/RFFHEM/blob/dev-r34/FHEM/14_SD_Keeloq.pm
Zitat von: Ralf9 am 17 April 2019, 22:26:41
Es muß auch ein SMD IC (Levelshifter) gelötet werden.
Ich habe es mir mal angeschaut, hier sind beide Seiten der Adapterplatine abgebildet:
https://www.ebay.de/itm/nanoCUL-Adapter-Board-Platine-fuer-CC1101-CUL-DIY-Kit-FHEM-openHAB-/273427912476
Als Levelshifter wird 74HC4050D verwendet. Die Signalduino die mir bekannt sind verwenden Widerstände als Levelshifter. Meine V 3.3.2.1-rcx firmware sollte damit auch funktionieren.
Liest hier jemand mit, der einen Signalduino mit Levelshifter IC Inbetrieb hat?
Gruß Ralf
Auch auf die Gefahr hin, dass ich gesteinigt werde:
Ich habe seit vielen vielen Monaten 3 CUL's und jetzt auch einen Signalduino (alles Arduino Nanos) ohne Levelshifter via esp-link an jeweils einer NodeMCU v3 (https://www.aliexpress.com/item/ESP8266-CH340G-CH340-G-NodeMcu-V3-Lua-Wireless-WIFI-Module-Connector-Development-Board-Based-ESP-12E/32803797003.html?spm=a2g0s.9042311.0.0.67fd4c4dHPNrzu) dran. Die scheinen auf der seriellen Leitung mit den 5V klarzukommen. So viel Glück kann man doch eigentlich nicht haben, dass die stabil sind und noch leben, wenn sie nicht 5V tollerant wären, oder? Die lassen sich perfekt über IP einbinden und auch flashen.
Levelshifter, Spannungswandler, promini und esp-01 waren mir viel zu viel Fummelei.
Hi,
Herzlichen Glückwunsch! Und nein ich diskutiere das nicht erneut hier ;-)
Aber wenig Fummelei wäre ein SignalESP bestehend aus:
Wemos D1 Mini (Clone), Zwischen Platine und Cc1101,
optional SMA Buchse und Antenne.
Weil der Wemos schon die 3V liefert ;-)
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Ich habe meine SIGNALduino mit der aktuellen Firmware bestückt und mich jetzt auf die Suche gemacht woher die OREGON: Unknown device THGR810_2, please define it Meldungen her kommen da ich auch einen RFXtrx433E im Einsatz habe.
Diese OREGON: Unknown device Meldungen produziert der SIGNALduino.
Was muss ich am SIGNALduino ändern damit diese OREGON Meldungen nicht mehr auftreten und die Daten ordnungsgemäß verarbeitet werden?
LIST
Internals:
CFGFN /media/hdd/fhem/mycfg/schnittstellen_rasp01.cfg
Clients :IT:CUL_TCM97001:SD_RSL:OREGON:CUL_TX:SD_AS:Hideki:SD_WS07:SD_WS09: :SD_WS:RFXX10REC:Dooya:SOMFY:SD_BELL:SD_UT:SD_WS_Maverick:FLAMINGO:CUL_WS:Revolt: :FS10:CUL_FHTTK:Siro:FHT:FS20:CUL_EM:Fernotron:SIGNALduino_un:
DEF 192.168.17.183:40733
DMSG u52#FFFFEB1224160
DevState initialized
DeviceName 192.168.17.183:40733
FD 26
FUUID 5c45b037-f33f-f4d2-f28c-b32d699badc97764
IDsNoDispatch 2,72.1,82
LASTDMSG u52#FFFFEB1224160
MSGCNT 1264
NAME sduino
NR 366
PARTIAL
RAWMSG MC;LL=-1022;LH=924;SL=-494;SH=453;D=000014EDDBE9F;C=482;L=52;R=238;s38;b1;
RSSI -83
STATE opened
TIME 1556643331.47682
TYPE SIGNALduino
sendworking 0
unknownmessages
version V 3.3.2.1-rc8 SIGNALduino cc1101 - compiled at Jan 10 2019 20:13:56
versionmodul v3.3.3
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 ^P(?:14|29|30|34|46|69|76|81|83|86|90|91|91.1|92)#.*
18:FLAMINGO ^P13\.?1?#[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
25:CUL_EM ^E0.................
26:Fernotron ^P82#.*
27:SD_BELL ^P(?:15|32|41|42|57|79)#.*
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:
2019-03-27 17:09:14 config MS=1;MU=1;MC=1;Mred=1;Mdebug=1_MScnt=4;MuSplitThresh=8000;MdebFifoLimit=120
2019-04-30 15:17:54 ping OK
2019-04-30 16:39:32 state opened
2019-03-27 17:09:31 uptime 0 00:02:00
2019-04-30 16:39:32 version V 3.3.2.1-rc8 SIGNALduino cc1101 - compiled at Jan 10 2019 20:13:56
keepalive:
ok 1
retry 0
mcIdList:
10
11
12
18
43
47
52
57
58
msIdList:
0
0.1
0.2
0.3
0.4
1
3
3.1
4
6
7
13
13.2
14
15
17
23
25
33
35
41
51
55
65
90
91.1
muIdList:
8
9
13.1
16
17.1
19
21
22
24
26
27
28
29
30
31
32
34
36
37
38
39
40
42
44
44.1
45
46
48
49
50
56
59
60
61
62
64
66
67
69
70
71
72
74
76
79
80
81
83
84
85
86
89
91
92
Attributes:
alias SIGNALduino - OG2 WebCam
debug 0
devStateIcon Initialized:it_network@0CFB0C opened:it_network@0CFB0C disconnected:it_network@red closed:it_network@red
flashCommand avrdude -c arduino -b 57600 -P [PORT] -p atmega328p -vv -U flash:w:[HEXFILE] 2>[LOGFILE]
group Schnittstellen ser2net
hardware nanoCC1101
icon cul_usb
longids 0
room _RxTx
verbose 0
LOG Auszug
2019.04.30 18:27:23.369 4: sduino/msg READ: MC;LL=-975;LH=952;SL=-488;SH=497;D=00000141D7B68B76B7E77CDAFC;C=485;L=103;R=83;s52;b7;
2019.04.30 18:27:23.370 4: sduino: Found manchester Protocol id 10 clock 485 RSSI -32.5 -> Oregon Scientific v2|v3
2019.04.30 18:27:23.371 5: sduino: extracted data 11111111111111111111111010111110001010000100100101110100100010010100100000011000100000110010010100000011 (bin)
2019.04.30 18:27:23.371 4: sduino: OSV3 protocol detected: msg_start = 27, message_length = 76
2019.04.30 18:27:23.371 4: sduino: OSV3 protocol = F8242D5225203289418
2019.04.30 18:27:23.371 4: sduino: OSV3 protocol converted to hex: (50FA28245D222530824981) with length (80) bits
2019.04.30 18:27:23.372 5: sduino Dispatch: 50FA28245D222530824981, test ungleich: disabled
2019.04.30 18:27:23.372 5: sduino Dispatch: 50FA28245D222530824981, -32.5 dB, dispatch
2019.04.30 18:27:23.372 5: sduino: dispatch 50FA28245D222530824981
2019.04.30 18:27:23.373 5: OREGON: decoding delay=117.864357948303 hex=50FA28245D222530824981
2019.04.30 18:27:23.374 5: OREGON: sensor_id=fa28 BitsMsg=80 Bits=80
2019.04.30 18:27:23.374 5: OREGON: checksum2 = 73 berechnet: 73
2019.04.30 18:27:23.374 3: OREGON: Unknown device THGR810_2, please define it
attr blacklist_ID raussuchen (https://wiki.fhem.de/wiki/SIGNALduino#Ger.C3.A4teerkennung (https://wiki.fhem.de/wiki/SIGNALduino#Ger.C3.A4teerkennung)) oder verbose 0.
ich habe ein Problem. Seit dem Neustart von FHEM geht sduino nicht mehr, anscheinend weil
2019.04.30 12:28:49 1: PERL WARNING: Use of uninitialized value in eval "string" at ./FHEM/00_SIGNALduino.pm line 257, <$fh> line 112.
2019.04.30 12:28:49 1: Error reloading protocol hash dynamic from svn.fhem.de. Module is in inoperable mode.
Weiß hier jemand weiter?
Zitatich habe ein Problem. Seit dem Neustart von FHEM geht sduino nicht mehr, anscheinend weil
Dies passt besser nach:
https://forum.fhem.de/index.php/topic,58397.0.html
Hast Du vor kurzem ein fhem update gemacht?
Vor ein paar Tagen hattest Du noch die dev-r34 nun hast Du anscheinend die Signalduino Module aus dem normalen fhem update.
ZitatError reloading protocol hash dynamic from svn.fhem.de. Module is in inoperable mode.
Das 00_Signalduino Modul wollte den Protokoll hash vom svn.fhem.de nachladen, dies hat aber nicht geklappt.
Gruß Ralf
Zitat von: Ralf9 am 30 April 2019, 22:22:14
Hast Du vor kurzem ein fhem update gemacht?
Vor ein paar Tagen hattest Du noch die dev-r34 nun hast Du anscheinend die Signalduino Module aus dem normalen fhem update.
Ja, Mist. Wegen etwas anderem. Wie kann ich Deine fest einstellen?
Gesendet von iPad mit Tapatalk Pro
Zitat2019.04.30 18:27:23.374 3: OREGON: Unknown device THGR810_2, please define it
Hast Du Autocreate aktiviert, normalerweise müsste der THGR810_2 automatisch angelegt werden.
2019.04.30 22:30:16.607 4 : sduinoD: Found manchester Protocol id 10 clock 485 RSSI -32.5 -> Oregon Scientific v2|v3
2019.04.30 22:30:16.607 5 : sduinoD: dispatch 50FA28245D222530824981
2019.04.30 22:30:16.607 5 : OREGON: decoding delay=29 hex=50FA28245D222530824981
2019.04.30 22:30:16.607 5 : OREGON: sensor_id=fa28 BitsMsg=80 Bits=80
2019.04.30 22:30:16.607 5 : OREGON: checksum2 = 73 berechnet: 73
2019-04-30 22:30:16.613 OREGON THGR810_2 temperature: 25.2
2019-04-30 22:30:16.613 OREGON THGR810_2 humidity: 23
2019-04-30 22:30:16.613 OREGON THGR810_2 battery: ok
2019-04-30 22:30:16.613 OREGON THGR810_2 batteryState: ok
2019-04-30 22:30:16.613 OREGON THGR810_2 T: 25.2 H: 23 BAT: okDu kannst auch versuchen ihn händisch anzulegen
define THGR810_2 OREGON THGR810_2Wenn Du möchtest, daß der sduino die Oregon nicht mehr verarbeitet, dann kannst Du die ID 10 aus der whitelist rausnehmen oder in die blacklist eintragen
Gruß Ralf
ZitatJa, Mist. Wegen etwas anderem. Wie kann ich Deine fest einstellen?
Ist nicht meine die dev-r34 ist von Sidey
Steht im wiki
update add https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r34/controls_signalduino.txt
Danke, ich brauche da nochmal Hilfe:
controls_signalduino.txt is already present in https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r33/controls_signalduino.txt
gab es als Rückmeldung. Irgendwas mache ich falsch.
PS Wobei, jetzt funktioniert der sduino wieder?!
Hast Du evtl schon früher mal ein
update add https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r33/controls_signalduino.txt
eingegeben? Das müsste wieder raus da es dev-r33 nicht mehr gibt, evtl gibt es damit ein Konflikt.
Damit kann ich Dir aber nicht weiterhelfen.
Das passt besser nach
https://forum.fhem.de/index.php/topic,58397.0.html
das Problem dürften auch noch andere haben oder bekommen.
Autocreate ist nicht aktiviert und die Oregon Sensoren sind unter ignoreTypes eingetragen.
Meine Oregon Sensoren sind vollständig durch den RFXtrx433E Empfänger angelegt worden.
Aufgrund der großen Abstände habe ich den SignalDuino unter anderem für die Oregon Sensoren ergänzt.
Der RFXtrx433E Empfänger hat schon ordnungsgemäß die Oregon Sensoren angelegt.
Der SIGNALDuino Empfänger sollte somit nur mehr die Daten einlesen, aber nicht wieder von Zeit zu Zeit Oregon Sensoren anlegen wollen.
Wie sieht es aus, einen Rademacher Garagentorantrieb ein zu binden aus ? Der Stick scheint darauf zu reagieren, er leuchtet wenn ich den Taster fürs Tor bediene. In minicom wird auch was angezeigt, sind aber nur Hieroglyphen zu sehen. Der Sender sendet mit 433 MHz.
Die andere Frage wäre, könnte man diese Kontakte mit einbinden, mit der a-culfw soll das wohl möglich sein.
https://www.ebay.de/itm/433MHZ-2-Wege-Tur-Fensterkontakt-kompatibel-zu-Sonoff-bridge/153218721525?_trkparms=aid%3D111001%26algo%3DREC.SEED%26ao%3D1%26asc%3D20160908103841%26meid%3D1c47823294ba42f78ff704f94e60b6b3%26pid%3D100227%26rk%3D4%26rkt%3D5%26sd%3D183414923889%26itm%3D153218721525&_trksid=p2054502.c100227.m3827 (https://www.ebay.de/itm/433MHZ-2-Wege-Tur-Fensterkontakt-kompatibel-zu-Sonoff-bridge/153218721525?_trkparms=aid%3D111001%26algo%3DREC.SEED%26ao%3D1%26asc%3D20160908103841%26meid%3D1c47823294ba42f78ff704f94e60b6b3%26pid%3D100227%26rk%3D4%26rkt%3D5%26sd%3D183414923889%26itm%3D153218721525&_trksid=p2054502.c100227.m3827)
Wenn das Signal bisher nicht ausgelesen wurde, hast Du einiges an Arbeit vor Dir: https://forum.pilight.org/showthread.php?tid=2771 (https://forum.pilight.org/showthread.php?tid=2771)
Aber vielleicht gibt es den Code schon irgendwo?
ZitatDer SIGNALDuino Empfänger sollte somit nur mehr die Daten einlesen, aber nicht wieder von Zeit zu Zeit Oregon Sensoren anlegen wollen.
Wenn bei den Oregon Sensoren die angelegt werden auch welche dabei sind die unplausible Werte liefern, gibt es evtl eine Möglichkeit.
Durch die checksum dürfte es eigentlich keine unplausiblen Werte geben.
ZitatWie sieht es aus, einen Rademacher Garagentorantrieb ein zu binden aus ? Der Stick scheint darauf zu reagieren, er leuchtet wenn ich den Taster fürs Tor bediene. In minicom wird auch was angezeigt, sind aber nur Hieroglyphen zu sehen. Der Sender sendet mit 433 MHz.
Die andere Frage wäre, könnte man diese Kontakte mit einbinden, mit der a-culfw soll das wohl möglich sein.
Hier geht es vorwiegend um die firmware, dies passt besser nach sonstiges.
Wenn die Kontakte mit der a-culfw funktionieren, sollte es auch mit dem signalduino funktionieren.
Gruß Ralf
Ich war überrascht wie viele Funk Sensoren in meinem Umfeld vorhanden sind.
Es sind so ca. 300 Sensoren unterschiedlicher Fabrikate vorhanden, wobei die meisten für Alarmanlagen genutzt werden.
Zum Glück sind die Oregonsensoren nur bei mir vorhanden.
Ich habe all diese fremden Sonsoren bei mir in einer ignor Liste eingetragen um die Belastung zu reduzieren, aber ich vermute das es durch diese hohe Anzahl dennoch beim SIGNALDuino zu Störungen kommen könnte die eventuell eine Neuanlage hervorrufen.
Nur diese Neuanlage passiert nur beim SIGNALDuino und nicht beim RFXtrx433E Empfänger.
Hallo!
Ich habe Schwierigkeiten, den Signalduino in Betrieb zu nehmen.
Meine Hardware: Arduino Mini Pro 16MHZ, 5V, betrieben an 3V FTDI.
Ich habe mir aus China einen CC1101, (ED07-1101D) - siehe https://de.aliexpress.com/item/1pcs-433MHz-CC2202-Wireless-rf-Module-E07-M1101D-TH-10mW-500m-SPI-433M-SMD-with-Spring/32810247068.html (https://de.aliexpress.com/item/1pcs-433MHz-CC2202-Wireless-rf-Module-E07-M1101D-TH-10mW-500m-SPI-433M-SMD-with-Spring/32810247068.html)
Als Schaltplan habe ich diesen
https://wiki.fhem.de/w/images/thumb/2/24/Selbstbau_cul_Schaltplan.png/400px-Selbstbau_cul_Schaltplan.png (https://wiki.fhem.de/w/images/thumb/2/24/Selbstbau_cul_Schaltplan.png/400px-Selbstbau_cul_Schaltplan.png)
Schaltplan benutzt.
Nachdem ich das ganze in FHEM in Betrieb genommen habe, bekomme ich im LOG folgende Meldungen angezeigt:
2019.05.16 07:26:29 3: signalduino reset
2019.05.16 07:26:29 3: Opening signalduino device /dev/ttyUSB0
2019.05.16 07:26:29 3: Setting signalduino serial parameters to 57600,8,N,1
2019.05.16 07:26:29 1: signalduino/define: /dev/ttyUSB0@57600
2019.05.16 07:26:29 1: signalduino/init: /dev/ttyUSB0@57600
2019.05.16 07:26:29 3: signalduino device opened
2019.05.16 07:26:31 3: signalduino/init: disable receiver (XQ)
2019.05.16 07:26:31 5: signalduino SW: XQ
2019.05.16 07:26:31 4: signalduino/msg READ: ;S%X;
2019.05.16 07:26:31 5: signalduino/noMsg Parse: ;S%X;
2019.05.16 07:26:31 1: /dev/ttyUSB0 disconnected, waiting to reappear (gateway)
2019.05.16 07:26:31 3: Setting gateway serial parameters to 38400,8,N,1
2019.05.16 07:26:31 1: /dev/ttyUSB0 reappeared (gateway)
2019.05.16 07:26:31 3: signalduino/init: get version, retry = 0
2019.05.16 07:26:31 5: signalduino SW: V
2019.05.16 07:26:41 3: signalduino/init: get version, retry = 1
2019.05.16 07:26:41 5: signalduino SW: V
2019.05.16 07:26:52 3: signalduino/init: get version, retry = 2
2019.05.16 07:26:52 5: signalduino SW: V
2019.05.16 07:27:02 3: signalduino/init: get version, retry = 3
2019.05.16 07:27:02 2: signalduino/init retry count reached. Closed
2019.05.16 07:27:02 2: signalduino closed
Er baut zwar eine Verbindung auf, bricht diese aber kurze Zeit später mit der Meldung "/dev/ttyUSB0 disconnected, waiting to reappear (gateway)" ab.
Kann mir jemand sagen, was da falsch läuft?
Danke schonmal im Voraus!!
Ändere erstmal das hier
https://wiki.fhem.de/wiki/SIGNALduino#USB-ID_ermitteln
und dann schau nach, ob das Problem damit schon gelöst wird.
Hallo andies,
danke für Deine Hilfe - nun sieht es so wie im Anhang bei mir aus...
Ist der Buchstabensalat in PARTIAL normal??
----2min später----
jetzt ist der Status wieder auf closed gegangen.... Keine Ahnung was da falsch läuft.... :-/
Das log:
2019.05.16 08:53:01 3: signalduino reset
2019.05.16 08:53:01 3: Opening signalduino device /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A700ePZP-if00-port0
2019.05.16 08:53:01 3: Setting signalduino serial parameters to 57600,8,N,1
2019.05.16 08:53:01 1: signalduino/define: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A700ePZP-if00-port0
2019.05.16 08:53:01 1: signalduino/init: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A700ePZP-if00-port0
2019.05.16 08:53:01 3: signalduino device opened
2019.05.16 08:53:02 3: signalduino/init: disable receiver (XQ)
2019.05.16 08:53:02 5: signalduino SW: XQ
2019.05.16 08:53:02 4: signalduino/msg READ: ;S%X;
2019.05.16 08:53:02 5: signalduino/noMsg Parse: ;S%X;
2019.05.16 08:53:02 1: /dev/ttyUSB0 disconnected, waiting to reappear (gateway)
2019.05.16 08:53:02 3: Setting gateway serial parameters to 38400,8,N,1
2019.05.16 08:53:02 1: /dev/ttyUSB0 reappeared (gateway)
2019.05.16 08:53:03 3: signalduino/init: get version, retry = 0
2019.05.16 08:53:03 5: signalduino SW: V
2019.05.16 08:53:13 3: signalduino/init: get version, retry = 1
2019.05.16 08:53:13 5: signalduino SW: V
2019.05.16 08:53:23 3: signalduino/init: get version, retry = 2
2019.05.16 08:53:23 5: signalduino SW: V
2019.05.16 08:53:33 3: signalduino/init: get version, retry = 3
2019.05.16 08:53:33 2: signalduino/init retry count reached. Reset
2019.05.16 08:53:33 3: signalduino reset
2019.05.16 08:53:33 3: Opening signalduino device /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A700ePZP-if00-port0
2019.05.16 08:53:33 3: Setting signalduino serial parameters to 57600,8,N,1
2019.05.16 08:53:33 1: signalduino/define: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A700ePZP-if00-port0
2019.05.16 08:53:33 1: signalduino/init: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A700ePZP-if00-port0
2019.05.16 08:53:33 3: signalduino device opened
2019.05.16 08:53:34 3: signalduino/init: disable receiver (XQ)
2019.05.16 08:53:34 5: signalduino SW: XQ
2019.05.16 08:53:34 4: signalduino/msg READ: ;S%X;
2019.05.16 08:53:34 5: signalduino/noMsg Parse: ;S%X;
2019.05.16 08:53:34 1: /dev/ttyUSB0 disconnected, waiting to reappear (gateway)
2019.05.16 08:53:34 3: Setting gateway serial parameters to 38400,8,N,1
2019.05.16 08:53:35 1: /dev/ttyUSB0 reappeared (gateway)
2019.05.16 08:53:35 3: signalduino/init: get version, retry = 0
2019.05.16 08:53:35 5: signalduino SW: V
2019.05.16 08:53:45 3: signalduino/init: get version, retry = 1
2019.05.16 08:53:45 5: signalduino SW: V
2019.05.16 08:53:55 3: signalduino/init: get version, retry = 2
2019.05.16 08:53:55 5: signalduino SW: V
2019.05.16 08:54:05 3: signalduino/init: get version, retry = 3
2019.05.16 08:54:05 2: signalduino/init retry count reached. Closed
2019.05.16 08:54:05 2: signalduino closed
Das Log ist komisch. Er verbindet sich, setzt die Verbindungsgeschwindigkeit auf
Setting signalduino serial parameters to 57600,8,N,1
um dann zu sagen
signalduino/init: disable receiver (XQ)
und dann fängt er wieder mit seinem tty-Ding da an. Das andere device mit tty ist gelöscht, richtig? Kannst du mal FHEM komplett neu starten?
Hallo,
ich betreibe selbst zwar einen Signalduino mit Arduino Pro Mini 16MHZ, 5V aber war es nicht so, dass wenn man den
ZitatHardware: Arduino Mini Pro 16MHZ, 5V, betrieben an 3V FTDI.
mit 3.3V betreibt er dann mit 8MHz taktet und eine andere Firmware benötigt?
im Wiki steht:
ZitatEs stehen auch für den UNO und PRO Mini Firmware-Dateien zur Verfügung.
Die ausgelieferte Firmware läuft nur auf Mikrocontrollern mit 16 MHz;
wer einen Mikrocontroller mit 8 MHz verwenden möchte, muss die Firmware selbst compilieren. Die SW ist auf github
nur so eine Idee, ob das stimmt sei mal dahingestellt.
MfG
Uwe
Hallo my-engel:
nein, das ist nicht so, denn der Arduino 5V wird mit einem Quarz getaktet, der bei 3,3V die gleiche Frequenz hat...
Hast du in der defmod die baudrate angegeben? Sieht nicht so aus, oder täusche ich mich? Die änderte sich nämlich auch.
Gesendet von iPhone mit Tapatalk Pro
Hallo,
hast du deine Verdrahtung überprüft?
( Anbindung Cc1101 usw )
Wenn du ohne FHEM den seriellen Monitor öffnest bei Arduino, siehst du dort was? Wenn nicht, stelle dort erst sicher, das du Signale empfangen kannst.
Gesendet von iPhone mit Tapatalk Pro
Hallo,
Zitatdenn der Arduino 5V wird mit einem Quarz getaktet, der bei 3,3V die gleiche Frequenz hat...
Wenn dem so ist, dann ist es ja gut ...
Ich habe gerade dieses noch gefunden:
https://forum.arduino.cc/index.php?topic=273893.msg1930129#msg1930129 (https://forum.arduino.cc/index.php?topic=273893.msg1930129#msg1930129)
MfG Uwe
Hallo zusammen.
Brauche mal eure Meinung.
Ich habe mir vor ca. 1 Jahr einen wemos d1 Mini mit esplink geflasht, diesen mit einen arduino nano verknüpft. Auf dem nano läuft die sw für ein Signal Duino. Als receiver habe ich einen cc1101 433mhz dran hängen. Bis vor kurzem lief alles ganz gut.
Jetzt habe ich das Problem, dass über den wlan Duino nix rein und raus geht.
Habe die Bauteile einzeln für sich geprüft.
Der esp funktioniert ohne Problem (alles ist gesockelt), der nano mit nem ftdi funktioniert. Habe das mit dem test Skript "led blinken" getestet. Die led auf dem Board vom nano funktioniert. Habe den cc1101 an einem anderen uC mit dem identischen Aufbau (wlanCUL mit cc1101) getestet, funktioniert. Auf dem anderen Gerät kann ich ohne Probleme Daten senden und empfangen.
Jedes Teil für sich funktioniert. Nur zusammen irgendwie nicht.
Hat jemand noch eine Idee wo ich da zum testen ansetzen kann?
Gruß Sascha
Gesendet von meinem E6653 mit Tapatalk
@my-engel:
Danke für den Hinweis. Ich werde es testweise mit einem 8 MHZ Arduino Mini Pro mit 3,3v versuchen. Ich berichte dann morgen!
Zitat
Hat jemand noch eine Idee wo ich da zum testen ansetzen kann?
Klingt nach Spannungsproblemen. Liegen da wirklich 3.3V an oder bricht das zusammen, wenn gesendet wird?
ZitatIch werde es testweise mit einem 8 MHZ Arduino Mini Pro mit 3,3v versuchen.
Wenn Du beim 8 MHZ Arduino Pro Mini mit 3,3v die nanoCul Verkabelung verwendest, ist dazu eine besondere Firmware notwendig (siehe 1.Beitrag):
set sduino flash https://raw.githubusercontent.com/Ralf9/SIGNALDuino/dev-r332_cc1101/firmware/SIGNALduino_3v3prominiCC1101_3321rc8.hexWenn Du die miniCUL Firmware verwenden möchtest:
Zitat von: Ralf9 am 14 März 2017, 23:10:25
Wenn eine miniCUL Firmware verwendet werden soll, dann muß:
GDO0 auf D2/PD2
GDO2 auf D3/PD3
LED auf D4/PD4
Bei 433 MHz muß A0/PC0 mit GND verbunden werden, wenn man ganz sicher gehen will, dann 50-100 Ohm als Strombegrenzung im Fehlerfall.
Gruß Ralf
Hallo,
Eine Frage. Könnt ihr mir sagen ob dieser Funk Schaltaktor mit dem Signalduion Stick funktioniert ?
Unter Protokoll war ja glaub intertechno aufgelistet.
https://www.funkschalter-intertechno.de/ITL-1000-Intertechno-Funk-Einbauschalter-Allrounder-bis-1000-W-Ein-Aus-oder-Abschaltautomatik-Potentialfrei
Wie sicher ist diese Verbindung ? Möchte damit meine Garagentor per FHEM steuern, über den ext. Taster Anschluss.
ZitatEine Frage. Könnt ihr mir sagen ob dieser Funk Schaltaktor mit dem Signalduion Stick funktioniert ?
Sollte eigentlich mit dem Signalduino oder Cul funktionieren, da in der Anleitung steht: "für alle Intertechno Sender"
ZitatWie sicher ist diese Verbindung ? Möchte damit meine Garagentor per FHEM steuern, über den ext. Taster Anschluss.
Die Sicherheit ist recht gering, das Sendesignal kann recht einfach z.B. mit einem Signalduino oder Cul und fhem aufgezeichnet und wieder gesendet werden.
Gruss Ralf
Zitat von: Ralf9 am 06 September 2019, 14:40:19
Die Sicherheit ist recht gering, das Sendesignal kann recht einfach z.B. mit einem Signalduino oder Cul und fhem aufgezeichnet und wieder gesendet werden.
Gruss Ralf
Hm gibt es was sichereres wenn man sich sowas selber smarter macht über FHEM und Co. ? Oder egal welchen Hersteller man da nimmt ? Wobei bei der Garage ist es nicht so schlimm denke ich. Was meinst du ?
Kann der Duino auch eine Wetterstation von Aldi oder Lidl erkennen ? Ich hatte ja Anfangs zig Geräte, unter anderem auch ein paar die mir Temps anzeigten. Hab die alle gelöscht und auch nur das Jaro Protokoll aktiviert.
Wisst ihr da was ? Oder war das dann irgendwas vom Nachbarn ?
Der Sduino kann inzwischen recht viele der Wetterstationen von Aldi oder Lidl erkennen.
Hier wird gerade die aktuelle Wetterstation von Lidl eingebaut:
https://github.com/RFD-FHEM/RFFHEM/issues/663
Gruß Ralf
Zitat von: Ralf9 am 07 Oktober 2019, 20:47:49
Der Sduino kann inzwischen recht viele der Wetterstationen von Aldi oder Lidl erkennen.
Hier wird gerade die aktuelle Wetterstation von Lidl eingebaut:
https://github.com/RFD-FHEM/RFFHEM/issues/663
Gruß Ralf
Welches Protokoll müsste ich den dafür reaktivieren. Dann kann ich bestimmt auch die Außentemperatur nutzen, um sie mir anzeigen zu lassen, so wie die Luftfeuchtigkeit. Indem Fall muss da nichts gepaired oder so werden, er kann einfach auf die Daten zugreifen und zeigt sie mir an.
ZitatWelches Protokoll müsste ich den dafür reaktivieren.
Das hängt von den Temperatursensoren ab die empfangen willst.
Welche Temperatursensoren/Wetterstationen hast Du?
GT-WS-04s und ein passenden Außensensor dazu.
https://www.pollin.de/p/funk-wetterstation-tr-ws-08s-b-ware-590358?&gclid=CjwKCAjwxOvsBRAjEiwAuY7L8n3e-tvAEsyL6nCpiXz9boAw7nV0_9Wfq90j9-Qn1wNucJAZS5jiZxoCcNAQAvD_BwE (https://www.pollin.de/p/funk-wetterstation-tr-ws-08s-b-ware-590358?&gclid=CjwKCAjwxOvsBRAjEiwAuY7L8n3e-tvAEsyL6nCpiXz9boAw7nV0_9Wfq90j9-Qn1wNucJAZS5jiZxoCcNAQAvD_BwE)
Der Außensensor sieht aus wie der GT_WT_02 von denen ich einige habe.
Die Protokoll ID ist die 0
Bräuchte ich da nicht mal die Innenstation um die Werte auszulesen ? Ich teste das morgen Mal. Danke
Zitat von: D3ltorohd am 07 Oktober 2019, 21:54:18
Bräuchte ich da nicht mal die Innenstation um die Werte auszulesen ? Ich teste das morgen Mal. Danke
@D3ltorohd
Die Innenstation kann nur empfangen und nicht senden. Es kann nur der aussensensor empfangen werden.
pejonp
Zitat von: Ralf9 am 07 Oktober 2019, 21:36:14
Der Außensensor sieht aus wie der GT_WT_02 von denen ich einige habe.
Die Protokoll ID ist die 0
Also hab den GT_WT_01. Klappt das mit dem auch, bis jetzt wurde kein neues Gerät angelegt. Vllt noch ein wenig warten, bis er was sendet.
ZitatAlso hab den GT_WT_01. Klappt das mit dem auch, bis jetzt wurde kein neues Gerät angelegt.
Damit es per autocreate angelegt wird, müssen innerhalb 180 sek 3 Nachrichten empfangen werden.
Du kannst mal die bWidth z.B. auf 541KHz erhöhen.
Falls nichts angelegt wird, kannst Du mit verbose 4 mal die rawmsg posten.
Hier ist als Beispiel eine rawmsg von einer meiner GT_WT_02
MS;P1=-9108;P2=581;P3=-2091;P4=-4140;D=2123232323242423232323232323232323242423232324232323242424242323242324232424;CP=2;SP=1;R=12;O;s=4;m1;Gruß Ralf
Hm, kann sein das das Teil von mir gar nicht mehr richtig funktioniert. Ich hatte 2 neue Geräte drin, in einem stand nicht wirklich viel, im anderen das nannte sich was mit Auriol hatte ich ne Temp von -67°, das konnte dann auch nicht mein Thermometer sein. Hab nun alles wieder gelöscht.
laut dem hier
https://forum.fhem.de/index.php/topic,102942.0.html
müsste das GT_WT_01 mit dem model Prologue funktionieren.
Gruß Ralf
Mein SignalESP geht ständig auf closed, obwohl er noch im WLAN erreichbar ist. :-[
Wie kann ich den SignalESP neu flashen? Mit welchem Tool und mit welcher Firmware?
Ich habe den SignalESP gebraucht gekauft.
Vielen Dank.
Grüße Mave
Hi Mave,
Schau mal im passenden Thread dazu :)
Flashen:
https://forum.fhem.de/index.php/topic,83273.msg925099.html#msg925099
FactoryReset:
https://forum.fhem.de/index.php/topic,83273.msg925121.html#msg925121
Ronny
Vielen Dank.
Ein erneutes flashen hat bis jetzt Erfolg gebracht.
Seit gestern kein disconnect und kein closed mehr..... :)
Hi,
Super.
Hattest Du vorher mal den Factory Reset probiert ? ich würde vermuten, das wäre schon ausreichend gewesen ;)
Ronny
So ich bin auf der Suche nach einem Funk Temp und Helligkeitssensor, gibt es da was, was mit dem Duino läuft und dessen Werte ich dann in Fhem zur Verfügung habe ?
So eine Wetterstation brauche ich nicht, da mir das was dann das Tablet anzeigt ausreicht. Bräuchte halt nen Sensor, der Temp und Helligkeit messen können sollte. Wenn noch Feuchtigkeitsensor usw dabei wäre, auch nicht schlecht. Das sollte aber auch nicht zu teuer sein. Hätte das nur gern mit in meiner FTUI als Anzeige. Die Helligkeit bräuchte ich für das ASC Modul.
@D3ltorohd
wenn der GT_WT_01 noch funktioniert (dies siehst Du ja an Deiner Innenstation), würde ich mir gerne die rawmsg anschauen.
Dazu den sduino auf verbose 4 setzen.
Wenn Du nun im Eventmonitor die Anzeige des FHEM log aktivierst, sieht Du dort die rawmsg
z.B.
2019.10.27 12:09:22.361 4 : sduinoRXB/msg READ: MS;P2=-2073;P3=560;P4=-4131;P5=-9019;D=3532343234323432323432323432323232343432343434323432343434343232343434323434;CP=3;SP=5;O;b75;s4;m0;
2019.10.27 12:09:22.675 4 : sduinoRXB/msg READ: MS;P2=-2069;P3=569;P4=-4106;P5=-9053;D=3532343234323432323432323432323232343432343434323432343434343232343434323434;CP=3;SP=5;O;s4;m1;
2019.10.27 12:09:22.845 4 : sduinoRXB/msg READ: MS;P2=-2073;P3=581;P4=-4115;P5=-9024;D=3532343234323432323432323432323232343432343434323432343434343232343434323434;CP=3;SP=5;e;s4;m2;
2019.10.27 12:09:22.846 4 : sduinoRXB/msg READ: MS;P2=-2073;P3=581;P4=-4115;P5=-9024;D=3532343234323432323432323432323232343432343434323432343434343232343434323434;CP=3;SP=5;e;s4;m3;
Damit Du die rawmsg besser dem GT_WT_01 zuordnen kannst,
kannst Du dazu beim GT_WT_01 schauen, wenn er sendet oder die Tx-Taste drücken
Gruß Ralf
Ich denke das Teil ist hinüber, der zeigt Temps an, die hier definitiv nicht zutreffen und das sind nicht nur ein paar Grad unterschied.
Daher bin ich ja auf der Suche nach etwas anderem.
Dies passt hier nicht so richtig rein, hier gehts überwiegend um die Firmware.
Hier passt es besser:
https://forum.fhem.de/index.php/topic,58397.msg987355.html#msg987355
Ich kann zum Testen noch vom signalduino rawmsg von ITv3 für on und off gebrauchen.
Liest hier zufällig jemand mit der einen signalduino und eine Intertechno v3 Fernbedienung hat?
Die rawmsg sieht ungefähr so aus:
MS;P1=230;P2=-2300;P3=-230;P4=-1150;P6=-9200;D=121314131414131413141313141413141313141413131414131314131414131413131414131314131414131314141314131413131413141413131413141314131416;CP=1;SP=2;O;m1;
Gruß Ralf
hoch schieb.
Liest hier niemand mit der einen signalduino und eine Intertechno v3 Fernbedienung hat?
Hi Ralf,
mitlesen schon.
Ich würd gern helfen, hab aber leider keine V3 Fernbedienung :/
Ronny
ZitatIch kann zum Testen noch vom signalduino rawmsg von ITv3 für on und off gebrauchen.
Hat sich inzwischen erledigt, ich habe die rawmsg erhalten.
Gruß Ralf
Hallo Ralf,
vielleicht kannst du mir weiterhelfen. Ich habe mir vor Jahren eine Beleuchtung (Weihnachtskugel) mit einem ATiny13a zusammengebaut. (http://danyk.cz/avr_rdo_en.html)
Ich konnte diese letztes Jahr auch noch mit dem Signalduino schalten. Jetzt geht es nicht mehr (version: V 3.3.1-experimental SIGNALduino - compiled at Jun 16 2019 00:08:41)
Beim senden des Strings
W433:.* set SIGRBX raw SR;;R=3;;P0=419;;P1=-230;;P2=105;;P3=-1104;;D=01212101230101012121212101012121012121012301010121212121010121210121210123010101212121210101212101212101230101012121212101012121012121012301010121212121010121210121210123010101212121210101212101212101230101012121212101012121012121012301010121212121010121;;
wird das im Log angezeigt. ??
2019.12.01 17:33:52.084 4: SIGRBX/keepalive ok, retry = 0
2019.12.01 17:33:53.554 4: set SIGRBX raw SR;R=3;P0=419;P1=-230;P2=105;P3=-1104;D=01212101230101012121212101012121012121012301010121212121010121210121210123010101212121210101212101212101230101012121212101012121012121012301010121212121010121210121210123010101212121210101212101212101230101012121212101012121012121012301010121212121010121;
2019.12.01 17:33:53.555 5: AddSendQueue: SIGRBX: SR;R=3;P0=419;P1=-230;P2=105;P3=-1104;D=01212101230101012121212101012121012121012301010121212121010121210121210123010101212121210101212101212101230101012121212101012121012121012301010121212121010121210121210123010101212121210101212101212101230101012121212101012121012121012301010121212121010121; (1)
2019.12.01 17:33:53.658 5: SIGRBX SW: SR;R=3;P0=419;P1=-230;P2=105;P3=-1104;D=01212101230101012121212101012121012121012301010121212121010121210121210123010101212121210101212101212101230101012121212101012121012121012301010121212121010121210121210123010101212121210101212101212101230101012121212101012121012121012301010121212121010121;
2019.12.01 17:33:53.669 4: SIGRBX SendrawFromQueue: msg=SR;R=3;P0=419;P1=-230;P2=105;P3=-1104;D=01212101230101012121212101012121012121012301010121212121010121210121210123010101212121210101212101212101230101012121212101012121012121012301010121212121010121210121210123010101212121210101212101212101230101012121212101012121012121012301010121212121010121;
2019.12.01 17:33:53.718 4: SIGRBX/msg READ: SR;R=3;P0=419;P1=-230;P2=105;P3=-1104;send cmd to long
2019.12.01 17:33:53.718 5: SIGRBX/noMsg Parse: SR;R=3;P0=419;P1=-230;P2=105;P3=-1104;send cmd to long
2019.12.01 17:33:53.720 5: SIGRBX/msg READ: regexp=^S(?:R|C|M);. cmd=sendraw msg=SR;R=3;P0=419;P1=-230;P2=105;P3=-1104;send cmd to long
2019.12.01 17:33:53.720 4: SIGRBX/read sendraw answer: SR;R=3;P0=419;P1=-230;P2=105;P3=-1104;send cmd to long
2019.12.01 17:33:53.722 4: SIGRBX/HandleWriteQueue: nothing to send, stopping timer
2019.12.01 17:33:56.758 4: set SIGRBX raw SR;R=3;P0=419;P1=-230;P2=105;P3=-1104;D=01212101230101012121212101012121012121012301010121212121010121210121210123010101212121210101212101212101230101012121212101012121012121012301010121212121010121210121210123010101212121210101212101212101230101012121212101012121012121012301010121212121010121;
2019.12.01 17:33:56.758 5: AddSendQueue: SIGRBX: SR;R=3;P0=419;P1=-230;P2=105;P3=-1104;D=01212101230101012121212101012121012121012301010121212121010121210121210123010101212121210101212101212101230101012121212101012121012121012301010121212121010121210121210123010101212121210101212101212101230101012121212101012121012121012301010121212121010121; (1)
2019.12.01 17:33:56.862 5: SIGRBX SW: SR;R=3;P0=419;P1=-230;P2=105;P3=-1104;D=01212101230101012121212101012121012121012301010121212121010121210121210123010101212121210101212101212101230101012121212101012121012121012301010121212121010121210121210123010101212121210101212101212101230101012121212101012121012121012301010121212121010121;
2019.12.01 17:33:56.872 4: SIGRBX SendrawFromQueue: msg=SR;R=3;P0=419;P1=-230;P2=105;P3=-1104;D=01212101230101012121212101012121012121012301010121212121010121210121210123010101212121210101212101212101230101012121212101012121012121012301010121212121010121210121210123010101212121210101212101212101230101012121212101012121012121012301010121212121010121;
2019.12.01 17:33:56.920 4: SIGRBX/msg READ: SR;R=3;P0=419;P1=-230;P2=105;P3=-1104;send cmd to long
2019.12.01 17:33:56.921 5: SIGRBX/noMsg Parse: SR;R=3;P0=419;P1=-230;P2=105;P3=-1104;send cmd to long
2019.12.01 17:33:56.922 5: SIGRBX/msg READ: regexp=^S(?:R|C|M);. cmd=sendraw msg=SR;R=3;P0=419;P1=-230;P2=105;P3=-1104;send cmd to long
2019.12.01 17:33:56.922 4: SIGRBX/read sendraw answer: SR;R=3;P0=419;P1=-230;P2=105;P3=-1104;send cmd to long
2019.12.01 17:33:56.924 4: SIGRBX/HandleWriteQueue: nothing to send, stopping timer
Vielen Dank.
Jörg
Zitatsendraw answer: SR;R=3;P0=419;P1=-230;P2=105;P3=-1104;send cmd to long
Das Sendekommando ist zu lang, bei der verwendeten Firmware ist die Länge auf 255 begrenzt.
Bei meiner V 3.3.2.1-rc9 ist je nach verwendeter Hardware die Länge auf 350 oder 400 begrenzt:
sduinoRXB/noMsg Parse: cmd to long! (max 400)Mir ist nicht klar, warum Du so ein langes Sendekommando verwendest, funktioniert dies nicht?
SR;;R=25;;P0=419;;P1=-230;;P2=105;;P3=-1104;;D=30101012121212101012121012121012;;Gruß Ralf
Hallo Ralf,
habe die SignalDuino auf Version beim CC1101 (V 3.3.2.1-rc9 SIGNALduino cc1101 - compiled at Jun 16 2019 20:18:01) und beim RFM83C (V 3.3.2.1-rc9 SIGNALduino - compiled at Jun 16 2019 18:11:42) umgestellt. Und Version
00_SIGNALduino.pm 10488 2019-07-10 12:00:00Z v3.4.0
Jetzt geht der alte String wieder.
Jörg
Ich würde gerne eine it 3500 Steckdose anlernen, aber irgendwie will die nicht. Autocreate ist an, an der Steckdose habe ich den Knopf länger gedrückt, danach fängt sie an mit blinken, aber es wird kein device angelegt. Ich weiß nicht mehr wie ich das bei der it1500 gemacht hab, da hat es damals auch geklappt.
EDIT:.
Hab es hinbekommen, man musste die ja erst mal anlegen und dann per On anlernen.
define Steckdose_Dunstabzug IT <26 Bit> <2Bit> <4 bit>
Hallo,
ich bin neu hier und versuche ein Protokoll via V 3.3.2.1-rc9 zu dekodieren (GFSK Modulation, Signalduino Nano, CC1101)
Mit der Standard Signalduino Firmware kann ich einen Teil des Protokolles dekodieren, allerdings ist der Block sehr lang und diese Firmware gerät out of Sync.
Mit Eurer V 3.3.2.1-rc9 habe ich jetzt das Problem, dass ich, sobald ich eine Taste an der FB drücke nur noch Schrott sehe, wie wenn Baudrate etc. falsch eingestellt ist.
Unsupported command
Unsupported command
Mu;;£ì;´
;Ä;ø;§;C1;RF6;DRg;p;
Mu;CCBSCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCsCCCsB;p;
Mu; ôÈ;
;¢î;¨;´;Ô;¦
;ü;C1;RF6;D42Vvp;p;
Mu;ø;¡;
;³¥ì;¶
;¼;C2;RF6;D###################################################################%##&s%#%%;p;
Mu;r2P2;p;
Mu; øÈ;ø;¢î;¤;´¨;Ô;¦
;ø;C1;RF6;D42Vvp;p;
Mu;ø;¡;
;³¥ì;¶
;¼;C2;RF6;D###################################################################%##&s%#%%;p;
Mu;r2P2;p;
Mu;°
¢î;³
;¼;
ü;¦;¦;C1;RF6;d!4!a!' ;p;
Mu; ;¡£
;ó;;´CCBSCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCcCCCcBc`;p;
Mu;r2P2;p;
Mu; àÈ;;¢î;¨;´¡;Ô;¦42Vvp;p;
Mu;ø;¡;
;³¥ì;¶
;À;C2;RF6;D###################################################################%##&s%#%%;p;
Normale Befehle wie C99 beantwortet die Firmware jedoch lesbar.
Allerdings kommt mit meinen korrigierten EEPROM Werten folgende Meldung beim Booten
Using sFIFO
Reading values from eeprom
CCInit ok. ccVer=20 ccPartnum=0
Starting timerjob
cc1101 is not correctly set. Please do a factory reset via command e
Was bedeutet hier eigentlich "Using sFIFO"?
Hier ist beschrieben, was genau ich machen will:
https://github.com/RFD-FHEM/RFFHEM/issues/711#issuecomment-566156624 (https://github.com/RFD-FHEM/RFFHEM/issues/711#issuecomment-566156624)
ZitatMit Eurer V 3.3.2.1-rc9 habe ich jetzt das Problem, dass ich, sobald ich eine Taste an der FB drücke nur noch Schrott sehe, wie wenn Baudrate etc. falsch eingestellt ist.
Mu;;
Da ist die Datenkomprimierung (config: Mred=1) noch eingeschaltet, dies ist auch am kleinen "u" erkennbar.
Damit wird die Ausgabe der sehr langen MU-Nachrichten aktiviert und die Datenkomprimierung abgeschaltet:
get sduino raw CEO
get sduino raw CDREin get config ergibt dann folgendes:
config: MS=1;MU=1;MC=1;Mred=0;MuNoOverflow=1;...Gruß Ralf
Kaum macht man es richtig schon klappts ;) (hab mir die Freiheit genommen und "get" durch "set" ersetzt ;D
Danke für die Hilfe, dann mach ich mich mal ans dekodieren
MU;P0=-784;P1=260;P2=-170;P4=-364;P5=-1436;P6=1696;P7=868;CP=1;R=246;D=121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121412121562141270;p;
MU;P0=-18532;P1=1724;P2=-784;P3=-156;P4=259;P5=-364;P6=-1311;P7=886;CP=4;R=246;D=6764343454340434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434543434613454372;p;
MU;P0=-18532;P1=1724;P2=-780;P3=-159;P4=256;P5=-366;P6=-1310;P7=888;CP=4;R=246;D=6764343454340434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434543434613454372;p;
MU;P0=-18544;P1=1724;P2=-784;P3=-159;P4=256;P5=-366;P6=-1311;P7=886;CP=4;R=246;D=6764343454340434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434543434613454372;p;
MU;P0=-18540;P1=1724;P2=-784;P3=-156;P4=257;P5=-366;P6=-1312;P7=888;CP=4;R=246;D=6764343454340434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434543434613454372;p;
MU;P0=-18528;P1=1724;P2=-784;P3=-156;P4=260;P5=-365;P6=-1307;P7=888;CP=4;R=246;D=6764343454340434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434543434613454372;p;
MU;P0=-18544;P1=1724;P2=-784;P3=-156;P4=260;P5=-367;P6=-1304;P7=888;CP=4;R=246;D=6764343454340434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434543434613454372;p;
MU;P0=-18540;P1=1732;P2=-784;P3=-156;P4=258;P5=-364;P6=-1306;P7=888;CP=4;R=246;D=6764343454340434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434543434613454372;p;
MU;P0=-18536;P1=1720;P2=-784;P3=-156;P4=261;P5=-365;P6=-1305;P7=888;CP=4;R=246;D=6764343454340434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434543434613454372;p;
MU;P0=-18524;P1=1724;P2=-784;P3=-156;P4=260;P5=-366;P6=-1309;P7=886;CP=4;R=246;D=6764343454340434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434543434613454372;p;
MU;P0=-18532;P1=1720;P2=-784;P3=-157;P4=258;P5=-365;P6=-1310;P7=888;CP=4;R=246;D=6764343454340434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434543434613454372;p;
MU;P0=-18524;P1=1724;P2=-784;P3=-156;P4=260;P5=-365;P6=-1309;P7=890;CP=4;R=246;D=6764343454340434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434543434613454372;p;
MU;P0=-18528;P1=-156;P2=1724;P4=259;P5=-364;P6=-1311;P7=888;CP=4;R=246;D=676414145414041414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141454141462145417;p;
Kann man das eigentlich auch alles innerhalb einer Zeile ausgeben lassen (würde mir das dekodieren erleichtern)
Da sind jetzt aber keine sehr langen MU-Nachrichten dabei.
Das p am Ende bedeutet daß der Patternspeicher (P0-P7) übergelaufen ist
Hinter den P7 und P2 am Ende folgen wahrscheinlich noch P8 und P9
Gruß Ralf
Kannst Du abschätzen wieviele verschiedene Pattern noch fehlen, würde es reichen, wenn es noch ein P8 und P9 geben würde?
Nachtrag:
ZitatWas bedeutet hier eigentlich "Using sFIFO"?
Dies ist nur eine Debugausgabe, daß für die empfangenen Pulse ein Fifo verwendet wird.
Zitatcc1101 is not correctly set. Please do a factory reset via command e
Dies kommt daher:
bool regCheck()
{
return (readReg(CC1100_PKTCTRL0, CC1101_CONFIG) == initVal[CC1100_PKTCTRL0]) && (readReg(CC1100_IOCFG2, CC1101_CONFIG) == initVal[CC1100_IOCFG2]);
}Gruß Ralf
Hab mir das mal angeschaut. Es fehlen tatsächlich Bits.
Erwarten würde ich folgende Botschaft:
17mal 0xaa, dann 0x54 0x07 0xfa 0x5e 0x14 0x75 0xcc 0x0f 0x02 0xa9
Erhalten tu ich:
17mal 0xaa, dann 0x54 0x07 0xfa 0x5e dann ist Zeile 1 fertig und es kommen ab Zeile2 nicht mehr die erwarteten Werte
Das Problem könnte sein, dass der Sender nach der ersten Botschaft (=was ich erwarten würde) erst mal Pause macht (das sind die ca. 18500 usec) d.h. nichts sendet.
Variabel sind im Block nur die 0x14, 0x75 und 0xa9 (am Ende). Diese können beliebige Werte zwischen 0x00 und 0xff annehmen, daraus ergeben sich die möglichen Pattern.
Wenn ich die doppelten Pattern mal rausstreiche ergibt sich:
MU;P0=-784;P1=260;P2=-170;P4=-364;P5=-1436;P6=1696;P7=868;
MU;P0=-18532;P1=1724;P2=-784;
MU;P1=-156;P6=-1311;
Die Frage ist nur wie groß die Toleranz ist.
Bsp.:
Zeile 1 P2=-170 ist das selbe Pattern wie Zeile 3 P1=-156, d.h. hier sieht man einen Jitter von 14usec
Zeile 1 P6=1696 ist das selbe Pattern wie Zeile 2 P1=1724 d.h. 28usec Jitter
Ich könnte ja schauen ob ich mit 3...5 zusätzlichen Pattern zurechtkomme sofern mir jemand die Firmware ändern kann
ZitatDie Frage ist nur wie groß die Toleranz ist.
Bsp.:
Zeile 1 P2=-170 ist das selbe Pattern wie Zeile 3 P1=-156, d.h. hier sieht man einen Jitter von 14usec
Zeile 1 P6=1696 ist das selbe Pattern wie Zeile 2 P1=1724 d.h. 28usec Jitter
Die Toleranz ist 0.2, d.h. die Pattern sind noch in der Toleranz.
ZitatIch könnte ja schauen ob ich mit 3...5 zusätzlichen Pattern zurechtkomme sofern mir jemand die Firmware ändern kann
Ich habe es mir mal angeschaut, ich kann es mit überschaubarem Aufwand einbauen,
Es gibt dann 2 zusätzliche Konfigurationsvariablen: maxnumpat und maxpulse
Mit maxnumpat kann man dann die max Anzahl Pattern bis auf 16 erhöhen (P0-PF Hex), default ist 8.
Mit maxpulse kann man die max Pulslänge (default -32001) verkleinern, ab der ein Ende erkannt wird. Z.B. mit maxpulse 17000 wird -18532 als Ende erkannt.
Kannst Du abschätzen ob es evtl noch mehr Protokolle gibt wo die max Anzahl Pattern von 8 nicht ausreicht?
Gruß Ralf
Hallo Ralf,
Mit 0.2 meist Du 1/5tel des Patzers also z.b 20% von 170 usec?
Bzgl. der Protokolle:
Abschätzen kann ich das nicht, je nach Länge des Protokolls müssten es m .e. aber deutlich mehr wie 8 sein, da ja beliebige Bitkombinationen kommen können.
Nimm mal eine variable Botschaft von nur 3 Bytes und überlege Dir welche Pattern auftreten können, da bist Du schnell deutlich über 10. Ein Maxpulse von 8000 für den ersten Test wäre mir am liebsten
ZitatMit 0.2 meist Du 1/5tel des Patzers also z.b 20% von 170 usec?
ja
ZitatNimm mal eine variable Botschaft von nur 3 Bytes und überlege Dir welche Pattern auftreten können, da bist Du schnell deutlich über 10.
Mir ist das Prinzip nicht klar.
Bei OOK habe ich 2 Pattern für Bit=1 und zwei Pattern für Bit=0, anscheinend ist es hier anders.
Da geht es mir genauso mit OOK, deshalb reden wir vielleicht etwas aneinander vorbei.
Ich erklär mal was der CC1101 mit dem GFSK Verfahren beim Demodulieren macht:
- eigentlich funktioniert der Baustein in diesem Mode wie eine synchrone serielle Schnittstelle. D.h. am GDO2 Pin kommen direkt die Bits hintereinander raus. Normalerweise gibt es einen zweiten Pin als Takt den ebenfalls der CC1101 liefert, d.h. mit jedem Takt kommt ein Bit (High oder Low, 8 Bits ergeben dann direkt ein Byte der Empfangsbotschaft ohne weitere Umrechnungen)
- Da beim Signalduino der Takt Pin nicht angeschlossen ist bzw. nicht ausgewertet wird, habe ich den CC1101 auf assynchronen Mode umkonfiguriert, dann reicht ein Pin aus (GO2), allerdings muss man die Taktzeiten angeben (das empfangene und demodulierte Signal wird dann mit Faktor 8 abgetastet). Der Takt vom Sender und Empfänger können leicht unterschiedlich sein, das ist vermutlich der Grund warum die High-/Low Zeiten nicht 100%ig identisch sind
- Der Signalduino sieht als Pattern dann aber die unterschiedlichen Bitkombinationen, und die sind dann abhängig vom der Empfangenen Botschaft
- Bsp.: 1. Byte = 0x00, 2.Byte = 0xFF, 3.Byte = 0x00 (also jeweils 8 Bit 1 oder 8 Bit 0)
Als Pattern würdest du dann 8x die Bitzeit für "1" und 8x die Bitzeit für "0" finden. Kommt direkt danach z.B. als:
1. Byte 0x00, 2.Byte = 0X00 und als 3. Byte 0xFF würdest Du noch das Pattern für 16x "1" dazubekommen usw.
(das Patter für 8x "0" hast Du ja schon)
Jetzt können aber auch die einzelnen Bits inerhalb eines Bytes unterschiedlich sein, d.h. die Pattern die Du findest sind beliebig unterschiedlich, je nach empfangenen Bits - Ich vermute mal, dass beim OOK Verfahren die Bits Pulsweitenmoduliert sind, d.h. Du findest immer nur 4 verschiedene Pattern
2 Pattern für die Low und High Zeit des "0" Bits, und nochmal 2 Pattern für das "1" Bit. Dann kommt evt. noch der Sync Impuls dazu und das sollte es dann schon sein. - Wie gesagt, bisher nur Vermutung, ich lese mich gerade ein.
Hoffe damit konnte ich zumindest den GFSK Mode erklären.
Da bei meinem Anwendungsfall max. 2 Bytes in folge "variabel" sind, sollten 16 Pattern völlig ausreichen. Zumindest für meinen Anwendungsfall. Wenn man den einen FSK Mode wirklich implementieren möchte, sollte man sich aber überlegen ob man hierfür nicht die Pattern vermisst, sondern die synchrone serielle Schnittstelle in Betrieb nimmt und die Bitfolgen direkt weitergibt.
Bleibt für mich erstmal eine Frage:
Kannst Du mir evt. eine Signalduino Variante erstellen, die 16 Pattern erfassen kann? Ich könnte dann zumindest sagen ob es für meinen Anwendungsfall ausreicht.
ZitatKannst Du mir evt. eine Signalduino Variante erstellen, die 16 Pattern erfassen kann?
Bis zu 16 Pattern kann ich einbauen, da dies Hex ist, über 16 wird aufwändig.
Welche Hardware verwendet Du, einen nano?
ja
Nachtrag: Nano mit CC1101 8)
Ich habe eben mal nachgelesen, GFSK und OOK funktionieren wie von mir oben beschrieben
hier ist eine neue Version 3.3.2.2-rc10
mit "?S" bekommst Du
CSfifolimit= CSmcmbl= CSmscnt= CSmuoverflmax= CSmaxnumpat= CSmuthresh= CSmaxpulse=
dann
CDR
CEO
CSmaxnumpat=15
CSmaxpulse=10000
ein "CG" sollte dann so aussehen
MS=1;MU=1;MC=1;Mred=0;MuNoOverflow=1;Mdebug=1_MScnt=4;MuOverflMax=3;maxNumPat=15;maxPulse=-10000;MdebFifoLimit=120/140
Ich musste mir was basteln damit ich das mit den Pattern testen konnte:
MU;P0=-1100;P1=200;P2=-200;P3=300;P4=-300;P5=525;P6=-466;P7=-600;P8=800;P9=-800;PA=400;PB=1100;CP=5;R=0;D=1234565789561234565789561254A65789561234A657B08956;e;
Nachtrag:
mit "CSmaxpulse=0" wird es auf Default 32001 gesetzt
Gruß Ralf
Ich denke ich habe es jetzt kapiert, wie das mit dem asynchronen Auslesen, der im cc1101 schon demodulierten Bits funktioniert.
Für alle Zustände von einem Byte werden dann 8 positive und 8 negative Pattern benötigt.
Wenn nicht alle Zustände vorkommen sollten eigentlich 16 Pattern reichen.
Dies ist aber recht umständlich, einfacher ist es wie es im nativen Modus vom cul gemacht wird, der Aufwand dies im Signalduino einzubauen, falls Bedarf besteht, müsste sich in Grenzen halten.
CC1100_IOCFG2, 0x01
"Associated to the RX FIFO: Asserts when RX FIFO is filled at or above the RX FIFO threshold or the end of packet is reached. De-asserts when the RX FIFO is empty."
damit die Anzahl Bytes des FIFOs auslesen
len = cc1100_readReg( CC1100_RXBYTES ) & 0x7f; // read len, transfer RX fifo
und dann die Daten aus dem FIFO auslesen.
Mir ist noch nicht klar wie Du den Anfang und das Ende einer Nachricht erkennst.
Gruß Ralf
ja, genau, meine Kopp FW nutzt das Fifo.
Den Anfang erkenne ich über das Sync Pattern. Das ist auf "AA 54" programmiert.
Eine normale Empfangsbotschaft sieht z.B. so aus (nur die Fetten Bytes sind variabel (bei einem einzelnen Sender, ein anderer Sender hat evt. andere Codes).
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA 54 07 FA 5E 1d 30 cc 0f 2d 23
Die "AA" am Anfang sind die Preamble, der CC1101 nutzt diese Phase u.A. zum Einregeln der Empfangsverstärkung
Findet der Empfangsbaustein ein Bitmuster mit "AA 55" (das Sync Pattern) werden alle weiteren Bits ausgegeben, jeweils 8 Bit. das erste Byte das dann im Fifo steht ist die 07. In diesem Protokoll ist diese Zahl die Längenangabe, d.h. man muss nur noch die nachfolgenden Bytes zählen und hat dann komplette Botschaft. Das letzte Byte ist wiederum die XOR Checksumme.
Aber wie gesagt, ich habe dieses Protokoll im CUL schon realisiert und möchte mir eine alte Variante davon anschauen.
Damit sind wir wieder bei meinem Thema.
Deine neue Firmware habe ich aufgespielt. Sie funktioniert auch schon fast richtig, allerdings passiert an einer Stelle ein Fehler diesen Fehler gab es vorher an dieser Stelle nicht.
Ich kann jetzt die komplette Boschaft mit dem Signalduino empfangen. Allerdings geht eine Null zwischen Syncpattern AA 54 und Blocklänge 07 verloren, d.h. alle nachfolgenden Bytes sind um eine Stelle nach links verschoben.
Kurios ist, dass das genau nach dem Syncpattern passiert und reproduzierbar jedes mal.
Das Sync Pattern dürfte eigentlich nur aktiv sein wenn das Fifo aktiv ist, uns beim Signalduino also nicht stören.
Ich schau mir nochmal die Konfiguration an.
Diese Stelle hatte bei Deiner alten Software funktioniert, allerdings kam dann dort nach "FA 5E" fast jedes Mal der Überlauf in die nächste Zeile (d.h. kein vollständiger Code)
Ich schau mir nochmal meine Konfiguration an, vielleicht finde ich doch noch ein Fehler.
Anbei noch meine Excel zur Auswertung
Nachtrag:
so sehen jetzt die Empfangsdaten aus (ich habe nur MU Botschaften zugelassen):
MU;P0=-2960;P1=260;P2=-156;P3=-364;P4=-1253;P5=1728;P6=889;P7=-784;P8=471;P9=680;CP=1;R=246;D=01212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121213121214521312676383129384641212838;e;
MF=140
MU;P0=-18756;P1=260;P2=-1239;P3=1724;P4=-155;P5=-364;P6=892;P8=468;CP=1;R=246;D=0123415146214141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141514141234151462621414858;e;
MF=139
MU;P0=259;P1=-159;P2=-366;P3=-1412;P4=1724;P5=888;CP=0;R=246;D=0101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101020101034102015;e;
MU;P0=-18740;P1=260;P2=-156;P4=-364;P5=-1253;P6=1724;P7=892;P8=-780;P9=469;PA=680;CP=1;R=246;D=0121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121412121562141278749412A495751212949;e;
MF=140
MU;P0=-18756;P1=260;P2=-1241;P3=1724;P4=-156;P5=-364;P6=888;P7=472;CP=1;R=246;D=0123415146214141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141514141234151462621414757;e;
MF=139
MU;P0=-18752;P1=259;P2=-1256;P3=1728;P4=-156;P5=-364;P6=886;P7=-784;P8=468;P9=680;CP=1;R=246;D=01234151467141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141415141412341514676585149582621414858;e;
MF=140
MU;P0=-18736;P1=259;P2=-1237;P3=1728;P4=-155;P5=-368;P6=892;P7=468;CP=1;R=246;D=0123415146214141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141514141234151462621414757;e;
MF=139
MU;P0=-18736;P1=261;P2=-1253;P3=1724;P4=-156;P5=-365;P6=888;P7=-784;P8=468;P9=680;CP=1;R=246;D=01234151467141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141415141412341514676585149582621414858;e;
MF=140
MU;P0=-18756;P1=260;P2=-1239;P3=1724;P4=-156;P5=-364;P6=890;P7=470;CP=1;R=246;D=0123415146214141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141514141234151462621414757;e;
MF=139
MU;P0=-18748;P1=260;P2=-1255;P3=1724;P4=-156;P5=-364;P6=888;P7=-784;P8=469;P9=680;CP=1;R=246;D=01234151467141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141415141412341514676585149582621414858;e;
MF=140
MU;P0=-18524;P1=260;P2=-1241;P3=1724;P4=-156;P5=-364;P6=888;P7=468;CP=1;R=246;D=0123415146214141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141514141234151462621414757;e;
MF=139
MU;P0=-18736;P1=259;P2=-1254;P3=1724;P4=-157;P5=-363;P6=888;P7=-784;P8=468;P9=680;CP=1;R=246;D=01234151467141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141415141412341514676585149582621414858;e;
MF=140
MU;P0=-18752;P1=260;P2=-1242;P3=1728;P4=-157;P5=-363;P6=888;P7=466;CP=1;R=246;D=0123415146214141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141514141234151462621414757;e;
MF=137
Ein Problem könnte sein, daß der FIFO in dem die empfangenen Pulse gepuffert werden, ab und zu überläuft, er kann 140 Pulse puffern.
Die Ausgabe "MF=140" bedeutet, daß der FIFO voll ist oder übergelaufen ist.
Das Problem verursachen wahrscheinlich die Pulse mit ca 200uS oder kleiner. Die Pulse kommen schneller rein als sie verarbeitet und mit einer Baudrate von 57600 ausgegeben werden können.
(260+156)/2=208
Gruß Ralf
Du treibst damit einen recht großen Aufwand, das umrechnen in der Exceltabelle sieht recht aufwändig aus.
Wahrscheinlich ist es einfacher die Routinen zum Auslesen vom FIFO des cc11101 in den Signalduino einzubauen.
Ich würde auch gerne damit etwas experimentieren, ich habe aber keinen GFSK Sender.
Mit der Excel Tabelle hast Du schon recht, da steck relativ viel Aufwand drin (Vorarbeiten hatte ich schon gemacht)
Allerdings gibt mir die Tabelle einen sehr guten Einblick in die Details.
D.h. ich kann Zeiten prüfen und nachschauen was schief geht, so konnte ich z.B. sehen, dass genau an einer Stelle exakt eine "0" fehlt.
Bzgl. der seriellen Schnittstelle (SS):
Ist die SS nicht als Ringpuffer programmiert?, müssen die Pattern tatsächlich so über die SS übertragen werden (in Echtzeit) wie die einzelnen Pattern reindröseln?
Für heut ist erst mal gut, schade, der Überlauf macht jetzt alles zunichte 8)
Nachtrag:
irgendwas stimmt in der Argumentation nicht. Die SS kann doch den String erst senden, nachdem alle Pattern verarbeitet sind, die 1/0 Folge am Anfang erzeugt ja nur 2 Pattern, d.h. die restlichen Pattern werden später erfasst.
Im String werden aber die Pattern zuerst gesendet, d.h. die Daten werden erst über die Serielle Schnittstelle gesendet wenn die Zeile komlett empfangen wurde (dann kann das aber nicht meine fehlende 0 erklären.). Wenn nach dem Empfang der ersten Zeile ein Überlauf kommt stört mich das im Augenblick nicht, da bei meiner Fernbedienung die Blöcke nx wiederholt werden (mir reicht es wenn ich einen Block komplett empfang)
Die empfangenen Pulse werden in der Interruptroutine in dem FIFO gespeichert.
In der loop werden dann die Pulse aus dem FIFO ausgelesen und an die Routinen übergeben die die Pulse verarbeiten und ausgeben, wenn die verarbeiteten Pulse ausgegeben sind, wird die FIFO Belegung ausgegeben.
Ein MF=139 bedeutet, daß während dem verarbeiten und ausgeben der Pulse, 139 Pulse im FIFO gespeichert worden sind.
Nachtrag:
Ich kann Dir eine firmwarevariante mit einer FIFO Größe von 240 machen
Habe mal nachgeschaut, bei einem Block mit MF=140 passiert der Fehler beim 142 Bit/Pattern, ja ein größeres Fifo wäre einen Versuch wert.
Hallo,
Zitat von: Ralf9 am 17 Dezember 2019, 13:22:05
Kannst Du abschätzen ob es evtl noch mehr Protokolle gibt wo die max Anzahl Pattern von 8 nicht ausreicht?
unter Umständen vielleicht hier?
ccconf: freq:868.300MHz bWidth:203KHz rAmpl:42dB sens:4dB (DataRate:17257.69Baud, Modulation:2-FSK)2019.12.18 12:04:28 4: nano_868Mhz: Read, msg READredu: MU;P0=-104;P1=103;P2=-312;P3=209;P4=314;P5=-209;P6=-420;P7=416;D=0101010101010101010101012103040101515451615153630101270;CP=1;R=227;
2019.12.18 12:04:38 4: nano_868Mhz: Read, msg READredu: MU;P0=420;P1=-102;P2=104;P3=-312;P4=212;P5=314;P6=-207;P7=-420;D=12121212121212121212123214151212626562726264741212301;CP=2;R=204;
2019.12.18 12:04:48 4: nano_868Mhz: Read, msg READredu: MU;P0=101;P1=-105;P3=-312;P4=210;P5=312;P6=-206;P7=-422;D=0101010101010101010101030141510106065607060647410103;CP=0;R=204;
2019.12.18 12:04:59 4: nano_868Mhz: Read, msg READredu: MU;P0=-103;P1=98;P2=-312;P3=212;P4=316;P5=-203;P6=-416;P7=420;D=01010101010101010101010121030401015154516151536301012701;CP=1;R=204;
2019.12.18 12:05:08 4: nano_868Mhz: Read, msg READredu: MU;P0=-102;P1=107;P4=-312;P5=208;P6=314;P7=-211;D=010101010101010101010101014105060101717671;CP=1;R=204;
2019.12.18 12:05:18 4: nano_868Mhz: Read, msg READredu: MU;P0=-201;P1=104;P2=-103;P3=-314;P4=210;P5=320;P7=-416;D=01212121212121212121212131242521210105017101047421213;CP=1;R=204;
2019.12.18 12:05:28 4: nano_868Mhz: Read, msg READredu: MU;P0=103;P1=-103;P3=-316;P4=212;P5=320;P6=-206;P7=-412;D=010101010101010101010101030141510106065607060647410103;CP=0;R=204;
2019.12.18 12:05:38 4: nano_868Mhz: Read, msg READredu: MU;P0=420;P1=-102;P2=106;P3=-310;P4=210;P5=312;P6=-207;P7=-416;D=12121212121212121212123214151212626562726264741212301;CP=2;R=204;
2019.12.18 12:05:49 4: nano_868Mhz: Read, msg READredu: MU;P0=207;P1=-100;P2=106;P3=-312;P4=316;P5=-209;P6=-418;P7=424;D=012121212121212121212123210141212525452625250601212371;CP=2;R=204;
2019.12.18 12:05:58 4: nano_868Mhz: Read, msg READredu: MU;P0=103;P1=-148;P2=-104;P3=-312;P4=210;P5=316;P6=-206;P7=-416;D=010202020202020202020202030242520206065607060647420203;CP=0;R=204;
2019.12.18 12:06:08 4: nano_868Mhz: Read, msg READredu: MU;P0=107;P1=-100;P2=-312;P3=200;P4=316;P5=-206;P6=-414;P7=420;D=0101010101010101010101010201314101050545060505363101027131;CP=0;R=204;
2019.12.18 12:06:18 4: nano_868Mhz: Read, msg READredu: MU;P0=-420;P1=420;P2=-100;P3=106;P4=-312;P5=203;P6=312;P7=-203;D=232323232323232323232343252623237376730373750523234125;CP=3;R=204;
2019.12.18 12:06:28 4: nano_868Mhz: Read, msg READredu: MU;P0=420;P1=-104;P2=105;P3=-312;P4=212;P5=312;P6=-207;P7=-416;D=12121212121212121212123214151212626562726264741212301;CP=2;R=204;
2019.12.18 12:06:38 4: nano_868Mhz: Read, msg READredu: MU;P0=412;P1=-105;P2=106;P3=-312;P4=209;P5=320;P6=-210;P7=-414;D=12121212121212121212123214151212626562726264741212301;CP=2;R=204;
2019.12.18 12:06:48 4: nano_868Mhz: Read, msg READredu: MU;P0=-101;P1=110;P2=-282;P3=-192;P5=212;P6=316;D=01210131010101010101010101010101012105060101313631;CP=1;R=204;
2019.12.18 12:06:58 4: nano_868Mhz: Read, msg READredu: MU;P0=-103;P1=152;P2=104;P3=-312;P4=211;P5=314;P6=-202;P7=-420;D=01020202020202020202020232040502026265627262647402023;CP=2;R=204;
2019.12.18 12:07:08 4: nano_868Mhz: Read, msg READredu: MU;P0=-102;P1=103;P2=-312;P3=210;P4=312;P5=-208;P6=-420;P7=420;D=01010101010101010101010121030401015154516151536301012701;CP=1;R=204;
2019.12.18 12:07:18 4: nano_868Mhz: Read, msg READredu: MU;P0=-102;P1=103;P2=-312;P3=211;P4=316;P5=-206;P6=-414;P7=416;D=010101010101010101010101210304010151545161515363010127010;CP=1;R=204;
2019.12.18 12:07:28 4: nano_868Mhz: Read, msg READredu: MU;P0=-418;P1=412;P2=-102;P3=102;P4=-316;P5=210;P6=314;P7=-205;D=232323232323232323232343252623237376730373750523234123;CP=3;R=204;
2019.12.18 12:07:38 4: nano_868Mhz: Read, msg READredu: MU;P0=112;P1=-96;P2=-312;P3=212;P4=316;P5=-210;P6=-418;P7=420;D=01010101010101010101010201314101050545060505363101027101;CP=0;R=204;
2019.12.18 12:07:48 4: nano_868Mhz: Read, msg READredu: MU;P0=424;P1=-100;P2=107;P3=-310;P4=209;P5=316;P6=-207;P7=-422;D=121212121212121212121232141512126265627262647412123012;CP=2;R=204;
2019.12.18 12:07:58 4: nano_868Mhz: Read, msg READredu: MU;P0=-104;P1=102;P2=-316;P3=210;P4=318;P5=-208;P6=-412;P7=416;D=01010101010101010101010121030401015154516151536301012701;CP=1;R=204;
2019.12.18 12:08:08 4: nano_868Mhz: Read, msg READredu: MU;P0=114;P1=-110;P2=-312;P3=216;P4=316;P5=-208;P6=-416;P7=420;D=010101010101010101010102013141010505450605053631010271010;CP=0;R=204;
2019.12.18 12:08:18 4: nano_868Mhz: Read, msg READredu: MU;P0=101;P1=-104;P2=-312;P3=211;P4=312;P5=-204;P6=-420;P7=420;D=0101010101010101010101020131410105054506050536310102710;CP=0;R=204;
2019.12.18 12:08:23 4: nano_868Mhz: Read, msg READredu: MU;P0=-102;P1=104;P2=-312;P3=208;P4=312;P5=-204;P6=-424;D=0101010101010101010101210304010151545161515104030101010151510;CP=1;R=204;
2019.12.18 12:08:28 4: nano_868Mhz: Read, msg READredu: MU;P0=105;P1=-100;P2=-316;P3=216;P4=310;P5=-201;P6=-420;D=0101010101010101010101020131410105054506050501413101010105050;CP=0;R=204;
2019.12.18 12:08:33 4: nano_868Mhz: Read, msg READredu: MU;P0=103;P1=-99;P2=-312;P3=212;P4=318;P5=-217;P6=-412;D=010101010101010101010102013141010505450605050141310101010505;CP=0;R=204;
2019.12.18 12:08:43 4: nano_868Mhz: Read, msg READredu: MU;P0=-113;P1=108;P2=-312;P3=210;P4=312;P5=-203;P6=-412;D=010101010101010101010101210304010151545161515104030101010151510;CP=1;R=204;
2019.12.18 12:08:53 4: nano_868Mhz: Read, msg READredu: MU;P0=-99;P1=110;P2=-312;P3=212;P4=312;P5=-202;P6=-424;P7=152;D=01010101010101010101010101210304010151545161515104030101010151570;CP=1;R=204;
2019.12.18 12:09:03 4: nano_868Mhz: Read, msg READredu: MU;P0=107;P1=-102;P2=312;P3=-312;P4=212;P5=-209;P6=-420;D=012101010101010101010101030141210105052506050501214101010105050;CP=0;R=204;
2019.12.18 12:09:13 4: nano_868Mhz: Read, msg READredu: MU;P0=108;P1=-101;P2=-312;P3=212;P4=312;P5=-205;P6=-420;D=010101010101010101010102013141010505450605050141310101010505;CP=0;R=204;
2019.12.18 12:09:23 4: nano_868Mhz: Read, msg READredu: MU;P0=-202;P1=109;P2=-102;P3=-312;P4=210;P5=312;P6=-424;D=0121212121212121212121213124252121010501610101252421212121010;CP=1;R=204;
2019.12.18 12:09:33 4: nano_868Mhz: Read, msg READredu: MU;P0=-416;P1=-148;P2=213;P3=-105;P4=111;P5=-320;P6=318;P7=-208;D=12343434343434343434343454323634347476740474743632343434347474;CP=4;R=204;
2019.12.18 12:09:43 4: nano_868Mhz: Read, msg READredu: MU;P0=-101;P1=103;P2=-280;P3=210;P4=320;P5=-208;P6=-412;D=01010101010101010101010121030401015154516151510403010101015121;CP=1;R=204;
2019.12.18 12:09:53 4: nano_868Mhz: Read, msg READredu: MU;P0=104;P1=-106;P2=-312;P3=212;P4=320;P5=-197;P6=-412;D=0101010101010101010101020131410105054506050501413101010105050505;CP=0;R=204;
2019.12.18 12:10:03 4: nano_868Mhz: Read, msg READredu: MU;P0=102;P1=-101;P2=-312;P3=212;P4=313;P5=-203;P6=-416;P7=-144;D=01010101010101010101010201314101050545060505014131010101050507;CP=0;R=204;
2019.12.18 12:10:13 4: nano_868Mhz: Read, msg READredu: MU;P0=-100;P1=308;P2=115;P3=-312;P4=210;P5=-213;P6=-420;D=010202020202020202020202320401020252515262525201040202020252520;CP=2;R=204;
2019.12.18 12:10:23 4: nano_868Mhz: Read, msg READredu: MU;P0=107;P1=-100;P2=-140;P3=144;P4=-312;P5=212;P6=320;P7=-205;D=010201310101010101010101010104015161010707670;CP=0;R=204;
2019.12.18 12:10:33 4: nano_868Mhz: Read, msg READredu: MU;P0=-139;P1=214;P2=106;P3=-100;P4=148;P5=-312;P6=312;P7=-208;D=0102013432323232323232323232325231363232727672;CP=2;R=204;
2019.12.18 12:10:43 4: nano_868Mhz: Read, msg READredu: MU;P0=104;P1=-100;P3=-312;P4=212;P5=312;P6=-206;P7=-420;D=01010101010101010101010103014151010606560706060151410101010606;CP=0;R=204;
2019.12.18 12:10:53 4: nano_868Mhz: Read, msg READredu: MU;P0=103;P1=-156;P2=-102;P4=-312;P5=212;P6=312;P7=-210;D=010102020202020202020202020204025262020707670;CP=0;R=204;
2019.12.18 12:11:03 4: nano_868Mhz: Read, msg READredu: MU;P0=-420;P1=-144;P2=209;P3=-101;P4=107;P5=-298;P6=314;P7=-207;D=1234343434343434343434345432363434747674047474363234343434745;CP=4;R=204;
2019.12.18 12:11:13 4: nano_868Mhz: Read, msg READredu: MU;P0=-105;P1=95;P2=-312;P3=208;P4=317;P5=-212;P6=-416;P7=-140;D=01010101010101010101010121030401015154516151510403010101015151017;CP=1;R=204;
2019.12.18 12:11:23 4: nano_868Mhz: Read, msg READredu: MU;P0=106;P1=-102;P3=-312;P4=210;P5=318;P6=-229;P7=-416;D=010101010101010101010103014151010606560706060151410101010606;CP=0;R=204;
2019.12.18 12:11:33 4: nano_868Mhz: Read, msg READredu: MU;P0=102;P1=-102;P2=-304;P3=212;P4=320;P5=-214;P6=-412;D=010101010101010101010102013141010505450605050141310101010505;CP=0;R=204;
2019.12.18 12:11:43 4: nano_868Mhz: Read, msg READredu: MU;P0=109;P1=-102;P3=-312;P4=210;P5=312;P6=-207;P7=-420;D=010101010101010101010103014151010606560706060151410101010606;CP=0;R=204;
2019.12.18 12:11:53 4: nano_868Mhz: Read, msg READredu: MU;P0=-140;P1=119;P2=-102;P3=-312;P4=210;P5=312;P6=-205;P7=-420;D=01212121212121212121212131242521216165617161612524212121216161;CP=1;R=204;
2019.12.18 12:12:03 4: nano_868Mhz: Read, msg READredu: MU;P0=-103;P1=103;P2=-312;P3=212;P4=318;P5=-209;P6=-420;D=0101010101010101010101012103040101515451615151040301010101515;CP=1;R=204;
2019.12.18 12:12:13 4: nano_868Mhz: Read, msg READredu: MU;P0=148;P1=-102;P2=113;P3=-312;P4=210;P5=315;P6=-200;P7=-420;D=01212121212121212121212321415121262656272626215141212121262626;CP=2;R=204;
2019.12.18 12:12:23 4: nano_868Mhz: Read, msg READredu: MU;P0=100;P1=-103;P2=-312;P3=208;P4=313;P5=-202;P6=-412;P7=-144;D=01010101010101010101010201314101050545060505014131010101050507;CP=0;R=204;
2019.12.18 12:12:33 4: nano_868Mhz: Read, msg READredu: MU;P0=-204;P1=113;P2=-103;P3=-312;P4=214;P5=312;P6=-420;D=01212121212121212121212131242521210105016101012524212121210101;CP=1;R=204;
2019.12.18 12:12:43 4: nano_868Mhz: Read, msg READredu: MU;P0=104;P1=-107;P2=-312;P3=212;P4=311;P5=-210;P6=-420;D=0101010101010101010101020131410105054506050501413101010105050101;CP=0;R=204;
2019.12.18 12:12:53 4: nano_868Mhz: Read, msg READredu: MU;P0=213;P1=-101;P2=115;P3=-312;P4=311;P5=-217;P6=-416;D=0121212121212121212121232101412125254526252521410121212125252;CP=2;R=204;
2019.12.18 12:13:03 4: nano_868Mhz: Read, msg READredu: MU;P0=-101;P1=306;P2=108;P3=-308;P4=212;P5=-208;P6=-420;D=0102020202020202020202023204010202525152625252010402020202523;CP=2;R=204;
2019.12.18 12:13:13 4: nano_868Mhz: Read, msg READredu: MU;P0=-100;P1=146;P3=-199;P4=196;P5=109;P6=-304;P7=318;D=0101013405050505050505050505056504070505353735;CP=5;R=204;
2019.12.18 12:13:23 4: nano_868Mhz: Read, msg READredu: MU;P0=106;P1=-100;P2=-288;P3=210;P4=313;P5=-210;P6=-416;D=010101010101010101010102013141010505450605050141310101010502;CP=0;R=204;
2019.12.18 12:13:33 4: nano_868Mhz: Read, msg READredu: MU;P0=160;P1=-103;P2=107;P3=-312;P4=208;P5=314;P6=-218;P7=-420;D=012121212121212121212123214151212626562726262151412121212626;CP=2;R=204;
2019.12.18 12:13:43 4: nano_868Mhz: Read, msg READredu: MU;P0=108;P1=-101;P2=-312;P3=212;P4=312;P5=-215;P6=-420;D=010101010101010101010102013141010505450605050141310101010505;CP=0;R=204;
2019.12.18 12:13:53 4: nano_868Mhz: Read, msg READredu: MU;P0=100;P1=-104;P2=-320;P3=210;P4=319;P5=-210;P6=-412;D=0101010101010101010101020131410105054506050501413101010105050;CP=0;R=204;
2019.12.18 12:14:03 4: nano_868Mhz: Read, msg READredu: MU;P0=-140;P1=110;P2=-102;P3=-312;P4=210;P5=312;P6=-205;P7=-420;D=012121212121212121212121312425212161656171616125242121212161;CP=1;R=204;
2019.12.18 12:14:13 4: nano_868Mhz: Read, msg READredu: MU;P0=-101;P1=112;P2=-316;P3=210;P4=320;P5=-221;P6=-412;D=010101010101010101010101210304010151545161515104030101010151510;CP=1;R=204;
2019.12.18 12:14:23 4: nano_868Mhz: Read, msg READredu: MU;P0=136;P1=-106;P2=100;P3=-312;P4=212;P5=320;P6=-228;P7=-412;D=0121010101010101010101010301415101060656070606015141010101060601010;CP=0;R=204;
2019.12.18 12:14:33 4: nano_868Mhz: Read, msg READredu: MU;P0=-102;P1=119;P2=-312;P3=208;P4=313;P5=-215;P6=-424;D=01010101010101010101010121030401015154516151510403010101015151;CP=1;R=204;
2019.12.18 12:14:43 4: nano_868Mhz: Read, msg READredu: MU;P0=101;P1=-104;P2=-312;P3=224;P4=316;P5=-206;P6=-412;D=0101010101010101010101020131410105054506050501413101010105053;CP=0;R=204;
2019.12.18 12:14:53 4: nano_868Mhz: Read, msg READredu: MU;P0=107;P1=-102;P2=-312;P3=212;P4=316;P5=-207;P6=-420;D=010101010101010101010102013141010505450605050141310101010505;CP=0;R=204;
2019.12.18 12:15:03 4: nano_868Mhz: Read, msg READredu: MU;P0=108;P1=-111;P2=-312;P3=208;P4=318;P5=-210;P6=-424;P7=144;D=01010101010101010101010201314101050545060505014131010101050571010;CP=0;R=204;
2019.12.18 12:15:13 4: nano_868Mhz: Read, msg READredu: MU;P0=160;P1=-108;P2=109;P3=-312;P4=212;P5=318;P6=-223;P7=-412;D=01212121212121212121212321415121262656272626215141212121262621;CP=2;R=204;
2019.12.18 12:15:23 4: nano_868Mhz: Read, msg READredu: MU;P0=152;P1=-110;P2=110;P3=-312;P4=208;P5=312;P6=-201;P7=-420;D=01212121212121212121212321415121262656272626215141212121262621;CP=2;R=204;
2019.12.18 12:15:33 4: nano_868Mhz: Read, msg READredu: MU;P0=106;P1=-102;P2=-312;P3=214;P4=310;P5=-226;P6=-420;D=01010101010101010101010102013141010505450605050141310101010505;CP=0;R=204;
2019.12.18 12:15:43 4: nano_868Mhz: Read, msg READredu: MU;P0=-104;P1=101;P2=-312;P3=210;P4=314;P5=-221;P6=-412;D=0101010101010101010101012103040101515451615151040301010101515;CP=1;R=204;
2019.12.18 12:15:53 4: nano_868Mhz: Read, msg READredu: MU;P0=326;P1=-102;P2=102;P3=-312;P4=212;P5=-215;P6=-412;D=012121212121212121212123214101212525052625252101412121212525;CP=2;R=204;
2019.12.18 12:16:03 4: nano_868Mhz: Read, msg READredu: MU;P0=-99;P1=110;P3=-312;P4=210;P5=314;P6=-229;P7=-412;D=010101010101010101010101310405010161656171616105040101010161610;CP=1;R=204;
2019.12.18 12:16:13 4: nano_868Mhz: Read, msg READredu: MU;P0=102;P1=-102;P2=-308;P3=212;P4=320;P5=-205;P6=-412;D=010101010101010101010102013141010505450605050141310101010505;CP=0;R=204;
2019.12.18 12:16:23 4: nano_868Mhz: Read, msg READredu: MU;P0=101;P1=-105;P2=-308;P3=210;P4=317;P5=-218;P6=-416;D=010101010101010101010102013141010505450605050141310101010505;CP=0;R=204;
2019.12.18 12:16:33 4: nano_868Mhz: Read, msg READredu: MU;P0=-104;P1=115;P3=-312;P4=210;P5=312;P6=-206;P7=-420;D=0101010101010101010101010131040501016165617161610504010101016161;CP=1;R=204;
2019.12.18 12:16:43 4: nano_868Mhz: Read, msg READredu: MU;P0=107;P1=-102;P2=-312;P3=210;P4=312;P5=-205;P6=-412;D=0101010101010101010101020131410105054506050501413101010105050;CP=0;R=204;
2019.12.18 12:16:53 4: nano_868Mhz: Read, msg READredu: MU;P0=102;P1=-105;P3=-312;P4=210;P5=316;P6=-210;P7=-412;D=010101010101010101010103014151010606560706060151410101010606;CP=0;R=204;
2019.12.18 12:17:03 4: nano_868Mhz: Read, msg READredu: MU;P0=99;P1=-111;P2=-312;P3=210;P4=320;P5=-219;P6=-412;D=01010101010101010101010201314101050545060505014131010101050501;CP=0;R=204;
2019.12.18 12:17:13 4: nano_868Mhz: Read, msg READredu: MU;P0=-102;P1=106;P2=-312;P3=210;P4=317;P5=-200;P6=-424;D=0101010101010101010101012103040101515451615151040301010101515;CP=1;R=204;
2019.12.18 12:17:23 4: nano_868Mhz: Read, msg READredu: MU;P0=-103;P1=108;P2=-312;P3=212;P4=310;P5=-205;P6=-420;D=010101010101010101010101010121030401015154516151510403010101015151;CP=1;R=204;
unter Umständen vielleicht hier?
2019.12.18 12:04:28 4: nano_868Mhz: Read, msg READredu: MU;P0=-104;P1=103;P2=-312;P3=209;P4=314;P5=-209;P6=-420;P7=416;D=0101010101010101010101012103040101515451615153630101270;CP=1;R=227;
Ja hier sind die Anzahl Pattern auch zuwenig.
Hier ist noch ein anderes Problem, durch die sehr niedrige clock von ca 100 kommen wahrscheinlich die Pulse schneller rein als sie verarbeitet und ausgegeben werden können. Evtl ist da auch der FIFO zu klein
Die Erhöhung der Patternanzahl ist nur bei nicht komprimierten Daten (Mred=0) möglich.
Gruß Ralf
Hallo,
Zitat von: Ralf9 am 19 Dezember 2019, 10:12:07
Ja hier sind die Anzahl Pattern auch zuwenig.
Hier ist noch ein anderes Problem, durch die sehr niedrige clock von ca 100 kommen wahrscheinlich die Pulse schneller rein als sie verarbeitet und ausgegeben werden können. Evtl ist da auch der FIFO zu klein
Die Erhöhung der Patternanzahl ist nur bei nicht komprimierten Daten (Mred=0) möglich.
hier ist die Information mit
config: MS=1;MU=1;MC=1;Mred=0;Mdebug=1_MScnt=4;MuSplitThresh=0;MdebFifoLimit=120/1402019.12.19 10:43:04 4: nano_868Mhz: Read, msg: MU;P0=-152;P1=-104;P2=105;P3=-312;P4=211;P5=304;P6=-212;P7=-418;CP=2;R=77;D=1212121212121212121212321415121262656272327414121215350;e;
2019.12.19 10:43:14 4: nano_868Mhz: Read, msg: MU;P0=205;P1=-96;P2=107;P3=-312;P4=314;P5=-211;P6=-414;CP=2;R=77;D=01212121212121212121212321014121252545262326010121214301;e;
2019.12.19 10:43:24 4: nano_868Mhz: Read, msg: MU;P0=-104;P1=108;P2=-312;P3=234;P4=314;P5=-203;P6=-412;CP=1;R=77;D=010101010101010101010101210304010151545161216303010104230;e;
2019.12.19 10:43:34 4: nano_868Mhz: Read, msg: MU;P0=-416;P1=107;P2=-102;P4=-312;P5=211;P6=313;P7=-210;CP=1;R=77;D=121212121212121212121214125262121717671014105252121264;e;
2019.12.19 10:43:44 4: nano_868Mhz: Read, msg: MU;P0=107;P1=-102;P2=-312;P3=204;P4=312;P5=-204;P6=-418;P7=-132;CP=0;R=77;D=0101010101010101010101010201314101050545060206313101014237;e;
2019.12.19 10:43:54 4: nano_868Mhz: Read, msg: MU;P0=105;P1=-108;P2=-312;P3=209;P4=315;P5=-207;P6=-416;CP=0;R=77;D=01010101010101010101010201314101050545060206313101014231;e;
2019.12.19 10:44:04 4: nano_868Mhz: Read, msg: MU;P0=-104;P1=105;P2=212;P3=-312;P4=316;P5=-206;P6=-416;CP=1;R=77;D=0102010101010101010101010131020401015154516131620201010432;e;
2019.12.19 10:44:14 4: nano_868Mhz: Read, msg: MU;P0=106;P1=-97;P2=160;P3=-312;P4=208;P5=315;P6=-206;P7=-420;CP=0;R=77;D=0121010101010101010101010301415101060656070307414101015341;e;
2019.12.19 10:44:24 4: nano_868Mhz: Read, msg: MU;P0=156;P1=-105;P2=116;P3=-312;P4=210;P5=316;P6=-207;P7=-412;CP=2;R=77;D=0121212121212121212121232141512126265627232323412126264121;e;
2019.12.19 10:44:29 4: nano_868Mhz: Read, msg: MU;P0=110;P1=-101;P2=-311;P3=213;P4=316;P5=-202;P6=-412;CP=0;R=77;D=010101010101010101010102013141010505450602020231010505310;e;
2019.12.19 10:44:34 4: nano_868Mhz: Read, msg: MU;P0=126;P1=-100;P2=-312;P3=210;P4=316;P5=-202;P6=-412;CP=0;R=77;D=01010101010101010101010201314101050545060202023101050531010;e;
2019.12.19 10:44:44 4: nano_868Mhz: Read, msg: MU;P0=-106;P1=108;P2=-312;P3=209;P4=316;P5=-211;P6=-412;CP=1;R=77;D=0101010101010101010101012103040101515451612121230101515301;e;
2019.12.19 10:44:54 4: nano_868Mhz: Read, msg: MU;P0=105;P1=-104;P2=-308;P3=210;P4=316;P5=-212;P6=-420;CP=0;R=77;D=0101010101010101010101010102013141010505450602020231010505310;e;
2019.12.19 10:45:04 4: nano_868Mhz: Read, msg: MU;P0=-209;P1=109;P2=-99;P3=-311;P4=212;P5=312;P6=-412;P7=146;CP=1;R=77;D=01212121212121212121212131242521210105016131313421210104272701;p;
2019.12.19 10:45:24 4: nano_868Mhz: Read, msg: MU;P0=101;P1=-105;P2=152;P4=-312;P5=208;P6=310;P7=-212;CP=0;R=77;D=01210101010101010101010104015161010707670;p;
2019.12.19 10:45:34 4: nano_868Mhz: Read, msg: MU;P0=210;P1=-104;P2=116;P3=-310;P4=316;P5=-206;P6=-412;CP=2;R=77;D=012121212121212121212123210141212525452623232301212525012;e;
2019.12.19 10:45:44 4: nano_868Mhz: Read, msg: MU;P0=-100;P1=105;P3=-313;P4=211;P5=316;P6=-206;P7=-416;CP=1;R=77;D=0101010101010101010101013104050101616561713131340101616401;e;
2019.12.19 10:45:54 4: nano_868Mhz: Read, msg: MU;P0=102;P1=-101;P2=-312;P3=211;P4=320;P5=-206;P6=-416;CP=0;R=77;D=010101010101010101010102013141010505450602020231010505310;e;
2019.12.19 10:46:04 4: nano_868Mhz: Read, msg: MU;P0=-104;P1=101;P3=-311;P4=209;P5=314;P6=-203;P7=-412;CP=1;R=77;D=010101010101010101010101013104050101616561713131340101616401;e;
2019.12.19 10:46:14 4: nano_868Mhz: Read, msg: MU;P0=-202;P1=108;P2=-104;P3=-312;P4=212;P5=316;P6=-412;CP=1;R=77;D=012121212121212121212121312425212101050161313134212101042;e;
2019.12.19 10:46:24 4: nano_868Mhz: Read, msg: MU;P0=105;P1=-103;P3=-313;P4=211;P5=312;P6=-206;P7=-416;CP=0;R=77;D=010101010101010101010103014151010606560703030341010606410;e;
2019.12.19 10:46:34 4: nano_868Mhz: Read, msg: MU;P0=-100;P1=109;P2=-311;P3=212;P4=316;P5=-205;P6=-420;P7=-136;CP=1;R=77;D=01010101010101010101010121030401015154516121212301015153017;e;
2019.12.19 10:46:44 4: nano_868Mhz: Read, msg: MU;P0=-205;P1=98;P2=-108;P4=-312;P5=209;P6=316;P7=-416;CP=1;R=77;D=01212121212121212121212141252621210106017141414521210105212121;e;i;
2019.12.19 10:46:54 4: nano_868Mhz: Read, msg: MU;P0=140;P1=-104;P2=101;P3=-313;P4=209;P5=312;P6=-211;P7=-416;CP=2;R=77;D=012121212121212121212123214151212626562723232341212626410;e;
2019.12.19 10:47:04 4: nano_868Mhz: Read, msg: MU;P0=117;P1=-102;P2=-312;P3=210;P4=320;P5=-205;P6=-412;P7=-132;CP=0;R=77;D=0101010101010101010101020131410105054506020202310105053107;p;
2019.12.19 10:47:14 4: nano_868Mhz: Read, msg: MU;P0=111;P1=-105;P2=-312;P3=212;P4=320;P5=-202;P6=-412;P7=-144;CP=0;R=77;D=0101010101010101010101020131410105054506020202310105053107;p;
2019.12.19 10:47:24 4: nano_868Mhz: Read, msg: MU;P0=203;P1=-103;P2=101;P3=-312;P4=311;P5=-209;P6=-424;CP=2;R=77;D=01212121212121212121212321014121252545262323212101212121452;e;
2019.12.19 10:47:29 4: nano_868Mhz: Read, msg: MU;P0=108;P1=-100;P2=-312;P3=210;P4=313;P5=-210;P6=-416;CP=0;R=77;D=01010101010101010101010201314101050545060202010131010101450;e;
2019.12.19 10:47:39 4: nano_868Mhz: Read, msg: MU;P0=-132;P1=116;P2=-96;P3=-312;P4=208;P5=313;P6=-200;P7=-420;CP=1;R=77;D=01212121212121212121212131242521216165617131312124212121256121;e;i;
@Ralf
Ich hätte heute Abend Zeit und könnte nochmal testen.
Gibt es eine Chance, dass du heute eine Variante mit größerem Fifo baust?
Ich kann dann auch schauen ob bei mir ein unbenötigter Sender rumliegt.
Ja heute Abend müsste ich es hinbekommen
in der Anlage ist eine Version "V 3.3.2.2-rc10f" mit einem FIFO von 200,
sieht man auch in der config:
MdebFifoLimit=120/200
Zitat2019.12.19 10:45:24 4: nano_868Mhz: Read, msg: MU;P0=101;P1=-105;P2=152;P4=-312;P5=208;P6=310;P7=-212;CP=0;R=77;D=01210101010101010101010104015161010707670;p;
@HomeAuto_User
bei den MU-Nachrichten, die mit p enden, ist die Pattern Anzahl von 8 zuwenig
Tut leider nicht, der Einzelbitfehler ist immer noch da.
Das Fifo von 200 wird wohl auch nicht ausgenutzt?
MU;P0=-32001;P1=262;P2=-154;P4=-362;P5=-1252;P6=1724;P7=892;P8=-572;P9=682;PA=468;CP=1;R=246;D=01212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121214121215621412781492A41294A5751218121;e;
MF=159
MU;P0=-18952;P1=260;P2=-153;P4=-364;P5=-1256;P6=1728;P7=886;P8=-576;P9=680;PA=468;CP=1;R=246;D=01212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121214121215621412781492A41294A5751218121;e;
MF=158
MU;P0=-18960;P1=263;P2=-153;P4=-364;P5=-1255;P6=1720;P7=888;P8=-574;P9=678;PA=470;CP=1;R=246;D=01212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121214121215621412781492A41294A5751218121;e;
MF=158
MU;P0=-18960;P1=263;P2=-154;P4=-365;P5=-1255;P6=1728;P7=888;P8=-580;P9=678;PA=468;CP=1;R=246;D=01212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121214121215621412781492A41294A5751218121;e;
MF=159
MU;P0=-18932;P1=261;P2=-154;P4=-367;P5=-1252;P6=1724;P7=888;P8=-576;P9=678;PA=470;CP=1;R=246;D=01212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121214121215621412781492A41294A5751218121;e;
MF=156
MU;P0=-18948;P1=260;P2=-152;P4=-362;P5=-1255;P6=1728;P7=888;P8=-578;P9=682;PA=472;CP=1;R=246;D=01212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121214121215621412781492A41294A5751218121;e;
MF=159
MU;P0=-18952;P1=257;P2=-155;P4=-362;P5=-1252;P6=1724;P7=892;P8=-576;P9=680;PA=468;CP=1;R=246;D=01212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121214121215621412781492A41294A5751218121;e;
MF=156
MU;P0=-18952;P1=262;P2=-151;P4=-364;P5=-1252;P6=1728;P7=890;P8=-576;P9=678;PA=468;CP=1;R=246;D=01212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121214121215621412781492A41294A5751218121;e;
MF=158
MU;P0=-18960;P1=259;P2=-155;P4=-366;P5=-1255;P6=1724;P7=886;P8=-576;P9=680;PA=468;CP=1;R=246;D=01212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121214121215621412781492A41294A5751218121;e;
MF=158
MU;P0=-18944;P1=265;P2=-149;P3=-362;P4=-1262;P5=1724;P6=888;P7=-564;P8=680;P9=482;CP=1;R=246;D=0121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121312121452131267138293128394641217121;e;
MF=160
MU;P0=-18952;P1=261;P2=-154;P4=-364;P5=-1255;P6=1728;P7=890;P8=-572;P9=680;PA=468;CP=1;R=246;D=01212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121214121215621412781492A41294A5751218121;e;
MF=158
MU;P0=-18964;P1=261;P2=-152;P4=-364;P5=-1251;P6=1724;P7=890;P8=-574;P9=682;PA=470;CP=1;R=246;D=01212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121214121215621412781492A41294A5751218121;e;
MF=159
MU;P0=-18948;P1=260;P2=-152;P4=-364;P5=-1255;P6=1720;P7=888;P8=-576;P9=680;PA=468;CP=1;R=246;D=01212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121214121215621412781492A41294A5751218121;e;
Ist wahrscheinlich sehr schwierig den Fehler zu finden.
Immerhin gibt es jetzt keine FIFO überläufe mehr
Zitat von: Ralf9 am 19 Dezember 2019, 19:31:16
@HomeAuto_User
bei den MU-Nachrichten, die mit p enden, ist die Pattern Anzahl von 8 zuwenig
Ich werde deine Version mal testen und dir das Ergebnis mitteilen.
Gesendet von iPhone mit Tapatalk Pro
Ich habe mir mal angeschaut wie in der a-culfw der FIFO des cc1101 ausgelesen wird:
if (bit_is_set( CC1100_IN_PORT, CC1100_IN_PIN )) {
// start over syncing
ccStrobe( CC1100_SIDLE );
len = cc1100_readReg( CC1100_RXBYTES ) & 0x7f; // read len, transfer RX fifo
if (len) {
Mir ist das "ccStrobe( CC1100_SIDLE );" nicht klar, damit wird doch cc1101 in den IDLE Mode gesetzt.
Ist evtl der Grund, daß die im Native Mode empfangenen Nachrichten nie länger als 64 Bytes sind?
Gruß Ralf
@Ralf
Damit ich sicher sein kann, dass ich in mein Excel keinen Fehler mehr eingebaut habe, habe ich nochmal die alte FW geflasht:
Ergebnis: alles ist wie es sein soll
Alte Firmware: V 3.3.2.1-rc9 SIGNALduino cc1101 - compiled at Jun 16 2019 20:18:01
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA 54 07 FA 5E
Die letzten Firmwareversion liefert:
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA 54
0F F4 BE 2B F7 CC 0F 81
also wie gesagt, hier fehlt ein "0" Bit.
Bei der Patternmessung ist an dieser Stelle auffällig, dass alle Bitzeiten sehr genau 208usec sind, d.h. 3 negative Bits werden mit z.B. 2,95 Bit oder 3,03 Bit berechnet.
nur an dieser Stelle haben werden jedes mal 6,
3 Bits berechnet, es sollten 7 Bits sein.
Hier als Beispiel ein paar Patternzeiten (alles "0" Bits), Wert mal 208 usec ergibt die Zeiten:
1,00
2,03
6,31 -> Hier liegt der Fehler
3,02
4,04
Da der Fehler immer an exakt der gleichen Stelle ist, bzw. immer bei 6x "0"-Bit liegt sehe ich folgende Möglichkeiten:
- Die Firmware verhagelt sich wenn zwischen 6 und 7 x 208 usec zu messen sind
- Es gibt eine anderes Pattern auf der Leitung (z.B. eine Störung z.B. wenn der Empfänger die Amplitude einregelt) die ähnlich von 6 Low Bit Zeiten hat und die Software kategoriesiert 7 Bitzeiten in dieses Pattern rein.
Werden die Patternzeiten (P0...PF) in der Reihenfolge erstellt, in der diese auf der Leitung gemessen werden?
Nachtrag:
Irgend eine Idee, was den Signalduino zum "Stottern" bewegt. Es müsste ja etwas mit der Erhöhung der Patternzahl zu tun haben,
wie gesagt die alte Firmware zeigt diesen Effekt nicht
@Ralf:
Zu Deiner Frage (SIDLE):
Meine Interpretation ist, dass in diesem Stück Software die Längeninterpretation innerhalb der Empfangenen Botschaften ausgewertet wird (oder eine feste Blocklänge angenommen wird).
Ablauf m.E.:
Empfänger signalisiert Botschaft ist da
Empfänger wird in Idle Mode versetzt (macht eigentlich nur Sinn wenn er auch wieder automatisch bei Botschaftseingang aktiv wird)
Die Anzahl der Empfangenen Bytes wird ermittelt und ausgelesen.
Prinzipiell kann der CC1101 bei der Nutzung des Fifo's auch "Endlosdaten" lesen, siehe Datenblatt: "infinite packet length mode".
Allerdings muss man in diesem Fall bestimmte Abläufe einhalten.
Da die meisten Protokolle aber eine feste und kurze Blocklänge oder einen Blocklängenzähler haben, reicht in der Regel die FIFO Tiefe von 64 Bytes zum Empfang einer Botschaft aus.
ZitatWerden die Patternzeiten (P0...PF) in der Reihenfolge erstellt, in der diese auf der Leitung gemessen werden?
Ja, solange der Patternpuffer nicht voll ist.
Woher weisst Du, daß es 7 und nicht 6 Bit sein sollen?
@RaspII
kannst Du mir auch an der MU-Nachricht zeigen, was nicht passt?
MU;P0=-32001;P1=262;P2=-154;P4=-362;P5=-1252;P6=1724;P7=892;P8=-572;P9=682;PA=468;CP=1;R=246;D=01212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121214121215621412781492A41294A5751218121;e;
MU;P0=-32001;P1=262;P2=-154;P4=-362;P5=-1252;P6=1724;P7=892;P8=-572;P9=682;PA=468;CP=1;R=246;D=01212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121214121215621412781492A41294A5751218121;e;
Das wäre der erste P5 Wert im String. Alle weiteren sind evt. auch falsch.
Hallo,
Zitat von: Ralf9 am 19 Dezember 2019, 19:31:16
@HomeAuto_User
bei den MU-Nachrichten, die mit p enden, ist die Pattern Anzahl von 8 zuwenig
Ich habe nun mal dein neues File probiert:
2019.12.19 22:02:09 4: nano_868Mhz: Read, msg: MS=1;MU=1;MC=1;Mred=0;Mdebug=1_MScnt=4;MuSplitThresh=0;MdebFifoLimit=120/200
2019.12.19 22:02:10 4: nano_868Mhz: Read, msg: MU;P0=105;P1=-101;P2=-312;P3=211;P4=313;P5=-209;P6=-412;P7=-728;CP=0;R=235;D=01010101010101010101010102013141010505450602073101013541;e;
2019.12.19 22:02:20 4: nano_868Mhz: Read, msg: MU;P0=108;P1=-99;P2=-312;P3=214;P4=314;P5=-205;P6=-416;P7=-728;CP=0;R=235;D=0101010101010101010101020131410105054506020731010135410;e;
2019.12.19 22:02:30 4: nano_868Mhz: Read, msg: MU;P0=105;P1=-103;P2=-310;P3=210;P4=315;P5=-204;P6=-412;P7=-732;CP=0;R=232;D=01010101010101010101010201314101050545060207310101354;p;
2019.12.19 22:02:50 4: nano_868Mhz: Read, msg: MU;P0=-104;P1=103;P2=-310;P3=210;P4=312;P5=-198;P6=-416;P7=-732;CP=1;R=233;D=0101010101010101010101012103040101515451612173010103545;p;
2019.12.19 22:03:00 4: nano_868Mhz: Read, msg: MU;P0=-420;P1=-732;P2=-101;P3=108;P4=-314;P5=212;P6=314;P7=-208;CP=3;R=234;D=2323232323232323232323432526232373767303431523232576232;e;
2019.12.19 22:03:20 4: nano_868Mhz: Read, msg: MU;P0=106;P1=-104;P2=-310;P3=212;P4=313;P5=-206;P6=-416;P7=-728;CP=0;R=233;D=01010101010101010101010201314101050545060207310101354;p;
2019.12.19 22:03:30 4: nano_868Mhz: Read, msg: MU;P0=210;P1=-119;P2=123;P3=-310;P4=314;P5=-205;P6=-420;P7=-724;CP=2;R=236;D=012121212121212121212123210141212525452623270121210541212121;e;
2019.12.19 22:03:40 4: nano_868Mhz: Read, msg: MU;P0=-103;P1=192;P2=-136;P4=105;P5=-312;P6=316;P7=-206;CP=4;R=233;D=0121242104040404040404040404045401060404747674;p;
2019.12.19 22:03:50 4: nano_868Mhz: Read, msg: MU;P0=108;P1=-100;P2=-310;P3=213;P4=317;P5=-190;P6=-424;P7=-732;CP=0;R=230;D=010101010101010101010102013141010505450602073101013545;e;
2019.12.19 22:04:00 4: nano_868Mhz: Read, msg: MU;P0=-105;P1=102;P3=-310;P4=212;P5=320;P6=-203;P7=-412;CP=1;R=236;D=01010101010101010101010131040501016165617131;p;
2019.12.19 22:04:10 4: nano_868Mhz: Read, msg: MU;P0=-101;P1=109;P3=-308;P4=212;P5=314;P6=-210;P7=-412;CP=1;R=235;D=01010101010101010101010131040501016165617131;p;
2019.12.19 22:04:20 4: nano_868Mhz: Read, msg: MU;P0=103;P1=-101;P3=-314;P4=208;P5=312;P6=-208;P7=-424;CP=0;R=233;D=0101010101010101010101030141510106065607030;p;
2019.12.19 22:04:30 4: nano_868Mhz: Read, msg: MU;P0=213;P1=-102;P2=103;P3=-310;P4=316;P5=-210;P6=-420;P7=-732;CP=2;R=213;D=01212121212121212121212321014121252545262327012121054;p;
2019.12.19 22:04:40 4: nano_868Mhz: Read, msg: MU;P0=102;P1=-205;P3=-105;P4=-312;P5=208;P6=318;P7=-416;CP=0;R=213;D=0103030303030303030303030303040353630301016107040;p;
2019.12.19 22:04:50 4: nano_868Mhz: Read, msg: MU;P0=109;P1=-100;P2=-312;P3=211;P4=316;P5=-207;P6=-412;P7=-732;CP=0;R=213;D=01010101010101010101010201314101050545060207310101354;p;
2019.12.19 22:05:00 4: nano_868Mhz: Read, msg: MU;P0=-420;P1=106;P3=-101;P4=-312;P5=208;P6=312;P7=-208;CP=1;R=213;D=1313131313131313131313141353631317176710141;p;
2019.12.19 22:05:10 4: nano_868Mhz: Read, msg: MU;P0=-202;P1=112;P2=-99;P3=-312;P4=212;P5=318;P6=-412;P7=-724;CP=1;R=213;D=012121212121212121212121312425212101050161317421212405212;e;
2019.12.19 22:05:20 4: nano_868Mhz: Read, msg: MU;P0=107;P1=-104;P2=-312;P3=211;P4=313;P5=-208;P6=-416;P7=-724;CP=0;R=213;D=010101010101010101010102013141010505450602073101013541;e;
2019.12.19 22:05:30 4: nano_868Mhz: Read, msg: MU;P0=101;P1=-103;P2=-312;P3=214;P4=316;P5=-193;P6=-412;P7=-724;CP=0;R=213;D=010101010101010101010102013141010505450602073101013545;e;
2019.12.19 22:05:40 4: nano_868Mhz: Read, msg: MU;P0=-101;P1=111;P2=152;P3=-310;P4=208;P5=318;P6=-203;P7=-412;CP=1;R=213;D=0102010101010101010101010131040501016165617131;p;
2019.12.19 22:05:50 4: nano_868Mhz: Read, msg: MU;P0=-724;P1=-102;P2=108;P3=-312;P4=211;P5=315;P6=-208;P7=-412;CP=2;R=213;D=12121212121212121212123214151212626562723204121214651;p;
2019.12.19 22:06:00 4: nano_868Mhz: Read, msg: MU;P0=106;P1=-158;P3=-101;P4=-308;P5=220;P6=316;P7=-205;CP=0;R=213;D=010101030303030303030303030304035363030707670;p;
2019.12.19 22:06:10 4: nano_868Mhz: Read, msg: MU;P0=-103;P1=144;P2=104;P3=-312;P4=212;P5=312;P6=-209;P7=-424;CP=2;R=213;D=01020202020202020202020232040502026265627232;p;
2019.12.19 22:06:20 4: nano_868Mhz: Read, msg: MU;P0=208;P1=-101;P2=107;P3=-312;P4=317;P5=-205;P6=-412;P7=-732;CP=2;R=213;D=01212121212121212121212321014121252545262327012121054;p;
Wie kann ich die Erweiterung der Pattern nutzen? Hattest du diese nicht erweitert?
ZitatDas wäre der erste P5 Wert im String.
was wäre der richtige Wert?
ZitatWie kann ich die Erweiterung der Pattern nutzen? Hattest du diese nicht erweitert?
Mit
get sduino raw CSmaxnumpat=15kannst Du die Anzahl der Pattern erhöhen
Sorry, gerade erst gesehen.
Zitat von: Ralf9 am 18 Dezember 2019, 01:01:41
CEO
CSmaxpulse=10000
Gruß Ralf
Was genau bewirkt
CEO
CSmaxpulse=10000EDIT:
neue Ausgabe
2019.12.19 22:16:15 4: nano_868Mhz: Read, msg: MU;P0=107;P1=-204;P2=144;P3=-103;P4=-308;P5=210;P6=312;P8=-416;CP=0;R=213;D=012303030303030303030303040353630301016108086103530304535;e;
2019.12.19 22:16:35 4: nano_868Mhz: Read, msg: MU;P0=102;P1=-104;P3=-312;P4=207;P5=314;P6=-211;P7=-414;P8=-152;CP=0;R=213;D=0101010101010101010101010301415101060656070756014101034148;e;
2019.12.19 22:16:45 4: nano_868Mhz: Read, msg: MU;P0=-104;P1=108;P3=-308;P4=211;P5=319;P6=-204;P7=-412;CP=1;R=213;D=010101010101010101010101310405010161656171756104010134040;e;
2019.12.19 22:16:55 4: nano_868Mhz: Read, msg: MU;P0=-186;P1=205;P4=-100;P5=104;P7=-312;P8=312;P9=-420;CP=5;R=213;D=0101454545454545454545454545754148454505080595980541454571410;e;
2019.12.19 22:17:05 4: nano_868Mhz: Read, msg: MU;P0=-105;P1=103;P3=-310;P4=216;P5=320;P6=-205;P7=-412;CP=1;R=213;D=0101010101010101010101013104050101616561717561040101340401;e;
2019.12.19 22:17:15 4: nano_868Mhz: Read, msg: MU;P0=105;P1=-96;P2=-312;P3=211;P4=316;P5=-210;P6=-416;P7=-136;CP=0;R=213;D=0101010101010101010101020131410105054506064501310102313701;e;
2019.12.19 22:17:25 4: nano_868Mhz: Read, msg: MU;P0=203;P1=-107;P2=110;P3=-310;P4=319;P5=-203;P6=-414;CP=2;R=213;D=012121212121212121212123210141212525452626452101212301012103212;e;
2019.12.19 22:17:35 4: nano_868Mhz: Read, msg: MU;P0=105;P1=-94;P2=-312;P3=212;P4=318;P5=-208;P6=-412;P7=-135;CP=0;R=213;D=01010101010101010101010201314101050545060645013101023131070701070;e;
2019.12.19 22:17:45 4: nano_868Mhz: Read, msg: MU;P0=204;P1=-102;P2=109;P3=-306;P4=318;P5=-218;P6=-414;CP=2;R=213;D=01212121212121212121212321014121252545262645210121230105;e;
2019.12.19 22:17:55 4: nano_868Mhz: Read, msg: MU;P0=-100;P1=114;P3=-312;P4=212;P5=312;P6=-210;P7=-420;P8=-136;CP=1;R=213;D=010101010101010101010101013104050101616561717561040101340481;e;
2019.12.19 22:18:05 4: nano_868Mhz: Read, msg: MU;P0=-102;P1=107;P2=-312;P3=211;P4=318;P5=-205;P6=-412;CP=1;R=213;D=0101010101010101010101210304010151545161645103010123030;e;
2019.12.19 22:18:15 4: nano_868Mhz: Read, msg: MU;P0=110;P1=-114;P3=-312;P4=208;P5=312;P6=-210;P7=-422;CP=0;R=213;D=010101010101010101010103014151010606560707560141010341410;e;
2019.12.19 22:18:25 4: nano_868Mhz: Read, msg: MU;P0=-102;P1=103;P2=-304;P3=213;P4=314;P5=-211;P6=-416;P7=-136;CP=1;R=213;D=010101010101010101010101210304010151545161645103010123037;e;
2019.12.19 22:18:35 4: nano_868Mhz: Read, msg: MU;P0=156;P1=-135;P2=94;P3=-98;P4=-312;P5=214;P6=312;P7=-208;P8=-420;CP=2;R=213;D=012123212323232323232323232323242353632327276728286723532324535121030;e;
2019.12.19 22:18:55 4: nano_868Mhz: Read, msg: MU;P0=110;P1=-98;P2=-312;P3=210;P4=317;P5=-204;P6=-412;CP=0;R=213;D=01010101010101010101010201314101050545060645013101023131;e;
2019.12.19 22:19:05 4: nano_868Mhz: Read, msg: MU;P0=144;P1=-99;P2=108;P3=-312;P4=211;P5=312;P6=-208;P7=-416;P8=-156;CP=2;R=213;D=01212121212121212121212321415121262656272756214121234148;e;
2019.12.19 22:19:15 4: nano_868Mhz: Read, msg: MU;P0=112;P1=-99;P2=-308;P3=211;P4=318;P5=-206;P6=-414;P7=-132;CP=0;R=213;D=0101010101010101010101020131410105054506064501310102313107;e;
2019.12.19 22:19:25 4: nano_868Mhz: Read, msg: MU;P0=108;P1=-100;P2=-312;P3=211;P4=319;P5=-204;P6=-416;CP=0;R=213;D=01010101010101010101010201314101050545060645013101023131;e;
2019.12.19 22:19:35 4: nano_868Mhz: Read, msg: MU;P0=98;P1=-97;P2=-312;P3=212;P4=313;P5=-206;P6=-418;CP=0;R=213;D=010101010101010101010102013141010505450606450131010231310;e;
2019.12.19 22:19:45 4: nano_868Mhz: Read, msg: MU;P0=-100;P1=109;P2=-312;P3=212;P4=319;P5=-204;P6=-414;P7=-136;CP=1;R=213;D=010101010101010101010101210304010151545161645103010123037;e;
2019.12.19 22:19:55 4: nano_868Mhz: Read, msg: MU;P0=110;P1=-100;P3=-312;P4=212;P5=312;P6=-211;P7=-422;CP=0;R=213;D=0101010101010101010101010103014151010606560707560141010341410;e;
2019.12.19 22:20:05 4: nano_868Mhz: Read, msg: MU;P0=-106;P1=98;P2=-312;P3=196;P4=314;P5=-211;P6=-414;CP=1;R=213;D=010101010101010101010101210304010151545161645103010123030301;e;
2019.12.19 22:20:15 4: nano_868Mhz: Read, msg: MU;P0=107;P1=-103;P2=-308;P3=212;P4=316;P5=-207;P6=-416;CP=0;R=213;D=0101010101010101010101020131410105054506064501310102313;e;
2019.12.19 22:20:25 4: nano_868Mhz: Read, msg: MU;P0=102;P1=-103;P2=-312;P3=216;P4=316;P5=-207;P6=-414;CP=0;R=213;D=01010101010101010101010201314101050545060645013101023131;e;
2019.12.19 22:20:35 4: nano_868Mhz: Read, msg: MU;P0=-142;P1=99;P2=-100;P3=-312;P4=212;P5=318;P6=-204;P7=-412;CP=1;R=213;D=0121212121212121212121213124252121616561717561242121342401;e;
2019.12.19 22:20:45 4: nano_868Mhz: Read, msg: MU;P0=-203;P1=108;P2=-104;P3=-312;P4=208;P5=316;P6=-414;CP=1;R=213;D=012121212121212121212121312425212101050161650124212134242;e;
2019.12.19 22:20:55 4: nano_868Mhz: Read, msg: MU;P0=-98;P1=107;P2=-308;P3=209;P4=319;P5=-204;P6=-414;CP=1;R=213;D=010101010101010101010101210304010151545161645103010123030;e;
2019.12.19 22:21:05 4: nano_868Mhz: Read, msg: MU;P0=100;P1=-96;P2=-312;P3=211;P4=312;P5=-202;P6=-420;P8=132;CP=0;R=213;D=01010101010101010101010201314101050545060645013101023135018;e;
2019.12.19 22:21:15 4: nano_868Mhz: Read, msg: MU;P0=-152;P1=104;P2=-108;P3=-312;P4=209;P5=311;P6=-211;P7=-416;CP=1;R=213;D=0121212121212121212121213124252121616561717561242121342421;e;
2019.12.19 22:21:25 4: nano_868Mhz: Read, msg: MU;P0=106;P1=-206;P2=-99;P3=207;P4=-312;P5=312;P6=-422;CP=0;R=213;D=01023202020202020202020202020402325202010151060651023202043232;e;
2019.12.19 22:21:35 4: nano_868Mhz: Read, msg: MU;P0=-106;P1=101;P2=148;P3=-312;P4=208;P5=312;P6=-209;P7=-420;CP=1;R=213;D=01020101010101010101010101013104050101616561717561040101340401;e;
2019.12.19 22:21:45 4: nano_868Mhz: Read, msg: MU;P0=-381;P1=104;P2=-100;P3=211;P4=313;P5=-211;CP=1;R=213;D=01212121212121212121212101232421215154510104512321210323;e;
2019.12.19 22:21:55 4: nano_868Mhz: Read, msg: MU;P0=100;P1=-113;P2=-312;P3=209;P4=312;P5=-208;P6=-420;CP=0;R=213;D=01010101010101010101010201314101050545060645013101023131;e;
2019.12.19 22:22:00 4: nano_868Mhz: Read, msg: MU;P0=104;P1=-103;P2=-312;P3=212;P4=314;P5=-189;P6=-417;P7=-144;CP=0;R=213;D=0101010101010101010101010201314101050545060646310101360507;e;
2019.12.19 22:22:05 4: nano_868Mhz: Read, msg: MU;P0=-192;P1=108;P2=-102;P3=-312;P4=210;P5=320;P7=-414;CP=1;R=213;D=012121212121212121212121312425212101050171757421212471;e;
2019.12.19 22:22:10 4: nano_868Mhz: Read, msg: MU;P0=107;P1=-99;P2=-312;P3=210;P4=316;P5=-211;P6=-414;CP=0;R=213;D=010101010101010101010102013141010505450606463101013601;e;
2019.12.19 22:22:20 4: nano_868Mhz: Read, msg: MU;P0=-207;P1=106;P2=-100;P3=-312;P4=213;P5=311;P6=-417;CP=1;R=213;D=012121212121212121212121312425212101050161656421212461;e;
2019.12.19 22:22:30 4: nano_868Mhz: Read, msg: MU;P0=-101;P1=107;P2=-304;P3=211;P4=318;P5=-205;P6=-413;CP=1;R=213;D=010101010101010101010101210304010151545161646301010361;e;
2019.12.19 22:22:40 4: nano_868Mhz: Read, msg: MU;P0=117;P1=-95;P2=-312;P3=203;P4=316;P5=-202;P6=-416;CP=0;R=213;D=010101010101010101010101020131410105054506064631010136013101;e;
2019.12.19 22:22:50 4: nano_868Mhz: Read, msg: MU;P0=-144;P1=104;P2=-103;P3=-312;P4=209;P5=314;P6=-210;P7=-412;CP=1;R=213;D=0121212121212121212121213124252121616561717574212124712121;e;
2019.12.19 22:23:00 4: nano_868Mhz: Read, msg: MU;P0=99;P1=-102;P2=-312;P3=208;P4=318;P5=-208;P6=-413;CP=0;R=213;D=0101010101010101010101020131410105054506064631010136010;e;
2019.12.19 22:23:10 4: nano_868Mhz: Read, msg: MU;P0=-203;P1=107;P2=-102;P3=-312;P4=211;P5=316;P6=-412;CP=1;R=213;D=01212121212121212121212131242521210105016165642121246121;e;
2019.12.19 22:23:20 4: nano_868Mhz: Read, msg: MU;P0=-140;P1=188;P2=-100;P4=108;P5=-312;P6=320;P7=-204;P8=-412;CP=4;R=213;D=012124242424242424242424245421262424747674848681242421842124;e;
2019.12.19 22:23:30 4: nano_868Mhz: Read, msg: MU;P0=-206;P1=212;P2=-112;P3=101;P4=-312;P5=320;P6=-412;CP=3;R=213;D=01232323232323232323232343212523230305036365612323216323;e;
2019.12.19 22:23:40 4: nano_868Mhz: Read, msg: MU;P0=100;P1=-106;P2=-312;P3=209;P4=313;P5=-210;P6=-422;CP=0;R=213;D=010101010101010101010102013141010505450606463101013601;e;
2019.12.19 22:23:50 4: nano_868Mhz: Read, msg: MU;P0=-110;P1=103;P3=-312;P4=211;P5=312;P6=-209;P7=-418;P8=144;CP=1;R=213;D=010101010101010101010101010131040501016165617175740101047108;e;
2019.12.19 22:24:00 4: nano_868Mhz: Read, msg: MU;P0=-152;P1=206;P2=-104;P3=106;P4=-312;P5=316;P6=-208;P7=-416;CP=3;R=213;D=01012323232323232323232323432125232363656373757123232173232;e;
2019.12.19 22:24:10 4: nano_868Mhz: Read, msg: MU;P0=-106;P1=148;P3=106;P4=-298;P5=211;P6=318;P7=-205;P8=-412;CP=3;R=213;D=0103030303030303030303034305060303737673838685030305834;e;
2019.12.19 22:24:20 4: nano_868Mhz: Read, msg: MU;P0=109;P1=-97;P2=-312;P3=210;P4=318;P5=-210;P6=-414;CP=0;R=213;D=0101010101010101010101020131410105054506064631010136010;e;
2019.12.19 22:24:40 4: nano_868Mhz: Read, msg: MU;P0=-152;P1=103;P2=-102;P3=207;P4=-312;P5=313;P6=-210;P7=-417;CP=1;R=213;D=012321212121212121212121214123252121616561717573212123712;e;
2019.12.19 22:24:50 4: nano_868Mhz: Read, msg: MU;P0=-108;P1=130;P2=-209;P3=-320;P4=211;P5=318;P6=-413;P7=-144;CP=1;R=213;D=012101010101010101010101013104050101212521616564010104610171;e;
2019.12.19 22:25:00 4: nano_868Mhz: Read, msg: MU;P0=136;P1=-97;P2=102;P3=-312;P4=211;P5=312;P6=-210;P7=-418;CP=2;R=213;D=012121212121212121212123214151212626562727574121214721;e;
2019.12.19 22:25:10 4: nano_868Mhz: Read, msg: MU;P0=101;P1=-102;P2=-312;P3=211;P4=314;P5=-212;P6=-412;P7=-140;CP=0;R=213;D=010101010101010101010102013141010505450606463101013607;e;
2019.12.19 22:25:20 4: nano_868Mhz: Read, msg: MU;P0=104;P1=-116;P2=-312;P3=212;P4=317;P5=-204;P6=-416;CP=0;R=213;D=01010101010101010101010201314101050545060646310101360101;e;
2019.12.19 22:25:30 4: nano_868Mhz: Read, msg: MU;P0=-101;P1=211;P2=98;P3=-312;P4=311;P5=-198;P6=-420;CP=2;R=213;D=0102020202020202020202023201040202525452626461020201625;e;
2019.12.19 22:25:40 4: nano_868Mhz: Read, msg: MU;P0=102;P1=-104;P2=-312;P3=209;P4=311;P5=-201;P6=-420;CP=0;R=213;D=010101010101010101010102013141010505450606463101013605;e;
2019.12.19 22:25:50 4: nano_868Mhz: Read, msg: MU;P0=-200;P1=108;P2=-101;P3=-308;P4=212;P5=318;P6=-412;P7=-140;CP=1;R=213;D=0121212121212121212121213124252121010501616564212124617;e;
2019.12.19 22:26:00 4: nano_868Mhz: Read, msg: MU;P0=102;P1=-107;P3=-312;P4=209;P5=312;P6=-208;P7=-420;CP=0;R=213;D=0101010101010101010101010301415101060656070757410101470141;e;
2019.12.19 22:26:10 4: nano_868Mhz: Read, msg: MU;P0=109;P1=-113;P4=-312;P5=209;P6=313;P7=-210;P8=-420;CP=0;R=213;D=010101010101010101010101010104015161010707670808685101015801;e;
2019.12.19 22:26:20 4: nano_868Mhz: Read, msg: MU;P0=210;P1=-100;P2=109;P3=-312;P4=316;P5=-195;P6=-413;CP=2;R=213;D=012121212121212121212123210141212525452626460121210625;e;
2019.12.19 22:26:30 4: nano_868Mhz: Read, msg: MU;P0=-107;P1=119;P3=-312;P4=211;P5=314;P6=-210;P7=-417;CP=1;R=213;D=01010101010101010101010131040501016165617175740101047101;e;
2019.12.19 22:26:50 4: nano_868Mhz: Read, msg: MU;P0=105;P1=-114;P2=-312;P3=209;P4=314;P5=-210;P6=-416;CP=0;R=213;D=0101010101010101010101020131410105054506064631010136010;e;
2019.12.19 22:27:00 4: nano_868Mhz: Read, msg: MU;P0=101;P1=-106;P2=-312;P3=209;P4=314;P5=-203;P6=-420;CP=0;R=213;D=010101010101010101010102013141010505450606463101013601;e;
2019.12.19 22:27:10 4: nano_868Mhz: Read, msg: MU;P0=107;P1=-98;P2=-312;P3=213;P4=318;P5=-210;P6=-414;CP=0;R=213;D=01010101010101010101010201314101050545060646310101360;e;
2019.12.19 22:27:20 4: nano_868Mhz: Read, msg: MU;P0=-97;P1=160;P2=119;P3=-312;P4=210;P5=318;P6=-204;P7=-412;P8=-132;CP=2;R=213;D=010202020202020202020202320405020262656272757402020472028;e;
2019.12.19 22:27:30 4: nano_868Mhz: Read, msg: MU;P0=-114;P1=105;P3=-312;P4=210;P5=312;P6=-208;P7=-416;CP=1;R=213;D=0101010101010101010101013104050101616561717574010104710;e;
2019.12.19 22:27:40 4: nano_868Mhz: Read, msg: MU;P0=110;P1=-96;P2=-304;P3=212;P4=318;P5=-210;P6=-412;CP=0;R=213;D=010101010101010101010102013141010505450606463101013601;e;
2019.12.19 22:27:50 4: nano_868Mhz: Read, msg: MU;P0=-99;P1=104;P2=-312;P3=211;P4=312;P5=-210;P6=-418;CP=1;R=213;D=01010101010101010101012103040101515451616463010103610;e;
2019.12.19 22:28:00 4: nano_868Mhz: Read, msg: MU;P0=-100;P1=106;P3=-312;P4=211;P5=316;P6=-204;P7=-414;CP=1;R=213;D=01010101010101010101010131040501016165617175740101047101;e;
2019.12.19 22:28:10 4: nano_868Mhz: Read, msg: MU;P0=150;P1=-108;P2=105;P3=-312;P4=211;P5=312;P6=-211;P7=-419;CP=2;R=213;D=0121212121212121212121232141512126265627275741212147210;e;
2019.12.19 22:28:20 4: nano_868Mhz: Read, msg: MU;P0=-284;P1=108;P2=-98;P3=211;P4=318;P5=-204;P6=-413;CP=1;R=213;D=0121212121212121212121210123242121515451616463212123612;e;
2019.12.19 22:28:30 4: nano_868Mhz: Read, msg: MU;P0=152;P1=-109;P2=105;P3=-312;P4=213;P5=318;P6=-210;P7=-415;CP=2;R=213;D=012121212121212121212123214151212626562727574121214721;e;
2019.12.19 22:28:35 4: nano_868Mhz: Read, msg: MU;P0=-152;P1=104;P2=-100;P4=-312;P5=209;P6=312;P7=-212;P8=-420;CP=1;R=213;D=0121212121212121212121214125262121717671818526252121712525;e;
2019.12.19 22:28:45 4: nano_868Mhz: Read, msg: MU;P0=222;P1=-103;P2=108;P3=-312;P4=314;P5=-203;P6=-420;CP=2;R=213;D=012121212121212121212123210141212525452626014101212521010;e;
2019.12.19 22:28:55 4: nano_868Mhz: Read, msg: MU;P0=106;P1=-97;P2=-312;P3=220;P4=317;P5=-210;P6=-414;CP=0;R=213;D=0101010101010101010101020131410105054506063141310105013131;e;
2019.12.19 22:29:05 4: nano_868Mhz: Read, msg: MU;P0=99;P1=-106;P2=-312;P3=230;P4=314;P5=-210;P6=-422;P7=-144;CP=0;R=213;D=010101010101010101010102013141010505450606314131010501313107010;e;
2019.12.19 22:29:15 4: nano_868Mhz: Read, msg: MU;P0=-103;P1=109;P2=-312;P3=208;P4=318;P5=-203;P6=-412;P7=-152;CP=1;R=213;D=0101010101010101010101010121030401015154516163040301015103037;e;
2019.12.19 22:29:25 4: nano_868Mhz: Read, msg: MU;P0=-100;P1=110;P3=-312;P4=210;P5=310;P6=-202;P7=-418;CP=1;R=213;D=0101010101010101010101013104050101616561717405040101610404;e;
2019.12.19 22:29:35 4: nano_868Mhz: Read, msg: MU;P0=107;P1=-96;P2=-312;P3=210;P4=305;P5=-207;P6=-416;CP=0;R=213;D=0101010101010101010101020131410105054506063141310105013141;e;
2019.12.19 22:29:45 4: nano_868Mhz: Read, msg: MU;P0=108;P1=-100;P2=-312;P3=211;P4=319;P5=-203;P6=-414;CP=0;R=213;D=010101010101010101010102013141010505450606314131010501313;e;
ZitatWas genau bewirkt
Mit maxpulse kann man die max Pulslänge (default -32001) verkleinern, ab der ein Ende erkannt wird. Z.B. mit maxpulse 17000 wird -18532 als Ende erkannt.
@Ralf
ZitatWoher weisst Du, daß es 7 und nicht 6 Bit sein sollen?
Sorry, hab ich erst jetzt gesehen.
Das Protokoll ist bereits in der culfw implementiert, ich hab es vor einiger Zeit von Hand mit einem RFM12b Baustein zerlegt, das war aber extrem aufwändig.
Ich hab das Protokoll seit 3 Jahren mit FHEM im Einsatz, es läuft völlig Problemlos.
Die 07 ist die Längenangabe des Blockes und immer identisch und die 07 kommt
immer nach "17 mal AA danach 54 danach 07"
Nachtrag:
zur Erklärung, in der falschen Botschaft kommt anstelle 07 die 0F, im Byte davor die 54, binär 01010100 00001111 (für 54 0F also in summe 6 Nullen)
01010100 00000111 (für 54 07, also 7 Nullen, im Falle der falschen 0F sind alle nachfolgenden Bytes um 1 Bit verschoben)
Läuft die Datenübertragung per Serieller Schnittstelle eigentlich parallel zur Datenerfassung der Bits, z.B. wenn der erste Block vom CC1101 empfangen wird oder startet diese Datenübertragung irgendwann mitten in der Erfassung?
MU;P0=156;P1=-135;P2=94;P3=-98;P4=-312;P5=214;P6=312;P7=-208;P8=-420;CP=2;R=213;D=012123212323232323232323232323242353632327276728286723532324535121030;e;
@RaspII
habe ich dies richtig verstanden?
-135 und 156 passen nicht so richtig. evtl Messungenaugigkeit?
P3=-98 0
P1=-135
P7=-208 00
P4=-312 000
P8=-420 0000
P2=94 1
P0=156
P5=214 11
P6=312 111
Die Pattern Nr werden dann durch die entsprechenden Anzahl 0 und 1 Bits ersetzt
32324235 ergibt dann 01010001011
3 2 3 2 4 2 3 5
0 1 0 1 000 1 0 11
wo hast Du jetzt diesen String her?
MU;P0=156;P1=-135;P2=94;P3=-98;P4=-312;P5=214;P6=312;P7=-208;P8=-420;CP=2;R=213;D=012123212323232323232323232323242353632327276728286723532324535121030;e;
Der ist nicht von mir, nehme ich an
ZitatLäuft die Datenübertragung per Serieller Schnittstelle eigentlich parallel zur Datenerfassung der Bits, z.B. wenn der erste Block vom CC1101 empfangen wird oder startet diese Datenübertragung irgendwann mitten in der Erfassung?
Die Datenübertragung per Serieller Schnittstelle startet, wenn das Nachrichtenende am Puls der in der Variable cmaxpuls steht (z.B -32001) erkannt wurde.
Wenn ich die Nachricht als Array von Pulsen hätte, könnte ich es simulieren
z.B. [262,-154,262,-154,262,-154,262,-154,262,-154,262,-154,262,-154,262,-154,-154,...]
Mit einer korrekten MU-Nachricht, müsste ich mir das Array auch selber erstellen können.
Zitatwo hast Du jetzt diesen String her?
der ist von HomeAuto_User
Zitat von: Ralf9 am 19 Dezember 2019, 23:18:38
Mit einer korrekten MU-Nachricht, müsste ich mir das Array auch selber erstellen können.
Reicht das hier nicht aus?
https://forum.fhem.de/index.php/topic,82379.msg1003583.html#msg1003583 (https://forum.fhem.de/index.php/topic,82379.msg1003583.html#msg1003583)
Ich bräuchte eine MU-Nachricht ohne den Einzelbitfehler.
Eine MU-Nachricht mit dem Einzelbitfehler und das zugehörige richtige Ergebnis als Bitfolge würde mir auch reichen
MU;P0=464;P1=260;P2=-152;P4=-365;P5=-1412;P6=1724;P7=888;D=121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121412121562141275140412;CP=1;R=246;
MU;P0=1720;P1=-366;P2=468;P3=-1357;P4=890;P5=260;P6=-156;P7=-18540;D=1234356565647565656565656565656565656565656565656565656565656565656565656565656565656565656565656565656565656565656565656565656565656565656565656565156565306515643512156;CP=5;R=246;
MU;P0=1724;P1=-364;P2=470;P3=-1362;P4=886;P5=260;P6=-154;P7=-18528;D=1234356565647565656565656565656565656565656565656565656565656565656565656565656565656565656565656565656565656565656565656565656565656565656565656565156565306515643512156;CP=5;R=246;
MU;P0=1724;P1=-366;P2=466;P3=-1357;P4=888;P5=260;P6=-156;P7=-18540;D=1234356565647565656565656565656565656565656565656565656565656565656565656565656565656565656565656565656565656565656565656565656565656565656565656565156565306515643512156;CP=5;R=246;
MU;P0=680;P1=261;P2=-156;P3=-366;P4=-1254;P5=1724;P6=888;P7=468;D=1212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121213121214521312641373120374641212126;CP=1;R=246;
MU;P0=-18744;P1=263;P2=-156;P3=889;P4=-1254;P5=-364;P6=468;P7=680;D=01212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212341565127564341212123012121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212151;CP=1;R=246;O;
MU;P0=680;P1=262;P2=-156;P3=-366;P4=-1252;P5=1724;P6=888;P7=468;D=121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121213121214521312641373120374641212126;CP=1;R=246;
MU;P0=-18744;P1=260;P2=-156;D=01212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212;CP=1;R=246;
MU;P0=-366;P1=262;P2=-155;P3=889;P4=-1330;P5=468;P6=680;P7=-18740;D=01234105012605434121212371212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121210121214;CP=1;R=246;
MU;P0=-18744;P1=-156;P2=262;P3=-366;P4=888;P5=-1331;P6=470;P7=680;D=1232145236321736545212121402121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212123212125;CP=2;R=246;
MU;P0=680;P1=259;P2=-156;P3=-364;P4=-1256;P5=1724;P6=889;P7=468;D=1212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121213121214521312641373120374641212126;CP=1;R=246;
MU;P0=-330;P1=136;P2=-164;P3=384;P4=-115;P5=100;D=0121234541454525414141454141414141414141414101;CP=1;R=188;
Die erste Zeile wäre so eine (wie gesagt, leider passiert dann der Fehler zwischen ersten und zweiten Block, dann auch keine Einzelbits sondern eine Größere Lücke die ich nicht erklären kann)
Die erste Zeile hat aber nur 7 Pattern.
Ich bräuchte eine mit mehr als 8 Pattern
Alternativ, hier eine MU Nachricht mit Bitfehler:
MU;P0=-18956;P1=260;P2=-154;P4=-367;P5=-1253;P6=1724;P7=940;P8=-572;P9=1312;PA=468;PB=-784;CP=1;R=246;D=012121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212141212156214127812129274A5751B121;e;
Dazu die fehlerhafte Bitfolge:
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010100101010000001111111101001011111000101011111101111100110000001111100000010000101
und die von Hand korrigierte Bitfolge:
00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101001010100000001111111101001011111000101011111101111100110000001111100000010000101
Suche nach der ersten Sequenz mit 6 bzw. 7 Nullen
Danke, sowas wollte ich
Hey,
ich mache Schluss für heute (waren lange Nächte die letzen Tage).
Ich vermute, dass sich in Deiner Software Interuppts verdrängen oder irgend ein anderes Laufzeitproblem.
Bevor wir jetzt zuviel Zeit investieren können wir auch den synchronen seriellen Mode in Betrieb nehmen.
Wäre aber trotzdem schade so kurz vor dem Ziel aufzugeben.
Besteht interesse, daß ich das Auslesen des FIFO in die Firmware einbaue?
Der Aufwand ist überschaubar, da es die Routinen in der rf_native.c schon gibt.
Die ausgelesenen Bytes des FIFOs könnten dann, z.B. als neuen rawmsg Typ in Hex ausgegeben werden
z.B. MN;D=0123ABF;
Dazu bräuchte ich eine Möglichkeit GFSK oder FSK Nachrichten zu senden.
Wenn ich mir einen weiteren Signalduino zusammenbauen würde, könnte ich dann auch FSK senden?
Nachtrag:
Sind die Daten die vom FIFO ausgelesen werden, die gleichen wie die über synchron oder asynchron
Wenn Du einen NanoCul reinprogrammierst kann ich Dir die FHEM Configuration zum Senden geben.
Dazu benötige ich einen weiteren cc1101
ist dieses Modul ok?
https://www.amazon.de/Neuftech-Wireless-Module-Transceiver-externen/dp/B01CI01F94/ref=sr_1_3?__mk_de_DE=%C3%85M%C3%85%C5%BD%C3%95%C3%91&keywords=cc1101+433&qid=1576797524&sr=8-3
Nein, du brauchst 868 Mhz.
Kannst Du nicht einfach Deinen Signalduino klonen oder ist der auch 433Mhz?
Kann ich FSK auch auf 433MHz senden und empfangen?
Wenn Du keine Reichweite benötigst kannst Du das 433 MHz Modul auf 868Mhz betreiben (die Antennenanpassung ist falsch).
Mit blauen Modulen habe ich aber schon viele Probleme gehabt (die Frequenz lag daneben), für 868 Mhz nehme ich aktuell die Module im Anhang
Kann ich FSK auch auf 433MHz senden und empfangen?
Das müsste schon gehen, aber meine Firmware schreibt die Frequenz fest auf 868 Mhz, aber dann wäre ich dran mit "Spezialversion"
ok, das ist kein Problem, ich kann dafür dann auch 868MHz verwenden
Kann man eigentlich in Deine Sourcen reinschauen?
Mit welcher Entwicklungsumgebung arbeitest Du?
ZitatMit welcher Entwicklungsumgebung arbeitest Du?
Mit der Arduino IDE
ZitatKann man eigentlich in Deine Sourcen reinschauen?
https://github.com/Ralf9/SIGNALDuino/tree/dev-r332_cc1101
die aktuellen Änderungen sind noch nicht drin
Ich habe den Fehler gefunden, es liegt an der Toleranz von 0.2
fehlerhaft
MU;P0=-18956;P1=260;P2=-154;P4=-367;P5=-1253;P6=1724;P7=940;P8=-572;P9=1312;PA=468;PB=-784;CP=1;R=246;D=
156214127812129274A5751B121;
aussehen müsste es so:
P5=-1200
PC=-1400
1C6214127812129274A5751B121;
100000001111111101001011111000101011111101111100110000001111100000010000101Wenn ein Pattern in der Toleranz ist, wird der Mittelwert gebildet:
(1200+1400)/2 = 1300
(1300+1200)/2 = 1250
dies sind dann die fehlerhaften P5=-1253;
Wenn ich die Toleranz auf 0.1 reduziere sollte es passen
Gruß Ralf
Ok, das könnten wir mal testen.
Das Problem ist vermutlich auch, dass die ersten Bitzeiten nach Flankenwechsel nicht symetrisch sind, siehe min. Los- und High-Zeiten.
Ich ziehe deshalb von den Patternzeit immer die Min Zeit des entsprechenden Patterns ab. Teilt man der Rest dann durch die Bitzeit (= min low- + min high-Zeit) komme ich immer sehr exakt auf vielfache der Bitzeit (außer im Fehlerfall)
Aber ich denke es mach keinen Sinn das schon in Deinem Algorithmus zu korrigieren
Nachtrag:
Das soll heißen deine Änderung kaschiert vermutlich nur das Problem, dass alle gemessenen Low Pattern etwas zu kurz sind und alle gemessenen high Pattern etwas zu lang (~ 50usec)
Bei 10 Nullen oder Einsen wird auch die Toleranz von 0.1 knapp.
Welche Toleranz möchtest Du haben?
Nachtrag:
Bei der Toleranz werden die negativen und positiven Pulse getrennt betrachtet
Ich glaube das Problem ist nicht die Toleranz sondern die Klassen selbst
Ich muss mir das heute Abend mal in Ruhe überlegen
Nachtrag zur Erklärung
Bei der Assynchronen Abtastung wird mit Faktor 8 Überabgetastet, d.h. der Jitter beträgt je Flanke 208/8=26 usec. Im Worst Case jittern beide Flanken Gegensätzlich, d.h. In Summe 52 usec.
D.h. das kleinste Pattern wird bei etwa 156usec liegen, dazu könnte nich ein Jitter in der Software kommen
Zitat von: Ralf9 am 19 Dezember 2019, 23:06:19
MU;P0=156;P1=-135;P2=94;P3=-98;P4=-312;P5=214;P6=312;P7=-208;P8=-420;CP=2;R=213;D=012123212323232323232323232323242353632327276728286723532324535121030;e;
@RaspII
habe ich dies richtig verstanden?
-135 und 156 passen nicht so richtig. evtl Messungenaugigkeit?
P3=-98 0
P1=-135
P7=-208 00
P4=-312 000
P8=-420 0000
P2=94 1
P0=156
P5=214 11
P6=312 111
Die Pattern Nr werden dann durch die entsprechenden Anzahl 0 und 1 Bits ersetzt
32324235 ergibt dann 01010001011
3 2 3 2 4 2 3 5
0 1 0 1 000 1 0 11
Wenn ich es richtig verstanden habe, ja.
Genau so, steht es auch in der cc1101 Doku, das fsk-4 4 Zustände hat.
Zitat von: Ralf9 am 20 Dezember 2019, 00:33:59
Kann ich FSK auch auf 433MHz senden und empfangen?
Ich denke, da sollte nichts dagegen sprechen.
Edit:
Ich überlegte schon den Sender (FSK) zu öffnen und parallel am cc1101 Messe was ankommt um direkt zu vergleichen. Das würde doch mehr Aufschluss bringen, oder.
Gesendet von iPad mit Tapatalk Pro
Zitat von: Ralf9 am 20 Dezember 2019, 00:10:42
Nachtrag:
Sind die Daten die vom FIFO ausgelesen werden, die gleichen wie die über synchron oder asynchron
Zu Deiner Frage:
Ja die Daten sind die selben.
M.E. macht das Fifo hauptsächlich Sinn wenn Du das Sync Pattern nutzen kannst, da dann die Bytes schon korrekt synchronisiert sind.
Bei unbekannten Botschaften kennst Du kein Sync Pattern, d.h. die einzelnen Bytes können völliger Quatsch sein, da die Bits noch nicht auf der richtigen Position landen.
Bei unbekannten Protokollen halte ich den Sync Mode am Sinnvollsten, damit kannst du die einzelnen Bits leichter analysieren und auf die richtige Position schieben.
Unsicher bin ich bzgl. der Frage ob man die Bitrate kennen muss. Ich erinnere mich schwach daran, dass ich irgendwo gelesen habe, dass beim FSK Protokoll der Takt aus dem Signal zurückgewonnen wird, dann würde die Bitrate (im Sync Mode) vom CC1101 selbst generiert werden. Im Async Mode muss diese m.e. aber immer korrekt eingestellt sein, da sonst die Abtastrate nicht stimmt.
Außerdem stellt man über die Bitrate auch immer ein Bandpassfilter ein, bei falsch eingestellter Bitrate leidet dann zumindest immer die Empfindlichkeit.
Das sollten wir mal testen
ZitatM.E. macht das Fifo hauptsächlich Sinn wenn Du das Sync Pattern nutzen kannst, da dann die Bytes schon korrekt synchronisiert sind.
Kann demnach der Fifo nur genutzt werden, wenn die Preamble and sync word detection aktiv ist
Sync Mode bedeutet dann, daß z.B. GDO2 der Takt ist und auf GDO0 die Datenbits sind. Dann müsste bei jeder fallender Flanke von GDO2 ein Interrupt ausgelöst und das Datenbit auf GDO0 in einen Fifo gespeichert werden.
Die Frage ist ob dies mit sehr kurzen Taktpulsen wie z.B. denen von HomeAuto_User geschwindigskeitsmässig noch mit einem Nano funktioniert.
Wenn ich dies richtig sehe wird da dann alle 100us ein Interrupt ausgelöst.
Gruß Ralf
Nachtrag:
Das Fifo kann auch ohne Sync genutzt werden.
Ja, stimmt, Mammuts dieUnterrupts dann Laufzeioptimieren.
Ich hab glaube ich auch einen Denkfehler gemacht.
Der Signalduino schickt die Daten ja auch Byteweise weiter, dann kann man die Daten auch gleich Byteweise holen.
Ich bin von der CUL Implementierung ausgegangen, dort wird die Botschaft gleich interpretiert
Aber nochmal zum Fehler: es muss einen Unterschied zwischen der Alten und neuen Firmwarevariante geben
Durch die erhöhung der max Pattern Anzahl wurden nach den 7 x 0 (P5=-1400) noch 2 zusätzliche 6 x 0 mit einem Pattern von ca -1200 angehängt
MU;P0=-18956;P1=260;P2=-154;P4=-367;P5=-1253;P6=1724;P7=940;P8=-572;P9=1312;PA=468;PB=-784;CP=1;R=246;D=
ohne die Erhöhung sah es so aus
...156214127812129274
mit der Erhöhung sah es so aus
...156214127812129274A5751B121;
die erste 5 war ursprünglich (P5=-1400),
da das zweite 5 (6 x 0) ein Pattern von ca -1200 hat liegt es in der Toleranz von der ersten 5 (-1400),
es wird nun von beiden ein Mittelwert gebildet (1200+1400)/2 = 1300, P5 ist dann -1300,
und da die dritte 5 mit ca -1200 auch in der Toleranz ist, wird wieder ein Mittelwert gebildet und P5 ist jetzt -1250
Hallo Ralf, ich schaute mal etwas und versuchte Infos zu sammeln.
Zitat von: Ralf9 am 20 Dezember 2019, 17:48:39
Die Frage ist ob dies mit sehr kurzen Taktpulsen wie z.B. denen von HomeAuto_User geschwindigskeitsmässig noch mit einem Nano funktioniert.
Wenn ich dies richtig sehe wird da dann alle 100us ein Interrupt ausgelöst.
Gruß Ralf
Ich denke, das sollte klappen weil es werden Jeelinks vertrieben mit Cc1101 und einem Nano. Dem würde ich entnehmen, das wir vielleicht nur die falschen Einstellungen haben oder noch etwas vielleicht übersehen. Ich möchte mal schauen, ob wir über die dortige FW mehr Erkenntnisse sammeln können.
Lg
Gesendet von iPhone mit Tapatalk Pro
Wenn der TX35TH-IT eine Datenrate von 9.579 kbps hat und die Bitlänge von ca 100us,
hat dann ein Sensor mit einer Datenrate von 17.241 kbps wie z.B. TX25-IT eine Bitlänge von ca 55us?
Zitat von: Ralf9 am 20 Dezember 2019, 19:38:02
die erste 5 war ursprünglich (P5=-1400),
da das zweite 5 (6 x 0) ein Pattern von ca -1200 hat liegt es in der Toleranz von der ersten 5 (-1400),
es wird nun von beiden ein Mittelwert gebildet (1200+1400)/2 = 1300, P5 ist dann -1300,
und da die dritte 5 mit ca -1200 auch in der Toleranz ist, wird wieder ein Mittelwert gebildet und P5 ist jetzt -1250
Hab ich jetzt noch nicht verstanden.
Kannst Du mir den Code senden der diese Mittelwetbildung macht?
Irgendwie hört sich das alles noch nicht logisch für mich an
https://github.com/Ralf9/SIGNALDuino/blob/f155fab7df861f6635cf7d6abe464f88bd586763/src/_micro-api/libraries/signalDecoder/src/signalDecoder.cpp#L201-L205
hier wird mit einer Toleranz von 0.2 gesucht ob es das Pattern schon gibt
https://github.com/Ralf9/SIGNALDuino/blob/f155fab7df861f6635cf7d6abe464f88bd586763/src/_micro-api/libraries/signalDecoder/src/signalDecoder.cpp#L1189-L1206
https://github.com/Ralf9/SIGNALDuino/blob/f155fab7df861f6635cf7d6abe464f88bd586763/src/_micro-api/libraries/signalDecoder/src/signalDecoder.cpp#L150-L153
Hallo,
Zitat von: Ralf9 am 20 Dezember 2019, 22:02:46
Wenn der TX35TH-IT eine Datenrate von 9.579 kbps hat und die Bitlänge von ca 100us,
hat dann ein Sensor mit einer Datenrate von 17.241 kbps wie z.B. TX25-IT eine Bitlänge von ca 55us?
ich habe mal geschaut und folgendes bisher gefunden.
Hier sind Informationen zu dem TX35DTH und TX29-IT. (https://github.com/merbanan/rtl_433/blob/master/src/devices/lacrosse_tx35.c)
Laut hier, (https://www.seegel-systeme.de/2015/02/07/funkthermometer/) hat der
- TX35-IT eine Datenrate von 9,579 kbit/s mit einer Pulslänge von 105
- TX29-IT mit der Daterate von 17,241 kbit/s mit einer Pulslänge von 55
- TX25-IT mit der Daterate von 17,241 kbit/s
Da viele Sensortypen auch die gleiche Datenrate verwenden, so vermute ich mal, das diese den selben Puls haben können. Leider habe ich bisher zu den anderen Bezeichnungen noch keine Referenzen gefunden.
Edit:
Hier sind mal noch ein paar RAWMSG wo die Pattern > 7 sind nachdem ich mal das Register ein wenig versuchte anzupassen.
2019.12.21 02:25:36 4: nano_868Mhz: Read, msg: MU;P0=140;P1=-102;P2=100;P3=-320;P4=212;P5=316;P6=-210;P7=-468;P9=420;CP=2;R=203;D=012121212121212121212123214151212626562726272641212121912;e;
2019.12.21 02:25:46 4: nano_868Mhz: Read, msg: MU;P0=96;P1=-103;P2=132;P3=-312;P4=210;P5=312;P6=-211;P7=-468;P8=420;P9=-142;CP=0;R=203;D=01210101010101010101010103014151010606560706070641010101812909;e;
2019.12.21 02:25:56 4: nano_868Mhz: Read, msg: MU;P0=-103;P1=164;P2=105;P3=-312;P4=212;P5=316;P6=-209;P7=-468;P9=420;CP=2;R=203;D=0102020202020202020202023204050202626562726272640202020902;e;
2019.12.21 02:26:06 4: nano_868Mhz: Read, msg: MU;P0=102;P1=-105;P3=-312;P4=210;P5=316;P6=-207;P7=-468;P9=420;PA=136;CP=0;R=203;D=01010101010101010101010301415101060656070607064101010191A1;e;
2019.12.21 02:26:16 4: nano_868Mhz: Read, msg: MU;P0=-105;P1=154;P2=103;P3=-312;P4=210;P5=316;P6=-209;P7=-470;P8=420;CP=2;R=203;D=0102020202020202020202023204050202626562726272640202020801;e;
2019.12.21 02:26:26 4: nano_868Mhz: Read, msg: MU;P0=-103;P1=102;P2=-312;P3=210;P4=316;P5=-208;P6=-468;P8=416;P9=132;CP=1;R=203;D=0101010101010101010101012103040101515451615161530101010809;e;
2019.12.21 02:26:36 4: nano_868Mhz: Read, msg: MU;P0=103;P1=-207;P2=154;P3=-101;P5=-312;P6=208;P7=316;P9=-468;PA=416;CP=0;R=203;D=0123030303030303030303030305036373030101710901090163030303A32;e;
2019.12.21 02:26:46 4: nano_868Mhz: Read, msg: MU;P0=-96;P1=101;P2=-312;P3=206;P4=312;P5=-210;P6=-466;P7=416;P8=-128;CP=1;R=203;D=0101010101010101010101012103040101515451615161530101010701830;e;
2019.12.21 02:26:56 4: nano_868Mhz: Read, msg: MU;P0=104;P1=-100;P2=-312;P3=198;P4=312;P5=-210;P6=-470;P7=420;CP=0;R=203;D=01010101010101010101010201314101050545060506053101010171310;e;
2019.12.21 02:27:06 4: nano_868Mhz: Read, msg: MU;P0=144;P1=-100;P2=110;P3=-312;P4=212;P5=316;P6=-209;P7=-466;P8=420;CP=2;R=203;D=01212121212121212121212321415121262656272627264121212181212;e;
2019.12.21 02:27:16 4: nano_868Mhz: Read, msg: MU;P0=103;P1=-103;P2=-312;P3=212;P4=312;P5=-206;P6=-470;P7=420;CP=0;R=203;D=0101010101010101010101020131410105054506050605310101017101;e;
2019.12.21 02:27:26 4: nano_868Mhz: Read, msg: MU;P0=-103;P1=116;P2=-312;P3=210;P4=312;P5=-206;P6=-468;P7=420;CP=1;R=203;D=0101010101010101010101010121030401015154516151615301010107010;e;
Welche Variante nun von den RAMSG´s die plausibelste ist zu einem Ergebnis, das müssen wir noch herausfinden.
PS, Ralf, was ist der Kürzel
- e am Ende der RAWMSG ?
- i am Ende der RAWMSG ?
Hallo Ralf
ich denke es ist einfacher wenn wir die Daten im Sync Mode lesen, danach kann man sehr leicht den Fifo Mode implementieren.
Mit welcher Entwicklungsumgebung arbeitest Du?
Sobald ich etwas Zeit habe könnte ich mich dann auch mal selbst ans Wer machen, evt gleich mit einer Variante auf Github?
@Ralf
Zitathier wird mit einer Toleranz von 0.2 gesucht ob es das Pattern schon gibt
Ich denke ich hab das jetzt verstanden.
Ab 5 identischen Bit ist die Toleranz > 1 Bit, so kann das nicht werden.
Könntest Du noch eine Variante mit .1 machen?
Mich würde interessieren ob die Theorie stimmt
ZitatKönntest Du noch eine Variante mit .1 machen?
Macht es evtl Sinn gleich auf 0.08 runter zu gehen oder ist dies dann für kleine Pulse zu klein.
Bei 200 ist die Toleranz dann 16 und bei 100 nur 8
ZitatMit welcher Entwicklungsumgebung arbeitest Du?
Ich arbeite mit der Arduino IDE
Ja, mache Sinn
Arduino IDE ist nicht mein Ding 😎
Ich mache mal die erste Schritte auf dem NanoCul und poste hier die Ergebnisse
hier ist die 3.3.2.2-rc10t mit Tol = 0.08
Da an der Firmware in der Anlage irgendwas nicht gepasst hat, habe ich sie gelöscht
Hat leider gar nicht funktioniert, das Problem bleibt exakt identisch (keine Änderung sichtbar)
Eigentlich müsse man die Tol. auf 0.2xMinimale Bitzeit programmieren, dann bleibt die Toleranz für alle Klassen gleich.
Mininale Bitzeit = (Betrag(Minimale Lowzeit) + Minimale Highzeit)/2
Noch was:
Der Signalduino verliert jetzt nach jedem Powerfail seine Konfiguration, da ist irgendwie ein größeres Problem reingerutscht
bekommst Du mit V die Version "3.3.2.2-rc10t"?
ZitatDer Signalduino verliert jetzt nach jedem Powerfail seine Konfiguration, da ist irgendwie ein größeres Problem reingerutscht
was verliert er, die cc001 konfiguration oder die konfigurationsvariablen?
Ich habe mal diese Pattern gesendet:
{-154,260,-154,260,-154,260,-154,260,-154,260,-154,260,-154,260,-154,260,-154,260,-154,260,-154,260,-154,260,-154,260,-154,260,-154,260,-154,260,-154,260,-154,260,-1400,1724,-154,260,-367,260,-154,940,-572,260,-154,260,-154,1312,-154,940,-367,468,-1200,940,-1200,260,-784,260,-154,260}und habe dann folgendes erhalten, dies passt
MU;P0=-154;P1=260;P2=-1400;P3=1724;P4=-367;P5=940;P6=-572;P7=1312;P8=468;P9=-1200;PA=-784;CP=1;R=0;D=0101010101010101010101010101010101012301410561010705489591A101;e;Ich schaue es mir heute Abend genauer an
Die CC1101 Config.
Oder muss ich jedesmal zuerst neu initialisieren?
Zitat von: HomeAuto_User am 21 Dezember 2019, 01:04:54
Hallo,
ich habe mal geschaut und folgendes bisher gefunden.
Hier sind Informationen zu dem TX35DTH und TX29-IT. (https://github.com/merbanan/rtl_433/blob/master/src/devices/lacrosse_tx35.c)
Laut hier, (https://www.seegel-systeme.de/2015/02/07/funkthermometer/) hat der
- TX35-IT eine Datenrate von 9,579 kbit/s mit einer Pulslänge von 105
- TX29-IT mit der Daterate von 17,241 kbit/s mit einer Pulslänge von 55
- TX25-IT mit der Daterate von 17,241 kbit/s
Hallo,
diese Sensoren können mit dem LaCross-Gateway (RFM12,RFM69..) (https://wiki.fhem.de/wiki/LaCrosseGateway_V1.x) , JeeLink (RFM12,RFM69..) (https://wiki.fhem.de/wiki/JeeLink) oder einem CUL (CC1101) mit a-culfw (https://github.com/heliflieger/a-culfw/tree/master/culfw/Devices) empfangen werden.
Dort könnte man sich auch die Config der Register ansehen um FSK oder G-FSK einzustellen (https://github.com/heliflieger/a-culfw/blob/master/culfw/clib/cc1100.c).
In der board.h hier für den CUL Nano (https://github.com/heliflieger/a-culfw/blob/master/culfw/Devices/CUL/board.h) müssen dann noch Protokolle freigeschaltet oder abgeschaltet werden, da unter Umständen der Speicher nicht reicht. Oder man versucht es mit einem STM32, der hat mehr Speicher.
pejonp
ZitatDer Signalduino verliert jetzt nach jedem Powerfail seine Konfiguration, da ist irgendwie ein größeres Problem reingerutscht
Ich habe mir jetzt auch einen nano mit cc1101 zusammengebaut und getestet, mit dem hex File hat irgendwas nicht gepasst.
In der Anlage ist ein neues Hexfile mit der Version V 3.3.2.2-rc10T
ich habe mal zur Gegenprobe die Pattern aus 4 Nachrichen vorher mit der Toleranz 0.2 gesendet, dann erhalte ich die Fehlerhafte MU-Nachricht mit 3 mal P2=-1250
MU;P0=-154;P1=260;P2=-1250;P3=1724;P4=-367;P5=940;P6=-572;P7=1312;P8=468;P9=-784;CP=1;R=0;D=01010101010101010101010101010101010123014105610107054825219101;e;ZitatWenn Du einen NanoCul reinprogrammierst kann ich Dir die FHEM Configuration zum Senden geben.
Ich habe jetzt eine nanocul Hardware, welche firmware soll ich flashen?
@HomeAuto_User
ZitatHier sind mal noch ein paar RAWMSG wo die Pattern > 7 sind nachdem ich mal das Register ein wenig versuchte anzupassen.
Welche Variante nun von den RAMSG´s die plausibelste ist zu einem Ergebnis, das müssen wir noch herausfinden.
asynch- und sync-Mode ist sinnvoll um unbekannte FSK Protokolle zu analysieren.
Beim asynch-Mode ist die Umwandlung der Daten der MU-Nachricht in eine Bitfolge sehr aufwändig.
Bei sehr kleinen Patternwerten scheint irgendwas nicht zu passen
Bei bekannten Protokollen ist es sinnvoller wie beim cul den FIFO des cc1101 zu verwenden
ZitatPS, Ralf, was ist der Kürzel
- e am Ende der RAWMSG ?
- i am Ende der RAWMSG ?
e bedeutet, daß ein Ende erkannt wurde (default maxPulse=32001)
i bedeutet, daß die MU-Nachricht von der prinzipiellen Patternfolge als Manchester erkannt wurde, das decodieren wurde aber wegen einer invaliden Patternfolge abgebrochen.
Zitat von: pejonp am 21 Dezember 2019, 17:53:39
Hallo,
diese Sensoren können mit dem LaCross-Gateway (RFM12,RFM69..) (https://wiki.fhem.de/wiki/LaCrosseGateway_V1.x) , JeeLink (RFM12,RFM69..) (https://wiki.fhem.de/wiki/JeeLink) oder einem CUL (CC1101) mit a-culfw (https://github.com/heliflieger/a-culfw/tree/master/culfw/Devices) empfangen werden.
Dort könnte man sich auch die Config der Register ansehen um FSK oder G-FSK einzustellen (https://github.com/heliflieger/a-culfw/blob/master/culfw/clib/cc1100.c).
In der board.h hier für den CUL Nano (https://github.com/heliflieger/a-culfw/blob/master/culfw/Devices/CUL/board.h) müssen dann noch Protokolle freigeschaltet oder abgeschaltet werden, da unter Umständen der Speicher nicht reicht. Oder man versucht es mit einem STM32, der hat mehr Speicher.
pejonp
Vielen Dank pejonp,
ich habe schon einige Files durchgesehen aber kam bisher noch nicht zum Erfolg.
Vielleicht kann mir einer dabei behilflich sein.
Fröhliche Weihnachtszeit
Zitat von: Ralf9 am 21 Dezember 2019, 19:01:57
Ich habe jetzt eine nanocul Hardware, welche firmware soll ich flashen?
sorry, ich hatte heute Mittag Familiäre Verpflichtungen, also keine Zeit ;D
Flash die ganz normale NanoCUL Firmware rein, ich suche Dir gleich die FHEM Config raus
https://sourceforge.net/p/culfw/code/HEAD/tree/trunk/culfw/Devices/nanoCUL/ (https://sourceforge.net/p/culfw/code/HEAD/tree/trunk/culfw/Devices/nanoCUL/)
Nachtrag:
define CUL_0 CUL /dev/ttyAMA0@38400 1234 <Hier Deinen NanoCUL definieren>
setuuid CUL_0 5c9d39a5-f33f-199e-18e9-473a5f726675ecb5
attr CUL_0 rfmode KOPP_FC
attr CUL_0 room TestFSK
define Gartenweg KOPP_FC 21 FA5E 02 11
setuuid Gartenweg 5c9d39bf-f33f-199e-51f2-824dfa12a2662016
attr Gartenweg IODev CUL_0
attr Gartenweg group Lampen
attr Gartenweg icon scene_garden
attr Gartenweg model Switch_8080_01_2Key
attr Gartenweg room TestFSK
attr Gartenweg webCmd on:offWas die setuuid Attribute machen kann ich Dir nicht sagen, die wurden automatisch festgelegt (vermutlich bei eiem FHEM Update), muss ich mal nachlesen. Bei Problemen löschen!
Dein neues Hexfile habe ich auch getestet, funktioniert deutlich besser.
Aber nachdem jetzt 192 Bits korrekt empfangen wurden fehlt das letzte Bit im Block. In diesem Fall wurden max. 12 Pattern gefunden
Manchmal kommt der Block auch komplett vermurkst, meistens dann wenn 13 oder mehr pattern gefunden wurden.
Ich kann jetzt den Signalduino auch übersetzen, vielleicht macht es Sinn gleich auf den Sync Mode zu gehen
ich habe nun folgendes vor.
- Unter sonstige Systeme ein neues Thema "FSK mit dem SIGNALDuino" eröffnen, dort können dann u.a. die für FSK notwendigen Registeränderungen dokumentiert und diskutiert werden.
- eine neue Version "V 3.3.3.0-dev"
#define VERSION_1 0x33
#define VERSION_2 0x30
VERSION_1 ist in der EEPROM Adr 00, wenn sich diese ändert, erfolgt ein cc1101 factory reset
VERSION_2 ist in der EEPROM Adr 01, wenn sich diese ändert, erfolgt ein factory reset der konfigurations Variablen (CG)
Am Besten ist es wahrscheinlich, wenn ich für die "V 3.3.3.0-dev" einen neuen branch mache, wie gehe ich da vor?
Ein Pullrequest der "V 3.3.2.2-rc10" in den Master und dann einen neuen branch "dev-r333_cc1101"?
- eine neue Konfigurationsvariable "mode"
mode=0 - normal
mode=1 - synch Modus
pinAsInput(PIN_SEND);
für PIN_RECEIVE eine neue Interrupt Routine, in der Interrupt Routine werden die von PIN_SEND empfangenen Bits im FIFO gespeichert
mode=2 - es wird der cc1101 FIFO verwendet
Gruß Ralf
Neues Thema Ralf [emoji106]
Somit splitten wir alles übersichtlicher.
Branch, nutzt du GitHub Desktop? So geht es sehr simple.
Gesendet von iPhone mit Tapatalk Pro
Ja, ich nutze u.a. auch GitHub Desktop und TortoiseGit
Ist bei Euch das Fhem Forum sehr langsam mit langen Reaktionszeiten?
Zitat von: Ralf9 am 22 Dezember 2019, 12:35:43
Ja, ich nutze u.a. auch GitHub Desktop und TortoiseGit
Ist bei Euch das Fhem Forum sehr langsam mit langen Reaktionszeiten?
Ja, das Forum ist träge. Es wurde auch schon ein Faden irgendwo geöffnet sah ich in der Übersicht.
Unter Github Desktop kannst du einen neuen Branch anlegen wie folgt,
- auf den Repro wechseln
- dann oberhalb in den Menüs gibt es einen Punkt ,,Create Branch"
- danach fragt er dich, von wo er ,,abzweigen soll", klicke da deinen Branch an und vergebe einen neuen Namen
Menüs habe ich gerade nicht vor mir, deswegen etwas allgemein gehalten.
Gesendet von iPhone mit Tapatalk Pro
Zitat von: Ralf9 am 22 Dezember 2019, 12:11:26
ich habe nun folgendes vor.
- Unter sonstige Systeme ein neues Thema "FSK mit dem SIGNALDuino" eröffnen, dort können dann u.a. die für FSK notwendigen Registeränderungen dokumentiert und diskutiert werden.
Hi Ralf9,
mein Wunschzettel für Weihnachten: ich bin ja seit über einem Jahr an dem Thema SIGNALduino und FSK dran, habe aber eine längere Pause gemacht. Aus meiner Sicht wäre es hilfreich/wünschenswert den Frequenzhub, die Bandbreite und die Baudrate via SIGNALduino-Modul separat einstellen zu können.
VG plin
Zitat von: plin am 22 Dezember 2019, 14:20:22
Hi Ralf9,
mein Wunschzettel für Weihnachten: ich bin ja seit über einem Jahr an dem Thema SIGNALduino und FSK dran, habe aber eine längere Pause gemacht. Aus meiner Sicht wäre es hilfreich/wünschenswert den Frequenzhub, die Bandbreite und die Baudrate via SIGNALduino-Modul separat einstellen zu können.
VG plin
Da hast du ja gleich den Wunschzettel vollgeschrieben ;) Ich denke das könnte man anstellen, wenn man den Empfang erstmal via Registerschreiben (manuell) sicherstellte mit plausiblen Ergebnis.
Gesendet von iPhone mit Tapatalk Pro
Zitat von: HomeAuto_User am 22 Dezember 2019, 14:31:55
Da hast du ja gleich den Wunschzettel vollgeschrieben ;) Ich denke das könnte man anstellen, wenn man den Empfang erstmal via Registerschreiben (manuell) sicherstellte mit plausiblen Ergebnis.
na ja, das sind die Themen die mich vor/seit einem Jahr bewegt haben. Damals habe ich mittels RF Studio die aus meiner Sicht erforderlichen Registereinstellungen ermittelt und mittels Script/Set Commands dem CC1101 eingeimpft. Das hat damals weder in puncto empfangen noch senden zum Erfolg geführt. Der SDUINO neighte bei meinen Commands in eine Sende-Loop zu gehen. Deshalb ist es schön, dass das Thema FSK wieder fahrt gewinnt.
ich habe mir den SIGNALduino_nanoCC1101_3322rc10t.hex geladen, die Frequenz auf meine letzten relevanten Werte (868.275 MHz bzw. lt. Messung 868.140 MHz) gesetzt, ich empfange aber nichts. Jetzt habe ich mein URH mit SDR-Stick aktualisiert und gemessen. Wenn ich mittels SDUINO sende sehe ich gar nichts im Spektrum des relevanten Frequenzbereichs. Die Baudrate ist lt. ccconf 115 kBaud (DataRate:115051.27Baud, Modulation:2-FSK). Ich sende die halbwegs brauchbaren OOK-Signale mit 5600 Baud. Wie kommt die Baudrate zustande? Über das entsprechende CC1101-Register?
Ciao, plin
@plin,
Vorsicht und nicht zu schnell verzweifeln ;)
Was FSK und SDRSharp angeht, so kann ich nur meine Erfahrung wiedergeben. Ich dachte auch der Sender ist still weil in SDRSharp ich nichts sah. ABER ich wurde des besseren belehrt, also nicht täuschen lassen.
Manuell eingestelltes Register zeigte mir auf einmal den Empfang mit dem Signalduino.
@Ralf, ich erstelle mal das neue Thema weil wir hier sonst weiter abzeigen.
Gesendet von iPhone mit Tapatalk Pro
Ab sofort alles ums Thema FSK hier
https://forum.fhem.de/index.php?topic=106582.msg1004408#msg1004408
Gesendet von iPhone mit Tapatalk Pro
Ich habe "FSK mit dem SIGNALDuino" unter sonstige Systeme angelegt
https://forum.fhem.de/index.php/topic,106594.0.html
Nachtrag:
Ich hab mal angefangen zu programmieren. Die Interruptroutine müsste eigentlich so ausreichend sein:
void handleSyncInterrupt() {
cli();
FiFo.enqueue(digitalRead(PIN_SEND));
sei();
}
void enableReceive() {
if (ccmode == 0) { // normal
attachInterrupt(digitalPinToInterrupt(PIN_RECEIVE), handleInterrupt, CHANGE);
}
else if (ccmode == 1) { // sync mode
attachInterrupt(digitalPinToInterrupt(PIN_RECEIVE), handleSyncInterrupt, CHANGE);
}
#ifdef CMP_CC1101
if (hasCC1101) cc1101::setReceiveMode();
#endif
}
Hallo Kollegen,
ihr habt mir den anderen Thread beim Tippen quasi unterm Hintern weggezogen, deshalb hier nochmal als Abschluss:
Nach mehrfachem Nachdenken bin ich zum Schluss gekommen, dass man das FSK Protkoll doch besser nicht mit dem Signalduino implementiert, meine Gedanken:
- Der Signalduino wurde entwickelt, damit man mehrere Protokolle empfangen kann ohne dazwischen Parameter umprogrammieren zu müssen, dadurch hatte er einige Vorteile gegenüber CUL und Ableger
- Nutzen wir das FSK Protokoll gibt es diese Vorteile m.E. nicht mehr, da man sich bzgl. Datenrate und damit Filterfrequenzen festlegen muss
- Mein Fazit ist, für das FSK Protkoll bleibe ich beim CUL
Ich habe für den NanoCUL eine Testimplementierung gemacht, siehe Anhang.
Parameter: 868,3MHz, bWidth 162,5 kHz, Drate: 4785,5 Baud, Daten werden via FiFo gelesen, ohne Sync Pattern, d.h. man bekommt alle Daten mit, wenn RSSI über einer bestimmten Schwelle ist.
Für meine Fernbedienung kommen dann alle Daten korrekt an (meine FB sendet die identsiche Botschaften zig mal), unten könnt Ihr sehen, dass die 1. 3. 5. Botschaft sogar Bitgenau synchronisiert sind (müsste man eigentlich per Firmware machen, da ohne Syn Pattern empfangen wird). Verschiebt man die 2. 4. ... Botschaften um ein Paar Bit hin und her sieht man, das es die selben Botschaften sind.
Bytes in Fifo: 14 Received Data: AAAAAAAAAAAAAAAAAAAAAAAAAAA5407FA5E2265C
Bytes in Fifo: 14 Received Data: C0F028F00000000000000000000002AAAAAAAAAA
Bytes in Fifo: 14 Received Data: AAAAAAAAAAAAAAAAAAAAAAA9501FE9788997303C
Bytes in Fifo: 14 Received Data: 0A3C0000000000000000000000AAAAAAAAAAAAAA
Bytes in Fifo: 14 Received Data: AAAAAAAAAAAAAAAAAAAA5407FA5E2265CC0F028F
Bytes in Fifo: 14 Received Data: 00000000000000000000002AAAAAAAAAAAAAAAAA
Bytes in Fifo: 14 Received Data: AAAAAAAAAAAAAAAA9501FE9788997303C0A3C000
Bytes in Fifo: 14 Received Data: 0000000000000000000AAAAAAAAAAAAAAAAAAAAA
Bytes in Fifo: 14 Received Data: AAAAAAAAAAAAA5407FA5E2265CC0F028F0000000
Bytes in Fifo: 14 Received Data: 0000000000000002AAAAAAAAAAAAAAAAAAAAAAAA
Bytes in Fifo: 14 Received Data: AAAAAAAAA9501FE9788997303C0A3C0000000000
Bytes in Fifo: 14 Received Data: 000000000000AAAAAAAAAAAAAAAAAAAAAAAAAAAA
Bytes in Fifo: 14 Received Data: AAAAAA5407FA5E2265CC0F028F00000000000000
Bytes in Fifo: 14 Received Data: 000000002AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Bytes in Fifo: 14 Received Data: AA9501FE9788997303C0A3C00000000000000000
Bytes in Fifo: 14 Received Data: 00000AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA5
Bytes in Fifo: 14 Received Data: 407FA5E2265CC0F028F000000000000000000000
Bytes in Fifo: 14 Received Data: 02AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA9501F
Bytes in Fifo: 14 Received Data: E9788997303C0A3C0000000000000000000000AA
Bytes in Fifo: 14 Received Data: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA5407FA5E
Bytes in Fifo: 14 Received Data: 2265CC0F028F00000000000000000000002AAAAA
Bytes in Fifo: 14 Received Data: AAAAAAAAAAAAAAAAAAAAAAAAAAAA9501FE978899
Bytes in Fifo: 14 Received Data: 7303C0A3C0000000000000000000000AAAAAAAAA
Bytes in Fifo: 14 Received Data: AAAAAAAAAAAAAAAAAAAAAAAAA5407FA5E2265CC0
Bytes in Fifo: 14 Received Data: F028F0000000000000000000000FFFFFFFFFFFFFbin jetzt erst mal eine Weile offline
Nachtrag: jetzt auf für den ProMicroCUL
!!!!! Diese Versionen können nur noch Testweise Empfangen, die Integration in FHEM funktioniert damit nicht !!!! Nachtrag2:Um diesen Mode in der Firmware zu aktivieren, muss man direkt im Terminal oder FHEM (raw mode) folgendes Kommado schicken:
krS3als Bestätigung muss dann folgende Antwot zu sehen sein:
krS-ReceiveStartNachtrag3:Die Firmwäre läuft noch mit GFSK
Hallo RaspII,
Zitat
Ich habe für den NanoCUL eine Testimplementierung gemacht, siehe Anhang.
Parameter: 868,3MHz, Drate: 4785,5 Baud, Daten werden via FiFo gelesen, ohne Sync Pattern, d.h. man bekommt alle Daten mit, wenn RSSI über einer bestimmten Schwelle ist.
kannst Du bitte auch noch die cc1101 register posten?
Gruß Ralf
Zitat von: RaspII am 22 Dezember 2019, 18:14:59
Nach mehrfachem Nachdenken bin ich zum Schluss gekommen, dass man das FSK Protkoll doch besser nicht mit dem Signalduino implementiert, meine Gedanken:
- Der Signalduino wurde entwickelt, damit man mehrere Protokolle empfangen kann ohne dazwischen Parameter umprogrammieren zu müssen, dadurch hatte er einige Vorteile gegenüber CUL und Ableger
- Nutzen wir das FSK Protokoll gibt es diese Vorteile m.E. nicht mehr, da man sich bzgl. Datenrate und damit Filterfrequenzen festlegen muss
- Mein Fazit ist, für das FSK Protkoll bleibe ich beim CUL
Ansichtssache. Ich habe einen SIGNALduino für 433 MHz-Devices die OOK funken und einen auf 868 MHz für den Use Case "Rolläden" der FSK sprechen soll. Für One-UseCase-User lohnt sich die FSK-Implementierung immer noch.
ZitatAnsichtssache. Ich habe einen SIGNALduino für 433 MHz-Devices die OOK funken und einen auf 868 MHz für den Use Case "Rolläden" der FSK sprechen soll. Für One-UseCase-User lohnt sich die FSK-Implementierung immer noch
Ja, das stimmt schon, nur wo ist da der Unterschied z.B. zu einem NanoCul?
Der schickt ja auch die Empfangenen Botschaften raus. Mag sein, ich bin da voreingenommen weil ich bisher viel auf dem CUL programmiert habe.
Hier meine Registerkonfiguration, Achtung die geänderten Werte sind doppelt vorhanden, einmal rauskommentiert.
/ CC1101 Register Initialisation (see CC1101 Page 70ff and 62ff)
// Data Adr Reg.Name RESET STUDIO COMMENT
// ====== ==== ======== ===== ====== =================================================================================================================================
0x01, // 00 IOCFG2 *29 *0B GDO2_CFG=1: GDO2 Asserts when the RX Fifo is filled or above the RX FIFO threshold or the end of package is reached. Deasserted if the Fifo is empty
0x2E, // 01 IOCFG1 2E 2E no change yet
0x46, // 02 IOCFG0 *3F *0C GDO0_CFG=2: Associated to the TX FIFO: Asserts when the TX FIFO is filled at or above the TX FIFO threshold.
// De-asserts when the TXFIFO is below the same threshold.
0x04, // 03 FIFOTHR 04 *47 RX Fifo Threshold = 20 Bytes
0xAA, // 04 SYNC1 D3 D3 Sync High Byte = AA (assumption: High Byte is first send sync byte)
0x54, // 05 SYNC0 91 91 Sync Low Byte = 54 (AA 54 should work with CC1101 as Sync word)
0x0F, // 06 PKTLEN *FF 3D Package length for Kopp 15 Bytes (incl. Cks+Zeros, because handled as data because no standard CC1101 checksum)
0xE0, // 07 PKTCTRL1 04 04 Preamble quality is maximum(7), No Auto RX Fifo Flush, No Status Bytes will be send, No Address check
// 0x00, // 08 PKTCTRL0 *45 32 Data whitening off, Rx and Tx Fifo, CRC disabled, Fixed package length
0x02, // 08 PKTCTRL0 *45 32 ## NoSync Data whitening off, Rx and Tx Fifo, CRC disabled, ## NoSync Infinite package length
0x00, // 09 ADDR 00 00 Device Adress (Address filter not used)
0x00, // 0A CHANNR 00 00 Channel Number (added to Base Frequency) is not used
0x06, // 0B FSCTRL1 *0F 06 152,34375 kHz IF Frquency (##Claus: to be adjusted for Kopp, later if RX is used)
0x00, // 0C FSCTRL0 00 00 Frequency Offset = 0
0x21, // 0D FREQ2 *1E 21 FREQ[23..0] = f(carrier)/f(XOSC)*2^16 -> 868,3Mhz / 26Mhz * 2^16 = 2188650 dez = 21656A hex (f(XOSC)=26 Mhz)
0x65, // 0E FREQ1 *C4 65 Alternativ für Kanumouse: 868,260 / 26Mhz * 2^16 = 2188550 dez = 216506 hex
0x6A, // 0F FREQ0 *EC e8 s.o.
0x97, // 10 MDMCFG4 *8C 55 bWidth 162,5 kHz (Kopp 50 Khz!, but does not work))
0x83, // 11 MDMCFG3 *22 *43 Drate: 4785,5 Baud (Kopp: 4789 Baud, measured value !! may be increase by 1 is needed (83) because value should be 4800) doesn't work better with 81/83 )
// 0x16, // 12 MDMCFG2 *02 *B0 DC Blocking filter enabled, GFSK modulation (Kopp uses FSK, do not know whether 2-FSK, GFSK odr 4-FSK),
0x14, // 12 MDMCFG2 *02 *B0 ## NoSync DC Blocking filter enabled, GFSK modulation (Kopp uses FSK, do not know whether 2-FSK, GFSK odr 4-FSK),
// manchester en-decoding disabled, ## NoSync Only carrier-sense above threshold
0x63, // 13 MDMCFG1 *22 23 Error Correction disabled, min 16 preamble bytes, Channel spacing = 350 khz
0xb9, // 14 MDMCFG0 *F8 b9 Channel spacing 350kHz (Copied from somfy, do not know if ok )
0x47, // 15 DEVIATN *47 00 frequency deviation = 47,607 khz (default, do not know if right, for RFM12b I used 45khz)
0x07, // 16 MCSM2 07 07
0x0C, // 17 MCSM1 30 30 see above
0x29, // 18 MCSM0 *04 18 Calibration after RX/TX -> IDLE, PO_Timeout=2 ##Claus 0x01: Oszillator always on for testing
0x36, // 19 FOCCFG *36 14
0x6C, // 1A BSCFG 6C 6C
0x07, // 1B AGCCTRL2 *03 *03 42 dB instead of 33dB
0x40, // 1C AGCCTRL1 *40 *40
0x91, // 1D AGCCTRL0 *91 *92
0x87, // 1E WOREVT1 87 87
0x6B, // 1F WOREVT0 6B 6B
0xF8, // 20 WORCTRL F8 F8
0x56, // 21 FREND1 56 56
0x11, // 22 FREND0 *16 17 0x11 for no PA ramping (before 16, this was the reason why transmission didn't run)
0xE9, // 23 FSCAL3 *A9 E9 as calculated by Smart RF Studio
0x2A, // 24 FSCAL2 *0A 2A as calculated by Smart RF Studio
0x00, // 25 FSCAL1 20 00 as calculated by Smart RF Studio
0x1F, // 26 FSCAL0 0D 1F as calculated by Smart RF Studio
0x41, // 27 RCCTRL1 41 41
0x00, // 28 RCCTRL0 00 00Der NanoCul kann bisher nur Empfangen,
Folgenden Befehl muss man hierfür in die Konsole eingeben:
krS3
Danke, wenn dies auch mit dem FIFO ohne Sync geht, dann ist der sync-Mode nicht mehr notwendig.
Jups,
allerdings muss man sich noch mit dem Parameter "carrier-sense above threshold" auseinandersetzten.
Man kann hier absolute Schwellen vorgeben oder eine Erhöhung der RSSI.
Für meine Zwecke gibt es hier keinen Bedarf (ich brauche keine Reichweite), aber für eine professionelle Implementierung sollt man sich anschauen wie man damit umgeht.
Irgendwas passt nicht. Ich habe den CUL als Sender benutzt, aber am sduino kommen keine MU-Nachrichten an
defmod myCUL CUL /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A600G900-if00-port0@38400 1234
attr myCUL rfmode KOPP_FC
attr myCUL room CUL_TCM97001
defmod culfsk KOPP_FC 21 FA5E 02 11
attr culfsk IODev myCUL
attr culfsk model Switch_8080_01
attr culfsk room CUL_TCM97001
und den sduino so wie hier im async Mode konfiguriert
https://github.com/RFD-FHEM/RFFHEM/issues/711#issuecomment-564270161
Hier sind die cc1101 register
ccreg 00: 0D 2E 2D 47 D3 91 3D 04 32 00 00 06 00 21 65 6A
ccreg 10: 97 83 16 63 B9 47 07 00 18 14 6C 07 00 91 87 6B
ccreg 20: F8 B6 11 EF 0C 3D 1F 41 00 59 7F 3F 88 31 0B
welchen CUL hast Du geflasht?
Du brauchst den hier:
https://forum.fhem.de/index.php/topic,82379.msg1004292.html#msg1004292 (https://forum.fhem.de/index.php/topic,82379.msg1004292.html#msg1004292)
Hier meine aktuellen Settings (Deine müssten aber auch gehen):
ccreg 00: 0D 2E 2D 77 AA 54 02 04 32 00 00 06 00 21 65 6A ccreg 10: 97 83 14 63 B9 47 07 00 18 14 6C F8 00 CF 87 6B ccreg 20: F8 B6 11 EF 2A 16 1F 41 00 59 7F 3F 88 31 0B
Nachtrag:
Hast Du beim Signalduino noch den Empfang enabled?
XE
Musste ich bei FSK immer machen
ja den habe ich geflasht
https://sourceforge.net/p/culfw/code/HEAD/tree/trunk/culfw/Devices/nanoCUL/
habe testweise den mode auf slowrf gewechselt, dann kann ich Intertechno v1 empfangen und schalten
Habe oben noch eine Info nachgetragen
hat nichts gebracht
ccreg 00: 0D 2E 2D 77 AA 54 02 04 32 00 00 06 00 21 65 6A
ccreg 10: 97 83 14 63 B9 47 07 00 18 14 6C F8 00 CF 87 6B
ccreg 20: F8 B6 11 EF 0C 3C 1F 41 00 59 7F 3F 88 31 0B
Hast Du das Commando XE eingegeben?
Wie bedienst Du den nanoCUL, via FHEM?
ja XE habe ich eingeben
mit fhem
2019.12.23 00:29:25.188 3 : KOPP_FC_Set: Device Name: culfsk, command: on, Model: Switch, Transm.-/KeyCode: FA5E 21
2019-12-23 00:29:25.189 KOPP_FC culfsk on
2019.12.23 00:29:25.190 5 : myCUL sending ks21FA5E0200000N
2019.12.23 00:29:25.190 5 : SW: ks21FA5E0200000N
2019.12.23 00:29:26.396 3 : KOPP_FC_Set: Device Name: culfsk, command: off, Model: Switch, Transm.-/KeyCode: FA5E 21
2019-12-23 00:29:26.397 KOPP_FC culfsk off
2019.12.23 00:29:26.398 5 : myCUL sending ks21FA5E0200000N
2019.12.23 00:29:26.398 5 : SW: ks21FA5E0200000N
Die Icons auf der FHEM Oberlfäche reagieren auf Knopfdruck (Lampen gehen an/aus)?
ja
Augenblick, ich programmiere mal um
Kannst Du mir bitte den Ausschnitt aus Deiner fhem.cfg senden?
Irgendwie sind Deine Log Einträge komisch
define myCUL CUL /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A600G900-if00-port0@38400 1234
setuuid myCUL 5c574612-f33f-9dc4-7c82-da22bb565b725c55
attr myCUL rfmode KOPP_FC
attr myCUL room CUL_TCM97001
attr myCUL verbose 4
define culfsk KOPP_FC 21 FA5E 02 11
setuuid culfsk 5dfeb9fa-f33f-9dc4-ff5c-198e20d9c9bde0e3
attr culfsk IODev myCUL
attr culfsk model Switch_8080_01
attr culfsk room CUL_TCM97001
sieht gut aus.
Ich habe bei mir gerade ein ähnliches Problem,
wenn ich meinen Signalduino auf nanoCUL zurückflashe geht auch nichts mehr (keine Kommunikation..).
Habe jetzt mal meinen eigenen Build genommen, jetzt klappts.
-> Versuche es mal mit der angehängten Datei
funktioniert damit auch nicht.
Ich habe eine minicul und eine nanocul Hardware
ZitatIch habe für den NanoCUL eine Testimplementierung gemacht,
Hast Du mir auch ein Hexfile für den minicul.
Aber heute Nacht nicht mehr
minicul hab ich nicht.
Mit obigem Hexfile muss es gehen, damit arbeite ich bei mir schon über Jahre.
Bei mir kommt dann folgende Info (natürlich bei mir mit Taste1Rad5 und das Licht schaltet auch, d.h. FSK wird gesendet)
2019.12.23 02:04:36 3: KOPP_FC_Set: Device Name: Taste1Rad5, command: on, Model: Switch, Transm.-/KeyCode: FA5E 05
Das ist passend zu Deinem Logfile, ich denke das Senden funktinoiert bei Dir bereits.
Kannst Du z.B. mit SDR Sharp bei 868,3 Mhz lauschen? Es gab mal blaue Module die bzgl. Frequenz völlig daneben lagen,
Es könnte auch noch Probleme mit dem Signalduino geben, das hat bei mir auch immer erst auf den 2ten Versuch geklappt, weil ich beim Initialisieren der Register immer irgend etwas vergessent hatte.
z.B. musste XE immer das letzte Kommando nach dem Register schreiben sein.
dann geh jetzt auch ins Bett.
Nachtrag:
Bei deinem SignalDuino sind noch die Register 24 und 25 (FSCAL) unterschiedlich zu meinem Setting
Dem NanoCUL darf in FHEM nur das Kopp Protokoll zugewiesen sein
Ich wollte ja sowieso mal einen anderen Weg als den SDUINO testen: Ich habe meinen SDUINO mit der nanocul fw geflasht.
Welchen RFmode muss ich wählen, um ein unbekanntes Funktprotokoll auf 868.275 MHz mit 25 kHz Hub zu empfangen?
schwere Frage,
wie meinst Du das mit dem unbekannten Protokoll? Willst irgendein Protokoll z.b. von den Nachbarn empfangen (dann wäre vermutlich
HomeMatic am besten geeignet, da es sehr verbreitet ist, allerdings passen Deine Parameter nicht unbedingt) oder ein spezifisches Protokoll analysieren?
Falls letzteres, dann lese diesen Beitrag und flashe die dort angehängte nanoCUL Datei
https://forum.fhem.de/index.php/topic,82379.msg1004482.html#msg1004482 (https://forum.fhem.de/index.php/topic,82379.msg1004482.html#msg1004482)
Allerdings sind die Parameter dort wie im Text beschrieben. Die größere Bandbreite sollte nicht stören, allerdings bin ich mir bei der Frequenz nicht sicher.
Falls das alles nicht klappt, müsste ich Dir eine Spezialversion erstellen, dann sollte ich aber auch die Bitrate kennen.
Zitat von: RaspII am 23 Dezember 2019, 20:42:38
schwere Frage,
wie meinst Du das mit dem unbekannten Protokoll?
Hi RaspII,
mit "unbekannte Funkprotokolle" meine ich eine RIO Funkfernbedienung die meine Rolladenmotoren steuert. Die Motoren habe ich bei einem Bonner Herstelller gekauft. Die Fernbedienung hat er wohl nicht selbst entwickelt sondern dazu gekauft. Ein Anfrage bzgl. technischer Details verlief jedenfalls negativ. Deren aktuelle Serie hat eine andere Fernbedienung. So habe ich mich letztendlich auf den Weg der Messungen, Analysen und des Reverse-Engineerings gemacht (siehe https://forum.fhem.de/index.php/topic,85006.0.html (https://forum.fhem.de/index.php/topic,85006.0.html) sowie https://wiki.fhem.de/wiki/Unbekannte_Funkprotokolle (https://wiki.fhem.de/wiki/Unbekannte_Funkprotokolle)). Der Zufall hat mir dabei geholfen, denn hätte ich mit dem SIGNALduino und OOK nichts empfangen, wäre ich gar nicht so weit gekommen. Screenshots des Spektrums befinden sich im Post https://forum.fhem.de/index.php/topic,58396.msg1003224.html#msg1003224 (https://forum.fhem.de/index.php/topic,58396.msg1003224.html#msg1003224).
Die bisher ermittelten Eckdaten sind
Trägerfrequenz 868.275 MHz
Frequenzhub 25 kHz
BaudRate 2482 Bd
Sender-Chip: TDK5110
Empfänger: TDA5210
Das Signal besteht aus 8 Bytes: 4 Bytes Vorspann (Random-Muster für pro Tastendruck), 4 Bytes Nutzlast (Rollade, Funktion, Fernbedienung). Die OOK raw-Commands sehen z.B. so aus:
SR;;R=10;;P0=-32001;;P1=15860;;P2=-398;;P3=412;;P4=3998;;P5=822;;P6=-800;;D=1232323232323232323232324256363632525636363632525252525256363256363636363256325632525256363636363636363636325636363632525632563632563636363636363632563252;Ich habe einen SDR-Stick, kann also das Signale von Fernbedienung und SIGNALduino in puncto Trägerfrequenz und Hub ver- bzw. abgleichen. Meine nächsten Schritte wären
- den SIGNALduino dazu zu bringen, dass er 2FSK bzw. GFSK sendet
- Frequenz und Hub mittels des SDR-Sicks und URH ermitteln (Vergleich Original FB gegen SIGNALduino) => Frquenz, Hub und 2FSK vs. GFSK
- Dann schauen, dass ich mit den Einstellungen Signale der FB empfange (die sollten vergleichbare Strukturen haben wie die mittels OOK empfangenen).
- Wann dann das Senden der Signale zu einer Reaktion meiner Rolladenmotoren führt gibt's zwei Varianten: durchtesten der empfangenen Signale bis ich stabile Patterns gefunden habe oder Generierung eines eigenen, synthetischen Signals auf Basis der bisherigen Erkennntnisse.
Dabei hat mir der SIGNALduino mit seinem offenen Ansatz sehr geholfen. Ich konnte alles über das FHEM-Modul ändern ohne ans Coding gehen zu müssen.
VG plin
bitte die allgemeinen Sachen wie Protokoll und ccRegister hier weiter diskutieren
https://forum.fhem.de/index.php/topic,106594.0.html
Wenn mir es gelingt, daß ich mit dem sduino ein xFSK signal empfange, dann kann ich das Empfangen und Senden mit dem FIFO des cc1101 einbauen, dann wird einiges einfacher.
Es wird für das Signalduino Modul demnächst ein neuer set Befehl geben, damit kann dann eine folge von ccRegistern gesendet werden.
z.B. set sduino cc1101_reg 1183 1214 1363 14B9 1500 1BF8 1DCF
Mit dem Senden mit dem nanocul und der culw firmware und dem kopp Protokoll komme ich nicht weiter.
Mein Problem ist, daß ich nicht weiss ob das Problem beim Sender (nanocul) oder beim Empfänger (minicul) ist.
Wenn ich eine ITv1 Nachricht vom nanocul (mode slowrf) zum minicul sende, dann funktioniert es. Ich habe eine freq von 868.3 und eine Bandbreite von 162 verwendet.
Ich überlege mir gerade ob ich vielleicht mit der a-culw weiterkomme, da gibt es auch eine firmware für den minicul.
Ich würde gerne auch mal versuchen mit dem minicul ein xFSK zu senden.
Evtl komme ich mit dem mode 1 und 2 (IT+) weiter, nur wie kann ich da was senden?
Falls jemand eine xFSK Fernbedienung hat die er nicht mehr benötigt, würde ich sie abkaufen
Gruß Ralf
Zitat von: Ralf9 am 24 Dezember 2019, 10:16:30
Wenn mir es gelingt, daß ich mit dem sduino ein xFSK signal empfange, dann kann ich das Empfangen und Senden mit dem FIFO des cc1101 einbauen, dann wird einiges einfacher.
Hi Ralf9,
ich habe gerade noch mal den minimalistischen Ansatz verfolgt: Zurück zu SIGNALDuino_nanocc1101_331rc7.hex, Register 12 auf GFSK bzw. 2-FSK geändert und bei
ccconf: freq:868.275MHz bWidth:650KHz rAmpl:42dB sens:4dB (DataRate:5603.79Baud, Modulation:GFSK)empfange ich jetzt MU-Nachrichten. Bei meinen weiteren Tests ist mir aber gerade die Baudrate abhanden gekommen (die steht jetzt auf 350 und ich empfange nichts).
VG plin
Also weiter gehts im obigen Thread
Ich werde heute abend mal anfangen, die Routinen zum Empfangen und Senden über den FIFO des cc1101 einzubauen, auch wenn ich es evtl noch nicht testen kann.
Es wird eine neue Konfigurationsvariable ccmode geben.
ccmode = 0 - normal
ccmode = 1 - FIFO mit sync
ccmode = 2 - FIFO ohne sync
Wenn ich es richtig verstanden habe, dann wird beim Empfang mit FIFO und sync (in CC1100_FIFOTHR steht wieviel Byte man empfangen will):
- ccStrobe( CC1100_SIDLE ); # nach IDLE
- die Anzahl der Bytes die in CC1100_RXBYTES stehen, auslesen
- ccStrobe( CC1100_SFRX ); # den FIFO löschen
ccStrobe( CC1100_SIDLE ); # IDLE
ccStrobe( CC1100_SNOP );
ccStrobe( CC1100_SRX ); # RX Mode
Beim ccmode = 2 - FIFO ohne sync wird dann:
Dies ist mir noch nicht so ganz klar.
Es werden CC1100_RXBYTES minus 1 Bytes aus dem FIFO ausgelesen (der FIFO darf nicht leer werden)
@RaspII
Kannst Du bitte mal Deine Routine zum FIFO auslesen ohne sync posten?
Die ausgelesenen Bytes werden in einem neuen Nachrichtentyp MN ausgegeben. z.B. MN;012ABC;
N für Native, oder ist ein anderer Buchstabe besser?
Mit dem Senden habe ich mich noch nicht befasst.
Es wird zum Senden ein neues Kommando benötigt,
z.B.
SN;R=1;012ABX;
Gruß Ralf
ich habe einen neuen Branch erstellt und mal damit angefangen, die Routinen zum Empfangen und Senden über den FIFO des cc1101 einzubauen:
https://github.com/Ralf9/SIGNALDuino/commits/dev-r333_cc1101
https://github.com/Ralf9/SIGNALDuino/commit/a4417812de764d58e55f523f689bbea34788e393
https://github.com/Ralf9/SIGNALDuino/commit/cec03d893fa067de176d80f539ab21694f20c237
Bis jetzt ist es mir noch nicht gelungen das GFSK was empfangen wird.
Hier sind die aktuellen cc1101 Register vom sduino auf der minicul Hardware
ccreg 00: 01 2E 46 04 AA 54 0F 0E 02 00 00 06 00 21 65 6A
ccreg 10: 97 83 14 63 B9 47 07 0C 29 36 6C 07 40 91 87 6B
ccreg 20: F8 56 11 E9 2A 00 1F 41 00 59 7F 3F 88 31 0B
Auf dem nanocul habe ich die culw im mode KOPP_FC.
Ich habe auf dem minicul sduino den FIFO emfang aktiviert,
Wenn ich mit dem nanocul sende geht beim minicul sduino nicht mal der receivePIN auf high.
Ich habe auch mal mit dem minicul sduino mit der neu eingebauten FIFO Senderoutine getestet und folgendes gesendet:
SN;AAAAAAAAAAAAAAAA5407FA5E1005CC0F02DD000000000000;
Der nanocul hat aber nichts empfangen.
Ich habe auch mal die Testfirmware mit deaktiviertem sync geflasht, der hat auch gar nichts empfangen.
Gruß Ralf
ZitatKannst Du bitte mal Deine Routine zum FIFO auslesen ohne sync posten?
siehe Anhang ab Zeile 703.
Beim Durchsehen ist mir noch aufgefallen, das ich den Empfangsmode nicht auf 2-FSK umgestellt habe.
(ich bin auf zu vielen Baustellen unterwegs, ich brauche diese Routine auch für Kopp-V1), ich mache mich da gleich noch dran
Nachtrag:ich denke es macht Sinn, wenn Du versuchst Schrittweise vorzugehen. Dabei wäre der erste Schritt zu testen, ob dein Nano CUL korrekt mit der KOPP Firmware funktioniert und z.B. deine beiden CULs auf der richtigen Frequenz senden.
Du nutzt hoffentlich
nicht das angehängte Funkmodul? (die hatten massive Frequenzabweichungen und deshalb nicht funktioniert)
Ich habe mal beim MiniCUL nachgeschaut. Die Verdrahtung scheint identisch mit dem NanoCUL zu sein, auch der Prozessor ist der selbe (ATMEGA 328P).
Ich gehe davon aus, dass die Standard nanoCUL Firmware (siehe FHEM) darauf läuft.
Die Vorgehensweise wäre wie folgt:
- MiniCUL mit Standard nanoCUL FW flashen https://sourceforge.net/p/culfw/code/HEAD/tree/trunk/culfw/Devices/nanoCUL/ (https://sourceforge.net/p/culfw/code/HEAD/tree/trunk/culfw/Devices/nanoCUL/)
- nanoCUL mit meiner modifizierten Firmware flashen (identisch Kopp nur ohne Sync) https://forum.fhem.de/index.php?action=dlattach;topic=82379.0;attach=129275 (https://forum.fhem.de/index.php?action=dlattach;topic=82379.0;attach=129275)
- nanoCUL mit
krs3 aktivieren
- am MiniCUL folgendes Kommando absetzten
kt30F96E0110000JDanach müsstest Du beim NanoCUL die Rohboschaften sehen, zumindest wenn Du direkt mit einem Terminal arbeitest
ZitatDu nutzt hoffentlich nicht das angehängte Funkmodul? (die hatten massive Frequenzabweichungen und deshalb nicht funktioniert)
Ich benutze ein blaues Modul (siehe Anlage) am nanocul, es kann sein, daß es eine geringe Frequenzabweichung hat.
Am minicul habe ich ein grünes D-SUN Modul.
Wenn ich mit OOK, 868.3 MHz und bwith 162 kHz von einem zum anderen sende funktioniert es.
ZitatIch habe mal beim MiniCUL nachgeschaut. Die Verdrahtung scheint identisch mit dem NanoCUL zu sein, auch der Prozessor ist der selbe (ATMEGA 328P).
Ich gehe davon aus, dass die Standard nanoCUL Firmware (siehe FHEM) darauf läuft.
Es ist zwar die nanocul Verkabelung, der ATMEGA 328P ist aber eine 3.3V 8MHz Version
Ich habe im sduino die Routinen zum auslesen des FIFO eingebaut.
Ich verwende die folgende konfig:
ccreg 00: 01 2E 2E 04 E9 CA FF 0C 45 00 00 06 00 21 65 6A ccreg 10: C8 93 06 22 F8 34 03 18 18 16 6C 43 40 91 87 6B ccreg 20: F8 56 11 EB 0C 3C 11 41 00 59 7F 3E 88 31 0B Wenn ich an der Homematic Steckdose die Taste drücke kommt am minicul folgendes an:
16 2B EF 66 AD 36 B1 CD 35 D4 1C 01 BA 5B 3E 39 CD 93 4A 2D
16 2B ED 73 92 31 F8 2E F0 5B D9 FE 31 61 52 C5 21 F1 91 6F
16 2B EF 61 A2 21 AE CA 3A A3 A3 76 B5 5C E9 39 7C 8A 99 AB
16 2B EF 60 A3 20 AF CB 3B A2 A2 77 B4 5D 20 39 FB 36 D5 AF
16 2B EF 63 A0 23 AC C8 38 A1 A1 74 B7 5E EB 39 13 EA E9 49
16 2B EF 62 A1 22 AD C9 39 A0 A0 75 B6 5F 22 39 94 56 E9 8EAm nanocul mit dem blauen Modul empfange ich nichts.
Gruß Ralf
Hast Du die selbe Firmware in MiniCUL und nanocul?
Wenn ja denke ich hast Du ebenfalls das Problem mit der Frequenzabweichung, FSK/GFSK scheint da empfindlich zu sein
Ja, sieht nach einer Freqenzabweichung um ca 100kHz aus.
Mit einer Frequenz von 868.4 empfange ich mit dem blauen Modul was, wenn ich am Homematic Heizkörperthermostat drehe, die Steckdose empfange ich seltsamerweise nicht.
Gruß Ralf
Heisst das dann, das bei den blauen Modulen evtl ein minderwertiger ungenauer Quarz verwendet wird?
Wie genau ist die Frequenz von 868 Modulen normalerweise?
Ist die 868.4 die ich am meinem blauen Modul eingestellt habe evtl noch zu ungenau? Wie genau muss die Frequenz passen?
Gruss Ralf
Hier hatten wir das schon einmal ausführlich geklärt, ich hatte den link eben wiedergefunden
https://forum.fhem.de/index.php/topic,24651.msg411458.html#msg411458 (https://forum.fhem.de/index.php/topic,24651.msg411458.html#msg411458)
macht es noch Sinn es mit dem blauen Modul weiterversuchen? Wie genau müsste die Frequenz sein?
Ich hab mal gegoogelt, es gibt 26MHz Quarze mit u.a. 10, 30 und 50ppm, wenn ich es richtig gerechnet habe sind die 50ppm bei 868MHz ein Abweichung von ca 22kHz.
Die ppm Angaben gibts bei der Frequenzabweichung und -Stabilität.
Es ist warscheinlich einfacher, wenn ich mir ein gutes 868MHz Modul besorge.
Hast Du oder jemand anders ein genaues 868MHz Modul übrig, das er mir verkaufen kann?
Nachtrag: lässt sich die Genauigkeit an der Beschriftung vom Quarz erkennen, oder ist die Genauigkeit auch vom verwendeten cc1101 abhängig?
Ich hatte mit diesen Modulen gute Erfahrungen gemacht (aderer Verkäufer, aber optisch völlig identisch):
https://www.ebay.de/itm/CC1101-Wireless-Module-868MHZ-Long-Distance-Transmission-Antenna-M115/401737754133?hash=item5d896fa615:m:my-XDn2k-JX6rwjg7FMhwWA
(https://www.ebay.de/itm/CC1101-Wireless-Module-868MHZ-Long-Distance-Transmission-Antenna-M115/401737754133?hash=item5d896fa615:m:my-XDn2k-JX6rwjg7FMhwWA)
Wenn Du noch einiges bzgl. Funkprotokollen unternehmen willst solltest Du Dir auch einen SDR Stick (am besten mit 1ppm, dann muss mann die Frequenzen nicht mehr abgleichen) zulegen, dann kannst Du z.B. mit SDR# oder HDSDR die Frequenzabweichungen etc. anschauen.
https://www.ebay.de/itm/USB-Adapter-RTL-SDR-RTL2832U-R820T2-1Ppm-TCXO-TV-Tuner-Stick-Receiver/312003009486?hash=item48a4d41bce:g:Hn4AAOSwTm9aCzIo (https://www.ebay.de/itm/USB-Adapter-RTL-SDR-RTL2832U-R820T2-1Ppm-TCXO-TV-Tuner-Stick-Receiver/312003009486?hash=item48a4d41bce:g:Hn4AAOSwTm9aCzIo)
Dann sollte doch dieses auch passen? Sieht genauso aus
https://www.ebay.de/itm/CC1101-868-MHz-Wireless-Funk-Transceiver-Modul-Antenne-SPI-FHEM-CUL-Arduino-Pi/163967911155?hash=item262d3fc4f3:g:P0cAAOSwNhNd4lVu
ich denke schon,
etwas teurer aber schneller da ;D
Prinzipiell kann man sich bei den Preisen auch auf Vorrat kaufen.
Bei den "Briefmaken" habe ich noch nie von Problemen gehört. ich habe 3-4 davon im Dauereinsatz, funktioniert alles einwandfrei
Die grüne "Briefmarke" habe ich gestern erhalten und am Nanocul gegen das blaue Modul getauscht, die Homematic Nachrichten kann ich damit viel besser empfangen.
Daß die Antenne (siehe Anlage) beim Versand etwas gedrückt wurde scheint egal zu sein.
Hast Du die Möglichkeit zu testen ob das senden von KOPP_RC von einem 868MHz Modul zu einem 433MHz Modul oder umgekehrt überhaupt funktionieren kann?
beim 433MHz Modul ist nur die Antennenanpassung unterschiedlich, d.h. auf kurze Distanzen sollte es tun.
Ich würde auf dem minicul (nanocul Verkabelung mit ATmega 328P 3.3V 8MHz) zum Testen auch gerne die culw im mode KOPP_RC verwenden.
Kannst Du mir dafür eine firmware machen?
ZitatHast Du die Möglichkeit zu testen ob das senden von KOPP_RC von einem 868MHz Modul zu einem 433MHz Modul oder umgekehrt überhaupt funktionieren kann?
Ja, kann ich machen, allerdings muss ich dann erst noch löten
ZitatIch würde auf dem minicul (nanocul Verkabelung mit ATmega 328P 3.3V 8MHz) zum Testen auch gerne die culw im mode KOPP_RC verwenden.
Kannst Du mir dafür eine firmware machen?
- Welche HF Parameter benötigst Du?
Meine Spezialfirmware könnte im ersten Schritt nur Empfangen, oder was genau hast Du vor?
8 MHz war beim nanoCUL kein Standard, glaube ich -> muss ich mir mal anschauen
Hi:
Wird ein Arduino mit einer Taktfrequenz von nur 8MHz, wie ein Pro Mini 3,3V, verwendet, so muss die Zeile
#define HAS_16MHZ_CLOCK
in der Datei board.h auskommentiert werden.
Von:
https://wiki.fhem.de/wiki/Selbstbau_CUL
Gruß Arnd
Signalduino (Nano, ESP, ...), CUL (Busware, Nano, Maple, ...), Homematic (HM-MOD-UART-RPI, ESP, Maple, ...), LaCrosseGateway (LGW, ESP, ...), 1-wire, ESPEasy, Bravia, Yamaha, ...
kann ich zum Senden und Empfangen von Kopp auch diese nehmen, dort gibt es auch ein "#define HAS_KOPP_FC"
wenn ja wie komme ich zum Hex File?
https://github.com/heliflieger/a-culfw/tree/master/culfw/Devices/miniCUL
Ich möchte nur an dem einen sduino was senden und am anderen dies empfangen
Wenn Kopp definier ist sollte es gehen
Dies muss ich dann selber kompilieren, da es keine fertigen Hex files gibt?
Ich kann dir das machen, bin aber erst in ca 1h Zuhause
Hi Ralf,
Ist zwar OT, aber das ist die Standard Toolchain der a-CulFW, oder:
https://forum.fhem.de/index.php/topic,82024.msg740991.html#msg740991
Gruß Arnd
Signalduino (Nano, ESP, ...), CUL (Busware, Nano, Maple, ...), Homematic (HM-MOD-UART-RPI, ESP, Maple, ...), LaCrosseGateway (LGW, ESP, ...), 1-wire, ESPEasy, Bravia, Yamaha, ...
danke, habe die a-culfw geflasht
V 1.26.08 a-culfw Build: 323 (2019-08-03_09-32-54) miniCUL (F-Band: 868MHz)
Kann ich auch im seriellen Monitor, den mode auf KOPP_FC wechseln und dann das hier "ks21FA5E0200000N" senden?
Hab es rausgefunden, wies im Seriellen Monitor funktioniert.
Habe im Seriellen Monitor des minicul "krS-ReceiveStart" eingegeben.
Wenn ich nun im fhem mit dem nano folgendes sende (dabei ist mir aufgefallen, daß bei on und off das selbe gesendet wird)
2019.12.29 21:55:49.992 3 : KOPP_FC_Set: Device Name: culfsk, command: on, Model: Switch, Transm.-/KeyCode: FA5E 21
2019-12-29 21:55:49.993 KOPP_FC culfsk on
2019.12.29 21:55:49.994 5 : myCUL sending ks21FA5E0200000N
2019.12.29 21:55:49.994 5 : SW: ks21FA5E0200000N
2019.12.29 21:56:12.927 3 : KOPP_FC_Set: Device Name: culfsk, command: off, Model: Switch, Transm.-/KeyCode: FA5E 21
2019-12-29 21:56:12.928 KOPP_FC culfsk off
2019.12.29 21:56:12.929 5 : myCUL sending ks21FA5E0200000N
2019.12.29 21:56:12.929 5 : SW: ks21FA5E0200000N
Kommt im Seriellen Monitor des minicul folgendes an:
kr07FA5E2D21CC0F02C4
kr07FA5E2E21CC0F02C7
Wenn ich im Seriellen Monitor des minicul dies "ks21FA5E0200000N" sende:
erhalte ich in fhem vom nano:
2019.12.29 22:00:41.973 5 : CUL/RAW: /kr07FA5E0221CC0F02EB
2019.12.29 22:00:41.973 4 : CUL_Parse: myCUL kr07FA5E0221CC0F02EB
2019.12.29 22:00:41.973 5 : myCUL: dispatch kr07FA5E0221CC0F02EB
2019.12.29 22:00:41.981 2 : KOPP_FC_Parse: name: myCUL code: FA5E 21 Specialkey:short
2019-12-29 22:00:41.982 KOPP_FC culfsk on
Nun kann ich schauen was beim sduino nicht passt.
Das sieht ja alles super aus.
Wenn als Empfangsstring:
kr07FA5E2D21CC0F02C4
kommt sind Checksumme etc. geprüft, d.h. das ist ein gültiger Code.
Bei On und Off kommt der selbe Code, da der Empfänger bei "Eintastenbedienung" nur toggelt.
Legst Du in FHEM ein Device an, das auf 2 Tasten funktioniert (siehe FHEM WIKI unter Kopp)
https://wiki.fhem.de/wiki/Kopp_Allgemein (https://wiki.fhem.de/wiki/Kopp_Allgemein)
z.B. Schalter/Switch (8080.01), über zwei Taster gesteuert (on, off)
Dann noch viel Spaß mit dem SDUINO
Nachtrag:
wie gesagt, die Parameter der Kopp Firmware kannst Du hier finden:
https://sourceforge.net/p/culfw/code/HEAD/tree/trunk/culfw/clib/kopp-fc.c (https://sourceforge.net/p/culfw/code/HEAD/tree/trunk/culfw/clib/kopp-fc.c)
Hab die Fehler im sduino gefunden, jetzt funktioniert es mit sync.
Ich gebe zum Testen die Anzahl Bytes des FIFO vor und nach dem Ausgeben aus.
Ist es normal, daß von den gesendetet ca 13 Wiederholungen nur so wenig ankommen?
Wann liest man am Besten die RSSI aus, vor und nach dem FIFO auslesen oder ist es egal?
ks21FA5E0200000N on
l=15 chipst=1 MARCST=13 , 07 FA 5E 44 21 CC 0F 02 AD 00 00 00 00 00 00 l=0 R=208
l=15 chipst=1 MARCST=13 , 07 FA 5E 44 21 CC 0F 02 AD 00 00 00 00 00 00 l=0 R=211
l=15 chipst=1 MARCST=13 , 07 FA 5E 44 21 CC 0F 02 AD 00 00 00 00 00 00 l=0 R=215
l=15 chipst=1 MARCST=13 , 07 FA 5E 44 21 CC 0F 02 AD 00 00 00 00 00 00 l=0 R=210
l=15 chipst=1 MARCST=13 , 07 FA 5E 44 21 CC 0F 02 AD 00 00 00 00 00 00 l=0 R=214
l=15 chipst=1 MARCST=13 , 07 FA 5E 44 21 CC 0F 02 AD 00 00 00 00 00 00 l=0 R=206
l=15 chipst=1 MARCST=13 , 07 FA 5E 44 21 CC 0F 02 AD 00 00 00 00 00 00 l=0 R=211
ks11FA5E0200000N off
l=15 chipst=1 MARCST=13 , 07 FA 5E 45 11 CC 0F 02 9C 00 00 00 00 00 00 l=0 R=211
l=15 chipst=1 MARCST=13 , 07 FA 5E 45 11 CC 0F 02 9C 00 00 00 00 00 00 l=0 R=208
l=15 chipst=1 MARCST=13 , 07 FA 5E 45 11 CC 0F 02 9C 00 00 00 00 00 00 l=0 R=211
l=15 chipst=1 MARCST=13 , 07 FA 5E 45 11 CC 0F 02 9C 00 00 00 00 00 00 l=0 R=217
l=15 chipst=1 MARCST=13 , 07 FA 5E 45 11 CC 0F 02 9C 00 00 00 00 00 00 l=0 R=209
l=15 chipst=1 MARCST=13 , 07 FA 5E 45 11 CC 0F 02 9C 00 00 00 00 00 00 l=0 R=212
l=15 chipst=1 MARCST=13 , 07 FA 5E 45 11 CC 0F 02 9C 00 00 00 00 00 00 l=0 R=209
l=15 chipst=1 MARCST=13 , 07 FA 5E 45 11 CC 0F 02 9C 00 00 00 00 00 00 l=0 R=207
l=15 chipst=1 MARCST=13 , 07 FA 5E 45 11 CC 0F 02 9C 00 00 00 00 00 00 l=0 R=190
Mir ist nicht klar was Du beim cul bei einem RXFIFO_OVERFLOW machst, muss da nicht ein
CC1101_SFRX 0x3A // Flush the RX FIFO buffer
gemacht werden?
Nachtrag:
dies ist ohne sync
l=20 chipst=1 MARCST=13 , 00 0E 98 5B 5F D5 55 55 55 55 55 55 55 55 55 55 55 55 55 55 l=2 R=234
l=20 chipst=1 MARCST=13 , 55 4A 80 FF 4B CD 84 39 81 E0 50 A0 00 00 00 00 00 1B D5 55 l=2 R=239
l=20 chipst=1 MARCST=13 , 55 55 55 55 55 55 55 55 55 55 55 55 55 55 4A 80 FF 4B CD 84 l=2 R=238
l=20 chipst=1 MARCST=13 , 39 81 E0 50 A0 00 00 00 00 00 1B D5 55 55 55 55 55 55 55 55 l=2 R=238
l=20 chipst=1 MARCST=13 , 55 55 55 55 55 55 55 4A 80 FF 4B CD 84 39 81 E0 50 A0 00 00 l=2 R=238
l=20 chipst=1 MARCST=13 , 00 00 00 1D EA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA l=2 R=236
l=20 chipst=1 MARCST=13 , A5 40 7F A5 E6 C2 1C C0 F0 28 50 00 00 00 00 00 0D EA AA AA l=2 R=236
l=20 chipst=1 MARCST=13 , AA AA AA AA AA AA AA AA AA AA AA AA AA A5 40 7F A5 E6 C2 1C l=2 R=239
l=20 chipst=1 MARCST=13 , C0 F0 28 50 00 00 00 00 00 0D 55 55 55 55 55 55 55 55 55 55 l=2 R=239
l=20 chipst=1 MARCST=13 , 55 55 55 55 55 55 52 A0 3F D2 F3 61 0E 60 78 14 28 00 00 00 l=2 R=236
l=20 chipst=1 MARCST=13 , 00 00 06 AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA A9 l=2 R=234
l=20 chipst=1 MARCST=13 , 50 1F E9 79 B0 87 30 3C 0A 14 00 00 00 00 00 03 BD 55 55 55 l=2 R=239
l=20 chipst=1 MARCST=13 , 55 55 55 55 55 55 55 55 55 55 55 55 54 A8 0F F4 BC D8 43 98 l=2 R=238
l=20 chipst=1 MARCST=13 , 1E 05 0A 00 00 00 00 00 01 BD 55 55 55 55 55 55 55 55 55 55 l=2 R=239
l=20 chipst=1 MARCST=13 , 55 55 55 55 55 54 A8 0F F4 BC D8 43 98 1E 05 0A 00 00 00 00 l=2 R=240
l=20 chipst=1 MARCST=13 , 00 01 AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA 54 l=2 R=234
l=20 chipst=1 MARCST=13 , 07 FA 5E 6C 21 CC 0F 02 85 00 00 00 00 00 00 DE AA AA AA AA l=2 R=235
l=20 chipst=1 MARCST=13 , AA AA AA AA AA AA AA AA AA AA AA AA 54 07 FA 5E 6C 21 CC 0F l=2 R=240
l=20 chipst=1 MARCST=13 , 02 85 00 00 00 00 00 00 EF 55 55 55 55 55 55 55 55 55 55 55 l=2 R=240
l=20 chipst=1 MARCST=13 , 55 55 55 55 55 2A 03 FD 2F 36 10 E6 07 81 42 80 00 00 00 00 l=2 R=241
l=20 chipst=1 MARCST=13 , 00 6F 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 2A 03 l=2 R=239
Hallo,
ich arbeite beim CUL normalerweise mit einer festen Botschaftslänge.
Ein Overflow kann da nicht vorkommen (das Fifo ist 64 Bytes tief, ich hole die Botschaften jeweils nach 20 Empfangenen Bytes ab).
Nach den 20 Bytes fängt der CC1101 wieder von vorne mit dem Empfang an und wartet auf ein Sync Event
Die Preamble und das SyncWort (0x54) filtert mir auch der CC1101 im FIFO Mode mit Sync Word bereits raus, d.h. bei mir kommen nur noch die Nutzdaten an.
Ich Empfange auch alle Botschaften, das kannst Du beobachten indem Du in meiner Standard Firmware einfach "krS" eingibst.
Das RSSI lese ich überhaupt nicht aus
Jetzt funktioniert auch der Empfang von LaCrosse.
Dies sind die Nachrichten vom TX29DTH-IT
90264430DAAAAA00000BCAB2
90264430DAAAAA00001A37A6
90264431EBAAAA00001422D5
91264632FAAAAA000032387C
91264632FAAAAA000027F65C
92264733A3AAAA00000F7F03
92264834ADAAAA00002ED74B
92264834ADAAAA000028FFCF
93A650358BAAAA00001DC3DE
93A650358BAAAA000003D2D5
In der a-culw werden diese nach HMS gewandelt und dann im cul Modul zum HMS Modul übergeben.
Hier ist das Message Format und die Wandlung beschrieben
https://github.com/heliflieger/a-culfw/blob/master/culfw/clib/lacrosse.c
9 3A 650 35 8B AAAA000003D2D5
id ttt hh cc
temp = (ttt - 400) / 10
Lässt sich wahrscheinlich recht einfach in das Signalduino Modul einbauen.
Dies hier
93A650358B AAAA000003D2D5
kann z.B. als neuer Sensor/Protokoll so ans SD_WS Modul übergeben werden
W98#93A650358B
hier ist für den nanocul eine neue firmware für den xFSK Empfang mit dem FIFO
set sduino flash https://github.com/Ralf9/SIGNALDuino/releases/download/3.3.3.0-dev/SIGNALduino_nanoCC1101_3330dev.hex
version: V 3.3.3.0-dev SIGNALduino cc1101 - compiled at Jan 1 2020 13:58:21
Es kann sein, dass noch nicht alles sauber funktioniert.
Ich habe hier die für den FIFO Empfang notwendigen Register ergänzt:
https://forum.fhem.de/index.php/topic,106594.msg1004463.html#msg1004463
Nun gibt es eine neue Konfig Variable "ccmode".
Gesetzt wird sie mit CSccmode=x
z.B.
get sduino raw CSccmode=1
Ausgelesen mit
get sduino raw CG
Es sind die folgenden Werte möglich:
0 - normal (OOK)
1 - FIFO auslesen normal, z.B. für Kopp
2 - FIFO auslesen ohne Wiederholungen
3 - FIFO auslesen LaCrosse
9 - FIFO auslesen mit Debug Ausgaben
Beim mode 9 ist vor und nach dem Ausgeben die Anzahl der Bytes im FIFO in Klammern angegeben.
M13 bedeutet das marcstate Register = 13
Gruß Ralf
Hi,
bei unseren Analysen haben wir immer wieder das CC1101 Data Sheet zu Rate gezogen, um Registerinhalte zu interpretieren. Ich habe mir mal die Mühe gemacht und die Variablen-Definitionen aus dem Data Sheet rausgezogen und in ein Script gepackt.
Im Header müsst Ihr die Variablen
my $myDevice = "mySIGNALESP"; # Names des SIGNALduino Devices
my $telnetPort = 7072; # FHEM Telnet Port
anpassen. Passwortschutz habe ich noch nicht eingebaut. Am Ende des Scriptes werden dann die Register-Ausprägungen lt. Data Sheet interpretiert bzw. gemäß Formel ausgewertet.
Das Script führt ihr auf Eurer FHEM-Instanz aus.
Lohnt sich der Aufwand/Ansatz? Welche Variablen interessieren Euch als nächste?
VG Peter
Update: nächste Iteration des Scripts, etwas mehr Struktur, bin noch in der Findungsphase ...
ZitatIch habe mir mal die Mühe gemacht und die Variablen-Definitionen aus dem Data Sheet rausgezogen und in ein Script gepackt.
Evtl macht es Sinn dies hier einzubauen, hier wird die Antwort vom C99 Kommando verarbeitet
https://github.com/RFD-FHEM/RFFHEM/blob/bed000aa1220539536a8ff00f1a15c749179abd7/FHEM/00_SIGNALduino.pm#L1019
Zitat von: Ralf9 am 03 Januar 2020, 21:38:11
Evtl macht es Sinn dies hier einzubauen, hier wird die Antwort vom C99 Kommando verarbeitet
https://github.com/RFD-FHEM/RFFHEM/blob/bed000aa1220539536a8ff00f1a15c749179abd7/FHEM/00_SIGNALduino.pm#L1019
Hi Ralph,
Die erste Frage war, ob es was bringt und Interesse besteht. Anscheinend ja :).
Die nächste wäre: in den SDUINO oder das SD_Tool einbauen? Braucht man die Informationen bei einem laufenden System oder eher in der Entwicklungsphase?
Ich baue aber erst mal die restlichen Register ein ...
Ciao, Peter
Hallo Peter,
Zitat von: plin am 03 Januar 2020, 22:16:03
Hi Ralph,
Die nächste wäre: in den SDUINO oder das SD_Tool einbauen? Braucht man die Informationen bei einem laufenden System oder eher in der Entwicklungsphase?
Ciao, Peter
was möchtest oder würdest du im Tool eingebaut haben?
Das konnte ich deiner Aussage nicht eindeutig vernehmen.
MfG
Zitat von: HomeAuto_User am 04 Januar 2020, 17:39:49
Hallo Peter,
was möchtest oder würdest du im Tool eingebaut haben?
Das konnte ich deiner Aussage nicht eindeutig vernehmen.
MfG
Hi,
ich habe ein Script zur Auswertung aller CC1101 Register in Arbeit (aktueller Zwischenstand siehe Anlage).
Ralf meinte dazu
Zitat
Evtl macht es Sinn dies hier einzubauen, hier wird die Antwort vom C99 Kommando verarbeitet
https://github.com/RFD-FHEM/RFFHEM/blob/bed000aa1220539536a8ff00f1a15c749179abd7/FHEM/00_SIGNALduino.pm#L1019
Da der Output sehr lang ist/wird und ich nicht weiß, wie oft man den Output im Tagesgeschäft braucht, habe ich die Frage gestellt wo man den am sinnvollsten einbringt bzw. einbaut.
VG Peter
P.S. Beispiel-Output:
---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Register: 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e
Data: 0D 2E 2D 47 D3 91 3D 04 32 00 00 06 00 21 65 6F F9 F4 18 23 B9 40 07 00 18 14 6C 07 00 91 87 6B F8 56 11 EF 0D 3D 1F 41 00 59 7F 2F 88 31 0B
---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Frequenz = 868.302 MHz
Bandwidth = 58.0357142857143 kHz
Deviation = 25.390625 kHz
Datarate = 24.7955322265625 kHz
Modulation = GFSK
+-------------------------------- 0x00: IOCFG2 – GDO2 Output Pin Configuration -----------------------------------------------------------------------+
| GDO2_INV | 0 | Invert output, i.e. select active low (1) / high (0) |
| GDO2_CFG | 001101 | for details see CC1101 Data Sheet, Table 41 on page 62 |
+-----------------------------------------------------------------------------------------------------------------------------------------------------+
+-------------------------------- 0x01: IOCFG1 – GDO1 Output Pin Configuration -----------------------------------------------------------------------+
| GDO_DS | 0 | Set high (1) or low (0) output drive strength on the GDO pins. |
| GDO1_INV | 0 | Invert output, i.e. select active low (1) / high (0) |
| GDO1_CFG | 101110 | for details see CC1101 Data Sheet, Table 41 on page 62) |
+-----------------------------------------------------------------------------------------------------------------------------------------------------+
+-------------------------------- 0x02: IOCFG0 – GDO0 Output Pin Configuration -----------------------------------------------------------------------+
| TEMP_SENSOR_ENABLE | 0 | Enable analog temperature sensor. Write 0 in all other register bits when using temperature sensor. |
| GDO0_INV | 0 | Invert output, i.e. select active low (1) / high (0) |
| GDO0_CFG | 101101 | for details see CC1101 Data Sheet, Table 41 on page 62) |
+-----------------------------------------------------------------------------------------------------------------------------------------------------+
+-------------------------------- 0x03: FIFOTHR – RX FIFO and TX FIFO Thresholds ---------------------------------------------------------------------+
| ADC_RETENTION | 1 | TEST1 = 0x35 and TEST2 = 0x81 when waking up from SLEEP |
| CLOSE_IN_RX | 00 | RX Attenuation = 0 db |
| FIFO_THR | 0111 | Byte in TX FIFO: 33, Bytes in RX FIFO 32 |
+-----------------------------------------------------------------------------------------------------------------------------------------------------+
+-------------------------------- 0x04: SYNC1 – Sync Word, High Byte ---------------------------------------------------------------------------------+
| SYNC1 | 11010011 | 8 MSB of 16-bit sync word |
+-----------------------------------------------------------------------------------------------------------------------------------------------------+
+-------------------------------- 0x05: SYNC0 – Sync Word, Low Byte ----------------------------------------------------------------------------------+
| SYNC0 | 10010001 | 8 LSB of 16-bit sync word |
+-----------------------------------------------------------------------------------------------------------------------------------------------------+
+-------------------------------- 0x06: PKTLEN – Packet Length ---------------------------------------------------------------------------------------+
| PACKET_LENGTH | 61 | Indicates the packet length when fixed packet length mode is enabled. |
| | | If variable packet length mode is used, this value indicates the maximum packet length allowed. |
| | | This value must be different from 0. |
+-----------------------------------------------------------------------------------------------------------------------------------------------------+
+-------------------------------- 0x07: PKTCTRL1 – Packet Automation Control -------------------------------------------------------------------------+
| PQT | 000 | Preamble quality estimator threshold. |
| CRC_AUTOFLUSH | 0 | Enable automatic flush of RX FIFO when CRC is not OK. This requires that only one packet is in the RXIFIFO |
| | | and that packet length is limited to the RX FIFO size. |
| APPEND_STATUS | 1 | When enabled, two status bytes will be appended to the payload of the packet. The status bytes contain RSSI |
| | | and LQI values, as well as CRC OK. |
| ADR_CHK | 00 | No address check |
+-----------------------------------------------------------------------------------------------------------------------------------------------------+
+-------------------------------- 0x08: PKTCTRL0 – Packet Automation Control -------------------------------------------------------------------------+
| WHITE_DATA | 0 | Whitening is off |
| PKT_FORMAT | 11 | Format of RX and TX data: Asynchronous serial mode, Data in on GDO0 and data out on either of the GDOx pins |
| CRC_EN | 0 | CRC disabled for TX and RX |
| LENGTH_CONFIG | 10 | Infinite packet length mode |
+-----------------------------------------------------------------------------------------------------------------------------------------------------+
+-------------------------------- 0x09: ADDR – Device Address ----------------------------------------------------------------------------------------+
| DEVICE_ADDR | 00000000 | Address used for packet filtration. Optional broadcast addresses are 0 (0x00) and 255 (0xFF). |
+-----------------------------------------------------------------------------------------------------------------------------------------------------+
+-------------------------------- 0x0A: CHANNR – Channel Number --------------------------------------------------------------------------------------+
| CHAN | 0 | The 8-bit unsigned channel number, which is multiplied by the channel spacing setting and added to the base |
| | | frequency. |
+-----------------------------------------------------------------------------------------------------------------------------------------------------+
+-------------------------------- 0x0B: FSCTRL1 – Frequency Synthesizer Control ----------------------------------------------------------------------+
| FREQOFF | 00000000 | Frequency offset added to the base frequency before being used by the frequency synthesizer. ( |
+-----------------------------------------------------------------------------------------------------------------------------------------------------+
+-------------------------------- 0x0D: FREQ2 – Frequency Control Word, High Byte --------------------------------------------------------------------+
| FREQa | 00 | FREQ[23:22] is always 0 (the FREQ2 register is less than 36 with 26-27 MHz crystal) |
| FREQ2 | 100001 | FREQ[23:0] is the base frequency for the frequency synthesiser in increments of fXOSC/216. |
| | | => f_Carrier = 868.302 MHz |
+-----------------------------------------------------------------------------------------------------------------------------------------------------+
+-------------------------------- 0x0E: FREQ1 – Frequency Control Word, Middle Byte ------------------------------------------------------------------+
| FREQ1 | 01100101 | Ref. FREQ2 register |
+-----------------------------------------------------------------------------------------------------------------------------------------------------+
+-------------------------------- 0x0F: FREQ0 – Frequency Control Word, Low Byte ---------------------------------------------------------------------+
| FREQ0 | 01101111 | Ref. FREQ2 register |
+-----------------------------------------------------------------------------------------------------------------------------------------------------+
+-------------------------------- 0x10: MDMCFG4 – Modem Configuration --------------------------------------------------------------------------------+
| CHANBW_E | 3 | |
| CHANBW_M | 3 | Sets the decimation ratio for the delta-sigma ADC input stream and thus the channel bandwidth. |
| | | => Channel Bandwidth = 58.0357142857143 kHz |
| DRATE_E | 9 | The exponent of the user specified symbol rate |
+-----------------------------------------------------------------------------------------------------------------------------------------------------+
+-------------------------------- 0x11: MDMCFG3 – Modem Configuration --------------------------------------------------------------------------------+
| DRATE_M | 244 | The mantissa of the user specified symbol rate. The |
| | | => Data Rate = 24.7955322265625 kBaud |
+-----------------------------------------------------------------------------------------------------------------------------------------------------+
+-------------------------------- 0x12: MDMCFG2 – Modem Configuration --------------------------------------------------------------------------------+
| DEM_DCFILT_OFF | 0 | Enable (better sensitivity) |
| MOD_FORMAT | 001 | Modulation = GFSK |
| MANCHESTER_EN | 1 | Enables Manchester encoding/decoding -> Enable |
| SYNC_MODE | 000 | No preamble/sync |
+-----------------------------------------------------------------------------------------------------------------------------------------------------+
+-------------------------------- 0x13: MDMCFG1– Modem Configuration ---------------------------------------------------------------------------------+
| FEC_EN | 0 | Enable Forward Error Correction (FEC) with interleaving for packet payload -> Disable |
| NUM_PREAMBLE | 010 | Sets the minimum number of preamble bytes to be transmitted -> 4 |
| CHANSPC_E | 3 | 2 bit exponent of channel spacing |
+-----------------------------------------------------------------------------------------------------------------------------------------------------+
+-------------------------------- 0x14: MDMCFG0– Modem Configuration ---------------------------------------------------------------------------------+
| CHANSPC_M | 185 | 8-bit mantissa of channel spacing. |
| | | => Channel Spacing = 172.18017578125 kHz |
+-----------------------------------------------------------------------------------------------------------------------------------------------------+
+-------------------------------- 0x15: DEVIATN – Modem Deviation Setting ----------------------------------------------------------------------------+
| DEVIATION_E | 4 | Deviation exponent. |
| DEVIATION_M | 0 | Specifies the nominal frequency deviation from the carrier for a '0' (-DEVIATN) |
| | | and '1' (+DEVIATN) in a mantissa-exponent, interpreted as a 4-bit value with MSB implicit 1. |
| | | => Deviation = 25.390625 kHz |
+-----------------------------------------------------------------------------------------------------------------------------------------------------+
Da der Output sehr lang ist/wird und ich nicht weiß, wie oft man den Output im Tagesgeschäft braucht, habe ich die Frage gestellt wo man den am sinnvollsten einbringt bzw. einbaut.
Wenn du mit deinem Script fertig bist, so kann ich dies gern im Tool einbauen.
Du hast schon selbst den richtigen Ansatz gebracht, man benötigt es selten und somit wäre eine Verankerung im Modul unnötig.
Gib Bescheid, und ich übernehme die Erweiterung im Tool hier https://github.com/RFD-FHEM/SIGNALduino_TOOL/tree/pre-release.
MfG Marco
Zitat von: HomeAuto_User am 04 Januar 2020, 18:24:04
Da der Output sehr lang ist/wird und ich nicht weiß, wie oft man den Output im Tagesgeschäft braucht, habe ich die Frage gestellt wo man den am sinnvollsten einbringt bzw. einbaut.
Wenn du mit deinem Script fertig bist, so kann ich dies gern im Tool einbauen.
Du hast schon selbst den richtigen Ansatz gebracht, man benötigt es selten und somit wäre eine Verankerung im Modul unnötig.
Gib Bescheid, und ich übernehme die Erweiterung im Tool hier https://github.com/RFD-FHEM/SIGNALduino_TOOL/tree/pre-release.
MfG Marco
Hi Marco,
ich denke ich bin durch. Das Script in der Anlage berücksichtigt jetzt alle Register. War viel copy&paste, binäres Durchiterieren. Hoffe das Ergbnis ist halbwegs fehlerfrei.
Relevant sind die Zeilen ab 79. Der Aufruf erfolgt mit
SIGNALduino_TOOL_cc1101regs_Full($registerstring);
wobei $registerstring die konkatenierten Inhalte der Register sind 0D 2E 2D 47 D3 91 3D 04 ... mit einem \n am Ende.
Ciao, Peter
Danke Peter,
ich schaue es mir an und nehme es mit rein. Somit erweitern wir den Umfang und ein Debugging vom Register geht komfortabler.
Gesendet von iPhone mit Tapatalk Pro
Damit das Empfangen verschiedener Frequenzen und Modulationen komfortabler wird, habe ich meine Firmware um einige Funktionen erweitert, ist noch nicht ganz fertig.
Durch die Erweiterungen wird diese Firmware wegen der verwendeten Flashgröße nicht mehr auf sduinos mit einem ATmega32U4 laufen
Der Sketch verwendet 27758 Bytes (90%) des Programmspeicherplatzes. Das Maximum sind 30720 Bytes.
Ich habe in der V 3.3.4.0-dev SIGNALduino cc1101 folgendes eingebaut.
?
?S ? b CE CD CG CS C eC e P r R S t T V W x XE XQ
Es gibt einen neuen Befehl b<0-9>, damit können dann die Register zwischen 10 verschiedenen EEPROM Bänken (0000, 0100, 0140, 0180, 01C0,..) umgeschaltet werden.
Wenn z.B. mit "b1" auf den EEPROM Speicherbereich 0x100 umgeschaltet wird, dann werden mit den W-Befehlen wie z.B. "set sduino cc1101_reg" in diese EEPROM Bank geschrieben.
Wenn auf Bank 0 eine Register konfig für ook und in Bank 1 eine Register konfig für LaCrosse gespeichert ist, dann kann mit "b0" und "b1" zwischen diesen gewechselt werden:
MS;P1=497;P2=-1957;P3=-955;P4=-3894;D=14121312131312131213131313131313131213121213121213121212121313121213131312;CP=1;SP=4;R=223;e;m1;
MS;P1=497;P2=-1957;P3=-955;P4=-3894;D=14121312131312131213131313131313131213121213121213121212121313121213131312;CP=1;SP=4;R=223;e;m2;
set b=1 ccmode=3 sync=2DD4 MDMCFG[432]=895C06 boffs=0100
MN;D=9B263330CFAAAA000015AD57;
MN;D=9B263330CFAAAA000034FFAB;
MN;D=9B263330CFAAAA00003BB9FC;
set b=0 ccmode=0 sync=D391 MDMCFG[432]=57C430 boffs=0000
MS;P2=-393;P4=-1084;P5=332;P6=-11158;P7=1030;D=56547254545454545454545454545454545454547254725454;CP=5;SP=6;R=8;O;b7;m0;
MS;P2=-412;P4=-1073;P5=339;P6=-11130;P7=1028;D=56547254545454545454545454545454545454547254725454;CP=5;SP=6;R=8;O;m1;
MS;P2=-409;P4=-1094;P5=332;P6=-11125;P7=1025;D=56547254545454545454545454545454545454547254725454;CP=5;SP=6;R=8;O;m2;
Damit der Wechsel auch automatisch geht, habe ich eine Togglefunktion vorbereitet
z.B.
T?
Toggle= 100 20 0 0 0 0 0 0 0 0
damit ist dann die Bank0 100sek und Bank1 20sek aktiv.
Damit die EEPROM Speicherbereiche angeschaut werden können, habe ich den EEPROM read Befehl erweitert:
rN0100
EEPROM 0100: FF FF 01 2E 46 02 2D D4 FF 00 02 00 00 06 00 21
EEPROM 0110: 65 6A 89 5C 06 22 F8 56 07 00 18 16 6C 43 68 91
EEPROM 0120: 87 6B F8 56 10 E9 2A 00 11 41 00 FF FF FF FF FF
EEPROM 0130: 00 84 00 00 00 00 00 00 FF FF FF FF FF 00 03 FF
Gruß Ralf
Jetzt habe ich es hinbekommen, daß der Empfang von LaCrosse Temperatursensoren funktioniert.
Die LaCrosse Nachrichten werden per dispatch dem 36_LaCrosse Modul übergeben.
Damit ein neuer Sensor per Autocreate angelegt werden kann, ist ein neuer set Befehl notwendig:
set sduino LaCrossePairForSec
Ich habe hier die dazu notwendigen Anpassungen und Erweiterungen vom Signalduino Modul dokumentiert:
https://github.com/Ralf9/RFFHEM/issues/4
Die dazu notwendige firmware "V 3.3.4.0" habe ich fast fertig.
Gruß Ralf
Hallo zusammen.
Coole nummer das mit den LaCrosse Sensoren.
Besteht die Möglichkeit, das der Signal Duino dann mit 2 cc1101 arbeiten kann, für beide Frequenzen (433 und 868)?
Sonst bräuchte man für jede frequenz nen eigenen sduino?
Gruß und danke
Sascha
Gesendet von meinem MI 9 mit Tapatalk
Wunschliste II: MapleSignalduino (mit LAN+durchgereichten seriellen Interfaces, auf MapleCUN-Basis)...
Super Job, so oder so!!!
Ich verstehe zwar nicht so ganz, was ihr da macht, aber ich lese mal mit.
Zitat von: Beta-User am 07 Januar 2020, 11:17:23
Wunschliste II: MapleSignalduino (mit LAN+durchgereichten seriellen Interfaces, auf MapleCUN-Basis)...
Hm, das wäre was für die Erweiterungsplatine des LacrosseGateWays. Dazu müsste ich halt mal die Hardware eines SignalDuinos verstehen ::)
Gruß Peter
Hallo Peter,
ich lese hier auch mit und gemeint ist sicherlich so etwas:
https://forum.fhem.de/index.php/topic,97739.msg922502.html#msg922502 (https://forum.fhem.de/index.php/topic,97739.msg922502.html#msg922502)
zumindest wäre es auch mein Wunsch...
Gruß Uwe
Bevor Ihr spekuliert:
Das mit den addons ist toll, und das geht heute schon mit der normalen CUL-Maple-Firmware, v.a. für "Fertiggerät" wie das HM-PI-PCB oder den CC2531 (zigbee2mqtt), und man kann "nebenbei" auch einen Signalduino aufsatteln.
Da der Teil mit den drei seriellen Schnittstellen "reine STM-Basis" ist, ist es vermutlich nicht so schwer, das für den Signalduino zu adaptieren.
Der Vorschlag geht aber noch etwas weiter (bzw. das war der ursprüngliche und erste Gedanke (ausgehend von der Feststellung, dass auf dem ATMega32 der Platz eng wird):
Die CUL-Firmware hat die Stärke, dass viel in der firmware selbst erledigt wird, was v.a. auch für diverse Sonderprotokolle "neben HM-BidCoS und ZWave" angeht, der Signalduino ist schon immer und jetzt noch mehr super, wenn es um die flexible Auswertung von irgendwas seltenerem oder unbekannterem oder eben von "generischem Zeug" wie IT geht. (@Ralf9, Sidey&Co: Seht mir nach, wenn das etwas zu flapsig oder technisch gesehen unsauber ist... ich bin da auch nicht wirklich Experte).
Die eigentliche Idee wäre, jeden CC1101 dann (mehr oder weniger frei) wahlweise im "CUL-(xyz-)Mode" oder "Signalduino-Mode" ansprechen zu können und den "Nebeneffekt" mit den beiden zusätzlichen Schnittstellen mitzunehmen...
Hoffe, das ganze ist jetzt besser verständlich. (Ob das auch ganz oder in Teilen umsetzbar, ist eine ganz andere Frage...)
Gruß, Beta-User
Zitat von: Beta-User am 07 Januar 2020, 11:17:23
Wunschliste II: MapleSignalduino (mit LAN+durchgereichten seriellen Interfaces, auf MapleCUN-Basis)...
Es gibt anscheinend außer mir noch andere die lieber LAN als WLAN verwenden wollen.
Für den SIGNALDuino auf dem Maple Mini gibts ein eigenes Thema
https://forum.fhem.de/index.php/topic,106278.msg1010356.html#msg1010356
ZitatDie eigentliche Idee wäre, jeden CC1101 dann (mehr oder weniger frei) wahlweise im "CUL-(xyz-)Mode" oder "Signalduino-Mode" ansprechen zu können und den "Nebeneffekt" mit den beiden zusätzlichen Schnittstellen mitzunehmen...
Dies ist wahrscheinlich nicht oder nur mit sehr großem Programmieraufwand möglich. Der seitherige normale OOK Modus, indem die Länge der empfangenen Pulse gemessen wird, ist sehr zeitkritisch.
Außer den bidirektionalen Protokollen müsste alles was der cul kann mit überschaubarem Aufwand auch mit dem Signalduino empfangen werden können.
Gruß Ralf
Zitat von: sash.sc am 07 Januar 2020, 10:59:49
Besteht die Möglichkeit, das der Signal Duino dann mit 2 cc1101 arbeiten kann, für beide Frequenzen (433 und 868)?
Sonst bräuchte man für jede frequenz nen eigenen sduino?
Dies wird mit der jetzigen Arduino Hardware wahrscheinlich nicht gehen. Mit dem Maple Mini müsste es machbar sein.
Was demnächst gehen müsste, wenn Du nichts senden möchtest, ist per Timer zwischen den EEPROM Speicherbänken umzuschalten.
Wenn die Sensoren nicht so weit weg sind, empfängt der 868 cc1101 auch recht brauchbar die 433 Sensoren, auch durch eine Betondecke.
Wenn Du z.B. auf der Bank 0 eine cc1101 Register konfiguration für 433 MHz und auf Bank 1 eine Register konfiguration für LaCrosse hast,
dann kannst Du dies dann so konfigurieren, daß z.B. für 10 Min die Register konfiguration von Bank 0 und dann für 30 Sek Bank 1 für LaCrosse aktiv ist, und dann wieder Bank 0 ...
Ja, WLAN ist mMn. kurz vor dem 433MHz-Gedöns (das man leider nicht immer vermeiden kann...) so ziemlich das letzte, was man sich freiwillig für was wichtiges im Bereich der HA antun sollte... (haben wir nicht grade wieder jemanden, der sich wundert, dass die Fritte das nicht packt. Und Passwörter wechselt auch keiner mehr bei >20 Geräten :P .)
Was +CUL angeht: Wenn das mit dem Maple/LAN klappt, ist sowieso alles gut, das bidirektionale Zeug (HM, z.B.), ist sowieso auf "eigenen" Interfaces besser aufgehoben!
Danke für den Link, vielleicht komme ich mal dazu, da mitzutesten :) .
Irgendwas passt mit dem 36_LaCrosse Modul nicht, es scheint mir irgendwie mein ganze fhem durcheinander zu bringen.
Ich wandle die LaCrosse Rohdaten in das LaCrosse Format
z.B.
OK 9 43 129 4 210 50
Ich habe meine firmware auf einem nanocul und auf einer minicul Hardware, auf beiden ist eine Registerkonfiguration für den LaCrosse Mode 1 Empfang.
Damit kann ich problemlos meinen TX29 DTH-IT empfangen, er wird auch per Autocreate angelegt.
Wenn ich nun den einen sduino ausstecke und den anderen in den PC einstecke, dann funktioniert der dispatch nicht mehr. In der Parse Routine des LaCrosse Modul kommt nichts an. (bei allen anderen Modulen funktioniert ein Wechsel problemlos)
Ab und zu funktioniert es nach einem fhem restart wieder.
Es kommt auch vor, daß ich vor dem restart das angelegte LaCrosse Device vom TX29 löschen muss oder die regexp von der matchlist editieren muss.
Die regexp ist inzwischen recht einfach
"30:LaCrosse" => '^OK.*',
Können evtl die Leerzeichen in der LaCrosse Nachricht Probleme machen?
Mir fehlt ein Ansatz wie ich das Debuggen kann
Habs gefunden, es liegt an diesem Eintrag, dadurch muss nach einem Wechsel des IODev ein fhem restart gemacht werden, wenn ich dies auskommentiere, funktioniert es auch mit einem anderen IODev
$hash->{FingerprintFn} = "LaCrosse_Fingerprint";
sub LaCrosse_Fingerprint($$) {
my ($name, $msg) = @_;
return ( "", $msg );
}
Zitat von: Ralf9 am 07 Januar 2020, 23:12:40
Dies wird mit der jetzigen Arduino Hardware wahrscheinlich nicht gehen. Mit dem Maple Mini müsste es machbar sein.
Was demnächst gehen müsste, wenn Du nichts senden möchtest, ist per Timer zwischen den EEPROM Speicherbänken umzuschalten.
Wenn die Sensoren nicht so weit weg sind, empfängt der 868 cc1101 auch recht brauchbar die 433 Sensoren, auch durch eine Betondecke.
Wenn Du z.B. auf der Bank 0 eine cc1101 Register konfiguration für 433 MHz und auf Bank 1 eine Register konfiguration für LaCrosse hast,
dann kannst Du dies dann so konfigurieren, daß z.B. für 10 Min die Register konfiguration von Bank 0 und dann für 30 Sek Bank 1 für LaCrosse aktiv ist, und dann wieder Bank 0 ...
Habe von Locutus den maple Mini. Da sind schon 2 cc1101 mit beiden Frequenzen drauf und nem esp-01 als serial wlan bridge. LAN Modul kann man auch noch drauf löten.
Theoretisch wäre die Hardware da, oder?
Gesendet von meinem MI 9 mit Tapatalk
ZitatHabe von Locutus den maple Mini. Da sind schon 2 cc1101 mit beiden Frequenzen drauf und nem esp-01 als serial wlan bridge. LAN Modul kann man auch noch drauf löten.
Theoretisch wäre die Hardware da, oder?
Ja die Hardware sollte ungefähr passen
Cool, fehlt nur noch die Firmware. [emoji6]
Gesendet von meinem MI 9 mit Tapatalk
Hier ist für den Arduino nano , minicul und CUL V3 die Firmware V3.3.4 und V3.3.5, damit ist auch ein Empfangen und Senden von FSK modulierten Signalen möglich.Es gibt auch 10 EEPROM Speicherbänke in denen die cc1101 Register gespeichert werden können.
Es gibt seit 29.05.22 eine neue Version V3.3.5 es ist dafür mein 00_SIGNALDuino Modul ab v3.4.13-dev_ralf_29.05. notwendig
https://github.com/Ralf9/SIGNALDuino/releases/tag/3.3.5-dev220529
Die aktuelle Version ist V3.3.4-dev211207
https://github.com/Ralf9/SIGNALDuino/releases/tag/3.3.4-dev211207
https://github.com/Ralf9/SIGNALDuino/releases
für den nano mit cc1101
set sduino flash https://github.com/Ralf9/SIGNALDuino/releases/download/3.3.4-dev200914/SIGNALduino_nanoCC1101_3340dev200914.hex
für den minicul
set sduino flash https://github.com/Ralf9/SIGNALDuino/releases/download/3.3.4-dev200914/SIGNALduino_miniCUL_3340dev200914.hex
3.3.4-dev200914 SIGNALduino cc1101 (minicul 868Mhz) (b2) - compiled at Sep ...
3.3.4-dev200914 SIGNALduino cc1101 (b1) - compiled at Sep ...
In der firmware V 3.3.4 gibt es einen neuen Befehl b<0-9>, damit können dann die cc1101 Register zwischen 10 verschiedenen EEPROM Bänken (0000, 0100, 0140, 0180, 01C0,..) umgeschaltet werden.
Mit b? kann die aktuelle Bank abgefragt werden. Wenn mit b<0-9> auf eine nicht initialisierte Bank gewechselt wird, dann kann es noch zu einem Absturz der Firmware kommen.
Mit b<0-9>W wird die Bank umgeschaltet und die BankNr im EEPROM gespeichert.
Edit 12.01.20: Es wird nun durch eine Abfrage verhindet, daß auf eine nicht initialisierte Bank umgeschaltet wird (siehe unten)
Mit e<0-9> wird auf die angegebene Bank ein cc1101 Factoryreset durchgeführt.
Mit der firmware V 3.3.4-dev200914 gibt es die folgende Neuerungen:
- Es gibt einen neuen Befehl "bs" - Banksummary (siehe Anlage)
- ccmode=4 zugefügt
- beim CW Befehl die Bank Kurzbeschreibung zugefügt
- Bei SlowRF (ASK/OOK) wird beim Sendebefehl das Echo auf 100 Zeichen begrenzt.
- Wenn eine nicht initialisierte EEPROM Speicherbank ausgewählt wurde, dann wird diese mit den sduino Defaults initialisiert (raw e).
Ab der firmware V 3.3.4.0 dev 200121 gibts ein neues Kommando "CW", damit kann eine folge von cc1101 Registern gesetzt und in die aktuelle EEPROM Speicherbank geschrieben werden.
https://forum.fhem.de/index.php/topic,106594.msg1005067.html#msg1005067
Um z.B. die cc1101 Register vom culw Mode 1 - IT+ 17.241 kbps auf die EEPROM Bank 1, PCA301 auf Bank 3 und Kopp Free Kontrol auf Bank 4 zu speichern,
- wird zuerst mit b1 (get sduino raw b1) die Bank 1 aktiviert, (wenn defaultmässig die Bank 1 verwendet werden soll, dann kann mit b1W die default Banknr im EEPROM gespeichert werden)
wenn die Bank noch nicht initialisiert ist, kommt die folgende Antwort
The Bank 1 was not init, therefore it reseted to sduino defaults (raw e).
Nun werden damit
get sduino raw CW0001,012E,0246,0302,042D,05D4,06FF,0700,0802,0D21,0E65,0F6A,1089,115C,1206,1322,14F8,1556,1700,1818,1916,1B43,1C68,1D91,2211,23E9,242A,2500,2611,3D00,3E03,404d,4131,425f,4349,4454,452b,4600
die für den Mode 1 - IT+ notwendigen cc1101 Registeränderungen in die Bank 1 geschrieben und mit 3E03 wird auch gleich die Konfigvariable ccmode auf 3 gesetzt.
- dann wird mit b3 (get sduino raw b3) die Bank 3 aktiviert, wenn die Bank noch nicht initialisiert ist, dann wird sie automatisch mit den sduino defaults (raw e) initialisiert,
Nun werden damit
get sduino raw CW0001,012E,0246,0307,042D,05D4,06FF,0700,0802,0D21,0E6B,0FD0,1088,110B,1206,1322,14F8,1553,1700,1818,1916,1B43,1C68,1D91,2211,23E9,242A,2500,2611,3D03,3E03,4050,4143,4241,435f,4433,4530,4631,4700
die für PCA301 notwendigen cc1101 Registeränderungen in die Bank 3 geschrieben und mit 3D03 wird auch gleich die Konfigvariable ccN auf 3 und mit 3E03 wird die Konfigvariable ccmode auf 3 gesetzt.
- und mit b4 (get sduino raw b4) wird die Bank 4 aktiviert, wenn die Bank noch nicht initialisiert ist, dann wird sie automatisch mit den sduino defaults (raw e) initialisiert,
Nun kann mit
get sduino raw CW0001,012E,0206,0304,04AA,0554,060F,07E0,0800,0D21,0E65,0F6A,1097,1183,1216,1363,1547,170C,1829,1936,1C40,1D91,23E9,242A,2500,3D04,3E02,404b,416f,4270,4370,445f,4546,4643,4700
die für Kopp notwendigen cc1101 Registeränderungen in die Bank 4 geschrieben und ccN auf 4 und ccmode auf 2 gesetzt werden.
Bei ccmode sind z.Zt. die folgenden Werte möglich:
0 - normal (OOK)
1 - FIFO auslesen normal, z.B. für Kopp
2 - FIFO auslesen ohne Wiederholungen
3 - FIFO auslesen LaCrosse
4 - FIFO auslesen LaCrosse (selbe Methode wie bei der a-culw)
9 - FIFO auslesen mit Debug Ausgaben
Beim mode 9 ist vor und nach dem Ausgeben die Anzahl der Bytes im FIFO in Klammern angegeben.
M13 bedeutet das marcstate Register = 13
Ich habe auch eine Unschönheit beim Befehl XQ behoben.
Wenn nun mit XQ der Empfang gesperrt wird, bleibt er auch nach dem Senden gesperrt
Nun werden beim Umschalten auf eine Bank größer 0 die ersten beiden Speicherstellen in der umzuschalteten Bank abgefragt.
In der ersten Speicherstelle muss die Banknummer und in der zweiten Speicherstelle (255 - Banknr) stehen.
z.B. in der Bank 1
0100: 01
0101: FE
Für die FSK und EEPROM Speicherbank unterstützung ist eine angepasste und erweiterte Version der 00_SIGNALduino.pm und die signalduino_protocols.pm notwendig:
https://github.com/Ralf9/RFFHEM/issues/4
Siehe auch hier:
https://forum.fhem.de/index.php/topic,106594.msg1004463.html#msg1004463
Linkliste (https://forum.fhem.de/index.php/topic,111653.msg1058901.html#msg1058901)
Gruß Ralf
Zitat von: sash.sc am 08 Januar 2020, 06:19:20
Habe von Locutus den maple Mini. Da sind schon 2 cc1101 mit beiden Frequenzen drauf und nem esp-01 als serial wlan bridge. LAN Modul kann man auch noch drauf löten.
Theoretisch wäre die Hardware da, oder?
Eine Einschränkung wirds geben, ich habe nicht vor es so einzubauen, daß auf beiden cc1101 Modulen OOK/ASK (slowrf Modus vom cul) empfangen werden kann. Dies ist mir viel zu aufwändig. Ist dies beim Maple cul möglich?
D.h. es wird nicht möglich sein, FS20 oder die WH1080 auf 868MHz und gleichzeitig 433 MHz Sensoren zu empfangen.
Auf dem zweiten cc1101 wird nur der native Mode des cul möglich sein.
Man kann für jedes Modul einen Modus einstellen. 433 slowrf und 868 habe ich für Homematic. Jedes folgemodul wird als separates device (STACKABLE_CC) angelegt
Gesendet von meinem MI 9 mit Tapatalk
@RaspII
Mittlerweile funktioniert auch das einfache Senden über den FIFO.
Mir ist aber nicht klar was das beim kopp_fc in der "kopp-fc.c" mit dem SingleBlkOnly auf sich hat
if(in[1] == 's') SingleBlkOnly=1;
In welchen Fällen ist momentan "SingleBlkOnly=0"?
Im KOPP_FC Modul beginnen momentan alle gesendeten Nachrichten mit "ks"
Hi
Ich schreibe dir heute Abend eine ausführliche Antwort.
Ich habe aber auch noch eine Frage an Euch:
Hat schon jemand den Fifo Mode mit ASK/OOK genutzt?
Hintergrund:
Kopp V1 sendet via OOK
Die aktuellen Kopp Module haben zwei Modi
1. kurzer Tastendruck
damit schaltet man Devices ein, aus oder toggelt den Zustand.
2. langer Tastendruck (der Tastencode ist dann um 0x80 höher)
damit kann man z.B. Dimmer steuern, d.h. solange die Taste gedrückt wird ändert sich der Zustand.
Die alten KoppV1 Module haben tatsächlich während dem langen Tastendruck dauern den selben Code gesendet.
In den neuen Modulen ist das anders gelöst.
Wird ein langer Tastendruck erkannt wird eine Art "Startcode" gesendet, nach loslassen der Taste ein Endcode, natürlich jeweils ein kompletter Block.
Wenn man jetzt noch weiß, dass ich die Software über einen längeren Zeitraum entwickelt hat, versteht man eher, das ich:
- Anfangs die Module aus FHEM heraus im reinem RAW Mode also ohne KOPP_FC bedient habe
- Nachdem ich dann FHEM besser verstanden habe und mich auch an Perl herangetraut habe sind immer mehr Funktionalitäten in FHEM reingewandert (z.B. Kennt FHEM jetzt die wichtigsten Kopp Aktoren)
Fazit:
"kt" wird von FHEM nicht genutzt, möchte man aber z.B. neue Module ohne FHEM Implementierung bedienen kann man diesen Befehl im RAW Mode immer noch nutzen
Alles klar?
Zitat2. langer Tastendruck (der Tastencode ist dann um 0x80 höher)
damit kann man z.B. Dimmer steuern, d.h. solange die Taste gedrückt wird ändert sich der Zustand.
Ist dies ein ein Tasten Dimmer? Wenn das Modul in die falsche Richtung dimmt, dann wird die Taste kurz losgelassen, dann dimm es in die andere Richtung?
Zitat"kt" wird von FHEM nicht genutzt, möchte man aber z.B. neue Module ohne FHEM Implementierung bedienen kann man diesen Befehl im RAW Mode immer noch nutzen
Alles klar?
Dies kann doch aber auch erreicht werden, wenn ohne FHEM Implementierung erst der ks Befehl für dimm und dann den ks Befehl für stop gesendet wird.
Das kt in die sduino firmware einzubauen wäre recht aufwändig, das kt dürfte demnach auch nicht nötig sein.
Damit auch das Senden über das Kopp Modul funktioniert, muss noch folgendes in die "sub KOPP_FC_SendCommand" eingebaut werden:
if ($io->{TYPE} ne "SIGNALduino") {
$message = "s"
. $keycodehex
. $hash->{TRANSMITTERCODE1}
. $hash->{TRANSMITTERCODE2}
. $hash->{TIMEOUT}
. "N"; # N for do not print messages (FHEM will write error messages to log files if CCD/CUL sends status info
## Send Message to IODev using IOWrite
IOWrite( $hash, "k", $message );
}
else {
my $d;
my $dmsg = "07" . $hash->{TRANSMITTERCODE1} . sprintf("%02x",$hash->{blkctr}) . $keycodehex . "CC0F" . $hash->{TRANSMITTERCODE2};
my $blkck = 0xAA;
for (my $i = 0; $i < 8; $i++) {
$d = hex(substr($dmsg,$i*2,2));
$blkck ^= $d;
}
$message = "SN;R=13;D=" . $dmsg . sprintf("%02x",$blkck) . "000000000000;";
IOWrite($hash, "raw", $message);
#Log3 $name, 4, "$io->{NAME} Kopp_FC_Set: $name sendRaw=$message";
$hash->{blkctr}++;
}$hash->{blkctr} = 0
muss noch nach define
Gruß Ralf
zum langen Tastendruck:
Der Dimmer steuert durch, d.h. von hell nach dunkel, danach ohne pause wieder nach hell usw.
zum nichtnutzen von "kt"
Im Falle vom Dimmer hast Du recht, da könnte man so auch im RAW Mode arbeiten.
Ich hatte aber ein Spezialfall, bei dem man die taste für 3sec drücken musste. Das hatte dann die Firmware für mich erledigt.
Der "kt" Befehl ist so aufgebaut, dass man eine Zeit übergeben kann, die dann abläuft (zwischen start und stop).
In FHEM musste man dann keine Timer etc. händisch aufspannen.
Deine Änderung in KOPP_FC habe ich nicht verstanden, da bin ich aber vermutlich auch zu lange aus der Programmierung raus.
Was mir noch nicht einleuchtet ist, warum Du das Kopp Protokoll überhaupt unterstützen willst.
Man muss den Signalduino oder CUL immer exclusiv für das KOPP Protokoll reservieren, dann kann man doch auch gleich einen NANO CUL nutzen
ZitatDeine Änderung in KOPP_FC habe ich nicht verstanden, da bin ich aber vermutlich auch zu lange aus der Programmierung raus.
Damit wird, wenn das IOdev der Signalduino ist
anstatt "ks21FA5E0200000N" das hier gesendet "SN;R=13;D=07FA5E1821CC0F02f1000000000000;"
Wenn ich vom sduinoE zum sduinoRXB sende, siehts im fhemlog so aus:
2020.01.11 16:29:41.366 3 : KOPP_FC_Set: Device Name: culfsk, command: on, Model: Switch_2KeyMode, Transm.-/KeyCode: FA5E 21
2020-01-11 16:29:41.367 KOPP_FC culfsk on
2020.01.11 16:29:41.368 4 : set sduinoE raw SN;R=13;D=07FA5E1821CC0F02f1000000000000;
2020.01.11 16:29:41.606 4 : sduinoRXB/msg READ: MN;D=07FA5E1821CC0F02F1000000000000;
2020.01.11 16:29:41.606 4 : sduinoRXB: Found GFSK Protocol id 102 -> KoppFreeControl
2020.01.11 16:29:41.606 4 : sduinoRXB KoppFreeControl: dmsg=07FA5E1821CC0F02F1000000000000 anz=8 checksum=241 ok
2020.01.11 16:29:41.606 4 : sduinoRXB ParseMN: ID=102 dmsg=kr07FA5E1821CC0F02
2020.01.11 16:29:41.606 4 : sduinoRXB Dispatch: kr07FA5E1821CC0F02, dispatch
2020.01.11 16:29:41.606 2 : KOPP_FC_Parse: name: sduinoRXB code: FA5E 21 Specialkey:short
2020-01-11 16:29:41.608 KOPP_FC culfsk on
2020.01.11 16:29:42.232 4 : sduinoE/msg READ: SN;R=13;D=07FA5E1821CC0F02f1000000000000;Marcs=1
2020.01.11 16:29:43.638 3 : KOPP_FC_Set: Device Name: culfsk, command: off, Model: Switch_2KeyMode, Transm.-/KeyCode: FA5E 21
2020-01-11 16:29:43.639 KOPP_FC culfsk off
2020.01.11 16:29:43.640 4 : set sduinoE raw SN;R=13;D=07FA5E1911CC0F02c0000000000000;
2020.01.11 16:29:43.829 4 : sduinoRXB/msg READ: MN;D=07FA5E1911CC0F02C0000000000000;
2020.01.11 16:29:43.829 4 : sduinoRXB: Found GFSK Protocol id 102 -> KoppFreeControl
2020.01.11 16:29:43.829 4 : sduinoRXB KoppFreeControl: dmsg=07FA5E1911CC0F02C0000000000000 anz=8 checksum=192 ok
2020.01.11 16:29:43.829 4 : sduinoRXB ParseMN: ID=102 dmsg=kr07FA5E1911CC0F02
2020.01.11 16:29:43.829 4 : sduinoRXB Dispatch: kr07FA5E1911CC0F02, dispatch
2020.01.11 16:29:43.829 2 : KOPP_FC_Parse: name: sduinoRXB code: FA5E 11 Specialkey:short
2020-01-11 16:29:43.831 KOPP_FC culfsk off
2020.01.11 16:29:44.504 4 : sduinoE/msg READ: SN;R=13;D=07FA5E1911CC0F02c0000000000000;Marcs=1ZitatWas mir noch nicht einleuchtet ist, warum Du das Kopp Protokoll überhaupt unterstützen willst.
Ist für mich auch ein Test ob das Senden und Empfangen über den FIFO sauber funktioniert.
Auf der Version für den Maple Mini habe ich vor mehrere cc1101 zu unterstützen.
Hallo Ralf9,
kann ich denn meinen Cul (ich habe den von locutus) über http flashen? Mir sagte er
avrdude: Version 6.1, compiled on Jul 7 2015 at 10:29:47
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2014 Joerg Wunsch
System wide configuration file is "/etc/avrdude.conf"
Using Port : 192.168.2.54:23
Using Programmer : arduino
Overriding Baud Rate : 57600
avrdude: ser_open(): can't open device "192.168.2.54:23": No such file or directory
avrdude done. Thank you.
und anscheinend geht das nicht? Die IP ist korrekt und er ist openend, aber eben mit Version
Internals:
CFGFN
Clients :IT:CUL_TCM97001:SD_RSL:OREGON:CUL_TX:SD_AS:Hideki:SD_WS07:SD_WS09: :SD_WS:RFXX10REC:Dooya:SOMFY:SD_BELL:SD_UT:SD_WS_Maverick:FLAMINGO:CUL_WS:Revolt: :FS10:CUL_FHTTK:Siro:FHT:FS20:CUL_EM:Fernotron:SD_Keeloq:SIGNALduino_un:
DEF 192.168.2.54:23
DMSG s336CCB607000
DevState initialized
DeviceName 192.168.2.54:23
FD 37
FLASH_RESULT ERROR: avrdude exited with error
FUUID 5e1a4c68-f33f-05b9-0472-e14bd9c0af2f47d2
IDsNoDispatch 2,72.1,82
LASTDMSG s336CCB607000
LASTDMSGID 0.3
MSGCNT 109
NAME sduino2
NR 83604
PARTIAL
RAWMSG MS;P0=-4023;P1=478;P2=-2006;P4=-9012;D=14121210101212101012101012101012121010121210121010121010121212121212101010;CP=1;SP=4;R=240;O;m2;
RSSI -82
STATE opened
TIME 1578782835
TYPE SIGNALduino
hasCC1101 1
sendworking 0
version V 3.3.1 SIGNALduino cc1101 (433 Mhz ) - compiled at Dec 3 2019 19:42:03
versionProtocols 1.10
versionmodul v3.4.1
DoubleMsgIDs:
MatchList:
10:SD_WS07 ^P7#[A-Fa-f0-9]{6}[AFaf][A-Fa-f0-9]{2,3}
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 ^P(?:14|29|30|34|46|68|69|76|81|83|86|90|91|91.1|92|93|95)#.*
18:FLAMINGO ^P13\.?1?#[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
25:CUL_EM ^E0.................
26:Fernotron ^P82#.*
27:SD_BELL ^P(?:15|32|41|42|57|79|96)#.*
28:SD_Keeloq ^P(?:87|88)#.*
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:
2020-01-11 23:31:57 ccconf freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:8dB (DataRate:5603.79Baud)
2020-01-11 23:36:49 ccpatable C3E = 00 C0 00 00 00 00 00 00 => 10_dBm
2020-01-11 23:33:10 config MS=1;MU=1;MC=1;Mred=1
2020-01-11 23:37:12 freeram 939
2020-01-11 23:43:17 state opened
2020-01-11 23:36:14 uptime 0 00:49:34
2020-01-11 23:43:17 version V 3.3.1 SIGNALduino cc1101 (433 Mhz ) - compiled at Dec 3 2019 19:42:03
helper:
avrdudecmd avrdude -c arduino -b 57600 -P 192.168.2.54:23 -p atmega328p -vv -U flash:w:FHEM/firmware/SIGNALduino_nanoCC1101_3321rc9.hex 2>./log/SIGNALduino-Flash.log || avrdude -c arduino -b 57600 -P 192.168.2.54:23 -p atmega328p -vv -U flash:w:FHEM/firmware/SIGNALduino_nanoCC1101_3321rc9.hex 2>./log/SIGNALduino-Flash.log
avrdudelogs flashing Arduino sduino2
hex file: FHEM/firmware/SIGNALduino_nanoCC1101_3321rc9.hex
port: 192.168.2.54:23
command: avrdude -c arduino -b 57600 -P 192.168.2.54:23 -p atmega328p -vv -U flash:w:FHEM/firmware/SIGNALduino_nanoCC1101_3321rc9.hex 2>[LOGFILE] || avrdude -c arduino -b 57600 -P 192.168.2.54:23 -p atmega328p -vv -U flash:w:FHEM/firmware/SIGNALduino_nanoCC1101_3321rc9.hex 2>[LOGFILE]
sduino2 closed
--- AVRDUDE ---------------------------------------------------------------------------------
avrdude: Version 6.1, compiled on Jul 7 2015 at 10:29:47
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2014 Joerg Wunsch
System wide configuration file is "/etc/avrdude.conf"
Using Port : 192.168.2.54:23
Using Programmer : arduino
Overriding Baud Rate : 57600
avrdude: ser_open(): can't open device "192.168.2.54:23": No such file or directory
avrdude done. Thank you.
--- AVRDUDE ---------------------------------------------------------------------------------
sduino2 reopen started
keepalive:
ok 0
retry 0
mcIdList:
10
11
12
18
43
47
52
57
58
96
msIdList:
0
0.1
0.2
0.3
0.4
1
3
3.1
4
6
7
13
13.2
14
15
17
23
25
33
33.1
33.2
35
51
53
55
65
74.1
87
88
90
91.1
93
muIdList:
8
9
13.1
16
17.1
19
21
22
24
26
27
28
29
30
31
32
34
36
39
42
44
44.1
45
46
48
49
50
56
59
60
61
62
64
66
67
69
70
71
72
73
74
76
79
80
81
83
84
85
86
89
91
92
94
95
Attributes:
blacklist_IDs 41,40,37,38,68
flashCommand avrdude -c arduino -b 57600 -P [PORT] -p atmega328p -vv -U flash:w:[HEXFILE] 2>[LOGFILE]
Das hängt davon ab ob DTR (Reset) mit dem ESP8266 verbunden ist und ob die SW (z.B. ESPLink) richtig konfiguriert ist
https://forum.fhem.de/index.php/topic,69042.msg605241.html#msg605241
@Ralf
Du hast die KOPP_FC schon modifiziert, nehme ich an?
Schick mir die Datei mal zu. Ich teste das bei mir mit dem Signalduino und den Kopp Aktuatoren, wenn da alles klappt und es mit dem CUL auch noch funktioniert stelle ich das Online
Zitat von: Ralf9 am 11 Januar 2020, 23:58:35
Das hängt davon ab ob DTR (Reset) mit dem ESP8266 verbunden ist und ob die SW (z.B. ESPLink) richtig konfiguriert ist
https://forum.fhem.de/index.php/topic,69042.msg605241.html#msg605241
Da ist schonmal ein ESP8285 drauf, wer weiss, ob das eine Rolle spielt... Ich kann ja auf USB-Betrieb umstellen, da binde ich den so ein und flashe dann.
Zitat von: andies am 11 Januar 2020, 23:48:09
Hallo Ralf9,
kann ich denn meinen Cul (ich habe den von locutus) über http flashen? Mir sagte er
Ich habe gerade bemerkt, dass meine Frage zu unpräzise war. Ich habe die Firmware 3.3.1 drauf, will aber
Deine 3.3.2r benutzen. Nur dieser Vorgang ging nicht, der Rest ist anscheinend richtig eingestellt.
Zitatavrdude: ser_open(): can't open device "192.168.2.54:23": No such file or directory
diese Fehlermeldung kommt von avrdude, dies ist unabhängig von der firmware die Du flashen willst
hier gibts für den FSK Empfang eine neue Firmware für den nano- und minicul
https://forum.fhem.de/index.php/topic,82379.msg1010643.html#msg1010643
Da es wahrscheinlich noch länger dauern wird bis die dazu notwendigen Anpassungen im offiziellen Signalduino Modul sind,
sind hier zur Verwendung in einem Testsystem die notwendigen Anpassungen:
https://github.com/Ralf9/RFFHEM/issues/4
Gruß Ralf
Hallo zusammen,
kurzer Zwischen- bzw. Endstand zu meiner seit Februar 2018 schwelenden Baustelle "unbekannte Funkprotokolle":
Mein "unbekanntes" Funkprotokoll kommt aus einem HCS301. Somit ist es nunmehr ein bekanntes und lässt sich folglich (zunächst mal nur als Empfang) in das Modul SD_Keeloq einbauen.
Meinen Dank an alle Mitwirkenden für die Unterstützung in den letzten Jahren und insbesondere auch an @HomeAuto_User der letztendlich den Knoten gelöst hat.
VG Peter
@Ralf,
wie schaut eine korrekte Debugausgabe für den FIFO aus wenn man
Mode 1 - IT+ 17.241 kbps
empfangen möchte.
Ich versuche dahinter zu kommen wieso nicht empfangen wird oder sehr sporadisch wenn 3 Sensoren davon existent sind innerhalb Luftlinie 10 - 15m.
Meine Ausgabe
2020.01.13 14:26:05 4: nano_868Mhz/msg READ: RX(25) 49290E34285CA988714215CB012A7E4218FA13285C79A9213E (21) M13
2020.01.13 14:26:05 4: nano_868Mhz/msg READ: RX(24) 592F7B05320C5898FE20C1F153A774C247B02090D00C4802 (21) M13
2020.01.13 14:26:05 4: nano_868Mhz/msg READ: RX(25) 249D643F71F3354A7FC30444BA5982FAFC7F1A117603069AF0 (21) M13
2020.01.13 14:26:05 4: nano_868Mhz/msg READ: RX(25) 15C018EB52344DA4176FAC82012092C1BE99455990A01C3860 (21) M13
2020.01.13 14:26:05 4: nano_868Mhz/msg READ: RX(24) DCB44AD99D66B4804969D5A9C67C97D02394C9ECE7ADDC5A (21) M13
2020.01.13 14:26:05 4: nano_868Mhz/msg READ: RX(25) D94B03249D180FAAA227C4A8552C41221E9B4ED91F82378EB8 (21) M13
2020.01.13 14:26:05 4: nano_868Mhz/msg READ: RX(25) C202A9605AC78DC017F01D9E310C091089BE7A0A4A6A5AC777 (21) M13
2020.01.13 14:26:05 4: nano_868Mhz/msg READ: RX(24) C267868410C2E287381809C0EE33792CC4B48DD9864386C4 (21) M13
2020.01.13 14:26:05 4: nano_868Mhz/msg READ: RX(25) 231C052638A1B4063CB1EA1420809AEB4266221391B984798B (21) M13
2020.01.13 14:26:05 4: nano_868Mhz/msg READ: RX(25) 090FBB6C1B129A9501918249CA72BD84AA1D9E72C86B153AC4 (21) M13
2020.01.13 14:26:05 4: nano_868Mhz/msg READ: RX(24) 3C3B4E57522F33CB9A3A8154C59F4F1A315B0C199FF2941C (21) M13
2020.01.13 14:26:05 4: nano_868Mhz/msg READ: RX(25) 8F80B72DA54E0936D22C114006E3509FB180B380917C9F03F9 (21) M13
2020.01.13 14:26:05 4: nano_868Mhz/msg READ: RX(24) 08CC361A9130981489A64416D993302095168053AC90131F (21) M13
ccconf: freq:868.350MHz bWidth:203KHz rAmpl:36dB sens:8dB (DataRate:17257.69Baud, Modulation:2-FSK) SYNC_MODE:16/16 + carrier-sense above threshold
Thx
Zitatwie schaut eine korrekte Debugausgabe für den FIFO aus wenn man
Bei der hohen Datenrate von 17.241 kbps ist mir auch noch keine sinnvolle Debugausgabe gelungen.
Bei so einer hohen Datenrate kommen die Daten schneller in den FIFO als sie seriell mit 57600 ausgegeben werden können.
Verwendest Du ein 868MHz cc1101 Modul?
Ist evtl in der Nähe des cc1101 Moduls eine Störquelle?
ZitatIch versuche dahinter zu kommen wieso nicht empfangen wird oder sehr sporadisch wenn 3 Sensoren davon existent sind innerhalb Luftlinie 10 - 15m.
Sind bei den 10 - 15m Luftlinie auch Wände oder Decken dazwischen?
Bei meinem TX29DTH-IT ist mir aufgefallen, daß die Reichweite viel geringer ist als bei den 433MHz Sensoren.
Welche LaCrosse Sensoren verwendest Du?
Hi Ralf9, ich muss Dich nochmal belästigen. Ich habe den locutus signalduino-Stick und möchte aber mit Deiner Firmware arbeiten. Im USB Modus kann man den gut flashen
avrdude: Version 6.1, compiled on Jul 7 2015 at 10:29:47
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2014 Joerg Wunsch
System wide configuration file is "/etc/avrdude.conf"
Using Port : /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0
Using Programmer : arduino
Overriding Baud Rate : 57600
AVR Part : ATmega328P
Chip Erase delay : 9000 us
PAGEL : PD7
BS2 : PC2
RESET disposition : dedicated
RETRY pulse : SCK
serial program mode : yes
parallel program mode : yes
Timeout : 200
StabDelay : 100
CmdexeDelay : 25
SyncLoops : 32
ByteDelay : 0
PollIndex : 3
PollValue : 0x53
Memory Detail :
Block Poll Page Polled
Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
eeprom 65 20 4 0 no 1024 4 0 3600 3600 0xff 0xff
flash 65 6 128 0 yes 32768 128 256 4500 4500 0xff 0xff
lfuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
hfuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
efuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
lock 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
calibration 0 0 0 0 no 1 0 0 0 0 0x00 0x00
signature 0 0 0 0 no 3 0 0 0 0 0x00 0x00
Programmer Type : Arduino
Description : Arduino
Hardware Version: 3
Firmware Version: 6.2
Vtarget : 0.3 V
Varef : 0.3 V
Oscillator : 28.800 kHz
SCK period : 3.3 us
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.00s
avrdude: Device signature = 0x1e950f
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "FHEM/firmware/SIGNALduino_nanoCC1101_3321rc9.hex"
avrdude: input file FHEM/firmware/SIGNALduino_nanoCC1101_3321rc9.hex auto detected as Intel Hex
avrdude: writing flash (24984 bytes):
Writing | ################################################## | 100% 7.67s
avrdude: 24984 bytes of flash written
avrdude: verifying flash memory against FHEM/firmware/SIGNALduino_nanoCC1101_3321rc9.hex:
avrdude: load data flash data from input file FHEM/firmware/SIGNALduino_nanoCC1101_3321rc9.hex:
avrdude: input file FHEM/firmware/SIGNALduino_nanoCC1101_3321rc9.hex auto detected as Intel Hex
avrdude: input file FHEM/firmware/SIGNALduino_nanoCC1101_3321rc9.hex contains 24984 bytes
avrdude: reading on-chip flash data:
Reading | ################################################## | 100% 5.78s
avrdude: verifying ...
avrdude: 24984 bytes of flash verified
avrdude done. Thank you.
aber er schließt sich ständig von selbst und komisch erscheint mir, dass keine get-Befehle auf der Weboberfläche sichtbar sind. Weißt du, was da falsch ist?
Internals:
Clients :IT:CUL_TCM97001:SD_RSL:OREGON:CUL_TX:SD_AS:Hideki:SD_WS07:SD_WS09: :SD_WS:RFXX10REC:Dooya:SOMFY:SD_BELL:SD_UT:SD_WS_Maverick:FLAMINGO:CUL_WS:Revolt: :FS10:CUL_FHTTK:Siro:FHT:FS20:CUL_EM:Fernotron:SD_Keeloq:SIGNALduino_un:
DEF /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0@57600
DMSG s376FC260C000
DevState INACTIVE
DeviceName /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0@57600
FUUID 5e1a4c68-f33f-05b9-0472-e14bd9c0af2f47d2
IDsNoDispatch 2,72.1,82
LASTDMSG s376FC260C000
LASTDMSGID 0
MSGCNT 2
NAME sduino2
NR 266
RAWMSG MS;P0=-3946;P1=504;P2=-8896;P3=-1998;D=121212131310101310101013101013101010101010131313131013131010131313131310101313;CP=1;SP=2;R=251;m2;
RSSI -76.5
STATE closed
TIME 1579080822
TYPE SIGNALduino
hasCC1101 1
initResetFlag 1
initretry 3
sendworking 0
version
versionProtocols 1.10
versionmodul v3.4.1
DoubleMsgIDs:
MatchList:
10:SD_WS07 ^P7#[A-Fa-f0-9]{6}[AFaf][A-Fa-f0-9]{2,3}
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 ^P(?:14|29|30|34|46|68|69|76|81|83|86|90|91|91.1|92|93|95)#.*
18:FLAMINGO ^P13\.?1?#[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
25:CUL_EM ^E0.................
26:Fernotron ^P82#.*
27:SD_BELL ^P(?:15|32|41|42|57|79|96)#.*
28:SD_Keeloq ^P(?:87|88)#.*
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:
2020-01-12 15:28:23 ccconf freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:8dB (DataRate:5603.79Baud)
2020-01-15 10:30:29 ccpatable C3E = 00 C0 00 00 00 00 00 00 => 10_dBm
2020-01-12 15:42:00 config MS=1;MU=1;MC=1;Mred=1
2020-01-11 23:37:12 freeram 939
2020-01-13 09:04:40 ping OK
2020-01-15 10:38:06 state closed
2020-01-11 23:36:14 uptime 0 00:49:34
2020-01-15 10:29:49 version V 3.3.1 SIGNALduino cc1101 (433 Mhz ) - compiled at Dec 3 2019 19:42:03
helper:
avrdudecmd avrdude -c arduino -b 57600 -P /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0 -p atmega328p -v -v -U flash:w:FHEM/firmware/SIGNALduino_nanoCC1101_3321rc9.hex 2>./log/SIGNALduino-Flash.log || avrdude -c arduino -b 57600 -P /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0 -p atmega328p -v -v -U flash:w:FHEM/firmware/SIGNALduino_nanoCC1101_3321rc9.hex 2>./log/SIGNALduino-Flash.log
avrdudelogs flashing Arduino sduino2
hex file: FHEM/firmware/SIGNALduino_nanoCC1101_3321rc9.hex
port: /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0
command: avrdude -c arduino -b 57600 -P /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0 -p atmega328p -v -v -U flash:w:FHEM/firmware/SIGNALduino_nanoCC1101_3321rc9.hex 2>[LOGFILE] || avrdude -c arduino -b 57600 -P /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0 -p atmega328p -v -v -U flash:w:FHEM/firmware/SIGNALduino_nanoCC1101_3321rc9.hex 2>[LOGFILE]
sduino2 closed
--- AVRDUDE ---------------------------------------------------------------------------------
avrdude: Version 6.1, compiled on Jul 7 2015 at 10:29:47
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2014 Joerg Wunsch
System wide configuration file is "/etc/avrdude.conf"
Using Port : /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0
Using Programmer : arduino
Overriding Baud Rate : 57600
AVR Part : ATmega328P
Chip Erase delay : 9000 us
PAGEL : PD7
BS2 : PC2
RESET disposition : dedicated
RETRY pulse : SCK
serial program mode : yes
parallel program mode : yes
Timeout : 200
StabDelay : 100
CmdexeDelay : 25
SyncLoops : 32
ByteDelay : 0
PollIndex : 3
PollValue : 0x53
Memory Detail :
Block Poll Page Polled
Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
eeprom 65 20 4 0 no 1024 4 0 3600 3600 0xff 0xff
flash 65 6 128 0 yes 32768 128 256 4500 4500 0xff 0xff
lfuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
hfuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
efuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
lock 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
calibration 0 0 0 0 no 1 0 0 0 0 0x00 0x00
signature 0 0 0 0 no 3 0 0 0 0 0x00 0x00
Programmer Type : Arduino
Description : Arduino
Hardware Version: 3
Firmware Version: 6.2
Vtarget : 0.3 V
Varef : 0.3 V
Oscillator : 28.800 kHz
SCK period : 3.3 us
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.00s
avrdude: Device signature = 0x1e950f
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "FHEM/firmware/SIGNALduino_nanoCC1101_3321rc9.hex"
avrdude: input file FHEM/firmware/SIGNALduino_nanoCC1101_3321rc9.hex auto detected as Intel Hex
avrdude: writing flash (24984 bytes):
Writing | ################################################## | 100% 7.67s
avrdude: 24984 bytes of flash written
avrdude: verifying flash memory against FHEM/firmware/SIGNALduino_nanoCC1101_3321rc9.hex:
avrdude: load data flash data from input file FHEM/firmware/SIGNALduino_nanoCC1101_3321rc9.hex:
avrdude: input file FHEM/firmware/SIGNALduino_nanoCC1101_3321rc9.hex auto detected as Intel Hex
avrdude: input file FHEM/firmware/SIGNALduino_nanoCC1101_3321rc9.hex contains 24984 bytes
avrdude: reading on-chip flash data:
Reading | ################################################## | 100% 5.78s
avrdude: verifying ...
avrdude: 24984 bytes of flash verified
avrdude done. Thank you.
--- AVRDUDE ---------------------------------------------------------------------------------
sduino2 reopen started
keepalive:
ok 1
retry 0
mcIdList:
10
11
12
18
43
47
52
57
58
96
msIdList:
0
0.1
0.2
0.3
0.4
1
3
3.1
4
6
7
13
13.2
14
15
17
23
25
33
33.1
33.2
35
51
53
55
65
74.1
87
88
90
91.1
93
muIdList:
8
9
13.1
16
17.1
19
21
22
24
26
27
28
29
30
31
32
34
36
39
42
44
44.1
45
46
48
49
50
56
59
60
61
62
64
66
67
69
70
71
72
73
74
76
79
80
81
83
84
85
86
89
91
92
94
95
Attributes:
blacklist_IDs 41,40,37,38,68
flashCommand avrdude -c arduino -b 57600 -P [PORT] -p atmega328p -v -v -U flash:w:[HEXFILE] 2>[LOGFILE]
hardware nanoCC1101
updateChannelFW stable
Nachtrag: Beim Versuch, Dinge zu ändern, erhalte ich
sduino2 is not active, may firmware is not suppoted, please flash or reset
Ich habe noch einen zweiten Signaludino dran, der ist opened. Das hat doch nichts damit zu tun, oder?
Zitatavrdude: input file FHEM/firmware/SIGNALduino_nanoCC1101_3321rc9.hex auto detected as Intel Hex
Dies ist die firmware für den nano.
Es gibt auch eine für den minicul
set sduino flash https://github.com/Ralf9/SIGNALDuino/releases/download/3.3.2.1-rc9/SIGNALduino_miniCUL_3321rc9.hex
Zitat von: Ralf9 am 15 Januar 2020, 10:50:31
Dies ist die firmware für den nano.
Danke für die prompte Antwort, ist ja wie bei einem Großkonzern-Service: Klappt!
Hallo Ralf9, ich muss nochmal nachfragen. Hier stimmt bei mir was nicht. Ich habe den miniCUL in Betrieb:
Internals:
Clients :IT:CUL_TCM97001:SD_RSL:OREGON:CUL_TX:SD_AS:Hideki:SD_WS07:SD_WS09: :SD_WS:RFXX10REC:Dooya:SOMFY:SD_BELL:SD_UT:SD_WS_Maverick:FLAMINGO:CUL_WS:Revolt: :FS10:CUL_FHTTK:Siro:FHT:FS20:CUL_EM:Fernotron:SD_Keeloq:SIGNALduino_un:
DEF 192.168.2.54:23
DMSG YsAA828A3193ECA8
DevState initialized
DeviceName 192.168.2.54:23
FD 19
FUUID 5e1a4c68-f33f-05b9-0472-e14bd9c0af2f47d2
FVERSION 00_SIGNALduino.pm:0.207460/2019-12-14
IDsNoDispatch 2,72.1,82
LASTDMSG YsAA828A3193ECA8
LASTDMSGID 43
MSGCNT 3187
NAME sduino
NR 266
PARTIAL
RAWMSG MC;LL=-1269;LH=1304;SL=-638;SH=646;D=AA828A3193ECA8;C=642;L=54;R=227;s3;b3;
RSSI -88.5
STATE opened
TIME 1579248726
TYPE SIGNALduino
hasCC1101 1
sendworking 0
unknownmessages
version V 3.3.2.1-rc9 SIGNALduino cc1101 (minicul 433Mhz) - compiled at Jun 16 2019 18:50:20
versionProtocols 1.10
versionmodul v3.4.1
DoubleMsgIDs:
MatchList:
10:SD_WS07 ^P7#[A-Fa-f0-9]{6}[AFaf][A-Fa-f0-9]{2,3}
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 ^P(?:14|29|30|34|46|68|69|76|81|83|86|90|91|91.1|92|93|95)#.*
18:FLAMINGO ^P13\.?1?#[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
25:CUL_EM ^E0.................
26:Fernotron ^P82#.*
27:SD_BELL ^P(?:15|32|41|42|57|79|96)#.*
28:SD_Keeloq ^P(?:87|88)#.*
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:
2020-01-15 11:00:28 ccconf freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:4dB (DataRate:5603.79Baud)
2020-01-15 11:00:18 ccpatable C3E = 00 C0 00 00 00 00 00 00 => 10_dBm
2020-01-12 15:42:00 config MS=1;MU=1;MC=1;Mred=1
2020-01-11 23:37:12 freeram 939
2020-01-17 23:15:19 ping OK
2020-01-17 23:16:43 state opened
2020-01-17 23:15:36 uptime 2 11:33:54
2020-01-17 23:16:43 version V 3.3.2.1-rc9 SIGNALduino cc1101 (minicul 433Mhz) - compiled at Jun 16 2019 18:50:20
helper:
keepalive:
ok 0
retry 0
mcIdList:
10
11
12
18
43
47
52
57
58
96
msIdList:
0
0.1
0.2
0.3
0.4
1
3
3.1
4
6
7
13
13.2
14
15
17
23
25
33
33.1
33.2
35
51
53
55
65
74.1
87
88
90
91.1
93
muIdList:
8
9
13.1
16
17.1
19
21
22
24
26
27
28
29
30
31
32
34
36
39
42
44
44.1
45
46
48
49
50
56
59
60
61
62
64
66
67
69
70
71
72
73
74
76
79
80
81
83
84
85
86
89
91
92
94
95
Attributes:
blacklist_IDs 41,40,37,38,68
development 0
flashCommand avrdude -c arduino -b 57600 -P [PORT] -p atmega328p -v -v -U flash:w:[HEXFILE] 2>[LOGFILE]
und wenn ich ihn direkt anspreche, wird das Signal auch gesendet, zum Beispiel so:
{fhem("set sduino raw SR;;R=7;;P0=335;;P1=-665;;P2=-335;;P3=665;;P4=-15018;;D=01010102310101023101010234;;")}
Jedoch empfängt der miniCUL keine Daten aus meiner 433MHz-Station, schaltet keine Somfy-Rollos und kann auch keine Intertechno-Dosen schalten wie etwa diese hier:
Internals:
DEF 0FF00FF0FF 0F F0
FUUID 5c782b56-f33f-1115-0830-10aba2ba96527bc0
FVERSION 10_IT.pm:0.208390/2019-12-28
NAME Garagentor
NR 75
STATE Auf
TYPE IT
XMIT 0ff00ff0ff
XMITdimdown 00
XMITdimup 00
XMIToff f0
XMITon 0f
CODE:
1 0ff00ff0ff
READINGS:
2017-10-31 20:30:17 protocol V1
2020-01-17 18:05:46 state on
Attributes:
IODev sduino
ITclock 290
ITrepetition 10
devStateIcon .*:noIcon:noFhemwebLink
eventMap off:Zu on:Auf
Das Signal wurde 18:05 gesendet, der Schalter reagierte aber nicht.
Mit meinem selbst gebauten Signalduino ging das aber vorgestern noch. Analog bei den Somfy-Rollos. Ein Hardwareproblem schliesse ich auch aus, sonst würde der Befehl oben nicht gehen. Was kann das sein?
Bitte poste mal ein
get ccconf
get config
Zitat von: Ralf9 am 17 Januar 2020, 23:31:55
get ccconf
ergibt
ccconf: freq:433.920MHz bWidth:325KHz rAmpl:36dB sens:4dB (DataRate:5603.79Baud)und config
version: V 3.3.2.1-rc9 SIGNALduino cc1101 (minicul 433Mhz) - compiled at Jun 16 2019 18:50:20Mir fällt gerade auf, dass mein Log voll ist von
2020.01.18 07:41:47 1: 192.168.2.54:23 reappeared (sduino)
2020.01.18 07:42:44 1: 192.168.2.54:23 disconnected, waiting to reappear (sduino)
2020.01.18 07:42:45 1: sduino: DoInit, 192.168.2.54:23
2020.01.18 07:42:45 1: sduino: DoInit, 192.168.2.54:23
2020.01.18 07:42:45 1: 192.168.2.54:23 reappeared (sduino)
2020.01.18 07:43:44 1: 192.168.2.54:23 disconnected, waiting to reappear (sduino)
2020.01.18 07:43:44 1: sduino: DoInit, 192.168.2.54:23
2020.01.18 07:43:44 1: sduino: DoInit, 192.168.2.54:23
2020.01.18 07:43:44 1: 192.168.2.54:23 reappeared (sduino)
2020.01.18 07:44:44 1: 192.168.2.54:23 disconnected, waiting to reappear (sduino)
2020.01.18 07:44:44 1: sduino: DoInit, 192.168.2.54:23
2020.01.18 07:44:44 1: sduino: DoInit, 192.168.2.54:23
2020.01.18 07:44:44 1: 192.168.2.54:23 reappeared (sduino)
2020.01.18 07:45:43 1: 192.168.2.54:23 disconnected, waiting to reappear (sduino)
2020.01.18 07:45:43 1: sduino: DoInit, 192.168.2.54:23
2020.01.18 07:45:43 1: sduino: DoInit, 192.168.2.54:23
Welcher Prozessor ist auf Deimem miniCul?
ATmega328P?
Funktioniert es über USB, wenn Du ihn auf USB umjumperst?
Ich habe den Jumper Richtung USB gesetzt, den Stick eingesteckt
Jan 18 14:19:00 raspfhem kernel: [144053.905166] usb 1-1.4: new full-speed USB device number 4 using dwc_otg
Jan 18 14:19:00 raspfhem kernel: [144054.038288] usb 1-1.4: New USB device found, idVendor=1a86, idProduct=7523
Jan 18 14:19:00 raspfhem kernel: [144054.038302] usb 1-1.4: New USB device strings: Mfr=0, Product=2, SerialNumber=0
Jan 18 14:19:00 raspfhem kernel: [144054.038311] usb 1-1.4: Product: USB2.0-Serial
Jan 18 14:19:01 raspfhem kernel: [144055.219718] usbcore: registered new interface driver usbserial
Jan 18 14:19:01 raspfhem kernel: [144055.219782] usbcore: registered new interface driver usbserial_generic
Jan 18 14:19:01 raspfhem kernel: [144055.219846] usbserial: USB Serial support registered for generic
Jan 18 14:19:01 raspfhem kernel: [144055.222677] usbcore: registered new interface driver ch341
Jan 18 14:19:01 raspfhem kernel: [144055.222810] usbserial: USB Serial support registered for ch341-uart
Jan 18 14:19:01 raspfhem kernel: [144055.222941] ch341 1-1.4:1.0: ch341-uart converter detected
Jan 18 14:19:01 raspfhem kernel: [144055.226272] usb 1-1.4: ch341-uart converter now attached to ttyUSB0
und das Gerät wird geöffnet. getccconf ergibt
ccconf: freq:433.920MHz bWidth:325KHz rAmpl:36dB sens:4dB (DataRate:5603.79Baud)
und get config auf einmal
config: MS=1;MU=1;MC=1;Mred=1;Mdebug=1_MScnt=4;MuSplitThresh=8000;MdebFifoLimit=120/140
Heißt das, ich muss locutus fragen? Meines Wissens ist das ein ATM328P, so steht es in seinem ersten Post: https://forum.fhem.de/index.php/topic,42998.0.html (https://forum.fhem.de/index.php/topic,42998.0.html)
Ist auf dem ESP esplink drauf, evtl muss dort noch auf der console die Baudrate geändert werden
Ist drauf, ich habe nur jetzt keinen traffic wegen USB:
sollte eigentlich passen.
Funktioniert es über USB?
Ja, über USB empfange ich und kann auch senden. Nur der WLAN-"Anschluss" geht nicht.
evtl passt in den esplink Einstellungen was nicht.
Du kannst in der uc console mal die Baudrate auf einen anderen Wert und wieder zurück auf 57600 ändern
Werden in der console die emfangenen Nachrichten angezeigt.
In der Zeile console entry kannst Du auch Befehle zum sduino senden z.B. CG
Habe ich probiert, ohne Erfolg. Ich kann auch nicht an den Signalduino senden, wenn er im WLAN-Modus ist. Ich habe jetzt mal locutus angeschrieben und ihn gefragt; jedenfalls habe ich anscheinend keinen offensichtlichen Fehler gemacht. Mal sehen, ob er noch eine Idee hat.
In der mC-Konsole sehe ich keinerlei Nachrichten. Vielleicht probiere ich mal eine andere Firmware, rc8?
Hi,
welche Einstellungen hat den des ESP in Bezug auf die Pin Configuration?
Gruß Arnd
Signalduino (Nano, ESP, ...), CUL (Busware, Nano, Maple, ...), Homematic (HM-MOD-UART-RPI, ESP, Maple, ...), LaCrosseGateway (LGW, ESP, ...), 1-wire, ESPEasy, Bravia, Yamaha, ...
PINs sind so wie im Anhang. Ich habe jetzt mal sideys Firmware (3.3.1) draufgemacht, und da geht die WLAN--Variante (edit: kurzzeitig). Siehe Definition (die cconf, uptime, version etc sind alle aktualisiert):
Internals:
Clients :IT:CUL_TCM97001:SD_RSL:OREGON:CUL_TX:SD_AS:Hideki:SD_WS07:SD_WS09: :SD_WS:RFXX10REC:Dooya:SOMFY:SD_BELL:SD_UT:SD_WS_Maverick:FLAMINGO:CUL_WS:Revolt: :FS10:CUL_FHTTK:Siro:FHT:FS20:CUL_EM:Fernotron:SD_Keeloq:SIGNALduino_un:
DEF 192.168.2.54:23
DMSG s376FB9005000
DevState initialized
DeviceName 192.168.2.54:23
FD 38
FUUID 5e1a4c68-f33f-05b9-0472-e14bd9c0af2f47d2
FVERSION 00_SIGNALduino.pm:v3.4.1-s20746/2019-12-14
IDsNoDispatch 2,72.1,82
LASTDMSG s376FB9005000
LASTDMSGID 0.3
MSGCNT 3
NAME sduino
NR 265
PARTIAL
RAWMSG MS;P1=487;P2=-3973;P4=-8732;P5=-1982;D=14141414151512121512121215121215121212121215121212151512151515151515151515121512;CP=1;SP=4;R=248;m1;
RSSI -78
STATE opened
TIME 1579360818.35337
TYPE SIGNALduino
hasCC1101 1
sendworking 0
version V 3.3.1 SIGNALduino cc1101 (433 Mhz ) - compiled at Dec 3 2019 19:42:03
versionProtocols 1.10
versionmodul v3.4.1
DoubleMsgIDs:
MatchList:
10:SD_WS07 ^P7#[A-Fa-f0-9]{6}[AFaf][A-Fa-f0-9]{2,3}
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 ^P(?:14|29|30|34|46|68|69|76|81|83|86|90|91|91.1|92|93|95)#.*
18:FLAMINGO ^P13\.?1?#[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
25:CUL_EM ^E0.................
26:Fernotron ^P82#.*
27:SD_BELL ^P(?:15|32|41|42|57|79|96)#.*
28:SD_Keeloq ^P(?:87|88)#.*
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:
2020-01-18 16:19:53 ccconf freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:8dB (DataRate:5603.79Baud)
2020-01-18 16:20:11 ccpatable C3E = 00 84 00 00 00 00 00 00 => 5_dBm
2020-01-18 16:22:41 cmds V R t X S P C r W s x e
2020-01-18 16:19:59 config MS=1;MU=1;MC=1;Mred=1
2020-01-18 16:22:46 freeram 1010
2020-01-18 16:21:44 ping OK
2020-01-18 16:19:44 state opened
2020-01-18 16:22:52 uptime 0 00:02:18
2020-01-18 16:22:56 version V 3.3.1 SIGNALduino cc1101 (433 Mhz ) - compiled at Dec 3 2019 19:42:03
getcmd:
helper:
keepalive:
ok 1
retry 0
mcIdList:
10
11
12
18
43
47
52
57
58
96
msIdList:
0
0.1
0.2
0.3
0.4
1
3
3.1
4
6
7
13
13.2
14
15
17
23
25
33
33.1
33.2
35
51
53
55
65
74.1
87
88
90
91.1
93
muIdList:
8
9
13.1
16
17.1
19
21
22
24
26
27
28
29
30
31
32
34
36
39
42
44
44.1
45
46
48
49
50
56
59
60
61
62
64
66
67
69
70
71
72
73
74
76
79
80
81
83
84
85
86
89
91
92
94
95
Attributes:
blacklist_IDs 41,40,37,38,68
development 0
flashCommand avrdude -c arduino -b 57600 -P [PORT] -p atmega328p -v -v -U flash:w:[HEXFILE] 2>[LOGFILE]
group intern
hardware miniculCC1101
updateChannelFW stable
<edit> Wobei: Jetzt sehe ich trotz "openend" nur die set-Befehle, keine get-Befehle und er schließt sich automatisch. Ist das jetzt ein Hardware- oder ein Firmware-Problem?!
Hi,
ich dachte der Pull-Up muss an ;-)
Außerdem sind die Pins merkwürdig, oder?
Siehe:
https://forum.fhem.de/index.php/topic,42998.msg437065.html#msg437065
Gruß Arnd
Signalduino (Nano, ESP, ...), CUL (Busware, Nano, Maple, ...), Homematic (HM-MOD-UART-RPI, ESP, Maple, ...), LaCrosseGateway (LGW, ESP, ...), 1-wire, ESPEasy, Bravia, Yamaha, ...
Oh mann, da steht ja auch eine andere Baudrate drin. Also ich probiere mal und berichte. Je nach Post ändern sich die Dinge...
Das scheint zu klappen, allerdings auf einer anderen Baudrate. Ich beobachte mal, wie lange das Glück währt.
Danke!
Hallo Ralf9, irgendwie ist da der Wurm drin. Ich möchte auf dem locutus Stick Deine Firmware flashen (die von Sidey geht, aber da werden Wettermelder nicht erkannt). Also stecke ich den als USB hinein und bekomme
avrdude: Version 6.1, compiled on Jul 7 2015 at 10:29:47
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2014 Joerg Wunsch
System wide configuration file is "/etc/avrdude.conf"
Using Port : /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0
Using Programmer : arduino
Overriding Baud Rate : 57600
AVR Part : ATmega328P
Chip Erase delay : 9000 us
PAGEL : PD7
BS2 : PC2
RESET disposition : dedicated
RETRY pulse : SCK
serial program mode : yes
parallel program mode : yes
Timeout : 200
StabDelay : 100
CmdexeDelay : 25
SyncLoops : 32
ByteDelay : 0
PollIndex : 3
PollValue : 0x53
Memory Detail :
Block Poll Page Polled
Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
eeprom 65 20 4 0 no 1024 4 0 3600 3600 0xff 0xff
flash 65 6 128 0 yes 32768 128 256 4500 4500 0xff 0xff
lfuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
hfuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
efuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
lock 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
calibration 0 0 0 0 no 1 0 0 0 0 0x00 0x00
signature 0 0 0 0 no 3 0 0 0 0 0x00 0x00
Programmer Type : Arduino
Description : Arduino
Hardware Version: 3
Firmware Version: 6.2
Vtarget : 0.3 V
Varef : 0.3 V
Oscillator : 28.800 kHz
SCK period : 3.3 us
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.00s
avrdude: Device signature = 0x1e950f
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "FHEM/firmware/SIGNALduino_miniCUL_3321rc9.hex"
avrdude: input file FHEM/firmware/SIGNALduino_miniCUL_3321rc9.hex auto detected as Intel Hex
avrdude: writing flash (25042 bytes):
Writing | ################################################## | 100% 7.67s
avrdude: 25042 bytes of flash written
avrdude: verifying flash memory against FHEM/firmware/SIGNALduino_miniCUL_3321rc9.hex:
avrdude: load data flash data from input file FHEM/firmware/SIGNALduino_miniCUL_3321rc9.hex:
avrdude: input file FHEM/firmware/SIGNALduino_miniCUL_3321rc9.hex auto detected as Intel Hex
avrdude: input file FHEM/firmware/SIGNALduino_miniCUL_3321rc9.hex contains 25042 bytes
avrdude: reading on-chip flash data:
Reading | ################################################## | 100% 5.78s
avrdude: verifying ...
avrdude: 25042 bytes of flash verified
avrdude done. Thank you.
Rufe ich dann get version auf, erhalte ich nach einer Weile
version: V 3.3.2.1-rc9 SIGNALduino cc1101Jun 16 2019 18:50:20
Danach aber schließt sich der Stick wieder und ist auf closed?! Was mache ich da falsch?
In der Microcontroller Console des ESP sehe ich gar nichts, die ganze Zeit. Im Log steht
2020.01.20 19:55:06 1: sduino_via_USB: DoInit, /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0
2020.01.20 19:55:06 1: sduino_via_USB: DoInit, /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0
2020.01.20 19:55:06 1: /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0 reappeared (sduino_via_USB)
2020.01.20 19:55:38 1: sduino_via_USB: DoInit, /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0
2020.01.20 19:55:38 1: sduino_via_USB: DoInit, /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0
Empfangen wurde die ganze Zeit nichts:
LASTDMSG nothing
LASTDMSGID nothing
NAME sduino2
PS
Internals:
Clients :IT:CUL_TCM97001:SD_RSL:OREGON:CUL_TX:SD_AS:Hideki:SD_WS07:SD_WS09: :SD_WS:RFXX10REC:Dooya:SOMFY:SD_BELL:SD_UT:SD_WS_Maverick:FLAMINGO:CUL_WS:Revolt: :FS10:CUL_FHTTK:Siro:FHT:FS20:CUL_EM:Fernotron:SD_Keeloq:SIGNALduino_un:
DEF /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0
DMSG nothing
DevState waitInit
DeviceName /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0@57600
FD 20
FUUID 5e232f98-f33f-1115-62e9-3592cb22ca0454f7
FVERSION 00_SIGNALduino.pm:v3.4.1-s20746/2019-12-14
IDsNoDispatch 2,72.1,82
LASTDMSG nothing
LASTDMSGID nothing
NAME sduino2
NR 268
PARTIAL
STATE opened
TIME 1579546118.01408
TYPE SIGNALduino
hasCC1101 1
initretry 0
sendworking 0
version
versionProtocols 1.10
versionmodul v3.4.1
MatchList:
10:SD_WS07 ^P7#[A-Fa-f0-9]{6}[AFaf][A-Fa-f0-9]{2,3}
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 ^P(?:14|29|30|34|46|68|69|76|81|83|86|90|91|91.1|92|93|95)#.*
18:FLAMINGO ^P13\.?1?#[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
25:CUL_EM ^E0.................
26:Fernotron ^P82#.*
27:SD_BELL ^P(?:15|32|41|42|57|79|96)#.*
28:SD_Keeloq ^P(?:87|88)#.*
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:
2020-01-18 17:18:08 ccconf freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:8dB (DataRate:5603.79Baud)
2020-01-18 17:18:02 ccpatable C3E = 00 C0 00 00 00 00 00 00 => 10_dBm
2020-01-18 17:17:46 config MS=1;MU=1;MC=1;Mred=1
2020-01-20 19:58:31 state opened
2020-01-20 19:57:31 version V 3.3.2.1-rc9 SIGNALduino cc1101Jun 16 2019 18:50:20
getcmd:
cmd version
helper:
keepalive:
ok 0
retry 1
mcIdList:
10
11
12
18
43
47
52
57
58
96
msIdList:
0
0.1
0.2
0.3
0.4
1
3
3.1
4
6
7
13
13.2
14
15
17
23
25
33
33.1
33.2
35
51
53
55
65
74.1
87
88
90
91.1
93
muIdList:
8
9
13.1
16
17.1
19
21
22
24
26
27
28
29
30
31
32
34
36
39
42
44
44.1
45
46
48
49
50
56
59
60
61
62
64
66
67
69
70
71
72
73
74
76
79
80
81
83
84
85
86
89
91
92
94
95
Attributes:
blacklist_IDs 41,40,37,38,68
development 0
flashCommand avrdude -c arduino -b 57600 -P [PORT] -p atmega328p -v -v -U flash:w:[HEXFILE] 2>[LOGFILE]
group intern
hardware miniculCC1101
updateChannelFW stable
funktioniert er am USB?
Die Baudrate am esplink hast Du schon geändert?
Ja, am USB funktioniert er und die Baudrate hatte ich geändert. Ohne Ergebnis.
Ich hab momentan keine Idee an was dies liegen könnte.
Hast Du bei der firmware von Sidey schon mal versucht die bWidth zu erhöhen?
Nein, dann probiere ich das mal. Schade, ich mochte Deine Firmware, wäre irgendwie traurig, wenn das nicht geht.
Ich habe ja noch den alten Signalduino hier herumliegen, da kann ich doch eigentlich an Tx/Rx einene Wemos anschließen, den dann flashen und dann müsste das doch gehen, oder?
ja
https://forum.fhem.de/index.php/topic,69042.msg605241.html#msg605241
ich habe meine alternative firmware V 3.3.4.0 dev 200126 erweitert,
https://forum.fhem.de/index.php/topic,82379.msg1010643.html#msg1010643
https://github.com/Ralf9/SIGNALDuino/releases
Damit funktioniert der Empfang von LaCrosse Termperatursensoren, getestet habe ich bei mir den tx29 dth-it, für die Sensoren mit 2 Kanälen oder 2 Temperaturen sind noch Anpassungen notwendig.
Beim PCA 301 funktioniert bis jetzt nur der Empfang.
@RaspII
kannst Du bitte mal testen ob beim Kopp Modul in der Anlage von diesem Link das Schalten der Steckdosen funktioniert
https://forum.fhem.de/index.php/topic,106594.msg1017190.html#msg1017190
Gruß Ralf
Hallo Ralf,
Ich versuche, LaCrosse-Sensoren mit deiner Firmware auf einem nanoCC1101 zu empfangen. Alles läuft auf einen an sonsten leeren Test-FHEM-System auf dem neusten Stand. Der nano hat die letzte FW und deine modifizierte 00_SIGNALduino.pm ist auch in der aktuellen Version vorhanden.
Das Problem ist, dass ich zwar mit Verbose 5 sehe, das massenhaft LaCrosse-Nachrichten empfangen und als solche identifiziert werden, die Werte im Device aber nicht aktualisiert werden.
Autocreate hat nicht funktioniert (auch nach set LaCrossePairForSec), daher hab ich meine Devices per Hand angelegt. Teilweise haben sie auch einmal einen Wert erhalten, aber danach wurde nichts mehr aktualisiert.
Im Log habe ich dazu folgende Einträge gefunden.
Erste empfangene Nachricht des Device:
2020.01.29 11:46:35 4: mySignaldunio/msg READ: MN;D=96060831A6AAAA00003FCFFF;
2020.01.29 11:46:35 4: mySignaldunio Parse_MN: Found 2-FSK Protocol id 100 -> Lacrosse
2020.01.29 11:46:35 4: mySignaldunio LaCrosse_convert: ID=100, addr=24 temp=20.8, hum=49 bat=0 batInserted=0
2020.01.29 11:46:35 4: mySignaldunio ParseMN: ID=100 dmsg=OK 9 24 1 4 184 49
2020.01.29 11:46:35 5: mySignaldunio Dispatch: OK 9 24 1 4 184 49, test ungleich: disabled
2020.01.29 11:46:35 4: mySignaldunio Dispatch: OK 9 24 1 4 184 49, dispatch
2020.01.29 11:46:35 5: mySignaldunio: dispatch OK 9 24 1 4 184 49
2020.01.29 11:46:35 4: LaCrosse: Unknown device 18, please define it
Da per Autocreate nichts angelegt wurde, habe ich danach Device 18 per Hand angelegt:
Internals:
DEF 18 0.1 3
FUUID 5e3170f8-f33f-8cc9-9526-d47c54123c2f1efe
IODev mySignaldunio
LASTInputDev mySignaldunio
LaCrosse_lastRcv 2020-01-29 12:10:08
MSGCNT 1
NAME TL_Thermometer_AZAntje
NR 15
STATE T: 20.9 H: 52
TYPE LaCrosse
addr 18
battery_new 0
corr1 0.1
corr2 3
mySignaldunio_DMSG OK 9 24 1 4 184 49
mySignaldunio_MSGCNT 1
mySignaldunio_Protocol_ID 100
mySignaldunio_RAWMSG MN;D=96060831A6AAAA00005FD4FA;
mySignaldunio_TIME 2020-01-29 12:10:08
previousH 52
previousT 20.9
sensorType 0=T(H)
READINGS:
2020-01-29 12:10:08 battery ok
2020-01-29 12:10:08 humidity 52
2020-01-29 11:59:40 state T: 20.9 H: 52
2020-01-29 12:10:08 temperature 20.9
Attributes:
IODev mySignaldunio
room LaCrosse
Erfolgreiches Update:
2020.01.29 12:10:06 4: mySignaldunio/msg READ: MN;D=96060831A6AAAA00005FD4FA;
2020.01.29 12:10:06 4: mySignaldunio Parse_MN: Found 2-FSK Protocol id 100 -> Lacrosse
2020.01.29 12:10:06 4: mySignaldunio LaCrosse_convert: ID=100, addr=24 temp=20.8, hum=49 bat=0 batInserted=0
2020.01.29 12:10:06 4: mySignaldunio ParseMN: ID=100 dmsg=OK 9 24 1 4 184 49
2020.01.29 12:10:06 4: mySignaldunio Dispatch: OK 9 24 1 4 184 49, dispatch
Kein Update:
2020.01.29 13:41:57.667 4: mySignaldunio/msg READ: MN;D=9606083097AAAA00005FFFFF;
2020.01.29 13:41:57.673 4: mySignaldunio Parse_MN: Found 2-FSK Protocol id 100 -> Lacrosse
2020.01.29 13:41:57.675 4: mySignaldunio LaCrosse_convert: ID=100, addr=24 temp=20.8, hum=48 bat=0 batInserted=0
2020.01.29 13:41:57.676 4: mySignaldunio ParseMN: ID=100 dmsg=OK 9 24 1 4 184 48
2020.01.29 13:41:57.677 5: mySignaldunio Dispatch: OK 9 24 1 4 184 48, test ungleich: disabled
2020.01.29 13:41:57.678 4: mySignaldunio Dispatch: OK 9 24 1 4 184 48, dispatch
2020.01.29 13:41:57.680 5: mySignaldunio: dispatch OK 9 24 1 4 184 48
Hier ein List des Signaldunio:
Internals:
Clients :IT:CUL_TCM97001:SD_RSL:OREGON:CUL_TX:SD_AS:Hideki:SD_WS07:SD_WS09: :SD_WS:RFXX10REC:Dooya:SOMFY:SD_BELL:SD_UT:SD_WS_Maverick:FLAMINGO:CUL_WS:Revolt: :FS10:CUL_FHTTK:Siro:FHT:FS20:CUL_EM:Fernotron:SD_Keeloq:SD_GT:LaCrosse:KOPP_FC:PCA301:SIGNALduino_TOOL:SIGNALduino_un:
DEF /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0@57600
DMSG OK 9 21 1 4 203 47
DevState initialized
DeviceName /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0@57600
EQMSGCNT 0
FD 7
FUUID 5e3162cb-f33f-8cc9-5d1f-892d5366694eeb33
IDsNoDispatch 2,72.1,82,87,88
LASTDMSG OK 9 21 1 4 203 47
LASTDMSGID 100
MSGCNT 55099
NAME mySignaldunio
NR 14
PARTIAL
RAWMSG MN;D=9546272FD1AAAA00007EDFFF;
STATE opened
TIME 1580369320
TYPE SIGNALduino
ccconf b=0 freq:868.300MHz bWidth:203KHz rAmpl:33dB sens:8dB (DataRate:17257.69Baud) [boffs=0000]
ccconfFSK ccmode=3 sync=2DD4 Modulation:2-FSK (SYNC_MODE:16/16 + carrier-sense above threshold)
sendworking 0
unknownmessages
version V 3.3.4.0-dev200126 SIGNALduino cc1101 (b0) - compiled at Jan 28 2020 00:17:36
versionmodul v3.4.5-dev_ralf_27.01.
versionprotoL v3.4.5-dev_ralf_24.01.
DoubleMsgIDs:
MatchList:
10:SD_WS07 ^P7#[A-Fa-f0-9]{6}[AFaf][A-Fa-f0-9]{2}
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 ^P(?:14|20|26|29|30|34|46|68|69|76|81|83|86|90|91|91.1|92|93|95)#.*
18:FLAMINGO ^P13\.?1?#[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
25:CUL_EM ^E0.................
26:Fernotron ^P82#.*
27:SD_BELL ^P(?:15|32|41|42|57|79|96)#.*
28:SD_Keeloq ^P(?:87|88)#.*
29:SD_GT ^P49#[A-Fa-f0-9]+
2:CUL_TCM97001 ^s[A-Fa-f0-9]+
30:LaCrosse ^(\S+\s+9 |OK\sWS\s)
31:KOPP_FC ^kr..................
32:PCA301 ^\S+\s+24
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]+
90:SIGNALduino_TOOL ^pt([0-9]+(\.[0-9])?)(#.*)?
9:CUL_FHTTK ^T[A-F0-9]{8}
X:SIGNALduino_un ^[u]\d+#.*
QUEUE:
READINGS:
2020-01-30 07:26:45 ccconf freq:868.300MHz bWidth:203KHz rAmpl:33dB sens:8dB (DataRate:17257.69Baud)
Modulation:2-FSK (SYNC_MODE:16/16 + carrier-sense above threshold)
2020-01-29 11:22:57 cmds ?S ? b CE CD CG CS CW C eC e P r R S t T V W x XE XQ
2020-01-30 07:26:52 config ccmode=3
2020-01-30 07:15:59 ping OK
2020-01-29 11:25:04 raw ccFactoryReset done
2020-01-29 12:15:54 state opened
2020-01-29 10:52:04 version V 3.3.4.0-dev200126 SIGNALduino cc1101 (b0) - compiled at Jan 28 2020 00:17:36
getcmd:
keepalive:
ok 1
retry 0
mcIdList:
10
11
12
18
43
47
52
57
58
96
mnIdList:
100
101
102
msIdList:
0
0.1
0.2
0.3
0.4
0.5
1
3
3.1
4
6
7
13
13.2
14
15
17
20
23
25
32.1
33
33.1
33.2
35
41
49
51
53
55
65
68
74.1
90
91.1
93
muIdList:
8
9
13.1
16
17.1
19
21
22
24
26
27
28
29
30
32
34
36
37
38
39
40
42
44
44.1
45
46
48
49.1
49.2
50
56
59
60
61
62
64
66
67
69
70
71
72
73
74
79
80
81
83
84
85
86
89
91
92
94
95
Attributes:
debug 0
hardware nanoCC1101
updateChannelFW Ralf9
verbose 3
Gruß,
OppiM
Hallo OppiM,
werden die LaCrosse außer vom sduino auch noch parallel von einem Jeelink oder LaCrosse Gateway empfangen?
Du kannst mal testen ob es funktioniert, wenn Du in der "36_LaCrosse.pm"
bei der
sub LaCrosse_Initialize($)
diese Zeile auskommentierst
#$hash->{FingerprintFn} = "LaCrosse_Fingerprint";
danach ein fhem restart
Gruß Ralf
Hallo Ralf,
ja, mit der Änderung geht es.
Und ja, ein LGW empfängt die Daten ohne Probleme, allerdings auf dem produktivem FHEM, nicht in der Testumgebung.
Gruß,
OppiM
danke für das Testen.
https://forum.fhem.de/index.php/topic,107945.0.html
Hallo Ralf,
ich habe nach gefühlten Jahren es endlich geschafft, meinen Signalduino mit Deiner Firmware zu bestücken und ihn nicht via USB, sondern mit ESP-Wlan einzubinden. Mich störte der Raspberry im Jalousienkasten, der ESP stört mit weniger, der ist robuster.
Jetzt kommt es aber manchmal vor, dass der Signalduino anscheinend ,,schläft", jedenfalls reagiert in seltenen Fällen die Jalousie nicht auf meinen Befehl sie abzusenken (Somfy). Da ich exakt die gleichen Bauteile genommen und nur die serielle Schnittstelle erweitert habe, denke ich, es ist das WLAN.
Du hast doch da einen Ping-Befehl implementiert. Der öffnet aber ein Popup. Wie kann ich denn denn alle X Minuten auslösen - oder hast du eine bessere Idee?
Das Signalduino Fhem Modul sendet ein Ping, wenn es länger als 1 Minute nichts empfängt, kommt keine Antwort, wird was ins log geschrieben.
Wenn er anscheinend ,,schläft", empfängt er dann noch was?
Was macht das uptime, es darf sich nicht zurücksetzen
uptime ist unproblematisch:
uptime 7 01:36:18
und im log steht nur
2020.02.22 22:29:20 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/00_SIGNALduino.pm line 910.
2020.02.22 22:29:20 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/00_SIGNALduino.pm line 911.
Ständiger Empfang von Sensoren ist da!
Gesendet von iPad mit Tapatalk Pro
Nach dem Senden muss der gesendete Befehl wieder empfangen werden, dies sieht ungefähr so aus:
2020.02.22 23:36:29.175 4 : SOMFY_sendCommand: SOMFY_12389A -> cmd :on:
2020.02.22 23:36:29.175 4 : sduinoE/set: sending via SendMsg: SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=645;D=ABEDEDD64C7466;F=10AB85550A;
2020.02.22 23:36:29.286 4 : sduinoE SendrawFromQueue: msg=SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=645;D=ABEDEDD64C7466;F=10AB85550A;
2020.02.22 23:36:30.005 4 : sduinoE/msg READ: SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=645;D=ABEDEDD64C7466;F=10AB85550A;ccreg write back 10B07157C4
2020.02.22 23:36:30.005 3 : sduinoE/noMsg Parse: SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=645;D=ABEDEDD64C7466;F=10AB85550A;ccreg write back 10B07157C4
2020.02.22 23:36:30.005 4 : sduinoE/read sendraw answer: SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=645;D=ABEDEDD64C7466;F=10AB85550A;ccreg write back 10B07157C4
Wie sieht das log aus, wenn das senden nicht funktioniert?
Leider habe ich Pech/Glück: das scheint nicht immer schief zu gehen. Heute ging alles, ich muss wohl weiter beobachten
2020.02.23 08:42:45 5: sduino: Write, sending via Set sendMsg P43#A58A8C79777777#R6
2020.02.23 08:42:45 5: sduino: Set, sendmsg msg=P43#A58A8C79777777#R6
2020.02.23 08:42:45 5: sduino: Set, sendmsg Preparing manchester protocol=43, repeats=0, clock=645 data=A58A8C79777777
2020.02.23 08:42:45 5: sduino: AddSendQueue, sduino: SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=645;D=A58A8C79777777;F=10AB85550A; (1)
2020.02.23 08:42:45 4: sduino: Set, sending via SendMsg: SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=645;D=A58A8C79777777;F=10AB85550A;
2020.02.23 08:42:45 5: sduino: SimpleWrite, SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=645;D=A58A8C79777777;F=10AB85550A;
2020.02.23 08:42:45 4: sduino: SendFromQueue, msg=SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=645;D=A58A8C79777777;F=10AB85550A;
Ich habe nur Sorge, dass der rolling code aus dem Tritt kommt und ich neu einrichten muss.
Gesendet von iPad mit Tapatalk Pro
In Deinem log Auszug fehlt die Antwort vom Sendebefehl, müsste ungefähr so aussehen:
2020.02.22 23:36:30.005 4 : sduino/msg READ: SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=645;D=ABEDEDD64C7466;F=10AB85550A;ccreg write back 10B07157C4
2020.02.22 23:36:30.005 3 : sduino/noMsg Parse: SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=645;D=ABEDEDD64C7466;F=10AB85550A;ccreg write back 10B07157C4
Dann kopiere ich mal auch die Umgebung mit:
2020.02.23 08:42:45 5: sduino: Write, sending via Set sendMsg P43#A58A8C79777777#R6
2020.02.23 08:42:45 5: sduino: Set, sendmsg msg=P43#A58A8C79777777#R6
2020.02.23 08:42:45 5: sduino: Set, sendmsg Preparing manchester protocol=43, repeats=0, clock=645 data=A58A8C79777777
2020.02.23 08:42:45 5: sduino: AddSendQueue, sduino: SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=645;D=A58A8C79777777;F=10AB85550A; (1)
2020.02.23 08:42:45 4: sduino: Set, sending via SendMsg: SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=645;D=A58A8C79777777;F=10AB85550A;
2020.02.23 08:42:45 5: sduino: SimpleWrite, SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=645;D=A58A8C79777777;F=10AB85550A;
2020.02.23 08:42:45 4: sduino: SendFromQueue, msg=SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=645;D=A58A8C79777777;F=10AB85550A;
2020.02.23 08:42:46 4: sduino: Read, msg: SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=645;D=A58A8C79777777;F=10AB85550A;ccreg write back 10B07157C4
2020.02.23 08:42:46 5: sduino: Parse, noMsg: SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=645;D=A58A8C79777777;F=10AB85550A;ccreg write back 10B07157C4
2020.02.23 08:42:46 5: sduino: Read, msg: regexp=^S(?:R|C|M);. cmd=sendraw msg=SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=645;D=A58A8C79777777;F=10AB85550A;ccreg write back 10B07157C4
2020.02.23 08:42:46 4: sduino: Read, sendraw answer: SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=645;D=A58A8C79777777;F=10AB85550A;ccreg write back 10B07157C4
2020.02.23 08:42:46 4: sduino: HandleWriteQueue, nothing to send, stopping timer
2020.02.23 08:42:51 5: sduino: Read, RAW rmsg: Mu;���;��;��;���;�և;C1;R14;D!111111!11A1A1AAA11A1AAAAAAAAAAAA11AAAAA1A1A!!!!11A1A1AAA11A111AAAAAAAAA111AAAAAA111!!!!11A1A1AAA11A1AAAAAAAAAAAA11AAAAA1A1A!!;O;
2020.02.23 08:42:51 4: sduino: Read, msg READredu: MU;P0=-1440;P1=487;P2=-8940;P3=-3984;P4=-2006;CP=1;R=20;D=01213131313131312131314131413141414131314131414141414141414141414141313141414141413141314121212121313141314131414141313141313131414141414141414141313131414141414141313131212121213131413141314141413131413141414141414141414141414131314141414141314131412121;O;
2020.02.23 08:42:51 5: sduino: Parse_MU, start pattern for MU Protocol id 13.1 -> FLAMINGO FA22RF / FA21RF / LM-101LD not found, aborting
2020.02.23 08:42:51 5: sduino: Parse_MU, start pattern for MU Protocol id 16 -> Dooya not found, aborting
Ist der hier dabei? Ist das "ccreg write back 10B07157C4"?
ja, dies ist die Antwort
2020.02.23 08:42:46 4: sduino: Read, msg: SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=645;D=A58A8C79777777;F=10AB85550A;ccreg write back 10B07157C4
2020.02.23 08:42:46 5: sduino: Parse, noMsg: SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=645;D=A58A8C79777777;F=10AB85550A;ccreg write back 10B07157C4
2020.02.23 08:42:46 5: sduino: Read, msg: regexp=^S(?:R|C|M);. cmd=sendraw msg=SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=645;D=A58A8C79777777;F=10AB85550A;ccreg write back 10B07157C4
2020.02.23 08:42:46 4: sduino: Read, sendraw answer: SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=645;D=A58A8C79777777;F=10AB85550A;ccreg write back 10B07157C4
Zitat von: Ralf9 am 22 Februar 2020, 23:51:21
Wie sieht das log aus, wenn das senden nicht funktioniert?
Jetzt habe ich ein Log, wenn es nicht funktioniert. Das ist immer morgens, der allererste Versuch, die Rolladen hochzufahren:
2020.02.25 06:34:03 5: sduino: Write, sending via Set sendMsg P43#AA858379777777#R6
2020.02.25 06:34:03 5: sduino: Set, sendmsg msg=P43#AA858379777777#R6
2020.02.25 06:34:03 5: sduino: Set, sendmsg Preparing manchester protocol=43, repeats=0, clock=645 data=AA858379777777
2020.02.25 06:34:03 5: sduino: AddSendQueue, sduino: SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=645;D=AA858379777777;F=10AB85550A; (1)
2020.02.25 06:34:03 4: sduino: Set, sending via SendMsg: SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=645;D=AA858379777777;F=10AB85550A;
2020.02.25 06:34:03 5: sduino: SimpleWrite, SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=645;D=AA858379777777;F=10AB85550A;
2020.02.25 06:34:03 4: sduino: SendFromQueue, msg=SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=645;D=AA858379777777;F=10AB85550A;
2020.02.25 06:34:03 4: sduino: Read, msg: Unsupported command
2020.02.25 06:34:03 5: sduino: Parse, noMsg: Unsupported command
2020.02.25 06:34:03 4: sduino: Read, msg: Received answer (Unsupported command) for sendraw does not match ^S(?:R|C|M);.
2020.02.25 06:34:05 4: sduino: HandleWriteQueue, sendraw no answer (timeout)
2020.02.25 06:34:05 4: sduino: HandleWriteQueue, nothing to send, stopping timerAb dem zweiten Versuch (selbe "Taste") klappt alles, auch mit anderen Rolladen:
2020.02.25 06:36:27 5: sduino: Write, sending via Set sendMsg P43#AB848279777777#R6
2020.02.25 06:36:27 5: sduino: Set, sendmsg msg=P43#AB848279777777#R6
2020.02.25 06:36:27 5: sduino: Set, sendmsg Preparing manchester protocol=43, repeats=0, clock=645 data=AB848279777777
2020.02.25 06:36:27 5: sduino: AddSendQueue, sduino: SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=645;D=AB848279777777;F=10AB85550A; (1)
2020.02.25 06:36:27 4: sduino: Set, sending via SendMsg: SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=645;D=AB848279777777;F=10AB85550A;
2020.02.25 06:36:27 5: sduino: SimpleWrite, SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=645;D=AB848279777777;F=10AB85550A;
2020.02.25 06:36:27 4: sduino: SendFromQueue, msg=SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=645;D=AB848279777777;F=10AB85550A;
2020.02.25 06:36:28 4: sduino: Read, msg: SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=645;D=AB848279777777;F=10AB85550A;ccreg write back 10B07157C4
2020.02.25 06:36:28 5: sduino: Parse, noMsg: SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=645;D=AB848279777777;F=10AB85550A;ccreg write back 10B07157C4
2020.02.25 06:36:28 5: sduino: Read, msg: regexp=^S(?:R|C|M);. cmd=sendraw msg=SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=645;D=AB848279777777;F=10AB85550A;ccreg write back 10B07157C4
2020.02.25 06:36:28 4: sduino: Read, sendraw answer: SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=645;D=AB848279777777;F=10AB85550A;ccreg write back 10B07157C4
2020.02.25 06:36:28 4: sduino: HandleWriteQueue, nothing to send, stopping timer
Bitte mach mal ein get (z.B. version oder ccconf) vor dem allerersten Versuch, die Rolladen hochzufahren
Ich werde das hier hineinschreiben und notiere erst mal die Angaben, wenn die Sache funktioniert:
ccconf: freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:4dB (DataRate:5603.79Baud)
sowie
version: V 3.3.2.1-rc8 SIGNALduino cc1101 - compiled at Jan 10 2019 20:13:56
Die Werte die zurückkommen sind nicht so wichtig.
Mich interessiert ob der allererste Versuch, die Rolladen hochzufahren funktioniert, wenn Du davor irgendein Befehl sendest.
Verstanden: und es ist genau so. Der erste Versuch eines ,,get version" liefert nichts, erst beim zweiten Mal kommt die Rückantwort (und dann fährt auch die Jalousie sofort hoch).
Gesendet von iPad mit Tapatalk Pro
Du kannst auch mal versuchen, ob es auch reicht wenn Du vor dem ersten Versuch, die Rolladen hochzufahren, auf die IP des ESP einen Ping sendest.
Ich brauche mehrere Pings, damit der aufwacht:
ping 192.168.2.47
PING 192.168.2.47 (192.168.2.47): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
ping: sendto: No route to host
Request timeout for icmp_seq 4
Request timeout for icmp_seq 5
64 bytes from 192.168.2.47: icmp_seq=6 ttl=255 time=5.040 ms
64 bytes from 192.168.2.47: icmp_seq=7 ttl=255 time=113.543 ms
64 bytes from 192.168.2.47: icmp_seq=8 ttl=255 time=25.457 ms
64 bytes from 192.168.2.47: icmp_seq=9 ttl=255 time=44.852 ms
Wie gehe ich damit am geschicktesten um? Pings am morgen? Regelmäßige Pings?
<edit> wohl am besten
defmod sduino_ping PRESENCE lan-ping 192.168.2.47 300
<edit3> Mit diesem Code kann ich dann Probleme anzeigen lassen
attr <somfy device> stateFormat {('<img src="/fhem/www/images/default/10px-kreis-'.(ReadingsVal("sduino_ping","state","absent") eq "absent" ? "rot":"gruen").'.png">')}
Grüner Punkt= alles ok, roter Punkt=Probleme.
Hmm, Ralf9, ich brauche wohl noch einmal einen Tipp von Dir. Ich habe jetzt pingCount=7 eingestellt, weil auch =6 nicht reichte und er manchmal nicht aufwachte. Meinst du, dass pings genügen? Immerhin empfängt der sduino ja die ganze Zeit Signale aus den Thermometern und dem Windmesser um die Ecke, ich verstehe nicht ganz, wieso der überhaupt schläft. Eine Variante wäre auch, alle 5 Minuten oder so fake Schaltsignale zu senden (also von Schaltern, die ich gar nicht im Haus habe - schön, wenn der Nachbar dann zufällig so eines hat 8) )? Ich kapiere nicht ganz, was hier genau beim ESP abläuft; es muss ja an diesem ESP liegen, denn nur den habe ich hinzugelötet.
ZitatMeinst du, dass pings genügen?
Wenn es mit pings auch funktioniert, müsste es genügen.
Eine Variante wäre auch ein "get sduino ping".
ZitatImmerhin empfängt der sduino ja die ganze Zeit Signale aus den Thermometern und dem Windmesser um die Ecke, ich verstehe nicht ganz, wieso der überhaupt schläft.
Es gibt beim Signalduino Modul zwar eine Keepalive Routine, die überwacht aber nur den Empfang und sendet ein ping falls eine Minute nichts empfangen wird.
Warum es bei Dir ab und zu vorkommt, daß die Senderichtung nicht mehr funktioniert obwohl noch was empfangen wird, da kann ich Dir leider nicht weiterhelfen
Irgendwas scheint bei Dir mit dem ESP und dem WLAN nicht zu passen. Seltsam ist auch, daß dies nur morgens bei ersten Schalten passiert
Gruß Ralf
Zitat von: Ralf9 am 02 März 2020, 22:41:57
get sduino ping
Ist es ein Problem, wenn ich das über ein at erledigen lasse? Normalerweise kommt ja da ein popup. Kann das unterdrückt werden? Und ist dieser Befehl identisch zu einem lan-ping?
Heute morgen übrigens wieder: ich musste zweimal pingen. Könnte sein, dass die ESP nicht die besten sind.
Zitat von: andies am 03 März 2020, 05:43:36
Heute morgen übrigens wieder: ich musste zweimal pingen. Könnte sein, dass die ESP nicht die besten sind.
Hallo,
ich habe gelesen du hast nicht die aktuelle Firmware. Teste bitte die aktuell v3.4 für den ESP entwickelte Version und wiederhole den Vorgang.
Ist das Verhalten reproduzierbar auch mit anderen Protokollen?
Lg
Gesendet von iPhone mit Tapatalk Pro
ZitatIst es ein Problem, wenn ich das über ein at erledigen lasse? Normalerweise kommt ja da ein popup. Kann das unterdrückt werden? Und ist dieser Befehl identisch zu einem lan-ping?
Das popup sollte eigentlich nur kommen, wenn das get über das fhemweb ausgeführt wird. Dieses ping sendet an den sduino ein P und es kommt ein "ok" zurück.
Das lan-ping ist auf Betriebssystem Ebene
Zitat von: HomeAuto_User am 03 März 2020, 08:23:36
Teste bitte die aktuell v3.4 für den ESP entwickelte Version und wiederhole den Vorgang.
Ich kann leider den SignalESP nicht nehmen, weil somfy nicht damit steuerbar ist. Daher kann ich das damit nicht testen (bzw will das nicht).
Zitat von: HomeAuto_User am 03 März 2020, 08:23:36
Ist das Verhalten reproduzierbar auch mit anderen Protokollen?
Ja, ich konnte weder Somfy ansteuern noch ein Gartentor öffnen.
Inzwischen habe ich das Problem mit dem Vorschlag von Ralf9 im Griff. Alle halbe Stunde sende ich ein "get sduino ping" und damit bleibt er wach und sendet auf Anhieb.
Hallo,
ohne den Faden alles gelesen zu haben, wieso geht nicht die aktuelle ESP Version mit deiner Hardware?
Dann musst du mit einer nicht supporten ESP Version vorlieb nehmen.
Deine derzeitiges Workaround ist aber sehr ungewöhnlich. Interessant wäre, ob du das Verhalten auch reproduzieren kannst mit anderen Protokollen. Was wäre ein Indiz das du das Verhalten auch bei anderen Protokollen erkennst?
Mfg
Gesendet von iPhone mit Tapatalk Pro
Zitat von: HomeAuto_User am 05 März 2020, 19:47:08
ohne den Faden alles gelesen zu haben, wieso geht nicht die aktuelle ESP Version mit deiner Hardware?
Leider erinnere ich das im Detail nicht mehr. Es gab ein Problem mit der Version 3.3, aber ich weiß nicht mehr, ob das ein Regen- oder ein Windmesser war (oder was ganz anderes), was ich nicht empfangen konnte. Ich habe dann Ralfs Variante genommen - ich müsste in einem Thread nachschauen, wo ich länger mit ihm über mein Problem diskutiert hatte.
Zitat von: HomeAuto_User am 05 März 2020, 19:47:08
Interessant wäre, ob du das Verhalten auch reproduzieren kannst mit anderen Protokollen. Was wäre ein Indiz das du das Verhalten auch bei anderen Protokollen erkennst?
Also es ist so, dass alle Sendebefehle nicht auf Anhieb funktionieren. Erst, wenn ich einmal (umsonst) gesendet habe - und zwar egal, was ich da nun sende - kann ich danach den sduino verwenden. Aber wie gesagt: Mit der ping-Lösung habe ich das Problem im Griff.
Zitat von: andies am 05 März 2020, 20:01:08
Leider erinnere ich das im Detail nicht mehr. Es gab ein Problem mit der Version 3.3, aber ich weiß nicht mehr, ob das ein Regen- oder ein Windmesser war (oder was ganz anderes), was ich nicht empfangen konnte. Ich habe dann Ralfs Variante genommen - ich müsste in einem Thread nachschauen, wo ich länger mit ihm über mein Problem diskutiert hatte.
Also es ist so, dass alle Sendebefehle nicht auf Anhieb funktionieren. Erst, wenn ich einmal (umsonst) gesendet habe - und zwar egal, was ich da nun sende - kann ich danach den sduino verwenden. Aber wie gesagt: Mit der ping-Lösung habe ich das Problem im Griff.
Wenn du die Zeit findest, es wäre sehr interessant zu wissen, was der Fehler damals war um ihn ggf in der offiziellen Version zu beleuchten.
Nicht richtig senden, woran machst du die Aussage fest? Ist es nur ein ,,nicht richtig ankommen" des Signales oder sendet der ESP eine Signalfolge bewusst anders? Hattest du mal verbose 4 oder 5 aktiv beim ersten senden? Man könnte den Fall ggf mit einem festen Sendestring mal testen. Mir geht es hauptsächlich darum, den Fehler auch extern reproduzieren zu können.
Gesendet von iPhone mit Tapatalk Pro
Hier ist ein konkretes Beispiel mit ausführlichen Logs, wo das senden fehlschlug: https://forum.fhem.de/index.php/topic,82379.msg1026983.html#msg1026983
Im Gegensatz zu früher hatte ich nur an die serielle Schnittstelle einen ESP gelötet. Vorher war die Anbindung via USB, danach via ESP-WLAN. Von daher denke ich, dass das kein Signalduino-Problem, sondern eher ein WLAN-Problem (zB hohe Latenz o.ä.) ist. Aber ,,rekonstrierbar" in anderer Umgebung wäre natürlich mal interessant.
Der SIGNALduino war mein (vor drei Jahren?) zusammengelötetes, erstes FHEM-IO-Teil. Das sieht, wenn man es heute anschaut, ziemlich scheusslich aus. Daher habe ich eine eigene Platine entworfen und umgesetzt, deren Details ich hier mal anzeigen will. Ich muss bei meiner Platine mehrere Einschränkungen machen:
- Mir ging es in erster Linie darum, den SIGNALduino mit WLAN und nicht wie früher einem eigenen Raspberry in FHEM zu bringen. Ich wollte also keinen Platz für andere Sensoren etc vorsehen.
- Ich habe mich auch an den Teilen orientiert, die ich hatte. Beispielsweise besaß ich ein Micro-USB-Anschluss vom Nextion, den ich verbauen wollte (sieht man auf dem Foto). Damit andere die Platine aber auch nutzen können, habe ich für die Stromversorgung noch eine Schraubklemme angelötet.
- Ich wollte alle ICs auf Buchsenleisten anbringen, nicht aber anlöten. Ich musste früher so ein Teil mal auslöten und es war die Hölle.
Im Anhang habe ich die Gerber- und die Fritzing-Dateien dafür, das Gerät läuft bei mir. Ihr seht auch Fotos einmal der nackten Platine und einmal mit den Buchsenleisten und Widerständen. Und diejenigen, die das nachbauen wollen, wird wahrscheinlich die folgende Stückliste von reichelt helfen:
ZitatAnz. Reichelt-Nr. Beschreibung
1 K-O RD18JN331T52 Widerstand, Kohleschicht, 330 Ohm, 0204, 0,125 W, 5%
3 K-O RD18JN471T52 Widerstand, Kohleschicht, 470 Ohm, 0204, 0,125 W, 5%
3 K-O RD18JN102T52 Widerstand, Kohleschicht, 1,0 kOhm, 0204, 0,125 W, 5%
2 K-O RD14JN152T52 Widerstand, Kohleschicht, 1,5 kOhm, 0207, 250 mW, 5%
1 K-O RD18JN222T52 Widerstand, Kohleschicht, 2,2 kOhm, 0204, 0,125 W, 5%
2 K-O RD18JN103T52 Widerstand, Kohleschicht, 10 kOhm, 0204, 0,125 W, 5%
1 LM 1117 T3,3 LDO-Regler, fest, 3,3 V, TO-220
1 GA-A 10U 35-2 Elko, radial, 10 µF, 35 V, RM 2,5, 105°C, 1000 h, 20%
1 RND 205-00232 Lötbare Schraubklemme - 2-pol, RM 5,08 mm, 90°
1 LED 3MM BL LED, 3 mm, bedrahtet, blau, 800 mcd, 60°
1 MPE 094-2-008 Buchsenleisten 2,54 mm, 2X04, gerade
1 MPE 094-2-010 Buchsenleisten 2,54 mm, 2X05, gerade
2 MPE 094-1-016 Buchsenleisten 2,54 mm, 1X16, gerade
Ich habe noch acht Platinen, die ich jeweils für 2€ plus Versand anbiete. Ich habe gerade nachgewogen, das geht bei einer Platine noch mit dem Minimalpreis 0,80€. Ich schreibe das auch in den Verkaufsthread (https://forum.fhem.de/index.php/topic,109351.msg1033375.html#msg1033375 (https://forum.fhem.de/index.php/topic,109351.msg1033375.html#msg1033375)), bitte mit PM.
<edit> reichelt hat nur eine 16polige Buchsenleiste, der arduino benötigt aber eine 15polige. Daher ragt meine Leiste etwas über die vorgesehenen Löcher hinaus (also die Platine hat keine 16, sondern wirklich nur 15 Anschlüsse). Ich habe zwei Anschlüsse abgeknipst und fertig.
Hat du mal nen Schaltplan dazu?
Gesendet von meinem MI 9 mit Tapatalk
Jein, ich kann so was nicht richtig. Ich habe die Schaltung aus dem Wiki genommen (also die "übliche" in https://wiki.fhem.de/wiki/Selbstbau_CUL (https://wiki.fhem.de/wiki/Selbstbau_CUL)) und dann an den arduino bei Tx/Rx mit einem Spannungsteiler den ESP01 angeschlossen. So, wie in der von mir gerade umgeschriebenen Wiki-Grafik angedeutet.
Was hast du auf den esp 01 geflasht?
Gesendet von meinem MI 9 mit Tapatalk
ESP-Link, siehe https://forum.fhem.de/index.php/topic,82379.msg1014477.html#msg1014477 (https://forum.fhem.de/index.php/topic,82379.msg1014477.html#msg1014477)
Zitat von: sash.sc am 21 März 2020, 12:21:47
Hat du mal nen Schaltplan dazu?
Der ist doch in der fzz Datei mit drin. Könnte man ggf. etwas übersichtlicher/schöner Zeichnen, aber da ist alles vorhanden ;).
Gruß Peter
Ein Detail ist in der Fritzing-Datei noch wichtig, das betrifft den Spannungsregler. Da gibt es mehrere mögliche Varianten, die sich in der Reihenfolge der Pins unterscheiden: Mal ist Gnd links, mal in der Mitte, mal rechts. Ich wollte eine reichelt-Einkaufsliste erstellen und wollte daher das oben angegebene Bauteil (LM 1117) verwenden. In Fritzing war aber nur eine andere Variante verfügbar, die wiederum eine Pin-Reihenfolge hatte, die mit diesem LM 1117 nicht übereinstimmt.
Das Problem habe ich dann durch eine explizite Beschriftung auf der Platine wettgemacht. Man muss nicht dem LM 1117 nehmen, aber man muss einen Spannungsregler nehmen, der Gnd, 5V ("In", siehe Foto) sowie 3.3V ("Out") so wie auf der Platine beschriftet besitzt. In dem Schaltplan geht es dann mE drunter und drüber, das bekam ich nicht hin: So fit bin ich nicht in Fritzing und in Eagle habe ich mal versucht mich einzuarbeiten, es dann aber wieder gelassen.
Hallo zusammen,
vielleicht kann mir jemand helfen.... hab leider meinen Signalduino von In-Circuit zerschossen. Hab verschiedene FW getestet - hat auch wunderbar funktiniert. Beim aufspielen der letzten Datei hat sich der Updateprozess aufgehängt.
Nun wird mittels Befehl "ls /dev/serial/by-id/ -l" der Signalduino nicht mehr gefunden und ein erneutes Aufspielen einer FW mit avrdude ist nicht mehr möglich. Besteht die Möglichkeit den Signalduino noch zu retten?
Danke im Voraus und LG!
Stef
Zitat von: stef1938 am 25 März 2020, 13:44:56
Nun wird mittels Befehl "ls /dev/serial/by-id/ -l" der Signalduino nicht mehr gefunden und ein erneutes Aufspielen einer FW mit avrdude ist nicht mehr möglich. Besteht die Möglichkeit den Signalduino noch zu retten?
Wie hast Du die Firmware aufgespielt? Per seriellem Interface und Bootloader? Dann würde ich es ggf. mit einem ISProgrammer probieren, der kann auch den Bootloader bzw. falls erforderlich die Fuses brennen.
Gruß Peter
Hallo
ich versuche gerade meine Rollläden gleichzeitig zu fahren.Also das der Rollladen der Tür und des Fenster gleichzeitig anfangen los zu fahren. Aber es ist immer mindestens ca. 1 Sekunde zwischen den beiden Rollläden.
Kann man das irgendwie beschleunigen?
Da meine Rollläden mit dem Dooya und mit dem Siro Modul funktionieren habe ich es mal mit beiden probiert aber keinen großen Unterschied festgestellt. Gefühlt ist die Pause zwischen zwei Befehlen mit Dooya nen ticken kürzer.
Gruß Ricardo
Hi,
Zwei Funkgeräte ,,gleichzeitig" ansteuern bedeutet keins fährt! Also sei froh, das dort auf einem shared medium, deine Befehle nacheinander in der Queue abgearbeitet werden.
Du könntest aber beide Rolläden auf die gleiche ,,Fernbedienung" hören lassen.
Also:
FHEM FB A -> Rollo A
FHEM FB B -> Rollo B
FHEM FB C -> Rollo A&B
Die können ja bis zu 7 Fernbedienung empfangen, oder?
Gruß Arnd
Signalduino (Nano, ESP, ...), CUL (Busware, Nano, Maple, ...), Homematic (HM-MOD-UART-RPI, ESP, Maple, ...), LaCrosseGateway (LGW, ESP, ...), 1-wire, ESPEasy, Bravia, Yamaha, ...
Zitatich versuche gerade meine Rollläden gleichzeitig zu fahren.Also das der Rollladen der Tür und des Fenster gleichzeitig anfangen los zu fahren. Aber es ist immer mindestens ca. 1 Sekunde zwischen den beiden Rollläden.
Kann man das irgendwie beschleunigen?
mehr als ein paar Zehntel Sekunden lässt es sich wahrscheinlich nicht beschleunigen.
Falls es so wie von Arnd vorgeschlagen nicht funktioniert, kann ich mir es mal anschauen, wenn Du vom Rollladen der Tür und des Fensters die Raw definition des Siro Moduls postet.
Gruß Ralf
Hab ich hier irgendwo die Möglichkeit, das senden zu wiederholen / bzw. länger zu senden. Wenn es jetzt Standard den Fahrbefehl eine Sekunde lang sendet, könnte ich hier, einfach 2 Sekunden senden lassen, damit der Rollo auch sicher fährt. Hab seit einiger Zeit das Problem, das der ein oder andere nicht fährt. Ich habe schon alles mögliche probiert. Andere Position, größere Antenne. Leider kommt es doch immer wieder vor. Und dann auch noch Random,also nicht immer der gleiche. Daher meine Idee, ob man die Sendezeit vom Befehl, verlängern kann ? Damit sollte das Problem vllt behoben sein.
Nur kurz: schau mal nach ,,Wiederholrate", ich glaube das kann helfen
Zitat von: andies am 21 Juli 2020, 13:36:33
Nur kurz: schau mal nach ,,Wiederholrate", ich glaube das kann helfen
Im Signalduino Device ? In der cc1101_config ? Hab das hier mal kurz überflogen, aber leider nichts passendes gefunden.
Hi,
Schau mal im Device bei den Attributen. Bei IT devices geht das per attribut "ITrepetition".
Ronny
Der Stick sollte ja den Befehl länger senden. Mit IT meinst du Intertechno ?
Ich habe Jarolift Rollos. Im Modul für den Stick, habe ich nichts der gleichen gefunden, auch nicht bei den Rollos. Wobei das länger senden ja vom Stick ausgehen müsste.
Hmm, das habe ich nicht, was es schwer macht.
Poste doch mal ein List von Signaduino und vom Device
(also jeweils oben in der Eingabezeile von FHEM: list <DEVICENAMEY )
Dann kann man vielleicht was davon ableiten.
Ronny
Ich habe Jarolift Rollos. Im Modul für den Stick, habe ich nichts der gleichen gefunden, auch nicht bei den Rollos.
Dort heißt das Attribut "Repeats"
Zitat von: Ralf9 am 22 Juli 2020, 07:45:05
Ich habe Jarolift Rollos. Im Modul für den Stick, habe ich nichts der gleichen gefunden, auch nicht bei den Rollos.
Dort heißt das Attribut "Repeats"
Jetzt hab ich es gefunden, ganz wo anders. Zwar in dem Jaro Modul. Hab die ganze Zeit beim Stick geschaut, bei den Rollo Modulen usw. Dachte das geht dann vom Stick aus. Aber das sendet das Jaro Modul. Jetzt mal testen. Hab es auf zwei gestellt. Sollte ja dann 2x hintereinander der Fahrbefehl gesendet werden, bei erreichen der Pos dann wieder der Stop befehl ?
Zitat von: D3ltorohd am 22 Juli 2020, 11:23:00
Hab es auf zwei gestellt.
Hallo,
das macht es schlechter wie vorher, wenn der Parameter nicht gesetzt ist gilt der default von 3. Steht zur Info auch in der commandref.
Habe bei mir den Parameter auf 5 stehen, er verliert aber totzdem ab und zu den ein oder anderen Fahrbefehl.
Gruß
Zitat von: meier81 am 22 Juli 2020, 15:37:57
Hallo,
das macht es schlechter wie vorher, wenn der Parameter nicht gesetzt ist gilt der default von 3. Steht zur Info auch in der commandref.
Habe bei mir den Parameter auf 5 stehen, er verliert aber totzdem ab und zu den ein oder anderen Fahrbefehl.
Gruß
In welchem Abstand werden denn die Wiederholungen gesendet? Wenn ein Verlust auftritt ist bei mir wohl eine Störung auf dem Kanal. Dann reicht ein Wiederholen nicht, es müßte nach einigen Sekunen nocheinmal gesendet werden.
Horst
Zitat von: Harst am 23 Juli 2020, 10:58:03
In welchem Abstand werden denn die Wiederholungen gesendet? Wenn ein Verlust auftritt ist bei mir wohl eine Störung auf dem Kanal. Dann reicht ein Wiederholen nicht, es müßte nach einigen Sekunen nocheinmal gesendet werden.
Horst
Da müsste ich jetzt lügen aber ich glaube die werden direkt hintereinander gesendet, da ist keine größere Pause (wie z.B. 1 Sekunde oder so) zwischendrin. Ich schau aber nochmal in der Quellcode, vielleicht finde ich da was.
Gruß
Die Pausen zwischen den Wiederholungen sind normalerweise max 32 ms.
Wäre die Pause zu groß würde es vom Empfänger nicht mehr als Wiederholung erkannt, sondern als neuer Tastendruck.
Bei bidirektionalen Protokollen kann die Pause auch größer sein
Gruß Ralf
Hi Ralf,
ich weiß nicht, ob ich in dem Thread richtig bin (ggf. bitte auf den korrekten verweisen), aber ich versuch's mal:
Ich habe mir drei neue Funkthermometer (Funk-Außensensor für Wetterstation FWS-70, https://www.pearl.de/a-NX6876-3041.shtml (https://www.pearl.de/a-NX6876-3041.shtml)) von Pearl besorgt. Die werden prinzipiell als SD_WS07 Devices erkannt, das war's dann aber auch schon. Sporadisch erscheinen mal Tempaturwerte, aber es gibt keinen dauerhaften fehlerfreien Empfang. In meiner FHEM-Dev-Instanz habe ich vier SD_WS07 Devices, in meiner produktiven nur 2.
Ein List dines Devices sieht z.B. so aus:
Internals:
CFGFN
CODE SD_WS07_TH_2
DEF SD_WS07_TH_2
FUUID 5f370144-f33f-d483-d5e4-0780b9531796b0b5
LASTInputDev mySIGNALduino
MSGCNT 45
NAME SD_WS07_TH_2
NR 10698
STATE T: 27.7 H: 5
TYPE SD_WS07
bitMSG 10110111 1001 000100010101 1111 00000101
lastMSG B79115F05
lastReceive 1597476503.74956
mySIGNALduino_DMSG P7#B79115F05
mySIGNALduino_MSGCNT 64
mySIGNALduino_Protocol_ID 7
mySIGNALduino_RAWMSG MS;P1=504;P2=-1938;P3=-963;P4=-3882;D=1412131212131212121213131213131312131313121312131212121212131313131312131210;CP=1;SP=4;R=40;O;m2;
mySIGNALduino_RSSI -54
mySIGNALduino_TIME 2020-08-15 09:28:23
READINGS:
2020-08-15 09:28:23 batteryState ok
2020-08-15 09:28:23 channel 2
2020-08-15 09:28:23 humidity 5
2020-08-15 09:28:23 state T: 27.7 H: 5
2020-08-15 09:28:23 temperature 27.7
Attributes:
event-min-interval .*:300
event-on-change-reading .*
room SD_WS07
userattr max-deviation-hum:1,2,3,4,5,6,7,8,9,10,15,20,25,30,35,40,45,50 offset-hum
Im Log tauchen folgende Meldungen auf:
2020.08.15 09:21:50 5: mySIGNALduino: Read, RAW rmsg: Ms;▒▒;▒▒▒;▒̃;▒▒▒;D;C0;S4;R0;O;m2;
2020.08.15 09:21:50 4: mySIGNALduino: Read, msg READredu: MS;P0=503;P1=-1937;P2=-972;P4=-3902;D=0402010102020202020102020202020201020202010201010101010101010102020202010103;CP=0;SP=4;R=0;O;m2;
2020.08.15 09:21:50 4: mySIGNALduino: Parse_MS, Matched MS protocol id 7 -> Weather
2020.08.15 09:21:50 5: mySIGNALduino: Parse_MS, Starting demodulation at Position 2
2020.08.15 09:21:50 5: mySIGNALduino: Parse_MS, Found wrong signalpattern 03, catched 36 bits, aborting demodulation
2020.08.15 09:21:50 5: mySIGNALduino: Parse_MS, dispatching bits: 0 1 1 0 0 0 0 0 1 0 0 0 0 0 0 1 0 0 0 1 0 1 1 1 1 1 1 1 1 1 0 0 0 0 1 1
2020.08.15 09:21:50 4: mySIGNALduino: Parse_MS, Decoded matched MS protocol id 7 dmsg P7#608117FC3 length 36 RSSI = -74
2020.08.15 09:21:50 5: mySIGNALduino: Dispatch, P7#608117FC3, test gleich
2020.08.15 09:21:50 4: mySIGNALduino: Dispatch, P7#608117FC3, Dropped due to short time or equal msg
2020.08.15 09:21:50 4: mySIGNALduino: Parse_MS, Matched MS protocol id 91.1 -> Atlantic security
2020.08.15 09:21:50 5: mySIGNALduino: Parse_MS, Starting demodulation at Position 3
2020.08.15 09:21:50 5: mySIGNALduino: Parse_MS, can't reconstruct last part pair=1
Gibt's da noch Probleme mit der Dekodierung?
Ciao
Peter
Hallo Peter,
wenn möglich hier https://github.com/RFD-FHEM/RFFHEM/tree/dev-r34
ein Issues eröffnen und dort lesen mehr Entwickler mit.
Das beste wird sein, du fügst gleich mal ein Log von einer halben Std bei mit Beschreibung wo du zum Empfang den Sender positioniert hattest.
Mfg Marco
Zitat von: HomeAuto_User am 15 August 2020, 09:51:23
Hallo Peter,
wenn möglich hier https://github.com/RFD-FHEM/RFFHEM/tree/dev-r34
ein Issues eröffnen und dort lesen mehr Entwickler mit.
Das beste wird sein, du fügst gleich mal ein Log von einer halben Std bei mit Beschreibung wo du zum Empfang den Sender positioniert hattest.
Mfg Marco
Hi Marco,
ich werde versuchen mir noch etwas mehr Klarheit/Übersicht zu verschaffen, was wirklich los ist. Ich bin als erstes über die Fehlermeldung im Log gestolpert. Da sich auf 433 MHz aber sehr viel tut (keine Ahnung was meine Nachbarn so alles haben), werde ich das noch etwas vorsortieren ...
Ich habe mal das event-min-interval auf 60 Sekunden reduziert. Damit ich dichtere Messreihen kriege und sehen kann, ob die Temperatur drastisch springt (=zwei Devices funken funken Werte).
VG Peter
Update/Nachtrag: Nachdem ich gelesen habe, dass die von diesen (preisgünstigen) Teilen gelieferten Werte ziemliche Sprünge machen können, habe ich meine Erwartungen erst mal runtergeschraubt. Die Temperaturen sind (wenn sie denn ankommen) brauchbar präzise, die sehr sprunghafte Luftfeuchtigkeit interessiert mich nicht so sehr. Wenn ich's präziser/lückenfreier benötige melde ich mich wieder (oder kaufe mir was besseres ;)). Wenigstens funken keine Devies der Nachbarn auf den Kanälen.
Nachtrag 2: Immerhin erkennt man aufgrund der Zacken bei der Luftfeuchtigkeit wie selten die Messwerte durchkommen.
Zitat von: HomeAuto_User am 15 August 2020, 09:51:23
Das beste wird sein, du fügst gleich mal ein Log von einer halben Std bei mit Beschreibung wo du zum Empfang den Sender positioniert hattest.
Auf 433 MHz empfange ich Signale von sehr vielen Devices. Also muss ich den SIGNALduino und das Thermometer in einen Faradayschen-Käfig packen. Eine Blechdose funktioniert nicht. Zusätzlich Alufolie funktioniert auch nicht.
Hat jemand eine Idee wie ich den Traffic auf ein einzelnes Thermometer beschränken kann?
Ciao
Peter
Zitat von: plin am 15 August 2020, 20:24:31
Hat jemand eine Idee wie ich den Traffic auf ein einzelnes Thermometer beschränken kann?
Hallo Peter,
du kannst im SIGNALduino Device oben auf "Display Protocollist" klicken und dann geht eine "Whitelist" auf, in der kannst du alle Protokolle die du nicht benötigst abwählen. Wenn ich dich richtig verstanden habe hast du SD_WS07-Sensoren, dann kannst du dort alles abwählen bis auf die ID7, das wäre dein Protokoll. Du wirst sehen das wird etliches ruhiger, ich habe bei mir auch nur meine Sensoren freigegeben und es kommt ansonsten wirklich nichts anderes rein, es hat anscheinend keiner in der Nachbarschaft meine Sensoren.
Gruß Markus
Zitatich weiß nicht, ob ich in dem Thread richtig bin (ggf. bitte auf den korrekten verweisen), aber ich versuch's mal:
Ich habe unter SlowRF dazu ein neues Thema aufgemacht, ich schreibe dort später noch was dazu.
https://forum.fhem.de/index.php/topic,113600.0.html
Gruß Ralf
Hi Leute,
ich bin ganz neu hier und noch sehr grün hinter den Ohren was FHEM angeht. Allerdings bin ich Homematic-Profi.
Nun möchte ich aber meine Jarolifts mit FHM steuern und evtl. die Homematic-Devices später auch. Erster Versuch sollen eben die Jarolift Rolläden sein. Den Code dafür hab ich schon, ebenfalls habe ich einen Raspi mit FHEM installiert und Webzugriff. Nun bräuchte ich von Euch etwas Hilfe, meinen bereits zusammengelöteten Signalduino WLAN (auf Basis jenem von andies) zu flashen und einzubinden, die Jaros anzulernen. Ich habe die Möglichkeit, per AVR-ISP eine Firmware-Hex-Datei auf den Arduino nano zu schreiben, ist das nun der nächste Schritt? Welche FW nehme ich dann eigentlich für den Nano und für das ESP-01-Modul?
Gruß BJDriver
Hi Stephan, also:
- Firmware auf dem CC1101 ist bei mir "V 3.3.2.1-rc8 SIGNALduino cc1101", das Kommando dazu lautet
set sduino flash <url zur Firmware>, wobei du dir die Firmware in FHEM ja selbst holen kannst mit "get sduino availableFirmware" (ich glaube, ich habe dennoch eine von "außerhalb")
[/li]
- Bei dem ESP habe ich ESP-Link genommen. Der baut eine serielle Brücke auf und dann sprichst du den SIGNALduino via <ip-Adresse:23> an. Baudrate habe ich 57600 eingestellt, klappt.
Jetzt fällt mir noch was ein. Wenn das HM-Geräte sind, ist vermutlich der SIGNALduino nicht das geeignete Gerät. Super, das mir das jetzt einfällt :-[
Einmal ist die Frequenz bei meinem CC1101 433MHz, Homematic hat aber 868 MHz. Zudem schafft anscheinend der SIGNALduino die Flanken nicht richtig, siehe https://forum.fhem.de/index.php/topic,68145.msg595998.html#msg595998 (https://forum.fhem.de/index.php/topic,68145.msg595998.html#msg595998)
Die aktuelle Version meiner alternativen firmware ist die "V 3.3.2.1-rc9", siehe hier im ersten Beitrag
Mit "get sduino availableFirmware" kann nur die offizielle firmware von Sidey geholt werden
Gruß Ralf
Hallo,
Ich denke die HM Geräte können mit dem Signalduino laufen. Das muss aber alternativ mal in einem separaten Faden diskutiert werden.
Welche genaue Hardware wird verwendet und welche Software von welcher Quelle?
Den ESP kannst du direkt flashen via Arduino oder PIO.
Bitte wirbelt die Themen nicht zu sehr durcheinander weil es schon ein Durcheinander ist 😀
Liebe Grüße Marco
Hi !
mir geht's in erster Linie drum, Jarolift zu steuern, Homematic-Aktoren könnte ich bestimmt über die in der Homematic befindlichen CULs ansteuern.
Habe nun die aktuelle Firmware von Ralf9 drauf (denke ich).
In der config steht:
-----
# Disable this to avoid looking for new USB devices on startup
define initialUsbCheck notify global:INITIALIZED usb create
setuuid initialUsbCheck 5f3699a6-f33f-0bc1-3321-e49016576cc0aa5c
define sduino SIGNALduino /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0@57600
setuuid sduino 5f415040-f33f-0bc1-3640-eabe90adef876671
attr sduino hardware nanoCC1101
------
nun kommt hier Folgendes, siehe Bild. Ist das korrekt?:
du hast per USB angeschlossen? Meine Platine ist ja auf Wlan ausgelegt, da muss die Definition anders lauten. Derzeit ist das Gerät ,,closed" und reagiert demzufolge nicht.
Ja, aktuell ist es per USB dran. Mit dem WLNA-flashen komme ich nicht so ganz klar, wie ich das machen soll.
Warum geht es vorerst nicht per USB, warum "closed"?
dann poste mal, was im Logfile steht (in Codetags, der Knopf # oben). Die (USB)Adresse hast du überprüft, die ist richtig?
Es kann sein, daß es über über USB nur funktioniert, wenn der ESP nicht gesteckt ist.
Beim Anstecken an USB sollte im Eventmonitor und fhemlog folgendes stehen:
2020-08-23 13:11:35.075 SIGNALduino sduino CONNECTED
2020.08.23 13:11:36.574 3 : sduino: SimpleWrite_XQ, disable receiver (XQ)
2020.08.23 13:11:37.074 3 : sduino: StartInit, get version, retry = 0
2020.08.23 13:11:37.092 2 : sduino: CheckVersionResp, initialized v3.4.4
2020.08.23 13:11:37.102 3 : sduino: CheckVersionResp, enable receiver (XE)
2020-08-23 13:11:37.092 SIGNALduino sduino opened
Die USB-Adresse des Devices stimmt, ja. Der ESP01 steckt natürlich mit drin und leuchtet / blinkt ab und zu blau.
Es ist ein WLAN-Netzwerk "FaryLink_xxxx" sichtbar - das Modul habe ich noch nicht geflasht weill ich nicht weiss mit welcher Firmware (habt Ihr nen Link?)
Hab im LastFlashLog folg. gefunden . Bild 1
Danach habe ich shutdown restart ausgeführt, Log-File aufgerufen - Bild2
Ich habe den Nano wie auf https://wiki.fhem.de/wiki/SIGNALduino beschrieben ursprünglich geflasht, danach habe ich versucht, per Windows und AVR ISP die Firmware reinzuspielen, was der MySmart USB Brenner auch gemacht hat. Zurück am Raspbian hatte ich nochmals den Flashbefehl aus diesem Post (Seite1) (von Dir, Ralf9) ausgeführt, immer mit dem selben Erfolg, dass das Verhalten sich nicht änderte.
Zitat von: bjdriver am 23 August 2020, 14:25:24
Der ESP01 steckt natürlich mit drin und leuchtet / blinkt ab und zu blau.
Also, da ist einiges faul (vielleicht machst Du auch einen eigenen Thread auf und schickst uns die Adresse zu). Und bitte die Sachen in Codetags, also #, keiner will hier Bilder anschauen und dann abschreiben.
Das erste Foto zeigt, dass das Flashen des arduino nicht geklappt hat. Wenn USB, dann bitte den ESP entfernen, der hat ja keinen Sinn dann. Der zweite Screenshot dagegn zeigt, dass anscheinend der sduino geöffnet wurde (ich nehme an via USB) und auch läuft. Dann müsste da aber opened stehen? Mach mal
list sduinound schreibe (
in Codetags), was dann da steht.
Habe ein neues Thema erstellt, hier noch der Link dazu:
https://forum.fhem.de/index.php/topic,113753.0.html
Dort steht auch die Antwort auf Deine Frage bzw. der Plott zu "list sduino".
ZitatHab im LastFlashLog folg. gefunden
Das Flashen hat nicht funktioniert, bitte flashe mal mit nicht gestecktem ESP.
Das flash log sollte ungefähr so aussehen:
avrdude: Version 6.3, (openSUSE Buildservice)
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2014 Joerg Wunsch
System wide configuration file is "/etc/avrdude.conf"
User configuration file is "/home/ralf/.avrduderc"
User configuration file does not exist or is not a regular file, skipping
Using Port : /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0
Using Programmer : arduino
Overriding Baud Rate : 57600
AVR Part : ATmega328P
Chip Erase delay : 9000 us
PAGEL : PD7
BS2 : PC2
RESET disposition : dedicated
RETRY pulse : SCK
serial program mode : yes
...
Zitat von: andies am 05 März 2020, 19:22:49
Inzwischen habe ich das Problem mit dem Vorschlag von Ralf9 im Griff. Alle halbe Stunde sende ich ein "get sduino ping" und damit bleibt er wach und sendet auf Anhieb.
Es hat sich gezeigt, dass das Problem wo ganz anders lag. Eine selbst gebaute WLAN-Antenne hat sich anscheinend als 433 MHz-Störsender betätigt.
Es gibt für meine alternative Firmware V 3.3.4 eine neue Version V 3.3.4-dev200914
Sie ist für den Arduino nano und minicul, damit ist auch ein Empfangen und Senden von FSK modulierten Signalen möglich.
https://forum.fhem.de/index.php/topic,82379.msg1010643.html#msg1010643
Es gibt die folgenden Neuerungen, die ich von meiner Firmware V 4.x.x für den Maple Mini, übernommen habe
- Es gibt einen neuen Befehl "bs" - Banksummary
- ccmode=4 zugefügt
- beim CW Befehl die Bank Kurzbeschreibung zugefügt
- Bei SlowRF (ASK/OOK) wird beim Sendebefehl das Echo auf 100 Zeichen begrenzt.
- Wenn eine nicht initialisierte EEPROM Speicherbank ausgewählt wurde, dann wird diese mit den sduino Defaults initialisiert (raw e).
Für diejenigen wo kein Empfangen und Senden von FSK benötigen gibts die firmware V 3.3.2.1, die aktuelle Version ist V 3.3.2.1-rc9
https://forum.fhem.de/index.php/topic,82379.msg744554.html#msg744554
Bei einem Neuaufbau von einer sduino Hardware ist der Maple Mini zu empfehlen, der ist deutlich leistungsfähiger und zukunftssicherer
https://forum.fhem.de/index.php/topic,106278.msg1001477.html#msg1001477
https://wiki.fhem.de/wiki/Maple-SignalDuino
Gruß Ralf
Ich habe für meine Firmware V 3.3.2.1-rc9 auch für den Radino eine Firmware kompiliert.
Kann dies bitte mal jemand testen?
set sduino flash https://github.com/Ralf9/SIGNALDuino/releases/download/3.3.2.1-rc9/SIGNALduino_radinoCC1101_3321rc9.hex
Gruß Ralf
Zitat von: Ralf9 am 09 November 2020, 13:30:44
Ich habe für meine Firmware V 3.3.2.1-rc9 auch für den Radino eine Firmware kompiliert.
Kann dies bitte mal jemand testen?
set sduino flash https://github.com/Ralf9/SIGNALDuino/releases/download/3.3.2.1-rc9/SIGNALduino_radinoCC1101_3321rc9.hex
Ich habe bis jetzt noch keine Rückmeldung erhalten, ob meine 3.3.2.1-rc9 Firmware auf dem radinoCC1101 funktioniert.
Es wäre schön, wenn dies jemand testen könnte.
Gruß Ralf
Mein Stick funktioniert nach einam Stromausfall nicht mehr/richtig/unzuverlässig.
V 3.3.2-rc2 SIGNALduino cc1101 - compiled at Jun 1 2018 23:56:22
Ich verwende ihn ausschliesslich mit Siro Rollos. Protokolle 72, m72.1
Nun möchte ich die FW neu flashen.
Welche kann ich nehmen und woher bekomme ich die aktuelle Version, die mit Siro-Motoren läuft?
Gibt es vielleicht eine andere Möglichkeit, den Stick zur Vernunft zu bringen?
Danke im Voraus.
hast Du schon versucht den sduino mit der aktuellen Version neu zu flashen?
für den nanocul:
set sduino flash https://github.com/Ralf9/SIGNALDuino/releases/download/3.3.2.1-rc9/SIGNALduino_nanoCC1101_3321rc9.hex
Ich befürchte, dass die beiden Protokolle nicht mehr unterstützt werden. Falls das so wäre, könnte ich die Rollos nicht mehr bedienen.
Aber ich gucke mal, ob meine Version noch im Git liegt. Dann kann ich ja im notfall wieder zurück. Danke.
Ich habe das mal gemacht, aber es gibt keinerlei Besserung. Mal bewegt sich das Rollo, mal nicht. Meistens nicht. Das betrifft alle 4 Rollos. Die Entfernung ist dabei unerheblich (3 Meter).
Was kann ich tun, um das Senden zu verbessern oder zu kontrollieren?
Alternativ würde ich auch einen neuen Signalduino kaufen. Könnt ihr mir einen empfehlen, der auch zuverlässig arbeitet?
Bei den Protokollen 72 und 72.1 gab es in den letzten 2 Jahre keine Änderungen. Obs beim Siro-Modul änderungen gab habe ich nicht geschaut.
ZitatMein Stick funktioniert nach einam Stromausfall nicht mehr/richtig/unzuverlässig.
Was meinst Du mit Stromausfall? Hast Du danach bei Fhem ein update gemacht?
Werden die Tastendrücke von der Fernbedienung noch sauber erkannt?
Bitte poste mal ein Foto vom sduino
Gruß Ralf
Mein Herd hat mich angepfiffen und wollte sich auch nicht mehr beruhigen. Mi blieb nichts Anderes Übrig, als die Sicherung zu schalten. Dabei habe ich wegen mangelhafter Beschriftung die Sicherung für mein Wohnzimmer entfernt, statt die des Herdes.
Danach ging erst einmal bei fhem alles drunter und drüber. Z.B. ging in der Küche das Licht an, obwohl das DOIF nicht hätte schalten dürfen. Wenn ich hingegen den Pi ausschalte und neu starte gibt es solche Ausreisser nicht.
Seitdem schaltet der SD so bescheuert bis gar nicht.
Ich habe nun dir FW geflasht und mein fhem zurückgesetzt auf die Zeit vor dem Stromausfall.
Hat leider keine Besserung gebracht.
Es macht den Eindruck, als würde die Sendeleistung nicht mehr ausreichen.
Was könnte ich denn vor einem Neukauf noch probieren?
Schlafzimmer geht gar nicht mehr, Wohnzimmer geht einigermassen. Jeweils 2 Rollos. Schaltbefehle werden auch im Log klaglos angezeigt. Wie kann ich denn sehen, ob etwas gesendet wird? Muss ich mich da an byte09 wenden, wegen Siro-Modul?
Vielen Dank im Voraus.
Was ergibt ein
get sduino ccconf
get sduino ccpatable
ccconf: Freq: 433.920 MHz, Bandwidth: 406 KHz, rAmpl: 42 dB, sens: 16 dB, DataRate: 5603.79 Baud, Modulation: ASK/OOK, Syncmod: No preamble/sync
ccpatable: C3E = 00 84 00 00 00 00 00 00 => 5_dBm
Danke, dass du dich meiner Sache annimmst.
Ich habe inzwischen den SD in mein Testsystem aufgenommen. Einen Siro natürlich auch.
Dort funktioniert der Stick ebenfalls unzuverlässig.
Welchen Wert hat das Attribut "SIRO_signalRepeats"?
Du kannst auch mal mit dem raw Befehl "e" einen Factoryreset der cc1101 Register machen
Ein Foto von Deinem sduino wär auch interessant
Der Wert ist nicht gesetzt. Habe nun 5 und 9 probiert, aber ohne Erfolg. Habe das Attribut wieder gelöscht.
set sduino raw e
brachte auch keinen Erfolg.
EDIT
Unschärfe kommt durch den Schrumpfschlauch.
Ich sehe den Stick blinken, wenn ich ein Sendekommando gebe.
Hast Du nach dem flashen mit "get Version" die Version überprüft?
V 3.3.2.1-rc9 SIGNALduino cc1101
Du kannst auch mal die Sendeleistung mit "set patable" auf 7 oder 10 erhöhen.
Bitte setze beim Rollo im Schlafzimmer das Attribut verbose auf 5
und beim sduino das Attribut verbose auf 4.
Bitte sende dann zum Rollo das Kommando hoch oder runter und poste dann den log-Auszug.
Evtl passt was mit der Antenne nicht, z.B. Kontaktproblem an der Koaxbuchse, zum Testen kannst Du anstatt der Koaxbuchse einen 17.3 cm langen Draht anlöten.
Auf dem Foto kann ich keine Levelshifter erkennen, der cc1101 wird damit außerhalb der Spezifikation betrieben, in der Regel läuft es trotzdem problemlos, man kann aber nicht ausschließen daß dadurch der cc1101 irgendwann einen Schaden nimmt.
Gruß Ralf
Ich hatte die Version geprüft.
ZitatDu kannst auch mal die Sendeleistung mit "set patable" auf 7 oder 10 erhöhen.
Habe ich probiert, ging dann gefühlt etwas besser, aber nicht sehr zuverlässig.
Die Antenne sollte eigentlich funktionieren, aber ich werde es ausprobieren und dann breichten.
Logauszug:
2021.06.04 20:57:32 5: Siro-progmode: reached progmode off
2021.06.04 20:58:45 3: sduino: Attr, setting Verbose to: 4
2021.06.04 20:59:10 5: Siro-Set: eingehendes Kommando open
2021.06.04 20:59:10 5: Siro-Set: param -
2021.06.04 20:59:10 5: Siro-Set: ermittelter Befehl: off
2021.06.04 20:59:10 5: Siro-Set: cmd nach change : off
2021.06.04 20:59:10 3: Siro-Set (Siro_SZL) : set Up
2021.06.04 20:59:10 5: Siro-Set: off downtime - waytodrive 0
2021.06.04 20:59:10 5: Siro-Set: off downtime - state 0
2021.06.04 20:59:10 5: Siro-Set: off downtime - up1time 0.18
2021.06.04 20:59:10 5: Siro_sendCommand: cmd - off
2021.06.04 20:59:10 5: Siro_sendCommand: repeats - 9
2021.06.04 20:59:10 4: sduino: Set_sendMsg, sending : SR;R=9;P0=4760;P1=-1496;P2=680;P3=-408;P4=340;P5=-748;D=0123454545452345454545232345454523452345452323454523234523454523234545452345454523;
2021.06.04 20:59:10 5: Siro_sendCommand: name-Siro_SZL command-off channel-3 bincmd-00010001 bin-1000010000110001010011001101001100010001 id-undef message-P72#1000010000110001010011001101001100010001#R9
2021.06.04 20:59:10 5: Siro-Set: setze timer -off
2021.06.04 20:59:10 5: Siro-Finish: action - off
2021.06.04 20:59:10 4: sduino: HandleWriteQueue, called
2021.06.04 20:59:10 4: sduino: SendFromQueue, called
2021.06.04 20:59:10 4: sduino: SendFromQueue, msg=SR;R=9;P0=4760;P1=-1496;P2=680;P3=-408;P4=340;P5=-748;D=0123454545452345454545232345454523452345452323454523234523454523234545452345454523;
2021.06.04 20:59:10 4: sduino: Read, msg: SR;R=9;P0=4760;P1=-1496;P2=680;P3=-408;P4=340;P5=-748;D=0123454545452345454545232345454523452345452323454523234523454523234545452345454523;
2021.06.04 20:59:10 4: sduino: CheckSendrawResponse, sendraw answer: SR;R=9;P0=4760;P1=-1496;P2=680;P3=-408;P4=340;P5=-748;D=0123454545452345454545232345454523452345452323454523234523454523234545452345454523;
2021.06.04 20:59:12 4: sduino: HandleWriteQueue, called
2021.06.04 20:59:12 4: sduino: HandleWriteQueue, nothing to send, stopping timer
2021.06.04 20:59:20 5: Siro-Set: eingehendes Kommando close
2021.06.04 20:59:20 5: Siro-Set: param -
2021.06.04 20:59:20 5: Siro-Set: ermittelter Befehl: on
2021.06.04 20:59:20 5: Siro-Set: cmd nach change : on
2021.06.04 20:59:20 3: Siro-Set (Siro_SZL) : set Down
2021.06.04 20:59:20 5: Siro-Set: on downtime - waytodrive 100
2021.06.04 20:59:20 5: Siro-Set: on downtime - state 0
2021.06.04 20:59:20 5: Siro-Set: on downtime - down1time 0.17
2021.06.04 20:59:20 5: Siro_sendCommand: cmd - on
2021.06.04 20:59:20 5: Siro_sendCommand: repeats - 9
2021.06.04 20:59:20 4: sduino: Set_sendMsg, sending : SR;R=9;P0=4760;P1=-1496;P2=680;P3=-408;P4=340;P5=-748;D=0123454545452345454545232345454523452345452323454523234523454523234545232345452323;
2021.06.04 20:59:20 5: Siro_sendCommand: name-Siro_SZL command-on channel-3 bincmd-00110011 bin-1000010000110001010011001101001100110011 id-undef message-P72#1000010000110001010011001101001100110011#R9
2021.06.04 20:59:20 5: Siro-Set: setze state down , setze Timer - on
2021.06.04 20:59:20 4: sduino: HandleWriteQueue, called
2021.06.04 20:59:20 4: sduino: SendFromQueue, called
2021.06.04 20:59:20 4: sduino: SendFromQueue, msg=SR;R=9;P0=4760;P1=-1496;P2=680;P3=-408;P4=340;P5=-748;D=0123454545452345454545232345454523452345452323454523234523454523234545232345452323;
2021.06.04 20:59:20 4: sduino: Read, msg: SR;R=9;P0=4760;P1=-1496;P2=680;P3=-408;P4=340;P5=-748;D=0123454545452345454545232345454523452345452323454523234523454523234545232345452323;
2021.06.04 20:59:20 4: sduino: CheckSendrawResponse, sendraw answer: SR;R=9;P0=4760;P1=-1496;P2=680;P3=-408;P4=340;P5=-748;D=0123454545452345454545232345454523452345452323454523234523454523234545232345452323;
2021.06.04 20:59:22 4: sduino: HandleWriteQueue, called
2021.06.04 20:59:22 4: sduino: HandleWriteQueue, nothing to send, stopping timerZitatAuf dem Foto kann ich keine Levelshifter erkennen, der cc1101 wird damit außerhalb der Spezifikation betrieben, in der Regel läuft es trotzdem problemlos, man kann aber nicht ausschließen daß dadurch der cc1101 irgendwann einen Schaden nimmt.
Ich hbae vorsichtshalber einen neuen Stick bestellt. Der soll morgen oder Montag ankommen. Scheint mit meinem Stick identisch aufgebaut zu sein. Ist ja dann eigentlich schade. Ich habe aber keinen besseren gefunden.
Du hast ja echt ne Menge Ideen.
Ich danke dir nochmal für die Mühe und die Hilfe.
Mal sehen, was die Antenne bringt.
Ich glaube es einfach nicht.
Der Tipp, dem ich zuletzt zugetraut hätte, zu helfen, der war es.
Der angelötete Draht hat es offenbar gebracht.
Der Stick schaltet bisher bei 15 Versuchen fehlerfrei.
Nun habe ich ab morgen oder Montag 2 Sticks. Naja, ist dann halt reserve.
Nochmals herzlichen Dank!!!!
Hallo,
ich habe mal eine bescheidene Frage.
Welche Firmware muss ich bei einem minicul (nanocul Verkabelung mit ATmega 328P 3.3V 8MHz) nehmen wenn ich z.B. mit einem FTDI flashe?
und wenn ich später über fhem flashe, sollte ich das Attribut "hardware - miniculCC1101" setzen und mir wird dann die Richtige angeboten?
also die für den 3.3V 8MHz...
Danke Uwe
Zitatminicul (nanocul Verkabelung mit ATmega 328P 3.3V 8MHz) nehmen
wenn Du mit einem 3.3V promini und der nanocul Verkabelung einen Signalduino gebaut hast, dann ist es kein minicul.
Die passende Firmware und Attribut Hardware ist dann "3v3prominiCC1101"
Beim minicul sind im Vergleich zur nanocul Verkabelung gdo0 und gdo2 vertauscht
PIN_SEND 2 # cc1101 gdo0 Pin TX out
PIN_RECEIVE 3 # cc1101 gdo2 Pin Rx in
Danke für die Antwort,
habe ihn mit einem FTDI geflasht mit version:
V 3.3.2.1-rc9 SIGNALduino cc1101 - compiled at Jun 16 2019 20:14:45 (3.3V 8MHz)
und das versionmodul ist:
v3.4.4_dev+14042020
er ist opened und scheint zu empfangen,
aber es gibt kein Attribut "3v3prominiCC1101".
gibt es eine aktuellere Version?
Gruß Uwe
die aktuelle Version von meinem angepasstem 00_SIGNALduino.pm Modul gibts hier:
https://forum.fhem.de/index.php/topic,111653.msg1058900.html#msg1058900
Zitatv3.4.4_dev+14042020
Dies ist die offizelle Version von Sidey vom normalen fhem update. Damit müsste meine firmware auch funktionieren. Es fehlen damit einige komfort Funktionen, es kann sein, daß mit einem zukünftigen Update des 00_SIGNALduino.pm Moduls von Sidey meine Firmware nicht mehr funktioniert.
Das Attribut hardware wird beim normalen Betrieb nicht benötigt, es wird nur beim download und flashen der Firmware verwendet.
Gruß Ralf
Hallo Uwe,
Zitat von: my-engel am 28 Juni 2021, 21:00:42
...
aber es gibt kein Attribut "3v3prominiCC1101".
gibt es eine aktuellere Version?
Gruß Uwe
Das Attribut mit deinem Namen wird es nicht geben, da es allgemein "miniCC1101" beziffert wurde. Es hängt mit der Entwicklungsgeschichte zusammen. Ausschlaggebend im großen Sinne ist der Prozessor. In deinem Falle ein ATMega328P". Ob die FW dann für 5V oder 3.3V kompiliert wird sollte keine relevante Rolle spielen. Wichtig ist immer, du schaust nach deinem uC und dann kannst du in dem SourceCode auch die Beschaltung entnehmen wenn kein Wiki auf das passende existiert.
Zitat von: Ralf9 am 28 Juni 2021, 22:23:40
...
Dies ist die offizelle Version von Sidey vom normalen fhem update. Damit müsste meine firmware auch funktionieren. Es fehlen damit einige komfort Funktionen, es kann sein, daß mit einem zukünftigen Update des 00_SIGNALduino.pm Moduls von Sidey meine Firmware nicht mehr funktioniert.
Ob "komfort Funktionen" der Unterschied zwischen den Firmwarevarianten ist, liegt im Sinne des Betrachters. Die Versionen von Sidey und Ralf sind in deinem Falle gleich.
Wenn du auf die aktuelle Version deine uC´s springen möchtest, so gibt es auf
https://github.com/RFD-FHEM/SIGNALDuino/tree/dev-r3.5_xFSK die noch derzeit laufende Entwicklerversion. Damit kannst du auch xFSK empfangen. Das passende Modul hinterliegt auf
https://github.com/RFD-FHEM/RFFHEM weil das SVN noch etwas hinterher hinkt. Dies wird in der nächsten Zeit aktualisiert.
MfG Marco
Hallo,
ich danke euch für die Infos und werde mich mal versuchen...
VG Uwe
Hallo,
ich habe auch für die Cul V3 Hardware meine V 3.3.2.1-rc9 und V 3.3.4 Firmware kompiliert.
Damit die V 3.3.4 Firmware in den flash des Atmega32U4 passt, habe ich die Routinen für den ASK/OOK (slowrf) Empfang entfernt.
Z.zt. gibt's z.B. bei ebay ein "nanoCUL USB Stick 868 Mhz" zu kaufen, dieser besteht aber nicht aus einem nano sondern einem Atmega32U4
Die Hardware ist kompatibel zum Cul V3.
https://www.smarthome-agentur.de/blog/der-neue-cul-stick/
Für FSK lässt sich der Cul V3 ohne Einschränkungen verwenden.
Für ASK/OOK (slowrf) gibts beim Empfang von einigen neuen Protokollen Einschränkungen, da ist der MapleMini die bessere Wahl.
Dies ist die "V 3.3.2.1-rc9" für ASK/OOK (slowrf) für den cul V3
https://github.com/Ralf9/SIGNALDuino/releases/tag/3.3.2.1-rc9
SIGNALduino_culV3CC1101_3321rc9.hex
und dies ist die firmware für FSK
https://github.com/Ralf9/SIGNALDuino/releases/tag/3.3.4-dev211207
SIGNALduino_culV3CC1101_onlyFsk_334dev211207.hex
Zum flashen des Cul V3 ist der dfu-programmer notwendig.
Ich habe bei meiner FSK Firmware V3.3.4-dev211207
https://github.com/Ralf9/SIGNALDuino/releases/tag/3.3.4-dev211207
das Wechseln der aktiven EEPROM Bank optimiert (nur bei FSK).
Es werden nun die Register der alten und neuen Bank verglichen und dann nur die Differenz in die cc1101 Register geschrieben.
Zum Aktivieren wird nun nur noch der cc1101 kurz den IDLE Modus konfiguriert.
Beim optimierten Bankwechsel wird ein "f" angehängt.
z.B.
get sduino cmdBank 2f
Ab "versionmodul v3.4.7-dev_ralf_04.12." meiner Variante der 00_SIGNALduino.pm wird als Rückgabe die Anzahl der geschriebenen cc1101 Register (wrReganz=..) ausgegeben
https://forum.fhem.de/index.php/topic,111653.msg1058900.html#msg1058900
Wenn z.B. auf der Bank 1 "LaCrosse Mode1" und auf der Bank 2 "Lacrosse Mode2" ist,
dann können mit einem cc1101 Modul beide LaCrosse Mode empfangen werden, wenn mit "set cmdBank 2f" und "set cmdBank 1f" zwischen Bank 1 und Bank 2 gewechselt wird.
Dies kann z.B. mit einem notify oder DOIF alle 2 Min gemacht werden.
Wichtig:
Bei der Firmware V3.3.4-dev211207 habe ich beim CW Befehl, mit dem bei "set rfmode" die Registerkonfiguration zum sduino gesendet wird, ein bug behoben.
Es wurden mit dem CW Befehl auch Teile der nächsten EEPROM Bank überschrieben. Wenn die EEPROM Bänke in aufsteigender Reihenfolge beschrieben wurden, hatte dies keine Auswirkung.
Gruß Ralf
Gibt es eine Möglichkeit über ein Attribut oder ähnliches zwischen den cmdbank EEPROM Speicherbereiche des SIGNALduino Sticks in vorgegebenen Zeiten automatisch zu springen, um verschiedene Geräte abzufragen ?
Oder muss dazu z.B. eine DOIF programmiert werden?
Gruß Maik
Möchtest Du verschiedene FSK Sensoren empfangen?
ZitatOder muss dazu z.B. eine DOIF programmiert werden?
Ja, das muß über ein DOIF oder notify programmiert werden.
Hallo Ralf9,
kurze Frage, da ich 2 meiner 3 Signalduinos nicht zum laufen bekomme.
ich habe:
versionmodul v3.4.10-dev_ralf_12.02.
versionprotoL v3.4.10-dev_ralf_16.02.
version V 3.3.4-dev211207 SIGNALduino cc1101 (b0) - compiled at Dec 8 2021 00:17:23
sowie
00_SIGNALduino.pm 3410 2022-02-12 22:00:00Z v3.4.10-dev-Ralf9
14_SD_WS.pm 21666 2022-01-23 23:00:00Z Ralf9
der funktionierende Signalduino hat ein cc1101-Modul angeschlossen und empfängt meine Bresser5in1 einwandfrei (kurze Anmerkung: die mit dem cc1101 gelieferte "Drahtspule" als Antenne hat funktioniert, als der Signalduino neben der Wetterstation lag. Nachdem diese im Garten stand wurde nix mehr empfangen, die Basisstation zeigt aber immer noch vollen Empfang an. Dann habe ich die Drahtspule durch einen 8,3cm langen Draht ersetzt und siehe da: volles Rohr empfang, RSSI -68. (vorher irgendwas bei -97 oder so)
Ein weiterer Signalduino hat ein 433MHZ Sender/Empfänger-Set, angeschlossen nach Schaltplan aus FHEMduino, hat auch mal mit den "original"-Modulen aus fhem funktioniert und diverse Sender empfangen /Thermometer und so)
ein dritter Signalduino hat einen 868MHz Empfänger von ELV, den Du in einem der vielen Threads empfohlen hast. Auf dem Weg zur Lösung für die Wetterstation hat dieser signalduino auch mal FS20-Komponenten empfangen.
Die Wetterstation habe ich dann nur mit dem cc1101-Empfänger zum laufen bekommen, die anderen beiden liefern nichts mehr. Die Signalduinos werden als opened dargestellt.
Ich vermute nun, daß die Firmware nicht mit den Empfängern zusammenarbeitet. Ich dachte, die sei "rückwärtskompatibel", vielleicht liege ich da auch falsch. Im Moment habe ich allerdings auch etwas den Überblichk verloren bei all den verschiedenen Versionen.
Wie gesagt, ich bin mit allen Deinen Modulen/Firmwares auf dem neuesten Stand (soweit ich das sehe), nur die 2 Signalduinos ohne cc1101 liefern nix.
Vielleicht kannst Du mich ja da in die richtige Richtung "schubsen", was ich da tun kann.
Vielen dank schon mal.
Gruß
Sany
ZitatEin weiterer Signalduino hat ein 433MHZ Sender/Empfänger-Set, angeschlossen nach Schaltplan aus FHEMduino
Welche Firmware verwendest Du bei diesem sduino?
Welchen 433MHZ Empfänger verwendest Du? Einen RXB6?
Guten Morgen,
ZitatWelche Firmware verwendest Du bei diesem sduino?
ich habe auf allen die Version V 3.3.4-dev211207 SIGNALduino (b0) - compiled at Dec 8 2021 00:17:23 geflashed
ZitatWelchen 433MHZ Empfänger verwendest Du? Einen RXB6?
genau, eine RXB6
Wie gesagt, der lief schon mal mit den Signalduino-Modulen und Firmware, die per fhem-update verteilt werden. Ich bin dann, da ich die Wetterstation nicht gleich zum laufen bekommen habe, auf Deine Module+Firmware umgestiegen. Ich vermute mal, ein Mischbetrieb wird nicht gehen, da die 00_SIGNALduino.pm ja unterschiedlich ist.
Ich habe noch nicht durchschaut, was der Unterschied zwische Deinen Versionen und den , ich nenne sie mal "fhem-Versionen", ist. Ich dachte es ist die Möglichkeit, FSK-Protokolle zu empfangen, aber das geht jetzt wohl auch mit den fhem-Versionen?
Gruß
Sany
Die V 3.3.4 Firmware gibts nur für den cc1101.
Bei der V 3.3.2.1-rc9 gibts auch Firmware hex-Files ohne cc1101
https://github.com/Ralf9/SIGNALDuino/releases/tag/3.3.2.1-rc9
z.b. die "SIGNALduino_nano328_3321rc9.hex"
Bei der Firmware für den Arduino gibts für den cc1101 und RXB6 verschiedene hex-Files
Erst bei der V 4.x.x für den Maple Mini und ESP32 gibts für den cc1101 und RXB6 ein gemeinsame Firmware.
Gruß Ralf
So, habe auf beiden die angegebene Firmware geflashed, aber ohne Erfolg.
Damit es übersichtlich bleibt gehts ab jetzt erst mal nur um den Signalduino mit 868MHz Empfänger RX868SH-C3 (ELV Superhet Empfänger (Data-Pin an D2 vom Arduino,
Betrieb an 3,3V vom Arduino. Ich hoffe mal, das Signal wird erkannt, werde später mal mit Oszi nachmessen)).
List vom Signalduino:
Internals:
Clients :CUL_TCM97001:SD_WS:SD_WS07:SD_WS09:Hideki:LaCrosse:OREGON:CUL_EM:CUL_WS:CUL_TX:SD_AS:IT: :FS10:FS20:SOMFY:FLAMINGO:SD_WS_Maverick:KOPP_FC:PCA301:SD_BELL:SD_GT:SD_RSL:SD_UT:WMBUS: :CUL_FHTTK:FHT:RFXX10REC:Revolt:Dooya:Fernotron:SD_Keeloq:SD_Rojaflex:Siro:SD_Tool:SIGNALduino_un:
ClientsKeepOrder 1
DEF /dev/serial/by-path/platform-3f980000.usb-usb-0:1.5:1.0-port0@57600
DMSG nothing
DevState initialized
DeviceName /dev/serial/by-path/platform-3f980000.usb-usb-0:1.5:1.0-port0@57600
FD 10
FUUID 6224c651-f33f-833f-4751-2ccea7406d3d0238
IDsNoDispatch 2,43.1,72.1,82,87,88
LASTDMSG nothing
LASTDMSGID nothing
NAME signal868all_duino
NR 25
PARTIAL
STATE opened
TIME 1646830801
TYPE SIGNALduino
sendworking 0
version V 3.3.2.1-rc9 SIGNALduino - compiled at Jun 16 2019 18:11:42
versionmodul v3.4.10-dev_ralf_12.02.
versionprotoL v3.4.10-dev_ralf_16.02.
MatchList:
01:IT ^i......
02:CUL_TCM97001 ^s[A-Fa-f0-9]+
03:SD_RSL ^P1#[A-Fa-f0-9]{8}
04:OREGON ^(3[8-9A-F]|[4-6][0-9A-F]|7[0-8]).*
05:CUL_TX ^TX..........
06:SD_AS ^P2#[A-Fa-f0-9]{7,8}
07:Hideki ^P12#75[A-F0-9]+
09:CUL_FHTTK ^T[A-F0-9]{8}
10:SD_WS07 ^P7#[A-Fa-f0-9]{6}[AFaf][A-Fa-f0-9]{2,3}
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 ^P(?:14|20|24|26|29|30|34|46|56|68|69|76|78|81|83|86|90|91|91.1|92|93|95|97|99|104|105|114|118)#.*
18:FLAMINGO ^P13\.?1?#[A-Fa-f0-9]+
19:CUL_WS ^K[A-Fa-f0-9]{5,}
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
25:CUL_EM ^E0.................
26:Fernotron ^P82#.*
27:SD_BELL ^P(?:15|32|41|42|57|79|96|98|112)#.*
28:SD_Keeloq ^P(?:87|88)#.*
29:SD_GT ^P49#[A-Fa-f0-9]+
30:LaCrosse ^(\S+\s+9 |OK\sWS\s)
31:KOPP_FC ^kr..................
32:PCA301 ^\S+\s+24
33:SD_Rojaflex ^P109#[A-Fa-f0-9]+
34:WMBUS ^b.*
90:SD_Tool ^pt([0-9]+(\.[0-9])?)(#.*)?
X:SIGNALduino_un ^[u]\d+#.*
QUEUE:
READINGS:
2022-03-06 20:46:23 cmdBank Unsupported command
2022-03-11 09:21:26 cmds V R t X S P C r W
2022-03-11 09:21:31 config MS=1;MU=1;MC=1;Mred=1;Mdebug=1_MScnt=4;MuSplitThresh=8000;MdebFifoLimit=120/140
2022-03-11 09:21:37 freeram 589
2022-03-11 09:21:43 ping OK
2022-03-10 20:35:20 raw Unsupported command
2022-03-06 18:32:16 rfmode SlowRF_ccFactoryReset => ccFactoryReset done
2022-03-11 09:04:02 state opened
2022-03-11 09:21:50 uptime 0 00:17:50
2022-03-11 09:21:55 version V 3.3.2.1-rc9 SIGNALduino - compiled at Jun 16 2019 18:11:42
getcmd:
helper:
avrdudelogs flashing Arduino signal868all_duino
hex file: FHEM/firmware/SIGNALduino_nano328_3321rc9.hex
port: /dev/serial/by-path/platform-3f980000.usb-usb-0:1.5:1.0-port0
host: /dev/serial/by-path/platform-3f980000.usb-usb-0.5:1.0-port0
log file: ./log/SIGNALduino-Flash.log
signal868all_duino closed
command: avrdude -c arduino -b 115200 -P /dev/serial/by-path/platform-3f980000.usb-usb-0:1.5:1.0-port0 -p atmega328p -vv -U flash:w:FHEM/firmware/SIGNALduino_nano328_3321rc9.hex 2>./log/SIGNALduino-Flash.log
ERROR: avrdude exited with error--- AVRDUDE ---------------------------------------------------------------------------------
avrdude: Version 6.3-20171130
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2014 Joerg Wunsch
System wide configuration file is "/etc/avrdude.conf"
User configuration file is "/opt/fhem/.avrduderc"
User configuration file does not exist or is not a regular file, skipping
Using Port : /dev/serial/by-path/platform-3f980000.usb-usb-0:1.5:1.0-port0
Using Programmer : arduino
Overriding Baud Rate : 115200
AVR Part : ATmega328P
Chip Erase delay : 9000 us
PAGEL : PD7
BS2 : PC2
RESET disposition : dedicated
RETRY pulse : SCK
serial program mode : yes
parallel program mode : yes
Timeout : 200
StabDelay : 100
CmdexeDelay : 25
SyncLoops : 32
ByteDelay : 0
PollIndex : 3
PollValue : 0x53
Memory Detail :
Block Poll Page Polled
Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
eeprom 65 20 4 0 no 1024 4 0 3600 3600 0xff 0xff
flash 65 6 128 0 yes 32768 128 256 4500 4500 0xff 0xff
lfuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
hfuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
efuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
lock 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
calibration 0 0 0 0 no 1 0 0 0 0 0x00 0x00
signature 0 0 0 0 no 3 0 0 0 0 0x00 0x00
Programmer Type : Arduino
Description : Arduino
Hardware Version: 3
Firmware Version: 4.4
Vtarget : 0.3 V
Varef : 0.3 V
Oscillator : 28.800 kHz
SCK period : 3.3 us
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.00s
avrdude: Device signature = 0x1e950f (probably m328p)
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "FHEM/firmware/SIGNALduino_nano328_3321rc9.hex"
avrdude: input file FHEM/firmware/SIGNALduino_nano328_3321rc9.hex auto detected as Intel Hex
avrdude: writing flash (23040 bytes):
Writing | ################################################## | 100% 4.20s
avrdude: 23040 bytes of flash written
avrdude: verifying flash memory against FHEM/firmware/SIGNALduino_nano328_3321rc9.hex:
avrdude: load data flash data from input file FHEM/firmware/SIGNALduino_nano328_3321rc9.hex:
avrdude: input file FHEM/firmware/SIGNALduino_nano328_3321rc9.hex auto detected as Intel Hex
avrdude: input file FHEM/firmware/SIGNALduino_nano328_3321rc9.hex contains 23040 bytes
avrdude: reading on-chip flash data:
Reading | ###########
avrdude: stk500_paged_load(): (a) protocol error, expect=0x10, resp=0x66
avrdude: stk500_cmd(): programmer is out of sync
avr_read(): error reading address 0x0000
read operation not supported for memory "flash"
avrdude: failed to read all of flash memory, rc=-2
avrdude: stk500_disable(): protocol error, expect=0x14, resp=0x06
avrdude done. Thank you.
--- AVRDUDE ---------------------------------------------------------------------------------
signal868all_duino opened
keepalive:
ok 0
retry 0
mcIdList:
10
11
12
18
43
47
52
57
58
96
mnIdList:
100
101
102
103
107
108
109
112
115
116
201
202
203
204
205
206
207
208
209
210
msIdList:
0
0.1
0.2
0.3
0.4
0.5
1
3
3.1
4
6
7
13
13.2
14
15
17
20
23
25
32.1
33
33.1
33.2
35
41
49
51
53
54.1
55
65
68
74.1
90
91.1
93
106
113
118.1
muIdList:
8
9
13.1
16
17.1
19
21
22
24
26
27
28
29
30
31
32
34
36
37
38
39
40
42
44
44.1
45
46
48
49.1
49.2
50
54
56
59
60
61
62
64
66
67
69
70
71
72
73
74
78
79
80
81
83
84
85
86
89
91
92
94
95
97
98
99
104
105
110
111
114
118
200
rfmodesets:
rfmode Avantek_433__B8_N9_FSK,Bresser_5in1_u_7in1__B28_N7_8220,Bresser_6in1__B20_N7_8220,DP100_WH51_WH57_433__B16_N16_17241,DP100_WH51_WH57_868__B16_N6_17241,HoneywActivL__SlowRf_FSK,KOPP_FC__B20_N4_4785,Lacrosse_mode1__B12_N1_17241,Lacrosse_mode2__B12_N2_9579,PCA301_mode3__B32_N3_6631,Rojaflex_433__B12_N8_GFSK,SlowRF_ccFactoryReset,W136__B24_N10_4798,WH24_WH25__B20_N1_17241,WMBus_S__N11_ab_firmware_V422,WMBus_T_u_C__N12_ab_firmw_V422,WS1600_TX22_mode5__B16_N5_8842
Attributes:
devStateIcon opened:arduino\lime diconnected:arduino@red
hardware nano328_optiboot
room SignalDuino
updateChannelFW Ralf9
verbose 5Zitat00_SIGNALduino.pm 3410 2022-02-12 22:00:00Z v3.4.10-dev-Ralf9
signalduino_protocols.pm 3410 2022-02-16 22:00:00Z v3.4.10-dev-Ralf9
und ein Log-Auszug nach einem Reset:
2022.03.11 09:26:20.675 3: signal868all_duino reset
2022.03.11 09:26:20.677 3: Opening signal868all_duino device /dev/serial/by-path/platform-3f980000.usb-usb-0:1.5:1.0-port0
2022.03.11 09:26:20.681 3: Setting signal868all_duino serial parameters to 57600,8,N,1
2022.03.11 09:26:20.684 1: signal868all_duino/define: /dev/serial/by-path/platform-3f980000.usb-usb-0:1.5:1.0-port0@57600
2022.03.11 09:26:20.685 1: signal868all_duino/init: /dev/serial/by-path/platform-3f980000.usb-usb-0:1.5:1.0-port0@57600
2022.03.11 09:26:20.685 3: signal868all_duino device opened
2022.03.11 09:26:22.291 4: signal868all_duino/msg READ: Using sFIFO
2022.03.11 09:26:22.292 5: signal868all_duino/noMsg Parse: Using sFIFO
2022.03.11 09:26:22.297 4: signal868all_duino/msg READ: Reading values from eeprom
2022.03.11 09:26:22.298 5: signal868all_duino/noMsg Parse: Reading values from eeprom
2022.03.11 09:26:22.298 4: signal868all_duino/msg READ: Starting timerjob
2022.03.11 09:26:22.298 5: signal868all_duino/noMsg Parse: Starting timerjob
2022.03.11 09:26:22.341 4: signal868all_duino/msg READ: receiver enabled
2022.03.11 09:26:22.342 5: signal868all_duino/noMsg Parse: receiver enabled
2022.03.11 09:26:23.186 3: signal868all_duino/init: disable receiver (XQ)
2022.03.11 09:26:23.187 5: signal868all_duino SW: XQ
2022.03.11 09:26:23.686 3: signal868all_duino/init: get version, retry = 0
2022.03.11 09:26:23.687 5: signal868all_duino SW: V
2022.03.11 09:26:23.702 4: signal868all_duino/msg READ: V 3.3.2.1-rc9 SIGNALduino - compiled at Jun 16 2019 18:11:42
2022.03.11 09:26:23.703 5: signal868all_duino/noMsg Parse: V 3.3.2.1-rc9 SIGNALduino - compiled at Jun 16 2019 18:11:42
2022.03.11 09:26:23.704 4: signal868all_duino/msg READ: regexp=V\s.*SIGNAL(duino|ESP).* cmd=version msg=V 3.3.2.1-rc9 SIGNALduino - compiled at Jun 16 2019 18:11:42
2022.03.11 09:26:23.709 3: signal868all_duino/init: firmwareversion without cc1101 found
2022.03.11 09:26:23.710 2: signal868all_duino: initialized. v3.4.10-dev_ralf_12.02.
2022.03.11 09:26:23.711 5: signal868all_duino SW: XE
2022.03.11 09:26:23.721 3: signal868all_duino/init: enable receiver (XE)
2022.03.11 09:27:23.746 4: signal868all_duino/KeepAlive not ok, retry = 1 -> get ping
2022.03.11 09:27:23.747 5: AddSendQueue: signal868all_duino: P (1)
2022.03.11 09:27:23.848 5: signal868all_duino SW: P
2022.03.11 09:27:23.868 4: signal868all_duino/msg READ: OK
2022.03.11 09:27:23.868 5: signal868all_duino/noMsg Parse: OK
2022.03.11 09:27:23.868 4: signal868all_duino/msg READ: regexp=^OK$ cmd=ping msg=OK
2022.03.11 09:27:24.159 4: signal868all_duino/HandleWriteQueue: nothing to send, stopping timer
2022.03.11 09:28:23.772 4: signal868all_duino/keepalive ok, retry = 0
2022.03.11 09:29:23.797 4: signal868all_duino/KeepAlive not ok, retry = 1 -> get ping
2022.03.11 09:29:23.798 5: AddSendQueue: signal868all_duino: P (1)
2022.03.11 09:29:23.898 5: signal868all_duino SW: P
2022.03.11 09:29:23.909 4: signal868all_duino/msg READ: OK
2022.03.11 09:29:23.909 5: signal868all_duino/noMsg Parse: OK
2022.03.11 09:29:23.909 4: signal868all_duino/msg READ: regexp=^OK$ cmd=ping msg=OK
2022.03.11 09:29:24.209 4: signal868all_duino/HandleWriteQueue: nothing to send, stopping timer
2022.03.11 09:30:23.814 4: signal868all_duino/keepalive ok, retry = 0
(in der letzten Minute habe ich ein paar Tasten einer FS20 Fernbedienung gedrückt)
ZitatBetrieb an 3,3V vom Arduino
Warum 3.3 V? Der nano arbeitet mit 5V und der RX868SH kann auch 5V
ZitatSpannungsversorgung 2,3–5,5 V
sorry, hab ich wohl mit dem c1101 verwechselt. Ja, der ELV-Receiver kann 5V und ist auch da dran angeschlossen.
Hallo Ralf9,
Zitatder ELV-Receiver kann 5V und ist auch da dran angeschlossen.
Das alleine hat aber nicht gereicht: ich habe dann doch mal nachgemessen und festgestellt: am 5V-Pin vom Arduino kommt nix an. Warum das so ist habe ich nicht weiterverfolgt sondern einen neuen Arduino genommen und siehe da: geht!
Zuvor habe ich mir allerdings einen freien raspi frisch mit fhem versorgt und bin dann mit den Standard-Modulen erst mal weitergegangen. Auch den Arduino habe ich mit der SIGNALduino 3.5.0-dev Version geflashed. Meine FS20-Sender wurden sofort empfangen.
Nächster Kandidat war der SIGNALduino mit dem RXB6: Das ist noch auf einem Steckbrett zusammengesteckt und hier war ein Drähtchen leicht rausgerutscht, gesehen hat man das nicht, aber der Kontakt war weg. Nach Korrektur hat auch der wieder funktioniert.
Last but not least habe ich dann den Signalduino mit cc1101 auch umgeflashed und angeschlossen, die Einstellungen für das cc1101 überprüft und schon war die Wetterstation auch wieder eingebunden. Einziger Unterschied: die kmh-Readings für Wind und Gust fehlen, habe mir die per UserReadings nachgebaut.
attr WxStation userReadings windSpeed_kmh:windSpeed.* {sprintf("%.1f",ReadingsNum($name,"windSpeed",0)*3.6)},windGust_kmh:windGust.* {sprintf("%.1f",ReadingsNum($name,"windGust",0)*3.6)}
Somit läuft mein Zeug erst mal, allerdings jetzt halt mit den Standard SIGNALduino Modulen, die per Update verteilt werden.
eine letzte Frage: kann man mit SIGNALduino auch die HMS-Sensoren empfangen? Das ist ja irgendwie FS20.
Gruß
Sany
Zitatkann man mit SIGNALduino auch die HMS-Sensoren empfangen?
Die HMS können vermutlich z.Zt. nicht empfangen werden, ich konnte in der Signalduino Protokolliste nichts darüber finden.
Bitte poste mal ein paar raw Nachrichten die Du mit dem sduino von den HMS-Sensoren empfängst.
ich hoffe das sit richtig so, habe den signalduino auf verbose 4 gestellt und etwas "gelauscht".Parallel dazu den Eventmonitor mit Filter auf HMS. Das ergibt folgendes:
(zuerst 2 Zeilen vom HMS, danach die Zeielen aus dem Log)
Zitat2022-03-15 16:25:55.345 HMS TF_OAT2 temperature: 6.4
2022-03-15 16:25:55.345 HMS TF_OAT2 humidity: 99.1
2022.03.15 16:25:55 4: signal868all_duino: Read, msg: MC;LL=-1023;LH=974;SL=-498;SH=510;D=AFF3FFC;C=500;L=26;
--------------------
2022-03-15 16:28:39.572 HMS TF_OAT temperature: 6.7
2022-03-15 16:28:39.572 HMS TF_OAT humidity: 94.1
2022.03.15 16:28:39 4: signal868all_duino: Read, msg: MC;LL=-1023;LH=987;SL=-505;SH=513;D=5555555554;C=504;L=40;
2022.03.15 16:28:39 4: signal868all_duino: Parse_MC, Found manchester protocol id 52 clock 504 -> Oregon Scientific PIR
2022.03.15 16:28:40 4: signal868all_duino: Read, msg READredu: MU;P0=-128;P1=1408;P2=116;P3=-364;P4=244;P5=360;P6=-248;P7=484;D=01020202020202020202020202020202020202320405020267;CP=2;
--------------------
2022-03-15 16:31:08.343 HMS TF_OAT2 temperature: 6.4
2022-03-15 16:31:08.343 HMS TF_OAT2 humidity: 99.2
2022.03.15 16:31:08 4: signal868all_duino: Read, msg READredu: MU;P0=-740;P1=232;P2=-1024;P3=508;P4=-497;P5=996;D=012343434343434345432343434343434343434343434;CP=3;
2022.03.15 16:31:08 4: signal868all_duino: Parse_MU, Fingerprint for MU protocol id 8 -> TX3 Protocol matches, trying to demodulate
2022.03.15 16:31:08 4: signal868all_duino: Parse_MU, Fingerprint for MU protocol id 9 -> weather matches, trying to demodulate
2022.03.15 16:31:08 4: signal868all_duino: Parse_MU, Fingerprint for MU protocol id 19 -> minify matches, trying to demodulate
2022.03.15 16:31:08 4: signal868all_duino: Parse_MU, Fingerprint for MU protocol id 34 -> QUIGG | LIBRA | Mandolyn | Pollin ISOTRONIC matches, trying to demodulate
2022.03.15 16:31:08 4: signal868all_duino: Parse_MU, Fingerprint for MU protocol id 37 -> Bresser 7009994 matches, trying to demodulate
2022.03.15 16:31:08 4: signal868all_duino: Parse_MU, Fingerprint for MU protocol id 38 -> NC-3911 matches, trying to demodulate
2022.03.15 16:31:08 4: signal868all_duino: Parse_MU, Fingerprint for MU protocol id 40 -> Romotec matches, trying to demodulate
2022.03.15 16:31:08 4: signal868all_duino: Parse_MU, Fingerprint for MU protocol id 42 -> wireless doorbell matches, trying to demodulate
2022.03.15 16:31:08 4: signal868all_duino: Parse_MU, Fingerprint for MU protocol id 50 -> Opus_XT300 matches, trying to demodulate
2022.03.15 16:31:08 4: signal868all_duino: Parse_MU, Fingerprint for MU protocol id 54 -> TFA 30.3233.01 matches, trying to demodulate
2022.03.15 16:31:08 4: signal868all_duino: Parse_MU, Fingerprint for MU protocol id 61 -> FS10 matches, trying to demodulate
2022.03.15 16:31:08 4: signal868all_duino: Parse_MU, Fingerprint for MU protocol id 64 -> WH2 matches, trying to demodulate
2022.03.15 16:31:08 4: signal868all_duino: Parse_MU, Fingerprint for MU protocol id 70 -> FHT80TF matches, trying to demodulate
2022.03.15 16:31:08 4: signal868all_duino: Parse_MU, Fingerprint for MU protocol id 73 -> FHT80 matches, trying to demodulate
2022.03.15 16:31:08 4: signal868all_duino: Parse_MU, Fingerprint for MU protocol id 74 -> FS20 matches, trying to demodulate
2022.03.15 16:31:08 4: signal868all_duino: Parse_MU, Fingerprint for MU protocol id 80 -> EM1000WZ matches, trying to demodulate
2022.03.15 16:31:08 4: signal868all_duino: Parse_MU, Fingerprint for MU protocol id 85 -> TFA 30.3222.02 matches, trying to demodulate
2022.03.15 16:31:08 4: signal868all_duino: Parse_MU, Fingerprint for MU protocol id 89 -> TFA 30.3221.02 matches, trying to demodulate
--------------------
2022-03-15 16:33:52.370 HMS TF_OAT temperature: 6.7
2022-03-15 16:33:52.370 HMS TF_OAT humidity: 94.2
2022.03.15 16:33:52 4: signal868all_duino: Read, msg READredu: MU;P0=-488;P1=-129;P2=118;P3=-368;P4=240;P5=360;P6=-252;P7=482;D=121212121212121212121212121212121232141512126702371;CP=2;
2022.03.15 16:33:52 4: signal868all_duino: Parse_MU, Fingerprint for MU protocol id 8 -> TX3 Protocol matches, trying to demodulate
2022.03.15 16:33:52 4: signal868all_duino: Parse_MU, Fingerprint for MU protocol id 61 -> FS10 matches, trying to demodulate
2022.03.15 16:33:52 4: signal868all_duino: Parse_MU, Fingerprint for MU protocol id 70 -> FHT80TF matches, trying to demodulate
2022.03.15 16:33:52 4: signal868all_duino: Parse_MU, Fingerprint for MU protocol id 73 -> FHT80 matches, trying to demodulate
2022.03.15 16:33:52 4: signal868all_duino: Parse_MU, Fingerprint for MU protocol id 74 -> FS20 matches, trying to demodulate
2022.03.15 16:33:52 4: signal868all_duino: Parse_MU, Fingerprint for MU protocol id 80 -> EM1000WZ matches, trying to demodulate
2022.03.15 16:33:52 4: signal868all_duino: Read, msg: MC;LL=-1024;LH=990;SL=-542;SH=494;D=5555555554;C=508;L=40;
2022.03.15 16:33:52 4: signal868all_duino: Parse_MC, Found manchester protocol id 52 clock 508 -> Oregon Scientific PIR
Irgendwas passt da nicht so richtig. Ich habe dafür bei SlowRF ein neues Thema angefangen
https://forum.fhem.de/index.php/topic,126812.msg1213898.html#msg1213898
Es gibt seit 29.05.22 für FSK eine neue Version V3.3.5, es ist dafür mein 00_SIGNALDuino Modul ab v3.4.13-dev_ralf_29.05. notwendig
https://github.com/Ralf9/SIGNALDuino/releases/tag/3.3.5-dev220529
Es gibt für die Firmware V3.3.5 und die kommende V4.2.2 optimierte cc1101 Registerkonfigurationen rfmodeTesting,
Bei dem 00_SIGNALDuino Modul ab v3.4.13-dev_ralf_29.05. gibts ein neues Attribut "rfmode_testing", damit wird bei set ein neuer Eintrag "rfmodeTesting" aktiviert
Gruß Ralf
Hallo,
ich hab aktuell ein Problem mit meinem Doppel-CUL, auf dem ich die Firmware V 4.1.2-dev210205 SIGNALduinoAdv cc1101 (R: A- Bi*) - compiled at Feb 6 2021 00:26:38 installiert habe.
Anscheinend funktioniert das Modul A nicht mehr. Wenn ich versuche das Modul zu aktivieren
get sduino raw bA4bekomme ich als Rückmeldung:
raw: radio is not aktive!
Versuche ich das Modul einzuschalten
get sduino raw XEAKommt eine leere Messagebox zurück
Oder mit
get sduino raw CREAkommt
raw: detect A: timeout, no cc1101
Gibt es irgendeine andere Variante des Einschaltens? Oder kann es sein, dass der Empfänger defekt ist? Ich hatte irgendwann mal die Situation, dass ich die Antennenbuchse angefasst hatte und dabei leicht einen gewischt bekommen habe. Modul B funktioniert übrigens einwandfrei. Für Hinweise wäre ich sehr dankbar.
Zitat von: beaune am 05 Mai 2023, 10:10:42raw: detect A: timeout, no cc1101
ja, es sieht so aus, dass das cc1101 Modul defekt ist oder eine Lötstelle schlecht ist.
Beim CREx Befehl wird u.a. ein cc1101 Reset gemacht und dann ca 2ms auf eine Bestätigung (MISO Pin auf low) gewartet
Gruß Ralf
@Ralf9
Hallo Ralf super Arbeit. Ich habe schon einiges darüber gelesen, jedoch konnte ich aus dem hier im Forum und auf deiner Github Seite nichts über den ESP8266 lesen. Wird der nicht unterstützt? Auf Basis dessen habe ich einen Sduino mit dem cc1101.
Danke
Gruß
Uli
Hallo Uli,
nein, der ESP8266 wird von meiner Firmware nicht unterstützt.
Bei Slowrf (ASK/OOK) sollte es mit der Firmware von Sidey auch mit meiner Variante des 00_SIGNALDuino Moduls funktionieren.
Gruß Ralf
Danke. Habe es jetzt am SduinoNano am laufen. Mein alte WH1080 (Pollin WS 0101) ist am sterben, ab und zu mal eine Verbindung. Schade...
Jetzt hängt als Ersatz eine Bresser 5 in 1 am Nano, deshalb ja auch deine FW. Dank DIR funktioniert es!
Jetzt mal die Stabilität testen.
Wollte mit dem ESP8266 sduino flexibler mit der Platzierung sein. Aber ich denke es sollte auch so gehen.
Gruß
Uli