eBus Schaltung Rpi in Betrieb nehmen!

john30 · 09 Juni 2019, 09:43:52

Zitat von: rande am 08 Juni 2019, 21:21:44
Daraufhin hab ich mosquitto & mosquitto-clients nochmal installiert. Anscheinend hatte ich die gar nicht drauf, da er alle Pakete runtergeladen hat. Ich kann mich auch nicht erinnern, dass ich mosquitto schonmal wissentlich installiert hatte.

dann war der aber vorher auch nicht drauf, oder? hast du denn MQTT überhaupt genutzt? Falls nicht, kannst du die Meldung im ebusd.log einfach ignorieren.

rande · 09 Juni 2019, 16:22:28

Hi john30,

Nein, mosquitto habe ich nicht benutzt.
ich denke mal auch das ich mqtt vorher nicht drauf hatte.

Was könnte ich denn weiter zur Fehlersuche versuchen?

Wie gesagt... alles was ich bei der ersten Verwendung / Einrichtung installiert & konfiguriert habe, hab ich nochmals gemacht und gecheckt.
Mir fällt grad nichts mehr ein...

Gesendet von meinem TA-1012 mit Tapatalk

john30 · 10 Juni 2019, 11:18:14

Zitat von: rande am 09 Juni 2019, 16:22:28
Was könnte ich denn weiter zur Fehlersuche versuchen?

ich vermute, dass dein System ein automatisches Update gemacht hat, bei dem die Kernel Version aktualisiert wurde. Damit wärst du schon der dritte im Bunde. Ich hab ein Ticket dafür aufgemacht, siehe hier: https://github.com/eBUS/ttyebus/issues/2
Für den Moment würde als schnelle Abhilfe m.E. nur ein Downgrade des Kernel helfen

rande · 10 Juni 2019, 14:31:19

Zitat von: john30
ich vermute, dass dein System ein automatisches Update gemacht hat, bei dem die Kernel Version aktualisiert wurde.

Hi john30,

scheint wirklich so zu sein. Ich habe grade mal meine Kernelversion mit uname -r gecheckt... 4.19.42-v7+
Also genau diese für die du das Ticket geöffnet hast.

Dann versuche ich mal ein downgrade und hoffe, das danach mein System noch läuft.

Grüße

EDIT: Mist, jetzt hab ich den Salat. Nach mehreren getesteten "älteren" Kernel-Versionen kann ich ttyebus nun gar nicht mehr installieren. beim Befehl "make" komt nun immer folgendes:

Code Auswählen

pi@raspberrypi:/ttyebus $ sudo make
make -C /lib/modules/4.19.46-v7+/build M=/ttyebus modules
make[1]: *** /lib/modules/4.19.46-v7+/build: Datei oder Verzeichnis nicht gefunden.  Schluss.
Makefile:24: die Regel für Ziel ,,all" scheiterte
make: *** [all] Fehler 2

Wenn ich das Verzeichnis "build" im angegebenen Pfad erstelle, resultiert beim Ausführen nur noch eine andere Fehlermeldung:

Code Auswählen

pi@raspberrypi:/ttyebus $ make
make -C /lib/modules/4.19.46-v7+/build M=/ttyebus modules
make[1]: Verzeichnis ,,/lib/modules/4.19.46-v7+/build" wird betreten
make[1]: *** Keine Regel, um ,,modules" zu erstellen.  Schluss.
make[1]: Verzeichnis ,,/lib/modules/4.19.46-v7+/build" wird verlassen
Makefile:24: die Regel für Ziel ,,all" scheiterte
make: *** [all] Fehler 2

Reinhart · 10 Juni 2019, 21:39:05

versuchs mal damit.

LG

rande · 10 Juni 2019, 23:24:05

Zitat von: Reinhart am 10 Juni 2019, 21:39:05
versuchs mal damit.

Super, hat geklappt. Mein Problem war wohl vorher, dass ich kernel_headers nicht gedowngraded hatte.
Mit den Maßnahmen in dem Link und anschließendem make & make install für ttyebus hat es dann funktioniert.

