eBus->USB->Plugin->KNX

[Gast]

vaillant config

.
wolf config

.
Da die ebus Befehle unterschiedlich lange sind müsste man sowas machen.

struct foo {[INDENT]int tel;                   cyc
char short[??];            [B]yyyyy[/B]
unsigned char ebus[??];    1003080008[B]xx[/B][B]xx[/B]xxxxxxxxxxxx
int ebuslen;               13
int answer_bytes;          0
char pos[??];              [B]1,2[/B]
int postype;               data2b
int multi;                 0
char long_name[??];        Kesselsollwert
char comment[256];         Sollwertübertragung des Reglers an andere Regler  [/INDENT]}

Gibt es bessere Vorschläge?

[JuMi2006]

Ich habe es mir noch mal angesehen.
Eigentlich müsste man die Datentypen definieren. Zu hoffen bleibt dass es sich nicht zu sehr (bei den Herstellern) unterscheidet.

1. Zeitraum
2. Zeitraum mit Blocknummer
3. aktuelle Zeit

1. Zeitraum wäre ein einfaches TT MM JJ - TT MM JJ
2. mit Blocknummer wird z.B. bei Ferien benutzt BN - TT MM JJ - TT MM JJ (Blocknummer wird vorangeführt)
3. Das müsste sich bei Wolf/Vaillant decken, check ich nochmal. AT AT SS MM HH TT MM WT JJ

TT=Tag; MM=Monat; JJ=Jahr; BN=BlockNummer; AT=Aussentemp.; SS=Sekunde; WT=WochenTag

EDIT:
Das mit den Spalten blick ich erst morgen wieder

[JuMi2006]

Vaillant
.

Wolf
.


Ich probiere es noch mal kurz das in Worte zu fassen.

Beim cycle kann man ja das Telegramm zur Auswertung nutzen. Das Telegramm ist bis zum NN-Byte (Anzahl der Datenbytes) ja bereits durch die config bekannt. Damit kann man es schonmal (mit 100% Sicherheit ???) leicht ausfiltern.
Weiterhin ist bekannt welche Daten ich aus dem Telegramm haben will - theoretisch reicht jetzt ein "auszählen" der übertragenen Bytes und die Auswertung dieser mit der entsprechenden Codierung.

Beim get ist es ähnlich. Wir wissen wie viele Bytes als Antwort kommen und müssen einfach nur zählen. In Perl hab ich das mit dem WireGate-Plugin schon so umgesetzt und einfach mal ein paar Daten nach dem Schema hinzugefügt - klappt.

Für get/set/cycle benötigt man eben ein unterschiedliches Handling mit den Bytes.

Was fies ist: NN Wird in BCD gesendet.

Grüße

[JuMi2006]

Ein Problem fällt mir gerade noch auf.

Gehen wir mal vom get und vom set aus so müssten wir auch dort die Anzahl der Datenbytes mit im Array auswerten um zu wissen an welcher Stelle das zu sendene Telegramm in der config aufhört und die Anzahl der Antwortbytes anfängt.

Da fehlt mir aber ad hoc auch eine Idee. Evtl. muss man das Telegramm dann doch in der config schon zusammenbauen und die zu sendenden variablen Daten mit einem Platzhalter versehen.

Grüße

[Gast]

Die Frage der Datenhaltung ist meiner Meinung nach hier entscheidend.

• Variante A: je eine eigene Struktur für set/get/cyc
• Variante B: eine eigene Struktur für cyc und eine gemeinsame für get/set
• Variante C: für alles eine gemeinsame Struktur

Jeder Befehl gibt es x Einträge. Falls unterschiedliche Datenbytes betroffen sind. zB

# cyc Speicherladung Vorlauftemperatur
cyc;spl_vlt_;feb505;4;27;1;cod;0;gibt den Typ = 27 an
cyc;spl_vlt_;feb505;4;27;2;int;0;Speicherladung 01=aktiv
cyc;spl_vlt_;feb505;4;27;3;d1c;0;Vorlauftemperatur

Variante C würde ich mal ausscheiden, da sich cyc sich grundsätzlich anders darstellt als set/get

