Hallo Josef!
Genau das selbe Problem bei mir.
(hast das schön beschrieben).
Ich habe ganz normales Netzwerk ohne was dazwischen.
Ich habe die neuen Stellantriebe auch im Verdacht.
Deshalb habe ich nur 1 „alten“ Stellantrieb und 1 „altes“ Wandthermostat angelernt.
Seit heute morgen keinen einzigen Fehler im Log der CCU 2 gefunden.
Ich beobachte weiter…
* * * * * command to be executed
- - - - -
| | | | |
| | | | ----- Day of week (0 - 7) (Sunday=0 or 7)
| | | ------- Month (1 - 12)
| | --------- Day of month (1 - 31)
| ----------- Hour (0 - 23)
------------- Minute (0 - 59)
Aktuell habe ich die crontab so erweitert, dass die beiden Jobs stündlich, jeweils in Minute 12 und 16 laufen. Bisher läuft es entspannt, sagt aber noch nicht wirklich etwas aus.
Kann ich so bestätigen! Hier mal ein Kabelhai-Trace-Auszug kurz vor und nach der Funkstille wenn IPS aus der „RFD.handlers“ rausfliegt. Der Zeitpunkt ist schön zu sehen: [RST] == Nr. 170 (Anm.: .151 ist die CCU2 / .8 ist der IPS-Server):
an dieser Stelle dürfte der RST eigentlich nicht (mehr) kommen, da der TCP-Stream lange vorher, auf den 1. Blick regulär, beendet wurde
es waren vereinzelt Re-Transmits bei Paketen die die maxMTU überschritten haben zu sehen und wenn mich nicht alles täuscht wurde nie komplett neu übertragen, sondern nur das eine Paket, dass scheinbar nicht ankam. Ich hätte erwartet, dass alle Teile der betroffenen Übertragung noch einmal gesendet werden (da beide Teilnehmer mit gesetztem „DF“ senden, ist der Socket bzw. alles was OSI-technisch darüber liegt für den Wiederzusammenbau der Päckchen zuständig!)
der Keep-Alive zieht in diesem Zustand scheinbar auch nicht mehr; Timing-Problem?
unidirektional von IPS zur CCU über Port 2001 bzw. 2000 funktioniert es nach dem Abbruch noch, ich hatte allerdings zu dem Zeitpunkt keine Lust oder Nerven mehr zu warten bis/ob das ebenfalls stirbt
Ich schicke Dir mal das komplette, rohe .cap-File per PN. Nicht groß (~ 68 kB), aber man kann schön das Durcheinander bzw. die Überlagerung der einzelnen TCP-Streams sehen bis dann schließlich bei Paket Nr. 170 nichts mehr geht.
Leider ist der Zeitpunkt zu dem die Kommunikation aus den Fugen gerät nicht enthalten. Wenn ich mal wieder einen Zustand habe bei dem der Fehler im Minutenabstand auftritt versuche ich das nochmals vollständig mitzuschneiden.
Wenn mir jemand sagt was ich wie tun muss könnte ich auch Protokolle liefern. Habe aber „nur“ ein bis zwei IPS_Changes-Läufe am Tag und zwischenzeitlich 11 dieser Thermostaten.
Ich hatte heute so viele Fehler unterschiedlicher Art, dass ich frustriert wieder auf 2.5.4 zurück bin.
In diesem Zusammenhang ist mir aufgefallen, dass der xlmapi-patch auf Version 1.10 gehoben wurde.
Nur zur Info
Der Grund weswegen ich mit dem setHWClock und SetInterfaceClock spiele:
Die CCU2 (beide!) befindet sich immer 45 Sek. in der Zukunft! Ist mir da etwas entgangen oder zeigt die WebUI-Uhr die Zeit relativ zu meinem Standort an?!??! Wenn ich mich recht entsinne ist die Uhrzeit im gesamten Land doch die gleiche, oder?
Der NTP-Sync funktioniert laut Log auf dem NTP-Server (Stratum „0“ -> Funkempfänger) einwandfrei.
hab gestern auch noch einige zeit getestet…
Hab nun ne CCU2 ohne Diagramme, SD Karte, Programme & addons im Betrieb… naja was man so Betrieb nennen kann
nach max 30 minuten ist feierabend mit Kommunikation in richtung IPS… es beginnt mit dem error listdevices direkt beim connect von IPS… dann heisst es nen bissel warten und nach ca. 30 minuten hat man die genannten fehler… und immer nur die neuen Heizungsstellantriebe…
Ich habe nur 2 Geräte (die „alten“ Wandth. -Stellantriebe) drin.
Da bekomme ich auch Fehlermeldungen, sind aber ganz andere wie oben schon geschrieben.
Seit gestern Abend 22:00 keinen Stillstand beim aktualisieren. Mal sehn…
Es ist dauernd was anderes man kanns kaum beschreiben.
Jetzt hab ich die neuen Steckdosen und kann die nicht mit IPS benutzen.
ich hab gestern auch zwei neue Stellantriebe auf FW 1.2 geupdated … danach konnte ich diese nichtmal nehr steuern sprich die SollTemp ändern… weder per WebUI noch per IPS… es kommt nach ca. 3 Sekunden ein failed
ob das auch die FW 1.0 betrifft kann ich nicht genau sagen … da ich z.z wieder auf der CCU1 laufe…
da alle „Dritthersteller“ das Problem haben und es auch nicht wirklich gefixed bekommen, denke ich mal hier muss eq-3 Hand anlegen… und das wird dauern :-/ was mal echt ärgerlich ist… meine Zwischenstecker zur leistungsmessung sind quasi auch schon auf dem weg…
Hallo Dave!
Ob das EQ3 überhaupt weiss?
Und dann auch Interessiert?
Die könnten ja sagen: unsere CCU2 funktioniert.
Wenn da was drauf zugreift muss das eben richtig programmiert werden!
Was hindert Dich denn es eq-3 mitzuteilen? Dann hast Du ruckzuck eine Antwort auf Deine Fragen. :eek:
Ansonsten sehe ich keinen Sinn darin seitenweise zu posten " es geht " … " es geht nicht " … wasauchimmer. Paresy hat die Sachen von Jens und Josef bekommen und wird sich darum kümmern.