eBus Schaltung Rpi in Betrieb nehmen!

[john30]

Die Frage dabei ist, warum bei r -p 6 <Variable> kein Unterschied zu r -p 1 <Variable> besteht.
Es wird immer im hinterlegten --pollinterval=10 abgefragt und nich bei z.B. 10s*6=60s.

wie im issue gerade beschrieben: es ist eine Poll Priorität und kein Faktor auf die Zeit.

[Reinhart]

es gibt einen neuen Adapter der Version 3.0 !

LG
Reinhart

[MGK]

Ich habe alles noch einmal neu auf einem Raspi4 installiert:
Raspbian 4.19.97
ttyebus 1.8
ebusd 3.4.v3.3-51
und es funktioniert einwandfrei. Ich habe *kein* Upgrade vom Raspbian auf die aktuelle Version gemacht, weil ich ja dort das Problem vermute.

Ich habe ein Image (buster4.19.97-ttyebus1.8-ebusd3.4.v3.3-51.rar) gezogen und hier abgelegt.

Ich hoffe dass das zu einem Erfolg führt. Feedback erwünscht. Eine genauere Analyse mit anderen Raspbian Versionen werde ich noch anstellen.
LG

Ich scheitere auch gerade am Umzug von Pi3B auf den Pi4B.
Wie auch schon andere User habe ich das "no signal" Problem.
Leider ist das oben genannte Image nicht mehr online verfügbar (laut Google liegt es im Online Papierkorb).

@galileo Könntest du dir das Problem mit dem aktuellen Buster auf dem Pi4 bitte noch einmal genauer anschauen.

[galileo]

@galileo Könntest du dir das Problem mit dem aktuellen Buster auf dem Pi4 bitte noch einmal genauer anschauen.

Das habe ich bereits getan und ich bin nach vielen Stunden Recherche gescheitert.
Das Problem ist die Zuordnung der seriellen Interrupts welche beim Raspi4 und Raspbian nach 4.19.97 einer anderen Logik gehorchen, die ich nicht nachvollziehen kann.

Sollte hier ein Linux Spezialist mitlesen, wäre seine Hilfe sehr willkommen.
Ansonsten kann ich nur empfehlen, ein altes Raspbian für RASPI4 zu verwenden (funktioniert einwandfrei) oder auf den eBUS3 Adapter umzusteigen, der wieder mit dem ttyAMA0 funktioniert.
https://forum.fhem.de/index.php?topic=114988.msg1092202#msg1092202

Das "alte" Raspbian kann übrigens hier heruntergeladen werden:
https://downloads.raspberrypi.org/raspbian/images/
und ich denke, 2020-02-07 sollte funktionieren.

LG

[chons]

Wie auch schon andere User habe ich das "no signal" Problem.

Falls Du das Image (Kernel: 5.x) noch hast, könntest Du bitte folgendes probieren?
Aktiviere bitte zusätzlich zum ttyebus den UART0 (ttyAMA0) durch den Eintrag enable_uart=1 in der /boot/config.txt.
Die ebusd Koniguration bleibt unverändert "EBUSD_OPTS="-d /dev/ttyebus....:"

Danke.

EDIT: Nach der Anpassung in der config.txt bitte einmal booten und sicherstellen, dass /dev/ttyAMA0 (ls /dev/ttyAMA0) vorhanden ist.

[MGK]

Falls Du das Image (Kernel: 5.x) noch hast, könntest Du bitte folgendes probieren?
Aktiviere bitte zusätzlich zum ttyebus den UART0 (ttyAMA0) durch den Eintrag enable_uart=1 in der /boot/config.txt.
Die ebusd Koniguration bleibt unverändert "EBUSD_OPTS="-d /dev/ttyebus....:"

Danke.

EDIT: Nach der Anpassung in der config.txt bitte einmal booten und sicherstellen, dass /dev/ttyAMA0 (ls /dev/ttyAMA0) vorhanden ist.

Habe ich ausprobiert, leider ohne Erfolg, es findet wieder kein Signal.
Ich werde nun mal ein altes Imae probieren.

[MGK]

Ich habe noch mal ein bisschen weiter experimentiert.
Mit dem aktuellen Image (Kernel 5.4.79-v7l+) und mit ttyAMA0 (ohne ttyebus) findet er das Signal.

Code Auswählen Erweitern

version: ebusd 3.4.v3.4-83-gab75329
signal: acquired
symbol rate: 84
max symbol rate: 103
min arbitration micros: 26
max arbitration micros: 42
min symbol latency: 26
max symbol latency: 65
reconnects: 0
masters: 4
messages: 15
conditional: 0
poll: 0
update: 4
address 03: master #11
address 08: slave #11
address 10: master #2
address 31: master #8, ebusd
address 33: master #13
address 36: slave #8, ebusd
address 38: slave #13
address 52: slave


