mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Webasto W-Bus


Autor: Jürgen H. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Markus Fischbacher (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Folli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo

Ich suche ebenfalls noch Infos über den W-Bus.
Hast Du schon irgendwelche Infos.
Danke Folli

Autor: Kai-Boris Schad (Firma: ---) (kaipi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: uli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Tux Tux (tuxy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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-hei... 
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
Autor: Christian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Tux Tux,

Google mal nach Si9241A. Solch einen Pegelwandler/Transceiver musst du 
verbauen. Bei Fragen meld dich nochmal.

Gruß, Christian

Autor: Ille (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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ß

Autor: Sascha Weber (sascha-w)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ille (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
'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

Autor: Ille (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da fehlte noch ein Stück:

00 = ?
95 = Checksum???

Heizung antwortet:
03 c4 00 88???

Autor: Michael R. (mr-action)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Hi,

hier: 
http://sourceforge.net/p/libwbus/libwbus/ci/master... 
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

Autor: Sascha Weber (sascha-w)
Datum:
Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
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

Autor: Ille (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sascha Weber (sascha-w)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael Wulz (mwulz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sascha Weber schrieb:
> Webastosimulator

Hallo, kannst du dieses als ZIP hier uppen?

lg
Michael

Autor: Ille (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hey Sascha, nehm ich sehr gern! :)

Autor: Sascha Weber (sascha-w)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ille (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank! :) Und schönen Sonntag noch!

Autor: Torsten Henning (thenning)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ille (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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... ;)

Autor: Sascha Weber (sascha-w)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Ille (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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... :(

Autor: Sascha Weber (sascha-w)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ille (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Sascha Weber (sascha-w)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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-1...
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

Autor: Ille (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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-1...
> 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... :)

Autor: Ille (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Sascha Weber (sascha-w)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

mit was sendest du jetzt die Daten? Hterm?

Sascha

Autor: Ille (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael R. (mr-action)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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... ;-)

Autor: Ille (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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? ;)

Autor: Michael R. (mr-action)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
void WBus_Wake(){
  // TX auf High setzen
  PORTE |= (1<<PE1);
  
  // TX deaktivieren (Jetzt bekommen wir wieder die Kontrolle über den Port)
  UCSR0B &= ~(1<<TXEN0);
  
  // TX auf Low setzen
  PORTE &= ~(1<<PE1);
  
  // 50ms warten
  _delay_ms(50);
  
  // TX auf High setzen
  PORTE |= (1<<PE1);
  
  // Nochmal 50ms warten)
  _delay_ms(50);

  // TX aktivieren (Jetzt wollen wir ja gleich wieder normal senden)
  UCSR0B |= (1<<TXEN0);
}

Vielleicht hilfts ja... ;-)

Viele Grüße,
Michael

Autor: Ille (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael R. (mr-action)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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....

Autor: Ille (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael R. (mr-action)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Sascha Weber (sascha-w)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Ille (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sascha Weber (sascha-w)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Joachim B. (jar)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Ille (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Sascha Weber (sascha-w)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ille (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sascha Weber (sascha-w)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ille (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!?! ;)

Autor: Hänschen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Sascha Weber (sascha-w)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Olli Z. (z80freak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Andreas (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sascha Weber (sascha-w)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael R. (mr-action)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andreas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andreas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Olli Z. (z80freak)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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
Autor: Olli Z. (z80freak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;-)

Autor: Michael R. (mr-action)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Olli Z. (z80freak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael R. (mr-action)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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... ;-)

Autor: Olli Z. (z80freak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)"

Autor: Michael R. (mr-action)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
25ms low und 25ms high?! Ich dachte die Highphase muss bei dir jetzt 
<10ms sein... :-o

Oder war das noch eine Bonuswartezeit?

Autor: Olli Z. (z80freak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andreas Kräuchi (gekoch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael R. (mr-action)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andreas Kräuchi (gekoch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andreas Kräuchi (gekoch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael R. (mr-action)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/maste...

Davon ab, ist in der Antwort auch garkein ACK Bit gesetzt... :-o

Autor: Andreas Kräuchi (gekoch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael R. (mr-action)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/maste...

Autor: Andreas Kräuchi (gekoch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sascha Weber (sascha-w)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andreas Kräuchi (gekoch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael R. (mr-action)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Andreas Kräuchi (gekoch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Michael R. (mr-action)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Andreas Kräuchi (gekoch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Olli Z. (z80freak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andreas Kräuchi (gekoch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael R. (mr-action)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)

Autor: Andreas Kräuchi (gekoch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Olli Z. (z80freak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Michael R. (mr-action)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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... ;-)

Autor: Olli Z. (z80freak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael R. (mr-action)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Andreas Kräuchi (gekoch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Olli Z. (z80freak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;-)

Autor: Andreas Kräuchi (gekoch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Olli Z. (z80freak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andreas Kräuchi (gekoch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael R. (mr-action)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Sascha Weber (sascha-w)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andreas Kräuchi (gekoch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sascha Weber (sascha-w)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

wie ist denn nun die Schnittstelle in der WTT einzustellen?

Sascha

Autor: Andreas Kräuchi (gekoch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Olli Z. (z80freak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andreas Kräuchi (gekoch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael R. (mr-action)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?)

Autor: Andreas Kräuchi (gekoch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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....

Autor: Weißbeck Roman (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael R. (mr-action)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sascha Weber (sascha-w)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Karl-werner Riedel (kwriedel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Sascha Weber (sascha-w)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Olli Z. (z80freak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Sascha Weber (sascha-w)
Datum:
Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
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

Autor: Weißbeck Roman (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Karl-werner Riedel (kwriedel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Sascha Weber (sascha-w)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Alex H. (hitchhiker)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Sascha Weber (sascha-w)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Alex h. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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????

Autor: Michael R. (mr-action)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Guck doch mal, was aufm Bus so los ist... Vielleicht sieht man da ja 
was...

Autor: Alex h. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich glaube die 1533 uhr schaft es nicht den bus zu wecken...

Jetzt ist die frage.... uhr oder standheizung....

Autor: Alex h. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sascha Weber (sascha-w)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Alex h. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Alex h. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sascha Weber (sascha-w)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sascha Weber (sascha-w)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Alex h. (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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

Autor: Sascha Weber (sascha-w)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Alex h. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Sascha Weber (sascha-w)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Alex h. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Alex h. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Sascha Weber (sascha-w)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Alex h. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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..

Autor: Alex h. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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?

Autor: Sascha Weber (sascha-w)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Alex h. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Olli Z. (z80freak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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
Autor: Alex h. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sascha Weber (sascha-w)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Alex h. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Alex h. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Alex h. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Liegt das Problem vllt am 510ohm pullup zwischen wbus und 12v am l9637?

Autor: Alex h. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kann mir mal jemand sagen wie ich den 0x44 command check richtig 
aufbaue?

0xf4 0x03 0x44 0x?? 0xchecksumme

Danke
.. krig langsam ne krise

Autor: MichaR (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie das aussehen muss, steht doch in der txt im svn bzw. Git von der 
libwbus...

Autor: Alex h. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Olli Z. (z80freak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Sascha Weber (sascha-w)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Alex h. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Poste ich gleich!

Irgendwie krig ich dein Simulator nicht zum laufen..

Hast du eine Anleitung?

Autor: Sascha Weber (sascha-w)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Alex h. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Sascha Weber (sascha-w)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Alex h. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Sascha Weber (sascha-w)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Olli Z. (z80freak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Für schnelle Tests hatte ich mir mal ein Checksum-Tool geschrieben, 
vielleicht hilfts:

http://mk4-wiki.denkdose.de/tools/w-bus/checksum.php

Autor: Sascha Weber (sascha-w)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Olli Z. (z80freak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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ß").

Autor: Alex h. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du Sascha.....

Was soll mir .. rx:Echo sagen?!

Wenn ich tele heizen klicke hab ich das beim senden Check cmd...

Danke

Autor: MichaR (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das er das echo empfängt... Alles, was du auf den wbus schreibst, ließt 
du ja auch wieder zurück...

Autor: Alex h. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also für mein arduino Simulator uninteressant

Autor: Olli Z. (z80freak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Alex h. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Warum ff?!

Autor: Michael R. (mr-action)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/maste...

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...

Autor: Olli Z. (z80freak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Alex h. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Markus Bartels (djmaba)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Alex h. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Musste!

Autor: Sascha Weber (sascha-w)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ...
checksum=0
cmddata=(0x34,0x03,0x21,0x1e,0x00)
for i=0 to len(cmddata)-1
 checksum=checksum xor cmddata(i)
next
cmddata(len(cmddata)-1)=checksum

Sascha

: Bearbeitet durch User
Autor: Olli Z. (z80freak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael R. (mr-action)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Sascha Weber (sascha-w)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Olli Z. (z80freak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, was python angeht bin ich ein Noob :-/

Hier mein kläglicher Versuch in python einen SH-Simulator zu machen:
import serial
import binascii
import time
import sys

ser = serial.Serial('COM3', 2400, timeout=None, parity=serial.PARITY_EVEN)
time.sleep(2)
ser.read(ser.inWaiting())
ser.flush()
while 1:
    addr = ord(ser.read(1))
    if(addr == 0x34):
        len = ord(ser.read(1))
        cmd = ord(ser.read(1))
        if(cmd == 0x21):
            min = ord(ser.read(1))
            print("1533 send 'start heater for %d minutes'" % min)
            chk = ord(ser.read(1))
            ans = b'\x43\x03\xA1\x1E\xFF'
            ser.write(ans)
            ser.read(5)
        elif(cmd == 0x44):
            print("1533 send 'check running'")
            ser.read(3)
            ans = b'\x43\x03\xC4\x00\x84'
            ser.write(ans)
            ser.read(5)
        else:
            print("1533 send unknown command")
            s = 'ADDR=%s, LEN=%s, CMD=%s' % (hex(addr),hex(len),hex(cmd))
            #s = s + ' DATA: %s' % binascii.hexlify(ser.read(len))
            ser.read(len-1)
            print(s)
    else:
        print("reading other bytes...")
        s = 'ADDR: %s' % hex(addr)
        len = ord(ser.read(1))
        s = s + ' DATA: %s' % binascii.hexlify(ser.read(len))
        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.

Autor: Lars (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sascha Weber (sascha-w)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Lars (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Markus Bartels (djmaba)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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..

Autor: Sascha Weber (sascha-w)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Lars (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Olli Z. (z80freak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Lars (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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_el...

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

Autor: Alex h. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Alex h. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Alex h. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ansonsten 8pin stecker weg und direkt den wbus anzapfen... Kann sein das 
der canbus dir alles  klaut

Autor: Olli Z. (z80freak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Sascha Weber (sascha-w)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Olli Z. (z80freak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: ich von ichhausen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Olli Z. (z80freak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Olli Z. (z80freak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Alex h. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Olli Z. (z80freak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Michael R. (mr-action)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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? 
;-)

Autor: Olli Z. (z80freak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Michael R. (mr-action)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Probiers mal ohne den WLAN Kram dazwischen...

Autor: Olli Z. (z80freak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Nett (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Olli Z. (z80freak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael R. (mr-action)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Olli Z. (z80freak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
0 ---- 21:37:20 --------------------------------
[7°C] [12.62 V] [0] [0 W] [0.2 Ohm]
1 ---- 21:37:24 --------------------------------
[9°C] [12.62 V] [0] [0 W] [0.2 Ohm]
2 ---- 21:37:29 --------------------------------
[10°C] [12.60 V] [0] [0 W] [0.2 Ohm]
3 ---- 21:37:33 --------------------------------
[10°C] [12.60 V] [0] [0 W] [0.2 Ohm]
4 ---- 21:37:37 --------------------------------
Und das hat auch nichts mit WLAN zu tun, ist beim direkten Bus auch so.

: Bearbeitet durch User
Autor: Olli Z. (z80freak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Olli Z. (z80freak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: MichaR (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Olli Z. (z80freak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: MichaR (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also die CRC solltest du schon noch checken...

Autor: Olli Z. (z80freak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Michael R. (mr-action)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Olli Z. (z80freak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Sascha Weber (sascha-w)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Olli,

hast du mal versucht mit CMD 0x51 0x0C alias IDENT_WB_CODE auszulesen 
was die Heizung unterstützt?

#define     WB_CODE_0     0 /* Unknown supplemental heater feature */
#define     WB_CODE_ON    3 /* on/off switch capability */
#define     WB_CODE_PH    4 /* Parking heater capability */
#define     WB_CODE_SH    5 /* Supplemental heater capability */
#define     WB_CODE_VENT  6 /* Ventilation capability */
#define     WB_CODE_BOOST 7 /* Boost capability */

da sollte doch Bit 4 & 5 die gewünscht Info liefern.

Sascha

Autor: Michael R. (mr-action)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Olli: Seine Pumpe wird nicht automatisch anlaufen, denn er hat 
garkeine... VW verbaut die Pumpe nur bei einer Standheizung... Denn der 
Zuheizer läuft nur, wenn der Motor läuft und dann braucht man keine 
zusätzliche Wasserpumpe (von einigen Fahrzeugen mit Kühlwassernachlauf 
usw. mal abgesehen - aber das wäre mir im Touran neu)...

@Sascha: Sehr schöne Idee! Hatte ich garnicht im Kopf, was es so an 
Sensorwerten gibt...

Autor: Olli Z. (z80freak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, Michael, das war auch mein erster Gedanke. Aber, again what learned 
;-) die haben alle eine solche Pumpe verbaut. Ist bei Ford aber 
eigentlich nicht anders, denn meiner hatte ja auch nur Zuheizer. Die 
scheint beim Start der Zuheizung sogar anzuspringen (laut Aussage). Also 
kein Wärmestau.

Einzig der Lüfter im Fahrzeug bleibt natürlich aus. Die Climatronic im 
VW ist also scheinbar nicht für SH Betrieb konfiguriert, oder die SH 
kann diese per CAN nicht steuern. Mit einem entsprechendem 
Softwareupdate wird wohl richtig Geld gemacht, wodurch einige sich 
einfach eine entsprechende SH kaufen, oder nur die Steuerplatine und die 
dann wechseln, weil da billger kommt. Ich hab bislang keine Idee wie ein 
solches Firmwareupdate aussehen könnte und ob man diese auch "kopieren" 
kann.

Die Climatronic scheint die Klappen in der Stellung zu lassen, wie man 
den Wagen ausstellt. Daher die Idee den Lüftermotor direkt anzusteuern, 
das würde reichen.

Autor: Michael R. (mr-action)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also früher hat VW sich die Pumpe wirklich gespart... Krass, das die die 
beim Touran dann immer reingeworfen haben (macht ja eigentlich beim 
reinen Zuheizer keinen Sinn)...

Was die Climatronic angeht, zumindest im Octavia 1Z soll die normale 
Climatronic auch die Standheizung unterstützen, wenn von dieser die 
Befehle übern CAN kommen... Ich hab allerdings direkt das Bedienteil 
getauscht, weil ich die Standheizungstaste haben wollte... Aber laut 
google solls auch mit dem anderen Bedienteil gehen... Konfiguriert wird 
da ja eh nix - die neueren VWs merken ja selbst, was verbaut ist...

Anders ist also wohl nur die Software von Webasto - die unterstützt beim 
Zuheizer ja auch keine Bedienteile...

Und da du nicht weißt, was die Climatronic zuletzt gemacht hat - bist du 
sicher, das es dann reicht nur den Lüfter anzusteuern?

Davon ab: Will man nicht immer die Software von dem Zuheizer updaten? 
Sonst hat man ja wirklich nur seine gebastelte Fernsteuerung und kann 
keine original Fernbedienung oder den Timer (übern Tacho bei VW) 
nutzen...

Autor: Olli Z. (z80freak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also Du meinst, wenn man die richtigen CAN Nachrichten kennt, könnte man 
die einfach selbst anstelle der SH senden und alles ist gut?! Muss ich 
wohl mal intensiv nach suchen. Für das VW Zeugs gibt es eigentlich mehr 
Infos als zu Ford.

Zur Not halt nur Lüfter steuern. Und ja, wie ich doch schrieb verbleiben 
die Klappen in der letzten Position. Die fahren nicht zu. Man muss halt 
selbst dran denken die richtig einzustellen.

Das mit dem Firmwareupdate ist mir noch nicht klar. Wie genau wird das 
durchgeführt? Könnte mir vorstellen das das auch über den WBus läuft.

Autor: Michael R. (mr-action)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, genau das meine ich... ;-) Die passende Nachricht zu finden wird 
aber wohl nicht so easy - zumal die sicherlich auch Fahrzeugspezifisch 
ist... Also wenn du sie bei dir findest, ist die sicherlich anders wie 
im Touran...

Ja, sie verbleiben in der letzten Position - aber du weißt nicht, welche 
das ist... Du musst also um auf Nummer sicher zu gehen wirklich immer 
die Luft auf die Scheibe drehen, was immer auch gleichzeitig warm sein 
müsste... Du willst ja keine kalte Luft ins Auto schaufeln... Also muss 
man immer beim abstellen daran denken - das ist doch mega nervig! (man 
muss ja nicht gleich von Fehleranfällig sprechen)

Ja, das Firmware Update läuft übern WBus... Is mir schonmal im Netz 
übern weg gelaufen, sowas...

Autor: Sascha Weber (sascha-w)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael R. schrieb:
> Du willst ja keine kalte Luft ins Auto schaufeln... Also muss
> man immer beim abstellen daran denken - das ist doch mega nervig! (man
> muss ja nicht gleich von Fehleranfällig sprechen)
Das ist bei jeder nachgerüsteten SH aber auch so.
Dann ist halt früh die Scheibe gefrohren und dafür der Motor warm ;-)

Sascha

Autor: Michael R. (mr-action)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Na, wir sind aber doch nicht in der Chrome Abteilung von ATU sondern auf 
µC.net - wir streben doch nach Höherem... ;-)

Ich hab grade mal in die Anleitung von Webasto geguckt (Nachrüstung in 
nem Octavia 1Z)... Die Klemmen sich auch nur zwischen Klimasteuergerät 
und Lüftersteuergerät... Wundert mich ehrlich gesagt etwas... Im Golf4 
(und allem, das ungefähr das gleiche Alter hat) gab es noch einen Pin an 
der Climatronic, den man für den Standheizbetrieb auf 12V legen musste 
und dann lief alles automatisch... "Etwas" kacke, das es sowas heute 
nicht mehr gibt...

Bleibt also nur, um den ganzen Komfort zu haben:
- Zuheizer auf Standheizung upgraden (per Software)
- CAN Messages rausfinden und selbst senden

Gibts eigentlich einen relativ günstigen CAN Gateway, der sich für den 
Bus transparent verhält, aber dem PC sagen kann, welche Nachricht über 
welchen Bus kam? Damit könnte man dann mal ein Steuergerät isolieren und 
protokollieren, welche Nachrichten es schickt... Das wäre ja schonmal 
ein Anfang, wenn man sowas rausfinden will...

Autor: Olli Z. (z80freak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da muss ich Michael zustimmen, ich bin auch kein Freund von 
Bastellösungeb. Alles oder nichts! ;-)

Hatte gehofft im Internet mehr zu den CAN Nachrichten zu finden, aber 
fehlanzeige. Einzig canhack.de beschäftigt sich oberflächlich mit dem 
Thema. Leider ist das so halbmommerziell und undurchsichtig. Hatte mich 
da schon zweimal angemeldet, bin aber nach kurzer Zeit gesperrt worden. 
Scheinbar darf man da nur bleiben wenn man "dieselschrauberpunkte" 
kauft. Ich hab doch nur eine PayBack Karte! Scheiss Kapitalisten! ;-)))

Das mit dem CAN Gateway habe ich sogar schon begonnen. Die Hardware ist 
trivial, ein Arduino und zwei MCP2515 und MCP2551 als Transceiver. 
Dennoch muss man ja die eingehenden Pakete lesen, verarbeiten, ggf. 
einen Trigger für Serial oder so auslösen und auch wieder rausschreiben. 
Einfach nur RX/TX vertauscht verbinden ist wohl nicht... Wenn hierzu 
einer eine Idee hat, bitte melden! Ich werdedafür aber einen neuen 
Thread aufmachen, hat hier nix zu suchen.

Die Sache mit der SH Firmware treibt mich noch um. Nicht es langt die 
Codierung anzupassen?! Die steht ja vermutlich auf Zuheizer und dann 
könnte die TTV ja einfach keine CAN Befehle zur Climatronic senden. Am 
CAN muss ja doch sein, sonst könnte die Zuheizung nicht gesteuert 
werden. Der WBus war nicht verbunden.

Autor: Michael R. (mr-action)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zum canhack, da war ich früher mal - da gabs aber keine Infos, die es 
nicht auch so offen im Internet gab...

Also kurz zum CAN Gateway... Ich glaube nicht, das der AVR das schafft, 
wenn da viel auf dem Bus los ist! Und die externen SPI Transceiver sind 
auch keine Performancewunder - kann gehen, muss es aber nicht, wenn die 
das Timeing ziemlich streng kontrollieren... ;-)

Zum Update, du ließt deine E-Mails nicht, oder?

Autor: Olli Z. (z80freak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sascha W. schrieb:
> hast du mal versucht mit CMD 0x51 0x0C alias IDENT_WB_CODE auszulesen
> was die Heizung unterstützt?
>
> #define     WB_CODE_0     0 /* Unknown supplemental heater feature */
> #define     WB_CODE_ON    3 /* on/off switch capability */
> #define     WB_CODE_PH    4 /* Parking heater capability */
> #define     WB_CODE_SH    5 /* Supplemental heater capability */
> #define     WB_CODE_VENT  6 /* Ventilation capability */
> #define     WB_CODE_BOOST 7 /* Boost capability */

Hi Sascha! Also folgendes bekomme ich aus MEINER Heizung raus:
4F 0A D1 0C 31 3C C0 E3 3F 80 00 09

D0 = 0x0C = 0b00001100
Bit 4 mit PH ist klar. Aber was bedeutet Bit 3? Ist auch in der WBus-Lib 
nicht vorhanden.

D1 = 0x31 =
0b0011 0001
  0000 0001 ???
  0000 0010 External circulation pump control
  0000 0100 Combustion air fan (CAV)
  0000 1000 Glow Plug (flame detector)
  0000 1010 Fuel pump (FP)
  0011 0001 Circulation pump (CP)
  0100 0000 Vehicle fan relay (VFR)
  1000 0000 Yellow LED
Also mit Zirkulationspumpe. Obwohl ich weiss das da eine Dosierpumpe für 
den Kraftstoff vorhanden ist... oder ist FP was anderes?

D2 = 0x3C =
0b0011 1100
  0000 0001 Green LED present
  0000 0010 Spark transmitter
  0000 0100 Solenoid valve present (coolant circuit switching)
  0000 1000 Auxiliary drive indicator (whatever that means)
  0001 0000 Generator signal D+ present
  0010 0000 Combustion air fan level is in RPM instead of percent
  0100 0000 (ZH)
  1000 0000 (ZH)
Also hab ich ein "Solenoid valve"(?) einen Auxiliary drive indicator 
(ist das vielleicht das Ding was den Betrieb der Heizung nach "außen" 
hin zum Fahrzeug steuert/anzeigt? Also die CAN-Sendefunktion?)
Ein Generator-Signal (? Ist doch nur die popelige Spannungsüberwachung?)
Und ein "Combustion air fan level in RPM" (hmmm, drehzahl der Lüftung?)

D3 = 0xC0 =
0b1100 0000
  Unbekannte Werte

D4 = 0xE3 =
0b1110 0011
  0000 *    ?
  0000 1111 (ZH)
  0001 0000 Heating energy is in watts
  0010 0000 (ZH)
  0100 0000 Flame indicator (FI)
  1000 0000 Nozzle Stock heating
Also "Nozzle", "Flammwächter", (ZH), und etwas unbekanntes.

D5 = 0x3F =
0b0011 1111
  00** **** ?
  0010 0000 Ignition (T15) flag present
  0100 0000 Temperature thresholds available
  1000 0000 Fuel prewarming resistance and power can be read.
Auch hier nur das T15 Flag (meinen wohl "Klemme 15", also Zündung AN im 
Auto)

D6 = 0x80 =
0b1000 0000
  Unbekannte Werte

Autor: Olli Z. (z80freak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael R. schrieb:
> Ich glaube nicht, das der AVR das schafft
Es gibt hier im Forum bereits ein paar ältere Threads dazu. Die arbeite 
ich gerade durch. Es geht wohl schon, alles halbsowild. Vor allem reden 
wir hier nicht über einen HS-CAN, sondern MS-CAN mit 125kbit/s (gähn). 
Da langweilt sich doch wohl selbst ein 8-Bit 16 MHz Arduino und zwei 
SPIs ;-)

> Zum Update, du ließt deine E-Mails nicht, oder?
Na klar. Wenn da was hätte ankommen sollen, kam nichts. :-(

Autor: Michael R. (mr-action)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja, Daten aus dem einen per SPI raus, in den anderen per SPI rein und 
nebenbei noch per UART oder so an den PC schicken... Achja, und das 
eigentlich zeitgleich in beiden Richtungen, weil du ja auch Kolisionen 
auflösen musst und so Späße... Also ich denke nicht, das das soooo easy 
für den kleinen AVR ist... Da macht sich ein Controller, der mal eben so 
kann und zwei CAN Controller direkt drin hat sicher ne ganze ecke 
besser... ;-)

Aber das sollte man echt wo anders diskutieren - zurück zum Thema: Bist 
du bei deiner Auswertung vom IDENT_WB_CODE nicht um ein Byte verrutscht? 
Das erste Datenbyte müsste doch 0x31 sein und nicht 0x0C?

Autor: Olli Z. (z80freak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael R. schrieb:
> Bist du bei deiner Auswertung vom IDENT_WB_CODE nicht um ein Byte verrutscht?
> Das erste Datenbyte müsste doch 0x31 sein und nicht 0x0C?

Aaargh! Stimmt. 0x0C ist ja noch teil des bestätigten Wbus Kommandos! 
|-/

Autor: Olli Z. (z80freak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So, also hier mal der Codevergleich
Mondeo: 4F 0A D1 0C 31 3C C0 E3 3F 80 00 09
Touran: 4F 0A D1 0C 31 3C C4 E7 3F 80 00 09
Das sind eht ja aus, als würde die TTV im Touran auch auf Standheizung 
(0x21) reagieren. Tut sie aber nicht!

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.