Sonos Probleme mit fhem Log

[raspklaus]

Hallo,

Ich habe einen Play1 eingebunden aber Probleme beim Starten von Fhem:

es erscheinen immer wieder die folgenden Meldungen

Code Auswählen Erweitern

Error messages while initializing FHEM:\
statefile: Reading Sonos_B__ro->AlarmList must not be used out of statefile.\
Reading Sonos_B__ro->AlarmListIDs must not be used out of statefile.\
Reading Sonos_B__ro->AlarmListVersion must not be used out of statefile.\
Reading Sonos_B__ro->presence must not be used out of statefile.

im Logfile wird dann

attr global motd none

das none gelöscht und die obigen Fehlermeldungen angehängt.

Wie kann man das abstellen ?

[Reinerlein]

Hallo raspklaus,

ich habe (passend zur Idee mit dem rereadcfg-Erkennen) Code eingebaut, der ein Speichern dieser Readings bereits verhindert. Dann kann auch keine Fehlermeldung beim Starten mehr kommen, da die angemahnten Readings im Statefile gar nicht existent sind...

Das habe ich für den Dev-Bereich eben aktualisiert. Nach dem Aktualisieren musst du das Reading "motd" des Devices "global" auf "none" stellen. Dann einen Neustart machen und alles sollte gut sein...

Grüße
Reinerlein

[raspklaus]

Ab wann steht das Modul zur Verfügung? Ein Updatecheck bei Dir sagt Nothing to do


Und dann die Einstellung

attr global motd none

[Reinerlein]

Hi raspklaus,

ich habe das in meinem Dev-Bereich hochgeladen:

Code Auswählen Erweitern


update all http://fhem.lmsoft.de/sonos_dev/controls_sonos.txt


Die Version ist mittlerweile auch wieder stabil

Grüße
Reinerlein

[rapster]

Hi Reinerlein,

bei mir mags natürlich mal wieder nicht 

Code Auswählen Erweitern

ERROR:
Reading Sonos_Bad->presence must not be used out of statefile. This is not an error! This happens due to restrictions of Fhem. Reading Sonos_Kueche->presence must not be used out of statefile. This is not an error! This happens due to restrictions of Fhem. Reading Sonos_Schlafzimmer->presence must not be used out of statefile. This is not an error! This happens due to restrictions of Fhem.


Er schreibt das reading auf jedenfall auch noch in die fhem.save:

Code Auswählen Erweitern


setstate Sonos_Bad 2014-11-21 18:51:08 presence appeared

Gruß Claudiu

[Reinerlein]

Hi rapster,

das klingt nach einem zu schnellen Test

Das Reading "presence" wird erst ziemlich am Ende der gesamten Player-Erkennerei gesetzt. Bedeutet, das es wahrscheinlich erst nach dem Absetzen des Neustart-Kommandos gesetzt wurde. Das war mir beim basteln zumindest häufiger passiert... hat etwas gedauert, bis ich das gesehen hatte...

Aber als ich gewartet hatte, bis alle Player sauber erkannt worden sind, klappte alles Erwartungsgemäß.

Versuch das mal bitte...

Grüße
Reinerlein

[rapster]

Hi Reinerlein,

hmm, hab den Text jetzt 3 mal gelesen, aber so ganz hab ich nicht verstanden was ich ausprobieren soll 

Habe ein update durchgeführt, aber nach einem rereadcfg erhalte ich immer noch diese Meldung.

Oder meinst du nach einem reboot bzw. shutdown+restart? Hier erhalte ich diese Meldungen nicht mehr..

EDIT:
Achso, glaub jetzt habe ich kapiert was du mir sagen wolltest, zu werten bis alle SONOS-Devices initialisiert sind.
Ja, das habe ich, geht ja relativ flott..


Gruß Claudiu

[Reinerlein]

Hi Claudiu,

hmm... ein "rereadcfg" habe ich ehrlich gesagt nicht probiert. Meine Programmierung ging tatsächlich nur auf "Shutdown" und "Save". Aber du hast recht, ich sollte das auch bei "Rereadcfg" machen...

Ich mache mal, und melde mich gleich wieder...

Grüße
Reinerlein

[Reinerlein]

Hi Claudiu,

