SIGNALDuino Empfänger Firm- und Hardware

Sidey · 26 Januar 2017, 22:17:01

Zitat von: RaspII am 26 Januar 2017, 22:14:17
Man FHEM wohl beibringen, dass nach einem "FHEM Update" auch immer obiger Update mit ausgeführt wird, falls mir jemand eine Schnellbleiche geben kann: immer zu.

Das geht sogar:
https://wiki.fhem.de/wiki/Update#Repository-Verwaltung

RaspII · 26 Januar 2017, 22:47:18

Hat geklappt -> Danke

Ralf9 · 26 Januar 2017, 22:48:17

Zitat von: RaspII am 26 Januar 2017, 22:14:17
Jetzt bleibt nur noch das Problem mit dem Update der ICONs (attr WEB longpollSVG 1 hat nichts gebracht).

Du mußt Dich noch ein wenig mit den Attributen drive-up-time-... und drive-down-time-... beschäftigen, dann wird das auch noch was.

Gruß Ralf

RaspII · 27 Januar 2017, 09:23:01

Hab zwar nicht verstanden wo da der Zusammenhang ist, werde mich aber übers WE einlesen.
(Bei der Entwicklung der Kopp Implementierung habe ich mich am SOMFY.pm Modul orientiert, trotzdem reagiert die Oberfläche unterschiedlich)
Ich melde mich mit dem Ergebnis nach dem WE

Gesendet von meinem SM-G900F mit Tapatalk

pejonp · 27 Januar 2017, 15:28:46

Hallo Sidey, Ralf,

zur Zeit reagiert mein FHEM etwas träge. Ursache habe ich noch nicht so richtig gefunden. Perfmon läuft bei mir mit und zeigt es mir an.
Wiki: Modul perfmon überwacht das Antwortzeitverhalten von FHEM und erzeugt einen Eintrag in der Logdatei, wenn die Abarbeitung eines Ereignisses länger als eine Sekunde (1000 Millisekunden) dauert.
Sytem ist ein Odroid-C1 mit 2x SignalduinoCC1101 für 433 und 868 MHz. Sonst keine anderen Module. Ich habe den Odroid schon einmal neu aufgesetzt. Heute mach ich es noch einmal. DBLog läuft für die Logspeicherung in eine MySQL DB auf einem NAS.

Im Verdacht habe ich einen THR128 (siehe Bild). Der sendet diesen Code. Dieser wird noch nicht erkannt und die weitere Verarbeitung dauert zu lange ??:

Code Auswählen


2017.01.27 14:32:19 5: SD433: applying filterfunc SIGNALduino_compPattern
2017.01.27 14:32:19 4: SD433/msg READ: MC;LL=-2729;LH=3131;SL=-1255;SH=1666;D=DF5BBE2A;C=1463;L=31;R=47;
2017.01.27 14:32:19 4: SD433: Found manchester Protocol id 18 clock 1463 RSSI -50.5 -> OSV1
2017.01.27 14:32:19 5: SD433: extracted data 11011111010110111011111000101010 (bin)
2017.01.27 14:32:19 5: SD433: OSV1 protocol converted to hex: (0820A441D5) with length (8) bits

Heute hatte ich es, das zweimal solche Ausgaben kamen (siehe Anlage). Nach einer Weile fängt er sich wieder.
Die Daten habe ich mit einem CC110L empfangen.
V 3.3.1-dev SIGNALduino cc1101 - compiled at Jan 12 2017 23:04:38.
ccconf: freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:4dB (DataRate:5603.79Baud)

Version:
fhem.pl 13210 2017-01-23 17:16:54Z rudolfkoenig
98_autocreate.pm 11984 2016-08-19 12:47:50Z rudolfkoenig
14_CUL_TCM97001.pm 12994 2017-01-07 07:49:53Z bjoernh
93_DbLog.pm 13193 2017-01-22 20:00:41Z DS_Starter
91_eventTypes.pm 11984 2016-08-19 12:47:50Z rudolfkoenig
01_FHEMWEB.pm 13201 2017-01-23 09:56:46Z rudolfkoenig
92_FileLog.pm 13152 2017-01-20 09:04:34Z rudolfkoenig
14_Hideki.pm 14395 2017-01-23 18:00:00Z v3.3.1-dev
91_notify.pm 13207 2017-01-23 13:55:25Z rudolfkoenig
41_OREGON.pm 34476 2016-12-04 13:00:00Z dev
No Id found for 99_perfmon.pm
14_SD_WS09.pm 16018 2016-07-11 10:10:10Z pejonp
00_SIGNALduino.pm 10484 2017-01-22 15:00:00Z v3.3.1-dev
99_SUNRISE_EL.pm 12485 2016-11-01 15:18:51Z rudolfkoenig
98_SVG.pm 12482 2016-11-01 09:25:59Z rudolfkoenig
98_telnet.pm 13169 2017-01-21 13:28:14Z rudolfkoenig
99_Utils.pm 11984 2016-08-19 12:47:50Z rudolfkoenig
19_VBUSIF.pm 12980 2017-01-06 12:36:39Z Tobias.Faust
98_version.pm 11987 2016-08-19 17:13:41Z markusbloch

