Signalduino Entwicklung

Begonnen von thoffma3, 05 Juli 2015, 23:01:00

Vorheriges Thema - Nächstes Thema

trebron106

Hallo Sidey,

hier sind die Signaldaten :

2016.01.27 08:46:49 3: sduino: setting Verbose to: 5
2016.01.27 08:47:10 4: sduino/msg READ: MU;P0=-781;P1=-32001;P2=893;P3=-346;P4=452;P5=-3033;D=00123232323232323402340452323232323232340402345232340234023402323404523234023402340234023454040404040404040232345404040404040404040404540402340234040402323454040234023404040404045404023234023232323404540402323402323234023454023232340234040;CP=4;O;
2016.01.27 08:47:10 4: Fingerprint for MU Protocol id 16 -> Dooya shutter matches, trying to demodulate
2016.01.27 08:47:10 5: sduino: Starting demodulation at Position 1
2016.01.27 08:47:10 5: sduino: applying filterfunc SIGNALduino_filterSign
2016.01.27 08:47:10 4: Fingerprint for MU Protocol id 21 -> einhell garagedoor matches, trying to demodulate
2016.01.27 08:47:10 5: sduino: Starting demodulation at Position 1
2016.01.27 08:47:10 4: Fingerprint for MU Protocol id 26 -> remote26 matches, trying to demodulate
2016.01.27 08:47:10 5: sduino: Starting demodulation at Position 1
2016.01.27 08:47:10 4: Fingerprint for MU Protocol id 27 -> remote27 matches, trying to demodulate
2016.01.27 08:47:10 5: sduino: Starting demodulation at Position 1
2016.01.27 08:47:10 4: Fingerprint for MU Protocol id 28 -> IC Ledspot matches, trying to demodulate
2016.01.27 08:47:10 5: sduino: Starting demodulation at Position 1
2016.01.27 08:47:10 4: Fingerprint for MU Protocol id 30 -> unitec47031 matches, trying to demodulate
2016.01.27 08:47:10 5: sduino: Starting demodulation at Position 1
2016.01.27 08:47:10 4: Fingerprint for MU Protocol id 31 -> pollin isotronic matches, trying to demodulate
2016.01.27 08:47:10 5: sduino: Starting demodulation at Position 19
2016.01.27 08:47:10 4: Fingerprint for MU Protocol id 34 -> unknown34 matches, trying to demodulate
2016.01.27 08:47:10 5: sduino: Starting demodulation at Position 1
2016.01.27 08:47:10 4: Fingerprint for MU Protocol id 8 -> TX3 Protocol matches, trying to demodulate
2016.01.27 08:47:10 5: sduino: Starting demodulation at Position 2

Ich habe den Sender direkt an den Signalduino angeschlossen, so dass die Daten direkt digital übertragen worden sind.
Als Anhang habe ich die aufgezeichnete Grafik vom Logger angefügt.

Gruß
Klaus

pejonp

Hallo Sidey,

ich habe eben ein Update gemacht und jetzt werden meine Hideki-Sensoren (Bresser und Hama ) nicht mehr erkannt. Es ist nichts an- oder ausgeschalten. Verbose=5


