Läuft: Heizung mit eBus-Schnittstelle

[jamesgo]

Hallo,
ich wollte ich mal für die Arbeit bedanken, die in den ebusd und das Erforschen der Vaillant Konfigurationsparameter gesteckt wurde.
Für diejenigen, welche das Löten und Inbetriebnehmen des Konverters hinter sich habe ist es sicher interessant die verschiedenen Parameter einfacher zu visualisieren. Ich habe mir dazu ein Modul geschrieben, dass ich hier vorstellen möchte.

Das Modul analysiert die .csv Files, die auch der ebusd verwendet und erlaubt es alle Variablen mit "get" abzufragen.

Mit der Funktion "set" ist es mögliche Attribute zu generieren und einem Reading zuzuordnen. Die Readings werden dann in einem Interval vom ebusd abgefragt. Es ist auch möglich Werte nur jeden n-ten Zyklus abzufragen um den ebus nicht zu stark zu belasten.

Durch den Umweg über das Attribut ist es möglich die teilweise kryptischen Namen aus den .csv Files in einen eigenen Namensraum zu mappen.

Aktuell läuft das Modul in Verbindung mit meiner Vaillant Heizung (ecoTec plus, calorMatic 470/2, vr61, Wasserspeicher, zwei getrennte Heizkreise für Heizkörper und Fußbodenheizung). Ich verwenden den Adapter von eservice-online.de.

Bei Interesse kann ich das Modul auch im contrib Zweig zur Verfügung stellen und ich bin auch bereit Erweiterungen zu implementieren.

Viele Grüße
Andy

[nightstorm99]

Hallo,
ich wollte ich mal für die Arbeit bedanken, die in den ebusd und das Erforschen der Vaillant Konfigurationsparameter gesteckt wurde.
Für diejenigen, welche das Löten und Inbetriebnehmen des Konverters hinter sich habe ist es sicher interessant die verschiedenen Parameter einfacher zu visualisieren. Ich habe mir dazu ein Modul geschrieben, dass ich hier vorstellen möchte.

Das Modul analysiert die .csv Files, die auch der ebusd verwendet und erlaubt es alle Variablen mit "get" abzufragen.

Mit der Funktion "set" ist es mögliche Attribute zu generieren und einem Reading zuzuordnen. Die Readings werden dann in einem Interval vom ebusd abgefragt. Es ist auch möglich Werte nur jeden n-ten Zyklus abzufragen um den ebus nicht zu stark zu belasten.

Durch den Umweg über das Attribut ist es möglich die teilweise kryptischen Namen aus den .csv Files in einen eigenen Namensraum zu mappen.

Aktuell läuft das Modul in Verbindung mit meiner Vaillant Heizung (ecoTec plus, calorMatic 470/2, vr61, Wasserspeicher, zwei getrennte Heizkreise für Heizkörper und Fußbodenheizung). Ich verwenden den Adapter von eservice-online.de.

Bei Interesse kann ich das Modul auch im contrib Zweig zur Verfügung stellen und ich bin auch bereit Erweiterungen zu implementieren.

Viele Grüße
Andy

Hallo jamesgo,

ich wäre brennend an diesem Modul interessiert, da ich gerade überlege wie ich alle Parameter übernehmen kann.
Ansonsten muss man dieses sehr umständlich über diese CLASS Sachen bauen.

Könntest du diese bereit stellen mit einer kleinen Anleitung?

Danke im voraus
Gruß

[Jojo11]

Hallo,

ich hätte ebenfalls großes Interesse an einem alternativen Modul. ECMD läuft bei mir nicht sehr stabil.

schöne Grüße
Jo

[zentis666]

Hallo!
Dem schließe ich mich an, das Modul kommt mir gerade recht, meine bisherige Implementierung läuft zwar, ist aber noch recht rudimentär. Eine kurze Anleitung wäre top. Schonmal danke für die Mühe!

Gruss
Sven


Gesendet von iPhone mit Tapatalk

[primi]

