eBus->USB->Plugin->KNX

[WernerF]

eBusAnalyzer.exe

Hallo,

gerade fällt mir auf, dass sich einige schwer tun, die Protokolldaten zu analysieren. Der erste Schritt ist natürlich, dass die Hardware funktioniert und nichts verschluckt oder verfälscht.
Wer eine Schnittstelle mit RS232-Ausgang hat, kann die Daten ja auf einem PC analysieren. Ich habe mir dazu ein Progrämmchen geschrieben, das vielleicht jemand hilft.
Es liest den COM-Port, zeigt und filtert die eBus-Telegramme und schreibt 2 Dateien: eine mit den rohen eBus-Daten (binär) und eine CSV-Datei.
Das Programm kann nachträglich auch die Raw-Datei nochmal auswerten.
Über die Konfigurationsdatei kann man Befehlsklassen definieren, über die dann die Ausgabe gefiltert werden kann.
Alles work in progress und auf eigene Gefahr. Die Sende-Option habe ich vorerst ausgeblendet, da zu wenig getestet. Ach ja, man braucht das .Net Framework 2.0
Viel Erfolg.

[2pi]

r_type Wunsch..

Hallo yuhu,

kurze Frage: kannst du noch ein hex format zum get implementieren?

Momentan habe ich einfach mal mit

int
eb_msg_send_cmd_decode(int id, unsigned char *msg, char *buf)
{
	char *c1, *c2;
	char r_pos[CMD_GET_SIZE_R_POS+1];
	char tmp[CMD_GET_SIZE_R_POS*3+1];

	int ret, i, p1, p2;
	
...

	} else if (strncasecmp(get[id].r_type, "hex", 3) == 0) {

		memset(tmp, '\0', sizeof(tmp));
		for (i = 0; i<get[id].r_len; i++)
			sprintf(&buf[3*i], "%02X \n", msg[p1+i]);
	}

erweitert, um eine hex Ausgabe von get Befehlen zu erhalten, bei denen sich die Datenformate nicht auf die von dir implementierten mappen lassen, bzw. die ??? in den csv-dateien von jumi ...

ist bei der Roh Analyse ganz hilfreich, wenn man die Datenlänge kennt - dann geht Darstellung/Rückmeldung auch per telnet.

Gruß
2pi

[kleinklausi]

Config Datei anpassen - jetzt?

Hallo yuhu,

bevor ich versuche meine Wolf Cycle Config an das neue Format anzupassen, wollte ich kurz fragen, ob irgendwas dagegen spricht? Ich bilde mir ein gelesen zu haben, dass Du noch was an der Config ändern wolltest - ich weiss aber nicht wie umfangreich das wäre.

Danke und Gruß,
Moritz

[Gast]

Hallo kleinklausi,

ja ich bin gerade dabei.

GET funktioniert schon nach der neuen Config
SET bin ich gerade dabei
CYC muss wie immer warten.

Beim Implementieren von CYC sind mir viele Gemeinsamkeiten der 3 Typen aufgefallen und doch sind sie etwas anders zu behandeln.
Somit war CYC der Auslöser für die ganzen Änderungen. Nun sollte es aber ausreichend allgemein gehalten sein.

Wenn GET und SET ausreichend funktionieren kommt es ins SVN.

Alter Aufbau:

struct cmd_get {
    int key; /**< internal number - do we need this ? */
    char class[CMD_GET_SIZE_CLASS+1]; /**< ci */
    char cmd[CMD_GET_SIZE_CMD+1]; /**< hydraulic */
    char com[CMD_GET_SIZE_COM+1]; /**< just a comment */    
    int s_type; /**< message type */
    char s_zz[CMD_GET_SIZE_S_ZZ+1]; /**< zz */ 
    char s_cmd[CMD_GET_SIZE_S_CMD+1]; /**< pb sb */
    int s_len; /**< number of send bytes */
    char s_msg[CMD_GET_SIZE_S_MSG+1]; /**< max 15 data bytes */
    int r_len; /**< number of receive bytes */
    char r_pos[CMD_GET_SIZE_R_POS+1]; /**< data position at answer string */
    char r_type[CMD_GET_SIZE_R_TYPE+1]; /**< data type */
    float r_fac; /**< facter */
    char r_unit[CMD_GET_SIZE_R_UNIT+1]; /**< unit of data like °C,...) */
};

