HMScript failed. http://192.168.1.32:8181/tclrega.exe: Select timeout/error:

[zap]

Oje, Selbsthilfegruppe mit Stuhlkreis 

Ja, ich weiß, ich hab gut Lachen. Wenn ich das Verhalten nur nachvollziehen könnte. Aber ich kann mein FHeM und /oder meine CCU3 so oft neu starten wie ich will. Das Update meiner mittlerweile fast 80 Geräte (davon 10 HmIP) ist in max 2 Sekunden erledigt.

Das Flag zum Abschalten ist in Arbeit. Allerdings habe ich noch eine andere Großbaustelle und solange die nicht erledigt ist, kann ich die neue Version nich einchecken. Das ist noch zu instabil.

[doman75]

Hallo,

ich habe das Problem mittlerweile auch, angefangen hat es mit dem CCU Update 2.45.6, vorher hatte ich keinerlei Probleme. Da habe ich täglich mein FHEM geupdatet und ein shutdown restart gemacht.

Aber seitdem muss ich wie nach jedem shutdown restart, ein reboot der CCU machen und dann ein rpcregister all, dann geht es wieder. Was natürlich nicht sehr schön ist, ich habe sowohl BidCos als auch IP im Einsatz und eine virtuelle Heizungsgruppe.

Ihr seid nicht allein

Grüße
Swen

[doman75]

Verrückt, jetzt wollte ich das gerade nochmal testen und die CCU beobachten, da läuft alles ganz normal. Also einfach FHEM restart ohne Probleme, das einzige was ich gestern an HMCCU I/O DEV geändert habe war das ccuflag nonblocking und reconnect gesetzt und beim CCU RPC HmIP-RF das ccuflag auf expert gesetzt, sonst habe ich zu gestern nichts geändert.

Und beim HMCCU I/O DEV hatte ich das attr rpcinterval auf 2 stehen, warum weiß ich nicht mehr, aber ich habe das attribute komplett gelöscht, default ist wohl 5.

[Rewe2000]

Hallo Swen,

willkommen im Club.
Läuft es bei dir nun wieder "normal" beim Start oder hatte sich der Erfolg nur temporär eingestellt?

@Patrick:
Als weitere Fehlerursache können wir nun auch das Bundesland ausschließen, da ich aus Bayern (nähe Nürnberg) komme.

Das mit der Sebsthilfegruppe ist gar keine schlechte Idee, bevor einer wirklich mit dem Hammer auf das Smart Home einschlägt, könnten wir ein wenig Meditieren und unser Leid beweinen, bis uns Zap da was einbaut.

Spaß beiseite.
@Patrick: Hat denn der Einbau der Verzögerung in HMCCU (Testweise) bei dir funktioniert? Bei mir hatte das sleep() nicht dazu geführt, dass ich die Timeout Fehler losbekommen hätte. Ich würde sogar Freezes von 5-10 Minuten in Kauf nehmen, wenn ich die Systeme wieder automatisiert starten könnte.

Gruß Reinhard

[PatrickR]

Hi!

@Patrick: Hat denn der Einbau der Verzögerung in HMCCU (Testweise) bei dir funktioniert? Bei mir hatte das sleep() nicht dazu geführt, dass ich die Timeout Fehler losbekommen hätte. Ich würde sogar Freezes von 5-10 Minuten in Kauf nehmen, wenn ich die Systeme wieder automatisiert starten könnte.

Bei mir hatte es bei einer Stichprobe von n=1 funktioniert. Habe es allerdings wieder rausgenommen, nachdem Du Probleme gemeldet hattest. Aktuell habe ich das volle Update komplett rausgenommen. Letztlich hat das - man korrigiere mich - nur den Nachteil, dass die Status erst etwas später eintreffen. Aber das tun sie natürlich auch wenn einem stundenlang alles um die Ohren fliegt

Um das Problem weiter eingrenzen müsste man mal einen Google Spreadsheet o. ä. erstellen, für den dann jeder eine Zeile ausfüllt. Das könnte man dann schrittweise erweitern, in etwa:

User	Aufhängen der CCU	ccuflag: nonblocking
Patrick	ja	ja

Nutzer wie doman75 mit verschiedenen Erfahrungen bei verschiedenen Einstellungen könnten dann auch zwei Zeilen füllen.

Patrick

[zap]

rpcinterval wird nur verwendet, wenn der interne RPC Server eingestellt ist.
Aber selbst dann hat es keinen Einfluss auf die CCU Kommunikation, da es lediglich das Intervall für das Abfragen der FHEM bzw HMCCU internen Eventqueue zuständig ist.

[doman75]

Gerade Update und restart gemacht, alles läuft wie ganz normal.

[Dirk070]

Scheinbar gehöre ich nun auch zum Club 

https://forum.fhem.de/index.php/topic,100308.0.html

[zap]

Ich vermute, dass es mit dem HMServer Prozess der CCU zusammenhängt.
Löst sich vielleicht mit dem nächsten CCU Update.

Wäre interessant zu wissen, welche Fehlermeldungen im hmserver.log der CCU stehen

[Dirk070]

Nur eine Frage: müssten dann nicht alle CCU-Benutzer dieses Problem haben?
Wie komme ich am besten an das hmserver.log ? Dann schaue ich gerne mal nach Fehlermeldungen.

[Dirk070]

Ich habe das Log über die UI exportiert.

Beispiel gestern Abend:
Neustart FHEM mit

Code Auswählen Erweitern

