eBus->USB->Plugin->KNX

[JuMi2006]

Mit Protokoll offen meinte ich eine Schnittstelle ala Ethernet oder RS232, auch da findet Google genug Beispiele. Wozu sich also mir Reverse Engeneering rumärgern wenn man es nicht muss.

@yuhu: Eigentlich ja, aber dann auf einem Microcontroller, so wäre meine Anforderung.

[tger977]

Es gibt genug Hersteller die schon fertige KNX-Module anbieten...z.B.: Viessmann mit dem Vitogate 200 oder Buderus FM446 ... da hilft aber Tante Google auch weiter.

nur dafür verlangen die Hersteller aber auch Mondpreise! über 600€ für ein Vitogate ist mir echt zuviel...

da wäre der deutlich kostengünstigere Ansatz hier über ein ebus USB Modul schon sehr interessant.

Gibt es irgendwo eine Überischt was bisher an Funktionen / Werten über das Plugin dargestellt werden kann?

[JuMi2006]

Gibt es irgendwo eine Überischt was bisher an Funktionen / Werten über das Plugin dargestellt werden kann?

Für die EcoTec: Garnichts ... vielleicht Aussentemperatur, Uhrzeit und Datum

Ich hätte heute lieber 600€ auf den Tisch gelegt.

Aufwand bisher:
120€ Vaillant vrDialog (brauchten wir zum entschlüsseln)
80€ eBus Adapter (kostet jetzt 129€ !!!!)
Das sind schonmal 200€. Dazu kommen dann ca. 100-200h Freizeit bis das so stand wie es jetzt ist - bei Roland dem Entwickler vom ebusd wird es sich ähnlich verhalten - ohne Ihn hätten wir nicht so ein geiles Stück Software .

Zurück zur konkreten Frage:
Befehle kann man sicherlich im ip-Symcon-Forum spicken. Da waren mehr User mit Gasthermen unterwegs und mann kann sich evtl. das eigenhändige Reverse Engineering der Befehle sparen und benötigt vrDialog nicht. Aber mal eben copy &paste kann man vergessen ... es sei denn man kauft ne Vaillant geotherm Wärmepumpe.

[Gast]

Gibt es irgendwo eine Überischt was bisher an Funktionen / Werten über das Plugin dargestellt werden kann?

Ich vermute du meinst damit KNXD. Dazu ist mir keine Übersicht bekannt. (Knxd - Open Automation)

Der ebusd selbst, also der Daemon welcher auf der einen Seite mit dem ebus redet und auf der anderen Seite auf einem tcp-socket lauscht, versteht die Befehle GET, SET und CYC. Genaueres findest du im WIKI (Ebusd - Open Automation)

Die Original Software scant zu Beginn den ebus um die angeschlossenen Teilnehmer zu ermitteln. Damit werden die gültigen Parameter (je Komponente) ermittelt und im vrDialog angezeigt (Tabs).

Dieser Scan ist für den ebusd nichts anderes als ein GET Befehl auf die richtige Adresse und ist Hersteller unabhängig. (3.3.5 Identifikation ( Service 07h 04h ) aus Spec_Prot_7_V1_6_3_D.pdf)

[JuMi2006]

Dann kommt aber das "Problem". Die eBus Befehle sind teilweise nicht normiert (bei Vaillant schon gar nicht) und so kocht jeder seine eigene Suppe.
Die Datenbank aus der vrDialog kann man (Roland) wohl interpretieren ... zu diesem Zeitpunkt waren die 100 Stunden aber schon überschritten .

Was ich eigentlich sagen will: Ohne Fleiß keinen Preis ... und die Schmerzgrenze dazu muss jeder für sich entscheiden.
Der eBus-Koppler Ethernet kostet 129€ der USB nach wie vor 79€ - das hab ich vorhin irgendwie durcheinander gewürfelt.

[aloz77]

@yuhu:

Ich habe jetzt folgendes Problem mit dem aktuellen ebusd (Rev. 1987) bekommen:

get mv yield_sum
-32539.000000

Irgendwo ist anscheinend ein Integer überlaufen. Hast du eine Idee, wie man das fixen kann?

[JuMi2006]

Wie ist denn der echte Wert?
Was kommt an Rohdaten an?

[Gast]

Mist, dass Problem ist mir schon länger bewusst.
Ich wollte mit dem fixen noch warten bis der Überlauf bei mir stattfindet. (Wäre viel einfacher)

2013-11-05 19:28:53.391 [NET] >>> client [5] get mv yield_sum
2013-11-05 19:28:53.526 [EBH]   ff 08 b5 09 03 [COLOR=Red]0d bc 00[/COLOR] 12 00 04 [COLOR=Blue]5b 7c[/COLOR] [COLOR=SeaGreen]00 00[/COLOR] 75 00
2013-11-05 19:28:53.527 [NET] <<< client [5] 31835.000000

Das ganze hat nichts mit der aktuelle Revision zu tun, sonder mit der Art wie wir den Wert definiert haben.

type: get
class: mv
cmd: yield_sum
comment: Energieertrag
msg type: 1=BROAD, 2=MM, 3=MS: 3
ZZ: 08
PBSB: B509
NN: 3
D1D2D3: 0DBC00
elements: 1
sub: -
part: sd
position: 1,2
datatype: d2b
factor: 256.000
unit: kWh
valid: -
comment: -

Beim Aufnehmen der Werte habe wir (JuMi und ich) öfters 4 Nutzbytes 5b 7c 00 00 gesehen, aber nur die ersten Beiden interpretieren können.
Ich vermute jedoch das alle 4 Bytes (auch die grünen) für die Daten verwendet werden. Die Frage ist nur wie.

Ich bräuchte einen Logfileauszug wie den meinen und den tatsächlichen Werte (am Display) damit ich mehr dazu sagen bzw. Änderungen vornehmen kann.

@yuhu:

Ich habe jetzt folgendes Problem mit dem aktuellen ebusd (Rev. 1987) bekommen:

get mv yield_sum
-32539.000000

Irgendwo ist anscheinend ein Integer überlaufen. Hast du eine Idee, wie man das fixen kann?

[aloz77]

Sieht man das hier, was man braucht?

2013-11-05 20:41:12.696 [NET] >>> client [5] get mv yield_sum
2013-11-05 20:41:12.697 [NOT] search: get mv.yield_sum
2013-11-05 20:41:12.697 [NOT]  found: 08B509030DBC00 type: 3 ==> id: 93
2013-11-05 20:41:12.697 [NOT]   data: -
2013-11-05 20:41:12.697 [DBG] add: id: 93 clientfd: 5 ==> entries: 1
2013-11-05 20:41:12.700 [EBH]   10 fe b5 16 08 00 03 41 20 05 11 02 13 f6
2013-11-05 20:41:12.701 [NOT]  found: FEB5160800 type: 1 ==> id: 3
2013-11-05 20:41:12.701 [DBG] id: 3 elem: 0 p1: 7 p2: 0 p3: 0
2013-11-05 20:41:12.701 [DBG] id: 3 elem: 1 p1: 5 p2: 6 p3: 8
2013-11-05 20:41:12.702 [DBG] id: 3 elem: 2 p1: 4 p2: 3 p3: 2
2013-11-05 20:41:12.702 [EBS] 05.11.2013 20:41:03
2013-11-05 20:41:12.702 [DBG] del: id: 93 clientfd: 5 ==> entries: 0
2013-11-05 20:41:12.703 [EBH]   08 b5 09 03 0d bc 00
2013-11-05 20:41:12.858 [EBH]   04 11 81 00 00
2013-11-05 20:41:12.859 [DBG] id: 93 elem: 0 p1: 1 p2: 2 p3: 0
2013-11-05 20:41:12.859 [NET] <<< client [5] -32495.000

Der Wert im Display ist 33041 kWh, also einfacher Überlauf 65536-32495=33041.

[Gast]

Sieht man das hier, was man braucht?

2013-11-05 20:41:12.696 [NET] >>> client [5] get mv yield_sum
2013-11-05 20:41:12.697 [NOT] search: get mv.yield_sum
2013-11-05 20:41:12.697 [NOT]  found: 08B509030DBC00 type: 3 ==> id: 93
2013-11-05 20:41:12.697 [NOT]   data: -
2013-11-05 20:41:12.697 [DBG] add: id: 93 clientfd: 5 ==> entries: 1
2013-11-05 20:41:12.700 [EBH]   10 fe b5 16 08 00 03 41 20 05 11 02 13 f6
2013-11-05 20:41:12.701 [NOT]  found: FEB5160800 type: 1 ==> id: 3
2013-11-05 20:41:12.701 [DBG] id: 3 elem: 0 p1: 7 p2: 0 p3: 0
2013-11-05 20:41:12.701 [DBG] id: 3 elem: 1 p1: 5 p2: 6 p3: 8
2013-11-05 20:41:12.702 [DBG] id: 3 elem: 2 p1: 4 p2: 3 p3: 2
2013-11-05 20:41:12.702 [EBS] 05.11.2013 20:41:03
2013-11-05 20:41:12.702 [DBG] del: id: 93 clientfd: 5 ==> entries: 0
2013-11-05 20:41:12.703 [EBH]   08 b5 09 03 0d bc 00
2013-11-05 20:41:12.858 [EBH]   04 [COLOR=Red]11 81[/COLOR] [COLOR=SeaGreen]00 00[/COLOR]
2013-11-05 20:41:12.859 [DBG] id: 93 elem: 0 p1: 1 p2: 2 p3: 0
2013-11-05 20:41:12.859 [NET] <<< client [5] -32495.000

Der Wert im Display ist 33041 kWh, also einfacher Überlauf 65536-32495=33041.

Ist ja krass wie das gemacht wird. Irgendwie kann ich mir die Bildung noch nicht vorstellen, da auf diese Art erst recht wieder bei 65536 Schluss ist.

Der Datentyp ist im Moment data2b was von -127,99 bis +127,99 geht und mit dem Faktor 256 von -32765,44 bis +32765,44 entspricht.

Eventuell hat Vaillant hier einen eigenen Datentyp eingeführt.

[JuMi2006]

Ich rätsel auch schon mit

Erinnerst Du dich an die Diskussion die wir irgendwo mal führten wo es zwei Wege gab den Wert zu errechnen ? Es kommt ja auch kein Nutzbyte hinzu.

Wie wollen die denn den Überlauf markieren/zählen. Wir reden ja hier von Wärmemengen die alle 3 Jahre erreicht werden.

EDIT:
Was hältst Du von der Vermutung eines separaten Telegrammes?
Ich denke da an act_env_power und act_env_power_fine.
Ich schaffe es aber die nächsten Tage nicht die vrDialog anzuwerfen.

Grüße

[Gast]

Ich denke die verwende die Bytes einfach anders. Die Vaillant DB gibt da den Hinweis auf....

EarnedEnvironmentEnergy --> ulong --> 5 (basetype) --> 32 bit unsigned long

[JuMi2006]

Und woher nehmen wir die fehlenden 16bit/2byte? Hier sind es ja nur Nullen.

[Gast]

Und woher nehmen wir die fehlenden 16bit/2byte? Hier sind es ja nur Nullen.

Umstellen auf unsinged und die grünen Bytes mit verwenden :-)
11 81 00 00

Eventuell müssen wir noch die Reihenfolge beachten/tauschen.
00 00 11 81

[aloz77]

Der Datentyp ist im Moment data2b was von -127,99 bis +127,99 geht und mit dem Faktor 256 von -32765,44 bis +32765,44 entspricht.

Denkt ihr hier nicht zu kompliziert?

11 81 00 00 = 0x00008111 = 33041