eBus->USB->Plugin->KNX

[JuMi2006]

Bei einer csv spart man sich das umbenennen wenn sie aus dem Tabellenprogramm purzelt. Ergo: csv.

Grüße

[Gast]

telnet

Hi!

Der ebusd kann nun via Telnet GET Befehle ausführen. Das ganze ist noch in einem frühen Stadium, funktioniert aber schon passabel.

Der Daemon braucht für das Senden zwingend die Befehle in Form von CSV Dateien (siehe doc Verzeichnis im SVN)

In der Console sieht das etwa so aus.

Client:

media ~/src/csv $ telnet backup 8888
Trying 192.168.1.16...
Connected to backup.lan.
Escape character is '^]'.
[B]get ci yield_dec_last[/B]
[B][COLOR=Red]4569.000[/COLOR][/B]
[B][COLOR=Black]get ci yield_nov_last[/COLOR][/B]
[B][COLOR=Red]3419.000[/COLOR][/B]
shutdown
Connection closed by foreign host.

Server:

backup src # valgrind --leak-check=full --show-reachable=yes ./ebusd 
==6351== Memcheck, a memory error detector
==6351== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==6351== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==6351== Command: ./ebusd
==6351== 
configuration file /etc/ebusd/ebusd.conf not found.
local configuration file ebusd.conf used.

address = FF
cfgdir = /usr/src
cfgfile = /etc/ebusd/ebusd.conf
device = /dev/ttyUSB0
extension = .csv
foreground = YES
loglevel = ALL
logfile = /var/log/ebusd.log
pidfile = /var/run/ebusd.pid
port = 8888
rawdump = NO
rawfile = /tmp/ebusd.bin
showraw = NO
settings = YES
max_retry = 3
skip_ack = 1
max_wait = 4000

