Kommandos an LCN-Module kommen nicht zuverlässig an

janpeterdietz · 23. Januar 2022 um 12:48

Hallo Paresy,

ich muss noch mal nachfragen.
Also derzeit ist der Timeout 5 Sekunden, das heisst somit du wartest auch bis zu 5 Sekunden bis du den nächsten Befehl versendest?
Ein Retry machst du innerhalb der 5 Sekunden nicht.

Im Gutfall wird wesentlich schneller als eine Sekunde jeder Befehl beantwortet.
Die Beobachtung ist, das (siehe auch Fridolin) das ein Retry reicht.

Warum geht es nicht das du innerhalb der der 5 Sekunden einen Retry machst?
(Natürlich auch mehrere denkbar)
5 Sekunden erscheinen mir bei diesem System wir eine Ewigkeit.

Gruß Jan Peter

UweR · 23. Januar 2022 um 12:56

Moin,
da kommt dann bei mir auch die Verständnisfrage @paresy
Ich habe das so verstanden, dass für 5 Sek. probiert wird das Kommando (bis zur positiven Quittung) los zu werden (mit der Beschränkung max. 5 Kommandos/Sek. zu verschicken).

Und ja: auch bei mir ist die Erfahrung, dass ein Kommando spätestenes beim 2. Versand ‚erfolgreich‘ ist.

Grüße, Uwe

RitterFridolin · 23. Januar 2022 um 15:27

Hallo an alle IPS und LCN - Fans.

Ich habe zwischenzeitlich (fast) alles auf eine zentrale Stelle mit dem LCN Sendbefehl umgestellt. Da habe ich einen Zähler für jeden Aufruf eingebaut. Ergebnis nach 6 Tagen 4217 Kommandos in den Bus, 159 mal einmal wiederholt, 4 mal 2 mal wiederholt und 0 dreimal. Ich bin mit dem Ergebnis zufrieden.
Die Kombination läuft. Meinen Dank an das IPS-Team. Stören tun mich nur noch die Warnmeldungen bei Temperstur-Requests, die sollte man optional je Instanz abschalten können.

Herzliche Grüße
Fridolin

UweR · 23. Januar 2022 um 16:03

Moin Fridolin,
das halte ich auch für ein vorzeigbares Ergebnis. 165 Kommandos die sonst „untergegangen“ wären sind schon eine Hausnummer (wenn auch „nur“ ~1,5%).

Die Temperatur-Requests sind von LCN/PCK schon recht „döselig“. Damit bin ich auch nicht glücklich. Je älter die Anlage desto schlimmer wird das …

Grüße, Uwe

RitterFridolin · 23. Januar 2022 um 16:19

Hallo Uwe,

Zur Zeit überlege ich, die vielen Kommandos zu reduzieren. Bevor ich Relais schalte, könnte ich den Zustand vorher abfragen und das Kommando nur senden, wenn sich der Zustand tatsächlich ändert.
Was ist deine Meinung dazu?

Herzliche Grüße
Fridolin

ralf · 23. Januar 2022 um 16:46

Du könntest sicherlich das Senden optimieren, aber ca. 700 Telegramme am Tag sind ca. alle 5 Minuten eins.

Ist bei dir insgesamt so viel los auf dem Bus, dass diese geringe Anzahl auch noch wiederholt werden muss?
Ist der Bus physisch in Ordnung?

UweR · 23. Januar 2022 um 17:18

Moin Fridolin,
das sehe ich auch so wie Ralf - Optimierung kann sinnvoll sein, muss aber auch nicht zwingend sein.
Der LCN-Bus steckt das locker weg, meine Anzeige in der Pro pendelt bei mir derzeit immer zwischen 10 und 15 T/s, läuft aber auch wenn da Zahlen >30 stehen würden immer noch klaglos. Nach der Spezifikation kann KNX nur 1/10 der Buslast von LCN „verkraften“ - da kommt bei den Kollegen dann auch kein „kann nix“ bei raus. Läuft …
Auch ein direkt im LCN programmierter Bewegungsmelder sendet ja immer wieder seine Kommandos - ohne Rücksicht auf Verluste (aber immer mit Quittungsanforderung).
Das was neuere Module (ab FW17…) da von sich aus an StatusMELDUNGEN immer wieder in den Bus pusten ist (im LCN) auch nicht optimierbar/einstellbar - da ist ein wenig ‚pollen‘ bei älteren Modulen auch nur 1 (Abfrage)Kommndo mehr.