2019.05.06 22:11:21 2: HMCCU: [ccu3] Updated devices. Success=2 Failed=25

Danach Neustart CCU.
Welche Infos benötigst Du aus der hmserver.log ?

Ergänzung:
Heute morgen um 8:00 wurden Rolladen gefahren (aus FHEM gesteuert). In FHEM keine Fehlermeldung, die Aktionen wurden auch korrekt ausgeführt.
Im hmserver.log aber:

Code Auswählen Erweitern

May  7 08:00:02 ccu3-webui local0.warn ReGaHss: WARNING: XMLRPC 'setValue': rpcClient.isFault() failed (url: xmlrpc://127.0.0.1:32010, params: {"001118A9A765DD:4","LEVEL",1.000000}, result: [faultCode:-1,faultString:"Generic error (UNREACH)"]) [CallXmlrpcMethod():iseXmlRpc.cpp:2608]
May  7 08:00:02 ccu3-webui local0.err ReGaHss: ERROR: XMLRPC 'setValue' call failed (interface: 1011, params: {"001118A9A765DD:4","LEVEL",1.000000}) [CallSetValue():iseXmlRpc.cpp:1505]
May  7 08:00:02 ccu3-webui local0.err ReGaHss: ERROR: rpc.CallSetValue failed; address = 001118A9A765DD:4 [WriteValue():iseDOMdpHSS.cpp:76]

Wichtig? Interessant?

[Rewe2000]

Hallo Dirk070,

willkommen im Club.

Nur eine Frage: müssten dann nicht alle CCU-Benutzer dieses Problem haben?

Hier zermartere ich mir schon Wochenlag mein Hirn, denn wenn es auch mit einem neu aufgesetzten Linux incl. Fhem und nur mit dem HMCCU Modul auftritt, kann es ja nicht an einer fehlerhaften Programmierung/Parametrierung unter Fhem liegen . Selbst auf CCU Seite trat der Fehler bei mir mit CCU2, CCU3 und RaspberryMatic auf. Hätte ich nun exotische Dinge auf der CCU3 installiert, so wäre das auch erklärbar, aber bei mir gibt es da nix, außer Standard.

Ich habe mir derzeit grundsätzlich angewöhnt, nachdem ich Fhem neu starten musste, auch nach einigen Minuten (achdem Fhem wieder über WEB erreichbar ist) auch noch an der CCU3 (RaspberryMatic) einen Neustart auszuführen, auch wenn im ersten Moment keine Probleme sichtbar sind. Nachdem die CCU3 wieder über WEB erreichbar ist, führe ich unter Fhem (beim HMCCU Modul) nur ein set rpcregister all aus, nach 10 Sekunden einfrieren waren bisher immer die Systeme wieder syncron.

@zap:
Weshalb hast du die Hoffnung beim nächsten CCU Update wäre der Fehler nicht mehr vorhanden?
Hast du da irgendwelche Infos?
Die Hoffnung habe ich ehrlich gesagt schon aufgegeben.

Gruß Reinhard

[zap]

Bei EQ3 kann man nur hoffen. Konkrete Infos habe ich keine, weiß aber, dass Rega und HMServer ziemlich verbugt sind. Mit jedem Update behebt EQ3 einige Fehler, baut aber genauso viele neue ein. Das Spiel geht so seit Jahren. Wenn man dann mal einen Fehler meldet, wird der als Einzelfall abgetan, nur um dann im übernächsten Release als gefixter Bug im Changelog aufzutauchen.

@Dirk070: im Log steht als Fehlerursache UNREACH, d.h. Das Gerät ist nicht erreichbar. Der Befehl wurde aber ausgeführt?

Ich denke, ich werde das Update je Interface steuerbar machen. Im Moment denke ich, dass der Fehler auftritt, wenn viele HMIP Devices auf einmal aktualisiert werden sollen. Ich habe derzeit nur 3 HmIP Devices aktiv.

Ggf. genügt statt einem Neustart der CCU auch ein Neustart vom HMServer.

[Dirk070]

Hallo,

ja, die Aktionen wurden trotz der Meldung ausgeführt.
Mal ein Gedanke: kann es am Routing der IP-Aktoren liegen?

Hintergrund: Ich habe meine alten Rolladen-Aktoren (10 Stück) gegen IP getauscht.
Einige wenige Aktoren liessen sich schlecht erreichen, daher habe ich in Summe 2 Steckdosen-Aktoren, bei denen ich das Routing aktiviert habe.

Gestern Abend lief z.B. eine Rollade recht spät, FHEM lieferte die Fehlermeldung:

Code Auswählen Erweitern

HMCCUDEV: [CCU_EG_KU_Bl1PBU_STR] Error during CCU request. read from http://10.19.27.12:8181 timed out

Die Rollade lief aber, nur eben verzögert. Wenn ich das Vorgehen beim Routing richtig verstehe, versucht die CCU zuerst, direkt zu kommunizieren und wenn dies nicht funktioniert, wird über die Routing-Steckdosen-Aktoren gesendet.

Wilde Theorie: haben nur die, die ein Routing nutzen die Probleme? Könnte das die verhältnismäßig geringe Menge der Betroffenen erklären?

Viele Grüße
Dirk

[doman75]

Also ich habe routing im Einsatz, aber ich kann mittlerweile mein FHEM wieder starten wie ich will. ob es benutzt wird kann ich aber nicht sagen, aber zumindet aktviert ist es bei 2 PSM Aktoren.