Liebes Forum,
ich bin mit Protokolldekodierung eigentlich nicht ganz auf die Nase gefallen (siehe Projekte in meiner Sig), aber hier stehe ich wirklich auf dem Schlauch:
Nachdem ich als Weihnachtsbeigabe von Conrad die EuroChron EFTH-800 Wetterstation mit drei gleichnamigen Sendern bekommen habe (https://www.conrad.de/de/p/eurochron-efth-800-funk-thermo-hygrometer-schwarz-1719613.html), die auf 433 MHz funken, wollte ich diese in meine FHEM-Installation einbinden. Zur Verfügung steht mir ein auf CUL geflashter Max!Cube und ein Busware CC1101 CUL (letzteren müsste ich erst wieder ausgraben).
Nach einiger Starthilfe in dem "Alternative culfw"-Thread (https://forum.fhem.de/index.php/topic,35064.msg1004386.html#msg1004386) macht es aber wohl mehr Sinn, sich dem Thema in einem eigenen Thread zu widmen.
Neben dem Foto der Platine im Anhang sind dies Mitschnitte, die ich bereits gemacht habe (vorher CUL-Max aus FHEM per set CUL freq 433.92 umgestellt und rfmode auf SlowRF gesetzt), wenn auf einer frisch eingeschalteten Empfangsstation das erste Mal die Temperatur und Luftfeuchtigkeit übertragen wird:
(Temperatur, rel. Luftfeuchtigkeit, Kanal)
Raum 1 (Entfernung zum CUL-Max ca. 6 Meter, zwe Wände), Kanal 2:
omAAB5356C4A95C7 16,2 46 Kanal 2
omAA0AFFC000EFFF
omAAB0FC3FF1E000 16,2 46 Kanal 2
omAA000000000000
omAAB53D1815C040 15,8 47 Kanal 2
omAA0038003FFFFF80
omAAC535DBF6D006 15,9 47 Kanal 2
omAA0007FFFFC000
omAA0F99FDFE0006 15,9 47 Kanal 2
omAA000000000000
tA093C08F3C 15,8 47 Kanal 2
omAA000000000000
omAA000000000000 15,8 47 Kanal 2
omAA007FFE000000
Raum 2 (Entfernung zum CUL-Max ca. 10cm), Kanal 3:
omAA0003FE00000000 18,7 51 Kanal 3
omAA0000007E0000
omAA9FFD3CE98798 18,7 51 Kanal 3
omAA000000000000
omAA000000000000 18,8 51 Kanal 3
omAA000000000000
omAA0000FFFF0000 18,8 51 Kanal 3
omAA000000000001
omAA00003FFFFF8000 18,8 50 Kanal 3
omAA00001E00000000
omAA000001FF801F80 18,8 50 Kanal 3
omAA07FFFFFFFFFF
omAA000000000000 18,8 50 Kanal 3
omAA000000000000
Nachdem ich dann noch auf Anraten "set CUL sens 16" und "set bWidth 464" ausgeführt habe, sieht der Mitschnitt von Raum 2 so aus:
V 1.26.01 a-culfw Build: private build (unknown) CUBe (F-Band: 433MHz)
omAA00000000000035
omAA000000001FFF35
V 1.26.01 a-culfw Build: private build (unknown) CUBe (F-Band: 433MHz)
omAA000007FFFFFF35
omAA00000000000035
V 1.26.01 a-culfw Build: private build (unknown) CUBe (F-Band: 433MHz)
omAA00007FFFE00035
omAA000000001FFF33
V 1.26.01 a-culfw Build: private build (unknown) CUBe (F-Band: 433MHz)
omAA00000000003F8035
omAA0007FFFFFC3E35
V 1.26.01 a-culfw Build: private build (unknown) CUBe (F-Band: 433MHz)
omAA000000FFFFFF35
omAA000003FF800035
V 1.26.01 a-culfw Build: private build (unknown) CUBe (F-Band: 433MHz)
omAA00000000000035
V 1.26.01 a-culfw Build: private build (unknown) CUBe (F-Band: 433MHz)
omAA00000000000035
omAA000000001FFF35
V 1.26.01 a-culfw Build: private build (unknown) CUBe (F-Band: 433MHz)
omAC4AB69AA035
omAA00000000000035
V 1.26.01 a-culfw Build: private build (unknown) CUBe (F-Band: 433MHz)
omAA03FF8000001F35
omAA000000007FFF35
V 1.26.01 a-culfw Build: private build (unknown) CUBe (F-Band: 433MHz)
omAA00000000000035
omAA000000001FFF35
V 1.26.01 a-culfw Build: private build (unknown) CUBe (F-Band: 433MHz)
omAA07FFFFFFFFFF8035
omAA00000000FFFF35
V 1.26.01 a-culfw Build: private build (unknown) CUBe (F-Band: 433MHz)
omAA00000000000035
omAA00000000000F35
V 1.26.01 a-culfw Build: private build (unknown) CUBe (F-Band: 433MHz)
omAA00000FFFE00035
omAA00000000000035
V 1.26.01 a-culfw Build: private build (unknown) CUBe (F-Band: 433MHz)
omAA00000000000035
V 1.26.01 a-culfw Build: private build (unknown) CUBe (F-Band: 433MHz)
omAA0003FFFFFFFF8035
omAA07FFFFFFFFFF35
V 1.26.01 a-culfw Build: private build (unknown) CUBe (F-Band: 433MHz)
omAA000000007FFF35
omAA0000001FFFFF8035
V 1.26.01 a-culfw Build: private build (unknown) CUBe (F-Band: 433MHz)
omAA001FFFFFFFFC35
omAA000000001FFC35
(Ich habe die Firmware-Banner jetzt mal drin gelassen, um die Periodizität zu verdeutlichen)
In allen Fällen tauchen die zwei Telegramme immer zeitgleich auf. Da ich im letzten Mitschnitt auch die Empfangsstation ausgeschaltet habe, kann man auch sicher sein, dass das keins der Telegramme eine Art Empfangsbestätigung o.ä. ist.
Wie kann ich hier vorgehen, um das Protokoll weiter zu entschlüsseln? Es scheint mir nichts mit dem bisher in FHEM hinterlegten EuroChron Protokoll zu tun zu haben (das wohl auch auf Geräten mit 868MHz basiert).
Ich freue mich über jeden Hinweis und danke Euch dafür schon im Voraus,
F.
Möglicherweise ist auch die Interpretation aus dem CUL-Modul falsch, z.B. ein Telegramm in 2 zerstückelt u. vielleicht dazwischen auch noch was "vergessen"... Vielleicht passiert das aber auch in der culfw.
Bring den CUBE doch mal in den Debug-Modus(X67). Zumindest hat man dann auch mal Infos über Pulsweiten etc.
Danke, am CUL-Modul kann es nicht liegen, weil meine Mitschnitte eben alle von der culfw-Kommandoebene kommen. Hier drei Mitschnitte mit X67, alle drei mit Temperatur 18,5 Grad und 50% rel. Feuchte:
omAA000000001FBF35
p13 512 608 272 368 0 0 56 1 7 0 736 736 368 3B AA000000001FBF
omAA03FF8000000035
p13 448 496 272 384 0 0 56 1 7 0 752 720 368 32 AA03FF80000000
omAA00000000000034
p13 480 608 288 368 0 0 56 1 7 0 704 736 352 3C AA000000000000
omAA03FFFC00000034
p13 512 592 288 368 0 0 56 1 7 0 736 720 368 33 AA03FFFC000000
omAA00000000000034
p13 496 592 288 368 0 0 56 1 7 0 720 720 352 3F AA000000000000
omAA00000000000035
p13 480 608 288 352 0 0 56 1 7 0 704 752 352 33 AA000000000000
Mir sagen diese Werte leider nichts, kannst Du daraus etwas ableiten?
ggf. wäre die Signalduino-Firmware auf dem Busware-Cul was für dich, schau mal hier:
https://forum.fhem.de/index.php/topic,58397.1350.html (https://forum.fhem.de/index.php/topic,58397.1350.html)
Die Jungs da sind echte Spezis beim dekodieren.
Grüsse Christian
Oh, kann man die SignalDuino Firmware auf den Busware CUL flashen? Naja, hab' mir jetzt einen SignalDuino Stick bestellt, vielleicht kann der dann ja wirklich noch mehr Daten entlocken...
ZitatNaja, hab' mir jetzt einen SignalDuino Stick bestellt,
Besser ist das. Wer weiß, was der 868er bei der Analyse für Probleme macht, nur weil der Empfang zu schlecht ist.
Das ist dann ein 433-nanoCUL ? Fände ich die beste Variante, um auch die aculfw evtl. weiterentwickeln zu können, da der nano ja per "simplem" flashen beides kann.
Es ist dieses Teil hier, sieht mir nach Nano aus:
https://www.ebay.de/itm/SIGNALduino-433MHz-mit-SMA-Magnetfusantenne-5dbi/372667586853?hash=item56c4b81925:g:reYAAOSw3wVajTuC
Jepp, normaler nanoCUL ;-) Gruß Arnd
Signalduino (Nano, ESP, ...), CUL (Busware, Nano, Maple, ...), Homematic (HM-MOD-UART-RPI, ESP, Maple, ...), LaCrosseGateway (LGW, ESP, ...), 1-wire, ESPEasy, Bravia, Yamaha, ...
Zitat von: RaspiLED am 23 Dezember 2019, 15:42:28
Jepp, normaler nanoCUL ;-)
Vermutlich sogar die Variante ohne Pegelwandler *duckundweg* 8) 8) 8)
Gruß Peter
tztztz... bei mir läuft das ohne Pegelwandler schon seit Jahren ohne Probleme und ich kenne auch keinen selbstgebauten, der ohne Pegelwandler Probleme gemacht hat. Auch wenn mit natürlich chicker wäre ;-) Was mich mehr interessieren würde, wäre, ob das denn ein "echter" FTDI ist oder ob man den dann alle Weile abziehen muss, weil der Testpin nicht geerdet ist...
Grüße Christian
Also in der Beschreibung stand eigentlich explizit FTDI drin, ich werde berichten...
So, es hat nun etwas gedauert, bis ich Device::SerialPort auf meiner DS218+ zum Laufen bekommen habe, aber der SignalDuino wird nun von FHEM erkannt (V 3.3.2.1-rc8 SIGNALduino cc1101 - compiled at Jan 10 2019 20:13:56). cc1101_frequency habe ich auf 433.92 MHz gesetzt, verbose auf 5 und cc1101_bWidth auf 325.
Nun kommen im Log folgende Einträge:
2019.12.27 13:40:17 5: sduino/RAW rmsg: Mu;�Ȗ;���;�Ĭ;���;���;���;��;C5;RE2;D#CCCECECCCCCEEEEEEECCECECECCCCCECECECECF;e;
2019.12.27 13:40:17 4: sduino/msg READredu: MU;P0=-5832;P1=7840;P2=-11332;P3=1333;P4=-1061;P5=542;P6=116;CP=5;R=226;D=0123434343454345434343434345454545454545434345434543454343434343454345434543454346;e;
2019.12.27 13:40:17 5: sduino/RAW rmsg: Mu;���;���;���;���;���;��;C3;RE4;d!!!#!#!!!!!#######!!#!#!#!!!!!#!#!#!#!!#!#!E ;e;
2019.12.27 13:40:17 4: sduino/msg READredu: MU;P0=-32001;P1=1323;P2=-1025;P3=552;P4=-7216;P5=244;CP=3;R=228;D=0121212123212321212121212323232323232321212321232123212121212123212321232123212123212321452;e;
2019.12.27 13:40:17 5: sduino/RAW rmsg: Mu;��;���;���;���;���;C3;RE3;d!!!#!#!###!#######!#!!!!###!!!!#!!!!###!!##@;e;
2019.12.27 13:40:17 4: sduino/msg READredu: MU;P0=-1512;P1=1310;P2=-1075;P3=525;P4=-7864;CP=3;R=227;D=01212121232123212323232123232323232323212321212121232323212121212321212121232323212123234;e;
2019.12.27 13:40:17 5: sduino/RAW rmsg: Mu;���;���;���;���;���;���;C4;RE4;d####$#$#$$$#$$$$$$$#$####$$$####$####$$$##$$P;e;
2019.12.27 13:40:17 4: sduino/msg READredu: MU;P0=-12068;P1=136;P2=-1066;P3=1338;P4=545;P5=-21092;CP=4;R=228;D=0123232323242324232424242324242424242424232423232323242424232323232423232323242424232324245;e;
2019.12.27 13:40:17 5: sduino/RAW rmsg: Mu;��;���;��;��;���;��;�ւ;C1;R5;D!!!###!!#!!!#!#!!!!#!#!###Eeeea!#!!!###!!#!!!#!#!!!!#!#!###;e;i;
2019.12.27 13:40:17 4: sduino/msg READredu: MU;P0=-238;P1=259;P2=-487;P3=490;P4=-4860;P5=745;P6=-726;CP=1;R=5;D=012121212303030123012301212123012121212303012123030121212121230303012123030121230123030123014565656561212301212121230303012301230121212301212121230301212303012121212123030301212303012123012303012301;e;i;
2019.12.27 13:40:33 5: sduino/RAW rmsg: Ms;���;���;��;�ށ;���;�Ђ;�Ɠ;dPPPP444444444444444444;C1;S6;R2B;s106;e;
2019.12.27 13:40:33 4: sduino/msg READredu: MS;P0=-736;P1=248;P2=-483;P3=478;P4=-248;P5=720;P6=-4934;D=16505050501212123412121234121234343434121212341212341212343434121212121212123412123412121212123434343412341;CP=1;SP=6;R=43;s=106;e;
2019.12.27 13:40:47 4: sduino/keepalive ok, retry = 0
2019.12.27 13:40:58 5: sduino/RAW rmsg: Mu;���;���;���;���;��;C3;RE4;d!!!#!#!!!!!#######!!#!#!#!!!!#!!#!#!#!!#!##@;e;
2019.12.27 13:40:58 4: sduino/msg READredu: MU;P0=-408;P1=1298;P2=-1084;P3=525;P4=-12652;CP=3;R=228;D=01212121232123212121212123232323232323212123212321232121212123212123212321232121232123234;e;
2019.12.27 13:40:58 5: sduino: command for gets: R
2019.12.27 13:40:58 5: AddSendQueue: sduino: R (1)
2019.12.27 13:40:59 5: sduino/RAW rmsg: Mu;�ҙ;���;���;���;���;C4;RE3;D2224242222244444442242424222242242424224244;e;
2019.12.27 13:40:59 4: sduino/msg READredu: MU;P0=-6610;P1=112;P2=1296;P3=-1080;P4=535;CP=4;R=227;D=010232323234323432323232323434343434343432323432343234323232323432323432343234323234323434;e;
2019.12.27 13:40:59 4: sduino/msg READ: Received answer (MU;P0=-6610;P1=112;P2=1296;P3=-1080;P4=535;CP=4;R=227;D=010232323234323432323232323434343434343432323432343234323232323432323432343234323234323434;e;) for freeram does not match ^[0-9]+
2019.12.27 13:40:59 5: sduino SW: R
2019.12.27 13:40:59 4: sduino/msg READ: 558
2019.12.27 13:40:59 5: sduino/noMsg Parse: 558
2019.12.27 13:40:59 5: sduino/msg READ: regexp=^[0-9]+ cmd=freeram msg=558
2019.12.27 13:40:59 5: sduino/RAW rmsg: Mu;���;���;���;���;���;C3;RE4;d!!!#!#!###!#######!#!!!!###!$;e;
2019.12.27 13:40:59 4: sduino/msg READredu: MU;P0=-19766;P1=1329;P2=-1056;P3=552;P4=164;CP=3;R=228;D=0121212123212321232323212323232323232321232121212123232321240;e;
2019.12.27 13:40:59 4: sduino/HandleWriteQueue: nothing to send, stopping timer
2019.12.27 13:40:59 5: sduino/RAW rmsg: Mu;�ĉ;���;���;���;���;C3;RE4;d!!!#!#!###!#######!#!!!!###!!!!#!!!!###!!##@;e;
2019.12.27 13:40:59 4: sduino/msg READredu: MU;P0=-2372;P1=1306;P2=-1079;P3=538;P4=-19244;CP=3;R=228;D=01212121232123212323232123232323232323212321212121232323212121212321212121232323212123234;e;
2019.12.27 13:41:01 5: sduino/RAW rmsg: Ms;���;�ւ;��;��;��;��;��;D�!!!#CEcCCCEeecEcEcCCEcCCCEecCEecCCCCEeecCEecCEcEecEc;C3;S0;R6;s106;e;
2019.12.27 13:41:01 4: sduino/msg READredu: MS;P0=-4928;P1=726;P2=-737;P3=242;P4=-488;P5=487;P6=-242;D=30121212123434563434343456565634563456343434563434343456563434565634343434345656563434565634345634565634563;CP=3;SP=0;R=6;s=106;e;
2019.12.27 13:41:03 5: sduino: command for gets: V
2019.12.27 13:41:03 5: AddSendQueue: sduino: V (1)
2019.12.27 13:41:04 5: sduino SW: V
2019.12.27 13:41:04 4: sduino/msg READ: V 3.3.2.1-rc8 SIGNALduino cc1101 - compiled at Jan 10 2019 20:13:56
2019.12.27 13:41:04 5: sduino/noMsg Parse: V 3.3.2.1-rc8 SIGNALduino cc1101 - compiled at Jan 10 2019 20:13:56
2019.12.27 13:41:04 5: sduino/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:13:56
2019.12.27 13:41:04 4: sduino/HandleWriteQueue: nothing to send, stopping timer
2019.12.27 13:41:30 5: sduino/RAW rmsg: Mu;���;��;�ۂ;�݂;���;�;��;C4;R2B;d2EEEEEEEEEEEEEEEEEEEEEEEEEEEEEE@2222EEEEEEEEEEEEEEEEEEEEEEEEEEEEEE@;e;i;
2019.12.27 13:41:30 4: sduino/msg READredu: MU;P0=-4880;P1=497;P2=-731;P3=733;P4=259;P5=-472;P7=-232;CP=4;R=43;D=123245454517454545174545171717174545451745451745451717174545454545454517454517454545454517171717451740323232324545451745454517454517171717454545174545174545171717454545454545451745451745454545451717171745174;e;i;
2019.12.27 13:41:47 4: sduino/keepalive ok, retry = 0
2019.12.27 13:41:58 5: sduino/RAW rmsg: Mu;���;���;�;���;���;C3;RE2;d!!!#!#!!!!!#######!!#!#!#!!!!#!!#!#!#!!#!##@;e;
2019.12.27 13:41:58 4: sduino/msg READredu: MU;P0=-30812;P1=1298;P2=-1090;P3=533;P4=-13940;CP=3;R=226;D=01212121232123212121212123232323232323212123212321232121212123212123212321232121232123234;e;
2019.12.27 13:41:58 5: sduino/RAW rmsg: Mu;���;���;���;���;��;C1;RE3;d!!##!#!#!####!##!#!#!##!#!!@;e;
2019.12.27 13:41:58 4: sduino/msg READredu: MU;P0=-668;P1=528;P2=-1082;P3=1313;P4=-7792;CP=1;R=227;D=012121232321232123212323232321232321232123212323212321214;e;
2019.12.27 13:41:58 5: sduino/RAW rmsg: Mu;���;���;���;���;C3;RE4;D!!!#!#!###!#######!#!!!!###!!!!#!!!!###!!##;e;
2019.12.27 13:41:58 4: sduino/msg READredu: MU;P0=-1960;P1=1324;P2=-1059;P3=559;CP=3;R=228;D=0121212123212321232323212323232323232321232121212123232321212121232121212123232321212323;e;
2019.12.27 13:41:59 5: sduino/RAW rmsg: Mu;�Ձ;���;��;��;���;�܂;��;��;C7;R9;Daaab27bb7ggb7gggb27gb27ggggb227gb27gb7b27b7E;p;i;
2019.12.27 13:41:59 4: sduino/msg READredu: MU;P0=-341;P1=133;P2=493;P3=-239;P4=-4892;P5=732;P6=-481;P7=241;CP=7;R=9;D=0761616162023237620762376767623767676762323767623237676767676232323767623237676237623237623745;p;i;
2019.12.27 13:41:59 5: sduino/RAW rmsg: Mu;�ӂ;��;��;�ځ;��;���;C2;R9;D24R2224TTR4R4R224R2224TR24TR22224TTR24TR24R4TR4R;e;
2019.12.27 13:41:59 4: sduino/msg READredu: MU;P0=-723;P1=742;P2=243;P3=-474;P4=500;P5=-240;CP=2;R=9;D=01010102323452323232345454523452345232323452323232345452323454523232323234545452323454523234523454523452;e;
2019.12.27 13:42:27 5: sduino/RAW rmsg: Ms;��;��;���;�Ղ;��;���;��;D�4TTTVvvpvvpvpvvpvpvpvvvvvvpvpvvvvpp;C6;S3;R2B;s106;e;
2019.12.27 13:42:27 4: sduino/msg READredu: MS;P0=491;P1=-238;P3=-4910;P4=725;P5=-742;P6=252;P7=-488;D=63454545456767670167676701676701010101676767016767016767010101676767676767670167670167676767670101010167016;CP=6;SP=3;R=43;s=106;e;
2019.12.27 13:42:47 4: sduino/keepalive ok, retry = 0
2019.12.27 13:42:56 5: sduino/RAW rmsg: Mu;���;���;���;���;���;���;C3;RE3;D!!!#!#!!!!!#######!!#!#!#!!!!#!!#!#!#!!#!#$;e;w0;
2019.12.27 13:42:56 4: sduino/msg READredu: MU;P0=-21550;P1=1311;P2=-1082;P3=539;P4=388;P5=-31396;CP=3;R=227;D=0121212123212321212121212323232323232321212321232123212121212321212321232123212123212324;e;w=0;
2019.12.27 13:42:56 5: sduino/RAW rmsg: Mu;���;���;���;���;���;C3;RE3;dQ!!!#!#!!!!!#######!!#!#!#!!!!#!!#!#!#!!#!##;e;
2019.12.27 13:42:56 4: sduino/msg READredu: MU;P0=-21550;P1=1311;P2=-1082;P3=539;P5=-31396;CP=3;R=227;D=51212121232123212121212123232323232323212123212321232121212123212123212321232121232123230;e;
2019.12.27 13:42:56 5: sduino/RAW rmsg: Mu;���;�ą;���;���;C3;RE3;D!!!#!#!###!#######!#!!!!###!!!!#!!!!###!;e;
2019.12.27 13:42:56 4: sduino/msg READredu: MU;P0=-15924;P1=1348;P2=-1019;P3=550;CP=3;R=227;D=0121212123212321232323212323232323232321232121212123232321212121232121212123232321;e;
2019.12.27 13:42:56 5: sduino/RAW rmsg: Mu;��;���;���;���;���;���;C2;RE3;D##C#######C#CCCC###CCCC#CCCC###CC#%;e;
2019.12.27 13:42:56 4: sduino/msg READredu: MU;P0=884;P1=-156;P2=569;P3=-1052;P4=1331;P5=-12320;CP=2;R=227;D=012323432323232323232343234343434323232343434343234343434323232343432325;e;
2019.12.27 13:42:57 5: sduino/RAW rmsg: Mu;���;��;���;��;���;��;�܂;C1;R8;D!!!###!!#!!!##!!!!!!#!#!!##!Eeeea!#!!!###!!#!!!##!!!!!!#!#!!##!;e;i;
2019.12.27 13:42:57 4: sduino/msg READredu: MU;P0=-251;P1=237;P2=-496;P3=486;P4=-4880;P5=741;P6=-732;CP=1;R=8;D=012121212303030123012301212123012121212303012301212121212121230303012123030121212301230301214565656561212301212121230303012301230121212301212121230301230121212121212123030301212303012121230123030121;e;i;
Wie mache ich damit jetzt weiter oder wer kann damit etwas anfangen?
Ich würde erst einmal die Pulsweiten "sortieren". Sind ja in den Mustern unterschiedlich: zwischen 5-8 verschiedene(P0-P7). Das würd ich versuchen auf einen Nenner zu bringen. Ebenso den CP = "clock pulse". weitere Infos gibt's hier (https://wiki.fhem.de/wiki/Unbekannte_Funkprotokolle#SIGNALduino_-_OOK)
Grüße Markus
Dank der sehr schnellen Hilfe von HomeAutoUser auf GitHub konnten die Rohdaten schon ausgelesen werden (siehe https://github.com/RFD-FHEM/RFFHEM/issues/739). Ich habe mich dann mit den Sensoren und entsprechenden Temperaturveränderungen daran gemacht, das zu entschlüsseln, das hier ist das Ergebnis:
2F984A7085D00
||-||||||||||
|\ /||||||\/\->immer Null (Stop-Marker?)
| | |||||| \-> Checksumme über die vorhergehenden 10 Nibble (CRC-8 mit Generatorpolynom 0x31)
| | ||||\/
| | |||| \---> relative Feuchtigkeit (BCD)
| | |\/\-----> Unbekannt
| | | \------> Temperatur * 10
| | \--------> Vorzeichen: 0x3 = negatives Vorzeichen, 0x4 positives Vorzeichen, 0x5 = Wert über 25,5 Grad, 0xB/C/D das Gleiche nur mit Batteriewarnung
| \----------> Zufällige, beim Einschalten des Sensors vergebene ID
\------------> Kanal (1 bis 8) minus 1
Ich hoffe, das sich das vielleicht mit einem der bereits bekannten Geräte deckt oder zumindest einfach implementiert werden kann, damit auch noch andere Nutzer dieser Geräte etwas davon haben. Danke Euch allen auf jeden Fall für Eure Hilfe!
ZitatIch hoffe, das sich das vielleicht mit einem der bereits bekannten Geräte deckt oder zumindest einfach implementiert werden kann, damit auch noch andere Nutzer dieser Geräte etwas davon haben
Richtig interessant wird der Sensor erst wenn auch die Checksum bekannt ist.
ZitatIch habe nun noch mal ein Paar schwacher Batterien eingelegt, um zu prüfen, wie das Batteriesymbol auf der Empfangsstation aktiviert wird, auch das passiert über das 5. Nibble, und zwar in Bit 3. Ist es gesetzt (0x8), dann sind die Batterien schwach, ist es nicht gesetzt, sind sie in Ordnung. Mir scheint, dass das 5. Nibble dann doch bitweise aufgebaut ist, wobei ich den Wechsel von drei Bits beim Unterschreiten der 0-Grad-Grenze doch schwer zu erklären finde:
1101: > 25,5 Grad, Batteriewarnung
1100: < 25,5 Grad, Batteriewarnung
1011: < 0 Grad, Batteriewarnung
0101: > 25,5 Grad, keine Batteriewarnung
0100: < 25,5 Grad, keine Batteriewarnung
0011: < 0 Grad, keine Batteriewarnung
Hat der Sensor eine Sendetaste?
Evtl ändert sich ein Bit bei der ersten Nachricht nach dem Batteriewechsel.
Gruß Ralf
Wofür wäre die Prüfsumme interessant? Ich will ja keine Nachrichten an den Empfänger senden, sondern die vom Sender in FHEM auswerten. Und eine Validierung wäre zwar nett, ließe sich aber sonst auch über eine Plausibilitätsprüfung realisieren.
Eine Taste am Sender gibt es nicht und einen Batteriewechsel hat es (zwischen den jeweiligen Vergleichswerten) nicht gegeben.
Ja, eine eingeschränkte Validierung ist auch ohne Prüfsumme möglich.
Wie ist bei der ID oder dem Kanal eine Plausibilitätsprüfung möglich?
Die Temp und Hum lässt sich durch Prüfung auf größere Änderungen validieren. Im Bad beim Duschen oder wenn jemand den Sensor von draussen reinholt, kann es auch größere Änderungen geben.
Lässt sich erkennen ob die unbekannte Ziffer immer 0 ist? Dann kann sie zur Validierung verwendet werden.
Es gibt Sensoren, da lässt sich an der ersten Nachricht nach dem Batteriewechsel der Batteriewechsel erkennen.
Interessant wäre noch wie oft der Sensor sendet und mit wievielen Wiederholungen.
Also vielleicht unterscheiden sich unsere Anwendungsszenarien ja ein wenig, aber ich hatte nicht vor, dem Sensor im Winter hin und wieder einen aufwärmenden Kaminabend zu spendieren ;). Klar, die Punkte, die Du nennst, sind nice-to-have, aber für die Standardanwendung, für die dieser Sensor vorgesehen ist (Außentemperatur und -feuchtigkeit messen) reicht eine Plausibilitätsprüfung auf größere Abweichungen völlig aus. Wer drei Sensoren an verschiedenen Orten benötigt und dabei kein falsches Telegramm riskieren will, darf mich gerne bei der Identifizierung des CRC unterstützen, aber die Aussage, dass es erst mit dem CRC richtig interessant wird, ist für Otto Normaluser sicherlich übertrieben, und das könnten eine Menge Leute sein, da Conrad diesen Sensor als eine der Gratis-Beigaben vor Weihnachten ab einer bestimmten Bestellsumme angeboten hat.
Immerhin kann man festhalten, dass der Sensor gestern über 100 Telegramme (stoisch einmal pro Minute) durch zwei Stahlbetonwände an SIGNALduino gesendet hat und kein einziges davon Fehler aufwies.
Ein Batteriewechsel führt nur zu einer neuen ID, es wird kein weiterer Wert bei der ersten Nachricht nach dem Einschalten abweichend gesetzt.
Aber um es für wirkliche alle Anwendungsmöglichkeiten einsetzbar zu machen:
Bei dem CRC handelt es sich um CRC-8 mit 0x31 als Generatorpolynom. Dabei ist mir noch aufgefallen, dass das Telegramm immer mit einer Null aufhört, was für einen CRC ja nicht passen würde. Woher diese Null kommt und ob sie zwingend Teil des Telegramms oder nur ein End-Marker ist, weiß ich nicht, sie ist zumindest nicht Teil des CRC.
Mit diesen Einstellungen konnte ich jetzt jedenfalls ein gutes Dutzend von Telegrammen unter http://www.sunshine2k.de/coding/javascript/crc/crc_js.html überprüfen.
Wenn mir jemand sagt, wie ich auf die Schnelle das Telegramm
113C401090500
über SIGNALduino versenden kann, dann könnte ich es direkt am Empfänger verifizieren, ob der dieses Telegramm dann auch annimmt.
Sie haben es geschafft :) - Die EFTH-800 Sensoren werden jetzt von SIGNALduino automatisch erkannt und angelegt, einschließlich Batterie-Test - danke!
Glückwunsch :)
ZitatAlso vielleicht unterscheiden sich unsere Anwendungsszenarien ja ein wenig, aber ich hatte nicht vor, dem Sensor im Winter hin und wieder einen aufwärmenden Kaminabend zu spendieren ;). Klar, die Punkte, die Du nennst, sind nice-to-have, aber für die Standardanwendung, für die dieser Sensor vorgesehen ist (Außentemperatur und -feuchtigkeit messen)
Mir geht es dabei nicht um meine Anwendungsszenarien.
Ist für Dich das Bad keine Standardanwendung?
Zitat von: putzvarruckt am 21 Februar 2019, 21:33:23
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...
Mich würde noch interessieren wo oft der Sensor sendet. Alle 30 oder 60sek?
Gruß Ralf
Es ist ein Außentemperatur-Sensor, und selbst wenn man es kann, würde ich mir so ein klobiges Teil nicht ins Bad hängen, dafür gibt es sicher (optisch) bessere Lösungen. Aber wie gesagt, jeder nach seiner Façon...
Den zeitlichen Abstand kann ich noch mal nachsehen, wofür wäre das relevant?
Zitat von: Ralf9 am 29 Dezember 2019, 11:46:10
Mich würde noch interessieren wo oft der Sensor sendet. Alle 30 oder 60sek?
Der eine Sensor wurde alle 57 Sekunden registriert und der andere all 58 Sekunden.
Ich habe keine Ahnung, ob der Abstand vom eingestellten Kanal abhängig ist (erster Kanal 2, zweiter Kanal 3), oder einfach nur Toleranz. Da auf der Senderplatine ein Quartz zu sehen ist, tippe ich fast auf erstes.
ZitatDen zeitlichen Abstand kann ich noch mal nachsehen, wofür wäre das relevant?
Je öfter er sendet, desto höher ist bei vielen Sensoren die Wahrscheinlichkeit, daß mal 2 gleichzeitig senden.
ZitatDer eine Sensor wurde alle 57 Sekunden registriert und der andere all 58 Sekunden.
Lässt sich ganz grob abschätzen, wieviele Nachrichten er jeweils sendet?
Ah, ok, danke - es sind immer zwei Telegramme pro Intervall und Sensor.