das ging schnell

Kannst du noch mal probieren?

Danke schon mal..

Grüße
Reinerlein

[rapster]

Hi Reinerlein,

oha..

Auf Web:

Code Auswählen Erweitern

Cannot load module SONOSPLAYER
Please define Sonos_Kueche first
Please define Sonos_Kueche first
Please define Sonos_Kueche first
Please define Sonos_Kueche first
Please define Sonos_Kueche first
Please define Sonos_Kueche first
Please define Sonos_Kueche first
Please define Sonos_Kueche first
Please define Sonos_Kueche first
Please define Sonos_Kueche first
Please define Sonos_Kueche first
Cannot load module SONOSPLAYER
Please define Sonos_Schlafzimmer first
Please define Sonos_Schlafzimmer first
Please define Sonos_Schlafzimmer first
Please define Sonos_Schlafzimmer first
Please define Sonos_Schlafzimmer first
Please define Sonos_Schlafzimmer first
Please define Sonos_Schlafzimmer first
Please define Sonos_Schlafzimmer first
Please define Sonos_Schlafzimmer first
Please define Sonos_Schlafzimmer first
Please define Sonos_Schlafzimmer first
Cannot load module SONOSPLAYER
Please define Sonos_Bad first
Please define Sonos_Bad first
Please define Sonos_Bad first
Please define Sonos_Bad first
Please define Sonos_Bad first
Please define Sonos_Bad first
Please define Sonos_Bad first
Please define Sonos_Bad first
Please define Sonos_Bad first
Please define Sonos_Bad first
Please define Sonos_Bad first
Please define Sonos_BadRC first
Please define Sonos_BadRC_Notify first
Please define Sonos_KuecheRC first
Please define Sonos_KuecheRC_Notify first
Please define Sonos_SchlafzimmerRC first
Please define Sonos_SchlafzimmerRC_Notify first

fhem.log

Code Auswählen Erweitern


