Nach Neustart der CCU DRAP nicht mehr erreichbar

[joersch]

Moin!
Heute habe ich mal wieder einen sehr nervigen Effekt. Weil der Maler gerade durchs Haus geht, musste die CCU den Raum wechseln. Also: Runterfahren, umstöpseln, hochfahren, fertig, oder? Nein. Die CCU (CCU3 mit Raspimatic) startet problemlos und ist erreichbar. Der DRAP allerdings kann nicht angesprochen werden. Alle Funk-Aktoren funktionieren.

Stand:

• CCU ansprechbar (192.168.27.27).
• HMIP-Funk funtioniert
• HMIPW funktioniert nicht
• DRAP wird in der Fritte als online angezeigt und ist pingbar (192.168.27.26, Firmware 2.2.24)
• CCU erreicht ihn nicht "HmIPW-DRAP (00179BE9938402, IP: ) not connected"
• Wired Geräte "unter sich" funktionieren.
• Neustart des Wired Bus brachte keine Änderung.
• Im Net Finder werden CCU und DRAP problemlos angezeigt und können konfiguriert werden.

Code: Alles auswählen

root@nucserver:~# nmap -n 192.168.27.26
Starting Nmap 7.80 ( https://nmap.org ) at 2021-10-30 20:48 CEST
Nmap scan report for 192.168.27.26
Host is up (0.00027s latency).
All 1000 scanned ports on 192.168.27.26 are closed
MAC Address: 00:1A:22:16:53:82 (eQ-3 Entwicklung GmbH)

Nmap done: 1 IP address (1 host up) scanned in 7.45 seconds
root@nucserver:~# nmap -n 192.168.27.27
Starting Nmap 7.80 ( https://nmap.org ) at 2021-10-30 20:49 CEST
Nmap scan report for 192.168.27.27
Host is up (0.0014s latency).
Not shown: 988 closed ports
PORT     STATE SERVICE
22/tcp   open  ssh
80/tcp   open  http
443/tcp  open  https
1999/tcp open  tcp-id-port
2000/tcp open  cisco-sccp
2001/tcp open  dc
2010/tcp open  search
2121/tcp open  ccproxy-ftp
8088/tcp open  radan-http
8181/tcp open  intermapper
8701/tcp open  unknown
9099/tcp open  unknown
MAC Address: B8:27:EB:7D:26:3A (Raspberry Pi Foundation)

Nmap done: 1 IP address (1 host up) scanned in 0.21 seconds

Ich bin ratlos. Hat jemand zufällig eine Idee? Könnte ein Werksreset des DRAP helfen, oder mache ich mir damit noch mehr Probleme?

Grüße
Jörg

Ergänzung: Werksreset ist keine tolle Idee. Bus wurde von Ring auf separate Stränge umgestellt. E13 wird angezeigt. Umkonfiguration geht nicht, weil DRAP immer noch nicht erreichbar.

[joersch]

Welch ein abstruser Mist. Ich habe alles Mögliche ausprobiert, incl Werksreset DRAP, Löschen aus der CCU, anderer Switch, ohne Switch, etc. pp. Die EQ3 Hotline hat mich auch eine Weile ertragen dürfen - ohne Erfolg. Nun habe ich das CCU Backup von vor ein paar Tagen (bevor ich den DRAP gelöscht, aber nachdem ich umgezogen habe) eingespielt und es tut wieder. Erklärung? Fehlanzeige. So ein Verhalten liebe ich ja an Homematic IP - nicht.

Aber immerhin läuft es wieder.

[joersch]

Seit einer Weile ist das Problem übrigens wieder da. Keine Ursache auszumachen. Diverse male HMIPW stromlos gemacht, Raspimatic updates (mit Neustart) eingespielt, aber es geht nicht weg. Allerdings läuft die Ansteuerung von HMIPW problemlos. Nur eben eine nervige Meldung, die ich zwar bestätigen kann, welche aber direkt wieder erscheint. Blöd.

Diesmal aber mit IP...

HmIPW-DRAP (00179BE9938402, IP: 192.168.27.68) not connected

[Baxxy]

Die Watchdog-Meldung wird durch '/bin/updateDCVars.tcl' generiert.
https://github.com/jens-maus/RaspberryM ... #L394-L457

Das Script läuft jede Minute und (runtergebrochen auf dein Problem) liest den UNREACH Datenpunkt im Kanal:0 des DRAP aus.
Ist der "true" wird der Watchdog-Alarm getriggert.

Ich denke da ist irgendwas mit der Kommunikation hakelig, RM meldet das dann korrekt.

Abschalten geht, aber nur komplett. Also Verzicht auf DC/CS auf der Startseite und die Duty-Cycle SysVar(s) werden nicht mehr aktualisiert.
> Einstellungen > Systemsteuerung > erweiterte Einstellungen > Duty-Cycle Systemvariablen.

[joersch]

Ich denke da ist irgendwas mit der Kommunikation hakelig, RM meldet das dann korrekt.

Danke für die Erläuterung! Welche Kommunikation ist das dann? HMIP-Bus, oder LAN? Grundsätzlich funktioniert die Anlage ja problemlos. BUS ist im Ring verlegt und wird auf dem DRAP-Display als OK angezeigt. Die IP des DRAP (aus der Fritzbox) ist problemlos pingbar. Sehr seltsam...

Grüße
Jörg

[joersch]

Die Watchdog-Meldung wird durch '/bin/updateDCVars.tcl' generiert.
https://github.com/jens-maus/RaspberryM ... #L394-L457

Also ich habe mir jetzt mal den markierten Teil aus dem Script genommen und leicht modifiziert (Writeline, statt write, etc).

Code: Alles auswählen

string dev;
  foreach(dev, devices.Get().EnumUsedIDs()) {
    object oDev = dom.GetObject(dev);
    if(oDev.Label() == 'HmIPW-DRAP') {
      string name = oDev.Name();
      string chn;
      foreach(chn, oDev.Channels()) {
        object oChn = dom.GetObject(chn);
        if(oChn.Address().Contains(':0')) {
          integer connected = 0;
          integer overheat = 0;
          integer undervoltage = 0;
          if(oChn.DPByControl('MAINTENANCE.UNREACH').Value() == false) {
            connected = 1;
            temp = oChn.DPByControl('MAINTENANCE.ERROR_OVERHEAT').Value().ToInteger();
            undervoltage = oChn.DPByControl('MAINTENANCE.ERROR_UNDERVOLTAGE').Value().ToInteger();
          }
          WriteLine(' ADDRESS '#oDev.Address());
          WriteLine(' NAME {'#oDev.Name()#'}');
          WriteLine(' IP {'#oChn.DPByControl('MAINTENANCE.IP_ADDRESS').Value()#'}');
          WriteLine(' CONNECTED '#connected);
          WriteLine(' OVERHEAT '#overheat);
          WriteLine(' UNDERVOLTAGE '#undervoltage);
          WriteLine(' TYPE HMIPW-DRAP} ');
        }
      }
    }
  }

Ich habe zuerst mal den Alarm bestätigt und laufen lassen. Dann eben, als der Alarm wieder aufgetreten ist, noch einmal. Output ist identisch.

Code: Alles auswählen

 ADDRESS 00179BE9938402
 NAME {0KG-231-HmIPW-DRAP:8402}
 IP {192.168.27.68}
 CONNECTED 1
 OVERHEAT 0
 UNDERVOLTAGE 0
 TYPE HMIPW-DRAP} 

Der DRAP ist über die IP pingbar. Er hatte eben beim wegklicken 3 mal ausgelöst. Irgendwie scheint da was "wackelig" und scheint sich dann wohl selbst zu heilen - nur das eben die Meldung stehen bleibt...

[Baxxy]

Ja, komisch ist das schon.
Wenn der DRAP wirklich unreach wäre (das triggert ja den WatchDog-Alarm) müsste es eigentlich auch eine Servicemeldung geben.
Oder die kommt/geht im ms-Bereich so das man sie nie bemerkt.
Das ist dann aber wieder unrealistisch weil ja das Script nur jede Minute läuft und genau in dem Moment auf "UNREACH = true" treffen müsste um den Watchdog-Alarm zu triggern.

nur das eben die Meldung stehen bleibt...

Ja, das ist so. Watchdog-Alarme werden nur ausgelöst. Quittieren muss man selber.
Kann man zur Not auch per WebUI-Programm machen.

Code: Alles auswählen

WENN Watchdog_xyz ausgelöst bei Änderung
und 
DRAP UNREACH false prüfen
DANN Watchdog_xyz nicht ausgelöst

Ist aber kein schöner Workaround.

Stell mal Kanal:0 vom DRAP auf protokolliert, vielleicht sieht man was.