eBus->USB->Plugin->KNX

[JuMi2006]

Kann das Dein Daemon nicht auch (fast) alles?

Ich bleibe weiterhin der Meinung, die ich auch irgendwo im IPS-Forum gepostet habe, dass das ganze Handling der Daten (CRC,data2b,bcd etc.) gleich mit in den Daemon/Connector/Manager gehört. Dieser benötigt nur ein gutes config-Konzept und die schon sind wir beim "get xyz" und "set zyx".

Ein paar gute Features sind aber schon dabei (Kontrolle des Wertes, UDP). Ich fürchte da aber im Nachgang viel Handarbeit bei der Konfiguration/Übergabe der Befehle wenn man das nicht in eine zentrale config gibt.

Grundsätzlich aber schon ein gelungenes Projekt .

Grüße

[kleinklausi]

Ist in der Tat interessant. Ich werde mit Deinem Daemon aber sicherlich glücklicher! Vielleicht kann man sich aber ja an der einen oder anderen Stelle was abschauen...

Gruß

[JuMi2006]

Beschreibe doch bitte mal die Aufgabe genauer (Beispiel-Konfig, gewünschtes Ergebnis des Parsers).

Ich versuche das mal. So könnte das CSV für ein "get" also das Auslesen von Werten aussehen, für "set" und "cycle" wäre das nahezu identisch.

HK_soll;15;B5;09;03;0D;05;00;02;1;data1b;1;Heizkreis2-Solltemperatur
kWh_jan;15;B5;09;03;0D;84;00;02;1,2;data2b;256;Energie Januar

Die Reihenfolge ist momentan:

Kurzbefehl = kWh_jan
Zieladresse = 15
Primärbefehl = B5
Sekundärbefehl = 09
Anzahl_Datenbytes = 03
Datenbyte#1 = 0D
Datenbyte#2 = 84
Datenbyte#3 = 00
Anzahl_Antwortbytes = 02
Datenposition_in_Antwort = 1,2 (Also das erste und zweite Datenbyte werden benötigt)
Codierung = data2b
Multiplikator = 256 (Der Wert nach der Codierung muss mit 256 multipliziert werden)
Kommentar = Energie Januar

Ich würde das ganze jetzt als Array speichern, eigentlich schon genau so wie es dort steht. Damit könnte der Daemon folgendes anstellen:

• Den Kurzbefehl nutzt man zur externen Kommunikation mit dem Daemon, so wäre über Telnet, UDP, whatever der Befehl "get kWh_jan" zu senden und als Antwort kommt dann der Wert zurück.
• Zieladresse, Primärbefehl, Sekundärbefehl ist eigentlich klar und jeweils ein Wert im Array
• Anzahl_Datenbytes ist da schon interessanter. Hier kann es natürlich unterschiedliche Anzahlen geben. Diesen Wert müsste der Parser gleich auswerten um den Startpunkt für Anzahl_Antwortbytes zu finden. Dazwischen befindet sich im Zweifel eine beliebige Anzahl von Bytes.
• Datenbyte#1 ... Datenbyte#n benötigen wir um den Befehl nachher zusammenzubauen. Dabei hilft uns natürlich wieder Anzahl_Datenbytes.
• Anzahl_Antwortbytes könnte man etvl. auch aus dem Bus lesen, bräuchte man aber im Zusammenhang mit der config evtl. schon vorher. Darüber muss man mal genau nachdenken wie das Handling laufen soll.
• Datenposition_in Antwort wäre eigentlich wieder ein Array und gibt an wo sich die Daten finden lassen, es kann durchaus sein dass 8 Antwortbytes gesendet werden aber man nur 2 auswerten will/kann.
• Codierung ist nichts weiter als die Angabe des Datentypes. Damit weiß der Daemon dann wie er die Rohdaten verarbeiten soll.
• Multiplikator ist letztlich auch wieder klar
• Kommentar ist optional ... wobei ich denke dass es da früher oder später noch ein paar Spalten in der config geben wird.

