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
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
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!
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?
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.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.