2014.11.21 20:52:39.207 0: SONOS0: Fehlerhafter Aufruf von CurrentBulkUpdate: RINCON_000E58B7AF1401400_MR
2014.11.21 20:52:39.276 1: SONOS0: The Method 'SONOS_getSonosPlayerByUDN' cannot find the FHEM-Device according to 'RINCON_000E58B7AF1401400_MR'. This should not happen!
2014.11.21 20:52:39.276 0: SONOS0: Fehlerhafter Aufruf von ReadingsSingleUpdateIfChanged: RINCON_000E58B7AF1401400_MR:DailyIndexRefreshTime:04:00:00
2014.11.21 20:52:39.277 1: SONOS0: The Method 'SONOS_getSonosPlayerByUDN' cannot find the FHEM-Device according to 'RINCON_000E58B7AF1401400_MR'. This should not happen!
2014.11.21 20:52:39.277 0: SONOS0: Fehlerhafter Aufruf von ReadingsSingleUpdateIfChanged: RINCON_000E58B7AF1401400_MR:ZoneGroupID:RINCON_000E58B7AF1401400:__
2014.11.21 20:52:39.278 1: SONOS0: The Method 'SONOS_getSonosPlayerByUDN' cannot find the FHEM-Device according to 'RINCON_000E58B7AF1401400_MR'. This should not happen!
2014.11.21 20:52:39.278 0: SONOS0: Fehlerhafter Aufruf von ReadingsSingleUpdateIfChanged: RINCON_000E58B7AF1401400_MR:fieldType:
2014.11.21 20:52:39.278 1: SONOS0: The Method 'SONOS_getSonosPlayerByUDN' cannot find the FHEM-Device according to 'RINCON_000E58B7AF1401400_MR'. This should not happen!
2014.11.21 20:52:39.278 0: SONOS0: Fehlerhafter Aufruf von ReadingsSingleUpdateIfChanged: RINCON_000E58B7AF1401400_MR:roomName:Kueche
2014.11.21 20:52:39.279 1: SONOS0: The Method 'SONOS_getSonosPlayerByUDN' cannot find the FHEM-Device according to 'RINCON_000E58B7AF1401400_MR'. This should not happen!
2014.11.21 20:52:39.279 0: SONOS0: Fehlerhafter Aufruf von ReadingsSingleUpdateIfChanged: RINCON_000E58B7AF1401400_MR:saveRoomName:Kueche
2014.11.21 20:52:39.279 1: SONOS0: The Method 'SONOS_getSonosPlayerByUDN' cannot find the FHEM-Device according to 'RINCON_000E58B7AF1401400_MR'. This should not happen!
2014.11.21 20:52:39.280 0: SONOS0: Fehlerhafter Aufruf von ReadingsSingleUpdateIfChanged: RINCON_000E58B7AF1401400_MR:roomIcon:kitchen
2014.11.21 20:52:39.280 1: SONOS0: The Method 'SONOS_getSonosPlayerByUDN' cannot find the FHEM-Device according to 'RINCON_000E58B7AF1401400_MR'. This should not happen!
2014.11.21 20:52:39.280 0: SONOS0: Fehlerhafter Aufruf von ReadingsSingleUpdateIfChangedNoTrigger: RINCON_000E58B7AF1401400_MR:Mute:0
2014.11.21 20:52:39.280 1: SONOS0: The Method 'SONOS_getSonosPlayerByUDN' cannot find the FHEM-Device according to 'RINCON_000E58B7AF1401400_MR'. This should not happen!
2014.11.21 20:52:39.281 0: SONOS0: Fehlerhafter Aufruf von ReadingsSingleUpdateIfChangedNoTrigger: RINCON_000E58B7AF1401400_MR:HeadphoneConnected:0
2014.11.21 20:52:39.281 1: SONOS0: The Method 'SONOS_getSonosPlayerByUDN' cannot find the FHEM-Device according to 'RINCON_000E58B7AF1401400_MR'. This should not happen!
2014.11.21 20:52:39.281 0: SONOS0: Fehlerhafter Aufruf von ReadingsSingleUpdateIfChangedNoTrigger: RINCON_000E58B7AF1401400_MR:Balance:0
2014.11.21 20:52:39.281 1: SONOS0: The Method 'SONOS_getSonosPlayerByUDN' cannot find the FHEM-Device according to 'RINCON_000E58B7AF1401400_MR'. This should not happen!
2014.11.21 20:52:39.282 0: SONOS0: Fehlerhafter Aufruf von ReadingsSingleUpdateIfChangedNoTrigger: RINCON_000E58B7AF1401400_MR:Loudness:1
2014.11.21 20:52:39.282 1: SONOS0: The Method 'SONOS_getSonosPlayerByUDN' cannot find the FHEM-Device according to 'RINCON_000E58B7AF1401400_MR'. This should not happen!
2014.11.21 20:52:39.282 0: SONOS0: Fehlerhafter Aufruf von ReadingsSingleUpdateIfChangedNoTrigger: RINCON_000E58B7AF1401400_MR:Bass:1
2014.11.21 20:52:39.283 1: SONOS0: The Method 'SONOS_getSonosPlayerByUDN' cannot find the FHEM-Device according to 'RINCON_000E58B7AF1401400_MR'. This should not happen!
2014.11.21 20:52:39.283 0: SONOS0: Fehlerhafter Aufruf von ReadingsSingleUpdateIfChangedNoTrigger: RINCON_000E58B7AF1401400_MR:Treble:0
2014.11.21 20:52:39.283 1: SONOS0: The Method 'SONOS_getSonosPlayerByUDN' cannot find the FHEM-Device according to 'RINCON_000E58B7AF1401400_MR'. This should not happen!
2014.11.21 20:52:39.283 0: SONOS0: Fehlerhafter Aufruf von ReadingsSingleUpdateIfChangedNoTrigger: RINCON_000E58B7AF1401400_MR:Volume:34
2014.11.21 20:52:39.284 1: SONOS0: The Method 'SONOS_getSonosPlayerByUDN' cannot find the FHEM-Device according to 'RINCON_000E58B7AF1401400_MR'. This should not happen!
2014.11.21 20:52:39.284 0: SONOS0: Fehlerhafter Aufruf von GetReadingsToCurrentHash: RINCON_000E58B7AF1401400_MR:0
2014.11.21 20:52:39.284 1: SONOS0: The Method 'SONOS_getSonosPlayerByUDN' cannot find the FHEM-Device according to 'RINCON_000E58B7AF1401400_MR'. This should not happen!
2014.11.21 20:52:39.284 0: SONOS0: Fehlerhafter Aufruf von CurrentBulkUpdate: RINCON_000E58B7AF1401400_MR
2014.11.21 20:52:43.384 0: Server shutdown


