[ebusd] Frage zu command.csv

[ebus]

Die Variante mit 2
cyc;broad;tst;tst;2;46;112e;3;-;2;a;md;1;b1d;1.0;-;-;-;b;md;2;b1d;1.0;-;-;-;c;md;3;b1d;1.0;-;-;-;

[ebus]

Und die Variante mit 3
cyc;broad;tst;tst;3;46;112e;3;-;2;a;md;1;b1d;1.0;-;-;-;b;md;2;b1d;1.0;-;-;-;c;md;3;b1d;1.0;-;-;-;

[JuMi2006]

Sieht sehr komisch aus.

Aber hier gibt es die Aussentemperatur, Datum und Wochentag:

10 fe 07 00 09 [B][COLOR="Red"]90 0a[/COLOR][/B] [B][COLOR="Blue"]00 53 02[/COLOR][/B] [B][COLOR="Magenta"]25 04[/COLOR] 04 [COLOR="Magenta"]13[/COLOR][/B] 99

90 0a = AT (hier fehlt mir grad das check tool)
00 53 02 = 02:53:00 Uhr
25 04 04 13 = 25.04.2013
04 = Wochentag (Donnerstag)

10 fe 08 01 08 c4 24 36 33 00 42 00 80 bf

Scheint auch den Specs zu entsprechen. Seite 45: http://ebus.webhop.org/twiki/pub/EBu...7_V1_6_3_D.pdf

[Gast]

Morgen,

ich vermute es liegt am 112e. Teste mal mit 112E - der upper case wird in der config verlangt.

int
eb_cmd_search_com_cyc(const unsigned char *hex, int hexlen)
{
    unsigned char hlp[(CMD_SIZE_S_MSG * 2) + 1];
    int i;

    if (hexlen > (CMD_SIZE_S_MSG * 2)) {
        log_print(L_ERR, "hexlen: %d > hlp: %d ", hexlen, (CMD_SIZE_S_MSG * 2));
        return -2;
    }

    memset(hlp, '\0', sizeof(hlp));
    for (i = 0; i < hexlen; i++)
        sprintf((char *) &hlp[2 * i], "[COLOR=Red]%02X[/COLOR]", hex[i]);

    for (i = 0; i < cyclen; i++) {
        if (memcmp(hlp, cyc[i].msg, strlen((const char *) cyc[i].msg)) == 0) {
            log_print(L_NOT, " found: %s type: %d ==> id: %d",
                cyc[i].msg, com[cyc[i].id].s_type, cyc[i].id);
                    
            return cyc[i].id;
        }
    }
    
    return -1;
}

Dein Loglevel scheint nicht zu passen.

Am besten ebusd in der Kommandozeile mit ebusd -Sf -lALL -d /dev/...

[ebus]

> ich vermute es liegt am 112e. Teste mal mit 112E

Das war es !!!!!!!

Volle Punkte. Danke.

> Aber hier gibt es die Aussentemperatur, Datum und Wochentag:

Ja, klar. 0x0700, 0x0801 und 0x0803 funktionieren schon die ganze Zeit. Aber da kommt ja auch kein Buchstabe vor. Das sind aber auch die einzigen standardisierten Nachrichten meiner Heizung.

Jetzt muss ich "nur" noch herausfinden, was diese ganzen Botschaften "0x10 0x4[56] ..." bedeuten.

Da hilft wohl nur beobachten und ausprobieren.

Danke

Roland

@Roland: Das mit 112e vs 112E solltest Du m.E. toleranter gestalten.

[Gast]

@Roland: Das mit 112e vs 112E solltest Du m.E. toleranter gestalten.

da gebe ich dir recht, ist bis jetzt noch nicht so richtig aufgefallen.

[Gast]

fix

Der svn commit 1712 sollte das Problem beheben.

svn commit -m "Improved csv files read in a way that ebus parts are not case sensitive"

[Matthi]

command.csv für mich unklar

Hallo,

