Hallo,
ich knüpfe mit diesem Thema an ein voriges:
https://forum.fhem.de/index.php?topic=141010
Dabei ging es um den HMLAN-Funk-USB-Stick, der
vermutlich defekt ist.
Da es den nicht mehr gibt, habe ich das
Funkmodul HM-MOD-RPI-PCB bestellt,
das direkt auf den Raspberry Pi aufgesteckt wird.
Die Einrichtung selbst scheint schon nicht
ganz einfach zu sein:
https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi
Bevor ich damit anfange, ist meine Frage die:
der bisherige Stick ist ja als HMLAN definiert.
Wenn ich jetzt das neue Gerät als UART-Modul
konfiguriere und ans laufen kriege,
kann ich dann alle bisher schon angelernten
Komponenten ohne neues Anlernen nutzen?
Kann ich also einfach das HMLAN (bisherige
Stick-Konfiguration) auskommentieren
und dann das hier konfigurieren:
https://wiki.fhem.de/wiki/HMUARTLGW
??
Falls jemand das schonmal gemacht hat,
oder sich gut auskennt,
wäre ich übe einen Tipp dazu dankbar,
bevor ich mir das System zerschieße.
Danke!
Hi,
Du definierst eine VCCU (https://wiki.fhem.de/wiki/Virtueller_Controller_VCCU), gibst dieser die Hmid deines bisherigen IO und definierst den neuen IO neu als zusätzlichen IO der VCCU. Damit gehts einfach weiter.
VCCU ist sowieso eine gute Maßnahme.
Frag mich jetzt nicht wie bei einem seit 5 Jahre totem Ubuntu die UART aktiviert wird, aber ich hoffe es steht richtig im Wiki ;)
Gruß Otto
Habe UART aktiviert:
https://wiki.fhem.de/wiki/Raspberry_Pi#Verwendung_UART_f%C3%BCr_Zusatzmodule
das scheint zu funktionieren.
Die VCCU hat auch anscheinend funktioniert.
Ich kriege diese Ausgabe:
Ich kriege ein
device /dev/ttyAMA0
angezeigt mti Name myHmUART
und:
STATE opened
TYPE HMUARTLGW
XmitOpen 0
model HM-MOD-UART
owner_CCU vccuMain
Das sieht für doch gut aus !??
Die Rolladen haben anscheinend selbständig
angepaßt auf :
IODev myHmUART
Leider habe ich immer noch einen IOErr auf den Devices
und im Log:
2025.03.13 23:17:23 1: usb create starting
2025.03.13 23:17:24 1: usb create end
2025.03.13 23:17:24 0: Featurelevel: 6
2025.03.13 23:17:24 0: Server started with 68 defined entities (fhem.pl:23205/2020-11-21 perl:5.022001 os:linux user:fhem pid:1732)
2025.03.13 23:17:24 1: /dev/ttyAMA0 disconnected, waiting to reappear (myHmUART)
2025.03.13 23:17:28 1: HMUARTLGW myHmUART did not respond for the 1. time, resending
2025.03.13 23:17:31 1: /dev/ttyAMA0 reappeared (myHmUART)
2025.03.13 23:17:35 1: HMUARTLGW myHmUART did not respond for the 1. time, resending
2025.03.13 23:17:38 1: HMUARTLGW myHmUART did not respond for the 2. time, resending
2025.03.13 23:17:41 1: HMUARTLGW myHmUART did not respond for the 3. time, resending
2025.03.13 23:17:44 1: HMUARTLGW myHmUART did not respond after all, reopening
2025.03.13 23:17:44 1: /dev/ttyAMA0 reappeared (myHmUART)
2025.03.13 23:17:48 1: HMUARTLGW myHmUART did not respond for the 1. time, resending
2025.03.13 23:17:50 1: /dev/ttyAMA0 disconnected, waiting to reappear (myHmUART)
Vielleicht muss ich ja noch irgendwas aktivieren.
Ich machen mal morgen weiter!
attr initialUsbCheck disable 1Danach mindestens Neustart des Systems, manchmal muss man ausschalten das Modul abstecken, ein paar Minuten warten, Modul aufstecken und wieder einschalten.
Habe ich gemacht.
Habe auch mal das probiet:
dmesg | grep ttyAMA0
Das ergibt:
[ 0.000000] Kernel command line: 8250.nr_uarts=1 dma.dmachans=0x7f35 bcm2708_fb.fbwidth=656 bcm2708_fb.fbheight=416 bcm2709.boardrev=0xa02082 bcm2709.serial=0x7fb3b21 smsc95xx.macaddr=B8:27:EB:FB:3B:21 bcm2708_fb.fbswap=1 bcm2709.uart_clock=48000000 vc_mem.mem_base=0x3dc00000 vc_mem.mem_size=0x3f000000 dwc_otg.lpm_enable=0 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait
[ 0.081904] bcm2709: Mini UART enabled
[ 0.082189] Serial: AMBA PL011 UART driver
[ 0.082343] uart-pl011 3f201000.uart: could not find pctldev for node /soc/gpio@7e200000/uart0_pins, deferring probe
[ 0.283223] 3f215040.uart: ttyS0 at MMIO 0x3f215040 (irq = 59, base_baud = 31250000) is a 16550
[ 0.983350] 3f201000.uart: ttyAMA0 at MMIO 0x3f201000 (irq = 87, base_baud = 0) is a PL011 rev2
[ 6.225212] uart-pl011 3f201000.uart: no DMA platform data
hast Du mal die Ausgaben geprüft?
ls -l /dev/ttyAMA0
ls -l /dev/serial*
Ja:
ls -l /dev/ttyAMA0
gibt :
crw-rw---- 1 root dialout 204, 64 Mär 14 23:18 /dev/ttyAMA0
ls -l /dev/serial*
gibt:
lrwxrwxrwx 1 root root 5 Apr 2 2021 /dev/serial0 -> ttyS0
lrwxrwxrwx 1 root root 7 Apr 2 2021 /dev/serial1 -> ttyAMA0
Bei:
dmesg | grep ttyAMA0
stand übrigens u.a:
base_baud = 0
Muss ich die baud_rate noch irgendwo vielleicht einstellen?
Nein musst Du nicht.
Zeig mal ein list myHmUART
Ich habe eben versucht, die Funkmodul zu flashen,
erst über die fhem-Oberfläche, da kam keine Rückmeldung
nach absenden des update-Befehls:
set myHmUART updateCoPro /opt/fhem/FHEM/firmware/coprocessor_update.eq3
(wie hier
https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi
beschrieben).
Dann habe ich das manuelle Update über die console probiert:
./flash-hmmoduart -U /dev/ttyAMA0 coprocessor_update.eq3
Da kommt dann:
M-MOD-UART flasher version 0.103-git
Reading firmware from coprocessor_update.eq3...
Firmware with 43 blocks successfully read.
Initializing HM-MOD-UART...
Communication with the module timed out, is the serial port configured correctly?
root@raspi-fhem:/home/lxuser/hmcfgusb# ./flash-hmmoduart -U /dev/ttyAMA0 coprocessor_update.eq3
HM-MOD-UART flasher version 0.103-git
Reading firmware from coprocessor_update.eq3...
Firmware with 43 blocks successfully read.
Initializing HM-MOD-UART...
Communication with the module timed out, is the serial port configured correctly?
Zitat von: fgam am 14 März 2025, 23:35:56Ich habe eben versucht, die Funkmodul zu flashen,
das macht keinen Sinn solange das Modul nicht läuft.
Was ich nicht ganz verstehe:
systemctl status ttyAMA0.service
gibt:
ttyAMA0.service
Loaded: not-found (Reason: No such file or directory)
Active: inactive (dead)
mir fällt gerade ein: Ich meine wir hatten das schonmal: Ubuntu auf dem Pi und da läuft das Modul über die AMA0 Schnittstellen nicht. Der User hat dann Raspberry Os genommen und alles lief. Irgendein Dienst funkt bei Ubuntu rhythmisch dazwischen war damals meine Vermutung.
Allerdings beim alten Ubuntu lief es https://forum.fhem.de/index.php?topic=111341.0
ZitatttyAMA0.service
sowas gibt es bei mir gar nicht.
Interessant.
Ich habe mal alle services gesucht:
ccounts-daemon.service loaded active running Accounts Service
apache2.service loaded active running LSB: Apache2 web server
avahi-daemon.service loaded active running Avahi mDNS/DNS-SD Stack
avahi-dnsconfd.service loaded active running Avahi DNS Configuration Daemon
cron.service loaded active running Regular background program processing daemon
dbus.service loaded active running D-Bus System Message Bus
fhem.service loaded active running LSB: FHEM server
getty@tty1.service loaded active running Getty on tty1
lightdm.service loaded active running Light Display Manager
ModemManager.service loaded active running Modem Manager
NetworkManager.service loaded active running Network Manager
ondemand.service loaded active running LSB: Set the CPU Frequency Scaling governor to "ondemand"
polkitd.service loaded active running Authenticate and Authorize Users to Run Privileged Tasks
rng-tools.service loaded active running rng-tools.service
rsyslog.service loaded active running System Logging Service
rtkit-daemon.service loaded active running RealtimeKit Scheduling Policy Service
ssh@0-192.168.178.24:22-192.168.178.20:59154.service loaded active running OpenBSD Secure Shell server per-connection daemon (192.168.178.20:59154)
systemd-fsckd.service loaded active running File System Check Daemon to report status
systemd-hostnamed.service loaded active running Hostname Service
systemd-journald.service loaded active running Journal Service
systemd-logind.service loaded active running Login Service
systemd-timesyncd.service loaded active running Network Time Synchronization
systemd-udevd.service loaded active running udev Kernel Device Manager
triggerhappy.service loaded active running LSB: triggerhappy hotkey daemon
udisks2.service loaded active running Disk Manager
unattended-upgrades.service loaded active running Unattended Upgrades Shutdown
upower.service loaded active running Daemon for power management
user@1000.service loaded active running User Manager for UID 1000
wpa_supplicant.service loaded active running WPA supplicant
und die Befehle ausgeführt:
systemctl stop serial-getty@ttyAMA0.service
systemctl disable serial-getty@ttyAMA0.service
systemctl mask serial-getty@ttyAMA0.service
Der Service getty@tty1.service scheint davon
aber unbeeindruckt zu sein! Er zeigt weiter
getty@tty1.service loaded active running Getty on tty1
sudo service getty@tty1.service status
zeigt
● getty@tty1.service.service - Getty on tty1.service
Loaded: loaded (/lib/systemd/system/getty@.service; enabled; vendor preset: enabled)
Active: inactive (dead)
Docs: man:agetty(8)
man:systemd-getty-generator(8)
http://0pointer.de/blog/projects/serial-console.html
ttyAMA0.service
gibt es bei mir auch nicht.
Ich hatte gelesen irgendwo,
dass ich dort vielleiht explizit die
Baudrate angeben könnte.
Vielleicht könnte ich die Datei anlegen?
Wozu? Man braucht keinen Dienst für die Schnittstelle - ganz im Gegenteil, die Schnittstelle wird exklusiv verwendet.
Das Du nach der Baudrate suchst ist die falsche Fährte. Die Angabe ist bei mir bei dmesg genauso.
Zitat von: Otto123 am 14 März 2025, 23:32:15Zeig mal ein list myHmUART
list myHmUART
gibt
Save config
Bib
CUL_HM
Esszi
Kueche
Unsorted
Wozi
fewo_SZ
fewo_Wozi
icoEverything Everything
Logfile
Commandref
Remote doc
Edit files
Select style
Event monitor
Internals:
CFGFN /opt/fhem/rolladen.cfg
CNT 1
Clients :CUL_HM:
DEF /dev/ttyAMA0
DevState 1
DevType UART
DeviceName /dev/ttyAMA0@115200
FD 5
FUUID 67d467d1-f33f-e901-dd2b-b36f974b4950ce43
LastOpen 1742068220.73415
NAME myHmUART
NOTIFYDEV global
NR 48
NTFY_ORDER 50-myHmUART
PARTIAL 040e0401009e01
STATE opened
TYPE HMUARTLGW
XmitOpen 0
model HM-MOD-UART
Helper:
AckPending:
1:
cmd 00
dst 0
frame FD00030001009E03
resend 3
time 1742068221.73653
LastSendLen:
3
Log:
IDs:
MatchList:
1:CUL_HM ^A......................
PeerQueue:
HASH(0xfb15a8)
HASH(0x2405728)
HASH(0x240b3a0)
HASH(0x2414058)
HASH(0x2416460)
HASH(0x2416b50)
HASH(0x241a350)
HASH(0x241aa58)
HASH(0x241c850)
HASH(0x241cf88)
HASH(0x241e570)
HASH(0x241eca8)
HASH(0x2422230)
HASH(0x2422968)
HASH(0x2423148)
HASH(0x24259b8)
HASH(0x24286a8)
HASH(0x242eae0)
HASH(0x1ac1760)
HASH(0x227cee0)
HASH(0x2360d20)
HASH(0x23610e0)
HASH(0x2360840)
HASH(0x21678a8)
HASH(0x21830b8)
HASH(0x21830d0)
HASH(0x21827e8)
HASH(0x21825a8)
HASH(0x232d938)
HASH(0x235bc28)
HASH(0x22d2ac8)
HASH(0x22df130)
HASH(0x21824a0)
HASH(0x21683d0)
HASH(0x21795b8)
HASH(0x1ffa2d0)
Peers:
0589F6 pending
3CBCFC pending
3CBE05 pending
469587 pending
46A553 pending
46FC75 pending
47A5D5 pending
4915C1 pending
4915E9 pending
4915FF pending
491608 pending
49164F pending
4934D2 pending
493570 pending
49DA4B pending
503383 pending
52935C pending
529493 pending
READINGS:
2025-03-15 06:43:44 D-type HM-MOD-UART
2025-03-15 20:50:21 cond init
2025-03-15 06:43:44 loadLvl suspended
2025-03-15 20:50:20 state opened
helper:
Attributes:
hmId 434343
Das Modul hat noch gar nicht mit FHEM gesprochen. Das bedeutet:
- das Modul funktioniert nicht (falsch zusammen gebaut?)
- die Schnittstelle ist nicht richtig aktiviert.
Wenn zwei Dienste um die Schnittstelle "kämpfen" würden käme eine kurze Kommunikation zustande und es gäbe ein paar Readings.
o.k., danke für die Analyse
Bei der Schnittsetlle hatten wir das ja geprüft:
ls -l /dev/ttyAMA0
gibt :
crw-rw---- 1 root dialout 204, 64 Mär 14 23:18 /dev/ttyAMA0
ls -l /dev/serial*
gibt:
lrwxrwxrwx 1 root root 5 Apr 2 2021 /dev/serial0 -> ttyS0
lrwxrwxrwx 1 root root 7 Apr 2 2021 /dev/serial1 -> ttyAMA0
und gettyp1 ist noch aktiv, obwohl der service gestoppt war.
Ich weiß nicht, ob das ein Problem ist, jedenfalls sollte
es nach Anleitung ausgeschaltet werden.
Kann ich noch mehr herausfinden, ob de Schnittstelle
richtig konfiguriert ist?
Eine Sache ist mir in der Konfiguration aufgefallen:
Da steht:
# serielle Schnittstelle aktivieren und mit BT Schnittstelle tauschen
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"
Ich habe die Einträge in /boot/config.txt gemacht,
weil es die Datei gab.
Nach Anleitung wäre
# für Ubuntu
#config="/boot/firmware/usercfg.txt"
zuständig, die gibt es aber bei mir nicht,
das Verzeichnis /firmware existiert gar nicht.
Die Kontakte und Lötstellen habe ich geprüft.
Auch gecheckt, dass GPIO aktiviert ist und die serielle Schnittstelle.
Zitat von: fgam am 16 März 2025, 08:57:52und gettyp1 ist noch aktiv,
Der einzige Dienst der hier meiner Erfahrung nach eine Rolle spielen kann ist: serial-getty@ttyAMA0.service
Es gibt jede Menge Dienste die zwar ähnlich heißen, aber für irgendwas anderes zuständig sind. Der getty@tty1.service ist bei mir auch aktiv ;)
die Lage und der Name der config.txt ist leider abhängig von Zeit und Raum :) und wird in den Distributionen immer gern geändert.
Es sieht so aus, als ist die Schnittstelle richtig konfiguriert. Dann kann es nur am Modul liegen, keine Quatsch ich hatte es hier im Forum mehr als einmal, dass aus Versehen der Zusammenbau beider Hälften des Moduls spiegelverkehrt passiert war. Kannst Du bitte die Bilder im Wiki nochmal mit deinem Modul vergleichen?
https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi
sudo service serial-getty@ttyAMA0.service status
[sudo] password for lxuser:
● serial-getty@ttyAMA0.service.service - Serial Getty on ttyAMA0.service
Loaded: loaded (/lib/systemd/system/serial-getty@.service; disabled; vendor p
Active: inactive (dead)
Docs: man:agetty(8)
man:systemd-getty-generator(8)
http://0pointer.de/blog/projects/serial-console.html
Das Modul habe ich nochmal geprüft.
Die Lötstellen sind alle soweit o.k.
Das Modul ist gemäß Foto richtig aufgesteckt.
Zwischen zwei Pins gibt es einen Durchgang,
da kann es aber vielleicht auch sein, dass die
über die Platine verbunden sind. Alle anderen
Pins haben keine Verbindung untereinander.
Ich habe es nach diesem Video gemacht:
https://www.youtube.com/watch?v=xtzXsvOLa_Y
Auch habe ich den Ferrit-Ring in die Stromversorgung
eingebracht.
Zwischenzeitlich hatte ich auch das Netzteil
nochmal ausgetauscht, um Schwankungen auszuschließen.
Das sollte alles stabil sein.
Da bin ich ratlos ...
Du kannst die ttyAMA0 im loopback testen, also einfach Modul abziehen, eine Verbindung zwischen GPIO14 und GPIO15 - Anschluss 8 und 10 (nebeneinander) schaffen, z.B. mit eine kurzen Kabel oder mit einem Jumper wie man ihn (früher) auf Motherboards findet.
Man kann das dann testen, z.B. hier https://forum.fhem.de/index.php?topic=138389.msg1314488#msg1314488
Das finde ich grossartig, vielen Dank!
Habe auch einen Widerstand (680 Ohm) dazwischengeschaltet.
python3 serial_uart-test_TxRx.py
gibt
Serial port /dev/ttyAMA0 ready for test :
loopback: b''
Received incorrect data: b'' on serial part /dev/ttyAMA0 loopback
Serial port /dev/ttyS0 ready for test :
loopback: b'Test serial port ...'
Received 20 bytes. Port /dev/ttyS0 is OK !
Error on /dev/ttyS1
Habe dies probierT:
sudo modprobe serial
Ergebnis:
modprobe: FATAL: Module serial not found in directory /lib/modules/4.4.38-v7+
sudo systemctl start serial-getty@ttyAMA0.service
gibt:
Failed to start serial-getty@ttyAMA0.service: Unit serial-getty@ttyAMA0.service is masked.
nach unmask und enable und start kriege ich:
sudo systemctl status serial-getty@ttyAMA0.service
● serial-getty@ttyAMA0.service - Serial Getty on ttyAMA0
Loaded: loaded (/lib/systemd/system/serial-getty@.service; enabled; vendor preset: enabled)
Active: active (running) since So 2025-03-16 15:13:15 CET; 4min 28s ago
Docs: man:agetty(8)
man:systemd-getty-generator(8)
http://0pointer.de/blog/projects/serial-console.html
Main PID: 3049 (agetty)
CGroup: /system.slice/system-serial\x2dgetty.slice/serial-getty@ttyAMA0.service
└─3049 /sbin/agetty --keep-baud 115200 38400 9600 ttyAMA0 vt220
Mär 16 15:13:15 raspi-fhem systemd[1]: Started Serial Getty on ttyAMA0.
Mär 16 15:16:10 raspi-fhem systemd[1]: Started Serial Getty on ttyAMA0.
Beim python-Test kommt dann:
Error on /dev/ttyAMA10
Error on /dev/ttyAMA0
Serial port /dev/ttyS0 ready for test :
loopback: b'Test serial port ...'
Received 20 bytes. Port /dev/ttyS0 is OK !
Error on /dev/ttyS1
Bisher habe ich mich wohl strikt an:
https://wiki.fhem.de/wiki/Raspberry_Pi#Verwendung_UART_f%C3%BCr_Zusatzmodule
gehalten.
Jetzt habe ich mal
dtoverlay=uart0,txd0_pin=14,rxd0_pin=15
statt
dtoverlay=miniuart-bt
probiert.
Das hat aber keinen Effekt.
Ich habe mal einen anderen Raspberry Pi (Version 4) genommen
und die SD-Karte da rein gesteckt.
uname -r
4.4.38-v7+
Dann:
sudo apt-get install raspberrypi-kernel-headers
Das ist durchgelaufen, bei Wiederholung kommt:
-> raspberrypi-kernel-headers ist schon die neueste Version (1.20161215-1~xenial1.0).
Und jetzt gibt
list myHmUART
das:
Internals:
AssignedPeerCnt 18
CFGFN /opt/fhem/rolladen.cfg
CNT 232
Clients :CUL_HM:
DEF /dev/ttyAMA0
DEVCNT 231
DevState 100
DevType UART
DeviceName /dev/ttyAMA0@115200
FD 5
FUUID 67d467d1-f33f-e901-dd2b-b36f974b4950ce43
LastOpen 1742153881.40088
NAME myHmUART
NOTIFYDEV global
NR 48
NTFY_ORDER 50-myHmUART
PARTIAL
RAWMSG 04024B
RSSI -41
STATE opened
TYPE HMUARTLGW
XmitOpen 1
model HM-MOD-UART
msgLoadCurrent 38
msgLoadHistory 6/32/-/-/-/-/-/-/-/-/-/-
msgLoadHistoryAbs 38/32/0/-/-/-/-/-/-/-/-/-/-
owner 434343
Helper:
CreditTimer 25
FW 66049
Initialized 1
SendCnt 66
AckPending:
232:
cmd 020000013AB00143434347A5D5010E
dst 1
frame FD001101E8020000013AB00143434347A5D5010E1944
time 1742154486.45331
LastSendLen:
3
17
Log:
IDs:
PendingCMD:
HASH(0x2689518)
RoundTrip:
Delay 0.00295186042785645
loadLvl:
lastHistory 1742154483.89305
MatchList:
1:CUL_HM ^A......................
Peers:
0589F6 +0589F6,00,00,00
3CBCFC +3CBCFC,00,00,00
3CBE05 +3CBE05,00,00,00
469587 +469587,00,00,00
46A553 +46A553,00,00,00
46FC75 +46FC75,00,00,00
47A5D5 +47A5D5,00,00,00
4915C1 +4915C1,00,00,00
4915E9 +4915E9,00,00,00
4915FF +4915FF,00,00,00
491608 +491608,00,00,00
49164F +49164F,00,00,00
4934D2 +4934D2,00,00,00
493570 +493570,00,00,00
49DA4B +49DA4B,00,00,00
503383 +503383,00,00,00
52935C +52935C,00,00,00
529493 +529493,00,00,00
READINGS:
2025-03-16 20:38:03 D-HMIdAssigned 434343
2025-03-16 20:38:03 D-HMIdOriginal 7A3BFA
2025-03-16 20:38:03 D-firmware 1.2.1 (outdated)
2025-03-16 20:38:03 D-serialNr TEQ2822193
2025-03-16 20:37:59 D-type HM-MOD-UART
2025-03-16 20:38:03 cond ok
2025-03-16 20:48:05 load 38
2025-03-16 20:38:03 loadLvl low
2025-03-16 20:38:01 state opened
helper:
Attributes:
hmId 434343
Jetzt sagen die Rolladen-Aktoren nicht mehr
IOErr
sondern
MISSING ACK
korrekt wäre die Antwort:
ZitatSerial port /dev/ttyAMA0 ready for test :
Sended 20 byte
Received 20 bytes. Port /dev/ttyAMA0 is OK !
Ergo Deine Schnittstelle geht nicht / ist nicht korrekt konfiguriert / wird irgendwie gestört.
Deine weiteren Maßnahmen sind mMn nicht sinnvoll, bzw. liefern zu erwartende Ergebnisse. Den serial-getty@ttyAMA0.service haben wir ja extra deaktiviert. Wenn der läuft ist die ttyAM0 nicht zu gebrauchen.
Zitat von: fgam am 16 März 2025, 21:03:382025-03-16 20:38:03 D-firmware 1.2.1 (outdated)
Jetzt läuft die Schnittstelle und Modul :)
Jetzt kannst Du Firmware update machen ;) bitte wie im Wiki beschrieben in FHEM
>>Jetzt läuft die Schnittstelle und Modul
Wow, danke für die gute Nachricht ;-)
Habe:
set myHmUART updateCoPro /opt/fhem/FHEM/firmware/coprocessor_update.eq3
gemacht.
Da kam keine Rückmeldung,
aber jetzt sagt das list nicht mehr:
D-firmware 1.2.1 (outdated)
sondern
D-firmware 1.4.1
Das scheint also funktioniert zu haben.
Das Missing-ACK
ist noch immer da (auch nach stromlos schalten und reboot)
und entsprechend lassen sich die Rolladen auch noch nicht wieder schalten.
Interessanterweise ist es umgekehrt so:
wenn ich die Rolladen manuell schalte, reagiert fhem und zeigt den
Status an....
Dazu müssen die hmid des IO mit der hmid des alten IO übereinstimmen und das IODev entsprechend geändert werden.
Eigentlich macht man das über eine VCCU aber Du kannst auch einfach das attr bei den Devices ändern.
Zeig mal ein list von einem Rollladen.
Zitat von: fgam am 16 März 2025, 21:03:38Ich habe mal einen anderen Raspberry Pi (Version 4) genommen
Was war das für ein Raspberry den wir die ganze Zeit "bearbeitet" haben?
Raspberry Pi 3B
hätte genauso gehen müssen ... :-\
Kannst DU jetzt schalten nach dem du IODev attr umgestellt hast?
Ich bin am Anfang dieses Beitrags Deinem Rat
sofort gefolgt und habe eine VCCU angelegt.
Die IODevs der Rolladen haben sich anscheinend
selbst auf myHmUART umgestellt.
Vielleicht sollte ich die IODevs auf vccuMain umstellen?
list buero_Tuer
gibt:
Internals:
CFGFN /opt/fhem/rolladen.cfg
DEF 3CBCFC
FUUID 5fc0d838-f33f-e901-3a94-780e0489b1bd7ec9
IODev myHmUART
NAME buero_Fenster
NOTIFYDEV global
NR 104
NTFY_ORDER 50-buero_Fenster
STATE MISSING ACK
TYPE CUL_HM
chanNo 01
protCmdDel 4
protResnd 3 last_at:2025-03-16 21:50:46
protResndFail 1 last_at:2025-03-16 21:50:51
protSnd 1 last_at:2025-03-16 21:50:32
protState CMDs_done_Errors:1
READINGS:
2025-02-05 12:25:14 CommandAccepted yes
2019-06-30 20:23:10 D-firmware 2.8
2019-06-30 20:23:10 D-serialNr MEQ0732663
2022-04-09 13:14:44 PairedTo 0x424242
2019-12-01 14:08:09 R-driveDown 50 s
2019-12-01 14:08:09 R-driveTurn 0.5 s
2019-12-01 14:08:09 R-driveUp 50 s
2019-12-01 14:08:08 R-pairCentral 0x424242
2019-12-01 14:08:09 R-sign off
2022-04-09 13:14:43 RegL_00. 00:00 02:01 0A:42 0B:42 0C:42 15:FF 18:00
2022-04-09 13:14:44 RegL_01. 00:00 08:00 09:00 0A:00 0B:01 0C:F4 0D:01 0E:F4 0F:05 10:00 30:06 56:00 57:24
2022-04-09 13:14:43 cfgState updating
2025-03-16 21:50:51 commState CMDs_done_Errors:1
2025-03-16 21:37:09 deviceMsg 92.5 (to 424242)
2025-03-16 21:37:09 level 92.5
2025-03-16 21:37:09 motor stop:92.5
2025-03-16 21:37:09 pct 92.5
2022-04-09 13:13:57 powerOn 2022-04-09 13:13:57
2025-03-16 21:37:09 recentStateType info
2025-03-16 21:50:51 state MISSING ACK
2025-03-16 21:37:09 timedOn off
helper:
HM_CMDNR 83
cSnd ,114444443CBCFC0201000000
dlvl C8
dlvlCmd ++A0114444443CBCFC0201C80000
mId 0005
peerFriend peerSens,peerVirt
peerOpt 3:blindActuator
regLst 0,1,3p
rxType 1
cmds:
TmplKey :no:1742158222.54043
TmplTs 1742158222.54043
cmdKey 1:1:0::buero_Fenster:0005:01:
cmdLst:
assignHmKey noArg
clear [(readings|trigger|register|oldRegs|rssi|msgEvents|{msgErrors}|attack|all)]
deviceRename -newName-
down [(-changeValue-|{10})] [(-ontime-|{0})] [(-ramptime-|{0})]
fwUpdate -filename- [-bootTime-]
getConfig noArg
getDevInfo noArg
getRegRaw (List0|List1|List2|List3|List4|List5|List6) [-peerChn-]
getVersion noArg
inhibit [(on|{off})]
off noArg
on noArg
pair noArg
pct -value- [-ontime-]
peerBulk -peer1,peer2,...- [({set}|unset)]
peerIODev [IO] -btn- [({set}|unset)] 'not for future use'
peerSmart -peerOpt-
press [(long|{short})] [(-peer-|{self01})] [(-repCount-|{0})] [(-repDelay-|{0.25})]
raw -data- [...]
regBulk -list-.-peerChn- -addr1:data1- -addr2:data2-...
regSet [(prep|{exec})] -regName- -value- [-peerChn-]
reset noArg
sign [(on|{off})]
statusRequest noArg
stop noArg
toggle noArg
toggleDir noArg
tplDel -tplDel-
unpair noArg
up [(-changeValue-|{10})] [(-ontime-|{0})] [(-ramptime-|{0})]
lst:
condition slider,0,1,255
peer
peerOpt HM_0589F6_Btn_01,HM_0589F6_Btn_02,HM_0589F6_Btn_03,HM_0589F6_Btn_04,HM_Motion1,HM_Motion2
tplDel
rtrvLst:
cmdList [({short}|long)]
deviceInfo [({short}|long)]
param -param-
reg -addr- -list- [-peerChn-]
regList noArg
regTable noArg
regVal -addr- -list- [-peerChn-]
saveConfig [-filename-]
tplInfo noArg
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +3CBCFC,00,00,00
prefIO
rxt 0
vccu
p:
3CBCFC
00
00
00
mRssi:
mNo
prt:
bErr 0
sProc 0
q:
qReqConf
qReqStat
role:
chn 1
dev 1
prs 1
tmpl:
Attributes:
IODev myHmUART
Rolladen_hinten Rolladen_hinten
alle_Rolladen alle_Rolladen
autoReadReg 4_reqStatus
expert defReg,rawReg
firmware 2.8
model HM-LC-BL1PBU-FM
peerIDs 00000000,
room CUL_HM
serialNr MEQ0732663
subType blindActuator
userattr Rolladen_hinten Rolladen_hinten_map alle_Rolladen alle_Rolladen_map structexclude
webCmd statusRequest:toggleDir:on:off:up:down:stop
und
list vccuMain
gibt:
Internals:
CFGFN /opt/fhem/rolladen.cfg
DEF 444444
FUUID 67d737cc-f33f-e901-77a1-1b93abce9d7869fa
IODev myHmUART
NAME vccuMain
NOTIFYDEV global
NR 51
NTFY_ORDER 50-vccuMain
STATE myHmUART:ok
TYPE CUL_HM
assignedIOs myHmUART
chanNo 01
READINGS:
2025-03-16 21:50:25 IOopen 1
2025-03-16 21:50:25 state myHmUART:ok
2025-03-16 21:06:42 unknown_25B778 received
2025-03-16 21:12:16 unknown_28B9E4 received
2025-03-16 21:03:21 unknown_2D1AE4 received
2025-03-16 21:12:18 unknown_3FBF2B received
2025-03-16 21:11:47 unknown_42793D received
2025-03-16 21:02:38 unknown_57D588 received
2025-03-16 21:13:42 unknown_5BD662 received
2025-03-16 20:59:58 unknown_67BF3D received
2025-03-16 21:13:06 unknown_6DE399 received
2025-03-16 21:48:56 unknown_71C977 received
2025-03-16 21:13:06 unknown_B64C4F received
helper:
HM_CMDNR 106
peerFriend peerSD,peerSens,peerAct
peerOpt -:virtual
regLst 0
rxType 1
cmds:
TmplKey :no:1742158222.63941
TmplTs 1742158222.63941
cmdKey 1:1:1::vccuMain::01:
cmdLst:
assignHmKey noArg
assignIO -IO- [({set}|unset)]
clear [(readings|rssi|msgErrors|{msgErrors}|unknownDev)]
defIgnUnknown noArg
deviceRename -newName-
fwUpdate -filename- [-bootTime-]
getDevInfo noArg
hmPairForSec [-sec-]
hmPairSerial -serial-
peerChan -btnNumber- -actChn- [({single}|dual|reverse)] [({set}|unset)] [(actor|remote|{both})]
peerSmart -peerOpt-
postEvent -condition-
press [(long|{short})] [(-peer-|{all})] [(noBurst|{Burst})] [(-repCount-|{0})] [(-repDelay-|{0.25})]
pressL [(-peer-|{all})]
pressS [(-peer-|{all})]
raw -data- [...]
reset noArg
unpair noArg
update noArg
virtual [(1..50;1|{1})]
lst:
condition slider,0,1,255
peer
peerOpt Garage,HM_0589F6_Btn_01,HM_0589F6_Btn_02,HM_0589F6_Btn_03,HM_0589F6_Btn_04,HM_503383_Arm,HM_503383_Panic,HM_503383_Sen_01,HM_503383_Sen_02,HM_Motion1,HM_Motion2,HM_Smoke_Flur_EG,bib_Rolladen,buero_Fenster,buero_Tuer,esszi_Rolladen_Strasse,esszi_Rolladen_Terrasse,fewo_Rolladen_SZ_links,fewo_Rolladen_SZ_rechts,fewo_Rolladen_Wozi_links,fewo_Rolladen_Wozi_rechts,kueche_Rolladen,wozi_Rolladen_Garten,wozi_Rolladen_Terrasse
tplDel
rtrvLst:
cmdList [({short}|long)]
listDevice noArg
param -param-
expert:
def 1
det 0
raw 0
tpl 0
io:
prefIO
vccu vccuMain
ioList:
myHmUART
mRssi:
mNo
prt:
bErr 0
sProc 0
q:
qReqConf
qReqStat
role:
chn 1
dev 1
vrt 1
tmpl:
Attributes:
IODev myHmUART
IOList myHmUART
IOgrp vccuMain
model CCU-FHEM
subType virtual
webCmd virtual:update
Du hast Unfug gemacht!
ZitatPairedTo 0x424242
ZitatDEF 444444
FUUID 67d737cc-f33f-e901-77a1-1b93abce9d7869fa
IODev myHmUART
NAME vccuMain
Hier steht was Du tun musst https://wiki.fhem.de/wiki/Virtueller_Controller_VCCU
Die ID (DEF) der vccu muss 424242 sein! Du kannst einfach das Feld DEF editieren.
Die Geräte/Rolladen müssen das Attribute IOgrp bekommen!
Ich habe die definition umgestellt:
define vccuMain CUL_HM 424242
Das hat funktioniert. Die Rolladen schalten wieder !!!
Die IOGrp habe ich (noch?) nicht gesetzt.
Vielleicht kannst Du mir die genaue Syntax sagen,
damit ich da nichts Falsches schreibe.
Warum ich die mainVCCU brauche, wenn IODEV bei
den Rolladen auf myHmUART steht,
habe ich noch nicht verstanden
(vielleicht auch nicht mehr, weil die
Grundkonfiguration ist bei mir schon
8 Jahre her).
Aber ich frische das anlässlich
dieser großen Exkursion nochmal auf,
vielleicht geht es bei der nächsten
Systemumstellung dann schneller.
Herzlichen Dank für Deine Begleitung
auf dieser Reise und für Deine große Expertise!!!
Zitat von: fgam am 16 März 2025, 22:29:41Warum ich die mainVCCU brauche, wenn IODEV bei
den Rolladen auf myHmUART steht,
habe ich noch nicht verstanden
Lies Dir den Wiki Artikel (link oben) in Ruhe durch, da steht eigentlich alles drin. Deine Konfiguration läuft jetzt so erstmal.
Die VCCU kann mehrere IOs verwenden. Wenn IOgrp gesetzt ist, können die Geräte auch alle IOs der VCCU verwenden. Jetzt hast Du nur einen und IODev ist richtig gesetzt, erstmal ok. Mich wundert es etwas, dass bei Dir IODev ohne IOgrp umgestellt wurde. Aber vielleicht ist an mir auch eine Entwicklung vorbei gegangen. ;)
Warum es auf dem Pi3B nicht funktioniert hat, ist mir nicht klar.
>>Warum es auf dem Pi3B nicht funktioniert hat, ist mir nicht klar.
Ich stecke die SD-Karte auch bei Gelegenheit nochmal
in das ursprüngliche Gerät.
Vielleicht funktioniert es durch die Header-Installation dort ja
jetzt auch. Das hatte ich ja noch gar nicht ausprobiert.