Läuft: Heizung mit eBus-Schnittstelle

[john30]

@Jojo11:
Das sieht so aus, als könnte gar nichts mehr an das Interface geschrieben werden.
Welche Rechte hat denn /dev/ttyUSB0?
Läuft auf dem RPi irgendwas rechenintensives? Was sagt denn uptime so?

[Jojo11]

@Jojo11:
Das sieht so aus, als könnte gar nichts mehr an das Interface geschrieben werden.
Welche Rechte hat denn /dev/ttyUSB0?
Läuft auf dem RPi irgendwas rechenintensives? Was sagt denn uptime so?

Hallo,

Rechte sind

Code Auswählen Erweitern


$ ls -lt /dev/ttyUSB0
crw-rw---T 1 root dialout 188, 0 Feb  7 10:14 /dev/ttyUSB0


Uptime:

Code Auswählen Erweitern


$ uptime
10:18:48 up  3:10,  2 users,  load average: 0.00, 0.01, 0.05


Die beiden user sind dann wohl pi und su. Sonst läuft eigentlich nichts.

schöne Grüße
Jo

[john30]

@Jojo11:
Ich fürchte, dann hat Dein Interface die Fähigkeit zu senden verloren. Zumindest sieht es sehr danach aus, wenn Du sonst an keiner Komponente (weder HW noch SW) irgendwas verändert hast.
Hast Du ein Selbstbau-Interface oder etwas fertiges im Einsatz?

[Jojo11]

  Äh, nein, kein Selbstbau. Ist das Interface von eservice.
Wie kann denn sowas passieren? Ich werde jetzt nochmal alles stromlos setzen und dann nochmal testen.

schöne Grüße
Jo

[Reinhart]

@John30

ich teste ja schon über eine Woche deine Binary und wollte dir daher berichten das sie ohne irgendwelcher Probleme bei mir läuft.
Es wird im Augenblick zyklisch alle 6 Minuten der eBus mit je 15 Datenpunkten abgefragt, ohne Ausfälle, ohne Fehlermeldungen!
Ich mache sogar automatische Heizkurven Einstellungen mehrmals am Tag und FHEM setzt somit direkt Befehle an den eBus ab.
Sie Bild im Anhang, am 4.2 habe ich bewusst die Steuerung abgeschaltet um die Auswirkung an der Wichtung zu verfolgen, ansonsten alles fehlerfrei!

Ich kann daher nur sagen, der ebusd ist bei mir sehr stabil, prima Arbeit!

Therme: Vaillant Ecotec plus VCW AT 246/3-5
Busregler: VRC 430
eBus Interface: Eigenbau (Schaltung nach pah)

Code Auswählen Erweitern

pi@raspberry2 ~ $ uptime
09:23:05 up 6 days, 15:08,  1 user,  load average: 0,01, 0,04, 0,05
pi@raspberry2 ~ $


vor 6 Tagen war ein reboot weil ich den Raspi mit dem eBus-Interface in eine Gehäuse verbaut habe.

Schöne Grüße
Reinhart

[Jojo11]

Puuuuhhh. Läuft wieder 
Allerdings musste ich dazu nicht nur den Strom entfernen (das hatte ich vorher schon einmal gemacht), sondern auch die ebus-Leitung abkoppeln.
Verstehen tue ich das nicht, aber ich bin ja auch kein Elektroniker 
Danke John!

schöne Grüße
Jo

[john30]

@Reinhart:
Das freut mich, Danke fürs Feedback!

@Jojo11:
freut mich ebenfalls, dass es wieder läuft. Wieso allerings ein kurzes Abhängen der Leitungen Abhilfe schafft, kann ich mir auch nicht erklären (und das trotz Nebenstudium Elektrotechnik ). Murphy's law schlägt wieder zu

[Jojo11]