Leider weißt ebusd den Adressen keine CSV zu.
Kann ich den Adressen die richtigen CSV manuell zuweisen?
Meine ebusd config sieht aktuell wie folgt aus:

Code Auswählen Erweitern

EBUSD_OPTS="-d /dev/ttyAMA0 -p 8888 --scanconfig --httpport=8889 --latency=100000 --receivetimeout=100000"

Mit dem alten pi3B sieht die ebusctl info so aus:

Code Auswählen Erweitern

version: ebusd 3.4.v3.3-51-g57eae05
update check: revision v3.4 available, vaillant/15.700.csv: different version available, vaillant/52.vr_70.csv: different version available
signal: acquired
symbol rate: 22
max symbol rate: 140
min arbitration micros: 7
max arbitration micros: 86
min symbol latency: 4
max symbol latency: 21
reconnects: 0
masters: 4
messages: 677
conditional: 0
poll: 0
update: 9
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0703;HW=7401", loaded "vaillant/bai.0010006101.inc" ([PROD='']), "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=70000;SW=0419;HW=4603", loaded "vaillant/15.700.csv"
address 31: master #8, ebusd
address 33: master #13
address 36: slave #8, ebusd
address 38: slave #13, scanned "MF=Vaillant;ID=V32;SW=0117;HW=9802", loaded "vaillant/38.v32.csv"
address 52: slave, scanned "MF=Vaillant;ID=VR_70;SW=0109;HW=2903", loaded "vaillant/52.vr_70.csv"


[galileo]

Auch auf die Gefahr dass ich mich wiederhole:
Das aktuelle Raspbian Image wird mit ttyebus und RASPI 4 nicht funktionieren.
ttyAMA0 funktioniert, aber da bekommst du wahrscheinlich Probleme mit der Latency oder der Arbitrierung oder...
Ich habe die letzte mir bekannte und funktionierende Kombination aus Raspbian (Buster), ttyebus und ebusd nochmals aktiviert
(buster4.19.97-ttyebus1.8-ebusd3.4.v3.3-51.rar) und die kann wieder unter
https://drive.google.com/file/d/1t5DwRCnL9svqCC7si-Y-qeUK_uVIfmuW/view
runtergeladen werden.
Eventuell müssen aber noch die Konfigurationen angepasst werden, weil dieses Image meinem persönlichen Umfeld entspricht.
LG

[DerFranke]

Meine Schaltung ist zwar noch nicht da, aber man könnte die SW ja schon mal installieren.
Nur, wie ist das mit root auf dem pi?

Code Auswählen Erweitern

pi@raspberrypi:~ $ sudo wget -qO - https://raw.githubusercontent.com/john30/ebusd-debian/master/ebusd.gpg.key|apt-key add -
E: This command can only be used by root.

Ich komme da mit Johns Anleitung nicht weiter

https://github.com/john30/ebusd-debian/blob/master/README.md

Code Auswählen Erweitern

pi@raspberrypi:~ $ sudo apt-get update
OK:1 http://raspbian.raspberrypi.org/raspbian buster InRelease
OK:2 http://archive.raspberrypi.org/debian buster InRelease
OK:3 http://packages.microsoft.com/repos/code stable InRelease
Holen:4 https://www.ebusd.eu/repos/apt/default/buster buster InRelease [4.382 B]
Fehl:4 https://www.ebusd.eu/repos/apt/default/buster buster InRelease
  Die folgenden Signaturen konnten nicht überprüft werden, weil ihr öffentlicher Schlüssel nicht verfügbar ist: NO_PUBKEY E30CF1F4E8C8272C
Paketlisten werden gelesen... Fertig
W: GPG-Fehler: https://www.ebusd.eu/repos/apt/default/buster buster InRelease: Die folgenden Signaturen konnten nicht überprüft werden, weil ihr öffentlicher Schlüssel nicht verfügbar ist: NO_PUBKEY E30CF1F4E8C8272C
E: Das Depot »https://www.ebusd.eu/repos/apt/default/buster buster InRelease« ist nicht signiert.
N: Eine Aktualisierung von solch einem Depot kann nicht auf eine sichere Art durchgeführt werden, daher ist es standardmäßig deaktiviert.
N: Weitere Details zur Erzeugung von Paketdepots sowie zu deren Benutzerkonfiguration finden Sie in der Handbuchseite apt-secure(8).


[Otto123]

