Datenweitergabe vom TFA 30.3208.02 über Signalduino an FHEM

xlf. · 12 Januar 2019, 16:11:06

Hallo zusammen,

ich habe einen TFA Hydrosensor 30.3208.02, der über einen Signalduino erkannt wurde in FHEM und Daten liefert.

Mein Problem:
Es werden nur sporadisch Daten an FHEM weitergegeben, wenn ich das so ausdrücken darf. Jede Minute sehe ich im Log folgende Zeilen mit verbose 5:

Code Auswählen

2019.01.12 16:07:31 4: SIGNALduino433/keepalive ok, retry = 0
2019.01.12 16:07:44 4: SIGNALduino433/msg READ: MC;LL=-983;LH=971;SL=-474;SH=523;D=002BA37EBBCB136F0015D1BF5DE589B7800AE8DE;C=488;L=159;R=43;
2019.01.12 16:07:44 4: SIGNALduino433: Found manchester Protocol id 10 clock 488 RSSI -52.5 -> OSV2o3
2019.01.12 16:07:44 5: SIGNALduino433: extracted data 1111111111010100010111001000000101000100001101001110110010010000111111111110101000101110010000001010001000011010011101100100100001111111111101010001011100100001 (bin)
2019.01.12 16:07:44 5: SIGNALduino433: protocol does not match return from method: (undef)
2019.01.12 16:07:44 4: SIGNALduino433: Found manchester Protocol id 12 clock 488 RSSI -52.5 -> Hideki protocol
2019.01.12 16:07:44 5: SIGNALduino433: extracted data 0000000000101011101000110111111010111011110010110001001101101111000000000001010111010001101111110101110111100101100010011011011110000000000010101110100011011110 (bin)
2019.01.12 16:07:44 4: SIGNALduino433: receive Hideki protocol not inverted
2019.01.12 16:07:44 4: SIGNALduino433: Hideki protocol converted to hex: 75D8D79E23ED00D4625F with 85 bits, messagestart 10
2019.01.12 16:07:44 5: SIGNALduino433 Dispatch: P12#75D8D79E23ED00D4625F, test gleich
2019.01.12 16:07:44 5: SIGNALduino433 Dispatch: P12#75D8D79E23ED00D4625F, -52.5 dB, dispatch
2019.01.12 16:07:44 5: SIGNALduino433: dispatch P12#75D8D79E23ED00D4625F
2019.01.12 16:07:44 4: SIGNALduino433 Hideki_Parse: incomming P12#75D8D79E23ED00D4625F
2019.01.12 16:07:44 4: SIGNALduino433 Hideki_crc: rawdata=75D8D79E23ED00D4625F to short, count=28 data length=10
2019.01.12 16:07:44 4: SIGNALduino433: Found manchester Protocol id 52 clock 488 RSSI -52.5 -> OS_PIR
2019.01.12 16:07:44 5: SIGNALduino433: extracted data 1111111111010100010111001000000101000100001101001110110010010000111111111110101000101110010000001010001000011010011101100100100001111111111101010001011100100001 (bin)
2019.01.12 16:07:44 5: SIGNALduino433: protocol does not match return from method: ( header not found)
2019.01.12 16:07:44 4: SIGNALduino433: Found manchester Protocol id 58 clock 488 RSSI -52.5 -> tfa 30.3208.0 
2019.01.12 16:07:44 5: SIGNALduino433: extracted data 1111111111010100010111001000000101000100001101001110110010010000111111111110101000101110010000001010001000011010011101100100100001111111111101010001011100100001 (bin)
2019.01.12 16:07:44 4: SIGNALduino433: TFA 30.3208.0 preamble_pos = 77
2019.01.12 16:07:44 4: SIGNALduino433: TFA message start=77 end=129 with length52
2019.01.12 16:07:44 5: SIGNALduino433: part 0100010111001000000101000100001101001110110010010000
2019.01.12 16:07:44 4: SIGNALduino433: 45C814434EC90
2019.01.12 16:07:44 4: SIGNALduino433: TFA message start=142 end=160 with length18
2019.01.12 16:07:44 5: SIGNALduino433: part 010001011100100001
2019.01.12 16:07:44 4: SIGNALduino433: 11721
2019.01.12 16:07:44 5: SIGNALduino433: protocol does not match return from method: ( no duplicate found)

