HMUARTLGW bleibt disconnected

[teichtaucher]

Hallo,
ich habe seit langer Zeit neben dem HMLAN ein hm-mod-rpi-pcb auf einem Wemos D1 mini laufen. Auf dem Wemos D1 mini läuft ESP-link. Dieses Setup lieft seit Jahren stabil. Seit einiger Zeit zickt der HMLAN rum. Deshalb habe ich mich entschieden einen zweiten Wemos D1 mit hm-mod-rpi-pcb aufzusetzen. Heute habe ich den zweiten ans Netz genommen, per HMUARTLGW in FHEM eingebunden und in der VCCU aufgenommen.
Beide HMUARTLGW liefen seit heute mittag parallel ohne Probleme. Als ich vorhin den Status checken wollte habe ich gesehen dass der erste HMUARTLGW disconnected ist. Der Wemos ist unter der gleichen IP wie sonst online und auf die Weboberfläche kann ich auch zugreifen. Aber ich bekomme ihn in FHEM nicht wieder online. Wenn ich reopen mache versucht er online zu gehen, geht dann aber gleich wieder auf disconnect.
Kann es sein dass sich die beiden HMUARTLGW untereinander stören? Selbst wenn ich den neuen HMUARTLGW offline nehmen bekomme ich den alten nicht wieder online. Auch ein Neustart hat nichts gebracht.
Habt ihr irgendwelche Ideen was ich machen kann?

[Otto123]

Hi,

eventuell haben die beiden den gleichen hostnamen (esp-link) und es gibt einen IP Namens Konflikt? Eventuell wird das durch den WLAN AP (DHCP -> DNS)  verursacht?

esp-link will use the hostname in its DHCP request, which allows you to identify the module's MAC and IP addresses in your DHCP server (typ. your wifi router). In addition, some DHCP servers will inject these names into the local DNS cache so you can use URLs like hostname.local.

Hast Du mal den Namen in der Weboberfläche geändert und den esp-link neu gestartet?

Gruß Otto

[teichtaucher]

Ja, beide heißen unterschiedlich WemosGateway1 und WemosGateway2. Auch die IP Adressen sind unterschiedlich. In FHEM heißt das Problemkind gl.gw.Wemos1 und das sind die letzten Logeinträge:

Code Auswählen Erweitern


2022.09.08 13:24:40 1: HMUARTLGW gl.gw.Wemos1 unexpected info about Co_CPU_BL received (module crashed?), reopening
2022.09.08 13:24:40 3: gl.gw.Wemos1 device closed
2022.09.08 13:24:40 1: 192.168.178.5:23 reappeared (gl.gw.Wemos1)
2022.09.08 13:24:41 1: 192.168.178.5:23 disconnected, waiting to reappear (gl.gw.Wemos1)
2022.09.08 13:24:44 1: HMUARTLGW gl.gw.Wemos1 did not respond for the 1. time, resending
2022.09.08 13:24:47 1: 192.168.178.5:23 reappeared (gl.gw.Wemos1)
2022.09.08 13:24:48 1: 192.168.178.5:23 disconnected, waiting to reappear (gl.gw.Wemos1)
2022.09.08 13:24:51 1: HMUARTLGW gl.gw.Wemos1 did not respond for the 1. time, resending
2022.09.08 13:24:54 1: 192.168.178.5:23 reappeared (gl.gw.Wemos1)
2022.09.08 13:24:55 1: 192.168.178.5:23 disconnected, waiting to reappear (gl.gw.Wemos1)
2022.09.08 13:24:58 1: HMUARTLGW gl.gw.Wemos1 did not respond for the 1. time, resending
2022.09.08 13:25:00 1: 192.168.178.5:23 reappeared (gl.gw.Wemos1)
2022.09.08 13:25:02 1: 192.168.178.5:23 disconnected, waiting to reappear (gl.gw.Wemos1)
2022.09.08 13:25:05 1: 192.168.178.5:23 reappeared (gl.gw.Wemos1)
2022.09.08 13:25:07 1: 192.168.178.5:23 disconnected, waiting to reappear (gl.gw.Wemos1)
2022.09.08 13:25:10 1: 192.168.178.5:23 reappeared (gl.gw.Wemos1)
2022.09.08 13:25:11 1: 192.168.178.5:23 disconnected, waiting to reappear (gl.gw.Wemos1)
2022.09.08 13:25:14 1: HMUARTLGW gl.gw.Wemos1 did not respond after all, reopening