Das „größte“ Problem können wir ohnehin nicht beheben. Die Kollision von Telegrammen, die über PCHK kommen ist quasi in der Hard/Software integriert. Da müsste (so wie LCN-Module das „intern“ auch machen) eine Erkennung von Busaktivitäten vom Hersteller integriert werden.

Ich sehe das ganz entspannt.
Grüße, Uwe

janpeterdietz · 25. Januar 2022 um 18:41

Hallo an LCN Fans,

die Lösung Fridolin ist gut.
Eine Zentraleinheit um die LCN Befehle auszuwerten und evtl. Repeat einzubauen.
Jedoch widerspricht es aus meiner Sicht dem Ansatz von IPS das alle Systeme einfach integriert werden. Ich schalte mittlerweile auch gerne LCN Module über RequestAction, das ist schon bequem und gut (und echt Klasse).

Jedoch ist es so nicht sinnvoll möglich eine zentrale Stelle einzufügen und an sich gibt es diese schon. Ist der LCN Socket, von daher würde ich mich sehr freuen wenn die Wiederholung beim Fehlschlagen dort integriert werden.

Bei mir gibt es Fehler; über verschiedene Arten von Versuchen kommen ich auf eine Fehlerrate von ca. 0,1%. Ich bin überzeugt das durch den Repeat an zentraler Stelle die Fehlerrate nicht mehr messbar wäre.

Viele Grüße Jan Peter

RitterFridolin · 26. Januar 2022 um 07:59

Hallo Jan Peter,

ich würde es ideal finden, wenn man in jeder LCN-Instanz die Wartezeit in Millisekunden und die Anzahl automatischer Wiederholungen je fehlerhaftem Zugriff frei einstellen könnte, auch bis zum Timeout. Es gibt wichtiges und unwichtiges in der Ansteuerung. In der Automation gibt es ja was ähnliches für jede Automation. Dann wäre vermutlich allen geholfen.
Ich habe mir zwischenzeitlich eine Ersatzlösung über eine Include-Datei gebaut, welche ich überall einbinde und verwende nur noch das LCN Send Command, welches ich bei Fehlermeldungen wiederhole. Für mich ist die Anbindung zwischenzeitlich weitestgehend stabil und beherrschbar. Aber wie gesagt, dein Vorschlag über den LCN Socket wäre auch eine weitere Verbesserung. Vielleicht denkt das Team um @paresy über die Vorschläge nach.

Noch ein Hinweis: Seit dem ich bei alten Module, bei denen besonders viele Fehlermeldungen entstanden sind, die Verwendung auf das reine Schalten der Aktoren reduziert habe (keine logischen Relais, LED und Logik mehr), liegt die Wiederholungsquote nun nur noch bei ca. 0,8%. Die darin enthaltene Logik habe ich in IPS-Skripte verlagert, und das funktioniert prima. Danke auch hier für deinen Tip.

IPS ist eine prima Sache, und wenn die Experten in Lübeck noch etwas nachlegen wird’s für LCN die perfekte Lösung.

Noch eine Bitte an @paresy: Die Dokumentation mit guten Beispielen hat noch viel Luft nach oben. Ich kenne das aus eigenen Erfahrungen, für die Experten ist alles klar, weil sie ständig damit arbeiten, die Freizeit- und Gelegenheitsentwickler tun sich da schon deutlich schwerer und verlieren viel Zeit durch aufwändiges Experimentieren. Hier könnte IPS noch deutlich attraktiver werden.

