12299 Squeeze Baustein

[MatthiasS]

..oder auch nicht

Syslog habe ich jetzt direkt dran. Trotzdem (2.25):

[MatthiasS]

Die Exceptions sind auch noch da:

02.11.2011 09:20:24 (132)
File "/hs/compile/hs_event.py", line 727, in doSend
File "/hs/compile/hs_fkt.py", line 160, in SockSend
error: (111, 'Connection refused')

Im Prinzip würden die Reconnects ja nicht stören, wenn er danach wirklich verbunden wäre. Tatsächlich ist die Verbindung aber tot. Kann man nicht so was wie einen Heartbeat einbauen?

[tbi]

dann nimm den 2.20 , den ich hier
reingestellt habe. Das ist der der bei mir fehlerfrei läuft.

Gruß Tbi

[tbi]

kannst du mal das GLE vom SystemLog posten ?

PS: Ich habe seit ich die direkte Verbindung drin habe, gar keine Verbindungsabrüche mehr.
Ich kann es also zu 100% reproduzieren.

Hier hat es Nils übrigens erklärt: https://knx-user-forum.de/162421-post122.html

Gruß Tbi

[tbi]

Also nun bin ich wieder etwas schlauer

Also, wo kann man sehen das DirektConnect angewendet wird: In debug vom SystemLog. Seht dort "DC: 1" ist am Ausgang 1 ein DirektConnect in Anwendung.

Es gibt drei Möglichkeiten zwischen SystemLog und XML ScrollList Baustein Verbindungen zu erstellen.

1. Über ein remantes iKO => Dann wird die gesamte XML Liste bei jedem berechnen des Bausteins gezipt, übergeben und entzipt. Der HS geht dabei ganz schön in Überlast. Die Reaktionen auf Lauter und Leiser extrem langsam.
2. Über eine direkte Verbindung => Wenn beide Bausteine DirektConnect unterstützen, wird statt der gesamten liste nur die Baustein ID und der Speicher übergeben. Das ist sehr schnell. Leiser und Lauter bei der Squeezebox geht fast in echtzeit.
3. Über einen Konnector im GLE => Hier werden auch DirektConnects gemacht. Auch das ist schnell.

Wer also viele Sachen am SystemLog zu hängen hat und sehr häufig eine Berechnung des SystemLog mit Übergabe zum XML ScrollList hat, wird sehen das sein HS ganz schön langsam wird.

Weil der HS dann so langsam ist, kann er nicht mehr die TCP Connection aussreichend schnell bedienen. Sie bricht ab und wird aber vom Baustein später wieder automatisch aufgebaut.

Also nochmal ganz klar: Das DirektConnect ist nicht das Problem, sondern die Lösung. Fehlt das "DC: 1" oder "DC: 2"
oder "DC: 3" obwohl an Ausgang 1, 2 oder 3 ein XML Scrolllist hängt, wird es mächtig langsam.

Viele Grüsse Tbi

[eckerho1]

Hallo Tobias

Vielen Dank für deine Analysen.

Habe bei mir jetzt mal auf dem Systemlogclient 2.003 upgedatet. Was noch auf 1.88.

Die XML Scrollist 2.002 hatte ich dabei auch im Einsatz. Das Scrol klappt bei mir aber nicht richtig. Rückwärts geht, aber an den Start komm ich nicht mehr. Darum bin ich bei der ScrolList wieder auf Version 1.4 gegangen.

Somit hab ich zwar kein DC mehr zur Verfügung, aber es geht recht flüssig.

Aenderungen an der Squeezebox via HS gehen bei mir realtime.

Gruss, Holger

[tbi]

gehst du über ein iKO ?

Was steht in debug bei SystemLog ? DC: ?

Gruß Tbi

[eckerho1]

Hallo Tobias

Ja, über iKO und im debug fehlt die Zeile mit dem DC. Also kein DC.

Ohne iKO kommt mit neuem Systemlog und alter Scrollist nichts aus der Scrollist.

Gruss, Holger

[MatthiasS]

In meiner Debugseite steht überhaupt nichts vom Syslog. Uralte Version, werde gleich mal updaten.

was ich nicht verstehe ist das hier:

Über eine direkte Verbindung => Wenn beide Bausteine DirektConnect unterstützen, wird statt der gesamten liste nur die Baustein ID und der Speicher übergeben. Das ist sehr schnell. Leiser und Lauter bei der Squeezebox geht fast in echtzeit.


Was hat die Syslog uns Scrolllist mit der Kommunikation zum SC zu tun?

[tbi]

@Holger: Du hast also die alte kommunikation. Die kann auch schnell sein, wenn die liste kurz ist. Wieviel eintrage hast du im SystemLog siehe bei debug. Jedesmal wenn der Baustein berechnet wird, wird die gesamte Liste gepackt und übergeben. Bei mir hat die Liste ca.210 eintrage mit Texten.

@Mathhias: Der HS hat nur eine CPU das verbindet beides. Wenn ständig ganze Listen gezipt werden, übergen und wieder entzipt werden müssen geht auch ein HS in die Kniee. Wenn die nun bei jeder GA ein .... ist schon klar.oder?

Den Debug bekommst Du wenn du es so in bei Conf drin stehen hast. schau mal in die Hilfe vom SystemLog.

vom Handy, kann also grad nicht nachschauen.

Gruß Tbi

[eckerho1]

Hallo Tobias

Momentan:
Buffergrösse: 1 Buffer 9.50/10 KB belegt
Einträge: 179/179

Ich schreibe allerdings nur Fehler und einige wenige Events dort rein.
Da reicht mir ein Buffer.

Gruss, Holger

[eckerho1]

Hallo

Für alle bei denen der 2.26er auch schon läuft.
Verbesserung in der Behandlung von Pause bei Ansagen.

Gruss, Holger

[tbi]

Ja, die liste ist schön voll. Wenn du aber nur selten was reinschreibst, bremst es auch nicht so. Ich schreibe im moment zum debuggen selbst Leiser umd lauter in SystemLog. Da merke ich sehr deutlich die Verzögerung, wenn ohne DirektConnect ist.


Das mit dem XML ScrollList, dass du nicht an den Anfang kommst merke ich mir mal. Muß ich mal selbst hinstellen.

Gruß Tbi

[MatthiasS]

Ich schreibe da - wie man sieht - überhaupt nichts rein. Mein FS war auch nie langsam. Fakt ist, obwohl ich die Meldung "verbunden" habe, komme ich nicht auf das SC.

Was gerade besonders spannend war: ich habe die Scrollist und den Syslog auf die neusten Versionen getauscht. Folge: der FS war dermaßen im Nirvana, dass das Nullmodemkabel her musste. Habe das Projekt auch auf meinem Ersatz-FS getestet, gleiches Ergebnis. Bausteine zurückgetauscht, läuft wieder. Ich wusste ja, dass die Bytecode-Bateine hochbrisant sind, aber so tot war ein HS bei mir noch nie.

[tbi]

Hi Matthias,

ich dachte du kannst mit dem Sqeezebaustein schon steuern. Nun sagst Du es geht gar nichts ? Was geht denn eigentlich?


Zu den neuen Bausteinen:Es kann sein, das die remanenten daten anders sind. also diese erst gelöscht werden müssen. zumindest die die die Bausteine verwenden.

Gruß Tbi