CCU2 Update - HomeMatic löst sich sporadisch von IPS

Hardware HomeMatic
141

Ich meine der Timer der HMSocket Instanz (Timeransicht in IPS) steht auf 60 sek. Vorher wird es nur erkannt, wen du per IPS was über die CCU steuern willst.
Michael

142

Hallo!

Ich bekomme auch nach 1 Std. keine Fehlermeldung wenn das Netzwerkabel entdernt wird.

Schönen Gruß
Egon

143

Der Socket reagiert hier auch nicht beim LAN-Adapter nach 3 min. immer noch geöffnet. Bei der CCU klappt es nach einer Minute.

Habe jetzt mal die Diagramme wieder am Laufen und es gibt noch keine Hänger, mal bis morgen abwarten.

144

Nur zur Info: Ich hatte dann auch mal für fast 24h keine Daten von der CCU mit der 2.5.4.

145

Bei mir läuft es jetzt nach dem update ! Endlich .

Vielen Dank ans Team

Gesendet von meinem iPhone mit Tapatalk

146

Hallo!

Ich „glaube“ jetzt läufts mit der 2.7.8.:smiley:
(Ohne Extrascripte) mit dem letzten Update.
Ist jetzt aber erst 2 Std. in Beobachtung.
Vor dem Update war ja schon nach ca. 10-15 Min. Stillstand.

Ich berichte weiter…

Meine Theorie zu dem Problem daß es scheinbar bei manchen funktionierte:
Da wir ja mehr oder weniger fleißig Updates installieren wurde die Console öfters danach neu gestartet.

Deshalb liefs bei manchen scheinbar ohne Probleme.
Die die nicht so oft Updaten gerieten in den Stillstand…gerade bei der 2.5.4, die nicht so oft hängenblieb.

Schönen Gruß
Egon

147

Nicht nachvollziehbar, lief bei mir auch ohne Neustart der Konsole längere Zeit problemlos :wink:

148

Für mich auch nicht. Ich arbeite immer über RDP auf dem Server und lasse da immer alles so stehen und liegen wenn ich aufhöre = Konsole immer offen.

Allerdings habe ich das Problem bei mir bisher überhaupt nicht beobachten können und auch mein Syslog-Mitschnitt der letzten Wochen ergibt keine Einträge hinsichtlich „XmlRpc transport error“. Diese treten bei mir immer nur dann auf wenn ich IPS wegen eines Updates neu starten musste.

149

Ich formuliere es mal so: wir sind auf einem guten Weg!

Nach dem Update auf die #3215 kam die Verbindung nicht automatisch wieder:

Dec 18 15:43:25 homematic-ccu2 user.err rfd: XmlRpc transport error calling system.listMethods({"IPS"}) on http://192.168.xxx.xxx:5545/RPC2:
Dec 18 15:43:25 homematic-ccu2 user.err rfd: XmlRpc transport error calling listDevices({"IPS"}) on http://192.168.xxx.xxx:5545/RPC2:

Nach Neustart des IPS-Dienstes läuft es seitdem wieder. Mal weiter beobachten …

Dann gibt´s da noch ein Problemkind über das ich gestolpert bin. Einer der UP Dimmer (wird durch einen Drehgriffkontakt über ein CCU-Skript ausgelöst) dimmt nicht auf 0% sondern nur bis auf 0,5% :confused: Ich bekomme ihn nur auf „0“ wenn ich den „AUS“-Knopf in der WebUI betätige. Blöde daran ist, dass als Folge 1.) IPS den Slider auf 1% stellt und 2.) die CCU sich genötigt fühlt den kompletten Status des Dimmers alle 3 Sekunden zu melden:

| VariableManager      | [IPS LABOR\Stockwerke\Staffelgeschoss\Dachterrasse\Licht\DIMMER\LEVEL] = [b]0,005
[/b]| VariableManager      | [IPS LABOR\Stockwerke\Staffelgeschoss\Dachterrasse\Licht\DIMMER\WORKING] = False
| VariableManager      | [IPS LABOR\Stockwerke\Staffelgeschoss\Dachterrasse\Licht\DIMMER\DIRECTION] = 0
| VariableManager      | [IPS LABOR\Stockwerke\Staffelgeschoss\Dachterrasse\Licht\DIMMER\ERROR_REDUCED] = False
| VariableManager      | [IPS LABOR\Stockwerke\Staffelgeschoss\Dachterrasse\Licht\DIMMER\ERROR_OVERLOAD] = False
| VariableManager      | [IPS LABOR\Stockwerke\Staffelgeschoss\Dachterrasse\Licht\DIMMER\ERROR_OVERHEAT] = False

… was dann irgendwann zu diesen 2 zeitgleichen Meldungen führte:

homematic-ccu2 user.err rfd: XmlRpcClient error calling event({[methodName:"event",params:{"IPS","IEQxxxxxxx:1","LEVEL",[b]0.005000[/b]}],[methodName:"event",params:{"IPS","IEQxxxxxxx:1","WORKING",false}],[methodName:"event",params:{"IPS","IEQxxxxxxx:1","DIRECTION",

homematic-ccu2 user.err rfd: [b]XmlRpc transport error
[/b]

Man könnte jetzt auch diskutieren wie viel Sinn eine Nachkommastelle bei einem 220V-Dimmer macht …

150

Hallo!
Leider zu früh gefreut.
Nach ca. 5 Std. ist die aktualisierung wieder eingeschlafen.:eek:
Ohne Fehlermeldung.

(Ist aber schon viel besser, vor Updates wars in 10 Min. passiert)

Schönen Gruß
Egon

151

Schuld eigene, das war ein „false positive“ … da hatten sich 2 Dimmaktionen überschnitten :rolleyes: Der Transport Error zur gleichen Zeit war Zufall.

Beobachtungs-Timer ist auch wieder zurückgesetzt, da Update auf #3224

152

25 Std. ohne CCU2-Kommunikationsproblem!!! Wasssischdalooosdalooooos??? :D:D:D

Erst einmal Update auf #3233 … wenn Paresy es „schafft“ mal über´s WE kein Update rauszuhauen (… sorry, ich leide unter pathologischem Update-Zwang!) bin ich sehr zuversichtlich, dass wir MINDESTENS 48 Std. stabilen Betrieb erreichen :wink:

In diesem Sinne … ein schönes, absturzfreies Wochenende!

Cheers
/Jens

153

Hallo Jens!

Hast du die 2.5.4 drauf.
Mit meiner 2.7.8 gehts nur ca. 4 Std. gut. Mit neustem Update getestet.

Schönen Gruß
Egon

154

Nope … seit der #3209 fahre ich ausschließlich mit der 2.7.8 auf beiden Kisten.

Was sagt denn Dein Log auf der CCU2 bzw. IPS zum Zeitpunkt des Ausfalls?
Im FS auf der CCU unter „/var“ gibt es eine Datei „RFD.handlers“. Ist dort IPS nach bzw. während des Ausfalls noch mit den korrekten Werten aufgeführt?
Im Normalfall sieht der Eintrag (IP anonymisiert!) so aus:

http://127.0.0.1:9292/bidcos    BidCos-RF_java
[b]http://192.168.xxx.xxx:5544    IPS[/b]
xmlrpc_bin://127.0.0.1:1999    1007
155

Moinsen

Nur mal so am Rande… Private IP Adressen muss man nicht unbedingt anonymisieren :wink: eine 192.168.0.1 oder 192.168.1.10 etc. kommt milliardenfach vor;) Die ist von außen eh nicht erreichbar. http://de.wikipedia.org/wiki/Private_IP-Adresse

Die soll nicht besserwisserisch rüberkommen, sondern mehr zur Aufklärung dienen :wink:
LG
Sven

156

Es ging dabei nicht primär um die Tatsache, dass die privaten IPv4-Ranges im Internet nicht geroutet werden. Das sollte aber hier im Forum nicht wirklich News sein.

1.) o.k. „richtiger“ wäre „xxx.xxx.xxx.xxx“ oder "<IP_des_IPS-Servers> gewesen um Konfusion zu vermeiden :wink:
2.) „verrät“ man das/die intern genutzte/genutzten Subnet(s) generell nicht -> je weniger Info über ein „Angriffsziel“, umso schwieriger wird es für böse Buben oder das Script-Kiddie von nebenan.

… keine Paranoia, nur so am Rande als ergänzende Aufklärung resultierend aus fast 2 Jahrzehnten Erfahrung mit Netzwerk(en), -protokollen und IT-Security.

Cheers
/Jens

157

Hallo Jens!
Bis jetzt läufts aaaber diese Fehlermeldungen kommen regelmässig
:
Dec 21 12:32:45 homematic-ccu2 user.err rfd: XmlRpcClient error calling event({[methodName:„event“,params:{„IPS“,„KEQ0734751:4“,„BATTERY_STATE“,3.000000}],[methodName:„event“,params:{„IPS“,„KEQ0734751:4“,„VALVE_STATE“,69}],[methodName:„event“,params:{„IPS“,„KEQ0734751:4“,"BO
Dec 21 12:32:45 homematic-ccu2 user.err rfd: XmlRpc transport error
Dec 21 12:45:16 homematic-ccu2 user.err rfd: XmlRpcClient error calling event({[methodName:„event“,params:{„IPS“,„KEQ0734751:4“,„CONTROL_MODE“,1}],[methodName:„event“,params:{„IPS“,„KEQ0734751:4“,„FAULT_REPORTING“,0}],[methodName:„event“,params:{„IPS“,„KEQ0734751:4“,"BATTERY
Dec 21 12:45:16 homematic-ccu2 user.err rfd: XmlRpc transport error
Dec 21 12:52:53 homematic-ccu2 user.err rfd: XmlRpcClient error calling event({[methodName:„event“,params:{„IPS“,„KEQ0734751:4“,„BATTERY_STATE“,3.000000}],[methodName:„event“,params:{„IPS“,„KEQ0734751:4“,„VALVE_STATE“,69}],[methodName:„event“,params:{„IPS“,„KEQ0734751:4“,"BO
Dec 21 12:52:53 homematic-ccu2 user.err rfd: XmlRpc transport error
Dec 21 12:58:39 homematic-ccu2 user.err rfd: XmlRpcClient error calling event({[methodName:„event“,params:{„IPS“,„KEQ0507417:4“,„CONTROL_MODE“,0}],[methodName:„event“,params:{„IPS“,„KEQ0507417:4“,„FAULT_REPORTING“,0}],[methodName:„event“,params:{„IPS“,„KEQ0507417:4“,"BATTERY
Dec 21 12:58:39 homematic-ccu2 user.err rfd: XmlRpc transport error
Dec 21 13:06:07 homematic-ccu2 user.err rfd: XmlRpcClient error calling event({[methodName:„event“,params:{„IPS“,„KEQ0507417:4“,„CONTROL_MODE“,0}],[methodName:„event“,params:{„IPS“,„KEQ0507417:4“,„FAULT_REPORTING“,0}],[methodName:„event“,params:{„IPS“,„KEQ0507417:4“,"BATTERY
Dec 21 13:06:07 homematic-ccu2 user.err rfd: XmlRpc transport error
Dec 21 13:15:32 homematic-ccu2 user.err rfd: XmlRpcClient error calling event({[methodName:„event“,params:{„IPS“,„KEQ0734751:4“,„CONTROL_MODE“,1}],[methodName:„event“,params:{„IPS“,„KEQ0734751:4“,„FAULT_REPORTING“,0}],[methodName:„event“,params:{„IPS“,„KEQ0734751:4“,"BATTERY
Dec 21 13:15:32 homematic-ccu2 user.err rfd: XmlRpc transport error
Dec 21 13:25:03 homematic-ccu2 user.err rfd: XmlRpcClient error calling event({[methodName:„event“,params:{„IPS“,„KEQ0734751:4“,„CONTROL_MODE“,1}],[methodName:„event“,params:{„IPS“,„KEQ0734751:4“,„FAULT_REPORTING“,0}],[methodName:„event“,params:{„IPS“,„KEQ0734751:4“,"BATTERY
Dec 21 13:25:03 homematic-ccu2 user.err rfd: XmlRpc transport error
Dec 21 13:36:46 homematic-ccu2 user.err rfd: XmlRpcClient error calling event({[methodName:„event“,params:{„IPS“,„KEQ0507417:4“,„BATTERY_STATE“,3.000000}],[methodName:„event“,params:{„IPS“,„KEQ0507417:4“,„VALVE_STATE“,0}],[methodName:„event“,params:{„IPS“,„KEQ0507417:4“,"BOO
Dec 21 13:36:46 homematic-ccu2 user.err rfd: XmlRpc transport error
Dec 21 13:57:09 homematic-ccu2 user.err rfd: XmlRpcClient error calling event({[methodName:„event“,params:{„IPS“,„KEQ0507417:4“,„CONTROL_MODE“,0}],[methodName:„event“,params:{„IPS“,„KEQ0507417:4“,„FAULT_REPORTING“,0}],[methodName:„event“,params:{„IPS“,„KEQ0507417:4“,"BATTERY
Dec 21 13:57:09 homematic-ccu2 user.err rfd: XmlRpc transport error
Dec 21 14:14:14 homematic-ccu2 user.err rfd: XmlRpcClient error calling event({[methodName:„event“,params:{„IPS“,„KEQ0734751:4“,„BATTERY_STATE“,3.000000}],[methodName:„event“,params:{„IPS“,„KEQ0734751:4“,„VALVE_STATE“,54}],[methodName:„event“,params:{„IPS“,„KEQ0734751:4“,"BO
Dec 21 14:14:14 homematic-ccu2 user.err rfd: XmlRpc transport error
Dec 21 14:38:45 homematic-ccu2 local0.err ReGaHss: Error: IseESP::ExecError= Execution failed: [-1] 0 0x00 [0] 97 0x61 [1] 0 0x00 [2] 99 0x63 [3] 0 0x00 [4] 100 0x64 […/Platform/DOM/iseESPexec.cpp (11622)]

Betrifft nur die neuen Stellantriebe…

Was sagt das aus?
Schönen Gruß
Egon

158

Sorry für die späte AW! Hatte zwischenzeitlich andere Schmerzen -> LINK

Meine Vermutung wäre evtl. die FW-Version der Stellantriebe. Ich habe auch einen davon installiert und das Teil gleich nach dem 1. Test der 2.7.8 auf FW 1.2 gehoben, aus der WebUI entfernt (Werkseinstellung) und danach neu angelernt. Da ich zu dieser Zeit von anderen Problemchen „abgelenkt“ war kann ich aber leider nicht sagen ob ich mit der 1.0 die FMs hatte.

Welche FW läuft bei Dir?

159

Hallo Jens!
Habe jetzt wieder die 2.5.4. drauf. Die läuft seit gestern Abend ca. 20:00.:slight_smile:
Die 2.7.8 bleibt nach wie vor irgendwann stecken.
Die Antriebe haben die 1.2 drauf. Habe keinen mit 1.0 mehr zum Testen.
Reset und so weiter neu anlernen alles mehrfach versucht.

Also hat die 2.7.8 irgendwas… verschlimmert.:mad:

Die Fehler scheinen nur beim Battery und Controlmode senden zu sein.
Ich lösche mal die Stellantriebe und gucke obs dann länger läuft.

Danke für die Antwort.:slight_smile:
Egon

160

@Egon: Probier mal die #3237. Und wenn die Fehler weiter auftreten, schau mal bitte, ob du im IPS Log WARNINGS oder ERRORS hast von der HomeMatic Socket Instanz.

Siehst du die Leerzeichen z.B. bei F AULT_REPORTING? Das sieht nicht korrekt aus.

paresy