Closed roobbb closed 6 years ago
Mit der angehängten Log Datei hat etwas nicht geklappt. Du kannst es auch direkt hier als code reinkopieren
Wow, so schnell war ich nicht. Jetzt müsste es drin sein. Danke für den Hinweis
Da kommen verschiedene Sachen rein:
2018.09.10 20:24:51 4: SignalDuino_434: decoded matched MU Protocol id 40 dmsg u40#C4430238 length 32 RSSI = -78.5
aber auch das hier:
2018.09.10 20:24:50 4: SignalDuino_434/msg READ: MC;LL=-606;LH=594;SL=-259;SH=242;D=52A54AA9554AA8;C=283;L=54;R=247;
2018.09.10 20:24:50 4: SignalDuino_434/msg READ: MC;LL=-629;LH=595;SL=-259;SH=225;D=5554A952A554AAA554;C=284;L=71;R=248;
2018.09.10 20:24:50 4: SignalDuino_434/msg READ: MC;LL=-623;LH=599;SL=-256;SH=234;D=52A54AA9554AA8;C=285;L=54;R=248;
Hast Du an dem Sender einen Knopf oder eine LED die blinkt, wenn der Sender eine Nachricht sendet?
Wenn da ein Knopf ist, dann am besten mal im Abstand von 10 Sekunden mehrmals betätigen und den passenden Zeitraum im Log suchen.
Stimmt, da funkt noch etwas dazwischen. Es gibt einen Knopf und einen Kanalwahlschalter. Hab den Knopf nun mehrfach gedrückt. Aber irgendwas mit MC... ist trotzdem dabei - ich versuchs mal... Auriol.txt
@roobbb
habe ich richtig geschaut und das man den Außensensor verstellen kann? Ch1 - CH3? Wenn Ja, bitte sammle einmal Daten wenn du auf CH1 gestellt hast, dann auf CH2 und ebenso auf CH3.
Der erste Blick auf die gefilterten Daten zeigt, die Nachrichtenlänge schwankt arg. Zwischen u20 und ü 40 ist alles dabei.
Ja stimmt, Ch01 - 03.
Channel 1 - 10x gedrückt: Auriol01.txt
Channel 2 - 10x gedrückt: Auriol02.txt
und Channel 3 - 10x gedrückt: Auriol03.txt
@roobbb Du formatierst als einzelen code... naja gut der Editor hier macht das gerne so, wenn vorher nicht mehere Zeilen markiert sind. Wenn Du den logtext markierst und dann insert code wählst, macht er einen mehrzeilen codebschnitt und die Zeilenumbrüche bleiben erhalten.
@roobbb Welche Firmware hast Du drauf?
V 3.3.1-dev SIGNALduino cc1101 - compiled at Mar 10 2017 22:54:50
Hab die Logs nochmals formatiert. Sah wirklich konfus aus.
Probier bitte mal die für deine Hardware passende: https://wiki.fhem.de/wiki/SIGNALduino#Vorabversion_einer_Firmware
Ich glaube uns fehlen aktuell ein paar Daten.
PS: Ich hatte deine Beiträge auch aktualisiert :)
OK: V 3.3.1-RC7 SIGNALduino cc1101 - compiled at May 11 2018 23:00:28
Wie sehen die Daten jetzt aus? Fürs erste reicht ein Kanal :)
Auf Ch1 - 5x gedrückt: Auriol01_5x.txt
Wenn ich richtig schaute, dann sieht es verdächtig nach Preamble + 36bits aus. Hatte vorhin da eine Definition offen. Der CH2 + CH3 könnten vielleicht doch nützlich sein weil man so eine „Ankerstelle“ leichter finden kann wenn es gänzlich unbekannt sein sollte.
Bitte doch mal die 2 CH noch offenlegen und ich schaue morgen noch einmal was ich vorhin dachte. Die „kochen“ ja alle fast gleich.
G8 erstmal
@HomeAutoUser : Wenn Ihr Euch wegen meinem Popeltempsensor die Nacht um die Ohren schlagt, habe ich ein schlechtes Gewissen :)
Ch2 - 5x gedrückt Auriol02_5x.txt
Beim Drücken ist mir aufgefallen, dass der Sensor selbst zwischendrin auch von allein zusätzlich sendet. Falls das irgendwie hilft (?).
Vielen Dank und beste Grüße rob
Erstmal ist gut, dass die neuere Firmware das Problem mit den fehlerhaften MC Ausgaben auflöst. @HomeAutoUser Was meinst Du? Protokoll 40 scheint nicht zu passen.
@sidey79
Erstmal ist gut, dass die neuere Firmware das Problem mit den fehlerhaften MC Ausgaben auflöst.
Meinst du damit, das bei den Ausgaben auf einmal keine MC mit dabei ist?
Was meinst Du? Protokoll 40 scheint nicht zu passen.
Ich habe mal eine "Gegenüberstellung" geschaffen und bin mir aber nicht sicher.
2018.09.10 23:12:54 4: SIGNALduino_unknown converted to bits: 1101010 1 0000001111110110 1111
2018.09.10 23:12:54 4: SIGNALduino_unknown converted to bits: 1101010 1 0000001111110110 1111
2018.09.10 23:12:54 4: SIGNALduino_unknown converted to bits: 00000 11001101010 1 0000001111110110 1111 000
2018.09.10 23:12:54 4: SIGNALduino_unknown converted to bits: 00000 11001101010 1 0000001111110110 1111 000
2018.09.10 23:12:54 4: SIGNALduino_unknown converted to bits: 1010 1 0000001111110110 1111 000
2018.09.10 23:12:54 4: SIGNALduino_unknown converted to bits: 1010 1 0000001111110110 1111 000
2018.09.10 23:12:54 4: SIGNALduino_unknown converted to bits: 11001101010 1 0000001111110110 1111 0000
2018.09.10 23:12:54 4: SIGNALduino_unknown converted to bits: 11001101010 1 0000001111110110 1111 0000
2018.09.10 23:12:55 4: SIGNALduino_unknown converted to bits: 00000 11001101010 1 0000001111110110 1111 000
2018.09.10 23:12:55 4: SIGNALduino_unknown converted to bits: 00000 11001101010 1 0000001111110110 1111 000
2018.09.10 23:12:58 4: SIGNALduino_unknown converted to bits: 00000 11001101010 1 0000001111110110 1111 000
2018.09.10 23:12:58 4: SIGNALduino_unknown converted to bits: 00000 11001101010 1 0000001111110110 1111 000
2018.09.10 23:12:59 4: SIGNALduino_unknown converted to bits: 1010 1 0000001111110110 1111 000
2018.09.10 23:12:59 4: SIGNALduino_unknown converted to bits: 1010 1 0000001111110110 1111 000
2018.09.10 23:12:59 4: SIGNALduino_unknown converted to bits: 00000 11001101010 1 0000001111110110 1111 000
2018.09.10 23:12:59 4: SIGNALduino_unknown converted to bits: 00000 11001101010 1 0000001111110110 1111 000
2018.09.10 23:13:00 4: SIGNALduino_unknown converted to bits: 11001101010 1 0000001111110110 1111 0000
2018.09.10 23:13:00 4: SIGNALduino_unknown converted to bits: 11001101010 1 0000001111110110 1111 0000
2018.09.10 23:13:00 4: SIGNALduino_unknown converted to bits: 00000 11001101010 1 0000001111110110 1111 000
2018.09.10 23:13:00 4: SIGNALduino_unknown converted to bits: 00000 11001101010 1 0000001111110110 1111 000
2018.09.10 23:13:00 4: SIGNALduino_unknown converted to bits: 1101010 1 0000001111110110 1111 0000
2018.09.10 23:13:00 4: SIGNALduino_unknown converted to bits: 1101010 1 0000001111110110 1111 0000
2018.09.11 06:25:52 4: SIGNALduino_unknown converted to bits: 00000 11010011100 1 0100001000001100 0010 100
2018.09.11 06:25:52 4: SIGNALduino_unknown converted to bits: 00000 11010011100 1 0100001000001100 0010 100
2018.09.11 06:25:52 4: SIGNALduino_unknown converted to bits: 10011100 1 01000010000
2018.09.11 06:25:52 4: SIGNALduino_unknown converted to bits: 10011100 1 01000010000
2018.09.11 06:25:52 4: SIGNALduino_unknown converted to 001000000 11010011100 1 0100001000001100 0010 100
2018.09.11 06:25:52 4: SIGNALduino_unknown converted to 001000000 11010011100 1 0100001000001100 0010 100
2018.09.11 06:25:52 4: SIGNALduino_unknown converted to bits: 00000 11010011100 1 0100001000001100 0010 100
2018.09.11 06:25:52 4: SIGNALduino_unknown converted to bits: 00000 11010011100 1 0100001000001100 0010 100
2018.09.11 06:25:52 4: SIGNALduino_unknown converted to bits: 00000 11010011100 0 0100001000001100 1101 100
2018.09.11 06:25:52 4: SIGNALduino_unknown converted to bits: 00000 11010011100 0 0100001000001100 1101 100
2018.09.11 06:25:52 4: SIGNALduino_unknown converte 001000000 11010011100 0 0100001000001100 1101 100
2018.09.11 06:25:52 4: SIGNALduino_unknown converted to 001000000 11010011100 0 0100001000001100 1101 100
2018.09.11 06:25:52 4: SIGNALduino_unknown converted to bits: 00000 11010011100 0 0100001000001100 1101 100
2018.09.11 06:25:52 4: SIGNALduino_unknown converted to bits: 00000 11010011100 0 0100001000001100 1101 100
2018.09.11 06:25:52 4: SIGNALduino_unknown converted to bits: 10011100 0 0100001000001100 1101 100
2018.09.11 06:25:52 4: SIGNALduino_unknown converted to bits: 10011100 0 0100001000001100 1101 100
2018.09.11 06:25:53 4: SIGNALduino_unknown converted to bits: 11100 0 0100001000001100 1101 10
2018.09.11 06:25:53 4: SIGNALduino_unknown converted to bits: 11100 0 0100001000001100 1101 10
2018.09.11 06:25:53 4: SIGNALduino_unknown converted to b 001000000 11010011100 0 0100001000001100 1101 100
2018.09.11 06:25:53 4: SIGNALduino_unknown converted to 001000000 11010011100 0 0100001000001100 1101 100
2018.09.11 06:25:53 4: SIGNALduino_unknown converted to bits: 11010011100 1 0100001000001100 0010 1000
2018.09.11 06:25:53 4: SIGNALduino_unknown converted to bits: 11010011100 1 0100001000001100 0010 1000
Ich komme in manchen Fällen auf 32-36bit und es könnte anfangs ein "Muster" vorhanden sein. ABER wenn ich CH1 und CH2 von der Länge vergleiche, so komme ich noch nicht auf einen Nenner.
Bin mir aber diesbezüglich unsicher. Nach genauen Werten habe ich noch nicht geschaut denn da wäre eine Dokumentation von @roobbb notwendig damit wir nicht zu sehr stochern.
@sidey79 wenn ich allgemein nach AURIOL ... --> Lidl Station google komme ich hierauf . Da fällt mir wieder das model 0110 vor die Füße aber ich habe das Ganze noch nicht weiter verfolgt.
Hallo.
Ich habe das Teil kurzerhand aufgeschraubt. Fotos anbei. Leider scheint das IC genau unterm Display verklebt zu sein. Hinten steht noch etwas von ModellNr. HG02832D. Aber auch damit finde ich nix brauchbares via Gurgel. IAN 114324 scheint baugleich zu sein.
Ansonsten habe ich zu pilight was gefunden (Auriol 89210) - passt nur nicht 100%, aber vielleicht ist ein Ansatz dabei. https://manual.pilight.org/protocols/433.92/weather/auriol_89210.html
Anscheinend habe ich da ein doofes Teil erwischt ☹
Ich habe den Empfänger auch gleich mal zerlegt. Ich konnte zwei ICs erkennen: links ZR6100 - scheint sich um den DCF77 Krams zu kümmern und rechts ein CMT2210LC - scheint der Empfängerteil zu sein. Laut Datenblatt 433.92MHz OOK. Naja, nicht wirklich viel.
@roobb Wenn du das gleich noch einmal mit dem Sensor machst, ist dies vielleicht hilfreicher. Achte bzw. fotografiere da auch die Platine bitte.
@HomeAutoUser Das sind die Fotos im Post davor. Das IC steckt nur leider hinterm LCD. Ich fürchte, wenn ich das abreiße, funktioniert zum Dank das LCD nicht mehr und das IC könnte unbeschriftet sein 😱
Ach watt solls, ich reiß es ab. Meld mich gleich...
Mach das lieber nicht. Das IC ist sicher sowieso unter einem schwarzen "Klecks" versteckt. Auf dem Gehäuse des Sensors steht wohl nichts weiter?
Ah ja. Hinterm LCD steckt ja nur der Treiber. Den gesuchten Funkteil habe ich oben schon erwischt 😜
Egal. LCD läuft noch und Foto anbei. Auf dem IC steht 0A7pa und auf dem PCB steht RF11-B. Tante Google weiß dazu so direkt nix.
@elektron-bbs Vor lauter Eifer habe ich Deinen Post erst jetzt gesehen. Danke für die Warnung. Und Du hattest Recht mit dem Klecks. Auf dem Gehäuse bappt nur der silberne Beipackzettel aus obigen Fotos. Naja, den Versuch wars wert.
Habe eben mal versucht, ob der RFXtrx was empfängt und anzeigt, wenn ich alles aktiviere - auch undec. Nö, empfängt nix. Als wäre kein Sender da.
@HomeAutoUser
Meinst du damit, das bei den Ausgaben auf einmal keine MC mit dabei ist? Ja
Ich habe mal eine "Gegenüberstellung" geschaffen und bin mir aber nicht sicher.
Ich bin auch nicht sicher :)
@roobbb Machst Du mal ein get SignalDuino_434 config auf den SDUINO?
@sidey79 Gern: config: MS=1;MU=1;MC=1;Mred=0
Die Nachrichten Komprimierung solltest Du wieder aktivieren. Das ganze logging machst Du ja über FHEM:
set SignalDuino_434 raw CER
OK. Hab ich. Danke für den Tipp.
config: MS=1;MU=1;MC=1;Mred=1
@HomeAutoUser @elektron-bbs
Ich tippe aktuell auf Start +850,-850 (bis zu 3 mal) zero = 240,-620 one = 0|1 600,-250
Zum Beispiel dann: (40 Bits)
00000011 01001110 01010000 10000011 00001011
Das letzte Bit, wird allerdings nicht demoduliert, ich habe die Ahnung, dass die Pause zwischen dem Senden sehr sehr lange ist und der letzte low pegel dann einfach mit der Sendepause einher geht.
Das Protokoll versucht hier zu demodulieren, aber das passt meiner Meinung nach nicht.
@sidey79 wenn ich den Taster gedrückt halte, wird quasi pausenlos gesendet - soll ich das mal auf Ch1 posten? Macht halt die Kommentartapete noch etwas länger 😁
@sidey79 Sieht erstmal plausibel aus.
Genaue Prüfung meinerseits Anfang nächster Woche. Es würde da glaube nur Sinn machen, wenn @robb mal paar werte aufnimmt und dokumentiert welche Werte dahinter stecken im Display. (Separate Textdatei vielleicht)
@sidey79 Ich komme zu einem ähnlichen Ergebnis. Ich habe mir absichtlich Nachrichten gegriffen, die einen eindeutigen Start haben (lange Pause).
"84" => ## Funk Wetterstation Auriol IAN 283582 (Lidl 2018) @roobbb
# https://github.com/RFD-FHEM/RFFHEM/issues/263#issuecomment-420739666
# MU;P0=-28796;P1=376;P2=-875;P3=834;P4=220;P5=-632;P6=592;P7=-268;D=0123232324545454545456767454567674567456745674545454545456767676767674567674567676767456;CP=4;R=22;
# MU;P0=-28784;P1=340;P2=-903;P3=814;P4=223;P5=-632;P6=604;P7=-248;D=0123232324545454545456767456745456767674545674567454545456745454545456767454545456745676;CP=4;R=22;
{
name => 'IAN283582',
comment => 'Funk Wetterstation Auriol IAN 283582',
id => '84',
one => [3,-1],
zero => [1,-3],
start => [4,-4,4,-4,4,-4],
clockabs => 213,
preamble => 'u84#', # prepend to converted message
clientmodule => '', # not used now
modulematch => '', # not used now
length_min => '39', # das letzte Bit fehlt
length_max => '40',
},
@roobbb Den Taster dauernd gedrückt halten, bringt uns nicht weiter. Am besten wäre es, normal zu loggen (verbose 4) und whitelist_IDs nur auf Protokoll 40 setzen. Oder, wenn du es dir zutraust, die signalduino_protocols.hash um die von mir gepostete Eintragung erweitern und dann whitelist_IDs auf Protokoll 84 setzen. Zum Log benötigen wir dann die Temperatur- und Feuchte-Werte, die die Wetterstation jeweils anzeigt.
@elektron-bbs OK. signalduino_protocols.hash ergänzt. whitelist_ID=84. Protokoll anbei.
Ich hoffe, es passt so. Temp+Luftfeuchte haben sich kaum geändert. Habs aber mit allen drei Kanälen geloggt. Wenn stärkere Messwertunterschiede nötig sind, muss ich es etwas anders machen.
Es finden sich nur die LOG-Einträge wo ich anhand Zeitstempel und Sende-LED LOG+LCD sicher zuordnen konnte. Beim Rest war ich durch LOG-Aktualisieren + Copy&Paste + Tippen der Werte abgelenkt.
Viele Grüße rob Auriol_whiteID84.txt
@sidey79 Einen ersten Ansatz habe ich. Ein bereits vorhandenes passendes Modul finde ich nicht. Wollen wir es in das Modul 14_SD_WS.pm als neues Protokoll W84 einbauen?
@roobbb Deine Messwerte waren erst mal ausreichend. Wie es der Zufall so will, empfange ich jetzt hier auch so einen Sensor aus der Nachbarschaft. Zum Test müsstest du nochmal die Definition des Sensors in der Datei signalduino_protocols.hash ändern in folgenden Eintrag:
"84" => ## Funk Wetterstation Auriol IAN 283582 (Lidl) 09/2018@roobbb
# https://github.com/RFD-FHEM/RFFHEM/issues/263#issuecomment-420739666
# MU;P0=-28796;P1=376;P2=-875;P3=834;P4=220;P5=-632;P6=592;P7=-268;D=0123232324545454545456767454567674567456745674545454545456767676767674567674567676767456;CP=4;R=22;
# MU;P0=-28784;P1=340;P2=-903;P3=814;P4=223;P5=-632;P6=604;P7=-248;D=0123232324545454545456767456745456767674545674567454545456745454545456767454545456745676;CP=4;R=22;
{
name => 'IAN283582',
comment => 'Weatherstation Auriol IAN 283582',
id => '84',
one => [3,-1],
zero => [1,-3],
# start => [4,-4,4,-4,4,-4], # Empfang unzuverlässig
# start => [-4,4,-4], # Empfang unzuverlässig
clockabs => 213,
format => 'twostate',
preamble => 'W84#', # prepend to converted message
postamble => '', # append to converted message
clientmodule => 'SD_WS',
length_min => '39', # das letzte Bit fehlt
length_max => '40', # bits + start
},
Außerdem muss die Datei 14_SD_WS.pm im durch diese 14_SD_WS.txt ersetzt werden (bitte umbenennen, hier kann ich keine .pm hochladen).
Was noch fehlt, ist die Auswertung von negativen Temperaturen. Wenn möglich, bitte mal den Sensor in den Tiefkühlschrank packen, sonst müssen wir bis zum Winter warten :-) Außerdem fehlt noch ein Bit, das erschöpfte Batterien signalisiert. Hast du dafür eine Möglichkeit, das zu simulieren? Labornetzteil macht sich natürlich am einfachsten, aber das hat nicht jeder. Erfahrungsgemäß setzen die meisten Sensoren das Bit so unter etwa 2,5 Volt Batteriespannung.
Für eine Auswertung der Daten würde mir dann das Logfile des (hoffentlich) neu angelegten Sensors reichen. Damit darin alle benötigten Informationen gesammelt werden, muss beim SIGNALduino das Attribut "addvaltrigger" auf 1 gesetzt werden.
@elektron-bbs
Ja bitte in das Modul SD_WS einbauen. Das ist genau dafür gedacht
@elektron-bbs Hash und Modul-Dateien geändert. Shutdown restart gemacht. Attribut "addvaltrigger"=1, whitelist_ID=84 und verbose=4. Kein neues Device erkannt. Negative Temp. via Tiefkühler (bis zu kalten Wintertemp. dauerts hoffentlich noch länger 😆 ) und Low Bat mit halbvollen NiMH-Akkus simuliert. LOG mit Werten anbei. Auriol_whiteID84_mehr.txt
Randgedanke: Lt. spec kann der Sensor min. -20°C bis +50°C. Aber z.B. -21,7°C zeigt er noch. Erst ab ca. -22 stieg er mit "LL.L" aus. Vermutung: ein Offset von +2°C könnte eingestellt sein?
Mhmm, heißt das, das bei dir kein SD_WS_TH_x angelegt wurde?
Ich fürchte ja. Hab ich vielleicht etwas vergessen oder hätte etwas anders machen sollen (Reihenfolge)? Ich hatte nur die Files editiert und ein shutdown restart vollführt. Kein update all oder so.
Wenn ich deine Daten hier dispatche, legt es mir die Sensoren an. Verwendest du die aktuelle Entwicklerversion? Wenn nicht, dann mach bitte noch eine Update darauf: update all https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r33/controls_signalduino.txt
ich bin noch dei diesem Stand aus obigem Verlauf gewesen:
version | V 3.3.1-RC7 SIGNALduino cc1101 - compiled at May 11 2018 23:00:28
Hab das update so ausgeführt, die Files editiert und jetzt wurde es auch angelegt.
Ich schließe daraus, dass ich meine Testreihe neu starten sollte? Lad ich hoch, sobald ich's hab 😉
Freut mich, das es jetzt geklappt hat. Tests musst du eigentlich erst mal keine mehr fahren. Batteriebit ist jetzt klar und negative Temperaturen eigentlich auch. Was ich noch nicht heraus bekommen habe, ist ein Byte, das wahrscheinlich als Prüfbyte gedacht ist.
Den Batteriestatus und negative Temperaturwerte habe ich jetzt eingebaut. Bitte noch einmal diese Datei 14_SD_WS.txt einbauen und dann ausgiebig testen.
OK. Zwischenzeitlich hatte ich doch noch geloggt: Auriol_whiteID84_noch_mehr.txt
Meine Beobachtung: Channel, Bat und Hum werden sauber erkannt. Ein Batteriewechsel erzeugt kein neues Device. Bei Temp weicht manchmal die nachkommastelle vom LCD ab. Kann ggf. auch ein Rundungsthema sein - z.B. LCD zeigt gerundet an, obwohl der Wert granularer ankommt.
Schaut wirklich prima aus 😃
Hallo.
Ich habe eine Funk Wetterstation von Lidl, welche auf den Namen Auriol IAN 283582 hört. Es gehört ein Außensender dazu. Dieser funkt auf 433,92Mhz und sendet Temperatur, Luftfeuchte und Batteriestatus.
Weder mit RFXtrx noch mit SIGNALduino scheinen die Daten aktuell dekodiert werden zu können. Der SIGNALduino zeigt lt. Eventmonitor solches:
2018-09-10 20:24:18 SIGNALduino SignalDuino_434 DMSG u40#21811C 2018-09-10 20:24:18 SIGNALduino SignalDuino_434 UNKNOWNCODE u40#21811C
Anbei ein paar Log-Mitschnitte via verbose=4.
Vielleicht ist es ja wert/ interessant genug, um implementiert zu werden. Oder gibt es da ggf. schon etwas? Zu den bekannten Auriols scheint es nicht zu passen.
Ich unterstütze gern so gut ich kann.
Vielen Dank vorab und beste Grüße rob
Auriol.txt