Grüße

[Fry]

Das Parsing einer solchen CSV-Datei ist eine Aufgabe fürs Frühstück. Wichtiger ist, was man danach damit anfängt. Soll der Daemon die Daten auch gleich interpretieren und die Kürzel ausgeben?

ME sollte der Daemon noch eine Option anbieten, mit der man Telegramme mit falscher CRC unterdrücken kann.

VG, Fry

PS. Bin übrigens mit Wolf in Kontakt. Sehr hilfsbereite Leute dort.

[kleinklausi]

PS. Bin übrigens mit Wolf in Kontakt. Sehr hilfsbereite Leute dort.

Genial! Das wäre super wenn wir die Wolf (bzw. Kromschröder) spezifischen Befehle komplett dekodieren könnten.

Gruß Moritz

[kleinklausi]

Hi,

ich hab endlich mal bei der Wolf Config die data_pos geändert - config_wolf_cycle.ods im SVN.

@Fry: in der Datei sind schon einige Telegramme, die ich bisher nicht entschlüsseln konnte.

Gruß Moritz

[kleinklausi]

Senden

Hallo Mirko und Roland,

wie sendet Ihr denn im Moment Befehle auf den Ebus? Ich komme mit serial_write nicht weiter, da egal wie oft ich es versuche, ich niemals den sync treffe.

Danke und Gruß

[Gast]

Commandline Tool

Hallo Mirko und Roland,

wie sendet Ihr denn im Moment Befehle auf den Ebus? Ich komme mit serial_write nicht weiter, da egal wie oft ich es versuche, ich niemals den sync treffe.

serial_write war der erste Wurf für den ebus Schreibzugriff.
Seit der letzten SVN Version ist bei den Funktionen kein Stein auf dem anderen geblieben.
Nun bin ich wieder auf einem Stand, welcher halbwegs das macht, was man erwartet.

Aufbauend auf diesen Funktionen, habe ich ein interkatives Sendeprogramm. (serial_write heißt bei mir nun ebus_send)

media ebus_send # ./ebus_send -h

Usage: ebus_send [OPTION]
  -a --address  set bus address. (ff)
  -r --retry    max retry getting bus. (3)
  -s --serial   use a specified serial device. (/dev/ttyUSB0)
  -t --type     message type. (3)
                1 = Broadcast, 2 = Master-Master, 3 = Master-Slave
  -w --wait     wait time for QQ compare. (~4100 usec)
  -h --help     print this message.

Das Erweitern (AA->A9 01,..) und crc Berechnung fürs Senden bzw. beim Empfangen retour wird alles abgearbeitet.

Sollten Übertragungsfehler auftreten wird (wie in der ebus Doku beschrieben) die Nachricht erneut gesendet bzw. angefordert.

Die Ausgabe sieht dann so aus (ohne Debug übersetzt)

backup src # ./ebus_send 
msg: 15 b5 09 03 0d 85 20
<<<  15 b5 09 03 0d 85 20
>>>  02 31 00

mit Debug übersetzt

msg: 15 b5 09 03 0d 85 20
skip: 0 found: 99
skip: 0 found: 99
skip: 0 found: 1
write: 0.000022
wait : 0.004279 
got bus
<<<  15 b5 09 03 0d 85 20
get_ack: tmplen: 1 tmp [0]: 15 - buf [0]: 15
get_ack: tmplen: 1 tmp [0]: b5 - buf [1]: b5
get_ack: tmplen: 1 tmp [0]: 09 - buf [2]: 09
get_ack: tmplen: 1 tmp [0]: 03 - buf [3]: 03
get_ack: tmplen: 1 tmp [0]: 0d - buf [4]: 0d
get_ack: tmplen: 1 tmp [0]: 85 - buf [5]: 85
get_ack: tmplen: 1 tmp [0]: 20 - buf [6]: 20
get_ack: tmplen: 1 tmp [0]: f8 - buf [7]: f8
get_ack: tmplen: 1 tmp [0]: 00 - buf [8]: 00
j: 8 buflen: 8 tmp[0]: 00
ret: 0
recv_data: tmplen: 1 tmp [0]: 02 - msg [0]: 02 esc: 0
recv_data: tmplen: 1 tmp [0]: 31 - msg [1]: 31 esc: 0
recv_data: tmplen: 1 tmp [0]: 00 - msg [2]: 00 esc: 0
recv_data: tmplen: 1 tmp [0]: e1 - msg [3]: e1 esc: 0
re0: 02 31 00 e1
po1: 02 31 00 e1
crc_calc: e1 crc_recv: e1
po2: 02 31 00
>>>  02 31 00

