Probleme mit TCM310 und seriellem Interface beim Umzug auf Raspberry Pi 5

Begonnen von MathiasE, 08 Januar 2025, 22:18:28

Vorheriges Thema - Nächstes Thema

MathiasE

Hallo zusammen,

ich versuche aktuell meinen Raspberry Pi 3 durch einen Raspberry Pi 5 abzulösen und stoße mit dem Enocean Pi auf Kommunikationsprobleme.

Mein System:
- Raspberry Pi 5
- SSD-Erweiterung
- Enocean Pi (von Eltako) mit TCM310 Chip
- Ubuntu 24.10
- FHEM manuell installiert und Backup vom Altsystem eingespielt

Nun zum Problem:
Die serielle Schnittstelle ließ sich recht einfach aktivieren (in config.txt das Overlay dtoverlay=uart0-pi5 eingetragen). FHEM kann auch darauf über ttyAMA0 zugreifen. ABER nicht vollständig. Und jetzt wird es komisch...
Ich kann vom TCM310 beispielsweise die BASEID auslesen. Ja sogar schreiben. ABER sobald ich die Version auslesen will, hängt sich FHEM auf. Gefühlt hängt FHEM dann in einer Schleife.
Zunächst dachte ich, dass der TCM310 ein Problem hat. Auf dem Raspberry Pi 3 funktioniert die Kommunikation aber tadellos.
Wenn ich nun den Enocean Pi über ein UART2USB Interface per USB anschließe und in FHEM über ttyUSB0 einbinde, funktioniert alles einwandfrei.
So könnte ich es lassen. Aber mich wurmt es, dass ich die UART-Schnittstelle des Raspberry Pi's nicht nutzen kann und frage mich, ob nicht jemand anderes ebenso die Probleme hat und vielleicht schon gelöst hat.
Außerdem ist mir aufgefallen, dass nicht alle Telegramme über die UART0 Schnittstelle ankommen, wenn ich in FHEM testweise auf ttyAMA0 wechsle (das geht nur, wenn man nicht speichert bzw. FHEM nicht startet, denn da wird die Version abgefragt).
Achso... Noch etwas. Wenn ich ein Logic-Analyzer anschließe, dann sehe ich, dass auf Anfrage der Version über ttyAMA0 auch eine Antwort kommt. Aber scheinbar wird die nicht interpretiert - über UART2USB dann aber schon.
Kann das ein Timing Problem beim Raspberry Pi sein? Ich hab gelesen, dass der TCM310 ja nicht mit 57600 baud arbeitet, sondern mit 58823 baud. Ich habe vergeblich versucht die UART-Clock anzupassen. Die Frage ist, ob der Pi5 diesbezüglich weniger tolerant ist, als der Pi3? Oder kann das an etwas ganz anderem liegen? Hat jemand eine Idee?

IPWF

FHEM auf Hardkernel ODROID-N2+ mit Ubuntu 22.04.5 LTS
Funkschnittstelle EnOcean

MathiasE

Ne, leider nicht. Meine UART0 ist ja ansprechbar. Loopback funktioniert auch einwandfrei. Allerdings das eingangs beschriebene Problem, dass der Response vom TCM310 nicht sauber interpretiert wird.
Die Einstellungen der UART hab ich übrigens auch mit denen vom RPi3 verglichen und die waren gleich. Einen Bug im TCM Modul in FHEM würde ich ausschließen, da über USB Adapter alles funktioniert. Deswegen bin ich auf die Idee gekommen, dass bei längeren Übertragungen wie beispielsweise der Version die unterschiedlichen Baudraten (57600 vs 58823) eine Rolle spielen könnten.

Otto123

Zitat von: MathiasE am 08 Januar 2025, 22:18:28(in config.txt das Overlay dtoverlay=uart0-pi5 eingetragen)
raspi-config macht es offenbar anders. Da steht anschließend das in /boot/firmware/config.txt drin (nur die letzten Zeilen):
...
[cm5]
dtoverlay=dwc2,dr_mode=host

[all]
dtparam=i2c_arm=on
dtparam=uart0=on
Also nur als Versuch: nimm deine händische Änderung zurück und mach es mal mit raspi-config. Vermutlich kommt nix anderes raus, aber man weiß ja nie.
Ich konnte das mittlerweile am echten Objekt nachvollziehen, die hier zitierten Artikel waren ja nur graue Theorie :)
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

MathiasE

