Läuft: Heizung mit eBus-Schnittstelle

[Jojo11]

Vielen Dank. Kompiliert hatte ich schon 
Das Einzige, was mir aufgefallen ist (schon in der Vorgängerversion): Im init.d Skript steht

Code Auswählen Erweitern

DAEMON=/usr/bin/ebusd
Damit funktioniert es nicht. Bei mir wird der ebusd immer unter

Code Auswählen Erweitern

/usr/local/bin/ebusd installiert.
Ist das nur bei mir so?
Habe die Zeile halt geändert, aber an dem Sende-Problem ändert es nichts.

schöne Grüße
Jo

[Reinhart]

@Jojo11

Durch deinen Hinweis ist mir jetzt eingefallen, das ich ursprünglich das Problem mit dem Pfad /usr/bin/ebusd einmal so gelöst hatte, dass ich einfach die Binary dorthin kopiert hatte.  Das hatte jetzt für meinen ganzen Tests den Effekt, dass wenn ich händisch im Vordergrund gestartet hatte immer die Binary von John30 benutzt habe und wenn ich den Dämon starte, dann die Binary von Yuhu benutze.

D.h. in der Binary von John30 ist im Dämonbetrieb dann noch ein Pfadfehler drinnen. Ich habe das jetzt anaylsiert und musste in der init.d das Startscript nochmals anpassen (Pfade ändern), jetzt funktioniert es.

Code Auswählen Erweitern

#DAEMON=/usr/bin/ebusd
#PIDFILE=/var/run/ebusd.pid

DAEMON=/usr/local/bin/ebusd
PIDFILE=/usr/local/var/ebusd.pid


Jetzt funktioniert auch das Logfile korrekt, lediglich der Pfad /usr/local/var muss vorher für das Pidfile angelegt werden.
Ich glaube aber, das hat nichts zu tun das du nicht senden kannst, nur der Dämon sollte dann richtig laufen.

@John30
Sorry für meinen Fehler, dass ich die alte Binary von Yuhu im /usr/bin vergessen habe, somit habe ich immer 2-spurig getestet. Das erklärt jetzt auch warum letztens die Rechte nicht so passten, wie du es erwartet hättest. D.h, es ist dann leider der Pfad des Pidfiles noch nicht ganz korrekt. Warum es aber jetzt mit der Yuhu Variante plötzlich funktioniert, ist mir noch unklar. Logfile geht dort nicht.
Im Prinzip habe ich aber jetzt eine tolle Testumgebung, da ich durch Ändern des Dämonstartscriptes schnell beide Versionen testen und gegenüber stellen kann.

Fakt ist aber dann, beide Varianten (wenn man sie angepasst hat) funktionieren was die Stabilität betrifft tadellos bei mir. Ich habe jetzt den Dämon von John30 in Betrieb und schaue nochmals eine Woche.

LG
Reinhart

[john30]

Habe die Zeile halt geändert, aber an dem Sende-Problem ändert es nichts.

Das habe ich mir schon gedacht...

Bei mir wird der ebusd immer unter

Code Auswählen Erweitern

/usr/local/bin/ebusd installiert.
Ist das nur bei mir so?

Das ist durchaus so gewollt. Die Pfade lassen sich einfach mit Hilfe des "configure" Scripts justieren. Wenn Du lieber alles in /usr statt /usr/local als Basisverzeichnis haben willst, dann brauchst Du nur autogen wie folgt zu starten:

Code Auswählen Erweitern

./autogen.sh --prefix=/usr

[john30]

D.h, es ist dann leider der Pfad des Pidfiles noch nicht ganz korrekt.

Der Pfad des PID Files lässt sich seit kurzem auch mit Hilfe der Optionen an das configure Script anpassen ("localstatedir"). Ich habe gerade meinen fork aktualisiert, so dass ab sofort das PID file per default unter "/var/run/ebusd.pid" angelegt wird.

[Jojo11]

Hallo,

der ebus macht mich fertig 
Nachdem ich heute nochmal die Leitungen getrennt und neu angeschlossen habe, scheint er wieder zu laufen. Alles deutet auf einen kombinierten hard-/software-/Bedienfehler hin
Was ich mir vorstellen könnte ist evtl. eine kalte Lötstelle. Habe nochmal die Version von yuhu installiert.

schöne Grüße
Jo

[Reinhart]

@John30

Danke für die Änderung!
Ich weiß, das ich dich schon etwas nerve, aber es funktioniert noch nicht ganz.

habe folgendes durchgeführt nachdem ich die Autogen.sh aus deinem Fork angepasst habe.

Code Auswählen Erweitern

cd /home/pi/ebusd.master
sudo ./autogen.sh --prefix=/usr
sudo make
sudo make install
sudo cp /home/pi/ebusd-master/contrib/etc/init.d/ebusd.debian /etc/init.d/ebusd   (Dämonstartfile kopieren)
sudo chmod 755 /etc/init.d/ebusd         (Script Rechte setzen, wenn es via PC kopiert wurde)
sudo update-rc.d ebusd defaults           (Runlevel Script aktualisieren)