ich nutze auch den EbusD seit ein paar Wochen mit den im Lieferumfang enthaltenen .csv dateien. Da ich aber recht viele werte Aktiv abfrage und diese auch zyklisch auf dem Bus gesendet werden und ich bereits ca. 40 Werte bereits 2011 mit dem EbusConnector von der Wiki-Seite gesnifft habe und weiß was sie bedeuten, würde ich diese gerne in die cyc_vaillant.csv mit einfügen. Leider bin ich nicht so der Programmierer oder Computer-Nerd und komme mit Conficg datei nicht klar, ich versuche schon ein Paar Tage da irgendwas zurecht zu biegen, bekomme es aber nicht hin.

Also zu meinem Problem, ich habe eine Vaillant VWL101/3S mit einem Außenwärmetauscher. Folgenden Code habe ich wie Folgt entschlüsselt:

03 e0 b5 21 05 00 05 07 00 e7 64 00 09 01 06 f2 ff 40 00 07 3f 47 66 00

Folgendes bleibt immer Gleich:

03 = Sender
e0 = Empfänger (Außeneinheit)
b521 = PBSB ist auch Klar
05 = Datenlänge
00 05 07 00 e7 = keine Ahnung ist immer gleich
64 = CRC
00 = das ACK vom empfänger
09 = Datenlänge der Antwort vom Empfänger

Hier die Antwort, auch die unbekannten Daten ändern sich manchmal, aber Warum weiß ich (noch) nicht:

01 = unbekannt
06 = unbekannt
f2 ff = Soletemperatur in °C (DATA2C)
40 00= Temperatur Zuluft Wärmetauscher in °C (DATA2C)
07 = unbekannt
3f = Lüfterdrehzahl in U/min (CHAR x 10)
47 = Lüfteransteuerung in % (CHAR)

Der Rest dürfte wieder Klar sein:

66 = CRC der Antwort vom Empfänger
00 = Ack vom Sender

Und nun meine Frage, wie muss die Zeile im cyc_vaillant.csv aussehen??? ich habe keinen Plan, kann mir jemand behilflich sein und das vielleicht auch mal für dummies wie mich erklären? Danke im Vorraus!

MfG Matthi

[Gast]

Hi,

im Grunde ist es nicht schwer, wenn man die Struktur verstanden hat.

Hier wäre eine Beschreibung: Ebusd - Open Automation

Jede Zeile der csv - Dateien entspricht genau einem Befehl am ebus.
Die einzelnen Felder je Zeile sind durch Strichpunkte ; getrennt.

char[  3] type     - Typ des Befehls (get, set, cyc)
char[ 20] class    - Klasse (ci, ...)
char[ 40] cmd      - Befehl (password, ...)
char[256] com      - Beschreibung des Befehls
char[  2] s_type   - ebus Nachrichten Typ (BR = Broadcast, MM = MasterMaster or MS = MasterSlave)
char[  2] s_zz     - Adresse des Slave (15, ...)
char[  4] s_cmd    - Primär und Sekundär ebus Befehl (B509, ...)
int       s_len    - Anzahl Datenbytes des Befehls
char[ 32] s_msg    - Datenbytes des Befehls (0D2C00, ...)
int       d_elem   - Anzahl der Elemente der Wiederholgruppe

Wiederholgruppe:

char[ 20] d_sub    - Unterbefehl (pin1, ...)
char[  2] d_part   - Quelle des Datenbytes (MD=Master Data, SA=Slave ACK, SD=Slave Data, MA=Master ACK)
char[ 10] d_pos    - Position der Datenbytes  (1,2 oder 3,4,5 ...)
char[  3] d_type   - Datentyp (asc, bcd, ...))
float     d_fac    - Skalierungsfaktor (1.0, 0.02, ...)
char[  6] d_unit   - Einheit des Wertes (°C, ...)
char[ 30] d_valid  - Mögliche Werte (noch nicht Implementiert) (01, 02, 03, ...)
char[256] d_com    - Beschreibung des Unterbefehl

Wenn Du den Befehl: "03 e0 b5 21 05 00 05 07 00 e7 64 00 09 01 06 f2 ff 40 00 07 3f 47 66 00" auswerten willst kannst Du das wie folgt machen

Die lila markierten Werte sind entscheidend zum erkennen des Befehles.