EDIT: Hab mal schnell wieder downgegradet bevor das log explodiert 

stdout ist im Anhang

Gruß Claudiu

[rapster]

Nur ein Gedanke von mir...

Habe alle Sonos Definitions in einer includierten sonos.cfg
Kann es damit zusammenhängen, hast du die defs in der fhem.cfg?

Gruß Claudiu

[Reinerlein]

Hi Claudiu,

arghh... ich habe eine Klammer übersehen... das passiert, wenn man das neben dem Filmegucken macht 

Bitte noch mal probieren...

Grüße
Reinerlein

P.S.: Ich habe meine Sonos-Komponenten auch in einer extra Datei. Das sollte ja auch eigentlich keinerlei Einfluß haben...

[rapster]

Hi Reinerlein,

passiert, das Problem ist soweit schonmal gelöst.

Allerdings leider immer noch nach einem rereadcfg:

Code Auswählen Erweitern

Reading Sonos_Bad->presence must not be used out of statefile. This is not an error! This happens due to restrictions of Fhem.
Reading Sonos_Kueche->presence must not be used out of statefile. This is not an error! This happens due to restrictions of Fhem.
Reading Sonos_Schlafzimmer->presence must not be used out of statefile. This is not an error! This happens due to restrictions of Fhem.

fhem.log + stdout nach einem rereadcfg habe ich angehangen.

[rapster]

Mir ist grad aufgefallen, dass nach einem "Save config" mit anschließendem rereadcfg, mal kein Fehler angezeigt wird, oder beim 2. Versuch wurde nur ein Player mit dem presence Fehler angezeigt.

[raspklaus]

Noch eine kleine Frage:

Als Cover wird immer das FhemSymbol angezeigt. Ist das so gewollt ?

[rapster]

@rapsklaus, ist bei mir nicht so (z.B. mit Spotify als Quelle)

Wird eigtl bei mir nur beim SPDIF-Eingang angezeigt.
Was nutzt du als Quelle im Player?

[Reinerlein]

Hi Claudiu,

komisch... Ich kann mir das nur so erklären, dass es dort eine Zeitdifferenz gibt, und die Readings wieder gesetzt werden, nachdem ich sie entfernt habe.
Leider kann man in Fhem keine Readings als "nicht-speicherbar" markieren. Das würde das Problem im Keim lösen...
Ich denke, wir werden mit der jetzigen Situation leben müssen. Ich hoffe, dass es in den meisten Fällen für einen ruhigen Start sorgt...

@raspklaus: Du solltest sicherstellen, dass du eine Cover-Liefernde Quelle ausgewählt hast (Audio-Eingänge machen das z.B. nie). Des Weiteren musst du Reload beim Browser drücken, da es kein Longpoll für Weblinks gibt...

Grüße
Reinerlein

[rapster]

Hi Reinerlein,

ja generell sehe ich so kleine Schönheitsfehler auch nicht als problematisch an, ob man das jetzt sieht oder nicht ändert erstmal nichts an der Funktion, genauso wie die ein oder andere warning im log/stdout.

Als interne Variablen lässt sich diese Value nicht speichern oder? Da hätten wir das Problem auch nicht..

Danke für deine Mühe, Gruß Claudiu

[Reinerlein]

Hi Claudiu,

von der Funktion her ist der Inhalt der Variablen ja ein Reading (mit der wichtigen Möglichkeit ein Notify darauf zu legen), und so sollte der Benutzer es auch verwenden können.
Es geht nur darum, dass nach einem Neustart sichergestellt ist, dass diese Felder keine Vorbelegung haben, da es sein könnte, dass der Zustand der Player sich während der Abwesenheit verändert hat...

Grüße
Reinerlein

[rapster]

Hi Reinerlein,

OK, dann muss man das mit dieser Warnung eben so hinnehmen.

Allerdings scheint sich heute irgendwie ein Fehler in der Dev eingeschlichen zu haben.

