[gelöst] HM-CFG-LAN ersetzen

Begonnen von grappa24, 27 November 2025, 11:54:09

Vorheriges Thema - Nächstes Thema

grappa24

ich denke, mein HM-CFG-LAN ist "am Ende", ich erhalte immer öfter die Fehlermeldung
2025.11.27 10:44:21 1: 192.168.178.86:1000 disconnected, waiting to reappear (HMLAN1)
2025.11.27 10:44:21 1: HMLAN_Parse: HMLAN1 new condition disconnected
2025.11.27 10:44:21 1: HMLAN_Parse: HMLAN1 new condition init

Ich könnte in der Bucht sowohl einen "gebrauchten" HM-CFG-LAN oder einen HM-CFG-USB-2 bekommen.

Was macht denn mehr Sinn, bzw. wo ist der Aufwand beim Austausch geringer bzgl. Umstellung meines HMLAN Devices in Fhem?
Gebäudesicherheit/-komfort, PV-Prognose/Verbrauchssteuerung, Heizungssteuerung, Multimedia, ...
KNX, FS20, HM, HUE, Tradfri, Shellies, KLF200, Netatmo, Nuki, SolarForecast, HEOS, Alexa-FHEM, ...
FHEM 6.4, 2 x RasPi 3B+, Debian Bullseye

Otto123

Der Aufwand ist immer relativ gleich: hast Du VCCU - dann einfach IOlist erweitern, hast Du keine VCCU dann mache Eine - und dann IOlist erweitern :)

Beide Geräte sind älter als alt - hol Dir besser ein HM-MOD-RPI-PCB bei elv und einen USB Serialwandler. Wenn Du nicht löten kannst / willst gibt es die Kombi mW auch fertig in der Bucht.
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle

aktives Mitglied des FHEM e.V. (Technik)

Sailor

Hallo grappa24

Zitat von: grappa24 am 27 November 2025, 11:54:09ich denke, mein HM-CFG-LAN ist "am Ende", ich erhalte immer öfter die Fehlermeldung
Ich könnte in der Bucht sowohl einen "gebrauchten" HM-CFG-LAN oder einen HM-CFG-USB-2 bekommen.
Was macht denn mehr Sinn, bzw. wo ist der Aufwand beim Austausch geringer bzgl. Umstellung meines HMLAN Devices in Fhem?

Wenn du löten kannst (Lötkolben besitzt), kannst du auch versuchen die beiden Elkos im HM-CGF-LAN zu ersetzen.
Sind Cent-Teile die gerne aus dem Leben scheiden und gut zu erreichen sind.

Wenn's klappt - Super
Wenn's nicht klappt, dann kannst du das Teil immer noch ersetzen.

Gruß
    Sailor
******************************
Man wird immer besser...

grappa24

Zitat von: Otto123 am 27 November 2025, 12:14:14Der Aufwand ist immer relativ gleich: hast Du VCCU - dann einfach IOlist erweitern, hast Du keine VCCU dann mache Eine - und dann IOlist erweitern :)
Eine VCCU hab ich, Anleitung für IOList erweitern hab ich auch gefunden - check

ZitatBeide Geräte sind älter als alt - hol Dir besser ein HM-MOD-RPI-PCB bei elv und einen USB Serialwandler. Wenn Du nicht löten kannst / willst gibt es die Kombi mW auch fertig in der Bucht.
- Der HM-MOD-RPI-PCB wird "normalerweise" auf das GPIO vom RasPi aufgesteckt?
- Alternativ kann man ihn mit einem USB Serialwandler an die USB-Schnittstelle des Raspi anschließen?
- Nach dem Anstecken muss er in FHEM konfiguriert werden?
- Für sowas gibts doch sicher dann auch ein kleines "Gehäuse"???
- Das Foto zeigt wohl einen fertigen HM-MOD-RPI-PCB mit Antenne(nadapter)?
Gebäudesicherheit/-komfort, PV-Prognose/Verbrauchssteuerung, Heizungssteuerung, Multimedia, ...
KNX, FS20, HM, HUE, Tradfri, Shellies, KLF200, Netatmo, Nuki, SolarForecast, HEOS, Alexa-FHEM, ...
FHEM 6.4, 2 x RasPi 3B+, Debian Bullseye