Herzliche Grüße
Fridolin

UweR · 26. Januar 2022 um 09:06

Moin,
Probleme (vor allem bei den älteren Modulen) machen alle Werte die immer wieder abgefragt werden müssen - also LED, Logik, Temperaturen. Die aus der Abfrage entstehende MELDUNG hat keine Quittung und kann untergehen.
Ein logisches Relais kann ich (mit Quittung) schalten wie ein „echtes“.

Zur Doku (die dann ja wohl @Pio landet): ja, natürlich ist da Luft nach oben. Meine Erfahrung mit den letzten Baustellen zeigt aber auch, dass ich meist „nur“ Nutzer erzeuge. Die können dann nicht mal den Dienst auf der SymBox neu starten - weil sie die (grundlegende) Doku gar nicht erst lesen. Man muss/sollte also schon Kosten/Nutzen abwägen.
Die für ein LCN Send Command notwendige PCK-Doku wird dann erst recht nicht genutzt - sie ist nicht Bestandteil von Symcon (und sie ist tw. auch so „unverständlich“, dass selbst ich immer wieder „Test Command“-Skripte erzeuge). Außerdem ist sie personifiziert und muss ‚angefordert‘ werden - sie ist nicht im Download verfügbar.

Grüße, Uwe - der die grundlegenden Verbesserungsvorschläge auch für sinnvoll ansieht

RitterFridolin · 26. Januar 2022 um 10:59

Hallo Uwe,

ich stimme dir grundsätzlich zu. Ich verwende das LCN Send Command in Verbindung mit der PCK-Doku hauptsächlich deshalb, weil ich hier den Aufruf zentralisieren und überwachen kann. Natürlich auch, um z.B. alle Relais eines Moduls mit einem Befehl zu schalten Wäre die Logik wie vorgeschlagen in den Instanzen oder im LCN-Socket grundsätzlich gelöst, würde ich die bereitgestellten LCN-Kommandos in IPS verwenden.

Bis zur Lösung des Zuverlässigkeitsproblems in Version 6.2 war ich der Meinung, möglichst viel direkt in LCN gestalten zu müssen. Dies bedeutete für mich mehr Zuverlässigkeit aber dies eben auch mit allen Aufwendungen die hier entstehen. Zwischenzeitlich bin ich dazu übergegangen, LCN auf die wichtigen Basisfunktionen (z.B. je Ausgang eine Taste für manuelles an/aus) zu reduzieren und den Komfort in IPS durch Skripte zu überführen. Dies ist für mich zwischenzeitlich viel schneller, einfacher und langfristig auch besser dokumentiert. Deshalb auch mein Hinweis z.B. auf logische Relais zur Speicherung von Zuständen zu verzichten und diese durch Variablen in IPS abzubilden. Dies reduziert auch die Anzahl der Kommandos in den Bus.

Dies birgt natürlich auch folgendes Risiko: Wenn IPS (die Symbox) ausfällt, dann ist auf einen Schlag aller Komfort weg. Deshalb die Frage in die Runde: Wie sehen hier die Sicherheitskonzepte (Backup-Lösungen) bei euch aus? Welche Empfehlung gebt ihr euren Kunden? @paresy: Gibt es hier eine Empfehlung von Symcon. Am liebsten wäre mir hier eine automatische Backup-Lösung, damit man entspannt in Urlaub fahren kann.

Bin gespannt auf euere Meinung.

Herzliche Grüße
Fridolin

UweR · 26. Januar 2022 um 13:04