Neues Aufbau:

Der Header eines Befehles
struct commands {
    int key; /**< internal number - do we need this ? */
    char type[CMD_SIZE_TYPE+1]; /**< type of message */
    char class[CMD_SIZE_CLASS+1]; /**< ci */
    char cmd[CMD_SIZE_CMD+1]; /**< hydraulic */
    char com[CMD_SIZE_COM+1]; /**< just a comment */    
    int s_type; /**< message type */
    char s_zz[CMD_SIZE_S_ZZ+1]; /**< zz */ 
    char s_cmd[CMD_SIZE_S_CMD+1]; /**< pb sb */
    int s_len; /**< number of send bytes */
    char s_msg[CMD_SIZE_S_MSG+1]; /**< max 15 data bytes */
    int d_elem; /**< number of elements */
    struct element *elem; /**< pointer of array with elements */
};

Jedes [B]elem[/B] hat dann folgenden Aufbau:

struct element {
    char d_sub[CMD_SIZE_D_SUB+1]; /**< pin1 */
    int d_len; /**< number of data bytes */
    char d_pos[CMD_SIZE_D_POS+1]; /**< data position at bytes */
    char d_type[CMD_SIZE_D_TYPE+1]; /**< data type */
    float d_fac; /**< facter */
    char d_unit[CMD_SIZE_D_UNIT+1]; /**< unit of data like °C,...) */
    char d_com[CMD_SIZE_D_COM+1]; /**< just a comment */
};

Es könnte sein, das d_len noch rausfliegt. Ich denke das es nicht mehr gebraucht wird.

Stattdessen könnte man noch ein d_valid hinzufügen, wenn eine Prüfung der Ein-/Ausgabe Werte gewünscht wird.
zB 01,02,03,04,05 für SET cir2 mode (Heizkreis Betriebsart) wobei 01=Ein 02=Aus 03=Auto 04=Eco 05=Absenken gültige Werte sind.

[kleinklausi]

Kann mir mal kurz jemand weiterhelfen?

Ich habe eine Datei /etc/ebusd/ebusd.conf angelegt:

# configuration file for ebusd

# bus address (FF)
#address=FF

# configuration directory of command files (/etc/ebusd)
#cfgdir=/etc/ebusd

# serial device (/dev/ttyUSB0)
device=/dev/ttyUSBHeizung

# extension of command files (csv)
#extension=csv

# run in foreground (NO | YES/NO)
foreground=NO

# log level (INF | INF, NOT, WAR, ERR, DBG, EBH, EBS, NET, ALL)
loglevel=ALL

Warum findet er die Config da nicht? Ich hatte es so gelesen, dass das Verzeichnis so passt. Oder muss der Dateiname anders heissen?

Danke

[kleinklausi]

CYC muss wie immer warten.
Wenn GET und SET ausreichend funktionieren kommt es ins SVN.

Danke. Ich schaus mir an, aber werde wohl noch kurz warten die Wolf Config komplett zu überarbeiten.

Gruß Moritz

[kobza]

Hallo Thomas et al.

ich habe die TEM-Befehle in meiner Ochsner-WP entschlüsselt und werde sie demnächst in einer Mini-Spec. dokumentieren (vorher noch ein neuer Chip und ein paar Tests).
Bei mir kommen auch DUNGS-Befehle vor (PB=06), die ich ebenfalls entschlüsselt habe.
Kommen die bei Hautec auch vor?

In meiner WP ist eine Steuerung "SE 6021 WPC" von TEM verbaut, die als OEM-Produkt bei Ochsner unter dem Namen "OTE Easy Plus" vermarktet wird.
Was für ein TEM-Produkt ist denn in Deiner Hautec drin?
Weiss jemand, welche Hersteller noch TEM-Controller benützen?

Hi WernerF,

super das Du die Befehle hast, könntest Du mir diese dann zuschicken.
Mein Controller: TEM IT 5711 MD W.
Dieser sendet sehr oft die Boradcast Nachrichet 701,801 und 802.
Lieder konnte ich noch nichts senden, mache mich aber heute dran das zu untersuchen.

Gruß
Thomas

[WernerF]

Hallo kobza,

wie gesagt, ich muss das erst zusammenschrieben, dann verteile ich meine Erkenntnisse gern.
Ich bin nicht sicher, was Du mit 701, 801 und 802 meinst. Kannst Du mal eine Beispieldatei posten oder mailen (am liebsten rohe Binärdaten)?