Otto123

Zitat von: grappa24 am 27 November 2025, 15:37:42- Der HM-MOD-RPI-PCB wird "normalerweise" auf das GPIO vom RasPi aufgesteckt?
- Alternativ kann man ihn mit einem USB Serialwandler an die USB-Schnittstelle des Raspi anschließen?
- Nach dem Anstecken muss er in FHEM konfiguriert werden?
- Für sowas gibts doch sicher dann auch ein kleines "Gehäuse"???
- Das Foto zeigt wohl einen fertigen HM-MOD-RPI-PCB mit Antenne(nadapter)?
Ja, Ja, Ja, mmh da muss man erfinderisch sein, offenbar - braucht man mMn nicht.
Du kannst den auch auf einen Raspberry stecken auf dem FHEM NICHT läuft und übers Netzwerk betreiben
Steht eigentlich alles hier
Man kann auch Wandler und HM-MOD-RPI-PCB mit einem Stück vieradrigen Kabel Verbinden ohne die ganzen Pfostenstecker und die Platinchen mit Schrumpfschlauch schützen.


Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle

aktives Mitglied des FHEM e.V. (Technik)

tndx


grappa24

#6
Am Besten würde mir die Anbindung des HM-MOD-RPI-PCB Funkmoduls via USB-Serialwandler gefallen und anschließend die Veröffentlichung mit ser2net in meinem Netzwerk.

Ich skizziere mal kurz meine Konfiguration mit 2 Stück RasPi 3B+ (nennen wir sie A und B):
A) im Keller, Buster, Host für mein FHEM, HMLAN mit VCCU, relativ weit weg von den HM-Komponenten (15 Stück, verteilt über 4 Etagen)
B) im 1. OG, Bullseye, relativ zentral, mit einem "kleinen" zweiten FHEM, angebunden an A) mit FHEM2FHEM
  neben Gerät B) steht direkt der "alte" HM-CFG-LAN

Meine Idee wäre es, den HM-MOD-RPI-PCB auf B) zu installieren und ihn dann via ser2net im Netzwerk zur Verfügung zu stellen.
Oder bringt mir FHEM2FHEM hier irgendeinen Vorteil?

Grüße
Dieter



Gebäudesicherheit/-komfort, PV-Prognose/Verbrauchssteuerung, Heizungssteuerung, Multimedia, ...
KNX, FS20, HM, HUE, Tradfri, Shellies, KLF200, Netatmo, Nuki, SolarForecast, HEOS, Alexa-FHEM, ...
FHEM 6.4, 2 x RasPi 3B+, Debian Bullseye

Otto123

Hallo Dieter,

FHEM2FHEM ist dafür keine Lösung, ser2net ist prima.
Du kannst natürlich das Modul auch direkt auf die GPIO stecken und die ttyAMA0 über ser2net zur Verfügung stellen. Da sparts Du den serial Wandler und hast ihn (wenn er passt) mit im Gehäuse.
Nachteil ist die etwas höhere Störbeeinflussung durch den Pi selbst. Du darfst vor allem den Ferritkern (der mitgeliefert wird) nicht vergessen.

Kannst Du ja auch probieren...

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle

aktives Mitglied des FHEM e.V. (Technik)

grappa24

Nochmal eine andere Frage:
an dem RasPi 3B+ (Bullseye), wo der HM-MOD-RPI-PCB via USB-Serialwandler angeschlossen werden soll, hängt schon ein CUL an /dev/ttyACM0, (wie) kann man denn beide parallel betreiben?

pi@raspberrypi:~ $ ls /dev/ttyACM*
/dev/ttyACM0
pi@raspberrypi:~ $ lsusb
Bus 001 Device 004: ID 03eb:204b Atmel Corp. LUFA USB to Serial Adapter Project
Bus 001 Device 005: ID 0424:7800 Microchip Technology, Inc. (formerly SMSC)
Bus 001 Device 003: ID 0424:2514 Microchip Technology, Inc. (formerly SMSC) USB 2.0 Hub
Bus 001 Device 002: ID 0424:2514 Microchip Technology, Inc. (formerly SMSC) USB 2.0 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Gebäudesicherheit/-komfort, PV-Prognose/Verbrauchssteuerung, Heizungssteuerung, Multimedia, ...
KNX, FS20, HM, HUE, Tradfri, Shellies, KLF200, Netatmo, Nuki, SolarForecast, HEOS, Alexa-FHEM, ...
FHEM 6.4, 2 x RasPi 3B+, Debian Bullseye