Sporadisch werden Daten vom Sensor weitergegeben, das allerdings in viel größeren Abständen. Logauszug mit verbose 4:

Code Auswählen

2019.01.12 15:48:31 4: SIGNALduino433/keepalive ok, retry = 0
2019.01.12 15:48:43 4: SIGNALduino433/msg READ: MC;LL=-984;LH=957;SL=-482;SH=494;D=0015D1BF5DC57657800AE8DFAEE2BB2BC005746FD4;C=486;L=166;R=37;
2019.01.12 15:48:43 4: SIGNALduino433: Found manchester Protocol id 10 clock 486 RSSI -55.5 -> OSV2o3
2019.01.12 15:48:43 4: SIGNALduino433: Found manchester Protocol id 12 clock 486 RSSI -55.5 -> Hideki protocol
2019.01.12 15:48:43 4: SIGNALduino433: receive Hideki protocol not inverted
2019.01.12 15:48:43 4: SIGNALduino433: Hideki protocol converted to hex: 75D8D78EDDEA00D4625F with 85 bits, messagestart 11
2019.01.12 15:48:43 4: SIGNALduino433 Hideki_Parse: incomming P12#75D8D78EDDEA00D4625F
2019.01.12 15:48:43 4: SIGNALduino433 Hideki_crc: rawdata=75D8D78EDDEA00D4625F to short, count=28 data length=10
2019.01.12 15:48:43 4: SIGNALduino433: Found manchester Protocol id 52 clock 486 RSSI -55.5 -> OS_PIR
2019.01.12 15:48:43 4: SIGNALduino433: Found manchester Protocol id 58 clock 486 RSSI -55.5 -> tfa 30.3208.0 
2019.01.12 15:48:43 4: SIGNALduino433: TFA 30.3208.0 preamble_pos = 13
2019.01.12 15:48:43 4: SIGNALduino433: TFA message start=13 end=65 with length52
2019.01.12 15:48:43 4: SIGNALduino433: 45C8144751350
2019.01.12 15:48:43 4: SIGNALduino433: TFA message start=78 end=130 with length52
2019.01.12 15:48:43 4: SIGNALduino433: 45C8144751350
2019.01.12 15:48:43 4: SIGNALduino433: TFA message start=143 end=168 with length25
2019.01.12 15:48:43 4: SIGNALduino433: 08B902B
2019.01.12 15:48:43 4: SIGNALduino433: repeated hex 45C8144751350 found 2 times
2019.01.12 15:48:43 4: SD_WS_Parse: Protocol: 58, rawData: 45C8144751350
2019.01.12 15:48:43 4: SIGNALduino433 decoded protocolid: 58 (TFA 3032080) sensor id=200, channel=2, temp=20.8, hum=81, bat=ok

Habt ihr eine Idee, woran das liegt?

Wenn ich noch erweiterte Daten liefern kann, gerne melden!

Vorab vielen Dank und beste Grüße

yoda_gh · 12 Januar 2019, 19:52:54

Sehr interessant. Ich habe hier auch diverse TFA 30.3208.02 mit einem SIGNALduino mit günstigem 433 MHz-Empfänger verteilt über verschiedene Stockwerke seit längerem im Einsatz und es schaut eigentich so aus, dass alles auch seit dem Firmware-Update auf 3.3.1-RC10 und Modulupdate auf v3.3.3-dev_30.12. normal läuft.

