eBus->USB->Plugin->KNX

[Gast]

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

.
kurz zum Stand für Vaillant:

• Ein Master-Master Telegramm ist mir auf Vaillant bis jetzt nicht bekannt.

• Die Master-Slave Telegramme zum Lesen und Schreiben sind weitgehend für Wärmepumpen bekannt.

• Die Broadcast für Datum, Uhrzeit bzw. Aussentermpertur sind bekannt und nicht Vaillant spezifisch.

Wie das für andere Hersteller aussieht, wäre interessant.

[JuMi2006]

Ganz kurz mit fetter Grippe:

unit sollte optional werden, sonst muss man das später wiederr mühsam regexen.

Ansonsten Daumen hoch, das muss man dann ganz real testen und sehen wo die config hakt.

[kleinklausi]

.
Wie das für andere Hersteller aussieht, wäre interessant.

Meine Wolf Gastherme benutzt sehr viele Ebus Standard Master-Master Telegramme.

Danke und Gruß Moritz

[Gast]

Die Einheit finde ich wichtig und muss rein.

Ansonsten habe ich für GET das MIN/MAX/VAL wieder rausgenommen.

    /* müsste für get egal sein, da kommt ja das was in der Maschine ist */
    //~ float r_min; /* min value */
    //~ float r_max; /* max value */
    //~ char r_val[30+1]; /* allowed values like 00,01,.. */

Macht ja nur bei SET wirklich Sinn und vertraue mal darauf, daß die Bus Teilnehmer richtige Werte liefern.

Was mir noch einfällt, man könnte beim das Zyklische Abfragen Warn und Alarm Grenzen mit angeben....

Meine Wolf Gastherme benutzt sehr viele Ebus Standard Master-Master Telegramme.

Hast du das Senden von Master-Master Telegrammen mit ebus_send mal getestet? Würde mich interessieren, ob das funktioniert.

[kleinklausi]

Die Einheit finde ich wichtig und muss rein.

Der Rückgabewert wird aber ohne Einheit ausgegeben, oder?

Macht ja nur bei SET wirklich Sinn und vertraue mal darauf, daß die Bus Teilnehmer richtige Werte liefern.

Ja, macht Sinn, denke ich.

Was mir noch einfällt, man könnte beim das Zyklische Abfragen Warn und Alarm Grenzen mit angeben....

Nicht sicher, was Du damit meinst. Was willst Du damit machen?

Hast du das Senden von Master-Master Telegrammen mit ebus_send mal getestet? Würde mich interessieren, ob das funktioniert.

Vor geschätzt 3 Wochen ging es nicht, weil ich ja nicht gleichzeitig senden und auf dem Interface lauschen konnte. Ich muss aber zugeben, ich habe viele Deiner Neuerungen noch nicht ausprobeiren können.

gruß

[Gast]

@kleinklausi:
Das ist der Trick dabei. Du musst nicht gleichzeitig am Bus lauschen damit du die Antwort erhälst,
sondern sobald das MM-Telegramm am Bus ist, wartet der Sender auf die Antwort vom Empfänger (ist bei einem MS-Telegramm nicht anders).

ebus_send liefert als Rückgabe auf eine MM-Telegramm: 0 ok | 1 neg. ACK from Slave | -1 error

[kleinklausi]

@kleinklausi:
Das ist der Trick dabei. Du musst nicht gleichzeitig am Bus lauschen damit du die Antwort erhälst,
sondern sobald das MM-Telegramm am Bus ist, wartet der Sender auf die Antwort vom Empfänger (ist bei einem MS-Telegramm nicht anders).

ebus_send liefert als Rückgabe auf eine MM-Telegramm: 0 ok | 1 neg. ACK from Slave | -1 error

Ok, dann muss ich das noch mal versuchen. Danke!

[Sandman60]

.
Wie das für andere Hersteller aussieht, wäre interessant.

Sorry, bin auch grad ziemlich unter Dampf, daher leider aktuell nur mitlesen möglich. Weiter mußte ich den EBus-Adapter erst mal abklemmen, da größere Umverkabelungen parallel notwendig wurden.

Aus den bisherigen Hautec/TEM-Dumps würde ich auch sagen, dass es sich hier um eine reine Master-Slave Kommunikation handelt. Die Cycles sind zwar auch da, aber m.E. vernachlässigbar, da gewisse zyklische Statuswerte auch on Demand via Master-Slave abgefragt werden können.
Was ich gegenwärtig noch nicht mittracen konnte ist die Ausgabe von Alarmmeldungen wie Störungen und EVU-Abschaltungen.

Soweit das magere Feedback von meiner Seite.
P.S.: Seitdem ich den EBus-Converter physikalisch vom Bus getrennt habe rennt das Display wieder performant bzgl. Rückmeldungen... Da ist noch irgendwas im Argen..

[Gast]

Im Anhang mal ein parser und ein csv file für vaillant. (gcc -Wall -o csv csv.c)

So könnte sowas aussehen.

[JuMi2006]

Ja das macht Sinn. Funktioniert.

Gut finde ich die Trennung vor/nach dem NN-Byte (Anzahl der Datenbytes). Das macht zwar nur für "set" und "cycle" Sinn, ist aber der Übersicht halber auch bei "get" nicht verkehrt. So verlässt man das Schema nicht.

Nochmal auf die Einheiten. Die Einheiten machen in der Config natürlich Sinn, sollten aber bei der späteren Ausgabe optional/parametrierbar sein.

Grüße

[Gast]

Einheit in der Config ja - Ausgabe kann man sich dann wünschen

Ich hab den Aufbau noch etwas verändert.

Das Kommando setzt sich nun aus class.cmd zusammen..

• class[5] = ci
• cmd[20] = hydraulic

get;ci;hydraulic;15;B509;3;0D2900;1;1;int;0;-;Hydraulikschema
get;mw;at_temp;08;B509;3;0D0600;3;1,2;d2c;0;°C;Aussentempertur

ergibt dann

[000]    15B5090D2900       ci.hydraulic            ==> [-]     Hydraulikschema
[131]    08B5090D0600       mw.at_temp              ==> [°C]    Aussentempertur

Sollte das ganze vereinfachen und leichter lesbar machen.

[JuMi2006]

Ja ... und ... Ja !

Macht Sinn. Soll ich die configs schon mal umbauen ?

[Gast]

hab ich schon + angepassten csv parser

was noch fehlt sind sprechende namen :-)

[JuMi2006]

Wenn das noch der aktuelle Stand ist dann würde ich morgen mal mit der Namensvergabe anfangen ... kann man ja später eh nach gusto ändern.

[Gast]

Im Moment ja.

Der Daemon wird alle Dateien mit der Endung csv im Konfigurationverzeichnis (/etc/ebusd) einlesen. Ist eine andere Endung besser?