2013-02-04 22:43:49.994 [0x02 NOT] /usr/src/vaillant_get.csv
2013-02-04 22:43:50.185 [0x02 NOT] /usr/src/vaillant_get.csv success
2013-02-04 22:43:50.214 [0x01 INF] /dev/ttyUSB0 opened.
2013-02-04 22:43:50.222 [0x01 INF] port 8888 opened.
2013-02-04 22:43:50.224 [0x01 INF] msg queue initialized.
2013-02-04 22:43:51.054 [0x20 EBH]  10 fe b5 05 04 27 00 1f 00 4f
2013-02-04 22:43:51.314 [0x20 EBH]  10 fe b5 05 03 4a 01 00 f4
2013-02-04 22:43:51.565 [0x20 EBH]  10 08 b5 09 03 29 b9 01 66 00 03 b9 01 00 66 00
2013-02-04 22:43:51.737 [0x20 EBH]  10 08 b5 09 03 29 0f 00 56 00 05 0f 00 76 00 00 5d 00
2013-02-04 22:43:51.901 [0x20 EBH]  10 08 b5 09 03 29 bb 00 ca 00 03 bb 00 64 b5 00
2013-02-04 22:43:52.064 [0x20 EBH]  10 08 b5 09 03 29 ba 00 51 00 03 ba 00 0a cd 00
2013-02-04 22:43:52.113 [0x80 NET] client [6] from 192.168.1.11 connected.
2013-02-04 22:43:52.227 [0x20 EBH]  10 08 b5 09 03 29 e2 01 b3 00 03 e2 01 65 a8 00
2013-02-04 22:43:53.142 [0x20 EBH]  10 53 b5 05 07 2b 00 01 00 00 00 00 5a 00 00 00 00
2013-02-04 22:43:53.419 [0x20 EBH]  10 08 b5 11 02 03 00 1e 00 0a fc 01 74 09 44 06 03 2c 00 00 9c 00
2013-02-04 22:43:53.581 [0x20 EBH]  10 08 b5 11 01 02 8a 00 05 00 00 c8 00 c8 ca 00
2013-02-04 22:43:53.748 [0x20 EBH]  10 ed b5 08 07 07 01 01 e0 03 d0 01 d1 00 00 00 00
2013-02-04 22:43:55.173 [0x20 EBH]  10 08 b5 13 03 04 cd 01 7f 00 0a cd 01 00 00 00 00 01 00 01 00 fa 00
2013-02-04 22:43:55.620 [0x20 EBH]  03 0a b5 03 02 00 01 dc 00 0a ff ff ff ff ff ff ff ff ff ff 0f 00
2013-02-04 22:43:56.192 [0x80 NET] >>> client [6] [B]get ci yield_dec_last[/B]
2013-02-04 22:43:56.197 [0x02 NOT] search: get ci.yield_dec_last
2013-02-04 22:43:56.202 [0x02 NOT]  found: 15B509030D8558 type: 3 ==> id: 42
2013-02-04 22:43:56.204 [0x10 DBG] add: id: 42 clientfd: 6 ==> entries: 1
2013-02-04 22:43:56.206 [0x10 DBG] del: id: 42 clientfd: 6 ==> entries: 0
2013-02-04 22:43:56.214 [0x20 EBH]  15 b5 09 03 0d 85 58
2013-02-04 22:43:56.331 [0x20 EBH]  02 d9 11
2013-02-04 22:43:56.381 [0x80 NET] <<< client [6] [COLOR=Red][B]4569.000[/B][/COLOR]
2013-02-04 22:43:57.161 [0x20 EBH]  10 08 b5 10 09 00 02 3a 00 00 00 00 00 02 d1 00 00 00 00
2013-02-04 22:43:57.404 [0x20 EBH]  10 08 b5 09 04 0e d1 00 00 29 00 00 00 00
2013-02-04 22:43:59.161 [0x20 EBH]  10 08 b5 09 03 29 01 00 23 00 05 01 00 f7 01 00 52 00
2013-02-04 22:43:59.342 [0x20 EBH]  10 25 b5 04 01 01 d2 00 09 30 03 00 00 00 03 00 01 00 f2 00
2013-02-04 22:43:59.510 [0x20 EBH]  10 25 b5 04 02 0d 00 be 00 05 50 00 8e 03 30 d1 00
2013-02-04 22:43:59.587 [0x80 NET] >>> client [6] [B]get ci yield_nov_last[/B]
2013-02-04 22:43:59.588 [0x02 NOT] search: get ci.yield_nov_last
2013-02-04 22:43:59.589 [0x02 NOT]  found: 15B509030D8550 type: 3 ==> id: 40
2013-02-04 22:43:59.589 [0x10 DBG] add: id: 40 clientfd: 6 ==> entries: 1
2013-02-04 22:43:59.598 [0x10 DBG] del: id: 40 clientfd: 6 ==> entries: 0
2013-02-04 22:43:59.598 [0x20 EBH]  15 b5 09 03 0d 85 50
2013-02-04 22:43:59.770 [0x20 EBH]  02 5b 0d
2013-02-04 22:43:59.770 [0x80 NET] <<< client [6] [B][COLOR=Red]3419.000[/COLOR][/B]
2013-02-04 22:43:59.876 [0x20 EBH]  10 25 b5 04 01 31 e2 00 02 00 00 2c 00
2013-02-04 22:44:01.193 [0x20 EBH]  10 08 b5 09 03 29 07 00 4f 00 05 07 00 f0 01 00 24 00
2013-02-04 22:44:01.357 [0x20 EBH]  10 08 b5 09 03 29 b8 01 fd 00 03 b8 01 00 70 00
2013-02-04 22:44:03.122 [0x20 EBH]  10 fe b5 05 04 27 00 1f 00 4f
2013-02-04 22:44:03.419 [0x80 NET] >>> client [6] shutdown
==6351== 
==6351== HEAP SUMMARY:
==6351==     in use at exit: 0 bytes in 0 blocks
==6351==   total heap usage: 306 allocs, 306 frees, 9,898,979 bytes allocated
==6351== 
==6351== All heap blocks were freed -- no leaks are possible
==6351== 
==6351== For counts of detected and suppressed errors, rerun with: -v
==6351== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2)

Die Nachrichten via Telnet zum Daemon werden in der Config gesucht. Falls vorhanden werden diese in einer Queue gepuffert bis die Verarbeitung möglich ist.

Das einzige was bereits sinnvolle Ergebnisse zurückliefert, sind die Energieertäge. Bei allen anderen Befehlen kommt zur Zeit noch nichst zurück.

Was auch gehen sollte, sind Master-Master (ACK/NAK als Antwort) bzw Broadcast Telegramm (jedoch nicht getestet)

Was fehlt also noch?

• Brauchbare Namen der Befehle in den CSV Files. (Danach wird gesucht)
• Dekodierung der Anworten (im Moment nur d2b) - Welche Datentypen gibt es?
  • (Eine Kodierung als Zahlen wäre einfacher zum verarbeiten, jedoch schlechter zum lesen)
  
  

Weiere Befehle:
quit - schließt Verbindung
shutdown - beendet Daemon

[kleinklausi]

Hi,

super cool, ich bin leider die Woche unterwegs. Ich hoffe ich finde dafür bald mal wieder Zeit!

