Ab meiner firmware
V 3.3.4.
https://forum.fhem.de/index.php/topic,82379.msg1010643.html#msg1010643
und
V 4.x.xhttps://forum.fhem.de/index.php/topic,106278.msg1001477.html#msg1001477
ist auch ein
Empfangen und Senden von FSK modulierten Signalen möglich. Es gibt auch 10 EEPROM Speicherbänke in denen die cc1101 Register gespeichert werden können.
Der sduino hat die Option, verschiedene Funk-Modi für die dauerhafte Nutzung zu speichern und zwischen den gespeicherten Funk-Modi per raw-Befehl flexibel und einfach umzuschalten.
In dem übernächsten Beitrag sind noch weitere Funk-Modi aufgeführt
u.a.
1. Empfang von IT+ Protokoll(Lacrosse Sensoren; FSK-Modulation bei 17.241 und 9.579 kbps)
2. Senden/Empfang von PCA301 (Funkmesssteckdosen bisher in der Regel nur per Jeelink oder LaCrosse Gateway zu empfangen)
3. Kopp Free Control
hier sind weitere Infos zu FSK mit dem SIGNALDuino:
https://forum.fhem.de/index.php/topic,106594.msg1150650.html#msg1150650
Für die einfache u. flexible Umschaltung werden im EEPROM (z.B. Nano oder Promini) 10 Speicherbänke, die mit 0-9 adressiert werden, genutzt. Die firmware des sduino hat zur Verwaltung die folgenden raw-Befehle:
- get raw
e<0-9>je nach Speicherbank; der Befehl initialisiert und aktiviert die jeweilige Speicherbank mit Standard-Settings[FactoryReset])
- get raw
b<0-9> je nach Speicherbank; der Befehl aktiviert die angegebene Speicherbank, dazu wird der cc1101 mit den in der Speicherbank gespeicherten Registern initialisiert.
mit nachgestelltem W, also set raw bNW, wird die "Standard-Bank" dauerhaft im EEPROM gespeichert, so dass der sduino immer in diesem
Modus startet
- get raw
CW, damit kann eine folge von cc1101 Registern gesetzt und in die aktuelle EEPROM Speicherbank geschrieben werden.
- get raw
b oder
b? damit wird eine Info über die aktive Speicherbank ausgegeben
Ab der firmware 4.x (z.Zt. nur für den Maple Mini) werden auch bis zu vier cc1101 Module und ein LAN-Modul unterstützt
https://forum.fhem.de/index.php/topic,106278.0.html
Für die zusätzlichen cc1101 gibt es die folgenden raw Befehle:
CR - configRadioMIt CRE<A-D> kann ein cc1101 Modul aktiviert werden. z.B. CREA aktiviert das erste cc1101 Modul A
MIt CRD<A-D> kann ein cc1101 Modul deaktiviert werden. z.B. CRDA deaktiviert das erste cc1101 Modul A
Der Befehl
b wurde erweitert:
b <A-D><0-9> damit wird ein cc1101 (A-D) mit einer Speicherbank (0-9) initialisiert. z.B. mit bA3 wird das das erste cc1101 Modul A mit der Speicherbank 3 initalisiert.
b<A-D> damit wird ein cc1101 (A-D) selektiert. Die Befehle zum lesen und schreiben vom EEPROM und cc1101 Registern werden auf das selektierte cc1101 angewendet. Z.B. mit bA wird das erste cc1101 Modul A selektiert.
Ein FSK Sendekommando sieht so aus:
SN;R=13;N=4;D=07FA5E1921CC0F02F0000000000000;13 Wiederholungen
Mit N=4 wird angegeben, dass mit dem cc1101 Modul gesendet wird, das der Kopp Free Controll Speicherbank zugeordnet ist. Wenn z.B. die Bank 4 für Kopp verwendet wird und mit bA4 das cc1101 Modul A der Bank 4 zugeordnet ist, dann wird das cc1101 Modul A zum Senden verwendet.
Eine raw Nachricht sieht z.B. so aus:
MN;D=07FA5E1721CC0F02FE000000000000;N=4;Mit dem N=4 kann das 00_Signalduino Modul die raw Nachricht der Protocol ID 102 zuordnen und entsprechend weiter verarbeiten.
Für die FSK und EEPROM Speicherbank unterstützung ist eine
angepasste und erweiterte Version der 00_SIGNALduino.pm und die signalduino_protocols.pm
notwendig:
https://forum.fhem.de/index.php/topic,111653.msg1058900.html#msg1058900
https://github.com/Ralf9/RFFHEM/issues/4
In dem übernächsten Beitrag sind die die für FSK notwendigen Registeränderungen beschrieben.
Für einige Protokolle sind angepasste Module notwendig
- 101 (PCA 301)
https://github.com/Ralf9/36_PCA301.pm
- 102 (Kopp) siehe Anlage
und das angepasste und erweiterte Modul 14_SD_WS.pm:
- 107 (DP100, WH51)
- 108 (Bresser 5in1)
- 115 (Bresser 5in1 neu und Bresser 6in1 )
- 116 (DP60, WH57)
- 204 (WH24 WH65A/B)
- 205 (WH25 WH25A)
- 206 (W136)
https://github.com/Ralf9/14_SD_WS/blob/main/FHEM/14_SD_WS.pm
Gruß Ralf
Bitte ergänzen.
Laut http://www.panstamp.org/forum/showthread.php?tid=3070 ist noch bei
Mode 1 - IT+ 17.241 kbps
Mode 2 - IT+ 9.579 kbps
ein Synchronwort 0x2DD4 wichtig.
Das betrifft bestimmt
0x04 SYNC1
0x05 SYNC0
hier gehts u.a. um die für FSK notwendigen Registeränderungen.
Ab meiner firmware V 3.3.4.0 dev 200121 gibts ein neues Kommando "CW", damit kann eine folge von cc1101 Registern gesetzt und in die aktuelle EEPROM Speicherbank geschrieben werden. Es kann damit auch gleich die Konfigvariable ccN (Adr 3D) und ccmode (Adr 3E) gesetzt werden.
Ab der Firmware 4.1.0-dev200427 und 3.3.4-dev200914 wurde der CW Befehl (cc register write) erweitert, es kann nun auch eine max 8 Zeichen (Adr 0x40 bis 0x47) Bankkurzbeschreibung ins EEPROM geschrieben werden.
Bevor die cc1101 Registersequenz an den sduino gesendet wird, muß der EEPROM Speicherbereich mit e oder e<0-9> mit einem Factoryreset initialisiert werden. Wird eine nicht initialisierte Bank aktiviert, dann wird die Bank automatisch mit Standard-Settings[FactoryReset]) initialisiert.
Bei meiner Variante der 00_SIGNALduino.pm gibts seit 03.11.20 ein "set sduino rfmode", damit wird dann die ausgewählte Registersequenz mit dem CW Befehl gesendet.
Für die Firmware V3.3.5 und V4.2.2 gibts auch optimierte cc1101 Registerkonfigurationen "set sduino rfmodeTesting"
Hier ist eine Übersicht der rfmodes
https://ralf9.github.io/SD_rfmode.html
Die CW Befehle stehen in der ProtocolList und können auch mit "get sduino raw ..." oder im seriellen Monitor gesendet werden
https://github.com/Ralf9/RFFHEM/blob/dev/FHEM/lib/signalduino_protocols.pm
Mode 1 - IT+ 17.241 kbps und Mode 2 - IT+ 9.579 kbps (LaCrosse) sind aus der rf_native.c vom cul
Für ältere Versionen gibt es unten eine History.
Konfiguration von RaspII für async Mode von Kopp Free Control (GFSK)
ccreg 00: 0D 2E 2D 47 D3 91 3D 04 32 00 00 06 00 21 65 6A
ccreg 10: 97 83 16 63 B9 47 07 00 18 14 6C 07 00 91 87 6B
ccreg 20: F8 B6 11 EF 2A 16 1F 41 00 59 7F 3F 88 31 0B
reichen diese Register gegenüber default?
00 IOCFG2 0D Serial Data Output. Used for asynchronous serial mode.
01 IOCFG1 2E
02 IOCFG0 2D
0B FSCTRL1 06
0C FSCTRL0 00
10 MDMCFG4 97
11 MDMCFG3 83
12 MDMCFG2 16
13 MDMCFG1 63
14 MDMCFG0 B9
15 DEVIATN 47
History:
für ältere Versionen als V 4.1.0-dev200427 und 3.3.4-dev200914
Wichtig: Bevor die cc1101 Registersequenz an den sduino gesendet wird, muß der EEPROM Speicherbereich mit e oder e<0-9> mit einem Factoryreset initialisiert werden.
Mode 1 - IT+ 17.241 kbps (LaCrosse) - ccN=0, ccmode=3
get sduino raw CW0001,012E,0246,0302,042D,05D4,06FF,0700,0802,0D21,0E65,0F6A,1089,115C,1206,1322,14F8,1556,1700,1818,1916,1B43,1C68,1D91,2211,23E9,242A,2500,2611,3D00,3E03
Mode 2 - IT+ 9.579 kbps (LaCrosse) - ccN=2, ccmode=3
get sduino raw CW0001,012E,0246,0302,042D,05D4,06FF,0700,0802,0D21,0E65,0F6A,1088,1182,1206,1322,14F8,1556,1700,1818,1916,1B43,1C68,1D91,2211,23E9,242A,2500,2611,3D02,3E03
Mode 3 - PCA 301 - 868.9500MHz, 6.631kbps - ccN=3, ccmode=3
get sduino raw CW0001,012E,0246,0307,042D,05D4,06FF,0700,0802,0D21,0E6B,0FD0,1088,110B,1206,1322,14F8,1553,1700,1818,1916,1B43,1C68,1D91,2211,23E9,242A,2500,2611,3D03,3E03
Kopp Free Control Datarate: 4785,5 Baud (GFSK) - ccN=4, ccmode=2
get sduino raw CW0001,012E,0206,0304,04AA,0554,060F,07E0,0800,0D21,0E65,0F6A,1097,1183,1216,1363,1547,170C,1829,1936,1C40,1D91,23E9,242A,2500,3D04,3E02
ECOWITT/FineOffset WH51 - Datarate: 17.241 kbps - ccN=6, ccmode=3
CW0001,012E,0246,0303,042D,05D4,06FF,0700,0802,0D21,0E65,0FE8,1009,115C,1206,1322,14F8,1556,1700,1818,1916,1B43,1C68,1D91,2211,23E9,242A,2500,2611,3D06,3E03
Gruß Ralf
Ich habe gerade noch mal den minimalistischen Ansatz verfolgt: Zurück zu SIGNALDuino_nanocc1101_331rc7.hex, Register 12 auf GFSK bzw. 2-FSK geändert und bei ccconf: freq:868.275MHz bWidth:650KHz rAmpl:42dB sens:4dB (DataRate:5603.79Baud, Modulation:GFSK)
empfange ich jetzt MU-Nachrichten.
Der SDUINO hat das Register auf
0x12 MDMCFG2 - 0x30 -> 00110000 (ASK/OOK)
gesetzt.
Die für FSK relevanten Varianten sind
00000000 (2-FSK)
00010000 (GFSK)
Ich habe noch ein paar Fragen:
Welchen SDR Stick hast Du?, dabei geht es mir um die Genauigkeit der Frequenz
Bzgl. Der Datenrate: Im Datenblatt deines Senderchips steht 20khz
, bist Du Dir bei 2482 Baud ganz sicher?
Nachtrag:
Kannst du nicht den Originalsender zum Testen mit der culfw nehmen?
Zitat von: RaspII am 24 Dezember 2019, 10:47:53
Welchen SDR Stick hast Du?, dabei geht es mir um die Genauigkeit der Frequenz
E4000 USB DVB-T RTL-SDR Realtek RTL2832U R820T DVB-T Tuner Receiver
Zitat von: RaspII am 24 Dezember 2019, 10:47:53
Bzgl. Der Datenrate: Im Datenblatt deines Senderchips steht 20khz
, bist Du Dir bei ca. 2khz ganz sicher?
Die ca. 2.500 Baud habe ich aus den empfangenen Daten errechnet.
Zitat von: RaspII am 24 Dezember 2019, 10:47:53
Kannst du nicht den Originalsender zum Testen mit der culfw nehmen?
Ich teste immer mit dem Original-Sender der RIO FB. Ich muss meinen SDUINO dann gleich noch mal auf die culfw umschießen. Ist die V 1.67 die geeignete Version?
Den E4000 Stick habe ich auch, der hat gegenüber den Professionellen Sticks aber eine nicht unerhebliche Frequenzabweichung.
Falls Du den Offset noch nicht ermittelt hast, hier steht wie es geht (den Offset dann bei SDRSharp eingeben.
https://www.turais.de/ein-rtl_sdr-mit-kalibrate-sdr-kalibrieren (https://www.turais.de/ein-rtl_sdr-mit-kalibrate-sdr-kalibrieren)
Bzgl. NanoCUL Firmware gehe vor wie hier beschrieben und nehme auch die dort angehängte FW:
https://forum.fhem.de/index.php/topic,82379.msg1004482.html#msg1004482 (https://forum.fhem.de/index.php/topic,82379.msg1004482.html#msg1004482)
Die culfw ist leider nicht so flexibel wie der Signalduino, ich müsst Dir deshalb ggf. Spezialversionen machen. Heute und die Feiertage habe ich aber nur limitierte Zeit (später am Abend), evt. die nächste Stunde noch sporadisch
Ich habe meinen SDUINO wieder auf Deine culfw aus dem Posting geändert, krS3 abgesetzt:
2019.12.24 11:52:38 3: set nanoCUL raw krS3
2019.12.24 11:52:38 5: SW: krS3
2019.12.24 11:52:38 5: CUL/RAW: /krS-ReceiveStart
Danach habe ich die Frequenz auf 868.275 MHz und bWidth auf 101 kHz geändert => kein Empfang von irgendwelchen Signalen
Dann die Frequenz auf 868.140 MHz abgeändert => kein Empfang von irgendwelchen Signalen
>eine nicht unerhebliche Frequenzabweichung.
Deshalb will ich ja GFSK bzw. 2-FSK senden können. Mit URH und SDR kann ich dann schauen, ob das Spektrum der Original FB und des SDUINO auf denselben Frequenzen liegen. Mein letzter Stand vor einem Jahr hat 868.140 MHz als Trägerfrequenz ergeben.
Hallo,
Sorry, Du kannst die Frequenz nicht ändern, alle Parameter sind fest auf "Kopp" eingestellt.
Da die Firmware mit anderen Protokollen coexistiert, kann man noch die Befehle zum Ändern der Frequenz etc. absetzen, diese haben aber keine Auswirkung. Ich wollte das angehen, sofern ich eine Möglichkeit finde, dass die Kopp FW mit den anderen Protokollen gleichzeitig genutzt werden kann (das scheitert aktuell noch an den Empfangsparamentern)
D-h. ich muss ich Dir jeweils eine Spezialversionen bauen. Das macht aber nichts, damit sollten wir schnell weiterkommen, sofern wir die genaue Sendefrequenz kennen.
Ich lese mal das Datenblatt des TDK5110 genauer studieren und Dir dann eine Version bauen.
Schön wäre, wenn Du bis dahin die genaue Frequenz via RTL SDR ermitteln könntest (wie oben beschrieben den offset ermitteln, dann ist das Ding genau genug).
Wenn ich das Datenblatt richtig verstanden habe (ich habe nur mit dem Handy reingeschaut), geht es erst bei 834MHz los.
@RaspII:
Zwischendurch mal wieder ein kleiner Versuch mit SDUINO V 3.3.4-dev:
- Reg12: W1410 -> GFSK
- Reg15: W1740 -> Deviation = 25 kHz
- ccconf: freq:868.307MHz bWidth:58KHz rAmpl:42dB sens:4dB (DataRate:5603.79Baud, Modulation:GFSK)
Ich kann mit der bWidth 58 kHz MU-Signale empfangen. Bei einer Deviation von 25 kHz sieht das Sendesignal optisch schon ganz ansprechend aus (siehe Anlagen).
Ich muss jetzt erst mal schauen, ob ich unter den Rahmenbedingungen komplette Codesequenzen empfangen und dekodieren kann. Die bisherigen Signale sehen noch nicht so sauber aus.
Die eigene culfw lohnt sich meines Erachtens erst, wenn ich weiß wie das Zielsignal aussehen soll.
Hallo,
schaut mal bitte nach Deviation & Datenrate. Da gibt es unter Umständen Abhängigkeiten.
Schaut mal hier Bsp. https://www.silabs.com/community/wireless/proprietary/knowledge-base.entry.html/2015/02/17/calculation_of_theo-S9wI
Gesendet von iPhone mit Tapatalk Pro
@plin
Zeigt SDR# für dein FB und den Sduino die selbe Frequenz?
Wenn es Dir nur um FSK senden geht, dann schicke den String:
kt30F96E0110000J
Zu meiner Firmware
(Dann siehst Du auch gleich das Frequenz-Delta)
Zitat von: RaspII am 24 Dezember 2019, 13:14:53
@plin
Zeigt SDR# für dein FB und den Sduino die selbe Frequenz?
ja, die beiden Screenshots sind mit denselben Einstellungen geschossen worden. Die beiden Frequenzspitzen liegen in beiden Fällen bei ca. 868.249 MHz (low) und ca. 868.300 MHz (high).
Zitat von: HomeAuto_User am 24 Dezember 2019, 13:12:30
Hallo,
schaut mal bitte nach Deviation & Datenrate. Da gibt es unter Umständen Abhängigkeiten.
ja, das wurde mir bei der Nutzung des RF Studios auch sehr schnell bewusst. Deshalb glaubte ich einen ganzen Satz von Registeränderungen durchführen zu müssen, um ins Ziel zu kommen. Vor einem Jahr mit wenig Erfolg. Mit meinen wenigen Änderungen scheine ich aber auf einem guten Weg zu sein.
Ich habe Dir mal eine Version mit 868,275 Mhz gemacht.
alle anderen Parameter wie bisher
Nachtrag:
ggf. muss man die Taste am Sender mehrfach drücken (krs3 vorher abschicken), da ich immer 20Bytes empfange
Ich denke für heute muss das reichen
Datei gelöscht, siehe unten
Zitat von: RaspII am 24 Dezember 2019, 13:51:05
Ich habe Dir mal eine Version mit 868,275 Mhz gemacht.
Ich denke für heute muss das reichen
a) Danke
b) ja, die Familie hat mich wiederentdeckt ... ggf. geht's erst morgen früh weiter
Hi,
habe Dir noch eine zweite Version gemacht mit der gewünschten deviation von ca. 25kHz
Die Datei oben habe ich gelöscht, im Anhang die selbe Datei aber mit Parameter im Namen
Nachtrag:
- mit dieser Firmware kann man jeweils nur empfangen !
- Datenrate wenn nicht im Dateinamen genannt = 4785,5
- Modulation wenn nicht im Dateinamen genannt = GFSK
F r o h e W e i h n a c h t e n !
Zitat von: RaspII am 24 Dezember 2019, 18:00:44
F r o h e W e i h n a c h t e n !
ebenso und weitere einfallsreiche Idee'n uns allen.
Gesendet von iPhone mit Tapatalk Pro
@plin
Warum bist du eigentlich sicher das deine FB FSK verwendet und nicht ASK?
Hast Du mal rausgelesen wie der FSK Konfig Pin belegt ist?
Zitat von: RaspII am 25 Dezember 2019, 08:30:53
@plin
Warum bist du eigentlich sicher das deine FB FSK verwendet und nicht ASK?
Hast Du mal rausgelesen wie der FSK Konfig Pin belegt ist?
Das war dieser Beitrag im Ursprungs-Thread: https://forum.fhem.de/index.php/topic,85006.msg782985.html#msg782985 (https://forum.fhem.de/index.php/topic,85006.msg782985.html#msg782985) sowie die Antwort von habeIchVergessen:
Pin 5/10/13 sind GND
Pin 11 auf GND => 868MHz
Pin 15 auf GND => FSK
P.S. Frohe Weihnachten ... bin aktuell noch mit der Aktivierung/Konfiguration der Weihnachtsgeschenke beschäftigt ...
Whow, Du bist seit März 2018 an diesem Thema dran?
Dann wird es echt Zeit, dass Dir geholfen wird.
Aber mal ernst, woher kommt die Aussage von habeIchVergessen?
Hat er den selben Empfänger oder hattest Du die Pins vermessen?
Hattest Du auch schon ein Bild bzw. eine exakte Typenbeschreibung gepostet?
Dein Problem ist über zig Threads verteilt, es ist sehr mühsam sich da durchzuquälen.
Ich habe das hier gefunden:
https://enjoy-motors.de/files/_anleitungen/alt/specht_bal_swm_funksender_rio_hs1.pdf (https://enjoy-motors.de/files/_anleitungen/alt/specht_bal_swm_funksender_rio_hs1.pdf)
Ist Das Dein Sender?
Zitat von: RaspII am 25 Dezember 2019, 10:42:20
Hattest Du auch schon ein Bild bzw. eine exakte Typenbeschreibung gepostet?
Dein Problem ist über zig Threads verteilt, es ist sehr mühsam sich da durchzuquälen.
Ich habe das hier gefunden:
https://enjoy-motors.de/files/_anleitungen/alt/specht_bal_swm_funksender_rio_hs1.pdf (https://enjoy-motors.de/files/_anleitungen/alt/specht_bal_swm_funksender_rio_hs1.pdf)
Ist Das Dein Sender?
ja, fast. Ich habe 2 HS-8 (das ist die 8fach-Variante).
Also wenn das hier dein System ist:
Ordner:
https://enjoy-motors.de/index.php?gruppe=fachhaendler&seite1=bedienungsanleitungen_alt (https://enjoy-motors.de/index.php?gruppe=fachhaendler&seite1=bedienungsanleitungen_alt)
Dateien:
https://enjoy-motors.de/files/_anleitungen/alt/specht_bal_swm_funksender_rio_hs8fu8_kurzanleitung.pdf (https://enjoy-motors.de/files/_anleitungen/alt/specht_bal_swm_funksender_rio_hs8fu8_kurzanleitung.pdf)
https://enjoy-motors.de/files/_anleitungen/alt/specht_bal_swm_funksender_rio_hs8.pdf (https://enjoy-motors.de/files/_anleitungen/alt/specht_bal_swm_funksender_rio_hs8.pdf)
Dann könnte es Aufwändig werden. Die Fernbedienung benutzt einen "Rolling Code", d.h. man muss die Vorgeschichte kennen wenn man was senden möchte.
Irgendwie hört sich das an wie das Somfy Protokoll (nutzt auch einen Rolling Code), Somfy RTS sendet aber au 433 Mhz, es gibt auch 868Mhz Versionen, da kenn ich mich aber nicht aus
https://wiki.fhem.de/wiki/Somfy_via_SIGNALduino (https://wiki.fhem.de/wiki/Somfy_via_SIGNALduino)
Hallo,
ist es machbar deine Fernbedienung störungsfrei auseinander zu schrauben?
Wenn ja, bitte poste 2 Bilder der Vorderseite und Rückseite. So bekommen wir ggf noch bessere Erkenntnisse mit dazugehörigen Datenblättern der Bauteile.
Frohes Festessen
Gesendet von iPhone mit Tapatalk Pro
Zitat von: RaspII am 25 Dezember 2019, 10:58:37
Also wenn das hier dein System ist:
Ordner:
https://enjoy-motors.de/index.php?gruppe=fachhaendler&seite1=bedienungsanleitungen_alt (https://enjoy-motors.de/index.php?gruppe=fachhaendler&seite1=bedienungsanleitungen_alt)
Dateien:
https://enjoy-motors.de/files/_anleitungen/alt/specht_bal_swm_funksender_rio_hs8fu8_kurzanleitung.pdf (https://enjoy-motors.de/files/_anleitungen/alt/specht_bal_swm_funksender_rio_hs8fu8_kurzanleitung.pdf)
https://enjoy-motors.de/files/_anleitungen/alt/specht_bal_swm_funksender_rio_hs8.pdf (https://enjoy-motors.de/files/_anleitungen/alt/specht_bal_swm_funksender_rio_hs8.pdf)
Dann könnte es Aufwändig werden. Die Fernbedienung benutzt einen "Rolling Code", d.h. man muss die Vorgeschichte kennen wenn man was senden möchte.
Irgendwie hört sich das an wie das Somfy Protokoll (nutzt auch einen Rolling Code), Somfy RTS sendet aber au 433 Mhz, es gibt auch 868Mhz Versionen, da kenn ich mich aber nicht aus
https://wiki.fhem.de/wiki/Somfy_via_SIGNALduino (https://wiki.fhem.de/wiki/Somfy_via_SIGNALduino)
meine FB ist diese Variante: https://enjoy-motors.de/files/_anleitungen/alt/specht_bal_swm_funksender_rio_hs8.pdf (https://enjoy-motors.de/files/_anleitungen/alt/specht_bal_swm_funksender_rio_hs8.pdf).
Ich glaube nicht an Somfy o.ä.. Ja, es wird vor dem eigentlichen Steuercode ein Muster übertragen. Das lässt sich aber immer wieder verwenden. Also wenn, dann ist es maximal einer aus einem Set von Codes der hier vorgeschaltet wird. Ich hatte letztes Jahr einen Versuch mit einer Werteliste für diese Codes gestartet, um mir dann auf Grund meiner Analyseergebnisse eine Codesequenz zusammenzubauen. Ist damals negativ verlaufen. Mitgeschnittene komplette Sequenzen funktionieren aber. Wobei sich nicht alle Rolläden mit gleicher Qualität/Zuverlässigkeit ansteuern lassen. Deshalb will ich weg von OOK zu FSK, in der Hoffnung dann stabile Sequenzen zu kriegen oder optimalerweise sogar in der Kurzform als 8 Hexbytes zu übergeben.
Zitat von: HomeAuto_User am 25 Dezember 2019, 11:02:24
Hallo,
ist es machbar deine Fernbedienung störungsfrei auseinander zu schrauben?
Wenn ja, bitte poste 2 Bilder der Vorderseite und Rückseite. So bekommen wir ggf noch bessere Erkenntnisse mit dazugehörigen Datenblättern der Bauteile.
Frohes Festessen
Gesendet von iPhone mit Tapatalk Pro
>ist es machbar deine Fernbedienung störungsfrei auseinander zu schrauben?
eine Schraube ... und das war's
>Frohes Festessen
danke gleichfalls
Hi nochmal,
ich habe Google bemüht und bin dabei auf folgenden Thead gestoßen:
https://github.com/RFD-FHEM/RFFHEM/issues/210 (https://github.com/RFD-FHEM/RFFHEM/issues/210)
Wenn ich das richtig verstehe warst Du schon mal weiter und konntest Botschaften bei 868,000 Mhz empfangen, korrekt?
Vorschlag zur weiteren Vorgehensweise:
- Du programmierst eine meiner NanoCUL Versionen und sendest mal den String wie in:
https://forum.fhem.de/index.php/topic,106594.msg1005131.html#msg1005131 (https://forum.fhem.de/index.php/topic,106594.msg1005131.html#msg1005131)
erwähnt und zeichnest das mit SDR# auf. - Dann bestimmen wir das Delta zu Deiner Fernbedienungsfrequenz, am besten Du postest mal beide SDR# Spektren.
Sobald wir die Frequenz zu 100% kennen (als Delta zum nanoCUL) baue ich dir eine Version mit der korrekten Frequenz und wir machen uns an die Baudrate.
Je nach dem ob die MU Botschaften in Deinem ursprünglichen Thread korrekt sind, ist die Baudrate irgendwo bei 2500 Baud (die nächste Normbaudrate wäre dann 2400Baud)
Nachtrag:
Das Du keine zuverlässige Übertragung hattest kann nicht nur am Protokoll liegen, sondern auch am Rolling Code (der von Botschaft zu Botschaft geändert werden muss
ZitatDurch den 64 Bit Rolling Sicherheitscode im HS-8 RIO ist ein optimaler Schutz vor unberechtigtem Bedienen der angeschlossenen Geräte durch Unbefugte gewährleistet.
Hi RaspII,
hier noch mal das komplette aktuelle Bild
Zitat von: RaspII am 25 Dezember 2019, 13:01:37
Hi nochmal,
ich habe Google bemüht und bin dabei auf folgenden Thead gestoßen:
https://github.com/RFD-FHEM/RFFHEM/issues/210 (https://github.com/RFD-FHEM/RFFHEM/issues/210)
Wenn ich das richtig verstehe warst Du schon mal weiter und konntest Botschaften bei 868,000 Mhz empfangen, korrekt?
ja, ich kann mit folgenden Parametern
ccconf: freq:868.000MHz bWidth:650KHz rAmpl:42dB sens:4dB (DataRate:5603.79Baud)
im ASK/OOK Mode senden. Eine der Oberwellen trifft genau die obere oder untere Frequenz des FSK-FM-Signals. Da der Empfänger es nicht so genau zu nehmen scheint, kann ich also OOK senden und er (halbes) FSK empfangen. So bediene ich aktuell meine Rolläden und muss von Hand (per Fernbedienung) nachsteuern. Wie damals schon geschrieben, reagieren die Rolladen 1, 4 und 5 relativ sicher auf das Signal, 3 und 6 öfters mal, 2 habe ich noch nicht überzeugen können. Meine Hoffnung ist durch den Wechsel von OOK auf FSK saubere Codes mitschneiden und senden zu können, damit sich die Rolläden sauber/stabil ansteuern lassen.
Zitat von: RaspII am 25 Dezember 2019, 13:01:37
Vorschlag zur weiteren Vorgehensweise:
- Du programmierst eine meiner NanoCUL Versionen und sendest mal den String wie in:
https://forum.fhem.de/index.php/topic,106594.msg1005131.html#msg1005131 (https://forum.fhem.de/index.php/topic,106594.msg1005131.html#msg1005131)
erwähnt und zeichnest das mit SDR# auf. - Dann bestimmen wir das Delta zu Deiner Fernbedienungsfrequenz, am besten Du postest mal beide SDR# Spektren.
Sobald wir die Frequenz zu 100% kennen (als Delta zum nanoCUL) baue ich dir eine Version mit der korrekten Frequenz und wir machen uns an die Baudrate.
Je nach dem ob die MU Botschaften in Deinem ursprünglichen Thread korrekt sind, ist die Baudrate irgendwo bei 2500 Baud (die nächste Normbaudrate wäre dann 2400Baud)
Die Frequenzen habe aus Sicht des SDUINO meines Erachtens nach bereits ermittelt. Im Screenshot waren die aber nicht dargestellt. Ich habe die beiden URH-Screenshot noch mal beigefügt. Bei identischer Auflösung sind die beiden Signale meiner Meinung nach brauchbar identisch. Die im SDUINO eingestellte Trägerfrequenz ist 868.307 MHz, die per Register 15 eingestellte Deviation 25 khZ. Durch den direkten Vergleich der Signale der RIO FB und des SDUINO-Signals schneke ich mir die Korrektur der in URH evtl. falsch dargestellten Frequenzen. Bei der Frequenz kann ich bei einer Bandbreite von 58 kHz Daten empfangen. Also müssen die 868.307 MHz relativ gut passen.
Ich würde jetzt schauen, ob ich relativ stabile, brauchbare Code-Sequenzen empfangen/mitschneiden kann. Die Sync-Nibbles am Anfang des Signals geben schon Aufschluss darüber, ob die Qualität passt:
Der hier
P0=-32001;P1=15864;P2=-407;P3=412;P4=4008;P5=802;P6=-799;D=0123232323232323232323232425632563636363256363632563252563632525636325252525636325636325636363636363636363256363632563252563256363256363636363636363256325;wird runtergebrochen in
01232323232323232323232324Im Sync-Vorspann selektiere ich die mit sauberem Pattern
2323232323232323232323.
Danach kommen
25632563636363256363632563252563
63252563632525252563632563632563
63636363636363632563636325632525
63256363256363636363636363256325Daraus ergibt sich dann in Hex
5EE9 986D FF74 B7FADie Sequenz
5EE9 986Dist ein Random Code der sich von Tastendruck zu Tastendruck unterscheidet.
FF74 B7FAIst der eigentliche Steuercode.
Ciao, plin
Hallo,
ich habe versucht Deine Dekodierung nachzuvollziehen und bin gescheitert.
Hast Du eine Möglichkeit mit einem Oszi direkt am Sender zu messen?
3 Pins sind interessant: FSKDTA, ASKDTA und PDWN.
Einer dieser PINs müsste statisch sein, die andere müssten toggeln.
Je nachdem wie die Pins agieren wird ein bestimmtes Protokoll eingestellt, siehe Datenblatt Kapitel 3.4.6
@plin:
was mir noch aufgefallen ist:
Meine Firmware empfängt noch mit GFSK, ich bau Dir noch ne 2-FSK = FSK Variante
Nachtrag:
Hab Dir zwei neue Varianten gebaut und oben angehängt, siehe:
https://forum.fhem.de/index.php/topic,106594.msg1005156.html#msg1005156 (https://forum.fhem.de/index.php/topic,106594.msg1005156.html#msg1005156)
Kurzer Zwischenstand: Ich habe heute Morgen einige Frequenzen durchgespielt und geschaut, ob der SDUINO Codesequenzen ins Log schreibt:
ccconf: freq:868.287MHz bWidth:58KHz rAmpl:42dB sens:4dB (DataRate:5603.79Baud, Modulation:GFSK) => no
ccconf: freq:868.290MHz bWidth:58KHz rAmpl:42dB sens:4dB (DataRate:5603.79Baud, Modulation:GFSK) => no
ccconf: freq:868.291MHz bWidth:58KHz rAmpl:42dB sens:4dB (DataRate:5603.79Baud, Modulation:GFSK) => teils/teils
ccconf: freq:868.292MHz bWidth:58KHz rAmpl:42dB sens:4dB (DataRate:5603.79Baud, Modulation:GFSK) => ok
ccconf: freq:868.297MHz bWidth:58KHz rAmpl:42dB sens:4dB (DataRate:5603.79Baud, Modulation:GFSK) => ok
ccconf: freq:868.302MHz bWidth:58KHz rAmpl:42dB sens:4dB (DataRate:5603.79Baud, Modulation:GFSK) => ok
ccconf: freq:868.307MHz bWidth:58KHz rAmpl:42dB sens:4dB (DataRate:5603.79Baud, Modulation:GFSK) => ok
ccconf: freq:868.312MHz bWidth:58KHz rAmpl:42dB sens:4dB (DataRate:5603.79Baud, Modulation:GFSK) => ok
ccconf: freq:868.314MHz bWidth:58KHz rAmpl:42dB sens:4dB (DataRate:5603.79Baud, Modulation:GFSK) => teils/teils
ccconf: freq:868.315MHz bWidth:58KHz rAmpl:42dB sens:4dB (DataRate:5603.79Baud, Modulation:GFSK) => no
ccconf: freq:868.317MHz bWidth:58KHz rAmpl:42dB sens:4dB (DataRate:5603.79Baud, Modulation:GFSK) => no
Wenn ich mal davon ausgehe, dass die Trägerfrequenz in der Mitte zwischen der oberen und unteren Frequenz bei der der Empafng nachlässt liegt, komme ich auf 868.302 MHz.
Die bei 868.302 MHz empfangenen Codesequenzen sind aber noch nicht so stabil wie ich mir das erhofft hatte:
D=012343434343434343434343435643764646437643737376464373764...
D=010101023101010231023231023101023101010101010101023102324...
D=012123030123030301212123030123012121212303030123030121212...
D=012121212121212121212121314525214145252525214141452141452...
@RaspII: jetzt wechsle ich auf Deine Firmware
Zitat von: RaspII am 24 Dezember 2019, 16:17:22
Hi,
habe Dir noch eine zweite Version gemacht mit der gewünschten deviation von ca. 25kHz
Die Datei oben habe ich gelöscht, im Anhang die selbe Datei aber mit Parameter im Namen
Nachtrag:
- mit dieser Firmware kann man jeweils nur empfangen !
- Datenrate wenn nicht im Dateinamen genannt = 4785,5
- Modulation wenn nicht im Dateinamen genannt = GFSK
Ich habe die nanoCUL_f868.275dev25.39_2FSK_drate2498.hex und nanoCUL_f868.275dev25.39_2FSK.hex auf den SDUINO geflasht und jeweils krS3 abgesetzt, sehe im Log auch
SW: krS3
CUL/RAW: /krS-ReceiveStart
CUL_Parse: nanoCUL krS-ReceiveStart
nanoCUL: dispatch krS-ReceiveStart
nanoCUL: Unknown code krS-ReceiveStart, help me!Empfangsseitig ist aber tote Hose, im Log rührt sich nichts.
Hallo, sorry das ich nun Zwischenfrage. Ich werde das Gefühl nicht los, Ihr wisst nicht 100% auf welcher Modulation das von Euch gewollte stattfindet. Ich lese immer nur, step zu der Variante und zu dieser...
Ist es nicht einfacher, einen Sender zu nehmen wo man weiß, er sendet mit dieser Modulation und macht sich erstmal an die Decodierung?
Irgendwie fehlt mir hier der feste Bezugspunkt manchmal ;)
Gesendet von iPhone mit Tapatalk Pro
@plin
kannst du mit einem Terminal an den nanoCUL gehen?
Ich bin mir nicht sicher ob FHEM die Antworten weiterreicht
Zitat von: HomeAuto_User am 26 Dezember 2019, 11:08:50
Hallo, sorry das ich nun Zwischenfrage. Ich werde das Gefühl nicht los, Ihr wisst nicht 100% auf welcher Modulation das von Euch gewollte stattfindet. Ich lese immer nur, step zu der Variante und zu dieser...
Ist es nicht einfacher, einen Sender zu nehmen wo man weiß, er sendet mit dieser Modulation und macht sich erstmal an die Decodierung?
Irgendwie fehlt mir hier der feste Bezugspunkt manchmal ;)
Im Prinzip ja, nur liegen 2FSK und GFSK meiner Meinung nach nicht weit auseinander. Ich habe nur zwei Sender und kann vermutlich keinen mehr nachkaufen, deshalb bin ich mit Aktivitäten an sehr kleinen Pins bei denen man leicht einen Kurzschluss verurschachen sehr SEHR vorsichtig :-).
Mein Oszi ist ca. 40 Jahre alt. Vor einem Jahr bin ich schon mal an die Pins des Empfängers dran gegangen. Die Synchronisation/Auflösung war aber schwierig ...
Ich habe zum Vergleich mal drei Spektren mitgeschnitten (siehe Anlage). Die Original-FB sendet ein Signal ohne Oberwellen, während der CC101 bei GFSK ein seichtes Tal bei der Trägerfrequenz hat, mit 2FSK sind die Spitzen ausgeprägter. Die Oberwellen sind auch schärfer ausgeprägt als bei GFSK.
Zitat von: RaspII am 26 Dezember 2019, 11:39:31
@plin
kannst du mit einem Terminal an den nanoCUL gehen?
Ich bin mir nicht sicher ob FHEM die Antworten weiterreicht
Ja, gerne, aber eine Frage geht mir schon seit gestern durch den Kopf: Ist Dein Sketch wirklich auf 868.275 MHz eingestellt? Wenn ich mit dem SDUINO FSK funke muss ich den auf 868.302 oder 868.307 MHz einstellen. Bei 868.275 MHz ist der Empfang auch mit dem SDUINO = 0.
Verschoben von: "Antwort #3 am: 24 Dezember 2019, 10:20:56"
ZitatWenn mir es gelingt, daß ich mit dem sduino ein xFSK signal empfange, dann kann ich das Empfangen und Senden mit dem FIFO des cc1101 einbauen, dann wird einiges einfacher.
Es wird für das Signalduino Modul demnächst ein neuer set Befehl geben, damit kann dann eine folge von ccRegistern gesendet werden.
z.B. set sduino cc1101_reg 1183 1214 1363 14B9 1500 1BF8 1DCF
Mit dem Senden mit dem nanocul und der culw firmware und dem kopp Protokoll komme ich nicht weiter.
Mein Problem ist, daß ich nicht weiss ob das Problem beim Sender (nanocul) oder beim Empfänger (minicul) ist.
Wenn ich eine ITv1 Nachricht vom nanocul (mode slowrf) zum minicul sende, dann funktioniert es. Ich habe eine freq von 868.3 und eine Bandbreite von 162 verwendet.
Ich überlege mir gerade ob ich vielleicht mit der a-culw weiterkomme, da gibt es auch eine firmware für den minicul.
Ich würde gerne auch mal versuchen mit dem minicul ein xFSK zu senden.
Evtl komme ich mit dem mode 1 und 2 (IT+) weiter, nur wie kann ich da was senden?
Falls jemand eine xFSK Fernbedienung hat die er nicht mehr benötigt, würde ich sie abkaufen
Ich verwende 433MHz Module für den 868MHz GFSK Empfang.
Kann dies der Grund sein, warum ich mit GFSK nichts empfange. Lässt sich ungefähr abschätzen wie gross die Dämpfung durch die Fehlanpassung am Antenneneingang ist?
bei 0x12:MDMCFG2– Modem Configuration
steht bei SYNC_MODE[2:0]
Seting 4 (100): No preamble/sync, carrier-sense above threshold
Was ist "carrier-sense above threshold"? Lässt sich der threshold einstellen?
Ich habe eine HomeMatic Steckdose HM-LC-Sw1-Pl-DN-R1,
weiss jemand wie ich den cc1101 konfigurieren muss, damit ich Homematic empfangen kann?
Ist eine Entfernung von ca 2m ok, oder ist dies wegen dem 433MHz Modul schon zu weit?
Gruß Ralf
Zitat von: Ralf9 am 26 Dezember 2019, 13:10:42
Ich verwende 433MHz Module für den 868MHz GFSK Empfang.
Kann dies der Grund sein, warum ich mit GFSK nichts empfange. Lässt sich ungefähr abschätzen wie gross die Dämpfung durch die Fehlanpassung am Antenneneingang ist?
bei 0x12:MDMCFG2– Modem Configuration
steht bei SYNC_MODE[2:0]
Seting 4 (100): No preamble/sync, carrier-sense above threshold
Was ist "carrier-sense above threshold"? Lässt sich der threshold einstellen?
Ich habe eine HomeMatic Steckdose HM-LC-Sw1-Pl-DN-R1,
weiss jemand wie ich den cc1101 konfigurieren muss, damit ich Homematic empfangen kann?
Ist eine Entfernung von ca 2m ok, oder ist dies wegen dem 433MHz Modul schon zu weit?
Gruß Ralf
@Ralf9, vielleicht findest du hier einen Ansatz https://github.com/jp112sdl/Beispiel_AskSinPP
Gesendet von iPhone mit Tapatalk Pro
Hi Ralf,
ich habe bei mir zu Hause Homematic-Geräte im Einsatz und nutze einen Original-CUL. Meine SDUINOs haben auch die jeweils passenden CC1101er im Einsatz, deshalb fehlen mir die Erfahrungswerte, um auf Deine Frage die passenden Antworten zu haben.
Hast Du einen SDR-Stick? Dann könntest Du zumindest OOK auf 868 MHz senden und schauen wie sich 433 vs 868 MHz und die Entfernung SDUINO/SDR-Stick auswirkten.
VG plin
Zitat@Ralf9, vielleicht findest du hier einen Ansatz https://github.com/jp112sdl/Beispiel_AskSinPP
@HomeAuto_User, Danke dort habe ich die Konfiguration für Homematic gefunden.
ZitatHast Du einen SDR-Stick? Dann könntest Du zumindest OOK auf 868 MHz senden und schauen wie sich 433 vs 868 MHz und die Entfernung SDUINO/SDR-Stick auswirkten.
Nein, ich habe keinen SDR-Stick
OOK auf 868 MHz funktioniert zwischen minicul und nanocul bei 1m Abstand problemlos, habe aber nicht auf die RSSI geachtet.
Gruß Ralf
@HomeAuto_User:
ZitatHallo, sorry das ich nun Zwischenfrage. Ich werde das Gefühl nicht los, Ihr wisst nicht 100% auf welcher Modulation das von Euch gewollte stattfindet. Ich lese immer nur, step zu der Variante und zu dieser...
Ja, da hast Du schon recht. Unser Problem ist, dass wir alle eine andere HW- und Firmware Basis nutzen.
Ausserdem haben wir in 3 Threads "Paralleldiskussionen", ich bin mir nicht mehr ganz sicher wo welche Diskussion läuft.
Mein Ansatz war, dass wir über meine Kopp Firmware gehen könnten, da ich hier schon beliebige Botschaften mit GFSK empfangen kann.
Die Kopp Firmware läuft stabil und ich kenne mich damit aus :).
Allerdings arbeite ich immer direkt mit einem Terminalprogramm (Tera Term, Windows10), dann kann ich mir sicher sein, dass ich alle Antworten des Sticks auch sehe ohne das FHEM etwas rausfiltert.
@Ralf9:
bzgl. den 433Mhz Modulen, mit diesen hier:
https://forum.fhem.de/index.php/topic,82379.msg1005476.html#msg1005476 (https://forum.fhem.de/index.php/topic,82379.msg1005476.html#msg1005476)
habe ich extrem schlechte Erfahrung gemacht, da die Frequenz völlig daneben lag.
Mir persönlich wäre am liebsten wir könnten weitermachen wie hier beschrieben:
https://forum.fhem.de/index.php/topic,82379.msg1005476.html#msg1005476 (https://forum.fhem.de/index.php/topic,82379.msg1005476.html#msg1005476)
Wenn wir die Module mit Kopp zum Laufen bekommen, können wir im nächsten Schritt den Signalduiono mit GFSK zum laufen bekommen und danach
auf 2-FSK umstellen (falls nötig). die Kopp FW sendet via Fifo definierte Botschaften, die wir dann auf der Gegenseite analysieren können.
Als ersten Schritt müssen wir aber dafür sorgen, dass sich die Sender- und Empfänger Hardware verstehen um auszuschliessen, dass irgend etwas an der HW nicht funktioniert
Ich hätte heute Abend etwas Zeit
Leichte Euphorie: ich habe sowohl den Rolladen 1 (bisher relativ zuverlässig) als auch den Rolladen 2 (ging bisher so gut wie nie) mittels FSK zu einer Abwärtsbewegung überreden können, und das mit der ersten halbwegs passenden frisch mitgeschnittenen Sequenz.
Wo soll ich anfangen?
Ich bin bei der durch den Vergleich RIO-FB vs. SDUINO ermittelten Frequenz von 868.302 MHz sowie dem Hub von 58 kHz geblieben.
ccconf: freq:868.302MHz bWidth:58KHz rAmpl:42dB sens:8dB (DataRate:24795.53Baud, Modulation:GFSK)
Dann kamen die diversen Überlegungen zur Baudrate. Mein URH geht ja mit 1 MHz ans Sampling ran. Die Taktung der von mir gemessenen Code-Sequenzen liegt im Mittel bei 402 ms. Wenn ich die einzelnen Passagen der Codesequenz anhand von 400 ms tics bewerte und aufaddiere, komme ich auf 168 Einheiten. Dafür gehen in Summe 67.664 ms drauf. Eine Einheit dauert folglich 402,8 ms. Das entspricht dann den 2.482,9 Baud.
Dann kam mal wieder die Grundsatzfrage, ob ich den Sender auf diese Baudrate einstellen muss. Beim Empfang ermittelt der SDUINO ja die absoluten Zeitscheiben, unabhändig von der Baudrate. Wenn nun beim Empfang das Oversampling funktioniert, wieso dann nicht auch beim Senden? So habe ich mich für das 10fach Oversampling entschieden und überlasse das Status-Management 0/1 dem SDUINO. Die Mitschnitte im URH sehen vergleichbar aus. Der mittlere ist übrigens 2-FSK, der uneter GFSK. Peak weisen beiden auf. Da hätte ich bei GFSK etwas glattere Übergänge erwartet.
Und das scheint zu funktionieren. Die von der RIO-FB gesendeten Sequenzen wiederholen sich, leicht erkennbar an der Anfangssequenz 0121212121212121212121213.
mySIGNALduino: Read, msg READredu: MU;P0=-15610;P1=403;P2=-408;P3=-4014;P4=-810;P5=803;D=0121212121212121212121213141414525252141452145214521452521414141414145214141414521452145214525252525252521452525214521414521452521452525252525252525214141<ende>0121212121212121212121213141414525252141452145214521452521414141414145214141414521452145214525252525;CP=1;R=63;O;
Bei meinen OOK-Versuchen musste ich die mitgeschnittenen Sequenzen durchtesten, um brauchbare zu finden. Heute habe ich zwei optisch brauchbar aussehende genommen und damit direkt Erfolg gehabt.
ccregAll:
ccreg 00: 0D 2E 2D 47 D3 91 3D 04 32 00 00 06 00 21 65 6F
ccreg 10: F9 F4 18 23 B9 40 07 00 18 14 6C 07 00 91 87 6B
ccreg 20: F8 56 11 EF 2D 12 1F 41 00 59 7F 3F 88 31 0B
Configuration Register Detail (address, name, value):
0x00 IOCFG2 - 0x0D
0x01 IOCFG1 - 0x2E
0x02 IOCFG0 - 0x2D
0x03 FIFOTHR - 0x47
0x04 SYNC1 - 0xD3
0x05 SYNC0 - 0x91
0x06 PKTLEN - 0x3D
0x07 PKTCTRL1 - 0x04
0x08 PKTCTRL0 - 0x32
0x09 ADDR - 0x00
0x0A CHANNR - 0x00
0x0B FSCTRL1 - 0x06
0x0C FSCTRL0 - 0x00
0x0D FREQ2 - 0x21
0x0E FREQ1 - 0x65
0x0F FREQ0 - 0x6F
0x10 MDMCFG4 - 0xF9
0x11 MDMCFG3 - 0xF4
0x12 MDMCFG2 - 0x18
0x13 MDMCFG1 - 0x23
0x14 MDMCFG0 - 0xB9
0x15 DEVIATN - 0x40
0x16 MCSM2 - 0x07
0x17 MCSM1 - 0x00
0x18 MCSM0 - 0x18
0x19 FOCCFG - 0x14
0x1A BSCFG - 0x6C
0x1B AGCCTRL2 - 0x07
0x1C AGCCTRL1 - 0x00
0x1D AGCCTRL0 - 0x91
0x1E WOREVT1 - 0x87
0x1F WOREVT0 - 0x6B
0x20 WORCTRL - 0xF8
0x21 FREND1 - 0x56
0x22 FREND0 - 0x11
0x23 FSCAL3 - 0xEF
0x24 FSCAL2 - 0x2D
0x25 FSCAL1 - 0x12
0x26 FSCAL0 - 0x1F
0x27 RCCTRL1 - 0x41
0x28 RCCTRL0 - 0x00
0x29 FSTEST - 0x59
0x2A PTEST - 0x7F
0x2B AGCTEST - 0x3F
0x2C TEST2 - 0x88
0x2D TEST1 - 0x31
0x2E TEST0 - 0x0B
Jetzt muss meine Frau nur noch eine Freunding besuchen, damit ich alle Rolläden durchspielen und die Codes mitschneiden kann (das ständige rauf/runterfahren hat sie letztes Jahr ziemlich genervt ;D).
P.S. 6 Rolläden, je up/stop/down bedeutet in Summe 18 Codesequenzen. Wenn das funktioniert sollte der Ansatz ausbaufähig sein.
Gratulation !
Zitat von: RaspII am 28 Dezember 2019, 20:46:25
Gratulation !
Warten wir mal den morgigen Tag ab ... aber es gibt einem Hoffnung
Ein paar Nachträge:
- getestet wurde mit der SDUINO Version 3.4.0-dev
- Die Struktur des zugrunde liegenden Original-Signals ist der Anlage zu entnehmen
Ich war mir nicht sicher, ob die Datenrate von 24.795 Baud im Konflikt zum Nyquist-Shannon-Abtasttheorem stehen würde, da die eigentliche Datenrate aber 2.482 Baud beträgt scheint das trotzdem mit den 25 kHz Hub einherzugehen.
Alle relevanten Codes (6 Rolläden, jeweils down/stop/up) sind mitgeschnitten und in FHEM eingetragen (Modul ROLLO). Ergebnis: 66% Erfolgsquote. Up/Down funktioniert bei allen Rolläden, also eine deutliche qualitätive Verbesserung gegenüber dem OOK-Protokoll. Aber die Stop-Commands wollen irgendwie nicht. Zwischendurch musste ich öfters mal den SDUINO reseten, da er nicht mehr funken wollte.
Es geht also weiter.
Die Stop-Funktion im Modul ROLLO scheint Probleme zu bereiten. Wenn ich den Stop-Sommand in der Eingabezeile absetze klappt's ...
Ich habe jetzt meine produktive FHEM-Instanz im Erdgeschoss umgestellt und alle 6 Rolläden bewegen sich auf FSK-Kommando runter bzw. hoch ;D.
Mal schauen wie zuverlässig sich das in den nächsten Tagen wiederholen lässt.
So, Wiki ist nachgezogen https://wiki.fhem.de/wiki/Unbekannte_Funkprotokolle#SIGNALduino_-_FSK (https://wiki.fhem.de/wiki/Unbekannte_Funkprotokolle#SIGNALduino_-_FSK)
Korrekturlesen steht noch aus. Wer mag kann gerne mithelfen und im Abschnitt noch nicht beantwortete Fragen stellen.
@Ralf: Im SIGNALduino-Modul bräuchten wir folgende Möglichkeiten:
- Einstellung der Übertragungsart OOK/2-FSK/GFSK (Register 12, MDMCFG2 )
- Einstellung Frequenzhub (Register 15, DEVIATN)
- Einstellung Baudrate (Register 10 und 11, MDMCFG4/MDMCFG3)
Ciao, Peter
P.S. Der Abschnitt im Artikel liest sich als wenn's ganz einfach wäre ...
P.P.S. Und sie bewegen sich immer noch :).
Stand 2.1.20: Und sie bewegen sich immer noch :).
Hi nochmal,
Ein paar Dinge sind mir persönlich noch nicht klar:
- Deine FB (Rio) scheint ein Pulweiten kodiertes Signal zu nutzen, kurz Low & lang High = 0, lang Low & kurz High = 1, habe ich das richtig verstanden?
- Das ist aber nicht der Standard bei FSK, es gibt auch Protokolle die direkt eine 0 bzw. eine 1 senden (gleiche Pulslängen), wie z.B. das von Kopp verwendete Protokoll
- Die Rio Fernbedienung sendet ja einen Rolling Code, hattest Du den gesendeten Block schon komplett verstanden?
Zitat von: RaspII am 30 Dezember 2019, 13:49:28
Das ist aber nicht der Standard bei FSK, es gibt auch Protokolle die direkt eine 0 bzw. eine 1 senden (gleiche Pulslängen), wie z.B. das von Kopp verwendete Protokoll
Wie muss ich mir da den Freqenzverlauf vorstellen?
Der Frequenzverlauf (die beiden gesendeten Frequenzen) sind identisch, nur das Protokoll für die übertragenen Bits ist anders.
Es folgen ganz einfach die Bits (ohne Pulsweitencodierung), siehe Anhang.
Die Präambel ist identisch zu Deiner, danach geht's mit der einfachen Bitfolge (identischer Takt) weiter
Es muss also mit einem festen, bekannten Takt (Baudrate) abgetastet werden, ähnlich wie bei RS232?
Zitat von: RaspII am 30 Dezember 2019, 13:49:28
Hi nochmal,
Ein paar Dinge sind mir persönlich noch nicht klar:
- Deine FB (Rio) scheint ein Pulsweiten kodiertes Signal zu nutzen, kurz Low & lang High = 0, lang Low & kurz High = 1, habe ich das richtig verstanden?
Ja, das ist das Ergebnis meiner Analyse.
Zitat von: RaspII am 30 Dezember 2019, 13:49:28
- Das ist aber nicht der Standard bei FSK, es gibt auch Protokolle die direkt eine 0 bzw. eine 1 senden (gleiche Pulslängen), wie z.B. das von Kopp verwendete Protokoll
Mein Weltbild sieht so aus: der CC1101 macht aus einer Pegelvorgabe 0/1 (die kommt vom Arduino) eine Frequenz. Alles andere was der CC1101 an Signalaufbereitung von Hause aus könnte haben wir ausgeschaltet. Er fungiert also nur als Modem bzw. Sender.
Bei OOK ist das
- 0 = kein Signal
- 1 = Signal auf der vorgegebenen Frequenz
Bei FSK ist das
- 0 = vorgegebene Frequenz minus Hub (lt. DEVIATN)
- 1 = vorgegebene Frequenz plus Hub (lt. DEVIATN)
Ich weiß nicht wer die RIO-Fernbedienung entwickelt hat und ob er sich der Standards bewusst war. Er hat mit den Möglichkeiten der Chips TDK5110 und TDA5210 gespielt.
Zitat von: RaspII am 30 Dezember 2019, 13:49:28
- Die Rio Fernbedienung sendet ja einen Rolling Code, hattest Du den gesendeten Block schon komplett verstanden?
Ja, da gibt es einen Präfix. Der Begriff "Rolling Code" suggeriert aber, dass der sich nach jedem Tastendruck ändert und wenn du die Regeln des Codes nicht beachtest funkioniert er nicht. Daran glaube ich bei dem RIO-Code nicht. Der wird jedes Mal neu generiert oder setzt sich aus einem bekannten Set von Codes zusammen. Wichtig ist nur: Bei jedem Tastendruck wird eine neuer Code verwendet. Die mitgeschnittenen Sequenz sind bei mir immer iweder verwendbar.
Zitat von: elektron-bbs am 30 Dezember 2019, 17:44:50
Es muss also mit einem festen, bekannten Takt (Baudrate) abgetastet werden, ähnlich wie bei RS232?
feste Taktrate: ja
bekannte Taktrate: nicht unbedingt. Mindestens die tatsächliche Taktrate, vorzugsweise Oversampling
ähnlich wie bei RS232?: bei RS232 wird eine feste bekannte Taktrate verwendet die beide Partner verwenden
Oversampling steigert die Qualität der emittelten Parameter Px.
@Ralf,
du hast für den
ZitatMode 1 - IT+ 17.241 kbps
folgendes Register angegeben.
set sduino cc1101_reg 0001 012E 0246 0302 042D 05D4 06FF 0700 0802 0D21 0E65 0F6A 1089 115C 1206 1322 14F8 1556 1700 1818 1916 1B43 1C68 1D91 2210 23E9 242A 2500 2611ccconf: freq:868.300MHz bWidth:203KHz rAmpl:42dB sens:4dB (DataRate:17257.69Baud, Modulation:2-FSK)Hast du mit diesen Einstellungen schon mal etwas empfangen? Wenn ja, wie sehen die Daten aus?
Ich habe diese Testweise eingestellt und nichts erhalte ich diesbezüglich.
Wenn ich das Register
Configuration Register Detail (address, name, value):
0x00 IOCFG2 - 0x0D
0x01 IOCFG1 - 0x2E
0x02 IOCFG0 - 0x2D
0x03 FIFOTHR - 0x47
0x04 SYNC1 - 0x00
0x05 SYNC0 - 0x00
0x06 PKTLEN - 0x3D
0x07 PKTCTRL1 - 0x04
0x08 PKTCTRL0 - 0x32
0x09 ADDR - 0x00
0x0A CHANNR - 0x00
0x0B FSCTRL1 - 0x06
0x0C FSCTRL0 - 0x00
0x0D FREQ2 - 0x21
0x0E FREQ1 - 0x65
0x0F FREQ0 - 0x6A
0x10 MDMCFG4 - 0x89
0x11 MDMCFG3 - 0x5C
0x12 MDMCFG2 - 0x06
0x13 MDMCFG1 - 0x23
0x14 MDMCFG0 - 0xB9
0x15 DEVIATN - 0x56
0x16 MCSM2 - 0x07
0x17 MCSM1 - 0x00
0x18 MCSM0 - 0x18
0x19 FOCCFG - 0x14
0x1A BSCFG - 0x6C
0x1B AGCCTRL2 - 0x07
0x1C AGCCTRL1 - 0x00
0x1D AGCCTRL0 - 0x90
0x1E WOREVT1 - 0x87
0x1F WOREVT0 - 0x6B
0x20 WORCTRL - 0xF8
0x21 FREND1 - 0xB6
0x22 FREND0 - 0x10
0x23 FSCAL3 - 0xEC
0x24 FSCAL2 - 0x2A
0x25 FSCAL1 - 0x14
0x26 FSCAL0 - 0x11
0x27 RCCTRL1 - 0x41
0x28 RCCTRL0 - 0x00
0x29 FSTEST - 0x59
0x2A PTEST - 0x7F
0x2B AGCTEST - 0x3F
0x2C TEST2 - 0x88
0x2D TEST1 - 0x31
0x2E TEST0 - 0x0Beinspiele erhalte ich wieder Nachrichten in dem Intervall.
ccconf: freq:868.300MHz bWidth:203KHz rAmpl:42dB sens:4dB (DataRate:17257.69Baud, Modulation:2-FSK)Mfg und Gesundes Neues
ZitatHast du mit diesen Einstellungen schon mal etwas empfangen?
Diese Register habe ich von der a-culw.
Mit "Nr1" den Mode1 aktivieren und dann mit "C99" die Register auslesen.
Damit funktioniert das Auslesen über den FIFO des cc1101 zuverlässig.
Ich bekomme damit alle 5 Sekunden eine Nachricht vom TX29DTH-IT
90264430DAAAAA00000BCAB2
90264430DAAAAA00001A37A6
90264431EBAAAA00001422D5
91264632FAAAAA000032387C
91264632FAAAAA000027F65Cund dieser Form können sie dann vom Signalduino Modul weiterverarbeitet werden.
MN;D=90264430DAAAAA00000BCAB2;
MN;D=90264430DAAAAA00001A37A6;
MN;D=90264431EBAAAA00001422D5;Ich habe mir schon darüber Gedanken gemacht welche Anpassungen und Erweiterungen im Signalduino Modul gemacht werden müssen.
Gruß Ralf
Danke für die Info,
ich habe mir soeben nochmal die Einstellungen eingespielt.
Deine Aussage kann ich mit den Daten auf jedenfall verifizieren. Aller 5 Sekunden nicht aber dafür habe ich hier um so mehr Sensoren.
Ich habe mir schon darüber Gedanken gemacht welche Anpassungen und Erweiterungen im Signalduino Modul gemacht werden müssen.
Ich denke mal, das müsste man dann von dem Mode abhängig machen. Wenn der Mode Lacose eingestellt ist, so dann die Daten zum Modul weiterschicken oder welche Idee hast du ?
Die LaCrosse Nachrichten beginnen mit 9.
Hier ist das Message Format und die CRC beschrieben
https://github.com/heliflieger/a-culfw/blob/master/culfw/clib/lacrosse.c
Dies ist das LaCrosse Modul: 36_LaCrosse.pm
Hier wird die Wandlung ins LaCrosse Format beschrieben: 36_Jeelink.pm
Wenn wir dann für jedes Protokoll eine neue Protokoll Id nehmen, können dort die notwendigen Info eingetragen werden.
Z.B:
"100" => ## Lacrosse
{
name => 'Lacrosse',
id => '100',
DataRate => '17257.69',
Sync => 'd42d ',
format => '2-FSK',
match => '^9.*', # fuer eine regexp Pruefung am Anfang vor dem method Aufruf
clientmodule => 'LaCrosse',
method => \&main::SIGNALduino_LaCrosse,
}
Gruß Ralf
Im Datenblatt des cc1101 steht unter "Data FIFO" folgendes:
The number of bytes in the RX FIFO and TX FIFO can be read from the status registers RXBYTES.NUM_RXBYTES and TXBYTES.NUM_TXBYTES respectively.
If a received data byte is written to the RX FIFO at the exact same time as the last byte in the RX FIFO is read over the SPI interface,
the RX FIFO pointer is not properly updated and the last read byte will be duplicated.
To avoid this problem, the RX FIFO should never be emptied before the last byte of the packet is received.
For packet lengths less than 64 bytes it is recommended to wait until the complete packet has been received before reading it out of the RX FIFO.
If the packet length is larger than 64 bytes, the MCU must determine how many bytes can be read from the RX FIFO (RXBYTES.NUM_RXBYTES-1).
The following software routine can be used:
1.) Read RXBYTES.NUM_RXBYTES
repeatedly at a rate specified to be at least
twice that of which RF bytes are received
until the same value is returned twice;
store value in n.
2.) If n < # of bytes remaining in packet, read n-1 bytes from the RX FIFO.
3.) Repeat steps 1 and 2 until n = # of bytes remaining in packet.
4.) Read the remaining bytes from the RX FIFO.
Weiß jemand wie dies "The following software routine can be used:" zu verstehen ist?
Es müsste doch ausreichen "RXBYTES.NUM_RXBYTES-1" Bytes aus dem FIFO auszulesen.
Das dürfte dann auch bedeuten, wenn zum Analisieren von unbekannten Protokollen kein sync verwendet wird, daß dann jeweils nur "RXBYTES.NUM_RXBYTES-1" Bytes aus dem FIFO ausgelesen werden dürfen.
Gruß Ralf
Ich habe es jetzt bei mir im Signalduino Modul soweit eingebaut, daß die Daten im Log ausgegeben werden.
"100" => # Lacrosse
{
name => 'Lacrosse',
id => '100',
knownFreqs => '868.3',
datarate => '17257.69',
sync => '2DD4',
modulation => '2-FSK',
match => '^9.*', # fuer eine regexp Pruefung am Anfang vor dem method Aufruf
clientmodule => 'LaCrosse',
method => \&main::SIGNALduino_LaCrosse,
}
2020.01.04 20:50:35.650 4 : sduinoRXB/msg READ: MN;D=9FE64331ECAAAA0000BFEE54;
2020.01.04 20:50:35.650 4 : sduinoRXB: Found 2-FSK Protocol id 100 -> Lacrosse
2020.01.04 20:50:35.650 4 : sduinoRXB LaCrosse: ID=100, addr=63 temp=24.3, hum=49 bat=0 batInserted=128
2020.01.04 20:54:08.105 4 : sduinoRXB/msg READ: MN;D=926646B1BDAAAA0000CF5F7F;
2020.01.04 20:54:08.105 4 : sduinoRXB: Found 2-FSK Protocol id 100 -> Lacrosse
2020.01.04 20:54:08.105 4 : sduinoRXB LaCrosse: ID=100, addr=9 temp=24.6, hum=49 bat=128 batInserted=128
2020.01.04 20:56:41.257 4 : sduinoRXB/msg READ: MN;D=95A653316BAAAA00000FAD2A;
2020.01.04 20:56:41.257 4 : sduinoRXB: Found 2-FSK Protocol id 100 -> Lacrosse
2020.01.04 20:56:41.257 4 : sduinoRXB LaCrosse: ID=100, addr=22 temp=25.3, hum=49 bat=0 batInserted=128
Mir ist dabei aufgefallen, daß das new battery Bit immer gesetzt ist. Dauert dies nach einem Batteriewechsel länger (ca wie lange) bis das new battery Bit gelöscht wird?
Es fehlt noch die CRC Berechnung.
Hier ist die Arduino CRC Routine:
https://github.com/heliflieger/a-culfw/blob/master/culfw/clib/lacrosse.c
Kann mir diese Routine jemand nach Perl umschreiben?
Die Daten sind in $dmg gespeichert
z.B.
$dmsg = "926646B1BDAAAA0000CF5F7F";
Gruß Ralf
Der Empfang von KoppFreeControl funktioniert bei mir jetzt auch.
Damit auch der Dispatch funktioniert musste ich im 14_CUL_WS.pm Modul den Match Eintrag ändern, sonst wurde ein CUL_WS Sensor angelegt.
von
$hash->{Match} = "^K.....";
nach
$hash->{Match} = "^K[A-Fa-f0-9]{5,}";
Dies ist die neue Protokoll ID
"102" => # Kopp
{
name => 'KoppFreeControl',
id => '102',
datarate => '4785.5',
sync => 'AA54',
modulation => 'GFSK',
match => '^0.*', # fuer eine regexp Pruefung am Anfang vor dem method Aufruf
clientmodule => 'Kopp',
method => \&main::SIGNALduino_KoppFreeControl,
}
2020.01.05 01:09:54.504 4 : sduinoD/msg get raw: MN;D=07FA5E1721CC0F02FE000000000000;
2020.01.05 01:09:54.504 4 : sduinoD: Found GFSK Protocol id 102 -> KoppFreeControl
2020.01.05 01:09:54.504 4 : sduinoD KoppFreeControl: dmsg=07FA5E1721CC0F02FE000000000000 anz=8 checksum=254 ok
2020.01.05 01:09:54.504 4 : sduinoD ParseMN: ID=102 dmsg=kr07FA5E1721CC0F02
2020.01.05 01:09:54.504 4 : sduinoD Dispatch: kr07FA5E1721CC0F02, dispatch
2020.01.05 01:09:54.504 2 : KOPP_FC_Parse: name: sduinoD code: FA5E 21 Specialkey:short
2020-01-05 01:09:54.506 KOPP_FC culfsk on
ZitatEs fehlt noch die CRC Berechnung.
Hier ist die Arduino CRC Routine:
https://github.com/heliflieger/a-culfw/blob/master/culfw/clib/lacrosse.c
Kann mir diese Routine jemand nach Perl umschreiben?
Die Daten sind in $dmg gespeichert
z.B.
$dmsg = "926646B1BDAAAA0000CF5F7F";
Es wäre schön, wenn ich eine Info bekommen könnte ob mir das jemand umschreiben kann, sonst frage ich wo anders.
Gruß Ralf
Zitat von: Ralf9 am 05 Januar 2020, 11:59:03
Es wäre schön, wenn ich eine Info bekommen könnte ob mir das jemand umschreiben kann, sonst frage ich wo anders.
Gruß Ralf
sorry, Java ist nicht mein Ding. Da fehlen mir noch ca. 300 Seiten im Java für Dummies ...
Ist nicht Java, es ist c oder c++
Zitat von: Ralf9 am 05 Januar 2020, 14:18:29
Ist nicht Java, es ist c oder c++
c++ für Dummies steht auch noch im Regal ...
Hast Du eine Formel für mich? Das könnte bei der Interpretation helfen.
Zitat von: Ralf9 am 05 Januar 2020, 11:59:03
Es wäre schön, wenn ich eine Info bekommen könnte ob mir das jemand umschreiben kann, sonst frage ich wo anders.
Gruß Ralf
Hallo Ralf,
so mal auf die schnelle, aber schau mal bitte in die 14_SD_WS09.pm. Da ist diese Funktion enthalten.
sub SD_WS09_CRCCHECK($) {
my $rawData = shift;
my $datacheck1 = pack( 'H*', substr($rawData,2,length($rawData)-2) );
my $crcmein1 = Digest::CRC->new(width => 8, poly => 0x31);
my $rr3 = $crcmein1->add($datacheck1)->hexdigest;
$rr3 = sprintf("%d", hex($rr3));
Log3 "SD_WS09_CRCCHECK", 4, "SD_WS09_CRCCHECK : raw:$rawData CRC=$rr3 " ;
return $rr3 ;
}
Jörg
Das bedeutet dann, daß das "use Digest::CRC qw(crc);" dem Signalduino Modul zugefügt werden muß, das wollte ich eigentlich vermeiden.
Ich würde es gerne mit dieser Routine machen.
Ich verstehe nicht ganz was diese Routine macht, ist dieses Prinzip irgendwo beschrieben?
static uint8_t CalculateCRC(uint8_t *data, uint8_t len) {
uint8_t i, j;
uint8_t res = 0;
for (j = 0; j < len; j++) {
uint8_t val = data[j];
for (i = 0; i < 8; i++) {
uint8_t tmp = (uint8_t)((res ^ val) & 0x80);
res <<= 1;
if (0 != tmp) {
res ^= 0x31;
}
val <<= 1;
}
}
return res;
}
Hi Ralf,
kennst Du Input/Output der Routine? Dann hilft Dir evtl. ein Abgleich mit der hier http://billauer.co.il/blog/2011/05/perl-crc32-crc-xs-module/ (http://billauer.co.il/blog/2011/05/perl-crc32-crc-xs-module/).
Ciao, Peter
dies ist der Input:
90264430DAAAAA00000BCAB2
90264430DAAAAA00001A37A6
90264431EBAAAA00001422D5
91264632FAAAAA000032387C
91264632FAAAAA000027F65C
Ich werde es selber versuchen ob ich es hinbekomme, die c++ Routine nach Perl umzuschreiben.
damit funktioniert es, habe es in einem online Perl Compiler getestet.
my $len = 4;
my $i;
my $j;
my $tmp;
my $val;
my $res = 0;
my $dms = "90264431EBAAAA00001422D5";
my @data = ();
for ($i=0; $i<5; $i++ ) {
push(@data,hex(substr($dms,$i*2,2)));
}
print "data=@data\n";
for ($j = 0; $j < $len; $j++) {
$val = $data[$j];
for ($i = 0; $i < 8; $i++) {
$tmp = ($res ^ $val) & 0x80;
$res <<= 1;
$res = $res & 0xFF;
if ($tmp != 0) {
$res ^= 0x31;
}
$val <<= 1;
}
}
print "res=$res\n";
Nun fehlt im Signalduino Modul noch das
set sduino LaCrossePairForSec <seconds_active> [ignore_battery]
Dann müsste das LaCrosse mit dem 36_LaCrosse.pm Modul funktionieren
ich kann noch raw Nachrichten vom CUL in den Native Modes 1-3 gebrauchen:
Von den normalen Sensoren mit Temperatur und Feuchtigkeit und und nur einem festen Kanal, benötige ich keine, da habe ich den TX29 DTH-IT
Der Mode 1 kann eingestellt werden z.B. mit
set mycul raw Nr1
Die Nachrichten sehen ungefähr so aus, dabei ist N01 der Mode 1, N02 der Mode 2
N019366492F99AAAA0000004008
u.a. kann ich noch raw Nachrichten gebrauchen von folgenden Lacrosse Temperatursensoren
- Sensor mit 2 Kanälen: raw Nachrichten von beiden Kanälen
- Sensor mit 2 Temperaturen: raw Nachrichten von beiden Temperaturen
es sind auch u.a. folgende RAW-Nachrichten interessant
- Mode 3 - PCA 301
- WS 1600 (TX22)
Hallo Ralf,
wollte Ihr die anderen Sensoren Wh24,WH25,usw. (siehe https://forum.fhem.de/index.php/topic,93280.msg859226.html#msg859226) auch einbinden. Senden alle FSK.
Jörg
Zitatwollte Ihr die anderen Sensoren Wh24,WH25,usw. (siehe https://forum.fhem.de/index.php/topic,93280.msg859226.html#msg859226) auch einbinden. Senden alle FSK.
Ich möchte es mir anhand der RAW Nachrichten mal anschauen ob ichs mit überschaubarem Aufwand einbinden kann.
Am Besten beides raw + LaCrosse (OK 9 66 129 4 203 60 [51 02 48 07 3C 22]) Format
Zitat von: Ralf9 am 09 Januar 2020, 23:58:16
Ich möchte es mir anhand der RAW Nachrichten mal anschauen ob ichs mit überschaubarem Aufwand einbinden kann.
Am Besten beides raw + LaCrosse (OK 9 66 129 4 203 60 [51 02 48 07 3C 22]) Format
Als Anhang vom LaCross-Gateway das Log.
WH24, WH25A, 868300 MHz (bessere Empfang, gestern festgestellt 868.340 MHz) 17.241, KeyValue-Protokoll
W136 869.820 MHz 4800 KeyValue-Protokoll
der Rest gemischt 868.300 MHz 17.241/9.579 Umwandlung in das HCS eigene, das vom LaCross.pm Modul verstanden wird.
Wenn man das KeyValue-Protokoll oder JSON nehmen würde, ist man flexibler.
Beim rtl_433 (https://github.com/merbanan/rtl_433) wird MQTT genommen.
Jörg
Hallo Jörg,
Danke für das Log, außer wie die Daten im Lacrosse Format aussehen müssen, hilft mir dies leider nicht weiter.
Das LaCrosse-Gateway sendet die Daten anscheindend schon gewandelt ins LaCrosse Format.
Ich benötigte die Daten vom Cul im nativen Mode 1-3
Mode 1:
N019....
Mode 2:
N029...
Mode 3 müsste dann
N03
Gruß Ralf
Kleiner Zwischenstand von mir: Meine Rolläden lassen sich seit 30.12. mit den RAW-Codes und FSK sauber steuern.
Beim Testen mit diversen Einstellungen habe ich nun festgestellt, nachdem ich die anderen Messagetypen MS und MC wieder aktiviert habe, dass auf einmal Devices vom Typ SD_Keeloq erkannt und angelegt werden. Das macht die Sache für mich wieder spannend, denn wenn ich die Signale der Fernbedienung sauber entschlüsseln und zuordnen kann, kann ich den Status der Rolläden in FHEM auch meiner manueller Bedienung nachziehen.
The show goes on ...
P.S. Kennt sich jemand mit SD_Keeloq aus? Ich müsste da noch ein paar Attribute setzen.
Zitat von: plin am 11 Januar 2020, 10:11:45
P.S. Kennt sich jemand mit SD_Keeloq aus? Ich müsste da noch ein paar Attribute setzen.
Hallo, was benötigst du für ein Attribut und wieso?
Ich habe das Modul ins Leben gerufen.
Gesendet von iPhone mit Tapatalk Pro
Zitat von: HomeAuto_User am 11 Januar 2020, 10:29:59
Ich habe das Modul ins Leben gerufen.
ah, gute Nachricht :)
Zitat von: HomeAuto_User am 11 Januar 2020, 10:29:59
Hallo, was benötigst du für ein Attribut und wieso?
Wieso? Weil das Modul mich dazu auffordert.
Welches Attribut? Zumindest mal attr xxx model Roto, damit habe ich 3 Buttons und kriege einen Status "receive" bei Betätigung.
Ich bin jetzt schon fast im Ziel, habe aber das Problem, dass sich das Reading "button" nicht zuverlässig ändert. Es löst auch kein Event aus. Derzeit umgehe ich das Problem im DOIF mit
((([SD_Keeloq_012C200:state] eq "receive") and ([SD_Keeloq_012C200:button] eq "1010")) or (([SD_Keeloq_012D100:state] eq "receive") and ([SD_Keeloq_012D100:button] eq "1010")))
(setstate Rollladen_EG_WZ_Ter open)Damit funktioniert das was ich brauche.
Update: Das dachte ich. Mit model Roto kriege ich STATE-Updates aber button wird nicht mehr gesetzt. Lösche ich model Roto wieder werden die Buttons richtig erkannt und lösen Events aus.
Muss ich noch andere Attribute setzen ( zumindest gibt es Hinweise auf "Please input KeeLoq_NLF, MasterMSB and MasterLSB Key!")?
Hallo,
Weißt du was KeeLog ist?
Das Modul ist darauf ausgerichtet das du die 3 Schlüssel kennst.
- KeeLoq_NLF, MasterMSB and MasterLSB Key
Damit du die unverschlüsselten Infos erhältst musst du dein Model wählen. Wenn es das nicht gibt, muss man das Modul mit dem Modell von dir gern erweitern. Dazu dann bitte aber einen anderen Faden eröffnen.
Gesendet von iPhone mit Tapatalk Pro
Hochinteressant. Ich dachte mir ja schon, dass der Entwickler der RIO Fernbedienung faul war und sich nur etwas dazu gekauft hat.
Ich mache später einen neuen Thread auf.
Der neue Thread zu SD_Keeloq und RIO FB findet sich unter https://forum.fhem.de/index.php/topic,107239.0.html (https://forum.fhem.de/index.php/topic,107239.0.html).
ich habe meine alternative firmware V 3.3.4.0 dev 200126 erweitert,
https://forum.fhem.de/index.php/topic,82379.msg1010643.html#msg1010643
https://github.com/Ralf9/SIGNALDuino/releases
Da es wahrscheinlich noch länger dauern wird bis die dazu notwendigen Anpassungen im offiziellen Signalduino Modul sind,
sind hier zur Verwendung in einem Testsystem die notwendigen Anpassungen:
https://github.com/Ralf9/RFFHEM/issues/4
Damit funktioniert der Empfang von LaCrosse Termperatursensoren, getestet habe ich bei mir den tx29 dth-it, für die Sensoren mit 2 Kanälen oder 2 Temperaturen sind noch Anpassungen notwendig.
Mit dem Kopp Modul in der Anlage sollte auch das Senden von Kopp Free Control funktionieren.
Beim PCA 301 funktioniert bis jetzt nur der Empfang.
Gruß Ralf
Zitat...nur der Empfang.
Woran hakt es ? Ich würde meine länger brach liegenden Gedanken, eine Sendefunktion in die culfw(aculfw) einzubauen, dann (wahrscheinlich)einstampfen. :D
Grüße Markus
ZitatWoran hakt es ?
Es gibt gerade noch mehrere unbekannte.
Mir ist auch noch nicht klar ob das Schalten und der Statusrequest auch funktionieren, wenn der PCA301 noch nicht gepairt ist
Hallo Ralf,
die geführte Dokumentation ist schon sehr zielstrebig. #Daumen#
Wenn ein User mit der Änderung Bsp.
03 CC1100_FIFOTHR, 2, // 12 byte in RX
04 CC1100_SYNC1, 0x2d,
05 CC1100_SYNC0, 0xd4,
10 CC1100_MDMCFG4, 0x89,
11 CC1100_MDMCFG3, 0x5C,
15 CC1100_DEVIATN, 0x56, // DEVIATN Modem deviation setting (when FSK modulation is enabled).
Das Register setzt, so empfängt dieser noch nichts sichtbar. Dafür sind noch minimale Änderungen in der Firmware / Software notwendig. Bekommen wir es hin, diese noch zu ergänzen. Alternativ bist du bereit diese ggf. an anderer Stelle zu erläutern.
Es kommt ggf. zu Missverständnissen.
Gesendet von iPad mit Tapatalk Pro
Zitatdas Schalten und der Statusrequest auch funktionieren, wenn der PCA301 noch nicht gepairt ist
Wichtig ist sicherlich nur, dass die Dose ihre Adresse u. einen channel hat. Hast Du mittlerweile eine Dose ? Wenn man manuell schaltet wird der Status gesendet.
ZitatHast Du mittlerweile eine Dose?
Ja eine habe ich mittlerweile, 2 weitere folgen noch.
Ich sehe gerade, on und off sind noch vertauscht
2020.01.26 17:03:32.846 4 : sduinoE/msg READ: MN;D=010503B7A101AAAAAAAA7492AA9885E53246E91113F897A4F80D30C8DE602BDF;N=3;
2020.01.26 17:03:32.846 4 : sduinoE Parse_MN: Found 2-FSK Protocol id 101 -> PCA 301
2020.01.26 17:03:32.846 4 : sduinoE PCA301_convert: translated native RF telegram PCA301 OK 24 1 5 3 183 161 1 170 170 170 170 7492
2020.01.26 17:03:32.846 4 : sduinoE ParseMN: ID=101 dmsg=OK 24 1 5 3 183 161 1 170 170 170 170 7492
2020.01.26 17:03:32.846 4 : sduinoE Dispatch: OK 24 1 5 3 183 161 1 170 170 170 170 7492, dispatch
2020-01-26 17:03:32.848 PCA301 PCA301_03B7A1 on
2020.01.26 17:03:34.493 4 : sduinoE/msg READ: MN;D=010503B7A100AAAAAAAAF4E9AAB0D3E2F64942A5C89D17EF862BB860BB4B2F07;N=3;
2020.01.26 17:03:34.494 4 : sduinoE Parse_MN: Found 2-FSK Protocol id 101 -> PCA 301
2020.01.26 17:03:34.494 4 : sduinoE PCA301_convert: translated native RF telegram PCA301 OK 24 1 5 3 183 161 0 170 170 170 170 F4E9
2020.01.26 17:03:34.494 4 : sduinoE ParseMN: ID=101 dmsg=OK 24 1 5 3 183 161 0 170 170 170 170 F4E9
2020.01.26 17:03:34.494 4 : sduinoE Dispatch: OK 24 1 5 3 183 161 0 170 170 170 170 F4E9, dispatch
2020-01-26 17:03:34.496 PCA301 PCA301_03B7A1 offGruß Ralf
Zitat von: HomeAuto_User am 26 Januar 2020, 12:46:41
Das Register setzt, so empfängt dieser noch nichts sichtbar. Dafür sind noch minimale Änderungen in der Firmware / Software notwendig. Bekommen wir es hin, diese noch zu ergänzen. Alternativ bist du bereit diese ggf. an anderer Stelle zu erläutern.
Um welche Änderungen geht es Dir?
Ich hab mal im ersten Beitrag ein paar Sachen ergänzt.
Gruß Ralf
Irgendwas passt bei den PCA 301 Registereinstellungen noch nicht.
Wenn ich versuche von einem sduino zum anderen was zu senden, kommt beim anderen nichts an.
Beim Kopp Free Control kann ich problemlos von einem zum anderen sduino was senden.
Zitat von: Ralf9 am 27 Januar 2020, 00:22:06
Irgendwas passt bei den PCA 301 Registereinstellungen noch nicht.
Ich habe da ja kürzlich ein Script geschrieben, um alle Register-Settings in interpretierter Form auszugeben. Vielleicht hilft Dir das.
Ich habe jetzt erstmal zum Vergleich die SlowRF defaultwerte und die Werte nach dem Reset in ein Array eingetragen:
my %cc1101_register = ( # for get ccreg 99
"00" => ['IOCFG2 ', '0D', '29' ],
"01" => ['IOCFG1 ', '2E' ],
"02" => ['IOCFG0 ', '2D', '3F' ],
"03" => ['FIFOTHR ', '07' ],
"04" => ['SYNC1 ', 'D3' ],
"05" => ['SYNC0 ', '91' ],
"06" => ['PKTLEN ', '3D', '0F' ],
"07" => ['PKTCTRL1', '04' ],
"08" => ['PKTCTRL0', '32', '45' ],
"09" => ['ADDR ', '00' ],
"0A" => ['CHANNR ', '00' ],
"0B" => ['FSCTRL1 ', '06', '0F' ],
"0C" => ['FSCTRL0 ', '00' ],
"0D" => ['FREQ2 ', '10', '1E' ],
"0E" => ['FREQ1 ', 'B0', 'C4' ],
"0F" => ['FREQ0 ', '71', 'EC' ],
"10" => ['MDMCFG4 ', '57', '8C' ],
"11" => ['MDMCFG3 ', 'C4', '22' ],
"12" => ['MDMCFG2 ', '30', '02' ],
"13" => ['MDMCFG1 ', '23', '22' ],
"14" => ['MDMCFG0 ', 'B9', 'F8' ],
"15" => ['DEVIATN ', '00', '47' ],
"16" => ['MCSM2 ', '07', '07' ],
"17" => ['MCSM1 ', '00', '30' ],
"18" => ['MCSM0 ', '18', '04' ],
"19" => ['FOCCFG ', '14', '36' ],
"1A" => ['BSCFG ', '6C' ],
"1B" => ['AGCCTRL2', '07', '03' ],
"1C" => ['AGCCTRL1', '00', '40' ],
"1D" => ['AGCCTRL0', '90', '91' ],
"1E" => ['WOREVT1 ', '87' ],
"1F" => ['WOREVT0 ', '6B' ],
"20" => ['WORCTRL ', 'F8' ],
"21" => ['FREND1 ', '56' ],
"22" => ['FREND0 ', '11', '16' ],
"23" => ['FSCAL3 ', 'E9', 'A9' ],
"24" => ['FSCAL2 ', '2A', '0A' ],
"25" => ['FSCAL1 ', '00', '20' ],
"26" => ['FSCAL0 ', '1F', '0D' ],
"27" => ['RCCTRL1 ', '41' ],
"28" => ['RCCTRL0 ', '00' ],
"29" => ['FSTEST ' ],
"2A" => ['PTEST ' ],
"2B" => ['AGCTEST ' ],
"2C" => ['TEST2 ' ],
"2D" => ['TEST1 ' ],
"2E" => ['TEST0 ' ]
);
Dann habe ich eine Liste der cc1101 Register beim PCA 301, bei den Werten die vom Resetwert abweichen, steht der Resetwert in [ ]
ccregAll:
ccreg 00: 01 2E 46 07 2D D4 FF 00 02 00 00 06 00 21 6B D0
ccreg 10: 88 0B 06 22 F8 53 07 00 18 16 6C 43 68 91 87 6B
ccreg 20: F8 56 10 EC 0C 3D 11 41 00 59 7F 3E 88 31 0B
cc1101 reg detail - addr, name, value, (OOK default),[reset]
0x00 IOCFG2 - 0x01 (0D) [29]
0x01 IOCFG1 - 0x2E
0x02 IOCFG0 - 0x46 (2D) [3F]
0x03 FIFOTHR - 0x07
0x04 SYNC1 - 0x2D (D3)
0x05 SYNC0 - 0xD4 (91)
0x06 PKTLEN - 0xFF (3D) [0F]
0x07 PKTCTRL1 - 0x00 (04)
0x08 PKTCTRL0 - 0x02 (32) [45]
0x09 ADDR - 0x00
0x0A CHANNR - 0x00
0x0B FSCTRL1 - 0x06 [0F]
0x0C FSCTRL0 - 0x00
0x0D FREQ2 - 0x21 (10) [1E]
0x0E FREQ1 - 0x6B (B0) [C4]
0x0F FREQ0 - 0xD0 (71) [EC]
0x10 MDMCFG4 - 0x88 (57) [8C]
0x11 MDMCFG3 - 0x0B (C4) [22]
0x12 MDMCFG2 - 0x06 (30) [02]
0x13 MDMCFG1 - 0x22 (23)
0x14 MDMCFG0 - 0xF8 (B9)
0x15 DEVIATN - 0x53 (00) [47]
0x16 MCSM2 - 0x07
0x17 MCSM1 - 0x00 [30]
0x18 MCSM0 - 0x18 [04]
0x19 FOCCFG - 0x16 (14) [36]
0x1A BSCFG - 0x6C
0x1B AGCCTRL2 - 0x43 (07) [03]
0x1C AGCCTRL1 - 0x68 (00) [40]
0x1D AGCCTRL0 - 0x91 (90)
0x1E WOREVT1 - 0x87
0x1F WOREVT0 - 0x6B
0x20 WORCTRL - 0xF8
0x21 FREND1 - 0x56
0x22 FREND0 - 0x10 (11) [16]
0x23 FSCAL3 - 0xEC (E9) [A9]
0x24 FSCAL2 - 0x0C (2A) [0A]
0x25 FSCAL1 - 0x3D (00) [20]
0x26 FSCAL0 - 0x11 (1F) [0D]
0x27 RCCTRL1 - 0x41
0x28 RCCTRL0 - 0x00
0x29 FSTEST - 0x59
0x2A PTEST - 0x7F
0x2B AGCTEST - 0x3E
0x2C TEST2 - 0x88
0x2D TEST1 - 0x31
0x2E TEST0 - 0x0B
Hi Ralf,
mich wundern etwas Deine Daten. Beim CUL gibt es ja OOK(rfmode=SlowRF=default=Deine 1. Liste). Gegenüber dessen Registereinstellungen werden für native(2-FSK "allgemein") diese Register beim Lesen geändert
NATIVE_CFG[46] = {
CC1100_FSCTRL1, 0x06,
CC1100_FREQ2, 0x21, // FREQ2 Frequency control word, high byte.
CC1100_FREQ1, 0x65, // FREQ1 Frequency control word, middle byte.
CC1100_FREQ0, 0x6A, // FREQ0 Frequency control word, low byte.
CC1100_MCSM1, 0x00, // always go into IDLE after RX or TX
CC1100_MCSM0, 0x18, // automatic calibration when going from IDLE to RX or TX (or FSTXON)
CC1100_FOCCFG, 0x16,
CC1100_AGCCTRL2, 0x43,
CC1100_AGCCTRL1, 0x68,
CC1100_FSCAL1, 0x00,
CC1100_FSCAL0, 0x11,
CC1100_IOCFG2, 0x01, // IOCFG2 Associated to the RX FIFO: Asserts when RX FIFO is filled at or above the RX FIFO threshold or the end of packet is reached. De-asserts when the RX FIFO is empty
CC1100_IOCFG0, 0x46, // IOCFG0 invert output, i.e. select active low (1) / high (0)
CC1100_SYNC0, 0xd4,
CC1100_SYNC1, 0x2d,
CC1100_FIFOTHR, 2, // 12 byte in RX - see page 72 of CC1101.pdf
CC1100_PKTCTRL1, 0x00, // PKTCTRL1 Packet automation control -
CC1100_PKTCTRL0, 0x02, // PKTCTRL0 Packet automation control - Infinite packet length mode
CC1100_MDMCFG4, 0x89, // MDMCFG4 Modem configuration. - channel bandwidth
CC1100_MDMCFG3, 0x5C, // MDMCFG3 Modem configuration. - data rate
CC1100_MDMCFG2, 0x06, // !! 05 !! MDMCFG2 Modem configuration. Modulation 2-FSK with sync-word 16/16 + carrier-sense above threshold
CC1100_DEVIATN, 0x56, // DEVIATN Modem deviation setting (when FSK modulation is enabled).
0xff
};
Für PCA301 zusätzlich
// Mode 3 - PCA 301 - 868.9500MHz 6.631kbps
{
CC1100_FIFOTHR, 0x02, // 32 byte in RX 0x07 RX 0x02 12 bytes / TX 0x12 13 bytes
CC1100_MDMCFG4, 0x88, // MDMCFG4 Modem configuration.
CC1100_MDMCFG3, 0x0B, // MDMCFG3 Modem configuration
CC1100_FREQ2, 0x21, // FREQ2 Frequency control word, high byte.
CC1100_FREQ1, 0x6B, // FREQ1 Frequency control word, middle byte.
CC1100_FREQ0, 0xD0, // FREQ0 Frequency control word, low byte.
CC1100_DEVIATN, 0x53, // DEVIATN Modem deviation setting (when FSK modulation is enabled).
0xff,
}
zumindest bei FIFOTHR(in der culfw 0x07, aber den halte ich für falsch),FSCALx ist mir ein Unterschied aufgefallen.
Und fürs Senden hab ich mir damals nur
CC1100_FIFOTHR, 0x12, //TX 0x12 13 bytes
aufgeschrieben. Ob das richtig ist, weiß ich nicht.
Grüße Markus
Die Registerwerte habe ich von hier, der Empfang funktioniert ja problemlos
https://github.com/heliflieger/a-culfw/blob/master/culfw/clib/rf_native.c
In der zweiten Liste sind die Registerwerte die ich verwende.
Mit Hilfe des HashArrays %cc1101_register wird aus
ccreg 00: 01 2E 46 07 2D D4 FF 00 02 00 00 06 00 21 6B D0
ccreg 10: 88 0B 06 22 F8 53 07 00 18 16 6C 43 68 91 87 6B
ccreg 20: F8 56 10 EC 0C 3D 11 41 00 59 7F 3E 88 31 0B
die zweite Liste erzeugt
Zitatder Empfang funktioniert ja problemlos
das wundert mich ja, wenn FSCALx anders ist. Steht doch im Link auch anders
CC1100_FSCAL1, 0x00,
CC1100_FSCAL0, 0x11,und in Deiner 2.Liste steht
0x23 FSCAL3 - 0xEC (E9) [A9]
0x24 FSCAL2 - 0x0C (2A) [0A]
0x25 FSCAL1 - 0x3D (00) [20]
0x26 FSCAL0 - 0x11 (1F) [0D]ZitatUnd fürs Senden hab ich mir damals nur
Code: [Auswählen]
CC1100_FIFOTHR, 0x12, //TX 0x12 13 bytes
aufgeschrieben. Ob das richtig ist, weiß ich nicht.
Ist (aus dem Kopf) schon wichtig, da dann ja überhaupt erst bei der korrekten Anzahl von bytes im Puffer das Senden erfolgt(wie gesagt: Gedächtnis von vor über einem Jahr) :-\
0x23 FSCAL3 - 0xEC (E9) [A9]
0x24 FSCAL2 - 0x0C (2A) [0A]
0x25 FSCAL1 - 0x3D (00) [20]
0x26 FSCAL0 - 0x11 (1F) [0D]
Die FSCAL Werte sind beim späteren auslesen der Register anders als wie sie am Anfang mit den Werten im EEPROM initialisiert wurden.
Mit diesen Werten werden sie initialisiert
0x23 FSCAL3 E9
0x24 FSCAL2 2A
0x25 FSCAL1 00
0x26 FSCAL0 11
ZitatIst (aus dem Kopf) schon wichtig, da dann ja überhaupt erst bei der korrekten Anzahl von bytes im Puffer das Senden erfolgt(wie gesagt: Gedächtnis von vor über einem Jahr)
Nach meinem Verständnis hat dies nichts mit dem Senden zu tun, dies ist nur ein Schwellwert ab dem sich der Status auf TXFIFO_UNDERFLOW ändert.
ZitatFSCAL Werte sind beim späteren auslesen der Register anders
OK, dann haben die wohl keine Bedeutung. Ich guckte halt nur stumpf in die culfw-source.
ZitatNach meinem Verständnis hat dies nichts mit dem Senden zu tun, dies ist nur ein Schwellwert ab dem sich der Status auf TXFIFO_UNDERFLOW ändert.
Das hab ich anders im Kopf. Ich hab mich am Anfang gewundert, dass viel-zu-viele bytes/Telegramm empfangen wurden. Immer die selbe Anzahl. Und dann meine ich den "Fehler" im CC1100_FIFOTHR, 0x07 gefunden zu haben. Umgekehrt sind dann fürs Senden die volle Anz. bytes notwendig, weil erst ein voller Puffer den/das Empfang/Senden auslöst. Ich kann da aber auch völlig auf dem Holzweg sein....
ZitatMode 3 - PCA 301 - 868.9500MHz 6.631kbps
Was mir auf gefallen ist, mit diesen Registern kommt ein etwas andere Datenrate raus
ccconf: freq:868.950MHz bWidth:203KHz rAmpl:33dB sens:8dB (DataRate:6620.41Baud)
Ich bin inzwischen etwas weitergekommen, so wies aussieht liegts an den Registereinstellungen. Ich bin so weit, daß ich weiß das ich das Schalten und den Statusrequest des PCA 301 hinbekommen werde.
Ich mache hier erst mal nicht weiter, ich weiß bis jetzt überhaupt nicht ob überhaupt Interesse und Bedarf an dem besteht was ich hier mit dem FSK und dem Signalduino mache.
Ich weiß auch mangels Rückmeldungen nicht ob schon jemand mit meiner Firmware den FSK Empfang getestet hat.
Ich warte jetzt erst mal ab ob Interesse und Bedarf an LaCrosse, Kopp Free Control und PCA 301 und weiteren Sensoren mit dem Signalduino besteht.
Gruß Ralf
LaCrosse definitiv. Habe von den it 29-dth ein paar. Brauche dafür ja noch das LaCrosse Gateway.
Gebe ich richtig in der Annahme, daß der geänderte sduino mit 2x cc1101 (433 und 868Mhz) ausgestattet werden wird bzw kann?
Gesendet von meinem MI 9 mit Tapatalk
Zitat von: Ralf9 am 28 Januar 2020, 19:13:05
Ich mache hier erst mal nicht weiter, ich weiß bis jetzt überhaupt nicht ob überhaupt Interesse und Bedarf an dem besteht was ich hier mit dem FSK und dem Signalduino mache.
Ich weiß auch mangels Rückmeldungen nicht ob schon jemand mit meiner Firmware den FSK Empfang getestet hat.
Hallo Ralf,
ich habe mittlerweile eine Lösung für meine RIO-Motoren, die senden per FSK. Ich weiß welche Register ich dafür wie umschießen muss. Ich hatte das auch mit Deiner Firmware gestetet. Mittlwerweile ist das Protokoll ins Modul SD_Keeloq eingeflossen.
Aber: Ich nutze den SIGNALduino nicht im FIFO-Mode sondern nur als Modem. Wenn ich von OOK auf FSK wechsele, Trägerfrequenz, Hub und Bandbreite anpasse kann ich die Rolladenmotoren steuern und auch die Signale der Fernbedienung empfangen.
Also: Ja, es gibt Leute die Interesse an FSK mit SIGNALduino haben. Ich sehe hier insbesondere den Vorteil, dass der SIGNALduino recht frei konfigurierbar ist und die Demodulation erst im Modul erfolgt. Wenn man es mit Exoten, unbekannten oder neuen Protokollen zu tun hat ist das recht hilfreich.
Viele Grüße
Peter
ZitatGebe ich richtig in der Annahme, daß der geänderte sduino mit 2x cc1101 (433 und 868Mhz) ausgestattet werden wird bzw kann?
Ja, die sduino Firmware auf dem Maple Mini wird 1 x 433 oder 868 (SlowRF) und bis zu 3 x 868Mhz mit FIFO können.
Zitatich weiß bis jetzt überhaupt nicht ob überhaupt Interesse und Bedarf an dem besteht was ich hier mit dem FSK und dem Signalduino mache.
Aber hallo. Natürlich gibt es Bedarf. Was hat Dich entmutigt ?
Nunja. Wenn alles klappt, dann braucht man ja nur noch den neuen sduino. Kein cul, kein LaCrosse Gateway.
Aber die Firmware wäre kompatibel mit der Hardware von Locutus seinen maple Mini?
Gesendet von meinem MI 9 mit Tapatalk
Zitat von: Ralf9 am 28 Januar 2020, 19:13:05
Ich warte jetzt erst mal ab ob Interesse und Bedarf an LaCrosse, Kopp Free Control und PCA 301 und weiteren Sensoren mit dem Signalduino besteht.
Also ich hab auch Interesse und verfolge den Thread sehr begeistert und still lesend von Beginn an. Imho eröffnen solche Fähigkeitserweiterungen des Sduino schöne neue Möglichkeiten (kinetische Funktaster@433?? oder gar KNX-RF?? uvm.).
Ich fänds klasse wenn es doch weiter ginge. Aber, jeder braucht ne Verschnaufpause - Rom wurde auch nicht an einem Tag erbaut :D
Viele Grüße
rob
Ja, es geht schon weiter, aber vorerst nicht hier. Ich sehe bei der Version für den nano oder minicul momentan kein Interesse oder Bedarf an FSK unterstützung beim sduino.
Es geht jetzt weiter bei der Version für den Maple Mini. Es ist geplant, daß diese dann auch auf dem Maple Cul läuft.
Ja MapleSignalduino sollte die Zukunft sein ;-)
Daumen hoch! Ich bin auch super begeistert von der Möglichkeit.
Gruß Arnd
Signalduino (Nano, ESP, ...), CUL (Busware, Nano, Maple, ...), Homematic (HM-MOD-UART-RPI, ESP, Maple, ...), LaCrosseGateway (LGW, ESP, ...), 1-wire, ESPEasy, Bravia, Yamaha, ...
Hallo zusammen,
ich halte mich hier in letzter Zeit zurück, weil meine Probleme ausmeiner Sicht, mit dem SDuino nicht zu lösen sind. Ich empfange wie schon vor längerer Zeit erwähnt die Bits direkt (quasi wie mit einem Schieberegister) d.h. Es kann nahezu beliebig viele Pattern geben.
D.h tatsächlich wenig Interesse im Augenblick
Zitatmein maple läuft derzeit mit N1 und N2. Parallel läuft noch ein Jeelink Gateway mit, das empfängt aber wesentlich mehr Pakete.
Welche Sensoren empfängst Du z.Zt. mit N1 und N2?
Welche Sensoren empfängt der Jeelink zusätzlich?
soll mir auch recht sein wenn der Signalduino die Eierlegendewollmilchsau wird.
Ich habe ausschließlich TFA 30.3155 WD im Einsatz mit N2, N1 empfängt jede Menge TCM97001 aus der Nachbarschaft.
Der Jeelink empfängt auch nur die TFA's und kümmert sich um meine PCA301 Steckdosen.
Vielleicht hab ich mich auch falsch ausgedrückt, es gibt Abweichungen zwischen dem mapleCUN und dem Jeelink
MapleCUN:
Internals:
CHANGED
CODE 4326
DEF 4326
FUUID 5c433311-f33f-371b-9511-b194e49fc04aa793
FVERSION 12_HMS.pm:0.167970/2018-05-29
IODev mapleCUN1
LASTInputDev mapleCUN1
MSGCNT 6354
NAME Kuehlschrank
NR 922
STACKABLE_CC_4_MSGCNT 81
STACKABLE_CC_4_RAWMSG 810e04xx0510a0014326000000130025
STACKABLE_CC_4_RSSI -74.5
STACKABLE_CC_4_TIME 2020-02-27 19:05:42
STATE T: 4.8 H: 21 Bat: ok
TYPE HMS
mapleCUN1_MSGCNT 6273
mapleCUN1_RAWMSG 810e04xx0510a0014326000000480021
mapleCUN1_RSSI -74.5
mapleCUN1_TIME 2020-02-27 19:26:37
Helper:
DBLOG:
humidity:
fhemlogDB:
TIME 1582827952.20374
VALUE 21
temperature:
fhemlogDB:
TIME 1582827977.25417
VALUE 4.8
READINGS:
2020-02-27 19:26:37 battery ok
2020-02-27 19:26:37 batteryState ok
2020-02-27 19:26:17 dewpoint -15.7
2020-02-27 19:26:37 humidity 21
2020-02-27 19:26:37 state T: 4.8 H: 21 Bat: ok
2020-02-27 19:26:37 temperature 4.8
2020-02-27 19:26:37 ttstemp 4,8
2020-02-27 19:26:37 type HMS100TF
Attributes:
DbLogInclude humidity,temperature
IODev mapleCUN1
event-min-interval humidity:60,temperature:60
event-on-change-reading battery,humidity:2,temperature:0.2
model hms100-tf
mqttName Kuehlschrank
mqttReadings humidity,temperature
mqttRoom Wetter
room Wetter
userReadings ttstemp { my $val = ReadingsVal($name,"temperature","Fehler"); $val =~ s/\./,/; $val;}
Jeelink:
Internals:
CHANGED
DEF 26
FUUID 5cd5b9b7-f33f-371b-bcaf-5a7a7400b6405b89
FVERSION 36_LaCrosse.pm:0.202170/2019-09-21
IODev LaCrosseGateway
LASTInputDev LaCrosseGateway
LaCrosseGateway_MSGCNT 6911
LaCrosseGateway_TIME 2020-02-27 19:46:12
LaCrosse_lastRcv 2020-02-27 19:46:12
MSGCNT 6874
NAME Lacrosse_Kuehlschrank
NR 1165
STATE T: 6.2 H: 20
TYPE LaCrosse
addr 26
battery_new 0
corr1 0
corr2 0
previousH 20
previousT 6.2
sensorType 0=T(H)
Helper:
DBLOG:
humidity:
fhemlogDB:
TIME 1582828442.23685
VALUE 20
temperature:
fhemlogDB:
TIME 1582829152.25169
VALUE 6.2
ttstemp:
fhemlogDB:
TIME 1582829152.25169
VALUE 6,2
READINGS:
2020-02-27 19:46:12 battery ok
2020-02-27 19:45:52 dewpoint -15.2
2020-02-27 19:46:12 humidity 20
2020-02-27 19:45:52 state T: 6.2 H: 20
2020-02-27 19:46:12 temperature 6.2
2020-02-27 19:46:12 ttstemp 6,2
Attributes:
DbLogInclude .*
IODev LaCrosseGateway
event-on-change-reading battery,humidity,temperature,ttstemp
room Wetter
userReadings ttstemp { my $val = ReadingsVal($name,"temperature","Fehler");; $val =~ s/\./,/;; $val;;}
Der TFA 30.3155 WD wird demnach beim Cul im Mode 2 - IT+ 9.579 kbps empfangen.
Die Cul Raw Nachrichten müssten dann mit N02 anfangen.
Ich kann vom TFA 30.3155 WD noch log Auszüge gebrauchen die folgendes enthalten:
2019.01.08 17:59:25 4: CUL_Parse: CUL0 N03070426D9C300FFFFFFFF054418A0841212810A6501C5120600000000000000B2
2019.01.08 17:59:25 5: CUL0: dispatch OK 24 7 4 38 217 195 0 255 255 255 255 0544
2019.01.08 17:59:25 5: JeeLink/RAW: OK 24 7 4 38 217 /195 1 0 123 26 176
Was empfängst Du mit dem Cul Mode 1 - IT+ 17.241 kbps
log vom maplecun3 (N1):
2020.02.27 20:55:43 4: CUL_Parse: mapleCUN3 N0192C4636AD8AAAA000156F0D1
2020.02.27 20:55:43 3: mapleCUN3: Unknown code N0192C4636AD8AAAA000156F0D1, help me!
2020.02.27 20:55:48 4: CUL_Parse: mapleCUN3 *N03050426D9D500FFFFFFFF5578AAAAAA000000000428AEDAD7347CA4DA8DBD93D6
2020.02.27 20:55:50 4: CUL_Parse: mapleCUN3 N0192C4636AD8AAAA000190D17D
2020.02.27 20:55:50 3: mapleCUN3: Unknown code N0192C4636AD8AAAA000190D17D, help me!
2020.02.27 20:55:55 4: CUL_Parse: mapleCUN3 *N0303040B9DB500FFFFFFFF85C2AAAAAA000000000BBDF4178EF8D535CB36A9F322
2020.02.27 20:55:56 4: CUL_Parse: mapleCUN3 *N03020406795A00FFFFFFFFF759AAAAAA00000000060814E6139D7807231EC6262B
2020.02.27 20:55:56 4: CUL_Parse: mapleCUN3 *N03020406795A01000A019C72C8AABCED0323283962589F487F5920A591D10EB41F
2020.02.27 20:55:56 4: CUL_Parse: mapleCUN3 *N03080406DDF300FFFFFFFFA138AAAAAA2121212103F3E9D7D814DD63B869A00002
2020.02.27 20:55:56 4: CUL_Parse: mapleCUN3 *N03080406DDF301000B000021F5AAF7150220DF15580EBA02CE19918CEFB8207E69
2020.02.27 20:55:57 4: CUL_Parse: mapleCUN3 *N03010426E3B600FFFFFFFF64E8AAAAAA0404040406C60B5323D3CECFAB64D48AAE
2020.02.27 20:55:57 4: CUL_Parse: mapleCUN3 *N03010426E3B600000002606982AA3BF18FAC439887A471819C136B0FB8C667A594
2020.02.27 20:55:58 4: CUL_Parse: mapleCUN3 *N03070406CF3300FFFFFFFF1217AAAAAA050505050DDAB46456D09F447A9B2727B7
2020.02.27 20:55:58 4: CUL_Parse: mapleCUN3 N0192C4636AD8AAAA000146AE17
2020.02.27 20:55:58 3: mapleCUN3: Unknown code N0192C4636AD8AAAA000146AE17, help me!
2020.02.27 20:55:58 4: CUL_Parse: mapleCUN3 *N0308040EDDF300FFFFFFFF2108AAAAAA909090908347ADB9AD91767995487B7029
2020.02.27 20:55:59 4: CUL_Parse: mapleCUN3 *N0308040EDDF300FFFFFFFF2108AAAAAA90909090F2103B79A107A8E5187C3F7CC5
2020.02.27 20:55:59 4: CUL_Parse: mapleCUN3 *N03080426D9FC00FFFFFFFF8DBBAAAAAA9090909005468334E897058E63E1E65598
2020.02.27 20:55:59 4: CUL_Parse: mapleCUN3 *N03080426D9FC00FFFFFFFF8DBBAAAAAA90909090F6228F4F7358217291FAED7C52
2020.02.27 20:55:59 4: CUL_Parse: mapleCUN3 *N03030426E3C600FFFFFFFFA4B7AAAAAA9090909086EB047FD2CF735432EFF4C572
2020.02.27 20:56:00 4: CUL_Parse: mapleCUN3 *N03030426E3C6010101290AC6CEAAE6F777F5D43B31FA254CBFA05405FDF5BA6CB7
2020.02.27 20:56:00 4: CUL_Parse: mapleCUN3 *N0303040D8AFA00FFFFFFFF5BEEAAAAAA0000000004C654DE75FF89B269F98A88FE
2020.02.27 20:56:00 4: CUL_Parse: mapleCUN3 *N0303040D8AFA00FFFFFFFF5BEEAAAAAA00000000068D86DA6694228EB7CE396B4B
2020.02.27 20:56:01 4: CUL_Parse: mapleCUN3 *N03010426DADE00FFFFFFFF1E17AAAAAA000000000721D2BD8427C29FB3112DF2B7
2020.02.27 20:56:01 4: CUL_Parse: mapleCUN3 *N03010426DADE00000023DA56E2AAA27574BE9519B60D6072F22DAD69D2E9EDF7D8
2020.02.27 20:56:01 4: CUL_Parse: mapleCUN3 *N03080426D9AE00FFFFFFFFFDEDAAAAAA101010100244C8FFE7F54A54417C745193
2020.02.27 20:56:01 4: CUL_Parse: mapleCUN3 *N03080426D9AE01041280F6AEE9AAFE518BC8F84BD94777ADE4EA66D0FBEDE7D2B5
2020.02.27 20:56:02 4: CUL_Parse: mapleCUN3 *N03070426D9C300FFFFFFFF0544AAAAAA292929290A88362E53A1D7E6BA9CA55F82
2020.02.27 20:56:02 4: CUL_Parse: mapleCUN3 *N0302040B9DB400FFFFFFFF9DD6AAAAAA01010101035CD1E7A6E2D669725FC10D83
2020.02.27 20:56:02 4: CUL_Parse: mapleCUN3 *N0302040B9DB401000A00009D0CAABA7FB7EDDA56F99875CF6E7EF3BD407B8D86B0
2020.02.27 20:56:03 4: CUL_Parse: mapleCUN3 *N03050426D10C00FFFFFFFFE52FAAAAAA000000000D9D32532078A97AAC0A650033
2020.02.27 20:56:03 4: CUL_Parse: mapleCUN3 *N03050426D10C00FFFFFFFFE52FAAAAAA00000000040B4FFF94759B508CD709B356
2020.02.27 20:56:03 4: CUL_Parse: mapleCUN3 *N03080404981000FFFFFFFF488AAAAAAA000000000120E96B0FA23B2A1DBF39ADF1
2020.02.27 20:56:03 4: CUL_Parse: mapleCUN3 *N03080404981000FFFFFFFF488AAAAAAA0000000004DC7DFD4B451C1BD533FB1EE4
2020.02.27 20:56:04 4: CUL_Parse: mapleCUN3 *N0303040A1DB000FFFFFFFF85C2AAAAAA00000000021EF23BF9AC3D6357369D3158
2020.02.27 20:56:04 4: CUL_Parse: mapleCUN3 *N0303040A1DB000FFFFFFFF85C2AAAAAA0000000001A4B3FC8D58BF85BE68EBBBF8
2020.02.27 20:56:04 4: CUL_Parse: mapleCUN3 *N0303040B8DB500FFFFFFFF14C1AAAAAA00000000093E7F6408F1B7944F267BCB56
2020.02.27 20:56:05 4: CUL_Parse: mapleCUN3 *N0303040B8DB500FFFFFFFF14C1AAAAAA00000000043F20A9FEB93F16AA28833D9C
2020.02.27 20:56:05 4: CUL_Parse: mapleCUN3 *N03080407829600FFFFFFFFF3ADAAAAAA000000000FA53C6D166FD95F0EBDE4A31B
2020.02.27 20:56:05 4: CUL_Parse: mapleCUN3 *N03080407829600FFFFFFFFF3ADAAAAAA0000000007F020C0E04E0633E33EDE5729
2020.02.27 20:56:05 4: CUL_Parse: mapleCUN3 *N0303040D02FA00FFFFFFFFDB6EAAAAAA0000000009C3FBB4625FFB2ABB2429373B
2020.02.27 20:56:06 4: CUL_Parse: mapleCUN3 *N0303040D02FA00FFFFFFFFDB6EAAAAAA0000000006F9DC6CF7D26FD8E8AF2E4EBE
2020.02.27 20:56:06 4: CUL_Parse: mapleCUN3 *N0303040D02FA00FFFFFFFFDB6EAAAAAA000000000528E5539838976558BCA51DE2
2020.02.27 20:56:06 4: CUL_Parse: mapleCUN3 *N0303040D02FA00FFFFFFFFDB6EAAAAAA0000000002091B00000000000000139155
2020.02.27 20:56:09 4: CUL_Parse: mapleCUN3 *N03010426E40500FFFFFFFFEB23AAAAAA000000000545C469D059BC2FAA997049DB
2020.02.27 20:56:11 4: CUL_Parse: mapleCUN3 *N03050426D98C00FFFFFFFFED27AAAAAA6464646402506ABB5C19949E8AFF8754EE
2020.02.27 20:56:15 4: CUL_Parse: mapleCUN3 N0192C4636AD8AAAA0000607B68
2020.02.27 20:56:15 3: mapleCUN3: Unknown code N0192C4636AD8AAAA0000607B68, help me!
2020.02.27 20:56:23 4: CUL_Parse: mapleCUN3 N0192C4636AD8AAAA0001C20356
2020.02.27 20:56:23 3: mapleCUN3: Unknown code N0192C4636AD8AAAA0001C20356, help me!
2020.02.27 20:56:24 4: CUL_Parse: mapleCUN3 *N03080406B91000FFFFFFFF4B96AAAAAAC2C2C2C2084CF0BCE349CFFC16FE833922
2020.02.27 20:56:27 4: CUL_Parse: mapleCUN3 N0192C4626A2CAAAA0001FDB589
2020.02.27 20:56:27 3: mapleCUN3: Unknown code N0192C4626A2CAAAA0001FDB589, help me!
2020.02.27 20:56:31 4: CUL_Parse: mapleCUN3 N0192C4626A2CAAAA0001CAF1F5
2020.02.27 20:56:31 3: mapleCUN3: Unknown code N0192C4626A2CAAAA0001CAF1F5, help me!
2020.02.27 20:56:35 4: CUL_Parse: mapleCUN3 N0192C4626A2CAAAA000046E3F8
2020.02.27 20:56:35 3: mapleCUN3: Unknown code N0192C4626A2CAAAA000046E3F8, help me!
2020.02.27 20:56:43 4: CUL_Parse: mapleCUN3 N0192C4636AD8AAAA0001E2B762
2020.02.27 20:56:43 3: mapleCUN3: Unknown code N0192C4636AD8AAAA0001E2B762, help me!
2020.02.27 20:56:47 4: CUL_Parse: mapleCUN3 N0192C4626A2CAAAA000191EC54
2020.02.27 20:56:47 3: mapleCUN3: Unknown code N0192C4626A2CAAAA000191EC54, help me!
2020.02.27 20:56:51 4: CUL_Parse: mapleCUN3 N0192C4626A2CAAAA00004F832F
2020.02.27 20:56:51 3: mapleCUN3: Unknown code N0192C4626A2CAAAA00004F832F, help me!
2020.02.27 20:56:55 4: CUL_Parse: mapleCUN3 N0192C4626A2CAAAA00008FD676AF
2020.02.27 20:56:55 3: mapleCUN3: Unknown code N0192C4626A2CAAAA00008FD676AF, help me!
mapleCUN1 (N1):
2020.02.27 21:00:51 4: CUL_Parse: mapleCUN1 N029D06162D1B14831400D40C4E
2020.02.27 21:00:51 3: mapleCUN1: Unknown code N029D06162D1B14831400D40C4E, help me!
2020.02.27 21:00:51 4: CUL_Parse: mapleCUN1 H433400160245FF -74.5
2020.02.27 21:00:52 4: CUL_Parse: mapleCUN1 N0296C59636FC10080020444140
2020.02.27 21:00:52 3: mapleCUN1: Unknown code N0296C59636FC10080020444140, help me!
2020.02.27 21:00:52 4: CUL_Parse: mapleCUN1 H431B00960154FF -74.5
2020.02.27 21:00:55 4: CUL_Parse: mapleCUN1 **N0192C4626A2CAAAA000173C8D1
2020.02.27 21:00:55 4: CUL_Parse: mapleCUN1 H430B01620000FF -74.5
2020.02.27 21:00:55 4: CUL_Parse: mapleCUN1 N029384844367C0F0B10B540400
2020.02.27 21:00:55 3: mapleCUN1: Unknown code N029384844367C0F0B10B540400, help me!
2020.02.27 21:00:55 4: CUL_Parse: mapleCUN1 H430E00840067FF -74.5
2020.02.27 21:00:55 4: CUL_Parse: mapleCUN1 N0298C185495000002400000018
2020.02.27 21:00:55 3: mapleCUN1: Unknown code N0298C185495000002400000018, help me!
2020.02.27 21:00:55 4: CUL_Parse: mapleCUN1 ***N03080406B91000FFFFFFFF4B96AAAAAA0505050507262335214D0DA0A6D104DFF7
2020.02.27 21:00:56 4: CUL_Parse: mapleCUN1 *omAAAAAAAAAAAAAAA0FF
2020.02.27 21:00:56 4: CUL_Parse: mapleCUN1 *omAB5C7F1A2D4F8AD0FF
2020.02.27 21:00:56 4: CUL_Parse: mapleCUN1 **N0192C4626A2CAAAA00004B0E75
2020.02.27 21:00:57 4: CUL_Parse: mapleCUN1 H430B01620000FF -74.5
2020.02.27 21:00:57 4: CUL_Parse: mapleCUN1 N02998399163AA0100A7626B517
2020.02.27 21:00:57 3: mapleCUN1: Unknown code N02998399163AA0100A7626B517, help me!
2020.02.27 21:00:57 4: CUL_Parse: mapleCUN1 H432680010022FF -74.5
2020.02.27 21:00:58 4: CUL_Parse: mapleCUN1 N029D46082EB9828111010050A2
2020.02.27 21:00:58 3: mapleCUN1: Unknown code N029D46082EB9828111010050A2, help me!
2020.02.27 21:00:58 4: CUL_Parse: mapleCUN1 H433500080246FF -74.5
2020.02.27 21:00:58 4: CUL_Parse: mapleCUN1 N029A0598300205000000000000
2020.02.27 21:00:58 3: mapleCUN1: Unknown code N029A0598300205000000000000, help me!
2020.02.27 21:00:58 4: CUL_Parse: mapleCUN1 H432800980148FF -74.5
2020.02.27 21:00:58 4: CUL_Parse: mapleCUN1 N0298C185496901000000000000
2020.02.27 21:00:58 3: mapleCUN1: Unknown code N0298C185496901000000000000, help me!
2020.02.27 21:01:01 4: CUL_Parse: mapleCUN1 **N0192C4626A2CAAAA0001C431C7
2020.02.27 21:01:01 4: CUL_Parse: mapleCUN1 H430B01620000FF -74.5
2020.02.27 21:01:01 4: CUL_Parse: mapleCUN1 N029D06162D1B000001000C0052
2020.02.27 21:01:01 3: mapleCUN1: Unknown code N029D06162D1B000001000C0052, help me!
2020.02.27 21:01:01 4: CUL_Parse: mapleCUN1 H433400160245FF -74.5
2020.02.27 21:01:02 4: CUL_Parse: mapleCUN1 N0296C59636FC30201800100002
2020.02.27 21:01:02 3: mapleCUN1: Unknown code N0296C59636FC30201800100002, help me!
2020.02.27 21:01:02 4: CUL_Parse: mapleCUN1 H431B00960154FF -74.5
2020.02.27 21:01:02 4: CUL_Parse: mapleCUN1 N02998399163A02A40000000000
2020.02.27 21:01:02 3: mapleCUN1: Unknown code N02998399163A02A40000000000, help me!
2020.02.27 21:01:02 4: CUL_Parse: mapleCUN1 H432680010022FF -74.5
2020.02.27 21:01:03 4: CUL_Parse: mapleCUN1 N02938484436704400814000881
2020.02.27 21:01:03 3: mapleCUN1: Unknown code N02938484436704400814000881, help me!
2020.02.27 21:01:03 4: CUL_Parse: mapleCUN1 H430E00840067FF -74.5
2020.02.27 21:01:03 4: CUL_Parse: mapleCUN1 N0298C185496000001003010810
2020.02.27 21:01:03 3: mapleCUN1: Unknown code N0298C185496000001003010810, help me!
2020.02.27 21:01:07 4: CUL_Parse: mapleCUN1 N02998399163AC2001900000088
2020.02.27 21:01:07 3: mapleCUN1: Unknown code N02998399163AC2001900000088, help me!
2020.02.27 21:01:07 4: CUL_Parse: mapleCUN1 H432680010022FF -74.5
2020.02.27 21:01:08 4: CUL_Parse: mapleCUN1 N029D46082EB900000000240600
2020.02.27 21:01:08 3: mapleCUN1: Unknown code N029D46082EB900000000240600, help me!
2020.02.27 21:01:08 4: CUL_Parse: mapleCUN1 H433500080246FF -74.5
2020.02.27 21:01:08 4: CUL_Parse: mapleCUN1 N029A05983002100110400C2000
2020.02.27 21:01:08 3: mapleCUN1: Unknown code N029A05983002100110400C2000, help me!
2020.02.27 21:01:08 4: CUL_Parse: mapleCUN1 H432800980148FF -74.5
2020.02.27 21:01:09 4: CUL_Parse: mapleCUN1 **N0192C4636AD8AAAA000131E6BE
2020.02.27 21:01:09 4: CUL_Parse: mapleCUN1 H430B01630000FF -74.5
2020.02.27 21:01:11 4: CUL_Parse: mapleCUN1 N029D06162D1B42501222608030
2020.02.27 21:01:11 3: mapleCUN1: Unknown code N029D06162D1B42501222608030, help me!
2020.02.27 21:01:11 4: CUL_Parse: mapleCUN1 H433400160245FF -74.5
2020.02.27 21:01:12 4: CUL_Parse: mapleCUN1 N0296C59636FC8000C088400241
2020.02.27 21:01:12 3: mapleCUN1: Unknown code N0296C59636FC8000C088400241, help me!
2020.02.27 21:01:12 4: CUL_Parse: mapleCUN1 H431B00960154FF -74.5
2020.02.27 21:01:13 4: CUL_Parse: mapleCUN1 N02938484436720C28008000440
2020.02.27 21:01:13 3: mapleCUN1: Unknown code N02938484436720C28008000440, help me!
2020.02.27 21:01:13 4: CUL_Parse: mapleCUN1 H430E00840067FF -74.5
2020.02.27 21:01:13 4: CUL_Parse: mapleCUN1 **N0192C4626A2CAAAA00016F0213
2020.02.27 21:01:13 4: CUL_Parse: mapleCUN1 H430B01620000FF -74.5
2020.02.27 21:01:13 4: CUL_Parse: mapleCUN1 N0298C18549440C108040A8500A
2020.02.27 21:01:13 3: mapleCUN1: Unknown code N0298C18549440C108040A8500A, help me!
2020.02.27 21:01:17 4: CUL_Parse: mapleCUN1 N0299839816CE44040220000014
2020.02.27 21:01:17 3: mapleCUN1: Unknown code N0299839816CE44040220000014, help me!
2020.02.27 21:01:17 4: CUL_Parse: mapleCUN1 H432680020022FF -74.5
2020.02.27 21:01:17 4: CUL_Parse: mapleCUN1 **N0192C4626A2CAAAA0001FFE9C1
2020.02.27 21:01:17 4: CUL_Parse: mapleCUN1 H430B01620000FF -74.5
2020.02.27 21:01:18 4: CUL_Parse: mapleCUN1 N029D46082EB905142005285480
2020.02.27 21:01:18 3: mapleCUN1: Unknown code N029D46082EB905142005285480, help me!
2020.02.27 21:01:18 4: CUL_Parse: mapleCUN1 H433500080246FF -74.5
2020.02.27 21:01:18 4: CUL_Parse: mapleCUN1 N029A05983002100800A2442186
2020.02.27 21:01:18 3: mapleCUN1: Unknown code N029A05983002100800A2442186, help me!
2020.02.27 21:01:18 4: CUL_Parse: mapleCUN1 H432800980148FF -74.5
2020.02.27 21:01:21 4: CUL_Parse: mapleCUN1 **N0192C4626A2CAAAA00006CF9B6
2020.02.27 21:01:21 4: CUL_Parse: mapleCUN1 H430B01620000FF -74.5
2020.02.27 21:01:21 4: CUL_Parse: mapleCUN1 N029D06162D1B80010400C2925E
2020.02.27 21:01:21 3: mapleCUN1: Unknown code N029D06162D1B80010400C2925E, help me!
2020.02.27 21:01:21 4: CUL_Parse: mapleCUN1 H433400160245FF -74.5
Ich hoffe das bringt Dich weiter...
ZitatVielleicht hab ich mich auch falsch ausgedrückt, es gibt Abweichungen zwischen dem mapleCUN und dem Jeelink
Werden vom Jeelink die richtigen Werte angezeigt?
2020.02.27 21:00:57 4: CUL_Parse: mapleCUN1 N02998399163AA0100A7626B517
2020.02.27 21:01:02 4: CUL_Parse: mapleCUN1 N02998399163A02A40000000000
2020.02.27 21:01:18 4: CUL_Parse: mapleCUN1 N029D46082EB905142005285480Beim TFA 30.3155 WD kann ich zu den Raw Nachrichten vom Cul auch die JeeLink/RAW
2019.01.08 17:59:25 5: JeeLink/RAW: OK 9 14 1 4 60 67und die temp und Hum gebrauchen
Hast Du auch einen 2 Kanal Sensor wie z.B. der TX25IT oder ist der evtl vom Nachbar?
2020.02.27 20:56:23 4: CUL_Parse: mapleCUN3 N0192C4636AD8AAAA0001C20356
2020.02.27 20:56:51 4: CUL_Parse: mapleCUN3 N0192C4626A2CAAAA00004F832F
Zitat von: Ralf9 am 27 Februar 2020, 23:04:40
Werden vom Jeelink die richtigen Werte angezeigt?
Da sich die Werte beim Jeelink öfter ändern, gehe ich davon aus dass dieser die aktuellen liefert.
Zitat von: Ralf9 am 27 Februar 2020, 23:04:40
Hast Du auch einen 2 Kanal Sensor wie z.B. der TX25IT oder ist der evtl vom Nachbar?
2020.02.27 20:56:23 4: CUL_Parse: mapleCUN3 N0192C4636AD8AAAA0001C20356
2020.02.27 20:56:51 4: CUL_Parse: mapleCUN3 N0192C4626A2CAAAA00004F832F
nein, alle aus der Nachbarschaft.
[code]
2020.02.28 15:43:34 4: CUL_Parse: mapleCUN1 **N0192C4976A43AAAA000166DA1E
2020.02.28 15:43:34 4: CUL_Parse: mapleCUN1 H430B01970000FF -74.5
2020.02.28 15:43:36 4: CUL_Parse: mapleCUN1 N029D06152F54E9298018012808
2020.02.28 15:43:36 3: mapleCUN1: Unknown code N029D06152F54E9298018012808, help me!
2020.02.28 15:43:36 4: CUL_Parse: mapleCUN1 H433400150247FF -74.5
2020.02.28 15:43:36 4: CUL_Parse: mapleCUN1 N0296C5963D1600000000000000
2020.02.28 15:43:36 3: mapleCUN1: Unknown code N0296C5963D1600000000000000, help me!
2020.02.28 15:43:36 4: CUL_Parse: mapleCUN1 H431B00960161FF -74.5
2020.02.28 15:43:37 4: CUL_Parse: mapleCUN1 N0298C175494080000000C02840
2020.02.28 15:43:37 3: mapleCUN1: Unknown code N0298C175494080000000C02840, help me!
2020.02.28 15:43:38 4: CUL_Parse: mapleCUN1 N029A05912FAC82000100800008
2020.02.28 15:43:38 3: mapleCUN1: Unknown code N029A05912FAC82000100800008, help me!
2020.02.28 15:43:38 4: CUL_Parse: mapleCUN1 H432800910147FF -74.5
2020.02.28 15:43:38 4: CUL_Parse: mapleCUN1 **N0192C4986ADAAAAA0001A70F04
2020.02.28 15:43:38 4: CUL_Parse: mapleCUN1 H430B01980000FF -74.5
2020.02.28 15:43:42 4: CUL_Parse: mapleCUN1 **N0192C4986ADAAAAA0001F5B848
2020.02.28 15:43:42 4: CUL_Parse: mapleCUN1 H430B01980000FF -74.5
2020.02.28 15:43:42 4: CUL_Parse: mapleCUN1 N0299846613AD09100056C920D4
2020.02.28 15:43:42 3: mapleCUN1: Unknown code N0299846613AD09100056C920D4, help me!
2020.02.28 15:43:42 4: CUL_Parse: mapleCUN1 H432600660019FF -74.5
2020.02.28 15:43:43 4: CUL_Parse: mapleCUN1 N029A05912FAC00488000001014
2020.02.28 15:43:43 3: mapleCUN1: Unknown code N029A05912FAC00488000001014, help me!
2020.02.28 15:43:43 4: CUL_Parse: mapleCUN1 H432800910147FF -74.5
2020.02.28 15:43:43 4: CUL_Parse: mapleCUN1 N02938496332801000410000008
2020.02.28 15:43:43 3: mapleCUN1: Unknown code N02938496332801000410000008, help me!
2020.02.28 15:43:43 4: CUL_Parse: mapleCUN1 H430E00960051FF -74.5
2020.02.28 15:43:46 4: CUL_Parse: mapleCUN1 N029D06152F5400B10008000044
2020.02.28 15:43:46 3: mapleCUN1: Unknown code N029D06152F5400B10008000044, help me!
2020.02.28 15:43:46 4: CUL_Parse: mapleCUN1 H433400150247FF -74.5
2020.02.28 15:43:46 4: CUL_Parse: mapleCUN1 **N0192C4986ADAAAAA0001E3EBD8
2020.02.28 15:43:46 4: CUL_Parse: mapleCUN1 H430B01980000FF -74.5
2020.02.28 15:43:46 4: CUL_Parse: mapleCUN1 N0296C5963D16F0851C370A0100
2020.02.28 15:43:46 3: mapleCUN1: Unknown code N0296C5963D16F0851C370A0100, help me!
2020.02.28 15:43:46 4: CUL_Parse: mapleCUN1 H431B00960161FF -74.5
2020.02.28 15:43:47 4: CUL_Parse: mapleCUN1 N0298C175494000100011000001
2020.02.28 15:43:47 3: mapleCUN1: Unknown code N0298C175494000100011000001, help me!
2020.02.28 15:43:48 4: CUL_Parse: mapleCUN1 N029A05912FAC00000520000000
2020.02.28 15:43:48 3: mapleCUN1: Unknown code N029A05912FAC00000520000000, help me!
2020.02.28 15:43:48 4: CUL_Parse: mapleCUN1 H432800910147FF -74.5
2020.02.28 15:43:48 4: CUL_Parse: mapleCUN1 ***N0303040B9DB500FFFFFFFF85C2AAAAAA4646464603A8A3EE5F9C947C3FF7412626
2020.02.28 15:43:49 4: CUL_Parse: mapleCUN1 ***N0303040B9DB500FFFFFFFF85C2AAAAAA98989898F5F5E09975D2413539717FF36E
2020.02.28 15:43:49 4: CUL_Parse: mapleCUN1 ***N03010426E3B600FFFFFFFF64E8AAAAAA252525250BEA66B363AD82C1C2E627B703
2020.02.28 15:43:49 4: CUL_Parse: mapleCUN1 ***N03010426E3B600000002606982AABECA00000000000007B7C31FEB2AB24D04BDFB
2020.02.28 15:43:49 4: CUL_Parse: mapleCUN1 ***N03070406CF3300FFFFFFFF1217AAAAAA0000000000CBA4F1D50D9982D2C536BDC3
2020.02.28 15:43:50 4: CUL_Parse: mapleCUN1 ***N0308040EDDF300FFFFFFFF2108AAAAAA12121212027085208C66CB443B7B937792
2020.02.28 15:43:50 4: CUL_Parse: mapleCUN1 ***N0308040EDDF300FFFFFFFF2108AAAAAA121212120D472EFA98118818D09586019D
2020.02.28 15:43:50 4: CUL_Parse: mapleCUN1 ***N03080426D9FC00FFFFFFFF8DBBAAAAAA1212121208000800000078CBE09503D8C1
2020.02.28 15:43:51 4: CUL_Parse: mapleCUN1 ***N03080426D9FC00FFFFFFFF8DBBAAAAAA1212121204904A99FCB500000000000006
2020.02.28 15:43:51 4: CUL_Parse: mapleCUN1 ***N03080426D9FC00FFFFFFFF8DBBAAAAAA1212121200AFC61C5772559729E9EA0169
2020.02.28 15:43:51 4: CUL_Parse: mapleCUN1 ***N03080426D9FC00FFFFFFFF8DBBAAAAAA121212120D8C4B89DA0DBAA229ADAE1624
2020.02.28 15:43:51 4: CUL_Parse: mapleCUN1 ***N0303040D8AFA00FFFFFFFF5BEEAAAAAA1212121207D64F8C910619D273069FBFE3
2020.02.28 15:43:52 4: CUL_Parse: mapleCUN1 ***N0303040D8AFA00FFFFFFFF5BEEAAAAAA121212120FFCB3245C37CB96C40B08649B
2020.02.28 15:43:52 4: CUL_Parse: mapleCUN1 ***N03010426DADE00FFFFFFFF1E17AAAAAA1212121203A62C33C105300442C6189407
2020.02.28 15:43:52 4: CUL_Parse: mapleCUN1 N0299846613AD80000000014205
2020.02.28 15:43:52 3: mapleCUN1: Unknown code N0299846613AD80000000014205, help me!
2020.02.28 15:43:52 4: CUL_Parse: mapleCUN1 H432600660019FF -74.5
2020.02.28 15:43:52 4: CUL_Parse: mapleCUN1 ***N03080426D9AE00FFFFFFFFFDEDAAAAAA2A2A2A2A0EF091072DCCC59C9768FB1C34
2020.02.28 15:43:53 4: CUL_Parse: mapleCUN1 ***N03080426D9AE0100208163787CAAD9A9497CF81D2BEAA3363EC73F83FE9F0936D8
2020.02.28 15:43:53 4: CUL_Parse: mapleCUN1 ***N03070426D9C300FFFFFFFF0544AAAAAAB0B0B0B0F0DF4BD055750424F7CF3EEC4A
2020.02.28 15:43:53 4: CUL_Parse: mapleCUN1 N02938496332800000900000001
2020.02.28 15:43:53 3: mapleCUN1: Unknown code N02938496332800000900000001, help me!
2020.02.28 15:43:53 4: CUL_Parse: mapleCUN1 H430E00960051FF -74.5
2020.02.28 15:43:54 4: CUL_Parse: mapleCUN1 ***N0302040B9DB400FFFFFFFF9DD6AAAAAA48484848077D9AF09021E6197A2233BAF7
2020.02.28 15:43:54 4: CUL_Parse: mapleCUN1 ***N03050426D10C00FFFFFFFFE52FAAAAAA303030300F176D7D49B11544BBC30F4AA2
2020.02.28 15:43:54 4: CUL_Parse: mapleCUN1 ***N03050426D10C00FFFFFFFFE52FAAAAAA303030300005C574D5E84F53C5050AFFBF
2020.02.28 15:43:55 4: CUL_Parse: mapleCUN1 ***N03080404981000FFFFFFFF488AAAAAAA303030300B695C5815ACDFBC7C8C1CC8ED
2020.02.28 15:43:55 4: CUL_Parse: mapleCUN1 ***N03080404981000FFFFFFFF488AAAAAAA303030300E649C2FE2CFBF5B47D7F31CDD
2020.02.28 15:43:55 4: CUL_Parse: mapleCUN1 ***N0303040A1DB000FFFFFFFF85C2AAAAAA303030300F70ED0AA8984BBFF88BC4AC32
2020.02.28 15:43:55 4: CUL_Parse: mapleCUN1 ***N0303040A1DB000FFFFFFFF85C2AAAAAA3030303002D9B1F5D700002000000005F2
2020.02.28 15:43:56 4: CUL_Parse: mapleCUN1 ***N0303040A1DB000FFFFFFFF85C2AAAAAA303030300EE85BDC98DB1953801202B001
2020.02.28 15:43:56 4: CUL_Parse: mapleCUN1 N029D06152F54800214E0302252
2020.02.28 15:43:56 3: mapleCUN1: Unknown code N029D06152F54800214E0302252, help me!
2020.02.28 15:43:56 4: CUL_Parse: mapleCUN1 H433400150247FF -74.5
2020.02.28 15:43:56 4: CUL_Parse: mapleCUN1 N0296C5963D1680010000100020
2020.02.28 15:43:56 3: mapleCUN1: Unknown code N0296C5963D1680010000100020, help me!
2020.02.28 15:43:56 4: CUL_Parse: mapleCUN1 H431B00960161FF -74.5
2020.02.28 15:43:56 4: CUL_Parse: mapleCUN1 ***N0303040A1DB000FFFFFFFF85C2AAAAAA3030303005E40367A42C8A0E51DE8FAF3F
2020.02.28 15:43:57 4: CUL_Parse: mapleCUN1 ***N03080406DDF300FFFFFFFFA138AAAAAA303030300FBC40EC025D3A13ACF29DA56E
2020.02.28 15:43:57 4: CUL_Parse: mapleCUN1 ***N03080406DDF300000000002111AA4F6D45C1E3609D8EFAE80E73A7E4D69BFF9DD3
2020.02.28 15:43:57 4: CUL_Parse: mapleCUN1 N0298C175494000008000002000
2020.02.28 15:43:57 3: mapleCUN1: Unknown code N0298C175494000008000002000, help me!
2020.02.28 15:43:57 4: CUL_Parse: mapleCUN1 *omAAAA5555555550F9
2020.02.28 15:43:57 4: CUL_Parse: mapleCUN1 ***N0303040B8DB500FFFFFFFF14C1AAAAAA9C9C9C9C0B0D4FA9B2C3F63D96B45D70E0
2020.02.28 15:43:57 4: CUL_Parse: mapleCUN1 *omA5D289F804CC451C5C40F9
2020.02.28 15:43:57 4: CUL_Parse: mapleCUN1 ***N0303040B8DB500FFFFFFFF14C1AAAAAA9C9C9C9CFFDE78FBEBF03C7E5AF728973D
2020.02.28 15:43:58 4: CUL_Parse: mapleCUN1 N029A05922F81C1000200002000
2020.02.28 15:43:58 3: mapleCUN1: Unknown code N029A05922F81C1000200002000, help me!
2020.02.28 15:43:58 4: CUL_Parse: mapleCUN1 H432800920147FF -74.5
2020.02.28 15:43:58 4: CUL_Parse: mapleCUN1 ***N03080407829600FFFFFFFFF3ADAAAAAA9C9C9C9CF44E4360BE504B76FB53EEB0DA
2020.02.28 15:43:58 4: CUL_Parse: mapleCUN1 ***N03080407829600FFFFFFFFF3ADAAAAAA9C9C9C9C86B621B9EB6E267472927DD536
2020.02.28 15:43:58 4: CUL_Parse: mapleCUN1 ***N0303040D02FA00FFFFFFFFDB6EAAAAAA9C9C9C9CF27E257B013585FA99C7CE66FE
2020.02.28 15:43:59 4: CUL_Parse: mapleCUN1 ***N0303040D02FA00FFFFFFFFDB6EAAAAAA9C9C9C9CFD7E56043FF3D86CF4AF9DBF59
2020.02.28 15:43:59 4: CUL_Parse: mapleCUN1 ***N0303040D02FA00FFFFFFFFDB6EAAAAAA9C9C9C9C021E199F77963ED3C018FDC074
2020.02.28 15:43:59 4: CUL_Parse: mapleCUN1 ***N0303040D02FA00FFFFFFFFDB6EAAAAAA9C9C9C9CFE35F79EA88CFA4394443F5B45
2020.02.28 15:44:02 4: CUL_Parse: mapleCUN1 N0299846613AD8092938357D310
2020.02.28 15:44:02 3: mapleCUN1: Unknown code N0299846613AD8092938357D310, help me!
2020.02.28 15:44:02 4: CUL_Parse: mapleCUN1 H432600660019FF -74.5
2020.02.28 15:44:02 4: CUL_Parse: mapleCUN1 **N0192C4986ADAAAAA0001F8FF7C
2020.02.28 15:44:02 4: CUL_Parse: mapleCUN1 H430B01980000FF -74.5
2020.02.28 15:44:03 4: CUL_Parse: mapleCUN1 N029A05912FAC179FC36E608448
2020.02.28 15:44:03 3: mapleCUN1: Unknown code N029A05912FAC179FC36E608448, help me!
2020.02.28 15:44:03 4: CUL_Parse: mapleCUN1 H432800910147FF -74.5
2020.02.28 15:44:03 4: CUL_Parse: mapleCUN1 N02938496332808020120000002
2020.02.28 15:44:03 3: mapleCUN1: Unknown code N02938496332808020120000002, help me!
2020.02.28 15:44:03 4: CUL_Parse: mapleCUN1 H430E00960051FF -74.5
2020.02.28 15:44:06 4: CUL_Parse: mapleCUN1 N021804000F0080400400000000
2020.02.28 15:44:06 3: mapleCUN1: Unknown code N021804000F0080400400000000, help me!
2020.02.28 15:44:06 4: CUL_Parse: mapleCUN1 N0296C5963D1680000001180180
2020.02.28 15:44:06 3: mapleCUN1: Unknown code N0296C5963D1680000001180180, help me!
2020.02.28 15:44:06 4: CUL_Parse: mapleCUN1 H431B00960161FF -74.5
2020.02.28 15:44:07 4: CUL_Parse: mapleCUN1 N0298C175494000400000002000
2020.02.28 15:44:07 3: mapleCUN1: Unknown code N0298C175494000400000002000, help me!
2020.02.28 15:44:08 4: CUL_Parse: mapleCUN1 N029A05912FAC00001041002040
2020.02.28 15:44:08 3: mapleCUN1: Unknown code N029A05912FAC00001041002040, help me!
2020.02.28 15:44:08 4: CUL_Parse: mapleCUN1 H432800910147FF -74.5
2020.02.28 15:44:10 4: CUL_Parse: mapleCUN1 **N0192C4986ADAAAAA0001C2074D
2020.02.28 15:44:10 4: CUL_Parse: mapleCUN1 H430B01980000FF -74.5
2020.02.28 15:44:11 4: CUL_Parse: mapleCUN1 N029D06142FA03A0BCBD1A80D00
2020.02.28 15:44:11 3: mapleCUN1: Unknown code N029D06142FA03A0BCBD1A80D00, help me!
2020.02.28 15:44:11 4: CUL_Parse: mapleCUN1 H433400140247FF -74.5
2020.02.28 15:44:12 4: CUL_Parse: mapleCUN1 N02998467135900000080818000
2020.02.28 15:44:12 3: mapleCUN1: Unknown code N02998467135900000080818000, help me!
2020.02.28 15:44:12 4: CUL_Parse: mapleCUN1 H432600670019FF -74.5
2020.02.28 15:44:13 4: CUL_Parse: mapleCUN1 N029A05912FACD0000040001020
2020.02.28 15:44:13 3: mapleCUN1: Unknown code N029A05912FACD0000040001020, help me!
2020.02.28 15:44:13 4: CUL_Parse: mapleCUN1 H432800910147FF -74.5
2020.02.28 15:44:13 4: CUL_Parse: mapleCUN1 N02938496332800000000080208
2020.02.28 15:44:13 3: mapleCUN1: Unknown code N02938496332800000000080208, help me!
2020.02.28 15:44:13 4: CUL_Parse: mapleCUN1 H430E00960051FF -74.5
2020.02.28 15:44:15 4: CUL_Parse: mapleCUN1 **N0192C4916A19AAAA00015151A8
2020.02.28 15:44:15 4: CUL_Parse: mapleCUN1 H430B01910000FF -74.5
2020.02.28 15:44:16 4: CUL_Parse: mapleCUN1 N029D06152F544149A429030202
2020.02.28 15:44:16 3: mapleCUN1: Unknown code N029D06152F544149A429030202, help me!
2020.02.28 15:44:16 4: CUL_Parse: mapleCUN1 H433400150247FF -74.5
2020.02.28 15:44:16 4: CUL_Parse: mapleCUN1 N0296C5963D160200A400018000
2020.02.28 15:44:16 3: mapleCUN1: Unknown code N0296C5963D160200A400018000, help me!
2020.02.28 15:44:16 4: CUL_Parse: mapleCUN1 H431B00960161FF -74.5
2020.02.28 15:44:17 4: CUL_Parse: mapleCUN1 N0298C175494000000000002000
2020.02.28 15:44:17 3: mapleCUN1: Unknown code N0298C175494000000000002000, help me!
2020.02.28 15:44:17 4: CUL_Parse: mapleCUN1 N02998467135980024000240000
2020.02.28 15:44:17 3: mapleCUN1: Unknown code N02998467135980024000240000, help me!
2020.02.28 15:44:17 4: CUL_Parse: mapleCUN1 H432600670019FF -74.5
2020.02.28 15:44:19 4: CUL_Parse: mapleCUN1 **N0192C4986ADAAAAA00017FCB8B
2020.02.28 15:44:19 4: CUL_Parse: mapleCUN1 H430B01980000FF -74.5
2020.02.28 15:44:23 5: LaCrosseGateway: dispatch OK 9 52 1 4 191 47
2020.02.28 15:44:23 5: LaCrosseGateway: dispatch OK 9 38 1 4 43 19
2020.02.28 15:44:23 5: LaCrosseGateway: dispatch OK 9 53 1 4 186 49
2020.02.28 15:44:23 5: LaCrosseGateway: dispatch OK 9 40 1 4 168 47
2020.02.28 15:44:23 4: CUL_Parse: mapleCUN1 N029D06152F54C8248AAAE052B1
2020.02.28 15:44:23 3: mapleCUN1: Unknown code N029D06152F54C8248AAAE052B1, help me!
2020.02.28 15:44:23 4: CUL_Parse: mapleCUN1 H433400150247FF -74.5
2020.02.28 15:44:23 4: CUL_Parse: mapleCUN1 N0299846713590000100400A001
2020.02.28 15:44:23 3: mapleCUN1: Unknown code N0299846713590000100400A001, help me!
2020.02.28 15:44:23 4: CUL_Parse: mapleCUN1 H432600670019FF -74.5
2020.02.28 15:44:23 4: CUL_Parse: mapleCUN1 N029A05922F8180000000048000
2020.02.28 15:44:23 3: mapleCUN1: Unknown code N029A05922F8180000000048000, help me!
2020.02.28 15:44:23 4: CUL_Parse: mapleCUN1 H432800920147FF -74.5
2020.02.28 15:44:23 4: CUL_Parse: mapleCUN1 **N0192C4986ADAAAAA0000FE1C14
2020.02.28 15:44:23 4: CUL_Parse: mapleCUN1 H430B01980000FF -74.5
2020.02.28 15:44:23 4: CUL_Parse: mapleCUN1 N029384963328C8004491883612
2020.02.28 15:44:23 3: mapleCUN1: Unknown code N029384963328C8004491883612, help me!
2020.02.28 15:44:23 4: CUL_Parse: mapleCUN1 H430E00960051FF -74.5
2020.02.28 15:44:23 5: LaCrosseGateway: dispatch OK 9 14 1 4 72 51
2020.02.28 15:44:26 4: CUL_Parse: mapleCUN1 N029D06152F5444000000400088
2020.02.28 15:44:26 3: mapleCUN1: Unknown code N029D06152F5444000000400088, help me!
2020.02.28 15:44:26 4: CUL_Parse: mapleCUN1 H433400150247FF -74.5
2020.02.28 15:44:26 5: LaCrosseGateway: dispatch OK 9 52 1 4 191 47
2020.02.28 15:44:26 4: CUL_Parse: mapleCUN1 N0296C5963D1600001000800000
2020.02.28 15:44:26 3: mapleCUN1: Unknown code N0296C5963D1600001000800000, help me!
2020.02.28 15:44:26 4: CUL_Parse: mapleCUN1 H431B00960161FF -74.5
2020.02.28 15:44:26 5: LaCrosseGateway: dispatch OK 9 27 1 4 172 61
2020.02.28 15:44:27 4: CUL_Parse: mapleCUN1 **N0192C4986ADAAAAA000199AE3A
2020.02.28 15:44:27 4: CUL_Parse: mapleCUN1 H430B01980000FF -74.5
2020.02.28 15:44:27 5: LaCrosseGateway: dispatch OK VALUES LGW 3238236 UpTimeSeconds=252617,UpTimeText=2Tg. 22Std. 10Min. 17Sek. ,WIFI=xxxxxxxx,ReceivedFrames=203834,FramesPerMinute=52,RSSI=-72,FreeHeap=17968,LD.Min=0.13,LD.Avg=0.13,LD.Max=7.32,OLED=none
2020.02.28 15:44:27 4: CUL_Parse: mapleCUN1 N0298C175495217402128800508
2020.02.28 15:44:27 3: mapleCUN1: Unknown code N0298C175495217402128800508, help me!
2020.02.28 15:44:28 4: CUL_Parse: mapleCUN1 N029A05912FAC8000000000208A
2020.02.28 15:44:28 3: mapleCUN1: Unknown code N029A05912FAC8000000000208A, help me!
2020.02.28 15:44:28 4: CUL_Parse: mapleCUN1 H432800910147FF -74.5
2020.02.28 15:44:28 5: LaCrosseGateway: dispatch OK 9 40 1 4 167 47
2020.02.28 15:44:32 4: CUL_Parse: mapleCUN1 ***N03030426E3C600FFFFFFFFA4B7AAAAAA9C9C9C9CFAA0D7E285EFA956BD0ED25DF7
2020.02.28 15:44:32 4: CUL_Parse: mapleCUN1 ***N03030426E3C60000002915D2E0AAB72F84A4E8F94B597F5A651E1A6170F0800800
2020.02.28 15:44:32 4: CUL_Parse: mapleCUN1 N029984671359F476E410010000
2020.02.28 15:44:32 3: mapleCUN1: Unknown code N029984671359F476E410010000, help me!
2020.02.28 15:44:32 4: CUL_Parse: mapleCUN1 H432600670019FF -74.5
2020.02.28 15:44:32 5: LaCrosseGateway: dispatch OK 24 3 4 38 227 198 0 0 0 41 21
2020.02.28 15:44:32 5: LaCrosseGateway: dispatch OK 9 38 1 4 43 19
2020.02.28 15:44:32 5: LaCrosseGateway: dispatch OK 9 53 1 4 186 49
2020.02.28 15:44:33 4: CUL_Parse: mapleCUN1 N029A05922F81020A1080420182
2020.02.28 15:44:33 3: mapleCUN1: Unknown code N029A05922F81020A1080420182, help me!
2020.02.28 15:44:33 4: CUL_Parse: mapleCUN1 H432800920147FF -74.5
2020.02.28 15:44:33 5: LaCrosseGateway: dispatch OK 9 40 1 4 168 47
2020.02.28 15:44:33 4: CUL_Parse: mapleCUN1 N029384963328C0000002000000
2020.02.28 15:44:33 3: mapleCUN1: Unknown code N029384963328C0000002000000, help me!
2020.02.28 15:44:33 4: CUL_Parse: mapleCUN1 H430E00960051FF -74.5
2020.02.28 15:44:33 5: LaCrosseGateway: dispatch OK 9 14 1 4 72 51
2020.02.28 15:44:34 4: CUL_Parse: mapleCUN1 ***N03020406795A00FFFFFFFFF759AAAAAA12121212021BA7F674000000000000142F
2020.02.28 15:44:34 4: CUL_Parse: mapleCUN1 ***N03020406795A000000019CF23BAAE1BE0C90BFB6DE155AFC009D7773853589AD78
2020.02.28 15:44:34 5: LaCrosseGateway: dispatch OK 24 2 4 6 121 90 0 0 0 1 156
2020.02.28 15:44:35 4: CUL_Parse: mapleCUN1 **N0192C4986ADAAAAA00010ABABD
2020.02.28 15:44:35 4: CUL_Parse: mapleCUN1 H430B01980000FF -74.5
2020.02.28 15:44:35 4: CUL_Parse: mapleCUN1 ***N0304040384EC00FFFFFFFF0554AAAAAA2222222205AA4AAE622966AC968E86B9D2
2020.02.28 15:44:35 4: CUL_Parse: mapleCUN1 ***N0304040384EC00000002D68B89AA8B95A68F7DA28FEA84985F13AF5EAE9C6A5E2C
2020.02.28 15:44:36 5: LaCrosseGateway: dispatch OK 24 4 4 3 132 236 0 0 0 2 214
2020.02.28 15:44:36 4: CUL_Parse: mapleCUN1 N029D06152F54D02081424039A8
2020.02.28 15:44:36 3: mapleCUN1: Unknown code N029D06152F54D02081424039A8, help me!
2020.02.28 15:44:36 4: CUL_Parse: mapleCUN1 H433400150247FF -74.5
2020.02.28 15:44:36 5: LaCrosseGateway: dispatch OK 9 52 1 4 191 47
2020.02.28 15:44:36 4: CUL_Parse: mapleCUN1 N0296C5963D1600100014004401
2020.02.28 15:44:36 3: mapleCUN1: Unknown code N0296C5963D1600100014004401, help me!
2020.02.28 15:44:36 4: CUL_Parse: mapleCUN1 H431B00960161FF -74.5
2020.02.28 15:44:36 5: LaCrosseGateway: dispatch OK 9 27 1 4 172 61
2020.02.28 15:44:37 5: LaCrosseGateway: dispatch OK VALUES LGW 3238236 UpTimeSeconds=252627,UpTimeText=2Tg. 22Std. 10Min. 27Sek. ,WIFI=xxxxxxxx,ReceivedFrames=203844,FramesPerMinute=53,RSSI=-74,FreeHeap=17968,LD.Min=0.13,LD.Avg=0.13,LD.Max=30.65,OLED=none
2020.02.28 15:44:37 4: CUL_Parse: mapleCUN1 N0298C175494000080000000100
2020.02.28 15:44:37 3: mapleCUN1: Unknown code N0298C175494000080000000100, help me!
2020.02.28 15:44:38 4: CUL_Parse: mapleCUN1 ***N03050426D98C00FFFFFFFFED27AAAAAA141414140A29845EF05BCA6E3D8B7FBCE2
2020.02.28 15:44:38 4: CUL_Parse: mapleCUN1 N029A05922F8160000000004002
2020.02.28 15:44:38 3: mapleCUN1: Unknown code N029A05922F8160000000004002, help me!
2020.02.28 15:44:38 4: CUL_Parse: mapleCUN1 H432800920147FF -74.5
2020.02.28 15:44:38 5: LaCrosseGateway: dispatch OK 24 5 4 38 217 140 0 0 0 0 52
2020.02.28 15:44:38 5: LaCrosseGateway: dispatch OK 9 40 1 4 168 47
2020.02.28 15:44:38 4: CUL_Parse: mapleCUN1 ***N03010426E40500FFFFFFFFEB23AAAAAA0000000003C2FEE5A35187399FB3E40002
2020.02.28 15:44:38 4: CUL_Parse: mapleCUN1 ***N03010426E40500000000006B0AAA90DDAB15D8FE7B4DE155F5C240ABBD45B1DD0E
2020.02.28 15:44:38 5: LaCrosseGateway: dispatch OK 24 1 4 38 228 5 0 0 0 0 0
2020.02.28 15:44:39 4: CUL_Parse: mapleCUN1 ***N03080406B91000FFFFFFFF4B96AAAAAA02020202056ED455942D08D18B9F2D1C6F
2020.02.28 15:44:39 5: LaCrosseGateway: dispatch OK 24 8 4 6 185 16 0 0 0 0 195
2020.02.28 15:44:39 4: CUL_Parse: mapleCUN1 ***N03050426D9D500FFFFFFFF5578AAAAAA30303030007088805E84121623E0B02DFA
2020.02.28 15:44:39 5: LaCrosseGateway: dispatch OK 24 5 4 38 217 213 0 0 0 21 165
2020.02.28 15:44:40 4: CUL_Parse: mapleCUN1 *omAAAAAAAAAAAAAAAA80F9
2020.02.28 15:44:40 4: CUL_Parse: mapleCUN1 *omAAAAAAAAAAAAA0F8
2020.02.28 15:44:42 4: CUL_Parse: mapleCUN1 N0298C176494000000000008000
2020.02.28 15:44:42 3: mapleCUN1: Unknown code N0298C176494000000000008000, help me!
2020.02.28 15:44:42 4: CUL_Parse: mapleCUN1 N02998467135900000200000000
2020.02.28 15:44:42 3: mapleCUN1: Unknown code N02998467135900000200000000, help me!
2020.02.28 15:44:42 4: CUL_Parse: mapleCUN1 H432600670019FF -74.5
2020.02.28 15:44:42 5: LaCrosseGateway: dispatch OK 9 38 1 4 43 19
2020.02.28 15:44:42 5: LaCrosseGateway: dispatch OK 9 53 1 4 186 49
2020.02.28 15:44:43 4: CUL_Parse: mapleCUN1 N029A05922F8180046818480800
2020.02.28 15:44:43 3: mapleCUN1: Unknown code N029A05922F8180046818480800, help me!
2020.02.28 15:44:43 4: CUL_Parse: mapleCUN1 H432800920147FF -74.5
2020.02.28 15:44:43 5: LaCrosseGateway: dispatch OK 9 40 1 4 168 47
2020.02.28 15:44:43 4: CUL_Parse: mapleCUN1 N02938496332840000005042004
2020.02.28 15:44:43 3: mapleCUN1: Unknown code N02938496332840000005042004, help me!
2020.02.28 15:44:43 4: CUL_Parse: mapleCUN1 H430E00960051FF -74.5
2020.02.28 15:44:43 4: CUL_Parse: mapleCUN1 **N0192C4996A2EAAAA0001CB4F2B
2020.02.28 15:44:43 4: CUL_Parse: mapleCUN1 H430B01990000FF -74.5
2020.02.28 15:44:43 5: LaCrosseGateway: dispatch OK 9 14 1 4 72 51
2020.02.28 15:44:44 3: Lichtsensor brightness: 10560.8
2020.02.28 15:44:46 4: CUL_Parse: mapleCUN1 N029D06152F54C0810900014001
2020.02.28 15:44:46 3: mapleCUN1: Unknown code N029D06152F54C0810900014001, help me!
2020.02.28 15:44:46 4: CUL_Parse: mapleCUN1 H433400150247FF -74.5
2020.02.28 15:44:46 5: LaCrosseGateway: dispatch OK 9 52 1 4 191 47
2020.02.28 15:44:46 4: CUL_Parse: mapleCUN1 N0296C5963D1689200000000000
2020.02.28 15:44:46 3: mapleCUN1: Unknown code N0296C5963D1689200000000000, help me!
2020.02.28 15:44:46 4: CUL_Parse: mapleCUN1 H431B00960161FF -74.5
2020.02.28 15:44:46 5: LaCrosseGateway: dispatch OK 9 27 1 4 172 61
2020.02.28 15:44:47 5: LaCrosseGateway: dispatch OK VALUES LGW 3238236 UpTimeSeconds=252637,UpTimeText=2Tg. 22Std. 10Min. 37Sek. ,WIFI=xxxxxxxx,ReceivedFrames=203855,FramesPerMinute=57,RSSI=-72,FreeHeap=17968,LD.Min=0.13,LD.Avg=0.13,LD.Max=30.76,OLED=none
2020.02.28 15:44:47 4: CUL_Parse: mapleCUN1 N0298C176496000000000002000
2020.02.28 15:44:47 3: mapleCUN1: Unknown code N0298C176496000000000002000, help me!
2020.02.28 15:44:47 4: CUL_Parse: mapleCUN1 H432380240273FF -74.5
2020.02.28 15:44:47 4: CUL_Parse: mapleCUN1 **N0192C4986ADAAAAA0000AEFFDB
2020.02.28 15:44:47 4: CUL_Parse: mapleCUN1 H430B01980000FF -74.5
2020.02.28 15:44:48 4: CUL_Parse: mapleCUN1 N029A05922EB0D0C60002088119
2020.02.28 15:44:48 3: mapleCUN1: Unknown code N029A05922EB0D0C60002088119, help me!
2020.02.28 15:44:48 4: CUL_Parse: mapleCUN1 H432800920146FF -74.5
2020.02.28 15:44:48 5: LaCrosseGateway: dispatch OK 9 40 1 4 168 46
2020.02.28 15:44:51 4: CUL_Parse: mapleCUN1 **N0192C4986ADAAAAA00016A84BB
2020.02.28 15:44:51 4: CUL_Parse: mapleCUN1 H430B01980000FF -74.5
2020.02.28 15:44:52 4: CUL_Parse: mapleCUN1 N0298C1764958808A20880106E9
2020.02.28 15:44:52 3: mapleCUN1: Unknown code N0298C1764958808A20880106E9, help me!
2020.02.28 15:44:52 4: CUL_Parse: mapleCUN1 N02998467135980200900010002
2020.02.28 15:44:52 3: mapleCUN1: Unknown code N02998467135980200900010002, help me!
2020.02.28 15:44:52 4: CUL_Parse: mapleCUN1 H432600670019FF -74.5
2020.02.28 15:44:52 5: LaCrosseGateway: dispatch OK 9 38 1 4 43 19
2020.02.28 15:44:52 5: LaCrosseGateway: dispatch OK 9 53 1 4 186 49
2020.02.28 15:44:53 4: CUL_Parse: mapleCUN1 N029A05922F8100000000000000
2020.02.28 15:44:53 3: mapleCUN1: Unknown code N029A05922F8100000000000000, help me!
2020.02.28 15:44:53 4: CUL_Parse: mapleCUN1 H432800920147FF -74.5
2020.02.28 15:44:53 5: LaCrosseGateway: dispatch OK 9 40 1 4 168 47
2020.02.28 15:44:53 4: CUL_Parse: mapleCUN1 N02938496332800100000004000
2020.02.28 15:44:53 3: mapleCUN1: Unknown code N02938496332800100000004000, help me!
2020.02.28 15:44:53 4: CUL_Parse: mapleCUN1 H430E00960051FF -74.5
2020.02.28 15:44:53 5: LaCrosseGateway: dispatch OK 9 14 1 4 72 51
2020.02.28 15:44:55 4: CUL_Parse: mapleCUN1 **N0192C4986ADAAAAA0000E4E694
2020.02.28 15:44:55 4: CUL_Parse: mapleCUN1 H430B01980000FF -74.5
2020.02.28 15:44:56 4: CUL_Parse: mapleCUN1 N029D06152F5484791062004090
2020.02.28 15:44:56 3: mapleCUN1: Unknown code N029D06152F5484791062004090, help me!
2020.02.28 15:44:56 4: CUL_Parse: mapleCUN1 H433400150247FF -74.5
2020.02.28 15:44:56 5: LaCrosseGateway: dispatch OK 9 52 1 4 191 47
2020.02.28 15:44:56 4: CUL_Parse: mapleCUN1 N0296C5963D1601000000000800
2020.02.28 15:44:56 3: mapleCUN1: Unknown code N0296C5963D1601000000000800, help me!
2020.02.28 15:44:56 4: CUL_Parse: mapleCUN1 H431B00960161FF -74.5
2020.02.28 15:44:56 5: LaCrosseGateway: dispatch OK 9 27 1 4 172 61
2020.02.28 15:44:56 4: CUL_Parse: mapleCUN1 ***N030804078A9600FFFFFFFF7B2EAAAAAA000000000D08ABFB290CCE9B07FB8ECD6E
2020.02.28 15:44:56 5: LaCrosseGateway: dispatch OK 24 8 4 7 138 150 1 10 93 166 34
2020.02.28 15:44:57 5: LaCrosseGateway: dispatch OK VALUES LGW 3238236 UpTimeSeconds=252647,UpTimeText=2Tg. 22Std. 10Min. 47Sek. ,WIFI=xxxxxxxx,ReceivedFrames=203863,FramesPerMinute=53,RSSI=-74,FreeHeap=17968,LD.Min=0.13,LD.Avg=0.13,LD.Max=7.32,OLED=none
2020.02.28 15:44:58 4: CUL_Parse: mapleCUN1 N029A05922F8102000102000098
2020.02.28 15:44:58 3: mapleCUN1: Unknown code N029A05922F8102000102000098, help me!
2020.02.28 15:44:58 4: CUL_Parse: mapleCUN1 H432800920147FF -74.5
2020.02.28 15:44:58 5: LaCrosseGateway: dispatch OK 9 40 1 4 168 47
2020.02.28 15:45:02 4: CUL_Parse: mapleCUN1 ***N03050406977200FFFFFFFFF7FBAAAAAAF8F8F8F8FAFCEFDB538D1CDBC739C38F73
2020.02.28 15:45:02 4: CUL_Parse: mapleCUN1 ***N0305040697720000000052F63DAA7148EC598663069F6CEA5A7ACDBF9A3BB729BD
2020.02.28 15:45:02 5: LaCrosseGateway: dispatch OK 24 5 4 6 151 114 0 0 0 0 82
2020.02.28 15:45:02 4: CUL_Parse: mapleCUN1 N0298C176494000010800200001
2020.02.28 15:45:02 3: mapleCUN1: Unknown code N0298C176494000010800200001, help me!
2020.02.28 15:45:02 4: CUL_Parse: mapleCUN1 N02998467135900000000000008
2020.02.28 15:45:02 3: mapleCUN1: Unknown code N02998467135900000000000008, help me!
2020.02.28 15:45:02 4: CUL_Parse: mapleCUN1 H432600670019FF -74.5
2020.02.28 15:45:02 5: LaCrosseGateway: dispatch OK 9 38 1 4 43 19
2020.02.28 15:45:02 5: LaCrosseGateway: dispatch OK 9 53 1 4 186 49
2020.02.28 15:45:03 4: CUL_Parse: mapleCUN1 N029A05912E9D40000001400100
2020.02.28 15:45:03 3: mapleCUN1: Unknown code N029A05912E9D40000001400100, help me!
2020.02.28 15:45:03 4: CUL_Parse: mapleCUN1 H432800910146FF -74.5
2020.02.28 15:45:03 5: LaCrosseGateway: dispatch OK 9 40 1 4 167 46
2020.02.28 15:45:03 4: CUL_Parse: mapleCUN1 N029384963328A4200200441001
2020.02.28 15:45:03 3: mapleCUN1: Unknown code N029384963328A4200200441001, help me!
2020.02.28 15:45:03 4: CUL_Parse: mapleCUN1 H430E00960051FF -74.5
2020.02.28 15:45:03 5: LaCrosseGateway: dispatch OK 9 14 1 4 72 51
2020.02.28 15:45:04 4: CUL_Parse: mapleCUN1 **N0192C4996A2EAAAA0001050BC5
2020.02.28 15:45:04 4: CUL_Parse: mapleCUN1 H430B01990000FF -74.5
2020.02.28 15:45:06 4: CUL_Parse: mapleCUN1 N029D06152F5401220164010B09
2020.02.28 15:45:06 3: mapleCUN1: Unknown code N029D06152F5401220164010B09, help me!
2020.02.28 15:45:06 4: CUL_Parse: mapleCUN1 H433400150247FF -74.5
2020.02.28 15:45:06 5: LaCrosseGateway: dispatch OK 9 52 1 4 191 47
2020.02.28 15:45:06 4: CUL_Parse: mapleCUN1 N0296C5963D1600001010000800
2020.02.28 15:45:06 3: mapleCUN1: Unknown code N0296C5963D1600001010000800, help me!
2020.02.28 15:45:06 4: CUL_Parse: mapleCUN1 H431B00960161FF -74.5
2020.02.28 15:45:06 5: LaCrosseGateway: dispatch OK 9 27 1 4 172 61
2020.02.28 15:45:07 5: LaCrosseGateway: dispatch OK VALUES LGW 3238236 UpTimeSeconds=252657,UpTimeText=2Tg. 22Std. 10Min. 57Sek. ,WIFI=xxxxxxxx,ReceivedFrames=203871,FramesPerMinute=53,RSSI=-72,FreeHeap=17968,LD.Min=0.13,LD.Avg=0.13,LD.Max=30.72,OLED=none
2020.02.28 15:45:08 4: CUL_Parse: mapleCUN1 N029A05922EB080800004000020
2020.02.28 15:45:08 3: mapleCUN1: Unknown code N029A05922EB080800004000020, help me!
2020.02.28 15:45:08 4: CUL_Parse: mapleCUN1 H432800920146FF -74.5
2020.02.28 15:45:08 5: LaCrosseGateway: dispatch OK 9 40 1 4 168 46
2020.02.28 15:45:08 4: CUL_Parse: mapleCUN1 **N0192C4986ADAAAAA0001FEC6C3
2020.02.28 15:45:08 4: CUL_Parse: mapleCUN1 H430B01980000FF -74.5
2020.02.28 15:45:12 4: CUL_Parse: mapleCUN1 **N0192C4986ADAAAAA00008A99D5
2020.02.28 15:45:12 4: CUL_Parse: mapleCUN1 H430B01980000FF -74.5
2020.02.28 15:45:12 4: CUL_Parse: mapleCUN1 N0298C176496C800420489C99E4
2020.02.28 15:45:12 3: mapleCUN1: Unknown code N0298C176496C800420489C99E4, help me!
2020.02.28 15:45:12 4: CUL_Parse: mapleCUN1 N02998467135900002400069010
2020.02.28 15:45:12 3: mapleCUN1: Unknown code N02998467135900002400069010, help me!
2020.02.28 15:45:12 4: CUL_Parse: mapleCUN1 H432600670019FF -74.5
2020.02.28 15:45:12 5: LaCrosseGateway: dispatch OK 9 38 1 4 43 19
2020.02.28 15:45:12 5: LaCrosseGateway: dispatch OK 9 53 1 4 186 49
2020.02.28 15:45:13 5: LaCrosseGateway: dispatch OK 9 40 1 4 168 46
2020.02.28 15:45:13 4: CUL_Parse: mapleCUN1 N02938496332801600000001404
2020.02.28 15:45:13 3: mapleCUN1: Unknown code N02938496332801600000001404, help me!
2020.02.28 15:45:13 4: CUL_Parse: mapleCUN1 H430E00960051FF -74.5
2020.02.28 15:45:13 5: LaCrosseGateway: dispatch OK 9 14 1 4 72 51
2020.02.28 15:45:16 4: CUL_Parse: mapleCUN1 N029D06152F5480800000000200
2020.02.28 15:45:16 3: mapleCUN1: Unknown code N029D06152F5480800000000200, help me!
2020.02.28 15:45:16 4: CUL_Parse: mapleCUN1 H433400150247FF -74.5
2020.02.28 15:45:16 4: CUL_Parse: mapleCUN1 **N0192C4986ADAAAAA00017D77E7
2020.02.28 15:45:16 4: CUL_Parse: mapleCUN1 H430B01980000FF -74.5
2020.02.28 15:45:16 5: LaCrosseGateway: dispatch OK 9 52 1 4 191 47
2020.02.28 15:45:16 4: CUL_Parse: mapleCUN1 N0296C5963D1640010002101620
2020.02.28 15:45:16 3: mapleCUN1: Unknown code N0296C5963D1640010002101620, help me!
2020.02.28 15:45:16 4: CUL_Parse: mapleCUN1 H431B00960161FF -74.5
2020.02.28 15:45:16 5: LaCrosseGateway: dispatch OK 9 27 1 4 172 61
2020.02.28 15:45:17 5: LaCrosseGateway: dispatch OK VALUES LGW 3238236 UpTimeSeconds=252667,UpTimeText=2Tg. 22Std. 11Min. 7Sek. ,WIFI=xxxxxxxx,ReceivedFrames=203878,FramesPerMinute=52,RSSI=-73,FreeHeap=17968,LD.Min=0.13,LD.Avg=0.13,LD.Max=7.34,OLED=none
2020.02.28 15:45:18 4: CUL_Parse: mapleCUN1 N029A05912FAC00000101008000
2020.02.28 15:45:18 3: mapleCUN1: Unknown code N029A05912FAC00000101008000, help me!
2020.02.28 15:45:18 4: CUL_Parse: mapleCUN1 H432800910147FF -74.5
2020.02.28 15:45:18 5: LaCrosseGateway: dispatch OK 9 40 1 4 167 47
2020.02.28 15:45:18 4: CUL_Parse: mapleCUN1 N02938495330500000000000000
2020.02.28 15:45:18 3: mapleCUN1: Unknown code N02938495330500000000000000, help me!
2020.02.28 15:45:18 4: CUL_Parse: mapleCUN1 H430E00950051FF -74.5
2020.02.28 15:45:18 5: LaCrosseGateway: dispatch OK 9 14 1 4 71 51
2020.02.28 15:45:19 4: CUL_Parse: mapleCUN1 ***N0303040B9DB500FFFFFFFF85C2AAAAAA0808080805D0B75116D4FAF276AD31BFEF
2020.02.28 15:45:19 4: CUL_Parse: mapleCUN1 ***N0303040B9DB500FFFFFFFF85C2AAAAAA0808080803F6BE07AB743FCB92853FBEA1
2020.02.28 15:45:19 4: CUL_Parse: mapleCUN1 ***N03010426E3B600FFFFFFFF64E8AAAAAA0808080806CFDE7697EABFF91B98B58B6A
2020.02.28 15:45:19 4: CUL_Parse: mapleCUN1 ***N03010426E3B600000002606982AAFFA49E98D1F4B090540000010A0349873FD798
2020.02.28 15:45:19 5: LaCrosseGateway: dispatch OK 24 1 4 38 227 182 0 0 0 2 96
2020.02.28 15:45:20 4: CUL_Parse: mapleCUN1 ***N03070406CF3300FFFFFFFF1217AAAAAA0000000009618A7E8446547D7C26DC0D37
2020.02.28 15:45:20 5: LaCrosseGateway: dispatch OK 24 7 4 6 207 51 0 0 0 0 27
2020.02.28 15:45:20 4: CUL_Parse: mapleCUN1 ***N0308040EDDF300FFFFFFFF2108AAAAAAD2D2D2D2F1458F80165BC71B0BB212E974
2020.02.28 15:45:21 4: CUL_Parse: mapleCUN1 ***N0308040EDDF300FFFFFFFF2108AAAAAAD2D2D2D2FEFF670293CEC3E7397B530CF2
2020.02.28 15:45:21 4: CUL_Parse: mapleCUN1 N029D06142FA080040100800080
2020.02.28 15:45:21 3: mapleCUN1: Unknown code N029D06142FA080040100800080, help me!
2020.02.28 15:45:21 4: CUL_Parse: mapleCUN1 H433400140247FF -74.5
2020.02.28 15:45:21 5: LaCrosseGateway: dispatch OK 9 52 1 4 190 47
2020.02.28 15:45:21 4: CUL_Parse: mapleCUN1 ***N03080426D9FC00FFFFFFFF8DBBAAAAAAD2D2D2D2F0EFDDF60E30F31E58FB9AF737
2020.02.28 15:45:21 4: CUL_Parse: mapleCUN1 ***N03080426D9FC00FFFFFFFF8DBBAAAAAAD2D2D2D2FAF115730FFB38BFB10D611468
2020.02.28 15:45:21 4: CUL_Parse: mapleCUN1 ***N03080426D9FC00FFFFFFFF8DBBAAAAAAD2D2D2D2F5E8B77A98051E39B18AA58C51
2020.02.28 15:45:22 4: CUL_Parse: mapleCUN1 ***N03080426D9FC00FFFFFFFF8DBBAAAAAAD2D2D2D2FEE747C1AB7C5115B516E4C9FA
2020.02.28 15:45:22 4: CUL_Parse: mapleCUN1 ***N0303040D8AFA00FFFFFFFF5BEEAAAAAAD2D2D2D2FAF198FCD85F665F36BFB53E3A
2020.02.28 15:45:22 4: CUL_Parse: mapleCUN1 N02998467135981000000000008
2020.02.28 15:45:22 3: mapleCUN1: Unknown code N02998467135981000000000008, help me!
2020.02.28 15:45:22 4: CUL_Parse: mapleCUN1 H432600670019FF -74.5
2020.02.28 15:45:22 5: LaCrosseGateway: dispatch OK 9 38 1 4 43 19
2020.02.28 15:45:22 4: CUL_Parse: mapleCUN1 ***N0303040D8AFA00FFFFFFFF5BEEAAAAAA202020200E4A8EED040D8CBEDEB1EB392A
2020.02.28 15:45:22 4: CUL_Parse: mapleCUN1 ***N03010426DADE00FFFFFFFF1E17AAAAAA2020202009EE251C66314F57C377605E25
2020.02.28 15:45:23 5: LaCrosseGateway: dispatch OK 24 1 4 38 218 222 0 0 0 35 218
2020.02.28 15:45:23 4: CUL_Parse: mapleCUN1 N029A05912FAC00000008000104
2020.02.28 15:45:23 3: mapleCUN1: Unknown code N029A05912FAC00000008000104, help me!
2020.02.28 15:45:23 4: CUL_Parse: mapleCUN1 H432800910147FF -74.5
2020.02.28 15:45:23 5: LaCrosseGateway: dispatch OK 9 40 1 4 167 47
2020.02.28 15:45:23 4: CUL_Parse: mapleCUN1 ***N03080426D9AE00FFFFFFFFFDEDAAAAAA03030303F598A4B38EFEEEDE75AE466742
2020.02.28 15:45:23 4: CUL_Parse: mapleCUN1 ***N03080426D9AE0100208163787CAAA7B5AD18D5DEC50D29D8FE787D281FB5DBB3FC
2020.02.28 15:45:23 5: LaCrosseGateway: dispatch OK 24 8 4 38 217 174 1 0 32 129 99
2020.02.28 15:45:23 4: CUL_Parse: mapleCUN1 N02938495330500200011504000
2020.02.28 15:45:23 3: mapleCUN1: Unknown code N02938495330500200011504000, help me!
2020.02.28 15:45:23 4: CUL_Parse: mapleCUN1 H430E00950051FF -74.5
2020.02.28 15:45:23 5: LaCrosseGateway: dispatch OK 9 14 1 4 71 51
2020.02.28 15:45:23 4: CUL_Parse: mapleCUN1 *om96A95555555D5568F9
2020.02.28 15:45:23 4: CUL_Parse: mapleCUN1 *omAAAAAAAAAAAAAAAA80FE
2020.02.28 15:45:23 4: CUL_Parse: mapleCUN1 *omAA57232AAAD550F9
2020.02.28 15:45:23 4: CUL_Parse: mapleCUN1 ***N03070426D9C300FFFFFFFF0544AAAAAA1010101001CF56C7681F24916741446D0A
2020.02.28 15:45:24 5: LaCrosseGateway: dispatch OK 24 7 4 38 217 195 1 0 121 75 241
2020.02.28 15:45:24 4: CUL_Parse: mapleCUN1 **N0192C4996A2EAAAA00017B45DB
2020.02.28 15:45:24 4: CUL_Parse: mapleCUN1 H430B01990000FF -74.5
2020.02.28 15:45:24 4: CUL_Parse: mapleCUN1 ***N0302040B9DB400FFFFFFFF9DD6AAAAAA0505050502F21C9EABEAF8A4CD39810E37
2020.02.28 15:45:24 5: LaCrosseGateway: dispatch OK 24 2 4 11 157 180 1 0 8 0 0
2020.02.28 15:45:25 4: CUL_Parse: mapleCUN1 ***N03050426D10C00FFFFFFFFE52FAAAAAA606060600ADC935CE9916549D53FFAD5EB
2020.02.28 15:45:25 4: CUL_Parse: mapleCUN1 ***N03050426D10C00FFFFFFFFE52FAAAAAA6060606002EAC7E81AD05130102117C14A
2020.02.28 15:45:25 4: CUL_Parse: mapleCUN1 ***N03080404981000FFFFFFFF488AAAAAAA6060606007FE1400000000000000000348
2020.02.28 15:45:25 4: CUL_Parse: mapleCUN1 ***N03080404981000FFFFFFFF488AAAAAAA606060600BB028960729F2B59AAD486B6A
2020.02.28 15:45:26 4: CUL_Parse: mapleCUN1 ***N0303040A1DB000FFFFFFFF85C2AAAAAA60606060047C7555E495EABCE69CC2CEF7
2020.02.28 15:45:26 4: CUL_Parse: mapleCUN1 N029D06152F540140B6074F5802
2020.02.28 15:45:26 3: mapleCUN1: Unknown code N029D06152F540140B6074F5802, help me!
2020.02.28 15:45:26 4: CUL_Parse: mapleCUN1 H433400150247FF -74.5
2020.02.28 15:45:26 5: LaCrosseGateway: dispatch OK 9 52 1 4 191 47
2020.02.28 15:45:26 4: CUL_Parse: mapleCUN1 ***N0303040A1DB000FFFFFFFF85C2AAAAAA6060606000840E4323EB6945D4F4F6BCCD
2020.02.28 15:45:26 4: CUL_Parse: mapleCUN1 N0296C5963D1680280000000420
2020.02.28 15:45:26 3: mapleCUN1: Unknown code N0296C5963D1680280000000420, help me!
2020.02.28 15:45:26 4: CUL_Parse: mapleCUN1 H431B00960161FF -74.5
2020.02.28 15:45:26 5: LaCrosseGateway: dispatch OK 9 27 1 4 172 61
2020.02.28 15:45:26 4: CUL_Parse: mapleCUN1 ***N0303040A1DB000FFFFFFFF85C2AAAAAA60606060076B0854F502918CEBAF8D5C00
2020.02.28 15:45:26 4: CUL_Parse: mapleCUN1 ***N0303040A1DB000FFFFFFFF85C2AAAAAA606060600BC4277EB5F7BE047538862AC6
2020.02.28 15:45:27 5: LaCrosseGateway: dispatch OK VALUES LGW 3238236 UpTimeSeconds=252677,UpTimeText=2Tg. 22Std. 11Min. 17Sek. ,WIFI=xxxxxxxx,ReceivedFrames=203892,FramesPerMinute=58,RSSI=-73,FreeHeap=17968,LD.Min=0.13,LD.Avg=0.14,LD.Max=32.10,OLED=none
2020.02.28 15:45:27 4: CUL_Parse: mapleCUN1 ***N03080406DDF300FFFFFFFFA138AAAAAA606060600244766BFEC76F651EADEE1723
2020.02.28 15:45:27 4: CUL_Parse: mapleCUN1 ***N03080406DDF300000000002111AAC1F9ABEABBBB4CE32505679449FC46BECC1679
2020.02.28 15:45:27 5: LaCrosseGateway: dispatch OK 24 8 4 6 221 243 0 0 0 0 0
2020.02.28 15:45:28 4: CUL_Parse: mapleCUN1 N029A05922F8180040004000101
2020.02.28 15:45:28 3: mapleCUN1: Unknown code N029A05922F8180040004000101, help me!
2020.02.28 15:45:28 4: CUL_Parse: mapleCUN1 H432800920147FF -74.5
2020.02.28 15:45:28 5: LaCrosseGateway: dispatch OK 9 40 1 4 168 47
2020.02.28 15:45:28 4: CUL_Parse: mapleCUN1 ***N0303040B8DB500FFFFFFFF14C1AAAAAA4040404009DDFFEF18DAB05F2FB24F32A8
2020.02.28 15:45:28 4: CUL_Parse: mapleCUN1 ***N0303040B8DB500FFFFFFFF14C1AAAAAA404040400E48D7BEB99708DDADDDCEB941
2020.02.28 15:45:28 4: CUL_Parse: mapleCUN1 **N0192C4996A2EAAAA00002B0EC5
2020.02.28 15:45:28 4: CUL_Parse: mapleCUN1 H430B01990000FF -74.5
2020.02.28 15:45:28 4: CUL_Parse: mapleCUN1 N02938495330518100422080C02
2020.02.28 15:45:28 3: mapleCUN1: Unknown code N02938495330518100422080C02, help me!
2020.02.28 15:45:28 4: CUL_Parse: mapleCUN1 H430E00950051FF -74.5
2020.02.28 15:45:28 5: LaCrosseGateway: dispatch OK 9 14 1 4 71 51
2020.02.28 15:45:28 4: CUL_Parse: mapleCUN1 ***N03080407829600FFFFFFFFF3ADAAAAAA4040404012BBFBCD2E9C2C59FE665DBFCC
2020.02.28 15:45:28 4: CUL_Parse: mapleCUN1 ***N03080407829600FFFFFFFFF3ADAAAAAA40404040003CBDE9DBB56FA7E3C9C5988D
2020.02.28 15:45:29 4: CUL_Parse: mapleCUN1 ***N0303040D02FA00FFFFFFFFDB6EAAAAAA4040404002202C1A64060FEE8D90A33323
2020.02.28 15:45:29 4: CUL_Parse: mapleCUN1 ***N0303040D02FA00FFFFFFFFDB6EAAAAAA404040400ED2C925228FCE882F3EF8115F
2020.02.28 15:45:29 4: CUL_Parse: mapleCUN1 ***N0303040D02FA00FFFFFFFFDB6EAAAAAA4040404008D4F3562E2BD14F45FEACEB7B
2020.02.28 15:45:30 4: CUL_Parse: mapleCUN1 ***N0303040D02FA00FFFFFFFFDB6EAAAAAA40404040016019B8E5D84900056007042F
2020.02.28 15:45:31 4: CUL_Parse: mapleCUN1 N029D06152F54C1002000000000
2020.02.28 15:45:31 3: mapleCUN1: Unknown code N029D06152F54C1002000000000, help me!
2020.02.28 15:45:31 4: CUL_Parse: mapleCUN1 H433400150247FF -74.5
2020.02.28 15:45:31 5: LaCrosseGateway: dispatch OK 9 52 1 4 191 47
2020.02.28 15:45:32 4: CUL_Parse: mapleCUN1 N0298C1764944D0000000000000
2020.02.28 15:45:32 3: mapleCUN1: Unknown code N0298C1764944D0000000000000, help me!
2020.02.28 15:45:32 4: CUL_Parse: mapleCUN1 N02998467135900000000000000
2020.02.28 15:45:32 3: mapleCUN1: Unknown code N02998467135900000000000000, help me!
2020.02.28 15:45:32 4: CUL_Parse: mapleCUN1 H432600670019FF -74.5
2020.02.28 15:45:32 5: LaCrosseGateway: dispatch OK 9 38 1 4 43 19
2020.02.28 15:45:32 4: CUL_Parse: mapleCUN1 **N0192C4996A2EAAAA0001011A00
2020.02.28 15:45:32 4: CUL_Parse: mapleCUN1 H430B01990000FF -74.5
2020.02.28 15:45:32 5: LaCrosseGateway: dispatch OK 9 53 1 4 186 49
2020.02.28 15:45:33 4: CUL_Parse: mapleCUN1 N029A05912FAC020021482050A3
2020.02.28 15:45:33 3: mapleCUN1: Unknown code N029A05912FAC020021482050A3, help me!
2020.02.28 15:45:33 4: CUL_Parse: mapleCUN1 H432800910147FF -74.5
2020.02.28 15:45:33 5: LaCrosseGateway: dispatch OK 9 40 1 4 167 47
2020.02.28 15:45:33 4: CUL_Parse: mapleCUN1 N02938496332800860002080008
2020.02.28 15:45:33 3: mapleCUN1: Unknown code N02938496332800860002080008, help me!
2020.02.28 15:45:33 4: CUL_Parse: mapleCUN1 H430E00960051FF -74.5
2020.02.28 15:45:33 5: LaCrosseGateway: dispatch OK 9 14 1 4 72 51
2020.02.28 15:45:36 4: CUL_Parse: mapleCUN1 N029D06142FA048008000000040
2020.02.28 15:45:36 3: mapleCUN1: Unknown code N029D06142FA048008000000040, help me!
2020.02.28 15:45:36 4: CUL_Parse: mapleCUN1 H433400140247FF -74.5
2020.02.28 15:45:36 5: LaCrosseGateway: dispatch OK 9 52 1 4 190 47
2020.02.28 15:45:36 4: CUL_Parse: mapleCUN1 N0296C5963D160C010000000002
2020.02.28 15:45:36 3: mapleCUN1: Unknown code N0296C5963D160C010000000002, help me!
2020.02.28 15:45:36 4: CUL_Parse: mapleCUN1 H431B00960161FF -74.5
2020.02.28 15:45:36 5: LaCrosseGateway: dispatch OK 9 27 1 4 172 61
2020.02.28 15:45:36 3: Events from device BM_HM_AZ_:battery: ok,CMDs_done
2020.02.28 15:45:37 3: Events from device BM_HM_Az:brightness: 110,motion
2020.02.28 15:45:37 5: LaCrosseGateway: dispatch OK VALUES LGW 3238236 UpTimeSeconds=252687,UpTimeText=2Tg. 22Std. 11Min. 27Sek. ,WIFI=xxxxxxxx,ReceivedFrames=203902,FramesPerMinute=58,RSSI=-74,FreeHeap=17968,LD.Min=0.12,LD.Avg=0.14,LD.Max=30.97,OLED=none
2020.02.28 15:45:38 4: CUL_Parse: mapleCUN1 N029A05922F8180008860000000
2020.02.28 15:45:38 3: mapleCUN1: Unknown code N029A05922F8180008860000000, help me!
2020.02.28 15:45:38 4: CUL_Parse: mapleCUN1 H432800920147FF -74.5
2020.02.28 15:45:38 5: LaCrosseGateway: dispatch OK 9 40 1 4 168 47
2020.02.28 15:45:38 4: CUL_Parse: mapleCUN1 N02938495330590100101400000
2020.02.28 15:45:38 3: mapleCUN1: Unknown code N02938495330590100101400000, help me!
2020.02.28 15:45:38 4: CUL_Parse: mapleCUN1 H430E00950051FF -74.5
2020.02.28 15:45:38 5: LaCrosseGateway: dispatch OK 9 14 1 4 71 51
2020.02.28 15:45:40 4: CUL_Parse: mapleCUN1 **N0192C4996A2EAAAA0000BF97C1
2020.02.28 15:45:40 4: CUL_Parse: mapleCUN1 H430B01990000FF -74.5
2020.02.28 15:45:41 4: CUL_Parse: mapleCUN1 N029D06142FA04000203533ACF9
2020.02.28 15:45:41 3: mapleCUN1: Unknown code N029D06142FA04000203533ACF9, help me!
2020.02.28 15:45:41 4: CUL_Parse: mapleCUN1 H433400140247FF -74.5
2020.02.28 15:45:41 5: LaCrosseGateway: dispatch OK 9 52 1 4 190 47
2020.02.28 15:45:42 4: CUL_Parse: mapleCUN1 N0298C176494101001000000000
2020.02.28 15:45:42 3: mapleCUN1: Unknown code N0298C176494101001000000000, help me!
2020.02.28 15:45:42 4: CUL_Parse: mapleCUN1 N02998467135900000000000022
2020.02.28 15:45:42 3: mapleCUN1: Unknown code N02998467135900000000000022, help me!
2020.02.28 15:45:42 4: CUL_Parse: mapleCUN1 H432600670019FF -74.5
2020.02.28 15:45:42 5: LaCrosseGateway: dispatch OK 9 38 1 4 43 19
2020.02.28 15:45:42 5: LaCrosseGateway: dispatch OK 9 53 1 4 186 49
2020.02.28 15:45:43 4: CUL_Parse: mapleCUN1 N029A05922F8180000001000000
2020.02.28 15:45:43 3: mapleCUN1: Unknown code N029A05922F8180000001000000, help me!
2020.02.28 15:45:43 4: CUL_Parse: mapleCUN1 H432800920147FF -74.5
2020.02.28 15:45:43 5: LaCrosseGateway: dispatch OK 9 40 1 4 168 47
2020.02.28 15:45:43 4: CUL_Parse: mapleCUN1 N02938496332800010100200000
2020.02.28 15:45:43 3: mapleCUN1: Unknown code N02938496332800010100200000, help me!
2020.02.28 15:45:43 4: CUL_Parse: mapleCUN1 H430E00960051FF -74.5
2020.02.28 15:45:43 5: LaCrosseGateway: dispatch OK 9 14 1 4 72 51
2020.02.28 15:45:46 4: CUL_Parse: mapleCUN1 N029D06152F54E0480000010000
2020.02.28 15:45:46 3: mapleCUN1: Unknown code N029D06152F54E0480000010000, help me!
2020.02.28 15:45:46 4: CUL_Parse: mapleCUN1 H433400150247FF -74.5
2020.02.28 15:45:46 5: LaCrosseGateway: dispatch OK 9 52 1 4 191 47
2020.02.28 15:45:46 4: CUL_Parse: mapleCUN1 N0296C5963D1640200004000000
2020.02.28 15:45:46 3: mapleCUN1: Unknown code N0296C5963D1640200004000000, help me!
2020.02.28 15:45:46 4: CUL_Parse: mapleCUN1 H431B00960161FF -74.5
2020.02.28 15:45:46 5: LaCrosseGateway: dispatch OK 9 27 1 4 172 61
2020.02.28 15:45:47 5: LaCrosseGateway: dispatch OK VALUES LGW 3238236 UpTimeSeconds=252697,UpTimeText=2Tg. 22Std. 11Min. 37Sek. ,WIFI=xxxxxxxx,ReceivedFrames=203911,FramesPerMinute=56,RSSI=-74,FreeHeap=17968,LD.Min=0.13,LD.Avg=0.13,LD.Max=7.34,OLED=none
2020.02.28 15:45:48 4: CUL_Parse: mapleCUN1 N029A05922F8180030000A20002
2020.02.28 15:45:48 3: mapleCUN1: Unknown code N029A05922F8180030000A20002, help me!
2020.02.28 15:45:48 4: CUL_Parse: mapleCUN1 H432800920147FF -74.5
2020.02.28 15:45:48 5: LaCrosseGateway: dispatch OK 9 40 1 4 168 47
2020.02.28 15:45:48 4: CUL_Parse: mapleCUN1 N02938495330582000000000000
2020.02.28 15:45:48 3: mapleCUN1: Unknown code N02938495330582000000000000, help me!
2020.02.28 15:45:48 4: CUL_Parse: mapleCUN1 H430E00950051FF -74.5
2020.02.28 15:45:48 5: LaCrosseGateway: dispatch OK 9 14 1 4 71 51
2020.02.28 15:45:48 4: CUL_Parse: mapleCUN1 **N0192C4996A2EAAAA0001E7E5F0
2020.02.28 15:45:49 4: CUL_Parse: mapleCUN1 H430B01990000FF -74.5
2020.02.28 15:45:51 4: CUL_Parse: mapleCUN1 N029D06152F54000000060004A0
2020.02.28 15:45:51 3: mapleCUN1: Unknown code N029D06152F54000000060004A0, help me!
2020.02.28 15:45:51 4: CUL_Parse: mapleCUN1 H433400150247FF -74.5
2020.02.28 15:45:51 5: LaCrosseGateway: dispatch OK 9 52 1 4 191 47
2020.02.28 15:45:52 4: CUL_Parse: mapleCUN1 N0298C176494000000000000000
2020.02.28 15:45:52 3: mapleCUN1: Unknown code N0298C176494000000000000000, help me!
2020.02.28 15:45:52 4: CUL_Parse: mapleCUN1 N02998467135904040000000010
2020.02.28 15:45:52 3: mapleCUN1: Unknown code N02998467135904040000000010, help me!
2020.02.28 15:45:52 4: CUL_Parse: mapleCUN1 H432600670019FF -74.5
2020.02.28 15:45:52 5: LaCrosseGateway: dispatch OK 9 38 1 4 43 19
2020.02.28 15:45:52 5: LaCrosseGateway: dispatch OK 9 53 1 4 186 49
2020.02.28 15:45:53 4: CUL_Parse: mapleCUN1 N029A05912FAC80000000000200
2020.02.28 15:45:53 3: mapleCUN1: Unknown code N029A05912FAC80000000000200, help me!
2020.02.28 15:45:53 4: CUL_Parse: mapleCUN1 H432800910147FF -74.5
2020.02.28 15:45:53 5: LaCrosseGateway: dispatch OK 9 40 1 4 167 47
2020.02.28 15:45:53 4: CUL_Parse: mapleCUN1 N02938495330512000100020000
2020.02.28 15:45:53 3: mapleCUN1: Unknown code N02938495330512000100020000, help me!
2020.02.28 15:45:53 4: CUL_Parse: mapleCUN1 H430E00950051FF -74.5
2020.02.28 15:45:53 5: LaCrosseGateway: dispatch OK 9 14 1 4 71 51
2020.02.28 15:45:56 4: CUL_Parse: mapleCUN1 N029D06142FA000102084050480
2020.02.28 15:45:56 3: mapleCUN1: Unknown code N029D06142FA000102084050480, help me!
2020.02.28 15:45:56 4: CUL_Parse: mapleCUN1 H433400140247FF -74.5
2020.02.28 15:45:56 5: LaCrosseGateway: dispatch OK 9 52 1 4 190 47
2020.02.28 15:45:56 4: CUL_Parse: mapleCUN1 N0296C5963D1640420000101014
2020.02.28 15:45:56 3: mapleCUN1: Unknown code N0296C5963D1640420000101014, help me!
2020.02.28 15:45:56 4: CUL_Parse: mapleCUN1 H431B00960161FF -74.5
2020.02.28 15:45:56 5: LaCrosseGateway: dispatch OK 9 27 1 4 172 61
2020.02.28 15:45:57 4: CUL_Parse: mapleCUN1 **N0192C4996A2EAAAA00016E95EF
2020.02.28 15:45:57 4: CUL_Parse: mapleCUN1 H430B01990000FF -74.5
2020.02.28 15:45:57 5: LaCrosseGateway: dispatch OK VALUES LGW 3238236 UpTimeSeconds=252707,UpTimeText=2Tg. 22Std. 11Min. 47Sek. ,WIFI=xxxxxxxx,ReceivedFrames=203920,FramesPerMinute=57,RSSI=-75,FreeHeap=17968,LD.Min=0.13,LD.Avg=0.13,LD.Max=7.28,OLED=none
2020.02.28 15:45:58 4: CUL_Parse: mapleCUN1 N029A05922F8171823080800804
2020.02.28 15:45:58 3: mapleCUN1: Unknown code N029A05922F8171823080800804, help me!
2020.02.28 15:45:58 4: CUL_Parse: mapleCUN1 H432800920147FF -74.5
2020.02.28 15:45:58 5: LaCrosseGateway: dispatch OK 9 40 1 4 168 47
2020.02.28 15:45:58 4: CUL_Parse: mapleCUN1 N02938495330501080004810004
2020.02.28 15:45:58 3: mapleCUN1: Unknown code N02938495330501080004810004, help me!
2020.02.28 15:45:58 4: CUL_Parse: mapleCUN1 H430E00950051FF -74.5
2020.02.28 15:45:58 5: LaCrosseGateway: dispatch OK 9 14 1 4 71 51
2020.02.28 15:46:01 4: CUL_Parse: mapleCUN1 N029D06152F5400000000000080
2020.02.28 15:46:01 3: mapleCUN1: Unknown code N029D06152F5400000000000080, help me!
2020.02.28 15:46:01 4: CUL_Parse: mapleCUN1 H433400150247FF -74.5
2020.02.28 15:46:01 5: LaCrosseGateway: dispatch OK 9 52 1 4 191 47
2020.02.28 15:46:02 4: CUL_Parse: mapleCUN1 N0298C176495800040080000020
2020.02.28 15:46:02 3: mapleCUN1: Unknown code N0298C176495800040080000020, help me!
2020.02.28 15:46:02 4: CUL_Parse: mapleCUN1 N0299846813C080000000000000
2020.02.28 15:46:02 3: mapleCUN1: Unknown code N0299846813C080000000000000, help me!
2020.02.28 15:46:02 4: CUL_Parse: mapleCUN1 H432600680019FF -74.5
2020.02.28 15:46:02 5: LaCrosseGateway: dispatch OK 9 38 1 4 44 19
2020.02.28 15:46:02 5: LaCrosseGateway: dispatch OK 9 53 1 4 186 49
2020.02.28 15:46:02 4: CUL_Parse: mapleCUN1 ***N03030426E3C600FFFFFFFFA4B7AAAAAA4040404000000000079F9B4BFF676F5D1B
2020.02.28 15:46:02 4: CUL_Parse: mapleCUN1 ***N03030426E3C60000002915D2E0AAD3F915B1BC958DC2F42EAC5E302A924FF2015B
2020.02.28 15:46:02 5: LaCrosseGateway: dispatch OK 24 3 4 38 227 198 0 0 0 41 21
2020.02.28 15:46:03 4: CUL_Parse: mapleCUN1 N029A05912FAC00010000880210
2020.02.28 15:46:03 3: mapleCUN1: Unknown code N029A05912FAC00010000880210, help me!
2020.02.28 15:46:03 4: CUL_Parse: mapleCUN1 H432800910147FF -74.5
2020.02.28 15:46:03 5: LaCrosseGateway: dispatch OK 9 40 1 4 167 47
2020.02.28 15:46:04 4: CUL_Parse: mapleCUN1 ***N03020406795A00FFFFFFFFF759AAAAAA000000000DDE2EB659D8B63D4018042802
2020.02.28 15:46:04 4: CUL_Parse: mapleCUN1 ***N03020406795A000000019CF23BAAC00078ADBE2092D0C3B692977C737995FC18F7
2020.02.28 15:46:04 5: LaCrosseGateway: dispatch OK 24 2 4 6 121 90 0 0 0 1 156
2020.02.28 15:46:05 4: CUL_Parse: mapleCUN1 **N0192C4996A2EAAAA000081D44B
2020.02.28 15:46:05 4: CUL_Parse: mapleCUN1 H430B01990000FF -74.5
2020.02.28 15:46:06 4: CUL_Parse: mapleCUN1 N029D06152F544094053808C42A
2020.02.28 15:46:06 3: mapleCUN1: Unknown code N029D06152F544094053808C42A, help me!
2020.02.28 15:46:06 4: CUL_Parse: mapleCUN1 H433400150247FF -74.5
2020.02.28 15:46:06 5: LaCrosseGateway: dispatch OK 9 52 1 4 191 47
2020.02.28 15:46:06 4: CUL_Parse: mapleCUN1 ***N0304040384EC00FFFFFFFF0554AAAAAAB2B2B2B2F54C220D32CA79F01CABE32D42
2020.02.28 15:46:06 4: CUL_Parse: mapleCUN1 N0296C5963D1600000000248830
2020.02.28 15:46:06 3: mapleCUN1: Unknown code N0296C5963D1600000000248830, help me!
2020.02.28 15:46:06 4: CUL_Parse: mapleCUN1 H431B00960161FF -74.5
2020.02.28 15:46:06 4: CUL_Parse: mapleCUN1 ***N0304040384EC00000002D68B89AA334F87CFE7667EDB604A7D0A1CF370CD3D92A2
2020.02.28 15:46:06 5: LaCrosseGateway: dispatch OK 9 27 1 4 172 61
2020.02.28 15:46:06 5: LaCrosseGateway: dispatch OK 24 4 4 3 132 236 0 0 0 2 214
2020.02.28 15:46:06 4: CUL_Parse: mapleCUN1 *omE5D29A0404CC45231540F8
2020.02.28 15:46:06 4: CUL_Parse: mapleCUN1 *omAAA595E731F9
2020.02.28 15:46:06 4: CUL_Parse: mapleCUN1 *omA9FC9948A452F9
2020.02.28 15:46:07 5: LaCrosseGateway: dispatch OK VALUES LGW 3238236 UpTimeSeconds=252717,UpTimeText=2Tg. 22Std. 11Min. 57Sek. ,WIFI=xxxxxxxx,ReceivedFrames=203931,FramesPerMinute=60,RSSI=-74,FreeHeap=17968,LD.Min=0.13,LD.Avg=0.13,LD.Max=30.76,OLED=none
2020.02.28 15:46:07 4: CUL_Parse: mapleCUN1 N0299846713598A081100000000
2020.02.28 15:46:07 3: mapleCUN1: Unknown code N0299846713598A081100000000, help me!
2020.02.28 15:46:07 4: CUL_Parse: mapleCUN1 H432600670019FF -74.5
2020.02.28 15:46:07 5: LaCrosseGateway: dispatch OK 9 38 1 4 43 19
2020.02.28 15:46:08 4: CUL_Parse: mapleCUN1 N029A05922F8180000000420008
2020.02.28 15:46:08 3: mapleCUN1: Unknown code N029A05922F8180000000420008, help me!
2020.02.28 15:46:08 4: CUL_Parse: mapleCUN1 H432800920147FF -74.5
2020.02.28 15:46:08 5: LaCrosseGateway: dispatch OK 9 40 1 4 168 47
2020.02.28 15:46:08 4: CUL_Parse: mapleCUN1 ***N03050426D98C00FFFFFFFFED27AAAAAAFAFAFAFAF2D9BFF8B4F7F928C6F374223E
2020.02.28 15:46:08 5: LaCrosseGateway: dispatch OK 24 5 4 38 217 140 0 0 0 0 52
2020.02.28 15:46:08 4: CUL_Parse: mapleCUN1 N02938495330580483700040000
2020.02.28 15:46:08 3: mapleCUN1: Unknown code N02938495330580483700040000, help me!
2020.02.28 15:46:08 4: CUL_Parse: mapleCUN1 H430E00950051FF -74.5
2020.02.28 15:46:08 5: LaCrosseGateway: dispatch OK 9 14 1 4 71 51
2020.02.28 15:46:08 4: CUL_Parse: mapleCUN1 ***N03010426E40500FFFFFFFFEB23AAAAAA1616161600009BAFB888D710B7F3E3B02F
2020.02.28 15:46:09 4: CUL_Parse: mapleCUN1 ***N03010426E40500000000006B0AAAE4FEE5ACB2BA649EDE7CE63E6998E1B45FE01A
2020.02.28 15:46:09 5: LaCrosseGateway: dispatch OK 24 1 4 38 228 5 0 0 0 0 0
2020.02.28 15:46:09 4: CUL_Parse: mapleCUN1 ***N03080406B91000FFFFFFFF4B96AAAAAA0000000000D939AD0C1B4F41EBC1E4A647
2020.02.28 15:46:09 5: LaCrosseGateway: dispatch OK 24 8 4 6 185 16 0 0 0 0 195
2020.02.28 15:46:10 4: CUL_Parse: mapleCUN1 ***N03050426D9D500FFFFFFFF5578AAAAAA101010100249086E059364986039E7B5EE
2020.02.28 15:46:10 5: LaCrosseGateway: dispatch OK 24 5 4 38 217 213 0 0 0 21 165
2020.02.28 15:46:11 4: CUL_Parse: mapleCUN1 N029D06142FA041000000500028
2020.02.28 15:46:11 3: mapleCUN1: Unknown code N029D06142FA041000000500028, help me!
2020.02.28 15:46:11 4: CUL_Parse: mapleCUN1 H433400140247FF -74.5
2020.02.28 15:46:11 5: LaCrosseGateway: dispatch OK 9 52 1 4 190 47
2020.02.28 15:46:12 4: CUL_Parse: mapleCUN1 N0298C176494000000000002804
2020.02.28 15:46:12 3: mapleCUN1: Unknown code N0298C176494000000000002804, help me!
2020.02.28 15:46:12 4: CUL_Parse: mapleCUN1 N02998467135900020021000000
2020.02.28 15:46:12 3: mapleCUN1: Unknown code N02998467135900020021000000, help me!
2020.02.28 15:46:12 4: CUL_Parse: mapleCUN1 H432600670019FF -74.5
2020.02.28 15:46:12 5: LaCrosseGateway: dispatch OK 9 38 1 4 43 19
2020.02.28 15:46:12 5: LaCrosseGateway: dispatch OK 9 53 1 4 186 49
2020.02.28 15:46:13 4: CUL_Parse: mapleCUN1 N029A05912FAC80000000C80005
2020.02.28 15:46:13 3: mapleCUN1: Unknown code N029A05912FAC80000000C80005, help me!
2020.02.28 15:46:13 4: CUL_Parse: mapleCUN1 H432800910147FF -74.5
2020.02.28 15:46:13 5: LaCrosseGateway: dispatch OK 9 40 1 4 167 47
2020.02.28 15:46:13 4: CUL_Parse: mapleCUN1 **N0192C4996A2EAAAA000126C4BC
2020.02.28 15:46:13 4: CUL_Parse: mapleCUN1 H430B01990000FF -74.5
2020.02.28 15:46:16 4: CUL_Parse: mapleCUN1 N029D06152F5400001010056B67
2020.02.28 15:46:16 3: mapleCUN1: Unknown code N029D06152F5400001010056B67, help me!
2020.02.28 15:46:16 4: CUL_Parse: mapleCUN1 H433400150247FF -74.5
2020.02.28 15:46:16 5: LaCrosseGateway: dispatch OK 9 52 1 4 191 47
2020.02.28 15:46:16 4: CUL_Parse: mapleCUN1 N0296C5963D1600002208000020
2020.02.28 15:46:16 3: mapleCUN1: Unknown code N0296C5963D1600002208000020, help me!
2020.02.28 15:46:16 4: CUL_Parse: mapleCUN1 H431B00960161FF -74.5
2020.02.28 15:46:16 5: LaCrosseGateway: dispatch OK 9 27 1 4 172 61
2020.02.28 15:46:17 5: LaCrosseGateway: dispatch OK VALUES LGW 3238236 UpTimeSeconds=252727,UpTimeText=2Tg. 22Std. 12Min. 7Sek. ,WIFI=xxxxxxxx,ReceivedFrames=203944,FramesPerMinute=66,RSSI=-73,FreeHeap=17968,LD.Min=0.13,LD.Avg=0.13,LD.Max=31.05,OLED=none
2020.02.28 15:46:17 4: CUL_Parse: mapleCUN1 N02998467135980000000001020
2020.02.28 15:46:17 3: mapleCUN1: Unknown code N02998467135980000000001020, help me!
2020.02.28 15:46:17 4: CUL_Parse: mapleCUN1 H432600670019FF -74.5
2020.02.28 15:46:17 5: LaCrosseGateway: dispatch OK 9 38 1 4 43 19
2020.02.28 15:46:18 4: CUL_Parse: mapleCUN1 N029A05912FAC40800000000010
2020.02.28 15:46:18 3: mapleCUN1: Unknown code N029A05912FAC40800000000010, help me!
2020.02.28 15:46:18 4: CUL_Parse: mapleCUN1 H432800910147FF -74.5
2020.02.28 15:46:18 5: LaCrosseGateway: dispatch OK 9 40 1 4 167 47
2020.02.28 15:46:18 4: CUL_Parse: mapleCUN1 N02938495330500000400400000
2020.02.28 15:46:18 3: mapleCUN1: Unknown code N02938495330500000400400000, help me!
2020.02.28 15:46:18 4: CUL_Parse: mapleCUN1 H430E00950051FF -74.5
2020.02.28 15:46:18 5: LaCrosseGateway: dispatch OK 9 14 1 4 71 51
2020.02.28 15:46:21 4: CUL_Parse: mapleCUN1 N029D06142FA0E0900000000000
2020.02.28 15:46:21 3: mapleCUN1: Unknown code N029D06142FA0E0900000000000, help me!
2020.02.28 15:46:21 4: CUL_Parse: mapleCUN1 H433400140247FF -74.5
2020.02.28 15:46:21 5: LaCrosseGateway: dispatch OK 9 52 1 4 190 47
2020.02.28 15:46:21 4: CUL_Parse: mapleCUN1 **N0192C4996A2EAAAA000112D3F9
2020.02.28 15:46:21 4: CUL_Parse: mapleCUN1 H430B01990000FF -74.5
2020.02.28 15:46:22 4: CUL_Parse: mapleCUN1 N0298C176497F90400323C40A84
2020.02.28 15:46:22 3: mapleCUN1: Unknown code N0298C176497F90400323C40A84, help me!
2020.02.28 15:46:22 4: CUL_Parse: mapleCUN1 N0299846813C080000004004000
2020.02.28 15:46:22 3: mapleCUN1: Unknown code N0299846813C080000004004000, help me!
2020.02.28 15:46:22 4: CUL_Parse: mapleCUN1 H432600680019FF -74.5
2020.02.28 15:46:22 5: LaCrosseGateway: dispatch OK 9 38 1 4 44 19
2020.02.28 15:46:22 5: LaCrosseGateway: dispatch OK 9 53 1 4 186 49
2020.02.28 15:46:23 4: CUL_Parse: mapleCUN1 N029A05912FAC80000000800000
2020.02.28 15:46:23 3: mapleCUN1: Unknown code N029A05912FAC80000000800000, help me!
2020.02.28 15:46:23 4: CUL_Parse: mapleCUN1 H432800910147FF -74.5
2020.02.28 15:46:23 5: LaCrosseGateway: dispatch OK 9 40 1 4 167 47
2020.02.28 15:46:26 4: CUL_Parse: mapleCUN1 N029D06152F54DB882A5194EC69
2020.02.28 15:46:26 3: mapleCUN1: Unknown code N029D06152F54DB882A5194EC69, help me!
2020.02.28 15:46:26 4: CUL_Parse: mapleCUN1 H433400150247FF -74.5
2020.02.28 15:46:26 5: LaCrosseGateway: dispatch OK 9 52 1 4 191 47
2020.02.28 15:46:26 4: CUL_Parse: mapleCUN1 N0296C5963D1680000000000000
2020.02.28 15:46:26 3: mapleCUN1: Unknown code N0296C5963D1680000000000000, help me!
2020.02.28 15:46:26 4: CUL_Parse: mapleCUN1 H431B00960161FF -74.5
2020.02.28 15:46:26 5: LaCrosseGateway: dispatch OK 9 27 1 4 172 61
2020.02.28 15:46:27 4: CUL_Parse: mapleCUN1 ***N030804078A9600FFFFFFFF7B2EAAAAAA414141410B474F59DC99A4677756EAA04A
2020.02.28 15:46:27 5: LaCrosseGateway: dispatch OK VALUES LGW 3238236 UpTimeSeconds=252737,UpTimeText=2Tg. 22Std. 12Min. 17Sek. ,WIFI=xxxxxxxx,ReceivedFrames=203953,FramesPerMinute=61,RSSI=-73,FreeHeap=17968,LD.Min=0.13,LD.Avg=0.13,LD.Max=7.33,OLED=none
2020.02.28 15:46:27 4: CUL_Parse: mapleCUN1 ***N030804078A9600FFFFFFFF7B2EAAAAAA282828280876FE2A591A50920114A13F08
2020.02.28 15:46:27 5: LaCrosseGateway: dispatch OK 24 8 4 7 138 150 1 8 159 166 34
2020.02.28 15:46:27 5: LaCrosseGateway: dispatch OK 9 38 1 4 43 19
2020.02.28 15:46:27 4: CUL_Parse: mapleCUN1 N02998467135980000400000000
2020.02.28 15:46:27 3: mapleCUN1: Unknown code N02998467135980000400000000, help me!
2020.02.28 15:46:27 4: CUL_Parse: mapleCUN1 H432600670019FF -74.5
2020.02.28 15:46:28 4: CUL_Parse: mapleCUN1 N02938495330500000000000202
2020.02.28 15:46:28 3: mapleCUN1: Unknown code N02938495330500000000000202, help me!
2020.02.28 15:46:28 4: CUL_Parse: mapleCUN1 H430E00950051FF -74.5
2020.02.28 15:46:28 5: LaCrosseGateway: dispatch OK 9 14 1 4 71 51
2020.02.28 15:46:29 4: CUL_Parse: mapleCUN1 **N0192C4996A2EAAAA00012BC1F9
2020.02.28 15:46:29 4: CUL_Parse: mapleCUN1 H430B01990000FF -74.5
2020.02.28 15:46:31 4: CUL_Parse: mapleCUN1 N029D06142FA040001181423EC8
2020.02.28 15:46:31 3: mapleCUN1: Unknown code N029D06142FA040001181423EC8, help me!
2020.02.28 15:46:31 4: CUL_Parse: mapleCUN1 H433400140247FF -74.5
2020.02.28 15:46:31 5: LaCrosseGateway: dispatch OK 9 52 1 4 190 47
2020.02.28 15:46:32 4: CUL_Parse: mapleCUN1 N0298C176494000000842200000
2020.02.28 15:46:32 3: mapleCUN1: Unknown code N0298C176494000000842200000, help me!
2020.02.28 15:46:32 4: CUL_Parse: mapleCUN1 N0299846813C000010004000500
2020.02.28 15:46:32 3: mapleCUN1: Unknown code N0299846813C000010004000500, help me!
2020.02.28 15:46:32 4: CUL_Parse: mapleCUN1 H432600680019FF -74.5
2020.02.28 15:46:32 5: LaCrosseGateway: dispatch OK 9 38 1 4 44 19
2020.02.28 15:46:32 4: CUL_Parse: mapleCUN1 ***N03050406977200FFFFFFFFF7FBAAAAAA080808080B44779F21B2DEED7233FB839A
2020.02.28 15:46:32 4: CUL_Parse: mapleCUN1 ***N0305040697720000000052F63DAAE6B75181BC16AADCAAB6FB7B305DB14FB68FFE
2020.02.28 15:46:32 4: CUL_Parse: mapleCUN1 ***N03050406977200FFFFFFFFF7FBAAAAAA01010101027FBFC65F0A2BFDBF2C3D2DD3
2020.02.28 15:46:33 4: CUL_Parse: mapleCUN1 ***N0305040697720000000052F63DAA8FEFE613ABA6BA5A455BFAE3BB22D2670BF5EF
2020.02.28 15:46:33 5: LaCrosseGateway: dispatch OK 24 5 4 6 151 114 0 0 0 0 82
2020.02.28 15:46:33 4: CUL_Parse: mapleCUN1 N029A05922F8100003044008600
2020.02.28 15:46:33 3: mapleCUN1: Unknown code N029A05922F8100003044008600, help me!
2020.02.28 15:46:33 4: CUL_Parse: mapleCUN1 H432800920147FF -74.5
2020.02.28 15:46:33 5: LaCrosseGateway: dispatch OK 9 40 1 4 168 47
2020.02.28 15:46:36 4: CUL_Parse: mapleCUN1 N029D06142FA080020400020001
2020.02.28 15:46:36 3: mapleCUN1: Unknown code N029D06142FA080020400020001, help me!
2020.02.28 15:46:36 4: CUL_Parse: mapleCUN1 H433400140247FF -74.5
2020.02.28 15:46:36 5: LaCrosseGateway: dispatch OK 9 52 1 4 190 47
2020.02.28 15:46:36 4: CUL_Parse: mapleCUN1 N0296C5963D1652000C20000484
2020.02.28 15:46:36 3: mapleCUN1: Unknown code N0296C5963D1652000C20000484, help me!
2020.02.28 15:46:36 4: CUL_Parse: mapleCUN1 H431B00960161FF -74.5
2020.02.28 15:46:36 5: LaCrosseGateway: dispatch OK 9 27 1 4 172 61
2020.02.28 15:46:37 5: LaCrosseGateway: dispatch OK VALUES LGW 3238236 UpTimeSeconds=252747,UpTimeText=2Tg. 22Std. 12Min. 27Sek. ,WIFI=xxxxxxxx,ReceivedFrames=203962,FramesPerMinute=60,RSSI=-71,FreeHeap=17968,LD.Min=0.13,LD.Avg=0.13,LD.Max=30.90,OLED=none
2020.02.28 15:46:37 4: CUL_Parse: mapleCUN1 N0299846813C080000000080000
2020.02.28 15:46:37 3: mapleCUN1: Unknown code N0299846813C080000000080000, help me!
2020.02.28 15:46:37 4: CUL_Parse: mapleCUN1 H432600680019FF -74.5
2020.02.28 15:46:37 5: LaCrosseGateway: dispatch OK 9 38 1 4 44 19
2020.02.28 15:46:38 5: LaCrosseGateway: dispatch OK 9 40 1 4 167 47
2020.02.28 15:46:38 4: CUL_Parse: mapleCUN1 **N0192C4996A2EAAAA0000BBF4CE
2020.02.28 15:46:38 4: CUL_Parse: mapleCUN1 H430B01990000FF -74.5
2020.02.28 15:46:38 4: CUL_Parse: mapleCUN1 N029A05912FAC50006908000C81
2020.02.28 15:46:38 3: mapleCUN1: Unknown code N029A05912FAC50006908000C81, help me!
2020.02.28 15:46:38 4: CUL_Parse: mapleCUN1 H432
Danke für das Log.
Nun sollte der Signalduino alle LaCrosse Sensoren vom Mode 1 - IT+ 17.241 kbps und Mode 2 - IT+ 9.579 kbps empfangen können.
es gibt Abweichungen zwischen dem mapleCUN und dem Jeelink
Das LaCrosse Gateway, der Jeelink und der Signalduino verwenden das LaCrosse Modul.
Der Cul verwendet das hms Modul, dazu werden die LaCrosse Raw Nachrichten ins hms Format umgewandelt, evtl passt da irgendwas nicht.
Das hms Modul unterstützt auch nicht das set replaceBatteryForSec
Gruß Ralf
Moin Ralf,
Danke für Deine Arbeit!
Wird es eine neue Firmware dafür geben?
Gruß
Arthur
ZitatWird es eine neue Firmware dafür geben?
Ja, für USB gibt es mittlerweile eine Firmware, für LAN kommt später.
https://forum.fhem.de/index.php/topic,106278.msg1001477.html#msg1001477
Gruß Ralf
Hallo zusammen,
ich bin mir nicht sicher, ob ich hier mit meinem Problem richtig aufgehoben bin, habe ja schon seit längeren mitgelesen aber trotzdem ersmal meine Frage:
Ich möchte einen TFA- Dostmann WeatherHub Modul (30.3303.02 = Temperatur und Luftfeuchte) ohne Gateway in FHEM einbinden.
Funktioniert das mit dem Signalduino oder einem anderen Modul bereits?
Mit Lacross kenne ich mich nicht aus, via SDR Stick, siehe:
https://github.com/baycom/tfrec (https://github.com/baycom/tfrec)
kann ich die Daten aber schon empfangen, dazu muss ich die SW mit Parameter T20 starten.
./tfrec -T20
Ich suche aber eine Lösung via CUL oder kompatibler Hardware.
Hallo, mit der offiziellen Version des Signalduino geht es derzeit noch nicht.
Wenn man den Bedarf bündelt, Bereichskennende sich zu Wort melden und manche Mitwirkenden zusammen handeln, wäre es kein Problem.
Solange das nicht so kommt, kann man nur eine nichtoffizielle Version nutzen.
Mfg
Gesendet von iPhone mit Tapatalk Pro
Hm,
verstehe nicht ganz wie das gemeint ist, aber ich helfe gerne bei derartigen Aktionen.
Auf der anderen Seite könnte ich aktuell auch mit einer inoffiziellen Version die ersten Schritte machen, da würde man gleich sehen wie ich Euch unterstützen kann.
Nur tu ich mich gerade schwer die Informationen zusammenzutragen, was nötig ist um hier den nächsten Schritt zu machen.
ZitatIch möchte einen TFA- Dostmann WeatherHub Modul (30.3303.02 = Temperatur und Luftfeuchte) ohne Gateway in FHEM einbinden.
Funktioniert das mit dem Signalduino oder einem anderen Modul bereits?
Das funktioniert momentan noch nicht mit dem Signalduino.
Hast Du schon geschaut ob es FHEM was dafür gibt?
Ich hab mal hier geschaut
https://github.com/baycom/tfrec/blob/master/sensors.txt
https://github.com/baycom/tfrec/blob/master/whb.cpp
und folgendes gefunden:
TFA_WHB 30.3303.02
868.250 MHz
ID 6 Byte
DataR 6000 Baud
Mod PSK-NRZM (PSK-NRZS-G3RUH-scrambled)
Sync 4b2dd42b
Als erstes müssen für den cc1101 die richtigen Registereinstellungen gefunden werden:
Mir ist nicht klar wie das beim cc1101 mit dem 32 Bit sync funktioniert
ZitatThe sync word is a 16 bit configurable field (can be repeated to get a 32 bit) that is automatically inserted at
the start of the packet by the modulator in transmit mode. The MSB in the sync word is sent first.
Ich hab auch nichts gefunden was für eine Modulation es ist: 2-FSK, GFSK, ASK/OOK, 4-FSK, oder MSK
Gruß Ralf
Zitat von: Ralf9 am 19 März 2020, 21:01:30
Ich hab auch nichts gefunden was für eine Modulation es ist: 2-FSK, GFSK, ASK/OOK, 4-FSK, oder MSK
Hast Du einen SDR-Stick? Dann kannst Du Dir mit Software wie URH das Spektrum anschauen und erkennst zumindest wieviele Pegelspitzen das Signal hat. Daraus lässt sich OOK, 2-FSK/GFSK und 4-FSK ableiten.
Bei tfrec arbeite ich mit der option "-T20"
Damit wird die Sensorgruppe:
NRZS/6000baud: WeatherHub sensors (TFA 30.3303.02, 30.3305.02, 30.3306.02, 30.3307.02 30.3311.02, MA10410/TFA 35.1147.01, TFA 35.1147.01, 30.3304.02, 30.5043.01 probably others like Technoline Mobile Alerts)
aktiviert.
In der Zugehörigen Sensors.txt
https://github.com/baycom/tfrec/blob/master/sensors.txt (https://github.com/baycom/tfrec/blob/master/sensors.txt)
steht für meinen Sensor (30.3303.03):
Type Temp1 Temp2 Humid ID LCD Baudrate Mod Sync Period Init-Msg Notes
30.3303.02 TFA_WHB X - X 6Byte X 6000 PSK-NRZM 4b2dd42b 420s? ? WeatherHub temp/humidity sensor
Damit wäre zumindest mal die Modulation geklärt:
PSK-NRZM (Non-return-to-zero mark)
https://en.wikipedia.org/wiki/Non-return-to-zero (https://en.wikipedia.org/wiki/Non-return-to-zero)
ZitatDamit wäre zumindest mal die Modulation geklärt:
PSK-NRZM (Non-return-to-zero mark)
Für mich sieht das nicht nach einer Modulation aus.
Der cc1101 kann die folgenden Modulationen:
2-FSK, GFSK, ASK/OOK, 4-FSK, oder MSK
Gruß Ralf
ZitatHallo, mit der offiziellen Version des Signalduino geht es derzeit noch nicht.
Wenn man den Bedarf bündelt, Bereichskennende sich zu Wort melden und manche Mitwirkenden zusammen handeln, wäre es kein Problem.
Die FSK Unterstützung sollte sich mit überschaubarem Aufwand auch ins offizielle Signalduino Modul einbauen lassen.
Dazu müssen in der SD_ProtocolData.pm die neuen FSK ProtocolIDs eingetragen werden:
https://github.com/Ralf9/RFFHEM/blob/06c8f176c53dbe05e9431bf94564ca7ce188c3d9/FHEM/lib/signalduino_protocols.pm#L2569
In der 00_SIGNALduino.pm ist u.a. eine neue "sub SIGNALduino_Parse_MN" dazugekommen:
https://github.com/Ralf9/RFFHEM/blob/06c8f176c53dbe05e9431bf94564ca7ce188c3d9/FHEM/00_SIGNALduino.pm#L3084
Hier sind für FSK notwendige Anpassungen
https://github.com/Ralf9/RFFHEM/commit/6fd89e12c3ab00302ae8f2cc1324496db5f522f6
damit werden dann die neuen FSK ProtocolIDs auch in der Protocolllist Overview ausgegeben (siehe Anlage)
Hier sind Anpassungen für die Firmware V 4.x
https://github.com/Ralf9/RFFHEM/commit/5f885f759c4632b78eda8636638741fb93850a3e
FSK Raw Nachrichten zum Testen reiche ich noch nach.
Es sind einige raw Befehle dazugekommen u.a.
Mit "get sduino raw rN0100" werden 64 Byte vom EEPROM gelesen
EEPROM 0100: 01 FE 01 2E 46 02 2D D4 FF 00 02 00 00 06 00 21 EEPROM 0110: 65 6A 89 5C 06 22 F8 56 07 00 18 16 6C 43 68 91 EEPROM 0120: 87 6B F8 56 11 E9 2A 00 11 41 00 FF FF FF FF FF EEPROM 0130: 00 81 00 00 00 00 00 00 FF FF FF FF FF 00 03 FFmit "get sduino raw b" wird eine Info von dem gerade selektiertem Radio (cc1101) und EEPROM Speicherbank ausgegeben
r=A b=1 ccmode=3 sync=2DD4 ccconf=21656A895C0622F856070018166C436891 boffs=0100Ab der sduino Version 4 werden bis zu 4 cc1101 Module unterstützt, da kann mit
"get sduiono raw br" eine Info zu allen aktiven Radio (cc1101) ausgegeben werden
r=A b=1 ccmode=3 sync=2DD4 ccconf=21656A895C0622F856070018166C436891 boffs=0100 r=B b=0 ccmode=0 sync=D391 ccconf=10B07137C43023B900070018146C070090 boffs=0000Vom 00_SIGNALduino.pm Modul werden diese Ausgaben aufbereitet (siehe Anlage)
Gruß Ralf
ZitatFür mich sieht das nicht nach einer Modulation aus.
Doch, das schon. Aber Du hast recht, PSK kann der CC1101 nicht.
Grüße Markus
Bzgl. PSK, hier sind die Unterschiede erwähnt:
https://www.rfwireless-world.com/Terminology/ASK-vs-FSK-vs-PSK.html (https://www.rfwireless-world.com/Terminology/ASK-vs-FSK-vs-PSK.html)
Wenn das der CC1101 nicht kann hat sich das Thema schon für mich erledigt >:(
Danke fürs Feed Back
Zitat von: HomeAuto_User am 19 März 2020, 14:00:18
Hallo, mit der offiziellen Version des Signalduino geht es derzeit noch nicht.
Wenn man den Bedarf bündelt, Bereichskennende sich zu Wort melden und manche Mitwirkenden zusammen handeln, wäre es kein Problem.
Ja, es wäre schön, wenn die FSK Unterstützung auch ins offizielle Signalduino Modul eingebaut würde.
Ich habe nun einiges dazu geschrieben, bitte meldet Euch, wenn Ihr noch Info oder Hilfe benötigt.
Zitat von: Ralf9 am 20 März 2020, 19:04:07
FSK Raw Nachrichten zum Testen reiche ich noch nach.
LaCrosse TX29DTH-IT
2020.03.22 13:22:26.369 4 : sduinoRXB/msg READ: MN;D=99E6342D4EAAAA0000236275;R=4;
2020.03.22 13:22:26.369 4 : sduinoRXB Parse_MN: Found 2-FSK Protocol id 100 -> Lacrosse mode 1
2020.03.22 13:22:26.369 4 : sduinoRXB LaCrosse_convert: ID=100, addr=39 temp=23.4 hum=45 bat=0 batInserted=128
2020.03.22 13:22:26.369 4 : sduinoRXB ParseMN: ID=100 dmsg=OK 9 39 129 4 210 45
2020.03.22 13:22:26.369 4 : sduinoRXB Dispatch: OK 9 39 129 4 210 45, -72 dB, dispatch
2020.03.22 13:22:26.370 3 : sduinoRXB LaCrosse Parse: type=0 T(H)
2020.03.22 13:22:26.370 3 : LaCrosse: Unknown device 27, please define it
2020.03.22 13:22:30.485 1 : PERL WARNING: Odd number of elements in anonymous hash at ./FHEM/36_LaCrosse.pm line 151.
2020-03-22 13:22:30.491 LaCrosse LaCrosse_0b replaceBatteryForSec 30
2020.03.22 13:22:30.674 4 : sduinoRXB/msg READ: MN;D=99E6342D4EAAAA00002E41AC;R=255;
2020.03.22 13:22:30.674 4 : sduinoRXB Parse_MN: Found 2-FSK Protocol id 100 -> Lacrosse mode 1
2020.03.22 13:22:30.674 4 : sduinoRXB LaCrosse_convert: ID=100, addr=39 temp=23.4 hum=45 bat=0 batInserted=128
2020.03.22 13:22:30.674 4 : sduinoRXB ParseMN: ID=100 dmsg=OK 9 39 129 4 210 45
2020.03.22 13:22:30.674 4 : sduinoRXB Dispatch: OK 9 39 129 4 210 45, -74.5 dB, dispatch
2020.03.22 13:22:30.676 3 : LaCrosse: Changing device 27 from 3C to 27
2020.03.22 13:22:34.978 4 : sduinoRXB/msg READ: MN;D=99E6352DBAAAAA0000613521;R=5;
2020.03.22 13:22:34.978 4 : sduinoRXB Parse_MN: Found 2-FSK Protocol id 100 -> Lacrosse mode 1
2020.03.22 13:22:34.978 4 : sduinoRXB LaCrosse_convert: ID=100, addr=39 temp=23.5 hum=45 bat=0 batInserted=128
2020.03.22 13:22:34.978 4 : sduinoRXB ParseMN: ID=100 dmsg=OK 9 39 129 4 211 45
2020.03.22 13:22:34.978 4 : sduinoRXB Dispatch: OK 9 39 129 4 211 45, -71.5 dB, dispatch
2020-03-22 13:22:34.985 LaCrosse LaCrosse_0b battery: ok
2020-03-22 13:22:34.985 LaCrosse LaCrosse_0b temperature: 23.5
2020-03-22 13:22:34.985 LaCrosse LaCrosse_0b humidity: 45
2020-03-22 13:22:34.985 LaCrosse LaCrosse_0b T: 23.5 H: 45
2020-03-22 13:22:34.985 LaCrosse LaCrosse_0b RAWMSG: MN;D=99E6352DBAAAAA0000613521;R=5;
2020-03-22 13:22:34.985 LaCrosse LaCrosse_0b Protocol_ID: 100
2020-03-22 13:22:34.985 LaCrosse LaCrosse_0b RSSI: -71.5
2020-03-22 13:22:34.985 LaCrosse LaCrosse_0b DMSG: OK 9 39 129 4 211 45PCA301
2020.03.22 13:36:20.188 4 : sduinoRXB/msg READ: MN;D=020503B7A100AAAAAAAA54D5AA18590B66A88797465D50AED898482A1E80E8CC;N=3;R=252;
2020.03.22 13:36:20.189 4 : sduinoRXB Parse_MN: Found 2-FSK Protocol id 101 -> PCA 301
2020.03.22 13:36:20.189 4 : sduinoRXB PCA301_convert: translated native RF telegram PCA301 OK 24 2 5 3 183 161 0 170 170 170 170 54D5
2020.03.22 13:36:20.189 4 : sduinoRXB ParseMN: ID=101 dmsg=OK 24 2 5 3 183 161 0 170 170 170 170 54D5
2020.03.22 13:36:20.189 4 : sduinoRXB Dispatch: OK 24 2 5 3 183 161 0 170 170 170 170 54D5, -76 dB, dispatch
2020-03-22 13:36:20.192 PCA301 PCA301_03B7A1 on
2020-03-22 13:36:20.192 PCA301 PCA301_03B7A1 DMSG: OK 24 2 5 3 183 161 0 170 170 170 170 54D5
2020-03-22 13:36:20.192 PCA301 PCA301_03B7A1 RSSI: -76
2020-03-22 13:36:20.192 PCA301 PCA301_03B7A1 Protocol_ID: 101
2020-03-22 13:36:20.192 PCA301 PCA301_03B7A1 RAWMSG: MN;D=020503B7A100AAAAAAAA54D5AA18590B66A88797465D50AED898482A1E80E8CC;N=3;R=252;
2020-03-22 13:37:54.572 PCA301 PCA301_03B7A1 set-off
2020.03.22 13:37:54.572 3 : PCA301 send off: msg=SN;N=3;D=020503B7A100FFFFFFFFAB31AAAAAA;
2020.03.22 13:37:54.572 4 : set sduinoRXB raw SN;N=3;D=020503B7A100FFFFFFFFAB31AAAAAA;
2020.03.22 13:37:54.701 4 : sduinoRXB/msg READ: SN;N=3;D=020503B7A100FFFFFFFFAB31AAAAAA;Marcs=22
2020.03.22 13:37:54.701 3 : sduinoRXB/noMsg Parse: SN;N=3;D=020503B7A100FFFFFFFFAB31AAAAAA;Marcs=22
2020.03.22 13:37:54.773 4 : sduinoRXB/msg READ: MN;D=020503B7A100AAAAAAAA54D5AAE8D7FB6872421E381C3FF9BCCC1598AE95B04D;N=3;R=6;
2020.03.22 13:37:54.773 4 : sduinoRXB Parse_MN: Found 2-FSK Protocol id 101 -> PCA 301
2020.03.22 13:37:54.773 4 : sduinoRXB PCA301_convert: translated native RF telegram PCA301 OK 24 2 5 3 183 161 0 170 170 170 170 54D5
2020.03.22 13:37:54.773 4 : sduinoRXB ParseMN: ID=101 dmsg=OK 24 2 5 3 183 161 0 170 170 170 170 54D5
2020.03.22 13:37:54.773 4 : sduinoRXB Dispatch: OK 24 2 5 3 183 161 0 170 170 170 170 54D5, -71 dB, dispatch
2020-03-22 13:37:54.777 PCA301 PCA301_03B7A1 off
2020-03-22 13:37:54.777 PCA301 PCA301_03B7A1 Protocol_ID: 101
2020-03-22 13:37:54.777 PCA301 PCA301_03B7A1 RAWMSG: MN;D=020503B7A100AAAAAAAA54D5AAE8D7FB6872421E381C3FF9BCCC1598AE95B04D;N=3;R=6;
2020-03-22 13:37:54.777 PCA301 PCA301_03B7A1 DMSG: OK 24 2 5 3 183 161 0 170 170 170 170 54D5
2020-03-22 13:37:54.777 PCA301 PCA301_03B7A1 RSSI: -71
2020-03-22 13:40:08.733 PCA301 PCA301_03B7A1 set-statusRequest
2020.03.22 13:40:08.733 3 : PCA301 send statreq: msg=SN;N=3;D=020403B7A100FFFFFFFF2D52AAAAAA;
2020.03.22 13:40:08.733 4 : set sduinoRXB raw SN;N=3;D=020403B7A100FFFFFFFF2D52AAAAAA;
2020.03.22 13:40:08.863 4 : sduinoRXB/msg READ: SN;N=3;D=020403B7A100FFFFFFFF2D52AAAAAA;Marcs=22
2020.03.22 13:40:08.863 3 : sduinoRXB/noMsg Parse: SN;N=3;D=020403B7A100FFFFFFFF2D52AAAAAA;Marcs=22
2020.03.22 13:40:08.935 4 : sduinoRXB/msg READ: MN;D=020403B7A10101A7000031ECAAA9615CF878C1E17E3CDF4882A8D0045204CB0D;N=3;R=252;
2020.03.22 13:40:08.935 4 : sduinoRXB Parse_MN: Found 2-FSK Protocol id 101 -> PCA 301
2020.03.22 13:40:08.935 4 : sduinoRXB PCA301_convert: translated native RF telegram PCA301 OK 24 2 4 3 183 161 1 1 167 0 0 31EC
2020.03.22 13:40:08.935 4 : sduinoRXB ParseMN: ID=101 dmsg=OK 24 2 4 3 183 161 1 1 167 0 0 31EC
2020.03.22 13:40:08.936 4 : sduinoRXB Dispatch: OK 24 2 4 3 183 161 1 1 167 0 0 31EC, -76 dB, dispatch
2020.03.22 13:40:08.936 4 : sduinoRXB PCA301 Parse: PCA301_03B7A1, state=on, power=42.3
2020-03-22 13:40:08.939 PCA301 PCA301_03B7A1 power: 42.3
2020-03-22 13:40:08.939 PCA301 PCA301_03B7A1 on
2020-03-22 13:40:08.939 PCA301 PCA301_03B7A1 RSSI: -76
2020-03-22 13:40:08.939 PCA301 PCA301_03B7A1 DMSG: OK 24 2 4 3 183 161 1 1 167 0 0 31EC
2020-03-22 13:40:08.939 PCA301 PCA301_03B7A1 RAWMSG: MN;D=020403B7A10101A7000031ECAAA9615CF878C1E17E3CDF4882A8D0045204CB0D;N=3;R=252;
2020-03-22 13:40:08.939 PCA301 PCA301_03B7A1 Protocol_ID: 101TFA 30.3155 WD
2020.03.22 14:01:38.687 4 : sduinoD/msg get raw: MN;D=96C5963D160200A400018000;N=2;
2020.03.22 14:01:38.687 4 : sduinoD Parse_MN: Found 2-FSK Protocol id 103 -> Lacrosse mode 2
2020.03.22 14:01:38.687 4 : sduinoD LaCrosse_convert: ID=103, addr=27 temp=19.6 hum=61 bat=0 batInserted=0
2020.03.22 14:01:38.687 4 : sduinoD ParseMN: ID=103 dmsg=OK 9 27 1 4 172 61
2020.03.22 14:01:38.688 4 : sduinoD Dispatch: OK 9 27 1 4 172 61, dispatch
2020.03.22 14:01:38.721 3 : sduinoD LaCrosse Parse: type=0 T(H)
2020.03.22 14:01:38.721 3 : LaCrosse: Unknown device 1B, please define itKopp FreeControl
2020.03.22 14:08:51.431 4 : sduinoD/msg get raw: MN;D=07FA5E1721CC0F02FE000000000000;N=4;
2020.03.22 14:08:51.431 4 : sduinoD Parse_MN: Found GFSK Protocol id 102 -> KoppFreeControl
2020.03.22 14:08:51.431 4 : sduinoD KoppFreeControl: dmsg=07FA5E1721CC0F02FE000000000000 anz=8 checksum=254 ok
2020.03.22 14:08:51.431 4 : sduinoD ParseMN: ID=102 dmsg=kr07FA5E1721CC0F02
2020.03.22 14:08:51.431 5 : sduinoD Dispatch: kr07FA5E1721CC0F02, test ungleich: disabled
2020.03.22 14:08:51.431 4 : sduinoD Dispatch: kr07FA5E1721CC0F02, dispatch
2020.03.22 14:08:51.431 5 : sduinoD: dispatch kr07FA5E1721CC0F02
2020.03.22 14:08:51.431 2 : KOPP_FC_Parse: name: sduinoD code: FA5E 21 Specialkey:short
2020-03-22 14:08:51.433 KOPP_FC culfsk onlist culfsk
Internals:
DEF 21 FA5E 02 11
KEYCODE 21
KEYCODE2 11
NAME culfsk
TRANSMITTERCODE1 FA5E
TRANSMITTERCODE2 02
TYPE KOPP_FC
Attributes:
model Switch_8080_01_2KeyGruß Ralf
Hallo Ralf,
Zitat von: Ralf9 am 22 März 2020, 14:32:15
Ja, es wäre schön, wenn die FSK Unterstützung auch ins offizielle Signalduino Modul eingebaut würde.
Ich habe nun einiges dazu geschrieben, bitte meldet Euch, wenn Ihr noch Info oder Hilfe benötigt.
ich denke wir finden da einen Konsens.
Die Einarbeitung sollten wir Schritt für Schritt gemeinsam hinbekommen.
Welche Plattform für den systematischen Einbau wäre dir für die Kommunikation am liebsten? Forum hier oder Github?
LG Marco
#GemeinsamSindWirStark #StayAtHome #DankeAnAlleFunktionalenKräfte
ZitatWelche Plattform für den systematischen Einbau wäre dir für die Kommunikation am liebsten? Forum hier oder Github?
Am praktischen wird es in github sein.
Du kannst ja dafür ein neues Issue und Branch aufmachen.
In einem ersten Schritt kann dann z.B. erstmal das Grundsätzliche für FSK rein, dies kann dann mit den raw Nachrichten getestet werden.
- In die SD_ProtocolData.pm die neuen FSK ProtocolIDs eintragen
- Die "sub SIGNALduino_IdList" und "sub SIGNALduino_FW_getProtocolList" erweitern, damit die FSK ProtocollIds unterstützt werden
- Die neue "sub SIGNALduino_Parse_MN" einbauen
- Neuer set Befehl: LaCrossePairForSec
- Die "sub SIGNALduino_FingerprintFn" wird nun bei dispatch msg deaktiviert die mit "OK" beginnen.
Dies ist notwendig, da bei einigen LaCrosse Modulen auch das FingerprintFn verwendet wird.
Gruß Ralf
Zitat von: Ralf9 am 07 März 2020, 19:45:35
Ja, für USB gibt es mittlerweile eine Firmware, für LAN kommt später.
https://forum.fhem.de/index.php/topic,106278.msg1001477.html#msg1001477
Gruß Ralf
Ich hab den "großen" mapleCUL (von Ranseyer) mit 4 Radios + Homematic der über LAN angebunden ist. Das soll auch so bleiben. Ich warte dann mal auf die LAN Version. Hast Du da schon eine zeitliche Vorstellung?
Gruß
Arthur
@Ralf,
Hallo,
ich habe mal begonnen mit der Übernahme. Ich schaute soeben in deiner Zusammenfassung von Seite 1 nach den zugehörigen MN RAW Nachrichten.
Ist es machbar, das wir zu jedem Device mindestens eine RAW ergänzen. Diese würde ich gern zum testen wollen für die Funktion und ebenso dann gleich im Anschluss in die große JSON Sammlung ergänzen.
LG Marco
#GemeinsamSindWirStark #StayAtHome #DankeAnAlleFunktionalenKräfte
Zitat von: arthur_dent_2015 am 23 März 2020, 17:17:21
Ich hab den "großen" mapleCUL (von Ranseyer) mit 4 Radios + Homematic der über LAN angebunden ist. Das soll auch so bleiben. Ich warte dann mal auf die LAN Version. Hast Du da schon eine zeitliche Vorstellung?
Kann noch ein paar Wochen dauern, erst kommt mal das LAN beim MapleSduino.
Das durchreichen der seriellen Daten fürs Homematic Modul kann noch eine Weile dauern, da brauche ich jemand der mir den Code dafür liefert
ZitatIst es machbar, das wir zu jedem Device mindestens eine RAW ergänzen.
Hier sind noch 2 raw Nachrichten vom LaCrosse TX29DTH-IT mit Batterie wechsel, das batInserted=128 wird erst nach einigen Stunden 0
2020.03.23 21:01:43.301 4 : sduinoRXB/msg READ: MN;D=9AA6362CC8AAAA000012F8F4;R=4;
2020.03.23 21:01:43.301 4 : sduinoRXB Parse_MN: Found 2-FSK Protocol id 100 -> Lacrosse mode 1
2020.03.23 21:01:43.301 4 : sduinoRXB LaCrosse_convert: ID=100, addr=42 temp=23.6 hum=44 bat=0 batInserted=128
2020.03.23 21:01:43.301 4 : sduinoRXB ParseMN: ID=100 dmsg=OK 9 42 129 4 212 44
2020.03.23 21:01:43.301 4 : sduinoRXB Dispatch: OK 9 42 129 4 212 44, -72 dB, dispatch
2020-03-23 21:01:43.303 LaCrosse LaCrosse_0b battery: ok
2020-03-23 21:01:43.303 LaCrosse LaCrosse_0b temperature: 23.6
2020-03-23 21:01:43.303 LaCrosse LaCrosse_0b humidity: 44
2020.03.23 21:02:09.673 4 : sduinoRXB/msg READ: MN;D=9B66362C74AAAA000028B1CB;R=23;
2020.03.23 21:02:09.673 4 : sduinoRXB Parse_MN: Found 2-FSK Protocol id 100 -> Lacrosse mode 1
2020.03.23 21:02:09.673 4 : sduinoRXB LaCrosse_convert: ID=100, addr=45 temp=23.6 hum=44 bat=0 batInserted=128
2020.03.23 21:02:09.673 4 : sduinoRXB ParseMN: ID=100 dmsg=OK 9 45 129 4 212 44
2020.03.23 21:02:09.673 4 : sduinoRXB Dispatch: OK 9 45 129 4 212 44, -62.5 dB, dispatch
2020-03-23 21:02:09.680 LaCrosse LaCrosse_0b battery: ok
2020-03-23 21:02:09.680 LaCrosse LaCrosse_0b temperature: 23.6
2020-03-23 21:02:09.680 LaCrosse LaCrosse_0b humidity: 44Hier sind raw Nachrichten von einem anderen PCA301
2020.03.23 20:52:58.095 4 : sduinoRXB/msg READ: MN;D=0405019E8700AAAAAAAA0F13AA16ACC0540AAA49C814473A2774D208AC0B0167;N=3;R=6;
2020.03.23 20:52:58.095 4 : sduinoRXB Parse_MN: Found 2-FSK Protocol id 101 -> PCA 301
2020.03.23 20:52:58.095 5 : sduinoRXB PCA301_convert: checksumCalc=3859 checksum=3859
2020.03.23 20:52:58.095 4 : sduinoRXB PCA301_convert: translated native RF telegram PCA301 OK 24 4 5 1 158 135 0 170 170 170 170 0F13
2020.03.23 20:52:58.095 4 : sduinoRXB ParseMN: ID=101 dmsg=OK 24 4 5 1 158 135 0 170 170 170 170 0F13
2020.03.23 20:52:58.095 4 : sduinoRXB Dispatch: OK 24 4 5 1 158 135 0 170 170 170 170 0F13, -71 dB, dispatch
2020-03-23 20:52:58.097 PCA301 PCA301_019E87 on
2020.03.23 20:52:59.063 4 : sduinoRXB/msg READ: MN;D=0405019E8701AAAAAAAA8F68AAF21E3E22B4643AE51BE4A044365B2B87CDA50A;N=3;R=7;
2020.03.23 20:52:59.064 4 : sduinoRXB Parse_MN: Found 2-FSK Protocol id 101 -> PCA 301
2020.03.23 20:52:59.064 5 : sduinoRXB PCA301_convert: checksumCalc=36712 checksum=36712
2020.03.23 20:52:59.064 4 : sduinoRXB PCA301_convert: translated native RF telegram PCA301 OK 24 4 5 1 158 135 1 170 170 170 170 8F68
2020.03.23 20:52:59.064 4 : sduinoRXB ParseMN: ID=101 dmsg=OK 24 4 5 1 158 135 1 170 170 170 170 8F68
2020.03.23 20:52:59.064 4 : sduinoRXB Dispatch: OK 24 4 5 1 158 135 1 170 170 170 170 8F68, -70.5 dB, dispatch
2020-03-23 20:52:59.066 PCA301 PCA301_019E87 off
2020-03-23 20:56:17.939 PCA301 PCA301_019E87 set-statusRequest
2020.03.23 20:56:17.940 3 : PCA301 send statreq: msg=SN;N=3;D=0404019E8700FFFFFFFF7694AAAAAA;
2020.03.23 20:56:17.941 4 : set sduinoRXB raw SN;N=3;D=0404019E8700FFFFFFFF7694AAAAAA;
2020.03.23 20:56:18.071 4 : sduinoRXB/msg READ: SN;N=3;D=0404019E8700FFFFFFFF7694AAAAAA;Marcs=22
2020.03.23 20:56:18.144 4 : sduinoRXB/msg READ: MN;D=0404019E87010000000076C6AA197DCDE38D78D1BE4103CE1877F025F4F0C607;N=3;R=5;
2020.03.23 20:56:18.144 5 : sduinoRXB PCA301_convert: checksumCalc=30406 checksum=30406
2020.03.23 20:56:18.144 4 : sduinoRXB PCA301_convert: translated native RF telegram PCA301 OK 24 4 4 1 158 135 1 0 0 0 0 76C6
2020.03.23 20:56:18.144 4 : sduinoRXB ParseMN: ID=101 dmsg=OK 24 4 4 1 158 135 1 0 0 0 0 76C6
2020.03.23 20:56:18.144 4 : sduinoRXB Dispatch: OK 24 4 4 1 158 135 1 0 0 0 0 76C6, -71.5 dB, dispatch
2020-03-23 20:56:18.146 PCA301 PCA301_019E87 onVom Kopp FreeControll habe ich keine Fernbedienung, ich habe von einem sduino zum anderen gesendet.
Die Daten vom TFA 30.3155 WD sind von arthur_dent_2015, die raw Nachrichten vom cul können recht einfach in raw Format vom sduino gewandelt werden
MN;D=9A05922F8180046818480800;N=2; OK 9 40 1 4 168 47 ID=103, addr=40(28) temp=19.2 hum=47 bat=0 batInserted=0
MN;D=9D06152F5484791062004090;N=2; OK 9 52 1 4 191 47 ID=103, addr=52(34) temp=21.5 hum=47 bat=0 batInserted=0Gruß Ralf
Hallo,
ich hatte die Hoffnung, daß meine aktuelle Firmware V 4.1.x für den MapleSduino und MapleCul auch mit dem offiziellen fhem Modul von Sidey verwendet werden kann.
In der kommenden dev-r35_xFSK wird zwar das Empfangen und Senden von FSK unterstützt, aber seit der v3.4.3 kann das
get sduino raw nicht mehr zum Senden von Kommandos an die Firmware verwendet werden.
Es muss dafür das "set sduino raw" verwendet werden, was aber den Nachteil hat, daß keine Rückmeldungen von der Firmware ausgegeben werden:
https://wiki.fhem.de/wiki/SIGNALduino#Fehlerbehandlung
ZitatIn der Firmware sind die diverse Befehle eingebaut, welche über einen set raw Befehl im Modul direkt ausgeführt werden können. Sofern möglich, sollten die Abfrage von Werten aus dem Modul allerdings mit den dafür vorgesehenen Kommandos erfolgen, da die Rückmeldungen des set raw Befehls nur im Logfile ab Verbose 4 erscheinen. Die Befehle sind nützlich, wenn direkt auf den Microcontroller zugegriffen wird:
Ohne die Komfortfunktion "get sduino raw", mit dem die Rückmeldungen von der Firmware in einem Ausgabefenster ausgegeben werden, ist meine Firmware nur sehr eingeschränkt verwendbar.
Mit dem "set sduino raw" ist es recht umständlich die Rückmeldungen zu erhalten:
Wenn viele Nachrichten empfangen werden, muß zuerst mit
set raw XQden Empfang deakiviert werden, und dann der
verbose auf 4 erhöht werden.
Dann das gewünschte
set raw ...verbose wieder auf den vorherigen Wert
set raw XEIch habe nicht vor in meinen Anleitungen und Beschreibungen überall das "get raw" in "set raw" zu ändern.
Das "get raw" gilt zukünftig nur für meine angepasstes 00_Signalduino Modul, dort sind auch weitere Komfortfunktionen enthalten
https://github.com/Ralf9/RFFHEM/issues/4
Ich habe es heute auf den aktuellen Stand gebracht und werde es zukünfitig regelmässig aktualisieren.
Ich habe vor dafür hier unter "Sonstige Systeme" ein eigenes Thema aufzumachen.
Gruß Ralf
Hallo Ralf9,
ich schreibe jetzt mal hier weiter, da es nicht mit dem Maple zu tun hat.
Ich habe jetzt meinen nanoCUL mit dem Signalduino 3.3.4.0-dev200126 beschrieben.
habe bisher ein e1 und ein b1 gemacht um auf Bank1 umzuschalten,
mit der Initialisierung für Lacrosse Mode2 bekomme ich aber einen Fehler gemeldet:
raw: CW0001,012E,0246,0302,042D,05D4,06FF,0700,0802,0D21,0E65,0F6A,1088,1182,1206,1322,14F8,1556,1700,1818,1916,1B43,1C68,1D91,2211,23E9,242A,2500,2611,3D02,3E03,404d,4132,425f,4349,4454,452b,4600 Error at pos=157
Empfang bisher nix.
Kannst du mir was zu diesem Error sagen?
Gruss
Bei diesem Befehl ist schon die Kurzbeschreibung für die Version für den MapleSduino enthalten
,404d,4132,425f,4349,4454,452b,4600
Bitte verwende den Befehl unten in der History
https://forum.fhem.de/index.php/topic,106594.msg1005067.html#msg1005067
ok, hat er angenommen, trotzdem noch kein FSK Empfang.
Kannst du irgendwelche Auffälligkeiten erkennen?
V:
raw: V 3.3.4.0-dev200126 SIGNALduino cc1101 (b1) - compiled at Jan 28 2020 00:17:36
b:
raw: b=1 N=2 ccmode=3 sync=2DD4 ccconf=21656A88820622F856070018166C436891 boffs=0100
C99:
ccregAll:
ccreg 00: 01 2E 46 02 2D D4 FF 00 02 00 00 06 00 21 65 6A
ccreg 10: 88 82 06 22 F8 56 07 00 18 16 6C 43 68 91 87 6B
ccreg 20: F8 56 11 EC 2C 1A 11 41 00 59 7F 3E 88 31 0B
cc1101 reg detail - addr, name, value, (OOK default),[reset]
0x00 IOCFG2 - 0x01 (0D) [29]
0x01 IOCFG1 - 0x2E
0x02 IOCFG0 - 0x46 (2D) [3F]
0x03 FIFOTHR - 0x02 (07)
0x04 SYNC1 - 0x2D (D3)
0x05 SYNC0 - 0xD4 (91)
0x06 PKTLEN - 0xFF (3D) [0F]
0x07 PKTCTRL1 - 0x00 (04)
0x08 PKTCTRL0 - 0x02 (32) [45]
0x09 ADDR - 0x00
0x0A CHANNR - 0x00
0x0B FSCTRL1 - 0x06 [0F]
0x0C FSCTRL0 - 0x00
0x0D FREQ2 - 0x21 (10) [1E]
0x0E FREQ1 - 0x65 (B0) [C4]
0x0F FREQ0 - 0x6A (71) [EC]
0x10 MDMCFG4 - 0x88 (57) [8C]
0x11 MDMCFG3 - 0x82 (C4) [22]
0x12 MDMCFG2 - 0x06 (30) [02]
0x13 MDMCFG1 - 0x22 (23)
0x14 MDMCFG0 - 0xF8 (B9)
0x15 DEVIATN - 0x56 (00) [47]
0x16 MCSM2 - 0x07
0x17 MCSM1 - 0x00 [30]
0x18 MCSM0 - 0x18 [04]
0x19 FOCCFG - 0x16 (14) [36]
0x1A BSCFG - 0x6C
0x1B AGCCTRL2 - 0x43 (07) [03]
0x1C AGCCTRL1 - 0x68 (00) [40]
0x1D AGCCTRL0 - 0x91 (90)
0x1E WOREVT1 - 0x87
0x1F WOREVT0 - 0x6B
0x20 WORCTRL - 0xF8
0x21 FREND1 - 0x56
0x22 FREND0 - 0x11 [16]
0x23 FSCAL3 - 0xEC (E9) [A9]
0x24 FSCAL2 - 0x2C (2A) [0A]
0x25 FSCAL1 - 0x1A (00) [20]
0x26 FSCAL0 - 0x11 (1F) [0D]
0x27 RCCTRL1 - 0x41
0x28 RCCTRL0 - 0x00
0x29 FSTEST - 0x59
0x2A PTEST - 0x7F
0x2B AGCTEST - 0x3E
0x2C TEST2 - 0x88
0x2D TEST1 - 0x31
0x2E TEST0 - 0x0B
OK
ccconf:
ccconf: freq:868.300MHz bWidth:203KHz rAmpl:33dB sens:8dB (DataRate:9571.08Baud)
Modulation:2-FSK (SYNC_MODE:16/16 + carrier-sense above threshold)
bitte mach mal ein
get raw XE
schon probiert. (Antwort: OK) Trotzdem kein Empfang.
Emfpang von SlowRF funktioniert ohne Probleme.
habe momentan keine Idee mehr, außer wenn Du ein blaues 433 MHz cc1101 Modul verwendest, kann sein, daß es damit nicht funktioniert.
Ich schaue es mir heute Nachmittag/Abend mal genauer an
Im Detail kann ich nichts beitragen. Aber meine Einstellungen sehen bei selber firmware an einigen Stellen anders aus. So ist meine Baudrate z.B. nur 6.620,41.
Grüße Markus
Die Baudrate sollte so passen für Lacrosse Mode 2.
Empfangen werden soll ein TX35-IT.
Aber es ist tatsächlich ein blaues Modul RF1100SE.
Habe aber noch andere CULs. Ich probiere mal durch.
Ah, sorry. Ich nutze ja FSK f. PCA301. :-[
Seltsam. Ich habe jetzt einen anderen nanoCUL geflashed und ihn mal in den Seriellen Monitor gehangen.
Ich empfange Nachrichten.
ZB:
MN;D=97C6086A8E8A3439CDD8002C;N=2;
Auch hier stottert es bei mir. Die Nachrichten kommen also nicht kontinuierlich, sondern hören irgendwann auf und fangen dann irgendwann wieder an. Ich kann noch nicht sagen, ob dies besser/schlechter als beim Maple funktioniert, habe es nur kurz getestet.
Aber diese Nachrichten kommen im FHEM überhaupt nicht an. Hier wird nichts empfangen.
Gibt hier vielleicht Probleme bei meiner installierten Version?
version
V 3.3.4.0-dev200126 SIGNALduino cc1101 (b1) - compiled at Jan 28 2020 00:17:36
versionmodul
v3.4.5-dev_ralf_25.04.
versionprotoL
v3.4.5-dev_ralf_25.04.
Ansonsten kann ich sagen, dass ich dieses Stottern über mehrere Rechner beobachte (Windows/Intel und Linux/Arm).
Auch habe ich verschiedene Hardware (nano/Maple) und verschiedene cc1101 Funkmodule getestet.
Gibt es jemanden der Lacrosse mit dem Signalduino im Einsatz hat? Vielleicht sogar Mode 2? Dann bitte mal hier melden.
Also primär geht es mir um das Problem, dass der Empfang aufhört und irgendwann wieder einsteigt. Bei mir sind das (Ausfall-) Intervalle von 5 Minuten bis zu mehreren Stunden. Wäre interessant, ob das woanders auch ist und vielleicht nur bisher nicht aufgefallen ist.
Gruss
ZitatAber diese Nachrichten kommen im FHEM überhaupt nicht an. Hier wird nichts empfangen.
dies
MN;D=97C6086A8E8A3439CDD8002C;N=2;sollte im fhem log ungefähr so ankommen:
2020.05.06 18:01:20.366 4 : sduinoD/msg read: MN;D=97C6086A8E8A3439CDD8002C;N=2;
2020.05.06 18:01:20.366 4 : sduinoD Parse_MN: Found 2-FSK Protocol id 103 -> Lacrosse mode 2
2020.05.06 18:01:20.366 4 : sduinoD LaCrosse_convert: ID=103, addr=31 temp=20.8 channel=1 nohum=106 bat=0 batInserted=0
2020.05.06 18:01:20.366 4 : sduinoD ParseMN: ID=103 dmsg=OK 9 31 1 4 184 106
2020.05.06 18:01:20.366 5 : sduinoD Dispatch: OK 9 31 1 4 184 106, test ungleich: disabled
2020.05.06 18:01:20.366 4 : sduinoD Dispatch: OK 9 31 1 4 184 106, dispatch
2020.05.06 18:01:20.366 5 : sduinoD: dispatch OK 9 31 1 4 184 106
2020.05.06 18:01:20.401 3 : LaCrosse: Unknown device 1F, please define itDu kannst es auch mal mit der a-culw testen. Der Mode 2 wird aktiviert mit
set raw Nr2Es sollte dann sowas kommen
N0297C6086A8E8A3439CDD8002CNachtrag:
Ich habe den TX29DTH-IT, den kann ich im Mode 1 problemlos empfangen, mir sind bis jetzt noch keine Aussetzer aufgefallen
Gruß Ralf
Habe jetzt mal auf dem Nano die a-cul geflashed.
Mit diesem Empfange ich erstmal Mode2, allerdings wird es nicht dispatched:
2020.05.06 20:51:12 5: CUL/RAW: /N0297C60
2020.05.06 20:51:12 5: CUL/RAW: N0297C60/86A8EC9D422009C5B44
2020.05.06 20:51:12 4: CUL_Parse: nanoCUL868B N0297C6086A8EC9D422009C5B44
2020.05.06 20:51:12 5: nanoCUL868B: dispatch N0297C6086A8EC9D422009C5B44
2020.05.06 20:51:12 3: nanoCUL868B: Unknown code N0297C6086A8EC9D422009C5B44, help me!
Mit dem Signalduino hatte ich die Einträge im Log:
2020.05.06 16:56:47 4: sduino/msg READ: MN;D=97C6086A8EC4F32A01421083;N=2;
Allerdings sonst nichts weiter. Und im Device selbst stand auch immer:
LASTDMSG Nothing
Aber das lag vermutlich daran, dass ich Protokoll 103 nicht eingeschaltet hatte.
Ich beobachte jetzt mal den Empfang von dem nanoCUL.
Edit: ok, habe herausgefunden, dass Lacrosse in der Firmware mit aktiviert werden muss. Scheint nicht so zu sein. Aber ok. Für den test reicht das ja.
Ergebnis nach ca 13 Stunden loggen:
Stabiler Empfang ca alle 10 Sekunden.
Lediglich 5 Ausfälle/Pausen von 45 Sekunden bis maximal 5 Minuten.
Das ist jetzt die selbe Hardware, die als Signalduino Aussetzer hat.
Ich flashe jetzt wieder die Signalduino Firmware und logge weiter
Edit: Mal eine andere Frage dazu: Wird es später auch möglich sein, weitere FSK-"Protokolle" zu implementieren? Als Beispiel zB. ein Honeywell Funkgong? Der sendet mit einer anderen Baudrate. Aber das sollte doch im Grunde auch möglich sein, oder?
Update: Mit Signalduino in 6 Studen 27 "Aussetzer" gehabt. Der längste davon ca 40 Minuten. Davon 12 über 5 Minuten.
Hallo Ralf,
ich habe mal über alle Einträge hier gelesen und wollte mich schlau machen was der ccmode=4 ist.
Kannst du mich diesbezüglich aufklären?
LG
Der ccmode=4 ist noch experimentell, es ist der Versuch einer Optimierung
Hallo Zusammen,
ich versuche mich gerade am Signalduino (3.4) auf Basis eines NanoCul868. Ich hab gesehen, dass die Lacrosse Sensoren (TX29 DTH-IT) empfangen werden müssten. Leider empfange ich auf 868MHz nichts - noch nicht mal irgendwelche Rohdaten.
Ich hab die Frequenz und die weiteren Einstellungen eingestellt wie bei der a-culfw - auch das Attribut 868.300 hab ich gesetzt.
Mit der a-culfw funktioniert das problemlos in Mode Nr1.
Was muss ich denn einstellen, dass die Lacrosse Temperatur Sensoren auch mit Signaldiuno empfangen werden können?
Gruß
Markus
Hallo Markus,
Zitat von: Kent am 24 Juli 2020, 07:44:56
Hallo Zusammen,
ich versuche mich gerade am Signalduino (3.4) auf Basis eines NanoCul868. Ich hab gesehen, dass die Lacrosse Sensoren (TX29 DTH-IT) empfangen werden müssten. Leider empfange ich auf 868MHz nichts - noch nicht mal irgendwelche Rohdaten.
Ich hab die Frequenz und die weiteren Einstellungen eingestellt wie bei der a-culfw - auch das Attribut 868.300 hab ich gesetzt.
Mit der a-culfw funktioniert das problemlos in Mode Nr1.
Was muss ich denn einstellen, dass die Lacrosse Temperatur Sensoren auch mit Signaldiuno empfangen werden können?
Gruß
Markus
dein Vorhaben welches du derzeit getestet hast, ist mit deiner Version
Signalduino (3.4) auf Basis (vermutlich die offizielle) derzeit noch nicht möglich.
Die Einarbeitung erfolgt derzeit. Ich kann dir gern, die Firmware zum testen zukommen lassen und du müsstest dann auf die Developversion updaten oder du zeigst noch etwas gedult, bis wir die Einarbeitung in beiden Entwicklungszweigen (Modul und Firmware) abgeschlossen haben um diese via update Github Befehl umzustellen.
Mfg Marco
Hallo Marco,
gerne biete ich mich als Tester an. Ich kann auf 868MHZ folgende Systeme zum Test anbieten:
Lacrosse Temperatursensor
Max! Fensterkontakt
Elero Funk Rolladen
EsyLux funk Rolladensteuerung
Hörmann HSM4
Gruß
Markus
ZitatMit der a-culfw funktioniert das problemlos in Mode Nr1.
Mit der passenden Firmware und Modul funktioniert es auch seit anfang des Jahres mit dem SIGNALDuino.
Mit dem nano hast Du damit gegenüber dem cul allerdings keine großen Vorteile, außer daß es beim Batteriewechsel komfortabler ist.
ZitatMax! Fensterkontakt
Der Max! Fensterkontakt wird mit dem SIGNALDuino nicht funktionieren, das bidirektionale Protokoll einzubauen ist zu aufwändig
ZitatElero Funk Rolladen
EsyLux funk Rolladensteuerung
Hörmann HSM4
Mit welchen Modes funktionieren diese Systeme mit dem cul?
Gruß Ralf
Hallo Ralph9,
Danke für deine Antworten.
ZitatMit welchen Modes funktionieren diese Systeme mit dem cul?
Mit noch keinem :-)
Für die Elero Rollladen nutze ich den Elero USB Stick seit Jahren ohne Probleme mit FHEM
Für ESYLUX suche ich gerade noch eine Lösung und hier hab ich auf den SIGNALDuino gehofft.
Und Hörmann HSM4 funktioniert halb - Ich sehe, dass die Hörmann FB gedrückt wurde, FHEM leg auch ein Device an - Der Toggle Knopf unter FHEM ist aber ohne Funktion.
Gruß
Kent
Hallo Kent,
kannst du zu ESYLUX ein wenig mehr Details / Input liefern?
Am besten ist vielleicht, wenn du in GitHub Björn
https://github.com/RFD-FHEM/RFFHEM/issues ein Issues erstellt mit allen Details.
Liebe Grüße Marco
ZitatUnd Hörmann HSM4 funktioniert halb - Ich sehe, dass die Hörmann FB gedrückt wurde, FHEM leg auch ein Device an - Der Toggle Knopf unter FHEM ist aber ohne Funktion.
die Hörmann FB ist kein FSK es gibt dafür die Protokoll ID 69, evtl passt da im SD_UT Modul etwas noch nicht so richtig
https://forum.fhem.de/index.php/topic,71877.msg655120.html#msg655120
ZitatFür die Elero Rollladen nutze ich den Elero USB Stick seit Jahren ohne Probleme mit FHEM
Ich hab mal danach gesucht und nur gefunden, daß es ein herstellereigenes bidirektionales Funkprotokoll ist.
ZitatFür ESYLUX suche ich gerade noch eine Lösung und hier hab ich auf den SIGNALDuino gehofft.
Du kannst mal versuchen beim sduino die Frequenz auf 868.3 zu ändern und beim SIGNALDuino Modul das Attribut verbose auf 4 zu ändern.
Wenn dann beim Drücken einer Taste was empfangen wird, kannst Du unter "Sonstige Systeme" oder
https://github.com/RFD-FHEM/RFFHEM/issues
ein neues Thema aufmachen und die emfangenen RAW Nachrichten dort posten.
Gruß Ralf
Zitat von: Kent am 24 Juli 2020, 09:52:09
Hallo Marco,
gerne biete ich mich als Tester an. Ich kann auf 868MHZ folgende Systeme zum Test anbieten:
Lacrosse Temperatursensor
Max! Fensterkontakt
.....
@Kent
diese kannst du mit einem JeeLink empfangen. (https://forum.fhem.de/index.php/topic,93280.0.html) oder Original (https://forum.fhem.de/index.php/topic,43672.0.html)
pejonp
Hallo,
ich möchte mich an dieser Stelle für eure Arbeit an der FSK Implementierung bedanken.
So ist es mir gelungen den DP100 Bodenfeuchte Sensor von froggit zu integrieren.
Den sduino mit get sduino raw CW0001,012E,0246,0302,042D,05D4,06FF,0700,0802,0D21,0E65,0F6A,1009,115C,1206,1322,14F8,1556,1700,1818,1916,1B43,1C68,1D91,2211,23E9,242A,2500,2611,3D00,3E03 auf FSK schalten.
Der patch erledigt die notwendigen Änderungen an den Dateien
FHEM/00_SIGNALduino.pm
FHEM/14_SD_WS.pm
FHEM/lib/signalduino_protocols.pm
Der SIGNALduino hat die Version V 3.3.4.0-dev200126
Das Modul die Version v3.4.5-dev_ralf_04.08.
Protokol v3.4.5-dev_ralf_05.08.
Änderungsvorschläge am Code sind ausdrücklich erwünscht.
Schöne Grüße,
Jörg
Hallo Ralph9,
danke für Deine Antwort. Ich hab bei Github mal ein Issue mit allen Infos und den empfangenen Nachrichten erstellt
https://github.com/RFD-FHEM/RFFHEM/issues/897
Gruß und Dank
Kent
ZitatSo ist es mir gelungen den DP100 Bodenfeuchte Sensor von froggit zu integrieren.
Ich habe es mir mal angeschaut.
Du verwendest nicht die selben Registerwerte wie "Mode 1 - IT+ 17.241 kbps (LaCrosse)"
Mode 1 hat eine bWidth:203KHz und Du verwendest eine bWidth:812KHz.
Wird bei einer bWidth:203KHz nichts empfangen?
Was für ein cc1101 Modul verwendest Du?
Ein paar raw-Nachrichten mit verschiedenen Batteriespannungen und Feuchtigkeitswerten wären hilfreich.
Die raw-Nachrichten sehen ungefähr so aus: MN;D=51...
Gruß Ralf
Du hast richtig vermutet. Mit bWidth:203KHz habe ich nichts empfangen.
Alles kleiner als bWidth:812KHz hat nicht funktioniert.
Das Modul ist vom eiligen Chinesen
https://de.aliexpress.com/item/32924239954.html (https://de.aliexpress.com/item/32924239954.html)
Die Antenne von Technikkram
https://www.amazon.de/gp/product/B079NZ9W54/ (https://www.amazon.de/gp/product/B079NZ9W54/)
Hier ein paar raw messages
MN;D=5100C6BF107F21F8C2FFFFFF;R=20;
MN;D=5100C6BF107F1FF8BAFFFFFF;R=20;
MN;D=5100C6BF107F21F8C2FFFFFF;R=20;
MN;D=5100C6BF107F21F8C0FFFFFF;R=21;
MN;D=5100C6BF107F21F8C0FFFFFF;R=19;
MN;D=5100C6BF107F21F8C2FFFFFF;R=20;
MN;D=5100C6BF107F21F8C2FFFFFF;R=20;
MN;D=5100C6BF107F21F8C2FFFFFF;R=19;
Wenn ich sonst noch etwas tun kann, lass es mich bitte wissen.
Schöne Grüße,
Jörg
ZitatDas Modul ist vom eiligen Chinesen
das sollte passen
ZitatHier ein paar raw messages
Da fehlen noch die beiden Prüfsummen.
Reg 03, CC1100_FIFOTHR = 2, // 12 byte in RXBitte versuche es bei Register 3 mal mit 3 (14 byte in RX)
Hilfreich wären auch Nachrichten mit schwächeren Batterien, dann müsste auch die ID sich ändern
Gruß Ralf
Hab was länger gebraucht bis ich den syntax hatte 8)
Nach set sduino868 ccreg 0303 sieht es so aus
MN;D=5100C6BF107F1FF8BAFFFFFF75A81402;R=14;
MN;D=5100C6BF107F1FF8BAFFFFFF75A81A8B;R=19;
MN;D=5100C6BF107F1FF8BAFFFFFF75A82152;R=22;
MN;D=5100C6BF107F1FF8BAFFFFFF75A80561;R=20;
Muss mal schaun, ob ich irgendwo eine schwächere Batterie finde.
Die ID 00C6BF steht auf einem Sticker am Sensor. Besteht trotzdem die Möglichkeit, dass die sich ändert?
Grüße,
Jörg
Die ID 00C6BF steht auf einem Sticker am Sensor. Besteht trotzdem die Möglichkeit, dass die sich ändert?
Ja, kann sein, daß dies eine feste ID ist.
Bei den Nachrichten sind alle Prüfsummen gleich.
Zum Einbauen und Testen der Prüfsummen sind Nachrichten mit verschiedenen Prüfsummen hilfreich.
Sorry, für meine Unwissenheit. Ich nehme an 75A8 ist die Prüfsumme. Wenn das so ist hätte ich folgendes im Angebot
MN;D=5100C6BF107F1FF8BAFFFFFF75A818CC
MN;D=5100C6BF107F1FF8B9FFFFFFE91B0CE8
Mehr könnte ich liefern wenn die Bodenfeuchte weiter sinkt.
Ja 75A8 und E91B sind die Prüfsummen
Die 10 sind die 1.6V der Batterie
Hier noch ein paar raw messages.
Ich hoffe, dass die aussagekräftig sind
Schöne Grüße,
Jörg
MN;D=5100C6BF107F1FC0000000000000
MN;D=5100C6BF107F1FF8B8FFFFFF72A3
MN;D=5100C6BF107F1FF8B9FFFFFFE91B
MN;D=5100C6BF107F1FF8BAFFFFFF7528
MN;D=5100C6BF107F1FF8BAFFFFFF75A8
MN;D=5100C6BF107F1FF8BBFFFFFFEE22
MN;D=5100C6BF107F21F8C0FFFFFF619C
MN;D=5100C6BF107F21F8C1FFFFFFFA36
MN;D=5100C6BF107F21F8C2FFFFFF66A3
MN;D=5100C6BF107F21F8C2FFFFFF66B3
MN;D=5100C6BF107F22F8C0FFFFDF96D6
MN;D=5100C6BF107F22F8C3FFFFFF0043
MN;D=5100C6BF107F22F8C3FFFFFF0443
MN;D=5100C6BF107F22F8C4FFFFFF96D6
MN;D=5100C6BF107F22F8C5FFFFFF0D4E
MN;D=5100C6BF107F22F8C6FFFFFF91D3
MN;D=5100C6BF107F23F8C7FFFFFF5DA1
MN;D=5100C6BF107F23F8C8FFFFFFD318
MN;D=5100C6BF107F23F8C8FFFFFFD31C
MN;D=5100C6BF107F23F8C9FFFFFF488E
MN;D=5100C6BF107F2AF8D4FFFFFF96D7
MN;D=5100C6BF107F61F8D3FFFFFFFA36
MN;D=5100C6BF107F9FF8BAFFFFFF75A8
MN;D=5100C6BF10FF1FF8B9FFFFFFE91B
MN;D=5100C7BF107F22F8C3FFFFFF0443
MN;D=5104C6BF107F23F8C4FFFFFF96D6
MN;D=5115D40DAE5D767C8AA4212C7DCE
MN;D=5120C6BF107F1FF8BAFFFFFF75E8
MN;D=5120C6BF107F22F8C3FFFFFF0443
MN;D=5120C6FF187F1FF8BEFFFFFF75A8
MN;D=5140C6BF127FA1F9E3FFFFFFFA76
MN;D=51B282D5E3F6C87A935A4B5D71A2
Danke für die raw messages, es sind auch einige fehlerhafte dabei, aber durch die Prüfsummen werden diese erkannt.
ich habe Deinen Patch etwas angepasst und erweitet:
https://forum.fhem.de/index.php/topic,109056.msg1090771.html#msg1090771
Gruß Ralf
Super vielen Dank dafür.
Musste in der signalduino_protocols.pm noch defaultNoN auf 1 setzen. Erst danach wurde das device per autocreate angelegt.
--- signalduino_protocols.pm-ralf9.orig 2020-10-08 13:03:24.055640900 +0200
+++ signalduino_protocols.pm 2020-10-08 13:31:19.338509672 +0200
@@ -2778,6 +2778,7 @@
id => '107',
knownFreqs => '868.3',
N => 6,
+ defaultNoN => '1',
datarate => '17257.69',
sync => '2DD4',
modulation => '2-FSK',
Grüße Jörg
Hast Du die Speicherbank konfiguration aktualisiert. Es muß N=6 sein, damit bei den rawNachrichten ";N=6" angehängt wird, z.B.
MN;D=5100C6BF107F1FF8B9FFFFFFE91B0CE8;R=14;N=6;
Gruß Ralf
Danke für den Hinweis. Nach einem
get raw CW0001,012E,0246,0303,042D,05D4,06FF,0700,0802,0D21,0E65,0F6A,1009,115C,1206,1322,14F8,1556,1700,1818,1916,1B43,1C68,1D91,2211,23E9,242A,2500,2611,3D06,3E03
musste ich noch die cc1101_freq auf 868.350 setzen. Seit dem läufts ohne defaultNoN. Nochmal vielen Dank für deinen Support.
Schöne Grüße,
Jörg
Zitatmusste ich noch die cc1101_freq auf 868.350 setzen.
Ich habe in der cc1101 registerkonfig die Freqenz auf 868.350 geändert:
https://forum.fhem.de/index.php/topic,106594.msg1005067.html#msg1005067
Hast Du die 868.350 durch probieren herausgefunden oder steht dies irgendwo?
Gruß Ralf
War mehr oder weniger Zufall, dass ich die 868,350 Mhz eingestellt habe. In der Doku steht lediglich 868Mhz.
Grüße,
Jörg
Kannst du denn jetzt wieder mit der Bandbreite auf niedrigere Werte gehen?
Es wäre günstig, wenn du versuchst die Frequenz genauer zu ermitteln, in dem du die Bandbreite niedriger stellst und die Frequenz in Schritten von 50 kHz anpasst, bis du die besten Empfangsergebnisse hast.
Hallo zusammen,
Das empfangen von FSK Signalen über eine 868.X Mhz fernbedienung funktionert wunderbar.
Das Signal ist erstaulich sauber von der FB und stark soweit ich das mit Hilfe von URH beurteilen kann.
Nun ist aber das Problem bei mir mit dem Senden über den nanoCUL via SignalDUINO.
Ich verwende einen nanoCUL mit CC1101 und nachfolgender SIGNALDUINO version:
V 3.3.4-dev200914 SIGNALduino cc1101 (b0) - compiled at Sep 17 2020 23:37:47
Das identische Sendesignal welches auch von der FB geschickt wird) ist sehr schwach beim senden und kann über den URH (im vergleich zur FB) nicht interpretiert werden (sieht auch schlecht aus)
Auch das spektrum sieht entsprechend schwach aus.
Was ich bereits versucht habe
* Anpassung der frquenz (da ich vermute das zwischen Senden und Empfangen ~0.04 Mhz abweichungen sind / abhängig von DEVIATN register)
* Anpassung des DEVIATN register (1530 / 1540, etc....)
* Bandwidth durch probierten
* sens, ..
Alles brachte keinen wesentlichen Erfolg.
Hat jemand noch eine Idee?
Gibt es ggf. bessere sender als den nanoCUL für FSK auf 868Mhz oder hilft es eine andere Antenne einzusetzen?
Hast Du die Sendeleistung erhöht?
set cc1101_patable_868 10_dBm
Da erhalte ich:
Unknown argument cc1101_patable_868, choose one of supported commands
In FHEM zeigt es mir nur "cc1101_patable"
Ich ging davon aus, daß Du meine Variante der 00_SIGNALduino.pm verwendest. versionmodul v3.4.5
Mit dem offiziellen 00_SIGNALduino.pm Modul von Sidey ist die Bedienung etwas umständlicher, da die Komfortfunktionen fehlen.
Da heisst es "set cc1101_patable"
Wenn ein "get cc1101_patable" C2 ergibt, dann sind es bei 868MHz 10_dBm
Zitat von: Ralf9 am 18 Dezember 2020, 16:12:26
Mit dem offiziellen 00_SIGNALduino.pm Modul von Sidey ist die Bedienung etwas umständlicher, da die Komfortfunktionen fehlen.
Könntest du mal bitte näher erläutern, welche "Komfortfunktionen" fehlen?
Vielleicht können wir ja etwas nachbessern.
ZitatKönntest du mal bitte näher erläutern, welche "Komfortfunktionen" fehlen?
z.B.
In den aktuellen Versionen des offiziellen 00_SIGNALduino.pm Moduls funktioniert "get sduino raw" nicht mehr.
Siehe auch im Signalduino wiki. Es muss jetzt das "set sduino raw" verwendet werden wo keine Rückmeldungen angezeigt werden.
Die Rückmeldungen des set raw Befehls erscheinen nur im Logfile ab Verbose 4
Mit "get sduino ccreg" lässt sich das Statusregister (z.B. 31 oder 35) nicht mehr auslesen.
Gruß Ralf
Zitat von: ole1986 am 23 Dezember 2020, 14:40:12
Auf 433 laufen intertechno und auf 868 eben etwas anderes. Ich habe keine Ahnung ob es für die Intertechno ein protokoll - Wie finde ich das heraus?
Meinst Du mit 868 dies?
ZitatDas empfangen von FSK Signalen über eine 868.X Mhz fernbedienung funktionert wunderbar.
Das Signal ist erstaulich sauber von der FB und stark soweit ich das mit Hilfe von URH beurteilen kann.
Kurz dazwischen eingeschoben: Anbei ein Update meines Sciptes cc1101regs.pl zum Auslesen und interpretieren der cc1101-Register für diejenigen die es intersssiert.
In Zeile 15 müsst Ihr den Namen Eures SIGNALduino-Devices eintragen. Dann könnt Ihr das Script mit
./cc1101regs.pl
unter Unix ausführen.
Zitat von: plin am 02 Januar 2021, 09:47:50
Kurz dazwischen eingeschoben: Anbei ein Update meines Sciptes cc1101regs.pl zum Auslesen und interpretieren der cc1101-Register für diejenigen die es intersssiert.
In Zeile 15 müsst Ihr den Namen Eures SIGNALduino-Devices eintragen. Dann könnt Ihr das Script mit
./cc1101regs.pl
ausführen.
Nun, bei mir funktioniert es trotz entsprechender Anpassung in Zeile 15 weder in der Command-Line noch in einem FHEM Telnet Fenster. Und auch nicht direkt unter UNIX. :-\
Zitat von: Reinhard.M am 02 Januar 2021, 17:53:25
Nun, bei mir funktioniert es trotz entsprechender Anpassung in Zeile 15 weder in der Command-Line noch in einem FHEM Telnet Fenster. Und auch nicht direkt unter UNIX. :-\
ok, was gibt das Scipt denn aus?
1. Muss unter Unix am command prompt ausgeführt werden.
2. möglicherweise fehlen Dir noch ein paar Libs für
use IO::Socket;
use Socket;
use Data::Dumper;
Das Script gibt nichts aus. Und ob die genannten Libs installiert sind - keine Ahnung. Wüsste im Moment auch nicht wie und wo ich das prüfe bzw. hinzufüge. Sorry. :-[
Zitat von: Reinhard.M am 02 Januar 2021, 18:55:36
Das Script gibt nichts aus. Und ob die genannten Libs installiert sind - keine Ahnung. Wüsste im Moment auch nicht wie und wo ich das prüfe bzw. hinzufüge. Sorry. :-[
Wie sieht die Ausgabe eines
get <mysduinodevice> ccreg 99 aus?
Übersichtlich :)
Zitat
ccreg 00: 0D 2E 2D 07 D3 91 3D 04 32 00 00 06 00 10 B0 71
ccreg 10: 57 C4 30 23 B9 00 07 00 18 14 6C 07 00 90 87 6B
ccreg 20: F8 56 11 EF 0B 3D 1F 41 00 59 7F 1F 88 31 0B
cc1101 reg detail - addr, name, value, (OOK default),[reset]
0x00 IOCFG2 - 0x0D [29]
0x01 IOCFG1 - 0x2E
0x02 IOCFG0 - 0x2D [3F]
0x03 FIFOTHR - 0x07
0x04 SYNC1 - 0xD3
0x05 SYNC0 - 0x91
0x06 PKTLEN - 0x3D [0F]
0x07 PKTCTRL1 - 0x04
0x08 PKTCTRL0 - 0x32 [45]
0x09 ADDR - 0x00
0x0A CHANNR - 0x00
0x0B FSCTRL1 - 0x06 [0F]
0x0C FSCTRL0 - 0x00
0x0D FREQ2 - 0x10 [1E]
0x0E FREQ1 - 0xB0 [C4]
0x0F FREQ0 - 0x71 [EC]
0x10 MDMCFG4 - 0x57 [8C]
0x11 MDMCFG3 - 0xC4 [22]
0x12 MDMCFG2 - 0x30 [02]
0x13 MDMCFG1 - 0x23 [22]
0x14 MDMCFG0 - 0xB9 [F8]
0x15 DEVIATN - 0x00 [47]
0x16 MCSM2 - 0x07
0x17 MCSM1 - 0x00 [30]
0x18 MCSM0 - 0x18 [04]
0x19 FOCCFG - 0x14 [36]
0x1A BSCFG - 0x6C
0x1B AGCCTRL2 - 0x07 [03]
0x1C AGCCTRL1 - 0x00 [40]
0x1D AGCCTRL0 - 0x90 [91]
0x1E WOREVT1 - 0x87
0x1F WOREVT0 - 0x6B
0x20 WORCTRL - 0xF8
0x21 FREND1 - 0x56
0x22 FREND0 - 0x11 [16]
0x23 FSCAL3 - 0xEF (E9) [A9]
0x24 FSCAL2 - 0x0B (2A) [0A]
0x25 FSCAL1 - 0x3D (00) [20]
0x26 FSCAL0 - 0x1F [0D]
0x27 RCCTRL1 - 0x41
0x28 RCCTRL0 - 0x00
0x29 FSTEST - 0x59
0x2A PTEST - 0x7F
0x2B AGCTEST - 0x1F
0x2C TEST2 - 0x88
0x2D TEST1 - 0x31
0x2E TEST0 - 0x0B
Zitat von: Reinhard.M am 02 Januar 2021, 20:20:34
Übersichtlich :)
Ich habe das Script angepasst und im Post aktualisiert. Neues Spiel - neues Glück :-)
Passt und funktioniert :)
Beim Ausgabewert würde ich mir noch das Format des Ausgabewertes wünschen, also Hex oder Dec. Binär erkennt man ja meistens so.
Hallo @Ralf
ich habe heute deine Version mal getestet und musste feststellen, das ein Dispatch von Kopp nicht funktioniert.
Zitat von: Ralf9 am 05 Januar 2020, 01:32:06
Der Empfang von KoppFreeControl funktioniert bei mir jetzt auch.
Damit auch der Dispatch funktioniert musste ich im 14_CUL_WS.pm Modul den Match Eintrag ändern, sonst wurde ein CUL_WS Sensor angelegt.
von
$hash->{Match} = "^K.....";
nach
$hash->{Match} = "^K[A-Fa-f0-9]{5,}";
Dies ist die neue Protokoll ID
"102" => # Kopp
{
name => 'KoppFreeControl',
id => '102',
datarate => '4785.5',
sync => 'AA54',
modulation => 'GFSK',
match => '^0.*', # fuer eine regexp Pruefung am Anfang vor dem method Aufruf
clientmodule => 'Kopp',
method => \&main::SIGNALduino_KoppFreeControl,
}
2020.01.05 01:09:54.504 4 : sduinoD/msg get raw: MN;D=07FA5E1721CC0F02FE000000000000;
2020.01.05 01:09:54.504 4 : sduinoD: Found GFSK Protocol id 102 -> KoppFreeControl
2020.01.05 01:09:54.504 4 : sduinoD KoppFreeControl: dmsg=07FA5E1721CC0F02FE000000000000 anz=8 checksum=254 ok
2020.01.05 01:09:54.504 4 : sduinoD ParseMN: ID=102 dmsg=kr07FA5E1721CC0F02
2020.01.05 01:09:54.504 4 : sduinoD Dispatch: kr07FA5E1721CC0F02, dispatch
2020.01.05 01:09:54.504 2 : KOPP_FC_Parse: name: sduinoD code: FA5E 21 Specialkey:short
2020-01-05 01:09:54.506 KOPP_FC culfsk on
Kannst du bitte mit dem orginalem Kopp Modul und deiner Version von
update all https://raw.githubusercontent.com/Ralf9/RFFHEM/master/controls_ralf9_signalduino.txtmal bitte die RAW
MN;D=07FA5E1721CC0F02FE000000000000;N=4; testen.
Mir gelang es nicht.
2021.02.04 17:57:40 4: sduino_dummy/msg get raw: MN;D=07FA5E1721CC0F02FE000000000000;N=4;
2021.02.04 17:57:40 4: sduino_dummy Parse_MN: Found GFSK Protocol id 102 -> KoppFreeControl
2021.02.04 17:57:40 4: sduino_dummy KoppFreeControl: dmsg=07FA5E1721CC0F02FE000000000000 anz=8 checksum=254 ok
2021.02.04 17:57:40 4: sduino_dummy ParseMN: ID=102 dmsg=kr07FA5E1721CC0F02
2021.02.04 17:57:40 4: sduino_dummy Dispatch: kr07FA5E1721CC0F02, Dropped (1) due to short time and equal msg
2021.02.04 17:58:04 4: sduino_dummy/msg get raw: MN;D=07FA5E1721CC0F02FE000000000000;N=4;
2021.02.04 17:58:04 4: sduino_dummy Parse_MN: Found GFSK Protocol id 102 -> KoppFreeControl
2021.02.04 17:58:04 4: sduino_dummy KoppFreeControl: dmsg=07FA5E1721CC0F02FE000000000000 anz=8 checksum=254 ok
2021.02.04 17:58:04 4: sduino_dummy ParseMN: ID=102 dmsg=kr07FA5E1721CC0F02
2021.02.04 17:58:04 4: sduino_dummy Dispatch: kr07FA5E1721CC0F02, dispatch
2021.02.04 17:58:04 2: KOPP_FC_Parse: name: sduino_dummy code: FA5E 21 Specialkey:short
2021.02.04 17:58:04 2: KOPP_FC_Parse: Device not defined for message kr07FA5E1721CC0F02
2021.02.04 17:58:04 3: sduino_dummy: Unknown code kr07FA5E1721CC0F02, help me!
2021.02.04 17:58:10 4: sduino_dummy/msg get raw: MN;D=07FA5E1721CC0F02FE000000000000;N=4;
2021.02.04 17:58:10 4: sduino_dummy Parse_MN: Found GFSK Protocol id 102 -> KoppFreeControl
2021.02.04 17:58:10 4: sduino_dummy KoppFreeControl: dmsg=07FA5E1721CC0F02FE000000000000 anz=8 checksum=254 ok
2021.02.04 17:58:10 4: sduino_dummy ParseMN: ID=102 dmsg=kr07FA5E1721CC0F02
2021.02.04 17:58:10 4: sduino_dummy Dispatch: kr07FA5E1721CC0F02, dispatch
2021.02.04 17:58:10 2: KOPP_FC_Parse: name: sduino_dummy code: FA5E 21 Specialkey:short
2021.02.04 17:58:10 2: KOPP_FC_Parse: Device not defined for message kr07FA5E1721CC0F02
2021.02.04 17:58:10 3: sduino_dummy: Unknown code kr07FA5E1721CC0F02, help me!Hast du eine Erklärung woran es liegt?
MfG Marco
Das Dispatch funktioniert nur, wenn das Kopp Device von Hand angelegt wurde.
So wies aussieht gibts beim Kopp Modul kein Autocreate
Gruß Ralf
Gibt's auch 433 MHz Sensoren die eine Art FSK senden oder senden die immer ASK?
https://forum.fhem.de/index.php/topic,113811.msg1081334.html
Gruß Ralf
Hi Ralf,
Sensor kenne ich keinen. Die Betty macht GFSK mit dem CUL(vermutlich nur von mir genutzt). Brauchst Du Tester für den S'duino ?
Grüße Markus
GFSK mit dem CUL kenn ich nur Kopp gibt's da noch andere?
Gibts GFSK auch bei 433MHz?
Betty ist 433. Aber halt Bastelprojekt.
kann der cc1101 auch eine FSK_PULSE_PCM Modulation?
es geht um das BRESSER 5-in-1 Comfort Wetter Center
https://www.bresser.de/Wetter-Zeit/Wetterstationen/BRESSER-5-in-1-Comfort-Wetter-Center-mit-Farbdisplay.html
siehe auch hier
https://forum.fhem.de/index.php/topic,78809.0.html
hier
https://github.com/merbanan/rtl_433
https://github.com/merbanan/rtl_433/blob/master/src/devices/bresser_5in1.c
steht darüber folgendes
Preamble: aa aa aa aa aa 2d d4
Packet payload without preamble (203 bits):
modulation = FSK_PULSE_PCM
short_width = 124
long_width = 124
reset_limit = 25000
Nachtrag: hier steht dazu auch noch was
https://github.com/merbanan/rtl_433/issues/719#issuecomment-388896758
Gruß Ralf
Der Beitrag https://github.com/merbanan/rtl_433/issues/719#issuecomment-388896758 ist sehr interessant. Ich kann zumindest bestätigen, dass ich durch diesen Kommandozeilenaufruf die nachfolgende JSON-Ausgabe im 12s-Raster bekomme, die auch tatsächlich die Werte enthält, die im Bresser-Display angezeigt werden:
rtl_433 -f 868272000 -F json -R 119
{"time" : "2021-04-10 19:13:38", "model" : "Bresser-5in1", "id" : 67, "battery_ok" : 1, "temperature_C" : 22.800, "humidity" : 35, "wind_max_m_s" : 0.000, "wind_avg_m_s" : 0.200, "wind_dir_deg" : 157.500, "rain_mm" : 4.000, "mic" : "CHECKSUM"}
Die Bresser-5-in-1 entspricht also dem in rtl_433 implementierten Gerätetyp 119. Es bleibt also die spannende Frage, ob es möglich ist, die FSK-PCM im CC1101 zu realisieren.
Wenn das Spektrum, wie hier beschrieben 2 Spitzen hat, dann müsste es 2-FSK sein
https://wiki.fhem.de/wiki/Unbekannte_Funkprotokolle#Sendefrequenz_und_Frequenzhub
Der Frequenzhub (DEVIATN) ist (obere Frequenz - untere Frequenz) / 2
Wie man bei verwendung des cc1101 FIFO die datarate ermittelt, dazu habe ich noch nichts gefunden.
Es muß auch noch das FIFO_THR Register (threshold für FIFO) angepasst werden. Beim Bresser müsste 5 (24 Bytes in RX FIFO) oder 6 (28 Bytes in RX FIFO) passen
Der sync (2d d4) ist der gleiche wie bei Lacrosse.
Gruß Ralf
hier sind weitere Infos zu FSK mit dem SIGNALDuino:
Ich hab mir mal dies angeschaut:
https://github.com/merbanan/rtl_433
https://github.com/merbanan/rtl_433/tree/master/src/devices
demnach gibt es außer der FSK_PCM die u.a. bei Lacrosse verwendet wird auch noch FSK_PWM
Ermittlung der Frequenz und Frequenzhub (DEVIATN) , siehe vorherige Nachricht.
FSK_PCM:
- Es wird für RX und TX der FIFO des cc1101 verwendet.
- Damit der Begin der Nachricht erkannt wird muß ein SYNC angegeben werden.
- Es muß auch im FIFOTHR Reg ein threshold für den RX FIFO angegeben werden
z.B. bei Lacrosse
03 CC1100_FIFOTHR, 2, // 12 byte in RX
04 CC1100_SYNC1, 0x2d,
05 CC1100_SYNC0, 0xd4,
Außerdem muß noch in dem cc1101 Reg 0x12 MDMCFG2 der SYNC_MODE und das MOD_FORMAT angegeben werden
z.B.
0x06 - Modulation:2-FSK (SYNC_MODE:16/16 + carrier-sense above threshold)
oder
0x02 - Modulation:2-FSK (SYNC_MODE:16/16)
Damit der cc1101 FIFO verwendet wird, sind auch noch die folgenden Register einstellungen notwendig:
00 IOCFG2 01 Associated to the RX FIFO: Asserts when RX FIFO is filled at or above the RX FIFO threshold or the end of packet is reached
02 IOCFG0 46
08 PKTCTRL0 02 Normal mode, use FIFOs for RX and TX
Damit bei meiner firmware die Daten aus dem FIFO auch als MN-Nachrichten ans fhem geschickt werden, muß noch die ccmode Konfigurationsvarible gesetzt werden
ccmode 4 oder 3 bei Lacrosse
oder bei anderen evtl
ccmode 1 oder 2
Als Vorlage für ein neues Protokoll ist eine vorhandenes z.B. Mode 1 - IT+ zu empfehlen
FSK_PWM:
- es wird der asynchronous serial mode verwendet (RX: Data out GDO2, TX: GDO0)
- der cc1101 FIFO wird nicht verwendet
Außerdem muß noch in dem cc1101 Reg 0x12 MDMCFG2 der SYNC_MODE und das MOD_FORMAT angegeben werden, mit SYNC_MODE = 0 wird das sync-word deaktiviert
z.B.
0 - Modulation:2-FSK
Damit der asynchronous serial mode verwendet wird, sind auch noch die folgenden Register einstellungen notwendig:
00 IOCFG2 0D Serial Data Output. Used for asynchronous serial mode.
02 IOCFG0 2D
08 PKTCTRL0 32 Asynchronous serial mode, Data out GDO2
Damit bei meiner firmware die Daten auch als MU-,MS- oder MC-Nachrichten ans fhem geschickt werden, muß noch die ccmode = 0 Konfigurationsvarible gesetzt werden
Als Vorlage für ein neues Protokoll ist die SlowRF (factorydefault) zu empfehlen
Damit das Einstellen der deviation und datarate einfacher geht, gibts bei der dev Version meiner Variante der 00_SIGNALduino.pm 2 neue set Befehle
set sduino cc1101_deviatn
set sduino cc1101_dataRate
außerdem wird jetzt beim "get sduino ccconf" auch das DEVIATN angezeigt
https://forum.fhem.de/index.php/topic,111653.msg1058900.html#msg1058900
Gruß Ralf
Hallo,
ich hab mal versucht, die Infos auf die Bresser-Wetterstation anzuwenden. Dazu habe ich meinen Maple-Signalduino wie folgt konfiguriert:
ccregAll:
ccreg 00: 01 2E 46 1A 2D D4 FF 00 02 00 00 06 00 21 65 6A
ccreg 10: 89 5C 02 22 F8 53 07 00 18 16 6C 43 68 91 87 6B
ccreg 20: F8 56 11 EB 0E 3C 11 41 00 59 7F 3E 88 31 0B
cc1101 reg detail - addr, name, value, (OOK default),[reset]
0x00 IOCFG2 - 0x01 (0D) [29]
0x01 IOCFG1 - 0x2E
0x02 IOCFG0 - 0x46 (2D) [3F]
0x03 FIFOTHR - 0x1A (07)
0x04 SYNC1 - 0x2D (D3)
0x05 SYNC0 - 0xD4 (91)
0x06 PKTLEN - 0xFF (3D) [0F]
0x07 PKTCTRL1 - 0x00 (04)
0x08 PKTCTRL0 - 0x02 (32) [45]
0x09 ADDR - 0x00
0x0A CHANNR - 0x00
0x0B FSCTRL1 - 0x06 [0F]
0x0C FSCTRL0 - 0x00
0x0D FREQ2 - 0x21 (10) [1E]
0x0E FREQ1 - 0x65 (B0) [C4]
0x0F FREQ0 - 0x6A (71) [EC]
0x10 MDMCFG4 - 0x89 (57) [8C]
0x11 MDMCFG3 - 0x5C (C4) [22]
0x12 MDMCFG2 - 0x02 (30)
0x13 MDMCFG1 - 0x22 (23)
0x14 MDMCFG0 - 0xF8 (B9)
0x15 DEVIATN - 0x53 (00) [47]
0x16 MCSM2 - 0x07
0x17 MCSM1 - 0x00 [30]
0x18 MCSM0 - 0x18 [04]
0x19 FOCCFG - 0x16 (14) [36]
0x1A BSCFG - 0x6C
0x1B AGCCTRL2 - 0x43 (07) [03]
0x1C AGCCTRL1 - 0x68 (00) [40]
0x1D AGCCTRL0 - 0x91 (90)
0x1E WOREVT1 - 0x87
0x1F WOREVT0 - 0x6B
0x20 WORCTRL - 0xF8
0x21 FREND1 - 0x56
0x22 FREND0 - 0x11 [16]
0x23 FSCAL3 - 0xEB (E9) [A9]
0x24 FSCAL2 - 0x0E (2A) [0A]
0x25 FSCAL1 - 0x3C (00) [20]
0x26 FSCAL0 - 0x11 (1F) [0D]
0x27 RCCTRL1 - 0x41
0x28 RCCTRL0 - 0x00
0x29 FSTEST - 0x59
0x2A PTEST - 0x7F
0x2B AGCTEST - 0x3E
0x2C TEST2 - 0x88
0x2D TEST1 - 0x31
0x2E TEST0 - 0x0B
Verbose für den Signalduino habe ich auf 5 gestellt.
Parallel dazu habe ich meinen SDR-Stick mit rtl_433 angesprochen und die von dort versendeten MQTT-Telegramme in fhem eingebunden, also einen MQTT2_SERVER, der dann wiederum automatisch ein MQTT2_DEVICE für die Wetterstation nebst Readings angelegt hat. Im Log file sieht man nun also chronologisch fortlaufend beide Signale: die vom SDR-Stick empfangenen und interpretierten Daten, sowie die Telegramme, die mir der Signalduino liefert und denselben Inhalt haben müssten.
Ich bin mir zwar nicht zu 100% sicher, dass das wirklich so zusammen passt, aber ich wüßte auch nicht, was der Signalduino sonst empfangen haben könnte. Aber weiter komme ich jetzt nicht. Kann man mit diesem Log etwas anfangen? Falls es die Daten von der Wetterstation sind: was müßte jetzt wo implementiert werden?
Die Log-Datei ist angehängt.
Gruß
beaune
Die empfangenen MN-Nachrichten passen noch nicht.
Bitte versuche es mal mit 0x03 FIFOTHR - 0x06
evtl passt auch die datarate und DEVIATN noch nicht ganz
Gruß Ralf
Bei der Deviation bin ich mir relativ sicher, die beiden Frequenzen werden von rtl_433 ja auch ausgespuckt, so dass sich die Differenz leicht errechnen läßt.
Hinsichtlich der Datarate kann es sehr gut sein, dass die nicht stimmt. Mir ist allerdings auch nicht klar, wie ich die bestimmen kann. Beim rtl_433 muß man nur ne Samplerate angeben, und de ist da per Default 25KHz. Damit klappt der Empfang. Die Datarate kann dann ja max. die Hälte davon sein, aber wie kann ich das weiter konkretisieren? Oder was wären sinnvolle Tests?
Und dann würde mich noch inzeressieren, wie man feststellen kann, ob die Daten passen könnten. Ich kann an den MN-Telegrammen im fhem-Log nichts erkennen. Wie müßten die denn etwa aussehen, wenn sie richtig wären?
Die Daten sehen ungefähr so aus wie hier beschrieben:
https://github.com/merbanan/rtl_433/blob/7480c9c9f986859fdf0f661562f05509cc30a383/src/devices/bresser_5in1.c#L31
Die ersten 13 Byte sind die invertierten Werte der folgenden 13 Byte
z.B:
E7 1A 7F F7 0F FB EF 8B FD 9B BB FD FF 18 E5 80 08 F0 04 10 74 02 64 44 02 00
64 % Humidity
27.4 Grad
E7 1A 7F F7 0F FB EF 8B FD 9B BB FD FF
18 E5 80 08 F0 04 10 74 02 64 44 02 00
So jetzt sieht es besser aus. Hab nochmal recherchiert, was denn die richtige Datenrate ist, und hab diese Untersuchung gefunden: https://github.com/jgromes/RadioLib/issues/168. An der Datenrate scheint es zu hängen. Ändere ich nur die Deviation, ändert sich so gut wie nichts. Setze ich aber die Datenrate auf 8220, dann kommt etwas vernünftiges an, meine ich.
Meine Register sehen jetzt so aus:
ccregAll:
ccreg 00: 01 2E 46 06 2D D4 FF 00 02 00 00 06 00 21 65 E8
ccreg 10: 88 4C 02 22 F8 51 07 00 18 16 6C 43 68 91 87 6B
ccreg 20: F8 56 11 EC 0E 3C 11 41 00 59 7F 3E 88 31 0B
cc1101 reg detail - addr, name, value, (OOK default),[reset]
0x00 IOCFG2 - 0x01 (0D) [29]
0x01 IOCFG1 - 0x2E
0x02 IOCFG0 - 0x46 (2D) [3F]
0x03 FIFOTHR - 0x06 (07)
0x04 SYNC1 - 0x2D (D3)
0x05 SYNC0 - 0xD4 (91)
0x06 PKTLEN - 0xFF (3D) [0F]
0x07 PKTCTRL1 - 0x00 (04)
0x08 PKTCTRL0 - 0x02 (32) [45]
0x09 ADDR - 0x00
0x0A CHANNR - 0x00
0x0B FSCTRL1 - 0x06 [0F]
0x0C FSCTRL0 - 0x00
0x0D FREQ2 - 0x21 (10) [1E]
0x0E FREQ1 - 0x65 (B0) [C4]
0x0F FREQ0 - 0xE8 (71) [EC]
0x10 MDMCFG4 - 0x88 (57) [8C]
0x11 MDMCFG3 - 0x4C (C4) [22]
0x12 MDMCFG2 - 0x02 (30)
0x13 MDMCFG1 - 0x22 (23)
0x14 MDMCFG0 - 0xF8 (B9)
0x15 DEVIATN - 0x51 (00) [47]
0x16 MCSM2 - 0x07
0x17 MCSM1 - 0x00 [30]
0x18 MCSM0 - 0x18 [04]
0x19 FOCCFG - 0x16 (14) [36]
0x1A BSCFG - 0x6C
0x1B AGCCTRL2 - 0x43 (07) [03]
0x1C AGCCTRL1 - 0x68 (00) [40]
0x1D AGCCTRL0 - 0x91 (90)
0x1E WOREVT1 - 0x87
0x1F WOREVT0 - 0x6B
0x20 WORCTRL - 0xF8
0x21 FREND1 - 0x56
0x22 FREND0 - 0x11 [16]
0x23 FSCAL3 - 0xEC (E9) [A9]
0x24 FSCAL2 - 0x0E (2A) [0A]
0x25 FSCAL1 - 0x3C (00) [20]
0x26 FSCAL0 - 0x11 (1F) [0D]
0x27 RCCTRL1 - 0x41
0x28 RCCTRL0 - 0x00
0x29 FSTEST - 0x59
0x2A PTEST - 0x7F
0x2B AGCTEST - 0x3E
0x2C TEST2 - 0x88
0x2D TEST1 - 0x31
0x2E TEST0 - 0x0B
Und das ist das Log-Ergebnis:
2021.04.22 17:22:43 4: sduino/msg READ: MN;D=E6837FD73FE8EFEFFEBC89FFFF197C8028C017101001437600000001;R=230;
2021.04.22 17:22:43 4: mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/time:2021-04-22 17:22:43
2021.04.22 17:22:43 4: mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/id:124
2021.04.22 17:22:43 4: mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/battery_ok:1
2021.04.22 17:22:43 4: mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/temperature_C:11.0
2021.04.22 17:22:43 4: mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/humidity:43
2021.04.22 17:22:43 4: mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/wind_max_m_s:4.0
2021.04.22 17:22:43 4: mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/wind_avg_m_s:1.7
2021.04.22 17:22:43 4: mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/wind_dir_deg:270.0
2021.04.22 17:22:43 4: mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/rain_mm:7.6
2021.04.22 17:22:43 4: mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/mic:CHECKSUM
2021.04.22 17:22:43 4: mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/mod:FSK
2021.04.22 17:22:43 4: mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/freq1:868.24013
2021.04.22 17:22:43 4: mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/freq2:868.37171
2021.04.22 17:22:43 4: mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/rssi:-6.00578
2021.04.22 17:22:43 4: mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/snr:29.14872
2021.04.22 17:22:43 4: mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/noise:-35.1545
2021.04.22 17:22:55 4: sduino/msg READ: MN;D=E6837FE11FE7EFEFFEBD89FFFF197C801EE018101001427600000002;R=215;
2021.04.22 17:22:55 4: mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/time:2021-04-22 17:22:55
2021.04.22 17:22:55 4: mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/id:124
2021.04.22 17:22:55 4: mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/battery_ok:1
2021.04.22 17:22:55 4: mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/temperature_C:11.0
2021.04.22 17:22:55 4: mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/humidity:42
2021.04.22 17:22:55 4: mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/wind_max_m_s:3.0
2021.04.22 17:22:55 4: mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/wind_avg_m_s:1.8
2021.04.22 17:22:55 4: mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/wind_dir_deg:315.0
2021.04.22 17:22:55 4: mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/rain_mm:7.6
2021.04.22 17:22:55 4: mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/mic:CHECKSUM
2021.04.22 17:22:55 4: mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/mod:FSK
2021.04.22 17:22:55 4: mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/freq1:868.22938
2021.04.22 17:22:55 4: mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/freq2:868.37658
2021.04.22 17:22:55 4: mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/rssi:-6.21577
2021.04.22 17:22:55 4: mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/snr:25.92842
2021.04.22 17:22:55 4: mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/noise:-32.1442
2021.04.22 17:23:07 4: sduino/msg READ: MN;D=E6837FE11FE7EFEFFEBD89FFFF197C801EE018101001427600000001;R=213;
2021.04.22 17:23:07 4: mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/time:2021-04-22 17:23:07
2021.04.22 17:23:07 4: mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/id:124
2021.04.22 17:23:07 4: mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/battery_ok:1
2021.04.22 17:23:07 4: mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/temperature_C:11.0
2021.04.22 17:23:07 4: mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/humidity:42
2021.04.22 17:23:07 4: mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/wind_max_m_s:3.0
2021.04.22 17:23:07 4: mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/wind_avg_m_s:1.8
2021.04.22 17:23:07 4: mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/wind_dir_deg:315.0
2021.04.22 17:23:07 4: mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/rain_mm:7.6
2021.04.22 17:23:07 4: mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/mic:CHECKSUM
2021.04.22 17:23:07 4: mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/mod:FSK
2021.04.22 17:23:07 4: mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/freq1:868.23424
2021.04.22 17:23:07 4: mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/freq2:868.36512
2021.04.22 17:23:07 4: mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/rssi:-5.93452
2021.04.22 17:23:07 4: mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/snr:27.17878
2021.04.22 17:23:07 4: mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/noise:-33.1133
2021.04.22 17:23:19 4: sduino/msg READ: MN;D=E6837FEB1FE9EFEFFEBC89FFFF197C8014E016101001437600000002;R=216;
2021.04.22 17:23:19 4: mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/time:2021-04-22 17:23:19
2021.04.22 17:23:19 4: mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/id:124
2021.04.22 17:23:19 4: mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/battery_ok:1
2021.04.22 17:23:19 4: mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/temperature_C:11.0
2021.04.22 17:23:19 4: mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/humidity:43
2021.04.22 17:23:19 4: mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/wind_max_m_s:2.0
2021.04.22 17:23:19 4: mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/wind_avg_m_s:1.6
2021.04.22 17:23:19 4: mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/wind_dir_deg:315.0
2021.04.22 17:23:19 4: mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/rain_mm:7.6
2021.04.22 17:23:19 4: mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/mic:CHECKSUM
2021.04.22 17:23:19 4: mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/mod:FSK
2021.04.22 17:23:19 4: mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/freq1:868.22726
2021.04.22 17:23:19 4: mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/freq2:868.36768
2021.04.22 17:23:19 4: mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/rssi:-6.00578
2021.04.22 17:23:19 4: mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/snr:24.67714
2021.04.22 17:23:19 4: mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/noise:-30.6829
2021.04.22 17:23:31 4: sduino/msg READ: MN;D=E6837FEB2FE9EFEFFEBC89FFFF197C8014D016101001437600000000;R=218;
2021.04.22 17:23:31 4: mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/time:2021-04-22 17:23:31
2021.04.22 17:23:31 4: mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/id:124
2021.04.22 17:23:31 4: mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/battery_ok:1
2021.04.22 17:23:31 4: mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/temperature_C:11.0
2021.04.22 17:23:31 4: mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/humidity:43
2021.04.22 17:23:31 4: mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/wind_max_m_s:2.0
2021.04.22 17:23:31 4: mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/wind_avg_m_s:1.6
2021.04.22 17:23:31 4: mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/wind_dir_deg:292.5
2021.04.22 17:23:31 4: mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/rain_mm:7.6
2021.04.22 17:23:31 4: mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/mic:CHECKSUM
2021.04.22 17:23:31 4: mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/mod:FSK
2021.04.22 17:23:31 4: mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/freq1:868.22912
2021.04.22 17:23:31 4: mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/freq2:868.3609
2021.04.22 17:23:31 4: mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/rssi:-5.93763
2021.04.22 17:23:31 4: mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/snr:29.21686
2021.04.22 17:23:31 4: mqtt_192.168.2.47_54796 rtl_433-8195ffff PUBLISH rtl_433/noise:-35.1545
Man sieht hier im Log die Ausgaben, die ich über den SDR-Stick per MQTT bekomme, und passend dazu die MN_Telegramme des Signalduino. Das kommt regelmäßig alle 12 s. Alle gültigen MU-Telegramme haben als zweites Empfangsbyte die 83. Das ist das inverse des Stationscodes 7C, den man 13 Bytes weiter hinten wiederfindet. Auch die Temperatur hab ich in diesen Telegrammen gemäß https://github.com/merbanan/rtl_433/blob/7480c9c9f986859fdf0f661562f05509cc30a383/src/devices/bresser_5in1.c#L31 stichprobenartig gesucht und gefunden. Man kann die Werte im Log 1:1 mit den Werten vom SDR-Stick vergleichen, die anderen sollten dann wohl auch passen.
Läßt sich damit jetzt eine Integration in fhem vornehmen?
ja, das passt so.
Wie hast Du die Datenrate von 8220 ermittelt?
Ich vermute, daß die Datenrate der Kehrwert von der Dauer eines Bits ist
hier ist die short_width = 124
https://github.com/merbanan/rtl_433/blob/7480c9c9f986859fdf0f661562f05509cc30a383/src/devices/bresser_5in1.c#L188
demnach wäre die Datenrate 1 / 124 = 8065
bitte teste mal dies
get sduino raw CW0001,012E,0246,0306,042D,05D4,06FF,0700,0802,0D21,0E65,0FE8,1088,114C,1206,1322,14F8,1551,1700,1818,1916,1B43,1C68,1D91,2211,23E9,242A,2500,2611,3D07,3E04,4042,4172,4265,4373,4473,4535,4631,4700
dies ergibt das ccconf in der Anlage
Gruß Ralf
Hab ich probiert:
ccconf: freq:868.350MHz bWidth:203KHz rAmpl:33dB sens:8dB (DataRate:8058.55Baud)
Modulation:2-FSK (SYNC_MODE:16/16 sync) DEVIATN:57.129kHz
Aber das passt nicht, dann kommen keine sinnvollen Telegramme mehr an, also so läßt sich die Datenrate nicht ermitteln.
Der ursprüngich verwendete Wert 8220 stammt aus dieser Untersuchung: https://github.com/jgromes/RadioLib/issues/168#issuecomment-662631134. Die Herleitung kann ich ehrlich gesagt nicht nachvollziehen, aber es ist Fakt und mehrfach bestätigt, dass sie richtig ist.
Ergänzung: ich hab Deinen Konfigurationsstring nochmal mit meinem verglichen. Ganz wichtig ist der SyncMode in 0x12 MDMCFG2. Das muß auf "0x02 - Modulation:2-FSK (SYNC_MODE:16/16 ohne Preamble)" stehen, sonst kommt gar nichts an. Aber auch wenn das stimmt, passt die Datarate 8065 nicht, es kommen dann nur ungültige Telegramme an.
ZitatDer ursprüngich verwendete Wert 8220 stammt aus dieser Untersuchung
1 / 8220 ergibt 121,65us
das sind nur ca 2,5us weniger als die 124.
Evtl stimmen die short_width = 124 nicht ganz.
Die Frage ist wie genau der SDR die Bitdauer messen kann.
Zum Einbauen in Fhem kann ich noch ein paar MN-Nachrichten gebrauchen:
- mit fast leerer Batterie
- mit verschiedenen Temperaturen, Windstärken und Windrichtungen
MN-Nachrichten mit negativen Temperaturen wirst Du wahrscheinlich nicht mehr liefern können.
Ich würde gerne sehen ob sich beim Batteriewechsel die Stationsid ändert
Gruß Ralf
Ich bin auch überrascht, wie empfindlich das Ganze auf Änderungen der Datarate reagiert. Und ich frage mich auch, wie rtl_433 überhaupt funktionieren kann. Da gebe ich den Wert ja nicht an, und ich sehe auch nicht, dass dieser im Quellcode hinterlegt ist. Demnach müßte er ja online ermittelt werden können, oder eben doch mit den 124 + irgendeinem Detail, dass wir bislang nicht kennen, zusammenhängen....spooky.
Ich zeichne noch ein bisschen auf und hänge schon mal ein paar Telegramme an... der Wind dreht sich gerade öfters mal. Negative Temperaturen kann ich momentan nicht liefern, aber vielleicht wirds ja nochmal kühler. Die Wetterstation hängt draußen, vielleicht gibts ja Eisheilige.
Ne leere Batterie kann ich momentan auch nicht simulieren, aber das mit der ID kann ich dennoch beantworten. Die ändert sich definitiv beim Batteriewechsel, oder auch wenn man Reset drückt. Insofern wärs gut, wenn diese nicht in die Device Definition in fhem eingehen würde, sondern nur als gelesener Parameter, so dass man notfalls zwischen mehreren Wetterstationen unterscheiden kann, aber nicht bei Batteriewechsel die fhem-Konfiguration anpassen muß.
Was mir nicht so richtig klar ist ist, wie man den Regenwert interpretieren muß. Heute hat es nicht geregnet, dennoch wird ein Wert geliefert. Die Bedieneinheit zeigt aber einen Wert für "vor 4 Tagen" an. Muß also irgendewas kumuliertes sein. Vielleicht gibts da etwas übliches? Hab ich mich noch nicht mit beschäftigt.
Zitat
2021.04.23 09:39:31 4: sduino/msg READ: MN;D=E8837FF76FEFEF9CFF8F89FFFF177C80089010106300707600000002;N=7;R=215;
2021.04.23 13:57:31 4: sduino/msg READ: MN;D=E5837FEB1FEFEFD8FEB989FFFF1A7C8014E010102701467600000002;N=7;R=215;
2021.04.23 14:00:19 4: sduino/msg READ: MN;D=E5833FE16FE6EFDFFE9A897FFF1A7C801E9019102001457200000001;N=7;R=207;
ZitatIch bin auch überrascht, wie empfindlich das Ganze auf Änderungen der Datarate reagiert. Und ich frage mich auch, wie rtl_433 überhaupt funktionieren kann.
Beim rtl_433 wird die Samplingrate angegeben, die ist mindestens ca das 10 fache der Datarate.
Beim rtl_433 muss die Bitdauer nicht so genau angegeben werden, da die Flanken ausgewertet werden.
ZitatGanz wichtig ist der SyncMode in 0x12 MDMCFG2. Das muß auf "0x02 - Modulation:2-FSK
ich habe es angepasst:
CW0001,012E,0246,0306,042D,05D4,06FF,0700,0802,0D21,0E65,0FE8,1088,114C,1202,1322,14F8,1551,1700,1818,1916,1B43,1C68,1D91,2211,23E9,242A,2500,2611,3D07,3E04,4042,4172,4265,4373,4473,4535,4631,4700Ich habe mal mit dem Einbauen ins Fhemmodul angefangen (siehe Anlage), es ist im 14_SD_WS.pm Modul noch nicht ganz fertig, es fehlen noch einige readings.
2021.04.24 11:57:54.622 4 : sduinoD/msg get raw: MN;D=E8837FF76FEFEF9CFF8F89FFFF177C80089010106300707600000002;N=7;R=215;
2021.04.24 11:57:54.622 4 : sduinoD Parse_MN: Found 2-FSK Protocol id 108 length 56 RSSI = -94.5 -> Bresser 5in1
2021.04.24 11:57:54.622 4 : sduinoD ParseMN: ID=108 dmsg=W108#7C8008901010630070760000
2021.04.24 11:57:54.622 4 : sduinoD Dispatch: W108#7C8008901010630070760000, -94.5 dB, dispatch
2021.04.24 11:57:54.623 4 : sduinoD: SD_WS_Parse protocol 108, rawData 7C8008901010630070760000
2021.04.24 11:57:54.623 4 : sduinoD: SD_WS_Parse decoded protocol-id 108 (Bresser_5in1), sensor-id 7C
2021.04.24 11:57:54.623 4 : sduinoD: SD_WS_Parse SD_WS_108 (7C8008901010630070760000)
2021-04-24 11:57:54.625 SD_WS SD_WS_108 T: 6.3 H: 70
2021-04-24 11:57:54.625 SD_WS SD_WS_108 temperature: 6.3
2021-04-24 11:57:54.625 SD_WS SD_WS_108 humidity: 70
2021-04-24 11:57:54.625 SD_WS SD_WS_108 RSSI: -94.5
2021-04-24 11:57:54.625 SD_WS SD_WS_108 Protocol_ID: 108
2021-04-24 11:57:54.625 SD_WS SD_WS_108 DMSG: W108#7C8008901010630070760000
2021-04-24 11:57:54.625 SD_WS SD_WS_108 RAWMSG: MN;D=E8837FF76FEFEF9CFF8F89FFFF177C80089010106300707600000002;N=7;R=215;
2021.04.24 11:59:10.709 4 : sduinoD/msg get raw: MN;D=E5837FEB1FEFEFD8FEB989FFFF1A7C8014E010102701467600000002;N=7;R=215;
2021.04.24 11:59:10.709 4 : sduinoD Parse_MN: Found 2-FSK Protocol id 108 length 56 RSSI = -94.5 -> Bresser 5in1
2021.04.24 11:59:10.709 4 : sduinoD ParseMN: ID=108 dmsg=W108#7C8014E01010270146760000
2021.04.24 11:59:10.709 4 : sduinoD Dispatch: W108#7C8014E01010270146760000, -94.5 dB, dispatch
2021.04.24 11:59:10.710 4 : sduinoD: SD_WS_Parse protocol 108, rawData 7C8014E01010270146760000
2021.04.24 11:59:10.710 4 : sduinoD: SD_WS_Parse decoded protocol-id 108 (Bresser_5in1), sensor-id 7C
2021.04.24 11:59:10.710 4 : sduinoD: SD_WS_Parse SD_WS_108 (7C8014E01010270146760000)
2021-04-24 11:59:10.712 SD_WS SD_WS_108 T: 12.7 H: 46
2021-04-24 11:59:10.712 SD_WS SD_WS_108 temperature: 12.7
2021-04-24 11:59:10.712 SD_WS SD_WS_108 humidity: 46
2021-04-24 11:59:10.712 SD_WS SD_WS_108 Protocol_ID: 108
2021-04-24 11:59:10.712 SD_WS SD_WS_108 RSSI: -94.5
2021-04-24 11:59:10.712 SD_WS SD_WS_108 RAWMSG: MN;D=E5837FEB1FEFEFD8FEB989FFFF1A7C8014E010102701467600000002;N=7;R=215;
2021-04-24 11:59:10.712 SD_WS SD_WS_108 DMSG: W108#7C8014E01010270146760000Gruß Ralf
Habs auf die schnelle gerade mal probiert... und sieht gut aus! Die Wetterstation wird gefunden und ein fhem-Device dafür automatisch angelegt. :) Temperatur- und Feuchtigkeitswert stimmen auch. Ich lass es mal laufen, vielleicht gibts nochmal Nachfrost, so dass wir auch gleich mal negative Temperaturen mittesten können.
Zitat von: Ralf9 am 23 April 2021, 13:02:22
1 / 8220 ergibt 121,65us
das sind nur ca 2,5us weniger als die 124.
Evtl stimmen die short_width = 124 nicht ganz.
Die Frage ist wie genau der SDR die Bitdauer messen kann.
In irgendeiner bresser_5in1.c war auch mal 122 statt 124 angegeben. Daraus ergäbe sich dann eine Datenrate von 8196 Hz.
Ich hab Euch mal weitere Logs zusammengestellt. Wir hatten Glück, diese Nacht war wieder Frost. Und tatsächlich werden die negativen Temperaturen noch nicht richtig ausgewertet: das Minuszeichen fehlt. Zwischen 6:00 und 7:10 waren die Temperaturen aber negativ, danach bis 8:00 positiv.
Ich hab anbei 3 Dateien zusammengezippt beigefügt:
- Das Device-Log der Wetterstation, wo die Daten über rtl_433 dekodiert und an fhem per MQTT weitergeleitet wurden.
- Das Device-Log desselben Gerätes, wo die Daten über den Signalduino empfangen und als SD_WS_108 dekodiert wurden.
- Ein Auszug aus dem fhem-Log, wo die signalduino-Telegramme zu sehen sind.
Letztere Datei ist leider relativ groß. Da wurde auch viel uninteressantes geloggt, auch von mindestens einer anderen Wetterstation. Relevant sind die Daten mit der Sensor-ID 7C.
Die erste Datei stammt übrigens von einer separaten fhem-Installation, so dass die Zeitstempel leicht abweichen könnten.
Das mit der Datenrate 8196 hab ich auch gleich probiert. Das Ergebnis der Konfiguration sah so aus:
ccconf: freq:868.350MHz bWidth:203KHz rAmpl:33dB sens:8dB (DataRate:8207.32Baud)
Modulation:2-FSK (SYNC_MODE:16/16 sync) DEVIATN:57.129kHzDaten kommen auch an. Kann also durchaus sein, dass dieser Wert richtiger ist als 8220, womit wir dann auch eine Erklärung hätten, woher der Wert stammt. Nur nicht, warum es mal in bresser_5in1.c geändert wurde.
Ich habe jetzt mal angefangen, die Wetterstation einzuarbeiten. Wie es der Zufall so will, empfange ich auch Daten von einer Station irgendwo aus der Nachbarschaft. Zumindest passen schon mal Temperatur und Feuchte.
Einen Unterschied beim Empfang mit den beiden Datenraten 8232.12 oder 8207.32 konnte ich in der Kürze bis jetzt noch nicht feststellen.
In der 14_SD_WS.pm von Ralf9 ist die Verarbeitung von negativen Temperaturen noch nicht eingebunden.
Frage an Ralf9: Wieso verwendest du eigentlich die invertierten Daten am Beginn der Nachricht und nicht die hinteren? Ich habe mich zuerst gewundert, wieso ich falsche Werte erhalte. Nach Umstellung auf die Bytes 13 bis 25, so wie in der bresser_5in1.c beschrieben, stimmen die Werte.
ZitatFrage an Ralf9: Wieso verwendest du eigentlich die invertierten Daten am Beginn der Nachricht und nicht die hinteren?
Durch diese Zeile am Ende verwende ich auch die hinteren
$dmsg = substr($dmsg, 28, 24);
Ach so, hatte ich übersehen.
Die method => \&main::SIGNALduino_Bresser_5in1 will ich eigentlich einsparen und alles in die 14_SD_WS.pm einbauen. So ist das übersichtlicher.
ZitatDie method => \&main::SIGNALduino_Bresser_5in1 will ich eigentlich einsparen und alles in die 14_SD_WS.pm einbauen. So ist das übersichtlicher.
Das finde ich nicht so gut, meiner Meinung nach überwiegen da die Nachteile.
Bei fehlerhaften MN-Nachrichten kann es im ungünstigsten Fall alle 12 sek einen unnötigen dispatch zum 14_SD_WS.pm Modul geben.
In der 00_SIGNALduino.pm funktioniert in der Sub SIGNALduno_Dispatch dann die Erkennung doppelter Nachrichten auch nicht mehr so gut.
Gruß Ralf
in der Anlage ist eine neue Version des 14_SD_WS.pm Moduls.
Ich habe negative Temperaturen, rain, windspeed, batteryState und windDirectionDegree ergänzt.
Es fehlt noch windDirectionText und windgust
2021-04-27 22:14:47.296 SD_WS SD_WS_108 T: 11 H: 42 W: 1.8 R: 7.6
2021-04-27 22:14:47.296 SD_WS SD_WS_108 temperature: 11
2021-04-27 22:14:47.296 SD_WS SD_WS_108 humidity: 42
2021-04-27 22:14:47.296 SD_WS SD_WS_108 windspeed: 1.8
2021-04-27 22:14:47.296 SD_WS SD_WS_108 windspeed_kmh: 6.5
2021-04-27 22:14:47.296 SD_WS SD_WS_108 windDirectionDegree: 315
2021-04-27 22:14:47.296 SD_WS SD_WS_108 batteryState: ok
2021-04-27 22:14:47.296 SD_WS SD_WS_108 rain_mm: 7.6
Welche der beiden Versionen ist besser?
@winddir_name = ("N", "NNE", "NE", "ENE", "E", "ESE", "SE", "SSE", "S", "SSW", "SW", "WSW", "W", "WNW", "NW", "NNW");
oder
@winddir_name = ("N", "NNE", "NE", "NEE", "E", "SEE", "SE", "SSE", "S", "SSW", "SW", "SWW", "W", "NWW", "NW", "NNW");
Habs gerade probiert... sieht gut aus :-)
Zu Deiner Frage: Ich kenne nur die erste Form der Benennung der Windrichtungen. Die würde ich dementsprechend bevorzugen.
Und eine Frage hab ich dann noch:
Mir ist nicht ganz klar, was die Wetterstation als "rain_mm" meldet und wie man das am besten darstellt. Meine meldet aktuell immer denselben Wert, den sie schon seit einer Woche meldet, in der es nicht geregnet hat. Das Bresser-Display zeigt den Niederschlag tageweise, inzwischen nichts mehr. Der anscheinend kumulierte Wert in der Übertragung bleibt aber anscheinend. Ich vermute mal, man muß den Messwert in fhem in Verbindung mit dem Zeitstempel verarbeiten. Wie genau ist mir aber wie gesagt nicht klar, auch nicht, was man dementsprechend als Reading optimalerweise anbieten sollte. Vielleicht sowas wie "Niederschlag heute" und "Niederschlag der letzten Woche" oder so. Können wir uns hier an bestehenden Wetterstatiinsimplementierungen orientieren, oder müssen wir hier was Neues erfinden? Gibts dazu schon eine sinnvolle Visualisierung fürs Dashboard?
Laut bresser_5in1.c:
R = rain in mm, BCD coded, RRxR = 1203 => 31.2 mm
ist das nur ein fortlaufender Zähler, der bei 99,9 wahrscheinlich überläuft und wieder bei 0 beginnt. Warum angeblich das 4. Nibble nicht verwendet wird, ist mir ein Rätsel. Das können wir nur beobachten, oder du schüttest mal ne Menge Wasser in den Regenmesser :-)
Für stündliche, tägliche u.s.w. Auswertungen würde ich das Modul statistics empfehlen.
in der Anlage ist eine neue Version des 14_SD_WS.pm Moduls.
Ich habe windDirectionText und windgust ergänzt
Auch das sieht gut aus.
Zu der Sache mit der Regenmenge:
Es scheibt so zu sein, dass der Sensor einen kumulierten Niederschlagswert liefert. Aktuell ist das identisch mit dem Niederschlagswert des letzten Monats, was aber auch an der bislang kurzen Betriebsdauer liegen kann. Bin gespannt was ich dann am 1. Mai als Messwert bekomme.
Das Modul statistics kannte ich noch nicht. Damit könnte es möglich sein, mithilfe der Delta-Funktion stündliche oder tägliche Niederschlagsmengen auszurechnen. Ganz warm bin ich mit dem Modul aber noch nicht; es rechnet anscheinend erst ab Einrichtung und ignoriert früher aufgezeichnete Daten. Weiß jemand, ob man das irgendwie beeinflussen kann? Sonst muß ich wohl auf den nächsten Regen warten...
Das ist richtig, das Modul statistics muss erst Daten sammeln.
Wenn du jetzt schon etwas sehen willst, kannst du auch ein SVG-Plot mit der Funktion delta-h oder delta-d erstellen.
Ich habe beim 14_SD_WS.pm Modul noch einige Infos zum Protokoll ergänzt.
@berniie liest Du hier noch mit? Ich habe für den "DP100 / Fine Offset WH51" Bodenfeuchtesensor die CRC Berechung ergänzt.
Die aktuelle Version des angepassten 14_SD_WS.pm Moduls ist in der Anlage vom ersten Beitrag hier.
Ich habe auch hier im dritten Beitrag die cc1101 Registerwerte ergänzt
https://forum.fhem.de/index.php/topic,106594.msg1005067.html#msg1005067
Was passiert denn jetzt eigentlich mit der Geräte-ID? Die sehe ich als Reading noch nicht. Wird die einfach ignoriert? Was passiert dann, wenn man die Batterie wechselt oder Reset drückt, und sich damit die ID ndert? Und was, wenn man zufällig zwei unterschiedlioche Wetterstationen empfängt? Das sollten wir noch klären.
Es gibt das sduino Attribut "longids", wenn dies gesetzt ist, dann wird die Id an den Devicenamen angehängt
z.B.: "SD_WS_108_7C"
damit können dann mehrere Wetterstationen empfangen werden, der Devicename ändert sich dann aber beim Batteriewechsel.
Ein reading id gibt es noch nicht.
Wie soll es heissen? "id" oder sensorId" oder ??
Soll es immer und bei allen Modellen angelegt und aktuallisiert werden?
Oder nur wenn das Attribut "longids" nicht gesetzt ist?
Wieder was dazu gelernt: Das Attribut kannte ich noch nicht. Ok, dann ist klar, wie man mehrere Wetterstationen verwalten kann.
Das Reading macht meiner Meinung nach trotzdem Sinn. Ich würde es sensorID nennen. Und ich würde es in beiden Fällen anbieten:
- Wenn man longids nicht gesetzt hat braucht man die ID prinzipiell nicht zu wissen. Aber man könnte zumindest auf eine ID-Änderung reagieren, dies anzeigen, Email schicken oder so. Einfach nur um zu verhindern, dass hier eine unbewußte Umstellung auf die neue Wetterstation des Nachbarn erfolgt. Was würde überhaupt passieren, wenn longids nicht gesetzt ist und dann mehrere Wetterstationen senden? Wird longid dann automatisch gesetzt, oder gibts Kuddelmuddel?
- Auch wenn longids gesetzt ist, könnte ein solches Reading auch helfen. Hier müßte man ja nach einem Batteriewechsel eine Konfigurationsänderung vornehmen. Auch das könnte man mit fhem automatisieren und hätte direkten Zugriff auf die ID, um das Device umzubenennen.
Letztendlich kann ich mit allem leben; wir sind hier schon beim Feinschliff. Insgesamt bin ich sehr zufrieden mit dem Ergebnis. Schon mal vielen Dank an alle Beteiligten!
Hallo,
mein WH51 wird nicht mehr empfangen. Sehe einen crc error
2021.05.03 17:58:43.745 4: sduino868/msg READ:
MN;D=5101C6BF0F7F24F8CAFFFFFFF877F58B;N=6;R=254;
2021.05.03 17:58:43.765 4: sduino868 Parse_MN: Found 2-FSK Protocol id 107 -> WH51
2021.05.03 17:58:43.765 4: sduino868 ParseMN: ID=107 dmsg=W107#5101C6BF0F7F24F8CAFFFFFFF877F58B
2021.05.03 17:58:43.765 5: sduino868 Dispatch: W107#5101C6BF0F7F24F8CAFFFFFFF877F58B, test ungleich: disabled
2021.05.03 17:58:43.765 4: sduino868 Dispatch: W107#5101C6BF0F7F24F8CAFFFFFFF877F58B, -75 dB, dispatch
2021.05.03 17:58:43.766 5: sduino868: dispatch W107#5101C6BF0F7F24F8CAFFFFFFF877F58B
2021.05.03 17:58:43.769 4: sduino868: SD_WS_Parse protocol 107, rawData 5101C6BF0F7F24F8CAFFFFFFF877F58B
2021.05.03 17:58:43.769 5: sduino868: SD_WS_107: sum = 64, ref = 119
2021.05.03 17:58:43.769 4: sduino868: SD_WS_Parse 5101C6BF0F7F24F8CAFFFFFFF877F58B protocolid 107 (WH51) - ERROR CRC
Ich kann allerdings nicht ausschliessen, dass es diesen crc error wirklich gibt. Empfange den Sensor nur sehr sporadisch.
Schöne Grüße,
Jörg
Zitat2021.05.03 17:58:43.769 5: sduino868: SD_WS_107: sum = 64, ref = 119
dies ist ein checksum error, da sum und ref nicht gleich sind.
Wenn der Sensor nur sehr sporadisch empfangen wird, passen anscheinend die cc1101 Register noch nicht ganz.
Die Datarate von 17.241 müsste passen, ist der Kehrwert von der Bit width = 58µs
Die BandWidth von 812KHz erscheint mir zu hoch, evtl passt die Frequenz und die DEVIATN 88.867 kHz nicht ganz.
Gruß Ralf
Ich hab die bwidth jetzt mal auf 541khz gesetzt. Mal schaun was passiert.
Was wäre denn ein möglicher Wert für DEVIATN?
ccconf: freq:868.350MHz bWidth:541KHz rAmpl:42dB sens:8dB (DataRate:17257.69Baud)
Modulation:2-FSK (SYNC_MODE:16/16 + carrier-sense above threshold) DEVIATN:88.867kHz
Du kannst auch mal eine Datarate von 17208 oder 17307 versuchen
Das DEVIATN lässt sich am Spektrum ermitteln:
Zitat von: Ralf9 am 12 April 2021, 20:20:20
Wenn das Spektrum, wie hier beschrieben 2 Spitzen hat, dann müsste es 2-FSK sein
https://wiki.fhem.de/wiki/Unbekannte_Funkprotokolle#Sendefrequenz_und_Frequenzhub
Der Frequenzhub (DEVIATN) ist (obere Frequenz - untere Frequenz) / 2
Hallo,
ich versuche mit dem Signalduino auch einen Bresser 5 in 1 Sensor ziu empfangen. Leider bekomme ich folgende Fehlermeldung:
2021.05.18 18:48:43 4: sduino8/msg READ: MN;D=44004579014A80E02000280840C410334904084002A6140820822060;N=7;R=202;
2021.05.18 18:37:08 4: sduino8 Parse_MN: Found 2-FSK Protocol id 108 length 56 RSSI = -101 -> Bresser 5in1
2021.05.18 18:37:08 4: sduino8 ParseMN: method error! Bresser 5in1: Checksum Error pos=0
Ich verwende einen Signalduino auf Arduino Nano Basis mit CC1101 Modul.
Die Firmware die ich verwende ist die Version: V 3.3.4-dev200914 SIGNALduino cc1101 (b1) - compiled at Sep 17 2020 23:37:47
Die 14_SD_WS.pm ist die Version hier aus dem Forum. Die 00_Signalduino.pm und die Signalduni_protocols sind die neuesten aus dem Development Zweig, weil sie neuer sind als die hier aus dem Forum.
Die Konfiguration des Signalduino sieht so aus:
ccconf: freq:868.350MHz bWidth:203KHz rAmpl:33dB sens:8dB (DataRate:8232.12Baud) Modulation:2-FSK (SYNC_MODE:16/16 sync) DEVIATN:57.129kH
Ich hoffe die Information reichen aus um mir vielleicht beim Fehler finden helfen zu können.
Was für ein cc1101 Modul verwendest Du? Es gibt cc1101 Module mit einem ungenauen Quarz
Gruß Ralf
Hallo,
ich benutze das Modul im angehängten Foto. Ich hoffe das reicht zur Idendifikation aus.
Viele Grüße
Dieter
Das Modul sollte eigentlich passen.
Du kannst mal versuchen ob es besser wird, wenn Du die freq auf 868.300MHz änderst
Ich habe die Frequenz eingestellt, aber die Meldungen im Log sind die gleichen.
Du kannst auch mal die DataRate auf 8207 verkleinern
Das bringt leider auch keine Änderung.
Die Nachrichten müssten ungefähr so aussehen:
MN;D=E6837FE11FE7EFEFFEBD89FFFF197C801EE018101001427600000001;N=7;
Die Hexziffern der hinteren hälfte sind das Komplement der vorderen Hälfte.
Hinten gibt es einige 00 und in der vorderen Häfte gibt es einige FF und FE
Du kannst mal versuchen die Frequenz etwas zu ändern.
Im Bereich 868.250 bis 868.400 MHz
Falls Du mit ändern der Frequenz und Datenrate nicht weiterkommst, kannst Du deine Version des Bresser 5 in 1 mal mit der von @beaune vergleichen.
Es gibt anscheinend 2 Versionen, mit FSK Modulation mit ASK OOK
Ja, die Frequenz Änderungen bringen nichts. Ich habe zwischen 868.000 bos 868.500 in 25 khz-Schritten alle Frequenzen ausprobiert.
Die Einträge im Log sehen immer gleich aus. Auch sind die vorderen Hexziffern nicht das komplement der hinteren.
Was hat Baune anders gemacht? Wahrscheinlich hat mein Sensor wirklich ein anderes Protokoll, aber ich weiß halt nicht wie ich das feststellen kann. Ich hatte nur gehofft, dass es jetzt mit den von dir eingebrachten Änderungen funktionieren könnte.
Ich weiß leider auch nicht, wie man die beiden Varianten unterscheidet, und ob es sie wirklich gibt. Die Hinweise in den Foren waren dazu widersprüchlich. Das was jetzt implementiert ist, passt aber zur "aktuellen" Variante. Ich hab die Wetterstation irgendwann in diesem Frühjahr gekauft. Ein Bild vom Typenschild hänge ich zum Vergleichen mal an.
Ansonsten könnten wir folgendes tun:
- Nochmal alle Register vergleichen.
- Oder ausschließen, dass es sich um ein Problem mit dem Signalduino handelt, indem Du mal die Variante SDR-Stick mit rtl_433 versuchst. Das kannst Du auch auf Windows ausprobieren. Wenn das geht wüßten wir zumindest, dass das Protokoll und die Modulationsart zu Deiner Wetterstation passt.
Hallo,
danke für das Foto. Mein Sensor hat eine andere Typennummer, so dass er schon ein anderes Protokoll benutzen kann.
Das es am Signalduino liegt, glaube ich nicht, da ein zweiter SD die gleichen Probleme hat.
Um mit rtl_433 etwas zu machen muss ich mir erst eine SDR Stick besorgen, dass wir wohl etwas dauern.
Wenn ich dann soweit bin melde ich mich wieder.
Danke erst mal für die Hilfe.
Grüße
Dieter
Hallo,
hier wird gerade die Unterstützung für Rojaflex Rohrmotoren in den Signalduino eingebaut
https://github.com/RFD-FHEM/RFFHEM/issues/955
Ich möchte es auch in meine Version einbauen
Kann dies bitte mal jemand testen der Rojaflex Handsender und Rohrmotoren hat?
Hier sind für meine firmware die cc1101 Register und die Konfigvariablen: ccmode=4 und ccN=8
get sduino raw CW0001,0246,0302,04D3,0591,06FF,0700,0805,0D10,0EB0,0F71,10C8,1193,1213,1322,14F8,1535,1700,1818,1916,1B43,1C40,1D91,2211,23E9,242A,2500,2611,3D08,3E04,4052,416f,426a,4361,4466,456c,4665,4778
ein "get ccconf" ergibt dann
ccconf: freq:433.920MHz bWidth:101KHz rAmpl:33dB sens:8dB (DataRate:9992.60Baud)
Modulation:GFSK (SYNC_MODE:30/32 sync) DEVIATN:20.630kHz
Ich hab mal zum testen dies hier gesendet
SN;N=8;D=083122FD201A011AA5;
am anderen sduino kam dann dies an:
2021.05.29 22:04:15.439 4 : sduino/msg READ: MN;D=083122FD201A011AA5;N=8;R=41;
2021.05.29 22:04:15.439 4 : sduino Parse_MN: Found GFSK Protocol id 109 length 18 RSSI = -53.5 -> Rojaflex
2021.05.29 22:04:15.439 4 : sduino ParseMN: ID=109 dmsg=P109#083122FD201A011AA5
2021.05.29 22:04:15.439 4 : sduino Dispatch: P109#083122FD201A011AA5, -53.5 dB
2021.05.29 22:04:15.439 4 : sduino: SD_Rojaflex_Parse, Protocol 109, rawData 083122FD201A011AA5
2021.05.29 22:04:15.439 4 : sduino: SD_Rojaflex_Parse, deviceCode 3122FD_0, housecode 3122FD, channel 0
2021-05-29 22:04:15.442 SD_Rojaflex SD_Rojaflex_3122FD_9 up
2021-05-29 22:04:15.442 SD_Rojaflex SD_Rojaflex_3122FD_9 motor: up
2021-05-29 22:04:15.442 SD_Rojaflex SD_Rojaflex_3122FD_9 targetPosition: 0
2021-05-29 22:04:15.442 SD_Rojaflex SD_Rojaflex_3122FD_9 RSSI: -53.5
2021-05-29 22:04:15.442 SD_Rojaflex SD_Rojaflex_3122FD_9 Protocol_ID: 109
2021-05-29 22:04:15.442 SD_Rojaflex SD_Rojaflex_3122FD_9 DMSG: P109#083122FD201A011AA5
2021-05-29 22:04:15.442 SD_Rojaflex SD_Rojaflex_3122FD_9 RAWMSG: MN;D=083122FD201A011AA5;N=8;R=41;
Gruß Ralf
Hast du gesicherte Erkenntnisse, das es sich bei der Modulation von Rojaflex um GFSK und nicht um 2-FSK handelt?
Nein gesicherte Erkenntnisse habe ich keine.
Bei diesem Spectrum sieht es aus wie GFSK
https://user-images.githubusercontent.com/68365998/115438571-da8ed380-a20d-11eb-9798-6eb6ab7de380.png
https://www.silabs.com/community/wireless/proprietary/knowledge-base.entry.html/2015/06/09/modulation_choice-oUw0
Nach dieser Berechung ist die bandwith von 101 noch zu hoch
https://www.silabs.com/community/wireless/proprietary/knowledge-base.entry.html/2015/02/17/calculation_of_theo-S9wI
@plin liest Du hier mit?
Ich hab mal die verschiedenen Kombinationen von FSK und GFSK bei Sender und Empfänger getestet, es funktionieren alle Kombinationen.
Hab dazu das "083122FD201A011AA5" von einem sduino zum anderen gesendet.
Bei Sender und Empfänger GFSK war der Empfang am Besten
C07=04 RSSI and LQI values will be appended, as well as CRC OK
RX C12=13 TX C12=13
MN;D=083122FD201A011AA538B0;N=8;R=56; RSSI = -46
MN;D=083122FD201A011AA538B0;N=8;R=56;
MN;D=083122FD201A011AA539B0;N=8;R=57;
RX C12=13 TX C12=03
MN;D=083122FD201A011AA52AB3;N=8;R=42; RSSI = -53
MN;D=083122FD201A011AA52BB3;N=8;R=43;
MN;D=083122FD201A011AA52DB3;N=8;R=45;
RX C12=03 TX C12=03
MN;D=083122FD201A011AA52C8B;N=8;R=44;
MN;D=083122FD201A011AA52E8B;N=8;R=46;
MN;D=083122FD201A011AA52F8B;N=8;R=47;
RX C12=03 TX C12=13
MN;D=083122FD201A011AA52EBD;N=8;R=46; RSSI = -51
MN;D=083122FD201A011AA52FBD;N=8;R=47;
MN;D=083122FD201A011AA52FBE;N=8;R=47;
Gruß Ralf
Hallo in die Runde,
ich hätte da mal 8 bidirektionale Motoren zum testen.
Was soll ich denn genau testen, nur die Register Werte übernehmen?
Edit:
Ich habe gerade mal angefangen die Registerwerte zu prüfen und ich habe nur Register von:
0x0 -> 0x2F
Mir ist noch unklar warum Ihr mehr Configregister habt ..
Zur Info:
Ich hatte auch schon ein bisschen mit den Modulationen rumgespielt kenne mich da nur noch so aus.
Angefangen habe ich mit einem Decoder in rtl433, der alles Decodieren und sogar generieren kann, siehe Signalgenerator am Ende:
Der Request ist kurz davor in den Master zu kommen: https://github.com/merbanan/rtl_433/pull/1705
Es scheint mir auch das GFK schöner funktioniert, dann empfange ich auch alles im RTL433, allerdings verstopft dann mein FHEM Server.
Er empfängt genau eine Nachricht von der Fernbedienung und dann ist er still.
Aktuell fahren wir folgende Register. Damit lassen sich die Rolläden steuern und man kann die Fernbedienung empfangen:
register => ['0001','0246','0302','04D3','0591','06FF','0700','0805','0D10','0EB0','0F71','10C8','1193','1203','1322','14F8','1535','1916','1B43','1C40','2156','2211'],
Wenn man auf 0x1213 geht funktionieren die Rolläden weiterhin, aber man Empfängt nur eine Nachricht und dann scheint es zu Fehlern in dem FHEM Stack zu kommen. Ich kann gerne Schrittweise Abweichungen von unserem Known Good testen.
In meiner Firmware (siehe hier den ersten Beitrag) gibt es Konfigurationsvariablen, ccN (Adr 3D) und ccmode (Adr 3E)
Diese werden mit dem CW Befehl automatisch mit gesetzt.
Sie können auch einzeln mit dem raw Befehl CSccN= und CSccmode= gesetzt werden.
ccN wird bei meiner multi cc1101 Firmwarevariante für den MapleMini (und später auch für den ESP32) benötigt, damit die Sendenachricht dem entsprechenden cc1101 Modul zugeordnet werden kann.
Mit ccmode wird beim Empfang die Art festgelegt wie die vom cc1101 empfangenen Daten in der Firmware verarbeitet werden.
Bei 0 werden die Daten über den GDO2 Pin empfangen (ASK/OOK)
1 und 2 ist speziell für Kopp_FC Fernbedienungen und Steckdosen, dafür sind spezielle cc1101 Registereinstellungen notwendig
3 und 4 ist für Lacrosse entwickelt worden und funktioniert bei den meisten FSK Protokollen.
Das Problem dabei ist, daß bei der Firmware von Sidey das FSK nur unvollständig von meiner Firmware übernommen wurde.
Die ccmode Variable wird direkt vom cc1101 Register 0x12 gesetzt, d.h. bei GFSK wird automatisch das ccmode für kopp verwendet.
Zum testen vom GFSK mit der firmware von Sidey müsste es auch funktionieren, wenn Du nach jeder empfangen Nachricht mit dem raw Befehl XQ dem Empfang deaktivierst und mit XE wieder aktivierst.
Nach dieser Formel müsste die Bandbreite ca 50 kHz sein (20.630 x 2 + 9992)
https://www.silabs.com/community/wireless/proprietary/knowledge-base.entry.html/2015/02/17/calculation_of_theo-S9wI
Danke für den Hinweis. Ich habe vorläufig mal unsere Firmware gefixt. Damit funktioniert jetzt auch GFSK.
Senden und Empfangen von SIGNALduino zu SIGNALduino mit Protokoll Rojaflex geht auch gut mit einer Bandbreite von 58 kHz.
Mit dem cc1101 Register 0x13 lässt sich durch erhöhen der NUM_PREAMBLE bei Bedarf evtl die Zuverlässigkeit beim Senden erhöhen
- Restest mit Register 0x1213 und der neuen Firmware ist erfolgreich.
- Funktioniert mit dem original Rolladen, Fernbedienung und SDR mit RTL433.
Gibt es noch weitere Registervorschläge?
Was die Firmware angeht so wäre es nett zu wissen, welche davon genutzt werden soll.
Da ich das gerade schon Produktiv einsetze möchte ich hier auf Firmwareebene nicht zu viel testen.
Du kannst mal testen ob es bei nicht so guten Empfangsbedingungen, z.B. bei etwas größerer Entfernung zwischen sduino und Rolladen, was bringt wenn Du beim cc1101 Register 0x13 die NUM_PREAMBLE erhöhst.
ZitatWas die Firmware angeht so wäre es nett zu wissen, welche davon genutzt werden soll.
Sollte eigentlich bei diesem speziellen Fall egal sein.
Zu beachten ist, daß das FSK von meiner Firmware nicht zu dem FSK von der Firmware von Sidey kompatibel ist.
Das FSK von meiner Firmware funktioniert nur mit meiner angepassten und erweitertne Version der 00_SIGNALduino.pm
Ok, dann bleibe ich mal auf meiner Firmware.
Das mit dem Test ist nicht ganz so einfach, da ich noch nicht weiss wie ich mit dem SIGNALduino vom Haus weglaufen soll ...
Welchen Wertebereich hat denn das Register 0x13 und in welchen Schritten sollte es hochgehen?
Dann sehe ich noch das du Register 0x23 bis 0x26 setzt.
Was ist denn hier die Bedeutung und hält du die für relevant?
Die setzten wir aktuell garnicht und diese weichen auch vom Default ab.
Wenn das Senden auch durch Wände und Decken zuverlässig funktioniert, dann müsste Register 0x13 zu passen. Per Default werden 4 preamble Byte gesendet.
Die 0x23 bis 0x26 sind bei den meisten FSK Protokollen gleich , ich hab sie, glaube ich, vom cul übernommen, ist wahrscheinlich nicht relevant ( Frequency Synthesizer Calibration)
Ok.
Dann glaube ich haben wir erstmal eine Konfiguration die recht gut funktioniert.
Ich würde dann erstmal nichts weiter testen.
Ich denke wir werden in dem anderen Thread noch daran arbeiten GFSK stabil zu bekommen,
damit man dauerhaft auf 0x1213 (GFSK) umschalten kann.
Mit den aktuellen Firmwares 3.5.x scheint nur 0x1203 (2FSK stabil zu funktionieren. Auch wenn es wahrscheinlich nicht ideal für den Rolladen ist ud auch nicht von meinem RTL433 SDR empfangen werden kann.
hier sieht man, daß der Defaultwert (4 preamble Byte gesendet) von Register 0x13 passt
remote_shutter-küche_2x-down_433_92MHz-1MSps-1MHz
aaaaaaaad391d391083122fd298a018a8e30cd [Pause: 3459 samples] [Pause: 3,46 ms]
aaaaaaaad391d391083122fd298a018a8e30cd [Pause: 48986 samples] [Pause: 48,99 ms]
aaaaaaaad391d391083122fd29ea01026602a6 [Pause: 3258 samples] [Pause: 3,26 ms]
aaaaaaaad391d391083122fd29ea01026602a6 [Pause: 967860 samples] [Pause: 967,86 ms]
aaaaaaaad391d391083122fd298a018a8e30cd [Pause: 3454 samples] [Pause: 3,45 ms]
aaaaaaaad391d391083122fd298a018a8e30cd [Pause: 48883 samples] [Pause: 48,88 ms]
aaaaaaaad391d391083122fd29ea01026602a6 [Pause: 3264 samples] [Pause: 3,26 ms]
aaaaaaaad391d391083122fd29ea01026602a6 [Pause: 1654809 samples] [Pause: 1,65 s]
Wenn Du das Rojaflex auf dem produktiv System verwenden willst, ist es wahrscheinlich besser wenn Du vorerst auf der aktuellen Firmware 3.5.x bleibst und FSK verwendest.
FSK ist zwar nicht ideal aber es funktioniert auch, wahrscheinlich mit geringerer Reichweite, es müsste auch ausreichend sein um das Rojaflex Modul fertig zu entwickeln.
Du kannst dann immer noch auf GFSK wechseln, wenn es eine Firmware 3.5.x gibt bei der auch GFSK funktioniert und mindestens über eine Woche stabil läuft.
Meine Firmware läuft sehr stabil, ich habe damit eine uptime von deutlich über 100 Tagen.
Hallo,
ich melde mich wieder wegen meines Bresser 5 in 1 Sensor, bei dem der Signalduino ja immer einen 'Checksum Error pos=0' ausgibt. siehe: https://forum.fhem.de/index.php/topic,106594.msg1157364.html#msg1157364 (https://forum.fhem.de/index.php/topic,106594.msg1157364.html#msg1157364)
Mein rtl433 Stick ist heute angekommen. Nachdem ich die rtl433 Software installiert und gestartet habe, wurde mein Bresser 5 in 1 Sensor, der sich komischerweise als 6 in 1 Sensor meldet, sofort fehlerfrei empfangen, sie Bild im Anhang. Es sieht für mich nun danach aus als ob in der Signalduino Software noch etwas nicht richtig berechnet wird.
Kann ich hier noch mehr liefern?
Der bresser_6in1 hat ein anderes Protokoll
https://github.com/merbanan/rtl_433/blob/7480c9c9f986859fdf0f661562f05509cc30a383/src/devices/bresser_6in1.c
wie der bresser_5in1
https://github.com/merbanan/rtl_433/blob/7480c9c9f986859fdf0f661562f05509cc30a383/src/devices/bresser_5in1.c
ich schaus mir heute abend an.
Ich kann von sduino noch mehr MN-Nachrichten gebrauchen
Hallo,
schön das du dir das noch einmal anscheuen möchtest. Gut das es dieses RTL_433 gibt. Ich hatte eigentlich eine Wetterstation mit einem 5i in 1 Sensor gekauft und so dachte ich dass ich auch so einen habe. Ich habe die MN Nachrichten vom Mai angehängt. ich hoffe das reicht so aus.
Irgendwas passt noch nicht, es müsste normalerweise ungefähr so aussehen:
5e aa 18 80 02 c3 18 fa 8f fb 27 68 11 84 81 ff f0 72 00 [Temp 11.8 C Hum 81%]
ae d1 18 80 02 c3 18 fa 8d fb 26 78 ff ff ff fe 02 db f0
f8 2e 18 80 02 c3 18 fc c6 fd 26 38 11 84 81 ff f0 68 00 [Temp 11.8 C Hum 81%]
c4 7d 18 80 02 c3 18 fc 78 fd 29 28 ff ff ff fe 03 97 f0
28 1e 18 80 02 c3 18 fb b7 fc 26 58 ff ff ff fe 02 c3 f0
21 e8 18 80 02 c3 18 fb 9c fc 33 08 11 84 81 ff f0 b7 f8 [Temp 11.8 C Hum 81%]
83 ae 18 80 02 c3 18 fc 78 fc 29 28 ff ff ff fe 03 98 00
5c e4 18 80 02 c3 18 fb ba fc 26 98 11 84 81 ff f0 16 00 [Temp 11.8 C Hum 81%]
d0 bd 18 80 02 c3 18 f9 ad fa 26 48 ff ff ff fe 02 ff f0Die ersten beiden Byte ist die CRC16 Prüfsumme und die nächsten 4 Byte müssten immer gleich sein.
Bitte ändere mal das cc1101 reg 0x07 auf 40
set sduino cc1101_reg 0740anschauen kannst Du die cc1101 Register mit
get sduino ccreg 99Wenn dies noch nicht ausreicht, kannst Du auch mal die Frequenz auf 868.3 ändern.
Evtl passt auch die Datarate noch nicht ganz.
Es müsste ca alle 12 - 24 sek eine MN-Nachricht empfangen werden
ZitatThere are at least two different message types:
- 24 seconds interval for temperatur, hum, uv and rain (alternating messages)
- 12 seconds interval for wind data (every message)
Gruß Ralf
Danke für die Hinweise.
Ich habe das Register 07 von 00 auf 40 geändert. Dann kommt gar keine MN Nachricht mehr rein.
Eine Änderung der Frequenz ergibt keine Änderung.
Die Register sehen jetzt so aus:
ccregAll:
ccreg 00: 01 2E 46 06 2D D4 FF 00 02 00 00 06 00 21 65 6A
ccreg 10: 88 4C 02 22 F8 51 07 00 18 16 6C 43 68 91 87 6B
ccreg 20: F8 56 11 ED 2E 15 11 41 00 59 7F 3E 88 31 0B
Gruß
Dieter
Du kannst auch mal beim register 0x03 die Werte 5, 4 oder 3 versuchen, dies ist der Fifo threshold (5 = 24, 4 = 20, 3=16)
@beaune hat festgestellt, daß die Datenrate recht genau passen muss
Ich hab hier nochmal alles zusammengestellt, wie es bei mir für die 5-in-1 genau konfiguriert ist.
Hardwaremäßig setze ich einen Maple(Doppel)-CUL ein.
Softwareausstattung:
version: V 4.1.2-dev210205 SIGNALduinoAdv cc1101 (R: A4 B0*) - compiled at Feb 6 2021 00:26:38
versionmodul: v3.4.6-dev_ralf_24.04.
versionprotoL: v3.4.6-dev_ralf_24.04.
get sduino ccconf liefert:
ccconf: freq:868.315MHz bWidth:203KHz rAmpl:33dB sens:8dB (DataRate:8232.12Baud)
Modulation:2-FSK (SYNC_MODE:16/16 sync) DEVIATN:57.129kHzget sduino ccreg 99 liefert:
ccregAll:
ccreg 00: 01 2E 46 06 2D D4 FF 00 02 00 00 06 00 21 65 90
ccreg 10: 88 4C 02 22 F8 51 07 00 18 16 6C 43 68 91 87 6B
ccreg 20: F8 56 11 EC 0E 3D 11 41 00 59 7F 3E 88 31 0B
cc1101 reg detail - addr, name, value, (OOK default),[reset]
0x00 IOCFG2 - 0x01 (0D) [29]
0x01 IOCFG1 - 0x2E
0x02 IOCFG0 - 0x46 (2D) [3F]
0x03 FIFOTHR - 0x06 (07)
0x04 SYNC1 - 0x2D (D3)
0x05 SYNC0 - 0xD4 (91)
0x06 PKTLEN - 0xFF (3D) [0F]
0x07 PKTCTRL1 - 0x00 (04)
0x08 PKTCTRL0 - 0x02 (32) [45]
0x09 ADDR - 0x00
0x0A CHANNR - 0x00
0x0B FSCTRL1 - 0x06 [0F]
0x0C FSCTRL0 - 0x00
0x0D FREQ2 - 0x21 (10) [1E]
0x0E FREQ1 - 0x65 (B0) [C4]
0x0F FREQ0 - 0x90 (71) [EC]
0x10 MDMCFG4 - 0x88 (57) [8C]
0x11 MDMCFG3 - 0x4C (C4) [22]
0x12 MDMCFG2 - 0x02 (30)
0x13 MDMCFG1 - 0x22 (23)
0x14 MDMCFG0 - 0xF8 (B9)
0x15 DEVIATN - 0x51 (00) [47]
0x16 MCSM2 - 0x07
0x17 MCSM1 - 0x00 [30]
0x18 MCSM0 - 0x18 [04]
0x19 FOCCFG - 0x16 (14) [36]
0x1A BSCFG - 0x6C
0x1B AGCCTRL2 - 0x43 (07) [03]
0x1C AGCCTRL1 - 0x68 (00) [40]
0x1D AGCCTRL0 - 0x91 (90)
0x1E WOREVT1 - 0x87
0x1F WOREVT0 - 0x6B
0x20 WORCTRL - 0xF8
0x21 FREND1 - 0x56
0x22 FREND0 - 0x11 [16]
0x23 FSCAL3 - 0xEC (E9) [A9]
0x24 FSCAL2 - 0x0E (2A) [0A]
0x25 FSCAL1 - 0x3D (00) [20]
0x26 FSCAL0 - 0x11 (1F) [0D]
0x27 RCCTRL1 - 0x41
0x28 RCCTRL0 - 0x00
0x29 FSTEST - 0x59
0x2A PTEST - 0x7F
0x2B AGCTEST - 0x3E
0x2C TEST2 - 0x88
0x2D TEST1 - 0x31
0x2E TEST0 - 0x0B
Der Empfang geht nur mit ccmode=4
get sduino raw CSccmode=4
Wenn das alles so eingestellt ist, müßte es klappen.
Der Vollständigkeit halber möchte ich hier noch erwähnen, dass man auch mit dem SDR-Stick eine Integration in fhem machen kann, nur so als Rückfallstrategie wenn alle Stricke reißen. Der SDR braucht zwar mehr Strom, das rtl_433 mehr Rechenleistung, und der Empfang ist gefühlt auch nicht ganz so gut, aber es läuft auch ziemlich stabil, und ist auch konfigurationsmäßig nicht sehr schwierig:
- rtl_433 als Service auf dem Raspberry einrichten, auf dem auch fhem läuft.
- Mit diesen Parametern (bei der Frequenz ggf. etwas experimentieren): ExecStart=/usr/local/bin/rtl_433 -f 868315000 -R 119 -M level -F mqtt://localhost:1883,devices=rtl_433
- In fhem einen MQTT2 Server definieren und autocreate einstellen.
Der Rest geht dann automatisch, fhem legt ein MQTT-Device für die Wetterstation an und ermittelt auch die Readings selbständig. Je nachdem, was man loggen/visualisieren will, ist noch Handarbeit gefragt, aber das ist dann mit fhem Boardmitteln ohne weiteres möglich. Da ist ein für die Verwendung mit dem statistic Modul optimiertes fhem-Device natürlich schon etwas einfacher zu handhaben, als ein universelles MQTT Device, das z.B. die Besonderheiten bei der Auswertung der Regenmenge (Zählerüberlauf) nicht kennen kann, geht aber alles. Aber das Ziel dieses Threads ist natürlich ein anderes ;)
Viel Erfolg, bei welcher Lösung auch immer!
Hallo,
danke für eure Hinweise. Ich habe jetzt alles ausprobiert, aber der Checksum Error bleibt.
Ich verwende einen NanoCul mit folgenden Software versionen:
version
V 3.3.4-dev200914 SIGNALduino cc1101 (b0) - compiled at Sep 17 2020 23:37:47
versionmodul: v3.4.6-dev_ralf_01.05.
versionprotoL: v3.4.6-dev_ralf_30.04.
get sduino ccconf liefert:
ccconf: freq:868.315MHz bWidth:203KHz rAmpl:33dB sens:8dB (DataRate:8232.12Baud)
Modulation:2-FSK (SYNC_MODE:16/16 sync) DEVIATN:57.129kHz
get sduino ccreg 99 liefert:
ccreg 00: 01 2E 46 06 2D D4 FF 00 02 00 00 06 00 21 65 90
ccreg 10: 88 4C 02 22 F8 51 07 00 18 16 6C 43 68 91 87 6B
ccreg 20: F8 56 11 ED 2E 15 11 41 00 59 7F 3E 88 31 0B
cc1101 reg detail - addr, name, value, (OOK default),[reset]
0x00 IOCFG2 - 0x01 (0D) [29]
0x01 IOCFG1 - 0x2E
0x02 IOCFG0 - 0x46 (2D) [3F]
0x03 FIFOTHR - 0x06 (07)
0x04 SYNC1 - 0x2D (D3)
0x05 SYNC0 - 0xD4 (91)
0x06 PKTLEN - 0xFF (3D) [0F]
0x07 PKTCTRL1 - 0x00 (04)
0x08 PKTCTRL0 - 0x02 (32) [45]
Der Mode 4 ist eingestellt:
ccconfFSK: N=7 ccmode=4 sync=2DD4 Modulation:2-FSK (SYNC_MODE:16/16 sync) DEVIATN:57.129kHz
Der Unterschied liegt wohl nur in der Software des NanoCul, aber da scheint es keine neuere Version zugeben bzw. mir wird keine im Signalduino Modul angeboten. Läuft die 4.1.2 vielleicht auch auf dem nanoCul?
@baune: Danke für den Hinweis mit dem SDR Stick, das funktioniert so weit ganz gut. Ich denke ich werde das erst mal so machen, bis es vielleicht auch mit dem Signalduino funktioniert.
Viele Grüße
Dieter
Mit der V 3.3.4 sollte es eigentlich auch funktionieren dort gibts auch den ccmode=4
Der Checksum Error wird nur weggehen, wenn Nachrichten vom Bresser 5in1 wie ihn beaune hat, empfangen werden.
Bei Deinem Bresser wird die Checksum anders berechnet, dies kann ich erst ins Signalduino Modul einbauen, wenn ich passende MN-Nachrichten habe.
Ob die MN-Nachrichten passen, kannst Du nur erkennen indem Du die empfangenen MN-Nachrichten anschaust.
Sie müssen ungefähr so aussehen.
Das dritte bis sechste Byte sollten immer gleich sein
Zitat von: Ralf9 am 04 Juni 2021, 19:37:33
5e aa 18 80 02 c3 18 fa 8f fb 27 68 11 84 81 ff f0 72 00 [Temp 11.8 C Hum 81%]
ae d1 18 80 02 c3 18 fa 8d fb 26 78 ff ff ff fe 02 db f0
f8 2e 18 80 02 c3 18 fc c6 fd 26 38 11 84 81 ff f0 68 00 [Temp 11.8 C Hum 81%]
c4 7d 18 80 02 c3 18 fc 78 fd 29 28 ff ff ff fe 03 97 f0
28 1e 18 80 02 c3 18 fb b7 fc 26 58 ff ff ff fe 02 c3 f0
21 e8 18 80 02 c3 18 fb 9c fc 33 08 11 84 81 ff f0 b7 f8 [Temp 11.8 C Hum 81%]
83 ae 18 80 02 c3 18 fc 78 fc 29 28 ff ff ff fe 03 98 00
5c e4 18 80 02 c3 18 fb ba fc 26 98 11 84 81 ff f0 16 00 [Temp 11.8 C Hum 81%]
d0 bd 18 80 02 c3 18 f9 ad fa 26 48 ff ff ff fe 02 ff f0
Die ersten beiden Byte ist die CRC16 Prüfsumme und die nächsten 4 Byte müssten immer gleich sein.
Mir hat das Thema keine Ruhe gelassen und ich hab nochmal recherchiert.
Eine Sache sollten wir vielleicht mal als allererstes klären: Verwendet die Wetterstation von @roelleke jetzt das 5-in-1 oder das 6-in-1-Protokoll? Das läßt sich mit Hilfe von rtl_433 relativ leicht rausfinden, indem man den Parameter -R bemüht. Mit diesem Funktionsaufruf sollten nur dann noch Telegramme empfangen werden, wenn es sich um das in fhem bereits impleentierte 5-in-1-Protokoll handelt:
rtl_433 -f 868272000 -R 119Es scheint aber auch sehr ähnliche Geräte zu geben, die das 6-in-1-Protokoll verwenden. Da gibt es einige interessante Hinweise in diesem Chat:https://github.com/merbanan/rtl_433/issues/1214 (https://github.com/merbanan/rtl_433/issues/1214), speziell https://github.com/merbanan/rtl_433/issues/1214#issuecomment-751349385 (https://github.com/merbanan/rtl_433/issues/1214#issuecomment-751349385). Es würde sich also lohnen, mal zu probieren, ob mit diesem Funktionsaufruf etwas empfangen wird:
rtl_433 -f 868272000 -R 172So hätten wir dann zumindest über das Protokoll Klarheit. Da der Empfang mit fhem bislang nicht funktioniert hat gehe ich davon aus, dass mit -R 119 auch nichts empfangen wird, wohl aber mit -R 172. Wenn das so wäre, könnte man sich auf die Unterschiede stürzen.
Da hätten wir zum Einen den Quellcode des rtl_433: https://github.com/merbanan/rtl_433/blob/master/src/devices/bresser_6in1.c (https://github.com/merbanan/rtl_433/blob/master/src/devices/bresser_6in1.c). Wir wissen ja, dass die Datarate kritisch ist, und diese offenbar aus der short_width abzuleiten ist, die hier mit 124µs angegeben ist. Genau über diese 124 waren wir beim 5-in-1 auch schon mal gestolpert: https://forum.fhem.de/index.php/topic,106594.msg1152200.html#msg1152200 (https://forum.fhem.de/index.php/topic,106594.msg1152200.html#msg1152200). Darin hatte @elektron-bbs mal eine Tabelle erstellt und darin die unterschiedlichen Datarates ausgerechnet, die sich für 122 oder 124 ergeben: https://forum.fhem.de/index.php?action=dlattach;topic=106594.0;attach=151036 (https://forum.fhem.de/index.php?action=dlattach;topic=106594.0;attach=151036). Genau das könnte jetzt der entscheidende Unterschied für den fhem-Empfang werden. Ich würde daher jetzt nal folgendes ausprobieren:
Zitatset sduino cc1101_dataRate 8064
Wenn dann Nachichten kommen, die dem von @Ralf9 zuvor dargestellten Schema entsprechen, kommen wir entscheidend weiter. Ansonsten ruhig mal einfach ein paar Werte für die Datarate ausprobieren. Irgendwo in diesem Bereich wird es liegen; die Erkenntnis beim 5-in-1 war auch eher ein Zufallstreffer.
hier steht
https://github.com/merbanan/rtl_433/blob/7480c9c9f986859fdf0f661562f05509cc30a383/src/devices/bresser_6in1.c
- 1910 084d 18 : RebeckaJohansson, VENTUS W835
- 2030 088d 10 : mvdgrift, Wi-Fi Colour Weather Station with 5in1 Sensor, Art.No.: 7002580, ff 01 in the UV field is (obviously) invalid.
- 1970 0d57 18 : danrhjones, bresser 5-in-1 model 7002580, no UV
- 18b0 0301 18 : konserninjohtaja 6-in-1 outdoor sensor
- 18c0 0f10 18 : rege245 BRESSER-PC-Weather-station-with-6-in-1-outdoor-sensor
- 1880 02c3 18 : f4gqk 6-in-1
- 18b0 0887 18 : npkap
Es gibt demnach auch ein "bresser 5-in-1 model 7002580, no UV"
An den Byte 3-6 lässt sich demnach der Typ erkennen.
@beaune
hat Dein Bresser UV?
Nachtrag:
1/121 ergibt 8264
1/122 ergibt 8196
1/123 ergibt 8130
1/124 ergibt 8064
Zitat@beaune
hat Dein Bresser UV?
Nein, meine hat das nicht. Vielleicht die von @roelleke?
Ich probiere das heute Abend alles mal aus. Im Moment empfange ich mit rtl_433 das Protokoll 172, also einen Bresser 6 in 1 Sensor. Das gibt auch rtl_433 so aus.
Der Sensor hat auch kein UV. Ich melde mich dann wenn ich die Einstellungen ausprobiert habe.
Ich habe jetzt alle Datenraten, die Ralf9 mir angeben hat ausprobiert. Ich bekomme aber keine sinnvollen Meldungen herein. Es sieht immer gleich aus. und zwar so:
2021.06.06 18:50:19 4: sduino8/msg READ: MN;D=40864409244308880EE84A012A04F718C80089400240220A850D5960;N=7;R=200;
2021.06.06 18:50:19 4: sduino8 Parse_MN: Found 2-FSK Protocol id 108 length 56 RSSI = -102 -> Bresser 5in1
2021.06.06 18:50:19 4: sduino8 ParseMN: method error! Bresser 5in1: Checksum Error pos=0
Wobei das 3. und 4. Byte nie gleich sind.
Den RTL-SDR Stick betreibe ich mit folgender Konfiguration:
# to get the "protocol"-token available in output and set the time output to ISO
report_meta level
# specify MQTT output and formatting
output mqtt://localhost:1883,retain=0,devices=rtl_433
# enable the needed protocol
protocol 172 # Bresser 6 in 1 Sensor
frequency 868.315M
sample_rate 1024k
Für mich sieht es so aus, das der Signalduino zwar etwas erkennt, was ein 5 in 1 Sensor seien könnte, aber in wirklichkeit ein 6 in 1 Sensor oder ein neuer 5 in 1 Sensor ist, der ein etwas anderes Protokoll benutzt und daher nicht witklich richtig dekodiert wird.
ZitatRSSI = -102
Ich habe mir mal die RSSI Werte angeschaut, sind alle mit Werten kleiner -100 dB an der Empfangsgrenze.
Die RSSI Werte sollten besser als -90 sein
In beiden Protokollen wird dieselbe Präambel {0xaa, 0xaa, 0x2d, 0xd4} verwendet. Das ist wahrscheinlich der Grund, warum fhem beim Empfang der 6-in-1-Telegramme schon mal "Bresser" anzeigt, aber dann eben nicht dekodieren kann, weil es das falsche Protokoll ist. Eigentlich ist das ja schon ein gutes Zeichen, denn dann muß zumindest die Präambel richtig rüber gekommen sein.
Vielleicht ist es einfacher, in dem ganzen "Datenmüll" im Logfile nach den richtigen Telegrammen zu suchen, wenn man nach der ID sucht, die wir vom rtl_433 her ja schon kennen: 198001eb.
Man könnte auch auf das Intervall achten: offenbar gibt es zwei verschiedene Telegrammtypen, von denen der eine alle 12, und der andere alle 24s geschickt wird, und die soweit ich weiß unterschiedlich lang sind.
Die größten Erfolgsschancen erwarte ich bei Datarate 8064, wobei es wahrscheinlich wirklich Sinn machen würde, Übertragungsfehler aufgrund des schlechten Empfangs zu vermeiden, und zumindest für diese Tests die Entfernung zur Wetterstation deutlich zu verringern. Macht das Suchen nach den richtigen Einstellungen einfacher. Ist halt jetzt ein bisschen Sisyphus-Arbeit...
Hallo,
ich glaube ich habe schlechte CC1101 bekommen. Ich habe den NanoCul gegen einen anderen getausch, der hat dann Pegel von -95.
auch eine Veänderung des Empfangsortes, direkte Sicht zum Senosor bei einer Entfernung von ca. 10m änder nichts am Pegel.
Beim SDR Stick habe ich RSSi Werte von stabil -0.1 db. Ich denke ich muß zunächst mal einen guten CC1101 besorgen, sonst bringt das warscheinlich alles nichts.
Entschuldigt die eventuell blöde Frage, aber bekomme ich die Firmware auch auf den Doppel-WLAN-CUL von loctulus?
https://forum.fhem.de/index.php/topic,80872.msg786317.html#msg786317
wollte damit dann wenn es geht auch eine Bresser 5in1 empfangen.
Danke & Grüße
Mit der firmware Maple_cul_serial müsste es übers WLAN funktionieren.
Momentan gibts nur für die V4.1.1 ein bin file, für die aktuelle Version 4.12 muss ich erst noch ein bin file erstellen
https://github.com/Ralf9/SIGNALDuino/releases/download/V4.1.1-dev200627/Maple_cul_serial_411dev200627.bin
Zitat von: roelleke am 20 Mai 2021, 14:39:18
Hallo,
danke für das Foto. Mein Sensor hat eine andere Typennummer, so dass er schon ein anderes Protokoll benutzen kann.
Welche Typennr hat Dein Bresser 5 zu 1?
@Brillomat hat auch einen Bresser 5 zu 1 mit einer anderen Typennr wie beaune
Zitat von: Brillomat am 16 Juli 2021, 19:23:03
Ok, vielen lieben Dank Euch beiden. Ich habe tatsächlich eine andere Seriennummer als die von dem Foto aus dem genannten Thread.
Hi,
Der Vollständigkeit halber habe ich die Seriennummer meiner Bresser auch einmal angehangen.
LG
Michael
Wie hier zu sehen ist, wird die "Bresser 5 in 1 comfort neu" Wetterstation auch mit dem rfmode "bresser_5in1_8220" empfangen.
https://github.com/RFD-FHEM/RFFHEM/issues/607#issuecomment-890476479
Es gibt dafür die neue Protokoll ID 115, ich habe es in die dev Version v3.4.7-dev_ralf_01.08. meiner meiner Variante der 00_SIGNALduino.pm übernommen
https://forum.fhem.de/index.php/topic,111653.msg1058900.html#msg1058900
Es ist dafür auch das angepasste 14_SD_WS Modul in der Anlage erforderlich.
Da die Nachrichten des "bresser 5 in 1 comfort neu" kürzer als die des etwas älteren bresser 5 in 1 sind, gbts dafür einen neuen "set rfmode bresser_6in1_8220".
Der "bresser 5 in 1 comfort neu" funktioniert aber auch mit dem bisherigen "set rfmode bresser_5in1_8220"
Es gibt von den Bresser Wetterstationen verschiedene Varianten.
Ich kann MN-Nachrichten von den Bresser Wetterstationen gebrauchen.
Um zu testen ob es in der Nachbarschaft eine Bresser Wetterstation gibt, muß nur das "set rfmode bresser_5in1_8220" verwendet und die Protocol IDs 108 und 115 aktiviert werden.
Es gibt auch fehlerhafte 868MHz cc1101 Module bei denen die Frequenz nicht ganz stimmt.
Gruß Ralf
Zitat von: Ralf9 am 02 August 2021, 00:59:20
[...]
Um zu testen ob es in der Nachbarschaft eine Bresser Wetterstation gibt, muß nur das "set rfmode bresser_5in1_8220" verwendet und die Protocol IDs 108 und 115 aktiviert werden.
[...]
Hi,
vlt. eine blöde Frage, aber ich bin leider nicht so ganz mit der Materie vertraut. Kann es sein, dass dazu auch noch eine neue Version der signalduino_protocols.pm notwendig ist?
Das Protocol 115 taucht bei mir überhaupt nicht auf. Weder im Fhem UI, noch in der signalduino_protocols.pm (mit meinem Halbwissen gehe ich davon aus, dass Protocol ID genau dort aufgeführt sein müsste).
LG,
Michael
ja es ist eine neue Version der 00_SIGNALduino.pm und lib/signalduino_protocols.pm notwendig.
Dies habe ich hier
"angepasstes 00_SIGNALduino Modul, auch für FSK und für den Maple"
https://forum.fhem.de/index.php/topic,111653.msg1058900.html#msg1058900
unter "Dev Version" beschrieben.
Die neue ID 115 ist in der signalduino_protocols.pm definiert und in der 00_SIGNALduino.pm werden die beiden Prüfsummen berechnet.
Hallo und danke,
der Fehler saß (wie fast immer) vor dem Bildschirm - ich hatte mich an Deinem master respository bedient und nicht von deinem development gezogen.
Edit: Allerdings kann ich mit den Modulen aus dem dev respository keine sduinos mehr anlegen, bzw. meine angelegten sind nicht mehr da.
Ist aber kein Problem - bin dann wieder auf dein master repsository umgestiegen und siehe da, meine sduinos sind wieder vorhanden (halt nur ohne Prot 115).
LG
Michael
Super,
meine 5in1 wird jetzt auch erkannt:
2021-08-02 10:36:51 batteryState ok
2021-08-02 10:36:51 channel 0
2021-08-02 10:36:51 id 20B0170C
2021-08-02 10:36:51 rain 267.2
2021-08-02 10:36:51 state Ws: 0.8 Wg: 0.8 Wd: WNW R: 267.2
2021-08-02 10:36:51 type Bresser_6in1, new Bresser_5in1
2021-08-02 10:36:51 windDirectionDegree 292
2021-08-02 10:36:51 windDirectionText WNW
2021-08-02 10:36:51 windGust 0.8
2021-08-02 10:36:51 windGust_kmh 2.9
2021-08-02 10:36:51 windSpeed 0.8
2021-08-02 10:36:51 windSpeed_kmh 2.9
vielen vielen Dank.
Zitatid 20B0170C
Bei Alex ist die ID 20B00C16, wenn es Dir nichts ausmacht, wenn der rain Zähler auf 0 zurückgesetzt wird,
dann kannst Du mal testen ob die ID sich ändert, wenn Du kurz die Batterie rausnimmst.
Wenn Du fast leere Batterien hast, kannst Du auch mal testen ob der Sensor den Batteriezustand mitsendet.
Zitat von: Ralf9 am 02 August 2021, 11:07:34
[...]dann kannst Du mal testen ob die ID sich ändert, wenn Du kurz die Batterie rausnimmst.[...]
Sobald es hier nicht mehr regnet, werde ich das testen und Dir eine Rückmeldung geben.
Zitat von: Ralf9 am 02 August 2021, 11:07:34
Wenn Du fast leere Batterien hast, kannst Du auch mal testen ob der Sensor den Batteriezustand mitsendet.
Also laut Bresser Basisstation ist der Batteriezustand bereits low.
Im FHEM Listing ist er "ok"
2021-08-02 12:15:16 batteryState okLG
Michael
Zitat von: Ralf9 am 02 August 2021, 11:07:34
[...] dann kannst Du mal testen ob die ID sich ändert, wenn Du kurz die Batterie rausnimmst.
Wenn Du fast leere Batterien hast, kannst Du auch mal testen ob der Sensor den Batteriezustand mitsendet.
[...]
2021-08-02 12:54:59 batteryState low
2021-08-02 12:54:59 id 20B0170C
[...]
Hi,
also nach Batterieentnahme bleibt die ID identisch, aber der Batteriestatus hat sich geändert und zwar von
ok auf
low.
LG,
Michael
Lädst du mal bitte ein paar DMSG und RAWMSG mit allen Readings hoch, oder halt das Log vom Sensor, falls diese Daten dort enthalten sind, so wie hier im Beispiel:
2021-08-01_14:39:19 SD_WS_115_0 T: 18.6 H: 60 W: 1.7
2021-08-01_14:39:19 SD_WS_115_0 temperature: 18.6
2021-08-01_14:39:19 SD_WS_115_0 humidity: 60
2021-08-01_14:39:19 SD_WS_115_0 windSpeed: 1.7
2021-08-01_14:39:19 SD_WS_115_0 windDirectionDegree: 158
2021-08-01_14:39:19 SD_WS_115_0 windDirectionText: SSE
2021-08-01_14:39:19 SD_WS_115_0 windGust: 1.9
2021-08-01_14:39:19 SD_WS_115_0 batteryState: ok
2021-08-01_14:39:19 SD_WS_115_0 windGust_kmh: 6.84
2021-08-01_14:39:19 SD_WS_115_0 windSpeed_kmh: 6.12
2021-08-01_14:39:19 SD_WS_115_0 DMSG: W115#068720B00C1618FE68FE1588186260FFF02B00000000000000000002
2021-08-01_14:39:19 SD_WS_115_0 RSSI: -85
2021-08-01_14:39:19 SD_WS_115_0 RAWMSG: MN;D=068720B00C1618FE68FE1588186260FFF02B00000000000000000002;R=234;
2021-08-01_14:39:19 SD_WS_115_0 Protocol_ID: 115
Falls die DMSG und die RAWMSG bei den Events nicht dabei sind ist evtl noch ein "addvaltrigger 1" erforderlich.
attr sduino addvaltrigger 1
Die DMSG und die RAWMSG müssten auch in den Internals des SD_WS_115_0 stehen.
Hallo,
ich kann gerne noch mehr liefern - momentan tut sich beim Wind nicht wirklich viel.
LogRegex: SD_WS_115_0.*
2021-08-03_05:44:05 SD_WS_115_0 RAWMSG: MN;D=DA4220B0170C18FFFFFF2928112299FFF0EB0000000000000000002E;N=7;R=251;
2021-08-03_05:44:17 SD_WS_115_0 Ws: 0 Wg: 0 Wd: WNW R: 0.8
2021-08-03_05:44:17 SD_WS_115_0 Protocol_ID: 115
2021-08-03_05:44:17 SD_WS_115_0 RSSI: -75.5
2021-08-03_05:44:17 SD_WS_115_0 RAWMSG: MN;D=C03720B0170C18FFFFFF2928FFFFF7FF01B10000000000000000000E;N=7;R=253;
2021-08-03_05:44:17 SD_WS_115_0 DMSG: W115#20B0170C18FFFFFF2928FFFFF7FF01
2021-08-03_05:44:29 SD_WS_115_0 T: 11.2 H: 99 Ws: 0 Wg: 0 Wd: WNW
2021-08-03_05:44:29 SD_WS_115_0 RAWMSG: MN;D=DA4220B0170C18FFFFFF2928112299FFF0EB00000000000000000014;N=7;R=251;
2021-08-03_05:44:29 SD_WS_115_0 RSSI: -76.5
2021-08-03_05:44:29 SD_WS_115_0 Protocol_ID: 115
2021-08-03_05:44:29 SD_WS_115_0 DMSG: W115#20B0170C18FFFFFF2928112299FFF0
2021-08-03_05:45:17 SD_WS_115_0 T: 11.2 H: 99 Ws: 0 Wg: 0 Wd: WNW
2021-08-03_05:45:17 SD_WS_115_0 RAWMSG: MN;D=DA4220B0170C18FFFFFF2928112299FFF0EB00000000000000000033;N=7;R=253;
2021-08-03_05:45:17 SD_WS_115_0 RSSI: -75.5
2021-08-03_05:45:17 SD_WS_115_0 Protocol_ID: 115
2021-08-03_05:45:17 SD_WS_115_0 DMSG: W115#20B0170C18FFFFFF2928112299FFF0
2021-08-03_05:46:29 SD_WS_115_0 T: 11.2 H: 99 Ws: 0 Wg: 0 Wd: WNW
2021-08-03_05:46:29 SD_WS_115_0 DMSG: W115#20B0170C18FFFFFF2928112299FFF0
2021-08-03_05:46:29 SD_WS_115_0 RAWMSG: MN;D=DA4220B0170C18FFFFFF2928112299FFF0EB00000000000000000034;N=7;R=253;
2021-08-03_05:46:29 SD_WS_115_0 RSSI: -75.5
2021-08-03_05:46:29 SD_WS_115_0 Protocol_ID: 115
2021-08-03_05:51:30 SD_WS_115_0 Ws: 0 Wg: 0 Wd: WNW R: 0.8
2021-08-03_05:51:30 SD_WS_115_0 id: 20B0170C
2021-08-03_05:51:30 SD_WS_115_0 RSSI: -77
2021-08-03_05:51:30 SD_WS_115_0 Protocol_ID: 115
2021-08-03_05:51:30 SD_WS_115_0 RAWMSG: MN;D=C03720B0170C18FFFFFF2928FFFFF7FF01B100000000000000000038;N=7;R=250;
2021-08-03_05:51:30 SD_WS_115_0 DMSG: W115#20B0170C18FFFFFF2928FFFFF7FF01
2021-08-03_05:52:18 SD_WS_115_0 Ws: 0 Wg: 0 Wd: WNW R: 0.8
2021-08-03_05:52:18 SD_WS_115_0 DMSG: W115#20B0170C18FFFFFF2928FFFFF7FF01
2021-08-03_05:52:18 SD_WS_115_0 RAWMSG: MN;D=C03720B0170C18FFFFFF2928FFFFF7FF01B100000000000000000020;N=7;R=249;
2021-08-03_05:52:18 SD_WS_115_0 Protocol_ID: 115
2021-08-03_05:52:18 SD_WS_115_0 RSSI: -77.5
2021-08-03_05:52:30 SD_WS_115_0 T: 11.2 H: 99 Ws: 0 Wg: 0 Wd: WNW
2021-08-03_05:52:30 SD_WS_115_0 DMSG: W115#20B0170C18FFFFFF2928112299FFF0
2021-08-03_05:52:30 SD_WS_115_0 RAWMSG: MN;D=DA4220B0170C18FFFFFF2928112299FFF0EB0000000000000000000B;N=7;R=248;
2021-08-03_05:52:30 SD_WS_115_0 Protocol_ID: 115
2021-08-03_05:52:30 SD_WS_115_0 RSSI: -78
2021-08-03_05:53:30 SD_WS_115_0 Ws: 0 Wg: 0 Wd: WNW R: 0.8
2021-08-03_05:53:30 SD_WS_115_0 Protocol_ID: 115
2021-08-03_05:53:30 SD_WS_115_0 RSSI: -76.5
2021-08-03_05:53:30 SD_WS_115_0 RAWMSG: MN;D=C03720B0170C18FFFFFF2928FFFFF7FF01B100000000000000000000;N=7;R=251;
2021-08-03_05:53:30 SD_WS_115_0 DMSG: W115#20B0170C18FFFFFF2928FFFFF7FF01
2021-08-03_05:54:42 SD_WS_115_0 Ws: 0 Wg: 0 Wd: WNW R: 0.8
2021-08-03_05:54:42 SD_WS_115_0 DMSG: W115#20B0170C18FFFFFF2928FFFFF7FF01
2021-08-03_05:54:42 SD_WS_115_0 RSSI: -77.5
2021-08-03_05:54:42 SD_WS_115_0 Protocol_ID: 115
2021-08-03_05:54:42 SD_WS_115_0 RAWMSG: MN;D=C03720B0170C18FFFFFF2928FFFFF7FF01B100000000000000000037;N=7;R=249;
2021-08-03_05:54:54 SD_WS_115_0 T: 11.2 H: 99 Ws: 0 Wg: 0 Wd: WNW
2021-08-03_05:54:54 SD_WS_115_0 RAWMSG: MN;D=DA4220B0170C18FFFFFF2928112299FFF0EB00000000000000000030;N=7;R=249;
2021-08-03_05:54:54 SD_WS_115_0 RSSI: -77.5
2021-08-03_05:54:54 SD_WS_115_0 Protocol_ID: 115
2021-08-03_05:54:54 SD_WS_115_0 DMSG: W115#20B0170C18FFFFFF2928112299FFF0
2021-08-03_05:55:06 SD_WS_115_0 Ws: 0 Wg: 0 Wd: WNW R: 0.8
2021-08-03_05:55:06 SD_WS_115_0 DMSG: W115#20B0170C18FFFFFF2928FFFFF7FF01
2021-08-03_05:55:06 SD_WS_115_0 RAWMSG: MN;D=C03720B0170C18FFFFFF2928FFFFF7FF01B10000000000000000003A;N=7;R=250;
2021-08-03_05:55:06 SD_WS_115_0 RSSI: -77
2021-08-03_05:55:06 SD_WS_115_0 Protocol_ID: 115
2021-08-03_05:55:18 SD_WS_115_0 T: 11.2 H: 99 Ws: 0 Wg: 0 Wd: WNW
2021-08-03_05:55:18 SD_WS_115_0 DMSG: W115#20B0170C18FFFFFF2928112299FFF0
2021-08-03_05:55:18 SD_WS_115_0 Protocol_ID: 115
2021-08-03_05:55:18 SD_WS_115_0 RSSI: -76.5
2021-08-03_05:55:18 SD_WS_115_0 RAWMSG: MN;D=DA4220B0170C18FFFFFF2928112299FFF0EB0000000000000000000A;N=7;R=251;
2021-08-03_05:55:30 SD_WS_115_0 Ws: 0 Wg: 0 Wd: WNW R: 0.8
2021-08-03_05:55:30 SD_WS_115_0 DMSG: W115#20B0170C18FFFFFF2928FFFFF7FF01
2021-08-03_05:55:30 SD_WS_115_0 Protocol_ID: 115
2021-08-03_05:55:30 SD_WS_115_0 RSSI: -78
2021-08-03_05:55:30 SD_WS_115_0 RAWMSG: MN;D=C03720B0170C18FFFFFF2928FFFFF7FF01B10000000000000000001D;N=7;R=248;
2021-08-03_05:55:42 SD_WS_115_0 T: 11.2 H: 99 Ws: 0 Wg: 0 Wd: WNW
2021-08-03_05:55:42 SD_WS_115_0 RAWMSG: MN;D=DA4220B0170C18FFFFFF2928112299FFF0EB00000000000000000024;N=7;R=246;
2021-08-03_05:55:42 SD_WS_115_0 RSSI: -79
2021-08-03_05:55:42 SD_WS_115_0 Protocol_ID: 115
2021-08-03_05:55:42 SD_WS_115_0 DMSG: W115#20B0170C18FFFFFF2928112299FFF0
2021-08-03_05:55:54 SD_WS_115_0 Ws: 0 Wg: 0 Wd: WNW R: 0.8
2021-08-03_05:55:54 SD_WS_115_0 DMSG: W115#20B0170C18FFFFFF2928FFFFF7FF01
2021-08-03_05:55:54 SD_WS_115_0 RAWMSG: MN;D=C03720B0170C18FFFFFF2928FFFFF7FF01B10000000000000000002C;N=7;R=245;
2021-08-03_05:55:54 SD_WS_115_0 Protocol_ID: 115
2021-08-03_05:55:54 SD_WS_115_0 RSSI: -79.5
2021-08-03_05:56:06 SD_WS_115_0 T: 11.2 H: 99 Ws: 0 Wg: 0 Wd: WNW
2021-08-03_05:56:06 SD_WS_115_0 RAWMSG: MN;D=DA4220B0170C18FFFFFF2928112299FFF0EB00000000000000000011;N=7;R=248;
2021-08-03_05:56:06 SD_WS_115_0 Protocol_ID: 115
2021-08-03_05:56:06 SD_WS_115_0 RSSI: -78
2021-08-03_05:56:06 SD_WS_115_0 DMSG: W115#20B0170C18FFFFFF2928112299FFF0
2021-08-03_05:56:18 SD_WS_115_0 Ws: 0 Wg: 0 Wd: WNW R: 0.8
2021-08-03_05:56:18 SD_WS_115_0 DMSG: W115#20B0170C18FFFFFF2928FFFFF7FF01
2021-08-03_05:56:18 SD_WS_115_0 Protocol_ID: 115
2021-08-03_05:56:18 SD_WS_115_0 RSSI: -78.5
2021-08-03_05:56:18 SD_WS_115_0 RAWMSG: MN;D=C03720B0170C18FFFFFF2928FFFFF7FF01B100000000000000000032;N=7;R=247;
2021-08-03_05:56:30 SD_WS_115_0 T: 11.2 H: 99 Ws: 0 Wg: 0 Wd: WNW
2021-08-03_05:56:30 SD_WS_115_0 RAWMSG: MN;D=DA4220B0170C18FFFFFF2928112299FFF0EB0000000000000000000D;N=7;R=251;
2021-08-03_05:56:30 SD_WS_115_0 Protocol_ID: 115
2021-08-03_05:56:30 SD_WS_115_0 RSSI: -76.5
2021-08-03_05:56:30 SD_WS_115_0 DMSG: W115#20B0170C18FFFFFF2928112299FFF0
LG,
Michael
ZitatT: 11.2 H: 99 Ws: 0 Wg: 0 Wd: WNW
Die Luftfeuchtigkeit ist mit 99 etwas hoch.
Ist der batteryState immer noch low?
Zitat von: Ralf9 am 03 August 2021, 08:26:19
Die Luftfeuchtigkeit ist mit 99 etwas hoch.
Ist der batteryState immer noch low?
Ich habe die Batterien noch
nicht gewechselt - die Basisstation zeigt weiterhin
low an, in FHEM ist der batteryState
ok.
Hier ist noch ein Logifleschnipsel mit ein wenig Wind:
2021-08-03_08:59:19 SD_WS_115_0 T: 12.3 H: 97 Ws: 0.6 Wg: 0.6 Wd: NNW
2021-08-03_08:59:19 SD_WS_115_0 windSpeed: 0.6
2021-08-03_08:59:19 SD_WS_115_0 windSpeed_kmh: 2.2
2021-08-03_08:59:19 SD_WS_115_0 windGust: 0.6
2021-08-03_08:59:19 SD_WS_115_0 windGust_kmh: 2.2
2021-08-03_08:59:19 SD_WS_115_0 DMSG: W115#20B0170C18FF99FF3388123297FFF0
2021-08-03_08:59:19 SD_WS_115_0 RAWMSG: MN;D=B38620B0170C18FF99FF3388123297FFF0D8000000000000000001AB;N=7;R=11;LG,
Michael
Zitatdie Basisstation zeigt weiterhin low an
Ist dies evtl eine Anzeige, daß die Batterien in der Basisstation fast leer sind?
Es gibt auch Sensoren, wie z.B. LaCrosse, da wird nach einem Batteriewechsel ein Flag gesetzt, das Flag wird dann nach einigen Stunden automatisch wieder gelöscht.
Zitat von: Ralf9 am 03 August 2021, 10:59:36
Ist dies evtl eine Anzeige, daß die Batterien in der Basisstation fast leer sind?
Also ... ich betreibe das Gerät mit Netzstrom (ein alternativer Batteriebetrieb wäre aber auch möglich). In der zugehörigen Bedienungsanleitung taucht das Batteriesymbol überhaupt nicht auf.
Aber: Ich habe mir jetzt auch mal (im Netz) ein paar Anleitungen älterer Bresser Stationen angeschaut - dort entspricht das Batteriesymbol dem Batteriezustand der Basisstation.
LG,
Michael
Irgendwie sehe ich mit den diversen Artikelnummern nicht so richtig durch :-(
Gefunden habe ich z.B. folgendes:
Manual_7002510-7002511-7002512-7902510-7902511-7902512-9602510_Weather-Center-5in1_de-en_BRESSER_v032021a.pdf
https://www.optical-systems.com/out/media/95431902a995d53b0f3141c2ef8cfca8.pdf
2. Batteriestandsanzeige Basisstation
22. Batteriestandsanzeige Außensensor
Manual_7002580-7002581-7902580-7902581-7802580_WIFI-Colour-Weather-Station_it_BRESSER_v072021a.pdf
https://www.optical-systems.com/out/media/19f4e7dd1994303ac684cbbf686e6a3e.pdf
Sensor Batteriestand niedrig, gutes Signal Batterie-Symbol wird angezeigt
Es könnte auch sein, das die Wetterstation einen einmal empfangenen Zustand "Batterie leer" bis zum Neustart speichert.
Du könnest ja in den Logs vom Sensor nachsehen, ob irgendwann mal "batteryState: low" auftaucht.
Zitat von: elektron-bbs am 03 August 2021, 17:24:55
Du könnest ja in den Logs vom Sensor nachsehen, ob irgendwann mal "batteryState: low" auftaucht.
Hallo,
der Zustand war nur einmal auf low, nachdem ich das Batteriefach geöffnet und wieder geschlossen hatte.
Der nächste Zustand war aber wieder ok.
Was die Versionen angeht, so stehe ich da auch ein wenig auf dem Schlauch. Meine Papierversion führt das Batteriesymbol auf dem Display noch nicht mal auf. Ich könnte mir aber trotzdem vorstellen, dass die Basisstation gemeint ist wie bei dieser Version https://www.bresser.de/out/media/fe393b387118d49fc708abcc5b1668f6.pdf (https://www.bresser.de/out/media/fe393b387118d49fc708abcc5b1668f6.pdf)
LG
Michael
Hallo,
ich habe jetzt meinen neuen CC1101 Baustein erhalten und die neue Software mit meinem Bresser 6 in1/new 5 in1 (Bild) ausprobiert.
Zunächst lief es auch ganz gut, aber nach ein paar Stunden funktionierte es nicht mehr.
Erst als ich die Bandbreite von 203 khz auf 541 khz geändert habe funktionierte es wieder. Damit funktioniert dann jetzt auch mein alter CC1101, wenn auch nicht so gut wie der neue.
Hin und wieder werden Temperatur und Feuchtigkeit nicht mehr aktualisiert. Im Log finde ich dann folgende Fehlermeldung:
2021.08.05 16:37:42 4: sduino8: SD_WS_Parse protocol 115, rawData 198001EB18FF99FF0688240253FFF0
2021.08.05 16:37:42 4: sduino8: SD_WS_Parse decoded protocol-id 115 (Bresser_6in1, new Bresser_5in1), sensor-id 198001EB
2021.08.05 16:37:42 3: sduino8: SD_WS_115_0 ERROR - Temp diff too large (old 25.6, new 24, diff 1.6)
Das ist etwas blöd wenn einige Werte ausfallen z.B. wenn man den Server neu startet oder Störungen auftreten. Die Werte werden erst wieder neu eingetragen wenn man die Readings "temperature" und "humidity" löscht, was natürlich etwas umständlich ist. Ich denke, bei der Prüfung sollte der Timestamp mit berücksichtigt werden, oder vielleicht sollte solch eine Überprüfung gar nicht vorgenommen werden.
Das Problem sind die Attribute max-deviation-hum und max-deviation-temp, da ist in einigen Fällen der Defaultwert 1 zu wenig.
Siehe auch in der Device specific help
Diese Routinen sind anscheinend nicht für die Wetterstationen geeignet. Wahrscheinlich ist es besser, wenn diese Prüfung defaultmässig nicht aktiv ist.
Als Workaround kannst Du die Werte auf 50 erhöhen.
Evtl hast Du fehlerhafte CC1101 Module erwischt, wo die Frequenz nicht ganz passt. Wo hast Du diese gekauft? Die wo ich bis jetzt bei AliExpress gekauft habe waren alle ok.
Danke für den Tipp mit den Attributen, die hatte ich noch gar nicht gesehen.
Die CC1101 Module habe ich bei Aliexpress und bei Amazon gekauft. Es sieht aber so ziemlich gleich aus. Ich werde mit den Frequenzen noch ein wenig herrumprobieren, vielleicht bringt das ja noch etwas.
Ich hab mir jetzt auch einen RTL SDR gekauft (RTL2832U und R820T2)
Kann mir jemand unter Windows 10 eine Software empfehlen mit der ich bei FSK am Spektrum den Frequenzhub ermitteln kann
https://wiki.fhem.de/wiki/Unbekannte_Funkprotokolle#Sendefrequenz_und_Frequenzhub
Gruß Ralf
Ich habe den SDRSharp installiert, da lässt sich aber recht viel einstellen (siehe Anlage), da komme ich ohne Hilfe nicht weiter.
Mir ist auch nicht klar wie ich zur eingefrohrenen Spektrumansicht komme wie bei hackaday (siehe Anlage)
https://hackaday.com/2020/01/28/rf-modulation-crash-course-for-hackers/
Bei sieht es so aus wie in der Anlage
Gruß Ralf
Irgendwas passt nicht, obwohl mein TX29DHT-IT alle 12 Sek sendet und nur ca 2m vom SDR entfernt ist, kann ich im Spektrum keinen Ausschlag erkennen :(
Anscheinend ist der SDRSharp dafür nicht geeignet,
oder liegt es evtl daran, daß der RTL2832U Chip dafür nicht geeignet ist?
damit
https://github.com/merbanan/rtl_433
kann ich den TX29DHT-IT problemlos empfangen, ich kann damit auch meine 433MHz Sensoren empfangen
Falls noch relevant: ich nutze mit meinem RTL-SDR auch den URH Universal Radio Hacker. Im Wasserfall ist auch nicht jedes Signal zu sehen, aber er hat eine Signalhistorie die hilfreich ist. Frequenzbereich und Wiederholung auf Standard 1M ist gut für den Anfang.
Und weil das mit dem anzuzeigenden Frequenzbereich bzw dem direkten Ablesen des Frequenzhub auch nicht ganz so will wie ich, einen CC1101 am Nano (also quasi ein CUL) um über Arduino-IDE und mit ELECHOUSE_CC1101_SRC_DRV die Parameter so einzustellen, dass sie deckungsgleich werden.
Gruß,
Dieter
Hallo
Ich bin Anfänger in Sachen Fhem und Signalduino
Ich möchte gerne Nachbars Wetterstation werte abgreifen der hat eine Bresser 5 in 1 station
Meine Hardware ist ein Nuk mit Ubuntu wo Iobroker und Fhem drauf läuft
Jetzt habe ich noch ein nanocul 868
habe die tage hier mich mal durchgelesen aber ich bekomme es nicht hin , bekomme keine Daten von der station
Kann mir jemand helfen ?
LG.Pajda
Wie weit bist Du gekommen?
Das 00_ SIGNALDuino.pm Modul v3.4.10-dev_ralf_
https://forum.fhem.de/index.php/topic,111653.msg1058900.html#msg1058900
Die Firmware V3.3.4-dev211207 flashen
Ein update auf mein aktuelles 14_sd_ws.pm Modul
update all https://raw.githubusercontent.com/Ralf9/14_SD_WS/main/controls_ralf9_sd_ws.txt
Den passenden rfmode zum sduino senden
https://forum.fhem.de/index.php/topic,111653.msg1058902.html#msg1058902
set sduino rfmode Bresser_5in1_u_7in1__B28_N7_8220
Gruß Ralf
Danke für schnelle Antwort
Ich habe es jetzt nach deine Anleitung gemacht aber bis jetzt keine Veränderungen sehe Bilder
LG.Pajda
Bitte poste mal ein log Auszug mit sduino verbose 4
Log
Und Flash Log
Ich glaube der CC1101-868 ist defekt
Momentan empfängt er nichts
Laut dem Bildschirmfoto 2022-02-18 um 17.12.01.png
DMSG W115#1323...
LASTDMSG W115#1323...
RAWMSG MN;D=764C..
hat er schon mal was vom Bresser 5in1 empfangen
Bitte steck den sduino mal aus und wieder ein und schau mal im log ob er innerhalb der ersten 1-2 Minuten nach dem Stecken was empfängt
Ich habe den Fehler gefunden der nanocul war in eine Plastik hülle die auf den knöpf gedrückt hat
Jetzt kommen Signale und sehr schnell .
Danke
Ps: Wie schliesse ich denn original update aus das immer deine Daten bleiben ?
Ja, das passt jetzt, er wird alle 12 Sekunden empfangen und wurde per autocreate angelegt.
Ist ein ungewöhnlicher Fehler, man muß anscheinend mit allem rechnen, er war wenigstens einfach zu beheben :)
Ralf9
Wie schliesse ich denn original update aus das immer deine Daten bleiben ?
LG.Pajda
ZitatPs: Wie schliesse ich denn original update aus das immer deine Daten bleiben?
damit kannst Du 00_SIGNALduino und 14_SD_WS vom update ausschliessen
attr global exclude_from_update 00_SIGNALduino 14_SD_WS
Danke :)
#Ralf9
Hallo Ralf9
ich würde gerne ein readings mit "rain am tag" gehabt an statt "rain" da da rain total schon da ist .
sehe Bild
und sowie es aussieht ist die wind Geschwindigkeit in m/s und nicht in kmh
Lg.Pajda
siehe hier
https://forum.fhem.de/index.php/topic,78809.msg1210256.html#msg1210256
Hallo Ralf,
ich habe mir einen CUL mit ATMEGA328 und CC1101 gebaut, der allerdings nicht mit dem SignalDuino kompatibel ist. Bisher benutze ich diesen CUL nur für das MAX!-System.
Jetzt will ich zusätzlich Nachrichten von einer Bresser 5in1 Wetterstation empfangen. Laut
https://forum.fhem.de/index.php/topic,106594.msg1005067.html#msg1005067
ist dazu folgende CC1101-Registerbelegung notwendig:
get sduino raw CW0001,0246,0306,042D,05D4,06FF,07C0,0802,0D21,0E65,0FE8,1088,114C,1202,1322,14F8,1551,1700,1818,1916,1B43,1C68,1D91,2211,23E9,242A,2500,2611,3D07,3E04,4042,4172,4265,4373,4473,4535,4631,4700
Stimmt das noch? Laut Wiki https://wiki.fhem.de/wiki/SIGNALduino#Offizielles_Modul_.28Sidey.29 gilt
W<AA><XX> Write eeprom (schreibt einen Wert ins EEPROM und ins CC1101 Register. Die EEPROM Adresse hat einen Offset von 2. z.B W041D schreibt 1D ins Register 2 des CC1101).
Diesen Offset von 2 kann ich bei deiner Registerbelegung nicht erkennen. Wo liegt bei mir die Verwirrung? Ich würde gerne meine CC1101-Init-Prozedur entsprechend anpassen.
Harald
Hallo Harald,
hier stehen die aktuellen CC1101-Registerbelegungen
https://github.com/Ralf9/RFFHEM/blob/dev/FHEM/lib/signalduino_protocols.pm
Den offset von 2 gibts nur bei W<AA><XX> Write eeprom
Bei "get raw CW..", und "set cc1101_reg ..." sind direkt die Registeradressen ohne Offset.
Gruß Ralf
Danke für die schnelle Antwort!
Ich hoffe, dass ich hier von den unzähligen Signalduino-Threads richtig bin.
Ich habe eine alte Alarmanlage mit diversen Sensoren spaßeshalber reaktiviert und konnte mit einem Signalduino die Nachrichten empfangen:
ZitatInternals:
Clients :CUL_EM:CUL_FHTTK:CUL_TCM97001:CUL_TX:CUL_WS:Dooya:FHT:FLAMINGO:FS10:FS20: :Fernotron:Hideki:IT:KOPP_FC:LaCrosse:OREGON:PCA301:RFXX10REC:Revolt:SD_AS:SD_Rojaflex: :SD_BELL:SD_GT:SD_Keeloq:SD_RSL:SD_UT:SD_WS07:SD_WS09:SD_WS:SD_WS_Maverick:SOMFY: :Siro:SIGNALduino_un:
DEF /dev/serial/by-id/usb-SHK_NANO_CUL_433-if00-port0@57600
DMSG i555555
DevState initialized
DeviceName /dev/serial/by-id/usb-SHK_NANO_CUL_433-if00-port0@57600
FD 35
FUUID 61c4b358-f33f-30f6-e7ab-ab37818478dc90ef
LASTDMSG i555555
LASTDMSGID 3
MSGCNT 103
NAME sigduino
NR 682
PARTIAL
RAWMSG MS;P0=276;P1=-365;P3=-993;P4=902;P5=-7389;D=05034103410341034103410341034103410341034103410341;CP=0;SP=5;R=28;O;m2;
RSSI -60
STATE opened
TIME 1650796790.97093
TYPE SIGNALduino
cc1101_available 1
sendworking 0
version V 3.4.0 SIGNALduino cc1101 (chip CC1101) - compiled at Jul 16 2020 20:52:15
versionProtocols 1.42
versionmodul 3.5.3
DoubleMsgIDs:
MatchList:
10:SD_WS07 ^P7#[A-Fa-f0-9]{6}[AFaf][A-Fa-f0-9]{2,3}
11:SD_WS09 ^P9#F[A-Fa-f0-9]+
12:SD_WS ^W\d+x{0,1}#.*
13:RFXX10REC ^(20|29)[A-Fa-f0-9]+
14:Dooya ^P16#[A-Fa-f0-9]+
15:SOMFY ^Ys[0-9A-F]+
16:SD_WS_Maverick ^P47#[A-Fa-f0-9]+
17:SD_UT ^P(?:14|20|24|26|29|30|34|46|56|68|69|76|78|81|83|86|90|91|91.1|92|93|95|97|99|104|105|114)#.*
18:FLAMINGO ^P13\.?1?#[A-Fa-f0-9]+
19:CUL_WS ^K[A-Fa-f0-9]{5,}
1:IT ^i......
20:Revolt ^r[A-Fa-f0-9]{22}
21:FS10 ^P61#[A-F0-9]+
22:Siro ^P72#[A-Fa-f0-9]+
23:FHT ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
24:FS20 ^81..(04|0c)..0101a001
25:CUL_EM ^E0.................
26:Fernotron ^P82#.*
27:SD_BELL ^P(?:15|32|41|42|57|79|96|98|112)#.*
28:SD_Keeloq ^P(?:87|88)#.*
29:SD_GT ^P49#[A-Fa-f0-9]+
2:CUL_TCM97001 ^s[A-Fa-f0-9]+
30:LaCrosse ^(\S+\s+9 |OK\sWS\s)
31:KOPP_FC ^kr\w{18,}
32:PCA301 ^\S+\s+24
33:SD_Rojaflex ^P109#[A-Fa-f0-9]+
3:SD_RSL ^P1#[A-Fa-f0-9]{8}
4:OREGON ^(3[8-9A-F]|[4-6][0-9A-F]|7[0-8]).*
5:CUL_TX ^TX..........
6:SD_AS ^P2#[A-Fa-f0-9]{7,8}
7:Hideki ^P12#75[A-F0-9]+
9:CUL_FHTTK ^T[A-F0-9]{8}
X:SIGNALduino_un ^\d+#.*
QUEUE:
READINGS:
2022-04-24 12:23:36 cc1101_config Freq: 433.920 MHz, Bandwidth: 325 kHz, rAmpl: 42 dB, sens: 4 dB, DataRate: 5.60 kBaud
2022-04-24 12:23:36 cc1101_config_ext Modulation: ASK/OOK
2022-04-24 12:23:39 cc1101_patable C3E = 00 84 00 00 00 00 00 00 => 5_dBm
2022-04-09 08:52:15 ping OK
2022-04-24 12:23:35 state opened
additionalSets:
keepalive:
ok 1
retry 0
mcIdList:
mnIdList:
msIdList:
3
7
muIdList:
Attributes:
event-on-change-reading .*
hardware nanoCC1101
longids 1
room DEVICES->SIGDUINO
whitelist_IDs 3,7
Nun wird sie unter dem Protokoll 3 vom IT-Modul ausgewertet, allerdings können die Nachrichten nicht ausgewertet werden.
2022.04.24 12:34:30.314 3: sigduino IT: Code 0000 not supported by IT_F0000F00.
2022.04.24 12:34:30.591 3: sigduino: Unknown code i401000, help me!
2022.04.24 12:35:13.336 3: sigduino IT: Code 0000 not supported by IT_F01FFF10.
2022.04.24 12:35:13.349 3: sigduino: Unknown code i4D5C00, help me!
2022.04.24 12:35:15.666 3: sigduino IT: Code 0000 not supported by IT_F01FFF10.
2022.04.24 12:35:15.677 3: sigduino: Unknown code i4D5C00, help me!
2022.04.24 12:35:16.040 3: sigduino IT: Code FFFF not supported by IT_FFFFFFFF.
2022.04.24 12:35:16.051 3: sigduino: Unknown code i555555, help me!
2022.04.24 12:35:25.883 3: sigduino IT: Code 0000 not supported by IT_F01FFF10.
2022.04.24 12:35:25.896 3: sigduino: Unknown code i4D5C00, help me!
2022.04.24 12:35:27.934 3: sigduino IT: Code 0000 not supported by IT_F01FFF10.
2022.04.24 12:35:27.947 3: sigduino: Unknown code i4D5C00, help me!
2022.04.24 12:35:28.541 3: sigduino IT: Code FFFF not supported by IT_FFFFFFFF.
2022.04.24 12:35:28.554 3: sigduino: Unknown code i555555, help me!
2022.04.24 12:35:34.352 3: sigduino IT: Code 0000 not supported by IT_F01FFF10.
2022.04.24 12:35:34.357 3: sigduino: Unknown code i4D5C00, help me!
2022.04.24 12:39:48.437 3: sigduino IT: Code 0000 not supported by IT_F01FFF10.
2022.04.24 12:39:48.451 3: sigduino: Unknown code i4D5C00, help me!
2022.04.24 12:39:50.490 3: sigduino IT: Code 0000 not supported by IT_F01FFF10.
2022.04.24 12:39:50.496 3: sigduino: Unknown code i4D5C00, help me!
2022.04.24 12:39:50.971 3: sigduino IT: Code FFFF not supported by IT_FFFFFFFF.
2022.04.24 12:39:50.985 3: sigduino: Unknown code i555555, help me!
Per Jumper kann ich diverses Kodierungen an den Sensoren einstellen.
Wie gehe ich jetzt am besten vor, damit die Fehlermeldung unterdrückt werden können?
Das Protokoll muss ich wohl freigeschaltet lassen, sonst kann ich "Unknown code ..." nicht auswerten.
Die Entwicklung eines neuen Modul ist mir zu aufwändig, zumal ich dann diverse Codes entschlüsseln müsste und für die einfache Auswertung von ein paar Kontaktsensoren das ein nicht unerheblicher Aufwand wäre.
Hier gehts nur um FSK, für Slowrf gibts kein SIGNALDuino Sammelthema mehr.
Ich hab dafür bei InterTechno ein neues Thema aufgemacht
https://forum.fhem.de/index.php/topic,127415.0.html
Ich habe ein Honeywell DW915 funk gong. Ich habe mir dafür einen Signalduino basierend auf dem arduino mini und cc1101 gebaut und diesen in FHEM registriert.
Meine Ziele sind einmal das Signal zu detektieren, dass der Funkgong aussendet, wenn jemand den angeschlossenen verdrahteten Knopf drückt, und einmal mit dem Signalduino ein Signal abzusetzen, was eine Fernbedienung immitiert und diesen mit dem Funkgong zu pairen um diesen via FHEM auszulösen. Das Datenpaket hierfür ist auf der Seite https://github.com/klohner/honeywell-wireless-doorbell dokumentiert.
Ich habe auch einen RTL-SDR mit dem ich die Kommunikation überwachen kann (Über SDRSharp oder rtl_433). Mit RTL_433 habe ich auch verifiziert, dass der Gong das entsprechende Honeywell Activelink basierende Paket absetzt.
Ich habe mir Bank 1 mit dem entsprechenden Modus belegt, der für Honeywell Activelink korrekt sein sollte.
Das habe ich so gemacht
Bank 1 selektieren
raw b1
Den folgenden Befehl habe ich in den sourcen für das FHEM modul gefunden, welches scheinbar schon die korrekten register für den CC1101 setzt:
rfmode HoneywActivL_SlowRf_FSK
und dann noch ein
raw b1W
damit die Bank der default ist.
Die Werte werden mir nun entsprechend angezeigt
cc1101_frequency 868.350
ccconf b=1 freq:868.350MHz bWidth:203KHz rAmpl:33dB sens:8dB (DataRate:6248.47Baud) [boffs=0100]
ccconfFSK ccmode=0 sync=D391 Modulation:2-FSK (SYNC_MODE:No preamble/sync) DEVIATN:50.781kHz
version V 3.3.5-dev210522 SIGNALduino (b1) - compiled at May 29 2022 23:18:12
versionmodul v3.4.7-ralf_24.06.
Ich stehe aber noch ein wenig auf dem Schlauch. Ich dachte, dass ich jetzt via
raw SN;R=13;N=1;D=dbf860200009;
ein entsprechendes Datenpaket absetzen kann. Tatsächlich passiert da auch etwas, aber das ist dann kein 2FSK moduliertes Signal (es hat nur eine Spitze).
Ich hoffe hier kann mir jemand weiterhelfen.
Du kannst es mal damit versuchen:
set sduino sendmsg P200#0xdbf860200009#R50
@killah78 hat auch Honeywell dw915s
siehe hier
https://forum.fhem.de/index.php/topic,106278.msg1147491.html#msg1147491
Gruß Ralf
Danke erstmal für den Tipp.
Das ganze richtig auch zusammenlöten und schon klappt es (besser). :D
Ich sehe jetzt die wenn der Türgong ausgelöst wird in DMSG mit entsprechendem Datenpaket, welches ich auch genauso in RTL_433 sehe.
Das mit sendMsg erzeugte Signal sieht in SDRSharp zumindest mal richtig moduliert aus. Jedoch erkennt weder RTL_433 noch der eigentliche Türgong das ausgesendete sendMsg Signal als Honeywell Activlink. Auf verschiedenen Distanzen getestet ohne Besserung. Aktuell habe ich eine 86mm Drahtantenne. Ich werde die Tage nochmal mit einer "richtigen" 868Mhz antenne testen, sobald diese in der Post liegt.
P200#0x942160200009#R50
Das Profil müsste ja eigentlich passen. Trotzdem habe ich hier mal die aktuellen Register:
ccreg 00: 0D 2E 2D 07 D3 91 3D 04 32 00 00 06 00 21 65 E8
ccreg 10: 87 F8 00 23 B9 50 07 00 18 14 6C 43 00 91 87 6B
ccreg 20: F8 56 11 EC 2D 13 11 41 00 59 7F 2E 88 31 0B
Edit: Was ist denn der sinnvollste weg aus der DMSG internal nun ein event zu generieren?
Habe heute nochmal ein bischen getestet und das generierte Signal vom SDuino mit dem originalen Honeywell verglichen. RTL_433 erkennt das vom SDuino erzeugte Signal nicht.
Ich habe die Signale dann mal mit dem Universal Radio Hacker angesehen. Was mir auffällt ist, dass aus irgendeinem Grund die Bitsendelänge bei dem vom SDuino ausgegebenen Signal etwa bei 130us liegt statt der 160us aus der ActivLink Spezifikation. Siehe Screenshot im Anhang. Von oben nach unten ist das der originale Honeywell sender, dann einmal gesendet mit
set SDuino868 sendMsg P200#0xdbf860200009#R50
und dann
set SDuino868 raw SR;;R=50;;P0=-381;;P1=100;;P2=260;;P3=-220;;P4=419;;P5=-544;;D=52310102310231023101023101010102310232310101010101010231010101010101010101010101010101010101010234;;
Wenn Du eine empfangene MU-Nachricht mit "set SDuino868 raw SR;;R=50;;P0=.." wieder sendest, funktioniert demnach auch nicht?
Hier mal ein Verbose log von der Aktivität, wenn ich den originalen Honeywell Gong klingeln lasse. Vielleicht kannst du mir helfen, die entsprechende Raw message daraus zu generieren. Ganz blicke ich noch nicht durch.
2022.11.12 08:41:06.241 4 : SDuino868/msg READredu: MU;P0=-171;P1=301;P2=130;P3=-336;P5=448;P6=-524;CP=2;R=243;D=010232323232323232323232323232323232310232310561010231010;p;
2022.11.12 08:41:06.242 4 : SDuino868: Fingerprint for MU Protocol id 200 -> Honeywell ActivLink matches, trying to demodulate
2022.11.12 08:41:06.260 4 : SDuino868/msg READredu: MU;P0=-159;P1=153;P2=-320;P4=312;P6=102;P7=472;CP=1;R=241;D=0121212401212121212126212121210621212121212401212407;p;
2022.11.12 08:41:06.279 4 : SDuino868/msg READredu: MU;P0=-456;P1=319;P2=-163;P3=165;P4=-345;CP=3;R=246;D=01212341212341212121212121234343434121234343434343434123434343434343434;e;
2022.11.12 08:41:06.281 4 : SDuino868: Fingerprint for MU Protocol id 200 -> Honeywell ActivLink matches, trying to demodulate
2022.11.12 08:41:06.313 4 : SDuino868/msg READredu: MU;P0=157;P1=-320;P2=323;P3=-155;P5=648;P7=118;CP=0;R=248;D=012323232323232301010101232301010101010101510101010101010101010101010101717123010123;p;
2022.11.12 08:41:06.350 4 : SDuino868/msg READredu: MU;P0=-323;P1=118;P3=-164;P4=356;P7=-238;CP=1;R=254;D=01010101013431010101010101010101017101017;e;
2022.11.12 08:41:06.403 4 : SDuino868/msg READredu: MU;P0=152;P2=-328;P3=292;P4=-173;P7=-224;CP=0;R=239;D=0234023402020237020202020202020202020234040;e;
2022.11.12 08:41:06.661 4 : SDuino868/msg READredu: MU;P0=-175;P1=304;P2=163;P3=-332;P4=436;P5=-528;P7=124;CP=2;R=249;D=0102023104510102310102310101010101010732323231010232323232323231;p;i;
2022.11.12 08:41:06.663 4 : SDuino868: Fingerprint for MU Protocol id 200 -> Honeywell ActivLink matches, trying to demodulate
2022.11.12 08:41:06.696 4 : SDuino868/msg READredu: MU;P0=162;P2=-158;P3=308;P5=-315;CP=0;R=247;D=32320505050532320505050505050532050535050505050505050505050505050532050532;p;
2022.11.12 08:41:06.711 4 : SDuino868/msg READredu: MU;P0=484;P1=-360;P2=311;P3=-177;P4=155;P5=228;CP=4;R=249;D=0123234123234123232323532323414141412323414341414141412341414141;e;
2022.11.12 08:41:06.734 4 : SDuino868/msg READredu: MU;P0=332;P1=-346;P2=-153;P3=130;P4=-240;P5=168;CP=3;R=246;D=01020231020202020202343131313102023131313131313102313131313154;e;
2022.11.12 08:41:06.763 4 : SDuino868/msg READredu: MU;P0=102;P1=-332;P2=154;P3=320;P4=-167;CP=2;R=249;D=0121343421212121212121342121212121212121012121212121212124;e;
2022.11.12 08:41:06.828 4 : SDuino868/msg READredu: MU;P0=-173;P1=325;P3=147;P4=-332;P5=476;P6=-480;CP=3;R=245;D=10343410561010341010341010101010101034343434101034343434343434103434343434343434343434343434343434103434105610103410103410101010101010343434341030343434343434341034343434343434343434343434343434;p;i;
2022.11.12 08:41:06.830 4 : SDuino868: Fingerprint for MU Protocol id 200 -> Honeywell ActivLink matches, trying to demodulate
2022.11.12 08:41:06.830 4 : SDuino868: decoded matched MU Protocol id 200 dmsg u200#DBF860200009 length 48 RSSI = -79.5
2022.11.12 08:41:06.831 4 : SDuino868: equalDMS u200#DBF860200009 (1)
2022-11-12 08:41:06.837 SIGNALduino SDuino868 DMSG u200#DBF860200009
2022.11.12 08:41:06.837 4 : SDuino868 Dispatch: u200#DBF860200009, -79.5 dB, dispatch
2022.11.12 08:41:06.838 4 : SIGNALduino_unknown incomming msg: u200#DBF860200009
2022.11.12 08:41:06.839 4 : SIGNALduino_unknown rawData: DBF860200009
2022.11.12 08:41:06.839 4 : SIGNALduino_unknown Protocol: 200
2022.11.12 08:41:06.839 4 : SIGNALduino_unknown converted to bits: 110110111111100001100000001000000000000000001001
2022.11.12 08:41:06.839 4 : SIGNALduino_unknown SDuino868 Protocol:200 | To help decode or debug, please add u200! (attr SDuino868 development u200)
2022.11.12 08:41:06.839 4 : Unknown, please report
2022-11-12 08:41:06.847 SIGNALduino SDuino868 UNKNOWNCODE u200#DBF860200009
2022.11.12 08:41:06.847 3 : SDuino868: Unknown code u200#DBF860200009, help me!
2022.11.12 08:41:06.849 4 : SDuino868/msg READredu: MU;P0=313;P1=-344;P2=-165;P3=150;P5=480;P6=-480;CP=3;R=253;D=010231310256020231020231020202013202023131313102023131313131313102313131313131313131313131;p;i;
2022.11.12 08:41:06.850 4 : SDuino868: Fingerprint for MU Protocol id 200 -> Honeywell ActivLink matches, trying to demodulate
2022.11.12 08:41:06.874 4 : SDuino868/msg READredu: MU;P0=141;P1=-324;P2=307;P3=-178;P5=480;P6=-464;P7=212;CP=0;R=247;D=010101230101010101010101010101010101010101230101235623230123230123232323232323017;p;i;
2022.11.12 08:41:06.876 4 : SDuino868: Fingerprint for MU Protocol id 200 -> Honeywell ActivLink matches, trying to demodulate
2022.11.12 08:41:06.890 4 : SDuino868/msg READredu: MU;P0=-332;P1=181;P2=319;P3=-167;P4=-222;P5=138;P6=100;P7=460;CP=1;R=6;D=01010232310101010101010245050501010101010101010101010106010231410237;p;
2022.11.12 08:41:06.900 4 : SDuino868/msg READredu: MU;P0=-496;P1=321;P2=-174;P3=155;P4=-330;P5=-256;CP=3;R=247;D=01212341212341212121212121234343435121234343434343434;e;
2022.11.12 08:41:06.902 4 : SDuino868: Fingerprint for MU Protocol id 200 -> Honeywell ActivLink matches, trying to demodulate
2022.11.12 08:41:06.927 4 : SDuino868/msg READredu: MU;P0=150;P1=-355;P2=318;P3=-152;P4=460;P5=-476;CP=0;R=2;D=010123452323012323012323232323232301010101230301010101010101230101;p;i;
2022.11.12 08:41:06.928 4 : SDuino868: Fingerprint for MU Protocol id 200 -> Honeywell ActivLink matches, trying to demodulate
2022.11.12 08:41:06.965 4 : SDuino868/msg READredu: MU;P0=636;P1=-317;P2=158;P3=-116;P4=314;P5=-169;CP=2;R=245;D=014545214545454545454521212121454521212123;p;i;
2022.11.12 08:41:06.990 4 : SDuino868/msg READredu: MU;P0=-317;P1=159;P2=206;P3=300;P4=-180;P5=484;P6=-464;CP=1;R=242;D=010101010101010101020341010345634341034241034143434343434;e;
2022.11.12 08:41:06.991 4 : SDuino868: Fingerprint for MU Protocol id 200 -> Honeywell ActivLink matches, trying to demodulate
2022.11.12 08:41:07.004 4 : SDuino868/msg READredu: MU;P0=-318;P1=146;P3=204;P4=315;P5=-164;P7=96;CP=1;R=253;D=010301045451010101010101045101010101010101070101010101010101;p;
2022.11.12 08:41:07.030 4 : SDuino868/msg READredu: MU;P0=-502;P1=158;P2=-151;P4=-328;P5=120;P6=314;P7=452;CP=1;R=249;D=01214546270626214626214626262626262621414141462621414141414141462141414541414141414145412;e;i;
2022.11.12 08:41:07.031 4 : SDuino868: Fingerprint for MU Protocol id 200 -> Honeywell ActivLink matches, trying to demodulate
2022.11.12 08:41:07.042 4 : SDuino868/msg READredu: MU;P0=-178;P1=183;P2=-328;P3=308;P6=448;P7=-512;CP=1;R=245;D=01212121212301212106730301230301230301030303030;p;
2022.11.12 08:41:07.043 4 : SDuino868: Fingerprint for MU Protocol id 200 -> Honeywell ActivLink matches, trying to demodulate
2022.11.12 08:41:07.066 4 : SDuino868/msg READredu: MU;P0=149;P1=-332;P2=312;P3=-169;P6=500;P7=-464;CP=0;R=247;D=01010101232301010101010101230101010101010101010101010101010101230101236723230123230123232323;p;i;
2022.11.12 08:41:07.067 4 : SDuino868: Fingerprint for MU Protocol id 200 -> Honeywell ActivLink matches, trying to demodulate
2022.11.12 08:41:07.082 4 : SDuino868/msg READredu: MU;P0=150;P1=-178;P2=311;P3=-322;P5=480;P6=-484;CP=0;R=247;D=012121030303032121030303030303032103030303030303030303030303030303032103032156212;e;
2022.11.12 08:41:07.110 4 : SDuino868/msg READredu: MU;P0=-152;P1=159;P2=-311;P3=328;P6=496;P7=-500;CP=1;R=254;D=012121212121212121212301212306730301230101230103030303032;e;
2022.11.12 08:41:07.111 4 : SDuino868: Fingerprint for MU Protocol id 200 -> Honeywell ActivLink matches, trying to demodulate
2022.11.12 08:41:07.135 4 : SDuino868/msg READredu: MU;P0=-328;P1=162;P2=110;P3=314;P4=-169;CP=1;R=244;D=01020103434101010101020103410201010101010102010101010101010103410;e;
2022.11.12 08:41:07.138 4 : SDuino868/msg READredu: MU;P0=-170;P1=104;P3=-484;P4=317;P5=172;P6=-328;P7=228;CP=5;R=241;D=3404056704056404040404040405656565640405656561656;p;
2022.11.12 08:41:07.140 4 : SDuino868: Fingerprint for MU Protocol id 200 -> Honeywell ActivLink matches, trying to demodulate
2022.11.12 08:41:07.172 4 : SDuino868/msg READredu: MU;P0=-147;P1=161;P2=-328;P3=311;P4=472;P5=-500;P7=-220;CP=1;R=244;D=012121212121230121230453030123030123030303030303012121212303712121212121212301212;p;i;
2022.11.12 08:41:07.174 4 : SDuino868: Fingerprint for MU Protocol id 200 -> Honeywell ActivLink matches, trying to demodulate
2022.11.12 08:41:07.179 4 : SDuino868/msg READredu: MU;P0=160;P1=-315;P3=322;P4=-160;P6=488;P7=-500;CP=0;R=247;D=0101010101010101010101010101013401013467;p;
2022.11.12 08:41:07.196 4 : SDuino868/msg READredu: MU;P0=308;P1=-172;P3=166;P4=-317;P5=-100;P6=400;CP=3;R=245;D=0101340101340101010561010134343434010134343434343434013434343434343434343434;p;i;
2022.11.12 08:41:07.208 4 : SDuino868/msg READredu: MU;P0=174;P1=-337;P2=-173;P3=114;P4=314;P5=480;P6=-496;P7=-120;CP=0;R=240;D=0101010231014201014256424201424201424242424242470131;p;
2022.11.12 08:41:07.209 4 : SDuino868: Fingerprint for MU Protocol id 200 -> Honeywell ActivLink matches, trying to demodulate
2022.11.12 08:41:07.228 4 : SDuino868/msg READredu: MU;P0=-323;P1=145;P2=310;P3=-168;P5=476;P6=-500;P7=-104;CP=1;R=254;D=01010101010101010101010102310102356232310272310232323;p;i;
2022.11.12 08:41:07.229 4 : SDuino868: Fingerprint for MU Protocol id 200 -> Honeywell ActivLink matches, trying to demodulate
2022.11.12 08:41:07.249 4 : SDuino868/msg READredu: MU;P0=468;P1=-326;P2=316;P3=-153;P5=159;P7=120;CP=5;R=251;D=123232351515151232351515151515151235151515151515151515151515151517171235151230;p;
2022.11.12 08:41:07.276 4 : SDuino868/msg READredu: MU;P0=420;P1=302;P2=-170;P3=162;P4=-324;P6=122;CP=3;R=250;D=12123412123412121212121212343434341212343434343434341264343434343434343434321464343434341234340;e;i;
2022.11.12 08:41:07.289 4 : SDuino868/msg READredu: MU;P0=-135;P1=170;P2=309;P3=-168;P6=236;P7=-326;CP=1;R=244;D=602317232023232323231717171723231717171717171723171;p;
2022.11.12 08:41:07.357 4 : SDuino868/msg READredu: MU;P0=100;P1=323;P2=-167;P4=163;P5=-350;P6=220;P7=-244;CP=4;R=248;D=12124512124512121212121212456745451212454545454545051;p;i;
2022.11.12 08:41:07.367 4 : SDuino868/msg READredu: MU;P0=-780;P1=156;P2=-313;P4=320;P5=-162;P6=492;P7=-472;CP=1;R=241;D=1212121212121212121212121212121212451212456710;p;
Die Werte sind ein wenig anders als bei @killah78, die clock ist ungefähr 160, ich muss dazu die Protokolldefintion anpassen
Bitte ersetze in der lib/signalduino_protocols.pm bei der Protokoll ID 200 die folgenden Einträge. Sie werden erst nach einem fhem neustart aktiv
one => [2,-1],
zero => [1,-2],
start => [-3],
end => [3],
clockabs => 160,
Ein "set SDuino868 sendMsg P200#0xdbf860200009#R50" ergibt dann:
SR;R=50;P0=-480;P1=320;P2=-160;P3=160;P4=-320;P5=480;D=01212341212341212121212121234343434121234343434343434123434343434343434343434343434343434123434125;
In Deinem log war nur eine brauchbare Nachricht dabei, die anderen sind zu kurz:
MU;P0=-173;P1=325;P3=147;P4=-332;P5=476;P6=-480;CP=3;R=245;D=1034341056101034101034101010101010103434343410103434343434343410343434343434343434343434343434343410343410561010341010341010101010101034343434101034343434343434103434343434343434343434343434343434103434105;
Ich habe die Änderungen durchgeführt. Im Universal Radio Hacker sieht das Signal jetzt gut aus von den Laufzeiten. Ich konnte jetzt auch den Honeywell Funkgong mit einem vom Signalduino erzeugten Signal pairen. Super :D
Als Notiz für diejenigen, die einen virtuellen Sender haben wollen, reicht es hier die Kennung zu ändern. Vereinfacht ändert man dazu einfach die ersten 2 Bytes (die ausführlichere Spezifikation findet man unter https://github.com/klohner/honeywell-wireless-doorbell). Mit manchen von mir getesteten Kennungen wollte sich die die Türklingel allerdings nicht pairen. Das Muster ist mir nicht ganz klar, aber man probiert halt rum bis die Klingel zufrieden ist.
P200#0xXXXX60200009#R50
^^^^
Kennung
Jetzt fehlt mir nur noch der umgekehrte Weg. Wie bekomme ich ein Event in FHEM, wenn der Signalduino vom Funkgong ein eingehendes Klingelsignal erhält? Im Log ist es ja wunderbar aufgeführt, aber wie komme ich da nun als Event ran?
Ich hab für Honeywell ActivLink ein neues Thema angelegt
https://forum.fhem.de/index.php/topic,130271.0.html
Mein LaCrosse GW gibt langsam den Geist auf, deshalb möchte ich einen nanoCUL 868 mit SIGNALDuino gerne als alternatives GW nutzen.
Soweit hat das auch alles ganz gut geklappt: Umgeflasht, Attribute eingestellt, Protokolle ausgewählt usw.
Das Device sieht so aus:
Internals:
CFGFN
Clients :CUL_EM:CUL_FHTTK:CUL_TCM97001:CUL_TX:CUL_WS:Dooya:FHT:FLAMINGO:FS10:FS20: :Fernotron:Hideki:IT:KOPP_FC:LaCrosse:OREGON:PCA301:RFXX10REC:Revolt:SD_AS:SD_Rojaflex: :SD_BELL:SD_GT:SD_Keeloq:SD_RSL:SD_UT:SD_WS07:SD_WS09:SD_WS:SD_WS_Maverick:SOMFY: :Siro:SIGNALduino_un:
DEF /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0@57600
DMSG OK 9 41 1 2 98 106
DevState initialized
DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0@57600
FD 40
FLASH_RESULT ERROR: avrdude exited with error
FUUID 63e8dc74-f33f-b8ff-f9ae-f76a1e31c6ae2c4f
LASTDMSG OK 9 41 1 2 98 106
LASTDMSGID 100
MSGCNT 3594
NAME sduino868
NR 842
PARTIAL
RAWMSG MN;D=9A40106A2E;R=35;
RSSI -56.5
STATE opened
TIME 1676230403.87769
TYPE SIGNALduino
cc1101_available 1
eventCount 182
sendworking 0
version V 3.5.0-dev+20210808 SIGNALduino cc1101 (chip CC1101) - compiled at Aug 7 2021 22:44:01
versionProtocols 1.49
versionmodul 3.5.5+20230128
DoubleMsgIDs:
MatchList:
10:SD_WS07 ^P7#[A-Fa-f0-9]{6}[AFaf][A-Fa-f0-9]{2,3}
11:SD_WS09 ^P9#F[A-Fa-f0-9]+
12:SD_WS ^W\d+x{0,1}#.*
13:RFXX10REC ^(20|29)[A-Fa-f0-9]+
14:Dooya ^P16#[A-Fa-f0-9]+
15:SOMFY ^Ys[0-9A-F]+
16:SD_WS_Maverick ^P47#[A-Fa-f0-9]+
17:SD_UT ^P(?:14|20|24|26|29|30|34|46|56|68|69|76|78|81|83|86|90|91|91.1|92|93|95|97|99|104|105|114|118|121)#.*
18:FLAMINGO ^P13\.?1?#[A-Fa-f0-9]+
19:CUL_WS ^K[A-Fa-f0-9]{5,}
1:IT ^i......
20:Revolt ^r[A-Fa-f0-9]{22}
21:FS10 ^P61#[A-F0-9]+
22:Siro ^P72#[A-Fa-f0-9]+
23:FHT ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
24:FS20 ^81..(04|0c)..0101a001
25:CUL_EM ^E0.................
26:Fernotron ^P82#.*
27:SD_BELL ^P(?:15|32|41|42|57|79|96|98|112)#.*
28:SD_Keeloq ^P(?:87|88)#.*
29:SD_GT ^P49#[A-Fa-f0-9]+
2:CUL_TCM97001 ^s[A-Fa-f0-9]+
30:LaCrosse ^(\S+\s+9 |OK\sWS\s)
31:KOPP_FC ^kr\w{18,}
32:PCA301 ^\S+\s+24
33:SD_Rojaflex ^P109#[A-Fa-f0-9]+
3:SD_RSL ^P1#[A-Fa-f0-9]{8}
4:OREGON ^(3[8-9A-F]|[4-6][0-9A-F]|7[0-8]).*
5:CUL_TX ^TX..........
6:SD_AS ^P2#[A-Fa-f0-9]{7,8}
7:Hideki ^P12#75[A-F0-9]+
9:CUL_FHTTK ^T[A-F0-9]{8}
X:SIGNALduino_un ^[u]\d+#.*
QUEUE:
P
READINGS:
2023-02-12 15:02:23 cc1101_config Freq: 868.300 MHz, Bandwidth: 203 kHz, rAmpl: 33 dB, sens: 8 dB, DataRate: 17.26 kBaud
2023-02-12 15:02:23 cc1101_config_ext Modulation: 2-FSK, Syncmod: 16/16 sync word bits detected, Deviation: 88.87 kHz
2023-02-12 15:02:24 cc1101_patable C3E = 00 67 00 00 00 00 00 00 => -5_dBm
2023-02-12 20:32:27 ping OK
2023-02-12 15:02:22 state opened
additionalSets:
flash 3.5.0,3.5.0-dev+20210808,3.5.0-dev+20210623,3.4.0,3.4.0-dev+20200711,3.4.0-dev+20200216,3.3.1
helper:
avrdudecmd avrdude -c arduino -b 57600 -P /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0 -p atmega328p -vv -U flash:w:FHEM/firmware/SIGNALDuino_nanocc1101_3.5.0-dev+20210808.hex 2>./log/SIGNALduino-Flash.log || avrdude -c arduino -b 115200 -P /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0 -p atmega328p -vv -U flash:w:FHEM/firmware/SIGNALDuino_nanocc1101_3.5.0-dev+20210808.hex 2>./log/SIGNALduino-Flash.log
avrdudelogs flashing Arduino sduino868
hex file: FHEM/firmware/SIGNALDuino_nanocc1101_3.5.0-dev+20210808.hex
port: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0
command: avrdude -c arduino -b 57600 -P /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0 -p atmega328p -vv -U flash:w:FHEM/firmware/SIGNALDuino_nanocc1101_3.5.0-dev+20210808.hex 2>[LOGFILE] || avrdude -c arduino -b 115200 -P /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0 -p atmega328p -vv -U flash:w:FHEM/firmware/SIGNALDuino_nanocc1101_3.5.0-dev+20210808.hex 2>[LOGFILE]
sduino868 closed
--- AVRDUDE ---------------------------------------------------------------------------------
avrdude: Version 6.3-20171130
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2014 Joerg Wunsch
System wide configuration file is "/etc/avrdude.conf"
User configuration file is "/opt/fhem/.avrduderc"
User configuration file does not exist or is not a regular file, skipping
Using Port : /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0
Using Programmer : arduino
Overriding Baud Rate : 115200
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x00
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x18
avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0x80
avrdude: stk500_getsync() attempt 4 of 10: not in sync: resp=0xe6
avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0x98
avrdude: stk500_getsync() attempt 6 of 10: not in sync: resp=0xf8
avrdude: stk500_getsync() attempt 7 of 10: not in sync: resp=0x98
avrdude: stk500_getsync() attempt 8 of 10: not in sync: resp=0x9e
avrdude: stk500_getsync() attempt 9 of 10: not in sync: resp=0x18
avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0x06
avrdude done. Thank you.
--- AVRDUDE ---------------------------------------------------------------------------------
sduino868 reopen started
keepalive:
ok 0
retry 1
mcIdList:
mnIdList:
100
103
107.1
msIdList:
74.1
muIdList:
74
ucCmd:
cmd ping
timenow 1676230407.77895
Attributes:
addvaltrigger 1
cc1101_frequency 868
devStateIcon opened:usb@green closed:usb@yellow disconnected:usb@red
group CUL
hardware nanoCC1101
longids 1
rfmode Lacrosse_mode1
sortby 51
updateChannelFW testing
whitelist_IDs 74,74.1,100,103,107.1
Im Liste sehe ich einen Flash-Error. Aus meiner Sicht hat der Flash aber funktioniert... :-\
Ich habe 2 Temperaturfühler auf Basis LaCrosse im Einsatz:
Beide sollten laut Doku/Hilfe mit Lacrosse_mode1 funktionieren. Tatsächlich bekomme ich aber keine Daten vom 30.3144.IT empfangen, der TX29.IT funktioniert dagegen einwandfrei.
Der 30.3144.IT funktioniert an meinem alten LaCrosse GW problemlos. Auch ein kurzer Test mit der nanoCUL FW mit aktivierten LaCrosse-2-HMS Emulation hat soweit funktioniert. Nur mit dem SIGNALduino mag er nicht.
Habt ihr noch Tipps, worauf ich achten könnte oder was anders einzustellen ist?
Kommt mit sduino verbose 4 nichts vom 30.3144.IT?
Die RAWMSG sehen ungefähr so aus: MN;D=9A40106A2E...
Du kannst mal die Frequenz ein klein wenig in 0.05 MHz schritten ändern
Gruß Ralf
Guter Tipp, danke!
verbose=4 liefert mir folgendes:
2023.02.12 21:13:47.630 4: sduino868: Parse_MN, Found 2-FSK Protocol id 100 -> Lacrosse mode 1 with match (?^:^9)
2023.02.12 21:13:47.649 4: sduino868: Parse_MN, Found 2-FSK Protocol id 103 -> Lacrosse mode 2 with match (?^:^9)
2023.02.12 21:13:47.649 4: sduino868: Dispatch, OK 9 41 1 2 97 106, Dropped due to short time or equal msg
2023.02.12 21:13:47.649 4: sduino868: Parse_MN, Error! id 107.1 msg=9A40096A83, message is to short
2023.02.12 21:13:56.262 4: sduino868: Read, msg: MN;D=9A40096A83;R=31;
2023.02.12 21:13:56.264 4: sduino868: Parse_MN, Found 2-FSK Protocol id 100 -> Lacrosse mode 1 with match (?^:^9)
2023.02.12 21:13:56.304 4: sduino868: Parse_MN, Found 2-FSK Protocol id 103 -> Lacrosse mode 2 with match (?^:^9)
2023.02.12 21:13:56.305 4: sduino868: Dispatch, OK 9 41 1 2 97 106, Dropped due to short time or equal msg
2023.02.12 21:13:56.305 4: sduino868: Parse_MN, Error! id 107.1 msg=9A40096A83, message is to short
2023.02.12 21:14:04.910 4: sduino868: Read, msg: MN;D=9A40096A83;R=31;
2023.02.12 21:14:04.911 4: sduino868: Parse_MN, Found 2-FSK Protocol id 100 -> Lacrosse mode 1 with match (?^:^9)
2023.02.12 21:14:04.947 4: sduino868: Parse_MN, Found 2-FSK Protocol id 103 -> Lacrosse mode 2 with match (?^:^9)
2023.02.12 21:14:04.947 4: sduino868: Dispatch, OK 9 41 1 2 97 106, Dropped due to short time or equal msg
2023.02.12 21:14:04.948 4: sduino868: Parse_MN, Error! id 107.1 msg=9A40096A83, message is to short
2023.02.12 21:14:13.662 4: sduino868: Read, msg: MN;D=9A40096A83;R=32;
2023.02.12 21:14:13.663 4: sduino868: Parse_MN, Found 2-FSK Protocol id 100 -> Lacrosse mode 1 with match (?^:^9)
2023.02.12 21:14:13.679 4: sduino868: Parse_MN, Found 2-FSK Protocol id 103 -> Lacrosse mode 2 with match (?^:^9)
2023.02.12 21:14:13.680 4: sduino868: Dispatch, OK 9 41 1 2 97 106, Dropped due to short time or equal msg
2023.02.12 21:14:13.680 4: sduino868: Parse_MN, Error! id 107.1 msg=9A40096A83, message is to short
Ich spiele mal mit der Frequenz
Zwischen 868.250 und 868.350 kann ich den TX29-IT stabil empfangen, für den 30.3144.IT bekomme ich nur die Fehler wie oben angegeben.
Unter bzw. über den Schwellwerten verliere ich beide Sensoren.
VG, weini
Was ist der 30.3144.IT für ein Sensor, kann der auch Luftfeuchtigkeit?
Wenn ich dies "OK 9 41 1 2 97 106" per Dispatch zum LaCrosse Modul schicke, bekomme ich:
2023-02-12 23:24:08.953 LaCrosse LaCrosse_29 battery: ok
2023-02-12 23:24:08.953 LaCrosse LaCrosse_29 temperature: -39.1
Aha!
Das ist der TX29-IT. Der hat nur Temperatur und Batterie und ist als Helligkeitssensor umgebaut, weshalb er in der Nacht den recht tiefen Temperaturwert zeigt. Das ist also genau der Sensor, wo der Empfang gut klappt. Insofern ist die "Parse_MN, Error!" Meldung wohl nicht so ganz ernst zu nehmen.
Nun habe ich über Nacht auch ein paar wenige Lebenszeichen vom 30.3144.IT bekommen:
2023.02.13 05:58:46.496 4: sduino868: Read, msg: MN;D=96843050F0;R=19;
2023.02.13 05:58:46.497 4: sduino868: Parse_MN, Found 2-FSK Protocol id 100 -> Lacrosse mode 1 with match (?^:^9)
2023.02.13 05:58:46.520 4: sduino868: Parse_MN, Found 2-FSK Protocol id 103 -> Lacrosse mode 2 with match (?^:^9)
2023.02.13 05:58:46.520 4: sduino868: Dispatch, OK 9 26 1 4 6 80, Dropped due to short time or equal msg
2023.02.13 05:58:46.520 4: sduino868: Parse_MN, Error! id 107.1 msg=96843050F0, message is to short
So alle 2-3 Stunden kommt mal ein Funktelegramm durch.
Ich spiele jetzt nochmal mit der Frequenz rum. Gestern hatte ich immer nur kurz getestet und sofort weiter verändert, wenn ich die Meldungen für den TX29-IT bekommen hatte.
2023.02.13 05:58:46.520 4: sduino868: Parse_MN, Error! id 107.1 msg=96843050F0, message is to shortZitatInsofern ist die "Parse_MN, Error!" Meldung wohl nicht so ganz ernst zu nehmen.
Dies ist etwas unglücklich programmiert, dies ist keine Fehlermeldung sondern nur ein Hinweis, daß die ID 107.1 bei diesem rfmode nicht verarbeitet werden kann.
Da Du nur Lacrosse mode 1 Sensoren hast, ist es ausreichend wenn Du in der whitelist nur die ID 100 einträgst.
Dies geht auch in dem " Protocollist Overviev" Fenster.
Ok, habe das LaCrosse 2 Protokoll deaktiviert, damit ist die "Parse_MN, Error!" Meldung weg.
Leider wird es mit dem 30.3144.IT nicht besser: Abweichende Frequenzen bringen nichts, ab ehesten kommt noch mit 868.300 etwas durch.
Spannend finde ich dabei, dass die RSSI Werte im LaCrosse Device mit sduino868_RSSI=-74.5 eigentlich gut sind. Nur kommt eben so gut wie nichts an.
Auszug der Internals vom Temperatur Device:
lcg_LaCrosse_MSGCNT 76
lcg_LaCrosse_TIME 2023-02-13 09:10:28
previousH 72
previousT 4.9
sduino868_DMSG OK 9 36 1 4 25 72
sduino868_MSGCNT 10
sduino868_Protocol_ID 100
sduino868_RAWMSG MN;D=99044948A9;R=255;
sduino868_RSSI -74.5
sduino868_TIME 2023-02-13 14:23:38
Mit dem "echten" LaCrosse GW kommen die Meldungen dagegen schnell und zahlreich.
Im Forum habe ich auch keine Posts zu 30.3144.IT mit SIGNALDuino gefunden.
Habe schon überlegt, ob ich mir einen zweiten 30.3144.IT nachbestelle um zu testen, ob meiner ggf. eine Macke hat. Die zugehörige Wetterstation empfängt die Daten aber recht kontinuierlich. Bin etwas ratlos...
Werden vom 30.3144.IT fehlerhafte oder nur sehr wenige rawmsg empfangen.
Es sollte normalerweise ca alle 10sec was empfangen werden.
Welche rawmsg werden empfangen, wenn Du vom TX29-IT die Batterien raus nimmst?
Sehe ich die empfangenen RAWMSG im Log mit verbose 4?
Da kommt nur alle paar Stunden etwas durch.
Als ich auf dem 868er nanoCUL die culfw mit LaCrosse Empfang https://forum.fhem.de/index.php/topic,36565.msg702663.html#msg702663 (https://forum.fhem.de/index.php/topic,36565.msg702663.html#msg702663) drauf hatte, da habe ich die Telegramme im 10 Sekunden Takt empfangen. Auch über mein altes LaCrosse GW kommen die Daten in ungefähr dieser Frequenz rein.
Wenn ich aus dem TX29-IT die Batterie rausnehme, dann bleibt bei verbose 4 das im Log übrig:
2023.02.13 15:31:39.573 4: sduino868: KeepAlive, ok, retry = 0
2023.02.13 15:32:39.663 4: sduino868: KeepAlive, not ok, retry = 1 -> get ping
2023.02.13 15:32:39.711 4: sduino868: HandleWriteQueue, called
2023.02.13 15:32:39.711 4: sduino868: SendFromQueue, called
2023.02.13 15:32:39.729 4: sduino868: Read, msg: OK
2023.02.13 15:32:40.023 4: sduino868: HandleWriteQueue, called
2023.02.13 15:32:40.023 4: sduino868: HandleWriteQueue, nothing to send, stopping timer
2023.02.13 15:33:39.796 4: sduino868: KeepAlive, ok, retry = 0
was bekommst Du mit "get ccconf"?
Ich bekomme:
ccconf: freq:868.300MHz bWidth:203KHz rAmpl:33dB sens:8dB (DataRate:17257.69Baud)
Modulation:2-FSK (SYNC_MODE:16/16 + carrier-sense above threshold) DEVIATN:88.867kHzZitatSehe ich die empfangenen RAWMSG im Log mit verbose 4?
ja
Hier mein get cconf:
ccconf: Freq: 868.300 MHz, Bandwidth: 203 kHz, rAmpl: 33 dB, sens: 8 dB, DataRate: 17.26 kBaud, Modulation: 2-FSK, Syncmod: 16/16 sync word bits detected, Deviation: 88.87 kHz
Syntaktisch leicht abweichend, semantisch aber gleichbedeutend, oder?
Ist trotzdem interessant, warum das nicht identisch ist.
Ich habe folgende Repositories eingebunden:
http://fhem.de/fhemupdate/controls_fhem.txt
https://raw.githubusercontent.com/sw-home/FHEM-HomeConnect/master/controls_homeconnect.txt
https://raw.githubusercontent.com/verybadsoldier/esp_rgbww_fhemmodule/master/controls_espledcontroller.txt
https://raw.githubusercontent.com/uniqueck/fhem-abfall/master/controls_fhemabfall.txt
https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/master/controls_signalduino.txt
Gibt es da eine Präferenz? Ist die Reihenfolge relevant, wenn ein Modul von mehreren Repositories angeboten wird?
Die Ausgabe weicht ab da ich eine eigene Firmware und 00_SIGNALDuino Modul verwende
https://forum.fhem.de/index.php/topic,111653.msg1058900.html#msg1058900
Du kannst es mal mit meiner Firmware versuchen. Für den nanocul ist es die 3.3.5
ZitatGibt es da eine Präferenz? Ist die Reihenfolge relevant, wenn ein Modul von mehreren Repositories angeboten wird?
Das spielt hier keine Rolle
Zitat von: Ralf9 am 13 Februar 2023, 17:49:56
Du kannst es mal mit meiner Firmware versuchen. Für den nanocul ist es die 3.3.5
Habs gerade versucht, bringt leider auch keine Verbesserung.
Hast Du den rfmode "Lacrosse_mode1_WS1080_TX38" getestet?
Du kannst auch mal diese beiden testen:
"DP100_WH51_WH57_868" da musst Du wahrscheinlich die Frequenz anpassen
und beim rfmodeTesting:
"Lacrosse_mode1_TX38"
hier ist eine Übersicht der rfmodes
https://ralf9.github.io/SD_rfmode.html
Wie stelle ich denn bei deiner Version den rfmode ein? Ich finde das Attribut nicht in der Liste und ein entsprechendes Set finde ich auch nicht...
Sorry, stelle mich wahrscheinlich gerade doof an.
es gibt ein "set rfmode" und ein set "rfmodeTesting"
Also, ich habe dein SIGNALduino Module mittels "update all https://raw.githubusercontent.com/Ralf9/RFFHEM/master/controls_ralf9_signalduino.txt" installiert.
Dann ein "shutdown restart", den Update Channel auf "Ralf9" gestellt und die FW 3.3.5 geflasht.
Danach sieht mein Set Menü im SIGNALduino wie im Screenshot aus.
Die aktuelle Version ist:
versionmodul v3.4.14-dev_ralf_29.09.
versionprotoL v3.4.14-dev_ralf_27.09.
update all https://raw.githubusercontent.com/Ralf9/RFFHEM/dev/controls_dev_ralf9_signalduino.txt
Was ergibt ein "get version"?
Ich hatte zuerst dem Master-Branch installiert.
Nachdem ich jetzt auf deinen Dev-Branch umgestellt habe...
funktioniert es!!!
Ich bekomme den 30.3144.IT tatsächlich im 10 Sekunden-Takt rein.
rfmode = Lacrosse_mode1_WS1080_TX38
Super, vielen Danke dir für die Unterstützung!
beim "rfmode Lacrosse_mode1_WS1080_TX38" werden die gleichen cc1101 Register Einstellungen und Empfangsroutinen wie beim Cul verwendet.
Bitte teste auch mal ob es auch mit dem "set rfmodeTesting Lacrosse_mode1_TX38" funktioniert
Wenn ich den "Lacrosse_mode1_WS1080_TX38__B12_N1_17241" einstelle, dann funktioniert es ebenfalls.
Noch 3 Fragen:
- Der "set rfmode .." wird im eeeprom gespeichert, die Einstellung bleibt also beim Neustart erhalten und ich brauch da kein initCommand setzen, richtig?
- Ich habe noch einen 433MHz SIGNALduino. Den muss ich auch auf deine FW flashen, damit er mit dem FHEM Modul von dir zusammenpasst, oder?
- Wie verhindere ich am besten, dass dein SIGNALduino Modul überschrieben wird? Dein Dev-Repository mit "upd add" hinzufügen oder muss ich das Modul vom update ausschließen (wie ging das gleich nochmal)?
Zitatwenn ich den "Lacrosse_mode1_WS1080_TX38__B12_N1_17241" einstelle, dann funktioniert es ebenfalls.
ich meinte den rfmodeTesting "Lacrosse_mode1_TX38__B5_N1_17241"
Ja es wird alles im EEPROM des Arduinos gespeichert.
Zitatich habe noch einen 433MHz SIGNALduino. Den muss ich auch auf deine FW flashen, damit er mit dem FHEM Modul von dir zusammenpasst, oder?
Nein bei Slowrf (ASK/OOK) funktioniert die offizielle firmware von Sidey auch mit meinem FHEM Modul und meine firmware 3.3.2.1-rc9 funktioniert auch mit dem FHEM Modul von Sidey.
ZitatWie verhindere ich am besten, dass dein SIGNALduino Modul überschrieben wird? Dein Dev-Repository mit "upd add" hinzufügen oder muss ich das Modul vom update ausschließen (wie ging das gleich nochmal)?
Am einfachsten ist ein "attr global exclude_from_update 00_SIGNALduino"
Ok, dann via "exclude_from_update".
Ich wollte vorhin schreiben, dass es auch mit rfmodeTesting = Lacrosse_mode1_TX38__B5_N1_17241 funktioniert. Das war schon so eingestellt, ich hatte nur einen Kopierfehler bei meiner Antwort ::)
In dem "rfmodeTesting = Lacrosse_mode1_TX38__B5_N1_17241" sind Optimierungen enthalten, da Du nur sehr wenig Lacrosse_mode1 Sensoren hast, spielt es keine Rolle welchen rfmode Du verwendest.
Hallo Ralf,
ich habe eher zufällig festgestellt, dass ich meine WH4000SE https://www.froggit.de/product_info.php?language=de&info=p356_wh4000se-wifi-internet-funk-wetterstation---wunderground--ecowitt--pc-anbindung--auswertungssoftware.html (https://www.froggit.de/product_info.php?language=de&info=p356_wh4000se-wifi-internet-funk-wetterstation---wunderground--ecowitt--pc-anbindung--auswertungssoftware.html)Wetterstation mit dem DP100/868MHz, ProtocolID 204 auch direkt auslesen kann. Bislang mache ich es über eine URL. Allerdings sind die meisten Daten etwas daneben. Zumindest in der SD_WS Anzeige. In der Ecowitt App wird der Sensor als WS65 bezeichnet, laut Internet ist es aber wohl ein 7in1 WH65/WS69. Könntest du diesen Sensor in dein SD_WS integrieren und wenn ja, mit welchen Daten kann ich dabei unterstützen? BTW, ich verwende bereits dein SD_WS.
Gruß
Reinhard
Hallo Reinhard,
ZitatIn der Ecowitt App wird der Sensor als WS65 bezeichnet, laut Internet ist es aber wohl ein 7in1 WH65/WS69
Allerdings sind die meisten Daten etwas daneben. Zumindest in der SD_WS Anzeige
Die ProtocolID 204 ist die "WH24 WH65A/B"
Welche Werte passen nicht?
Für die WH65B gibts ein Attribut
elsif ($protocol eq '204') {
if (AttrVal($name, 'model', '') eq 'WH24_65B') {
$SensorTyp = 'WH65B';
$windspeed*=0.06375;
$windgust *=0.51;
$rain *=0.254;
}
else { # WH24
$windspeed*=0.14;
$windgust *=1.12;
$rain *=0.3;
}Gruß Ralf
Danke für die schnelle Rückmeldung!
Ich habe bereit model=WH65B gewählt. Temperatur, Humidity und Windrichtung scheinen weitestgehend zu stimmen. Auch der UV Werte sieht eigentlich gut aus. Der Lux Wert ist mal ca. Faktor 10 zu hoch und Regen sowie Windstärken absolut daneben. Hier mal aktuelle Daten vom Sensor:
Zitat2023-03-09_12:37:55 SD_WS_204 T: 11.9 H: 62 Ws: 6.4 Wg: 9.7 Wd: W Lux: 678740 UV: 4 R: 15111.8
2023-03-09_12:37:55 SD_WS_204 temperature: 11.9
2023-03-09_12:37:55 SD_WS_204 humidity: 62
2023-03-09_12:37:55 SD_WS_204 windSpeed: 6.4
2023-03-09_12:37:55 SD_WS_204 windSpeed_kmh: 360.0
2023-03-09_12:37:55 SD_WS_204 windDirectionDegree: 272
2023-03-09_12:37:55 SD_WS_204 windDirectionText: W
2023-03-09_12:37:55 SD_WS_204 windGust: 9.7
2023-03-09_12:37:55 SD_WS_204 windGust_kmh: 34.9
2023-03-09_12:37:55 SD_WS_204 batteryState: low
2023-03-09_12:37:55 SD_WS_204 rain: 2651.0
2023-03-09_12:37:55 SD_WS_204 rain_total: 15111.8
2023-03-09_12:37:55 SD_WS_204 uv: 4
2023-03-09_12:37:55 SD_WS_204 lux: 678740
2023-03-09_12:37:55 SD_WS_204 id: 05
Und über den WiFi Zugang:
Zitat2023-03-09_12:37:33.080 WH4000SE israining: 0
2023-03-09_12:37:55.676 WH4000SE windspeed: 20.2
2023-03-09_12:37:55.734 WH4000SE rain_week: 13.5
2023-03-09_12:37:55.734 WH4000SE wind_chill_f: 53.4
2023-03-09_12:37:55.734 WH4000SE wind_gust_mps: 7.1
2023-03-09_12:37:55.734 WH4000SE wind_speed: 15.8
2023-03-09_12:37:55.734 WH4000SE rain_month: 13.5
2023-03-09_12:37:55.734 WH4000SE indoorTemperature: 22.3
2023-03-09_12:37:55.734 WH4000SE pressure: 1001.6
2023-03-09_12:37:55.734 WH4000SE indoorHumidity: 39
2023-03-09_12:37:55.734 WH4000SE rain_year: 86.4
2023-03-09_12:37:55.734 WH4000SE wind_chill: 11.9
2023-03-09_12:37:55.734 WH4000SE rain: 0.0
2023-03-09_12:37:55.734 WH4000SE wind_speed_mps: 4.4
2023-03-09_12:37:55.734 WH4000SE dewpoint: 4.6
2023-03-09_12:37:55.734 WH4000SE wind_direction: 263
2023-03-09_12:37:55.734 WH4000SE wind_speed_mph: 9.8
2023-03-09_12:37:55.734 WH4000SE wind_gust: 25.6
2023-03-09_12:37:55.734 WH4000SE humidity: 61
2023-03-09_12:37:55.734 WH4000SE rain_day: 9.9
2023-03-09_12:37:55.734 WH4000SE temperature: 11.9
2023-03-09_12:37:55.734 WH4000SE wind_gust_mph: 15.9
2023-03-09_12:37:55.734 WH4000SE luminosity: 70075.2
2023-03-09_12:37:55.734 WH4000SE wind_compasspoint: W
2023-03-09_12:37:55.734 WH4000SE wind_speed_bft: 3
2023-03-09_12:37:55.734 WH4000SE wind_speed_kn: 8.5
2023-03-09_12:37:55.734 WH4000SE wind_speed_fts: 14.4
2023-03-09_12:37:55.734 WH4000SE wind_gust_bft: 4
2023-03-09_12:37:55.734 WH4000SE wind_gust_kn: 13.8
2023-03-09_12:37:55.734 WH4000SE wind_gust_fts: 23.3
2023-03-09_12:37:55.734 WH4000SE wind_gust_direction_avg10m: 276
2023-03-09_12:37:55.734 WH4000SE wind_direction_avg2m: 266
2023-03-09_12:37:55.734 WH4000SE wind_speed_avg2m: 18.0
2023-03-09_12:37:55.734 WH4000SE wind_speed_mph_avg2m: 11.2
2023-03-09_12:37:55.734 WH4000SE wind_speed_kn_avg2m: 9.7
2023-03-09_12:37:55.734 WH4000SE wind_speed_mps_avg2m: 5.0
Ich kann natürlich auch die RAW Message dazu raussuchen, dauert etwas länger.
Gruß Reinhard
ZitatDer Lux Wert ist mal ca. Faktor 10 zu hoch und Regen sowie Windstärken absolut daneben
Wird über Wifi auch Lux angezeigt? Ist es immer um den selben Faktor zu hoch?
Und bei den Windstärken ist es da auch immer um den selben Faktor zu hoch?
Beim Regen sind die absuluten Werte nicht aussagekräftig, Du müsstest Dir mal beim SD_WS_204 und über Wifi das rain merken und dann darauf achten ob es sich bei beiden gleich erhöht
Hallo Ralf,
der Lux Wert ist im WiFi Faktor 10 kleiner. Ich habe ein paar vergleichbare Werte genommen, scheint konstant zu sein.
Der "rain_total" Wert ist einfach konstant, der rain Wert entspricht dem gesamten bislang gemessenen Niederschlag.
wind_speed wird in m/s ausgegeben und wind_speed_kmh hat den Faktor 55 auf wind_speed.
wind_gust scheint beide Male den richtigen Wert zu zeigen.
UV, Temp und Hum scheinen soweit korrekt zu sein.
Ich hoffe die Werte helfen dir ein wenig, viel kann es ja jetzt nicht mehr sein ;)
Gruß Reinhard
Ich hab mirs angeschaut.
Bei der ProtocolID 204 ist in der SD_WS noch ein Bug bei Lux (geteilt durch 10 fehlt) und bei wind_speed_kmh. Es gibt demnächst eine neue Version der SD_WS
Das wind_speed in m/s müsste eigentlich passen
Bei rain bitte mal beobachten ob sich bei SD_WS_204 und über Wifi das rain gleich erhöht.
Hallo Ralf,
das meinte ich mit "entspricht dem gesamten...", mein Fehler. Der Gesamtwert ist um den gleichen Betrag gestiegen wie auch der Tageswert. Immer schön parallel mit jedem Regenschauer der kam. rain entsprich also eigentlich dem rain_total Wert und ist als solcher korrekt. Was fehlt ist der aktuelle Niederschlagswert. Die Wochen-, Monats- und Jahreswerte in der WiFi Übertragung stammen sicherlich von der Basisstation.
Gruß Reinhard
Zitat von: Reinhard.M am 10 März 2023, 13:15:55
Hallo Ralf,
das meinte ich mit "entspricht dem gesamten...", mein Fehler. Der Gesamtwert ist um den gleichen Betrag gestiegen wie auch der Tageswert. Immer schön parallel mit jedem Regenschauer der kam. rain entsprich also eigentlich dem rain_total Wert und ist als solcher korrekt. Was fehlt ist der aktuelle Niederschlagswert. Die Wochen-, Monats- und Jahreswerte in der WiFi Übertragung stammen sicherlich von der Basisstation.
Gruß Reinhard
Wenn ich es richtig verstehe, ist das korrekt so. Der Sensor sendet nur "rain". Raintotal soll im Falle eines Ausfalls/Reset/Batteriewechsel des Sensors den letzten Wert halten, um dann damit weiterzählen zu können.
Zitat von: hajo23 am 10 März 2023, 18:21:51
Wenn ich es richtig verstehe, ist das korrekt so. Der Sensor sendet nur "rain". Raintotal soll im Falle eines Ausfalls/Reset/Batteriewechsel des Sensors den letzten Wert halten, um dann damit weiterzählen zu können.
Grundsätzlich nicht falsch. Allerdings soll der "rain_total" den Gesamtwert liefern und "rain" den aktuellen Niederschlag. Momentan wird in "rain" der Gesamtwert geführt und in "rain_total" ein etwa 5,7 mal größerer Fantasiewert der sich zwar mit dem "rain" Wert gleichzeitig ändert aber nicht um einen festen Faktor. Momentan (3 verschiedene Messwerte verglichen) liegt der Abstand zwischen rain und rain_total bei 5,697 / 5,698 / 5,699. Der Unterschied sieht zwar gering aus, sollte aber bei einer fixen Umrechnung nicht vorkommen.
@Ralf: Das ich "rain_total" zunächst als fix betrachtet hatte lag wohl an zu wenig Daten. Beide Rain Werte ändern sich gleichzeitig. Allerdings nicht mit konstanten Abstandfaktor.
rain und rain_total sollte sich eigentlich mit gleichem Abstand ändern.
Es gibt ein reading ".rainOffset"
rain_total ist rain + rainOffset
# rain
if (defined($rain) && defined(ReadingsVal($name, 'rain', undef))) {
my $rainOffset = ReadingsVal($name, ".rainOffset", 0);
my $maxdeviation = AttrVal($name, 'max-deviation-rain', $defaultMaxDeviation);
if (SD_WS_Sanity_checks($ioname, $name, 'rain', 'rain', $rain, 0, $maxdeviation) == -1) {
my $valErr = ReadingsVal($name, 'rainErr', undef);
if (!defined($valErr)) {
readingsSingleUpdate($hash, 'rainErr', $rain, 0); # fehlerhafte rain merken
$sanityFlag = 0; # Abbruch
}
else { # die vorherige rain war fehlerhaft -> Differenz zur vorherigen rain pruefen
if (SD_WS_Sanity_checks($ioname, $name, 'rainErr', 'rainErr', $rain, 0, $maxdeviation) == -1) {
readingsSingleUpdate($hash, 'rainErr', $rain, 0);
$sanityFlag = 0; # Abbruch
}
else { # rain ok
readingsDelete($hash, "rainErr");
my $lastRain = ReadingsVal($name, "rain", 0);
# wenn der aktuelle Wert < letzter Wert ist, dann fand ein reset statt
# die Differenz "letzter Wert - aktueller Wert" wird dann als offset für zukünftige Ausgaben zu rain addiert
# offset wird auch im Reading ".rain_offset" gespeichert
if ($rain < $lastRain) {
$rainOffset += $lastRain;
readingsSingleUpdate($hash, '.rainOffset', $rainOffset, 0);
Log3 $hash, 3, "$ioname: $name reset rain, rain: $rain lastrain: $lastRain, new rainOffset: $rainOffset";
}
}
}
}
else { # rain ok
if (defined(ReadingsVal($name, 'rainErr', undef))) {
readingsDelete($hash, "rainErr");
}
}
$rain_total = $rain + $rainOffset;
}
return "" if ($sanityFlag == 0);
Zitat von: Ralf9 am 12 März 2023, 12:20:08
rain und rain_total sollte sich eigentlich mit gleichem Abstand ändern.
Es gibt ein reading ".rainOffset"
rain_total ist rain + rainOffset
Stimmt, 12460,8. Dann passt es auch das der Quotient sich ändert :)
Es gibt eine neue Version meiner Variante der 14_SD_WS.pm
https://github.com/Ralf9/14_SD_WS/blob/main/FHEM/14_SD_WS.pm
update all https://raw.githubusercontent.com/Ralf9/14_SD_WS/main/controls_ralf9_sd_ws.txt
- neue ID 123: Inkbird IBS-P01R, ITH-20R (Pool Thermometer)
- ID 120: BatteryState zugefügt
- ID 122: update
- ID 204: bugfix, Lux und windSpeed_kmh
Gruß Ralf
Hallo Ralf,
Wind und Lux scheinen bei mir erst einmal zu passen, ich werde es weiter beobachten.
Gruß Reinhard
Hallo zusammen,
angestoßen durch die Diskussion hier
https://forum.fhem.de/index.php?topic=134268.msg1286131#msg1286131 (https://forum.fhem.de/index.php?topic=134268.msg1286131#msg1286131)
möchte ich jetzt doch mal mein Problem/Feststellung schildern.
Ich habe hier im Forum Bodenfeuchtesensoren WH51 erworben und die funktionieren soweit auch gut.
Um FSK empfangen zu können, habe ich mir einen SignalESP mit der Firmware 3.5.1 RC 1 zusammengesteckt.
define SIGNALFSK SIGNALduino 192.168.2.58:23
attr SIGNALFSK hardware esp8266cc1101
attr SIGNALFSK rfmode Fine_Offset_WH51_434
attr SIGNALFSK verbose 4
attr SIGNALFSK whitelist_IDs 107
# CFGFN
# Clients :CUL_EM:CUL_FHTTK:CUL_TCM97001:CUL_TX:CUL_WS:Dooya:FHT:FLAMINGO:FS10:FS20: :Fernotron:Hideki:IT:KOPP_FC:LaCrosse:OREGON:PCA301:RFXX10REC:Revolt:SD_AS:SD_Rojaflex: :SD_BELL:SD_GT:SD_Keeloq:SD_RSL:SD_UT:SD_WS07:SD_WS09:SD_WS:SD_WS_Maverick:SOMFY: :Siro:SIGNALduino_un:
# DEF 192.168.2.58:23
# DMSG W107#510D48E6107F1B00AA00000010F0
# DevState initialized
# DeviceName 192.168.2.58:23
# FD 7
# FUUID 64c4d228-f33f-17d9-6aca-d3da3c1b819a6fb1
# LASTDMSG W107#510D48E6107F1B00AA00000010F0
# LASTDMSGID 107
# MSGCNT 8
# NAME SIGNALFSK
# NR 47
# PARTIAL
# RAWMSG MN;D=510D48E6107F1B00AA00000010F0;R=52;
# RSSI -48
# STATE opened
# TIME 1690620762.75552
# TYPE SIGNALduino
# cc1101_available 1
# eventCount 5
# sendworking 0
# version V 3.5.1-RC1 SIGNALESP cc1101 (chip CC1101) - compiled at Jun 18 2023 10:45:20
# versionProtocols 1.48
# versionmodul 3.5.5+20230516
# DoubleMsgIDs:
# MatchList:
Mit dem originalen SD_WS müssten diese Sensoren ja empfangbar sein. Aus der commandref:
ZitatFine Offset WH51, aka ECOWITT WH51, aka Froggit DP100, aka MISOL/1 (Bodenfeuchtesensor)
Leider bekomme ich damit aber Fehlermeldungen derart:
2023.07.29 10:50:37 4: SIGNALFSK: Read, msg: ␂MN;D=510D48E30F7F2B00E10000007DA0;R=22;␃
2023.07.29 10:50:37 4: SIGNALFSK: Parse_MN, Found 2-FSK Protocol id 107 -> WH51 433.92 MHz with match (?^:^51)
2023.07.29 10:50:37 4: SIGNALFSK: SD_WS_Parse protocol 107, rawData 510D48E30F7F2B00E10000007DA0
2023.07.29 10:50:37 4: SIGNALFSK: SD_WS_Parse 510D48E30F7F2B00E10000007DA0 protocolid 107 (WH51, DP100, MISOL/1) - ERROR prematch
2023.07.29 10:50:39 4: SIGNALFSK: KeepAlive, ok, retry = 0
2023.07.29 10:51:32 4: SIGNALFSK: Read, msg: MN;D=510D48E6107F1B00AA00000010F0;R=53;
2023.07.29 10:51:32 4: SIGNALFSK: Parse_MN, Found 2-FSK Protocol id 107 -> WH51 433.92 MHz with match (?^:^51)
2023.07.29 10:51:32 4: SIGNALFSK: SD_WS_Parse protocol 107, rawData 510D48E6107F1B00AA00000010F0
2023.07.29 10:51:32 4: SIGNALFSK: SD_WS_Parse 510D48E6107F1B00AA00000010F0 protocolid 107 (WH51, DP100, MISOL/1) - ERROR prematch
2023.07.29 10:51:32 4: SIGNALFSK: Read, msg: MN;D=510D48E6107F1B00AA00000010F0;R=53;Daher habe ich testweise das Modul 14_SD_WS von @Ralf9 genommen und damit geht es einwandfrei.
define FeuchteKraeuter SD_WS SD_WS_107_H_0D48E3
attr FeuchteKraeuter event-min-interval humidity:300,ad:300
attr FeuchteKraeuter event-on-change-reading .*
attr FeuchteKraeuter room XX_Neu
# CODE SD_WS_107_H_0D48E3
# DEF SD_WS_107_H_0D48E3
# FUUID 64c017d9-f33f-8873-2d62-ab96bbd86191011e
# FVERSION 14_SD_WS.pm:0.216660/2023-06-10
# LASTInputDev SIGNALFSK
# MSGCNT 20887
# NAME FeuchteKraeuter
# NR 1067
# SIGNALFSK_DMSG W107#510D48E30F7F2A00DF0000007797
# SIGNALFSK_MSGCNT 20887
# SIGNALFSK_Protocol_ID 107
# SIGNALFSK_RAWMSG MN;D=510D48E30F7F2A00DF0000007797;R=10;
# SIGNALFSK_RSSI -69
# SIGNALFSK_TIME 2023-09-06 15:28:44
# STATE H: 42 Bv: 1.5
# TYPE SD_WS
# bitMSG
# eventCount 6348
# lastMSG 510D48E30F7F2A00DF0000007797
# lastReceive 1694006924.61298
# READINGS:
# 2023-09-06 15:28:44 ad 223
# 2023-09-06 15:28:44 batteryVoltage 1.5
# 2023-09-06 15:28:44 humidity 42
# 2023-09-06 15:28:44 id 0D48E3
# 2023-09-06 15:28:44 state H: 42 Bv: 1.5
# 2023-09-06 15:28:44 transPerBoost 0
# 2023-09-06 15:28:44 type WH51
#
setstate FeuchteKraeuter H: 42 Bv: 1.5
setstate FeuchteKraeuter 2023-09-06 15:28:44 ad 223
setstate FeuchteKraeuter 2023-09-06 15:28:44 batteryVoltage 1.5
setstate FeuchteKraeuter 2023-09-06 15:28:44 humidity 42
setstate FeuchteKraeuter 2023-09-06 15:28:44 id 0D48E3
setstate FeuchteKraeuter 2023-09-06 15:28:44 state H: 42 Bv: 1.5
setstate FeuchteKraeuter 2023-09-06 15:28:44 transPerBoost 0
setstate FeuchteKraeuter 2023-09-06 15:28:44 type WH51
14_SD_WS.pm 21666 2023-06-10 10:00:00Z Ralf9
00_SIGNALduino.pm 26977 2023-01-06 11:35:00Z SideyWo ist denn da jetzt mein Denkfehler?
Und wie passt dann
Zitat von: Ralf9 am 06 September 2023, 14:57:38Bei Bedarf könnte ich mein 14_SD_WS Modul so anpassen und ergänzen, daß es auch bei FSK mit dem 00_SIGNALduino Modul von sidey verwendet werden kann.
Gruß
Norbert
Hallo Norbert,
ZitatMit dem originalen SD_WS müssten diese Sensoren ja empfangbar sein. Aus der commandref:
Leider bekomme ich damit aber Fehlermeldungen derart:
Der Grund ist eine regex in der prematch Routine, die nicht für alle Sensoren passt.
Hier sind einige Unterschiede der SD_WS Module von mir und Sidey:
Bei mir wird bei den IDs 107, 116, 207 und 213 die fixeID an die DEF angehängt. Bei Sidey muß da bei Bedarf das sduino Attribut longids gesetzt werden.
Die ID 207 entspricht der ID 117 von Sidey.
Bei Sidey werden bei den ID 115 und 117 die CRC am Anfang auch zum SD_WS übertragen obwohl diese bereits im 00_SIGNALduino Modul berechnet wurden. Bei der ID 108 wird die Prüfsumme am Anfang nicht zum SD_WS übertragen, dies ist nicht ganz einheitlich.
Bei mir wird bei den ID 115 und 207 die CRC am Anfang nicht zum SD_WS übertragen.
Die IDs 211 (Sidey 125) und IDs 213 (Sidey 126) sind nicht kompatibel.
Bei Sidey wird die CRC im SD_WS berechnet
Ich berechne die CRC im 00_SIGNALduino Modul
Gruß Ralf
Hallo Ralf,
dank für die Erläuterungen zu den Unterschieden.
Zitat von: Ralf9 am 06 September 2023, 17:57:20Der Grund ist eine regex in der prematch Routine, die nicht für alle Sensoren passt.
Ist das jetzt Absicht oder ein Bug?
Der WH51 ist ja schließlich als unterstütztes Modell angegeben.
Oder liegt es an einer speziellen Ausführung meiner WH51?
Norbert
Bei den 433 MHz WH51 gibts einige wenige wo sich die Nachrichten ein klein wenig unterscheiden, für diese passt die regex nicht.
Solche Probleme können entstehen, wenn bei einer regex auch Ziffern überprüft werden deren Bedeutung nicht bekannt ist.
Zitat von: Nobbynews am 11 September 2023, 06:42:24Ist das jetzt Absicht oder ein Bug?
Der WH51 ist ja schließlich als unterstütztes Modell angegeben.
Oder liegt es an einer speziellen Ausführung meiner WH51?
Ist mehr ein Fehler, als Absicht. Daten, wie sie von deinem Sensor kommen, lagen uns bisher noch nicht vor. Daten, die wir bisher so nicht kennen, lehnen wir ab. Dadurch werden unsere Testdaten umfangreicher und wir können auch in 3 Jahren noch feststellen, ob wir den Sensor verarbeiten.
Den Fix halt @elektron-bbs schon erstellt, der sollte in Kürze auch durch das Review sein und auch sehr zeitnah den Weg ins SVN finden.
Der Fehler ist nun auch in der durch das SVN verteilten Version behoben.
https://forum.fhem.de/index.php?topic=134953.0
Zitat von: Sidey am 14 September 2023, 08:06:28Der Fehler ist nun auch in der durch das SVN verteilten Version behoben.
Lüppt!
Danke