Das klappt jedoch wird der Status nicht immer korrekt übermittel.
Das scheint aber kein Problem von IpSymcon sondern der CCU2 zu sein.
Eigenartig dachte die Sende / Empfangsleistung sollte besser sein.
Mal ein wenig rumtesten.
In dem Fall hast du dich verlesen 
Einstellung auf LAN funktioniert, aber die CCU bekommt nicht immer eine Rückmeldung der Aktoren (Was mit der CCU1 ohne Probleme am selben Standort funktionierte)
Mal verliert man und mal gewinnt man. 
Firewall der CCU 2 haste gecheckt?
bei mir läuft es auch ohne jegliche Änderung mit der Einstellung CCU … unerklärliches Wunder oder Feature?
Was hattest Du vorher? Einen LAN-Adapter oder eine CCU?
2 LAN Adapter, ich habe nur die CCU getauscht.
Zusätzlicher Fehler:
Was mir aber jetzt noch aufgefallen ist, ALLE durch Backup wieder eingespielten Programme werden gestartet, wenn man nur das Feld „aktiv“ selektiert und auch wenn ein Restart gemacht wird!
Wenn mehrere Programme bei gleichem Aktor vorhanden sind, war nicht eindeutig welches Programm dann den Aktor steuert. Bei mir ging die Tür auf 
Die gleichen Programme neu geschrieben, dann tritt der Fehler nicht mehr auf.
Evtl. tritt dieser Fehler ja nur bei mir auf, habe es jedenfalls heute an ELV gemeldet. Ihr könnt das ja mal bei Euch probieren, würde mich interessieren.
Hi,
kann ich nicht bestätigen.
Muß meine CCU2 die letzte Zeit mehrmals neustarten, da sich die RF Componente aufgehängt hat.
An der CCU2 hängen 3 Lan Adapter plus RS485 Gateway.
Alle LAN Adapter sind dann weg und IPS meldet Verbindungsfehler.
Hatte die CCU2 bislangt im CCU Modus in IPS. Habt es jetzt mal auf LAN geändert. Mal sehen ob das auswirkungen hat.
Gruß Andre
Gesendet von meinem GT-I9100 mit Tapatalk 2
Genau das Problem habe ich auch noch und dieser „Hänger“ tritt leider nur sporadisch auf. An der CCU2 hängen bei mir 2 LAN Adapter plus RS485 Gateway.
Hatte aber bis jetzt den Verdacht das das eher mit der Homematic und weniger mit IPS zu tun hat, wenn sich dieser Prozess bei der Homematic aufhängt. Oder muss ich da ggf. umdenken?
Nach meiner Migration von CCU1 auf CCU2 + RS485 LAN Adapter funktionieren nach unterschiedlichen Zeiten die Funkkomponenten nicht mehr. WebUI liefert diese tolle Meldung und nach einem Neustart der CCU2 ist wieder alles ok.
Ok aber nur bis zum nächsten Ausfall, welcher mit hoher Wahrscheinlichkeit innerhalb der nächsten 24h stattfinden wird.
Alles sehr professionell mit dieser neuen CCU2! :mad:
Als Linux Newbie habe ich mich aber trotzdem mal an die Problemlösung gewagt und folgendes Problem gefunden.
Wenn die Funkkomponenten nicht mehr reagieren fehlt in der Prozessliste der Prozess „/bin/rfd“.
Wenn ich diesen über eine PuTTY Verbindung wieder starte, ist das Problem auch ohne Reboot der CCU2 behoben.
Also hab ich mir ein kleines Script geschrieben, welches die Prozessliste abfragt und bei fehlenden „bin/rfd“ Prozess diesen wieder startet und den Neustart in einem Logfile vermerkt. Das Script rufe ich über ein WebUI Programm jede Minute auf.
Seitdem läuft die CCU2 ohne Ausfall der Funkkomponenten stabil.
HowTo:
Mit WinSCP eine SCP Verbindung zur CCU aufbauen.
User: root
Password: MuZhlo9n%8!G
Ins Verzeichnis „/www/addons“ wechseln und dort ein neues Verzeichnis „watchdog“ anlegen. Anschließend im neuen watchdog Verzeichnis eine Datei mit dem Namen „check“ mit u.a. Inhalt anlegen.
Anschließend über „Properties“ die Datei Attribute auf rwx r-x r-x (0755) ändern.
#!/bin/sh
LOGFILE=/www/addons/watchdog/rfd_log.txt
if [ ! -f "$LOGFILE" ]
then
echo "*** rfd_log ***" >> $LOGFILE
fi
#check /bin/rfd
if ps ax | grep -v grep | grep "/bin/rfd" > /dev/null
then
echo "/bin/rfd is running. OK"
#echo "$(date "+%Y%m%d %T") : rfd OK" >> $LOGFILE
else
echo "/bin/rfd not running. Try to start it..."
echo "$(date "+%Y%m%d %T") : rfd ERROR" >> $LOGFILE
/bin/rfd -d -f /etc/config/rfd.conf -l 1
fi
Im WebUI ein neues Programm anlegen welches ein Script jede Minute ausführt.
Das WebUI Script lautet:
string stdout;
string stderr;
system.Exec("/www/addons/watchdog/check",&stdout,&stderr);
Mit http://IP-der-CCU2/addons/watchdog/rfd_log.txt kann man prüfen, wann der rfd Dienst neu gestartet wurde.
Ich hoffe ja mal, dass dieses Problem mit einer neuen Firmware gefixt wird.
Ist ja alles noch ganz neu auf dem Markt!
Edit 26.08.2013: Script und Logfile in den „addons“ Folder verlegt. Hierdurch bleibt das rfd-Logfile sowie das Script nach einem Reboot und Firmwareupdate erhalten und das Logfile kann einfach per HTTP (http://IP-der-CCU2/addons/watchdog/rfd_log.txt) abgefragt werden.
Hi,
seit Update auf Version 2.3.16 konnte ich das nicht mehr beobachten.
Läuft sauber und stabil, auch mit den Raumthermostaten.
Gruss
Andre
Gesendet von meinem B1-A71 mit Tapatalk 2
Habe die rfd-Crashes auch mit der V2.3.16 auf einer meiner beiden CCU2s (XML-API V1.6) 
Auf den ersten Blick ist der einzig offensichtliche Unterschied ein „HM-OU-LED16“, welches an der abstürzenden CCU2 hängt und häufig durch IPS geschaltet wird (-> Fensterstatus).
Dank der rfd-Neustart-Lösung von @Heimgeist (Danke!) werde ich mal in aller Gemütlichkeit beobachten wann und wie oft das passiert …
Cheers
/Jens
Ich habe zwar kein HM-Wired aber auch kein XMLAPI 1.6 sondern noch die 1.5 und bei mir läuft seit Wochen alles rund. Seit dem Umstieg auf die CCU2 nicht einen einzigen Absturz (toitoitoi + klopfaufHolz).
War da nicht auch was wegen Problemen mit der 1.6 im Homematic-Forum? Ich meinte da so etwas mal gelesen zu haben.
Ich habe auch die Statusanzeige und hatte weder unter der .15 noch mit der .16 solche Probleme mit meiner CCU2.
Allerdings weiß ich gerade die Version des XMLAPI Patch nicht.
Die Anzeige wird auch nur durch IPS beschrieben, aber jede LED einzeln.
Ich stelle mal eine ganz wage Vermutung auf, dass vielleicht das Beschreiben aller LEDs gleichzeitung, ein zu langes Funktelegramm erzeugen könnte, welches den rfd-daemon aus den Tritt bringt.
Gesendet von meinem TAB-PROTAB2XXL(4) mit Tapatalk 2
Sooo … mal wieder die Nacht mit HM verbracht :eek:
Nur soviel: wieder auf V2.3.16 und XML-API 1.5 zurück. Details später. Jetzt reicht es mir erst einmal … :mad:
Cheers
/Jens
Meine CCU2 läuft (oder besser crashed!) out-of-the-box mit FW: 2.3.15 ohne jegliche Erweiterungen oder Patches.
Die Version der XML-API Erweiterung scheint daher unerheblich zu sein.
Gestern war wieder mal richtig was los im rfd crash Logfile:
20130723 21:43:00 : rfd ERROR
20130723 21:48:00 : rfd ERROR
20130724 10:54:00 : rfd ERROR
20130724 16:54:01 : rfd ERROR
20130724 17:32:01 : rfd ERROR
20130724 18:22:00 : rfd ERROR
20130724 21:06:00 : rfd ERROR
Aber bis jetzt musste ich nicht durch einen Reboot manuell eingreifen. Dies ist erstmal die Hauptsache.
Positiv muss ich sagen, dass die CCU2 schneller und auch die Funkreichweite wesentlich besser ist.
Ich hatte mit der CCU1 zwei LAN-Konfiguations Adapter als Reichweitenverlängerung im Einsatz.
Die habe ich mit der CCU2 erstmal stillgelegt, weil alle Funkkomponenten von der CCU2 direkt erreichbar sind.
MCS-51 hat mir einen Link zum Download der 2.3.16 gesendet. (Wird bei meiner CCU2 im WebUI noch nicht angeboten)
Da aber r4m3u5 mit dieser Version weiterhin das Problem hat, bin ich nicht mehr so zuversichtlich dass dieses Problem mit 2.3.16 bei mir verschwindet.
Teste es heute mal.
Bisher ist es mit der Kombi V2.3.16 und XML-API V1.5 in Ordnung.
Beim Download der XML-API V1.6 hatte ich kurz gezögert, da es noch keine Einträge für diese Version im Changelog gab. Update um des Updates Willen hat manchmal eben Nachtschicht zur Folge :o
Weitere Erkenntnisse letzter Nacht später. Da sind noch ein paar gordische Logik-Knoten zu lösen … :rolleyes:
Soooo … neue Erkenntnisse!
Nach viel Herumprobieren und Gefrickel laufen jetzt beide CCU2s seit ca. 12 Std. wieder mit V2.3.15 ohne XML-API. Bislang problemlos!
Die V2.3.16 fliegt mir auf einer der beiden nach ca. 1 Std. um die Ohren und wirft auch sonst im Betrieb fast kontinuierlich „RegaHSS“- und „rfd“-Fehler aus. Bei der 2. dauert es etwas länger (auch massiv FMs) und die hat noch zusätzlich bei jedem 2-3 Startvorgang das Problem sich direkt mit tonnenweise BidCos-Fehlern in die Ecke zu setzen :mad:
Mit .16 ist auch gegenüber .15 eine leichte Verzögerung bei der Ausführung von Aktionen spürbar, sowohl bei Programmen direkt auf der CCU (nur wenige und diese sehr simpel wie z.B. „Fenster offen -> Licht dimmen“), Direktverknüpfungen („Fensterkontakt -> Thermostat“) als auch direkt aus IPS heraus. Bevor jetzt wieder einer „meckert“: ja, es wird in naher Zukunft alles exklusiv von IPS aus gesteuert werden
Im Vergleich zu dem oben Beschriebenen ist das Zeitproblem auf den Thermostaten doch eher erträglich. Ich bleibe vorerst mal auf der .15 und lasse mich überraschen wann die WebUI mich zum „offiziellen“ .16-Update drängelt.
Nun noch ein kurzer Blick in die Glaskugel … und unterstützt von den Erkenntnissen der letzten Nachtschichten … meine Vermutung ist, dass es evtl. bereits jetzt unterschiedliche HW-Stände unseres geliebten, weißen Brötchens gibt, speziell was den RF-Teil angeht. Das könnte auch ein Grund sein warum die V2.3.16 für die meisten (?) noch nicht über WebUI verfügbar ist. Wie ja bereits bekannt, ist die Verfügbarkeit des FW-Downloads direkt abhängig von der Seriennummer des einzelnen Gerätes.
Nochmal erwähnt, nur eine vage Vermutung! Bitte seht von Klagen ab wenn der letzte Absatz nicht den Fakten entspricht … äh … oder sich so oder ähnlich bewahrheitet
Cheers
/Jens
Also bei mir schmiert der BidCos-RF Prozess der CCU-2 weiter in regelmässig unregelmässigen Abständen ab. Dabei habe ich auch „nur“ die 2.3.15 und keinerlei zusätzliche SW etc. im Einsatz.
Heute wollte ich mich an die Arbeit machen die Absturzzeiten zeitlich genauer zu erfassen, um den Punkt im Logfile besser eingrenzen zu können, aber dank der rfd-Neustart-Lösung von @Heimgeist (Danke!) war die Arbeit schnell erledigt 
Gestern Abend nach 5 Tagen problemlosem Betrieb der rfd-Crash mit V2.3.15 … niiiarghh …
Dummerweise kein Logfile, da ich alle Erweiterungen entfernt hatte :mad:
So … dann erst einmal wieder @Heimgeist’s Watchdog anlegen …