Otto123

Zusatzinfo - das werden in dem Fall einfach zwei getrennte Schnittstellen: der eine ACM0 der andere USB0. Die Benennung der Schnittstellen hängt von der Art der Kommunikation ab.
Die KI liefert:
ZitatUnter Linux steht ttyACM0 für ein virtuelles serielles Gerät, das über USB mithilfe des Abstract Control Model (ACM) der USB Communication Device Class (CDC) emuliert wird.
Hier ist eine Aufschlüsselung der Bezeichnung:
tty: Dies ist die traditionelle Linux/Unix-Bezeichnung für ein "teletype" oder Terminal-Gerät, das zur seriellen Kommunikation verwendet wird.
ACM: Steht für Abstract Control Model, ein Standard-USB-Protokoll, das es Geräten wie Modems, Arduino-Boards, oder anderen Mikrocontrollern ermöglicht, über USB als virtueller serieller Port mit dem Host-System (Ihrem Computer) zu kommunizieren.
0: Dies ist die Gerätenummer. Sie zeigt an, dass es sich um das erste Gerät dieses Typs handelt, das vom Kernel erkannt wurde. Wenn Sie mehrere kompatible Geräte anschließen, würden diese als ttyACM1, ttyACM2 usw. erscheinen.
Im Gegensatz zu ttyUSB0, das typischerweise einen dedizierten USB-zu-Seriell-Konverter-Chip verwendet, nutzt ttyACM0 einen generischen Treiber, der direkt im Kernel integriert ist. Dies ist bei vielen modernen Mikrocontrollern, wie z.B. Arduino Uno oder Leonardo, die das CDC-ACM-Protokoll in ihrer Firmware implementieren, der Standardfall.
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle

aktives Mitglied des FHEM e.V. (Technik)

grappa24

#11
so, das HomeMatic Funkmodul läuft nun auf meinem RasPi, es hängt an ../../ttyUSB0

NUR: Sobald ich ser2net aktiviere (und nur dann) wechselt das Funkmodul ständig zwischen "opened" und "disconnected" ?

Laut chatGPT (sorry):

→ Das HM-MOD-RPI-PCB stolpert bei der ersten Verzögerung und versucht neu zu initialisieren → in FHEM:
opened → disconnected → opened → disconnected...

❗ Also: HM-MOD-RPI-PCB ist NICHT netzwerkfähig via ser2net

chatGPT empfiehlt stattdessen die Verwendung von hmland, was ist davon zu halten?
Gebäudesicherheit/-komfort, PV-Prognose/Verbrauchssteuerung, Heizungssteuerung, Multimedia, ...
KNX, FS20, HM, HUE, Tradfri, Shellies, KLF200, Netatmo, Nuki, SolarForecast, HEOS, Alexa-FHEM, ...
FHEM 6.4, 2 x RasPi 3B+, Debian Bullseye

Otto123

Zitat von: grappa24 am 03 Dezember 2025, 22:59:10chatGPT empfiehlt stattdessen die Verwendung von hmland, was ist davon zu halten?
Man darf der Plaudertasche nicht alles glauben ;)

ZitatSobald ich ser2net aktiviere (und nur dann) wechselt das Funkmodul ständig zwischen "opened" und "disconnected" ?
Ohne dürfte es doch gar nicht funktionieren? Also wie steht es ohne ser2net?

Welche Version ser2net?
Wie sieht die config aus?
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle

aktives Mitglied des FHEM e.V. (Technik)

grappa24

Wie gesagt, ich hab an meinen RasPi im Obergeschoss zwei USB-Geräte dran:
lrwxrwxrwx 1 root root 13 Dec  3 22:17 usb-busware.de_CUL868-if00 -> ../../ttyACM0
lrwxrwxrwx 1 root root 13 Dec  4 07:30 usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0 -> ../../ttyUSB0
Meine ser2net Version: 4.3.3