Gruß Moritz

[Gast]

Betreff CSV - Config:

Datentypen:

• Sind die Variablen vom Typ INT im Grunde BCD?
• Sollte es einen Typ BOOL geben?
• Wie ist das Datum / Uhrzeit codiert?
• Was ist ein Block - Sonderfall?
• Welche Sonderfälle gibt es noch?

Skalierungsfaktor:

• Ein Wert von 0 ist doff - Das sollten wir auf 1 ändern, dann brauchen wir ein IF weniger.

[JuMi2006]

Gib mir mal noch ein paar Stunden, ich überarbeite gerade die get-config und fixe ein paar Datentypen.

Sind die Variablen vom Typ INT im Grunde BCD?

Kann gut sein, ich sehe mir heute Abend noch mal die Datenbank von Vaillant an, wäre bis zur "10" aber das gleiche Handling.

Sollte es einen Typ BOOL geben?

Wäre das gleiche wie integer oder?

Wie ist das Datum / Uhrzeit codiert?

AFAIR sollte das BCD sein.

Was ist ein Block - Sonderfall?

Jein ... Beispiel Ferienzeitraum. Dort gibt es zwei Ferienblöcke, die könnte man aber auch einfach getrennt abfragen und setzen.
Bleibt trotzdem ein Sonderfall. TTMMJJTTMMJJ

Welche Sonderfälle gibt es noch?

Das wird die config zeigen. Einige fallen mir da ein speziell alles was mit Datum/Uhrzeit zu tun hat. Dann gibt es noch ein paar Service-Bytes (2byte-Werte) und z.B. die PIN 0x01 0x00 0x00 0x00 -> 4 Integer.

Skalierungsfaktor:
Ein Wert von 0 ist doff - Das sollten wir auf 1 ändern, dann brauchen wir ein IF weniger.

Würde ich auch so sehen, macht den Code einfacher. Hab ich persönlich bei meinem Perl-Script schon so genutzt. Mit dem Multiplikator/Dividor muss ich auch noch ein paar Sachen testen. Vorhin sit z.B. beim "get" ein Multiplikator von 0.256 aufgetaucht ... auch ungewöhnlich, aber immerhin konstant.


Wie gesagt arbeite ich gerade ein wenig an der get-config ... daher wäre es schön wenn da bis heute Abend nichts geändert wird .
Sonst funktioniert der Telnetzugriff wie erwartet.


Grüße

[Gast]

So, das aktuelle Commit kann schon die Typen

int - alles was Ganzahlig ist
d1b - sollte ganzzahlig sein - die ausgabe ist jedoch auf float gebaut.
d1c, d2b und d2c sollte sowieso kein problem sein.

viel spass beim testen

[kobza]

Hi Sandman60,

ich versuche seit längerer Zeit Informationen über das Hautec eBUS Protokoll von Hautec zu bekommen, habe auch eine Hautec Wärmepumpe, leider ohne Erfolg.
Hast Du die Infos? Wie hast Du die Anbindung realisiert.

Gruß
Thomas

Also so krass kenne ich das auch nicht, aber auch bei meinem eBus-Interface kommt es zu einem Performanceeinbruch am Infodisplay, sobald der Adapter am Bus hängt und über USB-Strom bekommt, egal ob der USB von einem Rechner oder ähnlichem gemountet ist.
Ist m.E. ein spezielles Ebus-Feature

Update: Bei der Erstinbetriebnahme hatte ich damals den Adapter auf das zweite EBus-Interface meiner Hautec/TEM-WP gehangen und prompt ist die WP bzw. das Infodisplay (auf dem ersten EBus-Interface) nicht angelaufen (wenn USB-Strom geflossen ist). Hilft evtl. bei der Fehlereingrenzung...

[Sandman60]

Hi Thomas,

direkte Infos von Hautec habe ich nicht, Anbindung fahre ich bis dato über den USB eBus-Converter. Das klappt auch supi, bin allerdings im Moment wegen Umbauarbeiten offline und muß erst wieder den Anschluss finden.
Im Moment für mich unklar ist, warum die Rückmeldungen des Displays (TEM MB 6100) so träge ist, sobald das Interface im eBus hängt.

Mein Heizerer hat mir zwar schon 2 Namen bei Hautec genannt, allerdings habe ich auch hier mangels Zeit noch keinen Kontakt aufgenommen.

