Adapter hm-rpc friert CCU2 ein
-
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?
-
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 -
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?
-
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
-
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
-
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?
-
Du könntest mal "Dienste" suchen und schauen was du dort für möglichkeiten hast.
Gesendet von meinem Jolla mit Tapatalk
-
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.
-
Zu früh gefreut…
Hatte den PC wohl nicht lang genug aus.
-
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
-
lasse nur noch einen ioBroker (24/7) auf CCu2 zugreifen und seit dem keine Probleme mehr.
