[solved] debmatic - HB-REF-ETH - keine HmIP-Geräte - Ubuntu 20

Debian/Ubuntu basierte CCU

Moderator: Co-Administratoren

Schlammschlumpf
Beiträge: 17
Registriert: 31.03.2019, 13:08
Hat sich bedankt: 1 Mal

Re: debmatic - HB-REF-ETH - keine HmIP-Geräte

Beitrag von Schlammschlumpf » 29.05.2021, 09:35

Guten Morgen Alex,

IP4 -Konfiguration auf statisch gewechselt und die DNS-Server entsprechend hinterlegt.

Code: Alles auswählen

Link 2 (ens18)
      Current Scopes: DNS
DefaultRoute setting: yes
       LLMNR setting: yes
MulticastDNS setting: no
  DNSOverTLS setting: no
      DNSSEC setting: no
    DNSSEC supported: no
  Current DNS Server: 8.8.8.8
         DNS Servers: 8.8.8.8
                      8.8.4.4
                      fd00::e228:6dff:fe6b:85a2
Scheint auch Namen aufzulösen:

Code: Alles auswählen

ping  eq-3.de
PING eq-3.de (81.14.202.21) 56(84) bytes of data.
64 bytes from www.eq-3.de (81.14.202.21): icmp_seq=1 ttl=52 time=23.4 ms
64 bytes from www.eq-3.de (81.14.202.21): icmp_seq=2 ttl=52 time=22.0 ms
Nach Neustart ohne Veränderung. Habe dann nochmal einen Restore der CC3-Backupdatei durchgeführt, da ich vermutlich den ersten Restore noch mit der anderen ETH-Platine und dem anderen Funkmodul durchgeführt hatte. Auch keine Änderung am Systemverhalten.

Das Funkmodul der alten CCU3 wollte ich eigentlich nicht verwenden, da die CCU3 eben sporadisch Ausfallerscheinungen hatte und die RF-Module dann nur noch nach einem Neustart steuern wollte.

Schlammschlumpf
Beiträge: 17
Registriert: 31.03.2019, 13:08
Hat sich bedankt: 1 Mal

Re: debmatic - HB-REF-ETH - keine HmIP-Geräte

Beitrag von Schlammschlumpf » 29.05.2021, 09:43

Zur Vollständigkeit, da ich nicht weiß, ob es relevant ist: Die LED des RPI-RF-MOD blinkt übrigens grün blau abwechselnd.

Die CCU3 habe ich jetzt nochmal zum Test angeschlossen (bevor ich sie zerlege). Die CCU3 kann immer noch mit meinen HmIP-Geräten kommunizieren. Nächster Step. Ich zerlege die CCU3 und teste das RPI-RF-MOD auf dem ETH-Board.

Schlammschlumpf
Beiträge: 17
Registriert: 31.03.2019, 13:08
Hat sich bedankt: 1 Mal

Re: debmatic - HB-REF-ETH - keine HmIP-Geräte

Beitrag von Schlammschlumpf » 29.05.2021, 10:01

Hallo,

also das Modul der CCU3 auf das ETH-Board geschnallt und Reboot der debmatic. (Müsste ich sonst noch etwas machen (Werksreset des ETH-Moduls?))

Allgemein scheint die "debmatic" ein Problem zu haben, wenn das ETH-Modul kurzzeitig vom Strom genommen wird. Bei mir wird dann die Console der debmatic vollgeschrieben mir irgendwelchen Fehler, dass das ETH-Board nicht erreichbar wäre, selbst wenn es schon länger wieder verfügbar sein sollte.

Aber zurück zum Thema:
Leider hilft das RPI-RF-MOD aus der CCU3 auch nicht. Unverändert erkennt meine debmatic-Instanz nur die HmRF-Geräte und keine Möglichkeit HmIP Geräte anzulernen. :cry:

Schlammschlumpf
Beiträge: 17
Registriert: 31.03.2019, 13:08
Hat sich bedankt: 1 Mal

Re: debmatic - HB-REF-ETH - keine HmIP-Geräte

Beitrag von Schlammschlumpf » 29.05.2021, 10:28