type   [COLOR=Magenta]cyc[/COLOR]
class  [COLOR=Magenta]vwl[/COLOR]
cmd    [COLOR=Magenta]status[/COLOR]
com    [COLOR=Magenta]-[/COLOR]
s_type [COLOR=Magenta]MS[/COLOR] --> Master Slave Telegramm
s_zz   [COLOR=Magenta]E0[/COLOR]
s_cmd  [COLOR=Magenta]B521[/COLOR]
s_len  [COLOR=Magenta]05[/COLOR]
s_msg  [COLOR=Magenta]00050700E7[/COLOR]
d_elem [COLOR=Magenta]2[/COLOR] (3 bei drei Wiederholgruppen)

Wiederholgruppe 1:

d_sub   [COLOR=Magenta]soletemp[/COLOR]
d_part  [COLOR=Magenta]SD[/COLOR] --> Slave Daten
d_pos   [COLOR=Magenta]3,4[/COLOR] --> 3 und 4 Byte nach der Anzahl der Antwortbytes NN
d_type  [COLOR=Magenta]d2c[/COLOR]
d_fac   [COLOR=Magenta]1.0[/COLOR]
d_unit  [COLOR=Magenta]°C[/COLOR]
d_valid [COLOR=Magenta]-[/COLOR]
d_com   [COLOR=Magenta]-[/COLOR]

Wiederholgruppe 2:

d_sub   [COLOR=Magenta]lufttemp[/COLOR]
d_part  [COLOR=Magenta]SD[/COLOR]
d_pos   [COLOR=Magenta]5,6[/COLOR]
d_type  [COLOR=Magenta]d2c[/COLOR]
d_fac   [COLOR=Magenta]1.0[/COLOR]
d_unit  [COLOR=Magenta]°C[/COLOR]
d_valid [COLOR=Magenta]-[/COLOR]
d_com[COLOR=Magenta]   -[/COLOR]

Wiederholgruppe 3:

....

Hoffe, das es nun leichter zu verstehen ist.

[Matthi]

kommando zurück

Hallo,

ich habe mal übernacht das Log mitlaufen lassen und mir jetzt die "03 e0 B0521" rasugefiltert.
Zum einen habe ich ca. 50% Fehler in der Kommunikation der Antwort, die von der außeneinheit (Slave) kommt, dann ist das ACK statt der "00" meist eine "80" die Antwort ist insgesamt um eine HEX Stelle zu kurz und der Master sendet am Schluss ein FehlerACK "ff" Die Daten werden daraufhin nicht erneut gesendet, sondern erst im nächsten Zyklus der zimlich genau alle 20sec. ist.

Zum anderen wird aus der gesendeten "05" manchmal auch ne "06" oder ne "02", wer weiß was das bedeuten soll. die "06" kam vorhin zumindest beim defrosten der außeneinheit die ganze zeit lang, die "02" kam nur 3 mal hintereinander heute Nacht.

03 e0 b5 21 05 00 05 07 00 e7 64 00 09 01 06 f2 ff 40 00 07 3f 47 66 00

kann ich die erkennung des Datenpacketes auch auf "e0 b521 05" beschränken? was passiert mit den Fehlern, erkennt der ebusD das selbstständig und verwirft die Daten und wartet auf das nächste mal?

MfG Matthias


EDIT:

ich habe das jetzt mal mit etwas einfacheren zum nachvollziehen probiert. die Zeile gab es auch schon in der Konfig, also ich möchte gerne meine Vorlauftemperatur auslesen, das geht auch mit dem Ebusconnector von der Wiki-Seite, aber im EbusD gehts irgendwie nicht.

Folgende Zeile wird auf dem Ebus immerwieder gesendet aber sie wird nicht erkannt und zwischengespeichert:

2014-02-03 17:07:45.199 [EBH]   10 08 b5 09 03 29 01 00 23 00 05 01 00 27 02 00 6a 00

Folgende Zeile steht in der cyc.csv:

cyc;mv;VF1_temp;Vorlauftemperatur VF1;MS;8;B509;3;290100;2;temp;sd;3,4;d2c;1;°C;-;Temperatur;stat;sd;5;bcd;1;-;-;Status;;;;;;;;;;;;;;;;

Die einstellung ist für mich auch aufgrund der beschreibung oben auch so nachvollziehbar, aber es kommt bei der Abfrage immer nur:

cyc mv VF1_temp
0.000000 0
cyc mv VF1_temp temp
0.000000
cyc mv VF1_temp state
 0

