eBus->USB->Plugin->KNX

[aloz77]

Meine Wärmepumpe ist VWS 61/2.

Ich werde mal die Tage ein weiteres kleines Tool für die Fritzbox schreiben, das einen konfigurierbaren Datenset von der Wärmepumpe ausliest und in eine externe mySQL-Datenbank speichert.

Es soll eigentlich mit dem FTP-Zugriff auf die Fritzbox sehr einfach gehen. Auf Fritzbox 7570 wirst du für eine dauerhafte Speicherung des Tools aber sowieso auf einen USB-Stick ausweichen müssen, sonst geht das Tool beim Restart der Fritzbox verloren. Du kannst also einfach einen USB-Stick am PC befüllen, dann den Stick an der Fritzbox anschließen und dann das machen:

cd /var/media/ftp/Sony-StorageMedia-01/ebusd/
chmod 755 ebusd
./ebusd -f -l ALL -d /dev/ttyUSB0 -p 7777 -c .

Der Stick kann je nach Marke auch anders heißen als Sony-StorageMedia-01.

[JuMi2006]

Da bei mir noch ein wenig mehr dran hängt bleibts eh auf dem Pi.
Du hast ja bewiesen dass es geht ... find ich super.

Grüße

[aloz77]

Ich habe ca. 40 Werte ausgesucht und sie werden schon fleißig jede Minute in die mySQL-Datenbank geschrieben. Das Tool ist noch nicht vorzeigbar, aber es läuft.

Ab und zu wirft ebusd solche Warnungen aus. Muss ich mir deswegen Sorgen machen?

2013-04-29 21:20:14.338 [WAR] Master CRC Error
2013-04-29 21:28:46.710 [WAR] Master CRC Error
2013-04-29 21:30:27.435 [WAR] LEN Error

[Gast]

Ab und zu wirft ebusd solche Warnungen aus. Muss ich mir deswegen Sorgen machen?

Es zeigt, dass bei der Übertragung manche Bits nicht richtig ankommen.
Mögliche Ursachen:
* Das Trimming des Adapters scheint noch nicht ganz perfekt zu sein.
* Es wurde von mehr als einem Teilnehmer versucht auf den Bus zuzugreifen.

[aloz77]

@yuhu: Ich habe folgende Schwierigkeit: Wenn ich den ebusd-Prozess kille, lässt er das USB-Device irgendwie blockiert. Beim nächsten Start sagt ebusd:

2013-05-02 22:14:13.411 [ERR] ebus-bus.c: 189: eb_serial_open: Error Input/output error
2013-05-02 22:14:13.412 [ERR] can't open device: /dev/ttyUSB0

Ich finde keinen Weg, das Device wieder freizubekommen, außer die Kiste neu zu starten. Selbst das hilft nicht:

rmmod ftdi_sio
modprobe ftdi_sio

Hast du einen Tipp?

[Gast]

Mit lsof /dev/deinUSBAdapter solltest du den blockierenden Prozess finden.

Was schreibt den der ebusd in das Logfile, wenn du dem Prozess ein SIGTERM schickst? (mit LogLevel auf ALL)

[Frank0207]

Kurzer Zwischenbericht

Hallo Jumi und yuhu,

ich hab jetzt schon ca. 2 Monate den ebusd mit knxd auf nem RaspberryPi am Laufen. Ohne Probleme und sehr stabil. Da habt ihr zwei wirklich super Arbeit geleistet! Herzlichen Dank dafür!

Die Ursache für die Probleme welche ich auf'm WG mit unsauberen Protokollen hatte, konnte ich leider noch nicht herausfinden.

Besorge mir jetzt noch einen zweiten ebus Adapter für meine Solarstation auromatic 560 und versuche mal hier was selbst zu entschlüsseln Könnte sein, dass ich euch hier bezüglich der Telegramme nochmals fragen werde.

Auf jeden Fall nochmals vielen Dank für eure super Arbeit!

Grüße

Frank

[aloz77]

Das Problem mit dem blockierten USB-Device konnte ich nicht mehr reproduzieren. Dafür habe ich gleich zwei andere. :-)

1. Dafür kann ebusd wahrscheinlich nichts, aber einmal verschwand aus unbekannten Gründen bei laufendem ebusd /dev/ttyUSB0 und es war dafür plötzlich /dev/ttyUSB1 da. ebusd konnte ab da natürlich nichts mehr machen.

2. Einmal setzte ebusd für 71 Minuten aus. So sah das in der Log-Datei aus:

2013-05-04 18:40:17.787 [NET] >>> client [4] get mv circ_pump_io
2013-05-04 18:40:17.788 [NOT] search: get mv.circ_pump_io
2013-05-04 18:40:17.789 [NOT] found: 08B509030D0C00 type: 3 ==> id: 120
2013-05-04 18:40:17.789 [NOT] data: -
2013-05-04 18:40:17.789 [DBG] add: id: 120 clientfd: 4 ==> entries: 1
2013-05-04 18:40:17.831 [DBG] del: id: 120 clientfd: 4 ==> entries: 0
2013-05-04 18:40:17.831 [EBH] 08 b5 09 03 0d 0c 00
2013-05-04 19:51:52.994 [NOT] send retry: 1
2013-05-04 19:51:53.138 [EBH] 01 01
2013-05-04 19:51:53.139 [DBG] id: 120 elem: 0 p1: 1 p2: 0 p3: 0
2013-05-04 19:51:53.139 [NET] <<< client [4] 1
2013-05-04 19:51:53.139 [NET] client [5] from 127.0.0.1 connected.
2013-05-04 19:51:53.139 [NET] client [4] disconnected.

