eBus->USB->Plugin->KNX

[Sandman60]

Kann jemand mir das erklären? Sieht für mich wie ein Netzwerkinterface aus. Ist aber ein Wolf-EBus-USB-Interface.

Soweit ich das verstehe meldet sich das Interface als Network device und nicht als USB-Device.
Bei dem E-Service Online USB-Device steht da "FTDI USB Serial Device converter detected", sprich das Ding kommt meldet sich als "USB Device".
Was das praktisch bzgl. dem Daemon bedeutet muß ich leider passen, ich vermute aber mal, dass aufgrund des Netzwerktreiber-Charakters der Schnittstelle hier noch andere Libs eingebunden werden müßten....
Ob sich der Aufwand lohnt im Vgl. zu einem nativen USB-E-Bus-Device bin ich mir allerdings nicht sicher...
Cheers,
Oliver

[JuMi2006]

So ich hab jetzt mal 2 configs für Vaillant ins SVN geladen -> config_get und config_set im OpenOffice Format.
Wie bereits beschrieben wäre ich dafür diese dann final bzw. zum testen in ein Semikolon getrenntes csv umzuwandeln. Dies sollte für einen Parser dann relativ einfach einzulesen sein.

@fry:
Jetzt wären die Wolf Befehle mal nicht schlecht um zu sehen wie die sich mit der Vaillant-Config vertragen.

Was fehlt sind die "short_names", also die Kurzbefehle die wir uns dazu ausdenken müssen/können.

Die Anbindung an den KNX bleibt in der config erstmal aussen vor. Bei einem gut funktionierendem Daemon können wir das locker in einem Plugin erschlagen. Auch die linknx-Fraktion sollte später damit umgehen können. Ich würde die direkte Anbindung an KNX mal als Version 1.0 ansehen.

Roland hat mit seinem serial_write einen großen Schritt geschafft. Ich war erstaunt wie flockig das über die Konsole geht.

Gruß

[Fry]

@fry:
Jetzt wären die Wolf Befehle mal nicht schlecht um zu sehen wie die sich mit der Vaillant-Config vertragen.

Da muss ich um etwas Geduld bitten. Erstmal muss ich auf euren Stand kommen, dann werde ich bei Wolf mal anfragen. Wie gesagt bin ich zuversichtlich, da etwas zu bekommen.
Viele Grüße,
Fry

[Sandman60]

@Fry:
bin mir nicht sicher, inwiefern da Wolf Protokoll-Details rausrückt, daher an dieser Stelle als Tipp der Verweis auf das EBUS-Wiki, dort findest Du schon ein paar Dinge bzgl. Wolf/Kromschroeder...
@JuMi: Danke! Werde heute Abend mal damit anfangen meine Hautec-WP mit TEM-Steuerung damit zu "befeuern" und berichte. Im Moment sehe ich eine gute Deckung bzgl. der Befehle, allerdings muß das erst die Praxis zeigen!

[Gast]

@JuMi2006:

Sind die set Befehle Master/Slave Telegramme?

zB: Heizkurve:

Master: FF 50 B5 09 05 0E 35 00 xx xx CRC
Slave: 00 00 00
Master: 00 AA

richtig so? (data2b(float(xx)*Faktor))

QQ ZZ PB SB NN DB1 DB2 DBx CRC | ACK NN CRC | ACK SYN

[Sandman60]

"Hope, we never saw this."

Kurze Frage: Was bedeutet es denn, wenn ein "Hope, we never saw this." kommt? Werde da nicht ganz aus dem Code schlau warum die meldung kommt. Ws. habe ich im Get noch irgendeinen Mist drinnen, bin mir aber nicht sicher....

[Gast]

@Sandman60:

Das ist im Teil, wo wir auf einen Antwort vom Slave warten.

Wenn ein SYN Zeichen (=AA) auftritt, dann ist der Bus für alle Master(Teilnehmer) zum Senden freigegeben.

Entweder hat der der Slave keine Antwort geschickt,
oder wir haben mit dem abgesetzten Befehl wo dazwischen gesendet,
oder.es gibt noch ein anderes Problem?

Es findet derzeit kein Kontrolle statt, ob eine Arbitrierung notwendig ist oder nicht.
Bis dato habe ich bei meiner Anlage noch kein Problem damit gehabt.

[kleinklausi]

Im tools Verzeichnis gibt es nun serial_write.

Hallo Yuhu,

muss ich den CRC vorher berechnen, oder wie funktioniert das?

Danke und Gruß

[Sandman60]

@Roland: Danke für die Erklärung. Macht in meinem Testfall Sinn, sprich es kommt keine Antwort...

[JuMi2006]

@JuMi2006:

Sind die set Befehle Master/Slave Telegramme?

zB: Heizkurve:

Master: FF 50 B5 09 05 0E 35 00 xx xx CRC
Slave: 00 00 00
Master: 00 AA

richtig so? (data2b(float(xx)*Faktor))

QQ ZZ PB SB NN DB1 DB2 DBx CRC | ACK NN CRC | ACK SYN

Wenn ich recht erinnere kommt folgendes:

FF 50 B5 09 05 0E 35 00 xx xx CRC 00 AA

Also keine drei 0x00 dazwischen...kommen die bei Dir?
Ich hab da so eine Theorie die evtl. auch zu meinen "Geistertelegrammen" passt.

Also entweder sehe nur ich die 3 0x00 nicht oder sie werden nicht gesendet.

Wenn ich jetzt mal unterstelle die die 0x00 kommen vom Slave und ich sehe sie nur nicht, dann scheint was mit dem Adapter nicht zu stimmen bzw. die Kommunikation läuft "ausserhalb" der Specs quasi an der Trimmung vorbei. Ich sehe die also einfach nicht weil sie auf einer anderen "Frequenz" kommen.

Gruß

[Gast]

@kleinklausi:

Die Eingabe muss so aussehen: QQ ZZ PB SB NN DB1 DB2 DBx

Das CRC wird vom Tool berechnet.

@JuMi2006:

Wenn ich recht erinnere kommt folgendes:

FF 50 B5 09 05 0E 35 00 xx xx CRC 00 AA

Also keine drei 0x00 dazwischen...kommen die bei Dir?
Ich hab da so eine Theorie die evtl. auch zu meinen "Geistertelegrammen" passt.

Also entweder sehe nur ich die 3 0x00 nicht oder sie werden nicht gesendet.

Wenn ich jetzt mal unterstelle die die 0x00 kommen vom Slave und ich sehe sie nur nicht, dann scheint was mit dem Adapter nicht zu stimmen bzw. die Kommunikation läuft "ausserhalb" der Specs quasi an der Trimmung vorbei. Ich sehe die also einfach nicht weil sie auf einer anderen "Frequenz" kommen.

Das schaut für mich eher so aus, als ob die set Telegramme nach dem Master-Master Aufbau arbeiten, obwohl der Empfänger ein Slave ist.

Also so dann: QQ ZZ PB SB NN DB1 DB2 DBx CRC | ACK | SYN

cu

[Fry]

Soweit ich das verstehe meldet sich das Interface als Network device und nicht als USB-Device.
...
Ob sich der Aufwand lohnt im Vgl. zu einem nativen USB-E-Bus-Device bin ich mir allerdings nicht sicher...

Ok, Plan B. Habe das USB-Netzwerk-wasauchimmer-EBus-Interface abgekoppelt und ein Ebus-RS232-Interface angeschlossen.

Welches Device ist nun das richtige? /dev/ttyUSB0 gibt es nicht, weil kein USB. Kann man das vielleicht hier sehen?

root@wiregate581:~# cat /proc/tty/drivers 
/dev/tty             /dev/tty        5       0 system:/dev/tty
/dev/console         /dev/console    5       1 system:console
/dev/ptmx            /dev/ptmx       5       2 system
/dev/vc/0            /dev/vc/0       4       0 system:vtmaster
acm                  /dev/ttyACM   166 0-31 serial
serial               /dev/ttyS       4 64-95 serial
pty_slave            /dev/pts      136 0-1048575 pty:slave
pty_master           /dev/ptm      128 0-1048575 pty:master
unknown              /dev/tty        4 1-63 console

Danke für Tipps,
VG, Fry

[JuMi2006]

Es sollte doch ein /dev/ttyS0 geben ?

[Fry]

Ja, es gibt ein /dev/ttyS0 und auch ein /dev/ttyS1.
Ein cat auf diese Devices liefert: nichts.
Ebenso der ebusd:

root@wiregate581:~/ebusd# ./ebusd -s /dev/ttyS0 -l3 -f
2013-00-02 17:52:51.212 [INF] serial device /dev/ttyS0 successfully opened.
2013-00-02 17:52:51.213 [INF] tcp port 8888 successfully opened.

Wie komme ich hier einen Schritt weiter?

VG, Fry

[JuMi2006]

Das schaut für mich eher so aus, als ob die set Telegramme nach dem Master-Master Aufbau arbeiten, obwohl der Empfänger ein Slave ist.

Also so dann: QQ ZZ PB SB NN DB1 DB2 DBx CRC | ACK | SYN

cu

Ich muss da leider wiedersprechen. Es gibt keine "Geistertelegramme" und ich hatte mit meiner Idee in Richtung Trimmung recht. Die Antworten laufen auf einer anderen Trimmung bzw. werden dann sichtbar. Das ist die positive Nachricht.

Problem: Ändere ich die Trimmung wird der Bus mit AA zugedröselt.

Beispielabfrage Bivalenzpunkt (get)

Trimmung so eingestellt dass die Telegramme sauber aufeinander folgen:

00 08 B5 09 03 0D 65 00 58 00 AA 
00 08 B5 09 03 0D 65 00 58 00 AA 
00 08 B5 09 03 0D 65 00 58 00 AA 
00 08 B5 09 03 0D 65 00 58 00 AA 
00 08 B5 09 03 0D 65 00 58 00 AA 
00 08 B5 09 03 0D 65 00 58 00 AA 
00 08 B5 09 03 0D 65 00 58 00 AA

Trimmung auf maximalen "Empfang" eingestellt:

00 08 B5 09 03 0D 65 00 58 00 02 C0 FF 10 00 AA 
AA 
AA 
AA 
00 08 B5 09 03 0D 65 00 58 00 02 C0 FF 10 00 AA 
AA 
AA 
AA 
00 08 B5 09 03 0D 65 00 58 00 02 C0 FF 10 00 AA 
AA 
AA 
AA 
00 08 B5 09 03 0D 65 00 58 00 02 C0 FF 10 00 AA 
AA 
AA 
AA 
00 08 B5 09 03 0D 65 00 58 00 02 C0 FF 10 00 AA 
10 08 B5 09 03 29 0F 00 56 00 05 0F 00 34 00 00 AB 00 AA 
AA 
AA 
00 08 B5 09 03 0D 65 00 58 00 02 C0 FF 10 00 AA

Also da geht dan richtig was ab und der Daemon hätte ordentlich zu tun.
Das sind jetzt aber "get" Abfragen aus der vrDialog. Hier wurde -4 Grad als Bivalenzpunkt abgefragt.

Beim "set" wird es dann zu einem richtigen Master-Slave-Diagramm!
Bivalenzpunkt +5 Grad

00 08 B5 09 05 0E 65 00 50 00 92 00 00 00 00 AA

bzw. bei anderer Trimmung

setzen auf +5 Grad

00 08 B5 09 05 0E 65 00 50 00 92 00 AA

Das positive ist: Ich kann mein Versprechen halten alle Werte aus der vrDialog auch im Daemon wiederzugeben .

Grüße