Moin! Ich kämpfe noch immer mit der IR-Fernbedienung meines Pelletofens. Nachdem ich weder über einen Mitschnitt des "Verkehrs" per ID-Diode, noch dem direkten Abfangen der Signale über eine Konsole irgendetwas sinnvolles herausfinden konnte, versuche ich nun den Mikrocontroller auf der (einseitig bestückten) Platine zu identifizieren. Aber irgendwie bin ich zu blöd mit dem großen G auch nur ein verwertbares ergebnis zu finden... Kann jemand anhand der angehängten Grafik das Ding identifizieren? MfG Pascal PS: Ich habe auch schon diese Arduino-Scetches zum Identifizieren von "bekannten" IR-Protokollen getestet. Kommt nur Nonsens raus. Das problem ist ja, dass das Ding jedes mal die Uhrzeit mit übermittelt, sonst würde ich die Impulse mit meinen 2 oder 3 Einstellungen die ich brauche einfach mitschneiden und stumpf abspielen... aber das Ding über mittelt immer alle Parameter und einer davon ist die aktuelle Uhrzeit...
Angehängte Dateien:
Meine Vermutung: kundenspezifischer Controller speziell für Fernbedienungen. Was willst Du erreichen, wenn du wüsstest, welcher Controller das ist? An das Programm kommst du eh nicht ran...
Immerhin könnte ich mit einem Pinout anfangen... Ach Mist. Ich greife halt langsam nach Strohhalmen. Nie wieder kaufe ich etwas so besch***en dokumentiertes wie diesen Pelletofen von Wamsler. Andere Hersteller bekommen es im selben Preissegment hin eine Doku rauszugeben, nur die Jungs nicht.
Was möchtest du denn überhaupt erreichen? Was ist deine Motivation dahinter das Protokoll zu analysieren?
Ich habe noch nie ein Elektrogerät gehabt, bei dem die Funktion der Fernbedienung dokumentiert gewesen wäre... Frag doch mal frech bei Wamsler nach...
Meine Motivation ist, den Pelletofen über einen Mikrocontroller ein und auszuschalten - gern mit etwas mit Internetzugang. Das Problem ist: -Wamsler gibt keine Datenblätter raus. Gar nix. -Nach meiner Recherche ist alles "innen" im Ofen zugekauft von der Firma Duepi aus Italien. Die geben auch auf Nachfrage keine Infos raus. Der Ofen hat 2 Nutzerschnittstellen: 1) einen IR Empfänger für die Fernbedienung 2) eine Serielle TTL-Schnittstelle, über die der Hersteller ein "WiFi"-Modul anbindet. Das würde ich ja glatt so nehmen wie es ist, wenn es nicht unverantwortlich unsicher programmiert wäre oder sagen wir zumindest ein CE-Zeichen hätte. Ich habe versucht mittels der TTL-Schnittstelle und dem WiFi-Modul zu "lauschen", was an Daten durch die Schnittstelle huscht, aber ich bin ernsthaft daran gescheitert, die ausgelesenen Daten zu interpretieren. Ich habe über Umwege erfahren, dass der Steuerung des Ofens alles in einer Art Registern speichert, die ich sogar über das 4-Stellige LED-Display aufrufen kann - aber ich finde keinerlei Dokumentation, welcher Paramter was tut. Der (wirklich freundliche) Herr vom Wamsler Kunderservice konnte mir zwar verraten, wie man die Service-Zeit abruft, aber mehr wollte er dann doch nicht verraten. Das Ding hat mindestens 5 Haupmenus mit je einer zweistelligen Zahl Paramter. Aber alles undokumentiert.
Pellkartoffel schrieb: > Was möchtest du denn überhaupt erreichen? Was ist deine Motivation > dahinter das Protokoll zu analysieren? Das frag ich mich auch. Eine zweite FB zu programmieren ist doch heute kein Hexenwerk.
>Art Registern speichert >mit je einer zweistelligen Zahl Paramter Vielleicht Modbus Protokoll ansosten Herstellerspezifisch.
Hallo, soweit ich das sehen kann bietet die Firma "DUEPI" jede Unterstützung für Android Handys und ihre System EVO, V8 und V8RE. Allerdings das Ganze halt nur in italienischer Sprache und auch nur auf einer italienischsprachigen WEBSITE. https://www.duepigroup.com/prodotti-duepi/mydpremote-app-iphone-android/ Hast du eines der drei Versionen ? Gruss
Versuch das doch Mechanisch. Kleine Hubmagnete mit Ardu oder esp32 (hat schon WLan an Board) ansteuern. Die drücken dann auf der FB die passenden Tasten. Gruß WAM
:
Bearbeitet durch User
Du könntest auch die FB "opfern" und an die Leiterbahnen der Tasten direkt digitale Analogschalter hängen (ala CD4066) und diese dann per Arduino oder was auch immer steuern. Dann liegt die Masse der FB auch auf der Masse Deiner Arduino-Steuerung, aber das ist in diesem Fall ja garkein Problem. Aber wie soll die FB denn eigentlich immer die aktuelle Zeit übermitteln? Sie hat doch weder eine extra Pufferung für eine RTC noch einen typischen Uhrenquarz (32KHz o.ä.). Kann ich mir daher eher nicht vorstellen.
Markus M. schrieb: > Aber wie soll die FB denn eigentlich immer die aktuelle Zeit > übermitteln? Sie hat doch weder eine extra Pufferung für eine RTC noch > einen typischen Uhrenquarz (32KHz o.ä.). Kann ich mir daher eher nicht > vorstellen. Da ist doch ein Quarz (X1) ? Und bei jedem Neustart die Uhrzeit eingeben. Rest ist im Chip. Gruß WAM
Markus M. schrieb: > Aber wie soll die FB denn eigentlich immer die aktuelle Zeit > übermitteln? Sie hat doch weder eine extra Pufferung für eine RTC noch > einen typischen Uhrenquarz (32KHz o.ä.). Kann ich mir daher eher nicht > vorstellen. Das wäre die erste FB, die das macht.
Ich habe eine Idee. Vermutlich wird es nicht funktionieren aber vielleicht kann ja jemand anderer meinen Denkansatz vervollständigen. Die Fernbedienung sendet die Uhrzeit wie du glaubst. Kann man die an der Fernbedienung einstellen? Ansonsten müsste die FB auch empfangen können. Nehmen wir mal an, es geht trotzdem, versuch doch mal immer die gleiche Uhrzeit einzustellen. Falls das geht, und nicht zusätzlich noch verschlüsselt wird, dann solltest du immer das gleiche Signal aussenden. Dann kannst du schonmal die Zeit rausfiltern. Der Rest sollte dann nicht mehr schwierig sein.
Das ist keine kleine Bude, die entwickeln eine Unmenge an Elektronik ! In der Gegend von Vicenza sind sehr viele schlaue Köpfe am Werk. Warum sollten die ihre Geheimnisse gerade Dir übermitteln ? Entweder Du bist kein guter Hacker oder das Produkt ist sehr GUT !
pascalts schrieb: > S: Ich habe auch schon diese Arduino-Scetches zum Identifizieren von > "bekannten" IR-Protokollen getestet. Kommt nur Nonsens raus. Hast du einen Logicanalyzer oder etwas ähnliches, das du an einen IR Empfänger anschließen kannst? Mit einem File, in dem einige der Kommunikationsframes aufgezeichnet sind, kann vielleicht jemand im Forum sagen, wie es aufgebaut ist.
pascalts schrieb: > Meine Motivation ist, den Pelletofen über einen Mikrocontroller ein und > auszuschalten - gern mit etwas mit Internetzugang. Da wäre doch der einfachste Versuch, das Signal mit einer lernfähigen Fernbedienung aufzuzeichnen und wieder abzuspielen. Nicht jede kann das, aber so etwas bekommt schon für rund 10 Euro. Wenn das klappt, dann kannst du das gleiche mit deiner eigenen Schaltung wiederholen. Einfach das Signal aufzeichnen und später wieder abspielen. Wenn das nicht klappt, hat sich das Thema eh erledigt, weil dann nämlich ein komplexer Algorithmus dahinter steckt, den du nicht knacken kannst. Wenn du das Signal mit einem Logic Analyzer untersuchen willst, dann mache das nicht direkt an der LED sondern über einen passenden Empfänger (z.B. TSOP 31238). Der demoduliert schonmal die Trägerfrequenz in Hardware. Hinten heraus kommt ein NF-Signal mit top sauberen Logikpegeln, die Signalfrequenz liegt typischerweise im Bereich zwischen 1 und 5 kHz.
Michael D. schrieb: > Ansonsten müsste die FB auch empfangen können. Die kann nicht empfangen, da ist nur eine IR-Sendediode drin, Antennen sehe ich keine.
Oder du stellst Mal die Daten hier rein die über die serielle Schnittstelle gehen. Am besten getrennt nach Frames. Vielleicht kann jemand was mit dem Protokoll anfangen.
Moin! Erstnal sorry, dass ich mich nicht gemeldet habe - es ist beruflich heiß gerade. Ich versuche dennoch allen zu antworten: @Stefan: Die App geht nur mit dem WLAN-Modul. Jenes kommuniziert folgendesmaßen: [Ofen] <-- Seriell TTL --> [WiFi-Modul] <-- Internet --> [DuepiServer] <-- Internet --> [AndroidApp]. Das ganze ist zwar https Verschlüsselt, aber die Registrierung erfolgt durch eine leicht erratbare Hardware ID ohne E-Mail, Passort oder andere Nutzerdaten. Serielle Daten kann ich in Kürze mal zur Verfügung stellen. @ Werner W., @ Markus M.: Die Fernbedienung möchte ich (noch) nicht opfern... Esp-Reihe kenne ich gut. @Markus M.: Ja, ich muss nach dem Einlegen der Batterien die Uhrzeit in die FB eingeben. Wenn ich dann einen Timer programmiere und dem Ofen per IR übermittle, dann dem Ofen den Strom wegnehme, ist die Timerprogrammierung auch weg, bis ich sie erneut per Fernbedinung übermittle. Ergo: 2 Zeitchips, einer in der FB, einer im Ofen. @ Michael D.: Ja, die Zeit muss ich an der FB einstellen. Mehrzach die selbe Zeit übermitteln um an die IR Daten zu kommen könnte gehen... @ im Kellerloch: Schon mal was von "Security durch obscurity" gehört? @M. H. Ich habe mit meinem (sehr einfachen) Logic Analyzer mal was aufgezeichnet und angehängt! @ Stefan F.: Aufzeichen + abspielen geht wegen der aktuellen Uhrzeit nicht! Aber einen TSOP 31238 besorge ich mir. Ich habe gestern einen Tipp bekommen von jemand, der mal bei Wamsler gearbeitet hat. Der hatte immerhin schon mal eine Technische Anleitung. Die sagt zwar absolut nichts zur Fernbedienung, aber eine Parameterliste liegt bei. Ich muss aber noch abklären, ob ich das einfach veröffentlichen kann... Im Anhang: Mitschnitt Seriell (.logicdata) Mitschnitt IR (.logicdata + .mat) Eventuell kann jemand was damit anfangen.
auch und @im Kellerloch: Nein, ich bin kein guter Hacker. Aber irgendwann muss man mal anfangen, oder?
pascalts schrieb: > Eventuell kann jemand was damit anfangen. Mit diesem Dateiformat kann ich nichts anfangen. Selbst wenn du das Signal grafisch aufbereiten würdest, ich kann die Matrix nicht lesen. Frage mal Morpheus oder Neo.
Angehängte Dateien:
Der IR-Signalverlauf sieht doch gar nicht so schlecht aus. Nach einer Sync-Phase nur noch kurze Impulse oder lange Impulse mit 3-facher Länge. Das eine wird als 0, das andere als 1 interpretiert werden. Müßtest mal mehrere Tasten nacheinander drücken und aufschreiben, um zu sehen, welche Bits sich ändern. Auch gleiche Taste zu verschiedenen Uhrzeiten müßte dann ja ein Hinweis darauf geben, wo die Uhrzeit gesendet wird.
Das Problem ist, die Fernbedieung funktioniert nicht, wie man es von einer normales Fernbedienung her kennt, wo bei jedem Tastendruck was gesendet wird. Man stellt alle Parameter ein (die Fernbedieung hat ein Display!) und am Ende drückt man "send" und alles wird in einem Rutsch übermittelt. So einen "Rutsch" habe ich oben angehängt. Die Daten wurden mit "saleae Logic" erzeugt. Die Software ist kostenlos: https://www.saleae.com/de/downloads/
Ich glaube nicht, das sie die Uhrzeit sendet, denn dafür müsste sie eine Uhr haben die sich zudem nach einem Batteriewechsel automatisch neu einstellt. Gleiches gitl für den Empfänger. "Rolling Code" ist hier wohl eher das Zauberwort zum Googeln.
pascalts schrieb: > Das Ding hat mindestens 5 > Haupmenus mit je einer zweistelligen Zahl Paramter. Aber alles > undokumentiert. Und das ist wahrscheinlich auch gut so. Wer weiß was für Sicherheitsrelevante Dinge Du sonst anstellen könntest. Später war es dann der furchtbare Wamser Ofen Der all diese Menschen auf dem Gewissen hat ... In Deinem Fall, würde ich mir eine zweite FB besorgen und mit einer MCU Deiner Wahl direkt die Tastenmatrix betütern. Das ist meist der deutlich schnellere Weg. Was ist Denn an dem WiFi Modul und der TTL so furchtbar skandalös? Und was hat das CE Zeichen damit zu schaffen?
Angehängte Dateien:
-
temp_fb.PNG
160 KB
Doch, die Fernbedienung hat zu 100% sicher eine Uhr. und ja, die muss ich jedes mal einstellen, wenn die Batterien raus waren. Hier ein Bild der Fernbedienung: https://media.bahag.cloud/m/695970/12.jpg Im Anhang ein Ausschnitt der Bedienungsanleitung. Rolling Code schaue ich mir mal an.
mkn schrieb: > Was ist Denn an dem WiFi Modul und der TTL so furchtbar skandalös? > Und was hat das CE Zeichen damit zu schaffen? Also: Um eine Verbindung zu dem Modul und somit zum Ofen herzustellen, muss ich mich auf der Seite von Duepi registrieren. Dabei gebe ich meine E-Mail und eine Hardware-ID ein (5-Stellig, Großbuchstaben + Zahlen). Dann kann ich - ohne jegliche weitere Schritte, wie die Konfiguration von Passwort oder Zugangsdaten - sofort mit der App diesen ofen Steuern. Kennt jemand diese Hardware-ID meines Ofens, kann er meinen Ofen steuern. Kenne ich die ID eines anderen Ofens, kann ich seinen Steuern, weil keinerlei Überprüfung stattfindet, ob das mein Ofen ist, den ich da steuere. Gebe ich eine "falsche" ID ein, bekomme ich eine Fehlermeldung, gebe ich eine korrekte ein, kann ich einen weiteren ofen registrieren. Jeder der mit CURL + bash ein script bauen kann, kann also testen, welche Hardware-IDs valide sind und somit all diese Öfen steuern. Das ist scheiße und sowas will ich nicht in meinem haus haben. Warum ich so angepisst bin wegen dem CE-Zeichen? Alle in der EU in Umlauf gebrachten Produkte, müssen die Maschinenrichtlinie erfüllen, sofern diese für das Produkt zutrifft. Bei einem elektr. Gerät ist das definitiv der Fall - es muss also CE-konform sein. Ohne CE-Kennzeichnung auf dem Produkt oder der Verpackung, darf es nicht verkauft werden. Habe ich einsolches Produkt im haushalt und deswegen fackelt meine Bude ab, möchte ich das nciht meiner Versicherung erklären.
pascalts schrieb: > die muss ich jedes mal einstellen, wenn die Batterien raus waren. Interessant, so eine Fernbedienung habe ich noch nie gesehen.
Stefan ⛄ F. schrieb: > Interessant, so eine Fernbedienung habe ich noch nie gesehen. Wenn es eine normale gewesen wäre, würde ich hier nicht schreiben :-D
HolgerT schrieb: > Nach einer > Sync-Phase nur noch kurze Impulse oder lange Impulse mit 3-facher Länge. > Das eine wird als 0, das andere als 1 interpretiert werden. dann wäre das entweder 110000100000111110100100101100000011100001000011000100010001011000001110 oder 001111011111000001011011010011111100011110111100111011101110100111110001 also C20FA4B0384311160E oder 3DF05B4FC7BCEEE9F1 Woebei C20FA4B0384311160E immerhin schon mal eine 20 drin hat, 20°C hatte ich als Ziel-Temperatur eingestellt.
pascalts schrieb: > Woebei C20FA4B0384311160E immerhin schon mal eine 20 drin hat, 20°C > hatte ich als Ziel-Temperatur eingestellt. 20°C wird aber wohl kaum 20 in hexadezimal sein.
michael_ schrieb: > Das wäre die erste FB, die das macht. Ganz sicher nicht. Ich habe z.B. FBs für Videorecorder von Sharp und von Sony aus den späten 80ern bzw. den frühen 90ern, die das ebenfalls tun. Du hast absolut keine Ahnung. Viel zu jung, viel zu unerfahren. Aber schon die große Klappe. Du gehst garantiert in's Management, für technische Beschäftigungen hast du nicht die nötigen Skills...
HolgerT schrieb: > Der IR-Signalverlauf sieht doch gar nicht so schlecht aus. Nach einer > Sync-Phase nur noch kurze Impulse oder lange Impulse mit 3-facher Länge. So isses, der PHY ist trivialer Standard-Kram. > Müßtest mal > mehrere Tasten nacheinander drücken und aufschreiben, um zu sehen, > welche Bits sich ändern. Bei der beschriebenen Funktionsweise der FB dürfte das nix nützen. Was etwas nützen würde wäre: mache dieselben Einstellungen zweimal hintereinander und zeichne beide Inkarnationen der resultierenden IR-Kommunikation auf. Wenn identisch, dann wird's relativ einfach. Ansonsten leider beliebig komplizert. Dann könnte sogar starke Verschlüsselung im Spiel sein, was die Sache praktisch fast hoffnungslos machen würde.
Hallo, dein Mitschnitt sieht aus, wie ein Pulsdistanzprotokoll. Am Anfang kommt ein "Startbit" (längerer Puls, längere Pause), danach die Nutzdaten. Ein Nutzdatenbit besteht immer aus einem Puls (hier feste Länge) und einer Pause (über die Länge wird 0 / 1 kodiert). Die Pulse sind die Low- die Pausen die High-Pegel, so wie es aus einem TSOP etc. rauskommt, nehme ich an. Bei diesen Protokollen ist die Bitanzahl (respektive Anzahl der Pulse und Pausen) in der Regel konstant. Das kannst du ja mal ermitteln, und wenn dem so ist, dann wird das ganze schonmal etwas einfacher. Bei den gängigen Protokollen sind die ersten Bits "konstant", d.h. Adressbits / ID-Bits etc. Das wäre schon mal eine Erleichterung. Der erste Schritt, um der Lösung näher zu kommen, wäre ein Programm, das dir einen solchen Frame dekodiert (Startbit erkennen und danach die Nutzdatenbits empfangen, abspeichern und anzeigen). Die Timings von: - Startpuls - Startpause - Nutzdatenpuls - Nutzdatenpause "kurz" - Nutzdatenpause "lang" Kannst du ja deinem Mitschnitt entnehmen. Bei der Auswertung musst die hier aber eine gewisse Toleranz zulassen, z.B. +-200 us. Ich denke, IRMP lässt sich dahingehend ganz gut verbiegen - du musst lediglich die protokollspezifischen Timings anpassen. Eine Statemachine dafür selbst zu programmieren ist aber auch kein großes Drama. Habe ich letztens auch gemacht (mit 10 kHz-Polling), allerdings in AVR-Assembler auf nem Tiny13 die sah grob wie folgt aus: 0: Sendepause abpassen (es muss eine gewisse Zeit, z.B. 20 ms "Ruhe" herrschen 1: Warte auf Startpuls 2: Startpuls erkennen (festes Timing) 3: Startpause erkennen (festes Timing) 4: Datenpuls erkennen (festes Timing) 5: Datenpause erkennen (Pausenlänge kodiert 0 / 1) Wenn alles passt, hast du beim Empfang die Zustandsfolge 0,1,2,3,4,5,4,5,4,5 usw. In der Zustandsübergängen habe ich dann eine Validierung (Vergleich der Puls / Pausendauer mit einem Toleranzfenster) gemacht. Wenn hier was nicht stimmt, habe ich die Statemachine zurück in den Zustand 0 versetzt. Das gleiche habe ich in den Zuständen selbst gemacht, wenn die maximal zu erwartende Puls- oder Pausendauer überschritten wird. Beim Übergang von Zustand 5 zu 4 passiert die Erkennung / Speicherung, ob gerade eine Null oder Eins empfangen wurde. Gleichzeitig habe ich mir die Anzahl der empfangenen Bits inkrementiert. Nach dem letzten Puls des Frames kommt dann logischerweise eine "sehr lange" Pause. Wenn dir also Zustand 5 in den Timeout läuft, kannst du prüfen, ob du die richtige Anzahl Bits erhalten hast (falls sie konstant ist...) Den empfangenen Nutzdatenstrom würde ich mir Dann byteweise dezimal/hexadezimal anzeigen lassen. Wenn das Ganze läuft, dann kannst du mit der eigentlichen "Dechiffrierung" anfangen. Wie schon vorgeschlagen, mehrfach hintereinander die gleichen Einstellungen eingeben und senden --> wenn sich hier etwas ändert, dann hast du die Position der "Uhrzeitbits" gefunden. Hier macht es ggf. auch Sinn, sich die aktuelle Uhrzeit der Fernbedienung mit zu notieren, mit etwas Glück ist sie unverschlüsselt in einer logischen Reihenfolge im Frame enthalten. Was wahrscheinlich noch hinzukommt: Je nachdem, wie viele Parameter / Bits übertragen werden müssen, kann es sein, dass die Fernbedienung das ganze auf mehrere Frames aufteilt - das wird dann schon etwas "ekliger". Kannst du mal schreiben, was du für Parameter einstellen kannst (und in welchem Wertebereich)? Daraus ließe sich abschätzen, ob das Gerät derlei Schweinereien betreibt. Wenn du Pech hast, werden die Datenbits nochmal irgendwie verschlüsselt. Worst case wäre meines Erachtens, wenn dafür die Uhrzeitbits verwendet werden. Dann, würde ich sagen, stehst du ziemlich im Regen, weil es dir quasi "alles" durcheinanderwürfelt und du Alan Turing um Rat fragen müsstest.
pascalts schrieb: > Meine Motivation ist, den Pelletofen über einen Mikrocontroller ein und > auszuschalten - gern mit etwas mit Internetzugang. > > ... Wenn es nur darum geht, die Heizfunktion fern zu steuern gibt es doch einfachere Möglichkeiten als die Benutzeroberfläche nachzubauen. Wie sehen denn die Eingänge der Thermostate aus? Evtl ist es einfacher, den Termofühler zu manipulieren um die gewünschte Heizleistung zum gewünschten Termin abzurufen. Manche Heizkessel haben ein einfaches Relais, was über einen Schließer den Befehl "Heizen!" setzt. Dort kann man einfach eins parallel drüber setzen und nach Belieben ansteuern.
die Versicherung muss so oder so zahlen wenn dein Haus abbrennt, Sie wird aber aufgrund des Produkthaftungsgesetzt, probieren sich etwas vom Hersteller zu holen und wenn da ein CE Zeichen gefehlt hat ist das auch nicht dein Problem.
Angehängte Dateien:
-
schaltplan.PNG
140 KB
Vielen Dank für die letzten 3 Beiträge, ihr habt mir geholfen das Problem besser zu verstehen. @c-hater: Das mit 2 mal das selbe Senden sollte gehen, wenn ich 2 mal innhalb einer Minute sende. Ich werde aufzeichen und berichten. @Patrick: Ob meine Fähigkeiten ausreichen, IRMP zu missbrauchen für diese Analyse, weiß ich noch nicht... Aber es wäre wohl die Arbeit wert. Ich kann aber jetzt bereits sagen: Es gibt nur 1 Frame! Ob das aber alle Daten übermittelt, oder venetuell die Änderungen zum letzten, das gilt es noch herauszufinden. @Roland E.: Ja, so hätte ich das gern gehabt. Der Vorgänger der Steuerplatine hatte einen einfachen Ein/Aus-Kontakt. Hat man den auf Masse gezogen, ging der Ofen an, hat man den Kontakt hochohmig gesetzt, ging der Ofen aus. Leider wurde meines wissens nach dieser Kontakt bei meiner Platine weggespart, weil man ja jetzt über die proprietären Protokolle via TTY alles machen kann. Die werben auf Ihrer Internetseite ja mit "GSM, WiFi und MBus"-Adaptern. Der Thermofühler ist ein PT10000. Dumm nur: Selbst wenn der 0°C anzeigt, geht der Ofen nicht an, und bei 40°C nicht aus, denn ein aus geht nur per Timer oder Direkt per Taste auf der Steuereinheit (die ich aber leider nicht anzapfen kann, ohne das Display kaputt zu machen da verklebt). //EDIT: Der Schaltplan des Ofens ist im Anhang.
Angehängte Dateien:
-
schaltplan_2_detail.PNG
28 KB
Ich muss meinen letzten Absatz eventuell korrigieren. Ich ahbe gerade durch Zufall auf einer (italienischen?) Website einen anderen Schaltplan meiner Steuereinheit gefunden: https://image.forumcommunity.it/8/7/4/5/2/5/4/1448184076.png In meinem Schaltplan ist zwischen den 3 Pins für den Encoder und den Raumtemperaturfühler ein nicht benutzer Pin. In dem anderen Schaltplan ist da etwas, das der weggesparte externe Steuereingang sein könnte...
pascalts schrieb: > Ich muss meinen letzten Absatz eventuell korrigieren. Ich ahbe gerade > durch Zufall auf einer (italienischen?) Website einen anderen Schaltplan > meiner Steuereinheit gefunden: > > https://image.forumcommunity.it/8/7/4/5/2/5/4/1448184076.png > > In meinem Schaltplan ist zwischen den 3 Pins für den Encoder und den > Raumtemperaturfühler ein nicht benutzer Pin. In dem anderen Schaltplan > ist da etwas, das der weggesparte externe Steuereingang sein könnte... 1. Das. 2. Wäre auch interessant mal zu sehen, was auf dem Flachbandkabel zum Benutzerinterface so alles drauf ist. Ich habe die EN298 nicht mehr im Kopf, aber es kann sein, dass "Feuerung ein" noch immer per Relais gesetzt werden muss. Dann wäre dort drin auch eines, welches man mittels Zwischenkabel "verodern" könnte. PS:Natürlich wäre es cool, die originale FB zu ersetzen um die vorhandene Hardware ohne Änderungen zu betreiben. Halte ich aber für sehr umfangreich. Ich schätze mal ein Mannjahr geht da drauf.
:
Bearbeitet durch User
Ja, ich glaube auch, dass ich mit der Fernbedienung gegen eine Wand von Arbeit rennen werde. Ich habe mal etwas gesucht und herausgefunden, dass bei mir eine solche Platine verbaut ist: https://www.micronovasrl.com/wp-content/uploads/2016/03/J042_1-2.jpg Dabei handelt es sich um eine "Micronova J042_1". Es gibt da wohl verschiene ausbaustufen, aber alle laufen, wie man schön in der Ecke sehen kann, mit einem ATMEGA32A. Interessant ist der Connector oben links. "I3" dürfte der nicht benutze Eingang sein, der als externes Thermostat verwendet werden kann. Am liebsten wäre mir jetzt, wenn ich diesen Steckertyp herausfinden könnte, um ohne invasive Dinge da einen Adapter zu bauen um mein persönliches externes "Thermostat", also z.B. einen ESP32 + Temperaturfühler ranzusetzen. Kennt jemand diesen Steckkontakt? Wenn ich ganz mutig bin, lege ich den pin heute Abend mal auf Masse, mit einer utraflinken Sicherung in Reihe. Wenn der Ofen dann angeht, war ja die Ganze aufregung hier "umsonst" :-D
Ich muss mal dumm fragen: Die EN298 gilt doch nur für gasförmige und flüssige Brennstoffe, oder? Also fallen Pellets da ja raus, oder sehe ich das falsch?
Angehängte Dateien:
-
sum.jpg
61 KB
Okay, also der Pin war ein Reinfall. Wenn ich den auf Masse lege passiert: Nix. Aber ich habe mal 3 Messungen mit dem Logic analyzer hintereinander gemacht. Die sind identisch. (siehe Bild) Die Einstellungen zu dem Zeitpunkt waren: -Ofen aus -Zeit ca 16:56 Uhr -Timer 1 6:30 bis 11:00 -Timer 2 19:00 bis 21:50 -Temperatur 21°C -Lüfterstufe 4/5 -Auto-Modus aktiv Aber: Das Telegramm ändert sich nach ca 1 min. Ich werde mal über mehrere Minuten je 1 Telegram aufnehmen. Dann sollte man die Zeit erkennen.
:
Bearbeitet durch User
c-hater schrieb: >> Das wäre die erste FB, die das macht. > > Ganz sicher nicht. Ich habe z.B. FBs für Videorecorder von Sharp und von > Sony aus den späten 80ern bzw. den frühen 90ern, die das ebenfalls tun. Medions einfache Saugbots habe auch so 'ne FB mit Uhr (für die Startzeit)
Pascal T. schrieb: > Aber ich habe mal 3 Messungen mit dem Logic analyzer hintereinander > gemacht. Die sind identisch. (siehe Bild) > > Die Einstellungen zu dem Zeitpunkt waren: jetzt musst du nur noch die Einstellungen variieren, und das ganze dann am besten hexadezimal dekodiert hier einstellen. Ob jetzt lang oder kurz eine "1" ist, ist erstmal egal. Also z.b. alles (inkl Uhrzeit) gleich, einmal Ofen an, einmal aus. Dann mal mit verschiedenen Zeiten, verschiedenen Timern usw.. Wenn du dann noch einmal 0 bzw. 0:00 nimmst, und dann mal eine Minute, eine Stunde mehr und vllt. nochmal mit dem maximalen Wert, sollte das recht schnell erkennbar sein.
Hallo, da ich heute eh nichts zu tun habe, habe ich mich mal drangesetzt, die beschriebene Statemachine mal in C zu verfassen. Das Ganze ist mehr oder weniger (eher mehr..) quick and dirty und man könnte meinen, dass ich gerne lange italienische Teigwaren zu mir nehme - dem ist wirklich so. Die Routine "interrupt()" muss in einer festen Frequenz aufgerufen werden, (10 kHz sollten in deinem Fall reichen). Über die globale volatile-Variable "update" erfolgt die Kommunikation mit deiner main-Schleife - Es werden fünf Fehlerflags als Debugmöglichkeit zur Timingeinstellung gesetzt sowie ein Timeoutflag, das bei Korrekter Timing-Einstellung das Ende des Frames signalisiert. Diese Flags werden von der Routine lediglich gesetzt, d.h. nach Auswertung in der main müssen sie wieder rückgesetzt werden. Als Debug-Möglichkeit werden auch die Puls- und Pausendauern des Telegramms mitgeschrieben - das frisst einen Haufen RAM, hat mir aber zur Findung des Timings enorm geholfen. Ich habe mit dieser Statemachine mehrere IR-Fernbedienungen "geknackt". Vorgehensweise ist die folgende: - Timings auf "friss alles was zu kriegst" stellen, bei den Pausendauern für null und eins einen großen Bereich, aber ohne Überlappung einstellen - Bitanzahl etwas höher als die Anzahl der Nutzdatenbits stellen (z.B. 100) Mit dieser Einstellung wird die Statemachine bis zum Timeout "durchrennen". Wenn das Timeout-Flag in "update" gesetzt ist, können die Puls / und Pausendauern aus den Arrays gelesen und (wie auch immer, LCD, UART...) zur Anzeige gebracht werden. Gleiches gilt für "bitzaehler" (der sollte konstant sein). Man muss auch nicht alle Dauern anzeigen, es reichen Startbit und ein paar Einsen / Nullen aus den Nutzdaten. Die hier ermittelten Werte (ggf. noch ein bisschen Toleranz draufpacken) dann für die Timingdefinitionen nutzen. Wenn man zu "eng" rangeht, bricht die Statemachine ab und setzt ein entspr. Fehlerbit. Mit dem eingestellten Timing kann dann der Empfangspuffer angezeigt werden. Die Main sollte das ganze abgewickelt haben, bevor der nächste Frame kommt, sonst werden die ersten Arrayelemente wieder überschrieben. Ich habe das ganze so gelöst, dass die Interruptroutine nur dann aufgerufen wird, wenn die Main fertig ist (also update wieder null ist). Wenn das Timing eingestellt ist, kann man die Anzeige auf das Array "empfangspuffer" umstellen. Dabei nur soviele Bytes anzeigen, wie die Anzahl der empfangenen Bits hergibt, da in den hinteren Elementen "irgendein Unfug" steht (es wird immer nur das "angerissene" Arrayelement initialisiert).
Ich sehe einen auf 72 Bits aufgeblasenen NEC-Code: https://www.mikrocontroller.net/articles/IRMP#NEC_.2B_extended_NEC
So. Ich hab jetzt mal die Temperatur variiert, kann aber nicht garantieren, dass die Uhrzeit währenddessen umgeswitcht ist.
1 | 1111 0011 0000 1110 0011 0011 0101 1000 1001 1000 1010 1101 0001 0010 0001 0110 1111 1011 --> 21°C |
2 | 1111 0011 0000 1111 0011 0011 0101 1000 1001 1000 1010 1101 0001 0010 0001 0110 1111 1010 --> 22°C |
3 | 1111 0011 0001 0000 0011 0011 0101 1000 1001 1000 1010 1101 0001 0010 0001 0110 1111 1000 --> 23°C |
4 | 1111 0011 0001 0001 0011 0011 0101 1000 1001 1000 1010 1101 0001 0010 0001 0110 1111 0111 --> 24°C |
5 | 1111 0011 0001 0010 0011 0011 0101 1000 1001 1000 1010 1101 0001 0010 0001 0110 1111 0110 --> 25°C |
Schön schon mal, dass alle Telegramme wirklich gleich lang sind. Es ändert sich immer nur die 2. und 3. vier Bit sowie das letzte Set von 4 Bit. Vermutung: In den 2. und 3. vier Bit steht die Solltemperatur, die letzten 4 sind ne Checksumme oder Parity oder sowas. Der Wertebereich für die Temperatur ist 7 ... 40°C. 1110bin ist 14dec. 14+7 = 21! Überprüfung: 00010010bin ist 18dec. 18+7 = 25. Ich danke ich habe die Temperatur im Telegramm gefunden. Übrigens: Lang = 1 und Kurz = 0 //EDIT Uhrzeit:
1 | 1111 0011 0000 1110 0011 0011 0101 1000 1001 1000 1010 1101 0001 0010 0001 0110 1111 1011 |
2 | [ 18] [ 22] |
3 | 1111 0011 0000 1110 0011 0011 0101 1000 1001 1000 1010 1101 0001 0010 0011 0101 1111 1010 |
4 | [ 18] [ 53] |
:
Bearbeitet durch User
Das letzte Nibble (4 bit) scheint das Zweierkomplement der Summe der Nibbles davor zu sein -- zumindest bei 21° und bei 25° stimmts. LG, Sebastian
pascalts schrieb: > Das Problem ist: > -Wamsler gibt keine Datenblätter raus. Gar nix. > -Nach meiner Recherche ist alles "innen" im Ofen zugekauft von der Firma > Duepi aus Italien. Die geben auch auf Nachfrage keine Infos raus. Das schreit förmlich nach reverse-engeneering und veröffentlichung als open-source arduino-projekt
Marc H. schrieb: > pascalts schrieb: > >> Das Problem ist: >> -Wamsler gibt keine Datenblätter raus. Gar nix. >> -Nach meiner Recherche ist alles "innen" im Ofen zugekauft von der Firma >> Duepi aus Italien. Die geben auch auf Nachfrage keine Infos raus. > > Das schreit förmlich nach reverse-engeneering und veröffentlichung als > open-source arduino-projekt :-D Das repo ist schon in Arbeit! Mittlerweile habe ich An/Aus (nur 1 Bit), Gebläsestufe (1 Nibble) und Uhrzeit (2 Byte) decodiert. Der Rest ist in Arbeit, aber halt Fleißarbeit.
Angehängte Dateien:
-
id_decoder_wamsler.PNG
43 KB
Okay, ich habe jetzt alle mir bekannten Funktionen der Fernbedienung durch und fast alle Bits erklärt im Telegramm. Mehr Funktionen hat meine Fernbedienung aber nicht, die mit den übrigen Bits zu erklären wären. Eventuell für ein Modell mit anderen / mehr Funktionen reserviert. Die Excel als Decoder habe ich mal angehängt. Könnt ihr mir bitte noch abschließend helfen, wie ich die letzen 4 Bit berechne, also diese Prüfsumme? Gruß Pascal PS: Es hat sich wieder mal bewahrheitet, dass dieses Forum ein wahrer Wissenschatz ist. Danke, danke, dannke! PPS: Hier baue ich das Repo: https://github.com/pascaltippelt/Wamsler-IR-Remote
:
Bearbeitet durch User
Vielleicht so: Summe aller Nibbles ohne Überlauf muss 15 (bzw. 0xF) ergeben.
Ich muss zugeben, dass ich das nicht ganz verstehe - wie meinst du das? Ich werde das Thema wohl in einen neuen Thread verschieben, aber damit ihr mal wisst, wie es weitergeht: Ich werde jetzt das Protokoll erstmal per "bit-banging" in einen 32u4 + IR-Sendediode basteln, ob zu sehen, wie der Ofen meine Bemühungen annimmt. Wenn das klappt, bekommt ein ESP32 einen IR Sender + Reciver. Mit dem Reciver nehme ich immer den aktuellen Einstellungsstand der Fernbedienung in den Speicher des ESP auf damit dann, wenn ich etwas ändere (an aus, Timer usw) der aktuelle stand bereits geladen ist. Das ganze bekommt dann eine einfache HTML-Oberfläche mit HTTP Basic auth und wird von meiner Fritzbox mit Freetz via SSH-Tunnel an meinen Webserver übergeben, damit ich die Oberfläche hinter einen HTTPS-Proxy stellen kann. So der Plan, aber bis dahin ist es noch ein paar Mannstunden hin. Zuerst gilt es noch zu verstehen, wie das letzte Nibble entsteht.
:
Bearbeitet durch User
Ich würde die Fernbedienung als Ersatzteil kaufen und die Tasten dann ferngesteuert schließen.
Marcuz schrieb: > Ich würde die Fernbedienung als Ersatzteil kaufen und die Tasten dann > ferngesteuert schließen. Über den Punkt bin ich lange raus - mal abgesehen davon, dass soe eine Fernbedienung 70 - 80 € kostet, ist das Protokoll doch nun recht gut dokumentiert. Und das mit den Checksummen bekomme ich auch hin.
Pascal T. schrieb: > Und das mit den Checksummen bekomme ich auch hin. Wenn du es selber hinbekommst: gut. Wenn nicht: Ein guter Hacker nimmt sicher viel mehr als diese 80 Euro für seine Dienstleistung.
Stefan ⛄ F. schrieb: > Pascal T. schrieb: >> Und das mit den Checksummen bekomme ich auch hin. > > Wenn du es selber hinbekommst: gut. > > Wenn nicht: Ein guter Hacker nimmt sicher viel mehr als diese 80 Euro > für seine Dienstleistung. Ok. Leider weiß ich nicht, wie mich deine Antwort weiterbringen soll :-) Wird aber sicher an mir liegen, da ich weder Ironie noch Anspielungen verstehe.
Sebastian W. schrieb: > Das letzte Nibble (4 bit) scheint das Zweierkomplement der Summe der > Nibbles davor zu sein -- zumindest bei 21° und bei 25° stimmts. Oops, hab mit dabei wohl jedesmal im Taschenrechner vertippt. Mario M. schrieb: > Vielleicht so: Summe aller Nibbles ohne Überlauf muss 15 (bzw. 0xF) > ergeben. DAS scheint zu stimmen. Also:
1 | uint8_t msg[9]; // Bitstrom in msg[0] (erstes bit in 0x80, achtes in 0x01) bis msg[8] |
2 | // Letztes nibble (msg[8]&0xF) soll Prüfsumme erhalten:
|
3 | uint8_t chksum = 0; |
4 | for (uint8_t i=0; i<sizeof(msg); i++) { |
5 | chksum += msg[i]>>4; |
6 | if (i<sizeof(msg)-1) { |
7 | chksum += msg[i]&0xF; |
8 | }
|
9 | }
|
10 | chksum &= 0xF; |
11 | msg[8] = (msg[8]&0xF0) | (0xF^chksum); |
Oder hab ich mich wieder vertan? LG, Sebastian
Pascal T. schrieb: > Leider weiß ich nicht, wie mich deine Antwort weiterbringen soll Was ich damit sagen wollte: Versuche es. Aber wenn abzusehen ist, dass du es nicht alleine hinbekommst, dann gebe besser auf und steuere eine reguläre Fernbedienung fern.
Ich versuche das gerade zu prüfen. Sehe ich das richtig, dass die Bits "rückwärts" in das Array müssen?
:
Bearbeitet durch User
Pascal T. schrieb: > Ich versuche das gerade zu prüfen. Sehe ich das richtig, dass die Bits > "rückwärts" in das Array müssen? Was ist vorwärts, was ist rückwärts? Wenn der Bitstrom abcdefghijklmnop ist, mit a zuerst und p zuletzt, und du diesen Bitstrom dann als abcd efgh ijkl mnop notierst (also von links nach rechts im Verlauf der Übertragungszeit), dann kann man diesen Bitstrom zum Beispiel als uint8_t msg[0] = 0babcdefgh und uint8_t msg[1] = 0bijklmnop speichern und verarbeiten (0b soll Binärdarstellung sagen). Dabei kommen also die früheren Bits im Bitstrom an die höherwertigen Bitpositionen im uint8_t. Also das erste Bit hätte die Wertigkeit 0x80 in msg[0], das zweite 0x40, das achte 0x01, das neunte landet als 0x80 in msg[1], und so weiter. Diese Art der Speicherung heisst "most significant bits first". Ich bin davon ausgegangen dass deine Telegramme oben in der Reihenfolge der Übertragung von links nach rechts notiert sind. Wenn das so ist, dann wird die Uhrzeit 18:53 zum Beispiel nur dann als msg[6] 18 (0b00010010) und msg[7] 53 (0b00110101) erscheinen, wenn du sie als most significant bit first verarbeitest. Und auch nur dann ist die Summer der Nibbles 0xF. LG, Sebastian
Ich danke euch. Gestern hat mir ein Kumpel nochmal "für dumme" erklärt, wie das mit der Methode von @thelonging funktioniert, jetzt habe ich es auch verstanden. Ich kann jetzt also die letzten 4 Bit auch berechnen und sollte ein funktionierendes Telegramm zustande bringen. Wenn meine Tage wieder etwas ruhiger werden, setze ich mich mal an die Umsetzung. Grüße!
So, ich hab den Encoder jetzt mal fix als c++-Klasse aufgebaut, die Checksummenberechnung klappt soweit, dass ich valide Telegramme bekomme. https://github.com/pascaltippelt/Wamsler-IR-Remote/tree/main/src Es ist noch keine hohe Kunst und bei weitem nicht fertig, aber ein gutes Proof-of-Concept. Mittels eines einfachen:
1 | telegram t; |
2 | t.AUTOTimer = true; |
3 | t.setBlowerLevel(3); |
4 | t.OnOff = true; |
5 | t.Turbo = false; |
6 | t.setTemperature(21); |
7 | t.setTimer1on(6, 30); |
8 | t.setTimer1off(11, 00); |
9 | t.setTimer2on(19, 00); |
10 | t.setTimer2off(21, 50); |
11 | t.setTime(20, 3); |
12 | t.timer1onActive = true; |
13 | t.timer1offActive = true; |
14 | t.timer2onActive = true; |
15 | t.timer2offActive = true; |
16 | |
17 | std::cout << t.toString(); |
...bekomme ich ein fertiges Telegramm:
1 | 111100110000111000110011010110001001100010101101000101000000001111111101 |
Das muss ich jetzt noch dem ESP beibringen - aber da die Hardware noch nicht final steht wird das etwas dauern. Nochmal danke an alle! //Closed!
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.