Meine ser2net.yaml: %YAML 1.1
---
# HM_MOD-RPI-PCB
connection: &con01
    accepter: tcp,4000
    connector: serialdev,
              /dev/ttyUSB0,
              115200n81,local,
              NOBREAK

Meine ser2net.service:
[Unit]
Description=Serial port to network proxy
Documentation=man:ser2net(8)
After=network-online.target
Wants=network-online.target

[Service]
EnvironmentFile=-/etc/default/ser2net
ExecStart=/usr/sbin/ser2net -n -c $CONFFILE -P /run/ser2net.pid
Type=exec
Restart=on-failure

[Install]
WantedBy=multi-user.target

Definition des HMUARTLGW auf dem RasPi mit Funkmodul im OG:
/dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0@115200
Definition des HMUARTLGW auf dem FHEM-Server im Keller:
defmod WLAN_HmUART HMUARTLGW uart://192.168.178.56:4000
Verhalten ohne ser2net:
RasPi mit Funkmodul: Device opened
RasPi mit FHEM-Server: Device disconnected

Verhalten mit ser2net:
RasPi mit Funkmodul: Ständiger Wechsel zwischen "Device opened" und "Device disconnected" im 2 Sekunden Takt
RasPi mit FHEM-Server: Device permanent "opened" aber "disconnected"
Gebäudesicherheit/-komfort, PV-Prognose/Verbrauchssteuerung, Heizungssteuerung, Multimedia, ...
KNX, FS20, HM, HUE, Tradfri, Shellies, KLF200, Netatmo, Nuki, SolarForecast, HEOS, Alexa-FHEM, ...
FHEM 6.4, 2 x RasPi 3B+, Debian Bullseye

Otto123

Guten Morgen,

hatte ich nicht gesagt: das Ganze geht nicht im Sharing! Du kannst das Modul an ein FHEM anbinden, nicht an mehrere. Das ist aber mit allen Homematic IOs so, auch mit dem HM-CFG-LAN.

Es steht zumindest auch so im Wiki.

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle

aktives Mitglied des FHEM e.V. (Technik)

grappa24

ja - sorry - aber wie bekomme ich dann Zugriff vom FHEM Host auf den Raspi mit dem Funkmodul?
Gebäudesicherheit/-komfort, PV-Prognose/Verbrauchssteuerung, Heizungssteuerung, Multimedia, ...
KNX, FS20, HM, HUE, Tradfri, Shellies, KLF200, Netatmo, Nuki, SolarForecast, HEOS, Alexa-FHEM, ...
FHEM 6.4, 2 x RasPi 3B+, Debian Bullseye

Otto123

#16
na genau so:
defmod WLAN_HmUART HMUARTLGW uart://192.168.178.56:4000Aber eben ohne die FHEM Definition auf dem Raspberry wo das Funkmodul auch steckt. Du hattest doch früher auch den HMLAN nicht in zwei FHEM Installationen definiert??
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle

aktives Mitglied des FHEM e.V. (Technik)

grappa24

#17
verstehe, dann hatte ich das falsch verstanden. Hätte das mit "kein Sharing" einfach ernst nehmen müssen, ist ja alles beschrieben ;)

War das von FHEM2FHEM und meinem "Remote_CUL" so gewöhnt.

Kaum macht mans richtig, schon gehts.

Jetzt noch Umzug meiner 14 HM-Devices von HMLAN1 auf WLAN_HmUART (um dann HMLAN1 stillzulegen).
In meiner VCCU hab ich bereits die IO-List erweitert - check.

Was sind denn jetzt die elementaren Schritte?

@Otto: Danke  für deine Geduld  ;)

P.S. Das mit chatGPT ist schon "bemerkenswert", auch wenn man da schnell mal in die falsche Richtung geführt wird  ;)

Gebäudesicherheit/-komfort, PV-Prognose/Verbrauchssteuerung, Heizungssteuerung, Multimedia, ...
KNX, FS20, HM, HUE, Tradfri, Shellies, KLF200, Netatmo, Nuki, SolarForecast, HEOS, Alexa-FHEM, ...
FHEM 6.4, 2 x RasPi 3B+, Debian Bullseye

Otto123