nun passt der Pfad der Binarys, sie werden jetzt brav im /usr/bin angelegt.

Code Auswählen Erweitern

pi@raspberry2 ~/ebusd-master $ cd /usr/bin
pi@raspberry2 /usr/bin $ ls -al ebus*
-rwxr-xr-x 1 root root  332633 Feb  8 09:54 ebusctl
-rwxr-xr-x 1 root root 2320207 Feb  8 09:54 ebusd
-rw------- 1 root root 2769981 Feb  7 18:44 ebusd.old
-rwxr-xr-x 1 root root  307968 Feb  8 09:54 ebusfeed


Der Dämon läuft auch korrekt und er wird aus der /usr/bin gestartet.

Code Auswählen Erweitern

pi@raspberry2 /usr/bin $ ps -aux|grep ebusd
root      9333  0.4  0.5  19872  2400 ?        Ssl  10:02   0:01 /usr/bin/ebusd -l /var/log/ebusd.log -d /dev/ttyUSB0 -p 8888


Das Pidfile läuft aber leider wieder  in /usr/local/var/. Diesmal aber mit den richtigen Rechten.

Code Auswählen Erweitern

pi@raspberry2 /usr/bin $ cd /usr/local/var/
pi@raspberry2 /usr/local/var $ ls -al
insgesamt 12
drwxr-sr-x  2 root staff 4096 Feb  8 10:02 .
drwxrwsr-x 11 root staff 4096 Feb  7 18:54 ..
-rw-r--r--  1 root staff    5 Feb  8 10:02 ebusd.pid


Ich muss daher noch den Pfad in der Dämonstartrotine anpassen.

Code Auswählen Erweitern

DAEMON=/usr/bin/ebusd
#PIDFILE=/var/run/ebusd.pid
PIDFILE=/usr/local/var/ebusd.pid

Mach jetzt ich noch was falsch oder fehlt noch was?
Wenn ich den Pfad ändere, funktioniert natürlich alles. Logfile funktioniert auch in /var/log/ebusd.log
Wegen mir brauchst du das aber nicht ändern, durch die kleine Scriptänderung kann ich gut damit leben.

Schöne Grüße
Reinhart

[Reinhart]

Hallo,

der ebus macht mich fertig 
Nachdem ich heute nochmal die Leitungen getrennt und neu angeschlossen habe, scheint er wieder zu laufen. Alles deutet auf einen kombinierten hard-/software-/Bedienfehler hin
Was ich mir vorstellen könnte ist evtl. eine kalte Lötstelle. Habe nochmal die Version von yuhu installiert.

schöne Grüße
Jo

Hallo Jojo11

Nachdem hier kein anderer User über solche Probleme klagt, nehme ich auch an das mit deiner Hardware was nicht stimmt. Du schreibst zwar, in diesem Zustand blinken die Leds weiterhin, aber es kommt ja drauf an wo diese Leds angeschlossen sind und was sie aussagen sollen (nur TxD oder auch RxD). Ich kenne die Schaltung des Gerätes nicht, daher ist es schwierig hier genaueres zu sagen, aber es wird im Prinzip ein ähnliches Verfahren wie bei der Schaltung im Wiki (vielleicht sogar mit Operationsverstärker LMxxx) sein.

Ein thermischer Fehler könnte es ja auch noch sein, dann müsste der sich auch zeigen wenn nach einem "Reset" du das Gerät mit dem Hahrföhn etwas anwärmst, sollte dann nach kurzer Zeit ausfallen. Dann weißt du zumindest wo der Fehler liegt.

LG
Reinhart

[MilanK]

yuhu- hat die ebusd repository aus GitHub gelöscht

https://github.com/yuhu-?tab=repositories

Nun gibt es noch:

https://github.com/John30

Besser eigene Kopie speichern...

Edit: Auch die Wiki is weg. Hat as jemand runtergeladen?

[Jojo11]

Hallo Jojo11

Nachdem hier kein anderer User über solche Probleme klagt, nehme ich auch an das mit deiner Hardware was nicht stimmt. Du schreibst zwar, in diesem Zustand blinken die Leds weiterhin, aber es kommt ja drauf an wo diese Leds angeschlossen sind und was sie aussagen sollen (nur TxD oder auch RxD). Ich kenne die Schaltung des Gerätes nicht, daher ist es schwierig hier genaueres zu sagen, aber es wird im Prinzip ein ähnliches Verfahren wie bei der Schaltung im Wiki (vielleicht sogar mit Operationsverstärker LMxxx) sein.

