Der Gedanke kam mir auch schon …
… kann man eigentlich irgendwie schmerzfrei die Hardware-Revision herausfinden? (ohne Gehäuseöffnung oder ähnliche Stunts)
Sonst wäre die Idee mal einen Vergleich anzustellen. In der Form …
Während des Tippens wurde mir klar wie aufwendig das werden könnte … 
Andere Vorschläge?
Cheers
/Jens
Während des Tippens wurde mir klar wie aufwendig das werden könnte …
Zumal das sehr wahrscheinlich nur ein temporäres Problem ist - bis zur nächsten Version (die dann andere Fehler haben wird :D).
Ich weiss zwar nicht was die bei der 1.507 unter der Haube alles geändert haben aber das Changelog ist bei dieser Version doch sehr übersichtlich. Ich frage mich daher mittlerweile warum ich überhaupt weg von der 1.506 den Versuch mit der 1.507 unternommen habe.
Aber mal die HW-Revision zu vergleichen wäre ein Anfang 
Im Moment habe ich leider keinen „lokalen Zugriff“, sonst hätte ich noch ein paar Sachen probiert.
Oder weiss jemand hier ob es über die Konsole etwas ähnliches wie „dmidecode“ gibt?
Anbei die Infos, die ich der CCU auf die Schnelle entlocken konnte. Per Telnet oder SSH auf die Konsole und dann einfach
more /proc/cpuinfo
Der Output ist … unbefriedigend (vor allem die letzten 3 Zeilen):
Processor : ARM920T rev 0 (v4l)
BogoMIPS : 89.70
Features : swp half thumb
CPU implementer : 0x41
CPU architecture: 4T
CPU variant : 0x1
CPU part : 0x920
CPU revision : 0
Cache type : write-back
Cache clean : cp15 c7 ops
Cache lockdown : format A
Cache format : Harvard
I size : 16384
I assoc : 64
I line length : 32
I sets : 8
D size : 16384
D assoc : 64
D line length : 32
D sets : 8
Hardware : HomeMatic
Revision : 0000
Serial : 0000000000000000
Wäre klasse, wenn Ihr zum Vergleich den Output Eurer CCUs posten könntet!
Cheers
/Jens
OK, Ich wollte eigentlich keinen weiteren Dienst auf der CCU starten 
aber ein Versuch war mir die Sache wert. Meine beiden CCU`s laufen jetzt seit ~ 72 Stunden. Die CPU infos sind hier :
Beide sind offensichtlich identisch
Bei mir auch identisch.
Danke für Eure Infos! … hätte ja klappen können
Bringt uns jetzt leider nur insofern weiter, dass es die Kernkomponenten der CCU, versionstechnisch gesehen, nicht sein können (die Revision des Motherboards mal ausgenommen). Das lässt maximal noch 1001 Möglichkeiten offen … :eek:
Vorerst ´ne gute Nacht!
/Jens
Ich sehe gerade, dass Du auch Nachtschwärmer bist. LOL
Es wird wohl unmöglich, hier die externe Fehlersuche für eQ3 durchzuführen. Erstens ist das ne Nadel im Heuhaufen und zweitens interessiert die externe Meinung wenig bis gar nicht. Die sitzen das faktisch aus.
So jedenfalls meine Beobachtungen mit dem Laden.
Im Prinzip sehe ich das auch so. Trotzdem kann man versuchen „Muster“ zu erkennen und Hinweise zur Fehlerbehebung bzw. Umgehung zu geben.
Meine Installation läuft zur Zeit immer noch so das ich glaube/hoffe das der Grund für die früheren Abstürze bei dem XML API Patch liegt. Das hätten wir unter Umständen alle gemeinsam auch durch eine eigene Lösung geschafft.
Ich weiß es ist illusorisch aber in meiner Idealen Welt gäbe es in IP Symcon ein Plugin das BIDCOS emuliert und uns in die Lage versetzt die Homematic Endgeräte ohne CCU oder LAN Adapter zu betreiben. Die CCU bringt uns IPS Leuten eigentlich überhaupt nichts außer Ausfällen
Da gab es ja diverse Sniffingversuche aber das wird jetzt OT. Grins
Ich hatte zur Erinnerung Probleme mit 1.507 mit dem 1.1er XML API Patch und mit dem 1.2er. Ganz ohne hatte ich noch nicht getestet.
Ich hab nur Funk, kein wired Kram.
Ich habe auch nur wireless …
Interessehalber als Du nach dem update die 33 Servicemeldungen bekommen hast, um welche Störung hat es sich da gehandelt ?
Woran hast Du erkannt das die CCU abgestürzt war ?
(Bei mir war das immer ein Socketfehler in IPS wobei sich die CCU über das Web Interface noch aufrufen lies und bedienbar war)
Kommunikationsfehler
Socketfehler war keiner da aber ich konnte auch über die GUI nix mehr ändern, obwohl alles normal aussah.
Das Fehlerprotokoll zeigte XML Fehler aber im Log waren nur Fehler Minuten vor Neustart drin. Von daher wußte ich nicht, wie es einzuordnen war, denn in IPS fehlten 3 Stunden.
Hmmm bei mir läuft auf beiden CCU`s der Watchdog von OWagner : https://github.com/owagner/regawatchdog. Könnte sein das die Kombination Watchdog und XML version die Kiste stabil macht
Watchdog hab ich keinen drauf.
Das Teil kann ich empfehlen, ist einfach zu installieren und sorgt dafür das Hänger Prozesse abgeschossen werden oder falls notwendig die CCU automatisch einen Neustart macht. Die SW hat die Stabilität meiner Anlage sehr positiv beeinflusst
Das teste ich mal gerne. Mit Add-ons hatte ich bisher noch nicht viel gemacht, da die CCU bei mir ne eher untergeordnete Rolle spielt.
Bei mir läuft der Watchdog nicht. Es war eine Überlegung, aber da ich ungern Sachen automatisch boote (alleine schon um evtl. im Fehlerfall noch troubleshooten bzw. Logs sehen zu können) habe ich es vorerst gelassen.
Trotzdem gut zu wissen, dass der Watchdog sauber arbeitet. Wer weiß ob man das Teil nicht noch braucht …
Mir kam da gerade noch ein Gedanke, da der Apparat bei nicht vorhandener/falscher Uhrzeit gerne zickig wird … nutzt Ihr NTP für die Zeitsync auf der CCU? Wenn ja, lokal oder aus dem WWW?
Cheers
/Jens
Ich nutze NTP aus dem WWW
Hallo.
NTP aus dem eigenen Netzwerk. Und der eigene lokale Zeitserver (Homeserver) holt sich die Zeit aus dem Internet.
Bei mir läuft NTP lokal auf dem SBS (-> DCF77 Dongle). Lustig wird´s immer dann wenn z.B. beim Neustart der CCU der NTP-Server nicht erreichbar ist (deswegen: SetTime).
Im laufenden Betrieb konnte ich bisher noch keinen Zeitverlust feststellen, allerdings gab es ja noch dieses hier:
Ist mir gerade vorgestern wieder passiert mit einem simplen CCU-Programm (Außenbeleuchtung nachts bei Bewegung auf 50%), dass seit längerer Zeit problemlos läuft. Wohlgemerkt: nur den Namen des Programms geändert … PAFF … alle Zeitsteuerungs-Einstellungen platt!