wenn die VCCU richtig eingerichtet ist (inklusive der Erweiterung um das IOgrp Attribute bei den Geräten) passiert der Umzug von alleine.

Zum überprüfen kannst Du (zusätzlich bzw. in Ergänzung der Befehle im Wiki Artikel zur VCCU) noch die vorhandenen Attribute testen:
list TYPE=CUL_HM:FILTER=DEF=[0-9a-fA-F]{6}:FILTER=DEF!=[0]{6} attr IOgrpOder schauen welches IODev gerade verwendet wird
list TYPE=CUL_HM:FILTER=DEF=[0-9a-fA-F]{6}:FILTER=DEF!=[0]{6} IODev
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle

aktives Mitglied des FHEM e.V. (Technik)

grappa24

#19
Das ist ja wirklich einfach  ;)

Nach Abschalten des "alten" HMLAN1 sind alle Devices auf das neue IO-Device umgezogen, einzig die vccu bleibt "scheinbar" beim alten IO-Dev
bd_fenster               WLAN_HmUART
bd_rollo                 WLAN_HmUART
dg_fenster_links         WLAN_HmUART
dg_fenster_rechts        WLAN_HmUART
di_fenster               WLAN_HmUART
he_fenster               WLAN_HmUART
keller_bm                WLAN_HmUART
keller_deckenleuchten     WLAN_HmUART
lu_fenster               WLAN_HmUART
rt_bd_dg                 WLAN_HmUART
rt_bd_og                 WLAN_HmUART
rt_diele                 WLAN_HmUART
rt_hwr                   WLAN_HmUART
rt_wz_li                 WLAN_HmUART
rt_wz_re                 WLAN_HmUART
v_fensterkontakt_bd_dg     WLAN_HmUART
v_fensterkontakt_hwr     WLAN_HmUART
v_fensterkontakt_wz      WLAN_HmUART
vccu                     HMLAN1
Gebäudesicherheit/-komfort, PV-Prognose/Verbrauchssteuerung, Heizungssteuerung, Multimedia, ...
KNX, FS20, HM, HUE, Tradfri, Shellies, KLF200, Netatmo, Nuki, SolarForecast, HEOS, Alexa-FHEM, ...
FHEM 6.4, 2 x RasPi 3B+, Debian Bullseye

Otto123

Hat die VCCU ev. das attr IODev separat? Das könnte/müsste weg. Ansonsten ist das glaube ich nur ein transientes "Problem". ;)
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle

aktives Mitglied des FHEM e.V. (Technik)

grappa24

#21
das wars, die vccu hatte tatsächlich das IODev attr  ;)

Alles in allem eine sehr erfolgreiche Umstellung - und die reconnects gehören hoffentlich der Vergangenheit an.

Danke dir
Dieter

Update: Nach nun 1 Woche kein einziges reconnect mehr und die FHEM-CPU-Auslastung ist drastisch gesunken, war vorher oft sekundenlang bei 100%
Gebäudesicherheit/-komfort, PV-Prognose/Verbrauchssteuerung, Heizungssteuerung, Multimedia, ...
KNX, FS20, HM, HUE, Tradfri, Shellies, KLF200, Netatmo, Nuki, SolarForecast, HEOS, Alexa-FHEM, ...
FHEM 6.4, 2 x RasPi 3B+, Debian Bullseye

berniie

Ich habe hier in der Wohnung drei HM-CFG-LAN im Einsatz. Die Wohnung ist etwas speziell und nur so erreiche ich alle HM Devices. Kann ich die drei HM-CFG-LAN durch drei HM-MOD-RPI-PCB ersetzen?

Otto123

Klar geht das, solange es die noch gibt :)
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle

aktives Mitglied des FHEM e.V. (Technik)

berniie

Danke. Hab gerade den ersten HM-MOD-RPI-PCB bestellt. Bin gespannt, ob das so läuft wie ich es erhoffe.

Sailor

Hallo berniie
Zitat von: berniie am 07 Januar 2026, 18:14:04Hab gerade den ersten HM-MOD-RPI-PCB bestellt. Bin gespannt, ob das so läuft wie ich es erhoffe.

Wir bitten um einen ausführlichen Erfahrungsbericht.

Gruss
    Sailor
******************************
Man wird immer besser...