Bei den älteren Pi boards (zumindest bis zum 3er) war das CUL-device von locutus' add-on board über /dev/ttyAMA0@38400 erreichbar.
Bei dem Pi5-board kommt nur noch "opened", aber kein "initialized". Alle Befehle laufen ins leere.
Alle anderen Boardkomponenten laufen mittlerweile, inkl. Display.
Wie muß das define aussehen bzw. was fehlt noch zusätzlich in der config.txt?
ich denke es ist keine Frage vom define sondern von der Vorbereitung des Systems. Das PI5 Board hat zwei UARTs AMA0 und AMA10.
Dazu kommen Änderungen in Bookworm.
Ich meine die Vorbereitung kann nach wie vor entsprechend https://wiki.fhem.de/wiki/Raspberry_Pi#Verwendung_UART_f%C3%BCr_Zusatzmodule erfolgen.
Aber bisher hat das mMn keiner ausdiskutiert und ich habe keinen PI5 :(
Danke Otto, das ist zumindest ein Ansatz.
Den Pi5 hab ich mir auch nur angeschafft um zu sehen, was sich dort so alles getan hat außer Geschwindigkeit und Stromverbrauch :)
Ich werde mich die nächsten Tage damit beschäftigen und berichten.
Bisher gibt's leider noch keine Erfolgsmeldung. Unzählige Konstellationen ausprobiert - ohne Erfolg.
Wenn ich das Board auf einen Pi3 verpflanze, klappt alles wieder auf Anhieb.
Ich muß mir überlegen, was man noch ausprobieren kann.
Hätte nicht gedacht, daß mit dem neuen Pi5 so viel umgekrempelt worden ist >:(
ich meine irgendwo gelesen zu haben, dass es relativ einfach mit raspi-config geht, die ttyAMA0 so wie früher aussehen zu lassen.
Eine der beidem UARTs ist ja jetzt per default auf dem extra Konnektor.
Das scheint das Problem zu sein:
2024.06.01 14:53:11 3: Setting CUL868 serial parameters to 38400,8,N,1
2024.06.01 14:53:20 1: Cannot init /dev/ttyAMA0, ignoring it (CUL868)
na das Problem ist eher, das die ttyAMA0 nicht "funktioniert". Was genau hast Du für die Vorbereitung der AMA0 getan?
Was sagt denn dmesg zu dem Teil? Da müsste man doch finden können, auf welchem port es erkannt wurde.
Ich schau mal morgen nach, ob dmesg Licht ins dunkel bringt.
Hab gerade mit einem PI3 nachgesehen, was da so auftauchen sollte, da funktioniert bookworm mit dem locutus-board ja:
dmesg |grep ttyAMA
[ 3.019460] 3f201000.serial: ttyAMA0 at MMIO 0x3f201000 (irq = 99, base_baud = 0) is a PL011 rev2
KeinE Änderung, immer die gleiche Meldung im Logfile:
2024.06.02 09:41:43 3: Setting CUL868 serial parameters to 38400,8,N,1
2024.06.02 09:41:52 1: Cannot init /dev/ttyAMA10, ignoring it (CUL868)
Ausgabe dmesg:
dmesg |grep ttyAMA
[ 0.011176] 107d001000.serial: ttyAMA10 at MMIO 0x107d001000 (irq = 15, base_baud = 0) is a PL011 rev2
[ 0.530792] 1f00030000.serial: ttyAMA0 at MMIO 0x1f00030000 (irq = 125, base_baud = 0) is a PL011 AXI
Mittlerweile habe ich auch alle ttyAMA{0-4,10] ausprobiert.
Auszug aus der config.txt:
dtoverlay=w1-gpio
dtoverlay=disable-bt
dtoverlay=uart0
core_freq=250
Du fischst im Trüben?
Zitat von: RappaSan am 02 Juni 2024, 10:01:04dtoverlay=disable-bt
dtoverlay=uart0
Zitatdisable-bt disables the Bluetooth device and makes the first PL011 (UART0) the primary UART. You must also disable the system service that initialises the modem, so it does not connect to the UART, using sudo systemctl disable hciuart.
miniuart-bt switches the Bluetooth function to use the mini UART, and makes the first PL011 (UART0) the primary UART. Note that this may reduce the maximum usable baud rate (see mini UART limitations below). You must also set the VPU core clock to a fixed frequency using either force_turbo=1 or core_freq=250.
Muss es nicht dtparam=uart0 heissen?
Hast Du danach auch serial-getty totgelegt?
systemctl stop serial-getty@ttyAMA0.service
systemctl disable serial-getty@ttyAMA0.service
systemctl mask serial-getty@ttyAMA0.serviceGeht aber auch über raspi-config (disable serial console)
Ich kann mangels Hardware nur raten ... Und die offizielle Doku empfehlen, in den ganzen Forenbeiträgen im Internet steht ziemlich viel Halbwissen...
https://www.raspberrypi.com/documentation/computers/configuration.html
Und ich meine, da war auch noch was mit veränderten Gruppen: falls bei ls -lha /dev/ttyAMA0 was anderes als dialout steht (plugdev oder tty), musst Du den User FHEM in die passende Gruppe packen.
Den system-getty kram hatte ich schon durchgeführt, auch zusätzlich per raspi-config kontrolliert.
Aus der overlays/Readme hab ich dtoverlay=uart0 und es damit probiert.
Aber egal ob dtoverlay=uart0, dtparam=uart0 oder Kombination davon - das Ergebnis bleibt gleich: Cannot init /dev/ttyAMA10, ignoring it (CUL868)
Es kommt nichts verwertbares vom CUL zurück.
Board auf den PI3 gesteckt und gestartet: Alles OK.
Zitat von: RappaSan am 02 Juni 2024, 13:03:31/dev/ttyAMA10
Das war von mir nur eine Anmerkung! Ziel ist nach wie vor die AMA0 aktivieren!
Es liegt nicht am Board und nicht am define. ;D
Load: dtoverlay=uart0,<param>=<val> ist nicht zum aktivieren der UART sondern zur Änderung der PIN Belegung, das wollte jetzt keiner!
Kannst Du bitte einfach mal von null an diese Schritte ausführen und die Ausgaben posten?
https://wiki.fhem.de/wiki/Raspberry_Pi#Verwendung_UART_f%C3%BCr_Zusatzmodule
und beachte bitte:
ZitatIm aktuellen RaspberryPi OS Bookworm Image ist die config.txt in den Pfad /boot/firmware gewandert.
Ich befürchte, daß ich auch das add-on board überprüfen muß. :(
Mittlerweile meldet es sich auch auf dem Pi3 nicht mehr mit dem CUL. Dann isses kein Wunder, daß der Pi5 auch nicht mitspielt.
Keine Ahnung, was da nun passiert ist.
Zum testen brauche ich aber noch Zeit, kann die Funktionen mit einem weiteren baugleichen board je nach Freizeitlage vergleichen.
Wenn's neue Erkenntnisse gibt, melde ich mich hier.
Hallo
Als Idee um das "add-on board" von der Umsteckerei (Zerstörung?) zu entlasten - es geht ja vermutlich um das ser.-IF auf GPIO 14/15.
Wenn du evtl. einen Programmieradater (USB2ser) oder Ähnliches hast (Achtung 3,3 Volt), kannst du versuchen mit einem Terminalprogramm am PC und auf dem Raspi zu checken ob eine Verbindung zu Stande kommt und fix die verschiedenen /dev/ttyAMA* durchprobieren.
Da kannst du ohne Umsteckerei die ganzen Tests mit den verschiedenen Einstellungen versuchen - ohne FHEM rein auf OS Ebene.
Gruß Ralf
geht noch einfacher: Quelle https://di-marco.net/blog/it/2020-06-06-raspberry_pi_3_4_and_0_w_serial_port_usage/
Man kann die Schnittstelle mit sich selbst testen:
1. PIN 8 und 10 zur Sicherheit mit einem Widerstand ca. 700 Ohm verbinden (Wert ziemlich egal)
2. python module serial installieren
sudo apt install python3-serial3. Script in Datei kopieren: z.B. nano serial_uart_test_TxRx.py
#!/usr/bin/env python
# -*- coding: utf-8 -*-
import serial
test_string = "Test serial port ...".encode('utf-8')
port_list = ["/dev/ttyAMA10","/dev/ttyAMA0","/dev/ttyS0","/dev/ttyS1"]
for port in port_list:
try:
serialPort = serial.Serial(port, 9600, timeout = 2)
print ("Serial port", port, " ready for test :")
bytes_sent = serialPort.write(test_string)
print ("Sended", bytes_sent, "byte")
loopback = serialPort.read(bytes_sent)
if loopback == test_string:
print ("Received ",len(loopback), "bytes. Port", port,"is OK ! \n")
else:
print ("Received incorrect data:", loopback, "on serial part", port, "loopback \n")
serialPort.close()
except IOError:
print ("Error on", port,"\n")
4. Test starten
python3 serial_uart_test_TxRx.py
Zitat von: Otto123 am 02 Juni 2024, 20:08:20geht noch einfacher:
Klar ;D (evtl. ist das IF reserviert wenn ne Console drauf liegt oder dort Bootmeldungen kommen)
Otto hatte weiter oben schon mal die Doku zitiert - da gibt es einen Abschnitt "UART konfigurieren":
https://www.raspberrypi.com/documentation/computers/configuration.html#configuring-uarts
Dort heisst es:
ZitatOn the Raspberry Pi, one UART is selected to be present on GPIO 14 (transmit) and 15 (receive) - this is the primary UART. By default, this will also be the UART on which a Linux console may be present. Note that GPIO 14 is pin 8 on the GPIO header, while GPIO 15 is pin 10.
On Raspberry Pi 5, the primary UART appears on the Debug header
Wenn UART0 der Primary ist liegt er daher vermutlich nicht auf GPIO14/15 sondern als AMA10 auf dem Debug-Header. Vielleicht musst du zusätzlich noch den UART1 aktvieren, der dann auf GPIO14/15 landet.
-> Schuss ins Blaue "dtparam=uart1=on" in Kombination mit "dtoverlay=disable-bt"
Bzw. ein Stück weiter unten heisst es noch:
Zitat/dev/serial0 and /dev/serial1 are symbolic links which point to either /dev/ttyS0 or /dev/ttyAMA0.
On the Raspberry Pi 5, /dev/serial0 is a symbolic link that points to /dev/ttyAMA10.
Due to changes in Bookworm, /dev/serial1 does not exist by default. You can re-enable serial1 by setting the following values in config.txt:
dtparam=krnbt=off
Alles in Allem irgendwie nicht leicht zu überblicken.
Statt ttyAMA0 kann man auch mal ttyS0 oder ttyS1 probieren.
Auf manchen RPi-kompatiblen Boards klappt es damit.
Gute Idee, ich such den USB-Adapter mal raus. Ist irgendwo in den Tiefen des Kellers... :)
Otto's python module serial probiere ich dann als erstes aus (weniger Sucharbeit).
"On Raspberry Pi 5, the primary UART appears on the Debug header"
Wo soll der sein? Zwischen den beiden HDMI-Anschlüssen?
Ich denke ja. Hab ja keinen.
https://m.youtube.com/watch?v=kP2S3JUH-qk
Es sieht so aus, als wäre das addon-board unter die Räder gekommen.
Per minicom -b 38400 -o -D /dev/ttyAMA0 kommt beim V Befehl etwas zurück, aber es ist ein ziemliches durcheinander.
Andere Baudraten, Paritätswechsel oder Stopbits ändern nichts daran.
Im alten thread meinte locutus damals, das in so einem Fall der bootloader per ISP-Programmierer neu geflasht werden muß.
Also muß ich mir mit einem Arduino Nano erst mal ein solches Teil herstellen.
Hi
Da kommst du mit Ottos Hinweis (#15) bestimmt schneller zum Ziel (wenn nichts anderes die Schnittstelle in Beschlag nimmt).
Die Port-List probiert ja fix die relevanten /dev/tty's durch und RX/TX ist mal schnell mit nem Widerstand gebrückt.
Die Herausforderung ist vermutlich die richtigen dtparam/dtoverlay zu finden.
Beim querlesen im Forum der Raspberryseite wird letzten Dezember beim Pi5 teilweise von Bugs in den Overlays berichtet.
Gruß Ralf
Ich hab das Board in einen funktionierenden Pi3 mit entsprechender älterer Software ausprobiert, dabei hat es sich eben herausgestellt, daß dieses add-on board keine verwertbare Kommunikation mehr bereitstellt, daher ist auch eine CUL initialisierung nicht mehr möglich.
Der minicom-check ergab nur noch Salat auf der Schnittstelle.
Das hier vorhandene 2. Board funktioniert auf gleichem Pi3 einwandfrei und liefert auch lesbare Antworten ab.
Mir ist nur rätselhaft, wie das alles passieren konnte - das Board wurde immer auf die richtigen Pins gesteckt, natührlich auch Stromlos.
Der bootloader des ATMEGA644-chips war tatsächlich platt.
Nach erneutem flashen per Arduino Nano und mithilfe des AVRDUDESS Programms konnte ich rpiaddon.hex neu aufspielen.
Allerdings tat sich FHEM schwer mit der Einstellung der Baudrate.
Im Log immer die Meldung:
024.06.08 09:42:55 3: Setting CUL868 serial parameters to 38400,8,N,1
2024.06.08 09:43:04 1: Cannot init /dev/ttyAMA0, ignoring it (CUL868)
Ein Test mit minicom brachte auch keine lesbare Kommunikation zustande.
Erst als ich in minicom die Parameter mehrfach hin und zurück auf 38400 8N1 geschaltet habe, kam Klartext an.
minicom beendet und in FHEM nachgesehen.
Siehe da -initialized :)
Im Log:
2024.06.08 09:58:56 0: Server started with 7 defined entities (fhem.pl:28849/2024-05-07 perl:5.036000 os:linux user:fhem pid:911)
2024.06.08 10:08:38 1: PERL WARNING: Use of uninitialized value $clock in string eq at ./FHEM/00_CUL.pm line 371.
2024.06.08 10:08:38 3: set CUL868 ITClock 250
2024.06.08 10:08:47 3: Setting CUL868 serial parameters to 38400,8,N,1
2024.06.08 10:08:47 1: /dev/ttyAMA0 disconnected, waiting to reappear (CUL868)
2024.06.08 10:09:51 3: Setting CUL868 serial parameters to 38400,8,N,1
2024.06.08 10:09:51 3: CUL868: Possible commands: ABbCEeFfGhIiKkLlMmNORTtUuVWXxYZz
2024.06.08 10:09:51 2: Setting CUL868 fhtid from 1034 to 1257
2024.06.08 10:09:51 1: /dev/ttyAMA0 reappeared (CUL868)
Seltsames Verhalten...
Nachtrag: Ein reboot hat alles wieder zunichte gemacht, Kommunikation ist wieder im Eimer.
Hört sich danach an, das die Config "hinne" ist, bzw. der GFlashSpeicher dazu. Kannst Du nochmals probieren, komplett neu zu flaschen?
Schon geschehen, keine Verbesserung.
Das Board auf einen Pi3 läuft dort.
Dann müßte der Pi5 eher hinne sein.
Für mich sieht:s so aus, als würde etwas die Initialisierung der Schnittstelle stören:
Setting CUL868 serial parameters to 38400,8,N,1
Cannot init /dev/ttyAMA0, ignoring it (CUL868)
Hast Du noch USB-Scan in FHEM drin?
Hast Du mal meinen Vorschlag aus #12 verfolgt?
@Wernieman: Du meinst initialUsbCheck? Abgeschaltet bzw. auskommentiert.
@Otto: Hab ich versucht, aber ohne positiven Effekt.
Wie schon erwähnt sieht es für mich so aus, als würde die Baudrate nicht richtig gesetzt werden können.
Hab ja wie in#24 erwähnt es einmal !! hinbekommen, daß der CUL ordentlich lesbare Antworten ablieferte - ich weiß bis heute nicht wie das gelungen ist und das Verhalten reproduziert werden kann.
Man kann in minicom auch sehen, daß da etwas geantwortet wird, aber nichts in Klartext. Daher auch die Logmeldung "Cannot init /dev/ttyAMA0, ignoring it ".
Zitat von: RappaSan am 10 Juni 2024, 09:18:37Hab ja wie in#24 erwähnt es einmal !! hinbekommen, daß der CUL ordentlich lesbare Antworten ablieferte - ich weiß bis heute nicht wie das gelungen ist und das Verhalten reproduziert werden kann.
Man kann in minicom auch sehen, daß da etwas geantwortet wird, aber nichts in Klartext. Daher auch die Logmeldung "Cannot init /dev/ttyAMA0, ignoring it ".
Hallo RappaSan
Heisst das, dass sowohl FHEM als auch Minicom gleichzeitig auf /dev/ttyAMA0 zugreifen?
Ich glaube nicht, dass das sinnvoll möglich ist und sich beides in die Quere kommt.
Gruß Ralf
Tut es auch. Besser erst FHEM beenden. :)
Ansonsten schien sich minicom bei dem einmalig erfolgreichen Versuch einfach davor zu klemmen.
Daher auch die Meldungen im Log:
2024.06.08 10:08:47 1: /dev/ttyAMA0 disconnected, waiting to reappear (CUL868)
2024.06.08 10:09:51 3: Setting CUL868 serial parameters to 38400,8,N,1
2024.06.08 10:09:51 3: CUL868: Possible commands: ABbCEeFfGhIiKkLlMmNORTtUuVWXxYZz
2024.06.08 10:09:51 2: Setting CUL868 fhtid from 1034 to 1257
2024.06.08 10:09:51 1: /dev/ttyAMA0 reappeared (CUL868)
Dann Probiere doch einfach mal, den PI ohne fhem zu booten. Dann per minicom testen .. wenn das nicht geht, ist definitiv nicht fhem schuld ...
Muß mal sehen, ob ich einen Widerstand für die Brückung in meiner Wühlkiste habe. :D
Zitat von: RappaSan am 10 Juni 2024, 09:18:37@Otto: Hab ich versucht, aber ohne positiven Effekt
hast du leider nicht. Ich hatte um Ausgaben gebeten. Ohne jede Info kann doch keiner mitdenken. Ob das Board in Ordnung oder defekt ist, ist der ttyAMA0 doch völlig egal!
Wenn die Straße nicht da ist, kann man mit dem Auto nicht fahren - egal ob es intakt ist oder der Fahrer nicht weiß wie man den Motor startet.
Hab ich schon... :)
Wenn die Ausgaben anders als in dem von dir verlinkten Beitrag wären, hätte ich diese gepostet und eventuell einen Hinweis auf das Problem.
Es ist ja auch nicht so, als würde das Board (per minicom) nicht reagieren - es kommt ein Echo zurück. Ist aber nicht lesbar und sieht aus, als wäre die Baudrate oder ein anderer serieller Parameter verdreht.
Einmal hat's ja sogar hingehauen, da konnte man die erwartbaren Antworten des CUL bekommen. Und prompt ging das Ding nach Beendigung von minicom auch per FHEM auf initialized.
Nach einem reboot war aber alles wieder hin - ohne weitere Änderungen an den Konfigurationsdateien.
Hallo Allerseits,
auch bei mir läuft es nicht wie gewünscht. Raspberry PI5 mit EnOcean board auf dem GPIO - die LED ist "on" ständiges grün. OS Bookworm aktuell.
Habe mal auf die Empfehlung von Otto123 aus #12 die Mitschrift hier:
pi@rasp5bg:~ $ sudo apt-get autoremove
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
0 upgraded, 0 newly installed, 0 to remove and 18 not upgraded.
pi@rasp5bg:~ $ apt-get clean
E: Could not open lock file /var/cache/apt/archives/lock - open (13: Permission denied)
E: Unable to lock directory /var/cache/apt/archives/
E: Could not open lock file /var/lib/apt/lists/lock - open (13: Permission denied)
E: Unable to lock directory /var/lib/apt/lists/
W: Problem unlinking the file /var/cache/apt/pkgcache.bin - RemoveCaches (13: Permission denied)
W: Problem unlinking the file /var/cache/apt/srcpkgcache.bin - RemoveCaches (13: Permission denied)
pi@rasp5bg:~ $ sudo apt-get clean
pi@rasp5bg:~ $ systemctl stop serial-getty@ttyAMA0.service
==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ====
Authentication is required to stop 'serial-getty@ttyAMA0.service'.
Authenticating as: ,,, (pi)
Password:
==== AUTHENTICATION COMPLETE ====
pi@rasp5bg:~ $ sudo systemctl stop serial-getty@ttyAMA0.service
pi@rasp5bg:~ $ sudo systemctl disable serial-getty@ttyAMA0.service
Unit /etc/systemd/system/serial-getty@ttyAMA0.service is masked, ignoring.
pi@rasp5bg:~ $ sudo systemctl mask serial-getty@ttyAMA0.service
pi@rasp5bg:~ $ sudo raspi-config nonint do_rgpio 0
pi@rasp5bg:~ $ config="/boot/firmware/config.txt"
# für Raspberry Pi OS vor Bookworm
# config="/boot/config.txt"
# für Ubuntu
#config="/boot/firmware/usercfg.txt"
bash -c "cat <<EOF >> $config
enable_uart=1
dtoverlay=miniuart-bt
core_freq=250
EOF"
bash: line 1: /boot/firmware/config.txt: Permission denied
pi@rasp5bg:~ $ sudo nano /boot/firmware/config.txt
pi@rasp5bg:~ $ sudo systemctl disable hciuart
pi@rasp5bg:~ $ sudo reboot
Die Prüfung ergibt eine Abweichung und zwar für /dev/serial0 wird ttyAMA10 wird nicht ttyAMA0 gemeldet.
In Fhem die TCM_ESP3 definiert mit "ttyAMA10" bringt keine Verbesserung. Der TCM_ESP3 STATE lautet disconnected.
Die Abfrage der base ID liefert "no FD"
Hinweis: das "sudo systemctl disable hciuart" hatte ich hier gefunden https://github.com/raspberrypi/documentation/blob/develop/documentation/asciidoc/computers/configuration/uart.adoc
Unter UARTS and Device tree.
Habt Ihr noch Hinweise wie das EnOcean board aktiviert werden kann.
Gruß Bernd
Hallo Bernd,
die Modifikation der config hat ja nicht funktioniert.
Zitat/boot/firmware/config.txt: Permission denied
Damit dürfte das Overlay nicht da sein und die Schnittstelle wird nicht getauscht.
Die Verwendung AMA10 ist mMn keine Alternative.
Gruß Otto
Sind die Modifikationen eventuell als user pi ausgeführt worden?
Der darf die config.txt doch bestimmt nicht verändern und diverses anderes ebenso nicht.
Ich hab mich immer als pi angemeldet, aber danach mit
sudo su
dauerhaft auf root rechte gewechselt.
Leider kann ich - im Moment zumindest nicht - mehr mitsuchen, da ich den Pi5 nur noch bis gestern zurückgeben konnte.
Jetzt versuche ich weiter Konfigurationshinweise zu finden, bevor ich zum tüfteln nochmal ein Board ordere.
Guten Morgen,
@ Otto
das mit dem "Permission denied" hatte ich gesehen und die config.txt mittels sudo nano geändert. Z.Z. sieht diese Datei - config.txt so aus:
GNU nano 7.2 /boot/firmware/config.txt *
# For more options and information see
# http://rptl.io/configtxt
# Some settings may impact device functionality. See link above for details
# Uncomment some or all of these to enable the optional hardware interfaces
#dtparam=i2c_arm=on
#dtparam=i2s=on
dtparam=spi=on
dtparam=krnbt=off
# von https://www.raspberrypi.com/documentation/computers/configuration.html#secondary-uart
# Enable audio (loads snd_bcm2835)
dtparam=audio=on
# Additional overlays and parameters are documented
# /boot/firmware/overlays/README
# Automatically load overlays for detected cameras
camera_auto_detect=1
# Automatically load overlays for detected DSI displays
display_auto_detect=1
# Automatically load initramfs files, if found
auto_initramfs=1
# Enable DRM VC4 V3D driver
dtoverlay=vc4-kms-v3d
max_framebuffers=2
# Don't have the firmware create an initial video= setting in cmdline.txt.
# Use the kernel's default instead.
disable_fw_kms_setup=1
# Run in 64-bit mode
arm_64bit=1
# Disable compensation for displays with overscan
disable_overscan=1
# Run as fast as firmware / board allows
arm_boost=1
[cm4]
# Enable host mode on the 2711 built-in XHCI USB controller.
# This line should be removed if the legacy DWC2 controller is required
# (e.g. for USB device mode) or if USB support is not required.
otg_mode=1
[all]
dtoverlay=uart0
dtoverlay=uart1
dtoverlay=disable-bt
#dtparam=uart0=on
enable_uart=1
core_freq=250
Das Ergebnis ist weiterhin kein connected
Internals:
BaseID 00000000
DEF ESP3 /dev/ttyAMA0@57600
DeviceName /dev/ttyAMA0@57600
FUUID 6651c70a-f33f-5a99-4904-e2d9eeab754f8d3b
FVERSION 00_TCM.pm:0.277860/2023-07-21
LastID 00000000
MODEL ESP3
NAME TCM_ESP3_0
NOTIFYDEV global
NR 47
NTFY_ORDER 45-TCM_ESP3_0
PARTIAL
STATE disconnected
TYPE TCM
READINGS:
2024-06-15 13:13:07 state disconnected
helper:
Attributes:
baseID FFA12C80
room System
sendInterval 0
smartAckMailboxMax 0
Wie werde ich der Lösung näher kommen? Habt Ihr eine Idee?
Gruß
Bernd
Zitat von: Onca am 15 Juni 2024, 13:24:44dtoverlay=disable-bt
das tauscht nicht und damit hat man nach meinem Verständnis keine AMA0:
https://www.raspberrypi.com/documentation/computers/configuration.html#primary-and-secondary-uart
und die UART10 ist am debug Connector. :o
Edit: Wenn ich den richtig verstehe: https://www.raspberrypi.com/documentation/computers/configuration.html#raspberry-pi-5
braucht man beim PI5 die Tauscherei nicht.
Einzig diese Zeile in der config (alles andere braucht man nicht!) sollte die UART0 am GPIO Header aktivieren.
dtoverlay=uart0was die Folge dtoverlay=uart0 dtoverlay=uart1 bewirkt weiß ich nicht, wird dann die PIN Belegung überschrieben?
Zitat von: Onca am 15 Juni 2024, 13:24:44Das Ergebnis ist weiterhin kein connected
fang doch weiter "unten" an: ;)
ls -lha /dev/ttyAMA*
Hallo Otto,
der Test entsprechend #15 liefert dieses Ergebnis und ist damit für /dev/ttyAMA0 ok
pi@rasp5bg:~ $ python3 serial_uart_test_TxRx.py
Serial port /dev/ttyAMA10 ready for test :
Sended 20 byte
Received incorrect data: b'' on serial part /dev/ttyAMA10 loopback
Serial port /dev/ttyAMA0 ready for test :
Sended 20 byte
Received 20 bytes. Port /dev/ttyAMA0 is OK !
Serial port /dev/ttyS0 ready for test :
Sended 20 byte
Received incorrect data: b'' on serial part /dev/ttyS0 loopback
Error on /dev/ttyS1
Der Test mit ls -lha /dev/ttyAMA* liefert:
pi@rasp5bg:~ $ ls -lha /dev/ttyAMA*
crw-rw---- 1 root dialout 204, 64 Jun 16 18:52 /dev/ttyAMA0
crw-rw---- 1 root dialout 204, 74 Jun 16 18:52 /dev/ttyAMA10
pi@rasp5bg:~ $
Jetzt das Modul wieder aufgesteckt und erneut ls -lha /dev/ttyAMA* liefert wie zuvor:
pi@rasp5bg:~ $ ls -lha /dev/ttyAMA*
crw-rw---- 1 root dialout 204, 64 Jun 16 18:54 /dev/ttyAMA0
crw-rw---- 1 root dialout 204, 74 Jun 16 18:51 /dev/ttyAMA10
pi@rasp5bg:~ $
Das listing der TCM_ESP3 ist unverändert:
Internals:
BaseID 00000000
DEF ESP3 /dev/ttyAMA0@57600
DeviceName /dev/ttyAMA0@57600
FUUID 6651c70a-f33f-5a99-4904-e2d9eeab754f8d3b
FVERSION 00_TCM.pm:0.277860/2023-07-21
LastID 00000000
MODEL ESP3
NAME TCM_ESP3_0
NOTIFYDEV global
NR 47
NTFY_ORDER 45-TCM_ESP3_0
PARTIAL
STATE disconnected
TYPE TCM
READINGS:
2024-06-16 18:57:32 state disconnected
helper:
telegramSentTimeLast 1718557246.09208
awaitCmdResp:
1
Attributes:
baseID FFA12C80
room System
sendInterval 15
smartAckMailboxMax 1
Wir wissen jetzt das die Schnittstelle entsprechend dem Python Programm funktioniert. DAs GPIO board habe ich auf einem anderen Raspberry getestet, voll funktionsfähig, die Signale weidengesendet und empfangen.
Kann es an einem Rechteproblem liegen.? Das Fhem ist über profanier aufgesetzt a, Raspberry 5?
Vor dem Test habe ich die config.txt nach Deiner Vorgabe angepasst. Sie sieht jetzt so aus:
GNU nano 7.2 /boot/firmware/config.txt
# For more options and information see
# http://rptl.io/configtxt
# Some settings may impact device functionality. See link above for details
# Uncomment some or all of these to enable the optional hardware interfaces
#dtparam=i2c_arm=on
#dtparam=i2s=on
dtparam=spi=on
dtparam=krnbt=off
# von https://www.raspberrypi.com/documentation/computers/configuration.html#secondary-uart
# Enable audio (loads snd_bcm2835)
dtparam=audio=on
# Additional overlays and parameters are documented
# /boot/firmware/overlays/README
# Automatically load overlays for detected cameras
camera_auto_detect=1
# Automatically load overlays for detected DSI displays
display_auto_detect=1
# Automatically load initramfs files, if found
auto_initramfs=1
# Enable DRM VC4 V3D driver
dtoverlay=vc4-kms-v3d
max_framebuffers=2
# Don't have the firmware create an initial video= setting in cmdline.txt.
# Use the kernel's default instead.
disable_fw_kms_setup=1
# Run in 64-bit mode
arm_64bit=1
# Disable compensation for displays with overscan
disable_overscan=1
# Run as fast as firmware / board allows
arm_boost=1
[cm4]
# Enable host mode on the 2711 built-in XHCI USB controller.
# This line should be removed if the legacy DWC2 controller is required
# (e.g. for USB device mode) or if USB support is not required.
otg_mode=1
[all]
dtoverlay=uart0
#dtoverlay=uart1
#dtoverlay=disable-bt
#dtparam=uart0=on
enable_uart=1
core_freq=250
Gibt es noch eine Idee was die Funktion ermöglicht?
Gruß Bernd
Das deckt sich ziemlich gut mit meinen Erfahrungen.
Es kommt ein Echo zurück, aber leider nichts verwertbares.
Wie schon beschrieben hab ich EIN!!! einziges Mal eine korrekte Kommunikation hinbekommen (warum's da funktioniert hat - keine Ahnung), nach einem Neustart ohne jegliche weitere Änderung war alles wieder hin.
@Onca die Ausgaben sehen eigentlich gut aus, die Kommunikation mit sich selbst funktioniert ja offenbar.
intialUsbCheck hast Du deaktiviert - vor dem FHEM Neustart?
Otto den initilUsbCheck habe ich zugefügt und deaktiviert. Das Ergebnis bleibt unverändert.
Im .log des portainer ist mir allerdings aufgefallen:
2024.06.17 14:05:06.197 1: Including fhem.cfg
2024.06.17 14:05:06.349 3: WEB: port 8083 opened
2024.06.17 14:05:06.376 2: eventTypes: loaded 335 lines from ./log/eventTypes.txt
2024.06.17 14:05:06.556 3: AptToDate (fhemServerApt) - defined
2024.06.17 14:05:06.880 3: telnetPort: port 7072 opened
2024.06.17 14:05:06.890 3: Opening TCM_ESP3_0 device /dev/ttyAMA0
2024.06.17 14:05:06.904 1: TCM_ESP3_0: Can't open /dev/ttyAMA0: No such file or directory
2024.06.17 14:05:07.287 2: EnOcean Cryptographic functions are not available.
2024.06.17 14:05:07.287 2: EnOcean XML functions available.
2024.06.17 14:05:07.289 1: Including ./log/fhem.save
2024.06.17 14:05:07.297 3: From the FHEM_GLOBALATTR environment: attr global logfile ./log/fhem-%Y-%m-%d.log
2024.06.17 14:05:07.297 3: From the FHEM_GLOBALATTR environment: attr global pidfilename ./log/fhem.pid
2024.06.17 14:05:07.298 3: From the FHEM_GLOBALATTR environment: attr global updateInBackground 1
2024.06.17 14:05:07.298 3: From the FHEM_GLOBALATTR environment: attr global nofork 0
Can't open ttyAMA0 no such file or directory
obwohl es den Eintrag im Verzeichnis /dev gibt:
crw-rw---- 1 root dialout 204, 64 Jun 17 14:04 ttyAMA0
crw-rw---- 1 root dialout 204, 74 Jun 17 14:04 ttyAMA10
Da ist noch einen Anpassung offen. Welche?
Gruß Bernd
Zitat von: Onca am 17 Juni 2024, 14:23:10Im .log des portainer ist mir allerdings aufgefallen:
Du arbeitest mit Docker und hast vergessen das Device zu mappen (und es zu erwähnen)? ::)
z.B. in der docker-compose.yml
devices:
- /dev/ttyAMA0
Sorry Otto,
ich war mir sicher das geschrieben zu haben mit docker und portainer. War aber in einem anderen post.
Inzwischen habe ich ehem ohne docker neu installiert auf dem Raspberry 5 und siehe da, es läuft. Im portainer ist für fhem/fhem latest nur das OS bullseye erwähnt und nicht bookworm, deshalb mache ich erstmal ohne docker weiter.
Danke für die Unterstützung
Bernd
Ich bin etwas verwirrt/ratlos: :o
Worauf läuft denn nun dein FHEM?
Auf einem Docker container?
Auf einem portainer(was immer das auch ist)?
Oder wie hier angefangen auf einem Pi5?
Es geht ja hier um ein mögliches Problem, die serielle Schnittstelle auf einem Pi5 wie bei den Vorgänger-Boards zu aktivieren.
Zitat von: RappaSan am 17 Juni 2024, 19:40:33Auf einem portainer(was immer das auch ist)?
das ist ein Tool ( meist auch docker Container) zur Verwaltung der Docker Container.
Auf seinem PI5 nach meinem letzten Tipp (#40) läuft die Schnittstelle offenbar.
Für den fhem Container hatte er offenbar einfach vergessen die ttyAMA0 zu mappen, deswegen lief die Schnittstelle mit python , aber das Device im fhem-Docker nicht. (#41)
Zitat von: RappaSan am 17 Juni 2024, 19:40:33Es geht ja hier um ein mögliches Problem, die serielle Schnittstelle auf einem Pi5 wie bei den Vorgänger-Boards zu aktivieren.
Für mich sieht es jetzt so aus, als ob man beim PI5 lediglich
dtoverlay=uart0in der config "/boot/firmware/config.txt" ergänzen muss ;D
Jetzt fehlt nur noch die Wiederholung :)
Quod erat demonstrandum.
Das wäre ja prima, wenn's nur diese Ergänzung braucht.
Ich werde mir bei Gelegenheit noch mal einen Pi5 bestellen und dann probiere ich das aus.
Du hast es also im Portainer laufen, nicht nativ auf dem Rechner? Hattest Du minicom auch im Portainer oder nativ laufen? Was sagt denn das kern.log?
Meinst du mich? :o
Wie kommst du darauf? Ich wußte ja noch nicht mal, was ein portainer ist.
Ich hatte einen Pi5 nativ laufen mit Rpi bookworm, neueste Version (alle updates).