Die TEM-Telegramme auf meiner Anlage sind alle zyklische Meldungen des aktuellen Systemzustandes, bzw. der verschiedenen Sensoren, mit denen der Controller dann arbeitet. Deshalb sind es auch Broadcasts, so dass der Absender nicht auf eine Bestätigung warten muss.
Daher verbietet es sich auch, solche Telegramme selbst zu senden (man bringt nur das System durcheinander oder löst Fehlfunktionen aus). Dafür kann man mit den TEM-Telegrammen den Zustand ganz gut protokollieren.

Siehst Du auch DUNGS-Telegramme?

[2pi]

@kleinklausi

ähnliches Problem hatte ich auch (sorry, hatte erst gedacht, dass du dich auf das das Einlesen der csv Datei beziehst).

Pfad und Dateiname der ebusd.conf sollten ok sein.

Lass den ebusd mal mit -l ALL und -f laufen, wenn das Config Verzeichnis nicht gefunden wird, dann gibt es ein Warning mit "configuration directory ... not found"

Aber bitte schau dir mal die extension für die get/set Dateien an:

# extension of command files (csv)
extension=.csv

Als extension musst du .csv angeben - mit dem Punkt. Dann findet der ebusd die csv.

Die *.cvs kann dann auch in das /et/ebusd.

Gruß
Holger

[kleinklausi]

Danke Holger!

ich hatte noch eine alte kompilierte ebusd im Verzeichnis. Erst als jetzt wirklich -l ALL nichts sinnvolles gemacht hat, hab ich es kapiert.

Gruß Moritz

[kleinklausi]

Hallo yuhu und alle,

Dass ich für die Wolf Gastherme nicht wirklich get Telegramme kenne, wisst Ihr ja. Aber dennoch wollte ich es mal probieren, um wieder auf den aktuellen Stand zu kommen.

Hier also der Log Auszug - leider funktioniert das Senden nicht:

2013-02-16 19:49:30.313 [0x80 NET] >>> client [5] get nm status_fa
2013-02-16 19:49:30.313 [0x02 NOT] search: get nm.status_fa
2013-02-16 19:49:30.313 [0x02 NOT]  found: 08FF03001 type: 3 ==> id: 0
2013-02-16 19:49:30.313 [0x10 DBG] add: id: 0 msgtype: 0 data: - clientfd: 5 ==> entries: 1
2013-02-16 19:49:30.329 [0x10 DBG] del: id: 0 msgtype: 0 data: - clientfd: 5 ==> entries: 0
2013-02-16 19:49:30.329 [0x20 EBH]  08 ff 03 00 10
2013-02-16 19:49:30.417 [0x02 NOT] send retry: 1
2013-02-16 19:49:30.549 [0x80 NET] <<< client [5]  error send ebus msg

Hat jemand eine Idee?

Danke und Gruß, Moritz

[kleinklausi]

ich schon wieder - send-retry=10 ändert leider nichts:

2013-02-16 19:57:48.617 [0x80 NET] >>> client [5] get nm status_fa
2013-02-16 19:57:48.617 [0x02 NOT] search: get nm.status_fa
2013-02-16 19:57:48.617 [0x02 NOT]  found: 08FF03001 type: 3 ==> id: 0
2013-02-16 19:57:48.617 [0x10 DBG] add: id: 0 msgtype: 0 data: - clientfd: 5 ==> entries: 1
2013-02-16 19:57:48.661 [0x10 DBG] del: id: 0 msgtype: 0 data: - clientfd: 5 ==> entries: 0
2013-02-16 19:57:48.661 [0x20 EBH]  08 ff 03 00 10
2013-02-16 19:57:48.749 [0x02 NOT] send retry: 1
2013-02-16 19:57:48.837 [0x02 NOT] send retry: 2
2013-02-16 19:57:48.973 [0x02 NOT] send retry: 3
2013-02-16 19:57:49.105 [0x02 NOT] send retry: 4
2013-02-16 19:57:49.193 [0x02 NOT] send retry: 5
2013-02-16 19:57:49.405 [0x02 NOT] send retry: 6
2013-02-16 19:57:49.493 [0x02 NOT] send retry: 7
2013-02-16 19:57:49.785 [0x02 NOT] send retry: 8
2013-02-16 19:57:49.921 [0x02 NOT] send retry: 9
2013-02-16 19:57:50.057 [0x80 NET] <<< client [5]  error send ebus msg