Vielleicht macht der Wemos ja die Grätsche. Aber das wäre ja ein krasser Zufall dass es just zwei Stunden passiert nachdem der neue in Betrieb genommen wurde.
Ich messe jetzt mal am alten Wemos die Spannung. Vielleicht hakt es ja schon daran.
Aber prinzipiell können doch mehrere HMUARTLGW parallel betrieben werden, oder?

[Otto123]

Aber prinzipiell können doch mehrere HMUARTLGW parallel betrieben werden, oder?

Bei mir laufen zwei bis drei. Hier gibt es einen im Forum da laufen glaube ich 6.

Über die Homepage ist der Wemos stabil erreichbar? Es gab wohl auch schon hm-mod-rpi-pcb die gestorben sind ...

[Beta-User]

Evtl. auch wieder unser "WLAN-Klassiker": Ein weiteres Gerät bringt das Fass zum Überlaufen?

Vielleicht schilderst du uns kurz, wie deine Infrastruktur aufgebaut ist.
Bekannt kritisch sind FritzBox (oä. Provider-Router) + 20 und mehr Geräte im WLAN (20 ist geschossen, häufiger sind auch 25 im  Rennen).

[det.]

Habt ihr irgendwelche Ideen was ich machen kann?


... runtersteigen vom toten Pferd - ging mir ähnlich, eine Zeitlang ging das Ding prima, dann genau so ein Fehlerbild. Konnte das dauerhaft (seit 2019) lösen durch Kauf von dem: Homematic Funk LAN Gateway

[teichtaucher]

Evtl. auch wieder unser "WLAN-Klassiker": Ein weiteres Gerät bringt das Fass zum Überlaufen?

Vielleicht schilderst du uns kurz, wie deine Infrastruktur aufgebaut ist.
Bekannt kritisch sind FritzBox (oä. Provider-Router) + 20 und mehr Geräte im WLAN (20 ist geschossen, häufiger sind auch 25 im  Rennen).

Bei mir sind definitiv mehr als 20 Geräte im WLAN, Handies, Tablets, Shellies, usw. Ich kann mir aber nicht vorstellen dass das ein Problem denn die Weboberfläche erreiche ich ganz normal.
Ich habe jetzt auchmal nachgemessen, die 3,3V liegen an. Ich sehe im Serialprotokoll auch dass der Wemos mit dem HM-MOD-RPI-PCB spricht:

Code Auswählen Erweitern



I]�prY@�4p��

9>�p1�B�6��
J0�ZrYo$�7���,$��
P-�p5���6���
6�RA�
��
���
B�qM�
$� @���,���
K0�prYo�7�x�
2��Z��
���r�
R-�ZF�$�6^9��,\��
;b�qI�
$�@9��
4��.u�
����
;_�<��
�����
5~�2�d
��ʔ��,Ȗ��,����,`��
=_�8��
$�@�n�
@��<�A
$�>#��,����,8��
F�<<o
$�@���,��
J^�ZrY@��41�}�
(E�.{�
������,���
�
+I_�ZrY@��4���,���
,G�<<o
$�@}��,��
-B�qM�
$� @
y�
.I_�prY@�4 ��
/(F�.{�
�����
0P/�Z5��$�6!=�
1;d�qI�
$�@8$�
2J2�ZrYo$�7Z�,4��
3Q/�p5���6>��,���
49@�Z1�B��6j�
56�RA�
��
]��
6J2�prYo�7bs�
72��Z��
��)�,l��
84��.u�
��M��
96��2�d
����
:9@�p1�B�6�8� ,���
;;a�<��
��0�|�
,ľ�,P��
<R/�pF��6^��
==a�8��
$�@���,���
>A��<�A
$�&2�
?J`�ZrY@��4���,(��
@J`�prY@�4 ��,��
AG�<<o
$�@7��,���
Be�?e
8�@ޤ�
CQׄ5��$�
@�o�
D(G�.{�
��|��
EQ0�p5���5C7�,��
FL3�ZrYo$�7o��
G4��.u�
�����,���
H5��2�d
��t�
IB�qM�
$� @���
J9A�Z1�B��6/
�
K;e�qI�
$�@���
L9��1�B��
��
MJ3�prYo�7�T�,���
N6 �RA�
��
�G�
O9A�p1�B�6Q��
P2��Z��
��C'�,0��
Q;b�<��
����,ܻ�
RR0�ZF�$�6���,H��
SR0�pF��6���,t��
TF�<<o
$�@��
U=b�8��
$�@�/�,��
VA��<�A
$�w��,,��
WJa�ZrY@��4ڨ�
X(H�.{�
����,���
YJa�prY@�4�Y�,���
Z9B�Z1�B��6��
[J4�ZrYo$�7�j�
\P1�Z5��$�5�G�,��
]:c�<��
��4��
^9B�p1�B�6��
_J4�prYo�7�C�
`;f�qI�
$�@ۆ�,�|��
aB�qM�
$� @4�
b6
�RA�
��
�C�
c4��.u�
��u�
d2��Z��
���x�
e6��2�d
��Da�,h��
fS1�ZF�$�6��,T��
gS1�pF��6z��,��� ,̲�!,X��
h=c�8��
$�@���
iA��<�A
$�T��",d��
j9C�Z1�B��6�u�
kIb�ZrY@��4��
lG�<<o
$�@���#,��
mK5�ZrYo$�7�/�
n9C�p1�B�6��$,��
oIb�prY@�4i��
p(I�.{�
��w��
qJ5�prYo�74e�%,���
r6�RA�
��
=��
s<g�qI�
$�@G��
t2��Z��
��/��
uQ2�Z5��$�5�q�&,���
vB�qM�
$� @���
w:d�<��
�����', ��
xQ2�p5���5���
y4��.u�
�����
z6��2�d
���R�(,��),x��
{S2�ZF�$�6���*,D��
|=d�8��
$�@���
}A��<�A
$�5��
~S2�pF��6m��

S�^
�05
��~�+,б�
�d�?e
8�@��,,<��
�Jc�ZrY@��4�`�-,���
�6�RA�
��
��
�9D�Z1�B��6�2�
�2��Z��
��G��
�Ic�prY@�4X��
�G�<<o
$�@]n�.,���
�;h�qI�
$�@!�/,��
�9D�p1�B�6$�
�K6�ZrYo$�7�}r�
�B�qM�
$� @\��
�(J�.{�
�����0,���
�Q3�Z5��$�5Pt�
�L6�prYo�7���1,��
�3��.u�
����
�;e�<��
��a:�
�6��2�d
��q��2,$��
�=e�8��
$�@W�
�A��<�A
$����3,���4,\��
�S3�ZF�$�6$��5,ȴ�
�Id�ZrY@��4���
�S3�pF��6ڜ�6,���
�Id�prY@�4��7,`��
�B �qM�
$� @�U�
�G�<<o
$�@ &�8,���
�9E�Z1�B��6J��9,8��
�6�RA�
��
���
�2��Z��
��ע�
�9E�p1�B�64J�
�Q4�Z5��$�5v_�
�(K�.{�
��
��:,��
�J7�ZrYo$�7���
�;i�qI�
$�@�h�
�4��.u�
��$8�
�4��2�d
�����
�Q4�p5���5�>�;,���
�;f�<��
��&P�
�K7�prYo�7=�<,|��=,��
�=f�8��
$�@5��>,Է�
�@��<�A
$�'��
�T4�ZF�$�68�?,@��
�e��?e
8�@OQ�@,̣�
�S4�pF��6��
�
Y��^ �05
�F�A,X��
�H�<<o
$�@�C�
�Ie�ZrY@��4K��
�9F�Z1�B��6���
�P5�Z5��$�5�I�B,d��
�5��.u�
���V

... ist halt nur Binär, da müsste man das Protokoll verstehen.

... runtersteigen vom toten Pferd - ging mir ähnlich, eine Zeitlang ging das Ding prima, dann genau so ein Fehlerbild. Konnte das dauerhaft (seit 2019)

Kann ja gut sein dass der hm-mod-rpi-pcb tot ist. Aber was ist das denn für ein Zufall dass es genau zwei Stunden nach der Inbetriebnahme vom dem neuen ist. Die beiden haben sich vermutlich noch abgeklatscht bis der alte dann einen würdigen Nachfolger gefunden und dann das zeitliche gesegnet hat 

Für heute höre ich mal auf. Morgen versuche ich ESPlink nochmal neu zu flashen oder vielleicht mal ESPeasy zu probieren. Wenn das auch nicht läuft bestelle ich einen neuen.

[Beta-User]

Ich kann mir aber nicht vorstellen dass das ein Problem denn die Weboberfläche erreiche ich ganz normal.

Diese Antwort ist "Teil des Klassikers"...

20+ Geräte sind ok, wenn man die passende Infrastruktur hat. Aus dem fehlenden "ich habe aber ... als weitere AP" kann ich nur rückschließen, dass die nicht vorhanden ist .

Ich sehe im Serialprotokoll auch dass der Wemos mit dem HM-MOD-RPI-PCB spricht:

Code Auswählen Erweitern



   I]�prY@�4p��




Sieht evtl. auch so aus, wenn die Baudrate nicht paßt.

[teichtaucher]

20+ Geräte sind ok, wenn man die passende Infrastruktur hat. Aus dem fehlenden "ich habe aber ... als weitere AP" kann ich nur rückschließen, dass die nicht vorhanden ist .

Ich habe weitere Accesspoints am Laufen die über Ethernet mit der Fritzbox verbunden sind falls du das meinst. Ich verstehe nur nicht wo da das Problem liegen kann. Auf der Protokollebene wo der Wemos mit dem hm-mod-rpi-pcb spricht spielt doch IP und TCP gar keine Rolle mehr. Also wenn ich mit dem Webserver auf dem Wemos sprechen kann sollte doch eine saubere Netzwerkverbindung vorhanden sein. Und umgekehrt müsste der alte Wemos doch wieder laufen wenn ich den neuen wieder abklemme?

Sieht evtl. auch so aus, wenn die Baudrate nicht paßt.

Konntest du das daraus lesen? Meinst du das ernst? Ich hatte vorher nix in ESPlink verändert.

[Beta-User]

Sorry, wenn ich grade keine Lust zum Suchen habe. Fakt ist: Dass man einen ESP scheinbar "normal" über sein HTTP-Web-Interface erreichen kann, ist keine Garantie dafür, dass es nicht bei anderen Verbindungsarten zu Abbrüchen und Fehlern kommen kann. Hatten wir die vergangenen 2 Monate mind. 2x hier im Forum (da betraf es  MQTT)...

Und wenn mal der "Wurm drin" ist, braucht es dem Bauchgefühl nach uU. eine Zeit, bis alles wieder "im Lot" ist - das Problem scheint nicht "digital" zu sein. Kann da aber auch falsch liegen.

Wenn du "gute" Hardware hast, solltest du dafür sorgen, dass möglichst viele deiner nicht mobilen Geräte sich ausschließlich auf einen anderen AP als grade zur Fritte hin zu verbinden.

Konntest du das daraus lesen? Meinst du das ernst? Ich hatte vorher nix in ESPlink verändert.

Ich habe keine Ahnung, wie der Verkehr aussehen muss, optisch wirkt es ähnlich, wenn man eine serielle Verbindung zu einer MCU mit der falschen Baudrate aufmacht. Auch das muss es nicht sein...

Das Pi-PCB hat die richtige firmware-Version?

[Otto123]

Hat der ESP-LINK nicht auch sowas wie ein syslog?
Hast Du ein Linux am gleichen Wlan? Schau da mal ins /var/log/syslog bzgl. wlan

[teichtaucher]

Ja, ich aber die 1.4.1 schon seit Ewigkeit am laufen. Ich versuche es morgen mal mit neu Flashen und berichte dann wie es gelaufen ist. Schonmal danke für deine Hilfe!

[frank]

Ich habe keine Ahnung, wie der Verkehr aussehen muss, optisch wirkt es ähnlich, wenn man eine serielle Verbindung zu einer MCU mit der falschen Baudrate aufmacht. Auch das muss es nicht sein...

irgendwie habe ich das gefühl, dass es schon mal den fall gab, wo die baudrate im esp verstellt war (zb nach reboot).
finde den thread aber nicht mehr.
wie ist er angebunden? serial2net?

[rih]

@teichtaucher:
Hoffe, ich habe es nicht überlesen, aber hast du die beiden HM-MOD-RPI-PCB-Module schon mal getauscht? Dann würdest du sehen, ob das Problem auf der ESP- oder der HM-MOD-RPI-PCB-Seite liegt.