Navigation

    Logo
    • Register
    • Login
    • Search
    • Recent
    • Tags
    • Unread
    • Categories
    • Unreplied
    • Popular
    • GitHub
    • Docu
    • Hilfe
    1. Home
    2. Deutsch
    3. Error/Bug
    4. Adapter hm-rpc friert CCU2 ein

    NEWS

    • Neuer Blog: Fotos und Eindrücke aus Solingen

    • ioBroker@Smart Living Forum Solingen, 14.06. - Agenda added

    • ioBroker goes Matter ... Matter Adapter in Stable

    Adapter hm-rpc friert CCU2 ein

    This topic has been deleted. Only users with topic management privileges can see it.
    • ?
      A Former User last edited by

      Danke für die Antwort. Das mit "debug" kannte ich noch nicht, habs jetzt eingestellt.

      Das Dumme:

      Bin die letzten zwei Wochen nicht ans Gerät rangekommen (deshalb auch die späte Antwort, sorry)

      Meine provisorische Lösung war, den hm-rpc-Adapter einfach nach Start des PCs über Autostart mit einer Batchdatei neu zu starten.

      Einfach: c:\iobroker\iobroker restart hm-rpc

      Das hat geklpappt.

      Zwei Wochen lief nun alles reibungslos.

      Heute Abend hatte ich mal Zeit, diese Notlösung zu deaktivieren und wieder nach dem Bug zu suchen.

      Und jetzt kann ich ihn nicht mehr reproduzieren!

      Ahh! ich werde noch wahnsinnig. Vor zwei Wochen konnte ich die CCU mit einem simplen Neustart des PCs noch gezielt einfrieren lassen - und mit einem refresh des Adapters wieder alles ans Laufen bringen.

      Jetzt läuft es auch so - und in den DEBUG-Logs krieg ich also folglich keine Fehlermeldung.

      Ich kann über die beiden Wochen auch keine Updates erkennen. Weder in den Adaptern

      admin 0.7.2

      hm-rpc 0.5.2

      sockets.io 1.2.3 (oder war das 1.2.2? hm…)

      noch in iobroker.js-controller 0.8.2

      noch in node.js 0.10.35

      oder npm 1.4.28

      Hm...

      Mir bleibt nur eins: Ich melde mich wieder, sobald ich was rausgefunden habe.

      Die autostart.bat lasse ich solange trotzdem sicherheitshalber drin.

      Achso: Zwischendurch hatte ich mal das hier gefunden:

                      2016-01-07 19:57:34	info	instance system.adapter.hm-rpc.0 terminated with code 6 (uncaught exception)
      Error:	2016-01-07 19:57:34	error	at TCP.onread (net.js:559:19)
      Error:	2016-01-07 19:57:34	error	at errnoException (net.js:905:11)
      Error:	2016-01-07 19:57:34	error	read ECONNRESET
      uncaught	2016-01-07 19:57:34	error	exception: read ECONNRESET
      
      

      Da ist aus irgendwelchen Gründen beim einloggen der Adapter nicht gestartet.

      Aber ich glaube, das hat nichts damit zu tun, oder?

      1 Reply Last reply Reply Quote 0
      • ?
        A Former User last edited by

        Habs DOCH NOCH reproduzieren können!

        Ich musste nur ein, zwei Minuten den Rechner auslassen.

        Jetzt friert der PC die CCU2 wieder ein.

        ALso nochmal Ablauf:

        PC aus.

        CCU2 funktioniert.

        PC an.

        Bis zum Login und PIN-Eingabe.

        CCU2 reagiert nicht mehr.

        Einloggen.

        iobroker-WebUI aufrufen: Alle Adapter laufen, aber NICHTS im Log.

        Neustart hm-rpc-Adapters: Log füllt sich und CCU2 reagiert wieder.

        Interessant ist:

        Wenn ich den PC bei eingefrorener CCU2 ausmache, bleibt sie eingefroren = Lässt sich nicht mehr bedienen.

        Erst wenn ich den PC wieder anmache und den Adapter neu starte (oder der CCU den Stecker ziehe), reagiert die CCU wieder.

        Das hier stand im Log, nachdem ich den hm-rpc-Adapter neu gestartet habe (vorher war wie gesagt nichts drin):

        TARDIS	2016-01-08 00:04:52	warn	host.TARDIS instance system.adapter.hm-rpc.0 already running with pid 8088
        TARDIS	2016-01-08 00:04:52	warn	host.TARDIS instance system.adapter.hm-rpc.0 already running with pid 8088
        hm-rpc.0	2016-01-08 00:04:30	debug	inMem message hm-rpc.0.* hm-rpc.0.LEQ0478264.1.STATE
        hm-rpc.0	2016-01-08 00:04:30	debug	inMem message hm-rpc.0.* hm-rpc.0.LEQ0478264.1.WORKING
        hm-rpc.0	2016-01-08 00:04:30	debug	hm-rpc.0 binrpc <- event ["hm-rpc.0","LEQ0478264:1","STATE",true]
        hm-rpc.0	2016-01-08 00:04:30	debug	hm-rpc.0 binrpc <- event ["hm-rpc.0","LEQ0478264:1","WORKING",false]
        hm-rpc.0	2016-01-08 00:04:30	debug	inMem message hm-rpc.0.* hm-rpc.0.LEQ0478010.0.UNREACH
        hm-rpc.0	2016-01-08 00:04:30	debug	hm-rpc.0 binrpc <- event ["hm-rpc.0","LEQ0478010:0","UNREACH",true]
        hm-rpc.0	2016-01-08 00:04:30	debug	inMem message hm-rpc.0.* hm-rpc.0.LEQ0478161.1.WORKING
        hm-rpc.0	2016-01-08 00:04:30	info	hm-rpc.0 binrpc -> 103 devices
        hm-rpc.0	2016-01-08 00:04:30	debug	inMem message hm-rpc.0.* hm-rpc.0.LEQ0478161.1.STATE
        hm-rpc.0	2016-01-08 00:04:30	debug	hm-rpc.0 binrpc <- event ["hm-rpc.0","LEQ0478161:1","WORKING",false]
        hm-rpc.0	2016-01-08 00:04:30	info	hm-rpc.0 binrpc <- listDevices ["hm-rpc.0"]
        hm-rpc.0	2016-01-08 00:04:30	debug	hm-rpc.0 binrpc <- event ["hm-rpc.0","LEQ0478161:1","STATE",false]
        hm-rpc.0	2016-01-08 00:04:30	info	hm-rpc.0 binrpc <- system.listMethods ["hm-rpc.0"]
        hm-rpc.0	2016-01-08 00:04:29	debug	inMem message hm-rpc.0.* hm-rpc.0.LEQ0807702.5.PRESS_SHORT
        hm-rpc.0	2016-01-08 00:04:29	debug	inMem message hm-rpc.0.* hm-rpc.0.LEQ0807702.5.PRESS_SHORT
        hm-rpc.0	2016-01-08 00:04:29	debug	inMem message hm-rpc.0.* hm-rpc.0.LEQ0807702.5.PRESS_SHORT
        hm-rpc.0	2016-01-08 00:04:29	debug	inMem message hm-rpc.0.* hm-rpc.0.LEQ0807702.5.PRESS_SHORT
        hm-rpc.0	2016-01-08 00:04:29	debug	inMem message hm-rpc.0.* hm-rpc.0.LEQ0807702.5.PRESS_SHORT
        hm-rpc.0	2016-01-08 00:04:29	debug	inMem message hm-rpc.0.* hm-rpc.0.LEQ0807702.5.PRESS_SHORT
        hm-rpc.0	2016-01-08 00:04:29	debug	inMem message hm-rpc.0.* hm-rpc.0.LEQ0807702.5.PRESS_SHORT
        hm-rpc.0	2016-01-08 00:04:29	debug	inMem message hm-rpc.0.* hm-rpc.0.LEQ0807702.5.PRESS_SHORT
        hm-rpc.0	2016-01-08 00:04:29	debug	inMem message hm-rpc.0.* hm-rpc.0.LEQ0807702.5.PRESS_SHORT
        hm-rpc.0	2016-01-08 00:04:29	debug	inMem message hm-rpc.0.* hm-rpc.0.LEQ0807702.5.PRESS_SHORT
        hm-rpc.0	2016-01-08 00:04:29	debug	hm-rpc.0 binrpc <- event ["hm-rpc.0","LEQ0807702:5","PRESS_SHORT",true]
        hm-rpc.0	2016-01-08 00:04:29	debug	inMem message hm-rpc.0.* hm-rpc.0.LEQ0807702.5.PRESS_SHORT
        hm-rpc.0	2016-01-08 00:04:29	debug	inMem message hm-rpc.0.* hm-rpc.0.LEQ0478010.0.UNREACH
        hm-rpc.0	2016-01-08 00:04:29	debug	hm-rpc.0 binrpc <- event ["hm-rpc.0","LEQ0807702:5","PRESS_SHORT",true]
        hm-rpc.0	2016-01-08 00:04:29	debug	hm-rpc.0 binrpc <- event ["hm-rpc.0","LEQ0807702:5","PRESS_SHORT",true]
        hm-rpc.0	2016-01-08 00:04:29	debug	hm-rpc.0 binrpc <- event ["hm-rpc.0","LEQ0807702:5","PRESS_SHORT",true]
        hm-rpc.0	2016-01-08 00:04:29	debug	hm-rpc.0 binrpc <- event ["hm-rpc.0","LEQ0807702:5","PRESS_SHORT",true]
        hm-rpc.0	2016-01-08 00:04:29	debug	hm-rpc.0 binrpc <- event ["hm-rpc.0","LEQ0807702:5","PRESS_SHORT",true]
        hm-rpc.0	2016-01-08 00:04:29	debug	hm-rpc.0 binrpc <- event ["hm-rpc.0","LEQ0807702:5","PRESS_SHORT",true]
        hm-rpc.0	2016-01-08 00:04:29	debug	hm-rpc.0 binrpc <- event ["hm-rpc.0","LEQ0807702:5","PRESS_SHORT",true]
        hm-rpc.0	2016-01-08 00:04:29	debug	hm-rpc.0 binrpc <- event ["hm-rpc.0","LEQ0807702:5","PRESS_SHORT",true]
        hm-rpc.0	2016-01-08 00:04:29	debug	hm-rpc.0 binrpc <- event ["hm-rpc.0","LEQ0807702:5","PRESS_SHORT",true]
        hm-rpc.0	2016-01-08 00:04:29	debug	hm-rpc.0 binrpc <- event ["hm-rpc.0","LEQ0807702:5","PRESS_SHORT",true]
        hm-rpc.0	2016-01-08 00:04:29	debug	inMem message hm-rpc.0.* hm-rpc.0.LEQ0807702.5.INSTALL_TEST
        hm-rpc.0	2016-01-08 00:04:29	debug	inMem message hm-rpc.0.* hm-rpc.0.LEQ0807702.5.PRESS_SHORT
        hm-rpc.0	2016-01-08 00:04:29	debug	hm-rpc.0 binrpc <- event ["hm-rpc.0","LEQ0478010:0","UNREACH",true]
        hm-rpc.0	2016-01-08 00:04:29	debug	hm-rpc.0 binrpc <- event ["hm-rpc.0","LEQ0807702:5","INSTALL_TEST",true]
        hm-rpc.0	2016-01-08 00:04:29	debug	hm-rpc.0 binrpc <- event ["hm-rpc.0","LEQ0807702:5","PRESS_SHORT",true]
        hm-rpc.0	2016-01-08 00:04:29	info	hm-rpc.0 binrpc -> 103 devices
        hm-rpc.0	2016-01-08 00:04:29	info	hm-rpc.0 binrpc <- listDevices ["hm-rpc.0"]
        hm-rpc-0	2016-01-08 00:04:26	debug	Send INIT...
        hm-rpc-0	2016-01-08 00:04:26	info	binrpc -> 192.168.178.30:2001 init ["xmlrpc_bin://192.168.178.52:2001","hm-rpc.0"]
        hm-rpc-0	2016-01-08 00:04:26	info	binrpc server is trying to listen on 192.168.178.52:2001
        hm-rpc-0	2016-01-08 00:04:26	debug	statesDB connected
        hm-rpc-0	2016-01-08 00:04:26	debug	objectDB connected
        host-TARDIS	2016-01-08 00:04:24	info	instance system.adapter.hm-rpc.0 started with pid 8088
        host-TARDIS	2016-01-08 00:04:22	info	Restart adapter system.adapter.hm-rpc.0 because enabled
        host-TARDIS	2016-01-08 00:04:22	warn	instance system.adapter.hm-rpc.0 terminated due to SIGTERM
        host-TARDIS	2016-01-08 00:04:22	info	stopInstance system.adapter.hm-rpc.0 killing pid 6952
        host-TARDIS	2016-01-08 00:04:22	info	stopInstance system.adapter.hm-rpc.0
        host-TARDIS	2016-01-08 00:04:22	info	object change system.adapter.hm-rpc.0
        inMem	2016-01-08 00:03:58	debug	message *.logging system.adapter.admin.0.logging val=true, ack=true, ts=1452207839, q=0, from=system.adapter.admin.0, lc=1452207839
        inMem	2016-01-08 00:03:58	debug	message *.logging system.adapter.admin.0.logging val=false, ack=true, ts=1452207838, q=0, from=system.adapter.admin.0, lc=1452207838
        inMem	2016-01-08 00:02:55	debug	message *.logging system.adapter.admin.0.logging val=true, ack=true, ts=1452207776, q=0, from=system.adapter.admin.0, lc=1452207776
        hm-rpc-0	2016-01-08 00:02:54	debug	Send PING...
        socketio-0	2016-01-08 00:02:29	warn	Reconnection to DB.
        socketio-0	2016-01-08 00:02:29	warn	Reconnection to DB.
        hm-rpc-0	2016-01-08 00:02:25	warn	Reconnection to DB.
        hm-rpc-0	2016-01-08 00:02:25	warn	Reconnection to DB.
        ping	2016-01-08 00:02:24	debug	timeout
        admin-0	2016-01-08 00:02:23	warn	Reconnection to DB.
        admin-0	2016-01-08 00:02:23	warn	Reconnection to DB.
        hm-rpc-0	2016-01-08 00:01:25	debug	binrpc <- event ["hm-rpc.0","LEQ0478264:1","STATE",false]
        hm-rpc-0	2016-01-08 00:01:25	debug	binrpc <- event ["hm-rpc.0","LEQ0478264:1","WORKING",false]
        hm-rpc-0	2016-01-08 00:01:25	debug	binrpc <- event ["hm-rpc.0","LEQ0807702:5","INSTALL_TEST",true]
        hm-rpc-0	2016-01-08 00:01:25	debug	binrpc <- event ["hm-rpc.0","LEQ0807702:5","PRESS_SHORT",true]
        hm-rpc-0	2016-01-08 00:01:25	info	binrpc <- listDevices ["hm-rpc.0"]
        hm-rpc-0	2016-01-08 00:01:25	info	binrpc <- system.listMethods ["hm-rpc.0"]
        hm-rpc-0	2016-01-08 00:01:24	debug	binrpc <- event ["hm-rpc.0","LEQ0807702:5","INSTALL_TEST",true]
        hm-rpc-0	2016-01-08 00:01:24	debug	binrpc <- event ["hm-rpc.0","LEQ0807702:5","PRESS_SHORT",true]
        
        

        Kann man da irgendwas erkennen?

        1 Reply Last reply Reply Quote 0
        • ?
          A Former User last edited by

          Ich kann auch nochmal bestätigen:

          Der PC muss zwischen zwei Neustarts ein, zwei Minuten aus sein, damit der Fehler auftritt.

          Wenn ich direkt runter und wieder hochfahre, blockiert er die CCU nicht.

          Nochmal ein Log:

          host-TARDIS	2016-01-08 00:33:30	info	Restart adapter system.adapter.hm-rpc.0 because enabled
          host-TARDIS	2016-01-08 00:33:30	warn	instance system.adapter.hm-rpc.0 terminated due to SIGTERM
          host-TARDIS	2016-01-08 00:33:30	info	stopInstance system.adapter.hm-rpc.0 killing pid 1008
          host-TARDIS	2016-01-08 00:33:30	info	stopInstance system.adapter.hm-rpc.0
          host-TARDIS	2016-01-08 00:33:30	info	object change system.adapter.hm-rpc.0
          hm-rpc-0	2016-01-08 00:32:52	debug	Send PING...
          socketio-0	2016-01-08 00:32:29	warn	Reconnection to DB.
          socketio-0	2016-01-08 00:32:29	warn	Reconnection to DB.
          hm-rpc-0	2016-01-08 00:32:23	warn	Reconnection to DB.
          hm-rpc-0	2016-01-08 00:32:23	warn	Reconnection to DB.
          ping	2016-01-08 00:32:22	debug	timeout
          admin-0	2016-01-08 00:32:17	warn	Reconnection to DB.
          admin-0	2016-01-08 00:32:17	warn	Reconnection to DB.
          hm-rpc-0	2016-01-08 00:31:22	info	binrpc <- listDevices ["hm-rpc.0"]
          hm-rpc-0	2016-01-08 00:31:22	debug	binrpc <- event ["hm-rpc.0","LEQ0807702:5","INSTALL_TEST",true]
          hm-rpc-0	2016-01-08 00:31:22	debug	binrpc <- event ["hm-rpc.0","LEQ0807702:5","PRESS_SHORT",true]
          hm-rpc-0	2016-01-08 00:31:22	info	binrpc <- system.listMethods ["hm-rpc.0"]
          hm-rpc-0	2016-01-08 00:31:22	debug	binrpc <- event ["hm-rpc.0","LEQ0807702:5","INSTALL_TEST",true]
          hm-rpc-0	2016-01-08 00:31:22	debug	binrpc <- event ["hm-rpc.0","LEQ0807702:5","PRESS_SHORT",true]
          hm-rpc-0	2016-01-08 00:31:22	debug	Send INIT...
          
          AAA Das hier sind die Meldungen, nachdem ich den PC neu gestartet habe AAA
          
          VVV Letzte Meldungen, bevor ich den PC ausgeschaltet hab VVV
          
          inMem	2016-01-08 00:27:49	debug	message *.logging system.adapter.admin.0.logging val=false, ack=true, ts=1452209270, q=0, from=system.adapter.admin.0, lc=1452209270
          inMem	2016-01-08 00:27:25	debug	message *.logging system.adapter.admin.0.logging val=true, ack=true, ts=1452209246, q=0, from=system.adapter.admin.0, lc=1452209246
          
          
          1 Reply Last reply Reply Quote 0
          • ?
            A Former User last edited by

            Ich habe noch etwas rausgefunden.

            Zumindest eine Vermutung:

            Ich glaube, es hat was mit der Passworteingabe/der Nutzerauswahl von Windows 10 zu tun.

            Ich habe 2 Nutzer auf dem System:

            Admin und Gast

            Admin MIT Passwort.

            Gast OHNE Passwort.

            Sobald der User-Auswahlbildschirm oder die Passworteingabe kommt, friert die CCU2 ein - und erholt sich erst nach Neustart.

            Wenn der PC automatisch Gast startet (ohne Auswahl, ohne Passworteingabe … Das tut er, wenn ich vorher als Gast drin war und den PC auch vom Gast-Account runtergefahren wurde), passiert auch nichts mit der CCU. Glaube ich zumindest, hab's nur 1-2 Mal getestet.

            Das würde auch erklären, warum es viele Monate reibungslos geklappt hat. Da hatte ich nämlich immer nur einen Admin-Account ohne Passwort.

            Muss ich irgendwelche Sicherheitseinstellungen ändern? Irgendwas freigeben?

            Oder liegt es daran, dass ich ioBroker im Hauptverzeichnis installiert habe, statt unter einem User?

            Aber wieso funktioniert es dann beim Gastaccount (nur wenn der Auswahlbildschirm nicht kommt)?

            Jemand eine Idee? Oder ist das die falsche Spur?

            1 Reply Last reply Reply Quote 0
            • Jey Cee
              Jey Cee Developer last edited by

              Ich tippe mal darauf das es was damit zu tun hat das iobroker gestartet wird bevor du dich anmeldest und das verursacht das Problem. Möglicherweise werden dienste von den iobroker abhängig ist erst nach der Anmeldung geladen. Die Lösung wäre den Dienst erst nach der Anmeldung des Benutzers zu laden.

              Gesendet von meinem Jolla mit Tapatalk

              1 Reply Last reply Reply Quote 0
              • B
                Beatz last edited by

                Hallo,

                ich hatte die Tage ein ähnliches Problem, auch wenn die Fehlermeldungen im Log nicht ganz identisch waren. Ich habe iobroker zwar auf einem raspi laufen, aber der rpc-Adapter hat reproduzierbar immer meine CCU abgeschossen. Auch im Log waren danach keine Einträge mehr zu sehen.

                Geholfen hat, die beiden Adapter rpc und rega zu löschen und neu zu installieren. Seitdem läuft mein System wieder stabil.

                Viele Grüße

                Andreas

                1 Reply Last reply Reply Quote 0
                • ?
                  A Former User last edited by

                  @Beatz:

                  Vielen Dank. Das klingt schon sehr ähnlich. Aber Neuinstallation habe ich schon Tausend Mal probiert. In verschiedensten Programm-Versionen und von automatisch bis manuell bis wasweißich. Jedes mal mit Löschung aller Ordner und Caches und hastdunichtgesehen. Inzwischen st es ja sogar ein neuer Computer mit neuem Betriebssystem. Der Fehler bleibt leider.

                  @Jey Cee:

                  Das könnte schon irgendwie sein.

                  Irgendetwas startet.

                  Etwas anderes ist aber noch nicht gestartet, weil das erst auf die Authentifizierung wartet.

                  Und schon ist die richtige Reihenfolge dahin - und der erste Dienst .. tja.. bombardiert die CCU mit Abfragen? Oder lässt sie in einem Wartungszustand zurück? Keine Ahnung.

                  Ich hatte den ioBroker-DIenst mal auf "verzögerten Start" gesetzt. Das hat leider nicht wirklich geholfen. Ich weiß nicht, ob der Fehler so weg ging. Aber das Problem war dann, dass der Dienst sehr spät gestartet wurde, was die (Gast-)Nutzer extrem verwirrt hat und weitere Eingriffe nötig macht.

                  Aber ist das überhaupt der richtige Dienst? Oder müsste es was mit node.js sein?

                  Gibt es einen Weg, Windows 10 oder node.js zu sagen, was wann wie mit welchen Rechten starten soll?

                  1 Reply Last reply Reply Quote 0
                  • Jey Cee
                    Jey Cee Developer last edited by

                    Du könntest mal "Dienste" suchen und schauen was du dort für möglichkeiten hast.

                    Gesendet von meinem Jolla mit Tapatalk

                    1 Reply Last reply Reply Quote 0
                    • ?
                      A Former User last edited by

                      Habe ich.

                      Da war eine Option:

                      "Datenaustausch zwischen Dienst und Desktop zulassen."

                      Die habe ich mal angekreuzt.

                      Und jetzt… GEHT ES ANSCHEINEND 😄 😄 😄

                      Ich habe keine Ahnung, aus dem Internet werd ich nicht ganz schlau, wozu er gut ist.

                      Die meisten sagen, man soll ihn nicht setzen.

                      Im Moment gelingt es mir aber nicht, den Fehler zu reproduzieren.

                      Ob das nur vorübergehend ist, weiß ich nicht. Ganz koscher kommt mir die Sache immer noch nicht vor.

                      Melde mich, wenn's was Neues gibt.

                      Wenn jemand weiß, was hier vor sich geht, würde ich es wirklich gern erfahren.

                      1 Reply Last reply Reply Quote 0
                      • ?
                        A Former User last edited by

                        Zu früh gefreut… 😞 😞

                        Hatte den PC wohl nicht lang genug aus.

                        😢

                        1 Reply Last reply Reply Quote 0
                        • greyhound
                          greyhound last edited by

                          Hallo,

                          bei der Recherche zu meinem Problem bin ich auf diese Diskussion gestoßen und da nicht als gelöst markiert, könnte es ja noch interessierte geben.

                          Meine momentane Installation:

                          Livesystem auf Raspberry Pi3

                          Test/Dev auf Windows10

                          Homematic CCU2, u.a. mit einigen Fenster- und Türsensoren

                          Beide Installationen sind aktuell und in beiden habe ich hm-rpc installiert, konfiguriert und am Laufen.

                          Ich hatte mir nun das Nuki-Türschloss zugelegt und habe dieses Zwecks besserer Integration mit dem Sensor der Haustür gekoppelt, etwas geskriptet und mir beim Öffnen und Schließen per Telegram eine Info zukommen lassen.

                          Mich hat es dann gewundert, dass ich am Tage keine Nachrichten bekommen. Zu Hause musste ich dann feststellen, dass die CCU2 (oder wer auch immer für die Sensordaten verantwortlich ist) eingefroren war. Es wurde der Status von keinem Sensor mehr erkannt. Ein weiteres Zeichen dafür ist, dass über die GUI das Systemmenü nicht aktivierbar/ aufgebaut wird. Nach einem Neustart (reboot) der CCU2 war wieder alles schön - bis zum nächsten Morgen.

                          Nach der Einschränkung des Zeitraumes, in welchem die CCU2 bei mir einfriert und dem Lesen dieser Diskussion, bin ich zu der Überzeugung gekommen, dass es am Schlafengehen meines Windowsrechners liegen muss. Wahrscheinlich wird die hm-rpv-Verbindung auf der CCU2 nicht terminiert, wenn ich meinen PC in den Ruhemodus sende, sondern mutiert zu einem Zombie und blockiert dann alles.

                          Ich werde die Woche mal ausprobieren, ob es anders ist, wenn ich den ioBroker-Dienst vor dem Ruhemodus beende.

                          Gruß

                          GH

                          1 Reply Last reply Reply Quote 0
                          • greyhound
                            greyhound last edited by

                            lasse nur noch einen ioBroker (24/7) auf CCu2 zugreifen und seit dem keine Probleme mehr.

                            1 Reply Last reply Reply Quote 0
                            • First post
                              Last post

                            Support us

                            ioBroker
                            Community Adapters
                            Donate

                            713
                            Online

                            31.8k
                            Users

                            80.0k
                            Topics

                            1.3m
                            Posts

                            4
                            15
                            4246
                            Loading More Posts
                            • Oldest to Newest
                            • Newest to Oldest
                            • Most Votes
                            Reply
                            • Reply as topic
                            Log in to reply
                            Community
                            Impressum | Datenschutz-Bestimmungen | Nutzungsbedingungen
                            The ioBroker Community 2014-2023
                            logo