Homeserver "zu schnell"

[DB9WV]

poste doch mal die debug-Seite...

mfg Daniel

[Frank65]

Ich kopiere hier mal einen Teil meines Beitrages #10

"Besonders hat mich das Zeitverhalten in Bezug auf den vorgegebenen Rücksprung der Visu in das Startbild gewundert. Eingestellt auf 60 Sekunden, so hat es auch immer funktioniert. Und dann auf einmal kommt der Rücksprung reproduzierbar nach weniger als 10 Sekunden"

Dieses Verhalten stellt sich immer im Zusammenhang mit dem beschriebenen "Turbo-Zustand" ein. Es geht also nicht nur um die reinen Befehle, sondern betrifft wohl das ganze System

Die Debug-Seite werde ich heute Abend mal Posten. Vielleicht könnt Ihr damit etwas auswerten

Gruß, Frank

[Frank65]

Die Debug-Seite werde ich heute Abend mal Posten. Vielleicht könnt Ihr amit etwas auswerten

Gruß, Frank

.... mache ich bei nächster Gelegenheit, denn aktuell ist das Verhalten mal wieder in Ordnung

[spookyt.]

Ich hab gerade in der betroffenen Anlage auf die Debug-Seite geguckt.

Was heißt es, dass in der Spalte "IST" in der "SetWertQueue"-Zeile ein Wert > 0 steht?
Sieht irgendwas anderes verdächtig aus?

[MatthiasS]

Ziemlich unauffällig.

Wenn im Setwertqueue Werte unter IST stehen (wobei 12 noch moderat ist, in der Regel ist das aber 0), dann heißt das, dass Zuweisungen an INTERNE KO aus dem Puffer abgearbeitet werden, weil sie zu schnell auflaufen.

In dem Fall mal

- alle internen KO mit einer GA versehen (geht automatisch)
- im EIBMON interne KO anzeigen lassen
- feststellen, wer da ständig gesetzt wird
- ggf. anpassen

[spookyt.]

- alle internen KO mit einer GA versehen (geht automatisch)

Wie geht das automatisch?

[MatthiasS]

F1 drücken

Kommunikationsobjekte - Extras - Gruppenadressen vergeben?

[EPIX]

ein guter Ansatz ist die Prüfung ob Ausgänge nicht auf sbc gesetzt werden können - dies reduziert die "Gesprächigkeit" enorm....

Am Bus hast du schon mit der ETS geschaut ob es da ev. eine Quasselstrippe gibt....
Oder Webabfragen die dauernd laufen, auch die Baustein zum PINGen ist ein heißer Tip: wenn das Ping-Ziel nicht antwortet verursacht das auch Verzögerungen

[MatthiasS]

Am Bus liegt es mMn nicht. Erstens sind die Queues EIB... auf 0, auch der Count ist niedrig (im Verhältnis zum Setwert-Counter).

Interessant bei der Betrachtung der Queues wäre die Up-zeit des HS!

[EPIX]

Meine Vermutung geht dahin, dass HS-Logiken ständig ausgeführt werden, und daher die Tips WAS diese Logiken triggert....

Ich habe da einiges an Mühsamkeiten durchgemacht weil ich vor ähnlichen Problemen stand (Nachtlicht-Schaltung somit WAF-relevant)...

[spookyt.]

bei der Betrachtung der Queues wäre die Up-zeit des HS!

Hi Matthias, der Tipp war gut - vermutlich ist der Fehler behoben. Ich habe ein iKo gefunden, welches in eine Logik rein und hinten wieder beschrieben worden ist. Also mit maximaler Geschwindigkeit :-)

Danke auf jeden Fall für die Hilfestellung!

Nichtsdestotrotz bin ich der Meinung, dass das den Homeserver nicht aus dem Tritt bringen darf - auch nicht nach einer Weile. Ich finde, das sollte man sich bei Gira unbedingt mal anschauen! Auch in der Anlage laufen zeitkritische Dinge, bei denen 60 Sekunden nun mal 60 Sekunden sein sollten.

[Frank65]

So, als ich heute von einer Dienstreise zurück gekommen bin, hatte sich mal wieder der Zustand "Turbo" eingestellt.

Anbei zwei Screenshots aus der Debug-Seite

Die erste hardcopy habe ich erstellt, als der Homeserver deutlich zu schnell lief. Zu diesem Zeitpunkt war der HS ca 1 Woche nicht neu gestartet worden

Die zweite Hardcopy zeigt den Zustand, nachdem ich den HS neu gestartet habe und alles im normalen Zeitrahmen ablief

Könnt Ihr da etwas erkennen ?

Danke und Gruß, Frank

[spookyt.]

Hi,
ich tippe darauf, dass du auch irgendwo in der Logik eine Schleife gebaut hast. D.h. du steckst in die Logik vorne das KO rein und hinten wird es als Ergebnis wieder beschrieben. Dadurch wied dieses KO mit maximaler Geschwindigkeit (entsprechend der Zykluszeit) beschrieben. Das findest du leicht raus, in dem du -wie Matthias schon schrieb- mal alle iKos mit einer internen GA belegst und dann im qHSMon vom Makki guckst.

Oder hast du das schon ausgeschlosesn?

[Frank65]

So ... Ich glaube, dass ich die Ursache de Problems gefunden habe.

Die Überprüfung des Eibmon hatte keine Auffälligkeiten gezeigt. Keine Schleifen in der Logik oder ähnliches.

So wie ich das jetzt sehe, ist das komische Verhalten wohl aufgrund einer zu hohen Umgebungstemperatur entstanden.

Ich habe leider nur einen relativ kleinen Serverschrank im Hauswirtschaftsraum unterbringen können. Der Raum ist durch die anderen Geräte (Waschmaschine, Trockner, Gefrierschrank, ... ) sowieso schon recht warm und da kann die Wärme auch nicht effektiv abtransportiert werden. Im Serverschrank habe ich Temperaturen von bis zu 37 Grad gemessen und das scheint für den GIRA HS wohl ein Problem zu sein.

Jetzt steht der HS provisorisch außerhalb des Schrankes, kann die Wärme besser abstrahlen und bisher hat er keine Auffälligkeiten mehr gezeigt.

Kennt jemand von Euch den zugelassenen Temperaturbereich für den HS ?

Gruß, Frank

[TRex]

das wäre ja eine abgefahrene Erklärung..
Bei 37° dürfte das auf keinen Fall passieren.
Wie sieht das mit den anderen aus. Haben diejenigen mit denselben Problemen auch alle das Temperaturproblem?