@JuMi: Ich glaube mich zu erinnern, dass Du am Anfang Probleme mit Deinem INterface hattest zu senden. Du hattest es eingeschickt oder so? Oder verwechsel ich das?

Gruß Moritz

[Gast]

@kleinklausi - falls der Empfänger nichts damit anfangen kann sieht das bei Vaillant genauso aus.

Was soll das für eine Befehl sein? 08 ff 03 00 10 Gibt es diesen Befehle bei dir wirklich?

Mir wäre das bei meiner Heizung zu heiß einfach so drauf loszusenden.

[kleinklausi]

Ok, danke. Dann weiss ich Bescheid.

Das ist ein Standard Befehl aus der Spezifikation, der nur den Status des Busteilnehmers abfragt.

Aber Du hast wohl Recht, ich lauf mal in den Keller und gucke ob die Heizung noch was tut

[Gast]

Neue Datenstruktur

Hallo!

Im aktuellen Commit (1480) hat sich nun die besagte Datenstruktur verändert. (sowohl Daemon intern als auch in der CSV Datei)

Falls das jemand nicht haben möchte, einfach eine Version vor 1480 besorgen.

Die Struktur (gilt für Daemon und CSV) hat einen fixen Teil (Header) und einen variablen (=Wiederholgruppe)

Header:

type        GET/SET/CYC
class       Hauptgruppe wie ci, cir2, amu...
cmd         Hauptbefehl
com         Beschreibung
s_type      Telegrammart (Broadcast, Master-Master, Master-Slave)
s_zz        Empfänger in hex
s_cmd       PB und SB in hex
s_len       Anzahl Datenbytes
s_msg       Nachrichtenkopf - bei Vaillant meist 3 Bytes (max 15)
d_elem      Anzahl der Wiederholgruppen

Wiederholgruppe:

d_sub       Unterbefehl wie pin1, temp, stat
d_pos       Position der Datenbyte nach NN vom Slave bei MS bzw. CYC
d_type      Datentype (asc, bcd, d1b, d1c, d2b, d2c, dat, tim, hex)
d_fac       Faktor falls der Wert noch angepasst werden muss
d_unit      Einheit - derzeit noch unbenutzt - sinnvoll bei der Ausgabe
d_valid     gültige Werte - derzeit noch unbenutzt - sinnvoll bei SET
d_com       Beschreibung des Unterbefehls

Beispiele:

$ telnet backup 8888
Trying 192.168.1.16...
Connected to backup.lan.
Escape character is '^]'.
get ci password
  1  0  0  0
set ci password 2 3 4 5
 ACK
get ci password
  2  3  4  5
get ci password p3   <== hier kommt keine Antwort, da p3 kein gültiger Unterbefehl ist
get ci password pin3
  4
set ci password 1 0 0 0 
 ACK
get ci password
  1  0  0  0
get amu date <== Datum
16.02.2013 
get amu time <== Uhrzeit
23:24:14
get mv vf1_temp <== Ohne Unterbefehl wird alles ausgegeben
   27.8750  0
get mv vf1_temp temp <== Unterbefehl temp
   28.5000
get mv vf1_temp stat <== Unterbefehl stat
  0
get mv vf1_temp
   29.4375  0
get mv vf1_temp
   29.6875  0
get mv brine_out
    4.4375  0
get mv brine_out temp
    4.1250
get mv low_press
   4.501  0
get mv low_press press
   4.461
gre mv low_press stat
command not found
get mv low_press stat
  0
get cir2 rt_day
 17.00
set cir2 rt_day 18.5
 ACK
get cir2 rt_day
 18.50
set cir2 rt_day 17.0
 ACK
get cir2 rt_day
 17.00
get amu comp_lock_time  <== ist als hex definiert
00 00 00 00 
get amu brine_pump_pre_time
78 00 00 00 
get ci hk16_name <== ASCII Wert
Speicher  
shutdown
Connection closed by foreign host.

Es sind mit Sicherheit noch einige Fehler im Code. Einfach testen und rückmelden.

Auf meiner todo-Liste stehen nun die zyklischen Telegramme an. Nachdem nun die Datenstruktur vorbereitet ist, sollte dass nun nicht mehr so schwierig werden.