Squeezebox broken pipe SHNG 1.8.1

[wvhn]

Ich halte es nicht für zielführend, dass die lib.network sendet und sendet; niemand weiß, was für ein Gerät angesteuert wird und wie das Reaktionsverhalten ist.

Das sehe ich auch so. Nach längerem Ausfall der Verbindung stimmen die Werte vieler items in shNG sehr wahrscheinlich nicht mehr mit den zugehörigen GAs überein. Wenn lib.network einen Status übermitteln würde - ins Unreine gesprochen so etwas wie "reconnected after 2 hours of broken pipe" - dann könnte das knx-Plugin die items wie bei einem Neustart neu einlesen.

[Morg]

Jep. Die lib.network meldet zwar "Erfolg/Fehler" beim Senden zurück, aber da müssten die Plugins dann ggf. selber mit umgehen lernen, ob sie das auswerten oder nicht.

Ich halte es nicht für zielführend, dass die lib.network sendet und sendet; niemand weiß, was für ein Gerät angesteuert wird und wie das Reaktionsverhalten ist. Was, wenn von einem Kommando nur die letzten 4 Bytes nicht gesendet wurden und jetzt was ganz anderes passiert...?

Aber gut, dass es ansonsten läuft

Und ja - die lib.network ist ja in develop neu gekommen, und ich wollte die UDP-Server-Komponente nicht komplett neu (erfinden) schreiben

[wvhn]

Morg
Ich kann jetzt definitiv vermelden, dass der Fix das Reconnect-Problem löst. Selbst nach 2 Stunden Trennung vom LAN verbindet sich das knx-Plugin wieder mit dem knxd des Produktivsystems. Ohne den Fix ging nach so langer Zeit nichts mehr.

Danke und Gruß
Wolfram

EDIT: Im Log steht danach die Meldung

Detected disconnect from 192.168.2.12. send failed.

und der erste knx-Befehl wird verschluckt.

[wvhn]

Onkelandy Nee, bevor ich mich dann durch weitere Unverträglichkeiten quäle, mache ich einmal den Umstieg auf develop. Hat auch auch kaum weh getan

Morg, nach dem Update hat mein Testsystem nach zwei brute-force Unterbrechungen (LAN Stecker abgezogen 1x 5 min, 1x 15 min) die Verbindung zum knxd des Produktivsystems sofort wieder hergestellt.

EDIT: Kommando zurück: bei den o.g. Unterbrechungen schafft es shNG auch ohne den Fix. Ich muss erstmal die Dauer der Unterbrechung herausfinden, ab der shNG das ohne den Fix nicht mehr schafft.

Vielen Dank! Ich teste weiter.

Gruß
Wolfram

[Onkelandy]

Vermutlich reicht es, wenn du dir die Datei ins lib Verzeichnis legst.. aber ohne Gewähr https://github.com/smarthomeNG/smart.../lib/aioudp.py

[wvhn]

Morg Wenn ich die network.py in meine Installation (v1.8.2 Master) kopiere, bekomme ich beim Neustart von shNG den Fehler

2021-12-06 00:17:29 ERROR lib.plugin Plugin 'knx' error importing Python package: cannot import name 'aioudp' from 'lib' (/usr/local/smarthome/lib/__init__.py)

Ich pulle in den nächsten Tagen mal den Develop-Stand und teste dann.

Danke und Gruß
Wolfram

[Morg]

@Wolfram: ich hab mal einen PR als Lösungsvorschlag für die lib.network hochgeladen: https://github.com/smarthomeNG/smarthome/pull/429

Magst du den mal ausprobieren, ob das was ändert? Die Erkennung von "remote disconnect" und (ggf) der automatische Reconnect sind jetzt in der lib.network drin...

[Onkelandy]

Ich hoffe, das ist verständlich und korrekt, sonst bitte gerne kommentieren: https://github.com/smarthomeNG/smarthome/issues/427

[bmx]

Ein aussagekräftiges Issue mit einem knackigen Titel auf Github wäre gut damit das nicht untergeht.

[wvhn]

Keine Idee, aber eine Ergänzung. Bei mir hat sich der Pi, auf dem das Produktivsystem mit Busanbindung läuft, in letzter Zeit mehrfach vom Netz verabschiedet. Neustarten des Routers oder Umstecken des LAN-Kabels hat das Problem jeweils behoben. Neustart des Pi oder einzelner Services war nicht nötig.

Allerdings hat mein Testsystem, ein zweiter Pi, dessen knx-Plugin auf den knxd / eibd des Produktivsystems zugreift, jedes Mal die Verbindung irreversibel verloren. Die Fehlermeldung von lib.network war die gleiche. Ich habe auf dem Testsystem versucht, die Services für networking und eibd neu zu starten, aber reproduzierbar hat nur ein Neustart von shNG geholfen. Auch hier scheint der Autoreconnect von lib.network blockiert zu sein.

Gruß
Wolfram

P.S.: shNG-Version ist v1.8.2 Master

[Onkelandy]

Hi zusammen! Hat sich da noch was mit dem aktuellen Plugin ergeben oder hat das niemand mehr probiert..?
Es scheint nämlich doch sehr wohl ein Problem am Plugin oder lib network zu geben, das wohl auch jeder rekonstruieren kann..

Beim Start von shng ist der Mediaserver normal am Laufen. Alles gut.
Während des Betriebs starte ich den Mediaserver neu (was bei mir 5 Minuten braucht, warum auch immer). In der Zeit gibt es natürlich keine Verbindung Eigentlich sollte dann meiner Meinung nach self._squeezebox_tcp_connection.connected() nicht True sein. Aber ist es. Und da liegt dann der Haken...

lib.network       No connection to 10.0.0.100, cannot send data b'02%3A00%3A09%3Ae1%3Ae4%3A2c time %3F\r\n'. Error: [Errno 32] Datenübergabe unterbrochen (broken pipe)

Und weil das Plugin meint, man ist eh noch verbunden, kommt auch der Autoreconnect nicht in die Gänge..

Any ideas?

[yachti]

Ich bin auf das alte Plugin zurück und seit 2 Monate keine Probleme mehr mit Verbindungsabbrüchen.

[loeserman]

Hallo zusammen,
ich habe auch das Problem. Nun habe ich das mit dem Timeout in der Config auch mal ergänzt und werde es beobachten. Gerade geht es.

[yachti]

Moin Onkelandy

habe gestern Abend die Version aus der 1.7. aktiviert. Momentan funktioniert es noch.

Ich habe den Logitech Media Server Version: 8.1.1 am Laufen.
Ich habe auf dem Router einen Packetsniffer auf die Host IP vom LMS und Port TCP/9090 laufen lassen.
Wenn keine Datenpakete von SHNG kommen timed anscheinend nach einer gewissen Zeit die TTL Session aus und wird nicht reconnected.
Es kamen dann statt TCP ack /psh TCP fin Pakete. Dann hilft nur noch ein Neustart von SHNG. Vielleicht fehlt da ein "keep alive" wenn keine Daten von SHNG kommen.
Wie gesagt momentan läuft die 1.7. und warte mal ab bis zum Wochenende

Gruß

Michael

[Onkelandy]

Weiß nicht, wie alt die Version 1.3.2 ist, aber die wäre noch im plugin Ordner drin. Kannst du im plugin.yaml mittels plugin_version: 1.3.2 ohne Aufwand laden.
Hab bei meinem Squeezebox Setup übrigens keine Probleme. Aber vermutlich andere Serverversion und andere Netzwerkstruktur.