2016.01.27 16:02:28 4: Founded matched MS Protocol id 0 -> weather1
2016.01.27 16:02:28 5: Starting demodulation at Position 2
2016.01.27 16:02:28 4: Decoded matched MS Protocol id 0 dmsg s52490B411000 length 40
2016.01.27 16:02:28 5: sduinousb converted Data to (s52490B411000)
2016.01.27 16:02:28 4: sduinousb Dropped (s52490B411000) due to short time or equal msg
2016.01.27 16:02:28 4: Founded matched MS Protocol id 7 -> weatherID7
2016.01.27 16:02:28 5: Starting demodulation at Position 6
2016.01.27 16:02:28 4: Decoded matched MS Protocol id 7 dmsg P7#0000000 length 36
2016.01.27 16:02:30 4: sduinousb/msg READ: MU;P0=332;P1=-157;P2=791;P3=1452;P5=-438;D=0012101312121010101050121010101050101010101010;CP=0;
2016.01.27 16:02:30 4: Fingerprint for MU Protocol id 16 -> Dooya shutter matches, trying to demodulate
2016.01.27 16:02:30 5: sduinousb: Starting demodulation at Position 2
2016.01.27 16:02:30 5: sduinousb: applying filterfunc SIGNALduino_filterSign
2016.01.27 16:02:30 4: Fingerprint for MU Protocol id 29 -> HT12e remote matches, trying to demodulate
2016.01.27 16:02:30 5: sduinousb: Starting demodulation at Position 2
2016.01.27 16:02:30 5: dispatching bits: 0 0 0 1 0 0 0 0 0 0 0 0
2016.01.27 16:02:30 4: decoded matched MU Protocol id 29 dmsg u29#100 length 12
2016.01.27 16:02:30 5: sduinousb converted Data to (u29#100)
2016.01.27 16:02:31 5: sduinousb dispatch u29#100
2016.01.27 16:02:31 4: SIGNALduino_unknown incomming msg: u29#100
2016.01.27 16:02:31 4: SIGNALduino_unknown rawData: 100
2016.01.27 16:02:31 4: SIGNALduino_unknown Protocol: 29
2016.01.27 16:02:31 4: SIGNALduino_unknown converted to bits: 000100000000
2016.01.27 16:02:31 4: Fingerprint for MU Protocol id 30 -> unitec47031 matches, trying to demodulate
2016.01.27 16:02:31 5: sduinousb: Starting demodulation at Position 2
2016.01.27 16:02:31 4: Fingerprint for MU Protocol id 34 -> unknown34 matches, trying to demodulate
2016.01.27 16:02:31 5: sduinousb: Starting demodulation at Position 2
2016.01.27 16:02:31 4: Fingerprint for MU Protocol id 37 -> weather37 matches, trying to demodulate
2016.01.27 16:02:31 5: sduinousb: Starting demodulation at Position 2
2016.01.27 16:02:36 4: sduinousb/msg READ: MC;LL=-952;LH=1005;SL=-481;SH=502;D=7A174A61B7EBB1147A2E00;C=502;
2016.01.27 16:02:36 4: sduinousb Found manchester Protocol id 10 clock 502 -> OSV2o3
2016.01.27 16:02:36 4: sduinousb Found manchester Protocol id 12 clock 502 -> Hideki protocol
2016.01.27 16:02:36 4: sduinousb/msg READ: MC;LL=-971;LH=993;SL=-487;SH=493;D=AE7A174A21B7EBB114780000;C=495;
2016.01.27 16:02:36 4: sduinousb Found manchester Protocol id 10 clock 495 -> OSV2o3
2016.01.27 16:02:36 4: sduinousb Found manchester Protocol id 12 clock 495 -> Hideki protocol
2016.01.27 16:02:37 4: sduinousb/msg READ: MU;P0=-8368;P2=973;P3=-981;P4=-490;P5=490;D=40232324545354245454532354545423245453235423235423545454542453245324545454545323245453245354542354542323545424545453245354245323545454;CP=5;
2016.01.27 16:02:37 4: Fingerprint for MU Protocol id 16 -> Dooya shutter matches, trying to demodulate
2016.01.27 16:02:37 5: sduinousb: Starting demodulation at Position 2
2016.01.27 16:02:37 5: sduinousb: applying filterfunc SIGNALduino_filterSign
2016.01.27 16:02:37 4: Fingerprint for MU Protocol id 21 -> einhell garagedoor matches, trying to demodulate
2016.01.27 16:02:37 5: sduinousb: Starting demodulation at Position 2
2016.01.27 16:02:37 4: Fingerprint for MU Protocol id 26 -> remote26 matches, trying to demodulate
2016.01.27 16:02:37 5: sduinousb: Starting demodulation at Position 2
2016.01.27 16:02:37 4: Fingerprint for MU Protocol id 27 -> remote27 matches, trying to demodulate
2016.01.27 16:02:37 5: sduinousb: Starting demodulation at Position 2
2016.01.27 16:02:37 4: Fingerprint for MU Protocol id 28 -> IC Ledspot matches, trying to demodulate
2016.01.27 16:02:37 5: sduinousb: Starting demodulation at Position 2
2016.01.27 16:02:37 4: Fingerprint for MU Protocol id 30 -> unitec47031 matches, trying to demodulate
2016.01.27 16:02:37 5: sduinousb: Starting demodulation at Position 2
2016.01.27 16:02:37 4: Fingerprint for MU Protocol id 31 -> pollin isotronic matches, trying to demodulate
2016.01.27 16:02:37 5: sduinousb: Starting demodulation at Position 11
2016.01.27 16:02:37 4: Fingerprint for MU Protocol id 34 -> unknown34 matches, trying to demodulate
2016.01.27 16:02:37 5: sduinousb: Starting demodulation at Position 8
2016.01.27 16:02:37 4: Fingerprint for MU Protocol id 36 -> socket36 matches, trying to demodulate
2016.01.27 16:02:37 5: sduinousb: Starting demodulation at Position 2
2016.01.27 16:02:37 4: Fingerprint for MU Protocol id 8 -> TX3 Protocol matches, trying to demodulate
2016.01.27 16:02:37 5: sduinousb: Starting demodulation at Position 2
2016.01.27 16:02:37 4: Fingerprint for MU Protocol id 9 -> CTW 600 matches, trying to demodulate
2016.01.27 16:02:37 5: sduinousb: Starting demodulation at Position 2
2016.01.27 16:02:37 4: sduinousb/msg READ: MS;P0=616;P1=-3789;P2=-1837;P3=-9113;D=03020102010102010101020101010201020202020201020102010201010202010102020101;CP=0;SP=3;O;
2016.01.27 16:02:37 4: Founded matched MS Protocol id 7 -> weatherID7
2016.01.27 16:02:37 5: Starting demodulation at Position 6
2016.01.27 16:02:37 4: Decoded matched MS Protocol id 7 dmsg P7#00000 length 36
2016.01.27 16:02:38 4: sduinousb/msg READ: MS;P0=-3800;P1=577;P2=-1847;P3=-9058;D=13121012101012101010121010101210121212121210121012101210101212101012121010;CP=1;SP=3;
2016.01.27 16:02:38 4: Founded matched MS Protocol id 0 -> weather1
2016.01.27 16:02:38 5: Starting demodulation at Position 2
2016.01.27 16:02:38 4: Decoded matched MS Protocol id 0 dmsg s5BBA0AB33000 length 40
2016.01.27 16:02:38 5: sduinousb converted Data to (s5BBA0AB33000)
2016.01.27 16:02:38 5: sduinousb dispatch s5BBA0AB33000
2016.01.27 16:02:38 4: CUL_TCM97001 using longid: 1 model: NC_WS
2016.01.27 16:02:46 4: sduinousb/msg READ: MS;P0=511;P1=-2061;P2=-3772;P3=-8059;D=0301010101010201020101010101010101020102020202020101010101010101010101010101;CP=0;SP=3;O;
2016.01.27 16:02:46 4: Founded matched MS Protocol id 0 -> weather1
2016.01.27 16:02:46 5: Starting demodulation at Position 2
2016.01.27 16:02:46 4: Decoded matched MS Protocol id 0 dmsg s0500BE000000 length 40
2016.01.27 16:02:46 5: sduinousb converted Data to (s0500BE000000)
2016.01.27 16:02:46 5: sduinousb dispatch s0500BE000000
2016.01.27 16:02:46 4: CUL_TCM97001 using longid: 1 model: AURIOL
2016.01.27 16:02:46 4: sduinousb/msg READ: MS;P0=-2066;P1=503;P2=-3771;P3=-8052;D=1310101010101210121010101010101010121012121212121010101010101010101010101010;CP=1;SP=3;O;
2016.01.27 16:02:46 4: Founded matched MS Protocol id 0 -> weather1
2016.01.27 16:02:46 5: Starting demodulation at Position 2
2016.01.27 16:02:46 4: Decoded matched MS Protocol id 0 dmsg s0500BE000000 length 40
2016.01.27 16:02:46 5: sduinousb converted Data to (s0500BE000000)
2016.01.27 16:02:46 4: sduinousb Dropped (s0500BE000000) due to short time or equal msg
2016.01.27 16:02:49 4: sduinousb/msg READ: MC;LL=-2674;LH=3201;SL=-1218;SH=1717;D=613D02C0;C=1639;
2016.01.27 16:02:49 4: sduinousb Found manchester Protocol id 18 clock 1639 -> OSV1
2016.01.27 16:02:49 5: sduinousb: OSV1 protocol converted to hex: (089EC2FD3F) with length (8) bits

2016.01.27 16:02:49 4: sduinousb/msg READ: MC;LL=-2680;LH=3195;SL=-1220;SH=1713;D=613D02C0;C=1635;
2016.01.27 16:02:49 4: sduinousb Found manchester Protocol id 18 clock 1635 -> OSV1
2016.01.27 16:02:49 5: sduinousb: OSV1 protocol converted to hex: (089EC2FD3F) with length (8) bits

2016.01.27 16:02:57 4: sduinousb/msg READ: MU;P0=614;P1=-1837;P2=-314;P3=22072;P4=3100;P5=-3788;D=2324520010501010505010105010501010101010101050105050501050501010505010101050;CP=0;
2016.01.27 16:02:57 4: Fingerprint for MU Protocol id 16 -> Dooya shutter matches, trying to demodulate
2016.01.27 16:02:57 5: sduinousb: Starting demodulation at Position 2
2016.01.27 16:02:57 5: sduinousb: applying filterfunc SIGNALduino_filterSign
2016.01.27 16:02:57 4: Fingerprint for MU Protocol id 30 -> unitec47031 matches, trying to demodulate
2016.01.27 16:02:57 5: sduinousb: Starting demodulation at Position 2
2016.01.27 16:02:57 4: Fingerprint for MU Protocol id 36 -> socket36 matches, trying to demodulate
2016.01.27 16:02:57 5: sduinousb: Starting demodulation at Position 2
2016.01.27 16:02:57 4: sduinousb/msg READ: MS;P0=603;P1=-1839;P2=-3804;P3=-9113;D=03010201020101020201010201020101010101010102010202020102020101020201010102;CP=0;SP=3;O;
2016.01.27 16:02:57 4: Founded matched MS Protocol id 0 -> weather1
2016.01.27 16:02:57 5: Starting demodulation at Position 2
2016.01.27 16:02:57 4: Decoded matched MS Protocol id 0 dmsg s53280BB31000 length 40
2016.01.27 16:02:57 5: sduinousb converted Data to (s53280BB31000)
2016.01.27 16:02:57 5: sduinousb dispatch s53280BB31000
2016.01.27 16:02:57 4: CUL_TCM97001 using longid: 1 model: NC_WS
2016.01.27 16:02:57 4: Founded matched MS Protocol id 7 -> weatherID7
2016.01.27 16:02:57 5: Starting demodulation at Position 6
2016.01.27 16:02:57 4: Decoded matched MS Protocol id 7 dmsg P7#000000 length 36
2016.01.27 16:02:58 4: sduinousb/msg READ: MS;P0=-1840;P1=568;P2=-3805;P3=-9072;D=13101210121010121210101210121010101010101012101212121012121010121210101012;CP=1;SP=3;
2016.01.27 16:02:58 4: Founded matched MS Protocol id 0 -> weather1
2016.01.27 16:02:58 5: Starting demodulation at Position 2
2016.01.27 16:02:58 4: Decoded matched MS Protocol id 0 dmsg s53280BB31000 length 40
2016.01.27 16:02:58 5: sduinousb converted Data to (s53280BB31000)
2016.01.27 16:02:58 4: sduinousb Dropped (s53280BB31000) due to short time or equal msg
2016.01.27 16:03:02 4: sduinousb/msg READ: MS;P1=-3531;P2=600;P3=-1840;P5=-9118;D=25232123212323212323212323212323212323232321232121232123232323232123232321;CP=2;SP=5;O;
2016.01.27 16:03:02 4: Founded matched MS Protocol id 0 -> weather1
2016.01.27 16:03:02 5: Starting demodulation at Position 2
2016.01.27 16:03:02 4: Decoded matched MS Protocol id 0 dmsg s52490B411000 length 40
2016.01.27 16:03:02 5: sduinousb converted Data to (s52490B411000)
2016.01.27 16:03:02 5: sduinousb dispatch s52490B411000
2016.01.27 16:03:02 4: CUL_TCM97001 using longid: 1 model: NC_WS
2016.01.27 16:03:03 4: sduinousb/msg READ: MS;P0=-1850;P1=598;P2=-3799;P3=-9126;D=13101210121010121010121010121010121010101012101212101210101010101210101012;CP=1;SP=3;O;
2016.01.27 16:03:03 4: Founded matched MS Protocol id 0 -> weather1
2016.01.27 16:03:03 5: Starting demodulation at Position 2
2016.01.27 16:03:03 4: Decoded matched MS Protocol id 0 dmsg s52490B411000 length 40
2016.01.27 16:03:03 5: sduinousb converted Data to (s52490B411000)
2016.01.27 16:03:03 4: sduinousb Dropped (s52490B411000) due to short time or equal msg


Kann erst heute abend mehr testen.

Tschüß Jörg
LaCrossGW 868MHz:WT470+TFA+TX37-IT+EMT7110+W136+WH25A HP1003+WH2621
SignalD(CC1101):Bresser+WS-0101(868MHz WH1080)+Velux KLF200+MAX!+HM-MOD-UART:Smoke HM-SEC-SD+VITOSOLIC 200 RESOL VBUS-LAN+SolarEdge SE5K(Modbus)+Sonnen!eco8(10kWh)+TD3511+DRT710M(Modbus)+ZigBee+Z-Wave+MQTT+vitoconnect

Cruiser79

Zitat von: Ralf9 am 26 Januar 2016, 22:29:21
Hast Du mir mal die Außentemperatur, bitte erst ablesen nachdem die Temperatur ca 1-2 Minuten konstant bleibt.
Ich hatte auch mal mit der Gefriertruhe einen Temperatursensor getestet, dabei hatte ich den Eindruck, daß bei sich schnell ändernden Temperaturen nicht immer der gerade angezeigte Wert gesendet wird.

Gruß Ralf

Nabend Ralf,

Ok, leider ist es hier nicht so richtig kalt, nur 12.1 Grad. Der Signalduino liefert mir folgendes zurück, nachdem der Sensor sehr lange Zeit draussen lag.


2016.01.27 20:35:40 4: SIGNALduino_unknown converted to bits: 0011001000010101100111100100001100101000
2016.01.27 20:35:40 4: SIGNALduino_unknown converted to bits: 00110010 0001 01011001111 00 1000011 00101000
2016.01.27 20:35:40 4: SIGNALduino_unknown decoded protocolid: 37 (Bresser 7009994 ) sensor id=50, channel=1, temp=12.9, hum=67


Passt somit leider nicht komplett. Ziemlich komisch das ganze.
Wie bekomme ich denn das ganze jetzt eigentlich als autocreate in FHEM rein?

Gruß,
Tim
FHEM auf Raspberry Pi
HM-CFG-LAN mit HM-TC-IT-WM-W-EU, HM-CC-RT-DN, HM-WDS10-TH-O, HM-LC-SW1-FM, HM-LC-Bl1-FM
Signalduino mit Elro AB440, LOGILINK WS0002, IT CMR-1000

Ralf9

#963
Zitat von: Cruiser79 am 27 Januar 2016, 20:37:40
Ok, leider ist es hier nicht so richtig kalt, nur 12.1 Grad. Der Signalduino liefert mir folgendes zurück, nachdem der Sensor sehr lange Zeit draussen lag.

2016.01.27 20:35:40 4: SIGNALduino_unknown converted to bits: 00110010 0001 01011001111 00 1000011 00101000
2016.01.27 20:35:40 4: SIGNALduino_unknown decoded protocolid: 37 (Bresser 7009994 ) sensor id=50, channel=1, temp=12.9, hum=67


Passt somit leider nicht komplett. Ziemlich komisch das ganze.

Ja, das ist recht komisch.
Hast Du draussen am Sensor 12.1 Grad abgelesen, und es wurden in Signalduino mehrere Nachrichten mit temp=12.9 empfangen?

Eine etwas unsaubere Möglichkeit, die man probieren könnte, wäre es mit einer Formel zu versuchen:

temp = (bitdataTemp - x) / y

Dann mit zwei bekannten Temperaturen die werte von x und y ermitteln
temp1 = (bitdataTemp1 - x) / y  z.B.   12,1 = (719 - x) / y
temp2 = (bitdataTemp2 - x) / y

@Sidey hast Du eine Idee was da nicht passen könnte? Hattest Du schon mal so einen komischen Fall?


Zitat von: Cruiser79 am 27 Januar 2016, 20:37:40
Wie bekomme ich denn das ganze jetzt eigentlich als autocreate in FHEM rein?

Es muß dafür ein Modul entwickelt werden, wie z.B. das 14_SD_WS07.pm Modul.

@Sidey ist es evtl sinnvoll, zukünftig für mehrere Temperatursensoren ein gemeinsames Weather-Modul zu entwickeln? Dort könnten dann auch die unbekannten  Temperatursensoren reinkommen.
Nachtrag:
Diese Protokolle könnten dann z.B. mit W beginnen. zB. W37#

Gruß Ralf
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

Sidey

Hi,

ich komme erst am Wochenende dazu, euch zu antworten.

Grüße Sidey
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem,zigbee2mqtt

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

Cruiser79

Zitat von: Ralf9 am 27 Januar 2016, 21:53:05
Ja, das ist recht komisch.
Hast Du draussen am Sensor 12.1 Grad abgelesen, und es wurden in Signalduino mehrere Nachrichten mit temp=12.9 empfangen?

Hi Ralf,

ja, ich hatte extra, nach deiner Anweisung, den Sensor draussen etliche Zeit liegen und habe erst dann abgelesen. Der Werte änderte sich dann nach dem Ablesen sowohl auf dem Sensor, als auch im Log längere Zeit nicht.
Da es hier bei uns eher nicht aussieht, als ob es demnächst kälter wird, werde ich heute Abend nochmal einen Test machen und den Sensor in den Kühlschrank über längere Zeit packen. Da sind es ja auch konstante 7 Grad. Sollte ja gehen.

Gruß,
Tim
FHEM auf Raspberry Pi
HM-CFG-LAN mit HM-TC-IT-WM-W-EU, HM-CC-RT-DN, HM-WDS10-TH-O, HM-LC-SW1-FM, HM-LC-Bl1-FM
Signalduino mit Elro AB440, LOGILINK WS0002, IT CMR-1000

Ralf9

Zitat von: Cruiser79 am 28 Januar 2016, 10:04:28
Da es hier bei uns eher nicht aussieht, als ob es demnächst kälter wird, werde ich heute Abend nochmal einen Test machen und den Sensor in den Kühlschrank über längere Zeit packen. Da sind es ja auch konstante 7 Grad. Sollte ja gehen.

Wenn Du den Sensor nur drinnen verwenden willst, sollte es ausreichen wenn die Temperatur von ca 10 bis ca 20-25 Grad passt.
Die Werte die Du seither ermittelt hast, müssten reichen.
Die tiefen Temperaturen kannst Du dann testen wenn es draussen wieder richtig kalt wird.

Hat der Sensor eine Abdichtung am Batteriedeckel? Ohne Abdichtung dürfte er nur bedingt für draussen geeignet sein.

Gruß Ralf
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

Cruiser79

Zitat von: Ralf9 am 28 Januar 2016, 13:09:47
Wenn Du den Sensor nur drinnen verwenden willst, sollte es ausreichen wenn die Temperatur von ca 10 bis ca 20-25 Grad passt.
Die Werte die Du seither ermittelt hast, müssten reichen.
Die tiefen Temperaturen kannst Du dann testen wenn es draussen wieder richtig kalt wird.

Hat der Sensor eine Abdichtung am Batteriedeckel? Ohne Abdichtung dürfte er nur bedingt für draussen geeignet sein.

Gruß Ralf

Moin Ralf,

ich will den Sensor nur drinnen verwenden, für draussen habe ich was anderes. Aber es juckt ja schon in den Fingern, die Werte richtig aus den Bits zu bekommen.
Ich versuche einfach mal die nächsten Tage nochmal ein paar gesicherte (heisst mehrere Minuten der gleiche Wert) Werte zu bekommen.

Gruß,
Tim
FHEM auf Raspberry Pi
HM-CFG-LAN mit HM-TC-IT-WM-W-EU, HM-CC-RT-DN, HM-WDS10-TH-O, HM-LC-SW1-FM, HM-LC-Bl1-FM
Signalduino mit Elro AB440, LOGILINK WS0002, IT CMR-1000

reibuehl

Zitat von: Cruiser79 am 28 Januar 2016, 16:06:37
Moin Ralf,

ich will den Sensor nur drinnen verwenden, für draussen habe ich was anderes. Aber es juckt ja schon in den Fingern, die Werte richtig aus den Bits zu bekommen.
Ich versuche einfach mal die nächsten Tage nochmal ein paar gesicherte (heisst mehrere Minuten der gleiche Wert) Werte zu bekommen.

Gruß,
Tim

Evtl. wird das vergleichen ja einfacher, wenn Du eine Webcam/GoPro/etc. mit korrekter Uhrzeit auf das Display richtest. Dann musst Du nur zu den entsprechenden Punkten spulen, zu denen Du auch Logeinträge hast.

Gruß,
Reiner
Reiner.

Ralf9

Zitat von: Ralf9 am 27 Januar 2016, 21:53:05
Eine etwas unsaubere Möglichkeit, die man probieren könnte, wäre es mit einer Formel zu versuchen:

temp = (bitdataTemp - x) / y

Hallo Tim,

ich habe das mit der Formel mal ins 90_SIGNALduino_un.pm Modul eingebaut, Du kannst mal testen ob die Temperaturen im log jetzt besser passen.

Gruß Ralf
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

Sidey

Zitat von: trebron106 am 27 Januar 2016, 09:02:57
hier sind die Signaldaten :

2016.01.27 08:47:10 4: sduino/msg READ: MU;P0=-781;P1=-32001;P2=893;P3=-346;P4=452;P5=-3033;D=00123232323232323402340452323232323232340402345232340234023402323404523234023402340234023454040404040404040232345404040404040404040404540402340234040402323454040234023404040404045404023234023232323404540402323402323234023454023232340234040;CP=4;O;

Hmm, das ist interessant. Ich tippe folgendes:

Es wird ein "Satz" übertragen, der aus mehreren "Wörtern besteht". Zwischen den Wörtern, ist eine kleine Pause (5).

Das ist in sofern interessant, da mir auf Anhieb nicht einfällt, welche Vorteile das bringt.
Die Auswerteroutine die ich aktuell entwickelt habe, kommt damit auch erst einmal nicht zurecht, bzw. es würde jedes Wort einzeln ausgewertet werden.
Um dann wieder den kompletten Satz zu erhalten, müsste man einen Puffer an geeigneter Stelle implementieren.
Alles machbar, aber auch ein gewisser Aufwand.

Ansonsten könnten das Signal wie folgt demoduliert werden:
23= Bit 1
45 = Bit 0

Offen wäre für mich allerdings
1. Passt der komplette Satz überhaupt in den Puffer und wurde der Satz somit komplett empfangen
2. Wie ist der Start /das Ende eines Satzes markiert.

These, wir haben den Anfang, aber uns fehlt vermutlich noch das Ende.
Hast Du irgendwo noch Daten zu den Schaltern gefunden?


Zitat von: pejonp am 27 Januar 2016, 16:07:40
Hallo Sidey,

ich habe eben ein Update gemacht und jetzt werden meine Hideki-Sensoren (Bresser und Hama ) nicht mehr erkannt. Es ist nichts an- oder ausgeschalten. Verbose=5

Das klingt nicht gut. Ich habe bestimmt schon 2 Wochen nichts mehr an Hideki, Manchester etc. verändert.
Kannst Du denn die letzte Version benennen oder zumindest eingrenzen, bis wann es funktioniert hat?


Zitat von: Ralf9 am 27 Januar 2016, 21:53:05
@Sidey hast Du eine Idee was da nicht passen könnte? Hattest Du schon mal so einen komischen Fall?


@Sidey ist es evtl sinnvoll, zukünftig für mehrere Temperatursensoren ein gemeinsames Weather-Modul zu entwickeln? Dort könnten dann auch die unbekannten  Temperatursensoren reinkommen.
Nachtrag:
Diese Protokolle könnten dann z.B. mit W beginnen. zB. W37#

So ein Problem hatte ich noch nicht. Auch hier ist eigentlich anzunehmen, dass der Entwickler, der das Funkprotokoll entwickelt hat, sicher nichts komplizierter gemacht hat, als es sein muss. Vielleicht hat er aber auch eine Korrekturformel in den Empfänger eingebaut, weil er festgestellt hat, dass die Sender nicht linear messen.
Da hilft wohl nur experimentieren.

Zur Idee mehrere Sensoren in ein Modul folgende Punkte:

Du meinst mehrere Protokolle in ein Modul.

Chancen:
Das Einbinden neuer Sensoren kann einfacher werden, da nicht die kompletten Funktionen eines Modules entwickelt werden müssen. Beispiele gibt es ja aus dem TRX_Weather Umfeld, wie gut das funktioniert.

Risiken:
Anpassungen in dem Modul, betreffen alle Sensoren. Beispiele finden sich auch z.B. CUL_TCM97001
Unterschiedliche Sensortypen, die aber das gleiche Protokoll verwenden, lassen sich nur schwer auf mehrere Module aufteilen.

Pro:
Wir brauchen weniger Module

Contra:
Das Modul müsste in FHEM von einer Person verantwortet werden. (Maintainer)


Das ist jetzt erst mal meine Sicht.
Die Trennung 1 Modul = 1 Protokoll, empfand ich in sofern gut da
1. Die Zuordnung intuitiv und technisch auch super einfach umgesetzt werden kann.
2. Jeder ein logisches Modul beisteuern und pflegen kann.


Machbar ist allerdings beides. Ein "Mega" Modul zu bauen ist möglich, bedarf aber einiger Überlegungen, damit es später auch lesbar und wartbar bleibt.
z.B. mittels dispatchtable etc.. Dadurch wird aber die Hürde vermutlich wieder etwas höher dass sich andere an der Entwicklung beteiligen.
Ein eigenes Modul zu bauen ist aus meiner Sicht keine große Aktion, da mittels suchen und Ersetzen ein vorhandenes schon mal sehr schnell umbenannt werden kann.
Und danach ist vermutlich nur noch in der parse Funktion, die entsprechende Logik für das Auswerten zu ergänzen.

Das ganze ließe sich auch noch weiter Vereinfachen, wenn wir die Sensoren wie Objekte betrachten würden und das ganze Modul so weit standardisieren, dass nur noch Funktionen wie

getTemp (Hole bits x - y,  Fomel zum Umrechnen, rückgabe)
getHum
getSendmode (Hole bits x - y,  <an aus>, rückgabe)
getxyz
getCrc
calcCrc
...

angepasst werden müssten.

Grüße Sidey
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem,zigbee2mqtt

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

Ralf9

Zitat von: Sidey am 29 Januar 2016, 23:21:33
Das klingt nicht gut. Ich habe bestimmt schon 2 Wochen nichts mehr an Hideki, Manchester etc. verändert.
Kannst Du denn die letzte Version benennen oder zumindest eingrenzen, bis wann es funktioniert hat?

Ich habe auch die Hama und Bresser Sensoren, bei mir funktioniert es. Ich habe die Version 3.2.0-b11 und habe die MU-Nachrichten disabled da ich nur die Protokolle 0,7,12 verwende.
Die Version 3.2.0-b11 läuft sehr stabil, ich habe mittlerweile eine uptime von 5 Tagen.


Zitat von: Sidey am 29 Januar 2016, 23:21:33
Zur Idee mehrere Sensoren in ein Modul folgende Punkte:

Risiken:
Anpassungen in dem Modul, betreffen alle Sensoren. Beispiele finden sich auch z.B. CUL_TCM97001
Unterschiedliche Sensortypen, die aber das gleiche Protokoll verwenden, lassen sich nur schwer auf mehrere Module aufteilen.

Ich würde nur für die einfachen Temperatursensoren und Protokolle ein gemeinsames Modul verwenden.


Zitat von: Sidey am 29 Januar 2016, 23:21:33
Das ganze ließe sich auch noch weiter Vereinfachen, wenn wir die Sensoren wie Objekte betrachten würden und das ganze Modul so weit standardisieren, dass nur noch Funktionen wie

getTemp (Hole bits x - y,  Fomel zum Umrechnen, rückgabe)
getHum
getSendmode (Hole bits x - y,  <an aus>, rückgabe)
...

Das Modul wird damit viel zu kompliziert. Das Modul sollte recht einfach sein, damit es auch jemand der nur Perl Grundkenntnise hat, verstehen und ergänzungen vornehmen kann.

Ich habe es mir wie folgt gedacht:

Es könnte z.B. 14_SD_Weather heißen

Ein W am Anfang, z.B. W31#

else if Abschnitte wie bei der 90_SIGNALduino_un
am Anfang kann mit log Ausgaben getestet werden
wenn der model-Variablen ein model zugewiesen wird, dann wird auch das autocreate verwendet.

Gruß Ralf
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

pejonp

Hallo Sidey,

ich hatte vorher eine Version vom 16.1.2016, genau weiß ich es auch nicht mehr.
Mir ist ja nur das aufgefallen.


2016.01.27 16:02:36 4: sduinousb/msg READ: MC;LL=-952;LH=1005;SL=-481;SH=502;D=7A174A61B7EBB1147A2E00;C=502;
2016.01.27 16:02:36 4: sduinousb Found manchester Protocol id 10 clock 502 -> OSV2o3
2016.01.27 16:02:36 4: sduinousb Found manchester Protocol id 12 clock 502 -> Hideki protocol
2016.01.27 16:02:36 4: sduinousb/msg READ: MC;LL=-971;LH=993;SL=-487;SH=493;D=AE7A174A21B7EBB114780000;C=495;
2016.01.27 16:02:36 4: sduinousb Found manchester Protocol id 10 clock 495 -> OSV2o3
2016.01.27 16:02:36 4: sduinousb Found manchester Protocol id 12 clock 495 -> Hideki protocol
2016.01.27 16:02:37 4: sduinousb/msg READ: MU;P0=-8368;P2=973;P3=-981;P4=-490;P5=490;D=40232324545354245454532354545423245453235423235423545454542453245324545454545323245453245354542354542323545424545453245354245323545454;CP=5;
2016.01.27 16:02:37 4: Fingerprint for MU Protocol id 16 -> Dooya shutter matches, trying to demodulate


es wird ja anscheinend Hideki erkannt aber nicht an das Modul weitergegeben. 1 Sensor von 3 wird ja noch erkannt. Die Batterien können eigentlich nicht leer sein, sind noch nicht lange im Gerät.
Aber es hat keine Eile, ich bin jetzt erst einmal eine Woche im Urlaub (es geht gleich los).

Tschüß Jörg
LaCrossGW 868MHz:WT470+TFA+TX37-IT+EMT7110+W136+WH25A HP1003+WH2621
SignalD(CC1101):Bresser+WS-0101(868MHz WH1080)+Velux KLF200+MAX!+HM-MOD-UART:Smoke HM-SEC-SD+VITOSOLIC 200 RESOL VBUS-LAN+SolarEdge SE5K(Modbus)+Sonnen!eco8(10kWh)+TD3511+DRT710M(Modbus)+ZigBee+Z-Wave+MQTT+vitoconnect

Burny4600

Gibt es eigentlich ein Protokollübersicht für den SignalDuino wo die Zuordnung der Protokollnummer zum Sensor gegeben ist.
LG Chris

Raspberry Pi 2-5, Bullseye Lite, Bookworm Lite
Schnittstellen: 1-Wire, FHEM2FEHEM, HM-MOD-UART, LAN, Modbus, MQTT, nanoCUL, RFXtrx433E, SIGNALduino, ser2net
Devices: APC, Eastron, FS20, IT, Homematic, MQTT, PV-(DEYE, EPEVER, FRONIUS), Resol-VBUS, S.USV, TEK603, WMR200, YouLess

trebron106

Hallo Sidey,

ich habe die RF_Reicever.ino einmal geändert, damit wird jetzt der komplette Datensatz gesendet und ich kann damit die Rolladen ansteuern. Die Änderungen betreffen hauptsächlich Datentypen uint8_t geändert in uint16_t , damit werden auch Strings die länger als 255 Zeichen sind verarbeitet. Auch habe ich die String.substring() Routine in "split_cmdpart" ersetzt, da sie mit langen Strings nicht zurechtkommt.


//================================= RAW Send ======================================
void send_raw(const uint8_t startpos,const uint8_t endpos,const int16_t *buckets, String *source=&cmdstring)

for (uint8_t i=startpos;i<=endpos;i++ )

// geändert in:

//================================= RAW Send ======================================
void send_raw(const uint16_t startpos,const uint16_t endpos,const int16_t *buckets, String *source=&cmdstring)

for (uint16_t i=startpos;i<=endpos;i++ )


//============================= split_cmdpart   =======================================

bool split_cmdpart(int16_t *startpos, String *msg_part)
{
int16_t endpos=0;
//startpos=cmdstring.indexOf(";",startpos);    // search first  ";"
endpos=cmdstring.indexOf(";",*startpos);      // search next   ";"

if (endpos ==-1 || *startpos== -1) return false;
*msg_part = cmdstring.substring(*startpos,endpos);
*startpos=endpos+1;    // Set startpos to endpos to extract next part
return true;
}


// geändert in:

bool split_cmdpart(int16_t *startpos, String *msg_part)
{
int16_t endpos=0;
  *msg_part = "";
 
//startpos=cmdstring.indexOf(";",startpos);    // search first  ";"
endpos=cmdstring.indexOf(";",*startpos);      // search next   ";"

  for (int16_t n=*startpos; n<=endpos; n++ ){
      *msg_part+=cmdstring.substring(n,n+1);
    }

if (endpos ==-1 || *startpos== -1) return false;
// *msg_part = cmdstring.substring(*startpos,endpos);
*startpos=endpos+1;    // Set startpos to endpos to extract next part
return true;
}

//============================= s_sendcmd  =======================================

struct s_sendcmd {
int sendclock;
uint8_t type;
uint8_t datastart;
uint8_t dataend;
int16_t buckets[6];
} ;


// geändert in:

struct s_sendcmd {
int sendclock;
uint8_t type;
uint16_t datastart;
uint16_t dataend;
int16_t buckets[6];
} ;



Ich habe die Sendedaten mit einen Datalogger mit geschnitten, es sind immer 12 Blöcke die mit einem 3030µs Low Signal anfangen und danach folgen 11 Pulse unterschiedlicher Länge. Die ersten 6 Blöcke enthalten die Adresse des Senders und sind immer gleich.  Wie schon oben geschrieben, funktioniert das Senden als RAW mit den Änderungen und das genügt mir schon. Vielleicht kannst du das ganze in die nächste Version einpflegen.

Gruß
Klaus