Allerdings habe ich vor einigen Tagen einen neuen Sensor auf Channel 6 in Betrieb genommen und mich sehr gewundert, dass nur wenige Nachrichten korrekt empfangen wurden (vielleicht eine alle 15 Minuten), obwohl der Sensor wenige Meter entfernt vom SIGNALduino lag. Ich hatte das eigentlich auf einen schlecht funktionierenden Sender in diesem Sensor geschoben, ohne mich weiter darum zu kümmern, da es mir letztlich auch reicht, wenn ich alle 1-2 Std. einen Wert bekomme.

Interessanterweise werden wie gesagt die Telegramme von diversen Sensoren, die bis zu 2 Stockwerke vom SIGNALduino entfernt sind nach wie vor gut empfangen. Es kann also keine generelle Verschlechterung des Empfangs vorliegen.

Könnte es denn sein, dass er sich bei bestimmten Inhalten der Telegramme systematisch häufiger vertut? Z.B. bei einem bestimmten Channel oder so? Hast Du schon mal einen anderen Channel probiert? Was heißt denn "sporadisch" und "viel größere Abstände" etwas genauer? Wie oft klappt's denn?

Wie gesagt, ich habe das die letzten Monate/Jahre nie genauer beobachtet, da ich letztlich nicht mehr wie einen Wert alle 2-3 Stunden brauche und in dem Rahmen hat immer alles funktioniert...

Ralf9 · 12 Januar 2019, 20:09:39

ZitatHabt ihr eine Idee, woran das liegt?

Du hast anscheinend keine optimalen Empfangsbedingungen.

Du kannst mal meine firmware V 3.3.2.1-rc8 testen, damit müssten eigentlich die TFA 30.3208.02 besser empfangen werden.
https://forum.fhem.de/index.php/topic,82379.msg744554.html#msg744554

Gruß Ralf

xlf. · 12 Januar 2019, 22:51:46

Hallo zusammen,

ZitatKönnte es denn sein, dass er sich bei bestimmten Inhalten der Telegramme systematisch häufiger vertut? Z.B. bei einem bestimmten Channel oder so? Hast Du schon mal einen anderen Channel probiert?

Den Channel habe ich noch nicht geändert. Werde ich aber als eigenen Test nochmal durchführen und das Ergebnis hier ergänzen.

ZitatWas heißt denn "sporadisch" und "viel größere Abstände" etwas genauer? Wie oft klappt's denn?

Durchschnittlich (über den gestrigen Tag gemessen) kann etwa jeder 15. Wert interpretiert werden, das entspricht auch etwa 15 Minuten. Es gibt allerdings gehäuft Ausreißer nach oben, dann ist es eine zeitliche Differenz von fünf Stunden zwischen zwei erfolgreichen Werten!

ZitatDu hast anscheinend keine optimalen Empfangsbedingungen.

Das kann ich so nicht bestätigen. Ich habe den Sender auch direkt neben den Signalduino gelegt (weniger als fünf cm Abstand) und habe noch immer die "kaputten" Werte bekommen. Diesen Test habe ich etwa eine Stunde so laufen lassen.

ZitatDu kannst mal meine firmware V 3.3.2.1-rc8 testen, damit müssten eigentlich die TFA 30.3208.02 besser empfangen werden.

Tatsächlich bekomme ich jetzt seit etwa einer halben Stunde konstant Werte alle paar Minuten, die höchste zeitliche Differenz war bisher fünf Minuten. Im Log kann ich auch keine "kaputten" Werte mehr sehen.

Ich werde das jetzige Verhalten noch ein wenig beobachten und dann nochmal berichten, ob es eine langfristige Besserung zu geben scheint.

Besten Dank für die Unterstützung!

Sidey · 13 Januar 2019, 13:26:26

Zitat von: xlf. am 12 Januar 2019, 16:11:06
Hallo zusammen,

ich habe einen TFA Hydrosensor 30.3208.02, der über einen Signalduino erkannt wurde in FHEM und Daten liefert.