Ich habe mir inzwischen auch ein modul geschrieben. allerdings lese ich die vom ebusd erkannten csv befehle direkt aus dem ebusd aus ( option dumpconfig). anschliessen werden diese  sortiert verarbeitet und als neue datei mit zusaetzlichen parameter fuer postproc und timer abgespeichert. somit kann man die parameter dauerhaft anpassen. ist bereits eine datei vorhanden werden neue befehle ergaenzt. anschliessen wird eine ebus.cfg datei und auch timerdefinitionen erstellt.

ich bin noch ein bisschen am testen und verfeinern. der aktuelle stand scheint aber schon zu gehen.

ich plane noch die postproc anweisungen passen zum datentyp der antwort zu generieren. werde aber den jetzigen stand auch demnaechst hier zu veroeffentlichen.

[Prof. Dr. Peter Henning]

Leute, das ist alles schön und gut. Aber m.E. muss dabei eine gewisse Abstraktion stattfinden, denn es macht wenig Sinn, jeden Befehl des Vaillant-Controllers von FHEM aus steuern zu wollen. Das ist auch nicht sicher genug.

Also noch einmal der Vorschlag, der schon lange im Raum steht:

1. Einigung auf ein "Standard"-Set von Befehlen, diese sind von einem Frontend-Device aus absetzbar
2- Verschiedene Backends, die nichtnur EBUS, sondern auch andere Heizungssysteme steuern können.

LG

pah

[primi]

gedacht war es fuer mich auch nur um erstmal alle lesebefehle mitit den antworten zu sehen. welche befehle ich leztendlich benoetige sehe ich doch erst wenn ich mir alle angeschaut habe. nicht benoetigte kann ich dann in dem generiertem dumpconfig file auskommentieren oder noch  sicherer in den csv dateien loeschen.

[amunra]

ECMD funktioniert! -> mMn ist es für Ebusd suboptimal.

@pah
könntest Du bitte 1) und 2) näher spezifizieren? Hintergrund: Ich könnte das eine oder andere in die Entwicklung einfließen lassen und einen ersten Wurf hier bereitstellen.

1. Einigung auf ein "Standard"-Set von Befehlen, diese sind von einem Frontend-Device aus absetzbar

Der Standard Set ist durch die CSV Files definiert, der lässt sich mit den Boardmitteln ermitteln "ebusctl find (-r(get)/-w(set))". - das wäre mein Ansatz.
Im Detail: Set der möglichen Abfragen über "ebusd" ermitteln, den Rest über default FHEM Mechanismen "notifies/ats"? - damit überlebt man, hoffentlich, ein paar Updates (sowohl Ebusd als auch FHEM).

2- Verschiedene Backends, die nichtnur EBUS, sondern auch andere Heizungssysteme steuern können.

Siehe Punkt 1. Ansatz ist Ebusd Tools/Mittel zu nutzen, sonst wird es problematisch? Bitte in kleinen Schritten denken - sonst wird das nichts.

Was genau meinst du mit "Backends"? Im konkretem Fall reden wir doch von Ebusd oder? Ich vermute Du meinst DevIo "telnet, ebusctl, etc."?

Vielen Dank und Grüße
Arthur

[jamesgo]

Hallo,

hier eine kurze Beschreibung zum Modul 98_GAEBUS.pm:

- 98_GAEBUS.pm nach /opt/fhem/FHEM kopieren
- nun bekommt man eine Beschreibung wenn man "help GAEBUS" in der telnet session oder im Eingabefenster des GUI eingibt
- die .csv files aus /etc/ebusd nach /opt/fhem/ebusd kopieren
- define ebus GAEBUS <servername>
- jetzt kann man alle Variablen aus dem .csv files mit "get" interaktiv abfragen (Ergebnis als popup)
- mit "set" kann man (über den Umweg eines Attributes) readings definieren, die dann zyklisch abgefragt werden