Vielleicht ist diese Verhalten ja schon bekannt oder andere haben so ein Verhalten auch schon festgestellt. Es funktioniert soweit alles, nur das die Anzeige in FHEM machmal etwas dauert.

Jörg

Ralf9 · 27 Januar 2017, 19:11:47

Zitatzur Zeit reagiert mein FHEM etwas träge. Ursache habe ich noch nicht so richtig gefunden. Perfmon läuft bei mir mit und zeigt es mir an.
Wiki: Modul perfmon überwacht das Antwortzeitverhalten von FHEM und erzeugt einen Eintrag in der Logdatei, wenn die Abarbeitung eines Ereignisses länger als eine Sekunde (1000 Millisekunden) dauert.

Mir sind im log recht viele unsinnige und unplausible Nachrichten aufgefallen.
@Sidey
Ist da evtl noch ein Bug in der Firmware? Kannst Du eine Abfrage einbauen, damit solche unplausible Nachrichten nicht übertragen erden?

Code Auswählen

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

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

Sidey · 27 Januar 2017, 20:06:03

Ja, das ist ein Bug.
Ich hab noch nicht raus, wieso das den Nachrichtenpuffer nicht resettet, da beide Werte ja das gleiche Vorzeichen haben.

Sidey · 27 Januar 2017, 23:30:28

Hallöchen,

Zitat von: pejonp am 27 Januar 2017, 15:28:46
zur Zeit reagiert mein FHEM etwas träge. Ursache habe ich noch nicht so richtig gefunden. Perfmon läuft bei mir mit und zeigt es mir an.

hmm, vielleicht hilft die apptime noch etwas weiter.
Ich habe mal eine deiner Nachrichten, die 5 Sekunden gebraucht hat bei mir durchgejagt:

Code Auswählen


2017.01.27 23:15:21.531 3: dummyDuino: Unknown code 0820CC419D, help me!
2017.01.27 23:15:21.497 5: dummyDuino: dispatch 0820CC419D
2017.01.27 23:15:21.492 5: dummyDuino: converted Data to (0820CC419D)

2017.01.27 23:15:21.491 5: dummyDuino: OSV1 protocol converted to hex: (0820CC419D) with length (8) bits 
2017.01.27 23:15:21.489 5: dummyDuino: extracted data 11011111001100111011111001100010 (bin)
2017.01.27 23:15:21.488 4: dummyDuino: Found manchester Protocol id 18 clock 1466 RSSI -56.5 -> OSV1
2017.01.27 23:15:21.484 4: dummyDuino/msg get raw: MC;LL=-2712;LH=3152;SL=-1252;SH=1681;D=DF33BE62;C=1466;L=31;R=35;

Das dauert auf einem Raspberry Pi 1 in diesem Beispiel 50 millisekunden. In einem anderen Versuch hängt da auch was etwa 1,6 Sekunden.

Code Auswählen


2017.01.27 23:21:37.817 3: dummyDuino: Unknown code 0820CC419D, help me!
2017.01.27 23:21:36.207 5: dummyDuino: dispatch 0820CC419D
2017.01.27 23:21:36.202 5: dummyDuino: converted Data to (0820CC419D)

Das Log ist bei dir nicht umgedreht, aber es dauert fast 5 Sekunden:

Code Auswählen


2017.01.27 14:32:48 4: SD433/msg READ: MC;LL=-2728;LH=3136;SL=-1262;SH=1668;D=DF33BE62;C=1465;L=31;R=37;
2017.01.27 14:32:48 4: SD433: Found manchester Protocol id 18 clock 1465 RSSI -55.5 -> OSV1
2017.01.27 14:32:48 5: SD433: extracted data 11011111001100111011111001100010 (bin)
2017.01.27 14:32:48 5: SD433: OSV1 protocol converted to hex: (0820CC419D) with length (8) bits 
2017.01.27 14:32:48 5: SD433: converted Data to (0820CC419D)
2017.01.27 14:32:48 5: SD433: dispatch 0820CC419D
2017.01.27 14:32:53 3: SD433: Unknown code 0820CC419D, help me!