Moin Fridolin,
meine Meinung entsteht aus meiner Erfahrung.
Die Ausführung von Summen etc. ist im LCN genauso unsicher wie aus IPS - sobald da MELDUNGEN beteiligt sind, funktioniert das weder in LCN als auch in IPS nicht zu 100%.
Ansonsten mache ich das genau wie du - der Komfort kommt aus IPS. Am besten per KOMMANDO.
Ausfälle der SymBox kann ich nur beklagen, wenn ich „bastele“ und ‚Fehler 40‘ erzeuge - da laufen selbst beta-Versionen bei mir völlig klaglos (mit LCN, bei anderen Systemen mag das vielleicht anders aussehen).
Ich hatte vor ein paar Tagen gerade einen Ausfall meines PKU - da war dann auch „Ende mit Komfort“. Nach meiner Erfahrung sind die Fehler/Defekte meistens eher im LCN zu suchen als im Symcon.
Die LCN Kommandos in IPS machen übrigens nicht anderes als ein SendCommand ‚PCK‘. Das resultiert daraus, dass LCN seine „geheimen“ Kommandos der personifizierten Doku nicht öffentlich sehen möchte/wollte - was ich für völligen Blödsinn halte (Google weiß das schon).
Was mir immer wieder mal fehlt ist ein Kommando an eine Gruppe (also nicht M… , sondern G…) - hat aber auch den Nachteil, dass die PCHK nicht weiß, wer alles zur Gruppe gehört. Somit kommen dann zwar Quittungen von allen Gruppenmitgliedern, die sich aber (ohne tiefere Kenntnis) nicht zuordnen lassen. Da werden dann 5 ‚einzelne‘ Kommandos aus IPS sicherer ausgeführt …

Grüße, Uwe

tomgr · 26. Januar 2022 um 19:20

Beispiel : 26.01.2022, 20:06:42 | TRANSMIT | >M000007!GTDT32,6° O53,5°
und 26.01.2022, 20:08:39 | TRANSMIT | >M000027!MWTB (auch alle anderen Messwertabfragen mit MW )
brauche ich keine Quittierung.
Daher ist das bei mir abgeschaltet, nur für diesen Post mal kurz in Betrieb gesetzt.

Das „!“ dürfte für mich, nur bei bestimmten Kommandos gesetzt werden, sonst geht der Schuß hier nach hinten los.

Und ja, LCN Module altern und machen im „Rentenalter“ doch mehr Probleme.

lg Thomas

ps 26.01.2022, 20:18:42 | TRANSMIT | >M000007.GTDT32,6° O55,1°
ist doch viel entspannter im Bus.

paresy · 26. Januar 2022 um 20:17

Ich nutze mein DropBox Modul und habe dann alle Daten falls mal was sein sollte. Dann würde ich schnell einen Docker oder Pi hochfahren bis ich ne neue SymBox aus dem Lager nehmen darf Die Ausfallrate unserer SymBox ist zum Glück extrem gering. Da fällt schon mal schneller das Netzteil aus als die SymBox selbst

paresy

janpeterdietz · 30. Januar 2022 um 08:38

Hallo zusammen,

ich einen Versuch gemacht. In IPS ist die LCN Quittierung abgeschaltet.
Ich schalte alle 5 Sekunden auf einem sparten Modul einen Ausgang um.
Es wird nicht der IPS Befehl genutzt sondern:

$TX_BUF = '>M000099!A4DI100000'.chr(10);
CSCK_SendText(13690 ,$TX_BUF); // an den Client Socket LCN

Über eine Registervariable erhalte ich die Quittierung die nach dem Senden alle 100ms abgefragt wird in der Sendefunktion.
Ist nach 300ms keine Quittierung erfolgt wird erneut gesendet.
Es wird bis zu dreimal nach je 300ms der Befehl erneut gesendet.

Ergebnis nach 10000 Durchläufen: 42mal musste 1 mal wiederholt werden / 2 mal musste 2 mal wiederholt werden. Alle anderen kamen ohne Wiederholungen aus.
Maximales Timeout ca. 700ms. (Es ist kein 3 faches Wiederholen aufgetaucht. )

Wäre schon cool wenn die Sendewiederholung in IPS erfolgt.

Viele Grüße Jan Peter

RitterFridolin · 30. Januar 2022 um 10:44

Bin gerade unterwegs, habe meine Statistik der letzten 3Tage abgerufen