@pah: Als Abstraktionsebene sehe ich meine Implementierung Readings über den Umweg eines Attributes zu definieren. D.h. nicht alle Werte werden permanent abgefragt sondern nur diejenigen für die ein "lokaler" name für das reading definiert wurde. Werte die sich nicht permanent ändern frage ich z.B. nur alle 10 Zyklen ab (suffix ":10" beim Namen des readings). Analog möchte ich das auch zum schreiben implementieren.

Die Idee die Variablennamen statt aus den .csv files direkt vom ebusd zu bekommen finde ich sehr gut.

Grüße
Andy

[NemoN]

Vier kurze Anfänger-Fragen zur Platine (von zentis666): 

- Wo ist bei der grauen eBus Anschlussklemme der + Pol? Oder ist die Schaltung verpolungssicher?
- Muss TX/RX zum USB Modul 1:1 verbunden sein oder muss es gedreht werden? (Platine TX->USB RX / Platine RX -> USB TX)
- Ich vermute für den Vorwiderstand der "Status" LED (zwischen PIN4 und PIN7 am 4011) muss es nicht exakt 1k Ohm sein? (Hab nur 920 Ohm da
- Die Platine zieht die Versorgungspannung von den 5V die vom USB Modul kommen? (muss also angeschlossen sein?)

[Prof. Dr. Peter Henning]

Bitte mal einen Blick auf meinen Originalschaltplan im Wiki werfen. Ebus Anschluss ist verpolungssicher. Nix gedreht. Ja.

LG

pah

[Thomas03]

EBUS Stabilität

Hallo Zusammen,

die EBUS-Anbindung an eine Vaillant VSC S 196/2-C 200 über den Ebus-Koppler USB von eservice habe ich nun seit ca. 6 Monaten in Betrieb. Es läuft auch recht ordentlich.

Probleme habe ich bei der Stabilität. In unregelmäßigen Abständen (mal 7 Tage, mal 1 Tag, mal 3 Tage) sammelt mein FHEM (extra RasPi) keine Daten mehr. Wenn ich in dieser Situation den EBUS-RasPi komplett per Hand neu starte (Shutdown -r) und in FHEM den EBUS wieder verbinde, läuft es wieder.

In der Störungssituation verhält sich der EBUS-RasPi folgend:

Code Auswählen Erweitern

pi@raspberrypi / $ sudo etc/init.d/ebusd status
Ergebnis:

Code Auswählen Erweitern

[ ok ] ebusd is running.

Wenn ich nun den Befehl:

Code Auswählen Erweitern

pi@raspberrypi / $ ebusctl read OutsideTemp
absetzte, passiert ca. 3 Minuten nix und dann kommt:

Code Auswählen Erweitern

recv: Connection reset by peer

Ebusd-Version ist:

Code Auswählen Erweitern

pi@raspberrypi / $ ebusd -V
ebusd 1.1.0

auch die Überprüfung der Prozesse (aus /etc/watchdog.d/ebusd)

Code Auswählen Erweitern

ps -ef | grep ebusd.*USB0 | grep -v grep
bringt:

Code Auswählen Erweitern

root      2112     1 13 Aug13 ?        08:44:34 /usr/bin/ebusd -d /dev/ttyUSB0

Nun nun bin ich am Ende. Wie soll der Watchdog auf dem EBUS-RasPi feststellen, dass mit dem EBUSD etwas nicht funktioniert, wenn der Prozess läuft.

Hat einer von euch eine Idee, wo ich weiter suchen kann ?

Gruß
Thomas

[jamesgo]

Hallo Thomas,

schau doch mal in die /var/log/syslog. Evtl. verschwindet dein USB device (/dev/ttyUSB0) kurz.
Auch ein "fuser /dev/ttyUSB0" wäre interessant.

Grüße
Andy

[Thomas03]

Hallo Andy,

danke für deine Antwort.

fuser:

Code Auswählen Erweitern

pi@raspberrypi / $ sudo fuser /dev/ttyUSB0
/dev/ttyUSB0:         2112

/var/log/syslog.1 vom 15.08.2015 (sieht für mich vollkommen normal aus):

Code Auswählen Erweitern

Aug 15 06:25:08 raspberrypi rsyslogd: [origin software="rsyslogd" swVersion="5.8.11" x-pid="1927" x-info="http://www.rsyslog.com"] rsyslogd was HUPed
Aug 15 07:17:01 raspberrypi /USR/SBIN/CRON[2870]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Aug 15 08:17:01 raspberrypi /USR/SBIN/CRON[2883]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Aug 15 09:17:01 raspberrypi /USR/SBIN/CRON[2895]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Aug 15 10:17:01 raspberrypi /USR/SBIN/CRON[2907]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Aug 15 11:17:01 raspberrypi /USR/SBIN/CRON[2920]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Aug 15 12:17:01 raspberrypi /USR/SBIN/CRON[2930]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Aug 15 13:17:01 raspberrypi /USR/SBIN/CRON[2944]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Aug 15 14:17:01 raspberrypi /USR/SBIN/CRON[2956]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Aug 15 15:17:01 raspberrypi /USR/SBIN/CRON[2967]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Aug 15 16:17:02 raspberrypi /USR/SBIN/CRON[2978]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Aug 15 17:17:01 raspberrypi /USR/SBIN/CRON[2991]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Aug 15 18:17:01 raspberrypi /USR/SBIN/CRON[3003]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Aug 15 19:17:01 raspberrypi /USR/SBIN/CRON[3014]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Aug 15 20:17:01 raspberrypi /USR/SBIN/CRON[3028]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Aug 15 21:17:01 raspberrypi /USR/SBIN/CRON[3041]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Aug 15 22:17:02 raspberrypi /USR/SBIN/CRON[3052]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Aug 15 23:17:01 raspberrypi /USR/SBIN/CRON[3066]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Aug 16 00:17:01 raspberrypi /USR/SBIN/CRON[3078]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Aug 16 01:17:01 raspberrypi /USR/SBIN/CRON[3090]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Aug 16 02:17:01 raspberrypi /USR/SBIN/CRON[3104]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Aug 16 03:17:01 raspberrypi /USR/SBIN/CRON[3118]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Aug 16 04:17:01 raspberrypi /USR/SBIN/CRON[3286]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Aug 16 05:17:01 raspberrypi /USR/SBIN/CRON[3483]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Aug 16 06:17:01 raspberrypi /USR/SBIN/CRON[3494]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Aug 16 06:25:01 raspberrypi /USR/SBIN/CRON[3504]: (root) CMD (test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily ))