Wo liegt jetzt mein Problem ich verstehs nicht!

MfG Matthias

[Gast]

Kann ich die Erkennung des Datenpacketes auch auf "e0 b521 05" beschränken?

Der Vergleich beinhaltet die Felder: s_zz + s_cmd + s_len + s_msg
Ich habe es nie getestet s_msg mit weniger Bytes zu fülle als in s_len angegeben sind. Könnte aber funktionieren.

was passiert mit den Fehlern, erkennt der ebusD das selbstständig und verwirft die Daten und wartet auf das nächste mal?

Wenn das Telegramm erkannt wird, wird es auch gespeichert. Wenn nicht, dann nicht.

cyc;mv;VF1_temp;Vorlauftemperatur VF1;MS;[COLOR=Red]08[/COLOR];B509;3;290100;2;temp;sd;3,4;d2c;1;°C;-;Temperatur;stat;sd;5;bcd;1;-;-;Status;;;;;;;;;;;;;;;;

Die führende 0 ist notwendig und passiert meist beim Export in das csv Format.

[Matthi]

läuft....

Ah, jetzt kommt Licht ins dunkle, mit der "08" klappt das auch. das ist die Grundlage zum weiter rum probieren. Das ist vermutlich auch der Grund, warum die vaillant_get.csv nur teilweise funktioniert, habe dort statt 1, 2, und 3 in BR, MS und MM in excel geändert. Danke dafür. Wenn ich das jetzt hinbekomme, stelle ich die cyc.csv mal zur verfügung, wenn ich schon einige Daten herrausgefunden habe, kann die auch jeder andere nuten der es braucht. Es wird eh besser sein die Daten einfach Passiv mitzulesen, um so den lumpigen Ebus nicht zu überlasten!

MfG Matthias

[Matthi]

bin schon weiter, aber noch ne Frage:

Hallo yuhu,

zur Info, es funktioniert, wenn man zur erkennung des paketes nicht alles der angegeben datenlänge einträgt. meine Configzeile sieht so aus:

cyc;vwl;OutUnitData;AusseneinheitDaten;MS;E0;B521;5;00;4;sole;sd;3,4;d2c;1.00;°C;-;Temperatur;zuluft;sd;5,6;d2c;1;°C;-;Temperatur;fanspeed;sd;8;d1b;10;Upm;-;Drehzahl;fanpower;sd;9;d1b;1;%;-;Power

leider kann ich nur 4 Werte abfragen, wenn ich mehr als 41 semikolons benutze werden zwar alle Werte angezeigt, aber überall steht dann null. Ich wollte mal beobachten wann welcher Status kommt um diese auch noch zu erforschen, aber das geht leider nicht so. was passiert, wenn ich eine neue Configzeile erstelle und die Restlichen blöcke, die noch nicht abgefragt sind darin abfrage, also die stellen 1,2 und 7. Funktioniert das?

MfG Matthi

[Gast]

Leider kann ich nur 4 Werte abfragen, wenn ich mehr als 41 semikolons benutze werden zwar alle Werte angezeigt, aber überall steht dann null.

Im Sourcecode habe ich da keine Beschränkungen eingebaut. In der Theorie solltest du beliebige Elemente definieren können.

Vielleicht ist auch nur ein Buffer falsch gesetzt. Kannst Du mal die "defekte" CSV mit dem Tool csv aus dem tools Verzeichnis auslesen und anzeigen.

Was passiert, wenn ich eine neue Configzeile erstelle und die Restlichen blöcke, die noch nicht abgefragt sind darin abfrage, also die stellen 1,2 und 7. Funktioniert das?

Ja, wäre möglich, man muss aber auf die Reihenfolge aufpassen. Die Regel, welche als erstes gefunden wird, wird verwendet.

[Matthi]

Hallo, yuhu,

welche defekte .csv? meinste die, die dann die zu lange Configzeile hätte? Die CSV selbst geht ja, nur werden die werte nirgends nicht zwischengespeichert, es kommt dann bei der Abfrage über Telnet überall 0 bzw. 0.000000 raus. Die Anzahl der Werte Selbst passt schon, es währen dann 7 Stück.

MfG Matthias