Hallo, hat sich schon mal jemand den Webasto W-Bus näher angeschaut? Mit welchen Kommunikationseinstellungen wird da gearbeitet (Daten,-Start und Stoppbits, Parität und Baudrate)? Als Interface-Bausteine sehe ich auf fast allen Webasto-Platinen den L9637, also ein K-Line-Interface. Jürgen H.
:
Verschoben durch Moderator
Hallo Jürgen, hast du dahingehend schon was rausgefunden? Ich will nämlich den W-Bus per µC ansteuern. Bis jetzt habe ich noch nichts gefunden. Zu wissen, dass der W-Bus eine K-Line ist, ist schon mal ein Fortschritt. Sg, Maxx
Hallo Ich suche ebenfalls noch Infos über den W-Bus. Hast Du schon irgendwelche Infos. Danke Folli
Schaut mal hier rein - eventuell hilft´s. http://micro.homelinux.net/~mjander/webasto_beschreibung.txt Habs beim googeln gefunden. Leider ist keine Info dabei von wem die Beschreibung ist und es gilt wie immer: kein Anspruch auf Richtigkeit ! Kaipi
Hallo, ich möchte das Thema nochmal hoch holen. Ich habe einen Zuheizer aus einem T5 von 2012 mit CAN in ein anderes Fahrzeug eingebaut. Dieser funktioniert nur wenn die Sofortheiztaste an der Vorwahluhr im Abstand von 15s zweimal betätigt wird. Warum konnte ich bisher nicht herausfinden, vermutlich fehlende CAN Anbindung.? Ich habe mir nun eine GSM Fernbedienung mit einem Arduino gebaut. Dieser schaltet den Taster der Vorwahluhr. Ich suche nun eine Möglichkeit die Heizung über den W-Bus direkt anzusteuern. Die Heizung kann über den W-Bus mit einem K-line Diagnosekabel und der Webasto Software ausgelesen und gestartet werden. Dazu habe ich auf http://www.motor-talk.de/forum/webasto-can-bus-heizung-ohne-can-ansteuern-thermo-top-v-und-andere-t1622120.html?page=1 folgendes gefunden: >von Tomi0815 Wenn ich an die Heizung folgendes am Com 1 ( 2400 Baud, e, 8,1) sende : Start 1 mal : F4 03 21 3C EA --> < --- 4F 03 A1 3C D1 ( Heizung startet) alle 10 Sek : F4 04 44 21 00 95 --> <--- 03 c4 00 88 ( zur Erhaltung ) Heizung läuft hoch, brennt dann auf Volllast und regelt auch bei ca 70 °C die Leistung runter, wenn man das Wasser abkühlt regelt die Heizung wieder hoch ....Wärend Betrieb - Dosierpumpe abgesteckt -- Heizung geht auf Störung und >geht in die Kühlfase, es kommt dann <--- 4F 03 C4 FF 77 zurück und nicht 03 C4 00 88 zum Ausschalten 1 mal F4 02 10 E6 --> <--- 4F 02 90 DD > Nun frage ich mich wie der physische Aufbau ausehen müsste um einen AVR mit dem W-bus zu verbinden. Bin nur Hobbybastler...
:
Bearbeitet durch User
Hallo Tux Tux, Google mal nach Si9241A. Solch einen Pegelwandler/Transceiver musst du verbauen. Bei Fragen meld dich nochmal. Gruß, Christian
Tux Tux schrieb: > Dieser > funktioniert nur wenn die Sofortheiztaste an der Vorwahluhr im Abstand > von 15s zweimal betätigt wird. Hi, beim Suchen nach ebenso einer W-Bus Atmel Geschichte bin ich gerade auf Deinen Post gestoßen. Meine Top-V ist aus einem BMW und lässt sich über die 1533 Uhr bedienen und hat keinen Can-Bus. Das Verhalten, daß die Heizung sich (und das Sofortheizen der Uhr) manchmal nach ca 15 Sekunden ohne jegliche Fehlermeldung wieder ausschaltet kenne ich auch. Bei mir scheinbar aber nur bei tiefen Temperaturen (super im Winter... ;) ). Hast du dazu was rausfinden können? Gelöst habe ich das Problem indem ich nach 30sek über den µC prüfen und ggf. noch einmal einschalten lasse. Hast du es hingekriegt die Ein- und Ausschaltsignale direkt dem Atmel zu entlocken also ohne die hässliche Uhr? Gruß
Hallo, bei mir wiederholt die 1533 das Einschaltkommando selbstständig nach ca. 8s. So hab ich das dann auch in meine Funkfernbedienung übernommen - läuft seit 2 Jahren problemlos. Die Erzeugung/Auswerung der Busnachrichten per AVR ist kein Problem, Serielle Schnittstelle 2400 Baud 8E1. Sascha
'n Paar Bascom Schnipsel hast aber nicht zufällig noch für mich oder? ;) Ich bin da schon lange am suchen und versuchen zu verstehen, aber es fällt mir schwer und wenn über haupt, kann ich nur Bascom. Was ich (meiner Meinung nach) verstanden hab ist, ich brauch zum Beispiel am Mega8 die UART Schnittstelle. Dann über einen L9637D Treiber einen K-Bus daraus gemacht und ran ans Auto. Richtig? Ab dann fängt's an zu klemmen... :( Die folgenden Daten hab ich mir bei sourceforge zusammengesammelt und versucht zu verstehen. Stimmt das, was ich hier nachfolgend geschrieben habe? Und wie krieg ich das dann per Bascom in den µC? Ich vermute mit "SEROUT"? Und dann hab ich da noch vor der eigentlichen Kommunikation etwas von irgendwelchen "BREAKS" und 50ms gehört, um das ganze zum Leben zu erwecken, weiß mir aber dazu mit Bascom auch keinen Rat... Befehl an Heizgerät: F4 03 21 3C EA F4 = Wesbasto Thermo Test Software (F) sendet an Thermo Top V (4) 03 = ? 21 = Standheizen ein (21) für 3C = 59min (hex 3C = dez 60) EA = Checksum (XOR aus F4 03 21 3C)? Heizung antwortet: 4F 03 A1 3C D1 4F = Thermo Top V (4) antwortet an Wesbasto Thermo Test Software (F) 03= ? A1 = ? 3C = 60min (hex 3C = dez 60) D1 = Checksum (XOR aus 4F 03 A1 3C D1)? Befehl alle 10 Sek an Heizgerät(zur Erhaltung): F4 04 44 21 00 95 F4 = Wesbasto Thermo Test Software (F) sendet an Thermo Top V (4) 04 = ? 44 = ? 21 = ? Gruß Ille
Da fehlte noch ein Stück: 00 = ? 95 = Checksum??? Heizung antwortet: 03 c4 00 88???
Hi, hier: http://sourceforge.net/p/libwbus/libwbus/ci/master/tree/webasto_wbus.txt solltest du alles finden, was du brauchst... Zumindest habe ich damit meinen GSM Gateway gebaut und das klappt prima... Einzig bei ein paar Kommandos muss man aufpassen, die verstand meine Heizung nicht und hat darauf nicht geantwortet... Am einfachsten ist es, mit dem Webasto Diagnose Tool die Heizung zu starten, die Kommunikation aufzuzeichnen und dann zusammen mit der Beschreibung oben das ganze verstehen und nachbauen... Fehler auslesen usw. geht überigens auch prima und kann man sich dann schön per SMS zuschicken... ;-) Viele Grüße, Michael
Ille schrieb: > 'n Paar Bascom Schnipsel hast aber nicht zufällig noch für mich oder? ;) kein Problem - aber nur in ASM > Ich bin da schon lange am suchen und versuchen zu verstehen, aber es > fällt mir schwer und wenn über haupt, kann ich nur Bascom. hmm, eher ungünstig > Was ich (meiner Meinung nach) verstanden hab ist, ich brauch zum > Beispiel am Mega8 die UART Schnittstelle. genau > Dann über einen L9637D Treiber > einen K-Bus daraus gemacht und ran ans Auto. Richtig? so ist es, wobei es verschiedene Treiber gibt > Ab dann fängt's an zu klemmen... :( > Die folgenden Daten hab ich mir bei sourceforge zusammengesammelt und > versucht zu verstehen. > Stimmt das, was ich hier nachfolgend geschrieben habe? Und wie krieg ich > das dann per Bascom in den µC? > Ich vermute mit "SEROUT"? ja, und einlesen muss du auch was ;SERIN?? > Und dann hab ich da noch vor der eigentlichen Kommunikation etwas von > irgendwelchen "BREAKS" und 50ms gehört, um das ganze zum Leben zu > erwecken, weiß mir aber dazu mit Bascom auch keinen Rat... ein Break ist nix anderes als ein statischer Pegel an der Schnittstelle, der hier eben 50ms anliegen muss. Den erzeugst du indem du die Serielle Schnittstelle deaktivierst und den Portpin für 50ms auf Low setzt und im Anschluss die Serielle Schnittstelle wieder aktivierst (Portpin wir High) und noch mal 50ms wartest. Wie du mit jetzt mit Bascom die Konfiguration der Portpins während des Programms wieder zwischen UART oder normaler PIN-Funktion umschalten kannst weiß ich als ASM'ler auch nicht. Da auf der W-Bus/K-Line/LIN-Schnittstelle alle Busteilnehmer auf einer Leitung Senden und Empfangen, empfängst du die Daten welche du selbst sendest ebenfalls was dein Programm zur Erkennung von Kollisionen auf dem Bus benutzen sollte. Auf unterster Ebene sendest du ein Kommando und prüfst ob das was du im gleichen Moment empfängst das ist was du auch gesendet hast. Passt das, dann ist das Telegam sauber auf die Leitung gegangen. Als nächstes wartest du (mit Timeout) auf die Bestätigung des Kommandos vom Heizgerät und prüfst ob die zum gesendeten Kommando passt (CMD ist dein ges. CMD+0x80). Tritt ein Fehler auf oder wurde lange nichts gesendet machst du einen Break. > Befehl an Heizgerät: > F4 03 21 3C EA > F4 = Wesbasto Thermo Test Software (F) sendet an Thermo Top V (4) ich nehm 0x24, (2) ist der Absender der Funkfernsteuerung > 03 = ? Anzahl der Bytes die noch kommen, incl. Checksum > 21 = Standheizen ein (21) für > 3C = 59min (hex 3C = dez 60) > EA = Checksum (XOR aus F4 03 21 3C)? genau > > > Heizung antwortet: > 4F 03 A1 3C D1 ja > 4F = Thermo Top V (4) antwortet an Wesbasto Thermo Test Software (F) > 03= ? > A1 = ? in der Antwort der Heizung wird zu dem Kommando was du gesendet hast noch das Bit 7 gesetzt. 0x21 + 0x80 = 0xA1 > 3C = 60min (hex 3C = dez 60) > D1 = Checksum (XOR aus 4F 03 A1 3C D1)? > > > Befehl alle 10 Sek an Heizgerät(zur Erhaltung): > F4 04 44 21 00 95 > > F4 = Wesbasto Thermo Test Software (F) sendet an Thermo Top V (4) > 04 = ? 4 Byte > 44 = ? CMD: Check current command > 21 = ? prüfe auf Ausführung CMD 0x21 wenn du als "Absender" Adresse 2 nimmst dann wird das Einschalten der Heizung auch auf der 1533-Uhr als "Telestart Ein" angezeigt und die Heizung lässt sich mit der Uhr auch wieder aussschalten. Anbei mal noch paar Unterlagen, die ich mir aus dem Netz zusammengesucht hatte. Sascha
Wow! Vielen herzlichen Dank für Deine umfangreiche Hilfe Sascha! Ich bin grad echt verblüfft, damit hab ich echt nicht gerechnet! Toll erklärt! Jetzt bleibt mir ja gar nix anderes übrig, als das hinzukriegen! ;) Michael, auch Dir danke ich! Ihr hört von mir... LG Ille
Hallo, na dann probier mal ... Wenn du WIN verwendest hätte ich auch noch ein AutoIT3 Script, als "Webastosimulator". Hab ich mir damals geschrieben um die grundlegenden Funktionen (Ein,Aus,Statusabfrage,Sensordaten,1533-Ein/Aus) zu simulieren und mein Programm zu testen - man will/kann ja nicht nach jeder Programmänderung raus auf den Parkplatz zum Auto. Sascha
Hallo, viel Spass damit ... am besten aus dem Editor starten, da die Meldungen nur auf der Console ausgegeben werden. Am PC braucht ihr natürlich auch einen K-Line Treiber, oder auf beiden Seiten nur TTL und mit Dioden verodern. Sascha
Hallo und guten Abend zusammen! Mit großem Interesse habe ich das Thema hier grad gelesen, da ich auch irgendwie versuchen möchte, meine Standheizung über den w-bus anzusprechen. Unglücklicher Weise bin ich auch nur Bascomler, daher meine Frage an Euch bzw. Ille: Hast Du schon etwas in der Richtung mit Bascom auf die Beine gestellt? Viele Grüße Torsten
Hi Torsten, nur sehr mühsam ernährt sich das Eichhörnchen, aber es lebt... ;) Den Inhalt der Kommunikation habe ich jetzt verstanden, steht zwar bei sourceforge.net unter libwbus alles gut erklärt, dennoch hat's mim Durchblick etwas gedauert. Sascha hat mir dabei sehr geholfen (siehe oben - top erklärt)! Zum besseren Verständnis und zum Errechnen von Checksummen, hab ich mir dazu eine Excel Tabelle gebastelt, in der ich dann auch komplette Befehlspakete erstellen, reinkopieren oder rauskopieren und prüfen kann. Ich habe jetzt erstmal mehrere Terminalprogramme getestet und finde hterm ziemlich gut. Damit kann man sehr schön verfolgen, was gesendet und empfangen wird und kann selber Befehle senden und schauen, was passiert. So habe ich z.B. auch heute die Gerätenummer meiner Heizung mittels Laptop ausgelesen (als Beispiel in meiner Excel-Tabelle). Was ich noch nicht rausgefunden habe ist, wie ich mittels Terminal dieses mysteriöse "BREAK" senden könnte. Das heißt, ich kann mich nur in eine "laufende" Kommunikation einklinken. @Sascha Any idea? ;) Der Testaufbau mit dem Atmel wird dann folgen, aber auch das wird bissl dauern, da ich mich da erstmal noch genauer mit UART und Bascom befassen muss. Wenn's dazu Fortschritte von irgendwem gibt - immer her damit! :) Meine Excel-Tabelle XOR.xls ist mit einem Sub und einer function versehen, also nicht wundern, ist kein Virus! Wer will kann sie sich ja mal anschauen und seinen Senf dazgeben... ;)
Ille schrieb: > Was ich noch nicht rausgefunden habe ist, wie ich mittels Terminal > dieses mysteriöse "BREAK" senden könnte. Das ist in der Tat schwierig, eine direkte Möglichkeit im Terminalprogramm gibts nicht. Ein Break kann mann in dem Fall nur senden wenn man die Baudrate so weit runter setzt, das die 9-Bit (Startbit und 8-Datenbits) eines 00-Bytes die Zeit von 50ms erreichen. Da musst du allerdings nur mickrige 180Baud einstellen aber so wenig geht glaube ich gar nicht. Am AVR hat man es da schon einfacher. > Das heißt, ich kann mich nur in > eine "laufende" Kommunikation einklinken. nicht unbedingt - ein Break ist nicht zwingend vor Begin jeder Kommunikation erforderlich. Erst wenn sich das Steuergerät der Heizung schlafengelegt hat braucht es zwingend ein Break bevor sich mit der Kommunikation beginnen lässt. Sascha
:
Bearbeitet durch User
ein "Break" (bewusst gemachter Frame-Error) Hi Sascha, wenn ich über die Uhr das Standheizen starte, sehe ich auch diese ominöse 00 auch gekennzeichnet als Fehler. Das stützt Deine Aussage und die eines anderem irgendwo im Netz, der schrieb, daß ein BREAK ein bewusst erzeugter Frame-Error ist. Er schreibt allerdings die halbe Baudrate würde reichen. Das kann ich allerdings so nicht bestätigen. Und wie du richtig sagst, 180 Baud kann das Programm nicht. Mit "laufende Kommunikation" meinte ich, daß die Heizung noch nicht "schläft". Hin und wieder kann ich durch Senden einer 00 mit geringerer Baudrate die Kommunikation zum Leben erwecken. Allerdings passiert (wenn ich die Heizung nur über PC betreibe und die 1533-Uhr hardwaremäßig überhaupt nicht angeschlossen habe) folgendes Seltsames... So sieht's normal aus, gesteuert von der Uhr: 34 03 21 1E 08 43 03 A1 1E FF 34 04 44 21 00 55 43 03 C4 00 84 Ohne Uhr aber so: F4 03 21 1E C8 4F 03 A1 1E F3 F4 04 44 21 00 95 4F 03 C4 01 89 oder 34 03 21 1E 08 43 03 A1 1E FF 34 04 44 21 00 55 43 03 C4 01 85 In der Antwort der Heizung auf den alle 15sek gesendeten "Erhaltungsbefehl" ist das 4. Byte immer 01 statt 00. Nach einem kurzen Anlaufen des Brennluftgebläses passiert einfach nichts mehr. Darauf kann ich mir aber keinen Reim machen und finde auch nirgends eine Erklärung... :(
Ille schrieb: > ein "Break" (bewusst gemachter Frame-Error) ja, da an der Stelle wo das Stoppbit kommen müsste noch der falsche Pegel anliegt > wenn ich über die Uhr das Standheizen starte, sehe ich auch diese > ominöse 00 auch gekennzeichnet als Fehler. genau HTerm gibt bei einem Frameerror ein 0-Byte aus (rot markiert) > Das stützt Deine Aussage und die eines anderem irgendwo im Netz, der > schrieb, daß ein BREAK ein bewusst erzeugter Frame-Error ist. Er > schreibt allerdings die halbe Baudrate würde reichen. ist wohl in der Tat die allgemein gültige Definition > Das kann ich allerdings so nicht bestätigen. ich auch, in meiner Schaltung verwende ich als Treiber für den W-Bus einen MCP2003 (LIN-Bus). Nachdem das mit dem Break auch nicht so recht geklappt hat hab ich gemerkt das bei 50ms die vom Controller kamen am W-Bus nur 25ms "zu sehen" waren da der Treiber eine interne Schutzschaltung gegen statischen Pegel auf der Leitung hat (hätte man bei genauem Lesen des DB auch vorher sehen können). Hab dann noch einen Transistor extra an den W-Bus gehangen. Wer weiß wie die Heizungssteuerung geweckt wird, das die 50ms braucht. > Und wie du richtig sagst, 180 Baud kann > das Programm nicht. hab das gerade mal mit HTerm getestet, du kannst zwar keine 180Baud auswählen, aber wenn du von Hand 180 in das Feld reinschreibst und dann ein 0-Byte sendest kommt ein schöner 50ms Impuls auf der Schnittstelle raus. > Mit "laufende Kommunikation" meinte ich, daß die Heizung noch nicht > "schläft". genau > Hin und wieder kann ich durch Senden einer 00 mit geringerer Baudrate > die Kommunikation zum Leben erwecken. > > Allerdings passiert (wenn ich die Heizung nur über PC betreibe und die > 1533-Uhr hardwaremäßig überhaupt nicht angeschlossen habe) folgendes > Seltsames... > > So sieht's normal aus, gesteuert von der Uhr: > > 34 03 21 1E 08 > 43 03 A1 1E FF > 34 04 44 21 00 55 > 43 03 C4 00 84 ok > Ohne Uhr aber so: > > F4 03 21 1E C8 > 4F 03 A1 1E F3 > F4 04 44 21 00 95 > 4F 03 C4 01 89 hmm, das 01 in der Rückmeldung wird wohl bedeuten das das Kommando nicht mehr läuft > oder > 34 03 21 1E 08 > 43 03 A1 1E FF > 34 04 44 21 00 55 > 43 03 C4 01 85 das währe doch wieder die Uhr ?! > Nach einem kurzen > Anlaufen des Brennluftgebläses passiert einfach nichts mehr. > Darauf kann ich mir aber keinen Reim machen und finde auch nirgends eine > Erklärung... :( über den PC heist jetzt mit Termimalprogramm? Oder der Webasto Software? nach dem ersten 21'er Kommando wird dieses eigentlich auch noch mal wiederholt und dann erst mit der Abfrage begonnen. Sascha
Hey, ich hoffe ich nerve nicht, versuche nur zu lernen... ;) Sascha Weber schrieb: > Hab dann noch einen Transistor extra an den > W-Bus gehangen. Hab ich mir auch schon überlegt... Verstehe ich das richtig, du gibst aus einem Pin des µC einen statischen Pegel für 50ms raus auf einen Transitor, der das dann direkt auf die K-Leitung gibt? Aber welchen, Low oder High? Also Pin µC -> Basis, Kollektor -> K-line z.B.? Sascha Weber schrieb: > aber wenn du von Hand 180 in das Feld reinschreibst und dann > ein 0-Byte sendest kommt ein schöner 50ms Impuls auf der Schnittstelle > raus. Das misst du mim Oszi? Sascha Weber schrieb: > das währe doch wieder die Uhr ?! Hab ich so aus hterm gesendet... Sascha Weber schrieb: > über den PC heist jetzt mit Termimalprogramm? Oder der Webasto Software? Über PC heißt hterm. Mit der Webasto Software läuft das alles rund. Nur weiß ich ja nicht was die macht, weil der virtuelle COM Port ja entweder von der Webasto Software oder hterm benutzt wird. Beides gleichzeitig geht nicht. Sascha Weber schrieb: > nach dem ersten 21'er Kommando wird dieses eigentlich auch noch mal > wiederholt und dann erst mit der Abfrage begonnen. Sascha Weber schrieb: > nach dem ersten 21'er Kommando wird dieses eigentlich auch noch mal > wiederholt und dann erst mit der Abfrage begonnen. Also meine Uhr sendet das 21er Kommando unter Umständen bis zu 5mal bis die Heizung antwortet. Wenn sie reagiert, geht's sofort mit dem 44er weiter.
Ille schrieb: > Hey, ich hoffe ich nerve nicht, versuche nur zu lernen... ;) mach nur > Sascha Weber schrieb: >> Hab dann noch einen Transistor extra an den >> W-Bus gehangen. > Hab ich mir auch schon überlegt... Verstehe ich das richtig, du gibst > aus einem Pin des µC einen statischen Pegel für 50ms raus auf einen > Transitor, der das dann direkt auf die K-Leitung gibt? Aber welchen, Low > oder High? Also Pin µC -> Basis, Kollektor -> K-line z.B.? genau, Ruhezustand der K-Line ist 12V, µC auf H, npn schaltet durch und zieht den Bus auf GND > Sascha Weber schrieb: >> aber wenn du von Hand 180 in das Feld reinschreibst und dann >> ein 0-Byte sendest kommt ein schöner 50ms Impuls auf der Schnittstelle >> raus. > Das misst du mim Oszi? Soundkarte > Sascha Weber schrieb: >> das währe doch wieder die Uhr ?! > Hab ich so aus hterm gesendet... ok > Sascha Weber schrieb: >> über den PC heist jetzt mit Termimalprogramm? Oder der Webasto Software? > Über PC heißt hterm. Mit der Webasto Software läuft das alles rund. Nur > weiß ich ja nicht was die macht, weil der virtuelle COM Port ja entweder > von der Webasto Software oder hterm benutzt wird. Beides gleichzeitig > geht nicht. da gibts: http://www.heise.de/download/serial-port-monitor-1122897.html damit kann man sich 'zwischenschalten' > Sascha Weber schrieb: >> nach dem ersten 21'er Kommando wird dieses eigentlich auch noch mal >> wiederholt und dann erst mit der Abfrage begonnen. > Also meine Uhr sendet das 21er Kommando unter Umständen bis zu 5mal bis > die Heizung antwortet. Wenn sie reagiert, geht's sofort mit dem 44er > weiter. und was passiert wenn du das 21'er über hterm nach 8s noch mal wiederholst und dann mit dem 44'er weitermachst? Sascha
Du bist echt super Sascha! :) Sascha Weber schrieb: > genau, > Ruhezustand der K-Line ist 12V, µC auf H, npn schaltet durch und zieht > den Bus auf GND Ok, binsch ja doch nicht so dumm... ;) Sascha Weber schrieb: >> Das misst du mim Oszi? > Soundkarte Verrückt... :) Ich frag besser nicht weiter... Sascha Weber schrieb: > da gibts: http://www.heise.de/download/serial-port-monitor-1122897.html > damit kann man sich 'zwischenschalten' Ok, sehr interessantes Tool! Was es nicht alles gibt! Sascha Weber schrieb: > und was passiert wenn du das 21'er über hterm nach 8s noch mal > wiederholst und dann mit dem 44'er weitermachst? Werde ich prüfen... Hab aber gerade mal geprüft, was die Webasto Software macht, sie sendet auch nur einmal die 21 und 10 Sekunden später geht's mit der 44 weiter. Ich denke, ich hab jetzt eine ganze Menge Infos zusammen und werde jetzt mal versuchen mittels Atmel, UART und dem erzwungenen BREAK irgendwas der Heizung zu entlocken... Wir werden sehen... :)
Ach verdammt... :( Wenn die Kommunikation einmal läuft geht's prima (z.B. hergestellt mit Thermo Test von Webasto), ansonsten unzuverlässig bis gar nicht! Ich zieh die K-Line jetzt über einen Portpin und einen BC548 direkt auf GND für 50ms, danach 50ms Pause. Egal, was ich danach sende - keine Antwort. Im htrem zeigt's mir aber prima einen Error an, sieht aus wie von der 1533 Uhr. Ich raste hier gleich völlig aus! Was macht die Software anders als ich??? Sascha hast du noch eine Idee? Is ne Top V aus'm E90...
Entweder mit dem Mega8 oder mit hterm. Die "Breaks" kommen aber immer vom Atmel, sehen auch im hterm wunderschön rot markiert als 00 aus.
Hast du dir den Break mal mim Oszi oder nem Logicanalyzer angeguckt? Passen die Zeiten wirklich? Ansonsten: Mach den Break einfach mal länger... Der dieht ja nur dazu, das das Steuergerät aufwacht, von daher wird es das lieber länger als zu kurz sehen... ;-)
Nein, hab ich noch nicht, werd ich wohl aber demnächst machen müssen... Ob die Zeiten passen, weiß ich also nicht. Hab aber schon auf anderen Seiten gelesen, daß es da Probleme gibt. Dort wird von 25/25ms 30/45ms und anderen geschrieben. Länger hab ich noch nicht gehört, aber probiert. Bis jetzt ohne Erfolg. Die einzige, die wohl jede Heizung problemlos bedient ist die Software. Hattest du nicht gesagt, du misst die Pulslänge mit der Soundkarte? Willste mir verraten, wie? ;)
Also, das mit der Soundkarte war ich nicht, muss daher leider passen... Zu deinem eigentlichen Problem, also ich wecke meine wirklich mit 50ms/50ms... Das mit dem einfach mal verlängern ist auch nur so eine Idee gewesen - ob das wirklich was bringt, weiß ich nicht... Bei mir hat es auf anhieb funktioniert... Als Treiber nutz ich einen L9637 - der hat sich bei meinen Tests vorab mit nem K-Line Adapter und dem Webasto-Tool bewehr gehabt... Und der Code dazu wäre dann:
1 | void WBus_Wake(){
|
2 | // TX auf High setzen |
3 | PORTE |= (1<<PE1); |
4 | |
5 | // TX deaktivieren (Jetzt bekommen wir wieder die Kontrolle über den Port) |
6 | UCSR0B &= ~(1<<TXEN0); |
7 | |
8 | // TX auf Low setzen |
9 | PORTE &= ~(1<<PE1); |
10 | |
11 | // 50ms warten |
12 | _delay_ms(50); |
13 | |
14 | // TX auf High setzen |
15 | PORTE |= (1<<PE1); |
16 | |
17 | // Nochmal 50ms warten) |
18 | _delay_ms(50); |
19 | |
20 | // TX aktivieren (Jetzt wollen wir ja gleich wieder normal senden) |
21 | UCSR0B |= (1<<TXEN0); |
22 | } |
Vielleicht hilfts ja... ;-) Viele Grüße, Michael
Angehängte Dateien:
-
Plan.png
240 KB
Lieb gemeint, aber ich arbeite rein mit Basic (Bascom) mit dem Rest kenne ich mich nicht aus. Hier ein Stück aus meinem Code... Schaltung siehe Anhang... Breakport = 1 Waitms 50 Breakport = 0 Waitms 50 For X = 1 To 5 Printbin &H34 ; &H03 ; &H21 ; &H1E ; &H08 'Standheizen ein 30min Waitms 500 Next X
Angehängte Dateien:
-
W-Bus.png
2,8 KB
Hehe, das hab ich dann wohl wieder verdrängt, erklärt aber auch, warum du den Transistor da mit drin hast... Wenn ich mich recht erinnere, ist Bascom ja etwas abstrakter, was die ganzen Zugriffe angeht? Aber laufen sollte es ja so oder so... Was deine Schaltung angeht, da fehlt aber noch ein Pullup an der K-Line... 510Ohm - hab ich aus dem Schaltplan von dem K-Line Adapter, mit dem das PC-Tool lief übernommen... Das is sonn schicker Adapter von blafusel gewesen - da gibts ja zum Glück immer die Schaltpläne dazu... :-D Im Anhang auch nochmal meine Beschaltung vom L9637....
Ich wollt's noch schreiben, ist nur eine Prinzipschaltung... ;) Meine komplette Schaltung sieht exakt aus wie Deine und der Adapter scheint zumindest wunderbar zu funktionieren. Alles was ich über den Mega8 sende, sehe ich einwandfrei im htern. Nur die Heizung zickt halt rum.
Tja, dann haben wir jetzt ja alles abgeklopft - dann wäre jetzt wirklich mal interessant, in wie weit sich dein Signal von dem des PC-Tools unterscheidet... :-/
:
Bearbeitet durch User
Ille schrieb: > Hattest du nicht gesagt, du misst > die Pulslänge mit der Soundkarte? Willste mir verraten, wie? ;) Ich wars. Nimm einfach den Line-In und mach einen Spannungsteiler dran, so das die Eingangsspannung am PC nicht über 1V geht. Damit kannst du dann an die K-Line dran gehen, durch die kapazitive Kopplung der Soundkarte sehen die Flanken zwar etwas verrundet aus, aber das ist bei der Baudrate noch kein Problem. Als Software nehm ich immer Audacity (in der 1'er Version zeigt die die Markierungsgröße auch noch in ms an). Was die Zeiten angeht nehm ich exakt 50ms/50ms. Hast du mal parallel mit Hterm aufgezeichnet was du mit dem M8 gesendet hast? Es kommt durchaus vor, das nach einem exteren Break auch das Webastosteuergerät seinerseits noch einen Break sendet wenn du dann sofort ein Telegram sendest gehen die ersten paar Byte verloren. Sascha PS: ich hab ne EVO 4.
:
Bearbeitet durch User
Stimmt Sascha, du warst das mit der Soundkarte... :) Gut, danke haste wieder gut erklärt, werd ich probieren! Da ich ja die Uhr loswerden will, habe ich dann, wenn ich mit dem Mega8 oder hterm sende kein weiteres Webastogerät verbunden. Und im hterm sehe ich immer einwandfrei, was ich über den Mega8 in den Bus geschickt hab. Aber die Heizung antwortet nur, wenn sie grade Lust hat... Is wohl weiblich meine Heizung... :D
Ille schrieb: > Aber die Heizung antwortet nur, wenn sie grade Lust hat... Is wohl > weiblich meine Heizung... :D hmm, sollte Sie dann nicht wiedersprechen?! Anstatt immer Einschaltbefehle zu senden, solltest du zum testen der Kommunikation lieber nur die Sensorwerte lesen. Auch wenn ich hoffe das wir darüber schon weg sind - das richtige Frameformat für die serielle Schnittstelle hast du schon eingestellt. Im Hterm hast du bei "Send on Enter" (oder wie das gleich heißt) hoffentlich none eingestellt. Sascha
Ille schrieb: > Aber die Heizung antwortet nur, wenn sie grade Lust hat... Is wohl > weiblich meine Heizung... :D meine auch, als ich letztens beim Service war hatte selbst die Webasto Vertretung Probleme connect zu bekommen. Mir ist es mit 2 blafusel Adapter noch nie geglückt.
:
Bearbeitet durch User
Sascha Weber schrieb: > hmm, sollte Sie dann nicht wiedersprechen?! Hahaha! :) Punkt für Dich! :) Atmel - Bascom: $baud = 2400 Config Com1 = Dummy , Synchrone = 0 , Parity = Even , Stopbits = 1 , Databits = 8 , Clockpol = 0 Das "Dummy" im Config ersetzt der dann mit den obenstehenden 2400 hterm: 2400 8 1 E Send on Enter: None Also ich bin mir schon sicher, daß das passt Sascha. Ich sende zum probieren jetzt meist statt einem Einschaltsignal das Auslesen der Seriennummer. Was verwendest du für einen Controllertakt oder verwendest du gar ein spezielles Quarz? Joachim, von Problemen mit der Software erzählte mir ein Kumpel gestern auch...
ok die Einstellungen passen. Am Atmel hab ich einen Quarz mit 3.6864MHz (lässt 0% Fehler zu). Vom Rechner sollte das aber ja auch kein Thema sein zumal die Webasto-Software ja dann bei dir mit der selben Hardware läuft. Mit Hterm habe ich jedoch nie versucht mit der Heizung selbst zu kommunizieren sondern habs nur benutzt um die Kommunikation zwischen Uhr und Steuergerät zu belauschen. Sascha
So, Problem gelöst!!! Ums kurz zu machen, ich war selber schuld. Noch bevor das erste Telegramm (vom Mega8) komplett gesendet wurde, bin ich in eine Interrupt Routine gesprungen und hab mich dort bissl aufgehalten und das bei jedem Echo. Sah zwar im hterm mit 50ms Zeilenumbruch super aus, mehr aber auch nicht. Bei kürzeren Zeilenunbruchzeiten waren die Kommandos vom Mega8 total zerpflückt (keine Fehler, aber halt unterschiedliche Pausen zwischen den einzelnen Bytes), vom hterm gesendet waren sie stattdessen noch schön zusammen. Das zeigte dann gestern auch der Oszi beim Kumpel, der mich dankenderweise auf die Sache mit dem Interrupt brachte. Die Kommunikation läuft jetzt super, auch inklusive BREAK. Ich verwende aktuell 25/25ms, da sich gestern auch gezeigt hat, daß die einzelnen Softwareversionen von Webasto mit unterschiedlichen Zeiten arbeiten und dabei die Version 2.07 mit den genannten Zeiten am besten funktioniert. Mit der 2.14. z.B. war zum Teil keinerlei Verbindung zur Heizung möglich. Fazit - war'ne schwere Geburt, aber auch Dank Eurer tollen Hilfe hier, loift meine Heizung jetzt mit Mega8 und 'nem in Bascom geschriebenen Programm. Eigentlich recht easy wenn, ja wenn man einmal dahinter gestiegen ist... :) Viele Grüße Ille
Hallo, schön das es nun endlich läuft - jetzt wo der Winter endlich fast vorbei ist. Aber der nächste kommt bestimmt. Und im Sommer kann man ja immerhin auf diese Art und Weise noch das Gebläse zum lüften einschalten. Sascha
Haha lach ;) Das macht nichts Sascha vor der Idee mit dem Weglassen der Uhr gab's schon Version 1 und 2 in analog und seit letztem Jahr läuft Version 3 mit Atmel und Uhr problemlos. Also frieren is definitiv nicht angesagt! Wär ja auch doof, oder!?! ;)
Hallo ich fasse noch einmal zusammen: Das BREAK ist eigentlich ein Wakeup für die Steuergeräte. Das wird immer benötigt, wenn eine Busruhe von >60 Sekunden statt gefunden hat. Das Wakeup zieht den Bus für 25 ms (24ms < LOW < 26ms) auf Low und dann wieder auf HIGH. Die Gesamtdauer des Wakeups, bevor die Kommunikation statt finden kann ist 49ms < Wakeup < 51ms, heißt also 25ms LOW und 25ms HIGH sind gute Werte. Dann kanns los gehen. Noch was: Ist am W-Bus kein Heizungssteuergerät verbaut, muss ein externer Pull up Widerstand von 1k angeschlossen werden.
Hänschen schrieb: > Hallo ich fasse noch einmal zusammen: > > Das BREAK ist eigentlich ein Wakeup für die Steuergeräte. Das wird immer > benötigt, wenn eine Busruhe von >60 Sekunden statt gefunden hat. Ja wobei nicht so ganz klar ist nach welcher Zeit sich das Teil schlafen legt, kommt ohne Break keine Antwort macht man halt eins > Das Wakeup zieht den Bus für 25 ms (24ms < LOW < 26ms) auf Low und dann > wieder auf HIGH. Die Gesamtdauer des Wakeups, bevor die Kommunikation > statt finden kann ist 49ms < Wakeup < 51ms, heißt also 25ms LOW und 25ms > HIGH sind gute Werte. Dann kanns los gehen. eigentlich 50ms/50ms > Noch was: Ist am W-Bus kein Heizungssteuergerät verbaut, muss ein > externer Pull up Widerstand von 1k angeschlossen werden. ein Widerstand sollte irgendwo sein (510Ohm) waren das glaube ich. Sascha
Das Wbus Protokoll entspringt wohl dem LIN. In LIN ist eine Wakeup-Zeit von 100ms vorgegeben. Bis dahin muss ein LIN Teilnehmer empfangsbereit sein. Könnte gut sein das dieses Limit hier auch gilt. Vielleicht ist es nicht wichtig wie lang der Puls ist, sondern das man erst nach 100ms anfängt zu senden!
Angehängte Dateien:
-
W-Bus_mit_510ohm.png
2,8 KB
Habe nun ein L9637 Chip wie oben von mr-action verdrahtet und dabei RX TX GND und 5V an einen FTDI Chip angeschlossen damit ich mit dem Terminal Programm die Infos auf dem Bus abfangen kann. Habe eine MultiControl Einheit an der Heizung dran wo ich nun die Signale (12V GND sowie K-Line) direkt abgegriffen habe und an den L9637 Chip anschloss. Nun wollte ich mit dem Terminal Programm die Daten abgreifen sobald welche von der MultiControl Einheit and das Heizgerät gesendet werden. Aber ich sehe gar nichts... stimmt da was mit dem Chip nicht oder hat jemand eine Idee was ich falsch mache? Kann ich die MultiControl Einheit sowie den L9367 Chip gleichzeitig am WBUS anschliessen? Gruss Andi
Hallo, also das sollte passen, den 510Ohm kannst du weglassen der ist ja am BUS schon woanders vorhanden. Für den parallelen Betrieb von mehr als zwei Teilnehmern ist der BUS konzipiert also kannst du dich da auch mit ranhängen. Hast du TX und RX richtig mit dem MAX verbunden? RX ist am L9637 ein Ausgang! Sascha
Hi Andi, ich kann Sascha nur zustimmen - RX muss an RX vom FTDI und TX an TX vom FTDI... Ansonsten sieht das alles sehr richtig aus... ;-) Viele Grüße Michael
Danke euch beiden werde mal den 510Ohm entfernen sowie die TX und RX Leitungen tauschen. Sehe ich das richtig wenn ich an der MultiControl Einheit was verstelle z.B. die Heizung einschalte sollte ich das mit dem L9637 und den FTDI am Terminal-Programm sehen oder? So wüsste ich wenigstens dass der L9637 funktioniert denn ich habe langsam bedenken dass der Chip evtl. defekt ist... Gruss Andi
ooops habe wohl den Fehler gefunden... scheinbar ist GELD -> WBUS, ROT -> 12V und BRAUN -> GND. Habs eigentlich mit dem Multimeter ausgemessen aber eben wer misst misst mist... :) Gruss Andi
Testen kann man den im Prinzip auch ohne angeschlossene Heizung etc. Der W-Bus ist ja ein 1-Draht-Bus, d.h. Senden/Empfangen auf einem Kanal. Daher empfängt man automatisch alles was man sendet als Echo. Wenn Du also irgendwoher 12V drauf legts und den 510 Ohm Pullup doch anschließt, solltest Du im HTerm (oder was auch immer Du als Terminal nutzt) jedes gesendete Byte auch im Empfang erhalten. Somit kannst du testen ohne den Chip mit einem "echten" Bus zu verbinden. In meiner Software mache ich so einen Selbsttest, ob der Bus ok ist.
:
Bearbeitet durch User
Ein kleiner Nachtrag von mir, da ich bis gestern enorme Probleme mit der Bus-Kommunikation hatte. Ich bekam immer nur Timeouts und habe lange nach der Ursache des Problems gesucht. So wie es aussieht ist der Zeitliche Abstand zwischen BREAK und dem ersten Datenpaket kritisch. Meine Software war da etwas nachlässig, sprich es wurde beim Start ein BREAK erzeugt und dann, ca. 25-30ms später, fing der UART erst an zu senden. Das mag die Standheizung (zumindest meine) wohl garnicht und schaltet auf stur ;-) Will das nochmal verifizieren, aber sendet man sofort, dann klappte es bei mir auf Anhieb. Ich würde aber jetzt behaupten das BREAK kein eigenständiges Datenpaket ist sondern immer nur unmittelbar in Verbindung mit einem gesendeten Byte daher kommen darf. Wie lange es dauern darf bis man wieder ein BREAK senden muss ist noch unklar. 2-5 Sekunden sollten schon gehen. Theoretisch könnte man vor jeder Datagrammserie eins senden. "Sauber" wäre aber das abzustufen. Was Sascha sagte stimmt, der Bus ist Multimaster-fähig konzipiert. Ob das die SH aber auch kann, muss man testen. Scheinbar ist es der SH aber egal mit welcher Absendeadresse man daher kommt, solange es nicht die 0x4 ist, die hat sie nämlich selbst ;-)
Also die Zeit zwischen der letzten Nachricht und einem neuen BREAK ist größer 15sec. Denn die original FFB (T91R - VW Kram), fragt alle 15sec ob die Heizung noch läuft und macht dabei keinen neuen BREAK - vielleicht hängt das aber auch vom Betriebszustand ab? Also, das die Heizung schneller wieder einschläft, wenn sie nicht heizt?
:
Bearbeitet durch User
Also, laut meinen Versuchen ist es so, das eine Pause zwischen BREAK und erstem Byte den Wert von 10ms nicht überschreiten darf. Sonst erkennt die Standheizung den BREAK wohl nicht als solchen und irgnoriert auch die folgenden Bytes. Vermutlich kann sie den BREAK dann nicht von einer Spannungsstörung etc. unterscheiden. Von daher empfehle ich, den Break nicht einfach mal so zu senden, sondern wirklich unmittelbar vor der Byteübertragung. Ich habe Lösungen im Quelltext gesehen die das so tun, viele andere aber nicht. Die machen beim Start des uC eine "Init" Routine in der das Break gesendet wird und gehen dann später in die Kommunikationsroutine über. Die Zeit dazwischen kann durch Interrupts oder interne Logik verzögernd wirken. So war es bei mir.
Das Verhalten scheint aber Firmwareabhängig zu sein... Meine Heizung spricht auch mit 50ms Pause nach dem Break mit mir... Ohne Pause nach dem Break läuft es bei mir allerdings auch... Die scheint da also wesentlich unkritischer zu sein... Was aber definitiv falsch ist, einfach mal den Break zu machen und irgendwann mal was zu erzählen... Ich ruf ja auch net irgendwo an, leg den Hörer dann erstmal daneben und erzähle dem Gegenüber irgendwann mal was... ;-)
Michael R. schrieb: > Das Verhalten scheint aber Firmwareabhängig zu sein... Meine Heizung Das könnte gut sein! Ich weiß das die Fahrzeughersteller, bei mir Ford, durchaus "eigene" Firmware auf die Heizungen aufbringen lassen. Dadurch kann man wohl leider keine allgemeingültigen Aussagen machen. Dann reduzieren wir uns einfach auf den kleinsten gemeinsamen Nenner und den würde ich so definieren: "Vor der ersten Übertragung, bzw. nach einer längeren Übertragungspause muss unmittelbar vor dem ersten Byte ein BREAK gesendet werden. Dieses besteht aus einer 25ms langen LOW (0V, Dominant) gefolgt von einer 25ms langen HIGH (12V, Rezessiv) Phase. Die Signalzeiten sind kritisch und exakt einzuhalten (Toleranz max. 1-2ms)"
25ms low und 25ms high?! Ich dachte die Highphase muss bei dir jetzt <10ms sein... :-o Oder war das noch eine Bonuswartezeit?
Letzteres! Ich würde es nicht "bonus" sondern eher "unnötig" nennen ;-) Aber sowohl die Webasto-Uhr, als auch die Webasto-Thermo-Top-Software machen einen 25/25ms Break.
so kann nun endlich mit der Standheizung kommunizieren :) Ich brauche die "W-Bus constant definitions" von Manuel Jander. Wenn ich einen QUERY_STATE mache bekomme ich 0x71 zurück bei komplett ausgeschaltener Heizung. Was eigentlich ja 0x04 sein müsste... finde 0x71 auch in der Liste nicht... Kann mir einer sagen was da falsch läuft??? (Temperatur der Heizung, flame detection etc. kann ich alles abrufen) Gruss Andi
Wenn du das ganze mit Kommandos (siehe webasto txt im svn von der lib), könnt ich dir vielleicht helfen... So steh ich aufm Schlauch... ;-) btw: Die T91R (VW FFB von Webasto), antwortet auf Anfragen, die sie nicht beantworten will mit 0x7F... Also wenn man anfragt: 0xF2 0x03 0x51 0x0D 0xAD Kommt zurück: 0x2F 0x04 0x7F 0x51 0x11 0x14 Das gleiche kommt auch bei allen anderen Kommandos, die sie nicht kennt... Die Heizung selbst hingegen ignoriert alles, was sie nicht kennt... :-o
beantworten tut sie korrekt, denn wenn ich die Heizung starte dann geht die Heizung verschiedene Modis durch bis sie dann vollgas gibt und schlussendlich wieder ausschaltet. Diese verschiedenen Modis sehe ich als STATE Ausgaben aber eben kann die nicht in Verbindung mit dem "W-Bus constant definitions"-File bringen. Also somit funktioniert die Kommunikation aber evtl lese ich das zurückkommende Byte falsch... Gruss Andi
so hier wäre noch das Kommando: TX 34 03 41 3A 0C F3 RX 43 09 41 07 71 01 02 04 10 20 80 F6 TX 34 03 41 3A 0C F3 RX 43 09 41 07 71 01 02 08 10 40 80 EC Hilft das was? Gruss Andi
Nicht wirklich, denn ein Kommando 0x41 ist in der txt nicht dokumentiert und in der lib ist es (so weit ich das sehe) auch nicht definiert: https://sourceforge.net/p/libwbus/libwbus/ci/master/tree/wbus/wbus_const.h Davon ab, ist in der Antwort auch garkein ACK Bit gesetzt... :-o
hmm ok Kannst du mir dein Kommando geben wie du den Status der Heizung abfragst. Dann kann ich das mal manuell eingeben und schauen was zurückkommt. Gruss Andi
Also ich nutze 0x50 0x07 um zu erfahren, was meine Heizung grade treibt... (musst natürlich vorne noch Header und Länge sowie hinten die Checksumme hinzufügen) Eine super Beschreibung findest du hier: https://sourceforge.net/p/libwbus/libwbus/ci/master/tree/webasto_wbus.txt
alllsssoooo.... Beim letzten Post wo meine Kommandos standen hatte ich vergessen auf EVEN bei Parity zu schalten. Also die Kommandos waren so TX F4 03 50 07 A0 RX 4F 09 D0 07 71 00 00 00 00 00 E0 oder TX 34 03 50 07 60 RX 43 09 D0 07 71 00 00 00 00 00 EC Es scheint nun definitiv so, dass sie die STATEs bei meiner Firmware geändert haben also entspricht neu 0x71 => 0x04... (= Off state) (und nein ich kann nicht einfach 0x6D abziehen dann stimmt es immer noch nicht überein... habs schon versucht...) Hier noch ein weiteres Bsp., dass sonst alles funktioniert: TX 34 03 50 05 62 RX 43 0B D0 05 35 30 20 00 00 FF 01 05 43 Temp 35 => 3°C (jep es ist kalt draussen :)) usw. Oder sehe ich da was falsch? Gruss Andi
Hallo, hab jetzt grad keine Unterlagen zur Hand: Temp: 0x35 -> 53dez -> -50 = 3°C stimmt ! Da es kein Bit fürs Vorzeichen gibt musst du 50 abziehen. Sascha
jep danke dir! Ja dann haben die doch wirklich die "Operating state" codes geändert.... Würde Sinn machen, denn der höchste Code bei den "alten" war 0x62. (#0x62 Ramp full load) Und nun fangen sie höher an damit sie den gesamten "Operating state"-Satz neu anordnen können.... Weiss da jemand mehr darüber? Andi
Na, da sind wir dann doch schon weiter gekommen... Bzw. du... ;-) Was für eine Heizung hast du denn? Kannst du die Firmwareversion und WBus Version auslesen? Also 0x51 0x02 und 0x51 0x0a?
Nun gut das ist die Antwort der Heizung: Software version TX 34 03 51 02 64 RX 43 0F D1 02 FF FF 03 24 13 08 05 FF FF FF FF FF 59 W-BUS version TX 34 03 51 0A 6C RX 43 04 D1 0A 41 DD Frage wenn ich nur den Fan einschalte also Sommer-Modus ändert sich bei mir der Status der Heizung gar nicht sprich sie bleibt auf 0x04 oder eben 0x71 (logisch hat auch nichts mit der Heizung zu tun). Wo kann ich evtl. den Status trotzdem abfragen? EDIT: Hmm evtl 0x50 0x03 und dann evtl unter 0x10 Vehicle Fan Relay (VFR) Andi
:
Bearbeitet durch User
Hast du ne Webasto Thermo Top Evo? Von den Daten her, bist du ja beim WBus schon bei Version 4.1... Hardware Version ist ja undefiniert und die Software ist Version 8.05 von Mittwoch KW23 2013... Das is ja ne Ecke neuer wie die TTVs, deren Daten ich bisher so im Netz gefunden habe...
Ja es ist eine Thermo Top Evo. Schade, dann muss ich wohl selber herausfinden was die verschiedenen Status Meldungen bedeuten... Nun mit welchem Befehl startest du eigentlich die Heizung? WBUS_CMD_ON_SH?
Andreas K. schrieb: > Nun mit welchem Befehl startest du eigentlich die Heizung? > WBUS_CMD_ON_SH? Kommt drauf an was Deine Heizung ist. Wenn es eine echte Standheizung, also kein Zuheizer ist, dann besser WBUS_CMD_ON_PH (0x21). Das sendet zumindes der Webasto 1533 Timer. Und dann, damit die Heizung nicht wieder ausgeht, immer schön so alle 15 Sekunden ein WBUS_CMD_CHK (0x44) schicken. Dieser enthält wieder den ursprünglichen Startbefehl. Zum ausschalten muss man eigentlich nur damit aufhören Keep-Alives zu senden. Sauberer ist aber natürlich einen WBUS_CMD_OFF (0x10) zu senden.
Danke dir hatte vorhin nur WBUS_CMD_ON_SH gesendet und da ging zwar die Heizung aber das Gebläse im Innenraum ging nicht an. Nun mit WBUS_CMD_ON_PH ist alles TipTop! Nun habe mal ein bisschen die Status Meldungen Aufgezeichnet. Wen die Heizung volle Pulle läuft was ist bei euch der Status Code? Hat jemand die Temperatur verfolgt die bei den QUERY_SENSORS zurückkommt? Meine geht auf MAX 64°C hoch. Andi
Also meine Wassertemp geht bis ca. 70 Grad meine ich... Dann hört sie ja auch irgendwann auf, damit das Thermostat nicht auf geht... Zu den Zuständen, programmier dir doch aufm PC einen Heizungssimulator, der die EVO simuliert... Dann kannst jeden Zustand vorgeben und in der Thermo Top Software gucken, was sie drauß macht... (wäre auch cool, wenn du deine Erkenntnise dann hier postest oder in die wbuslib einfließen lässt)
Ja das mit dem Heizungssimulator hätte ich schon lange gemacht aber die Thermo Top Software zeigt meine Com Ports nicht an so dass ich ein uC an anschliessen könnte welcher die Zuständen durch geht... Welche Version habt ihr (habe V3.0) oder brauche ich da ein spezielles Interface und geht ein FTDI Chip nicht? Andi
Vergiss das USB-Zeugs, zumindest wenn es kein ORIGINAL Ftdi ist sondern so China-Klones. Damit habe ich Tagen und Woche sinnlos und erfolglos vergeudet das ans laufen zu bringen. Es klappt nicht. Dachte auch zuerst es liegt an der WTT Software und hab etlich Versionen ausprobiert. Damit hat es aber nichts zu tun, die gehen alle. Auch ein K-Line Adapter mit USB hats nicht gebracht. Wie auch, ist ja dasselbe drin ;-) Letztlich hat bei mir RS232 auf COM auf Anhieb perfekt funktioniert. Dazu mir hen Max232 Shield für nen Euro bestellt und am TTL Ausgang meinen LIN Transceiver angeschlossen. Ich nutze einen MC33660, andere gehen aber auch, gibt ja reichlich davon... (TJA1020, L96..)
:
Bearbeitet durch User
Also ich benutz die 2.07 mit dem "K²L901 USB KKL Interface" von blafusel - funktioniert super... Da der FTDI die baudrate auch kann, sehe ich da eigentlich keinen Grund, warum man USB verteufeln sollte... ;-)
Wie Du ja weist habe ich etliches hier ausprobiert und bin nur mit RS232 zum Erfolg gekommen. Jetzt habe ich jedoch nur bille Adapter genutzt, also einen FDTI-Klone, einen VAG-K-Line Adapter für 8€ aus Ebay. Am Ende liegt es wohl am Treiber... Wenn man aber anfängt und sicher sein will das nicht andere Probleme lauern, würde ich jedem RS232 mit einem MAX232 empfehlen. Das klappt 100% und DANN kann man ja mit USB rumprobieren.
Ist mir bewusst, das du mit allen USB Kabeln Probleme hattest - drum hab ich ja dazu geschrieben, welches bei mir läuft... ;-) Außerdem hat ja kaum noch jemand nen echten RS232 Port an seinem Rechner - ich hab da nur noch einen von und den Rechner trag ich sicher nicht in die Tiefgarage... Ich denke vielen anderen geht es genauso...
Ok hab nun ein RS232 - USB Koverter gefunden. Nun habe ich zwei von denen an den Laptop angeschlossen und mit einem Seriellen Kabel verbunden. Nun starte ich das WTT Programm und drücke auf "Start Diagnose" und verbinde auf den Anderen Konverter mit dem Hterm wo ich nun die Anfrage "F4 03 51 0A AC" sprich welche WBus Version die "Heizung" hat sehe. Ich Antworte dann z.B. mit "4f 04 d1 0a 33 a3" doch in der Protokoll-Anzeige des WTT Programms steht nur "Falsches Echo Empfangen". Müsste doch stimmen oder sehe ich das falsch? (Ich weiss ich könnte ins Auto gehen das Programm direkt mit der Heizung verbinden und dann die RS232 Leitung ausschnüffeln..., aber vielleicht hat ja jemand eine Idee :) ) LOG Auszug: Diagnose gestartet: 29.02.16 07:50:21 W-Bus Wakeup... Falsches Echo empfangen! Andi
:
Bearbeitet durch User
Hallo Andi, Andreas K. schrieb: > Ok hab nun ein RS232 - USB Koverter gefunden. Nun habe ich zwei von > denen an den Laptop angeschlossen und mit einem Seriellen Kabel > verbunden. So hatte ich das auch mal gemacht. Alternativ gibt es auch sowas wie einen "Serial Monitor" als Treiber. Der klemmt sich in die lokale Kommunikation und zeigt alles was rein und rausgeht. Sehr hilfreich. Leider sind die guten kostenpflichtig. > Nun starte ich das WTT Programm und drücke auf "Start Diagnose" und > verbinde auf den Anderen Konverter mit dem Hterm wo ich nun die Anfrage > "F4 03 51 0A AC" sprich welche WBus Version die "Heizung" hat sehe. Ich > Antworte dann z.B. mit "4f 04 d1 0a 33 a3" doch in der Protokoll-Anzeige > des WTT Programms steht nur "Falsches Echo Empfangen". Müsste doch > stimmen oder sehe ich das falsch? Der W-Bus ist ja ein Ein-Draht-Bus. TX- und RX Kanal sind physikalisch miteinander verbunden. Daher empfängt man auch gleichzeitig alles was man sendet. Dies ist gut geeignet um Bus-Störungen zu erkennen, z.B. wenn irgendwas den Ruhepegel auf 0V zieht (Kurzschluss). Die WTT-Software geht davon aus alles was sie sendet auch zu empfangen. Das ist das "echo". Dieses geht ab. Um die WTT-Software mit Deinem Aufbau zu täuschen müsstest Du also vor Deiner Antwort erstmal die Anfrage der Heizung senden. Damit emulierst Du quasi das Echo. Also so: WTT -> PC: "F4 03 51 0A AC" PC -> WTT: "F4 03 51 0A AC", "4f 04 d1 0a 33 a3" > (Ich weiss ich könnte ins Auto gehen das Programm direkt mit der Heizung > verbinden und dann die RS232 Leitung ausschnüffeln..., aber vielleicht > hat ja jemand eine Idee :) ) Genau das Problem habe ich auch. Ich bastele dafür gerade einen WBus-Nachrichten Dekoder/Enkoder als WebApp. Zusätzlich versuche ich mit einem ESP8266 (3€ WLAN-Modul) eine Serial-Bridge zu bauen. Der hat einen UART und man könnte so via WLAN und Telnet an seiner Serialschnittstelle Daten empfangen/senden. Leider kennt der chip von hause aus kein Parity-Bit. Bin noch auf der Suche nach eine anderen Firmware. Ansonsten muss halt noch ein Arduino Nano "dazwischen". Theoretisch ginge das auch per GSM-Modem. Dafür müsste man aber die "richtige" SIM-Kart haben, sonst wirds schnell teuer ;-)
danke dir! Ja das mit dem Echo hab ich nun weggekriegt. Nun bekomme ich immer noch weiter anfragen die ich nun mit dem Hterm bestätigen kann. Bin nun bei der 9ten Anfrage des WTT Prgrammes an die Heizung (F4 03 51 03 A5) aber lass es nun mal bleiben. Versuche zuerst das WTT Programm direkt an der Heizung da ich vermute, dass ich nicht die neuste Programm Version habe und diese WBus >4 wohl gar nicht unterstütz. Bin im Moment zufrieden mit meiner SMS-Start Heizung daher brauche ich aktuelle nicht weiter daran weiter zu basteln. Werde aber evtl. dann später mal die Status Meldungen von WbusV >4 decodieren... Andi
Die WTT liest massig Parameter von der Heizung. Das lässt sich per Hand nocht mehr simulieren. Da braucht man Software bzw. einen Simulator zu. In der Regel will man ja das die eigene Hardware mit einer SH quatscht, also einen SH-Simulator. Von verschiedenen Wbus Versionen hab ich noch nix gehört. Wäre aber interessant zu wissen wie die sich unterscheiden. Das mit der Programmversion hab ich jetzt nicht verstanden.
Habe eben zwei Versionen von der WTT Software (2.13 und 3.0). Bei 3.0 kannst du auswählen ob du eine WBus Version von <= 3.5 oder >= 4.0 hast. Da ich eben eine Heizung mit WBus v4.2 habe und die Heizungszustandsmeldungen anders sind wird wohl die WTT Software 2.13 mit meiner Heizung nicht funktionieren. Leider erkennt die VWTT ersion 3.0 mein RS232 Koverter nicht daher ist für mich da Endstation da ich kein Original Diagnose Geräte habe :) Andi
Also einen normalen FT232 will die Thermo Test 3.0 nicht sehen... Hab grade einfach mal einem die passende VID und PID für deren Treiber eingestellt, klappt aber nicht... Bleibt wohl nur original Interface - aktuell nur einmal bei ebay in gebraucht: 201525848175 Oder, simulator schreiben und dann eine Werkstatt suchen, deren Hardware man mal für ne Stunde oder so benutzen darf... Letzteres wäre mit ein paar Connections wohl am einfachsten und günstigsten...
Andreas K. schrieb: > Leider erkennt die VWTT ersion 3.0 mein RS232 Koverter nicht daher ist > für mich da Endstation da ich kein Original Diagnose Geräte habe :) Wenn die Software einfach ein COM-Port haben will ist eigentlich erst mal uninteressant was der in Wirklichkeit ist (Hardware-RS232/USB-Serial/Virtual). Kannst du den Port von Hand einstellen oder sucht die Software selbst. Dann könnte evl. das alte Problem bestehen das die Software nur die ersten paar (4) Schnittstellen testet (eigentlich sollte zwar dieses uraltet Problem heute nicht mehr auftreten aber wer weiß). Sascha
Hoi Sascha Danke für deine Antwort aber ich habe nun schon alles erdenkliche getestet aber keines meiner 6! unterschiedlichen RS232 oder TTL / USB Konverters werden von der Version 3.0 erkennt. Bei der Version 2.1 haben immerhin zwei funktioniert. Andi
Bei 1.2 kannst du ein COM Port 1-10 auswählen. Bei 3.0 ein Dropdown der mir einfach nichts anzeigt. Unten rechts steht aber "USB Schnittelle nicht bereit" sprich das ist wohl kein normaler COM Port wie in der 1.2 version. Andi
Also ich nutze derzeit die Version 2.13 und da ist wie geschrieben keine manuelle Eingabe, sondern nur die Auswahl aus einer bestehenden Liste möglich. Darin werden mir alle COMs angezeigt, die im System verfügbar und FREI sind. Habe ich zwei Adapter dran und keine andere Software nutz einen dieser Ports, werden mir auch beide angezeigt. Ganz egal was hinten dran steckt. Hast Du mal überprüft ob Du durch die ganze Testerei inzwischen irgendwo eine magische COM-Port Nummerngrenze überschritten hast? Manche Software mag es nicht wenn die Portnummer über 9 steigt. Also COM1 bis COM9 sehen die noch, aber ab COM10 ist dann schluß. Man kann die Portnummer meist über den Treiber selbst einstellen. Im Geräte-Manager von Windows lohnt es sich mal die Option "Ausgeblendete Geräte anzeigen..." unter "Ansicht" auszuwählen. Ich kann mir auch nicht vorstellen das die 3er Version nur noch bestimmte USB-Typen anzeigt. Ich hatte die kurzfristig auch mal drauf, als ich noch dachte meine Kommunikationsprobleme kommen von der Version. Da wurde mir aber alles so angezeigt wie bei der 2er.
Klar ich musste alle Geräte Manuel auf einen COM Port <10 setzten da sonst die 2.1 Version die nicht erkannt hat (denn wenn ich ein neues Gerät anschliesse bin ich sonst im Moment auf COM 258 :)). Aber die COM Geräte welche in 2.13 erkannt werden erscheinen in er Version 3 nicht.
Die Version 3.0 bringt einen eigenen Treiber mit, für das Diagnose Gerät, das man von Webasto kaufen kann... Und in der Drop Down Liste werden nur Geräte angezeigt, die diesen Treiber geladen haben! DAHER FUNKTIONIEREN KEINE SERIALLEN KABEL!! (irgendwie hab ich das gefühl, das ich immer überlesen werde...) Also weder RS232 noch FTDI oder so werden Out of the box im 3.0er laufen und FTDIs laufen auch mit dem Webasto Treiber nicht - da steckt also wohl was anderes drin... (hat irgendwer eigentlich meinen Post von gestern Abend gelesen?)
Michael R. schrieb: > (irgendwie hab ich das > gefühl, das ich immer überlesen werde...) Jep das Gefühl habe ich auch :) > (hat irgendwer eigentlich meinen Post von gestern Abend gelesen?) Jep immer doch, aber so viele Euronen habe ich nicht übrig nur um die Status Meldungen des WBus V4.2 Protokolls zu dekodieren....
Ich finde ihr habt im Ganzen klasse Leistungen gezeigt. Aber für Normalsterbliche wäre ein Fertig Paket zB für eine Atmel Arduino Nano und einer schönen Sitze und lückenloser HowTo Anleitung das Sahnehäubchen auf dieser Diskussion. Der Winter kommt. Ich habe ziemlich Alles an AHrdware da. Aber weil ich extrem in Arbeit eingespannt bin, kann ich nicht so schnell genug Lektüre aneignen um es selber hin zu biegen. Meine ThermoTop EVO hat nur ein W BUS bzw K Line. Und wie zuvor zu lesen ist. Unterstützt die Diagnosesoftware keine NoName OBD Adapter. Der Treiber für den China Adapter .. advanced obd scan tool, ist installiert und funktioniert. Außerdem ist mir auch noch unklar wie ich mit der Software HTERM Befehle an die Heizung senden kann. Die Vorwahluhr 1533 habe ich auch. Per HTERM oder per 1533 die Kommunikation erwecken? im Ganzen konnte man sehr gut das Geschehen in den ersten Beiträgen verfolgen. Aber welche Mittel, Software und Erkenntnisse Ressourcen ... handfestes ... Anleitungen ... Dateien ... keine Spur für Normalsterbliche
Hi Roman, also wenn du eh mit nem richtigen PC mit der Standheizung quatschen willst, guck dir doch die libwbus mal an... Was den Arduino angeht, vielleicht gibts da ja Input von Olli - der war/ist ja damit unterwegs... Aber in Summe find ich es lustig, das jeden Winter die gleichen Fragen aufkommen (und das ich den Sommer über das ganze - wieder - nicht fertig gemacht habe)... Aber jeden Winter wird es ein bisschen fertiger... :-D Viele Grüße Micha
Weißbeck Roman schrieb: > Ich finde ihr habt im Ganzen klasse Leistungen gezeigt. > > Aber für Normalsterbliche wäre ein Fertig Paket zB für eine Atmel > Arduino Nano und einer schönen Sitze und lückenloser HowTo Anleitung das > Sahnehäubchen auf dieser Diskussion. also wenn du nur nachbauen willst, dann würde ich mein Projekt schon zur Verfügung stellen - einen Artikel dazu zu erstellen hab ich noch nicht geschafft. Anbei mal die Schaltungen für den Empfänger im Auto, sowie der Fernbedienung (Strapubox 6029 mit 16x2 EADog-Display). Software (ASM) kann ich natürlich auch zur Verfügung stellen. Das Teil läuft in zweifacher Ausfertigung schon einige Jahre problemlos. Sascha PS: Wie weit Olli mit dem Arduino im Frühjahr gekommen ist weiß ich auch nicht.
Das klingt ja alles nach einer runden Sache. Meinst Du, ob eine Airtop direkt läuft? Könnte sein, dass sie einen anderen Start Befehl braucht - aber sollte machbar sein. Nur mit der Fehlerbehandlung weiss ich nicht recht, wie sich deine Software verhält, wenn da ein paar andere Codes kommen. Gibt der AVR am W-Bus die Protokolle einfach nur weiter an den Fernbedienungs-AVR? Aber bevor ich hier weiter Fragezeichen verbreite, fände ich es super, wenn auch der Code veröffentlicht wird. Ein klizekleiner Bug noch im Schaltplan: Ist die TVS-Diode gegen Masse nicht falsch herum. Auch hätte die 1n6267 eine Durchbruchspannung bei 6 Volt?
Angehängte Dateien:
-
Fernbedienung.jpg
250 KB
Karl-werner R. schrieb: > Das klingt ja alles nach einer runden Sache. Meinst Du, ob eine Airtop > direkt läuft? Könnte sein, dass sie einen anderen Start Befehl braucht - > aber sollte machbar sein. Wenn die 1533 geht dann wirds wohl auch funktionieren die Codes sind ja die selben. Als Adresse verwende ich die der originalen T90/T91 damit zeigt die 1533 auch an das via Telestart eingeschaltet wurde. Das 1. Exemplar hab ich für meine EVO 4 gebaut. Beim Bekannten, bei dem jetzt das 2. Exemplar eingebaut ist, hab ich meins einfach mal getestet und lief. Er hat einen als Standheizung erweiterten Zuheizer im VW. > Nur mit der Fehlerbehandlung weiss ich nicht > recht, wie sich deine Software verhält, wenn da ein paar andere Codes > kommen. Alles was nicht gebraucht wird wird ignoriert. > Gibt der AVR am W-Bus die Protokolle einfach nur weiter an den > Fernbedienungs-AVR? Nein, die W-Bus Kommunikation wird ausschließlich innerhalb der Onboardunit abgewickelt. Die Fernbedienung schickt z.B. ein Statusabfragepaket und erhält ein paar Daten wie Status, Temperaturen und Bordspannung, die die OBU vorher von der Heizung holt, zurück. > Aber bevor ich hier weiter Fragezeichen verbreite, fände ich es super, > wenn auch der Code veröffentlicht wird. Stell ich mal noch ein wenn ich am Rechner bin. > Ein klizekleiner Bug noch im Schaltplan: Ist die TVS-Diode gegen Masse > nicht falsch herum. Auch hätte die 1n6267 eine Durchbruchspannung bei 6 > Volt? Da muss ich mal schauen, da Eagle auch nicht alles kennt muss man manchmal auf was ähnliches zurückgreifen - warscheinlich hab ich dann die Bezeichnung nicht geändert. Anbei mal noch ein Bild der FB. Sascha
:
Bearbeitet durch User
Hallo, hier ist Oli :-) Melde mich aus dem Sommerschlaf zurück. Auch mir sind im Sommer mehr Projekte "dazwischen" gekommen als mir lieb war. So habe ich meine Schaltung nicht weiterentwickeln können und sie sind ist i Prototypstadium stehen geblieben. Jedoch habe ich die gesammelten Infos in meinen Wiki erfasst. Alles zum Thema ThermoTop V, W-Bus, KFZ-Schutzbeschaltung, GSM mit Arduino, etc. ist dort drin. Das dürfte zumindest eine gute Basis für ein Projekt sein. Ich wollte auch in der Tat nur eine einfache Blackbox bauen, die ich irgendwo im Handschuhfach vergrabe und die ausschliesslich mit Anruf die Heizung einschaltet. In dem Punkt sind Sascha und Michael schon viiiiel weiter als ich! Da ich nur Hobbyelektroniker bin, bezweifle ich auch das mir ein solch professioneller Aufbau gelingt, mit eigener Platine und so. Ich fänds ja toll wenn wir gemeinsam sowas wie eine OpenSource-Platine für solche Projekte entwickeln und anbieten könnten. Nicht jeder kann Platinen entwerfen und SMD bestücken. Aber es gibt viele kreative Ideen von denen man profitieren könnte. Was meint ihr beiden, hättet ihr interesse sowas zu verkaufen? Ich hätte schon Abnehmer...
Hallo, anbei soweit komplett ... @Karl-werner Riedel hast natürlich Recht mit der Diode (hatte auch noch ein Bild der Platine), habs im Plan gleich mal geändert, im übrigen ist es eine 6281 Sascha
Wahrscheinlich gibt es dank deinem, nun, veröffentlichten Plan,.. die Geräte demnächst auf eBay. Falls die Chinesen das entdecken. Anbei; Ich hätte nie gedacht das so Viele hier, besonders die Elite noch für dieses Projekt bereitstehen für Rat und Tat Respekt! Ihr macht viele Menschen glücklich. Freut mich. Danke.
Hallo Sascha, danke für den Code. Mit dem Assembler tue ich mir noch schwer, aber wenn es nur z.b. nur um den anderen Startcode 23 für die Airtop geht, ist es machbar. Auch will ich erst mal versuchen "normales" 16x2 Display in 3,3Volt anzuschließen. Die EA-DIPs sind zwar herrlich negativ/bunt und haben einen unschlagbaren FSTN Kontrast - aber zum entsprechenden Preis, und sie liegen nicht so einfach in der Schublade herum. Was ist eigentlich die Funktion der Taste auf der Basisplatine? Komme da mit dem Code noch nicht klar. Und ich wage kaum zu fragen: Gibt es vielleicht eine ältere SW-Version ohne Funk-Funktion? Einfach nur Ein/Aus reicht sicherlich vielen Leuten.
:
Bearbeitet durch User
Karl-werner R. schrieb: > Hallo Sascha, > danke für den Code. Mit dem Assembler tue ich mir noch schwer, aber wenn > es nur z.b. nur um den anderen Startcode 23 für die Airtop geht, ist es > machbar. Auch will ich erst mal versuchen "normales" 16x2 Display in > 3,3Volt anzuschließen. Die EA-DIPs sind zwar herrlich negativ/bunt und > haben einen unschlagbaren FSTN Kontrast - aber zum entsprechenden Preis, > und sie liegen nicht so einfach in der Schublade herum. sollte machbar sein > Was ist eigentlich die Funktion der Taste auf der Basisplatine? Die habe ich in der aktuellen Version der Leiterplatte nur noch als Lötflächen ausgelegt, da ich das Teil beim Bekannten von aussen unzugänglich im Amaturenbrett verbaut habe. An PD2(SJ2) kannst du aber nach wie vor einen Taster anschließen, wie ich ihn bei meiner eigenen zum Einschalten der Lüftung verwende. PC1(SJ1) hat keine Funktion im Programm, hatte ich nur als Testmöglichkeit vorgesehen- am TSOP-Gehäuse kann man so schlecht mal was abgreifen. > Komme da mit dem Code noch nicht klar. Die Taste wird vom Programm nach wie vor ausgewertet, und zwar für langes (1.5s) und kurzes Drücken. Die zugehörigen Funktionen sind Button_long und Button_short in [main.asm]. In der Funktion für langes drücken steht jetzt der Aufruf für die Lüftung drin (Lueftung_einschalten) der lässt sich durch die entsprechenden Aufrufe (Heizung_einschalten) oder (Heizung_ausschalten) aus [heizung.inc] ersetzen. Das ganze kann man dann auch auf Button_short übertragen die derzeit nichts tut. Ausschalten tu ich bei mir in dem Fall immer mit der 1533. > Und ich wage kaum zu fragen: Gibt es vielleicht eine ältere SW-Version > ohne Funk-Funktion? Einfach nur Ein/Aus reicht sicherlich vielen Leuten. Die gibt's nicht, man könnte aber alles was das RFM betrifft rausschmeißen das das ja nicht aktiv benötigt wird. Es passiert ja nur was wenn von der Fernbedienung ein Paket kommt. Es sollte genügen die [rfm22.inc] und [funk.inc] in [main.asm] auszukommentieren und die dann auftretenden 8 Fehler durch auskommentieren der entsprechenden Aufrufe (plus der evl. davorstehenden Skip-Befehle) zu eliminieren. Müsste ich noch mal anschauen ob da noch was den Sleepmode behindern würde. Wenn der Bedarf besteht könnte ich auch eine [nofunk.inc] bereitstellen die anstelle der zwei anderen einzubinden währe und die Aufrufe der Unterprogramme mit RET 'kurzschließt'. Sascha
:
Bearbeitet durch User
hallo!! ich bin grade dabei mir eine gsm steuerung zu bauen. per hterm kann ich die heizung (thermo top V) starten und erhalten. nun ist mir aber eine sache seid jahren schon ein dorn im auge! ich muss immer 2 mal die heiztaste an der 1533 uhr drücken zum sofortheizen. hat da jemand vielleicht eine erklärung für? mein code ist auf arduino basis.... ich hab vor über den telestart die heizung per gsm zu starten (adresse 2) hat sich mittlerweile jemand rein auf der arduino basis beschäftigt? ich bekomm es derzeit nicht hin das ich mit der 1533er uhr per sofortheizen die standheizung abschalten kann.... da kolidiert etwas... danke für eure hilfe!
Alex H. schrieb: > hallo!! > nun ist mir aber eine sache seid jahren schon ein dorn im auge! > > ich muss immer 2 mal die heiztaste an der 1533 uhr drücken zum > sofortheizen. > > hat da jemand vielleicht eine erklärung für? zeigt die Uhr nach dem 1. drücken schon was an? > ich bekomm es derzeit nicht hin das ich mit der 1533er uhr per > sofortheizen die standheizung abschalten kann.... da kolidiert etwas... wenn du die Heizung über den Bus mit der Adresse der Fernbedienung startest, sollte die Uhr ihre Displaybeleuchtung einschalten und "TELE ON" anzeigen. Dann müsste ein Ausschalten möglich sein. Deine Steuerung sollte aber den von der Uhr kommenden Abschaltbefehl auswerten und die Kommunikation einstellen. Sascha
Genau!..... aber das groesste problem für mich ist noch das ich die soforzheizen taste 3 mal drücken muss... Sprich... An...aus...an.... keine shnung warum das so ist..jemand eine idee????
Ich glaube die 1533 uhr schaft es nicht den bus zu wecken... Jetzt ist die frage.... uhr oder standheizung....
Ok... die thermotop v in einem bmw ist immer Linbus gesteuert auf pin 2!.... also eine thermotop finden mit der es geht...... Andere frage.... wie kann ich ohne heizungsgerät jetzt weiter probieren... Geht ja nur darum das ich sogesehn mit handy und 1533 uhr alles ein und ausschalten kann.. Der pullup widerstand in der w bus leitung auf masse bringt nix.... Hat jemand mal zwischen telestart und uhr den verkehr aufgezeichnwt? Danke
Alex h. schrieb: > Andere frage.... wie kann ich ohne heizungsgerät jetzt weiter > probieren... > > Geht ja nur darum das ich sogesehn mit handy und 1533 uhr alles ein und > ausschalten kann.. irgendwo hier weiter oben gibts einen einfachen Simulator für WIN den ich mal zum testen geschrieben habe. Musst natürlich noch einen Apapter für die Serielle bauen. > Der pullup widerstand in der w bus leitung auf masse bringt nix.... was solls auch bringen? > Hat jemand mal zwischen telestart und uhr den verkehr aufgezeichnwt? da wird nichts direkt ausgetauscht, da jeder Busteilnehmer alles mitlesen kann merkt die Uhr auch das die Heizung mit dem Telestart eingeschaltet wurde. Sascha
Kann ich den ohne heizgerät weiter am w bus werkeln? Oben stand was mit 510ohm bzw 1k ohm am wbus strang ende um das heizgerät zu simulieren! Hast du da noch pasr infos? Ich hab ein usb kkl interface wo ich k line 12v und gnd mit vernetze um am wbus zu lesen und zu senden!
Für ich wäre interessant ob: Webasto 1533 uhr verbunden mit telestart über wbus eine nicht wbus heizung starten würde über den 12v ausgang. Den dann kann ich ja mein gsm modul so umbauen das es als telestart die heizung startet. Dann wird auf der uhr × tele on × angezeigt. Nun geht es darum das auf dem wbus aber kein heizgerät angeschlossen ist! Man könnnte jetzt n mini arduino nehmen der dann die heizung simuliert.... weil ohne heizung arbeitet der ganze w bus nicht. Oder hat hier jemand rein aufem tisch mit ner uhr rumgebastelt? Danke
Alex h. schrieb: > Kann ich den ohne heizgerät weiter am w bus werkeln? klar, mit dem Simulator (tut so als ob es das Heizgerät währe) hab ich auch meine Fernsteuerung getestet. Ist sonst recht umständlich immer erst auf den Parkplatz raus zu gehen. > Oben stand was mit 510ohm bzw 1k ohm am wbus strang ende um das > heizgerät zu simulieren! die 510Ohm haben nichts mit dem Heizgerät zu tun. Ein k-Line-Interface (auch W-Bus) wird im Ruhezustand passiv auf 12V gezogen. Der Widerstand ist bei der Webastoheizung im Heizgerät - weil das halt auf jeden Fall da ist. Ohne Heizgerät musst du den Widerstand halt irgendwo ranklemmen. > Hast du da noch pasr infos? > > Ich hab ein usb kkl interface wo ich k line 12v und gnd mit vernetze um > am wbus zu lesen und zu senden! das wird funktionieren. Sascha
Alex h. schrieb: > Für ich wäre interessant ob: > > Webasto 1533 uhr verbunden mit telestart über wbus eine nicht wbus > heizung starten würde über den 12v ausgang. das wird nicht gehen, die Telestart wird über W-Bus nur mit dem Heizgerät sprechen. Ich meine auch die originale Telestart hat einen 12V Ausgang der eine nicht W-Bus fähige Heizung schalten konnte. > Den dann kann ich ja mein gsm modul so umbauen das es als telestart die > heizung startet. > Dann wird auf der uhr × tele on × angezeigt. also nur das ich das richtig verstehe, deine Heizung arbeitet nicht mit W-Bus? Du hast ein GSM-Modul was nur mit W-Bus arbeitet? > Nun geht es darum das auf dem wbus aber kein heizgerät angeschlossen > ist! W-Bus ohne Heizgerät geht nicht. > Man könnnte jetzt n mini arduino nehmen der dann die heizung > simuliert.... weil ohne heizung arbeitet der ganze w bus nicht. genau > Oder hat hier jemand rein aufem tisch mit ner uhr rumgebastelt? die Uhr hab ich bei mir nicht ausgebaut, macht auch der Simulator mit. Wenn du aber im Auto gar keinen W-Bus hast nützt das auch nichts. Sascha
Es geht darum das ich die heizug mit der uhr ausbekomme! Heisst Gsm modul sendet 12v an standheizung. Heizung ist an. Hat kein wbus. 1533 uhr hat w bus. Mein gsm modul... selbstbau.. hat auch w bus.. Ich verbinde wbus ohne heizgerät. Wbus gsm macht 1533 uhr an oder aus. 1533 bei an per wbus schaltet auch 12v an oder aus. Die thermotop v.. kannst vergessen..arbeizet als lin bus
Dann wird das nichts, solange das GSM-Modul die Heizung mit der 12V Spannung eingeschaltet hält, kann auch nur das GSM-Modul die Spannung wieder weg nehmen. Einzige Lösung: Du müsstest mit deinem selbstbau GSM per W-Bus das Heizgerät und die Telestart gleichzeitig simulieren. Damit könntest du der Uhr vorgaugeln das die Heizung per Telestart eingeschaltet wurde. Beim drücken der Taste auf der Uhr würde die dann das Abschaltsignal per W-Bus an dein GSM senden, was seinerseits die 12V abschaltet damit die Heizung aus geht. Sascha
Sascha... das mit dem widerstand.... erkläre mir das bitte mal genau! Wie muss ich den schalten und welche groesse? Dann müsste doch die uhr tele on zeigen auch ohne heizgerät richtig?
Alex h. schrieb: > Sascha... das mit dem widerstand.... erkläre mir das bitte mal genau! > Wie muss ich den schalten und welche groesse? was gibts da groß zu erklären, nimm 510Ohm und schließ ihn an 12V und an die W-Bus-Leitung - wo ist egal. > Dann müsste doch die uhr tele on zeigen auch ohne heizgerät richtig? Gute Frage - aber ich glaube das währe zu einfach! 1. Sendet dein GSM den Einschaltbefehl wenn kein Heizgerät da ist? Wenn es erst mal den Status abzufragen versucht und keine Antwort bekommt kann es sein das es gar nicht erst versucht die Heizung auf diese Weise einzuschalten. 2. Erkennt die Uhr eine eingeschaltete Heizung nur den dem Paket zum Einschalten vom GSM zum Heizgerät? Ich denke eher das es die positive Rückmeldung auf den Einschaltbefehl auswerten wird. Sascha
Mein gsm interface sendet zum einschalten: 24 03 21 3c 3a Die antwort ist 42 03 a1 3c dc Nunn sende ich alle 5 sekunden 24 03 21 3c 3a Schalte ich an der uhr aus sendet die uhr 34 02 10 26 Heizung antwortet 4f 02 90 d1 Schalte ich an der uhr ein sendet diese 34 03 21 1e 08 Heizung antwortet 43 03 a1 1e ff Was meinst du.... ist das verwertbar? Kommt von der uhr das aus signal über den wbus schaltet der arduino im gsm modul die 12v weg.. heizung geht aus Das ist der plan
Jetzt kann ich sogesehn... alles theoretisch.. den 12v out von der uhr wegnehmen.... An den transistor hängen mit dem ich vom gsm modul 12v auf die webasto gebe (meine alte thermotop arbeitet mit 12v signal) und so den wbus mit den nschrichten am leben halte.. ich antworte auf die nachrichten der uhr.. kommt von der uhr Aus schalte ich die 12v weg.. kommt von der uhr an.. schalte ich sie ein... das gleiche mit meinem gsm modul. Dafür nutz ich 1 hardware und 1 software serial an einem arduino nano. Oder ich arbeite mit 2.. mein gsm modul ist so gross wie eine zigaretten schachtel... auf platz kommt es nicht an.... Was denkst du?
So wie oben sollte das schon gehen Alex h. schrieb: > Jetzt kann ich sogesehn... alles theoretisch.. den 12v out von der uhr > wegnehmen.... Ja > An den transistor hängen mit dem ich vom gsm modul 12v auf die webasto > gebe (meine alte thermotop arbeitet mit 12v signal) und so den wbus mit > den nschrichten am leben halte.. ich antworte auf die nachrichten der > uhr.. kommt von der uhr Aus schalte ich die 12v weg.. kommt von der uhr > an.. schalte ich sie ein... das gleiche mit meinem gsm modul. Jo > Dafür nutz ich 1 hardware und 1 software serial an einem arduino nano. warum 2 Schnittstellen? Ist der arduino nano in deinem GSM-Modul? > Oder ich arbeite mit 2.. mein gsm modul ist so gross wie eine zigaretten > schachtel... auf platz kommt es nicht an.... Warum nimmst du nicht nur das GSM-Modul und programmierst es so das es primär die Heizung darstellt. Das macht die Sache doch einfacher, die Pakete zwischen GSM und Heizung immitierst du dann für beide Richtungen indem dein GSM immer sendet. Sascha
Weil ich immernoch gern mal was am gsm modul weiter ausarbeite .. so kann ich dann einfach den usb port normal nutzen... ist die kiste endreif dann denk ich werd ich mit 2 arbeiten müssen... weil ich mein klimabedienteil über den kbus regel im heiz und lüftungsbetrieb.. dann die abfrage mit der batteriespannung usw... Irgendwann haste keine ports mehr... und 1 software serial ist schon weg wegen gsm... bleibt dann noch einer fürs programmieren oder serial monitor.... so kann ich genau eingreifen.... wbus...kbus...gsm.. verstehst du? Ob ich nun 2 minis oder 1 nano am ende nutze ist eigentlich wurst... ich gab noch keine coole i2c lösung..
@Sascha Gibt es einen genauen Verlauf auf dem Bus damit die Heizung an bleibt? Oder sende ich die ganzezeit den an befehl alle 5 Sekunden? Oder fragt die Uhr oder Heizung..hey soll ich noch an sein? Ich arbeite mit fest definierten hex Nachrichten. 1533 Uhr macht an...uhr weckt eh den Bus ..Heizungen antwortet..Erhaltungsnachricht alle 5 Sekunden.. 12v an 1533 Uhr macht aus..heizung antwortet dann 12v weg Sms kommt..Gsmmodul startet..Dann Bus wecken wenn an Signal..Bei aus wäre der Bus eh aktiv...Nachricht an Heizung...12v an..Erhaltungsnachricht alle 5 Sekunden bis programmierte zeit im Gsmmodul erreicht ist.. Dabei simuliere ich die Heizung auf dem Bus..So das der w Bus zwischen Uhr und meinem Gsmmodul alles regelt. Meine thermotop z CD ist ohne wbus oder sonstiges...Nur 12v an aus. Ich möchte nur die Uhr sauber nutzen und mein GSM Modul. Das GSM Modul verwertet die Nachrichten auf dem wbus und simuliert das heizgerät und weckt den Bus für das simulierte telestart. Das GSM Modul ist als teilnehmer Adresse 2. Hab ich etwas übersehen?vergessen? Hast du noch eine Idee?
Hallo Alex, also ich denke das sollte so aussehen: 1) Heizung aus -> Einschalten per GSM (12V-EIN) Bus wecken TX: von Addr 2 an Addr 4 Einschalten für x-min TX: von Addr 4 an Addr 2 ok Einschalten für x-min 2s Pause TX: von Addr 2 an Addr 4 Einschalten für x-min TX: von Addr 4 an Addr 2 ok Einschalten für x-min alle 25s solange kein Ausschaltbefehl von GMS oder 1533 gekommen ist TX: von Addr 2 an Addr 4 Kommandostatus prüfen TX: von Addr 4 an Addr 2 ok Kommandostatus prüfen 2) Heizung per GSM oder 1533 Eingeschaltet -> 1533 aus RX: von Addr 3 an Addr 4 Ausschalten TX: von Addr 4 an Addr 3 ok Ausschalten (12V-AUS) 3) Heizung aus -> Einschalten per 1533 RX: von Addr 3 an Addr 4 Einschalten für x-min TX: von Addr 4 an Addr 3 ok Einschalten für x-min RX: von Addr 3 an Addr 4 Einschalten für x-min TX: von Addr 4 an Addr 3 ok Einschalten für x-min (12V-EIN) RX: von Addr 3 an Addr 4 Kommandostatus prüfen TX: von Addr 4 an Addr 3 ok Kommandostatus prüfen (12-AUS), wenn x-min abgelaufen Prüfung Kommandostaus ausbleibt Abschaltbefehl (wie 2) kommt Sascha
Danke! Muss ich eigentlich x Minuten runterrechnen in den Nachrichten? Welche genaue Position hat Minuten? Ist das dann eine normale Zahl zb 15 umgerechnet nach hex? Vielen Dank!
> Muss ich eigentlich x Minuten runterrechnen in den Nachrichten? Nein, Du sendest einfach immer denselben Zeitcode, nämlich die ursprünglich angedachte Laufzeit. Das Protokoll der SH erwartet nur bei der ersten Übertragung die Laufzeit, die nachfolgenden Übertragungen dienen nur der Erhaltung und können auch beliebige andere Kommunikationen sein (z.B. Temperaturabfrage). Findet nämlich für eine gewisse Zeit keine Kommunikation über den Bus mehr statt, schaltet die SH von selbst ab, auch ohne Ende-Befehl. > Welche genaue Position hat Minuten? > Ist das dann eine normale Zahl zb 15 umgerechnet nach hex? Na, das hast Du doch in Deinem Beitrag schon selbst geschrieben: >Mein gsm interface sendet zum einschalten: >24 03 21 3c 3a 0x21 ist der Befehl "Standheizung EIN". Dieser erwartet einen ein-byte Wert, nämlich die Laufzeit. In Deinem Fall entsprechen 0x3c dann dezimal 60, also 60 Minuten. Die maximale Laufzeit beim Start durch ein "T60" beträgt jedoch nur 30 Minuten (0x1E). Mehr lässt die interne Steuerung garnicht zu, bzw. schaltet dann selbst ab.
:
Bearbeitet durch User
Ich frag mich nur..... Wie funktioniert das ohne wbus wenn du per telestart t60 t70 t80 gestartet hast... Dan kannst du an der Uhr..1530 1533 mit 2 mal soforzheizen drücken auch ausschalten
Alex h. schrieb: > Ich frag mich nur..... Wie funktioniert das ohne wbus wenn du per > telestart t60 t70 t80 gestartet hast... Dan kannst du an der Uhr..1530 > 1533 mit 2 mal soforzheizen drücken auch ausschalten Die W-Bus Leitung müsste doch dann auch zumindest zwischen Uhr und Telestart verbunden sein. Vielleich erkennt die Telestart an dem durch die Uhr ausgelösten Busreset das sich da was tut was nur von der Uhr kommen kann. Sascha
Ich krig sie nicht zum laufen... Es schaltet sich immer einfach ab! Es ist alles richtig verdrahtet... Irgendwas stimmt mit meinem Code einfach nicht.. Sascha arbeitest du vllt mit der normalen arduino Idee?
Ich glaube ohne heizgerät kann man den wbus nicht simulieren. Nicht anhand serialen traffic ausgehend von einem Chip. Heisst.. Man braucht wohl ein 2. Arduino der wirklich nur als Heizung immer antwortet. Oder andere Ideen? Ohne ein heizgerät geht nix auf dem wbus. Nehmen ich ein heizungssteuergerät mit wbus und klemmt ihn an meine Schaltung geht das! Dann kann ich mit der Uhr starten und die springt sofort auf tele on! Ausschalten geht auch an der Uhr oder per GSM! Aber ohne wbus heiz Steuergerät keine Chance!
Kann mir mal jemand sagen wie ich den 0x44 command check richtig aufbaue? 0xf4 0x03 0x44 0x?? 0xchecksumme Danke .. krig langsam ne krise
Ich habe Grade aufem Bus mitgelesen .... Ohne GSM ohne wbus Simulation Uhr an kommt : 34 03 21 1e 08 ..ok Darauf kommt die Antwort: 43 03 a1 1e ff ... Dann kommt von der uhr: 34 04 44 21 00 55 Darauf wieder: 43 03 c4 ff 7b Dann: 34 03 56 04 65 Usw... Dann leuchtet F auf der Uhr Also irgendwas Haut hier nicht hin!
Getreu dem Motto: "Alle Jahre wieder..." fange auch ICH immer wieder mit dem Standheizungsthema an, wenn es kalt wird :-) Quasi als Gedächtnisstütze und Nachschlagewerk habe ich hier auf meiner Website eine Übersicht zum W-Bus begonnen. http://mk4-wiki.denkdose.de/grundlagen/w-bus/start Für rege Teilnahme, Erweiterung, Fehlerkorrektur bin ich jederzeit offen. @Sascha, @MichaR: Ihr beide seid natürlich herzlich eingeladen auf diesen Seiten als Autor/Korrektor tätig zu werden! Einfach anmelden und ich schalte euch frei!
Alex h. schrieb: > Kann mir mal jemand sagen wie ich den 0x44 command check richtig > aufbaue? > 0xf4 0x03 0x44 0x?? 0xchecksumme 0xF4 Tele -> HZ 0x04 4 Byte Länge 0x44 Check CMD 0x21 Code des Kommandos das geprüft werden soll (0x21 Heizen) 0x00 immer 0 <CS> > Ich habe Grade aufem Bus mitgelesen .... > Ohne GSM ohne wbus Simulation > > Uhr an kommt : > 34 03 21 1e 08 ..ok Uhr an HZ; Heizen für 30min > Darauf kommt die Antwort: > 43 03 a1 1e ff ... HZ an Uhr; OK Heizen für 30min > Dann kommt von der uhr: > 34 04 44 21 00 55 Uhr an HZ; Check CMD 0x21 > Darauf wieder: > 43 03 c4 ff 7b HZ an Uhr; Fehler ff passt nicht muss 0 sein > Dann: > 34 03 56 04 65 Uhr an HZ; Fehler abfragen > Usw... was kommt da? > Dann leuchtet F auf der Uhr logisch Sascha
Poste ich gleich! Irgendwie krig ich dein Simulator nicht zum laufen.. Hast du eine Anleitung?
Alex h. schrieb: > Poste ich gleich! hast du jetzt noch eine Heizung mit W-Bus? > Irgendwie krig ich dein Simulator nicht zum laufen.. was geht denn nicht? Am besten aus dem Editor heraus starten, dann gibts unten in der Ausgabe noch einige Meldungen > Hast du eine Anleitung? nein Sascha
Nein nur ein Steuergerät einer thermotop c mit wbus...Daher auch mein Fehler! Mit 1533 Uhr am wbus plus Interface plus deiner software geht das jetzt endlich mal. Kann ich mit deiner Software auch telestart simulieren? Sehen wahrscheinlich!aber auch senden?
Alex h. schrieb: > Nein nur ein Steuergerät einer thermotop c mit wbus...Daher auch mein > Fehler! ok > Mit 1533 Uhr am wbus plus Interface plus deiner software geht das jetzt > endlich mal. > > Kann ich mit deiner Software auch telestart simulieren? > > Sehen wahrscheinlich!aber auch senden? hab mal die Software mal noch etwas erweitert ... Sascha
Mein Problem ist jetzt.... Wenn ich an der Uhr ne andere Zeit angebe...verreckt wieder alles.. Heisst ich muss in meiner Programmierung...Die checksumme berechnen und dann antworten! Nur muss ich mich erstmal belesen!
Alex h. schrieb: > Mein Problem ist jetzt.... Wenn ich an der Uhr ne andere Zeit > angebe...verreckt wieder alles.. > > Heisst ich muss in meiner Programmierung...Die checksumme berechnen und > dann antworten! logisch > Nur muss ich mich erstmal belesen! ist ne einfache 'ver-x-oderung' Sascha
Für schnelle Tests hatte ich mir mal ein Checksum-Tool geschrieben, vielleicht hilfts: http://mk4-wiki.denkdose.de/tools/w-bus/checksum.php
Hallo Olli, Olli Z. schrieb: > Getreu dem Motto: "Alle Jahre wieder..." fange auch ICH immer wieder mit > dem Standheizungsthema an, wenn es kalt wird :-) läuft's denn nun in der neuen Saison? Sascha
Sascha W. schrieb: > läuft's denn nun in der neuen Saison? Im Prinzip ja, bzw. auf der Musterplatine. Dann wollte ich aber doch eher eine CAN-Version basteln und bin wieder vom Weg abgekommen... so hab ich nun beides nicht fertig (grr. "arschbeiß").
Du Sascha..... Was soll mir .. rx:Echo sagen?! Wenn ich tele heizen klicke hab ich das beim senden Check cmd... Danke
Das er das echo empfängt... Alles, was du auf den wbus schreibst, ließt du ja auch wieder zurück...
Sascha W. schrieb: > wenn du als "Absender" Adresse 2 nimmst dann wird das Einschalten der > Heizung auch auf der 1533-Uhr als "Telestart Ein" angezeigt und die > Heizung lässt sich mit der Uhr auch wieder aussschalten. Ist das nicht das Problem von Alex? Er will doch mit der Uhr die SH ausmachen, wo sie aber vom Telestart aktiviert wurde, richtig? Natürlich muss der Telestarter auch diesen Ausschaltbefehl von der Uhr erkennen und seine Keepalives entsprechend auswerten. Der sollte ja dann kein 0x44 0x21 0x00 sondern ein 0x44 0x21 0xFF bekommen. Selbstverständlich sollte der Telestart nicht ständig einen Einschaltbefehl senden. Den gibt es nur einmal und nachfolgend dann die Keepalives (0x44).
Weil es nicht 0x00 ist... ;-) Da es anscheint ja mal wieder untergegangen ist, alles was man brauchst steht hier drin: https://sourceforge.net/p/libwbus/libwbus/ci/master/tree/webasto_wbus.txt Und wenn jetzt jemand etwas weiß, was da nicht drin steht, wäre ich stark dafür es DORT nachzupflegen vorausgesetzt, das mjander da mitspielt...
Alex h. schrieb: > Warum ff?! Hier, aus Deinem Protokoll: Alex h. schrieb: > Darauf wieder: > > 43 03 c4 ff 7b > > Dann: > > 34 03 56 04 65 Damit ist klar, das die Antwort auf 0x44 (0xC4) nicht immer nur statisch 0x00 enthält, sondern wohl auch was anderes. Gesehen habe ich schon 0x01 und 0xFF (wie bei Dir). Aus der Tatsache das die 1533 nach dieser Antwort eine Fehlercodeabfrage (0x56) durchführt schließe ich, das ein Ergebniswert != 0x00 einen Fehler darstellt. Also ist 0x44 kein reines Keep-Alive, sondern eine Statusabfrage, welche wiederum ein Ergebnis liefert das es auszuwerten gilt.
Also ich hab mein Simulator aufem arduino fertig... läuft sauber! Problem..... Sobald ich an der Uhr ne andere Zeit als 30 Minuten angebe.... läuft es mit der Uhr nicht... Ich krig die checksummeNachricht Berechnung nicht hin so wie das ermitteln der Zeit die die Uhr sendet.... Wenn mir da jemand helfen könnte wäre es super toll
Hallo, ich klinke mich einfach mal kurz mit ein. Kann mir jemand sagen ob generell alle TT C den W-Bus besitzen? Meine ist von 2006 und ich frage mich ob er dort vorhanden ist oder die Diagnose anders funktioniert. Hintergrund ist natürlich das ich egal womit oder was ich mich verbinden möchte, ich keinerlei Reaktion von der SH bekomme. Schon mal danke im voraus. LG Markus
Alex h. schrieb: > Also ich hab mein Simulator aufem arduino fertig... läuft sauber! > > Problem..... > > Sobald ich an der Uhr ne andere Zeit als 30 Minuten angebe.... läuft es > mit der Uhr nicht... Ich krig die checksummeNachricht Berechnung nicht > hin so wie das ermitteln der Zeit die die Uhr sendet.... ganz einfach: > 34 03 21 1e 08 0x34 XOR 0x03 = 0x37 0x37 XOR 0x21 = 0x16 0x16 XOR 0x1E = 0x08 > 43 03 a1 1e ff 0x43 XOR 0x03 = 0x40 0x40 XOR 0xa1 = 0xE1 0xE1 XOR 0x1E = 0xFF Du verküpfst also alle Bytes (ausser der Checksumme - die weißt du ja noch nicht oder 0x00 annehmen) nacheinander per XOR. Du kannst auch mit 0x00 beginnen und mit dem 1.Byte verknüpfen. Beim Empfang verknüpfst du alle Bytes incl. Checksum und muss 0x00 erhalten. pseudocode ...
1 | checksum=0 |
2 | cmddata=(0x34,0x03,0x21,0x1e,0x00) |
3 | for i=0 to len(cmddata)-1 |
4 | checksum=checksum xor cmddata(i) |
5 | next |
6 | cmddata(len(cmddata)-1)=checksum |
Sascha
:
Bearbeitet durch User
Ich muss leider die BREAK-Problematik nochmal ausgraben. Prinzipiell wissen wir ja, das man zum initiieren einer Kommunikation die Teilnehmer am W-Bus "wecken" müssen. Hierzu sendet man ein BREAK bestehend aus einer 25ms langen LOW-Phase, gefolgt von einer 25ms langen HIGH-Phase auf der TX-Leitung. Mit einem uC ist das kein Problem, da programmiere ich den UART als Digital-IO Pin um, stelle den LOW und wieder HIGH und dann zurück auf UART-Modus. Aber wie zum teu*** bekomme ich sowas mit einer seriellen hin? Vor allem, wenn die Serielle nur virtuell ist, also z.B. über USB oder TCP gebridged wird? Zwar könnte man die DTR/CTS-Signal sicherlich dafür zweckentfremden indem man die über einen Transistor die TX-Leitung ziehen lässt, aber das wiederum muss die Software ja auch so ansteuern :-) Wie macht das denn die WTT-Software über den stinknormalen COM-Port? Im Internet bin ich darauf gestoßen, das man mit der Funktion "tcsendbreak()" (http://linux.die.net/man/3/tcsendbreak), welche in "termios.h" definiert ist, ein BREAK erzeugen kann. Dies ist auch in der MAN-page von tty_ioctl (http://linux.die.net/man/4/tty_ioctl) so beschrieben. Dabei kann beim Aufruf die Länge des BREAK eingestellt werden. Was ich nicht ermitteln konnte ist, ob dies nur für lokale COM-Ports gilt, oder auch bei remoten/virtuellen COMs möglich ist.
Also irgendwo stand mal, das man einfach die Baudrate so niedrig dreht, das ein Senden von 0x00 den 25ms low entspricht... Danach stellt man sie wieder richtig ein und fängt an mit der Heizung zu reden... Edit: Müsste gehen - probiert hab ichs aber nie...
:
Bearbeitet durch User
Hallo Olli, ich hab das gerade mal mit einem USB-Adapter mit FTDI-Chipsatz getestet. Unter Python mit pySerial gibts: sendBreak(Duration=0.25) egal welchen wert man übergibt -> macht 250ms LOW setBreak(True) setzt TXT auf LOW setBreak(False) gibt TXT wieder frei mit setBreak(True) sleep(0.025) setBreak(False) sleep(0.025) kann man also problemlos das Break erzeugen. Aber auch die Variante von Michael geht, hab mal 320 Baud eigestellt und ein 0-Byte gesendet macht 26ms. Die 1. Variante macht sich meiner Meinung nach aber besser. Sascha
Ok, was python angeht bin ich ein Noob :-/ Hier mein kläglicher Versuch in python einen SH-Simulator zu machen:
1 | import serial |
2 | import binascii |
3 | import time |
4 | import sys |
5 | |
6 | ser = serial.Serial('COM3', 2400, timeout=None, parity=serial.PARITY_EVEN)
|
7 | time.sleep(2) |
8 | ser.read(ser.inWaiting()) |
9 | ser.flush() |
10 | while 1: |
11 | addr = ord(ser.read(1)) |
12 | if(addr == 0x34): |
13 | len = ord(ser.read(1)) |
14 | cmd = ord(ser.read(1)) |
15 | if(cmd == 0x21): |
16 | min = ord(ser.read(1)) |
17 | print("1533 send 'start heater for %d minutes'" % min)
|
18 | chk = ord(ser.read(1)) |
19 | ans = b'\x43\x03\xA1\x1E\xFF' |
20 | ser.write(ans) |
21 | ser.read(5) |
22 | elif(cmd == 0x44): |
23 | print("1533 send 'check running'")
|
24 | ser.read(3) |
25 | ans = b'\x43\x03\xC4\x00\x84' |
26 | ser.write(ans) |
27 | ser.read(5) |
28 | else: |
29 | print("1533 send unknown command")
|
30 | s = 'ADDR=%s, LEN=%s, CMD=%s' % (hex(addr),hex(len),hex(cmd)) |
31 | #s = s + ' DATA: %s' % binascii.hexlify(ser.read(len)) |
32 | ser.read(len-1) |
33 | print(s) |
34 | else: |
35 | print("reading other bytes...")
|
36 | s = 'ADDR: %s' % hex(addr) |
37 | len = ord(ser.read(1)) |
38 | s = s + ' DATA: %s' % binascii.hexlify(ser.read(len)) |
39 | print(s) |
Immerhin schaffe ich es mit den Zeilen die Uhr am "leben" zu erhalten. Es wird der Einschaltbefehl (0x21) sowie die folgenden Erhaltungsbefehle (0x44) beantwortet. Damit bleibt das Flammensymbol im Display und die Zeit zählt von 30min runter bis 0. Bezüglich der Programmiersprache bin ich mir noch nicht sicher was ich nehmen sollte. Eigentlich würde ich schon gern python lernen wollen... komme eher aus der PHP-Ecke und tue mich mit OOP hart. Vielleicht versuche ich es eher mit C.
Hallo, ich bin ganz neu hier, habe in diesem Forum bisher nur lesen müssen um Hilfe bei meinen Projekten zu finden. Jetzt habe ich aber ein kleines Problem was ich nicht so lösen kann. Ich habe eine Thermo Evo 5 aus einem Golf 7 von 01.2013 drauf steht: Standheizung, 5Q0 815 005 L Diesel, SW:0066, HW:005. Wenn Ich das ding über die WTT(2.16) Software anspreche antwortet sie (mit Oszi gekuckt), aber die Software versteht das nicht, die gibt nur fehlermeldung wie Timeout und ungültige Frame oder Paketlänge. Kann es sein das die Heizung W-Bus V4.x von sich gibt und ich dafür WTT 3.x mit originalem Webasto USB-Inteface benutzen muß oder hat VW in den original eingebauten Heizungen ein anderes Protokoll verwendet? Habt Ihr da evtl. eine Idee was ich falsch mache? Gruß Lars
Hallo, Lars schrieb: > Ich habe eine Thermo Evo 5 aus einem Golf 7 von 01.2013 drauf steht: > Standheizung, 5Q0 815 005 L Diesel, SW:0066, HW:005. > > Wenn Ich das ding über die WTT(2.16) Software anspreche antwortet sie > (mit Oszi gekuckt), aber die Software versteht das nicht, die gibt nur > fehlermeldung wie Timeout und ungültige Frame oder Paketlänge. > > Kann es sein das die Heizung W-Bus V4.x von sich gibt und ich dafür WTT > 3.x mit originalem Webasto USB-Inteface benutzen muß oder hat VW in den > original eingebauten Heizungen ein anderes Protokoll verwendet Hast du eine 3'er Version getestet, oder findet die sich nicht zum Download? Die vom Fahrzeughersteller verbaute Heizung spricht zumindest mit dem Fahrzeug per CAN, die W-Busschnittstelle hat sie aber trotzdem. Was für einen Adapter verwendest du? An sonsten kannst du ja mal mit einem Terminalprogramm testen. Sascha
Hallo Sascha, die 3.0 habe ich probiert, die fragt erst welches Gerät man anquatschen will, wählt man W-Bus auf der linken Seite geht dann die V2.16 auf und ich kann über die Serielle den Bus ansteuern, da gibt es aber dann nur Fehler. Wählt man allerdings ein neues Gerät (TTEvo) von der rechten Seite, kann ich nicht kommunizieren da das Programm ab V3.0 nur noch über die USB-Snitstelle sprechen möchte. Ich habe einige USB-->RS232 Adapter probiert aber ohne Erfolg. Scheint als ob die SW nur mit originalen Adaptern von Webasto kommunizieren möchte, also so eine art Dongle. Alex h. schrieb weiter oben über die Thermo V, das die nur LIN-Bus hätte kann das bei der EVO evtl. auch sein? Gesteuert wurde die Heizung über Pin2 am Heizer lt. Unterlagen: W-Bus.(Stecker war noch am gelieferten Heizer) Zum Interface: Da hab Ich mir was mit 2 Transistoren gebastelt, die Signale sehen am Oszi aber recht gut aus.Das ganze steckt an einer echten com meines PCs. Was ich noch bemerkt habe ist, dass der Heizer nach einer längeren Zeit ohne Spannung beim einschalten sofort auf dem W-Bus redet, ist das normal? Dank und Gruß Lars
Hallo, da ich nicht aufgeben möchte habe ich weiter probiert und getestet. Via 2400 8E1 bekomme ich keine Reaktion, mit dem "Diagnose Protokoll?" über 10400 8N1 antwortet sie. Kann ich nun davon ausgehen das kein W-Bus vorhanden ist? Ich finde leider nichts darüber, würde den W-Bus jedoch gerne nutzen. Da ich es leider aktuell nicht schaffe den avr so zu programmieren das auch thermo test läuft, bin ich bei dem 10400 8N1 ohne jegliche Informationen etwas aufgeschmissen..
Lars schrieb: > Hallo Sascha, > > die 3.0 habe ich probiert, die fragt erst welches Gerät man anquatschen > will, wählt man W-Bus auf der linken Seite geht dann die V2.16 auf und > ich kann über die Serielle den Bus ansteuern, da gibt es aber dann nur > Fehler. ok, ich hab vor paar Jahren auch die 2.13 für meine Evo4 verwendet > Wählt man allerdings ein neues Gerät (TTEvo) von der rechten Seite, kann > ich nicht kommunizieren da das Programm ab V3.0 nur noch über die > USB-Snitstelle sprechen möchte. Ich habe einige USB-->RS232 Adapter > probiert aber ohne Erfolg. Scheint als ob die SW nur mit originalen > Adaptern von Webasto kommunizieren möchte, also so eine art Dongle. kann schon sein, oder es wird einfach eine spezielle Geräte-ID erwartet > Alex h. schrieb weiter oben über die Thermo V, das die nur LIN-Bus hätte > kann das bei der EVO evtl. auch sein? Gesteuert wurde die Heizung über > Pin2 am Heizer lt. Unterlagen: W-Bus.(Stecker war noch am gelieferten > Heizer) elektrisch ist der LIN-Bus auch nichts anderes. Bei einem Bekannten der auch einen Zuheizer zur SH 'hochrüsten' hat lassen wurde außer der 1533'er Uhr noch irgend ein Zusatzmodul eingebaut - sollte dort erdt der W-Bus zur Verfügung stehen? > Zum Interface: > Da hab Ich mir was mit 2 Transistoren gebastelt, die Signale sehen am > Oszi aber recht gut aus.Das ganze steckt an einer echten com meines PCs. Wenn du per Terminal was sendest sollte es ja erst mal korrekt als Echo zurückkommen. Kannst du auf dem Bus was mitlesen wenn die Heizung vom Auto gestartet wird? > Was ich noch bemerkt habe ist, dass der Heizer nach einer längeren Zeit > ohne Spannung beim einschalten sofort auf dem W-Bus redet, ist das > normal? keine Ahnung Sascha
Hallo Sascha, das Echo ist ok, auch noch bei 256000 Baud. der Heizer ist vom Verwerter und liegt bei mir auf dem Tisch, ich habe leider kein funktionierendes Heizsystem zum lauschen.Ich wollte bevor ich an meinem Auto schraube erstmal sehen ob die Heizung in Ordnung ist. Die Umbausätze im Netz haben soweit ich weis, noch diese IPCU zur Lüftersteuerung dabei, die wollte ich mir aber selber bauen. Lars
Lars schrieb: > das Echo ist ok, auch noch bei 256000 Baud. Das Echo von den eigenen Daten zu empfangen zeigt ja nur das Deine Schnittstelle funktioniert. Die macht ja, egal ob Transistor-Pegelwandel oder echter LIN-Tranceiver, nichts anderes als die RX und TX-Leitung zu verbinden. Natürlich klappt das grundsätzlich bei jeder Baudrate. Die Frage ist ja, ob Du wirklich mit der SH-Elektronik reden kannst. Sprich Du sendest Kommandos und erhälts nicht nur Dein Echo sondern wirklich eine Antwort von der SH. Ich würde Dir empfehlen die ältere WTT (bis v2.14) zu nutzen, dort funktioniert der W-Bus einwandfrei über einen COM. Und der ist 2400 8E1. Alles andere wäre eine für einen Hersteller modifzierte Firmware der SH (gibt es durchaus).
Hallo, ich habe nochmal wild mit dem Oszi herrumgestochert, es scheint als ob meine Heizung ein LIN Protokoll verwendet, nach dem Anlegen der Ub kann man Sync-Break, Sync-Field, Identifier und Daten erkennen. Sieht so aus wie da: http://infosys.beckhoff.com/content/1033/el600x_el602x/1688837003.html Die Heizung versucht wohl herauszufinden wer am Bus hängt. Da ist jetzt für mich erstmal Endstation. Vielen Dank für eure Unterstützung. Gruß Lars
Die thermotop v hat LinBus ja... Aber Du kannst eine 1533 Uhr betreiben .. Du musst aber 2 mal drücken für an damit der Bus aufwacht. Die v hat werksseitig (vw bmw etc) immer ein slave der wecken kann. Heisst die telestart thermocall etc module vom Hersteller wecken richtig. Dazu kommt eine 2. Busleitung fürs Gebläse! Hast du zb eine c oder evo mit wbus und eine 1533 Uhr gibst du dich als telestart aus und alles funktioniert. Bei den V Geräten geht das nicht. Trotzdem empfiehlt es sich das breaksignal zu senden um sauber den Bus zu wecken. Ich simuliere momentan mit einem arduino die Uhr telestart und das heizgerät... Alles funktioniert sauber... Mach ich per arduino (gsm) Heizung ss tart zeigt mir das die 1533 an und das heizgerät läuft auch... Ohne break!
Lars hast du vcds? Schalte mal deine standheizung frei! Du kommst zb bei den Mercedes Heizungen nur über den canbus rauf.... Nach Freischaltung funktioniert der wbus... Musst dich sonst genauer belesen wie man das macht!
Ansonsten 8pin stecker weg und direkt den wbus anzapfen... Kann sein das der canbus dir alles klaut
Kann man eigentlich eine 1533 auch irgendwie "erwecken"? Die geht ja normalerweise nach einiger Zeit aus. Gibt es irgendwelche W-Bus Kommandos mit denen man etwas auf dem Display anzeigen kann? Ich glaube hier war mal die Rede von "TELE ON" oder sowas, wenn die Uhr einen Startbefehl des GSM-Moduls erkennt. Hat dazu mal jemand eine Beispielkommunikation?
Olli Z. schrieb: > Kann man eigentlich eine 1533 auch irgendwie "erwecken"? Die geht ja > normalerweise nach einiger Zeit aus. Gibt es irgendwelche W-Bus > Kommandos mit denen man etwas auf dem Display anzeigen kann? Ich glaube > hier war mal die Rede von "TELE ON" oder sowas, wenn die Uhr einen > Startbefehl des GSM-Moduls erkennt. Nun das anzeigen von TELE ON macht sie sebständig indem sie passiv auf dem Bus lauscht. Glaube nicht das es da was gibt was man direkt an die Uhr senden kann um auf dem Display was anzuzeigen. > Hat dazu mal jemand eine Beispielkommunikation? Die Uhr reagiert einfach auf einen normalen Einschaltbefehl von der Telestart an das Heizgerät bzw. auf dessen Bestätigung. Sascha
Sascha W. schrieb: > Die Uhr reagiert einfach auf einen normalen Einschaltbefehl von der > Telestart an das Heizgerät bzw. auf dessen Bestätigung. Stimmt! Habs gerade probiert. Testaufbau ist nur mein "WiFi W-Bus Sender" und daran angeschlossen die 1533. Beim Einschaltbefehl 24 03 21 1E 18 passiert an der Uhr erstmal noch nix. Sende ich darauf eine simulierte Bestätigung der SH 42 03 A1 1E FE Springt das Display der Uhr an, es wird das "Flammsymbol" dargestellt und im Display wechelnd "tele" und "on" angezeigt. Sendet man nicht innerhalb von 20 Sekunden weitere Bestätigungsnachrichten, geht die Anzeige wieder aus. Achja, ein BREAK braucht es hierzu nicht.
Alex h. schrieb: > Ich simuliere momentan mit einem arduino die Uhr telestart und das > heizgerät... Alles funktioniert sauber... Kannst du bitte dein Projekt vorstellen.
Bislang habe ich die Sende- und Empfangsroutinen eher pragmatisch
behandelt. Ich habe nun versucht diese "kugelsicher" zu machen. Mag
etwas übertrieben sein, aber mir geht es um den theoretischen Ansatz
dabei :-)
==== Datenübertragung auf dem W-Bus ====
Auf dem W-Bus werden Nachrichten (Frames) immer zusammenhängend am Stück
übertragen. Es ist keine Pause zwischen dem Beginn einer Übertragung und
deren Ende vorgesehen. Ein Sync-Signal um den Beginn eines Frames
anzuzeigen, ist nicht vorgesehen.
Da W-Bus ein Eindraht-Bus ist, sind die RX- und TX-Leitungen miteinander
verkoppelt. Jeder Teilnehmer liest gleichzeitig auch was er sendet. Vor
dem senden sollten die Busteilnehmer prüfen ob die Leitung frei ist.
Dies kann angenommen werden, wenn innerhalb einer Zeit X keine Bytes am
eigenen Eingang einlaufen.
Dennoch kann es zu Kollisionen kommen, wodurch Datenpakete "verstümmelt"
übertragen/empfangen werden. Hiergegen schützt zum einen das
Paritäts-Bit innerhalb eines jeden Bytes während der Übertragung, aber
auch das Prüfsummen-Byte (CHK) am Ende eines Frames. Ein Empfänger muss
eine Nachricht verwerfen, wenn beim Empfang eines Bytes ein
Paritätsfehler auftritt, oder wenn die Prüfsumme des Frames nicht
stimmt. Um die Prüfsumme zu berechnen muss ein Frame vollständig
empfangen worden sein. Hier gilt es aus dem empfangenen Datenstrom das
Frame zu ermitteln. Da ein Empfänger nicht zwangsläufig den Beginn einer
Kommunikation mitbekommt, muss er seinen Eingangspuffer auf mögliche
Frames untersuchen.
Ein Frame besteht aus einer Absender- und Empfängeradresse, kodiert in
einem Adress-Byte (ADDR). Darauf folgt ein Datenlängen-Byte (LEN),
welche die Anzahl der nachfolgenden Bytes bestimmt. Dem folgt wenigstens
ein Kommando-Byte (CMD) und letztlich noch das Prüfsummen-Byte (CHK).
ADDR LEN CMD CHK
Das kleinstmögliche Frame besteht also aus 4 Bytes, wobei LEN mindestens
den Wert 0x02 haben muss.
Das größtmögliche Frame ergibt sich aus dem LEN-Byte, welches maximal
0xFF sein kann, also 255 Bytes. Dem hinzurechnen muss man das ADDR und
LEN-Byte selbst. Somit kommt man auf maximal 257 Bytes pro Frame.
ADDR LEN CMD DATA... CHK
==== Die RX-Buffer Serviceroutine ====
Der W-Bus wird über einen Pegelwandlerbaustein mit dem UART eines
Controllers verbunden. Die UARTs besitzen meist nur einen kleinen
Eingangspuffer (FIFO) von wenigen Bytes. Die übertragenen Daten (Frames)
sind in der Regel größer als dieser Hardware-Puffer. Um einen Überlauf
und damit einen Datenverlust zu vermeiden, müssen die eingehenden Bytes
regelmäßig in einen weiteren Eingangspuffer im (größeren)
Arbeitsspeicher des Controllers umgeladen werden.
Diese Aufgabe übernimmt eine Serviceroutine, die idealerweise unabhängig
von anderen Abläufen im Hintergrund über einen Interrupt aufgerufen
wird. Das auslösende Signal kann ein einfacher Timer ab auch eine
Eingangserkennung oder Puffer-Voll-Meldung vom UART sein.
==== Die Nachrichten-Erkennungs-Routine ====
Um nun innerhalb des Eingangsdatenstromes ein gültiges Frame zu finden
geht man wie folgt vor:
1. Sind mind. 4 Bytes im Empfangsbuffer vorhanden?
Nein => Dann Rücksprung (warte bis mehr Bytes eintreffen)
2. Lese zweites Byte im Eingangspuffer als LEN-Byte. Ist dieses größer
0x02?
Nein => Ungültige Länge, vermutlich ist das Byte nicht das
LEN-Byte. Entferne das erste Byte aus dem Eingangspuffer und starte
erneut bei 1.
3. Enthält der Eingangsbuffer mindesten LEN + 2 Bytes?
Nein => Wurde länger als X Millisekunden nichts mehr empfangen?
Ja => Vermutlich ist das gelesene Byte kein LEN-Byte.
Entferne das erste Zeichen aus dem RX-Buffer und starte erneut bei 1.
Nein => Rücksprung (warte bis mehr Bytes eintreffen)
4. Lese das CHK-Byte am Ende des Frames (Position LEN + 2 - 1).
Berechne die Prüfsumme des Frames (alle Bytes, beginnend mit dem
ADDR-Byte, jedoch ohne das CHK-Byte selbst miteinander XOR verknüpfen).
Stimmt die berechnete Prüfsumme mit dem CHK-Byte überein?
Nein => Ungültiges Frame empfangen oder falsche Bytepositionen
angenommen. Entferne das erste Byte im RX-Buffer und starte erneut bei
1.
5. Gültiges Frame empfangen. Parse ADDR, CMD, Datenrichtung (Anfrage
oder Antwort) und DATA in eine interne MSG-Struktur und entferne die
verarbeiteten Bytes aus dem RX-Buffer.
Irgendwann hat man damit dann mal ein gültiges Frame erkannt und kann es
verarbeiten!
P.S.: Natürlich stelle ich diese, wie auch alle weiteren Informationen zur W-Bus Hardware, Software, Grundlagen auf meiner Homepage zur Verfügung: http://mk4-wiki.denkdose.de/grundlagen/w-bus/
:
Bearbeitet durch User
Eigentlich ist das nix anderes als auf bestimmte Bytes kontrollieren..... Ich z.b. beziehe mich auf längen Byte.... Das plus richtiger Sender bzw Empfänger plus stimmende checksumme.. ergeben dann überhaupt eine interessante Nachricht.... Mein Problem war meine Uhr mit meinem Gsmmodul so zu koppeln und die nicht wbus Heizung gleichzeitig zu simulieren. Funktioniert jetzt perfekt! Sogar mit Diagnose nebenbei!
Kann es sein, das man zwischen zwei Kommandos (z.b. IDENT-Abfragen mit 0x51) eine gewisse Zeit warten muss? In meinen Versuchen wollte ich zwei oder mehr Kommandos gleich hintereinander wegschicken und die Antwort gesammelt lesen. Ich vermute aber das die W-Bus Schnittstelle in der WTT das nicht verkraftet und ich immer auf die Antwort warten muss bis diese vollständig angekommen ist. Das mag an meiner Implementation liegen, daher die Frage ob Euch sowas schon aufgefallen ist, oder ihr das problemlos machen könnt?
Also manchmal machst du mich echt schwach! ;-) Du hast doch selbst schon festgestellt, das man alles, was man auf den Bus schickt selbst wieder empfängt... Was passiert also, wenn du was schickst, während die die Heizung auf dein letztes Kommando antwortet? ;-)
Ups, Danke Michael. Wie konnte ich das vergessen! :-/ (peinlich) Aber noch was anderes: Gibt es ein Timing in dem die Bytes eintreffen müssen um als gesamte Nachricht erkannt zu werden? Ich habe eine Senderoutine die jedes Byte nach dem senden zurückliest und vergleicht. Manchmal klappt das nicht und wenn ich die Nachricht komplett schreibt und komplett zurücklese geht es. Scheinbar dauert da was zu lange. Muss dazu sagen das ich das derzeit über eine WLAN/Serial Bridge mache.
:
Bearbeitet durch User
Michael R. schrieb: > Probiers mal ohne den WLAN Kram dazwischen... Naja, wenns halt nicht so saukalt wär draussen im Auto... ;-) Für die Bridge nutze ich nen ESP-01 mit esp-link Firmware. Das Break erzeuge ich mit einer eigenen Erweiterung des NVT protokolls um BRK-ON und BRK-OFF Befehle. Im "Labor" mit ner 1533 lief das problemlos. Aber die scheint nicht so zickig zu sein wie die TTV. Ich glaub ich muss nach dem Break noch irgendwie den Framefehler vom UART resetten und sicherheitshalber auch den RX FIFO leeren.
Olli Z. schrieb: > Aber noch was anderes: Gibt es ein Timing in dem die Bytes eintreffen > müssen um als gesamte Nachricht erkannt zu werden? Dürfte sich an ISO9141 orientieren. Dazu gibt es Bücher von Schmidgall und Schäffer. Helfen vermutlich auch bei einigen anderen Fragen.
Nett schrieb: > Dürfte sich an ISO9141 orientieren. Ja, da hast Du wohl recht. W-Bus basiert auf LIN und LIN wiederum auf ISO 9141. Die aktuelle Fassung davon ist die ISO 14230 und da habe ich hier http://blog.perquin.com/blog/category/odbii/ folgendes gefunden zu den Timings: 0-20 ms for inter byte timing in ECU response 5-20 ms for inter byte time in tester request 25-50 ms time between end of tester request and start of ECU response or between ECU responses Übertragen bedeutet das, die Bytes einer Nachricht dürfen nicht länger als 20ms voneinander "entfernt" sein, um noch als zugehörig erkannt zu werden. Meine eigenen Experimente bestätigten das. Ich hatte in meiner Senderoutine Zeichen für Zeichen gesendet und wieder eingelesen. Da das ganze mit Python und über WLAN lief, war die Latenz so hoch, das ich auf mehr als 20ms kam und somit die Nachricht nicht erkannt wurde. Durch weglassen des Echo-Empfangs und einfügen von sleep() konnte ich die Zeit auf 15ms reduzieren und da klappte es wieder. Das dürfte damit wohl belegt sein. Bedeutet ebenfalls für meine Empfangsroutine, das nach mehr als 20ms Ruhe auf dem Bus (kein RX mehr) eine Nachricht als vollständig empfangen angesehen werden kann. Dann erfolgt eine Validierung des Frame (LEN-Byte -> Lanäge ok?, CHK-Byte -> Checksum ok?). Ggf. den ganzen RX-FIFO leeren und auf die nächste Nachricht warten. Die Zeit zwischen einer Anfrage und einer Antwort könnte kritisch sein, denn man muss bei einer Anfrage von der SH zusehen die Antwort innerhalb von 50ms zu geben, sonst wartet sie vielleicht nicht mehr drauf! Ebenfalls zu prüfen wäre noch dies: 55-5000 ms time between end of ECU response and start of new tester request, or time between end of tester request and start of new request if ECU doesn't respond Da steht, das zwischen einer abgeschlossenen Anfrage/Antwort mind. 55ms vergehen müssen und max. 5s liegen dürfen. Das könnte bedeuten, das nach 5s die SH keine Abfragen mehr erwartet und sich wieder schlafen legt. Dann müsste man wieder ein BREAK senden. In meinen Tests mit 1533 und meiner Software am W-Bus konnte ich feststellen, das die Uhr gern mal "dazwischenquatscht": 00 -> BREAK von mir F4 03 21 1E C8 -> Startbefehl von mir 4F 03 A1 1E F3 <- Heizung bestätigt den Start 34 02 10 26 -> Die 1533 sagt "Mach mal aus!" 43 02 90 D1 <- Heizung macht das auch :-( Meine nachfolgenden Startbefehle werden ignoriert. 00 F4 03 21 1E C8 F4 03 21 1E C8 F4 03 21 1E C8 Dann geht erstmal garnichts mehr auf dem Bus, so als wär die SH bockig. Habs noch nicht raus aber es dauert lange Zeit bis die SH dann wieder mit mir reden will.
Also ich weiß nicht, was du mit deiner "Analyse" des Zeitverhaltens bezwecken willst... Durch deine WLAN Bridge dazwischen ist das kein bisschen Aussagekräftig! Die meisten "Einschränkungen" und Fehler, die du so findest, werden bedingt durch deine WLAN Spielerei sein und haben mit dem eigentlichen W-Bus reichlich wenig zutun... Also wenn du das was analyzieren willst, dann doch bitte direkt am Bus - dann verhält sich das auch alles richtig und du musst keine komischen Vermutungen anstellen... Denn direkt am W-Bus kannst du sehr wohl sofort dein gesendetes Byte zurück lesen und da vergehen dann auch keine 20 oder 15ms... Das ist einfach ein verkorkster Aufbau, den du da fährst... Du müsstest eher einen µC im Auto per WLAN flashen und dann testen, wie übers WLAN zu kommunizieren... Zu deinem "Problem" mit der Uhr... Wenn dir Heizung gesagt bekommt, das sie abschalten soll, macht sie das... Da kannste nicht einfach sagen, das du dir das anders überlegt hast - die fährt dann runter und erst danach kannst du sie wieder starten... Wenn du den Status während deinem obrigen Beispiel auslesen würdest, würdest du sehen, das du sie wieder einschalten kannst, nachdem sie wirklich abgeschaltet hat. Einfach nur blinde Befehle abfeuern, ohne zu wissen, was die Heizung grade macht oder welchen Zustand sie hat, bringt dich halt leider nicht weiter bzw. zu keinem zuverlässig laufenden System... Und aus reiner Neugierde, warum bastelst du mit Python rum? Das kann man ja nichtmal später auf den AVR portieren, so das du das ganze dann nochmal neu machen darfst... :-o Viele Grüße Michael
Klar kann man nicht einfach nur Befehle drauf losfeuern. Mir ging es dabei auch in erster Linie nur darum sicher mit der SH zu kommunizieren. Ich habe nämlich seit langem das Problem das meine Heizung nicht immer quatschen will wenn ich will. Ich warte immer ca. 10 Minuten, dann initiiere ich eine Abfrage, irgendwas unverfängliches wie die Sensorwerte. Manchmal erhalte ich ohne BREAK sofort eine Antwort. Manchmal muss ich erst eine weitere Anfrage senden. Manchmal braucht es ein BREAK und mitunter tut sich auch trotz BREAK und mehrfacher Wiederholung einfach nichts. Dieses Problem habe ich noch nicht im Griff und es hat rein garnichts mit WLAN zu tun, denn das ist auch direkt am W-Bus so. Ich habe am W-Bus über einen MC33660 nen ESP-01 mit esp-link dran. Zusätzlich hatte ich mal noch einen Laptop mit Logicanalyzer am RX/TX zwischen ESP und Bustreiber um die Timings zu analysieren. Da bin ich dann drauf gekommen das mein Inter-Byte-Timing schlecht war, ok, gelöst. Sonst ist aber alles tutti und ich kann meine Tests bequem im Warmen machen :-) Danke und liebe Grüße, Oliver P.S.: Beim auslesen der Sensoren (0x50 mit 0x05) ist mir aufgefallen, das die Temperatur erst nach zwei bis drei Abfragen richtig ist:
1 | 0 ---- 21:37:20 -------------------------------- |
2 | [7°C] [12.62 V] [0] [0 W] [0.2 Ohm] |
3 | 1 ---- 21:37:24 -------------------------------- |
4 | [9°C] [12.62 V] [0] [0 W] [0.2 Ohm] |
5 | 2 ---- 21:37:29 -------------------------------- |
6 | [10°C] [12.60 V] [0] [0 W] [0.2 Ohm] |
7 | 3 ---- 21:37:33 -------------------------------- |
8 | [10°C] [12.60 V] [0] [0 W] [0.2 Ohm] |
9 | 4 ---- 21:37:37 -------------------------------- |
Und das hat auch nichts mit WLAN zu tun, ist beim direkten Bus auch so.
:
Bearbeitet durch User
Wenn die Thermotest beim Start einer ThermoTopV (originaleinbau im Fahrzeug, jedoch nur als Zuheizer) als Standheizung (CMD 0x21) meldet "ungültiger Befehl Heizgerät verriegelt", was bedeutet das dann in der Konsequenz? Muss die Heiznung nun wieder "entriegelt" werden? Oder ist die Meldung nur unglücklich formuliert? Hat schonmal jemand erfolgreich die Kodierung der TTV so geändert das sie auch auf Befehle für Standheizungen reagiert?
Gibt es ein Abfragekommando welches immer denselben Wert liefert? Seriennummer, etc. ist ja überall unterschiedlich. Ich suche eine Methode um bei der Initialisierung zu erkennen ob da am W-Bus eine Heizung hängt und antwortet und zwar ohne ggf. den Heizstatus zu beeinflussen.
Nimm doch die Seriennummer oder irgendeinen Sensor oder so... Wenn keine Heizung da ist, bekommst du keine Antwort... Wenn eine da ist, bekommst du eine - der Inhalt ist ja egal...
Jo, hast recht. Die Antwort muss ja wenigstens mein Kommando mit gesetztem Bit 7 enthalten. Ich versuchs jetzt einfach mit der W-Bus Protokollversion, also: F4 03 51 0A AC Als Ergebniss kommt definitiv nur ein 1 Byte zusätzlich zurück, also z.B.: 4F 03 D1 0A 33 A4 Wesentlich wäre für mich "4F" damit die Adresse stimmt und "D1" weil es das "51" mit gesetzem ACK-Bit ist. Alles andere wäre für den einfachen Komm-Test egal. Das dürfte die Heizung, selbst wenn sie in Betrieb ist, nicht weiter stören.
Also ich frage nun die W-Bus Protokollversion ab. Das sollte jede Heizung kennen. Für das Ergebnis interessiere ich mich garnicht, nur das die Kommunikation funktioniert und ich beim Senden mein Echo empfange (=Schnittstellentest) und das meine Abfrage mit ACK-Bit bestätigt wird (=Kommunikationstest). Habe im "hintergrund" mit einem anderen Bastler Kontakt mit dem ich zusammen seinen VW Touran Zuheizer mithilfe eines Arduinos und L9637 betreibe. Die ThermoTop darin reagiert nur auf den Heizungsbefehl 0x23, wogegen meine im Mondeo nur auf 0x21 anspricht. Vermutlich lässt sich das irgendwie in der Heizung codieren...?! Ich überlege in meinem Code eine Art Typensuche zu implementieren um herauszubekommen auf welchen Heizungstyp die TTV reagiert die am W-Bus ist. Wenn ich den gefunden habe könnte ich es ins EEPROM speichern. Außer dem Startbefehl ist mir aber kein Kommando bekannt, welches sonst noch abhängig vom programmierten Heizungstyp ist. Geschweigedenn wo man diesen Typ irgendwie auslesen kann. Habt ihr hier nen Tipp?
Die Frage wäre: Warum willst du es in der Software automatisch unterscheiden? 0x21 => Standheizung 0x23 => Zuheizer Steht so doch schon in der txt... Für den Zuheizer braucht es eh noch eine Wasserpumpe - ansonsten geht der nach ein paar Minuten doch sowieso direkt wieder aus, weil das Wasser eben nicht zirkuliert... Ergo muss er die eh noch einbauen und von seinem Arduino aus ansteuern... Da wirds dann also einfacher sein, eine angeschlossene Pumpe am Arduino als den Typ der Heizung zu erkennen... Quizfrage wäre aber auch: Lehnt die Heizung anfragen, die sie nicht kennt/machen will nicht auch ab? Warum schickst du also nicht ein 0x21 hin und wenn es nicht positiv beantwortet wird ein 0x23 und schaltest die Wasserpumpe ein?
:
Bearbeitet durch User
Das mit der Pumpe stimmt natürlich. Deren Existenz müsste sich doch über die Bits im W-Bus-Code ermitteln lassen. Soweit ich das noch richtig in Erinnerung hab reagierte seine Heizung nicht auf 0x21, so wie meine nicht auf 0x23 reagiert. Da kam einfach keine Antwort. Aber das teste ich nochmal. Ebenso ob sich seine Pumpe mit 0x21 selbst anschaltet, oder ob man das zusätzlich senden muss, bzw. kann.
Hallo Olli, hast du mal versucht mit CMD 0x51 0x0C alias IDENT_WB_CODE auszulesen was die Heizung unterstützt? #define WB_CODE_0 0 /* Unknown supplemental heater feature */ #define WB_CODE_ON 3 /* on/off switch capability */ #define WB_CODE_PH 4 /* Parking heater capability */ #define WB_CODE_SH 5 /* Supplemental heater capability */ #define WB_CODE_VENT 6 /* Ventilation capability */ #define WB_CODE_BOOST 7 /* Boost capability */ da sollte doch Bit 4 & 5 die gewünscht Info liefern. Sascha
@Olli: Seine Pumpe wird nicht automatisch anlaufen, denn er hat garkeine... VW verbaut die Pumpe nur bei einer Standheizung... Denn der Zuheizer läuft nur, wenn der Motor läuft und dann braucht man keine zusätzliche Wasserpumpe (von einigen Fahrzeugen mit Kühlwassernachlauf usw. mal abgesehen - aber das wäre mir im Touran neu)... @Sascha: Sehr schöne Idee! Hatte ich garnicht im Kopf, was es so an Sensorwerten gibt...
Ja, Michael, das war auch mein erster Gedanke. Aber, again what learned ;-) die haben alle eine solche Pumpe verbaut. Ist bei Ford aber eigentlich nicht anders, denn meiner hatte ja auch nur Zuheizer. Die scheint beim Start der Zuheizung sogar anzuspringen (laut Aussage). Also kein Wärmestau. Einzig der Lüfter im Fahrzeug bleibt natürlich aus. Die Climatronic im VW ist also scheinbar nicht für SH Betrieb konfiguriert, oder die SH kann diese per CAN nicht steuern. Mit einem entsprechendem Softwareupdate wird wohl richtig Geld gemacht, wodurch einige sich einfach eine entsprechende SH kaufen, oder nur die Steuerplatine und die dann wechseln, weil da billger kommt. Ich hab bislang keine Idee wie ein solches Firmwareupdate aussehen könnte und ob man diese auch "kopieren" kann. Die Climatronic scheint die Klappen in der Stellung zu lassen, wie man den Wagen ausstellt. Daher die Idee den Lüftermotor direkt anzusteuern, das würde reichen.
Also früher hat VW sich die Pumpe wirklich gespart... Krass, das die die beim Touran dann immer reingeworfen haben (macht ja eigentlich beim reinen Zuheizer keinen Sinn)... Was die Climatronic angeht, zumindest im Octavia 1Z soll die normale Climatronic auch die Standheizung unterstützen, wenn von dieser die Befehle übern CAN kommen... Ich hab allerdings direkt das Bedienteil getauscht, weil ich die Standheizungstaste haben wollte... Aber laut google solls auch mit dem anderen Bedienteil gehen... Konfiguriert wird da ja eh nix - die neueren VWs merken ja selbst, was verbaut ist... Anders ist also wohl nur die Software von Webasto - die unterstützt beim Zuheizer ja auch keine Bedienteile... Und da du nicht weißt, was die Climatronic zuletzt gemacht hat - bist du sicher, das es dann reicht nur den Lüfter anzusteuern? Davon ab: Will man nicht immer die Software von dem Zuheizer updaten? Sonst hat man ja wirklich nur seine gebastelte Fernsteuerung und kann keine original Fernbedienung oder den Timer (übern Tacho bei VW) nutzen...
Also Du meinst, wenn man die richtigen CAN Nachrichten kennt, könnte man die einfach selbst anstelle der SH senden und alles ist gut?! Muss ich wohl mal intensiv nach suchen. Für das VW Zeugs gibt es eigentlich mehr Infos als zu Ford. Zur Not halt nur Lüfter steuern. Und ja, wie ich doch schrieb verbleiben die Klappen in der letzten Position. Die fahren nicht zu. Man muss halt selbst dran denken die richtig einzustellen. Das mit dem Firmwareupdate ist mir noch nicht klar. Wie genau wird das durchgeführt? Könnte mir vorstellen das das auch über den WBus läuft.
Ja, genau das meine ich... ;-) Die passende Nachricht zu finden wird aber wohl nicht so easy - zumal die sicherlich auch Fahrzeugspezifisch ist... Also wenn du sie bei dir findest, ist die sicherlich anders wie im Touran... Ja, sie verbleiben in der letzten Position - aber du weißt nicht, welche das ist... Du musst also um auf Nummer sicher zu gehen wirklich immer die Luft auf die Scheibe drehen, was immer auch gleichzeitig warm sein müsste... Du willst ja keine kalte Luft ins Auto schaufeln... Also muss man immer beim abstellen daran denken - das ist doch mega nervig! (man muss ja nicht gleich von Fehleranfällig sprechen) Ja, das Firmware Update läuft übern WBus... Is mir schonmal im Netz übern weg gelaufen, sowas...
Michael R. schrieb: > Du willst ja keine kalte Luft ins Auto schaufeln... Also muss > man immer beim abstellen daran denken - das ist doch mega nervig! (man > muss ja nicht gleich von Fehleranfällig sprechen) Das ist bei jeder nachgerüsteten SH aber auch so. Dann ist halt früh die Scheibe gefrohren und dafür der Motor warm ;-) Sascha
Na, wir sind aber doch nicht in der Chrome Abteilung von ATU sondern auf µC.net - wir streben doch nach Höherem... ;-) Ich hab grade mal in die Anleitung von Webasto geguckt (Nachrüstung in nem Octavia 1Z)... Die Klemmen sich auch nur zwischen Klimasteuergerät und Lüftersteuergerät... Wundert mich ehrlich gesagt etwas... Im Golf4 (und allem, das ungefähr das gleiche Alter hat) gab es noch einen Pin an der Climatronic, den man für den Standheizbetrieb auf 12V legen musste und dann lief alles automatisch... "Etwas" kacke, das es sowas heute nicht mehr gibt... Bleibt also nur, um den ganzen Komfort zu haben: - Zuheizer auf Standheizung upgraden (per Software) - CAN Messages rausfinden und selbst senden Gibts eigentlich einen relativ günstigen CAN Gateway, der sich für den Bus transparent verhält, aber dem PC sagen kann, welche Nachricht über welchen Bus kam? Damit könnte man dann mal ein Steuergerät isolieren und protokollieren, welche Nachrichten es schickt... Das wäre ja schonmal ein Anfang, wenn man sowas rausfinden will...
Da muss ich Michael zustimmen, ich bin auch kein Freund von Bastellösungeb. Alles oder nichts! ;-) Hatte gehofft im Internet mehr zu den CAN Nachrichten zu finden, aber fehlanzeige. Einzig canhack.de beschäftigt sich oberflächlich mit dem Thema. Leider ist das so halbmommerziell und undurchsichtig. Hatte mich da schon zweimal angemeldet, bin aber nach kurzer Zeit gesperrt worden. Scheinbar darf man da nur bleiben wenn man "dieselschrauberpunkte" kauft. Ich hab doch nur eine PayBack Karte! Scheiss Kapitalisten! ;-))) Das mit dem CAN Gateway habe ich sogar schon begonnen. Die Hardware ist trivial, ein Arduino und zwei MCP2515 und MCP2551 als Transceiver. Dennoch muss man ja die eingehenden Pakete lesen, verarbeiten, ggf. einen Trigger für Serial oder so auslösen und auch wieder rausschreiben. Einfach nur RX/TX vertauscht verbinden ist wohl nicht... Wenn hierzu einer eine Idee hat, bitte melden! Ich werdedafür aber einen neuen Thread aufmachen, hat hier nix zu suchen. Die Sache mit der SH Firmware treibt mich noch um. Nicht es langt die Codierung anzupassen?! Die steht ja vermutlich auf Zuheizer und dann könnte die TTV ja einfach keine CAN Befehle zur Climatronic senden. Am CAN muss ja doch sein, sonst könnte die Zuheizung nicht gesteuert werden. Der WBus war nicht verbunden.
Zum canhack, da war ich früher mal - da gabs aber keine Infos, die es nicht auch so offen im Internet gab... Also kurz zum CAN Gateway... Ich glaube nicht, das der AVR das schafft, wenn da viel auf dem Bus los ist! Und die externen SPI Transceiver sind auch keine Performancewunder - kann gehen, muss es aber nicht, wenn die das Timeing ziemlich streng kontrollieren... ;-) Zum Update, du ließt deine E-Mails nicht, oder?
Sascha W. schrieb: > hast du mal versucht mit CMD 0x51 0x0C alias IDENT_WB_CODE auszulesen > was die Heizung unterstützt? > > #define WB_CODE_0 0 /* Unknown supplemental heater feature */ > #define WB_CODE_ON 3 /* on/off switch capability */ > #define WB_CODE_PH 4 /* Parking heater capability */ > #define WB_CODE_SH 5 /* Supplemental heater capability */ > #define WB_CODE_VENT 6 /* Ventilation capability */ > #define WB_CODE_BOOST 7 /* Boost capability */ Hi Sascha! Also folgendes bekomme ich aus MEINER Heizung raus: 4F 0A D1 0C 31 3C C0 E3 3F 80 00 09 D0 = 0x0C = 0b00001100 Bit 4 mit PH ist klar. Aber was bedeutet Bit 3? Ist auch in der WBus-Lib nicht vorhanden. D1 = 0x31 = 0b0011 0001 0000 0001 ??? 0000 0010 External circulation pump control 0000 0100 Combustion air fan (CAV) 0000 1000 Glow Plug (flame detector) 0000 1010 Fuel pump (FP) 0011 0001 Circulation pump (CP) 0100 0000 Vehicle fan relay (VFR) 1000 0000 Yellow LED Also mit Zirkulationspumpe. Obwohl ich weiss das da eine Dosierpumpe für den Kraftstoff vorhanden ist... oder ist FP was anderes? D2 = 0x3C = 0b0011 1100 0000 0001 Green LED present 0000 0010 Spark transmitter 0000 0100 Solenoid valve present (coolant circuit switching) 0000 1000 Auxiliary drive indicator (whatever that means) 0001 0000 Generator signal D+ present 0010 0000 Combustion air fan level is in RPM instead of percent 0100 0000 (ZH) 1000 0000 (ZH) Also hab ich ein "Solenoid valve"(?) einen Auxiliary drive indicator (ist das vielleicht das Ding was den Betrieb der Heizung nach "außen" hin zum Fahrzeug steuert/anzeigt? Also die CAN-Sendefunktion?) Ein Generator-Signal (? Ist doch nur die popelige Spannungsüberwachung?) Und ein "Combustion air fan level in RPM" (hmmm, drehzahl der Lüftung?) D3 = 0xC0 = 0b1100 0000 Unbekannte Werte D4 = 0xE3 = 0b1110 0011 0000 * ? 0000 1111 (ZH) 0001 0000 Heating energy is in watts 0010 0000 (ZH) 0100 0000 Flame indicator (FI) 1000 0000 Nozzle Stock heating Also "Nozzle", "Flammwächter", (ZH), und etwas unbekanntes. D5 = 0x3F = 0b0011 1111 00** **** ? 0010 0000 Ignition (T15) flag present 0100 0000 Temperature thresholds available 1000 0000 Fuel prewarming resistance and power can be read. Auch hier nur das T15 Flag (meinen wohl "Klemme 15", also Zündung AN im Auto) D6 = 0x80 = 0b1000 0000 Unbekannte Werte
Michael R. schrieb: > Ich glaube nicht, das der AVR das schafft Es gibt hier im Forum bereits ein paar ältere Threads dazu. Die arbeite ich gerade durch. Es geht wohl schon, alles halbsowild. Vor allem reden wir hier nicht über einen HS-CAN, sondern MS-CAN mit 125kbit/s (gähn). Da langweilt sich doch wohl selbst ein 8-Bit 16 MHz Arduino und zwei SPIs ;-) > Zum Update, du ließt deine E-Mails nicht, oder? Na klar. Wenn da was hätte ankommen sollen, kam nichts. :-(
Naja, Daten aus dem einen per SPI raus, in den anderen per SPI rein und nebenbei noch per UART oder so an den PC schicken... Achja, und das eigentlich zeitgleich in beiden Richtungen, weil du ja auch Kolisionen auflösen musst und so Späße... Also ich denke nicht, das das soooo easy für den kleinen AVR ist... Da macht sich ein Controller, der mal eben so kann und zwei CAN Controller direkt drin hat sicher ne ganze ecke besser... ;-) Aber das sollte man echt wo anders diskutieren - zurück zum Thema: Bist du bei deiner Auswertung vom IDENT_WB_CODE nicht um ein Byte verrutscht? Das erste Datenbyte müsste doch 0x31 sein und nicht 0x0C?
Michael R. schrieb: > Bist du bei deiner Auswertung vom IDENT_WB_CODE nicht um ein Byte verrutscht? > Das erste Datenbyte müsste doch 0x31 sein und nicht 0x0C? Aaargh! Stimmt. 0x0C ist ja noch teil des bestätigten Wbus Kommandos! |-/
So, also hier mal der Codevergleich Mondeo: 4F 0A D1 0C 31 3C C0 E3 3F 80 00 09 Touran: 4F 0A D1 0C 31 3C C4 E7 3F 80 00 09 Das sind eht ja aus, als würde die TTV im Touran auch auf Standheizung (0x21) reagieren. Tut sie aber nicht!
Hab da mal ne frage... Wenn ich an der uhr 1533 die sofortheiztaste drücke.. sendet die uhr ja 4 mal den AN befehl direkt hintereinander.. dann antwortet die heizung?! Aber wie oft? Ist es normal das die uhr 4 mal AN sendet? Ich hab mir mit nem arduino was programmiert um die heihung per wbus zu steuern... Nur start ich die heizung per 1533 uhr und schalte sie direkt ab... (innerhalb der zeit wo 4 mal AN gesendet wird) geht uhr und heizung aus und heizung wieder an... mach ich das versetzt um 2 sekunden ist alles ok. Ist das verhalten der uhr normal? 1533 uhr per wbus mit meinem gsm modul per arduino gekoppelt. Heizung ist ne alte thermotop ohne wbus. Ich nutze den 12v schaltausgang der uhr. Der wbus wird nur benutzt um die uhr mit nem fake telestart zu koppeln. So das ich an der uhr ausschalten kann usw. Oder die hsndgestsrtete/per timer gestelte uhr zum abbruch bringen ksnn.. Danke
Zu deiner Frage: Die Uhr sendet MAXIMAL vier Startbotschaften. Sie macht es solange, bis EINE Antwort (ACK) eintrifft. Kommt diese nicht, wie üblich und erwartet, direkt nach der ersten Botschaft (weil die Elektronik noch "schläft") so sendet sie ein weiteres mal. Nach viermal ist dann schluß. Den Rest habe ich ehrlich gesagt nicht so ganz verstande. Wirkt etwas konfus auf mich, auch die Schreibweise... Wozu soll denn die Uhr dienen, wenn die Heizung ohnehin per Relais gestartet/gestoppt wird? Einen Schaltausgang und eine Sofort-Heizen Taste könntest Du doch auch mit dem Arduino realisieren. Ein Telestart verwendet übrigens eine andere Wbus ID als ein Timer oder eine Heizung. Wenn Du vom Arduino alles richtig machst, erscheint im Display des Timers "TELE" - "ON".
So hab den fehler gefunden.. hatte ein delay vergessen zu löschen... Kann mir jemand sagen wie der befehl aussehen müsste wenn telestart 60minuten standlüften sendet? Und die antwort der heizung? Sowie die statusabfrage und die antwort darauf? Idealerweise noch das sauber ausschalten vom telestart und die antwort darauf? Vielen lieben dank!
langsam schwindet die Hoffnung... Abend zusammen, ich befasse mich schon seit längerem mit dem Thema die TTV mit Hilfe eines Mikrokontrollers zum Laufen zu bringen, angefangen mit C-Control. Da ich ein Hobby Elektroniker bin und mir einiges an wissen fehlte-fehlt ist es nicht leicht für mich. So mit dem C-Control habe ich schnell aufgegeben da ich nicht weiterkam. Seit 2 Jahre spiele ich mit Arduino rum und habe das Thema wieder im Angriff genommen. Ich besitze eine TTV -als Zuheizer Touran (J.2004) und eine TTV als Standheizung aus BMW. Für den Touran habe ich damals eine Box bei Zuheizerupgrade gekauft in der eine C-Control steckt(meiner Meinung nach). nur Die "Blackbox" krigt die TTV aus BMW nicht an, warum auch immer ist aus dem Jahr 2013. Onkel Google hat mir einiges rausgeschmissen für Arduino aber nichts fenzte. ich benutze ein Arduino Nano + K-Line-Interface L9637 . und ich Kämpfe schon seit einige Zeit kriege sie einfach nicht ans Laufen, seit gestern habe ich rausgefunden, wen ich die Diagnose Software WTT starte und die Heizung wird initialisiert ich mein Adapter einschalte läuft sie an, ich war baff, das ist mir seit Monate nicht gelungen.... dachte es liegt am "Break" habe wie von Sascha gesagt mittels Transistor gelöst, hatt aber nichts gebracht..... Kann mir vielleicht ein Tipp geben... welche Richtung ich suchen soll ??? hier mein Sketch:------- int x=0; int stat=0; int st; #define breakport 2 #define led 13 int incomingByte = 0; void setup() { Serial.begin(2400, SERIAL_8E1); delay(1000); pinMode(breakport ,OUTPUT); pinMode(led ,OUTPUT); } void loop() { //breack if (st==0){ digitalWrite(breakport,HIGH); delay(50); //50ms digitalWrite(breakport,LOW); delay(50); //50ms st=1; //nur einmal Break } //24 03 21 3c 3a Serial.write(0x24);//24 Funkfernsteuerung ,F4 Software Serial.write(0x03); //03 Serial.write(0x21); //21 Serial.write(0x3C); //1E Serial.write(0x3A); // C8 //zur kontrolle alle 5 sekunden digitalWrite(led,HIGH); delay(2500); digitalWrite(led,LOW); delay(2500); } //ende LOOP muss ich bevor die Startsequenz kommt noch was schicken......komisch wen die WTT Software sich mit der TTV verbunden hat, akzeptiert sie meine Steuerung und startet auch...
:
Bearbeitet durch User
Dein Break wird nicht ausgelöst, da du die Variable "st" nicht inialisierst. Die ist am Anfang von loop() NULL, du fragst auf 0 ab (das ist ein Unterschied in C!). Initialisiere die bei der Definition mit dem Wert 0.
Olli Z. schrieb: > Dein Break wird nicht ausgelöst, da du die Variable "st" nicht > inialisierst. Die ist am Anfang von loop() NULL, du fragst auf 0 ab (das > ist ein Unterschied in C!). Initialisiere die bei der Definition mit dem > Wert 0. Hi, wen ich "st" nicht initialisiere ist der Wert "0",ich habe mit längeren Pausen überprüft das Programm läuft richtig ab. habe Loop verändert und zwar so:-> void loop() { //breack while (st<4){ digitalWrite(breakport,HIGH);//HIGH LOW delay(50); //ootame 50ms digitalWrite(breakport,LOW); delay(50); //ootame 50ms Serial.write(0xf4); //F4 Software 24 Funkfernsteuerung Serial.write(0x03); //03 Serial.write(0x21); //21 Serial.write(0x1e); //1E Serial.write(0xc8); //C8 delay(100); st++; } delay(2000); Serial.write(0xf4);//F4 Software, 24 Funkfernsteuerung Serial.write(0x04); //03 Serial.write(0x44); //21 Serial.write(0x21); //1E Serial.write(0x00); // C8 Serial.write(0x95); // C8 digitalWrite(led,HIGH); delay(2500); digitalWrite(led,LOW); delay(2500); } Gestern zufällig rausgefunden......also wen der Break 4 mal durchläuft startet die TTV(von BMW) problemlos nur mit Arduino..... K.A. irgendwie wacht die nicht beim ersten Mal auf, bei meinem Turi bleibt sie mit dem Sketch stille Warum nicht beim einmaligen durchlauf????
:
Bearbeitet durch User
Das ist Zufall. Es ist nicht definiert. C legt beim compilieren für die
Variable "st" eine Speicherstelle fest. Diese ist dann nur per Zufall
mit "00" initialisiert. Ich würde mich nicht drauf verlassen.
Als erstes würde ich die setup() Routine so gestalten:
void setup() {
digitalWrite(breakport, HIGH);
pinMode(breakport, OUTPUT);
digitalWrite(led, HIGH);
pinMode(led, OUTPUT);
Serial.begin(2400, SERIAL_8E1);
delay(1000);
}
Warum? Zum einen sollte man Ports setzen BEVOR man die Datenrichtung
wählt. Das hat den Vorteil das dieser dann einen definierten Wert hat.
Ähnlich wie bei Variablen wollen auch Port initialisiert werden. Daher
zunächst ein, unschädlicher HIGH-Pegel.
Dann ist dein Break falsch. Im Ruhezustand liegt am W-Bus ein
HIGH-Pegel. Der LIN-Transceiver ist nicht-invertierend. 2x 50ms sind
m.E. auch zu lang, denn die Gesamtdauer des Break ist max. 50ms. Stelle
die Werte mal auf 25ms (bzw. sogar 13ms) pro Periode:
digitalWrite(breakport, LOW);
delay(25);
digitalWrite(breakport, HIGH);
delay(25);
Den Befehl den Du zur Heizung schickst lautet:
CMD 0x21 - "Parking heater on"
Es gibt aber neben dem Modus "Parking heater" auch noch:
CMD 0x23 - "Turn on supplemental heating"
CMD 0x20 - "Turn on heater (generic)"
Je nach Kodierung Deiner Heizung reagiert diese nur auf einen der
Befehle. Versuche also auch mal die anderen Varianten.
Sicher weisst Du das das letzte Byte eine Prüfsumme ist, die sich ändert
wenn sich die Bytewerte ändern. Also bei einem anderen CMD oder
Adressbyte (24 anstelle F4) ist auch das CHK-Byte anders. Ich würde mir
an Deiner Stelle gleich eine Routine zur Berechnung der Prüfsumme
schreiben, das erleichtert die Tests. Stimmt die Prüfsumme nicht,
reagiert die Heizung garnicht.
static unsigned char checksum(unsigned char *buf, unsigned char len,
unsigned char chk)
{
for (;len!=0; len--) {
chk ^= *buf++;
}
return chk;
}
Hier hatte ich für mich mal einiges zum Thema dokumentiert, vielleicht
hilft es Dir weiter: https://mk4-wiki.denkdose.de/grundlagen/w-bus/start
Olli Z. schrieb: > Das ist Zufall. Es ist nicht definiert. C legt beim compilieren für die > Variable "st" eine Speicherstelle fest. Diese ist dann nur per Zufall > mit "00" initialisiert. Ich würde mich nicht drauf verlassen. > > Als erstes würde ich die setup() Routine so gestalten: > > void setup() { > digitalWrite(breakport, HIGH); > pinMode(breakport, OUTPUT); > digitalWrite(led, HIGH); > pinMode(led, OUTPUT); > Serial.begin(2400, SERIAL_8E1); > delay(1000); > } habe ich so gemacht... > > Warum? Zum einen sollte man Ports setzen BEVOR man die Datenrichtung > wählt. Das hat den Vorteil das dieser dann einen definierten Wert hat. > Ähnlich wie bei Variablen wollen auch Port initialisiert werden. Daher > zunächst ein, unschädlicher HIGH-Pegel. > > Dann ist dein Break falsch. Im Ruhezustand liegt am W-Bus ein > HIGH-Pegel. Der LIN-Transceiver ist nicht-invertierend. 2x 50ms sind > m.E. auch zu lang, denn die Gesamtdauer des Break ist max. 50ms. Stelle > die Werte mal auf 25ms (bzw. sogar 13ms) pro Periode: > digitalWrite(breakport, LOW); > delay(25); > digitalWrite(breakport, HIGH); > delay(25); > ist er nicht weil,meine Schaltung sieht so aus: habe ein Transistor mit ihm ziehe ich den TX Pin des L9637 au Grund(dachte forher das es so besser ist), Arduino Pin High->schaltet den Transistor, der zieht mir die TX Leitung auf Grund ->nach 50 ms Arduino Pin Low-> Transistor wird wieder gesperrt 50 ms warten und Startbefehl schicken.... mein Loop weckt ja jetzt die Heizung auf, aber nur wen ich das Break-Teil min 4 mal durchlaufen lasse...... ich weiß da ist irgendwo ein Bock, aber wo. Könnte es die Hardware sein??? Danke für Wiki,also sobald ich die Zeit ändere passiert überhaupt nichts... > Den Befehl den Du zur Heizung schickst lautet: > CMD 0x21 - "Parking heater on" > Es gibt aber neben dem Modus "Parking heater" auch noch: > CMD 0x23 - "Turn on supplemental heating" > CMD 0x20 - "Turn on heater (generic)" > Je nach Kodierung Deiner Heizung reagiert diese nur auf einen der > Befehle. Versuche also auch mal die anderen Varianten. das weis ich > > Sicher weisst Du das das letzte Byte eine Prüfsumme ist, die sich ändert > wenn sich die Bytewerte ändern. Also bei einem anderen CMD oder > Adressbyte (24 anstelle F4) ist auch das CHK-Byte anders. Ich würde mir > an Deiner Stelle gleich eine Routine zur Berechnung der Prüfsumme > schreiben, das erleichtert die Tests. Stimmt die Prüfsumme nicht, > reagiert die Heizung garnicht. > static unsigned char checksum(unsigned char *buf, unsigned char len, > unsigned char chk) > { > for (;len!=0; len--) { > chk ^= *buf++; > } > > return chk; > } hier oben gabs eine Exeltabelle daür,ja das mit der Prüfsumme habe ich auch verstanden.... > > Hier hatte ich für mich mal einiges zum Thema dokumentiert, vielleicht > hilft es Dir weiter: https://mk4-wiki.denkdose.de/grundlagen/w-bus/start Hast du den bei dir was ans Laufen gekriegt??? wen ja mit welchen Kontroller?? Eine Frage noch, muss ich jedes Mal vor dem sende Break auslösen???? z.B wen ich den Befehl zum Heizung aus schicken will
:
Bearbeitet durch User
Ok, mit dem Transistor ist das klar. Ich hab dafür einfach den TX Pin kurz als Ausgang definiert und es darüber gemacht. Den BREAK muss man nur nach einer Kommunikationspause, bzw. Start senden. Er lässt die Elektronik in der Heizung "erwachen". Die Pause nach dem Low gibt der Heizung Zeit empfangsbereit zu werden. Es reicht den Break solange zu senden bis die Heizung antwortet und dann eret wieder wenn man eine längere Kommunikationspause macht. Einen genauen Wert dafür gibt es nicht, aber in der Praxis sind das so 20-30 Sekunden. Ich setze auch den L9637 ein. Bei anderen LIN Transceivern muss man aufpassen, die lassen nämlich keinen langen LOW Pegel zu und man muss den Break mit einem Transistor erzeugen. Sobald Du den Heizbefehl gesendet hast, sollte es von der Heizung eine Antwort geben. Diese kann positiv oder negativ sein. Erhälst Du sowas, bzw. überhaupt eine Antwort?
Also habe jetzt alle beide zum laufen gebracht, und zwar sende ich BREAK +Startbefehl mehrere Male hintereinander irgendwann nach 4-5 Mal springt die Heizung an und gibt mir eine Antwort, sehe es am HTerm. Wen ich jetzt nur einmal BREAK +Startbefehl sende bleibt alles ruhig. Ist es OKAY???? habe heute die damals gekaufte Black-Box ausgelesen, Sie sendet auch jede Sekunde BREAK +Startbefehl bis die Heizung nicht anspringt(insgesamt 20 mal, dan bleibt sie stehen). Bis dahin habe ich immer nur einmal gesendet und dachte sie Mus angehen.... Anscheinend ist es normal das man mehrmals hintereinander senden muss.... Die Standheizung aus BMW springt super an ,kann ein und ausschalten, die im Touran(Zuheizer) schalte ein->sofort aus, nachdem sie runtergefahren ist lässt sie sich nicht sofort wieder starten, aber das ist das kleinste Übel.. ich würde jetzt gerne wissen wie man Daten aus der Heizung abfragt.... das wird schon schwieriger https://www.youtube.com/watch?v=6zZjSFef4yA darauf bin ich gestoßen, nur bei mir funzt es nicht und das Programm ist schon für mich kompliziert.. mal schauen, alle Anfang ist schwer..
:
Bearbeitet durch User
Grundsätzlich ist das so das man eine gewisse Zeit (Timeout) einen Einschaltbefehl wiederholt. Sobald die Heizungselektronik bereit ist und eine Antwort sendet, kann man von ausgehen das man nicht mehr mehrfach senden muss. Dennoch ist es gute Praxis auch hier eine Widerholung einzubauen, z.b. 4mal senden mit kurzer Wartezeit dazwischen. Der wbus kann ja kurzzeitig gestört gewesen sein. Auch ist es völlig okay wenn die Heizung startet und danach wieder aus geht. Dafür ist ja der Erhaltungsbefehl zuständig. Dieser muss codetechnisch zum Startbefehl passen. Also, startest Du als Parking heater, musst Du auch als Parking heater erhalten. Der Erhaltungsbefehl wird, trotz angegebener Laufzeit beim Startbefehl, solange gesendet bis dieser negativ bestätigt wird. Es kann zig Gründe geben war die Heizung nicht an bleibt oder nach ner Zeit aus geht. Mangelnder Kraftstoff ist da nur eine. Aufschluß gibt hier eine Statusabfrage. Es ist auch völlig okay wenn sich die Heizung nicht zig al hintereinander aus und einschalten lässt. Da gibt es eine Wartezeit, abkühlzeit. Die Autohersteller versehen die Werksheizungen von Webasto gern mit auf sie zugeschnittener Firmware. Da können dann auch Abhängigkeiten zum Fahrzeug drin sein, wie das die Steuerung über den CAN Bus die Restkrqftstoffmenge ermittelt, oder ob es seit dem letzten Heizzyklus einen Motorstart gab, oder im Fall des Zuheizers ob der Motor überhaupt läuft und kalt ist. Deine nächsten Schritte werden sein aus deinen Befehlen, Kommunikationen zu machen, also die Antworten der Heizung auszuwerten und entsprechend darauf zu reagieren. Ich würde das ganze grundsätzlich in einer Statemachine machen, so hast Du ja auch schon angefangen. Wichtig ist keine Whileschleifen oder delays zu nutzen, da diesen den Programmzyklus hemmen und man evtl. wichtige Informationen "übersieht" während man irgendwo wartet. Für die Wiederholung sorgt schon die Arduino loop() selbst. Die benötigst also eine globale Statusvariable die den Zustand dem SM hält. In der main loop kommt dann eine große if-Zweiung zum Einsatz die auf den Status, wie auch den Statusübergabg reagiert. Neben dem Grundgerüst der SM brauchst Du dann noch eine Senderoutine die sich auch um die Antworten kümmert und zwar auch wieder nicht-blockierend. Ich würde vorschlagen mit einer Start-Funktion zu beginnen, z.b. wb_start_ph(int runtime); Die routine soll letztlich nur den Startbefehl zur Heizung schicken, ggf. mit einem Break davor und sofort zurückkehren. Jegliche Auswertung kommt im nöchsten Durchlauf. In der SM wird dann nach dem Aufruf der Status von ST_OFF auf ST_STARTING gesetzt. In der nächsten Iteration wird darauf mit Abfrage der Rückmeldung reagiert. Also eine Routine die prüft ob am UART Daten eingegangen sind und eine gewisse Timeout zeit nicht überschritten wurde. Die Routine prüft auch ob die eingegangenen Daten vollständig und valide sind. Hier kommt wieder die Prüfsumme und das LEN Byte zum Einsatz. Ist die Nachricht vollständig, signalisiert sie es der Statusfunktion, welche ihrerseits überprüft ob die Antwort positiv oder negativ ist und setzt entsprechend den nächsten Status. So hangelt man sich weiter durch. Das wichtige Konzept dabei ist, möglichst nirgendwo im code zu warten. Auch timeouts wartet man nicht ab, sondern setzt sich globale timer, entweder mit Abfragen oder richtige Timer mit Interrupts, welche dann wieder globale Statusvariablen füttern. Ich weiss nicht wie gut Du im programmieren und umsetzten solcher Design,Patterns bist. Wenn Dir das alles zu theoretisch ist, können wird das auch gern Schritt für Schritt zusammen umsetzen. Wenn das Grundgerüst erstmal steht und die Verarbeitungsweise klar ist, ist der Rest nur noch Fleißarbeit. Auch die Abfrage von Statuswerten funktioniert auf diese Weise. Je robuster und Protokollnäher die grundlegebdeb IO Funktionen sind, desto stabiler und besser wird später deine Anwendung sein.
Erstmals Danke für deine Hilfe. Ich bin vom beruf Schlosser, habe mich aber schon immer für Elektrik interessiert, bin jetzt etwas weiter als ein Anfänger im programmieren... so ungefähr habe ich dich verstanden. Das Größte Hindernis für mich ist das ich kein Englisch in der Schule gehabt habe, da muss ich schon fiel mit Übersetzer arbeiten, die aber nicht so gut(verständlich) übersetzen. Wen ich die Richtung weis dann könnte ich es schon hinbekommen, denke ich werde aber deine Hilfe noch brauchen. Machst du fiel mit Arduino???? meine Frage wie soll ich vorgehen wen ich z.B. Temperatur abfragen will "Command 0x50" ? ? Wie sieht der Befehl aus -> TX f4 04 50 21 00 95 Zurück kommt dann RX 4f 03 c4 00 88 42(ist nur ein Beispiel) wie werte ich die Daten aus, wo ist/steht die Temperatur oder andere Sachen, wie mache ich es praktisch. in der W-Bus library sind ja die Befehle hinterlegt....
Fertiges klicki-bunti gibts nur im YT-Video, die Praxis ist voll mit fiesen kleinen aber wichtigen Details. Du musst dich halt jetzt auch entscheiden - willst Du einen schnellen Erfolg ohne viel Einarbeitung, dann nutz eine fertige Library. Oder willst Du es wirklich verstehen und optimal auf Deine Bedürfnisse anpassen, mach es selbst und setz das um was Du brauchst. Jetzt wieder mit Temperaturabfragrn anzufangen, obwohl Du noch keine vernünftige Kommunikationsroutine hast, halte ich für sinnlos. Das wird Dich in der Umsetzung nicht weiter bringen, fürchte ich...
Hi Dennis, auch wenn es bei dir mit dem Englisch ja eher schlecht aussieht, sei an dieser Stelle mal wieder auf die tolle Beschreibung in der libwbus verwiesen: https://sourceforge.net/p/libwbus/libwbus/ci/master/tree/webasto_wbus.txt Da drin steht wirklich alles, was man über die Kommunikation wissen will... Zumindest habe ich meine Heizungen damit alle ohne Probleme ans laufen bekommen und als Bonus muss man sich die Infos nicht im Code der lib zusammensuchen... Ansonsten hat Olaf recht, du solltest erst mal aufräumen und gucken, das die Checksumme und die Adressen automatisch gesetzt werden... Der Inhalt der Kommandos ist danach ein Kinderspiel, weil man ja fix mal was ausprobieren oder ändern kann....
Michael R. schrieb: > Hi Dennis, > > auch wenn es bei dir mit dem Englisch ja eher schlecht aussieht, sei an > dieser Stelle mal wieder auf die tolle Beschreibung in der libwbus > verwiesen: > https://sourceforge.net/p/libwbus/libwbus/ci/master/tree/webasto_wbus.txt > Hallo Michael, kannst du mir vielleicht helfen, ich komme da nicht so richtig klar. Wenn ich das richtig verstanden habe kann ich die Umwälzpumpe ansteuern . "Command 0x24 Circulation pump external control" richtig und der Komplette Befehl wäre dann -> F4 03 24 3B E8 richtig??? habe es versucht bleibt aber alles ruhig....
Denis R. schrieb: > Hab's -> f4 06 45 02 05 07 d0 67 dosirPumpe ein für 5 sekunden Dosierpumpe und Zirkulationspumpe sind ja auch zwei verschiedene! Die erste pumpt den Kraftstoff, hört man durch das typische Klicken. Die zweite befördert das Kühlwasser, glaube nicht das man da von aussen groß was hören kann. Sascha
Ich weiß, wollte nur die Umwälzpumpe ansteuern und habe als erste aber die Dosier pumpe geschafft..... f4 06 45 04 05 00 c8 7e für die Umwälzpumpe.
Na, die Frage hat sich ja von alleine gelöst... Zum Thema hören, die Dosierpumpe hört man wie gesagt klackern - die Umwälzpumpe hört man aber auch gut - sowohl im als auch außerhalb des Autos...
from my experience, 1533 will wake up the bus. i am using TT C Diesel from old Mazda 6 programmed as "zuheisser". and when pin 1 from 6 pin connector(X1) IS CONNECTED TO WBUS PIN on 1533 i can turn on and of the furnace. problem is that furnace will be on for max 60 mins...
denke die 60 Minuten Begrenzung ist eher dazu da um die Batterie wegen des Lüfters nicht leer zu saugen.
hi ich hab eine thermotop c z d aus einrm bmw e39 mit der thermotest diagnose mit dongle kann ich die telegramme loggen! kennt sich da jemand aus? 3f diagsoftware länge 6b heizgerät daten1 . . daten x checksumme die abfragen wie bei einer wbus heizung.. zb nach werten x50 x05 und richtiger checksumme ergeben nix! anscheind ist das telegramm identisch aber es werden andere werte genutzt! jemand ne idee? danke!
Replay Attacke versuchen. Daten mitloggen, isolieren und mit eigener Software auf den Bus senden. Wenn das klappt versuchen die Telegramme zu isolieren um draus schlau zu werden. Binärbaum Technik, hälfte senden schauen ob das gesuchte passiert, wenn ja davon die Hälfte, wenn nein die andere Hälfte. Bis runter zum Einzeldiagramm. Poste doch mal ein Log in dem du die Heizung abfrägst oder startest. Und, wenn verfügbar auch das Diagramm eines Logicanalyzers dazu.
ich hab sogar ein video bzw screen capture... eigentlich fehlt mir derzeit nur eine sache! die berechnung des widerstandes des flammenwächters! HEX DEC OHM ohm/dec 3b 59 0,405 0,0068644068 3c 60 0,414 0,0069 3d 61 0,424 0,00695 40 64 0,455 0,007109375 42 66 0,476 0,0072121212 48 72 0,542 0,0075277778 4b 75 0,578 0,0077066667 4c 76 0,59 0,0077631579 4d 77 0,603 0,0078311688 4e 78 0,615 0,0078846154 5a 90 0,784 0,0087111111 5f 95 0,865 0,0091052632 61 97 0,9 0,0092783505 hex ist klar dec ist hex in dec ohm ermittelt aus der software ohm/dec ohm durch dezimal und da sieht man.. nicht linear.... und ich weis nicht weiter.. die software hat irgend eine berechnungsgrundlage... ich komme nicht weiter!
Ich verstehe zwar grad nicht was Du erreichen willst und wie, aber der Flammwächter dürfte ein NTC oder PTC sein und die haben nie eine lineare Kurve. Da wird vermutlich auch eher nichts berechnet, sondern über eine Lookuptabelle gearbeitet und Zwischenwerte interpoliert.
ich denke auf der einen seite hast du recht...auf der anderenseite... hab ich die vermutung dss da trotzdem eine berechnung hinter steht... zurzeit arbeite ich mit screencapture der diagnosesoftware.. dem telegram die komplette bandbreite aus... mit viel eiswasser und kältespray fehlen mir von 96 werten nur noch 30 stück... ich hab ein loses steuergerät ein 20a 24v konstanter und den glühstift. bei einer wbus heizung sind 2 hexwerte milliohm.. warum sollte es bei dem steuergerät anders sein?! ich arbeite heute ne excel tabelle aus und ein diagramm... nächste option wäre ein 0-2 ohm poti und damit weiter auflösen... wie komm ich nur weiter?
Die andere Frage wäre: Warum? Die Werte sind für einfaches an und aus doch uninteressant und für Diagnose haste ja den PC...
Hallo Fricklergemeinde Ist in dem Fred noch Bewegung? Ich habe mit bei eBay eine Webasto TT - C aus einem verunfallten Touareg geschossen und will die als Standheizung im meine WoMo Bj.85 einbauen. Da trifft die elektrische Steinzeit auf Microelektronik :-) Mehr als 12Volt und Masse gibt es in dem Ducato nicht. Zu Beginn werde ich schon froh sein wenn die TT schon mal als zusatzheizer laufen würde. (Die orginalheizung über den motorkreislauf ist eher ein Witz) Ich stehe jetzt vor der Option mit eine Zeitschaltuhr von Webasto zu kaufen - oder was meinem Frickeldrang eher entgehen kommt die Ansteuerung mit einem Arduino selbst zu bauen. Elektronisch bin ich gut unterwegs - Beim Software schreiben bin ich aber nie über 200 Zeilen Code rausgekommen. Um da auch eher Java oder Python. Mit Ausnahme von ein paar Arduino- Scrips auch kein C. Ich habe zwar schon ein paar mal den Thread hoch und runter gelesen, bin mir aber noch nicht so im Klaren wie ich anfangen soll. Am liebsten wäre es mir wenn ich erst mal versuche die Steuerung mit dem Simulator ans laufen zu bringen und dann erst die TT zu quälen. Welche Hardware brauche ich für den Simulator? Oder läuft die SW auch auf einem Arduino? Gruß Andreas
Hallo Andreas, wenn wieder mal jemand eine Frage hat dann geht es hier weiter. Wenn du dich auf den von mir hochgeladenen Simulator beziehst - das ist ein Windowsprogramm. Als Hardware brauchst du eine Anpassung von (USB) -> Seriell -> K-Line/Linbus. Das kann man mit einem entsprechendem Treiber machen oder mit paar Transistoren. Wenn du nur den Arduino gegen den Simulator testen willst reicht auch eine Diode und ein Widerstand und am Arduino natürlich auch kein Treiber. Die Heizung meckert aber auch nicht wenn man Ihr Mist sendet :) Mit dem Arduino solltet du das Problemlos hinbekommen - vielleicht sogar mit 200 Zeilen. Meine Fernbedienung hab ich in ASM programmiert, so das dir das auf dem Arduino und mit deinen Programmierkenntnissen nicht viel nützt. Vielleicht kann Olli noch was beisteuern. Sascha
Ob ich da mehr zu beisteuern kann...? Sascha ist hier eigentlich der Wbus-Gott ;) Ich sag immer „Der nächste Winter kommt bestimmt“ und dann geht es auch hier sicher wieder fleißig weiter :-) Ich selbst hab nur ne TT-V und meine mich zu erinnern das die Kommunikation da anders ist, aber das Prinzip, der W-Bus, ist dasselbe. Arbeite dich einfach schichtweise hoch. Also zuerst Bitübertragungsschicht. Und persönlich würde ich Dir eher empfehlen die Lowlevel Routinen auf Hardware zu machen. Dann die Sende und Empfangsroutinen für einzelne Frames. Damit kannst Du dann schonmal einzelne Befehle schicken und Antworten empfangen. Um dann ganze Abfolgen im Griff zu haben, z.B. Starten und heizen, empfiehlt sich der Einsatz, bzw. das Designpattern einer Statemachine. Weitere Details und Hilfen gern hier.
Hi Sascha, Vielen Dank für die überraschend schnelle Antwort. Ich hab zum Glück noch eine alten Notebook mit echter RS232 gefunden der mir den Murks mit dem USB->Seriell erspart, so dass ich mir nur die W-Bus Schnittstelle bauen muss. Irgendwo weiter oben hab ich gelesen „ mit Hterm den Traffic mitschneiden ..... Wie soll das an der RS332 gehen ? Sobald Hterm an der Schnittstelle ist ist die Adresse vergeben so dass die Webasto Thermo Test nicht mehr darauf zugreifen kann. Oder sollte damit gemeint sein sich über die w-Bus Schnittstelle zwischen Heizung und Uhr/Fernsteuerung klemmen? Gruss Andreas
Mithören war da die Ansage. Wenn Du dir z.B. ein einfaches Diagnoseinterface baust, z.B.: https://mk4-wiki.denkdose.de/grundlagen/wbus_diagnoseadapter_bauen/start kannst Du versuchen über die Webasto ThermoTest Software die Heizung anzusprechen. Das was dann da über die Leitung geht sollte man sich näher ansehen :-) Hierfür kannst Du dann Hterm nutzen, von einem weiteren PC aus, oder eine Software die das auf Treiberebene macht. Oder halt auch mit einem Logicanalyzer für ein paar Euro. Wenn Du die Bytes des Nachrichtenframes im Voraus "berechnest" dann kannst Du durchaus mit HTerm auch einfache Befehle senden und schauen wie die Heizung darauf reagiert. W-Bus ist ja im Prinzip ein einfacher Serialbus mit 2400 Baud 8E1 (gerade Parity). Wichtig zu wissen: Die Heizung selbst sendet von sich aus nichts, sie reagiert nur auf Deine Kommandos. Hier hab ich mal etwas zusammengefasst und da kannst Du dich vielleicht noch etwas einlesen: https://mk4-wiki.denkdose.de/grundlagen/w-bus/start Das größte Problem bei einfachen Serial-Schnittstellen ist die Erzeugung des BREAK Signals. Die ist aber überaus wichtig, weil sonst gar keine Kommunikation stattfinden wird. Ich fand es immer wesentlich einfacher die von einem Arduino per IO-Pin zu erledigen zu lassen, weil das über Serial zu machen immer ein Gewürge ist.
Olli Z. schrieb: > Ob ich da mehr zu beisteuern kann...? Sascha ist hier eigentlich > der Wbus-Gott ;) > > Ich sag immer „Der nächste Winter kommt bestimmt“ und dann geht es auch > hier sicher wieder fleißig weiter :-) > Ich selbst hab nur ne TT-V und meine mich zu erinnern das die > Kommunikation da anders ist, aber das Prinzip, der W-Bus, ist dasselbe. > Arbeite dich einfach schichtweise hoch. Also zuerst > Bitübertragungsschicht. Und persönlich würde ich Dir eher empfehlen die > Lowlevel Routinen auf Hardware zu machen. > Dann die Sende und Empfangsroutinen für einzelne Frames. > Damit kannst Du dann schonmal einzelne Befehle schicken und Antworten > empfangen. > Um dann ganze Abfolgen im Griff zu haben, z.B. Starten und heizen, > empfiehlt sich der Einsatz, bzw. das Designpattern einer Statemachine. > Weitere Details und Hilfen gern hier. Hallo Olli, Vielen Dank für die tips, ich werd dich wieder nerven sobald sobald die Hardware mit dem Linbus Driver zuckt. Aber im Moment ist es ja noch so warm dass mich alleine der Gedanke den Lötkolben anzufassen ins schwitzen bringt. Gruß Andreas
Hat jemand zur Zeit Interesse die Telestart von Sacha nachzubauen ? Ich werde die Tage die Platine bestellen, bekomme Sie aber 3x . Hätte also 2 übrig. Mfg Alban
Hallo zusammen, es ist zwar schon eine Weile Ruhe hier, aber vielleicht hilft mein Beitrag doch dem ein oder anderen. Ich habe eine Webasto Thermo Top Evo 5, also eine Heizung mit der neueren Wbus Version. Außerdem hab ich das original Webasto Diagnose Teil für die neue Thermo Test Software (V3.x). Zumindest das Byte welches den Betriebszustand angibt hat sich ja geändert im Vergleich zu dem was noch in der libwbus steht. Ich habe also mal mit hterm am PC aufgezeichnet was die Thermo Test Software mit der Heizung austauscht. Während der Diagnose sendet die Software endlos abwechselnd zwei Befehle
1 | F4 0D 50 30 5F 60 61 0A 2A 3D 2B 23 0E 28 F4 |
und
1 | F4 17 50 30 1E 5A 33 03 01 04 02 58 59 32 10 15 13 34 24 2C 12 11 0C 51 B7 |
Die sehen deutlich länger aus als alles was ich sonst so gesehen hab. Adresse Länge und Checksumme sind klar, auch der Befehl 0x50 macht Sinn (Read operational information registers - laut libwbus). Statt einem weitern Byte als Paramter für den 0x50 Befehl kommt aber jetzt ein ganzer Haufen an Bytes. Was die bedeuten hab ich noch nicht herausgefunden. Die Antwoten konnte ich aber zum Teil dekodieren und habe daher jetzt auch eine Liste an Betriebszuständen mit entsprechenden Hexcodes. Die Antwort auf F4 0D 50 30 5F 60 61 0A 2A 3D 2B 23 0E 28 F4 sieht so aus:
1 | ADRLENCMD00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 |
2 | 4F 1C D0 30 5F 00 63 60 00 62 61 00 01 0A 0D 2A 00 3D 03 20 2B 00 23 36 |
3 | |
4 | 21 22 23 24 25 CHK |
5 | 0E 34 9E 28 99 F5 |
- Byte 20 ist die Umwälzpumpe in Prozent (Wert zwischen 0 und 200). - Byte 22 und 23 ist die Spannung. Genau wie in der libwbus beschrieben. - Byte 25 ist das state byte. Ich habe also die Heizung einmal laufen lassen und die Thermo Test Software recorded und bin so auf folgende Zustände gekommen:
1 | 0x71: Wartezustand |
2 | 0x73: Motor Check |
3 | 0x75: Vorglühen 1 |
4 | 0x76: Vorglühen 2 |
5 | 0x79: Start1 |
6 | 0x7A: Start2 |
7 | 0x7B: Start3 |
8 | 0x7C: Start4 |
9 | 0x7D: Start5 |
10 | 0x7E: Start6 |
11 | 0x7F: Glühstiftrampe |
12 | 0x80: Flammwächter Messung1 |
13 | 0x81: Flammwächter Messung2 |
14 | 0x99: Stufenlose Heizleistungsregelung |
15 | 0x91: Teillastausbrand |
16 | 0x95: Kühlung1 |
17 | 0x97: Kühlung2 |
18 | 0x8F: Pause |
19 | 0x73: Motor Check |
20 | 0x77: Vorglühen Teillast, Start |
21 | 0x82: Start1 Teillast, Start |
22 | 0x83: Start2 Teillast, Start |
23 | 0x84: Start3 Teillast, Start |
24 | 0x85: Start4 Teillast, Start |
25 | 0x86: Start5 Teillast, Start |
26 | 0x87: Start6 Teillast, Start |
27 | 0x88: Glühstiftrampe Teillast, Start |
28 | 0x89: Flammwächter Messung1 Teillast, Start |
29 | 0x8A: Flammwächter Messung2 Teillast, Start |
30 | 0x9A: Stufenlose Heizleistungsregelung-Halten |
31 | 0x91: Teillastausbrand |
Die Liste ist sicher nicht vollständig. Wenn ich Zeit habe schreibe ich vielleicht einen Simulator und gucke was die Software draus macht. Die Antwort auf
1 | F4 17 50 30 1E 5A 33 03 01 04 02 58 59 32 10 15 13 34 24 2C 12 11 0C 51 B7 |
sieht so aus:
1 | ADRLENCMD00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 |
2 | 4F 37 D0 30 1E 25 D0 5A 00 1E 39 33 6C 03 00 01 03 04 00 02 00 58 00 23 |
3 | |
4 | 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 |
5 | 0B 59 00 00 05 32 00 10 01 15 7F 13 03 D9 34 04 6A 24 00 2C 00 12 C8 11 |
6 | |
7 | 45 46 47 48 49 50 51 52 CHK |
8 | 13 88 0C 68 51 00 00 00 CD |
- Byte 2 und 3 ist das Gebläse in rpm - Byte 9 ist die Kraftstoffpumpe, 0x6C=5.4Hz; 0x35=2.65Hz - Byte 13 könnte ein On/Off Byte sein. Es ist 0x00 im Wartezustand und 0x03 wenn die Heizung läuft. Vielleicht steht 0x03 für Standheizen und 0x02 würde für Zuheizen stehen. - Byte 29 ist Flammenerkennung 0x00 oder 0x01 - Byte 33 und 34 ist der Widerstand des Glühstabs in mOhm (siehe libwbus) - Byte 39 ist der Glühstab in Prozent (wieder 0..200) - Byte 43 ist die Heizleistung in Prozent (0..200) - Byte 48 und 49 ist die Leistung in Watt. Die wird nicht mehr übertragen wenn die Heizung mal im "Pause" Zustand war (0x0F), bleibt danach einfach auf 0. Byte 43 wird noch richtig geupdated. - Byte 51 ist die Temperatur+50 (siehe libwbus) Die restlichen Bytes sind immer konstant geblieben bis auf Byte 3, 6 und 11 beim ersten Befehl und Byte 7, 21 und 31 hier. Keine Ahnung was die bedeuten. Mit diesen zwei Befehlen und dem Start und Stop Befehl habe ich mir jetzt eine Arduino Steuerung gebastelt, läuft (fast) problemlos.
Simulator ist fertig, hier die vollständige Liste aller Statuscodes:
1 | 0x63: TRS-cooling .................................... TRS-Kühlung |
2 | 0x64: Rest heat utilisation .......................... Restwärmenutzung |
3 | 0x65: State activated ................................ ADR-Zustand aktiviert |
4 | 0x66: Ready .......................................... Bereit |
5 | 0x67: Burner regeneration ............................ Brennerregeneration |
6 | 0x68: Initialisation process ......................... Initialisierungsprozess |
7 | 0x69: Sleep_Mode ..................................... Sleep_Mode |
8 | 0x6a: Continue fuel priming .......................... Fortsetzung Kraftstofffördern |
9 | 0x6b: Continue stabilization, cold start ............. Fortsetzung Stabilisierung, Kaltstart |
10 | 0x6c: Continue stabilization, warm start ............. Fortsetzung Stabilisierung, Warmstart |
11 | 0x6d: After-run ramp ................................. Nachlauframpe |
12 | 0x6e: Rest heat utilisation .......................... Restwärmenutzung |
13 | 0x6f: Stabilization, cold start ...................... Stabilisierung, Kaltstart |
14 | 0x70: PROCESSOR OFF .................................. Prozessor aus |
15 | 0x71: WAIT STATE ..................................... Wartezustand |
16 | 0x72: Continue stabilization ......................... Fortsetzung Stabilisierung |
17 | 0x73: MOTOR CHECK .................................... Motor Check |
18 | 0x74: FLAME MONITOR COOLING .......................... Flammwächterkühlung |
19 | 0x75: PRE-GLOWING1 ................................... Vorglühen1 |
20 | 0x76: PRE-GLOWING2 ................................... Vorglühen2 |
21 | 0x77: PRE-GLOWING2 Partial Load Start ................ Vorglühen Teillast, Start |
22 | 0x78: FLAME MONITOR CALIBATION Start ................. Flammwächterkalibrierung, Start |
23 | 0x79: START 1 ........................................ Start1 |
24 | 0x7a: START 2 ........................................ Start2 |
25 | 0x7b: START 3 ........................................ Start3 |
26 | 0x7c: START 4 ........................................ Start4 |
27 | 0x7d: START 5 ........................................ Start5 |
28 | 0x7e: START 6 ........................................ Start6 |
29 | 0x7f: GLOW PLUG RAMP ................................. Glühstiftrampe |
30 | 0x80: FLAME MONITOR MEASURMENT1 ...................... Flammwächter Messung1 |
31 | 0x81: FLAME MONITOR MEASURMENT2 ...................... Flammwächter Messung2 |
32 | 0x82: START1 Partial Load Start ...................... Start1 Teillast, Start |
33 | 0x83: START2 Partial Load Start ...................... Start2 Teillast, Start |
34 | 0x84: START3 Partial Load Start ...................... Start3 Teillast, Start |
35 | 0x85: START4 Partial Load Start ...................... Start4 Teillast, Start |
36 | 0x86: START5 Partial Load Start ...................... Start5 Teillast, Start |
37 | 0x87: START6 Partial Load Start ...................... Start6 Teillast, Start |
38 | 0x88: GLOW PLUG RAMP Partial Load Start .............. Glühstiftrampe Teillast, Start |
39 | 0x89: FLAME MONITOR MEASUREMENT1 Partial Load Start .. Flammwächter Messung1 Teillast, Start |
40 | 0x8a: FLAME MONITOR MEASUREMENT2 Partial Load Start .. Flammwächter Messung2 Teillast, Start |
41 | 0x8b: FULL LOAD ...................................... Vollast |
42 | 0x8c: RAMP DOWN ...................................... Auslauf |
43 | 0x8d: PARTIAL LOAD ................................... Teillast |
44 | 0x8e: RAMP UP ........................................ Hochlauf |
45 | 0x8f: PAUSE .......................................... Pause |
46 | 0x90: BURN-OUT Full Load ............................. Vollastausbrand |
47 | 0x91: BURN-OUT Partial Load .......................... Teillastausbrand |
48 | 0x92: BURN-OUT Start ................................. Startausbrand |
49 | 0x93: BURN-OUT Partial Load Start .................... Teillast-Start-Ausbrand |
50 | 0x94: BURN-OUT Overheating ........................... Überhitzungsausbrand |
51 | 0x95: COOL 1 ......................................... Kühlung 1 |
52 | 0x96: FLAME MONITOR CALIBRATION ...................... Flammwächterkalibrierung |
53 | 0x97: COOL 2 ......................................... Kühlung 2 |
54 | 0x98: Boost .......................................... Boost |
55 | 0x99: CONTINUOUS COOLANT TEMPERATURE CONTROL ......... Stufenlose Heizleistungsregelung |
56 | 0x9a: CONTINUOUS COOLANT TEMPERATURE CONTROL HOLD .... Stufenlose Heizleistungsregelung-Halten |
57 | 0xa0: Stabilization, warm start ...................... Stabilisierung, Warmstart |
58 | 0xa1: Start ramp, cold start ......................... Startrampe, Kaltstart |
59 | 0xa2: Start ramp, warm start ......................... Startrampe, Warmstart |
60 | 0xa3: Residual heat utilization test ................. Test Restwärmenutzung |
Bei allen anderen Codes zeigt die TT Software <unknown Code>. Wo genau die Grenze zwischen alter Wbus und neuer Wbus ist ist mir nicht ganz klar (falls es überhaupt eine klare Grenze gibt). Der normale "Ruhezustand" bei meiner Heizung ist jedenfalls 0x71 und nicht etwa 0x66. 0x66 habe ich im normalen Betrieb noch nicht gesehen.
Danke dir,Ist eine Weile her, das ich da was angesteuert hatte. War eine TTV mit Arduino. Mit freundlichen Grüßen
Hallo, ich habe eine STC 2000 Luftstandheizung und dort das Thermoconnect Teil dran. Egal welche Temperatur ich einstelle in der App, egal ob es warm oder kalt ist im Auto, die Heizung läuft auf Max. Habe ich da in der App einen falschen Ausgang drin? In der erweiterten Einstellungen zum Ausgang gibts: - deaktiviert - aktiviert - impulsregelung - parallelregelung mit w bus - parallelregelung mit w bus und impulsregelung Kann das damit zusämmenhängen? Aktuell ist parallelregelung mit w bus eingestellt. Möchte da aber nix verändert. Webasto Support versteht das Problem nicht.. und sonst finde ich bei Google nix dazu.. Könnt ihr mir helfen? Danke!
Die Heizung kennt doch eigentlich nur Voll- / Teillast abhängig von der Kühlwassertemperatur. Um auch noch nach der Innenraumtemperatur zu regeln müsste die ja irgendwo gemessen werden - hast du da irgendwo einen sinnvollen Istwert? Sascha
Sascha W. schrieb: > Die Heizung kennt doch eigentlich nur Voll- / Teillast abhängig von der > Kühlwassertemperatur. Um auch noch nach der Innenraumtemperatur zu > regeln müsste die ja irgendwo gemessen werden übernehmen das nicht die PKW eigenen Steuergeräte? jedenfalls wurde eine Webasto immer el. zwischengebaut, von 2003 sogar so brutal das es selbst die Innenlüfter steuerte. Das war dann so das der Webastostromkreis mit 20A abgesichert war, obwohl mein Innenlüfter mit 30A lief, damit zur Folge hatte, wer nicht nach Anleitung die Lüfterdrehzahl drosselte den bestrafte die Webasto mit kaltem PKW, die 20A war einfach durch! Noch schlimmer, weil Wasser in den Luftschacht eindringen konnte, das die Lüfterachse rostete, was sie schwergängiger machte, verursachte auch mehr Motorstrom. Ein falsch oder schlampig montierter Pollenfilter bei der Inspektion reichte.
:
Bearbeitet durch User
Jain, früher war das wie von dir beschrieben, die Webasto hatte ein PWM-Steuergerät mit dem der Lüfter von der Bordelektrik getrennt und direkt angesteuert wurde. Da musste man auch immer dran denken die Lüftung auf die Scheibe zu stellen und die Temperatur hoch zu drehen damit die Klappen in der Lüftung richtig standen - sonst war es früh trotz Heizung kalt im Auto. Aktuell gibts für alle (weiß nicht) neueren Fahrzeuge ein Gateway auf CAN-Bus, über das die Heizung sowohl den Lüfter als auch die Klappenverstellung ansteuern kann. Das heißt aber nicht das dabei die gesamte Klimasteuerung im Auto aktiv ist - zumidest zeigt die da auch nix an, daher glaube ich nicht das da die Temperatur entsprechend geregelt wird. Evl. könnte sich die Heizung aber über den CAN-Bus die Innenraumtemperatur besorgen. Sascha
Sascha W. schrieb: > neueren Fahrzeuge ein Gateway auf > CAN-Bus das meinte ich und vermutete es auch Sascha W. schrieb: > Evl. könnte sich die Heizung aber über den CAN-Bus die > Innenraumtemperatur besorgen. ist durchaus denkbar, das muss nicht zwingend am w-bus sichtbar sein!
Joachim B. schrieb: > ist durchaus denkbar, das muss nicht zwingend am w-bus sichtbar sein! dann müsste die Reglung aber eher von der Klimasteuerung des Fahrzeugs vorgenommen werden, und dann könnte die über die App gesetzte Temperatur ggf. auch im Auto zu sehen sein?! Kann erst mal nur Benni klären wie seine Heizung mit dem Fahrzeug gekoppelt ist. Ohne passende Kopplung kann man in der App warscheinlich sonst was einstellen - es hat dann halt keine Wirkung. Oder der Temperatursensor ist in der ThermoConnect irgendwo hintem Armaturenbrett. Sascha
Sascha W. schrieb: > Kann erst mal nur Benni klären eben wir können nur spekulieren! Nathanael R. schrieb: > Simulator ist fertig, hier die vollständige Liste aller Statuscodes: trotzdem eine Wahnsinnsleistung! was habe ich seit 2003 alles versucht den Zicken meiner beiden Webasto auf den Grund zu kommen, etliche Dongles gekauft, selber gebaut und trotzdem nie Erfolg gehabt. Selbst wenn man zu einer Webasto Service Stelle geht wird man abgezockt. Vielleicht (ganz großes VIELLEICHT) meinte der Mensch es auch nett, aber Unterspannungsabschaltung hätte er mir ja nach Auslesen für 100,-€ auch sagen können, aber ein schlapper Akku bleibt ein schlapper Akku, da hilft auch Nachladen nichts, hat den Akkuneukauf nur verzögert aber im Winter nicht für ein warmes Auto gesorgt, wäre ich böse würde ich das Umsatzgenerierung nennen! Es hätte mich ja noch einmal zu diesem "Service" bringen können.
Guten Tag, ich habe eine Frage zur Steuerung einer Webasto AirTop 2000STC! Ich habe mich durch diesen Forenthread gelesen und bin über das Fachwissen sehr beeindruckt! Daher meine Anfrage hier, in der Hoffnung dass ihr mir weiterhelfen könnt. Ich würde diese Standheizung sehr gerne in einem "Leistungs - Modus" betreiben können. Soll heissen dass ich ihr zB minimum, oder halbe oder volle Leistung vorgeben will, ohne dass sie sich ständig über den Raumthermostat aus und einschaltet. Es ist ausgesprochen lästig, dass sich die Webasto ständig ein und ausschaltet sobald sie mein Reisefahrzeug aufgeheizt hat. Ich möchte sie zB für die Nacht in den Miminum Leistung Modus versetzen so dass sie einfach durchläuft. Ist es möglich über den K-Bus die Taktung der Spritpumpe und/oder die Lüfterdrehzahl vorzugeben? Kein mir bekanntes Steuergerät für die AirTop 2000 von Webasto bietet diese Funktion. Bei Autotherm und diversen Chinaheizungen ist das problemlos möglich. Weiters will ich nicht auf einen anderen Hersteller wechseln, weil mein Fahrzeug mit Benzin betrieben wird und Webasto einer der wenigen Benzin Standheizungshersteller ist. Vom Programmieren habe ich leider keine Ahnung, daher meine Anfrage hier. Vielen Dank für euer Fachwissen und Grüsse, Auf Achse .
Hallo zusammen,
ich versuche seit einer Woche meine praktisch neue Dual Top (Wohnmobil
Heizung) mit eigenen Mitteln "fernzusteuern" und verzweifle langsam...
Die Heizung soll am Ende an meinen selbst gebauten "Bordcomputer" auf
Basis eines ESP32 angeschlossen werden und so wie mit einer Thermocall
(auch) über Mobilfunk gesteuert werden können.
Um zu sehen was auf dem Bus passiert habe ich mir einen Sniffer gebaut
(auf Basis eines ESP32 mit einem diskreten W-BUS Interface). Zusätzlich
habe ich etwas mit der WTT Software herumgespielt.
Mit der (uralt) WTT Software, die im Netz verfügbar ist (V 2.13) kann
ich eine Diagnose durchführen und mir den vollständigen Gerätestatus
ansehen, aber ich kann die Heizung damit nicht steuern, nicht einmal die
"einfachsten" Befehle (EIN - f4 03 20 ff 28 / AUS ...) werden von der
Heizung ausgeführt, aber quittiert wie erwartet. Ebenso nicht von meinem
zwischenzeitlich etwas aufgeüsteten Sniffer, den ich unter der Adresse 2
(aber auch F probiert, also wie die Test-Software) senden lasse.
Auf dem Bus sehe ich allerdings die korrekte Kommunikation.
Sender sendet (24 03 20 ff f8) = beliebig lange einschalten. Heizung
antwortet wie erwartet (42 03 a0 ff 1e), aber sie tut nichts.
Angeschlossen war mein Sniffer und die Testsoftware an einem freien
4-poligen Stecker in der Nähe des Bedienelements, der anscheinend für
die Telestart ist.
Ich habe auch festgestellt, dass das Bedienelement ("Anzeige") an einem
physikalisch anderen W-Bus hängt, als obengenannter Stecker, auf dem
etwas anderes stattfindet. Ein Teil des Traffics vom Bedienelement-Bus
wird auch auf den anderen Bus für die Telestart gesendet: z.B. (44 03 a0
ff 18), das ist ebenfalls eine Quittung auf das Einschaltkommando vom
Bedienelement, allerdings schickt die Heizung das quasi an sich selbst
(44).
Wenn ich das Bedienelement einschalte, sendet die Heizung auf dem Bus
für die Telestart 3 Mal (42 03 39 02 7a), das geht offensichtlich an
eine -optional- vorhandene Telestart/Telecall (Adresse 2), ich habe aber
keine. Im Anschluss sendet die Heizung 3 Mal (48 03 51 01 1b), das geht
an Adresse 8 und scheint eine Abfrage der Geräte-ID (51 01) zu sein.
Welche optionale Komponente die Adresse 8 hat, weiß ich nicht.
Ich könnte mir vorstellen, dass in dem Letztgeschriebenen das Geheimnis
steckt: antworten diese Geräte auf die initiale Anfrage nicht, werden
sie danach ignoriert (?). Vielleicht kennt sich ja jemand aus, und weiß,
wie auf diese Anfragen der Heizung zu reagieren ist.
Oder was ich insgesamt anders machen muss ;-)
Versuchsweise habe ich mich auch schon an den W-BUS des Bedienelements
gehangen (ohne das Bedienelement), dort bekomme ich auf den
Einschaltbefehl (24 03 20 ff f8) allerdings sowas wie ein NAK zurück:
(42 04 7f 20 11 08)
Was ich noch nicht gemacht habe, ist Datenverkehr zwischen Heizung und
Bedienelement aufzeichnen, vielleicht lässt sich ja daraus noch etwas
ableiten. Hoffe aber trotzdem auf etwas Input von hier :-)
Gruß
Purehunter
:
Bearbeitet durch User
Beitrag #6958542 wurde von einem Moderator gelöscht.
Hallo, ich habe zwar keine Ahnung von der Dual Top aber vielleicht hilfts ja: - Welche Dual Top ist das genau? Wenn ich das richtig gesehen habe gibt es welche die zusätzlich noch mit Strom heizen können. Vielleicht hat diese Einheit eine eigene Firmware mit der Adresse 8. Ist aber nur geraten. - Hast Du schon versucht auf dem Bus an dem das Bedienteil angeschlossen ist mit der (eigenen) Adresse F zu senden? In Deinem Beitrag ist das nur für den Telestart-Bus sicher herauszulesen. - Auf welchem Bus hast Du die WTT laufen lassen? Falls nur auf dem Telestart-Bus kannst Du das ja noch auf dem des Bedienpanels probieren. - Mit welcher Wbus Version läuft die Heizung? Wird dann später interessant wenn sie mal läuft um den Betriebstatus richtig zu interpretieren. Was ich machen würde ist genau das was Du selbst schon unten erwähnt hast, nämlich den Verkehr von Bedienteil und Heizung auf diesem Bus mit zu hören und genau das dann nachzubauen. Da die Heizung ja mit dem Bedienteil gestartet werden kann muss es dann auch mit deiner eigenen Hardware funktionieren. Genau so hab ich das auch gemacht. Den anderen Bus würde ich einfach vergessen. Grüße
Hello! Ich hoffe es stört nicht zu sehr, dass ich mich hier einfach quer mit einer themenfremden Frage einklinke aber ich möchte auch nicht unbedingt einen neuen Thread anlegen. Ich fahre einen SupberB von 2018 mit originaler Standheizung inkl. Funkfernbedienung. Meine Recherche ergab, dass es eine Webasto (5Q0815005) Heizung sein sollte. Ich frage mich nun, ob es als semi geübter elektrotechnik Bastler möglich ist, sich mit einem ESP32 o.Ä. zwischen Funkempfänger und Steuerung einzuhängen um das Signal zum Starten der Heizung über mein Smart-Home zu senden? Das einfachst wäre zwar einen zweiten Handsender zu kaufen, allerdings kosten die Teile meines Wissens nach über 200€, die ich nicht einsehe.
Hallo, Geht bestimmt. Auf die Schnelle hab ich nachgeguckt und gesehen, dass das eine Thermo Top Evo ist. Sofern die nicht Fahrzeugherstellerspezifisch verändert wurde wird die auch über den Webasto Wbus gesteuert. Dann einfach eine eigene Hardware basteln und auch an den Bus hängen. Grundlagen zum Wbus gibts z.B. hier https://mk4-wiki.denkdose.de/artikel/w-bus/start oder auch in der libwbus. Und ansonsten den anderen Wbus Thread hier im Forum durchforsten. Grüße
Nathanael R. schrieb: > Hallo, > > Geht bestimmt. Auf die Schnelle hab ich nachgeguckt und gesehen, dass > das eine Thermo Top Evo ist. Sofern die nicht > Fahrzeugherstellerspezifisch verändert wurde wird die auch über den > Webasto Wbus gesteuert. Dann einfach eine eigene Hardware basteln und > auch an den Bus hängen. Grundlagen zum Wbus gibts z.B. hier > https://mk4-wiki.denkdose.de/artikel/w-bus/start oder auch in der > libwbus. Und ansonsten den anderen Wbus Thread hier im Forum > durchforsten. > > Grüße Vielen Dank für deinen Beitrag! Für mich wäre besonders interessant, ob man irgendwie leicht herausfinden kann oder evtl. weiß ja jemand wie der Funkempfänger mit der Standheizung kommuniziert. Ich könnte mir nämlich gut vorstellen, dass da gar nicht viel über BUS gearbeitet wird sondern dass der Empfänger das Signal über Funk erhält und dann ein einfacher Hi/Lo Puls das Programm startet, das im Boardcomputer voreingestellt ist. Wenn dies der Fall wäre, dann könnte ich wohl ganz simpel einen ESP zwischen die beiden Drähte hängen und den Puls schicken. Mein Problem aktuell ist einfach, dass ich nur ein kleiner Bastler bin und der Spaß bei mir dort aufhört wo BUS anfängt. Google hilft mir gerade auch nicht viel weil natürlich zu 99,9% die Leute einen Fernstart realisieren wollen, die eben keinen Funkempfänger haben. Im Reparaturleitfaden und den offiziell erlangbaren Dokumenten finde ich nur die Position des Emfpängers aber leider keine Info zu Kabelbelegung oder gar ein Schaltplan des Emfpängers.... Wenn noch jemand Tipps für mich hätte damit ich in die richtige Richtung komme, wäre ich sehr Tankwart!
Also wenn deine Fernbedienung die offizielle von Webasto ist, dann ist auch der entsprechende Empfänger verbaut und der kommuniziert per W-Bus. Der Empfänger hat aber glaube ich noch einen Signaleingang an den ein Taster angeschlossen wird, so das man die Heizung darüber auch im Fahrzeug ein-/ausschalten kann (für nachträglichen Heizungseinbau). Eine alternative Funkstrecke wirst du für deinen Anwendungsfall bauen müssen - nur die Fernbedienung wirst du nicht emulieren können. Einen ESP würde ich nicht ins Auto einbauen - braucht zu viel Strom. Sascha
Ja, das ist im Prinzip auch mein Problem. Ich würde sie auch gerne auf 1kw laufen lassen, geht aber ständig an und aus. Jede Chinaheizung läuft entspannt durch auf kleiner Stufe..
AufAchse schrieb: > Guten Tag, ich habe eine Frage zur Steuerung einer Webasto AirTop > 2000STC! > > > Ich würde diese Standheizung sehr gerne in einem "Leistungs - Modus" > betreiben können. Soll heissen dass ich ihr zB minimum, oder halbe oder > volle Leistung vorgeben will, ohne dass sie sich ständig über den > Raumthermostat aus und einschaltet. > > Es ist ausgesprochen lästig, dass sich die Webasto ständig ein und > ausschaltet sobald sie mein Reisefahrzeug aufgeheizt hat. Ich möchte sie > zB für die Nacht in den Miminum Leistung Modus versetzen so dass sie > einfach durchläuft. Gibt es hierzu eine Antwort? Ich habe exakt das gleiche Problem. Entweder sie geht aus an aus an (Temperatur zu niedrig vorgewählt) oder sie läuft durch aber nicht in Teillast, dann wird es schnell 30 grad im Auto. Bin echt am überlegen, ob ich die STC 2000 rausschmeiße und mir eine Autoterm einbaue, die stabil auf 0,8 kw läuft. Webasto ist einfach nur peinlich, dass die so eine einfache Regelung nicht hinbekommen
Benni schrieb: > Hallo, ich habe eine STC 2000 Luftstandheizung und dort das > Thermoconnect Teil dran. Egal welche Temperatur ich einstelle in der > App, egal ob es warm oder kalt ist im Auto, die Heizung läuft auf Max. > Habe ich da in der App einen falschen Ausgang drin? In der erweiterten > Einstellungen zum Ausgang gibts: > - deaktiviert > - aktiviert > - impulsregelung > - parallelregelung mit w bus > - parallelregelung mit w bus und impulsregelung > > Kann das damit zusämmenhängen? > > Aktuell ist parallelregelung mit w bus eingestellt. Möchte da aber nix > verändert. Webasto Support versteht das Problem nicht.. und sonst finde > ich bei Google nix dazu.. Könnt ihr mir helfen? Danke! Die Regelungsarten solltest du nicht verändern. Die STC funktioniert ausschliesslich über den W-Bus. Die Impulssteuerung war dazumals für die alten Heizungen. Dort wurde auf eine Leitung legendlich ein + angelegt und die Heizung startete. Du solltest einen direkt Heizstarttaste besitzen, dieser hat einen integrierten Temperaturfühler für das Thermoconnect. Die Natelapp sollte dir die Temperatur im Auto verraten und entsprechend die Heizung regeln. (Temp ist direkt unter der ,,Timer'' Anzeige im App. Des weiteren startet die STC immer auf voller Stufe und regelt langsam zurück wen die gewüschte Temperatur langsam erreicht wird. Die Heizung lüftet dann nurnoch. Hast du Umluft oder Frischluftbetrieb? Falls du Umluftbetrieb hast, sollte die nun gewünschte Temperatur durch das lüften relativ gut gehalten werden. (Je nach Isolation Fzg)
Danke für die ausführliche Antwort. Das Auto ist ein Vito, der nachträglich von allen Seiten sehr gut gedämmt wurde, bis auf das Fahrerhaus und die Türen. Ja ich habe die Taste, diese besitzt auch einen TemperaturFühler. Dieser regelt jedoch nicht die Temperatur, sondern zeigt sie nur an. Das wurde schon mehrfach berichtet. Die Anzeige in der App geht auf 25 Grad hoch, aber die Heizung fährt auf Volllast weiter. Ich habe Umluftbetrieb, und die Ansaugung ist unter dem Beifahrersitz. Erst wenn dort warme Luft ankommt, geht die Heizung aus, bzw auf Lüftung. Zu dem Zeitpunkt steht auf der App auch schonmal 30 Grad, weil der Knopf recht hoch unter dem Dach hängt. Das macht alles keinen Sinn, was Webasto da macht. Ich habe jetzt den externen Sensor bestellt und wenn ich mal Zeit habe, baue ich ihn an und setze ihn neben den Knopf. Ich hoffe, dann funktioniert die Regelung besser.
Hallo zusammen, sehr interessante Diskussion hier. Es mag sein, dass ich es überlesen habe, aber wenn nicht: Hat irgendjemand schon mal ein MultiControl fernbedient? Meine Anwendung wäre, dass es eine "Smart Home" Installation in dem mobilen Heim gibt, die aus verschiedenen Kabinen heraus Einfluss auf die Heizung nehmen will, ohne immer zum MultiControl laufen zu müssen. Letztendlich soll (neben der lokalen Bedienung) die Heizung/Lüftung weitgehend automatissiert werden, abhängig von Anwensenheit, Wetterstatus und Wettervorhersage. Ich will also nicht nur die Heizung/Lüftung fern ein-/ausschalten, ich will die Modis und Temperaturvorgabe am MultiControl aus der ferne umfassend kontrollieren. Wenn ich das bisher richtig verstehe, wird hier diskutiert, wie z.B. so ein MultiControl die Heizung kontrolliert und ersetzt oder ergänzt werden kann. Aber wie übernehme ich die Kontrolle über MultiControl? Es geht um eine aktuelle WEBASTO AIR TOP EVO 40 mit Multicontrol Weiß irgendjemand, ob das geht und wie?
Hallo, Habe zwar keine Ahnung von MultiControl, aber was ist mit der Option nicht MultiControl zu “bedienen” sondern alle benötigten Features mitzulesen und nachzubauen und dann MultiControl doch mit was eigenem ersetzen, was aber alles kann was Du brauchst. Ob das jetzt wirklich leichter ist ist natürlich nicht klar, nur ne Idee.
Angehängte Dateien:
-
WebastoMultiControl01.jpg
140 KB
Danke für Deine Antwort! Sicherlich ist es möglich, die Multicontrol Interaktion zu analysieren und letzlich nachzumachen. Ich hoffe nur, das eigentliche System minimalinvasiv anzupieksen und einfach das, was gut funktioniert, auch bestehen zu lassen. Das Bedienelement Multicontrol mach einen guten Job. Es ist extrem Stromsparend und bietet eigentlich alle Bedien- und Beobachtungsmöglichkeiten, die man braucht. Einschließlich Fehleranzeigen oder so ein Krams. Mir ist noch nicht klar, ob die Raumtemperaturregelung in dem Multicontrol läuft oder ob das Multicontrol nur die Steuerung macht, den Sollwert vorgibt und die Regelung in der Heizung abläuft. Eine Raumtemperaturregelung ist zwar kein Hexenwerk, aber das wollte ich eigentlich nicht übernehmen. Ein übergeordnetes System soll die Kontrolle über ein Subset von Funktionen übernehmen und nach Möglichkeit sollte das Multicontrol das alles konsistent zur Anzeige bringen. Aber gut. Ich werde mal einen Sniffer bauen und mithören. Vielleicht ergibt sich daraus ja auch alles, was ich brauche. Ich hege nur die Hoffnung, dass jemand sowas schon mal gemacht hat und mir wertvolle Hinweise geben kann.
Hallo Fiso, also seit meinem letzten Fahrzeugwechsel hab ich mit der neuen Thermo Top Evo auch die Multicontrol drin, an den Kommandos die da an die Heizung rausgehen hat sich gegenüber der 1533 die ich zuvor hatte nichts geändert. Meine Fernbedienung geht nach wie vor und auch der damit gestartete Heiz-/Lüftungsbetrieb wird von der MC korrekt angezeigt. Wenn du natürlich weitergehende Funktionen der MC wie Temperaturreglung mit deiner Airtop nutzen kannst und dies parrallel noch mit einer eigenen Bedieneinheit tun willst könnte ich mir vorstellen das das nix wird, denn die Intelligenz wird wohl in der MC stecken. Das würde dann bedeuten das du über den Bus die Vorgaben in der MC änderen müsstest und ob das geht - ich glaub es nicht, da mir gerade nichts einfällt wozu das erforderlich sein sollte - zumides aus Sicht des Herstellers. (Außer man könnte die MC mit der Thermotop Software parametrieren) Sascha
Angehängte Dateien:
-
Oszi_Wbus_break01.jpg
230 KB -
Oszi_Wbus_Adresse6_a.jpg
240 KB
Hallo Sascha, vielen Dank für Deine Einschätzungen und Befunde. Ich habe gestern endlich meinen W-Bus mit einem Oszi angezapft und beginne mir anzuschauen, was das MC so mit der Heizung diskutiert. Erster Befund: Erstaunlich wenig. Zweiter Befund: Hier ist das Break Signal klar 25ms/25ms Dritter Befund: Das MC versucht beim Initialisieren mit noch anderen Busteilnehmern Kontakt aufzunehmen. Da ist aber niemand außer der Heizung. Hat jemand eine Idee, welche Webasto Kompnente normalerweise auf die Adresse 6 hört?
Nope, kenne nur die 0xF Thermo Test Software 0x4 Webasto Heizung 0x3 Webasto 1533 Timer 0x2 Webasto Telestart
Ich habe hier eine Air Top Evo 40 und das MultiControl. Das MC versucht beim Aufwachen mit einer Adresse 6 zu sprechen, natürlich ohne Antwort. Es ist nur eine Vermutung, aber ich habe das ThermoConnect TCon2 im Verdacht. Und wenn es das wäre, würde mich brennend interessieren, was MC und ThermoConnect mit einander zu besprechen hätten. Denn ThermoConnect scheint nach Betrachtung der App Screenshots genau auf die Parameter zurückzugreifen, an denen ich interessiert bin. Aber das ist eben nur im Reich der Vermutungen. Da die ThermoConnect für mich als Produkt unintedressant ist (ich mag keine geschlossenen Cloud Lösung), habe ich keine zum sniffen. Hat irgendjemand so ein Ding?
Es gibt noch einen Webasto Temperaturfühler. Der wird auch an den W-Bus angeschlossen und hat natürlich auch eine Adresse. Ich muss mal schauen ob ich die ermitteln kann. Ich habe so einen mal gekauft für meine Telecall, hat mir aber keinen Vorteil gebracht, seither liegt das Ding in der Kiste. ThermoConnect kenne ich nicht, nutze wie gesagt die GSM-Lösung von ThermoCall und bin damit mehr als zufrieden. Die braucht nur lausiges GSM und einen Anruf, keine Mehrkosten, kein Internet, keine Cloud und trotzdem von überall ansteuerbar.
Ich bin dank der zahlreichen hilfreichen Informationen hier in diesem thread ein paar Schritte weiter. Ganz besonders klasse ist die Fortsetzung der Tabelle mit den Status-Codes! Danke für das Austüfteln und Einstellen hier! Wenn's interessiert, hier ein paar Erfahrungen und Erkenntnisse: 1. Der originale 25ms/25ms break kann bei meiner Kombination recht frei neu interpretiert werden. Es funktioniert auch 33ms/17ms oder ähnliches. Allerdings wird immer, selbst bei der originalen MC Webasto Kommunikation, das erste Telegramm nach dem break ignoriert und muss wiederholt werden, damit die Heizung antwortet. Das bleibt auch so, selbst wenn man das erste Telegramm auf den Zeitpunkt der Telegrammwiederholung verschiebt. Wenn der Bus erstmal wach ist, wird jedes weitere Telegramm ohne break und Wiederholung sofort beantwortet. 2. Die Raumtemperaturregelung läuft nicht im Multicontrol. Das Multicontrol gibt nur die Solltemperatur vor und sended danach alle 15 Sekunden das keep alive Telegramm. Sonst nichts. 3. Das Multicontrol lässt sich nicht reinquatschen. Alle Versuche, dem Multicontrol eine neue Solltemperatur unterzuschieben, sind fehlgeschlagen. Soweit nicht ganz überraschend. Etwas rätselhaft ist, dass man am Bus so tun kann, als ob man als Multicontrol eine neue Solltemperatur vorgibt. Das wird auch braf von der Heizung quittiert. Die Regelung der Heizung bleibt aber beim Wert, den das Multicontrol vorher vorgegeben hat. Das ist so rätselhaft, weil ich bis jetzt in der Kommunikation keinen Unterschied sehen kann, ob ich nun mit meiner Software die Sollwertänderung sende oder das Multicontrol selbst. Muss ich ggf. noch weiter untersuchen, um die Ursache zu verstehen. 4. Was aber sehr wohl geht, selbst komplett die Kontrolle zu übernehmen. Dank der Hinweise hier ist das besonders sinnvoll mit der Absenderadresse 2. Dann zeigt das MultiControl an, dass das System von Extern gesteuert wird, allerdings keine Details mehr, wie z.B. die aktuelle Solltemperatur. Nur das jetzt extern getriggert geheizt wird, kann man am MC sehen. Zuerst muss die Controlle vom MC weggenommen werden. Das geht mit dem 0x10 conmmand und nach dem Auslauf der Heizung einem erneuten Einschalten mit der externen Kontrolle. Dann kann ich auch Sollwerte von Extern vorgeben und es wird danach geregelt. 5. Wenn man die ganzen schönen Istwerte und den Status der Heizung regelmäßig aktualisiert sehen will, muss man regelmäßig pollen. Wenn man dann nicht artig auf Kollisionnen achtet, kann man das keep alive Telegramm der MC schon mal so weitreichend stören, dass die Heizung abschaltet und Fehler geschmissen werden. Wenn man hier eine gewisse Zurückhaltung pflegt, geht es ganz gut. Ich habe gesehen, dass das MC unbestätigte Telegramme bis zu 4 Mal wiederholt (also 5 insgesamt). Ich habe es nun etwas dirty so gemacht, dass ich schon nach einer einzigen Wiederholung aufgebe. Der nächste Pollzyklus kommt ja schon bald. So läuft´s bisher stabil bei mir.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.