Seit dem letzten Update wo diese Warnung beim restart/rereadcfg entfernt werden sollte erhalte ich nun schon zum 3. mal beim restart von Fhem diesen Fehler und das Sonos Modul startet nicht:

Code Auswählen Erweitern


Bind failed: Die Adresse wird bereits verwendet at FHEM/00_SONOS.pm line 5212.
2014.11.21 22:28:35.020 3: Opening Sonos device localhost:4711
2014.11.21 22:28:35.020 3: Can't connect to localhost:4711: Verbindungsaufbau abgelehnt


Das erste mal ist es vorhin bei der Version wo die Klammer fehlte passiert, kommt sehr sporadisch..

Gruß Claudiu

[Reinerlein]

Hi Claudiu,

ich hatte das "rereadcfg"-Event falsch verstanden. Ich dachte es käme *vor* dem eigentlichen Durchführen (wie z.B beim "Shutdown"-Event). Es kommt aber danach

Ich habe da jetzt wieder einiges umgebaut, und bei mir jetzt schon ein Weilchen am Laufen... Sieht erstmal gut aus...

Kannst du das nochmal bei dir testen?
Danke schon mal...

Grüße
Reinerlein

[rapster]

Hi Reinerlein,

ich glaube es schaut jetzt gut aus 

habe zwar (nach dem ersten shutdown+restart in fhem) beim ersten restart nochmal das problem gehabt:

Code Auswählen Erweitern

root@fhem:~>service fhem restart
Restarting FHEM...
OLD Process ID: 3219
NEW Process ID: 3259
root@fhem:~>Smartmatch is experimental at ./FHEM/00_SONOS.pm line 3545.
Current: "fhem.pl", gPath: "./FHEM"
Smartmatch is experimental at FHEM/00_SONOS.pm line 3545.
Current: "FHEM/00_SONOS.pm", gPath: ""
Bind failed: Die Adresse wird bereits verwendet at FHEM/00_SONOS.pm line 5226.

Allerdings habe ich jetz nochmal ~30 mal einen restart durchgeführt und alles ist sauber durchgelaufen.

Ich werde es beobachten 

Danke dir! Gruß Claudiu

EDIT:
Ganz vergessen, die presence Fehlermeldung beim 'rereadcfg' ist nun auch weg 

[rapster]

Hi Reinerlein,

habe grad ein fhem-update durchgeführt, und nach dem obligatorischen shutdown+restart ist sonos nicht mehr gestartet.

Ich hatte leider kein stdout offen, allerdings da anschließend keine Sonos PID zu finden war, gehe ich davon aus dass es sich wieder um das Port Problem handelte.

Lässt sich evtl. für debugging zwecke ein Log definieren in welches der Subprozess schreibt? Da ja dieses Problem anscheining sehr unregelmäßig auftritt muss man natürlich Glück haben dass man grad ein passendes Terminal offen hat um die stdout Ausgaben zu erhalten.

Gruß Claudiu

EDIT:
gerade eben eine *.cfg bearbeitet und anschließend 'shutdown+restart' durchgeführt, und wieder das Problem

Code Auswählen Erweitern

2014.11.22 14:22:58.361 1: Including ./FHEM/sonos.cfg
Smartmatch is experimental at ./FHEM/00_SONOS.pm line 3545.
Current: "fhem.pl", gPath: "./FHEM"
2014.11.22 14:22:58.533 1: SONOS0: Kein UPnP-Server gefunden... Starte selber einen und warte 1 Sekunde(n) darauf...
Smartmatch is experimental at FHEM/00_SONOS.pm line 3545.
Current: "FHEM/00_SONOS.pm", gPath: ""
Bind failed: Die Adresse wird bereits verwendet at FHEM/00_SONOS.pm line 5226.
2014.11.22 14:22:59.535 3: Opening Sonos device localhost:4711
2014.11.22 14:22:59.535 3: Can't connect to localhost:4711: Verbindungsaufbau abgelehnt


Evtl. tritt das nur auf wenn fhem schon eine weile läuft?

