Kommandos an LCN-Module kommen nicht zuverlässig an

Ja, ist denn schon wieder Weihnachten? :santa:
Mein Wunschzettel ist erfüllt, ich werde das „Türchen“ dann mal ordentlich quälen und bin schon auf das Ergebnis gespannt.
Dicken Dank @paresy :loveips:

Grüße, Uwe

Hallo zusammen,

das Nikolaus Geschenk habe ich installiert. Es kommt zu relativ viel Warn- und Fehlermeldungen:

Wo erfolgt die Konfiguration?

Hallo zusammen,

ich habe nach der Installation den gleichen Effekt. Heute morgen waren es über 300 TimerPool-Fehlermeldungen …Warten auf Antwort.

Was ist zu tun?

Viele Grüße

Könnt ihr mir ein paar Hinweise geben, um welche Module es sich handelt? Sind das die „alten“ Module oder sind das „neue“ Module mit den 12 Variablen?

@janpeterdietz Was genau sollten die Ereignisse schalten, bzw. welche Befehle nutzt du dort?
@RitterFridolin Kannst du ebenfalls mal schauen, was bei dir genau betroffen ist? (Die „Request“ Meldungen kannst du mal ausklammern - die müsste ich hier nachstellen können)

paresy

Hi,

a) Schalten eines Relais:
LCN_SwitchRelay(55794, false);
Ist ein altes LCN Modul

b) Setzen Solltemperatur
LCN_SetTargetValue(53714, 0, GetValueFloat($Id_Programm_Temperatur));
Ist ein altes LCN Modul

Gruß
Jan Peter

Hallo paresy,

anbei ein kleiner Auszug. Überwiegend alte Module.

Moin,
bei den Values gibt es kleine aber feine Unterschiede, die ich auch schon in den Meldungen so gesehen habe. Ich versuche auch noch mal das nachzuvollziehen.
Die alten Module (3 Variablen) wollen immer eine Anfrage (oder ein Änderungskommando) um ihre Werte zu melden. Die Meldung kann sich dann ggf. auch verzögern - es ist ja „nur“ eine Meldung, kein Kommando. Da kann es also schon reichen die Zeit für die Antwort größer (als die jetzige ‚Zeitüberschreitung‘ auslöst) zu wählen.
Die neuen Module mit 12 Variablen ‚plappern‘ regelmässig (wenn ich richtig bin alle 2 Minuten) ihre Werte in den Bus, reagieren aber auch auf eine eingetragene Abfragezeit bei den Values - das belastet den Bus aber zusätzlich und eigentlich unnötig.

Grüße, Uwe

Leider kann ich das Problem mit den Request’s mit den alten Modulen hier nicht nachstellen. Könnte ich bei jemandem mal raufschauen, der die Probleme aktuell hat?

Wir warten aktuell übrigens 2 Sekunden.

paresy

Könnte dir das anbieten :

Modul27 ist Firm 0F02…, Modul22 ist Firm. 140C…

Neue Warunungen zur Zeitüberschreitung bei den Kommandos:

LCN_SetIntensity($id_wohnzimmer, 0, 1);

LCN_SetIntensity($id_gadarobe, 0, 1);

2 Sekunden scheinen einfach zu kurz zu sein. Ich werde dies mal auf 5 Sekunden erhöhen und eine neue Version bauen.

paresy

Dann bitte auch gleich „Abschalten der Quittung“ mit einbauen, zum testen kann man dann ja wieder umschalten.
Falls du mal hier auf’s LCN schauen willst, kannst du das ja auch mit KaiS machen, wenn ich mal nicht da bin.
Habe das Gefühle, dass einige BWM’s sporadisch im Moment zu spät schalten.

Das Gefühl teile ich - die Programmierung dazu ist bei mir aber immer (meistens) direkt im LCN. Da wird aber auch die Quittung abgefragt … und wenn da gerade etwas stärkerer Busverkehr ist, dauert das halt „etwas“ (1 Sekunde ist ja schon eine gefühlte Ewigkeit).

@paresy 5 Sekunden finde ich gut (den Versuch wert)