am einfachsten erst sudo su - dann weiter mit dem Befehl. Sonst klappt die Pipe nicht.

Code Auswählen Erweitern

sudo su
# Jetzt alle weiteren Befehle ohne sudo davor
wget -qO - https://raw.githubusercontent.com/john30/ebusd-debian/master/ebusd.gpg.key|apt-key add -
Oder sudo bash -c "Dein Befehl"

[DerFranke]

am einfachsten erst sudo su - dann weiter mit dem Befehl. Sonst klappt die Pipe nicht.

Danke, hat geklappt

[Reinhart]

@DerFrankei

ich würde dich ersuchen alles was den neuen Adapter betrifft dann hier zu posten, sonst bekommen wir die totale Verwirbelung!

LG

[DerFranke]

OK, ich war nur der Meinung, daß das geschilderte Problem mehr Raspi als Ebus war.

[Masterdrive]

Hallo zusammen,

ich hoffe ihr könnt etwas Klarheit in meine Verwirrung bringen:
Kann man durch eine "falsche OS / Treiber-Config" die Hardware beschädigen?

Fehler: ich kann nicht mehr senden, nur empfangen

Hintergrund:
Seit Ende 2019 läuft bei mir die Ebus-Platine in Kombination mit einem RPI3 sauber und problemlos mit ebusd.
Seit Mitte 2020 auch mit Openhab2 und dem Ebus-Binding, hier aber mit einigen Workarounds (rule zum Neustart des Bindings, etc...)
Jetzt wollte ich am Wochenende die Workarounds ausbauen und habe folgendes gemacht:
Update des ebusd von 3.4.v3.3-51-g57eae05 auf 21.2.v21.2
Update ebus-binding von 2.5.1-6 auf 2.50.11
Update Openhab2 von 2.4.0 auf 2.5.12

Problem:
Nach dem "Update" funktionierte gar nichts mehr.
Durch den dmesg Fehler:

Code Auswählen Erweitern


genirq: Flags mismatch irq 81. 00000080 (uart-pl011) vs. 00000000 (ttyebus_irq_handler)
ttyebus: Close at at major 10  minor 58

hab ich festgestellt, dass in der /boot/confix.txt der Eintrag "enable_uart=0" verschwunden war.
Also den wieder eingefügt, und durchgestartet.

Nach dem Reboot (auch mit komplett stromlos versucht) startet der ebusd auch wieder, bringt aber folgende Fehler:

Code Auswählen Erweitern


[main error] scan config 08: ERR: arbitration lost
[bus error] send to 08: ERR: arbitration lost

(08 nur als Beispiel, Fehler kommt für alle Bus-Addressen)
Ich bekomme aber weiterhin alle Updates vom Bus mit:

Code Auswählen Erweitern


[update notice] received unknown MS cmd: 10ecb504010d / 050000008000
[update notice] received unknown MS cmd: 1025b504010d / 050000100332
[update notice] received unknown MS cmd: 1050b5040101 / 09150100000581000100
[update notice] received read bai Status01 QQ=10: 31.5;31.5;-;-;-;off
dmesg zeigt sporadisch

Code Auswählen Erweitern


ttyebus: Close at at major 10  minor 58
ttyebus: Close exit


Ich also kompletten Rollback auf das vorherige Image gemacht (von Mitte der vorigen Woche).
Problem bleibt bestehen.

Der Bus selbst funktioniert.
Eine alte 1.6er Platine an einem FTDI-Adapter lief parallel mit meinem PI 1B "zuverlässig" weiter.
(der läuft noch, weil ein paar nicht migrierte RRDs da liegen)
Daher auch das "received read" in den ebusd logs. Die "read" werden vom also PI1 gesendet.
Und die 1.6er kann auch am PI3 problemlos lesen und schreiben, nur die 2.2er Adapter-Platine will irgendwie nicht mehr

Bei einem Test der Platine mit einem

Code Auswählen Erweitern

echo "das ist ein Sendetest" >/dev/ttyebus
Flackert auch die Sende-LED schwach. Die serielle Sende-Verbindung zur Platine scheint also was zu tun...
(flackern, da die um einiges schwacher leuchtet als die beiden anderen)

Habt ihr einen Tip, woran's liegen kann, oder was ich noch in Richtung Fehlersuche unternehmen kann?

Danke, und LG

[HeikoGr]

Hast du zufällig auch dein Raspi OS geupdatet? Kannst du noch genauere Informationen zu Boardversion, OS, ebusd Version und Art der Anbindung geben?

Edit: Du benutzt ttyebus? In welcher Version?

Was steht bei dir in der EBUSD_OPTS Zeile?