Die bisher mitgeloggten Cycles und (Rück-)Meldungen weichen zwar enorm von den Vaillants ab, m.E. schickt umgekehrt TEM/Hautec weit mehr über die eBus-Protokoll-Standard-Parameter (und damit transparenter) nach eBus-Standard als dies Vaillant tut. Anyway, ohne die Hautec-SW bleibt uns da wohl nichts anderes übrig, als eine Entschlüsselung (z.B. Commando absetzen via Display und sowohl den Anfragestring als auch das Rückmeldeergebnis dechiffrieren) und dann Aufnahme in die Liste...

Interessant wäre es noch für mich zu erfahren, welche Steuerung bei Dir verbaut ist (bei mir ist das eine TEM xxxx (hab ich grad nicht zur Hand)).

Lass uns in Kontakt bleiben, bin froh, wenn sich beim Decodieren noch jemand anschließt...

Cheers,
Oliver

[kobza]

Hi Oliver,

verstehe ich, schaue heute Abend welche Version ich habe (dir WP ist vom Jahr 2005).
ich werde am Wochenende eine kleine Arduino Schaltung für eBUS aufbauen dann schaue ich mir da Protokoll an. Wollte dann letztendlich Alles auf meine Linux Server, wo auch meine VISU läuft laufen lassen.

Gruß
Thomas

[kobza]

Hi Oliver,

habe ich eben nachgeschaut.
Controller: TEM IT 5711 MD W.

Habe gerade mit dem Arduino eBUS converter angefangen, kriege aber nur '1' aus dem eBUS... Ich schaue mal am Wochenende weiter.

Gruß
Thomas

[Sandman60]

Hi Thomas,
lass uns für die Details am besten erst mal offline/PN gehen, ich denke es ist wenig sinnvoll den Thread hier weiter zu kapern.
Cheers,
Oliver

[Gast]

Für mich ist schon interessant, was sich so alles tut.

Falls ihr Features beim Daemon oder ebus_send zum dekodieren braucht, bin ich für alles offen.

[JuMi2006]

AW: eBus->USB->Plugin->KNX

Macht ruhig hier weiter, das hilft evtl. später mal. Auf die 3 Seiten kommt es hier auch nicht mehr an



Baustelle 2.0

[Sandman60]

OK, wenn's Euch nicht stört. Vom eigentlichen Threadersteller hab ich lange auch nix mehr gehört, daher ok. Wen es stört, dann bitte Feedback.

Also bei mir ist die Steuerung ein 6001, die aber in der WP verbaut ist. Außen dann das Display MB 6100. So wie ich das sehe, ist die 5711 nicht in der WP sondern außen mit Display, richtig?
Sollte aber von der Sache bzgl. Protokollierung keinen Unterschied machen, außer das Dein Display vielleicht nicht langsamer wird . Das mit den 1ern kommt mir merkwürdig vor, kenne aber auch den Arduino eBUS converter nicht. Beim fertigen eBus Converter mußten wir hier alle erst mal am Poti feinjustieren, bis die Flut von AAs und halbwegs brauchbare Pakete aufgetaucht sind. Hier hat sich der simple Einsatz von HTERM bewährt oder der Daemon im Dumpmode von Roland.

Habe für die 5711 aktuell keine Schaltskizze gefunden. Hast Du evtl. auch 2 Businterfaces? Bei mir hat nur ein Interface ein Ergebnis gebracht (das mit dem Display dran), bei Anschluss an das zweite Interface kam die Steuereinheit erst gar nicht auf die Füsse...
Soweit mal als Einstieg.
Cheers,
Oliver

[Gast]

Es sind nun einige Fixes im SVN, damit sollte das Dekodieren von int, d1b, d1c, d2b und d2c ganz gut funktionieren.

Der Daemon hat auch eine neue Option (send_retry) zur Anzahl der Sendeversuche bekommen (nur in der Konfigurationsdatei und 2 = default]
Es sollte damit auch die letzten Fehler vom Senden ausgebügelt werden.

Falls die Sendungswiederholung notwendig ist, sieht das beim Daemon so aus.

2013-02-06 23:46:55.380 [0x80 NET] >>> client [6] get mv undercool_temp
2013-02-06 23:46:55.380 [0x02 NOT] search: get mv.undercool_temp
2013-02-06 23:46:55.380 [0x02 NOT]  found: 08B509030D8E00 type: 3 ==> id: 93
2013-02-06 23:46:55.566 [0x02 NOT] send retry: 1
2013-02-06 23:46:55.720 [0x80 NET] <<< client [6]     0.0000

Demnächst kommen SET und CYC Telegramme bzw. exotische Datentypen zum Implementieren an die Reihe


Gibt es Feature Wünsche?