Monatsrückblick Januar/Februar 2026 ist online!

[Homoran]

Hängt die ccu evtl. an einem Green port?

Dann diesen Ma! Bitte auf nicht powersave umstellen.

Gruß

Rainer

[coffee-junk]

> Hängt die ccu evtl. an einem Green port?
Nein, die hängt an einem Port, der immer volle Lotte arbeitet

> Wenn du die Erreichbarkeit getestet hast… womit? Ping? Wie waren die Antwortzeiten?
Mit Ping, von der CCU aus und von der HM aus 1-4ms.

Irgendwas passiert da, denn wenn ich den Adapter neu starte läuf sofort alles wieder.

Ich bin überzeugt, dass wenn ich den Raspi direkt an den Router hänge, dass das Problem dann nicht mehr auftritt, da ja beim Neustart auch der Link am Raspi ausfällt.

Da er aber an einem Switch hängt kriegt er das erst beim Ping mit, dass er die CCU nicht erreichen kann, während die HM, da sie ja an dem Router direkt hängt, über den Neustart keinen Link hat… und da bleibt der rpc hängen....

Dieses Zenario müsste aber alle betreffen, deren CCU & HM an getrennten Switchen hängen, deshalb wundert mich das, dass da nix bekannt ist. Oder was Raspi spezielles..... aber ansonsten funktioniert die komplette Komunikation.

[coffee-junk]

@wendy2702:

Wenn du Netzwerk Probleme ausschließen kannst… eventuell mal Version 1.6.2 versuchen. `

Mich gefälltt das "clear Ping Interval" in der Debug Message nicht, gleich nach dem Connect

Die 1.6.2 werde ich mal morgen, nach einem Komplett Backup versuchen, für heute habe ich meine bessere Hälfte mit ausfällen (durchs rumtesten) überstrapaziert :roll:

[coffee-junk]

Ich habe mir mal den Code vom RPC Adapter durchgeschaut, bin mir aber absolut nicht sicher, ob ich richtig liege, denn so toll kene ich java dann auch nicht. In der Funktion connect finde ich folgendes (so ab Zeile 1459):

 connTimeout = null;
    adapter.log.debug('Connect...');
    if (eventInterval) {
        adapter.log.debug('clear ping interval');
        clearInterval(eventInterval);
        eventInterval = null;
    }

    if (isFirst) sendInit();

    // if not bin rpc
    if (!rpcClient.connect) {
        if (!connInterval) {
            adapter.log.debug('start connecting interval');
            connInterval = setInterval(function () {
                sendInit();
            }, adapter.config.reconnectInterval * 1000);
        }
}

Kann es sein, da der Adapter noch connected ist und auch alive, nur jedoch das "Verbunden mit hm-rpc : falsch" steht, dass er da gar keinen Versuch mehr macht????

:shock:

Habe mir das mal auf GitHub angesehen, da wurde von V1.6.0 auf 1.6.1 genau an dieser Stelle änderungen von Blufox gemacht, vielleicht liegt es daran? Denn ich wüsste nicht, dass dieses Problem "früher" schon da war….

[wendy2702]

Mir ist diese Problem noch nicht aufgefallen…. allerdings habe ich auch nur selten das Problem eines Netzwerk Ausfalls.

[coffee-junk]

@wendy2702:

Mir ist diese Problem noch nicht aufgefallen…. allerdings habe ich auch nur selten das Problem eines Netzwerk Ausfalls. `

Ich habe lange gebraucht bis ich die Ursache lokalisiert habe, da der zeitliche Zusammenhang nicht ersichtlich war, wenn es nicht irgendwelche Steuer-Operationen gegeben hat. Wie zum Beispielt Luftentfeuchter startet/stoppt nicht, Gartenpumpe wird nicht eingeschaltet….

Da startet man heute den InternetRouter neu und morgen merkt man dass irgendwas faul ist und dann muss einem erst mal wieder einfallen dass das mit dem Neustart von gestern zusammen hängen könnte.

Habe mir jetzt mal so beholfen, dass sich die HM & IObroker gegenseitig, über Flags, die toggeln, überwachen. Denn das gemeine ist ja, dass hm-rega fehlerfrei weiter läuft.

Und die Programme in der HM selbst steuern brav weiter, nur die komplexeren Sachen, die von IO-Broker aus gesteuert werden gehen dann nicht mehr.

[wendy2702]

Hast du denn mal mit 1.6.2 getestet?

Gesendet von iPhone mit Tapatalk Pro

[coffee-junk]

@wendy2702:

Hast du denn mal mit 1.6.2 getestet? `

Ja, gleiches Problem, rpc macht keinen Connect Versuch mehr, bleibt im Status Verbunden mit hm-rpc: falsch.

Wo kann ich das als BUG einkippen?

[wendy2702]

Github –> https://github.com/ioBroker/ioBroker.hm-rpc/issues

Gerade mal bei mir probiert, wobei bei mir iobroker und CCU an einem Switch hängen. Wenn ich die FB restarte... bekommen die davon nichts mit :lol:

Deshalb hatte ich das Problem noch nie :mrgreen:

[coffee-junk]

@wendy2702:

Deshalb hatte ich das Problem noch nie :mrgreen: `
:evil: Glück gehabt!

[coffee-junk]

@wendy2702:

Gerade mal bei mir probiert, wobei bei mir iobroker und CCU an einem Switch hängen. Wenn ich die FB restarte… bekommen die davon nichts mit :lol: `

Und was passiert, wenn du die CCU mal für 2/3 Minuten am Switch aussteckst und dann wieder einsteckst? Tritt dann das Problem auf? Sollte eigentlich…wenn du Lust/Zeit hast, würde evt. helfen das weiter einzugrenzen, obs nicht doch irgendwas spezielles nur bei mir im Netz ist, weis der Geier... :?:

[wendy2702]

Kann ich gleich mal testen.

Melde mich dann.

[wendy2702]

So,

habe das gleiche Verhalten. Wenn Verbindung zur CCU länger unterbrochen ist wird die nicht automatisch wieder hergestellt.

Machst du ein Issue auf Github dazu auf?

[coffee-junk]

@wendy2702:

Machst du ein Issue auf Github dazu auf? `
Schon erledigt! Vielen Dank für deine Hilfe!

Ich bin jetzt ein bisschen beruhigt, dass es nicht irgendwie an meiner Netzwerk Konfiguration liegt! ;)

[coffee-junk]

So, heute habe ich die neue Version direkt von Github (1.7.2) installiert, nun kommt der Adapter auch nach einem Ausfall wieder komplett hoch!

Gleichzeitig habe ich den admin auf V3 gesetzt und Node von V4.x auf 6.14 hochgezogen…. und bis jetzt keine Fehler festgestellt :D

Ich hoffe das bleibt auch so, hatte etwas muffe, dass nach dem Upgrade nix mehr geht, da zum schluss bei reinstall.sh eine Fehlermeldung wegen unerwartetem Datei Ende kam....

SchaunWerMal