Ein thermischer Fehler könnte es ja auch noch sein, dann müsste der sich auch zeigen wenn nach einem "Reset" du das Gerät mit dem Hahrföhn etwas anwärmst, sollte dann nach kurzer Zeit ausfallen. Dann weißt du zumindest wo der Fehler liegt.

LG
Reinhart

Hallo Reinhart,

es gestaltet sich durchaus komplex, den Fehler einzugrenzen. Leider ist das auch recht zeitintensiv.

schöne Grüße
Jo

[Jojo11]

Hallo,

falls jemand ähnliche Abstürze bei disconnects hat wie ich: Die DevIo.pm wurde modifiziert und ist ab morgen verfügbar (http://forum.fhem.de/index.php/topic,31307.0.html).

schöne Grüße
Jo

[Reinhart]

yuhu- hat die ebusd repository aus GitHub gelöscht

https://github.com/yuhu-?tab=repositories

Nun gibt es noch:

https://github.com/John30

Besser eigene Kopie speichern...

Edit: Auch die Wiki is weg. Hat as jemand runtergeladen?

Ja schade, aber Yuhu wird sicher seine Gründe haben.

Hier ein Auszug aus der Wiki der Version v0.5.0-Beta.3, die Dämon Commands stehen in der README.
Alles was in der Wiki stand ist auch in diesem Thread mehrfach enthalten.

Code Auswählen Erweitern

Latest Version: v0.5.0-beta.3 (01.01.2015)
All install instructions below are for the latest version of ebusd.

Download
Pre-release version: v0.5.0-beta.3
Develpoment version: master

Compile
To compile it, please open a 'terminal' in the directory containing the unpacked source code.
Use the following commands to build ebusd. Square brackets indicate optional values.
$ ./autogen.sh [--prefix=/usr]
$ make 

Silent building is enabled by default. If you have interest in all command-line options, or you will be prompted to debug information about the compile process, then compile ebusd with the following command.
$ make V=1 

Installation
For installation just type the follwing command.
$ make install 

For small systems you can use 'install-strip' for installation. (This will remove all symbols from object files)
$ make install-strip 

Note: During installation, the directory /etc/ebusd is created. Without installation, this directory must be manually created.


LG

[john30]

Bin dabei, das Wiki wieder aufzubauen. Hab ja eh ein gutes Stück davon geschrieben...
LG John

[Prof. Dr. Peter Henning]

Na, dann werde ich in ein paar Tagen auch mal den neuen Code ausprobieren. Bei mir läuft der ebusd so stabil, dass ich das bisher vermieden habe.

LG

pah

[Reinhart]

Mir fällt seit einigen Tagen auf, dass die Logdatei von einem Tag so etwa 2,6 Mb groß ist. Die erste Hälfte der Logdatei ist mit lauter Nullen gefüllt, dann beginnt die Datei mit normalen Logdaten. Dies betrifft jetzt die aktuelle Logdatei.

in der logrotate (/etc/logrotate.d/ebusd) steht bei mir folgendes:

Code Auswählen Erweitern

/var/log/ebusd.log {
rotate 7
size 1M
copytruncate
compress
missingok
notifempty
daily
}

So wie ich das verstehe, sollten max. 7 Files komprimiert (gz) angelegt werden, und die aktuelle nicht größer als max. 1 Mb und täglich ein neues File. Das würde bedeuten, die logrotate zieht irgendwie nicht richtig. Die aktuelle müsste bei > 1Mb rotieren. Oder beißt sich da daily mit size?
Copytruncate kann es ja nicht sein, denn da würde sich der Fehler meiner Meinung ja nur im komprimierten File auswirken.

Code Auswählen Erweitern

pi@raspberry2 /var/log $ ls -al ebusd.log*
-rw-r--r-- 1 root root 2755214 Feb 10 18:54 ebusd.log
-rw-r--r-- 1 root root  123203 Feb 10 06:25 ebusd.log.1.gz
-rw-r--r-- 1 root root  267780 Feb  9 06:25 ebusd.log.2.gz
-rw-r--r-- 1 root root  138344 Feb  8 06:25 ebusd.log.3.gz
-rw-r--r-- 1 root root      99 Jan 31 16:35 ebusd.log.4.gz

Komprimierte Dateien werden täglich um 06:25 angelegt und die Stelle wo die Nullen aufhören ist genau um 06:25.

Hat das Problem noch wer, oder liegt es nur bei meiner Konfiguration. Andere Logdateien funktionieren, das Problem ist nur bei der ebusd.log

geändert: Logdatei angehängt

LG
Reinhart

[Reinhart]

habe soeben einen Thread zum Thema logrotate mit Nullen gefunden.

https://groups.google.com/forum/#!topic/comp.unix.solaris/Zc7ysjMGprQ

Das Problem müssten aber dann alle User haben.

So wie ich hier lese, müsste da der ebusd Source geändert werden.

Code Auswählen Erweitern

Not using O_APPEND in the first case and using it properly in
the working case.

LG