Ähnliche Ergebnisse

Viele Grüße
Fridolin

RitterFridolin · 1. Februar 2022 um 12:21

Hallo LCN-Gemeinde mit alten Modulen. Wichtiger Hinweis an @ paresy

Thomas hat die Idee vorgetragen, direkt in den Bus die Temperaturabfrage zu senden und das Ergebnis zu verarbeiten. Dabei habe ich das passende Kommando
$befehl=">M000067!MW".chr(10);
CSCK_SendText(13246,$befehl);
verwendet.

Als Ergebnis kommt auch sofort die Antwort:

Die Temperatur im LCN-Format 18,9 Grad wird allerdings von IPS nicht weiterverarbeitet:

Am Datum ist zu erkennen, dass die Variable nicht aktualisiert wird.

Wird hingegen der IPS Befehl zum Abruf der Temperatur verwendet, sieht das so aus:

Und das Ergebnis wird auch in die Variable übertragen.

Nun vermute ich, dass IPS die Temperatur-Meldungen der alten Module ignoriert, falls nicht zuvor der Befehl für die passende Abfrage gesendet wurde.

In LCN ist einstellbar, dass die gemeldete Temperatur immer in TVar kopiert werden kann. Es ist meines Wissens auch nur ein Temperatursensor am Modul abschließbar, so dass man in IPS annehmen kann, dass falls die Variable TVar aktiviert ist, der gesendete Messwert immer da hineingehört.

Thomas hat recht wenn er schreibt, dass eine Request für das Auslesen der Temperaturen nicht zwingend erforderlich ist. Entweder der Wert kommt oder nicht, und falls nicht, dann eben beim nächstem mal.

Was spricht also dagegen, dass IPS die Temperaturmeldungen der alten Module immer in die TVar reinschreibt (falls angelegt), anstatt diese einfach zu ignorieren. Damit wären vermutlich alle Probleme vom Tisch.

Ich freue mich auf eine Antwort aus dem Hause Symcon.

Herzliche Grüße aus dem Schwarzwald
Fridolin

tomgr · 1. Februar 2022 um 13:06

Hallo Fridolin,

in der Tvar können auch mal andere Werte drin sein, also wird das so nix.

RitterFridolin · 1. Februar 2022 um 13:22

Hallo Tom,

ist doch egal, was für ein Wert in der Variable steckt. TVar referenziert doch eindeutig. Oder?
Mach mal ein Beispiel wo das nicht funktioniert.

Die Beziehung ist doch eindeutig, egal was drin steht:

Was meinen die anderen Experten?

Grüße
Fridolin

RitterFridolin · 1. Februar 2022 um 13:42

Hallo paresy,

vielen Dank für die Empfehlung. Leider kann ich bei diesem Konzept dann doch nicht entspannt in Urlaub fahren , da ich im Störungsfall keinen Zugriff auf die Hardware habe. Ich könnte mir aber folgendes vorstellen:

Ich gönne mir eine zweite Symbox inkl. Netzteil. Gggf. auch ein zweites LCN PKE (Visu).
Beide Netzteile hängen an LCN-Relais. Ein in LCN programmierter Watchdog (Timer) schaltet nach x Minuten die erste Symbox (Master) ab und startet die zweite Symbox (Slave) falls der Master den Watchdog nicht zyklisch (<x Minuten) zurückstellt. Auf den Slave installiere ich regelmäßig eine Kopie (Sicherung) des Masters. Das würde zu einer vollautomatischen Backup-Lösung führen.

Wäre das was? Vielleicht gibts ein Sonderrabatt für die zweite (Backup-)Symbox

Gibt es schon Überlegungen, zu dem Thema: „… ich würde es ideal finden, wenn man in jeder LCN-Instanz die Wartezeit in Millisekunden und die Anzahl automatischer Wiederholungen je fehlerhaftem Zugriff frei einstellen könnte, auch bis zum Timeout …“

Herzliche Grüße
Fridolin