Als nächsten Test habe ich nun in die alte CCU3 eines der neuen RPI-RF-MOD eingebaut. Da dies funktioniert, würde ich persönlich nun sowohl das neue RPI-RF-MOD als auch ein Netzwerkproblem beim Key-Austausch mit EQ3 als Problem ausschließen.

Verbleibende Ursachen:
  • HB-REF-ETH - Hardware
  • HB-REF-ETH - Software (Firmware/Treiber)
  • debmatic - Konfiguration
oder übersehe ich etwas? Wie kann ich vorgehen um das Problem weiter einzugrenzen?

Schlammschlumpf
Beiträge: 17
Registriert: 31.03.2019, 13:08
Hat sich bedankt: 1 Mal

Re: debmatic - HB-REF-ETH - keine HmIP-Geräte

Beitrag von Schlammschlumpf » 29.05.2021, 12:19

Um auch mein "Restore" auszuschließen habe ich nun auch eine neue debmatic-Instanz installiert. Meine zuerst neu gekaufte ETH-Platine zusammen mit dem Funk-Modul der CCU3 im Netzwerk platziert. Auch dort kommt (ohne jegliches Gerät) der Fehler und HmIP-Geräte können nicht angelernt werden.

Was kann ich noch probieren? (Bin kurz davor noch meinen alten RPi3 zu suchen und es dort mal mit der debmatic probieren.

Matthias K.
Beiträge: 1170
Registriert: 14.02.2016, 12:32
System: Alternative CCU (auf Basis OCCU)
Wohnort: Heidenheim
Hat sich bedankt: 57 Mal
Danksagung erhalten: 225 Mal

Re: debmatic - HB-REF-ETH - keine HmIP-Geräte

Beitrag von Matthias K. » 29.05.2021, 12:40

Schlammschlumpf hat geschrieben:
29.05.2021, 10:01
Allgemein scheint die "debmatic" ein Problem zu haben, wenn das ETH-Modul kurzzeitig vom Strom genommen wird. Bei mir wird dann die Console der debmatic vollgeschrieben mir irgendwelchen Fehler, dass das ETH-Board nicht erreichbar wäre, selbst wenn es schon länger wieder verfügbar sein sollte.
Dazu solltest du folgendes beachten: Wenn du das HB-RF-ETH neustartest / vom Strom nimmst, ist das Funkmodul danach nicht mehr initialisiert, d.h. debmatic bzw. der RFD kann nicht mehr darauf zugreifen. Du musst dann erst debmatic neustarten (bzw. besser den ganzen Host). Daher: Finger weg von Neustarts des HB-RF-ETH während debmatic läuft.

Benutzeravatar
deimos
Beiträge: 5396
Registriert: 20.06.2017, 10:38
System: Alternative CCU (auf Basis OCCU)
Wohnort: Leimersheim
Hat sich bedankt: 121 Mal
Danksagung erhalten: 957 Mal
Kontaktdaten:

Re: debmatic - HB-REF-ETH - keine HmIP-Geräte

Beitrag von deimos » 29.05.2021, 15:11

Hi,

gelb/blaues Blinken bedeutet Problrme mit der Netzwerkkonnektivität, im Log steht eindeutig, dass es bei Schlüsselaustausch Probleme beim Auflösen des DNS Namens des Keyservers gibt. Du kannst gerne alles mögliche an Hardware Versuchen starten, aber das wird das Problem nicht lösen, sondern eher verschlimmern, weil du dadurch mehrere Rekeyings anfängst, aber nicht abschließt.

Wie sieht denn deine /etc/resolv.conf aus?

Und in deiner Ausgabe steht was von Link 2, was ist mit Link 1?

Viele Grüße
Alex

Schlammschlumpf
Beiträge: 17
Registriert: 31.03.2019, 13:08
Hat sich bedankt: 1 Mal

Re: debmatic - HB-REF-ETH - keine HmIP-Geräte

Beitrag von Schlammschlumpf » 29.05.2021, 18:34

Hallo Alex,

vielen Dank für Deine Geduld! Mir ist halt nicht klar, warum eine frische debmatic-Installation Keys austauschen müsste oder warum meine CCU3 mit einem anderen Funkmodul dies nicht muss. Da fehlt mir halt komplett der technische Background. Daher bitte ich Dich meine Fehlannahmen zu entschuldigen. Ebenfalls der irreführende Hinweis mit der blinkenden LED. Das scheint nur eine Steckdose gewesen zu sein, die die CCU nicht erreichen kann. Nach Löschung des Gerätes leuchtet die LED nun stabil blau.


Es gibt keinen Link1 - hier der output im Gesamten:

Code: Alles auswählen

systemd-resolve --status
Global
       LLMNR setting: no
MulticastDNS setting: no
  DNSOverTLS setting: no
      DNSSEC setting: no
    DNSSEC supported: no
          DNSSEC NTA: 10.in-addr.arpa
                      16.172.in-addr.arpa
                      168.192.in-addr.arpa
                      17.172.in-addr.arpa
                      18.172.in-addr.arpa
                      19.172.in-addr.arpa
                      20.172.in-addr.arpa
                      21.172.in-addr.arpa
                      22.172.in-addr.arpa
                      23.172.in-addr.arpa
                      24.172.in-addr.arpa
                      25.172.in-addr.arpa
                      26.172.in-addr.arpa
                      27.172.in-addr.arpa
                      28.172.in-addr.arpa
                      29.172.in-addr.arpa
                      30.172.in-addr.arpa
                      31.172.in-addr.arpa
                      corp
                      d.f.ip6.arpa
                      home
                      internal
                      intranet
                      lan
                      local
                      private
                      test

Link 2 (ens18)
      Current Scopes: DNS
DefaultRoute setting: yes
       LLMNR setting: yes
MulticastDNS setting: no
  DNSOverTLS setting: no
      DNSSEC setting: no
    DNSSEC supported: no
  Current DNS Server: 8.8.8.8
         DNS Servers: 8.8.8.8
                      8.8.4.4
                      fd00::e228:6dff:fe6b:85a2

Code: Alles auswählen

cat /etc/resolv.conf
# This file is managed by man:systemd-resolved(8). Do not edit.
#
# This is a dynamic resolv.conf file for connecting local clients to the
# internal DNS stub resolver of systemd-resolved. This file lists all
# configured search domains.
#
# Run "resolvectl status" to see details about the uplink DNS servers
# currently in use.
#
# Third party programs must not access this file directly, but only through the
# symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a different way,
# replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.

nameserver 127.0.0.53
options edns0 trust-ad
Nur um sicher zu gehen, dass ich jetzt mit dem ganzen Hard- und Softwaregewechsel nicht ein neues Problem geschaffen habe, hier nochmal alle angefragte Punkte:

Hier nochmal ein frisches Log 10 Minuten nach dem Neustart:
hmserver.log
(422.25 KiB) 34-mal heruntergeladen

Die Funkadresse des HmIP-Moduls scheint sich irgendwann verändert zu haben:

Code: Alles auswählen

sudo debmatic-info
debmatic version: 3.57.5-71
Kernel modules: Available
Raw UART dev:   Available
HMRF Hardware:  RPI-RF-MOD
 Connected via: HB-RF-ETH@192.168.0.43 (/dev/raw-uart)
 Board serial:  5A49940428
 Radio MAC:     0xFF0428
HMIP Hardware:  RPI-RF-MOD
 SGTIN:         3014F711A0001F5A49940428
 Radio MAC:     0xBF4B62
Hier kam ein Warning dazu:

Code: Alles auswählen

sudo systemctl status debmatic-hmserver
● debmatic-hmserver.service - debmatic hmserver
     Loaded: loaded (/lib/systemd/system/debmatic-hmserver.service; enabled; vendor preset: enabled)
     Active: active (running) since Sat 2021-05-29 18:21:09 CEST; 10min ago
    Process: 1116 ExecStart=/usr/share/debmatic/bin/start_hmserver.sh (code=exited, status=0/SUCCESS)
   Main PID: 1118 (java)
      Tasks: 32 (limit: 2280)
     Memory: 169.0M
     CGroup: /system.slice/debmatic-hmserver.service
             └─1118 /usr/bin/java -Xmx128m -Dlog4j.configuration=file:///etc/config/log4j.xml -Dfile.encoding=ISO-8859-1 -Dgnu.io.rxtx.SerialPorts=/dev/mmd_hmip -jar /opt/HMServer/HMIP>

May 29 18:17:08 debmatic systemd[1]: Starting debmatic hmserver...
May 29 18:17:10 debmatic start_hmserver.sh[1118]: Init Hardware Info
May 29 18:17:24 debmatic start_hmserver.sh[1118]: May 29, 2021 6:17:24 PM io.vertx.core.impl.BlockedThreadChecker
May 29 18:17:24 debmatic start_hmserver.sh[1118]: WARNING: Thread Thread[vert.x-eventloop-thread-1,5,main] has been blocked for 2374 ms, time limit is 2000
May 29 18:21:09 debmatic systemd[1]: Started debmatic hmserver.

Benutzeravatar
deimos
Beiträge: 5396
Registriert: 20.06.2017, 10:38
System: Alternative CCU (auf Basis OCCU)
Wohnort: Leimersheim
Hat sich bedankt: 121 Mal
Danksagung erhalten: 957 Mal
Kontaktdaten:

Re: debmatic - HB-REF-ETH - keine HmIP-Geräte

Beitrag von deimos » 29.05.2021, 19:03

Hi,

naja, wenn du Anlernen mit Internet auswählst, dann wird der Keyserver im Internet verwendet. Und wenn du das Funkmodul wechselst ist das auch erforderlich, wie oben bereits geschrieben.

Du könntest mal versuchen systemd-resolved zu deaktivieren (Anleitung z.B. https://gist.github.com/zoilomora/f7d26 ... 2cea2c844c). Mir war nicht bewusst, dass das mittlerweile Standard ist, da muss ich noch prüfen, ob das Probleme macht und ob man da ggf. irgendwie die Probleme umgehen kann.

Viele Grüße
Alex

Schlammschlumpf
Beiträge: 17
Registriert: 31.03.2019, 13:08
Hat sich bedankt: 1 Mal

Re: debmatic - HB-REF-ETH - keine HmIP-Geräte

Beitrag von Schlammschlumpf » 29.05.2021, 19:43

Hallo Alex,

bin nicht unbedingt ein LINUX-Nutzer, aber sieht mir danach aus, als ob der "NetworkManager" nicht Bestandteil meiner Ubuntu-Server Installation ist. Daher nur die folgenden Befehle ausgeführt:

sudo systemctl disable systemd-resolved.service
sudo systemctl stop systemd-resolved
sudo rm /etc/resolv.conf

Danach Reboot und ich hoffe, dass dieser Dienst dennoch nach dem Reboot beendet blieb::

Code: Alles auswählen

sudo journalctl -u systemd-resolved -f
-- Logs begin at Thu 2021-05-20 15:37:20 CEST. --
May 29 18:15:45 debmatic systemd[1]: Stopped Network Name Resolution.
-- Reboot --
May 29 18:16:49 debmatic systemd[1]: Starting Network Name Resolution...
May 29 18:16:49 debmatic systemd-resolved[644]: Positive Trust Anchors:
May 29 18:16:49 debmatic systemd-resolved[644]: . IN DS 20326 8 2 e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d
May 29 18:16:49 debmatic systemd-resolved[644]: Negative trust anchors: 10.in-addr.arpa 16.172.in-addr.arpa 17.172.in-addr.arpa 18.172.in-addr.arpa 19.172.in-addr.arpa 20.172.in-addr.arpa 21.172.in-addr.arpa 22.172.in-addr.arpa 23.172.in-addr.arpa 24.172.in-addr.arpa 25.172.in-addr.arpa 26.172.in-addr.arpa 27.172.in-addr.arpa 28.172.in-addr.arpa 29.172.in-addr.arpa 30.172.in-addr.arpa 31.172.in-addr.arpa 168.192.in-addr.arpa d.f.ip6.arpa corp home internal intranet lan local private test
May 29 18:16:49 debmatic systemd-resolved[644]: Using system hostname 'debmatic'.
May 29 18:16:49 debmatic systemd[1]: Started Network Name Resolution.
May 29 19:13:28 debmatic systemd[1]: Stopping Network Name Resolution...
May 29 19:13:28 debmatic systemd[1]: systemd-resolved.service: Succeeded.
May 29 19:13:28 debmatic systemd[1]: Stopped Network Name Resolution.
Leider ist das Fehlerbild unverändert.

Soll ich mal den vorkonfigurierten debmatic-Container installieren? (Um Betriebssystemthemen auszuschließen...)

Antworten

Zurück zu „debmatic“