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...
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.
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.
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
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.
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.
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?
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.
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.
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.
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.
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?
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.
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).
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:
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.
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
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.
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_tmsg[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:
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.
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:
