eBus->USB->Plugin->KNX

[JuMi2006]

Hilft es wenn ich mal versuche die Telegramme, die zyklisch gesendet werden, in das Tabellenformat zu bringen?

Ja bitte! Ihr habt euch da evtl. schon in eure Telegramme eingelesen, bei mir würde das wieder ewig dauern und ich bin grad so tief bei Vaillant drin...

@Oliver: Sonst häng mal so ein Textfile an.

[kleinklausi]

Ja bitte! Ihr habt euch da evtl. schon in eure Telegramme eingelesen, bei mir würde das wieder ewig dauern und ich bin grad so tief bei Vaillant drin....

Hi,

so sieht z.B. ein normales Telegramm aus, dass zyklisch gesendet wird:
- ich dachte ich könnte hier eine Tabelle einfügen. Klappt aber nicht. Also bitte siehe 1. Tab im Anhang.

Wenn ich das jetzt in Dein Format übertrage, wäre das so was:
- ich dachte ich könnte hier eine Tabelle einfügen. Klappt aber nicht. Also bitte siehe 1. Tab im Anhang.

Hast Du Dir das so vorgestellt? Ganz passen tut es nicht.

Was meinst Du?

Gruß Moritz

[JuMi2006]

Naja sieht so schlecht ja nicht aus ... bedeutet einfach dass wir noch ne "cyclic" config brauchen.
Die hatte ich gar nicht mehr auf dem Schirm da ich ja jeden Wert aktiv abfragen kann und eigentlich auch will ...
Da muss man sich jetzt noch mal Gedanken über das Handling des Daemons machen.

P.S.:
Data2c [1/16] heißt nicht dass der Wert durch 16 dividiert wird sonder gibt lediglich die Auflösung an 1/16 Grad = 0,0875
Damit wird aus Deinem Vorlauf-Soll von 1.96094 ein Vorlauf Soll von 31,375°C ... passt schon eher.

[Sandman60]

Aber anstatt mit RegEx könntest Du im Debug Output auch den Spalten Modus von Notepad++ benutzen. Cursor platzieren, Alt und Shift drücken und mit der Maus den Block markieren.

Gute Idee, hätte dann aber alle Zeitstempel eliminiert.
Nach etwas tüfteln hab ich es dann doch mit RegEx hinbekommen:
Search: "[0-9]+\-[0-9]+\-[0-9]+ [0-9]+:[0-9]+:[0-9]+.[0-9]+ \[DBG\] aa"
und dann "Delete blank lines" und alles ist gut!

[Gast]

Hallo!

Beim ebusd gibt es nun die Option -n für nosyn

Das Ganze sieht dann so aus.

backup src # [B]./ebusd -l3 -f [/B]
2013-00-03 22:25:28.131 [INF] serial device /dev/ttyUSB0 successfully opened.
2013-00-03 22:25:28.175 [INF] tcp port 8888 successfully opened.
2013-00-03 22:25:28.219 [DBG]  aa
2013-00-03 22:25:28.263 [DBG]  aa
2013-00-03 22:25:28.356 [DBG]  10 25 b5 04 01 01 d2 00 09 30 03 00 00 00 03 00 01 00 f2 00 aa
2013-00-03 22:25:28.400 [DBG]  aa
2013-00-03 22:25:28.444 [DBG]  aa
2013-00-03 22:25:28.523 [DBG]  10 25 b5 04 02 0d 00 be 00 05 50 00 34 03 30 f4 00 aa
2013-00-03 22:25:28.567 [DBG]  aa
2013-00-03 22:25:28.611 [DBG]  aa
2013-00-03 22:25:28.707 [DBG]  10 25 b5 04 01 32 e1 00 0a 00 00 00 00 00 00 e0 02 00 00 93 00 aa
2013-00-03 22:25:28.751 [DBG]  aa
2013-00-03 22:25:28.795 [DBG]  aa
2013-00-03 22:25:28.857 [DBG]  10 25 b5 04 01 31 e2 00 02 00 00 2c 00 aa
2013-00-03 22:25:28.901 [DBG]  aa
2013-00-03 22:25:28.945 [DBG]  aa
2013-00-03 22:25:28.989 [DBG]  aa

