LCN ständige Timeouts

Hallo zusammen,
ich hoffe jemand kann mir weiterhelfen - das LCN in diesem Haus treibt mich in den Wahnsinn und nichts was ich versucht habe scheint etwas zu ändern / zu verbessern.

Das Problem besteht eigentlich schon immer, wird aber leider immer schlimmer/die Timeouts treten immer häufiger auf. Ich bin an einem Punkt wo einfaches fahren lassen der Rolläden via LCN_ShutterMove Kommando nach Zeitplan nicht zuverlässig funktioniert.

Zu meinem Setup (wenn etwas fehlt bitte gerne Bescheid sagen, ich weiß nicht wirklich was relevant sein könnte):
IP Symcon läuft in Version 6.4 (Rev 6dccc096176c) als Docker Container auf meinem Synology NAS: DSM 7.2. Edition: IP-Symcon Unlimited; Variables Used: 2699. Intel x64 Prozessor.

Läuft super stabil. Keine Crashes (die ich sehen würde). Andere gesteuerte Systeme wie Hue und Homematic laufen absolut stabil/ohne irgendwelche Probleme.

Das NAS (und damit auch der Symcon Container) hat im gleichen VLAN wie die LCN-Visu eine IP-Adresse. NATSupport Switch ist in Symcon gesetzt.

LCN Gateway ist ein LCN-VISU: Version: 3.03 - LCN-PCHK 3.2.3. Scheint für sich genommen stabil zu laufen. Ist zuverlässig erreichbar. Ist alles per Kabel angebunden. Habe nie ein FW-Update dafür seitens LCN auf der Webseite gesehen. Jetzt, seit neuerem, finde ich das gar nicht mehr auf der Webseite. Entweder veröffentlichen sie das nicht mehr oder es ist für mich zu gut versteckt.

Die LCN-Module sind bis auf wenige Ausnahmen schon etwas älter (so ca. 10 Jahre, evtl. etwas mehr). Wenn ich mich recht entsinne habe ich 1 Relais-Blöcke nebst LCN-SH und ein (bzw. das eine) LCN-UPP ersetzen müssen. Keine Ahnung weshalb die gestorben sind. Es sah mir damals nach Hitzetod aus, ich habe es aber nicht wirklich hinterfragt.

Hier die FW-Versionen lt. Symcon:
140719 LCN-SH+
1B060E/0F0B0B / 1F0715 LCN-UPS
010101 LCN-UPP
Insgesamt sind es 30 Module im Bus. Wenn das hilft poste ich gerne Screenshots aus LCN-Pro. Die Module machen nur noch absolute Basisfunktionen: Tastenkommandos ausführen. Die komplette Automatisierung findet in Symcon statt und LCN ist nur (bzw. sollte nur) Befehlsempfänger sein.
Ich bin kein Spezialist, kann jedoch einfache Sachen selbst parametrieren via LCN-Pro. Zum Beispiel Schalter für Licht an/aus, Rampe, Rolläden, soetwas.

LCN-Gateway in Symcon:
-Require Acknowledgement: Aktiv
-Output-Mode: 50 steps

Verschiedene Tipps aus diesem Thread habe ich schon versucht. Danke übrigens allen die dort etwas beigetragen haben falls jemand davon hier mitliest!

Besonders an tomgr das er seine Skripte zum resetten der Module geteilt hat. Das habe ich auch wie beschrieben erfolgreich bei mir eingebaut. Alle LCN-Module die einen Dimmer oder ein Relais bedienen werden via Skript jede Nacht bei mir resettet. Ich sehe auch in LCN-Pro, dass das funktioniert: Zähler werden alle genullt und Updtime läuft wieder ab 0 los.

Wenn sonst niemand Tipps hat/mir weiterhelfen kann würde ich als nächstes mit dem Mut der Verzweiflung das u.g. versuchen.