Der Client hat in dem Moment das Lesen aus dem Socket nach einem Timeout (5 Sekunden) abgebrochen. Dann hat sich der Client immer weiter bemüht, und ist immer mit einem Socket-Lesefehler (nicht Socket-Öffnungsfehler!) abgeblitzt. Ab 19:51 ging es weiter als wäre nichts gewesen. Kann es sein, dass da etwas in den Sockets hängengeblieben ist? Mein Client arbeitet im Grunde mit folgenden Zeilen:

sock = socket(AF_INET, SOCK_STREAM, 0);
tv.tv_sec = 5;
tv.tv_usec = 0;
setsockopt(sock, SOL_SOCKET, SO_RCVTIMEO, (char *)&tv,sizeof(struct timeval));
connect(sock , (struct sockaddr *)&server , sizeof(server));
send(sock, command, strlen(command), 0);
c=recv(sock, buf, sizeof(buf), 0));
buf[c]='\0';

Kann ich hier etwas besser machen?

[JuMi2006]

Zum Code kann ich nichts sagen, lediglich zum /dev. Das kann man mit einer udev-Regel sauber umschiffen, so hat der Adapter immer die "richtige" Adresse.

[aloz77]

Das Problem mit den udev-Regeln ist, dass sie (wie die meisten anderen Betriebssystem-Teile bei der Fritzbox) read-only sind. Wenn ich sie ändern will, muss ich das mit der Firmware reinflashen. Wenn sich das Problem mit dem ttyUSB0 auf ttyUSB1 Hopping wiederholt und nicht anders lösen lässt, muss ich das wohl noch machen. :-(

[Gast]

@Frank0207:

Danke für die Blumen. Warum den zweiten Adapter? Hängen deine Teilnehmer nicht auf demselben Bus?


@aloz77:

Falls die Fritzbox mit udev arbeitet wäre dort eine Regel sinnvoll.

Zu dem Socket Problem.

Du könntest dich an den laufenden ebusd mit strace -p anhängen. Vielleicht siehst Du damit wo er hängt bzw. ob er noch lebt.

Vielleicht wäre hier eine UDP Schnittstelle doch von Vorteil.

[Gast]

@aloz77: Ist der Code von Deinem Tool schon herzeigbar? Ich würde das gerne mal nachstellen.

[aloz77]

@yuhu: Ja, danke, der Code ist zeigbar. :-) Bin aber nur ein Hobby-Programmierer mit rudimentären C-Kenntnissen, die ich extra für die Fritzbox aufgefrischt habe.

Man muss auf einem mySQL-Server mit vamon-server.sql die Tabelle einrichten, anschließend mySQL-Zugangsdaten sowie einen zufälligen Serverkey in vamon-server.php konfigurieren und diese PHP-Datei auf dem Webserver ablegen. Der URL dazu und der Serverkey gehören in vamon-client.cfg rein.

Das Tool, das mit ebusd kommuniziert, läuft wie folgt an:

./vamon-client -v -c vamon-client.cfg

Ich glaube, die USB-Stabilitätsprobleme sind Fritzbox-spezifisch. ttyUSB ist wieder von 1 auf 0 gehoppt und dazu war ttyUSB0 bis zum Reboot nicht mehr lesbar. Habe dann auch die ioctl-Methode versucht, ein hängendes USB-Gerät zu resetten, ohne Erfolg. Vielleicht hilft da wirklich eine udev-Regel.

[aloz77]

Ich habe noch mal wegen ttyUSB-Hopping recherchiert. Das Problem kommt an verschiedensten Systemen vor und hat irgendwas mit EMI zu tun. Im Ergebnis trennt der USB-Host das Device kurz und verbindet es wieder. Siehe hier und hier:

https://groups.google.com/forum/?fro...ew/YmbFUvmjht0
https://groups.google.com/forum/?fro...ew/wiE_lHBPN7Y

Folge: Das ursprüngliche Device kann nicht weitergenutzt werden. Selbst eine udev-Regel mit einem konstanten Device-Namen hilft nicht dagegen, wenn die Software diesen Zustand nicht erkennt (und das USB-Device schließt und wieder öffnet).

@yuhu: Wie handelt das der ebusd? Kann ein verschwindender USB-Device zu Hängern führen?

[JuMi2006]

AW: eBus-&amp;gt;USB-&amp;gt;Plugin-&amp;gt;KNX

Du könntest ein Script bauen das jede Minute den USB scannt und anhand der Seriennummer oder Vendor ID den Symlink schreibt.
Udev für Arme .

Baustelle 2.0