Hi,
ich habe ein Problem mit meinem HM-MOD-UART Adapter.
Nach einem Stromausfall musste ich meinen PI 2 neu installieren. (Ich habe dafür ein fertiges Script) .
Problem ist nur, dass mein HM Adapter board nicht mehr funktionieren will. :(
Im Log sehe ich Meldungen, was auf ein Problem mit der seriellen Kommunikation hinweist:
2018.03.21 07:36:08 1: HMUARTLGW HMUART did not respond for the 1. time, resending
2018.03.21 07:36:11 1: HMUARTLGW HMUART did not respond for the 2. time, resending
2018.03.21 07:36:14 1: HMUARTLGW HMUART did not respond for the 3. time, resending
2018.03.21 07:36:17 1: HMUARTLGW HMUART did not respond after all, reopening
2018.03.21 07:36:17 3: HMUART device closed
2018.03.21 07:36:17 3: Setting HMUART serial parameters to 115200,8,N,1
2018.03.21 07:36:17 1: /dev/ttyAMA0 reappeared (HMUART)
Entweder habe ich ein Konfig Problem, oder das Board ist kaputt. Beides wäre denkbar.
Das Serielle Device ist wie folgt eingerichtet:
ls -l /dev/ttyAMA0
crw-rw---- 1 root dialout 204, 64 Mär 21 20:23 /dev/ttyAMA0
Der Benutzer fhem ist auch in der Gruppe dialout:
id fhem
uid=109(fhem) gid=20(dialout) Gruppen=20(dialout),5(tty)
In /boot/config.txt ist der UART aktiv:
[all]
# Add other config parameters below this line.
dtparam=watchdog=on
enable_uart=1
/boot/cmdline.txt ist auch angepasst:
dwc_otg.lpm_enable=0 console=tty1 elevator=deadline fsck.repair=yes enable_uart=1 root=/dev/mmcblk0p2 rootfstype=f2fs rootwait net.ifnames=0 loglevel=3
Den Dienst serial-getty habe ich auch am starten gehindert:
root@fhem-pi:/opt/fhem# systemctl status serial-getty@ttyAMA0.service
● serial-getty@ttyAMA0.service
Loaded: masked (/dev/null; bad)
Active: inactive (dead)
Aktuell fällt mir nichts mehr ein, was ich noch machen könnte.
Vielleicht habe ich ja etwas übersehen und jemand hat einen guten Tip für mich.
Grüße Sidey
Hallo Sidey,
ist sicher nicht das Problem, aber das
enable_uart=1 gehört nicht in die /boot/cmdlines.txt
Und einen "Abschnitt" [all] gibt es nicht in meiner /boot/config.txt
Hast Du die config.txt mit Linux editiert?
hast Du attr initialUsbCheck disable 1 gesetzt?
Gruß Otto
Zitat von: Otto123 am 21 März 2018, 21:07:52
ist sicher nicht das Problem, aber das
enable_uart=1 gehört nicht in die /boot/cmdlines.txt
Das habe ich mir auch gedacht, als ich die config hier gepostet habe.
Zitat von: Otto123 am 21 März 2018, 21:07:52
Und einen "Abschnitt" [all] gibt es nicht in meiner /boot/config.txt
Hast Du die config.txt mit Linux editiert?
Ich habe mir den Abschnitt all nicht ausgedacht. Der ist so vorgegeben. Ab da sollen alle eigenen Anpassungen erfolgen.
Einen Abschnitt mit [pi3] gibt es auch. :)
Zitat von: Otto123 am 21 März 2018, 21:07:52
hast Du attr initialUsbCheck disable 1 gesetzt?
Daran liegt es leider nicht.
Hat noch jemand eine Idee bezüglich serieller Schnittstelle prüfen?
Grüße Sidey
Zitat von: Sidey am 21 März 2018, 22:11:26
Ich habe mir den Abschnitt all nicht ausgedacht. Der ist so vorgegeben. Ab da sollen alle eigenen Anpassungen erfolgen.
Einen Abschnitt mit [pi3] gibt es auch. :)
Bei einem Original Raspbian? Die sieht bei mir so aus:
# For more options and information see
# http://rpf.io/configtxt
# Some settings may impact device functionality. See link above for details
# uncomment if you get no picture on HDMI for a default "safe" mode
#hdmi_safe=1
# uncomment this if your display has a black border of unused pixels visible
# and your display can output without overscan
#disable_overscan=1
# uncomment the following to adjust overscan. Use positive numbers if console
# goes off screen, and negative if there is too much border
#overscan_left=16
#overscan_right=16
#overscan_top=16
#overscan_bottom=16
# uncomment to force a console size. By default it will be display's size minus
# overscan.
#framebuffer_width=1280
#framebuffer_height=720
# uncomment if hdmi display is not detected and composite is being output
#hdmi_force_hotplug=1
# uncomment to force a specific HDMI mode (this will force VGA)
#hdmi_group=1
#hdmi_mode=1
# uncomment to force a HDMI mode rather than DVI. This can make audio work in
# DMT (computer monitor) modes
#hdmi_drive=2
# uncomment to increase signal to HDMI, if you have interference, blanking, or
# no display
#config_hdmi_boost=4
# uncomment for composite PAL
#sdtv_mode=2
#uncomment to overclock the arm. 700 MHz is the default.
#arm_freq=800
# Uncomment some or all of these to enable the optional hardware interfaces
#dtparam=i2c_arm=on
#dtparam=i2s=on
#dtparam=spi=on
# Uncomment this to enable the lirc-rpi module
#dtoverlay=lirc-rpi
# Additional overlays and parameters are documented /boot/overlays/README
# Enable audio (loads snd_bcm2835)
dtparam=audio=on
Kannst Du bitte noch ein list HMUARTLGW posten?
Gruß Otto
Hi,
hier der list vom device:
Internals:
CFGFN /opt/fhem/cfg/fhem_1_iodevs.cfg
CNT 1
Clients :CUL_HM:
DEF /dev/ttyAMA0
DevState 0
DevType UART
DeviceName /dev/ttyAMA0@115200
LastOpen 1521665987.64099
NAME HMUART
NR 63
STATE closed
TYPE HMUARTLGW
XmitOpen 0
model HM-MOD-UART
owner_CCU VCCU
Helper:
AckPending:
1:
cmd 00
dst 0
frame FD00030001009E03
resend 3
time 1521665988.71535
LastSendLen:
3
Log:
IDs:
MatchList:
1:CUL_HM ^A......................
Peers:
22A1A3 pending
389899 pending
4A75E4 pending
4A765D pending
READINGS:
2018-03-08 22:02:23 D-HMIdAssigned yyyyyy
2018-03-08 22:02:23 D-HMIdOriginal aaaaaa
2018-03-08 22:02:23 D-firmware 1.4.1
2018-03-08 22:02:23 D-serialNr NEQ1330941
2018-03-21 21:31:23 D-type HM-MOD-UART
2018-03-21 21:59:57 cond disconnected
2018-03-08 22:16:15 load 4
2018-03-21 21:31:23 loadLvl suspended
2018-03-21 21:59:57 state closed
helper:
Attributes:
group IO
hmId yyyyyy
hmKey 02:xxxxxx
room HM
Hmm, meine config.txt sieht so aus. Ich installiere seit längerem mittels ua-netinst.
Vom prinzip lädt der halt einfach alle aktuellen Pakete runter. Müsste identisch mit einem apt-get update && apt-get upgrade nach der Installation sein
# For more options and information see
# http://rpf.io/configtxt
# Some settings may impact device functionality. See link above for details
# uncomment if you get no picture on HDMI for a default "safe" mode
#hdmi_safe=1
# uncomment this if your display has a black border of unused pixels visible
# and your display can output without overscan
#disable_overscan=1
# uncomment the following to adjust overscan. Use positive numbers if console
# goes off screen, and negative if there is too much border
#overscan_left=16
#overscan_right=16
#overscan_top=16
#overscan_bottom=16
# uncomment to force a console size. By default it will be display's size minus
# overscan.
#framebuffer_width=1280
#framebuffer_height=720
# uncomment if hdmi display is not detected and composite is being output
#hdmi_force_hotplug=1
# uncomment to force a specific HDMI mode (this will force VGA)
#hdmi_group=1
#hdmi_mode=1
# uncomment to force a HDMI mode rather than DVI. This can make audio work in
# DMT (computer monitor) modes
#hdmi_drive=2
# uncomment to increase signal to HDMI, if you have interference, blanking, or
# no display
#config_hdmi_boost=4
# uncomment for composite PAL
#sdtv_mode=2
#uncomment to overclock the arm. 700 MHz is the default.
#arm_freq=800
# Uncomment some or all of these to enable the optional hardware interfaces
#dtparam=i2c_arm=on
#dtparam=i2s=on
#dtparam=spi=on
# Uncomment this to enable the lirc-rpi module
#dtoverlay=lirc-rpi
# Additional overlays and parameters are documented /boot/overlays/README
# Enable audio (loads snd_bcm2835)
#dtparam=audio=on
[pi3]
# Enable serial port
enable_uart=1
[all]
# Add other config parameters below this line.
dtparam=watchdog=on
enable_uart=1
Das ist eine alte FHEM Installation? Es gab schon Werte....
Da sieht man jetzt nicht ob er kurzzeitig mit der UART arbeitet :-[
Das ist ein Pi3 oder ein Pi2?
Gruß Otto
Hi Otto,
Ja. Also mein Setup ist wie folgt:
Ich habe einen Pi2.
Den Pi installiere ich mit ua-netinst. Meine Daten und die Applikationen habe ich auf einen USB Stick ausgelagert.
Dadurch habe ich Betriebssystem und Applikationen ein wenig getrennt. :)
Die alte SD Karte war futsch, der USB Stick zum Glück nicht. Ich habe es jetzt auch erst ein paar Tage nach dem Ausfall bemerkt. Es deutet aber alles darauf hin, dass das Modul das letzte mal vor meinem Stomausfall Crash funktioniert hat.
FHEM hängt leider immer an dem Aufbau der Seriellen Verbindung.
Grüße Sidey
Gesendet von meinem XT1650 mit Tapatalk
schon mal ins sys.log vom pi geschaut?
hast du eine möglichkeit den adapter testweise an anderer hardware zu probieren? anderer pi, serieller adapter, wemos, ...
Moin Sidey,
eigentlich sieht alles richtig aus. Ich habe noch einen letzten Einfall:
Hast Du mal den Pi heruntergefahren, vom Strom getrennt und das Modul abgezogen?
Dann eine Weile warten und alles wieder in Betrieb nehmen.
Gruß Otto
Hi,
stromlos hatte ich den Pi schon mal für etwa 5 Sekunden.
Ich habe das Modul jetzt ausgebaut und in einen anderen Pi eingebaut.
Läuft auf einem PI1 sogar ohne enable_uart in der config.txt..
Also das Modul selbst ist in Ordnung. :)
Fragt sich jetzt aber wieder, woran liegt es.
Vermutlich doch ein Konfigurations Thema.
Grüße Sidey
Zitat von: Sidey am 22 März 2018, 23:52:24
stromlos hatte ich den Pi schon mal für etwa 5 Sekunden.
Moin Sidey,
ich weiß das klingt nach Vodoo aber ich meinte eben nicht nur den Pi stromlos sondern das Modul auch abziehen. Es gibt dazu mehrere Hinweise und ich selbst hatte das auch schon. Ich bin aber unsicher, ob diese Problem nur mit der Original Firmware bei Auslieferung auftrat.
Hier ist die UART offiziell beschrieben: https://www.raspberrypi.org/documentation/configuration/uart.md
Der komplizierter Konfigurationskram ist eigentlich alles erst ab Pi3, bei allen anderen Pi sollte es völlig ohne Kunstgriffe einfach funktionieren.
Gruß Otto
ein hardware defekt am pi könnte es ja auch sein. daher der hinweis zum sys.log.
die gpio beim pi kann man ja auch "manuell" setzen/konfigurieren. vielleicht eine idee zum testen ohne hmuart.
Hi,
Danke für die Unterstützung.
Ich habe das Modul jetzt wieder in den Pi2 eingebaut und es funktioniert jetzt einfach wieder.
Seltsam ist es, aber vielleicht hätte ich den Pi einfach länger stromlos halten sollen.
Grüße Sidey
Gesendet von meinem XT1650 mit Tapatalk
Hallo Sidey,
super das freut mich!
Dann ein entspanntes Wochenende :D
Otto
Ich will meine Erkenntnisse einmal aktualisieren.
Problem ist prinzipiell immer noch das gleiche. Das HM UART Modul läuft nicht dauerhaft auf meinem Raspberry Pi 2.
Auf einer 1 B Version, keine Probleme.
Ich habe gestern herausgefunden, dass seit einem Kernel Update ende 2017, kommt es durchaus auch bei anderen Anwendungen zu einem Problem mit dem UART.
Ein Hardware Problem kann ich mittlerweile ausschließen denn
1) Das UART Modul läuft in einem anderen PI über etliiche Tage problemlos
2) durch stty -F /dev/ttyAMA0 habe ich den fehlerhaften Zustand gestern auf dem PI2 beheben können. Zuvor lief es so ca. 10 Minuten nach dem Reboot und geriet dann wieder in disconnected.
Ich bleibe dran, aber es spricht durchaus einiges dafür, dass eine Anpassung am Kernel mit verantwortlich sein könnte.
bei mir wars der fehlende feritkern am netzteil ...
Danke DasQ - das gleich bei mir
Der Raspi2 lief an einer Powerbank (NoName) und erst als ich den Ferrit um das MicroUSB Kabel gewickelt habe, war der Fehler sofort nach Reboot verschwunden.