Hmm, nachdem es jetzt ein paar Minuten gelaufen ist, hakt es wieder. Neue Theorie: Liegt nicht am Adapter sondern an der Software. Evtl. kann es sein, dass der RPi irgendwann neu gestartet ist und beim Neustart der ebusd "anders" gestartet wurde. Kann ich sehen, ob evtl. zwei/mehrere ebusd parallel laufen? Das hier gibt mir zu denken:

Code Auswählen Erweitern


$ /etc/init.d/ebusd status
[ ok ] ebusd is running.
$ /etc/init.d/ebusd stop
[ ok ] Stopping ebusd: ebusd.
$ /etc/init.d/ebusd status
[ ok ] ebusd is running.
$ sudo /etc/init.d/ebusd status
[ ok ] ebusd is running.
$ sudo /etc/init.d/ebusd stop
[ ok ] Stopping ebusd: ebusd.
$ sudo /etc/init.d/ebusd status
[ ok ] ebusd is running.


schöne Grüße
Jo

[john30]

Kann ich sehen, ob evtl. zwei/mehrere ebusd parallel laufen?

Folgendes Kommando:

Code Auswählen Erweitern

ps ax|grep ebusd

sollte ungefähr sowas liefern:

Code Auswählen Erweitern


12345 pts/0    Sl+    0:19 ./git/ebusd/src/ebusd/ebusd --pollinterval 30 -c config -f --loglevel notice --logareas all -d /dev/ttyUSB0
23456 pts/1    S+     0:00 grep --color=auto ebusd


Die Zeile mit dem "grep" ist der eben gestartete Aufruf. Der Rest sollte nur eine Zeile sein...

[Jojo11]

Code Auswählen Erweitern


$ ps ax|grep ebusd
2049 ?        Ssl    0:08 /usr/local/bin/ebusd -f-l All -d /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A602DIPA-if00-port0 -p 8888
2710 pts/0    S+     0:00 grep --color=auto ebusd


Seltsam. Diese Instanz bekomme ich mit dem init.d Skript nicht gestoppt.

Wobei ich mich gerade frage, was das "-f" da zu suchen hat 

schöne Grüße
Jo

[john30]

@Jojo11:
Welche Version vom ebusd hast Du denn im Einsatz?
Es gab da mal ein Problem mit dem init Script, weil das PID file leer war.
Wenn Du natürlich "-f" angibst, wird sowieso kein PID file erstellt, dann tut sich das init Script auch schwer, den Prozess zu finden...

[Jojo11]

Ich hatte ja heute nochmal aktualisiert. Bei mir läuft diese Version: https://github.com/yuhu-/ebusd
Seit ich das "-f" entfernt habe, funktioniert das Skript. Aber an dem eigentlichen Problem hat das nichts geändert 

schöne Grüße
Jo

[john30]

Bei mir läuft diese Version: https://github.com/yuhu-/ebusd

Wenn Du Muße hast, kannst ja mal meinen fork probieren:
https://github.com/john30/ebusd

Da sind ein paar Verbesserungen drin. Einen Versuch ist es wert denke ich, auch wenn es wahrscheinlich bei Dir keinen Unterschied machen wird.

Die Log Level sind in meinem Fork allerdings etwas anders und lehnen sich an syslog an (error/notice/info/debug). Es wäre gut, wenn Du für einen Test auf "debug" stellst.

LG John

[Jojo11]

Ok, danke. Werde ich später am Tag mal testen und dann berichten.

schöne Grüße
Jo

[Reinhart]

@Jojo11

John30 hat ja die ebusd Version hier bei dieser Diskussion weiter verbessert. http://forum.fhem.de/index.php/topic,29737.msg254167.html#msg254167 und liegt in seinem Git.

Ich hänge dir hier die fertig compilierte Version an (am Raspi B+ compiliert), dann brauchst nicht alles neu laden. Die Datei entpacken und nach /usr/local/bin/ kopieren, Rechte kontrollieren (755). Das ist die Version wo dieser PID Fehler bereits behoben ist und nicht mehr mehrere Instanzen laufen können.

Bei mir läuft diese Version etwa eine Woche stabil und ohne Probleme.

Schöne Grüße
Reinhart