Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[Ein ehemaliger Benutzer]

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

[Ein ehemaliger Benutzer]

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?

[Jey Cee]

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

[Beatz]

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

[Ein ehemaliger Benutzer]

@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?

[Jey Cee]

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

Gesendet von meinem Jolla mit Tapatalk

[Ein ehemaliger Benutzer]

Habe ich.

Da war eine Option:

"Datenaustausch zwischen Dienst und Desktop zulassen."

Die habe ich mal angekreuzt.

Und jetzt… GEHT ES ANSCHEINEND :D :D :D

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.

[Ein ehemaliger Benutzer]

Zu früh gefreut… :( :(

Hatte den PC wohl nicht lang genug aus.

:cry:

[greyhound]

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

[greyhound]

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