Immerhin sind die alten, lauffähigen Firmware-Pakete archiviert.
Download von 2.5.4 erfolgt, ich bin gespannt, ob die Macke weg ist.
Gruß
Bernd Aschendorf
Zumindest die letze Version habe ich immer noch auf dem PC, falls was ist. War aber diesmal nicht nötig. :)
Die neue Gruppenfunktion ist toll, viel weniger Kommunik.-fehler, Speicherkarte, … es läuft.
Vielleicht hilft ja ein zyklisches „IPS_Applychanges“ auf den Homematic-Port, hatten wir früher mal bei anderen Schnittstellen. Oder Port schliessen und öffnen …
Naja, meine Logs sehen in letzter Zeit etwas zerrupft aus. Eine Lücke nach der anderen durch die viele Patcherei. Außerdem ist die neue Firmware merklich reaktionslahmer durch die Aufrüstung. Als reine Schnittstelle zwischen IPS und Homematic ist mir das etwas viel Klimbim. Wenn das so weitergeht, wird der LAN-Adapter wieder reaktiviert und die CCU2 wandert is Lager.
Habe gerade beim Umlernen eines Geräts gemerkt, daß die Hänger wohl auch bei meiner CCU - Konsole - Verbindung kommen. Muss ich aber noch im Auge behalten, da es anscheinend nicht alle Geräte betrifft. Einige Geräte werden nach wie vor aktualisiert, andere hingegen nicht. Dabei wundert mich, dass ein Neustart der Konsole das Problem löst. CCU wird auch aktualisiert.
Ist das bei euch auch so oder „schläft“ die Verbindung in Etappen ein bis gar nix mehr kommt, muss nur warten?
Hallo Powerfreddy!
Hast du die 2.7.8 drauf?
Mußt nur warten…
Mit der 2.7.8 kommt das sehr schnell.
Mit der 2.5.4 seltener
Schönen Gruß
Egon
Klar ist die 2.7.8 drauf und das bleibt auch so. Die Vorteile überwiegen momentan. Kann mich jetzt nur mal an die Ursachenforschung/-beobachtung machen. Sollte ja mal geklärt werden warum das auftritt.
Moinsen,
konnte die Finger nicht still halten und habe auch noch ein wenig geforscht. Mittlerweile habe ich bestimmt schon 10-15 x zwischen 2.5.4 und 2.7.8 „gewechselt“. Fakt ist, wie schon zum größten Teil vorher beschrieben:
- der Fehler der Nicht-Aktualisierung in IPS tritt relativ zeitnah auf (ca. 60-120 min. nach Update auf die 2.7.8; in meinem Fall sind es ~170 Devices fast gleichmäßig verteilt auf 2 x CCU2). Manchmal ist die eine, manchmal die andere schneller „infiziert“
- es betrifft nicht alle Werte/Devices, manche sind aber immer betroffen -> mein Indikator ist jeweils eines der Wandthermostate
- wenn die Aktualisierung in IPS stillsteht werden die betroffenen Werte auf der CCU noch einwandfrei aktualisiert
- kurzfristig (ca. 5-10 min.) lässt es sich durch Neustart des IPS-Dienstes beheben
- die 2.5.4 hat den Fehler in dieser Form nicht, alle Versionen zwischen 2.5.4 und 2.7.8 (die ich auf Wunsch eines einzelnen Herren nicht mehr „namentlich“ erwähnen soll) haben den Fehler ebenfalls!
Das Log spuckt zum Zeitpunkt des Auftretens des Fehlers das hier aus:
Error: IseXmlRpc::CallSetValue: CallXmlrpcMethod failed [../Platform/DOM/iseXmlRpc.cpp (XXXX)]
Aktuell kann ich mit der 2.5.4 leben, auch wenn die 2.7.8 gefühlt um einiges schneller reagiert (z.B. bei CCU-Skripten oder Direktverknüpfungen wie Bewegungsmelder <> Dimmaktor). Der Graphen-Schnickschnack ist schön, aber nicht lebensnotwendig.
Ich hatte es schon in einem anderen Fred erwähnt: wesentlich bedenklicher finde ich, dass die NIC in den Büchsen nicht einwandfrei funktioniert (noch nie hat???). Bei „großen“ Paketen und speziell wenn fragmentiert werden muss (z.B. ping >= 1473 Byte) verschluckt sich das Interface, verliert Pakete bzw. reagiert mit Antwortzeiten teilweise im Sekundenbereich. Das ist relativ einfach z.B. von einem Client im gleichen Subnetz bzw. auf der Konsole der CCU2 nachzuvollziehen (einfach z.B. mal ‚ping -t -l 1490 <CCU-IP>‘ bzw. ping -s 1490 <Client-IP>’ … und versuchen den Mund geschlossen zu halten). Wenn´s mich reitet schalte ich mir nochmal einen SPAN-Port und schnüffel das mal mit. Wahrscheinlich im Fehlerfall nicht unbedingt spannend, da meine Vorahnung ist, dass die NIC dann einfach schweigt. Kommt Zeit, kommt Schnüffelstück …
Für mich gut vorstellbar, dass das aktuelle und evtl. auch andere Problemchen dadurch verursacht werden können. Wie soll man auch ohne Hals husten können 
10 Jahre alte ISA-FastEthernet NICs konnten das schon besser 
Wenn man sich in den eq-3 Laboren mal für 5 Pfennig die Konfiguration bzw. die Kernel-/Treiberunterstützung für das Netzwerkinterface anschaut … jajaja … ich tagträume mal wieder …
Cheers
/Jens
Mal vollkommen quer gedacht:
Nebenbei habe ich mitbekommen, dass die HM-Firmware auch auf Raspberry laufen würde.
Wenn jemand seine Stabilitätseindrücke mit SOLCH einer Hardwarekonstellation mal mitteilen würde könnte man eingrenzen, ob es „an der Hardware“ liegt.
vg Alexander
Ich habe die Beiträge aus dem 3.1er Beta-Thema hier eingefügt.
paresy
Unbedingt die Version lassen !!! Damit läuft es
Ich habe zwei Raspberries (2.3.18) und eine CCU2 (2.7.8) mit LAN adaptern laufen. Ich kann keinen Unterschied in der Stabilität erkennen. Auf meiner CCU / RCU läuft keinerlei Zusatzsoftware und kein Program. Ich nutze die Kisten nur um mit IPS zu kommunizieren. Beide Systemtypen reagieren allerdings gleichermassen allergisch wenn zu viele Nachrichten (über 100 Messages pro Minute) von IPS verschickt werden
Spannend wäre natürlich ein Raspi mit 2.7.8. Ich hatte den Eindruck, dass die CCU2 (in der kurzen Zeit in der sie mit der 2.7.8 stabil bleibt) wesentlich entspannter mit einer größeren Anzahl Messages umgeht. Das LED16 z.B. springt ohne Verzögerung an wenn es die komplette Matrix übertragen bekommt. Mit der 2.5.4 dauert es spürbar länger bzw. hängt auch hin und wieder und spuckt Servicemeldungen. Nur ein äußerer Eindruck …
Gab es da nicht noch ein Projekt „Filter-Layer in IPS“ für HomeMatic? Ich finde gerade den Fred nicht mehr …
So pauschalieren würde ich es nicht. Tatsache ist, wenn Dein PC oder Router so mit den Paketen umgehen würde wie die CCU2 hättest Du wenig Spaß
Ah! DANKE Bruno!
@BestEX
Darf ich mal ganz leise nach dem Status fragen bzw. nach Deiner Bereitschaft das Projekt zur Verfügung zu stellen? Ich glaube ich würde meine Oma dafür verkaufen 
Steht doch im Text …
… wird nicht besser, wenn Du mit Deiner Oma drohst :rolleyes:
Deswegen wurde die Frage ja sehr „leise“ gestellt! :rolleyes:
Ich habe die letzten Monaten an dem Thema weiter gearbeitet und das ganze so umgeschrieben das sich das Tool mehr oder weniger selbst konfiguriert. Es gibt ein paar Gründe warum ich die SW trotzdem noch nicht gepostet habe :
1.) Ich nutze zur Zeit Google Charts zu Visualisierung und habe eigentlich vor auf die nächste IPS Vers. zu warten um Google Charts durch den neuen IPS Multigraph zu ersetzen
2.) Ich habe leider immer noch eine ganz geringe Anzahl von Befehlen die verlorengehen ohne das mein Layer das bemerkt und ein paar weitere Fälle wo es dem Layer auffällt und ich eine Eskalation benötige die erst nach freiwerden der Ressourcen einsetzt. Da der IPS Logger keine Fehler anzeigt nehme ich an das mein Programm bei mehrfacher (gleichzeitiger) Ausführung manchmal einen Datenbank Lock (ich nutze eine separate SQL zum Speichern von variablen) erzeugt der dann einen Programabbruch provoziert bei dem dann der Befehl unbemerkt verlorengeht. Um das zu beheben muss ich aus einer großen Datenbank mehrere kleinere machen und über Semaphore einen exklusiv Zugriff sicherstellen. Um keinen Befehl zu verlieren muss ich mir einen Stack bauen der dann später die Homematic Befehle die während einer Semaphore Blockade eingehen abarbeitet. Das ist unter Umständen nicht ganz trivial 
3.) Ich habe den Layer um einen „Reale Welt Check“ erweitert der sich nur bis zu einem gewissen Grad selbst konfigurieren lassen wird. Bei einem Homematic Befehl wird die Adresse eines Sensors mitgegeben sowie eine wartezeit. Nach ausführen des Befehls wird ein Timer aufgezogen der nach Ablauf nachschaut ob die Aktion die gewünschte Wirkung erzeugt hat. Wenn ich also zum Beispiel den Mischer für meine Luft Heizung aufdrehe dann messe ich nach Ablauf der Wartezeit ob der Wärmetauscher wärmer wird. Falls das nicht der Fall ist hat der Befehl in der realen Welt nicht funktioniert und ich kann eskalieren i.e. Befehl nochmal senden und falls nach N Versuchen immer noch kein Erfolg automatisch die CCU zurücksetzen.
4.) Nachdem ich dann sicher bin das ich wirklich keine Befehle mehr verliere muss ich das Programm auf Geschwindigkeit optimieren ohne das sich Fehler einschleusen und versuchen die Autokonfigration so weit zu entwickeln das das Script möglichst ohne meine Hilfe von allen eingesetzt werden kann
Ich hoffe das ich zum Ende des Jahres soweit bin das ein paar von Euch die Lust haben mal eine Testrunde drehen können. Dann könnt Ihr mir ja sagen ob es Sinn macht so was für alle zu posten. Falls es länger dauert bitte nicht enttäuscht sein, ich werde Ende dieser Woche meine Google Glasses bekommen und entsprechend abgelenkt sein
Wow! Das klingt beeindruckend!
Die Idee mit dem „Reale Welt Check“ finde ich sehr spannend. Das könnte ganz neue Perspektiven was Regelgenauigkeit und Kontrollmechanismen angeht eröffnen. Im Moment laufen bei mir auch noch ein paar wenige logische Funktionalitäten als „Fail-Safe“ auf der CCU. Die könnten dann endlich auch verschwinden.
Für eine Testrunde bin ich immer zu haben. Noch ein Argument mehr sich eine weitere CCU rein zu Testzwecken anzuschaffen.
Bis dahin … viel Spaß beim „Glass“ testen. Achtung Laternenpfahl!
Mal zurück zu dem Problem, dass die CCU2 dem IPS keine aktuellen Werte mehr liefert:
Zitat Techwriter:
Die CCU-2 prüft, ob sie im Lauf der letzten Stunde schon 36 s lang gesendet hat – länger als 1% der Zeit darf im 868-MHz-Bereich keine Kompomponente senden. Das hat die CCU-1 wohl noch nicht überwacht. Wenn einem also in einer größeren Homematic-Installation mal der Netzstecker aus der CCU-2 rutscht, dauert der Wiederanlauf womöglich mehrere Stunden.
Könnte es sein, dass die CCU2 nach Ausschöpfung dieser 36 sec. auch nichts mehr entgegennimmt? Evtl. in Zusammenhang damit, dass sie ja ankommende Statusänderungen von Sensoren auch nicht quittieren dürfte?
vg Alexander
… und wenn da was dran sein sollte ergeben sich Folgeaspekte:
-
Man kann die Anzahl der Sendeversuche von vielen Komponenten einstellen (Default=6). Schlecht erreichbare Sensoren würden aufgrund vieler Wiederholungen dann nicht nur mehr Strom ziehen, sondern auch das Zeitkontingent von 36s/h der CCU2 mehr strapazieren.
-
Nach meinem Verständnis kann die CCU2 nur die EIGENE Sendezeit beurteilen, nicht die von angeschlossenen LAN-Adaptern. Das hieße wiederum dass man durch auch nur einen einzigen zusätzlichen LAN-Adapter (bei geeigneter Zuteilung der Komponenten) unendlich „Sendezeit gewinnt“ mangels Kontroll- und Begrenzungsmöglichkeit.
-
Eine Raspi-CCU wäre nach diesen Theorien gar nicht betroffen da sie „nur andere senden lässt“.
Eure Meinung?
vg Alexander