/var/log/syslog vom 16.08.2015 (die Watchdog-Einträge habe ich heute erzeugt, da ich den Watchdog ein paarmal neu gestartet habe):

Code Auswählen Erweitern

Aug 16 06:25:14 raspberrypi rsyslogd: [origin software="rsyslogd" swVersion="5.8.11" x-pid="1927" x-info="http://www.rsyslog.com"] rsyslogd was HUPed
Aug 16 06:25:15 raspberrypi rsyslogd: [origin software="rsyslogd" swVersion="5.8.11" x-pid="1927" x-info="http://www.rsyslog.com"] rsyslogd was HUPed
Aug 16 06:47:01 raspberrypi /USR/SBIN/CRON[3628]: (root) CMD (test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly ))
Aug 16 07:17:01 raspberrypi /USR/SBIN/CRON[3639]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Aug 16 08:17:01 raspberrypi /USR/SBIN/CRON[3651]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Aug 16 09:17:01 raspberrypi /USR/SBIN/CRON[3661]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Aug 16 10:17:01 raspberrypi /USR/SBIN/CRON[3671]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Aug 16 11:17:01 raspberrypi /USR/SBIN/CRON[3827]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Aug 16 11:59:41 raspberrypi watchdog[3968]: starting daemon (5.12):
Aug 16 11:59:41 raspberrypi watchdog[3968]: int=5s realtime=yes sync=no soft=no mla=24 mem=0
Aug 16 11:59:41 raspberrypi watchdog[3968]: ping: no machine to check
Aug 16 11:59:41 raspberrypi watchdog[3968]: file: no file to check
Aug 16 11:59:41 raspberrypi watchdog[3968]: pidfile: no server process to check
Aug 16 11:59:41 raspberrypi watchdog[3968]: interface: no interface to check
Aug 16 11:59:41 raspberrypi watchdog[3968]: test=none(10) repair=none(0) alive=/dev/watchdog heartbeat=none temp=none to=root no_act=no
Aug 16 11:59:41 raspberrypi watchdog[3968]: cannot open /dev/watchdog (errno = 13 = 'Permission denied')
Aug 16 11:59:51 raspberrypi watchdog[2240]: stopping daemon (5.12)
Aug 16 11:59:51 raspberrypi kernel: [226953.010231] watchdog stopped
Aug 16 11:59:56 raspberrypi watchdog[4000]: starting daemon (5.12):
Aug 16 11:59:56 raspberrypi watchdog[4000]: int=5s realtime=yes sync=no soft=no mla=24 mem=0
Aug 16 11:59:56 raspberrypi watchdog[4000]: ping: no machine to check
Aug 16 11:59:56 raspberrypi watchdog[4000]: file: no file to check
Aug 16 11:59:56 raspberrypi watchdog[4000]: pidfile: no server process to check
Aug 16 11:59:56 raspberrypi watchdog[4000]: interface: no interface to check
Aug 16 11:59:56 raspberrypi watchdog[4000]: test=none(10) repair=none(0) alive=/dev/watchdog heartbeat=none temp=none to=root no_act=no
Aug 16 11:59:56 raspberrypi watchdog[4000]: cannot set timeout 60 (errno = 22 = 'Invalid argument')
Aug 16 11:59:56 raspberrypi watchdog[4000]: hardware wartchdog identity: BCM2708
Aug 16 12:00:28 raspberrypi watchdog[4000]: stopping daemon (5.12)
Aug 16 12:00:28 raspberrypi kernel: [226989.967988] watchdog stopped
Aug 16 12:00:34 raspberrypi wd_keepalive[4049]: starting watchdog keepalive daemon (5.12):
Aug 16 12:00:34 raspberrypi wd_keepalive[4049]:  int=5 alive=/dev/watchdog realtime=yes
Aug 16 12:00:34 raspberrypi wd_keepalive[4049]: hardware wartchdog identity: BCM2708
Aug 16 12:00:34 raspberrypi wd_keepalive[4049]: unable to disable oom handling!
Aug 16 12:01:13 raspberrypi wd_keepalive[4049]: stopping watchdog keepalive daemon (5.12)
Aug 16 12:01:13 raspberrypi kernel: [227035.131621] watchdog stopped
Aug 16 12:01:19 raspberrypi watchdog[4101]: starting daemon (5.12):
Aug 16 12:01:19 raspberrypi watchdog[4101]: int=5s realtime=yes sync=no soft=no mla=24 mem=0
Aug 16 12:01:19 raspberrypi watchdog[4101]: ping: no machine to check
Aug 16 12:01:19 raspberrypi watchdog[4101]: file: no file to check
Aug 16 12:01:19 raspberrypi watchdog[4101]: pidfile: no server process to check
Aug 16 12:01:19 raspberrypi watchdog[4101]: interface: no interface to check
Aug 16 12:01:19 raspberrypi watchdog[4101]: test=none(10) repair=none(0) alive=/dev/watchdog heartbeat=none temp=none to=root no_act=no
Aug 16 12:01:19 raspberrypi watchdog[4101]: cannot set timeout 60 (errno = 22 = 'Invalid argument')
Aug 16 12:01:19 raspberrypi watchdog[4101]: hardware wartchdog identity: BCM2708
Aug 16 12:17:01 raspberrypi /USR/SBIN/CRON[4137]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Aug 16 13:17:01 raspberrypi /USR/SBIN/CRON[4191]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Aug 16 14:17:01 raspberrypi /USR/SBIN/CRON[4203]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)