Ein weiteres Problem sind unterschiedliche Ausprägungen bei einenm Datenbyte. zB

# set Heizkreis - Betriebsart 
set;hk2_bart;50B509;3;0E2B00;1;1;int;0;01=Ein 02=Aus 03=Auto 04=Eco 05=Absenken

Wie kann sowas abgelegt werden was gültig ist? Braucht es da eine Splate mit möglichen Einträgen?

EDIT: im Anhang mal ein mögliches Format

[Frank0207]

ebus usb adapter angepasst

hallo an alle,

bekomme jetzt recht gute telegramme vom ebus usb adapter.
Wenn ich die socat Abfrage von ttyUSB0 mache erhalte ich Daten. Beim Aufruf von ./ebusd erhalte ich jedoch keine Daten.
Gibt's da noch einen Trick?

Grüße

Frank

[Gast]

probier doch mal ./ebusd -lALL -f

[JuMi2006]

Hallo Roland, ganz schlau werde ich aus dem Format nicht.

# set Heizkreis - Betriebsart 
set;hk2_bart;50B509;3;0E2B00;1;1;int;0;01=Ein 02=Aus 03=Auto 04=Eco 05=Absenken

Bis 0E2B00 ist mir noch alles klar. Woher kommen die 2 folgenden "1" und die "0" vor dem Kommentar?
- Anzahl Datenbytes = 1 ?
- Multiplikator = 1 ?
- 0 = ???

Teilweise gibt es noch die post_value bytes. Bytes die z.B. bei der Heizkurve hinten angehangen werden ohne dass sie wirklich zum Datentyp passen. Aber die würde man im Zweifel auch noch mit unterbekommen.

Cycle macht aber noch mehr Probleme. Dort gibt es Broadcast-Nachrichten, Nachrichten die geACKed werden und klassische Master-Slave-Nachrichten mit Frage/Antwort.

Was spricht gegen Platzhalter ? Durch XX ersetzt man bei einem set einfach den Wert der durch die Encodierung ersetzt wird.
Bsp.:

set;hk2_bart;50B509030E2B00XX;int;0;01=Ein 02=Aus 03=Auto 04=Eco 05=Absenken
set;hk2_kurve;50B509050E3500XX00;data1b;0;Heizkurve

Beim get bräuchte man diesen Platzhalter nicht, gibt aber nach dem Telegramm die Anzahl der Datenbytes und die Position der interessanten Daten als Array an.

get;sys_at_;08B509030D0600;3;1,2;d2c;0;Temperatur in °C

Auf die Eingabe als Array könnte man auch verzichten wenn man unterstellt dass die Codierungsmethode weiß mit wie vielen Bytes sie arbeiten muss. Das muss aber nicht zwangsläufig immer passen.


EDIT:
Variante A -> Jedes file ein eigenes Handling.

[Gast]

Ich tendiere auch zu Variante A - Ist vielleicht manches doppelt gemoppelt, aber einfacher zum verarbeiten

Das mit den Platzhaltern bei den SET Befehlen hätte einen Charme. Für die uns bekannten Vaillant Befehle sollte das klappen.

Beim Get sind 1,2 bzw d2c redundante Angaben - daher habe das auf die Startposition reduziert.
Das einzige Problem besteht, wenn LSB und MSB vertauscht wäre. Dann könnte man durch 2,1 dies so angeben.

get;sys_at_;08B509030D0600;3;[B]1,2[/B];[B]d2c[/B];0;Temperatur in °C
get;sys_at_;08B509030D0600;3;[B]1[/B];[B]d2c[/B];0;Temperatur in °C

[JuMi2006]

So, jetzt komm ich mit meinem Gegenbeispiel, wobei es jetzt Haarspalterei wird. Im Zweifel gibt es dafür einen Datentypen -> int4.

PIN-Abfragen oder Setzen: 4 Bytes mit integer von 0-9:

get;PIN;15B509030D2C00;04;1,2,3,4;integer;Passwort Konfiguration

Ob die Angaben redundant sind ist erstmal zweitranging. Wichtig ist das große ganze zu finden.