backup src # [B]./ebusd -l3 -f -n[/B]
2013-00-03 22:27:54.518 [INF] serial device /dev/ttyUSB0 successfully opened.
2013-00-03 22:27:54.519 [INF] tcp port 8888 successfully opened.
2013-00-03 22:27:54.629 [DBG]  10 08 b5 09 04 0e d1 00 00 29 00 00 00 00 aa
2013-00-03 22:27:55.162 [DBG]  10 50 b5 04 01 01 fe 00 09 12 03 00 00 00 81 00 01 00 c1 00 aa
2013-00-03 22:27:55.329 [DBG]  10 50 b5 04 02 0d 00 02 00 05 1a 00 98 01 12 7f 00 aa
2013-00-03 22:27:55.514 [DBG]  10 50 b5 04 01 32 cd 00 0a 00 24 06 03 01 01 e0 02 01 00 da 00 aa
2013-00-03 22:27:55.664 [DBG]  10 50 b5 04 01 31 ce 00 02 00 01 2d 00 aa
2013-00-03 22:27:55.827 [DBG]  10 08 b5 09 03 29 b8 01 fd 00 03 b8 01 00 70 00 aa
2013-00-03 22:27:55.991 [DBG]  10 08 b5 09 03 29 b9 01 66 00 03 b9 01 00 66 00 aa
2013-00-03 22:27:56.162 [DBG]  10 08 b5 09 03 29 0f 00 56 00 05 0f 00 81 00 00 5c 00 aa

[kleinklausi]

Naja sieht so schlecht ja nicht aus ... bedeutet einfach dass wir noch ne "cyclic" config brauchen.
Da muss man sich jetzt noch mal Gedanken über das Handling des Daemons machen.

Hallo Roland,
kannst Du Dir prinzipiell vorstellen cycle mit aufzunehmen?

Data2c [1/16] heißt nicht dass der Wert durch 16 dividiert wird sonder gibt lediglich die Auflösung an 1/16 Grad = 0,0875

Hatte mich schon gewundert. Macht deutlich mehr Sinn :-)

Gruß

[Gast]

cycle config?

Was soll das sein und was soll das machen?

EDIT:
Falls du sowas meinst wie,

...falls das Senden schief geht, daß der Befehl erneut gesendet wird...

das kann ich sicher einbauen.

Im Moment arbeite ich noch daran, die Sende Funktionen richtig aufzubauen. (nach Spez)
* Gleichzeitiger Zugriff auf den Bus zu erkennen,..
* Bei negativen ACK das Senden wiederholen,...
* Die SYN Zeichen in den Daten zu erweitern und umgekehrt <- da könnte jemand 2 Funktionen schreiben :-)
* ...

Wenn das alles rund läuft wandert es in den Daemon.

[kleinklausi]

Was soll das sein und was soll das machen?
EDIT:
Falls du sowas meinst wie,
...falls das Senden schief geht, daß der Befehl erneut gesendet wird...

Ne leider nicht. Bei mir werden zyklisch verschiedene Telegramme gesendet ohne dass ich diese Anfragen muss. Da ich definitiv nicht alle get Befehle kenne, wollte ich eigentlich einfach den existierenden Datenverkehr interpretieren.

Hoffe das ist klarer.

Gruß

[Sandman60]

Ne leider nicht. Bei mir werden zyklisch verschiedene Telegramme gesendet ohne dass ich diese Anfragen muss. Da ich definitiv nicht alle get Befehle kenne, wollte ich eigentlich einfach den existierenden Datenverkehr interpretieren.

An der gleichen Stelle stehe ich mit der Hautec auch, allerdings ist das m.E. nur bedingt eine Lösung, da Du zwar das eine oder andere siehst, aber bei weitem nicht alles und spätestens beim Set holt Dich das ganze Spiel wieder ein.
Ich versuche daher parallel vorzugehen. Einerseits eine Interpretation des "zyklischen" Verkehrs um dann leichter den "anforderungsspezifischen" Verkehr (Auswahl von Irgendwas via Display und später Einstellungen via Display) identifizieren zu können.

Die Frage ist m.E. allerdings, ob das Performancetechnisch sinnvoll ist, dass Du jedes Command <>aa interpretierst und dann irgendetwas darstellst....

Zyklische (nicht angeforderte) Datensätze habe ich massig, aber ich denke die Kunst wird sein die entsprechende Leseanforderung für solche Pakete herauszufinden. Oder kommt bei Dir zyklisch alles durch?

Cheers, Oliver