Vielen Dank allen beteiligten für eure Hilfe und dem Workaround.

Beste Grüße

galileo · 12 Juni 2019, 21:05:10

Ich werde mir das mit dem ttyebus selbstverständlich ansehen. Ich fürchte nur dass ich frühestens am Wochenende Zeit dazu finden werde.
Bitte bis dahin bitte keinen Upgrade machen oder eben den Downgrade. Sobald ich etwas weiss melde ich mich hier wieder.
LG
Eduard

galileo · 16 Juni 2019, 17:28:12

Neue Version des ttyebus Kernel Moduls

Auf github https://github.com/eBUS/ttyebus gibt es eine neue Version 1.6 des ttyebus Treibers.
Dieser funktioniert nun auch mit der Kernel Version V4.19.42 (und hoffentlich höher auch).
Die Ursache für die Fehlfunktion war folgende:
Der Interrupt für den UART PL011 war beim Raspi 2 und 3 bisher auf 87.
Mit dem Kernel Update ist der Interrupt auf 81 gewandert. Ich habe keine Ahnung, warum das so ist.
Auffällig ist jedenfalls, dass der Interrupt für den Raspi 1 immer schon auf 81 war.

Der ttyebus Treiber hat jetzt eine Versionsabfrage auf V4.19.42 (oder größer) und setzt dann den Interrupt auf 81.
Schön ist das nicht, ich würde gerne den Interrupt so setzten wie ihn Raspbian jeweils vorgibt, habe aber noch keine
Möglichkeit gefunden, das per Programm herauszufinden. Falls irgendjemand hier eine Idee hat, wie das gehen könnte
("welcher Interrupt ist dem uart-pl011 zugeordnet") dann wäre ich für einen Hinweis dankbar.
LG
Eduard

jonien · 17 Juli 2019, 20:20:33

Hallo,

da ich mir den Raspi 4 zulegen möchte, bin ich gerade dabei "Buster" zu installieren. Bisher lief alles gut.

EBUS 3.3 habe ich installiert.
Ab EBUS 3.3 soll es ja möglich sein, die config-Dateien automatisch zu holen/aktualisieren: mit