Sieht für mich nicht so aus, als ob das System die USB-Verbindung verloren hätte.

Was noch komisch ist, dass die /var/log/ebusd.log aktuelle Werte enthält:

Code Auswählen Erweitern

2015-08-16 15:15:00.097 [update notice] unknown MS cmd: 1008b5110101 / 094246f00e4c580000ff
2015-08-16 15:15:02.091 [update notice] unknown MS cmd: 1008b5110102 / 05023c3c5078
2015-08-16 15:15:04.105 [update notice] update bc Mode QQ=10: standby
2015-08-16 15:15:08.107 [update notice] unknown MS cmd: 1008b5110101 / 094246f00e4c580000ff
2015-08-16 15:15:10.114 [update notice] unknown MS cmd: 1008b5040100 / 0a0310151516080715f00e
2015-08-16 15:15:10.337 [update notice] unknown BC cmd: 10feb505020400
2015-08-16 15:15:14.111 [update notice] update bc Mode QQ=10: standby
2015-08-16 15:15:18.111 [update notice] unknown MS cmd: 1008b5110101 / 094246f00e4c580000ff
2015-08-16 15:15:24.116 [update notice] update bc Mode QQ=10: standby
2015-08-16 15:15:28.118 [update notice] unknown MS cmd: 1008b5110101 / 094246f00e4c580000ff
2015-08-16 15:15:30.136 [update notice] unknown BC cmd: 10feb516080032151516080715
2015-08-16 15:15:30.387 [update notice] unknown MS cmd: 1008b512020000 / 00
2015-08-16 15:15:34.133 [update notice] update bc Mode QQ=10: standby
2015-08-16 15:15:38.133 [update notice] unknown MS cmd: 1008b5110101 / 094246f00e4c580000ff
2015-08-16 15:15:40.136 [update notice] unknown MS cmd: 1008b5040100 / 0a0341151516080715f00e
2015-08-16 15:15:40.406 [update notice] unknown MS cmd: 1008b5110102 / 05023c3c5078
2015-08-16 15:15:44.138 [update notice] update bc Mode QQ=10: standby
2015-08-16 15:15:48.149 [update notice] unknown MS cmd: 1008b5110101 / 094246f00e4c580000ff
2015-08-16 15:15:50.096 [update notice] unknown BC cmd: 10feb5160301f00e
2015-08-16 15:15:52.153 [update notice] update bc Mode QQ=10: standby
2015-08-16 15:15:58.160 [update notice] unknown MS cmd: 1008b5110101 / 094246f00e4c580000ff
2015-08-16 15:16:00.156 [update notice] unknown MS cmd: 1008b5110102 / 05023c3c5078
2015-08-16 15:16:02.160 [update notice] update bc Mode QQ=10: standby
2015-08-16 15:16:08.169 [update notice] unknown MS cmd: 1008b5110101 / 096054f00e52580400ff
2015-08-16 15:16:10.181 [update notice] unknown MS cmd: 1008b5040100 / 0a0311161516080715c00e
2015-08-16 15:16:10.401 [update notice] unknown BC cmd: 10feb505020400
2015-08-16 15:16:12.193 [update notice] update bc Mode QQ=10: standby
2015-08-16 15:16:18.203 [update notice] unknown MS cmd: 1008b5110101 / 097c62c00e68580400ff


Noch eine Idee ?

Gruß
Thomas

[jamesgo]

Hallo Thomas,

wenn das Problem nach dem 15.08 6:25 aufgetaucht ist ... dann deutet nichts auf ein USB Problem hin.

Aufgefallen ist mir nur, dass bei mir eine Version 1.2.0 (vom ebusd) läuft (als Debian pkg heruntergeladen und installiert).

Ich habe auch den Adapter von e-service. Erst seit ich einen HUB mit Stromversorgung dazwischen gehängt habe läuft der ebusd ohne Ausfälle.

Grüße
Andy