Kommunikation aktuell gestört

[gerdberger]

Hallo HMer,

da mit letztens so schön geholfen wurde, kann ich hier vielleicht auch dem einen oder anderen helfen.
Steigen Statusmeldungen plötzlich an, Unerreichbarkeiten von Geräten mehren sich, 'CO-ER', 'NAK's nerven, etc., dann muß es sich dabei keineswegs um Sende- oder Empfangsprobleme handeln, wenngleich sie auch 'Kommunikation aktuell gestört' heißen!

Einen Grund habe ich gefunden. Es liegt vornehmlich am Prozessor der CCU. Ist eigentlich kein Prozessor - vielmehr eine alte mechanische Rechenmaschine und offenbar sehr schnell überfordert.

Wer das Statusdisplay besitzt (HM-OU-LED16), programmiert sich mitunter einen Wolf, um Zustände anzeigen zu lassen und verschachtelt sich bei zuvielen Bedingungen in einer Schleife.
Das muß wie bei mir gar nicht mal auffallen, wenn lediglich Variablen logisch belegt werden (mehrere Lampen werden per Schalter und Fernbedienungen in unterschiedlichen Räumen geschaltet und sollen im Statusdisplay lediglich in einer einzigen resultieren: Licht ist noch (irgendwo) an!

Nun belegte bei mir ein ständig angesprungener Programmpunkt ebenso ständig eine Variable ('Licht ist noch nicht aus') - das Ergebnis der einzelnen Unterabfragen, daß gezielt irgendwo noch z.B. Licht brennt (Licht Küche an aber Licht Wohnzimmer aus) und die Ergebnisvariable somit noch nicht mit 'Licht aus' belegt werden kann.

Das überfordert bei ungeschickter Programmierung die CCU! Sie ist so sehr mit der Befragung und Belegung der Lampenzustände beschäftigt, produziert bei eingeschaltetem Protokoll pro Sekunde 2-3 Meldungen und schafft es nicht mehr, zuverlässig zu senden. Ergebnis: in 5 Minuten laufen 25 und mehr Systemmeldungen wegen Unerreichbarkeit von irgendwelchen Geräten auf (Kommunikation aktuell gestört).

Kaum wird die Routine ausgelassen, sind alle Störungen behoben!!!

Also, wer Kom-Fehler hat, sollte die Aktionen seiner Geräte protokollieren und nachsehen, ob sich da etwas ständig wiederholt. Besonders dann, wenn diese CO-ER z.b. plötzlich auftreten. Dann ist wahrscheinlich etwas unglücklich programmiert.

Viel Erfolg

[buempi]

Also, wer Kom-Fehler hat, sollte die Aktionen seiner Geräte protokollieren und nachsehen, ob sich da etwas ständig wiederholt. Besonders dann, wenn diese CO-ER z.b. plötzlich auftreten. Dann ist wahrscheinlich etwas unglücklich programmiert.

... diese Schlussfolgerung dürfte richtig sein. Allerdings ist dann die Ursache nicht ein überforderter Prozessor der CCU sondern schlicht und einfach die Tatsache, dass offensichtlich die gesetzlich zulässige Sendezeit (36 Sekunden je Stunde) überschritten wurde und die Hardware sich weigert, weitere Sendebefehl auszuführen, was dann die Software als "Kommunikation gestört" interpretiert.

Viele Grüsse
Bümpi

[Homoran]

Es ist schon auffällig, dass in vielen Fällen, bei denen gehäuft "Kommunikation gestört" auftritt auch ein LED16 mit im Spiel ist.

Gruß
Rainer

[gerdberger]

[ die Tatsache, dass offensichtlich die gesetzlich zulässige Sendezeit (36 Sekunden je Stunde) überschritten wurde

@ Bümpi:
die zulässige Sendezeit habe ich gar nicht berücksichtigt!
Wäre also noch ein weiterer Grund für die Kommunikationsfehler.

Trifft allerdings im beschriebenen Fall nicht zu, da nicht gesendet wird!
Das Senden, bzw. das Belegen von Variablen (um sinnvolle Anzeigen im LED16 zu ermöglichen) erfolgt in einer Subroutine. Nur dort wird geschaltet/gesendet. Ich schalte eine Lampe oder Heizungen oder sonstwas in allen Programmen konsequent nur per Variable (macht das Leben viel leichter). Solange sich kein Lampenzustand ändert, springt die CCU ohne zu senden lediglich munter durch die Variablenabfragen (eben wegen der erwähnten ursprünglichen unglücklichen Programmierung), was sie so überfordert, daß bei tatsächlichen Schaltvorgängen keine Kapazitäten mehr vorhanden sind - oder nicht immer - jedenfalls dann eine weitere negative Sendequittung hinzukommt. Eine abzuarbeitende Schleife und ein Sendevorgang sind leider zuviel für das arme Schätzchen...

Das LED16 zeigt übrigens an, wenn die von der Bundesnetzagentur vorgegebene Kommunikationsgrenze erreicht wurde und blockiert in dem Fall für 5 Minuten, damit der Nachbar auf selber Frequenz senden kann. Was für'n Quatsch...

Hmm... wenn ich mir hier selbst zuhöre kommen weitere Überlegungen: jedes systeminterne Setzen von z.B. 'Auslösen auf Änderung' (was ja auch nichts Anderes als das Durchlaufen von Schleifen ist) klappt anstandslos. Das läßt auf einen hinkenden Interpreter schließen, wenn selbstprogrammierte Schleifen Überlastungen verursachen...

Und einen Bug im webUI gibt's auch: wenn es das Haus erreicht hat, meine 'Summenvariable' "Licht überall aus" zu setzen, ist sie auch tatsächlich auch entsprechend gesetzt. Das zeigt die Abfrage des Inhaltes und der Umstand, daß die LED am Display korrekt leuchtet. Der Startseite fehlt in einigen Fällen allerdings ein refresh, denn dort wird diese Variable noch mit ehemaligem Inhalt ausgegeben! (bei hinzugefügter Systemvariable im Benutzerprofil). Andere stimmen jedoch. Aber gut...

[Homoran]

wenn ich mir hier selbst zuhöre kommen weitere Überlegungen

frei nach dem Motto: "wie soll ich wissen was ich denke, bevor ich höre was ich sage" SCNR

Woher weißt du, dass NICHT gesendet wird - und wenn es nur zur Statusabfrage ist?

Gruß
Rainer

[gerdberger]

Woher weißt du, dass NICHT gesendet wird - und wenn es nur zur Statusabfrage ist?

weil es nicht logisch wäre. Wenn kein Zustand vorliegt, um in die Sendesubroutine zu springen, warum sollte er dennoch etwas senden?
Statusabfragen - natürlich. Aber doch nicht in einem Umfang, daß die CPU überfordert ist...

[EnergyStar]

Moment, wer bringt da die Homematic mit Logik in Zusammenhang?
Das ist doch paradox durch das Design, oder?


Sorry, musste sein.
Gruß
EnergyStar