Problem: Miniserver Gen1 Reboot setzt KNX Kanäle auf 0

[bdaenzer]

Wegen hoher Auslastung und Reboots (es gäbe zu wenig freier Arbeitsspeicher) habe ich den Gen1 Miniserver mit einem GO ersetzt und den Gen1 quasi zur KNX Extension umfunktioniert in einem Gateway/Client Setup.
So weit so gut und hat ganz ordentlich geklappt. Und nett, dass das (auch mit mehr als 500 GA) möglich ist :-)

Nun hat der Gen1 trotz nunmehr 10% Auslastung immer noch periodische Reboots, wenn auch weniger häufig (natürlich nicht beruhigend) und ein weiteres Problem ist dazu gekommen:
Die klassische Programmierung ist ja z.b. KNX Sensor -> EIB Taster -> KNX Aktor.
Wenn der Gen1/Client nun unerwartet (oder auch erwartet, nach einem Update) rebootet, setzt dieser diverse KNX Kanäle auf 0 zurück!!!
So habe ich diverse geschaltete Steckdosen mit Strommessaktoren, welche eigentlich permanent ein sind zwecks Messung Verbrauch (TV, Kühlschrank [sic!] usw). Mit der genau gleichen Programmierung als Hauptminiserver hat so ein Reboot noch problemlos geklappt (wohl den KNX-Status erst einmal abgefragt bevor er eine 0 gesetzt hat?!).
Ich versuch's nun mal noch mit zusätzlichen Remanenzeinstellungen der Funktionsblöcke etc... zu retten.
Weiss noch nicht, ob dies zumindest teilweise das Problem abfedern kann. Ist schon jemand anderes damit ins Messer gelaufen?
Schade, dass solche Überraschungen, womit man nicht sollte rechnen müssen, zum Vorschein kommen.

In dem Zusammenhang ist mir auch aufgefallen, dass man wohl mit "Startimpuls" den Reboot eines Miniservers verarbeiten kann z.b. um irgendwelche Synchronisationsscripts zu triggern, beim Reboot mit dem Miniserver Gen1 als Client scheint es keine solche Möglichkeit zu geben?!

Oder liegt es an mir?

[IXMA]

Aus unserer Sicht funktioniert KNX mit Loxone nur zuverlässig wenn man den KNX "dumm" programmiert.
D.h. Sensoren senden Informationen über GAs an den Miniserver, der Miniserver verarbeitet die Daten und sendet diese dann wieder über GAs an KNX Aktorik raus. Bei einigen Anlagen haben wir z.B. auch einen GO Gen2 als Gateway und einen MS GEN1 als Client, das funktioniert soweit auch ganz gut, nur beim Speichern muss man Zeit haben. Die Erfahrung hat auch gezeigt, dass es ab ETS5 nicht mehr "schlau" ist, Geräte über die KNX Schnittstelle des MS zu programmieren.

Problem ist aus unserer Sicht nur immer Beschattungssteuerung mit KNX Aktorik.
Wie hast du die Programmierung aufgesetzt?

[bdaenzer]

Ich habe KNX auch immer schon auf "dumm" programmiert mit den Loxone Bausteinen dazwischen.
Gerade die Jalousien liefen sonst nicht wirklich richtig.
D.h. eigene GA für jeden Sensor und eigene GA für jeden Aktor und dazwischen war erst nur der MS Gen1.
Als dieser an den Anschlag kam neu jetzt eben den GO Gen2 als Gateway und MS Gen1 als Client mit allen KNX Sensoren und Aktoren, ohne wirkliche Änderung der Programmierung in der Zwischenzeit.

Probleme bereiten mir nun immer noch 2 Aspekte (Loxone Support konnte auch nicht fundamental wirklich helfen und ich war dann 2 Wochen in den Ferien)

- Immer noch periodische Reboots des MS Gen1 wegen "zu wenig freiem Arbeitsspeicher" obwohl die Loxone Config noch eine Auslastung von gerade mal 10% angibt, seit dem ändern auf Client/Gateway. Als der MS Gen1 noch "alleine Master" war, kamen die Reboots alle 4-5h (und Auslastung wurde mit über 100% angegeben), jetzt noch alle 3-5 Tage und eben 10% angegeben in der Config. Entweder stimmt die Anzeige der Config mit den 10% nicht, oder irgendwo gibt es ein Problem mit Speicher-Management oder irgend einem problematischen Programmteil. Was da hingegen etwas suspekt ist, es gab im letzten halben Jahr praktisch keine relevanten Änderungen, die Reboots kamen aber relativ plötzlich (zuerst mit der V12 und jetzt mit der V15).

