eBus Schaltung Rpi in Betrieb nehmen!

Begonnen von Reinhart, 19 Februar 2018, 19:38:23

Vorheriges Thema - Nächstes Thema

alphachris

Zitat von: jkyprian am 12 März 2018, 19:34:04
Hallo zuammen!

Ich hab inzwischen den eBus Rpi Adapter erfolgreich in Betrieb genommen. Allerdings verliert ebusd nach einigen Stunden die Verbindung zum Bus ("no signal"). Wenn ich den Rpi neu boote dann geht es wieder. Die Heizungsgeräte sind nicht betroffen. Habt Ihr vielleicht einen Tipp?

Viele Grüße
Jan Eric
Hallo! Lt. FHEM Wiki sollte hier ein Watchdog Abhilfe schaffen! (siehe https://wiki.fhem.de/wiki/EBUS#System.C3.BCberwachung)

LG

Reinhart

Zitat von: jkyprian am 12 März 2018, 19:34:04
Hallo zuammen!

Ich hab inzwischen den eBus Rpi Adapter erfolgreich in Betrieb genommen. Allerdings verliert ebusd nach einigen Stunden die Verbindung zum Bus ("no signal"). Wenn ich den Rpi neu boote dann geht es wieder. Die Heizungsgeräte sind nicht betroffen. Habt Ihr vielleicht einen Tipp?

Viele Grüße
Jan Eric

Man müsste jetzt wissen wer oder was das verursacht? Hast du schon eimal in den Logs (ebusd, syslog) geschaut ob hier irgend ein Hinweis steht?

Blinken die Leds in diesem Status noch?

LG
FHEM auf Raspy4 mit Bullseye + SSD, Homematic, ESP8266, ESP32, Sonoff, eBus, NanoCUL, MapleCUL, , MQTT2, Alexa

jkyprian

Zitat von: Reinhart am 12 März 2018, 22:05:39
Man müsste jetzt wissen wer oder was das verursacht? Hast du schon eimal in den Logs (ebusd, syslog) geschaut ob hier irgend ein Hinweis steht?

/var/log/syslog

syslog:Mar 12 23:44:52 raspi kernel: [12146.229627] ttyebus: Close at at major 10  minor 58
syslog:Mar 12 23:44:52 raspi kernel: [12146.229637] ttyebus: Close exit


/var/log/ebusd.log:

2018-03-12 23:43:37.046 [bus error] signal lost
2018-03-12 23:44:52.123 [bus notice] re-opened /dev/ttyebus


Zitat von: Reinhart am 12 März 2018, 22:05:39
Blinken die Leds in diesem Status noch?

Orange Led leuchtet, grün flimmert wg. der Aktivität auf dem eBus durch die Heizung.
ebusd scheint auch ok.

Es scheint mir am ttyebus zu liegen bzw. an der uart schnittstelle es Rpi. Ich hab schon versucht ttyebus neu zu laden (also erstmal ebusd gestoppt. dann rmmod ttyebus und insmod ttyebus). Hat leider nicht gebracht. Gibt es eine Möglichkeit den uart des Rpi zu reseten?

Viele Grüße,
Jan Eric
Raspberry Pi 3 + KNX

RaspiLED

Hi,
Du könntest den USB Port reseten:
http://www.gtkdb.de/index_36_2304.html
Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Raspberry Pi mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, WifiLight2, Bravia, ...

Reinhart

#19
da passiert eindeutig mit dem Treiber was und irgendwas bringt ihn zum Beenden seiner Tätigkeit.
syslog:Mar 12 23:44:52 raspi kernel: [12146.229627] ttyebus: Close at at major 10  minor 58
syslog:Mar 12 23:44:52 raspi kernel: [12146.229637] ttyebus: Close exit


Galileo ist bis zum Sonntag nicht erreichbar, wird sich aber darum kümmern, bzw. bei dir melden!
Kannst du noch posten welcher Typ von Raspi das ist?

Kannst du uns eventuell noch ein normales Log vom ebsud posten, so dass wir in etwa die letzten 5 Minuten vor dem Absturz sehen?

LG
FHEM auf Raspy4 mit Bullseye + SSD, Homematic, ESP8266, ESP32, Sonoff, eBus, NanoCUL, MapleCUL, , MQTT2, Alexa

pc1246

Moin
Da bin ich ja froh, dass ich mich noch nicht rangemacht habe!
@Arnd: Das Board steckt auf dem RPI nicht am USB!
Gruss Christoph
HP T610
Onkyo_AVR;3 Enigma2; SB_Server ; SB_Player; HM-USB mit 15 HM-CC-RT-DN, 3 HM_WDS10_TH_O, 6 HM-Sec-SCo, 4 HM-Sec-MDIR-2, 1 HM-Sen-MDIR-O-2, 8 Ferion 5000 OW ; PhilipsTV; 4 harmony hub; Jeelink mit 9 PCA301; Somfy; S7-300; 3 LGW; HUE; HM-IP auf Charly

Reinhart

Zitat von: pc1246 am 13 März 2018, 09:06:31
Moin
Da bin ich ja froh, dass ich mich noch nicht rangemacht habe!

Bei uns allen läuft der Treiber problemlos (Raspi B+, Raspi 2, Raspi 3), das ist der erste wo jetzt Probleme bekannt sind und auch dessen Ursache wird zu finden sein.
Bei mir läuft das seit vielen Wochen ohne einen einzigen Fehler.

LG
FHEM auf Raspy4 mit Bullseye + SSD, Homematic, ESP8266, ESP32, Sonoff, eBus, NanoCUL, MapleCUL, , MQTT2, Alexa

pc1246

Zitat von: Reinhart am 13 März 2018, 09:26:13
Bei uns allen läuft der Treiber problemlos (Raspi B+, Raspi 2, Raspi 3), das ist der erste wo jetzt Probleme bekannt sind und auch dessen Ursache wird zu finden sein.
Bei mir läuft das seit vielen Wochen ohne einen einzigen Fehler.

LG
Moin Reinhart
Das war auch so nicht gemeint. Zum einen haengt mein Leben nicht am eBus, und zum Anderen wollte ich das auf einem anderen RPI machen, den ich aber noch in Benutzung habe!
Gruss Christoph
HP T610
Onkyo_AVR;3 Enigma2; SB_Server ; SB_Player; HM-USB mit 15 HM-CC-RT-DN, 3 HM_WDS10_TH_O, 6 HM-Sec-SCo, 4 HM-Sec-MDIR-2, 1 HM-Sen-MDIR-O-2, 8 Ferion 5000 OW ; PhilipsTV; 4 harmony hub; Jeelink mit 9 PCA301; Somfy; S7-300; 3 LGW; HUE; HM-IP auf Charly

jkyprian

Zitat von: RaspiLED am 13 März 2018, 07:26:39
Hi,
Du könntest den USB Port reseten:
http://www.gtkdb.de/index_36_2304.html

Danke für den Tipp. Habe es gerade ausprobiert. Hilft leider anscheinend nicht. Ich werde heute abend mich nochmal dransetzen...
Raspberry Pi 3 + KNX

jkyprian

#24
Zitat von: Reinhart am 13 März 2018, 09:26:13
Bei uns allen läuft der Treiber problemlos (Raspi B+, Raspi 2, Raspi 3), das ist der erste wo jetzt Probleme bekannt sind und auch dessen Ursache wird zu finden sein.
Bei mir läuft das seit vielen Wochen ohne einen einzigen Fehler.

Ich polle alle 10 Sekunden mit eBus Werte der Heizung. Was ich mal probieren könnte ist das pollen auszustellen und nur lesend auf den eBus zuzugreifen.
Raspberry Pi 3 + KNX

Reinhart

alle 10 Sekunden ist etwas zuviel des Guten, das kommt darauf wieviel Werte du auslesen willst, aber das wird er kaum schaffen. Du musst bedenken, das für die normale Buskommunikation zwischen den Geräten auch noch genügend Zeitfenster vorhanden sein müssen. Das ist ja der eigentliche Zweck des eBus. Wenn du jetzt ständig den Bus belegst, bleibt da kaum Zeit für die internen Daten über.
Ich polle alle 10 - 15 Minuten.

Nichts desto trotz, sollte der Treiber sich dadurch nicht beenden.

LG
FHEM auf Raspy4 mit Bullseye + SSD, Homematic, ESP8266, ESP32, Sonoff, eBus, NanoCUL, MapleCUL, , MQTT2, Alexa

galileo

Zitatsyslog:Mar 12 23:44:52 raspi kernel: [12146.229627] ttyebus: Close at at major 10  minor 58
syslog:Mar 12 23:44:52 raspi kernel: [12146.229637] ttyebus: Close exit
Der Treiber beendet sich nicht von selbst, sondern er wird explizit von aussen beendet, durch den Aufruf von "ttyebus_close".
Das scheint aber der ebusd zu sein, der das sendet:
Zitat2018-03-12 23:43:37.046 [bus error] signal lost
2018-03-12 23:44:52.123 [bus notice] re-opened /dev/ttyebus
der hier wegen "signal lost" ein "close" und ein "reopen" macht. Wenn das stimmt, müsste im kernel log unmittelbar darauf so ein open sichtbar sein:
ttyebus: Open at at major xx  minor yy"
allerdings erst wenn man "DEBUG" einschaltet. Du kannst das einmal temporär probieren, indem du im File ttyebusm.c in Zeile 54 den Kommentar (//) von "#define DEBUG 1" entfernst und neu compilierst.
Aber Achtung, das erzeugt eine Menge LOGs, also nicht vergessen wieder auszuschalten.

Wenn das nicht erscheint, geht vielleicht das re-open schief?
LG
Eduard


jkyprian

Zitat von: galileo am 13 März 2018, 16:10:26
allerdings erst wenn man "DEBUG" einschaltet. Du kannst das einmal temporär probieren, indem du im File ttyebusm.c in Zeile 54 den Kommentar (//) von "#define DEBUG 1" entfernst und neu compilierst.
Aber Achtung, das erzeugt eine Menge LOGs, also nicht vergessen wieder auszuschalten.

Danke für den Tipp. Hab jetzt DEBUG eingeschaltet und lass es mal laufen...
Raspberry Pi 3 + KNX

jkyprian

#28
Zitat von: jkyprian am 13 März 2018, 18:09:27
Danke für den Tipp. Hab jetzt DEBUG eingeschaltet und lass es mal laufen...

/var/log/kern.log

Mar 13 18:39:41 raspi kernel: [25066.039011] ttyebus: Poll request
Mar 13 18:39:41 raspi kernel: [25066.039017] ttyebus: Poll succeeded. RxHead=51, RxTail=46
Mar 13 18:39:41 raspi kernel: [25066.039024] ttyebus: Read request with offset=0 and count=1
Mar 13 18:39:41 raspi kernel: [25066.039029] ttyebus: Read exit with 1 bytes read
Mar 13 18:39:41 raspi kernel: [25066.039039] ttyebus: Poll request
Mar 13 18:39:41 raspi kernel: [25066.039046] ttyebus: Poll succeeded. RxHead=51, RxTail=47
Mar 13 18:39:41 raspi kernel: [25066.039053] ttyebus: Read request with offset=0 and count=1
Mar 13 18:39:41 raspi kernel: [25066.039058] ttyebus: Read exit with 1 bytes read
Mar 13 18:39:41 raspi kernel: [25066.039069] ttyebus: Poll request
Mar 13 18:39:41 raspi kernel: [25066.039075] ttyebus: Poll succeeded. RxHead=51, RxTail=48
Mar 13 18:39:41 raspi kernel: [25066.039082] ttyebus: Read request with offset=0 and count=1
Mar 13 18:39:41 raspi kernel: [25066.039087] ttyebus: Read exit with 1 bytes read
Mar 13 18:39:41 raspi kernel: [25066.039097] ttyebus: Poll request
Mar 13 18:39:41 raspi kernel: [25066.039103] ttyebus: Poll succeeded. RxHead=51, RxTail=49
Mar 13 18:39:41 raspi kernel: [25066.039110] ttyebus: Read request with offset=0 and count=1
Mar 13 18:39:41 raspi kernel: [25066.039116] ttyebus: Read exit with 1 bytes read
Mar 13 18:39:41 raspi kernel: [25066.039126] ttyebus: Poll request
Mar 13 18:39:41 raspi kernel: [25066.039132] ttyebus: Poll succeeded. RxHead=51, RxTail=50
Mar 13 18:39:41 raspi kernel: [25066.039139] ttyebus: Read request with offset=0 and count=1
Mar 13 18:39:41 raspi kernel: [25066.039144] ttyebus: Read exit with 1 bytes read
Mar 13 18:39:41 raspi kernel: [25066.039154] ttyebus: Poll request
Mar 13 18:39:41 raspi kernel: [25066.039158] ttyebus: Poll timeout
Mar 13 18:39:41 raspi kernel: [25066.064234] ttyebus: Poll request
Mar 13 18:39:41 raspi kernel: [25066.064244] ttyebus: Poll timeout
Mar 13 18:39:41 raspi kernel: [25066.064357] ttyebus: Poll request
Mar 13 18:39:41 raspi kernel: [25066.064363] ttyebus: Poll timeout
Mar 13 18:39:41 raspi kernel: [25066.115231] ttyebus: Poll request
Mar 13 18:39:41 raspi kernel: [25066.115242] ttyebus: Poll timeout
Mar 13 18:39:41 raspi kernel: [25066.115271] ttyebus: Poll request
Mar 13 18:39:41 raspi kernel: [25066.115277] ttyebus: Poll timeout

/var/log/ebusd.log

2018-03-13 18:39:31.130 [update info] received MM cmd: 1013050a00
2018-03-13 18:39:31.130 [update notice] received unknown MM cmd: 1013050a00
2018-03-13 18:39:31.722 [update info] received BC cmd: 10fe080208003700300000003f
2018-03-13 18:39:31.722 [update notice] received unknown BC cmd: 10fe080208003700300000003f
2018-03-13 18:39:31.808 [main debug] performing regular tasks
2018-03-13 18:39:31.936 [update info] received MS cmd: 011506210400e00040 / 0a60800d02e8030000f900
2018-03-13 18:39:31.936 [update notice] received upd00 vorlauftemp_ww2 QQ=01: 24.9
2018-03-13 18:39:32.416 [update info] received MM cmd: 131005030c011a000031ffff3f43000100
2018-03-13 18:39:32.416 [update notice] received unknown MM cmd: 131005030c011a000031ffff3f43000100
2018-03-13 18:39:32.973 [bus debug] ERR: read timeout during receive command, switching to skip
2018-03-13 18:39:33.103 [bus debug] ERR: read timeout during receive response, switching to skip
2018-03-13 18:39:33.217 [update info] received MS cmd: 011506210400840040 / 0a04800d02e8030000ee01
2018-03-13 18:39:33.217 [update notice] received upd00 hwtemp2 QQ=01: 49.4
2018-03-13 18:39:33.431 [bus debug] ERR: read timeout during receive response, switching to skip
2018-03-13 18:39:34.155 [update info] received MS cmd: 011506210400800040 / 0a00800d02f4010cfe6200
2018-03-13 18:39:34.155 [update notice] received upd00 außentemp2 QQ=01: 9.8
2018-03-13 18:39:35.404 [update info] received MS cmd: 011506210402c80040 / 0a4841042a9f0500006304
2018-03-13 18:39:35.405 [update notice] received upd02 uhrzeit QQ=01: 18:43
2018-03-13 18:39:36.373 [update info] received MS cmd: 011506210402c60040 / 0a46410428ffff0000a3a8
2018-03-13 18:39:36.374 [update notice] received upd02 datum QQ=01: 14.03.2018
2018-03-13 18:39:37.134 [mqtt debug] publish ebusd/upd00/vorlauftemp_ww2 24.9
2018-03-13 18:39:37.411 [update info] received BC cmd: 10fe100a0c11030000030a010100213500
2018-03-13 18:39:37.411 [update notice] received unknown BC cmd: 10fe100a0c11030000030a010100213500
2018-03-13 18:39:37.518 [update info] received MS cmd: 011506210402b50040 / 0a35810000ff0000000100
2018-03-13 18:39:37.518 [update notice] received upd02 status2 QQ=01: Heizbetrieb
2018-03-13 18:39:38.091 [update info] received BC cmd: 10fe100a0e100300000000f4000000e001c800
2018-03-13 18:39:38.091 [update notice] received unknown BC cmd: 10fe100a0e100300000000f4000000e001c800
2018-03-13 18:39:38.593 [update info] received MS cmd: 011506210400e00040 / 0a60800d02e8030000fc00
2018-03-13 18:39:38.593 [update notice] received upd00 vorlauftemp_ww2 QQ=01: 25.2
2018-03-13 18:39:38.790 [update info] received MM cmd: 031005030c010148053218ff3f00000600
2018-03-13 18:39:38.790 [update notice] received unknown MM cmd: 031005030c010148053218ff3f00000600
2018-03-13 18:39:39.037 [bus info] poll cmd: 31150621047d870002
2018-03-13 18:39:39.041 [bus debug] arbitration delay 158 micros
2018-03-13 18:39:41.789 [bus debug] switching from ready to send command
2018-03-13 18:39:41.789 [bus debug] notify request: ERR: SYN received
2018-03-13 18:39:41.789 [bus error] poll waermepumpe heizenergie_kwh failed: ERR: SYN received
2018-03-13 18:39:41.789 [bus debug] ERR: SYN received during send command, switching to ready
2018-03-13 18:39:41.790 [update info] received MM cmd: 131005030c011a000032ffff3f43000100
2018-03-13 18:39:41.790 [update notice] received unknown MM cmd: 131005030c011a000032ffff3f43000100
2018-03-13 18:39:41.791 [update info] received MS cmd: 011506210400840040 / 0a04800d02e8030000ee01
2018-03-13 18:39:41.791 [update notice] received upd00 hwtemp2 QQ=01: 49.4
2018-03-13 18:39:41.809 [main debug] performing regular tasks
2018-03-13 18:39:41.817 [bus debug] ERR: read timeout during receive command, switching to skip
2018-03-13 18:39:42.136 [mqtt debug] publish ebusd/upd00/vorlauftemp_ww2 25.2
2018-03-13 18:39:43.038 [bus debug] ERR: read timeout during skip, switching to no signal
2018-03-13 18:39:43.038 [bus error] signal lost
2018-03-13 18:39:43.137 [mqtt debug] publish ebusd/global/signal false
2018-03-13 18:39:43.137 [mqtt debug] publish ebusd/global/uptime 2512
2018-03-13 18:39:51.809 [main debug] performing regular tasks
2018-03-13 18:39:59.143 [mqtt debug] publish ebusd/global/uptime 2528
2018-03-13 18:40:01.810 [main debug] performing regular tasks
2018-03-13 18:40:11.811 [main debug] performing regular tasks


Für mich sieht das so aus als ob bei ttyebus gar keine Daten mehr ankommen (Poll request -> Poll timeout)

Nachtrag: Habe jetzt zusätzlich IRQDEBUG eingeschaltet. Wenn er sich aufhängt dann kommen keine IRQs mehr.

Hab Ihr eine Idee was da vorgehen könnte?
Raspberry Pi 3 + KNX

galileo

ZitatHab Ihr eine Idee was da vorgehen könnte?
Mit
watch -n1 "cat /proc/interrupts"
könntest du feststellen, ob der Linux Kernel die Interrupts überhaupt noch sieht...
LG