Wie ich oben schon erwähnt habe, habe ich Probleme mit Timeouts. Im Log sieht das dann etwa so aus:
Date/Time ScriptEngine Result for Event 17192

Warning: Zeitüberschreitung beim warten auf Antwort in /var/lib/symcon/scripts/23492.ips.php on line 66

In der Praxis bedeutet das, dass der betreffende Rolladen oft nicht fährt - alle 2 oder 3 Tage ist einer dabei der nichts macht. Im Falle von SC_MOVE, das ich für eine selbst gescriptete Beschattung nutze (wo ich natürlich viel mehr Kommandos absetze und das auch viel mehr auffällt), macht es gleich nochmal so viel Spaß wenn die Rolläden herunterfahren und kein Stop-Kommando bekommen da Symcon gar nciht mitbekommen hat, dass der Rolladen losgefahren ist.

Für zeitgesteuertes hoch/runter und bei der Beschattung für komplett hoch nutze ich inzwischen, damit der Status wengistens ein paar Mal am Tag mit einer gewissen Wahrscheinlichkeit wieder richtig ist, LCN_ShutterMove.

Das sieht dann ca. so aus: (ich nehme gerne Tipps wie es besser geht, ich bitte euch bei eurer Kritik im Hinterkopf zu behalten, dass ich kein professioneller Programmierer bin/mir alles selbst beibringe bzw. aus den Foren lerne :slight_smile:

//dass da ist der ‚require 28652.ips.php‘. Da sind die Funktionen drin: zum Beispiel: das habe ich so gemacht, dass ich den Befehl bei Bedarf wiederholen kann wenn ich einen Timeout bekomme. Aber selbst 3 Mal reicht ab und zu nicht. Die IPS_Sleep mit random 50 bis 250 ms habe ich eingebaut damit der LCN-Bus nach Möglichkeit nicht mehrere Kommandos zeitgleich bekommt/mehr Zeit zu reagieren. Ich kann wirklich nicht sagen ob es hilft oder genau so gut ist wie mit ohne.
function LCN_MV_DWN($ModulID)
{
if (LCN_ShutterMoveDown($ModulID) === false)
{
IPS_Sleep(rand(50, 250));
if (LCN_ShutterMoveDown($ModulID) === false)
{
IPS_Sleep(rand(50, 250));
LCN_ShutterMoveDown($ModulID);
}
}
}

in den Skripten selbst:
require „28652.ips.php“;

IPS_Sleep(rand(50, 250));
LCN_MV_DWN(51973);

IPS_Sleep(150);
LCN_MV_DWN(41915);

IPS_Sleep(150);
LCN_MV_DWN(48662);

IPS_Sleep(150);
LCN_MV_DWN(20424);

Danke schonmal wenn ihr bis hierher in diesem langen Post durchgehalten habt :slight_smile: und vielen Dank im Voraus wenn jemand einen Tipp für mich hat!

Hi,

können wir uns gerne mal zusammen ansehen.
Ähnliche Effekte hatte ich bei mir auch, es gab letztlich mehrere Gründe.
Was mir geholfen hat, sind 2 Haupt-Massnahmen.
a) Reduktion der Anzahl der LCN Befehle von IPS an an LCN
b) Auswertung der LCN Quittung
Seitdem geht es sehr sicher.
Gerne nächste Woche mal, die Woche bin ich unterwegs

1 „Gefällt mir“

Guden, ja sehr gerne, danke schonmal! - richte mich gerne nach Ihnen, auch bzgl. Kommunikationsmethode (mir wirklich egal - was immer Sie nutzen möchten). Was ich anbieten kann - sofern Ihererseits gewünscht - ist ein Teams-Meeting zu erstellen.

Bin nur kommende Woche Dienstag bis Donnerstag selbst nicht zuhause.

Ich hätte einen Tipp: KNX wäre besser :slight_smile:

Ich fürchte für den Moment muss es das tun was bereits im Haus drin ist :wink:

Ansonsten sagt mir mein Bauch, dass Sie da früher oder später recht haben werden. Alles was ich bisher so in diesen Foren gelesen habe läuft etwas auf das Fazit, dass man dieses Verhalten bestenfalls auf ‚ ist ok genug’ Level bekommt. Im Moment hat das Solardach und danach die Heizung jedoch höhere Priorität.

Moin,
vorab mal: neuere LCN-Module aus den letzten Jahren haben nicht unbedingt die ‚Perfektion‘, die ich aus >20 davor liegenden Jahren gewohnt bin. Schon mal mit der LCN-Hotline dazu kommuniziert? Austausch/Reparatur von fehlerhaften Modulen ist nach wie vor so kulant wie ich das von keinem anderen Hersteller kenne. Im Zweifel helfe ich da gerne weiter.

Wenn ich das LCN-VISU richtig deute, ist das noch nicht die aktuellste Hardware mit einer Kollisionserkennung (wie die Module das auch machen). Zu erkennen an einer 2. Reihe LED, die ‚blinkern‘ wie bei den Modulen. Zu den „höheren“ PCHK-Versionen (>3.2.2) gibt es keine Doku - was da ‚verbessert‘ wurde ist (mir) nicht bekannt.

Die Lösung von Jan-Peter läuft auch bei mir - damit ist die Kommunikation (= „verschluckte“ Kommandos) um ein vielfaches besser geworden.

Wenn ich den ‚Guden‘ richtig definiere ist das eine hessische Lokalität - mein Arbeitgeber (unser Büro) sitzt in Rödermark bei Frankfurt. Falls das passen sollte schaue ich auch gerne mal persönlich zum fachsimpeln vorbei (wenn ich mal wieder dort bin).

Grüße, Uwe

1 „Gefällt mir“

Hallo Uwe
vielen Dank!

Issendorf habe ich dazu noch nicht angerufen - ich wüsste aber ehrlich gesagt auch nicht richtig was ich sagen soll. Wird man denn von denen als nicht-Profi ernst genommen wenn man ein Problem mit einer Anbindung an ein Fremdsystem meldet?
Wenn du dich auf die gestorbenen Module beziehst - die sind schon lange beim Wertstoffhof :wink:

Das LCN-VISU dürfte eines aus der ersten Generation gewesen sein. Es hat wie du beschreibst nur eine LED-Leiste. Das sind die sichtbaren LEDs: ‚ON‘, ‚ERR‘, ‚ACT‘, ‚WLAN‘. Wäre mMn recht ärgerlich wenn da ein wesentliches Feature fehlt das nicht via FW Upgrade nachgerüstet werden kann…

Korrekt, Hessen, südlich von Frankfurt, ca. 50km von Roedermark. Ich kann auch gerne Mal in deine Richtung kommen. :slight_smile: Bei mir: Die Kaffeemaschine liefert heißen Kaffe, Tee ist vorhanden und die Softdrinks gibt es auf Wunsch mit Eiswürfeln :wink: Quatschen auch gerne unabhängig von diesem Problem. So schrecklich viele in meinem Dunstkreis interessieren sich nicht für diese Themen.

Gruß
Christian

Ich vermute ein Hardware Problem, ev auch das Lcn-visu. Wenn du die Möglichkeit hast, einen alten Lcn koppler zu probieren, würde ich das versuchen.
Auch könnte ein Lcn Modul den Bus stören, hatte ich auch schon mal🥲

Beim LCN-VISU sind mir bislang keine Probleme bekannt - Probleme hatte da nur die erste Generation des Vorgängers LCN-PKE.
Das aktuelle VISU hat Änderungen an der Hardware, da ist mit FW nichts zu holen.

Bei der letzten Generation(en) von LCN-Modulen sieht das anders aus … :roll_eyes:

Zum quatschen treffen wir uns auf jeden Fall …
Grüße, Uwe