EDIT2:
Also bei mir lässt sich das reproduzieren indem ich fhem ein paar Minuten (2 - 4 sollten reichen) laufen lassen und anschließend ein 'shutdown+restart' ausführe.
Anschließend startet sonos nicht mehr aufgrund des Port Problems.
Ich habe mal das gesamt log ab einem shutdown+restart angehangen.

[Reinerlein]

Hi Claudiu,

irgendwie will der beendete Perl-Prozess bei dir den Port nicht wieder hergeben...
Ich habe den Port jetzt mal auf eine andere Art geschlossen (vorher stand da close, jetzt mache ich es mit shutdown). Vielleicht gehorcht er ja jetzt...

Bei mir geht ein shutdown+restart auf jeden Fall immer. Da gab es noch nie Probleme mit einem geblockten Port. Das hilft hier jetzt nur auch nix

Die Logausgabe (STDOUT) wird bei mir direkt im Fhem-Startskript in eine Datei umgeleitet, sodass ich immer nachschauen kann. Das sollte bei dir doch auch möglich sein, oder?
Das Skript kannst du sonst ja auch parametrisieren, dann kannst du es für Debug-Zwecke anders aufrufen.

Grüße
Reinerlein

[rapster]

Hi Reinerlein,

ohhwee, das war ja mal wieder zu einfach um selbst draufzukommen, einfach stdout+stderr im initscript umzuleiten 

Aber das Problem ist leider gleich geblieben
Nach einem Shutdown+Restart wenn fhem schon eine weile läuft ist der Port noch belegt.

Code Auswählen Erweitern


Bind failed: Die Adresse wird bereits verwendet at FHEM/00_SONOS.pm line 5226.


Ich habe zum test auch die Waittime mal wieder auf 8 erhöht, hat leider nicht geholfen.

Gruß Claudiu

[rapster]

Vergessen zu sagen, ein rereadcfg funktioniert einwandfrei.

[Reinerlein]

Hi Claudiu,

der ist aber auch wirklich hartnäckig

Ich habe noch ein exit() dazugepackt, kannst du das noch mal probieren?

Danke schon mal...

Grüße
Reinerlein

[rapster]

Hi Reinerlein,

sogar hartnäckiger als du denkst ...denn es geht leider immer noch nicht

Das komische ist allerdings wenn ich ein 'shutdown+restart' mache nachdem alles fertig geladen ist funktioniert das einwandrei.

Wenn ich allerdings mit dem 'shutdown+restart' warte bis das erste mal das hier geloggt wird (~60sec nach fhem start):

Code Auswählen Erweitern


2014.11.22 17:16:24 1: SONOS0: Connection accepted from localhost:45131


Erhalte ich den Bind failed error

Gruß Claudiu

[Reinerlein]

Hi Claudiu,

sorry für das gestochere, aber ich habe wirklich keine Idee, was der Grund sein könnte...

Ich habe jetzt noch den Selektor leer gemacht... Aber ob das hilft??
Irgendwie fühlt es sich so an, als würde irgendwas das Beenden und freigeben des Ports verhindern...

Grüße
Reinerlein

[rapster]

Hi Reinerlein,

leider nicht geholfen

Nachdem das Bind Problem aufgetreten ist, kann ich auch erst nach ~1min Sonos durch einen shutdown+restart zum starten überreden, derweil tritt das Problem dauerhaft weiter auf.

Wenn du irgendwas benötigst was evtl. helfen könnte der Sache auf die Spur zu kommen, gib bescheid.

Gruß Claudiu

[Reinerlein]

Hi Claudiu,

aus irgendeinem Grund will dein System den Port nicht sofort wieder hergeben... ich weiss nicht, ob es dazu noch eine Perl-Einstellung gibt? kennst du da was?

Ich habe jetzt noch was an der Reihenfolge der Beendigung gedreht, und ein paar kurze Thread-freigebende Wartezeiten eingebaut... vielleicht bewirkt es ja was...

Grüße
Reinerlein

[rapster]

Hi Reinerlein,

hat leider wieder nicht geklappt.

Habe zwar früher recht viel mit Perl gemacht, allerdings kenne ich bzgl. Sockets auch nur close() und shutdown()
Wüsste nicht dass es da noch was anderes gibt, glaube nur mich zu erinnern dass nach einem shutdown() immer noch ein close() notwendig ist.

