Signalduino Entwicklung

pejonp · 26 September 2015, 23:15:54

Zitat von: PeMue am 26 September 2015, 18:26:16
... weißt Du wie die baugleichen TFA Sensoren heißen? Habe nur was von Hama
http://www.amazon.de/Hama-Au%C3%9Fensensor-Erweiterung-Wetterstationen-wetterfest/dp/B005D6ZCQS/ref=sr_1_fkmr0_1?s=garden&ie=UTF8&qid=1443284653&sr=1-1-fkmr0&keywords=TFA+Aussensensor
gefunden, die sehen gleich aus ...
..

Hallo PeMue,

ich kann die leider nicht sagen ob dieser Sensor paßt. Sieht bald nurnach Thermometer aus, ohne Hygro.

Tschüss Jörg

PS: Lauf Forum (http://forum.fhem.de/index.php/topic,16462.msg113426.html#msg113426) soll dieser hier kompatibel sein: TFA TS34C .

Sidey · 27 September 2015, 11:02:32

Hallo Jörg,

ich habe mir die Unterschiede mal angesehen.
Versuchen wir erst mal das Problem mit WS0002 und Auriol in den Griff zu bekommen.

Zitat von: pejonp am 26 September 2015, 23:04:53
als Anlage die Module die mit beiden RF-Empfängern laufen und OREGON (THGR328N), Bresser (Cresta), Pearl NC-7159, WS0002, AURIOL (PRF-130) und manchmal auch Lifetec (ASB700) empfangen.

Dazu brauche ich deine Hilfe:

1. Probier mal die Module aus folgender Revision:
https://github.com/RFD-FHEM/RFFHEM/tree/359d702b36c1f542caf5a324f4b50e30e51f303b

Ich nehme an, mit denen funktioniert es nicht.

2. Probiere folgende Revision:
https://github.com/RFD-FHEM/RFFHEM/tree/0b33643a62061aaf03f5f923c7e8385c777705bb

Ich nehme an, damit funktioniert es wieder.

Die Dateien musst Du vermutlich manuell installieren, ein downgrade funktioniert denke ich nicht.

Wenn meine Annahmen zutreffen, dann müssten wir das Signal einer WS0002 mit dem aktuellsten Modul mal debuggen.
Das hilft vermutlich auch beim Lifetec.

Grüße Sidey

pejonp · 27 September 2015, 15:36:24

Zitat von: Sidey am 27 September 2015, 11:02:32
... wir erst mal das Problem mit WS0002 und Auriol in den Griff zu bekommen.

Hallo Sidey,

haqbe 1. und 2. ausprobiert. Bei 2. habe ich alle Sensoren empfangen.

Danach ein Update auf dev-cresta gemacht.
Empfänger (A): besserer RF-Empfänger
Empfänger (B): Empfänger ist aus der Wetterstation vom WS0001, etwas unempfindlicher.

Der A empfängt die AURIOL und ASB700. Und der B die Pearl und WS0002 Sensoren. Den OREGON empfangen beide.
Die Bresser werden vom A beide empfangen und vom B nur einer, da dort die Entfernung kürzer ist.

Habe danach ein Update auf dec-rawin gemacht. FHEM stürzt ab mit Fehler:

2015.09.27 15:33:55 4: SIGNALduino/msg READ: MS;P0=476;P1=-3905;P2=-1941;P3=-9145;P4=767;P5=24292;P6=1371;D=03020102010101010202010101010201020202020201010202010201010202010102020101;CP=0;SP=3;
2015.09.27 15:33:55 4: SIGNALduino/msg READ: MS;P0=-3424;P1=506;P2=-3893;P3=-1941;P4=-9205;D=14131213121313121213131313121313131313131312121213131313131313121213131312;CP=1;SP=4;
2015.09.27 15:33:55 4: SIGNALduino/msg READ: MS;P0=502;P1=-1940;P2=-3895;P3=-9216;D=03010201020101020201010101020101010101010102020201010101010101020201010102;CP=0;SP=3;
2015.09.27 15:33:55 4: Dropped (s53080E031000) due to short time or equal msg
2015.09.27 15:33:57 4: SIGNALduino/msg READ: MS;P0=-1940;P1=409;P2=-3895;P3=-9088;P4=767;P5=24096;P6=1371;D=131454102;CP=1;SP=3;
2015.09.27 15:33:57 4: SIGNALduino/msg READ: MC;LL=-1044;LH=912;SL=-553;SH=421;D=4BA53279F4E6AA5C1A80;C=444;
2015.09.27 15:33:57 4: SIGNALduino/msg READ: MC;LL=-1039;LH=909;SL=-556;SH=428;D=AE2E974A24F3E9CD54BA1B00;C=445;
2015.09.27 15:33:57 4: Cresta_Parse sduino incomming 5875BABA8AF2BECE555D6C00
2015.09.27 15:33:57 4: bytes arr->9fcece9e16c252ffe7b400
2015.09.27 15:33:57 4: bytes hex->9fcece9e16c252ffe7b400
2015.09.27 15:33:58 4: SensorTyp=30, 158
Undefined subroutine &main::SIGNALDuino_use_longid called at ./FHEM/14_Cresta.pm line 135.

Habe erst gedacht hängt am Verbose 5, war aber nicht so. Stürzt auch bei Verbose 4 ab.

Ich würde mal vermuten beim Aufteilen der Daten für NC_WS, AUROL, WS0002 usw. geht etwas schief.

Jörg

Sidey · 27 September 2015, 16:04:38

Hi Jörg,

kannst Du dem WS0002 eine Ausgabe vom Typ MS zuordnen?

Beispiel einer Ausgabe:

Code Auswählen

SIGNALduino/msg READ: MS;P0=-1940;P1=409;P2=-3895;P3=-9088;P4=767;P5=24096;P6=1371;D=131454102;CP=1;SP=3;

Die sollten ab Verbose 5 dargestellt werden. Der Absturz liegt an einem Programmierfehler. Schaue ich mir später an. Es hat mit den logids zu tun. Irgendwas passt da jetzt nicht zusammen.

Grüße Sidey

pejonp · 27 September 2015, 19:16:58

Zitat von: Sidey am 27 September 2015, 16:04:38
....
kannst Du dem WS0002 eine Ausgabe vom Typ MS zuordnen?

Code Auswählen Erweitern
SIGNALduino/msg READ: MS;P0=-1940;P1=409;P2=-3895;P3=-9088;P4=767;P5=24096;P6=1371;D=131454102;CP=1;SP=3;
...
der Absturz liegt an einem Programmierfehler ...

Hallo Sidey,

die fehlende Funktion habe ich in 00_Signalduino.pm reinkopiert (bei mir lokal). Geht jetzt. Als Anlage die Logdateien. Ich hoffe du kannst damit etwas anfangen. EmpfängerA hat die Liftect (ABS700) und AURIOL empfangen. Und EmpfängerB hat Pearl und WS0002 empfangen. OREGON und Cresta haben beide empfangen, EmpfängerB aber nur einen Cresta wegen der Entfernung.

Jörg

Jörg

Sidey · 27 September 2015, 22:57:21

Hallo Jörg,

Zitat von: pejonp am 27 September 2015, 19:16:58

die fehlende Funktion habe ich in 00_Signalduino.pm reinkopiert (bei mir lokal).

Ah ok, ich verstehe wieso das Problem aufgetaucht ist. Du hattest noch die 14_Cresta.pm. Ich hab mir da schon was überlegt, werde ich in 14_Cresta und 14_SIGNALduino_ID7 anpassen.

Zitat von: pejonp am 27 September 2015, 19:16:58
Geht jetzt. Als Anlage die Logdateien. Ich hoffe du kannst damit etwas anfangen. EmpfängerA hat die Liftect (ABS700) und AURIOL empfangen. Und EmpfängerB hat Pearl und WS0002 empfangen. OREGON und Cresta haben beide empfangen, EmpfängerB aber nur einen Cresta wegen der Entfernung.

Also ich hab deine Logfiles durch, bei mir werden die folgenden 4 Geräte erzeugt und erhalten auch readings:
CUL_TCM97001_45
CUL_TCM97001_7
CUL_TCM97001_83
CUL_TCM97001_94

Getestet mir der aktuellsten Version.
Und das funktioniert bei dir mit der aktuellen Version nicht, habe ich das richtig verstanden?

Grüße Sidey

pejonp · 28 September 2015, 07:19:43

Hallo sidey
Wenn ich eine der versionen aus dem git lade geht es nicht. Nur bei version 2 aus dem Archiv ging es bzw. mit der die ich als zip angehangen habe.
Jörg

Sidey · 28 September 2015, 08:44:30

Moin Jörg,

Das ist jetzt komisch.
Dein Fhem ist aber keine Neuinstallation?

Sidey

pejonp · 28 September 2015, 12:05:19

Zitat von: Sidey am 28 September 2015, 08:44:30
Das ist jetzt komisch.
Dein Fhem ist aber keine Neuinstallation?
Sidey

Hallo sidey
Es ist keine Neuinstallation, ich installiere/ziehe über "Update all" in fhem die dateien aus dem git. Beim erstellen der logdateien zur Fehlersuche habe ich die fhem.cfg bereinigt und nur die signalduino Einträge eingetragen.
Bis zu einer bestimmten version von 00_Signalduino.pm wurden ja alle Werte empfangen. Kann es mit dem ctw600 zusammenhängen?
Jörg

Sidey · 28 September 2015, 13:40:15

Hallo Jörg,

Irgendwas habe ich über sehen.

Ich fasse noch mal zusammen:
Du hast 4 Sensoren, die vom CUL_TCM_97001 verarbeitet werden.

Mit dieser Revision werden die Daten nicht oder nur sehr selten verarbeitet:
https://github.com/RFD-FHEM/RFFHEM/tree/359d702b36c1f542caf5a324f4b50e30e51f303b

Mit der vorhergehenden Revision geht es:
https://github.com/RFD-FHEM/RFFHEM/tree/0b33643a62061aaf03f5f923c7e8385c777705bb

Die Unterschiede im Commit zwischen den Revisionen sind demnach ausschlaggebend.

Getestet hast Du mit zwei verschiedenen Empfängern am gleichen Arduino. In wie weit die Hardware Unterschiede nun etwas beeinflussen, weiss ich noch nicht. Da gibt es keinen Unterschied zu den festgestellten Auswirkungen oder?

In allen Tests lief die Firmware 3.1.5 auf dem Arduino.

Die Logs von gestern wurden mit der Revision 0b33 (siehe oben) erstellt.

Ich habe ein paar der Einträge durch die aktuelle Revision laufen lassen und es wurden insgesamt vier Sensoren erkannt.

Wenn ich mir das überlege, dann sollten wir kein Problem haben. Wenn das Modul bei mir eine MS Nachricht ordentlich demoduliert, bei dir aber nicht, dann frage ich mich, was habe ich übersehen.

Am ctw600 liegt es kaum.

Sidey

pejonp · 28 September 2015, 13:55:57

Hallo sidey
Ich werde versuchen heute noch einmal zu testen. An der HW kann es liegen. Wenn ich die Empfänger umstecke werden auf dem anderen die noch fehlenden Sensoren angelegt. Die schon vorhandenen nc_ws, Pearl, auriol oder asb700 werden dann aber nicht weiter mit Daten versorgt. Aber wie gesagt mit einer früheren Versions (siehe zip) ging es auf beiden. Ich mache noch ein paar Tests. Ich werde die Nano mal am pc mit der arduinoconsole betreiben und vergleichen.

Jörg

Sidey · 28 September 2015, 14:05:00

Hallo Jörg,

Wenn Du noch mal testest, dann mache folgendes mit den aktuellen Modulen:

Verbose 5
Debug 1

Wenn Du am Sensor erkennen kannst, wann der gesendet hat, dann poste mal das Log von dem Zeitraum.

Grüße Sidey

Sidey · 28 September 2015, 14:05:12

Hallo Jörg,

Wenn Du noch mal testest, dann mache folgendes mit den aktuellen Modulen:

Verbose 5
Debug 1

Wenn Du am Sensor erkennen kannst, wann der gesendet hat, dann poste mal das Log von dem Zeitraum.

Grüße Sidey

Hauswart · 28 September 2015, 18:21:26

Also meine FA21RF scheinen nichts zu senden (ohne Knopf drücken). Ich habe mit verbose 5 nur folgendes im Log:

Code Auswählen

2015.09.28 18:19:59 4: sduino: GetUpdate called ...
2015.09.28 18:19:59 5: sduino: command for gets: R 
2015.09.28 18:19:59 5: SW: R
2015.09.28 18:19:59 5: SIGNALduino/RAW (ReadAnswer): 885

2015.09.28 18:19:59 5: sduino: received message for gets: 885

2015.09.28 18:20:29 4: sduino: GetUpdate called ...
2015.09.28 18:20:29 5: sduino: command for gets: R 
2015.09.28 18:20:29 5: SW: R
2015.09.28 18:20:29 5: SIGNALduino/RAW (ReadAnswer): 885

2015.09.28 18:20:29 5: sduino: received message for gets: 885

Habe eben den Alarm ausgelöst (richtiger test mit Rauch), Rauchmelder gingen beide los, aber keine Einträge im Log bzw. die oben gezeigten wieder.

Sidey · 28 September 2015, 18:32:42

Oder dein Empfänger empfängt nichts. Wird denn was empfangen, wenn Du den Knopf drückst?

Sidey