Wenn nichts dagegen spricht würde ich serial_write durch diese Version ersetzen.


Commandline Tool:

* Gibt es Vorschläge wie so ein Sende Tool heißen soll?
* Welche Funktionen muss es bietet?
* Interaktiv oder rein Befehl ausführen und beenden?
* Welche Optionen soll/muss es haben?
* Wie erfolgt die Ausgabe/Rückgabe?

Ich stelle mir das gerade so vor:

# name [OPTION] message

Rückgabe wäre dann die Antwort NN Dx (Master Slave) oder ein OK/NOK bei (Master Master)

Das könnten man dann einfach in Skripte einbauen und wieder verwenden.

[kleinklausi]

Sehr cool!

Ich werde leider erst am WE dazu kommen das zu testen. Aber danke schonmal. Dann veruche ich auch sinnvolle Antworten auf Deine Fragen...

Gruß Moritz

[JuMi2006]

Commandline Tool:

* Gibt es Vorschläge wie so ein Sende Tool heißen soll?
* Welche Funktionen bietet es?
* Interaktiv oder rein Befehl ausführen und beenden?
* Welche Optionen soll/muss es haben?
* Wie erfolgt die Ausgabe/Rückgabe?

Ich stelle mir das gerade so vor:

# name [OPTION] message

Rückgabe wäre dann die Antwort NN Dx (Master Slave) oder ein OK/NOK bei (Master Master)

Das könnten man dann einfach in Skripte einbauen und wieder verwenden.

Kurze Rückmeldung im Fieberwahn aus dem Krankenbett:
* Namen sind nur Schall und Rauch
* Was wären denn mögliche Funktionen? Senden sollte doch reichen.
* Ich wäre für ein Beenden und Mitgabe des Telegrammes als Parameter, das lässt sich leichter extern verarbeiten als interaktiv
* Optionen: Schnittstelle, zu sendendes Telegramm

Ansonsten teile ich Deine Vorstellungen.

Gruß Mirko

[fmeister]

finde auch das Parameter & beenden besser ist als interaktiv.

PS: Hat jemand den Ethernet-Ebus Koppler im Einsatz und verwendet den mit ebusd ?

lg,

Florian

[Gast]

PS: Hat jemand den Ethernet-Ebus Koppler im Einsatz und verwendet den mit ebusd ?

JuMi2006 meines wissens

[MarcusF]

PS: Hat jemand den Ethernet-Ebus Koppler im Einsatz und verwendet den mit ebusd ?

Da sitzt einfach ein RS232-nach-Ethernet-Umsetzer drin, in diesem Fall ein Gerät von WIZnet. Mittels socat kann man das zusammen mit dem ebusd verwenden, hier hab ich geschrieben wie das geht.

Marcus

[fmeister]

Da sitzt einfach ein RS232-nach-Ethernet-Umsetzer drin, in diesem Fall ein Gerät von WIZnet. Mittels socat kann man das zusammen mit dem ebusd verwenden, hier hab ich geschrieben wie das geht.

super, habs mir fast gedacht Dann werd ich mir mal so n Ding zulegen - das von eservice-online um 130 ist das günstigste mit Ethernet, oder ?

[MarcusF]

Mir sind keine anderen fertigen eBus-Interfaces sonst bekannt. Wenn man selber löten kann, wird es natürlich günstiger.

Marcus