Vielen Dank für die Unterstützung. Ich habe die Einstellung nun mit raspi-config gemacht und erhalte selbiges Fehlerbild. BaseID usw auslesen geht, Version nicht...

MathiasE

Ich hab hier zwei Bilder eingefügt:
Und zwar einmal die Rückmeldung des TCM310 auf Anfrage der BASEID (kann FHEM interpretieren):
<Response_BaseID.JPG>

Und einmal die Rückmeldung auf die Anfrage der VERSION (hier hängt sich FHEM auf):
<Response_Version.JPG>

Man sieht auch schön, dass die Baud-Rate bei den 58823 ist...

FHEM hängt sich wieder auf / ein Timeout kommt nicht...

Kann man beim Raspberry Pi 5 denn die Baudrate individuell einstellen, oder muss das über die Modifikation der UART-Clock passieren? Ich hab es leider nicht hin bekommen...

Damu

Zitat von: MathiasE am 08 Januar 2025, 22:18:28Ich hab gelesen, dass der TCM310 ja nicht mit 57600 baud arbeitet, sondern mit 58823 baud.

Wo steht den sowas.

Ubuntu und PI5?

klingt nach einem Rechteproblem mit der Uart Schnitstelle.

MathiasE

Das steht im User-Manual:
TCM310_User_Manual.pdf (Seite 9)

Ne, wieso Rechteproblem? Die serielle Schnittstelle kann geschrieben und gelesen werden (auch von FHEM), aber nur halt kleine Pakete. Andere werden verschluckt wie beispielsweise die "Version".

Ich habe übrigens noch einen anderen Enocean Pi bestellt, der eben angekommen ist. Damit habe ich das gleiche Problem...
Deshalb würde ich nun eher auf ein Timing Problem tippen. Vielleicht ist der Raspberry Pi 5 eben nicht so tolerant bezüglich der Baudrate wie seine Vorgänger?

Gibt es denn jemanden mit Ubuntu für RPi (24.10) bei dem der Enocean Pi über UART0 problemlos läuft?

Damu

Zitat3.6 Serial Interface
TCM 310x provides a bi-directional serial interface which conforms to the EnOcean ESP3
specification. For details regarding ESP3 please refer to the ESP3 specification1. The data
rate on the serial interface is 58.8 kbit/s which is usually interoperable with systems run-
ning at 57.6 kbit/s.
Direction Nominal serial data rate Tolerance
TX (sent by module) 58823 bit/s (=57600 bit/s + 2.1%) < 50 ppm
RX (received by module) 58823 bit/s < 5%

57600 würde ich sagen.
Ist bei mir so eingestellt.


MathiasE

Ja, das ist bei mir ebenso eingestellt. Beim Raspberry Pi 3b funktioniert alles, beim Pi5 eben nicht. Und zwar können nicht alle Pakete ordnungsgemäß empfangen werden. Je länger das Protokoll, desto unwahrscheinlicher der Empfang (so mein Verdacht). Der TCM310 kommt mit der Baudrate auch zurecht aber der Pi vermutlich nicht ganz... Könnte das sein?

Damu

Ja war doch was mit PI4 und Uart und BT zusammen.
Mann muste doch BT deaktivieren.

MathiasE

Das habe ich auch schon ausprobiert. Aber ich hab gelesen, dass der Pi5 mittlerweile eine eigen UART fürs Bluetooth hat. Da merke ich keinen Unterschied, wenn Bluetooth deaktiviert ist.

Damu

Vielleicht hilft das hier?
https://help.z-wave.me/en/knowledge_base/art/180/cat/34/
Data bits
 Parity
Stop bits
Flow ctrl
UART Packet Length

Ist alles korrekt?

Otto123

Stört ev. der GPIO4 Anschluss (Kühlung oder sowas?) oder ist der (mit SDA SCL) auf dem Board nur nach außen geführt?

meine Idee wäre noch: einen USB serial Adapter zu versuchen ...
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

MathiasE

Genau den USB-Serial Adapter habe ich verwendet und der funktioniert...

Was mir eben aufgefallen ist bei einem anderen Loop-Back-Test: Da verschluckt sich schon was. Und zwar kann ich 14 Zeichen übertragen - danach ist Schluss. Ich hab nun herausgefunden, dass die Raspberry Pi 5 UART einen Buffer von 16 Byte hat! Die alten Versionen 32 Byte! Ich kann mir vorstellen, dass es damit zu tun haben könnte?