HM-MOD-UART - did not respond after all

[Sidey]

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:

Code Auswählen Erweitern


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:

Code Auswählen Erweitern


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:

Code Auswählen Erweitern


id fhem
uid=109(fhem) gid=20(dialout) Gruppen=20(dialout),5(tty)


In /boot/config.txt ist der UART aktiv:

Code Auswählen Erweitern


[all]
# Add other config parameters below this line.
dtparam=watchdog=on
enable_uart=1


/boot/cmdline.txt ist auch angepasst:

Code Auswählen Erweitern


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:

Code Auswählen Erweitern


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

[Otto123]

Hallo Sidey,

ist sicher nicht das Problem, aber das

Code Auswählen Erweitern

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

Code Auswählen Erweitern

attr initialUsbCheck disable 1 gesetzt?

Gruß Otto

[Sidey]

ist sicher nicht das Problem, aber das

Code Auswählen Erweitern

enable_uart=1 gehört nicht in die /boot/cmdlines.txt

Das habe ich mir auch gedacht, als ich die config hier gepostet habe.

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.

hast Du

Code Auswählen Erweitern

attr initialUsbCheck disable 1 gesetzt?

Daran liegt es leider nicht.


Hat noch jemand eine Idee bezüglich serieller Schnittstelle prüfen?

Grüße Sidey

[Otto123]

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:

Code Auswählen Erweitern

# 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

[Sidey]

Hi,

hier der list vom device:

Code Auswählen Erweitern



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

Code Auswählen Erweitern

# 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

[Otto123]

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

[Sidey]

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

[frank]

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, ...

[Otto123]

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

[Sidey]

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

[Otto123]

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

[frank]

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.

[Sidey]

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

[Otto123]

Hallo Sidey,
super das freut mich!
Dann ein entspanntes Wochenende

Otto

[Sidey]

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.