habe gerade noch einmal genauer hingeschaut. Es scheint so, dass die Antwort der alten LCN-Module auf alle Messwertanfragen und auch auf die Sollwertanfragen das gleiche Muster zurücksenden. Für mich würde eine Lösung dennoch sinnvoll sein, da ich einzig die TVar benötige. Vielleicht hilft da ein Script, welches die „Registervariable?“ überwacht und den Wert in die jeweilige Variable schreibt. Betroffen sind 12 Module, die ich fest benennen kann. Kennt sich hier jemand aus?
Das ist das Problem mit den alten Modulen. Und deshalb können wir nur korrekt reagieren, wenn wir wissen, was wir abgefragt haben. Wenn du an uns vorbei Abfragen sendest, landet das Ergebnis im Zweifelsfall in der falschen Variable. Das sollte man somit nicht tun (hatte ich weiter oben schon mal geschrieben). Die Annahme, dass nur die TVar ausgelesen wird, ist leider nicht für alle Kunden korrekt und somit nichts, was wir einbauen können.
das ist richtig und ich hab den Versuch nur noch mal auf den Hinweis von Thomas gestartet. Wenn ich den IPS-Befehle LCN_RequestRead verwende habe ich eben laufend den Müll der Timeout-Warnungen. Über den offiziellen Weg des LCN-Send funktioniert die Abfrage eines Messwertes ja auch nicht. Hier wird in den Bus das gleiche Kommando wie auf direktem Weg abgesetzt und in der Antwort aber auch nicht weiterverarbeitet. Ich verstehe schon, dass hierfür von euch speziell das LCN_RequestRead - Command entwickelt wurde. Somit wäre es ideal, wenn das in der Instanz eingestellt werden könnte. Aber ich denke darüber gibts bestimmt schon Überlegungen.
Ansonsten bin ich sehr zufrieden. Alles läuft aktuell sehr gut !
wenn es dir um die Fehlermeldungen geht, vielleicht kannst du das auch anders lösen.
Die alten Module melden nicht selbst ihre Messwert. Die neuen Module können einen Messwert von anderen (auch alten) Modulen abholen.
Über diesen Weg würden dann die neuen Module die alten Module fragen und den Wert an IPS senden.
Habe ich nicht wirklich lange geprüft, aber könnte gehen…
Die Reglerrechnung ist schon genial, habe ich jahrelang"missbraucht" und tue das heute noch.
Aber das was ich mache, kann symcon nicht einbauen.
Ganz ehrlich, in bin froh, nicht einen LCN-TS zu haben, aber viele Temperaturen, die auch regeln.
Bei mir steigen auch immer mehr alte LCN Module aus, und die ersetze ich nicht mehr mit neuen LCN Modulen, da andere Dinge einfach mehr können.
Hm, kann sein das ich auch noch ne grüne Leitung bei mir nachrüste. Aber das steht noch nicht fest.
Gerne helfe ich bei LCN Fehlersuche noch mit, und ab und an hilft es auch mal auf die Elektronik zu schauen, wenn mal wieder ein Kondensator den Deckel aufgemacht hat. Aber das kann der Laie nicht.
Meine letzten Busfehler wurden durch defekte Module verursacht, die langsam aufgegeben haben.
vielen Dank für den tollen Tip. Hätte ich auch eigentlich selbst draufkommen können, da ich das Prinzip innerhalb LCN mehrfach verwendet habe. Aber vor lauter Wald keine Bäume…
Ich habs gestern Abend noch umprogrammiert und tatsächlich, es funktioniert sofort. Alle 12 alten Messwerte werden nun von 4 neuen Modulen (es gibt je Modul nur 3 mal Messwert holen) ausgelesen und dann vollautomatisch an IPS transportiert. Die Request-Aufrufe habe ich entfernt und siehe da, keine (gelben) Fehlermeldungen mehr im Status.
Das Problem ist für mich so super gelöst. Vielen Dank noch mal.
Moin,
natürlich sind neue Module „besser“ und können ggf. mehr - aber für mich ist das nur ein „workaround“, der eigentlich nicht sein muss / sein sollte.
Aber: der eigentliche Grund …
ich ‚kämpfe‘ gerade in einer Kundenanlage (~1Jahr alt) mit dem „umgekehrten“ Problem. Sämtliche Einstellungen für die Einzelraumregelung kommen aus IPS. Der Sollwert wird sicher übertragen und auch mit der Pro entsprechend angezeigt. Wir haben in den meisten Räumen (aus anderen Gründen) die Module ausgetauscht. Jetzt habe ich in mind. 3 Räumen das Problem, dass der Regler nicht mit dem Sollwert arbeitet, die Heizung bleibt kalt. Die LCN-Hotline kann den Fehler nicht nachvollziehen und rät mir zur (mind. vorrübergehenden) Abschaltung vom Symcon. Das fällt aber leider aus - der Kunde würde damit sein meistgenutztes Bediengerät verlieren (und ich die Möglichkeit zur Kontrolle aus der Ferne).
Von ~10 Modulen mit gleicher Firmware und LCN-Programmierung habe ich den Fehler immer wieder in den 3 (gleichen) Modulen. Kennt jemand ähnliche Phänomene? Mein Latein ist da gerade bei „6, setzen“ …
in meiner Anlage musste ich einen Workaround zur Störungsquittung der Heizung einbauen. Die meisten Module sind 0D/0F (also gute 10 Jahre alt). Ich nutze dafür ein paar Statuskommandos (alles was schaltet ist direkt im LCN programmiert) und einige STV-Timer (Relaistimer können die Module leider noch nicht). Die Störmeldung löst den „Reset-Taster“ aus, alles immer mit etwas (1-4 Sek.) Verzögerung. Ich muss jetzt feststellen, dass auch im LCN dann solche Statuskommandos (mit Quittung aus/an das Modul) untergehen - und dann natürlich auch nicht im Symcon entsprechend angezeigt/aufgezeichnet werden (wo nicht geschaltet wird, kommt ja auch keine Meldung).
Wenn ich den in LCN programmierten ‚automatischen‘ Ablauf aber von Hand aus IPS auslöse, kann ich solche Fehler nicht hervorrufen. Die „Buslast“ liegt lt. Pro bei 10-15 T/s.
Auch hier ist mein Latein am Ende … (und nach der/einer Reparatur wird das auch so hoffentlich nicht mehr benötigt).
Hat da auch jemand eine Idee für mich?
Grüße, Uwe - der auch eine fehlerhafte Programmierung nicht ausschliessen möchte, aber auch nicht wirklich sehen kann … (ich würde die „Macke“ nur gerne lokalisieren)
Macht ja wieder Lust auf suchen, wie früher.
Aber da es neue Module sind, habe ich auch keine Idee, und wenn in allen Modulen die Sollwerte sicher passen und dann nicht geregelt wird, hast du den nächsten BUG gefunden. Oder werden die Regler nur gesperrt, durch …
Ich habe mal eine Frage. Seid ich am Wochenende auf 6.1 hochgerüstet habe habe ich ein Problem mit dem LCN_SendCommand-Befehl.
Wenn mehrere SendCommand nacheinander ausführe bekommen ich Zeitüberschreitungsfehler. Die Scripte, in denen ich die Befehle ausführe haben bis zur letzten Woche einwandfrei funktioniert.
Hast du die Quittung im Splitter eingeschaltet? Die Verbindung evtl. mal ‚reconnecten‘ …
Bei fehlerhaften PKU/PKE oder IS habe ich solche Fehlermeldungen auch schon gehabt.
Alles nur Vermutungen, bei mir läuft das klaglos.
Daran habe ich nach fast 2 Wochen suchen auch schon gedacht, Thomas . 4 Augen sehen einfach mehr …
Wegen dem letzten BUG haben wir die Module getauscht - die jetzt eingesetzte FW ist aber an der LCN-Hotline bei allen (nur bei mir nicht) seit >6 Monaten klaglos.
Die Reglersperre war mal ein Bug in einer älteren FW, das kenne ich auch. Ich benötige sie aber für ‚offene Fenster‘ - und sie wäre auch mit einem Sollwert >3000 'sichtbar.
Der „Spuk“ bei mir ist (hoffentlich) morgen vorbei, wenn der HKL-Kollege den eigentlichen Fehler an der Heizung behebt/beheben kann.
Ich schicke dir auch gerne mal die .lp3, Jan Peter. Vielleicht siehst du ja mehr als die Kollegen an der Hotline.
Vorher probiere ich aber mind. an einem Modul noch mal den (ur)alten Bugfix „neu programmieren, aber nicht aus den Vorlagen“. Laut Hotline ist der Bug zwar seit Jahren behoben, aber …
Hab die Quittierungsanforderung rausgenommen. Seid dem funktionieren die Scripte wieder einwandfrei. Seltsam ist, dass das Problem erst nach dem Update aufgetreten ist.
Und in der Splitter ist der Hinweis für einen stabileren Betrieb mit Quittung etwas irreführend.
Ich hatte ein ähnliches Problem, wie Markus. Nach dem Update auf V6.1 hatte ich auf einmal viele seltsame Fehlermeldungen LCN betreffend. Eine Logik konnte ich spontan dabei nicht feststellen…
Nachdem ich die Quittierungsanforderung abgeschaltet habe, funktioniert wieder alles einwandfrei.
ich gehe davon aus, das es vorbei ist wenn die Befehlswiederholung innerhalb von IPS integriert ist.
Was es aber zu Tage bringt, ist das Befehle nicht immer durchkommen.
Durch die Integration der Befehlswiederholung erhalten wir dann eine stabile Lösung.
das Problem, dass Script nicht mehr funktioniert haben, hatte ich nicht. Durch die Fehlermeldungen wurde ich erst darauf aufmerksam ,was in der Vergangenheit nicht zuverlässig funktioniert hat.
Ich habe zwischenzeitlich systematisch alle Funktionen in LCN und IPS überarbeitet und die komplexen LCN-Schaltungen ins IPS verlagert. Alles ist zwischenzeitlich sehr übersichtlich und stabil und dadurch dass ich die Befehlswiederholung selbst im Griff habe, habe ich keine Probleme mehr. Die Wiederholungen liegen zwischenzeitlich bei unter 0,5 Prozent. Die Buslast ist erheblich zurückgegangen und liegt bei ca. 2 Telegrammen je Sekunde. Wenn ich noch etwas Erfahrung gesammelt habe, werde ich hier ein paar Tips einstellen, wie die Wiederholrate gesenkt werden kann.
Meine Wünsche an @paresy, wie z.B. die nun nervige (unnötige) Meldung zur Zeitüberschreitung, die Wartezeit, etc. (Siehe dazu meine Beiträge) je Instanz einstellbar zu machen besteht weiter. Ansonsten ist die Kombination von IPS und LCN für nicht nun sehr gut gelungen. Mein System ist zwischenzeitlich sehr verlässlich.
Ich werde mir in den nächsten Tagen auch eine zweite (neue) Symbox und Visu kaufen und für den Störungsfall eine automatische Umschaltung in die Backup-Hardware per Watchdog realisieren. So erhöhe ich meine Ausfallsicherheit wegen er Zentralisierung aller Komfortfunktionen in IPS.
Moin,
ich habe bei mir gestern auch die Qutittungen wieder abgeschaltet - da scheint noch ein Fehlerteufelchen drin zu sein das @paresy wohl noch beseitigen muss.
Meine Erfahrungen: mit der Quittung wurden Kommandos an LCN immer sicher ausgeführt (das war vorher ab und an ein Problem). Aber: mit Quittung gehen mir Statusmeldungen unter - und das auch direkt im LCN.
Somit wurden also auch Summen/Logik im LCN (wo die LED auch nur auf Statusmeldungen reagieren) nicht mehr sicher ausgeführt. Außerdem fehlten mir immer wieder aktuelle Anzeigen von LCN im IPS. So manches Skript reagiert da bei mir auf Änderungen eines Bewegungsmelders oder eines Relais - und wurde dann nicht ausgeführt.
Des weiteren ist mir dabei aufgefallen, dass ich bei/nach der Änderung des Quittungshäkchen den Socket einmal neu verbinden muss, sonst verweigert er den Dienst. Das sollte man (wenn wirklich notwendig) auch gleich mit aufnehmen - wobei nach meinem Verständnis eigentlich vor den Kommandos nur ein ‚!‘ mehr übertragen wird, was den Socket eigentlich nicht wirklich stören sollte.
Bereits nach ein paar Stunden konnte ich feststellen, dass meine Logik/Summe(n) im LCN auch wieder ‚sicher‘ ausgeführt werden.
. 4 Augen sehen einfach mehr …
- die jetzt eingesetzte FW ist aber an der LCN-Hotline bei allen (nur bei mir nicht) seit >6 Monaten klaglos.