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
… auch auf die Gefahr hin, hier zum „Alleinunterhalter“ zu werden:
Die 36-Sekunden-Sperre scheint das Problem zu sein. Bei mir reproduzierbar ist folgendes Szenario:
1CCU2, 2Lan-Adapter,
3Bewegungsmelder (jeder fest gekoppelt an einen der drei Empfänger)
3Schaltaktor - direkt verknüpft mit je einem Bewegungsmelder.
IPS als „Beobachter“ genutzt
Normalzustand: IPS zeigt die Bewegung aller Melder; Schaltaktoren lösen aus, alles OK
Sonderzustand: CCU2 wird heftig beschäftigt, um gezielt die 32 Sec. voll zu bekommen.
Danach Ergebnis:
- der Bew.Melder der an der CCU2 DIREKT angemeldet ist wird von dieser ignoriert; Schaltaktor löst aus wg. Direktkopplung. Fehlerhaftes Ergebnis: Keine Anzeige in IPS
- die beiden anderen 3er-Gruppen (Lan-Adapter+Bew.Melder+Schaltaktor) funktionieren wie vorgesehen. Korrekte Anzeige in IPS
Lösung vermutlich durch Verzicht auf die Funkeigenschaften der CCU2; stattdessen LAN-Adapter verwenden (womit man an dem Punkt wäre, dass es im weitesten Sinne „an der Hardware liegt“)
vg Alexander
Keine Angst. Wir hören Dir gespannt zu.
Wenn ich irgendwann einsteigen möchte, dann werde ich das tun.
Ich finde die Entwicklung der Denkansätze sehr spannend.
Die 36-Sekunden-Theorie ist im Ansatz gut, allerdings bei mir nicht zutreffend, da die CCU2 die Werte in der WebUI zuverlässig aktualisiert während sie in IPS nicht mehr ankommen. Der Fehler liegt hier also nicht im RF-Bereich.
Bei „Techwriter“ hatte meine Gesichtsmuskulatur für Sekundenbruchteile einen „Jürgen Klopp“ :eek: Der Hersteller hat den „Duty Cycle“ ja auch bereits ganz anschaulich beschrieben: Manchmal kann ich das System/die Geräte nicht Steuern - was bedeutet Duty Cycle?
Das Problem liegt nicht an den 36 Sek. Die CCU sendet und empfängt ja und der Austausch zu IPS geht nicht über Funk.
Das Problem liegt wohl an der Schnittstelle zu/in IPS. Bei mir reicht jedenfalls ein „IPS_ApplyChanges“ zur Wiederbelebung. Danach klappt die Verbindung wieder. Probiert mal bitte ob das bei euch auch geht.
Früher gab es diese Probleme mit anderen Schnittstellen auch. Deshalb der Workaround. Mit irgendwelchen IPS-Updates lösten sich diese Probleme, wobei ich den technischen Hintergrund nicht kenne, vielleicht auch Zufall.
Gruß
Bruno
Wie triggerst Du das? Ein Check ob der Socket „open“ ist tut´s nicht, da er scheinbar immer „open“ bleibt?
Habs mal zeitgesteuert eingerichtet, wie früher auch, alle 20 min., tut dem Socket ja nicht weh. Muss ich aber noch beobachten, ob es so ausreicht.
Bei mir führt der Befehl
IPS_ApplyChanges (55861 /[HomeMatic Socket]/);
stets zur Fehlermeldung
Warning: Could not bind socket. Address and port are already in use. in C:\IP-Symcon\scripts\45543.ips.php on line 3
und nachfolgend bei
HM_WriteValueBoolean($id_schalter, „STATE“ , true);
zu
Warning: Socket is not connected! in C:\IP-Symcon\scripts\45543.ips.php on line 65
Es wird als schlimmer durch den Befehl.
vg Alexander
Dann hast Du einen Einstellungsfehler, kann aber nur raten
Ereignisport kann wieder ohne Skript umgestellt werden.
Irgendwo ist bei mir was anders.
Konfiguaration lautet:
Und ALLE nachfolgenden Scriptvarianten führen zu Fehlern.
Eine zuvor noch funktionierende Socketverbindung wird unterbrochen.
(IPS 3.00 #3007 vom 25.10.13)
//csck_setopen(55861 /*[HomeMatic Socket]*/,false);
//HM_SetPort(55861 /*[HomeMatic Socket]*/, 5544);
IPS_ApplyChanges(55861 /*[HomeMatic Socket]*/);
//csck_setopen(55861 /*[HomeMatic Socket]*/,true);
//IPS_ApplyChanges (55861 /*[HomeMatic Socket]*/);
//sleep(3);
----> Warning: Could not bind socket. Address and port are already in use. in C:\IP-Symcon\scripts\45543.ips.php on line 5
csck_setopen(55861 /*[HomeMatic Socket]*/,false);
//HM_SetPort(55861 /*[HomeMatic Socket]*/, 5544);
IPS_ApplyChanges(55861 /*[HomeMatic Socket]*/);
csck_setopen(55861 /*[HomeMatic Socket]*/,true);
//IPS_ApplyChanges (55861 /*[HomeMatic Socket]*/);
sleep(3);
----> Warning: Socket ist nicht verbunden! in C:\IP-Symcon\scripts\45543.ips.php on line 42
csck_setopen(55861 /*[HomeMatic Socket]*/,false);
HM_SetPort(55861 /*[HomeMatic Socket]*/, 5544);
IPS_ApplyChanges(55861 /*[HomeMatic Socket]*/);
csck_setopen(55861 /*[HomeMatic Socket]*/,true);
//IPS_ApplyChanges (55861 /*[HomeMatic Socket]*/);
sleep(3);
----> Warning: Socket ist nicht verbunden! in C:\IP-Symcon\scripts\45543.ips.php on line 42
vg Alexander