Ich habe mal angefangen, ein Skript zu schreiben, welches ein Debug-Log für die LCN-Clientsocket erstellt und im Hintergrund auswertet, um dem „zu viel Traffic“ Problem auf die Schliche zu kommen, das in größeren LCN-Installationen leider auftreten kann. Bin allerdings nicht zur Vollendung gelangt, vor allem weil die zeitliche Auflösung der Logs in IPS nur sekundengenau ist und ich darum nie sicher sagen kann, wie viele Bustelegramme ein Modul pro Sekunde wirklich abbekommt. Es bleibt bei einer Schätzung von-bis und diese Spanne ist so groß dass ich die Erkenntnisse nicht mehr hilfreich fand.

Kann das Projekt aber noch mal reaktivieren, falls Interesse besteht. Im Prinzip wird einfach das Logging in eine Datei aktiviert, dann wieder gestoppt, die Datei ausgelesen und wieder aktiviert usw. im 10-Sekunden Intervall.

Edit: Wäre vermutlich einfacher gewesen, verwertbare Statistiken zu bekommen, wenn ich direkt auf die Client Socket gelauscht hätte, aber das wäre ein ganz anderer Ansatz und ich müsste dafür eh von vorne anfangen.

Moin Clemens,
ein debug ist ja prinzipiell gut - behebt aber IMHO nicht die Fehler (i.d.R. „verschluckte“ Kommandos).
Das was Jan Peter da „zusammengescriptet“ hat wiederholt solche Kommandos - damit werden sie (ggf. mit einem kleinen delay) recht sicher ausgeführt.
Nach meinen bisherigen Erfahrungen ist das aber nicht in allen Anlagen notwendig - oftmals reicht auch schon die in IPS integrierte Quittung.
Mit welchen Konstellationen (HW/FW) solche Fehler vorkommen hat sich mir noch nicht wirklich erschlossen …

Grüße, Uwe

Danke Tom - ich habe noch mein altes PKE. Das kann ich aber leider (oder wenn wüsste ich nicht, dass das so ohne weiteres geht) nicht verwenden. Seit DSM Version 7 kann man keine USB Geräte mehr an virtuelle Maschinen oder Container durchreichen. Daher denke ich, dass das zumindest als erster Schritt keine Option ist.

Gruß
Christian

Vielen Dank für dein Angebot, bzw. im allgemeinen euch allen für eure Hilfe! Mir ist bewusst, dass ihr alle Community-Member seid und das rein freiwillig und in eurer Freizeit macht. Daher: Bevor es zu verrückt wird was den zeitlichen Aufwand angeht würde ich das Thema eher fallen lassen und mittelfristig mit dem Problem leben während ich mir überlege was ich mache. Ich hoffe aktuell irgendwie immer noch, dass es evtl. nur ein relativ triviales parametrierungs- / ankabelungs- / ein Modul muss Mal ersetzt werden Thema ist.

Na, keine Sorge, ich habe das ja auch aus ganz eigenem Interesse mal angefangen. Also bloß kein schlechtes Gewissen, wenn daran Interesse bestehen sollte :wink:

1 „Gefällt mir“

Moin,

Ich klink mich mal mit ein. Ich habe das Problem erst seit dem ich mit dem shuttermodul arbeite. Wahrscheinlich fragt das enorm oft den Stand der Rollos ab. Auf der alten Installation von IP-Symcon habe ich nur hoch runter genutzt. Gab es nur ganz ganz selten mal ein sichtbaren Timeout.

Ich fahre die Rollos aktuell aber auch nicht automatisch über IP-Symcon- sonder direkt über LCN (zumindest hoch).
Den Timout erhalte ich z. B. Wenn ich abends das Rollo im Bad auf herunterfahren klicke über die App.

Also debug-log, wenn nicht Zuviel Aufwand sehr gerne :wink:

Schöne Grüße aus Nordhessen

Jörg