Skip to content
  • Home
  • Aktuell
  • Tags
  • 0 Ungelesen 0
  • Kategorien
  • Unreplied
  • Beliebt
  • GitHub
  • Docu
  • Hilfe
Skins
  • Light
  • Brite
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Standard: (Kein Skin)
  • Kein Skin
Einklappen
ioBroker Logo

Community Forum

donate donate
  1. ioBroker Community Home
  2. Deutsch
  3. Error/Bug
  4. hm-rpc unerklärliche Abstürze, evtl zu hohes Anfragevolumen?

NEWS

  • Neuer Blogbeitrag: Monatsrückblick - Dezember 2025 🎄
    BluefoxB
    Bluefox
    11
    1
    337

  • Weihnachtsangebot 2025! 🎄
    BluefoxB
    Bluefox
    24
    1
    1.6k

  • UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?
    apollon77A
    apollon77
    48
    3
    9.5k

hm-rpc unerklärliche Abstürze, evtl zu hohes Anfragevolumen?

Geplant Angeheftet Gesperrt Verschoben Error/Bug
8 Beiträge 5 Kommentatoren 700 Aufrufe 4 Watching
  • Älteste zuerst
  • Neuste zuerst
  • Meiste Stimmen
Antworten
  • In einem neuen Thema antworten