Grüße, Uwe

Hallo an alle LCN-ler,

ich möchte noch mal in Erinnerung bringen, worum es eigentlich geht. Ich möchte mich einfach darauf verlassen können, das die per Script abgesetzten LCN-Befehle zuverlässig verarbeitet werden und dies durch die Quittungsüberwachung sicherstellen.

Wir wissen, dass die von IPS abgesetzten Telegramme über das PKE ohne Kollisionserkennung in den BUS „gedrückt“ werden. Dies führt gelegentlich zur Kollision mit anderen Telegrammen was LCN weniger stört, da dieses die Quittung des angesteuerten Moduls erwartet und ggf. erneut sendet.

Ich hatte gehofft, dass die Quittungslogik in IPS nun dazu führt, dass ein ähnliches Verhalten realisiert wird. Also falls keine Quittung in einstellbarer Zeit (x Millisekunden per Parameter einstellbar) zurückkommt, sollte der Befehl erneut gesendet werden und nach y Versuchen (ebenfalls per Parameter einstellbar) sollte das Verfahren abgebrochen werden und ein Fehler gemeldet werden.

Hatte jemand eine andere Vorstellung?

Bin leider schon etwas frustriert vom Nikolaus, habe seit der Installation von 6.1 Beta bereits über 1000 rote Fehlermeldungen und ca. 100 Warnungen mit Zeitüberschreitung bei Warten auf Antwort.

Einen schönen Tag an Alle!

Definitiv :slight_smile:

  1. Das aktuell Update wartet nicht lange genug. Ein Fix kommt da im Laufe des Tages, sodass deine 1000 Fehlermeldungen sehr schrumpfen werden und wahrscheinlich nicht ein paar übrig bleiben.
  2. Die Retries werden wir nicht auf Gateway-Ebene einbauen, sondern diese sind Bestandteil von deinem Skript bzw. mittlerweile besser Ablaufplan, der eine Retry-Machanik mit an Board hat.

In IP-Symcon war es uns immer wichtig Fehler nicht einfach unter den Tisch fallen zu lassen, sondern immer Transparent zurückzugeben. Die einzige Ausnahme ist Z-Wave; aber das ist ein anderes Thema :wink:

paresy

Hallo paresy,

danke für die super schnelle Antwort.

Kann ich ein Beispiel für die Programmierung der Retries im Script bekommen.
Ich habe leider noch sehr viele Script, die ich nicht alle in Ablaufpläne übertragen möchte.

Ich habe versucht mit $status = LCN-Befehl… und dann if($status < 1) …
Der $status war jedoch auch bei Zeitüberschneidungen etc. immer „1“

Danke und viele Grüße
Fridolin

Im Prinzip willst du auf „false“ prüfen.

if(LCN_Irgendwas($id) === false) {
  // nochmal versuchen
  if(LCN_Irgendwas($id) === false) {
    // vielleicht was ins log schreiben?
  }
}

paresy

Moin,
ich habe gerade (mal wieder mehr zufällig) mitbekommen, dass es eine neue LCN-Pro Version hat.
Dort findet sich dann in den (m.E. spärlichen) Changelog Angaben

Timeout Wert beim Einlesen von Modulen wurde 30 auf 35 Sek erhöht

Das hat (für mich) schon fast ein generelles Zeit-Problem auf dem Bus - was nicht schlimm ist, es geht ja.
Mit den Quittungen hat das direkt aber nichts zu tun.

Ähnliche Skripte wie Fridolin habe ich übrigens auch - da kommen dann auch die meisten Probleme (einzelne Kommandos aus dem WebFront gehen deutlich besser).

Grüße, Uwe

Es gibt übrigens ab sofort eine neue Version.

@RitterFridolin Mit der Version bin ich gespannt, wie viele Fehler zu noch sehen wirst. Bei @janpeterdietz sind diese seitdem aktuell auf 0.

paresy

Hallo paresy,

nach dem Update sind bisher keine neuen Fehlermeldungen mehr entstanden.
Das Problem scheint behoben.
Vielen Dank für den tollen Service

Viele Grüße
Fridolin