Also bei get/set könnte ich mich mit dem gegebenen abfinden/anfreunden.

Grüße

[Gast]

warum dachte ich, es müsste so aussehen.

get;PIN;15B509030D2C00;04;1;integer;Passwort Konfiguration
get;PIN;15B509030D2C00;04;2;integer;Passwort Konfiguration
get;PIN;15B509030D2C00;04;3;integer;Passwort Konfiguration
get;PIN;15B509030D2C00;04;4;integer;Passwort Konfiguration

[JuMi2006]

Naja jetzt hast Du vier mal den gleichen short_name.
Find ich nicht gut.

Beim Sensor wirds doch vorgemacht. Da kommen 3 Bytes -> #1 & #2 bilden mit d2b den Wert ab. #3 mit den Status (0/1).

get;sys_at_temp;08B509030D0600;3;1,2;d2c;0;Temperatur in °C
get;sys_at_stat;08B509030D0600;3;3;int;0;Status

Damit kann ich jetzt mit "get sys_at_temp" die Temperatur abfragen und mit "get sys_at_stat" den Status abfragen.

Für alle Mitleser: Wir unterhalten uns hier noch über Phantasienamen

[Gast]

So könnten wirs machen.

Hat sonst niemand eine Meinung oder Ideen dazu?

[Gast]

Für das GET sieht es im Moment so aus.

struct cmd_get {
    int key; /* internal number - do we need this ? */
    char cmd[20+1]; /* sys_at */
    char sub[20+1]; /* temp, stat */
    char s_zz[10+1]; /* e.g. HK 50, 52, 53 */ 
    char s_cmd[4+1]; /* pb sb */
    int s_len; /* number of send bytes */
    char s_msg[30+1]; /* max 15 data bytes */
    int r_len; /* number of receive bytes */
    char r_pos[10+1]; /* data position at answer string */
    char r_type[3+1]; /* data type */
    float r_fac; /* facter */
    float r_min; /* min value */
    float r_max; /* max value */
    char r_val[30+1]; /* allowed values like 00,01,...*/
    char r_unit[10+1]; /* unit of data like °C,...) */
    char com[256+1]; /* just a comment */
};

Eintrag im csv File:

# get Aussentempertur
get;sys_at;temp;08;B509;3;0D0600;3;1,2;d2c;0;-30;+50;-;°C;Aussentempertur
get;sys_at;stat;08;B509;3;0D0600;3;3;int;0;0;0;00,01;-;Aussentempertur Fühler Status

Ausgabe vom Test Parser:

./csv 
[000]  sys_at.temp ==> Aussentempertur [°C]
       zz: 08 cmd: B509 len: 3 msg: 0D0600 ==> 08B5090D0600
       len: 0 pos: 1,2 type: d2c fac:  0.0 min: -30.0 max: 50.0 val: -

[001]  sys_at.stat ==> Aussentempertur Fühler Status [-]
       zz: 08 cmd: B509 len: 3 msg: 0D0600 ==> 08B5090D0600
       len: 0 pos: 3 type: int fac:  0.0 min:  0.0 max:  0.0 val: 00,01

[kleinklausi]

Hat sonst niemand eine Meinung oder Ideen dazu?

Hi,

sorry, bin ziemlich eingespannt. habe zwar mitgelesen aber mag schon was übersehen haben.

Gedanke:
Wenn wir die Master-Master Telgramme komplett zum laufen bekommen, bräuchten wir vielleicht gar kein cycle mehr?

Ansonsten:
So wie Mirko das geschrieben hat, habe ich mir das auch vorgestellt

get;sys_at_temp;08B509030D0600;3;1,2;d2c;0;Temperatur in °C
get;sys_at_stat;08B509030D0600;3;3;int;0;Status

für cycle könnte das in etwa so aussehen:

cycle;Kesseltemperatur;03fe050308;5;data1c;;Betriebsdaten des Feuerungsautomaten an den Regler
cycle;Rücklauftemperatur;03fe050308;6;char;;Betriebsdaten des Feuerungsautomaten an den Regler

Gruß