Habt ihr eine Idee, woran das liegt?

Da kann es viele Gründe geben.
Damit wir dir helfen können, brauchen wir mehr Details über die eingesetzten Versionen von Firmware und Modul.

Grüße Sidey

Gesendet von meinem Moto Z (2) mit Tapatalk

xlf. · 14 Januar 2019, 07:52:41

Nochmal ein kurzer Zwischenstand:
Weiterhin konstant Werte, durchschnittlich etwa 1,5 Minuten Abstand zwischen den Werten - also Perfekt!

ZitatDamit wir dir helfen können, brauchen wir mehr Details über die eingesetzten Versionen von Firmware und Modul.

Der Arduino mit CC1101 ist die Firmware von Ralf9 geflashed. In FHEM bin ich mit der aktuellen Developer-Version unterwegs. Beide Softwareupdates habe ich am 12.01 gemacht.

Sidey · 14 Januar 2019, 09:14:16

Zitat von: xlf. am 14 Januar 2019, 07:52:41In FHEM bin ich mit der aktuellen Developer-Version unterwegs. Beide Softwareupdates habe ich am 12.01 gemacht.

Welche ist das genau?

Insbesondere interessant ist, welche Firmware Du verwendest.
Zur Ralfs Spezial Version kann ich leider keinen Support geben.

Grüße Sidey

Gesendet von meinem Moto Z (2) mit Tapatalk

Ralf9 · 14 Januar 2019, 18:31:29

Hallo Sidey,

aus den logs von xlf. lässt sich recht einfach erkennen, daß die MC-Nachrichten 3 Nachrichten hintereinander enthalten. Bei der MC-Nachricht vom ersten log fehlt bei der ersten Nachricht am Anfang ein Teil der Preamble und bei der dritten Nachricht fehlt das Ende.
Anscheinend kommt die firmware die er vorher hatte, mit den Daten die der TFA 30.3208.02 sendet nicht zurecht.

Gruß Ralf

xlf. · 15 Januar 2019, 15:34:26

Hallo zusammen,

ZitatWelche ist das genau?

Die Firmware auf dem Arduino war, bevor ich die Version von Ralf9 geflashed habe, 3.3.1-RC10. In FHEM bin ich mit der Revision 18220 unterwegs. Falls ich hier mehr Details liefern kann, brauche ich ein kurzes HowTo.

Nächster Zwischenstand:
Gestern waren die Werte im Abstand von 1,55 Minuten, heute im Abstand von 1,38 Minuten - weiterhin Perfekt!

Ralf9 · 15 Januar 2019, 17:17:24

Kannst Du mal ein paar MC Nachrichten Posten?
Mich interessiert wie viele Wiederholungen empfangen werden.
Gruß Ralf

xlf. · 17 Januar 2019, 17:26:35

Hallo Ralf,

entsprechen diese Logauszüge dem, was Dich interessiert?

Code Auswählen

MC;LL=-976;LH=971;SL=-478;SH=529;D=5746FD7B77449E002BA37EBDBBA24F0015D1BF5EDDD1278;C=487;L=185;R=44;s5;b0;
MC;LL=-985;LH=954;SL=-488;SH=521;D=002BA37EBDBBA24F0015D1BF5EDDD127800AE8DFAF6EE893C;C=487;L=194;R=41;s21;b0;
MC;LL=-981;LH=971;SL=-485;SH=512;D=002BA37EBDBBA24F0015D1BF5EDDD127800AE8DFAF6EE893C;C=488;L=194;R=41;s23;b0;
MC;LL=-981;LH=964;SL=-480;SH=520;D=002BA37EBDBBA24F0015D1BF5EDDD127800AE8DFAF6EE893C;C=486;L=194;R=34;s21;b0;
MC;LL=-980;LH=969;SL=-497;SH=515;D=002BA37EBDBBA24F0015D1BF5EDDD127800AE8DFAF6EE893C;C=486;L=194;R=37;s24;b0;
MC;LL=-989;LH=966;SL=-483;SH=522;D=002BA37EBDBBA24F0015D1BF5EDDD127800AE8DFAF6EE893C;C=488;L=194;R=41;s23;b0;
MC;LL=-985;LH=974;SL=-483;SH=519;D=002BA37EBDBBA24F0015D1BF5EDDD127800AE8DFAF6EE893C;C=487;L=194;R=40;s23;b0;
MC;LL=-981;LH=981;SL=-473;SH=536;D=002BA37EBDBBA24F0015D1BF5EDDD127800AE8DFAF6EE893C;C=487;L=194;R=39;s21;b0;