Die Zeit vergeht nach dem Aufruf von Dispatch() (fhem.pl:3475) und vor (fhem.pl:3533).
Zwischen diesen Zeilen werden die Clientmodule durchprobiert.

Irgendein client Modul lässt sich vielleicht zeit?

Ralf9 · 28 Januar 2017, 00:38:30

Ich denke es ist am sinnvollsten das OSV1 vorläufig dem Modul SIGNALduino_un zuzuordnen

Code Auswählen

preamble		=> 'u18#',
modulematch     => '^u18#[0-9A-F].*',

Gruß Ralf

RaspII · 28 Januar 2017, 11:24:48

Zitat von: Ralf9 am 26 Januar 2017, 22:48:17
Du mußt Dich noch ein wenig mit den Attributen drive-up-time-... und drive-down-time-... beschäftigen, dann wird das auch noch was.

Gruß Ralf

Hab ich gemacht und schon klappts (ohne Longpoll)
Ich glaube ich habe das Prinzip verstanden, der Zustand ändert sich über die Zeit

Was ist der Unterschied zwischen den Attributen drive-up-time-to-100 und drive-up-time-to-open ?

Nachtrag:
Was mir noch fehlt, ist das sich meine ICONs (mit denen ich von FHEM aus die Rolläden steure) auch an den Status ändern, wenn via Somfy Fernbedienung (also anderer HEX Code) eine entsprechende Taste gedrückt ist. Ich habe da schon einige Infos gefunden wenn man den CUL zum senden und den FHEMduino zum Empfangen nimmt, verstanden habe ich das aber wenn ich ehrlich bin nicht.

Ansonsten denke ich das reicht fürs erste, jetzt geht es an die Praxis (mal schaun ob das Reichweitenproblem weg ist)

Wenn meine Implementierung jetzt in der Praxis funktioniert, würde ich die Erkenntnisse gerne in der Wiki dokumentieren.
Am besten geeignet finde ich hierfür die SOMFY Wiki,
https://wiki.fhem.de/wiki/SOMFY
dort könnte man z.B. einen Link auf "SOMFY via SIGNALduino" setzten und diese neue Seite anlegen.
Diese Seite könnte man auch in der SINGALduino WIKI verlinken.
Was meint Ihr?

HomeAuto_User · 28 Januar 2017, 12:49:20

Hallo,

die FW - SIGNALduino ist bisher nur für den Arduino Nano entwickelt. Wie ist der Stand für den Arduino Micro.
" ... muss die Firmware selbst compilieren."" Woher bekomme ich zum compilieren die Sourcen?

juergs · 28 Januar 2017, 12:52:44

Source hier unter https://wiki.fhem.de/wiki/SIGNALduino
Versteckt unter "github". unter https://github.com/RFD-FHEM/RFFHEM/tree/master
den passenden "Branch" auswählen.

HomeAuto_User · 28 Januar 2017, 13:33:14

Danke,
soweit war ich auch schon und nun "hapert" es das richtige zu finden.
Die Sourcen werden für den ATmega32u4 benötigt und nicht ATMega328

oder ich sehe langsam gar nicht mehr durch

Sidey · 28 Januar 2017, 13:57:55

Den pro Micro gibt es mit atmega328 und atmega168.

pejonp · 28 Januar 2017, 14:04:31

Hallo HomeAuto_User,

wenn du den ATmega32u4 hast, müstest du in der IDE den Leonardo auswählen. Steht so beim radino CC1101 433 MHz. Bei mir konnte ich es kompilieren. Ob es geht kann ich nicht sagen.

Eigenschaften (radino CC1101 433 MHz):

Arduino-compatible (Arduino Micro / Leonardo)
ATmega32U4 High-Performance Low-Power Microcontroller
CC1101 mit 433 MHz Frontend
15 GPIOS (5 PWM, 5 Analog IN)
I²C, SPI, UART
USB (HID Keyboard & Mouse, virtual UART)

Beim radino32 CC1101 433 MHz - Modul ist ja ein STM32 verbaut, da wird es etwas schwieriger.

pejonp