Allerdings habe ich grad meine Fhem-VM geclont, räum die mal noch bisl auf, richte noch schnell paar NAT Regeln in der Firewall ein, und lass dir mal die Daten zukommen.
Dann kannst du dich mal da draufschalten und Testen, ohne dass was kaputt gehen kann

Gruß Claudiu

[Reinerlein]

Hi Claudiu,

OK, das ging aus der Doku, die ich zu shutdown gelesen hatte, leider nicht so deutlich hervor... Ich habe jetzt noch zu jedem Shutdown ein Close dazugeschrieben...

Strohhalme, überall Strohhalme

Grüße
Reinerlein

P.S: Das mit der Testmaschine klingt gut... da kann man die Turn-Around-Zeiten etwas verringern

[rapster]

Hi Reinerlein,

das hier habe ich noch gefunden, evtl. hilft das?

SO_LINGER
              Sets or gets the SO_LINGER option.  The argument is a linger
              structure.

                  struct linger {
                      int l_onoff;    /* linger active */
                      int l_linger;   /* how many seconds to linger for */
                  };

              When enabled, a close(2) or shutdown(2) will not return until
              all queued messages for the socket have been successfully sent
              or the linger timeout has been reached.  Otherwise, the call
              returns immediately and the closing is done in the background.
              When the socket is closed as part of exit(2), it always
              lingers in the background.

Quelle: http://man7.org/linux/man-pages/man7/socket.7.html

Liegt es vll. daran das Sonos auf der Testmaschine früher geladen wird (weil sonst keine module geladen werden) dass Fhem komplett stirbt?
Wenn man hier evtl. einfach mal irgendein Modul davorstellt damit etwas mehr zeit vergeht, bzw. vll. funktioniert es auch mit einem simplen sleep?

Gruß Claudiu

[Reinerlein]

Hi Claudiu,

interessante Option, aber wir brauchen eigentlich genau das Gegenteil, nämlich blockierendes Warten, bis der Socket wieder freigegeben wurde (egal, ob das was da drin liegt noch abgeholt wird oder nicht).

Hier steht was davon, dass er das Schließen der Kommunikation dann im Hintergrund ausführt. Es fühlt sich so an, als würde er das hier an dieser Stelle auch machen...

Grüße
Reinerlein

[rapster]

Hi Reinerlein,

aber genau so versteh ich das ja auch:

When enabled, a close(2) or shutdown(2) will not return until
              all queued messages for the socket have been successfully sent[/b]
              or the linger timeout has been reached.  Otherwise, the call
              returns immediately and the closing is done in the background.

Also wenn man das aktiviert, sollte er quasi so lange das close() ausführen bis der Port wirklich geschlossen ist, bzw. der eingestellte Timeout erreicht ist.

Gruß Claudiu

[Reinerlein]

Hi Claudiu,

gewisse Dinge sollte ich wirklich nicht mehr spätabends machen Du hast wohl recht...
Ich habe es gerade mal eingebaut, und gleich den logischen Fehler gesehen, da es keine Veränderung gebracht hat:
Bei unserem Problem geht es darum, dass der Prozesstarter (die "Fhem-Ebene") erst dann den neuen Prozess anstarten dürfte, wenn der alte sauber weg ist (bzw. der Port wieder frei ist). Das wird aber über diese Option gar nicht gelöst. Zwar geht der SubProzess selbst erst dann weiter (zum exit()), wenn der Port geschlossen ist, aber der Prozessstarter weiß davon nix, und versucht trotzdem sofort einen neuen Subprozess zu starten, der dann doch wieder einen blockierten Port vorfindet...

Ich denke, wir haben es hier mit einer notwendigen Synronisation zu tun, die wir ja gerade in diesem Augenblick trennen wollen (die Verbindung), und der einzig saubere Weg ist da das zyklisch wiederholte Prüfen, ob der Port jetzt endlich frei ist...

Grüße
Reinerlein

[rapster]

Hi Reinerlein,

auf jedenfall schaut es ja jetzt ganz gut aus denk ich 

Grad mal verschiedenes ausprobiert was zuvor zu dem Fehler geführt hat, und das Modul startet einwandfrei!

Danke dir!
Gruß Claudiu