Viele Grüße

Ralf9 · 17 Januar 2019, 19:17:56

Hallo xlf.

danke für die Logauszüge, das ist genau was ich wollte. Der TFA 30.3208.02 wird nun sehr gut empfangen.
Im u.g. log lässt sich erkennen, daß nun alle 3 Nachrichten sauber empfangen werden.
Damit die Nachrichten im SD_WS weiter verarbeitet werden, sind 2 Nachrichten erforderlich.

Mit einer Optimierung im 00_SIGNALduino.pm sieht das log so aus.
Es kann noch eine Weile dauern bis die Optimierungen in der dev-r33 sind.

Code Auswählen


2019.01.17 18:35:17.156 4 : sduinoD/msg get raw: MC;LL=-980;LH=969;SL=-497;SH=515;D=002BA37EBDBBA24F0015D1BF5EDDD127800AE8DFAF6EE893C;C=486;L=194;R=37;
2019.01.17 18:35:17.156 4 : sduinoD: Found manchester Protocol id 58 clock 486 RSSI -55.5 -> TFA 30.3208.0
2019.01.17 18:35:17.156 5 : sduinoD: extracted data 1111111111010100010111001000000101000010010001000101110110110000111111111110101000101110010000001010000100100010001011101101100001111111111101010001011100100000010100001001000100010111011011000011 (bin)
2019.01.17 18:35:17.156 4 : sduinoD: TFA 30.3208.0 preamble_pos = 12
2019.01.17 18:35:17.156 4 : sduinoD: TFA message start=12 end=64 with length=52
2019.01.17 18:35:17.156 5 : sduinoD: part 0100010111001000000101000010010001000101110110110000
2019.01.17 18:35:17.156 4 : sduinoD: 45C8142445DB0
2019.01.17 18:35:17.156 4 : sduinoD: TFA message start=77 end=129 with length=52
2019.01.17 18:35:17.156 5 : sduinoD: part 0100010111001000000101000010010001000101110110110000
2019.01.17 18:35:17.156 4 : sduinoD: 45C8142445DB0
2019.01.17 18:35:17.157 4 : sduinoD: TFA message start=142 end=194 with length=52
2019.01.17 18:35:17.157 5 : sduinoD: part 0100010111001000000101000010010001000101110110110000
2019.01.17 18:35:17.157 4 : sduinoD: 45C8142445DB0
2019.01.17 18:35:17.157 4 : sduinoD: repeated hex 45C8142445DB0 found 3 times
2019.01.17 18:35:17.157 5 : sduinoD: dispatch W58#45C8142445DB0
2019.01.17 18:35:17.157 4 : SD_WS_Parse: Protocol: 58, rawData: 45C8142445DB0
2019.01.17 18:35:17.157 4 : sduinoD decoded protocolid: 58 (TFA 3032080) sensor id=200, channel=2, temp=18.9, hum=69, bat=ok
2019.01.17 18:35:17.157 1 : SD_WS: UNDEFINED sensor SD_WS_58_TH detected, code SD_WS_58_TH_2
2019-01-17 18:35:17.163 Global global UNDEFINED SD_WS_58_TH_2 SD_WS SD_WS_58_TH_2

Gruß Ralf