Anmelden zum Antworten
Dieses Thema wurde gelöscht. Nur Nutzer mit entsprechenden Rechten können es sehen.
  • maduutoM Offline
    maduutoM Offline
    maduuto
    schrieb am zuletzt editiert von
    #1

    Hallo. Urplötzlich konnte hm-rpc keine Verbindung aufbauen, was ich nur gemerkt habe weil ein Skript hätte anlaufen müssen. Blöderweise habe ich die Logfile gelöscht. Nun versuche ich aber das einzuschränken. Was ich allgemein gemerkt habe, wenn hmrpc abstürzt, kann ich es erst wieder verbinden, wenn ich javascript stoppe.

    Meine Vermutung, dass einer meiner Skripte einen üblen Anfragensturm an die CCU sendet, z.b. aktor immer ausschalten, ausschalten, ausschalten obwohl aus. Frage: Kann ich das Rausfiltern, was Javascript ständig macht?

    Nun habe ich RPC auf Debug und bekomme im Sekundentakt eine Meldung ähnlicher Art:
    hm-rpc.0.00175A498C5CBA.6.STATE ==> UNIT: "undefined" (min: undefined, max: undefined) From "false" => "false"

    Ist nicht immer der gleiche Aktor. Hat die Meldung was zu sagen oder irrelevant?

    Danke ;)
    MfG

    M 2 Antworten Letzte Antwort
    0
    • maduutoM maduuto

      Hallo. Urplötzlich konnte hm-rpc keine Verbindung aufbauen, was ich nur gemerkt habe weil ein Skript hätte anlaufen müssen. Blöderweise habe ich die Logfile gelöscht. Nun versuche ich aber das einzuschränken. Was ich allgemein gemerkt habe, wenn hmrpc abstürzt, kann ich es erst wieder verbinden, wenn ich javascript stoppe.

      Meine Vermutung, dass einer meiner Skripte einen üblen Anfragensturm an die CCU sendet, z.b. aktor immer ausschalten, ausschalten, ausschalten obwohl aus. Frage: Kann ich das Rausfiltern, was Javascript ständig macht?

      Nun habe ich RPC auf Debug und bekomme im Sekundentakt eine Meldung ähnlicher Art:
      hm-rpc.0.00175A498C5CBA.6.STATE ==> UNIT: "undefined" (min: undefined, max: undefined) From "false" => "false"

      Ist nicht immer der gleiche Aktor. Hat die Meldung was zu sagen oder irrelevant?

      Danke ;)
      MfG

      M Offline
      M Offline
      MarkusK
      schrieb am zuletzt editiert von
      #2

      @maduuto Ich habe auch seit geraumer Zeit (entweder nach Update der CCU3 oder des RPC Adapters) Probleme mit dem Adapter. Bei mir Crashed ein Prozess in der CCU3, welcher Verbindungen annimmt. Das geht soweit, dass man in der CCU3 keine Einstellungen mehr an den virutellen Gerätem mehr machen kann (z.B. in der Gruppen). Außerdem meldest die CCU3 kurz nach dem Login eine internen Fehler. Gelöst bekommt man das Problem nur wenn man die CCU3 neu startet und den RPC Adapter abschaltet. Aktuell kann ich den Adapter deshalb leider nicht mehr nutzen. EQ-3 (Homematic) schiebt den Fehler auf den IOBroker, bzw. sagen, die unterstüzten Fehler durch externe Software nicht. Ich habe bereits bei GIT-Hub einen Fehler bei dem Adapter aufgemacht.

      1 Antwort Letzte Antwort
      0
      • maduutoM maduuto

        Hallo. Urplötzlich konnte hm-rpc keine Verbindung aufbauen, was ich nur gemerkt habe weil ein Skript hätte anlaufen müssen. Blöderweise habe ich die Logfile gelöscht. Nun versuche ich aber das einzuschränken. Was ich allgemein gemerkt habe, wenn hmrpc abstürzt, kann ich es erst wieder verbinden, wenn ich javascript stoppe.

        Meine Vermutung, dass einer meiner Skripte einen üblen Anfragensturm an die CCU sendet, z.b. aktor immer ausschalten, ausschalten, ausschalten obwohl aus. Frage: Kann ich das Rausfiltern, was Javascript ständig macht?

        Nun habe ich RPC auf Debug und bekomme im Sekundentakt eine Meldung ähnlicher Art:
        hm-rpc.0.00175A498C5CBA.6.STATE ==> UNIT: "undefined" (min: undefined, max: undefined) From "false" => "false"

        Ist nicht immer der gleiche Aktor. Hat die Meldung was zu sagen oder irrelevant?

        Danke ;)
        MfG

        M Offline
        M Offline
        MarkusK
        schrieb am zuletzt editiert von MarkusK
        #3

        @maduuto Ich habe jetzt die auf der CCU3 die Version 3.65.11 installiert und parallel die Abfrageintervalle und Timeouts beim Adapter verdoppelt, wobei die Timeouts sicherlich keine Rolle spielen. Es läuft auch nach einem Tag noch und die CCU3 bringt im moment auch keine Fehlermeldung. Teile der CCU3 stürzte wieder nach über ein Tag ab. Gruppen ließen sich aufgrund eines "internen Fehlers" wieder nicht bearbeiten.
        Ich habe in den Releasenotes der CCU3 Firmwares gesehen, dass an der Version bevor ich die Probleme bekommen habe zur darauffolgenden Version mit dem Problem am crashenden rfd Deamon Änderungen gemacht wurden. Das könnte natürlich Fehler reingebracht haben. Allerdings gab es in den darauffolgenden Releasenotes keine Hinweise auf den Bug oder einem möglichen Fix.

        Scheinbar werden aber jetzt die Datenpunkte trotz laufender Instanzen nicht mehr regelmäßig aktualisiert. Eine Aktualisierung findet nur noch beim Instanzenstart statt. Debug bringt keine relevanten Infos.

        Edit:

        1 Antwort Letzte Antwort
        1
        • P Offline
          P Offline
          Piemur
          schrieb am zuletzt editiert von
          #4

          Das Verhalten kann ich bestätigen.
          Schalte ich den HM-RPC.0 RFD (XML-RPC) Port 42001 dazu, stürzt meine CCU3 kurz danach ab.
          Die Instanz selbst ist "grün" und das Protokoll unauffällig.

          HM-RPC.0 HM-IP (XML-RPC) ist grün, aber Geräte in den Objekten sind angelegt, allerdings finde ich nur im Kanal0 Datenpunkte.
          Alle anderen sind leer.

          HomoranH 1 Antwort Letzte Antwort
          0
          • P Piemur

            Das Verhalten kann ich bestätigen.
            Schalte ich den HM-RPC.0 RFD (XML-RPC) Port 42001 dazu, stürzt meine CCU3 kurz danach ab.
            Die Instanz selbst ist "grün" und das Protokoll unauffällig.

            HM-RPC.0 HM-IP (XML-RPC) ist grün, aber Geräte in den Objekten sind angelegt, allerdings finde ich nur im Kanal0 Datenpunkte.
            Alle anderen sind leer.

            HomoranH Nicht stören
            HomoranH Nicht stören
            Homoran
            Global Moderator Administrators
            schrieb am zuletzt editiert von
            #5

            @piemur sagte in hm-rpc unerklärliche Abstürze, evtl zu hohes Anfragevolumen?:

            HM-RPC.0 HM-IP (XML-RPC) ist grün, aber Geräte in den Objekten sind angelegt, allerdings finde ich nur im Kanal0 Datenpunkte.
            Alle anderen sind leer.

            auch hm-rpc.0? selbe Instanz für RF undIP?
            Das geht nicht!

            kein Support per PN! - Fragen im Forum stellen - es gibt fast nichts, was nicht auch für andere interessant ist.

            Benutzt das Voting rechts unten im Beitrag wenn er euch geholfen hat.

            der Installationsfixer: curl -fsL https://iobroker.net/fix.sh | bash -

            P 1 Antwort Letzte Antwort
            0
            • HomoranH Homoran

              @piemur sagte in hm-rpc unerklärliche Abstürze, evtl zu hohes Anfragevolumen?:

              HM-RPC.0 HM-IP (XML-RPC) ist grün, aber Geräte in den Objekten sind angelegt, allerdings finde ich nur im Kanal0 Datenpunkte.
              Alle anderen sind leer.

              auch hm-rpc.0? selbe Instanz für RF undIP?
              Das geht nicht!

              P Offline
              P Offline
              Piemur
              schrieb am zuletzt editiert von
              #6

              @homoran Nein, sorry hab mich gestern abend vertippt. Bin neu hier und hab mich grad erst gestern registriert.
              Aber danke für den Hinweis

              Meine Instanzen sind soweit IO eingestellt und ich verwende die Standard-Ports
              hm-rpc.0 RFD (XML-RPC) auf Port 42001
              hm-rpc.1 HomeMaticIP (XML-RPC) auf Port 42010
              hm-rpc.2 CuxD (BIN-RPC) auf Port 8701
              hm-rpc.3 VirtualDev auf Port 49292
              Ports sind in der CCU3 (3.65.11) freigegeben und die ioBroker-IP/WinLaptop ebenfalls.
              (CCU-Firewall: Ports blockiert, alles andere eingeschränkt, Ports freigegeben, 3x IPs freigegen IP/WinLaptop, CCUselbst und fritzbox)
              Die CallBack-Id sind auf IObroker WinLaptop (hab leider keinen RapsberryPi mehr bekommen)

              Alle Instanzen hm-rpc.1-3 werde bei Start auch "grün", von da her sollte es passen.

              IM hm.rega.0 sind die Instanzen konfiguriert und aktiviert.
              Wenn ich hm.rega.0 alleine laufen lasse oder mit hm-rpc.1-3, hängt sich die CCU3 nicht auf.

              Schalte ich hm-rpc.0 dazu, hängt sich die CCU auf. (Schön zu sehen, wenn auf der Startseite der CCU3 keine Firmware Version angezeigt wird. Hier hilft nur ein Reset der CCU3
              Im Protokoll hm-rpc.0 wird die Verbindung gestartet, mal kommt ein Connect mal nicht,
              je nachdem wann sich die CCU aufhängt.

              Wie gesagt, das passt zu dem beschriebenen Fehlerbild und ich wollte es bestätigen.

              Warum mir keine Datenpunkte unter hm-rpc.1 angezeigt werden (nur Kanal 0, von hm.rega.0 geschrieben) ist, denke ich ein anderes Thema. Hierzu bin ich noch am suchen, aber da rpc.0 meine CCU aufhängt, hab ich noch keine Idee woran dies liegen kann.

              HomoranH bahnuhrB 2 Antworten Letzte Antwort
              0
              • P Piemur

                @homoran Nein, sorry hab mich gestern abend vertippt. Bin neu hier und hab mich grad erst gestern registriert.
                Aber danke für den Hinweis

                Meine Instanzen sind soweit IO eingestellt und ich verwende die Standard-Ports
                hm-rpc.0 RFD (XML-RPC) auf Port 42001
                hm-rpc.1 HomeMaticIP (XML-RPC) auf Port 42010
                hm-rpc.2 CuxD (BIN-RPC) auf Port 8701
                hm-rpc.3 VirtualDev auf Port 49292
                Ports sind in der CCU3 (3.65.11) freigegeben und die ioBroker-IP/WinLaptop ebenfalls.
                (CCU-Firewall: Ports blockiert, alles andere eingeschränkt, Ports freigegeben, 3x IPs freigegen IP/WinLaptop, CCUselbst und fritzbox)
                Die CallBack-Id sind auf IObroker WinLaptop (hab leider keinen RapsberryPi mehr bekommen)

                Alle Instanzen hm-rpc.1-3 werde bei Start auch "grün", von da her sollte es passen.

                IM hm.rega.0 sind die Instanzen konfiguriert und aktiviert.
                Wenn ich hm.rega.0 alleine laufen lasse oder mit hm-rpc.1-3, hängt sich die CCU3 nicht auf.

                Schalte ich hm-rpc.0 dazu, hängt sich die CCU auf. (Schön zu sehen, wenn auf der Startseite der CCU3 keine Firmware Version angezeigt wird. Hier hilft nur ein Reset der CCU3
                Im Protokoll hm-rpc.0 wird die Verbindung gestartet, mal kommt ein Connect mal nicht,
                je nachdem wann sich die CCU aufhängt.

                Wie gesagt, das passt zu dem beschriebenen Fehlerbild und ich wollte es bestätigen.

                Warum mir keine Datenpunkte unter hm-rpc.1 angezeigt werden (nur Kanal 0, von hm.rega.0 geschrieben) ist, denke ich ein anderes Thema. Hierzu bin ich noch am suchen, aber da rpc.0 meine CCU aufhängt, hab ich noch keine Idee woran dies liegen kann.

                HomoranH Nicht stören
                HomoranH Nicht stören
                Homoran
                Global Moderator Administrators
                schrieb am zuletzt editiert von
                #7

                @piemur sagte in hm-rpc unerklärliche Abstürze, evtl zu hohes Anfragevolumen?:

                Meine Instanzen sind soweit IO eingestellt und ich verwende die Standard-Ports

                bitte zeigen!
                https://forum.iobroker.net/topic/51555/hinweise-für-gute-forenbeiträge/1

                @piemur sagte in hm-rpc unerklärliche Abstürze, evtl zu hohes Anfragevolumen?:

                Alle Instanzen hm-rpc.1-3 werde bei Start auch "grün", von da her sollte es passen.

                nicht unbedingt.
                Instanz (!) auf debug stellen und neu starten.

                @piemur sagte in hm-rpc unerklärliche Abstürze, evtl zu hohes Anfragevolumen?:

                Schön zu sehen,

                auch im syslog der ccu?

                @piemur sagte in hm-rpc unerklärliche Abstürze, evtl zu hohes Anfragevolumen?:

                denke ich ein anderes Thema.

                achso. das wollte ich eigentlich gerade angehen

                kein Support per PN! - Fragen im Forum stellen - es gibt fast nichts, was nicht auch für andere interessant ist.

                Benutzt das Voting rechts unten im Beitrag wenn er euch geholfen hat.

                der Installationsfixer: curl -fsL https://iobroker.net/fix.sh | bash -

                1 Antwort Letzte Antwort
                0
                • P Piemur

                  @homoran Nein, sorry hab mich gestern abend vertippt. Bin neu hier und hab mich grad erst gestern registriert.
                  Aber danke für den Hinweis

                  Meine Instanzen sind soweit IO eingestellt und ich verwende die Standard-Ports
                  hm-rpc.0 RFD (XML-RPC) auf Port 42001
                  hm-rpc.1 HomeMaticIP (XML-RPC) auf Port 42010
                  hm-rpc.2 CuxD (BIN-RPC) auf Port 8701
                  hm-rpc.3 VirtualDev auf Port 49292
                  Ports sind in der CCU3 (3.65.11) freigegeben und die ioBroker-IP/WinLaptop ebenfalls.
                  (CCU-Firewall: Ports blockiert, alles andere eingeschränkt, Ports freigegeben, 3x IPs freigegen IP/WinLaptop, CCUselbst und fritzbox)
                  Die CallBack-Id sind auf IObroker WinLaptop (hab leider keinen RapsberryPi mehr bekommen)

                  Alle Instanzen hm-rpc.1-3 werde bei Start auch "grün", von da her sollte es passen.

                  IM hm.rega.0 sind die Instanzen konfiguriert und aktiviert.
                  Wenn ich hm.rega.0 alleine laufen lasse oder mit hm-rpc.1-3, hängt sich die CCU3 nicht auf.

                  Schalte ich hm-rpc.0 dazu, hängt sich die CCU auf. (Schön zu sehen, wenn auf der Startseite der CCU3 keine Firmware Version angezeigt wird. Hier hilft nur ein Reset der CCU3
                  Im Protokoll hm-rpc.0 wird die Verbindung gestartet, mal kommt ein Connect mal nicht,
                  je nachdem wann sich die CCU aufhängt.

                  Wie gesagt, das passt zu dem beschriebenen Fehlerbild und ich wollte es bestätigen.

                  Warum mir keine Datenpunkte unter hm-rpc.1 angezeigt werden (nur Kanal 0, von hm.rega.0 geschrieben) ist, denke ich ein anderes Thema. Hierzu bin ich noch am suchen, aber da rpc.0 meine CCU aufhängt, hab ich noch keine Idee woran dies liegen kann.

                  bahnuhrB Online
                  bahnuhrB Online
                  bahnuhr
                  Forum Testing Most Active
                  schrieb am zuletzt editiert von bahnuhr
                  #8

                  @piemur sagte in hm-rpc unerklärliche Abstürze, evtl zu hohes Anfragevolumen?:

                  Meine Instanzen sind soweit IO eingestellt und ich verwende die Standard-Ports
                  hm-rpc.0 RFD (XML-RPC) auf Port 42001
                  hm-rpc.1 HomeMaticIP (XML-RPC) auf Port 42010
                  hm-rpc.2 CuxD (BIN-RPC) auf Port 8701
                  hm-rpc.3 VirtualDev auf Port 49292

                  Standard Ports sind dies aber nicht.
                  Lt. Anleitung:
                  60f8cc14-cc04-48f2-b7be-9f402aa4265a-image.png

                  Folgende Fragen:
                  warum https?
                  cuxd auf 8701 dürfte nicht funktionieren (vgl. Anleitung)

                  Und das Übliche:
                  screenshot von:

                  • ccu3 mit Original FW oder raspberrymatic
                  • firewall von ccu
                  • hm-rega
                  • alle hm-rpc

                  weiter:
                  hast du viele Scripts auf der ccu3 (gab früher mal Probleme), etc.

                  Einfach halten: Standard Ports, etc.
                  Aus meiner sicht gab es seit mehreren jahren keine Probleme mit ccu2 oder ccu3 und hm-rega, etc.
                  (wenn man es richtig einstellt).

                  Und zu guter letzt; das was @Homoran schon schrieb:
                  https://forum.iobroker.net/topic/51555/hinweise-für-gute-forenbeiträge/1


                  Wenn ich helfen konnte, dann Daumen hoch (Pfeil nach oben)!
                  Danke.
                  gute Forenbeiträge: https://forum.iobroker.net/topic/51555/hinweise-f%C3%BCr-gute-forenbeitr%C3%A4ge
                  ScreenToGif :https://www.screentogif.com/downloads.html

                  1 Antwort Letzte Antwort
                  1
                  Antworten
                  • In einem neuen Thema antworten
                  Anmelden zum Antworten
                  • Älteste zuerst
                  • Neuste zuerst
                  • Meiste Stimmen


                  Support us

                  ioBroker
                  Community Adapters
                  Donate

                  699

                  Online

                  32.5k

                  Benutzer

                  81.7k

                  Themen

                  1.3m

                  Beiträge
                  Community
                  Impressum | Datenschutz-Bestimmungen | Nutzungsbedingungen | Einwilligungseinstellungen
                  ioBroker Community 2014-2025
                  logo
                  • Anmelden

                  • Du hast noch kein Konto? Registrieren

                  • Anmelden oder registrieren, um zu suchen
                  • Erster Beitrag
                    Letzter Beitrag
                  0
                  • Home
                  • Aktuell
                  • Tags
                  • Ungelesen 0
                  • Kategorien
                  • Unreplied
                  • Beliebt
                  • GitHub
                  • Docu
                  • Hilfe