- Seit der Änderung in MS Gen1 als Client/ MS GO Gen2 als Gateway sehe ich ein schlechteres Verhalten im Zusammenspiel mit KNX während Reboots des MS Gen1 Clients, mit der quasi identischen Programmierung. Wo vorher die Ausgänge der KNX Aktoren nicht geändert oder überschrieben wurden und sich das System über kurz oder lang mit den Zuständen auf dem Bus synchronisieren liess, indem man die KNX Status reports z.b. über Loxberry und Startimpuls getriggert hat oder periodisch Werte senden liess, überschreibt nun der MS Gen1 als Client erst einmal alle Aktorwerte nach dem Reboots bevor er die Werte übernommen hat! Und wehe, der Loxone Baustein hat zu dem Zeitpunkt den falschen Status... Mit zusätzlichen Remanenzeinstellungen konnte ich das Problem teilweise etwas entschärfen (vor allem bei den permanent eingeschalteten Messaktoren), habe aber immer noch Probleme weil die Remanenz nur periodisch gespeichert wird und das Timing eines Reboots durchaus doof liegen kann (Licht in den Kinderzimmern kurz vor/nach einschlafen z.B.).

Schade ist es etwas ein Gebastel. Ich bin eh schon stark ans Netzwerk gebunden via diverse Raspberry Pi Lösungen (welche alle übrigens super zuverlässig über Jahre funktionieren). Da überlege ich mir auch die KNX Anbindung so zu machen und dann ev den MS Gen 1 ganz raus zu nehmen. Sonst war mir eigentlich die Robustheit des MS mit KNX an Bord direkt noch sympathisch weil das weiter lief auch wenn theoretisch mal LAN unterbrochen (was aber in 10 Jahren nie vorkam)

[Jan W.]

Ich würde versuchen, die Ursache für die Reboots des MS zu finden. Bei einer Auslastung von 10% dürfte es keine Probleme geben. Die Auslastung, die Loxone Config anzeigt, ist aus meiner Sicht nicht wirklich hilfreich. Ich bin seit Jahren bei ca. 85%. Hilfreicher für Troubleshooting ist aus meiner Sicht der Loxone Monitor, der z.B. den freien Speicher (Heap), CPU, Stack und weitere Parameter anzeigt. Der Prozess "EIB" wird neben vielen weiteren Prozessen in der Liste einzeln angezeigt.

Sollte der freie Speicher tatsächlich im Laufe von Tagen weniger werden, dann gibt es ein Problem mit irgendeinem Baustein, welches der MS nicht vernünftig verarbeiten kann und daher irgendwann neu startet. Ursachen kann es dafür viele geben, u.a. fehlerhafte Pico-C Skripte, die Speicher nicht ordentlich zurückgeben, (leicht) defekte SD-Karten, zu kurze Intervalle und hohe Timeouts bei virtuellen Ein-/Ausgängen. Eine Ursachenforschung ist leider aufwändig und schwierig. Über ein Löschen von Objekten in Loxone Config und testen könnte man die Ursache evtl. eingrenzen. Die Ergebnisse der Projektanalyse und Loxone Health Check hast Du sicherlich schon durchgearbeitet, sofern es Punkte gab.

Ich habe längst nicht so viele GA's und mit ca. 160 EIB Sensoren und 140 Aktoren deutlich weniger KNX Objekte in meiner Config, aber der gesamte Rest inkl. Loxberry mit mehreren Plugins und 2 Pico-C Skripten laufen auch noch auf dem MS Gen 1. Da es seit etlichen Jahren stabil und ohne Reboots mit v14 läuft, vermeide ich ein Upgrade.

Du hast bereits festgestellt, dass man mit Remanenz und den von Dir o.a. Workarounds die durch Reboots entstehenden Probleme nur bedingt lösen kann. Ich würde nicht unbedingt davon ausgehen, dass ein MS Gen 2 mit KNX Extension die Probleme löst und zudem kommt die Beschränkung bei der Anzahl an GA's hinzu.