-c, --configpath=PATH
Read CSV config files from PATH [http://ebusd.eu/config/]
...soll ganz einfach sein, aber wenn das Scheunentor erstmal zu ist..., ich versuche schon seit 2h den Eintrag in der "ebusd" anzupassen

...ich weiß einfach nicht an welcher Stelle welcher Eintrg zu machen ist, und welche Optionen noch anzugeben sind

Bisherige Konfiguration:

Code Auswählen

 EBUSD_OPTS="-d 192.168.168.151:8889 -l /var/log/ebusd.log --scanconfig --latency=20000 --address=01"
EBUSD_OPTS="-d 192.168.168.151:8889 -l /var/log/ebusd.log --scanconfig --latency=20000 --address=01 --configpath=http://ebusd.eu/config/"

Bei der manuellen Installation unter Stretch bekomme ich folgende Ausgabe:

Code Auswählen

root@phoscon:/home/pi# dpkg -l | grep 'ebusd'
ii  ebusd                                 3.2                               armhf        eBUS daemon.
ii  ebusd-configuration                   2.1.b143f39-de                    all          ebusd configuration files (de).

...unter BUSTER mit der Autom.Conf:

Code Auswählen

pi@raspiBUSTER:/ $ dpkg -l | grep 'ebusd'^C
pi@raspiBUSTER:/ $ sudo dpkg -l | grep 'ebusd'
ii  ebusd                                 3.3                                   armhf        eBUS daemon.

...kann mir jemand einen Schub's geben?

Liebe Grüße Jörg

john30 · 18 Juli 2019, 07:22:39

Zitat von: jonien am 17 Juli 2019, 20:20:33
-c, --configpath=PATH
Read CSV config files from PATH [http://ebusd.eu/config/]

die Werte in eckigen Klammern sind die defaults, d.h. wenn du nicht schon an den Parametern etwas geändert hast, dann wird eh der webservice genutzt.
Anonsten findest du die Einstellungen in der Zeile mit

Code Auswählen

EBUSD_OPTS="..." in der Datei /etc/default/ebusd oder /etc/init.d/ebusd

jonien · 18 Juli 2019, 09:29:55

Guten Morgen John,

vielen Dank für Deine schnelle Antwort. Da habe ich die Hinweise im WIKI und GIT falsch interpretiert. Ich hatte angenommen, das ich entweder die "manuelle" Installation der Config-Dateien vornehmen muss, oder aber die "ebusd" entsprechend ergänzen muss.

Demnach wäre ja dann dieser Eintrag in der "ebusd" ausreichend:

Code Auswählen

EBUSD_OPTS="-d 192.168.168.151:8889 -l /var/log/ebusd.log --scanconfig --latency=20000 --address=01"

Werden die Config-Dateien dann auf dem Raspi (zwischen-)gespeichert? Wenn ja, müsste ich sie dann nicht mit
dpkg -l | grep 'ebusd' angezeigt bekommen?

Wie könnte ich sonst am besten kontrollieren, ob der Zugriff auf die Config-Dateien erfolgreich ist?

LG Jörg

john30 · 18 Juli 2019, 10:14:12

Zitat von: jonien am 18 Juli 2019, 09:29:55
Demnach wäre ja dann dieser Eintrag in der "ebusd" ausreichend:
Code Auswählen Erweitern
EBUSD_OPTS="-d 192.168.168.151:8889 -l /var/log/ebusd.log --scanconfig --latency=20000 --address=01"

richtig

Zitat von: jonien am 18 Juli 2019, 09:29:55
Werden die Config-Dateien dann auf dem Raspi (zwischen-)gespeichert? Wenn ja, müsste ich sie dann nicht mit
dpkg -l | grep 'ebusd' angezeigt bekommen?

nein und nein

Zitat von: jonien am 18 Juli 2019, 09:29:55
Wie könnte ich sonst am besten kontrollieren, ob der Zugriff auf die Config-Dateien erfolgreich ist?

lass dir einfach nach start von ebusd mit dem "info" Kommando sagen, was Sache ist, also

Code Auswählen

ebusctl info aufrufen.
Da steht dann drin, ob ebusd überhaupt irgendwelche Geräte am Bus sieht und falls ja, welche config files dafür geholt&geladen wurden.

jonien · 18 Juli 2019, 11:41:45

Hallo John,

Danke für Deine ausführliche Hilfe und Hintergrundinformation. Somit ist die Standartinstallation ja sehr einfach geworden.

Wie immer ein toller Support.

LG Jörg

john30 · 18 Juli 2019, 11:46:12

Zitat von: jonien am 18 Juli 2019, 11:41:45
Somit ist die Standartinstallation ja sehr einfach geworden.

das war die Idee

ClausL · 12 September 2019, 12:50:19

Guten Tag,

ich habe hier plötzlich Probleme mit den Config-Dateien. Ohne wirklich erkennbare Ursache hatte ich nur noch ca. 50 messeages (statt vorher über 1.000) zur Verfügung. Das konnte ich inzwischen weitgehend bereinigen. Die Ursache konnte ich aber nicht wirklich feststellen. Ich vermute, dass sich die Speicherkarte beim Raspi langsam in den Ruhestand verabschiedet und daher einige Dateien vorübergehend nicht mehr lesbar waren.

Bei der Ursachenforschung habe ich mir die Frage gestellt, ob es nicht möglich ist, für erkannte Geräte das Laden der passenden csv zu erzwingen.

Und die 2. Frage wäre dann ob man schon das aktuelle Debian für den Raspi verwenden kann, oder ob da Probleme zu erwarten sind.

Viele Grüße, Claus