P.S.: @Roland: Danke für den "No Sync" Parameter. Werde ich gleich noch ausprobieren.

[Gast]

Ne leider nicht. Bei mir werden zyklisch verschiedene Telegramme gesendet ohne dass ich diese Anfragen muss. Da ich definitiv nicht alle get Befehle kenne, wollte ich eigentlich einfach den existierenden Datenverkehr interpretieren.

So habe ich ebenfalls angefangen. Bei Vaillant huschen da ~10-15 verschiedene Telegramme über den Bus. Davon sind vielleicht 2-3 von Interesse.
Wichtig wäre, wenn du rausfindest, ob dein Hersteller sowie Vaillant fast ausschließlich hersteller spezifische Telegramme (Vaillant: PB=b5) verwendet oder sich an den Standard hält.

Das mit dem "cycle" ist mir immer noch nicht klar!

[JuMi2006]

Hallo Roland,

mit "cyclic" war eigentlich eine config ala set/get gemeint die die zyklischen Telegramme im eBus auswertet. Jetzt wo meine "Geistertelegramme" verschwunden sind werde ich mir die auch genauer ansehen sobald get/set fertig sind.

@Oliver:
Vorgehensweise zum Telegramme sniffen:
- daemon/hterm laufen lassen und am besten vor Ort bzw. neben der Steuerung zuschauen
- an der Steuerung dann einen Wert so schnell es Dir möglich ist hin und herstellen als z.B. Solltemperatur immer wieder zwischen 20 und 21 Grad umschalten
- damit hast Du nun einen Haufen gleicher Befehle der sich leicht auswerten lässt, mit dumps ist das m.M.n. sehr mühselig

Grüße

[Gast]

Poti am eBus-Adapter

Zur Info an jene, welche mit dem Adapter von eserver-online arbeiten.

Bis gestern war es so:

* ich sah nur die Telegramme mit abschließendem SYN-Zeichen
* es gab praktisch keine SYN-Zeichen zwischen den Telegrammen
* und dachte es wäre alles richtig eingestellt
* jedoch kam alle 20 Sekunden sowas über den Bus

00 0a ff ff ff ff ff ff ff ff ff ff 0f 10 08 b5 09 03 29 0f 00 56 00 aa

Nachdem Hinweis auf die Geistertelegramme (Danke Mirko) habe ich am Poti des Adapters gedreht.

Es huschen nun verdammt viele SYN-Zeichen über den Schirm. So macht der Parameter --nosyn tatsächlich mehr Sinn.

aa
aa
03 0a b5 03 02 00 01 dc 00 0a ff ff ff ff ff ff ff ff ff ff 0f 00 aa
aa
aa

[MarcusF]

Soweit ich weiß, entspricht die Schaltung des eservice-online Adapters den veröffentlichten seriellen Adaptern mit dem 4011 als Empfangsschaltung. Das Poti muss man definitiv so einstellen, dass man die aa sieht, denn die Impulse sind auf dem Bus vorhanden. Wenn man das Poti nur so einstellt, dass man gerade so Telegramme sieht, dann ist kein korrekter Empfang gegeben. Die empfangenen Telegramme können dann auch fehlerhaft sein, weil einzelne Bits nicht erkannt werden.

Der -n Parameter beim ebusd ist sehr hilfreich, danke dafür!

Marcus

[JuMi2006]

Thema cycle-config

Hast Du Dir das so vorgestellt? Ganz passen tut es nicht.
Was meinst Du?

Gruß Moritz

Ich hab mir das mal angesehen und eine config_cycle.ods erstellt. Das Schema sollte passen und ist eigentlich selbsterklärend.

- Wenn answer_bytes 00 ist dann gibt es auf das Telegramm keine Antwort. Das kann z.B. ein Broadcast Telegramm sein oder ähnliche Telegramme, kommt durchaus vor.
- Werden in einem Telegramm mehrere Werte/Stati gesendet wird der Datensatz einfach mehrfach angelegt und die data_pos entsprechend angepasst

Die config_cycle liegt im SVN und müsste eigentlich so passen und später interpretierbar sein.

Grüße

[Anders]

datenverkehr

kann man den verkehr nicht irgendwie aufzeichnen? oder in eine datei schreiben lassen.
per putty kann ich im wiregate mir die schnittstelle ansehen, aufzeichnen wäre ja schöner.

gruß
andreas